Golden Ratio This article by Ethan Marcotte on Responsive Web Design has been widely touted as the designer's panacea for all things mobile. Other leading designers such as Jeffrey Zeldman and Andy Clarke have all jumped on the band wagon. Considering the amount of influence these guys have on young designers, it saddens me that leading designers, of all people, would sacrifice their art on the altar of a quick fix.

Progressive Enhancement is the accepted philosophical approach to Web development today and demands an increased time investment on the part of Web Designers and Developers. Speaking as a Developer/Designer - yes, I'm one of those "Devigner" unicorns - with a background in ASP.NET Web Forms (gasp), I have finally accepted that my future will involve a return to the three-legged stool of all Web work: HTML5, CSS3 and JavaScript. Because of the importance of Progressive Enhancement and the extra time constraints it poses on any kind of Web project, I am justifiably wary of any and all new fads and buzz words that crop up like a bad outbreak of acne.

So what exactly is Responsive Web Design? In short, it's a technique that adapts a website's layout for multiple screen resolutions using a combination of fluid grids, images and media. CSS3 Media queries are then applied to toggle the layout width in response to the device width. The idea is to take a desktop version of the site and narrow it to fit in the smallest browser - set width breakpoints using media queries, say for mobile, tablet and desktop. This is akin to putting lipstick on a pig, not to mention the scrolling effect the user has to endure on smaller devices.

The focus of this post is on the "fluid" part of RWD and its disastrous consequences on the esthetics of any website built in this manner - designers should be able to get this. The technical problems with RWD are many and varied and have been well documented by others.  First off, here's a simple overview of the technical limitations:

1) Media queries are applied after content has been downloaded. This means that even for a mobile version, all markup, CSS, images and scripts are still downloaded. Considering the bandwidth limitations of most mobiles, this is a performance showstopper.

2) Media queries are not supported by legacy browsers or by most mobile handsets.

3) Fluid images are also a performance killer - you download images at their maximum size and set a maximum percentage width for them, leaving the browser to resize the images as needed - CPU intensive.

The Fluid vs Fixed debate started in the 90s and it's not my intention to fan those flames. Personally, I have always detested fluid layouts; they are anathema to good page composition. Between a mobile browser and a desktop one, there exists an almost infinite range of browser sizes outside of the break point widths used by your media queries. For any of these in-between browser widths, fluid layouts are going to change the composition of your page. And adding even more script to make your images fluid in order to compensate is only adding insult to injury - you just can't fix stupid.

Remember the time constraints imposed by Progressive Enhancement I mentioned earlier - where would you rather invest development time? Do you seriously think that a real world client is going to swallow this extra cost? Real life is all about priorities.

The Desktop and the Mobile are Two Different Animals

The Desktop and the Mobile are Different Animals There is too much over-analyzing of words like "context" going on these days. Is the user going to be lying on the couch or standing in line at the cinema when they access the site? Context? Bullcrap. Don't insult the user - they can figure out how best to use their devices - all we have to do is make sure that we don't try to display something in a smart phone that defies common sense - like 2MB PDF map downloads. And always include a link to the desktop version of the website. It's not rocket science but smart phones and desktops PCs are worlds apart, and it should be obvious that in most cases the mobile version of a website demands to be created separately and given individual attention. In addition, if future development or design enhancements need to be made to the mobile version, creating it separately makes total sense. Re-skinning a desktop version of a website and calling it mobile-ready makes as much sense as asking a whore for a hug.

The RWD zealots often use the "One Web" argument, citing Tim Berners-Lee:

    "The primary design principle underlying the Web’s usefulness and growth is universality. When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, software they use or human language they speak and regardless of whether they have a wired or wireless Internet connection."

Henry Ford may have been the first to mass produce the automobile but that doesn't mean I'm going to take driving lessons from him. One Web proponents also misquote the W3C in support of their argument. Here is a direct extract from the W3C on One Web:

    "One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts."

In fairness to the designers mentioned at the start of this article, a few of them have come out recently and advocated a more judicious use of RWD and basically said that each case should be taken on its own particular merits. This may be a little too late in my opinion and I think that Web professionals should think before they speak. RWD as an alternative approach to multi-device layouts fails in so many respects, both technical and esthetic, that it cannot be considered as a responsible approach to Web development going forward. In our world, there is no silver bullet. The myriad of Web-enabled devices out there demand extra work and this is a fact of life.

If you're still not convinced, here's a sobering thought: speed is going to be a make or break factor in all websites going forward. After your client gets past the initial "oohs" and "aahs" of viewing their new site on their iPhone, try explaining to them why their new, expensive site cannot be found via Google search...

Recommended Reading:

Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement
Designing with Progressive Enhancement: Building the Web that Works for Everyone 
Why Separate Mobile & Desktop Web Pages?

Comments (4) -

Nicolas France
8/30/2011 12:23:51 PM #


I think the good choice is somewhere between the 2 approach and depends of your constraints.

You have to face it, your classic fixed design, even if you add a mobile version doesn't fix anything. Now that high resolution screen at 1600x1050 or 1980x1200 are common (nearly half of steams users do have a resolution of 1600 or more), the web site made for 1024x768 appear small and unappealing.

The same goes true for mobile. You can put nearly nothing on small basic Android phones, but high end mobile phones have very fine screen going up to something like 800x400 or more (but still limited to 4inches at most).

Some of the most widely used sites in the world do have fluid layout. Think amazon. Think Wikipedia.

Of course it is difficult to have exactly the same website for a mobile phone. Even though the limitation you show are irrelevant (You can know  the target screen before sending content even on old browsers).

But for optimal result your site should adapt to the target screen. Most pragmatic way of doing this is to have several web site to differents devices but make them adapt to different resolutions.

admin United States
8/30/2011 1:32:24 PM #

I think you're on the right track Nicolas. I'm considering a separate site/folder for smart phone up to iPad. But any technique we use after that simply has to take bandwidth into consideration. Apart from that, I have a problem with the rigidity of grids and the lack of control over the page composition with the fluid layout.

I still have to experiment with the current fluid image scripts but if one could get that to work and serve up the images, or any other extra payload incurred, using separate sub-domains, that might mitigate the performance hit?

For example:

Thanks for the feed back Smile

CMS developer London
CMS developer London United States
11/1/2012 1:53:25 AM #

Pretty good post. I just stumbled upon your blog and wanted to say that I have really enyed reading your blog posts. Any way I'll be subscribing to your feed and I hope you post again soon

Jerzy Poland
3/14/2013 4:40:10 PM #

Your comment to Berns Lee:
"Henry Ford may have been the first to mass produce the automobile but that doesn't mean I'm going to take driving lessons from him. "
seems irrelevant. What do you exactly mean by this - that links are obsolete?

Pingbacks and trackbacks (4)+