First I want to say that my only interest in the technical details of web development are from an end user perspective. I usually go to this site to get my weather forecasts. Their current display format is to present the forecasts horizontally but it will likely be changing soon to vertical. My two most visited pages are the hourly and seven day forecasts. It's always annoyed me that on my display (16x9 laptop) most of the space is wasted. On the seven day page it doesn't matter, but on the hourly page it could easily display twelve hours or more of data.

But when the switch is made to the vertical format the hourly page will show only five hours of data with pointless "content continues below" page breaks. The seven day forecast shows only one day per screen. It seems to me that if you are planning, for example, a multi-day activity (perhaps a trip to the beach/cottage) it makes for easier planning to see multiple days (the more the better) on one page. For single-day events, perhaps a trip to the park, seeing more hours at once is much better than fewer.

My question (and I do have one) is, how difficult is it for the web site to customize the html for the target device? I realize that many more people would access this site on a smart phone than a desktop/laptop computer, but shouldn't major sites like this try to please both smart phone users as well as dinosaurs?

I don't care to learn javascript for this one simple thing. I just want to know if allowing for different displays is such a big deal. I know that Dani has designed Daniweb to be usable on both desktop and mobile devices. I was curious as to whether it was a technical nightmare to do so.

I don't care to learn javascript for this one simple thing. I just want to know if allowing for different displays is such a big deal.

In most cases you can achieve this by managing your CSS correctly. It's not a very big deal for most pages IMO.

So, not a big deal.

I'm thinking of the time I got on to the VLC Media Player forum and asked why VLC could not automatically trim unused black space from the player window that is added when the window is manually resized. It's something that is already done when you resize using alt-# shortcuts. This resulted in my getting flamed with comments like, "if it's so easy then grab the source code and just do it yourself."

Any qualified front-end web developer should be skilled enough in HTML and CSS in order to make a webpage responsive. (Responsive web design means that the design changes based on the form factor or dimensions of the web browser window).

However, what's more important here are UI/UX experts. These are the people who analyze existing data on how a webpage is used (e.g. tracking eye and mouse movements), and combine that with the website's business goals (e.g. what primary calls-to-action does the business want for users on any given page? e.g. click on a specific button, fill out a form, etc.), as well as behavioral psychology, to design the best overall experience for end-users, while subconsciously leading them to accomplish the business's goals.

Front-end web developers are like construction companies. They can build anything to spec. Web designers are like interior designers. They put the final touch on things. UI/UX experts are like architects.

Sorry, I was in a rush before and didn't finish my thought. In conclusion, you're asking the wrong question. You're asking how difficult it is to build something. The correct question is what thoughts and decisions lead to it being spec'ed out the way it is?

I suppose a better question would have been is it reasonable, or unreasonable to expect a major site like The Weather Network to allow for larger (desktop) displays rather than focus exclusively on mobile devices?

@RJ, don't take this badly but the change to smart phone viewership is there. People will pick up the phone and view such a site in a few seconds over booting up their laptop or bigger systems. And thus the efforts from major sites are going to be small screen viewing first and other, reduced efforts to give the desktop viewers what they want.
The other area Weather Channel seems to put time and effort into are Smart TVs which looks to me to look very different from the phone and Apple/PC laptop view.

Let's not discount the untold thousands of office workers who will also view the site on (likely) 16x9 or 16x10 displays. Most Smart TVs also use the same wide formats.

I think it's high time that web developers focused less on mobile users, and more on what is really important.

Me ;-)

commented: The smart tv's I've seen have the app, not the web page. +17

When I look at that website from my desktop, I see a design intended for desktop use, not mobile, so I’m a bit confused what you’re referring to.

If you’re wondering why the content doesn’t take up the full width of your browser window, neither does DaniWeb’s at very high screen resolutions. This is done from a UI/UX standpoint because it’s known to be easier for the eye to read and follow text and absorb bits of information this way.

I see a design intended for desktop use, not mobile

The current format is formatted for desktop, although I don't understand the logic in displaying only six hours on less than half a page, then requiring me to click something to "scroll" in six more hours. That would be like Daniweb using (effectively) only a third of my display height and rendering blank space on the remaining third (the rest being address bar, header, etc) and justifying it by saying "just scroll down to see the rest".

And regardless of how wasteful the current format is, the beta (likely to go live shortly) is even more wasteful showing less useful data per page.

I agree that filling the screen with solid text is hard to read, but we are talking tabular data.

zap2it seems to have a handle on it. You can select all channels, or sub-groups, and scroll up or down through the listings. It uses the full width of the display and allows you to select whether you want three hours on a page (more textual information) of six hours, and you can scroll left or right to show earlier or later shows. Very little wasted space.

One more take on your question "My question (and I do have one) is, how difficult is it for the web site to customize the html for the target device?"

Apparently a lot. As a user / visitor I am constantly annoyed by the "mobile first" approach in web design. In my perspective it all lies to the weird assumption that "one responsive design for all devices" is cheaper and works. It doesn't work , and I question if it is cheaper (compared to what ?).

More than 12 years now , we have encompassed the approach "adjustive and then responsive" , which mean that you split your view in (at least) two (desktop / mobile) (and in some apps in three) and then you use responsive based on screen sizes. That along with the "load once" perspective , that some years referred to as SPA (single page application) and now is fully PWA ( progressive web app ) worked really well.

I have tried to reason with people that are doing ONLY bare responsive web design , some don't get how they can have one source code with two views , some don't want to maintain two views (and end up to ridiculous amount of complex media CSS rules).

Of course really big companies ( Google , Netflix , Disney e.t.c. ) go with "adjustive and then responsive" but for some reason that never sounded right to the community.

I don’t think it comes down to cheaper. I think it comes down to SEO. Google only crawls mobile versions of websites nowadays, and has been clear in stating you lose your rankings if the mobile version differs in any meaningful way from the desktop version.

I, for one, use responsive design because I would never trust serverside to correctly determine a mobile browser in order to serve them different HTML.

you lose your rankings if the mobile version differs in any meaningful way from the desktop version

Seriously? You lose points for catering to a wider audience? Would providing the exact same data in a wider format count as meaningful?

Would providing the exact same data in a wider format count as meaningful?

It's encouraged to provide the exact same data in a wider format. Typically that is accomplished with responsive design, as the HTML remains the same and CSS is used to change the layout.

You can save this code as an HTML document, and also test several display resolutions. It will automatically set the resolution & associated color. It includes a related weather forecast.

<!DOCTYPE html>
<html>
<head>
<style>
body {
  background-color: lightblue;
  transition: all 0.5s;
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  min-height: 100vh;
  margin: 0;
  padding: 0;
  text-align: center;
}

/* CSS rules for different resolutions */
@media (max-width: 1280px) {
  body {
    background-color: yellow;
  }
}
@media (max-width: 1920px) {
  body {
    background-color: orange;
  }
}
@media (max-width: 2560px) {
  body {
    background-color: red;
  }
}
@media (max-width: 3840px) {
  body {
    background-color: green;
  }
}
</style>
<script>
var resolutions = [
  { width: 1280, height: 720, color: 'yellow', name: '720p' },
  { width: 1920, height: 1080, color: 'orange', name: '1080p' },
  { width: 2560, height: 1440, color: 'red', name: '1440p' },
  { width: 3840, height: 2160, color: 'green', name: '2160p' },
  { width: 720, height: 1280, color: 'purple', name: 'Vertical 720p' },
  { width: 1080, height: 1920, color: 'pink', name: 'Vertical 1080p' },
  { width: 1440, height: 2560, color: 'cyan', name: 'Vertical 1440p' },
  { width: 2160, height: 3840, color: 'brown', name: 'Vertical 2160p' }
];

function setResolution(width, height, color) {
  var container = document.body;
  container.style.width = width + 'px';
  container.style.height = height + 'px';
  container.style.backgroundColor = color;
}

function detectResolution() {
  var width = window.innerWidth;
  var height = window.innerHeight;
  var resolution = document.getElementById('resolution');
  resolution.textContent = 'Detected resolution: ' + width + 'x' + height;

  // Find the closest resolution
  var closest = resolutions.reduce(function(prev, curr) {
    return (Math.abs(curr.width - width) < Math.abs(prev.width - width) ? curr : prev);
  });

  // Set the resolution to the closest one
  setResolution(closest.width, closest.height, closest.color);
  resolution.textContent += '. Setting display to closest resolution: ' + closest.name;
}

window.onresize = detectResolution;
</script>
</head>
<body onload="detectResolution()">

<h2>Resolution Simulator</h2>
<p>Click a button to simulate a screen resolution:</p>

<button onclick="setResolution(1280, 720, 'yellow')">720p</button>
<button onclick="setResolution(1920, 1080, 'orange')">1080p</button>
<button onclick="setResolution(2560, 1440, 'red')">1440p</button>
<button onclick="setResolution(3840, 2160, 'green')">2160p</button>
<button onclick="setResolution(720, 1280, 'purple')">Vertical 720p</button>
<button onclick="setResolution(1080, 1920, 'pink')">Vertical 1080p</button>
<button onclick="setResolution(1440, 2560, 'cyan')">Vertical 1440p</button>
<button onclick="setResolution(2160, 3840, 'brown')">Vertical 2160p</button>

<p id="resolution"></p>

<!-- Weather widget -->
<div id="ww_57d1a9aa9126a" v='1.3' loc='id' a='{"t":"horizontal","lang":"en","sl_lpl":1,"ids":["wl2350"],"font":"Arial","sl_ics":"one_a","sl_sot":"celsius","cl_bkg":"image","cl_font":"#FFFFFF","cl_cloud":"#FFFFFF","cl_persp":"#81D4FA","cl_sun":"#FFC107","cl_moon":"#FFC107","cl_thund":"#FF5722"}'>More forecasts: <a href="https://oneweather.org/calgary/30_days/" id="ww_57d1a9aa9126a_u" target="_blank">Weather 30 days Calgary</a></div>
<script async src="https://app2.weatherwidget.org/js/?id=ww_57d1a9aa9126a"></script>

<div id="ww_d181e525f65aa" v='1.3' loc='id' a='{"t":"responsive","lang":"en","sl_lpl":1,"ids":["wl2350"],"font":"Arial","sl_ics":"one_a","sl_sot":"celsius","cl_bkg":"image","cl_font":"#FFFFFF","cl_cloud":"#FFFFFF","cl_persp":"#81D4FA","cl_sun":"#FFC107","cl_moon":"#FFC107","cl_thund":"#FF5722"}'>More forecasts: <a href="https://oneweather.org/calgary/30_days/" id="ww_d181e525f65aa_u" target="_blank">Weather 30 days Calgary</a></div><script async src="https://app2.weatherwidget.org/js/?id=ww_d181e525f65aa"></script>

<div id="weather">
  <script language="JavaScript" type="text/javascript"> 
   document.write('<script language="JavaScript" src="https://www.myweather2.com/Plugins/weather/general.ashx?type=js&n=1&t=6&x=f1_day&inc=True&w=300&h=200&headerbgcolor=284252&headertextcolor=&temp_unit=1&windspeed_unit=2&puref=dad2ce00-b79f-4eef-a3a8-3365f3e58a57&cb=' + Math.random() + '" type="text/javascript"><\/scr' + 'ipt>');
  </script>
  <noscript><a href="https://www.myweather2.com/City-Town/Canada/Manitoba/Winnipeg.aspx" title="Winnipeg">Winnipeg weather forecast from Weather2</a></noscript>
</div>

</body>
</html>

Hope that helps. :)

Hello , it took me a while to respond, sorry for that. I also use responsive web design , just adjustive and then responsive. I totally agree with you Dani on:

Google ... has been clear in stating you lose your rankings if the mobile version differs in any meaningful way from the desktop version.

But I don't understand why anyone would want to serve different content in a mobile web app than to the desktop version of it. My templates always have one (and only one) main section and that HTML is the same in any meaningful way in mobile and in desktop (the css rules may be different on it) (there might be some minor differences in HTML but in a very few occasions and never on the real content) . What you need different in a mobile web app (in HTML perspective) is the main template , think it as the scaffold . You need different structure for the menu or the top icons or the logo or what ever. Of course you need different CSS rules and last but not least DIFFERENT JavaScript.

I wrote it with capitals letters because it makes me furious that so many (so many) sites have issues when you visit them from a mobile or tablet because they didn't account that the JavaScript events SHOULD be different. Luckily for that we have "jquery mobile just touch" for that and if you create a layer above that with same event calls in mobile and in desktop you don't even have to remember what does what (for example if you extend jQuery with a onClick function that used the native jQuery click on desktop and on("vclick") on mobile than you can just use $("...").onClick() in both)

About the part

I would never trust server-side to correctly determine a mobile browser in order to serve them different HTML

, yes the first years we had to check more often , but now the detection libraries have matured and we don't face any issue. Moreover as a safety net we make both versions to "report back" if something is weird in the dimensions (for example if the app has identify it as desktop version but the screen width is lower than 500px , but also some other rules). I rarely have to intervene there , maybe once a year or so.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.