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
11 reasons why Responsive Design isn’t that cool!
Why Separate Mobile & Desktop Web Pages?




RIA Scott Guthrie has just announced that Microsoft is going to include the JQuery JavaScript library as part of Visual Studio 2008 SP1 and the free Visual Web Developer 2008 Express SP1. JQuery is has quickly become the most popular JavaScript library out there, despite the competition and weighs in at only 15KB.

On the face of it, this is an unprecedented move by Microsoft. Nobody would have even dreamed of seeing an open source project being adopted by the Big M... exciting times! They are going to make it an integral part of their own framework and build upon it in the shape of controls for the ASP.NET AJAX Control Toolkit and new Ajax server-side helper methods for ASP.NET MVC.

My achilles heel as a developer has always been my limited knowledge of JavaScript but I recently took steps to immerse myself in it. Having JQuery to build upon is like getting Christmas early and should provide some great fun and excitement over the coming few years as we start to construct richer and more creative Web experiences.

Some JQuery Resources:

    * 10 Smart JavaScript Techniques
    * 10 Useful JQuery Plugins
    * Comparing Popular JavaScript/AJAX Frameworks
    * JQuery Documentation
    * JQuery Selectors Reference Card (PDF)

kick it on DotNetKicks.com