I have already written a couple of articles for Simple-Talk about Responsive Web Design (RWD), one of which is “Responsive Web Design: the Costs”. That article and this one together form two-third of a mini-series dedicated to Responsive Web Design as it happens to be today, late summer of 2014. The third article of the series will discuss an approach that takes the core idea of RWD one step further towards the relatively new concept of form-factor.

The content of this article is inspired by another article I wrote about a year ago for Simple-Talk, titled “Aiming for a Truly Responsive Web Experience“. That article offered an overview of the issues you may run into with RWD and pointed out at a few alternate options. A year has passed, though, and our understanding of the good and bad aspects of RWD has solidified. The good of RWD has remained stable while the awareness of the bad in RWD has increased a little bit amongst web developers.

In this article, I’ll focus on the objective downsides of RWD. It should be noted that a downside is not, by itself, a good reason to avoid RWD. It represents, instead, a stimulus to explore alternatives and make a well-considered decision.

Let’s just call it performance

In many discussions over the web as well as in technical meetings, it’s common to come across the statement that “we mostly do RWD-only apps now and we completely bypass the problem of detecting requesting devices.”

There is some truth in this idea. A web solution that relies on RWD for its user interface is definitely responsive to different devices and no line in the source code ever cares about figuring out the actual capabilities of the requesting device. To many, this sounds like the Egg of Columbus.

The problem with taking this idea too literally is that it offers an over-simplified perspective of the real world requirements. There is a catch, and one that will cause any software architect to wince.

So what is the catch in saying that RWD allows you to build user interfaces that automatically adapt to the size of the requesting device? In short, it is the performance issue. More specifically, it is the:

• Excess of downloaded data
• Impact on the actual bandwidth
• Overall user experience
• Complexity of development and project management

Today a responsive site not only has to work on desktops and look nice on cell phones, but has to work effectively and enjoyably on any devices of present and future – and in some cases even devices of the past (read: legacy three or four years old devices, such as those running now antiquated 2.x versions of Android).

You would, I’m sure, agree with this. However, there is a paradox. RWD solves the problem of having a responsive site that is capable of serving any devices by ignoring the nature and capabilities of the individual device.

What is “responsive” and what is “device”?

At first sight, RWD may just seem like a brilliantly simple solution for a thorny problem; something like the general “Divide-et-Impera” strategy or, focusing on software development, the Command Query Responsibility Segregation. (CQRS) architecture. To be responsive, RWD uses only one “key” parameter–the width of the screen. Thanks to CSS3 Media Queries, software developers link multiple CSS files each bound to a CSS3 Media Queries expression. Each applied CSS file reflows and reshapes the content to make it fit in the available space.

The CSS3 Media Queries supports a few parameters but the focal one is the width of the screen. Making a site responsive to variable screen width is an excellent move if the device is always the same-say, the desktop. Generalizing this trick to just any devices, though, leads to considering a desktop browser window resized to, say, 800px to be the same as a full-screen tablet browser.

From a purely user interface point of view, this similarity makes sense; but what about a user experience point of view? And what about performance? A desktop is not the same as a tablet or a smartphone; yet RWD leads to ignoring these key differences in the name of pure responsiveness.

In a nutshell, “responsiveness” based on the CSS3 Media Queries parameters makes sense but in the context of just “one” class of devices. If you want to achieve cross-device responsiveness, then RWD and CSS may not be the ideal tool. True cross-device responsiveness comes from detecting at least the “type” of the device (whether it’s a smartphone, a tablet, a smart-TV, a legacy phone) and serving ad hoc markup to each device.

Once you’ve got this far, be ready to face a couple of objections. One is that device detection means writing multiple versions of the site, one for each class of device. Another is that detecting the device means sniffing the user agent string which is something that many developers did in the past for desktop browsers and it was more than painful. I’ll specifically address these two points in a future article-the third of the RWD mini-series.

A Quick Look at CSS4 Media Queries

Last June W3C released the first public draft of upcoming CSS4 Media Queries standard. You can read more at http://dev.w3.org/csswg/mediaqueries-4. The new standard adds a few more properties but, in my opinion, it doesn’t resolve the core problem of building responsive user experiences rather than simply responsive user interfaces.

According to the current draft, for which WebKit provides a bit of support already, developers can rely on new properties such as scripting, pointer and hover. (See table.)

It turns out that it is a bit easier to detect non-desktop devices because you can rely on a combination of Hover and Pointer. The pointer = coarse setting, in particular, gives an easy way to switch to a user interface for tablets with buttons and clickable items just rendered larger.

This expression, though, doesn’t capture when a browser window is resized to 800 pixels. For that, you also need the following:

The more properties that become available, the easier it becomes to render the markup appropriately for various scenarios. At the same time, more properties mean more scenarios and more scenarios mean more CSS stylesheets to write and maintain.

Worse yet, CSS doesn’t create anything. CSS only renders the “same” content in different ways, albeit with some restrictions. With RWD, the markup returned is always the same regardless the device; it’s only the CSS file that changes and refers, for example, different images to partially minimize amount of download. Your biggest problem becomes working out a “one HTML” configuration that can be easily turned into different visual elements. Just to make an example, switching from drop-down menu to tabs may not be easy. Let’s go more in detail in the issues identified earlier.

Issue #1: Excess of downloaded data

Just the strength of RWD-the one site experience-becomes a notable weakness. It’s always the same type and amount of HTML that is returned. The markup necessarily targets the largest possible scenario. So you often download markup and then subsequently hide it on smaller devices.

The popular mobile-first methodology is out of place here. Mobile-first refers to a design approach that reasonably suggests you focus first on smaller devices and then rework the markup in light of larger screens. Depending on the actual content to display, it might be that you just end up with “one HTML” for the largest scenario. Or, worse yet, you realize you can’t do it with “one HTML”. So you design a different HTML for scenarios. Unfortunately, though, with RWD all markups are downloaded and only one is displayed at a time.

Issue #2: Impact on the actual bandwidth

Clearly, the amount of downloaded data has an impact on the use of the bandwidth and the actual download time. If you’re viewing a complex page on a desktop and you resize the browser window to 800 pixels, you won’t experience anything bad. Most, if not all, of the content is already in the cache and all of it is going to be used when the browser window is brought back to full screen size.

However, the same is not true if you look at the same sequence of events from a small device perspective, instead. You can’t fit the content of a 13″ large screen into a 4″ screen. So most of the content has to be discarded; on the other hand, isn’t this the classic 80-20 rule of mobile development? The problem is that with small devices you download 100 to consume 20. Bandwidth is not a problem? It’s likely not an issue for desktop computers connected over powerful wifi networks: But what about smartphones working on the go-over-slow 3G connections? An otherwise nice-looking SPA site using AngularJS and RWD design may look like in the picture:

But there’s more to it.

Issue #3: Overall user experience

Either the idea that mobile users expect web sites to be slow is a misconception or I’ve been so unlucky so far to find only customers who find slow sites just unacceptable. The excess of markup which is not optimized for download on mobile devices strikes just where connection is likely poor-while on the go.

Each class of device is different-desktop computers, smartphones, tablets, mini-tablets, smart TV, wearable devices, old cell phones. ‘Form-factor’ is an emerging term for referring to classes of devices. Some of these classes are likely edge cases unless you’re Facebook or the next big thing in social, but smartphones, tablets and desktops are just everyday business.

Smartphones, and to some extent tablets, may require their own user experience and to provide that you must serve ad hoc markup-which also happens to be far smaller. Your choice is easy in the end: worst of all versus best of all.

Issue #4: Complexity of development and project management

To distinguish tablets from smartphones, and both from desktop computers, you need to look at the user agent string. Frankly, it’s not a task to take on lightly and you are better-off with the expert help that you get by paying some money in licenses. However, if you just focus on detecting the form-factor you can find some free, or partly free, options.

A server-side device detection solution is as easy as using display modes in ASP.NET MVC. You manage several distinct Razor views that are independent and relatively simple. The MVC view engine then just selects the most appropriate view based on context-condition Boolean expressions. (See http://www.simple-talk.com/dotnet/asp.net/multiple-views-and-displaymode-providers-in-asp.net-mvc-4.)

By using ASP.NET MVC you can focus on one form-factor at a time or even multiple in parallel. More importantly, each form-factor view is independent. You can use distinct technologies, distinct design, even RWD.

In a single RWD approach, every addition or modification you make to the HTML may have a consequential impact across the whole spectrum of devices of today and tomorrow. Also, from a management perspective, things are harder than with plain ASP.NET projects. You’re only done when you’re done; no intermediate steps to release quickly. It’s a “one solution” approach that is all-or-nothing.