Expressions like “DLL hell” and “browser wars” may evoke ugly memories in seasoned developers. “DLL hell” referred to mixing different versions of libraries in the same project and application. The “browser wars” referred to writing web pages in the faint hope that they could display more or less the same across various browsers. Around the time the .NET Framework and ASP.NET were released developers hoped that hard times were finally a thing of the past – just an ugly memory, serving only to inspire anecdotes and fantasy stories to be told during breaks.

We were all wrong.

At some point, mostly thanks to an unrepeatable astral conjunction, we reached a stable point of balance for browsers. In particular, we reached a point where most widely-used versions of the most popular browsers were offering the same set of features. Moreover, this set of features was powerful enough to enable interactive Ajax scenarios and script-led connections as opposed to classic browser-led navigation.

You could finally write a web page to download data programmatically and refresh the document in a way that was both quick and effective on the vast majority of browsers. It was just like a cherished dream coming true. Human nature being what it is though, we seek stability and then, when we reach it, we immediately start finding ways to break it. So browser stability couldn’t last for too long.

Two factors contributed to this: HTML5 and mobile devices.

Newest versions of browsers support more and more advanced features, but only a fraction of users use these browsers. While the number of users on more recent versions grows every day, we’re still far from the critical mass of users that could induce stability and take the industry close to a new point of balance.

The proliferation of different devices are a new, different story – one this article aims to tell.

Device detection

The browser war originated from the proliferation of dozens of different browsers, all with different approaches to web standards. The number of different devices out there, however, can be counted in the order of thousands. Writing pages that can display well on single devices is therefore out of question. Instead, you should look to reduce the number of target devices to just a few families of devices – things like smartphones, tablets, or perhaps smart TVs.

When it comes to this approach, developers like to prove that they learned a lot from the browser war of some years ago. So they point out that it’s smarter to focus on effective device capabilities rather than coding a specific behavior based on a browser’s brand and name. While largely commonsense, this principle is, however, quite hard in execution. So many think that you should just ignore features of a device, focus on screen size and let CSS do some magic for you rearranging content to fit in a stricter or larger layout.

This is the essence of Responsive Web Design (RWD). Is RWD good? And more importantly, is it always good?

Overall, I think that RWD is good, but I’m not sure it is good for everyone and every project. As a design approach, RWD is nice and smart as it ensures a well laid out content at any screen (re)size. But it’s up to the developer to reasonably determine whether RWD works for a given project.

To get an idea about the effectiveness of RWD, let’s examine a popular website: http://www.microsoft.com/visualstudio/eng/. If you open the site and then resize the browser’s window, you’ll see that the content is rearranged to fit nicely in the available space. Now, press F12 to open the IE Developer Tools and select the “Always refresh from server” option from the Cache menu. Clear the list and hit F5 to fully download the page. You’ll see that the home page of the site downloads a bit more than 2.5 MB. Now try setting the user agent string to that of a smartphone. For example, you can use the following:

Mozilla/5.0 (Linux; U; Android 2.1; xx-xx; HTC Desire Build/ERE27) AppleWebKit/525.10+ (KHTML, like Gecko) Version/3.0.4 Mobile Safari/523.12.2

Leave the browser’s window at full screen, clear the list and the browser cache and refresh the page with F5. You should get the same amount of downloaded data. It’s weird, isn’t it? Try now reducing the browser’s window to the size of a smartphone browser. The view you get is nice; but the total download is only a bit smaller and still beyond 2MB. Now change to, for example, a Galaxy Tab user agent.

Mozilla/5.0 (Linux; Android 4.0.3; GT-P3110 Build/IML74K) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Safari/535.19

You get the same numbers as for desktop if you leave the browser’s window full screen and even if you reduce it to nearly the size of a tablet. The table below summarizes the results.

Let’s try to make sense of the results. The first aspect to consider is that the total download size doesn’t change at all if the browser is kept full screen. This happens regardless of the user agent set. In other words, there’s no check on the server side for the type of the requesting device. In fact, there’s no server-side code at all. It all happens within the browser; the browser sets a different set of styles based on the current screen width. This means that tablets and desktops are treated the same way; and smartphones (or any screen with nearly the size of a smartphone screen) are served slightly smaller images which accounts for some 30% saving on the amount of data the browser downloads.

The HTML page is bound to a CSS file that uses media queries to define a few breakpoints: at 478px, 768px, 996px and 1200px. It means that the site defines different rule sets for screen sizes that fall in between. The overall design of the page and, more importantly, its set of use cases doesn’t change at all for tablets or smartphones.

What you get in the end is rendering that adapts to the actual screen size; you won’t get any device-specific design or experience. Note that this may be a big issue for some apps and sites as a too rich user interface may stress the battery and take up too much bandwidth. As smartphones are used on the go, it’s worth minimizing the amount of bandwidth and battery your site taxes.

Beyond RWD

RWD is a nice way to make a site fit onto a variety of screens of different size. I haven’t used the term “device” here and with a specific reason: RWD is not about devices. RWD is about switching CSS rule sets based on the properties supported by the CSS Media Queries standard. This standard takes into account only the following properties with the value assigned to them by the browser.

You can find full documentation about CSS Media Queries at http://www.w3.org/TR/css3-mediaqueries. It should also be noted that the standard is going to be extended with CSS4. However, based on what has been unveiled at the time of writing, the number of properties that designers will be able to incorporate in their media queries is larger, but still won’t include properties that reliably work based upon the operating system or just the class of the device-whether smartphone, tablet or PC.

More and more applications require that you provide a specific experience made-to-measure for tablets and smartphones at the bare minimum. For more and more applications this just means rethinking the entire set of use cases, the information architecture, and finally the overall graphical layout that should put touch and common gestures at the center of the design.

RWD is all about a responsive design; it’s much more likely that you need a responsive experience. However, for certain types of web sites that are mostly read-only-for example, news portals-the RWD option is simple, cheap and effective. It starts getting hard to stick to RWD when you have a web site that implements workflows and requires a lot of interaction through input fields. In this case, just moving around input fields to fit the smaller screen of mobile devices may not be the ideal choice. In this case, you might want to reconsider the use cases and the workflow as a whole. Also, sometimes you might want to add new functionalities or present data aggregated in a different way when on mobile devices. For all these scenarios (which I bet will be more and more common in the coming months) there’s not really much you can do with RWD.

Let’s investigate how one could set up a solution that switches HTML views instead of switching CSS rule sets on top of the same HTML markup.

Towards a Responsive Experience

If you intend to provide a truly device-specific experience-whether tablet, smartphone, legacy phone, smart TV, desktop PC, and the like-first and foremost you must know about the capabilities of the device. Capabilities of the device are a potentially long list of name/value pairs that describe what a given device can or cannot do for you. Capabilities include the operating system, the browser version, whether the device can support video streaming, has a GPU accelerator, supports inline images, touch, can host a SIM card, as well as a bunch of HTML5/CSS specific capabilities.

At the very minimum, though, you want to know about some virtual capabilities of the device-whether it is considered a tablet, a smartphone, a desktop browser or a smart TV. Based on this information, your website can intelligently serve ad hoc markup to the browser making the request. In other words, instead of switching CSS rule sets, you end up switching HTML views. In doing so, you get a chance to completely redesign the experience for tablets or smartphones.

Where do you get device information? Device information is usually inferred from the user agent string. However, you don’t have to build and maintain yourself a database where the user agent string is the key and a dictionary indicates capabilities. Such databases already exist and the best you can do is getting a license to the on-premise or cloud edition of such a database and its API. Where would you find this? Well, Google and Facebook use WURFL (http://www.scientiamobile.com) and WURFL comes with on-premise and cloud solution and related API for PHP, .NET, Java and C++. For ASP.NET developers, WURFL also has a handy Nuget package. Free for open-source projects, WURFL comes at a cost but enables you to know everything about any present and future devices.

In ASP.NET MVC, you can use display modes to automatically route views based on the information you get from WURFL. For more details and an example of how to use display modes have a look at http://www.simple-talk.com/dotnet/asp.net/multiple-views-and-displaymode-providers-in-asp.net-mvc-4/. A WURFL-specific example of ASP.NET MVC display modes can be found on MSDN Magazine here: http://msdn.microsoft.com/en-us/magazine/dn342866.aspx.

Server-side plus Media Queries

Opting for a server-side feature detection of the device doesn’t prevent you from using RWD and media queries. Tablets and smartphones are not all the same. A tablet is considered a tablet whether it has 10″ or 7″ screen and similar things happen for smartphones. You can hardly provide a single good enough HTML experience without RWD. So you can get the best of both worlds: you use server-side detection and WURFL to identify the right set of use cases and UI layout. And then when you call the ASP.NET MVC view engine to render out HTML markup, you just return markup based on RWD and targeting breakpoints and liquid layouts that effectively serve 10″ and 7″ screens.

In the end, RWD and server-side detection (i.e., WURFL) is not an either/or choice. The best you can do today is to mix them up in a responsive experience. This is sometimes called RESS (Responsive Design + Server-Side Components), but I believe that responsive experience (as opposed to responsive design) is a much better term.