The only way responsive web design works is if it is thought of as a strategic engineering approach encompassing all facets of development, not a strict presentation solution.


There’s been lots (and lots) of talk about responsive web design (RWD). There’s been lots (and lots) of development in this area, from JQuery plug-ins to CSS processors to grids.

When you’re done reading this, check out my latest post on RWD — RWD Revisited.

There have been blog posts, by many well-meaning people, on the tremendous benefits provided by responsive web design and how those who don’t do it are forking themselves. The idea is that you can use a magical technique called “responsive web design” that will prevent you from having to code around different form factors, and that it is the panacea for the web development of mobile solutions based on their big desktop ancestors.

There has been, from what I’ve seen, a few (here, here) well-thought-out criticisms of RWD. And really, those two are decent, but where they touch they touch gently, as if afraid to buck the latest du jour and inspire ire. And where they don’t touch, I think they miss.

One example would be Karen McGrane’s recent blog, which makes, in my opinion, too many assumptions in its argumentation, which in turn oversimplifies the direction she proposes that web application developers take.  She is not alone in her opinion, and I’m also not suggesting that she is completely wrong — but if you were to simply read the article and take the advice, it’s a mistake. And I grow weary of the lack of educated dissent with respect to RWD. We all need a good argument, the devil’s advocate.

Many of the proponents of responsive web design (not the library makers — they’re responding to demand) are talking about content sites. Online brochures. Menus for the local eatery. Newspapers. Blogs.

Okay. Now I get it. And it makes sense. And I would agree that using media queries and javascript to reformat your pages makes a lot of sense there. You get to leverage your CMS and the bulk of your layout code. And you probably only need to make some minor adjustments to your css.

Anything beyond those site-types, however, and you wind up doing exactly what Karen says you’d do if you didn’t use responsive web design, only it’s more insidious — you won’t be creating forks of your code, you’ll be creating a wasp’s nest within your trunk.

For web applications that deliver capabilities beyond that of your typical content consumption site, there are (often vast) differences in the use cases for those applications. Here is where Karen errs (if she is making a sweeping argument for responsive design that covers all sorts of web-deployed solutions). I couldn’t possibly disagree more with her assertion that you need to focus on losslessly cramming your desktop content down into a mobile screen. Ah, actually, I can disagree more, because I even more strongly disagree with her assertion that “[we’re] going to guess wrong” when it comes to thinking about what content and features users of our desktop solutions will want on their mobile devices. Sorry, that’s snarky… But when you make your living developing screen-to-screen solutions for Fortune 500’s, and then you’re told that you won’t figure out what your users want, so give them everything you gave them on the desktop… Well, it rubs the wrong way. It teaches the wrong lesson.

Let’s talk about forking. The idea behind forking is you are essentially creating (at least) two versions of your web application — one for desktop, one for mobile. In theory, you could also have one for tablet, one for a particular brand of mobile phone, etc. Proponents of RWD says this is bad.

Let’s talk about responsive techniques. Let’s talk about media queries — the “if/then” of the css world (apologies to LESS etc.). If you build a single app and aren’t going to fork as per the implicit prescription of RWD, your css can possibly double in size. No joke. CSS defines the layout of your content, the positioning, visibility, appearance and animated properties of all of your on-screen elements. For richly interactive applications that are to be deployed to multiple form factors, a single, all-fitting css file is going to be a rabbit warren of media queries inspecting the browser dimensions and laying objects out accordingly. Have you ever seen a css for a complex web application that is attempting to leverage responsive web design? Maybe the apps I’ve seen were coded by shoddy developers — their sites look awesome, but that doesn’t mean they’re good developers — but as a developer, this is exactly the situation you will run into when you want to leverage css for responsive web design for complex web applications.

Some might then argue that you would have different css files and load them up at run-time. Hey, no cheating! What’s the difference between forking and having one css file for desktop delivery and one for mobile? I call foul. You wind up maintaining both anyway.

Now let’s talk about JavaScript. RIA’s do a lot more than present content — they present content and application functionality in interactive ways. On a desktop, that means a click on a navigation menu. On a tablet, that might mean a swipe from the left side of the screen to slide into view a navigation bar that will gracefully glide away once an option is selected. On a mobile device, it’s a menu button that slides down your menu options, which will slide up and dissolve in your selected option.

So, some of that is handled in css (there you go again with the spaghetti media queries). Some of that is handled in JavaScript. A lot, in fact. So, in your JavaScript, you are, again, inspecting browser dimensions and forking branching to the appropriate handlers (or specifying appropriate functions in your callback routines). You are, in JQuery if you’re lazy like me or straight-DOM if you’re a masochist, adding or not adding interface elements, setting format-specific event handlers.

Now, I’m not suggesting that you maintain separate JavaScript files for every screen you are targeting. Not hardly. But the proponents of RWD who exclaim “Oh! Use responsive web design and your problems are solved!” are naive. It suggests that, if you do your css just right, all your problems go away. This is disingenuous.

Let’s talk images. Sure, there are JQuery plug-ins for thumbnailing, ways in css to resize background images (but only background images — not images embedded with, you know, the IMG tag). But they’re still operating on images geared towards a desktop use — namely, they’re big. With big, bandwidth-eating byte counts. You will want to have smaller versions of the images. Same with video. No amount of RWD on the client side is going to shrink those images down for you until they’re already downloaded to the client.

You may even want different images or video based on the form factor. Karen’s argument here appears to be that you’re making a big mistake — that you should simply mobilify everything on your site via responsive design, don’t cut content, and so on. Again, that’s fine for the relatively simplistic world of content-focused sites. Applications aren’t going to work this way.

Which brings me to Karen’s next point. That we shouldn’t provide different functionality based on the form factor. This (and this is my opinion — flame away) is wrong on so many levels that would be evident to any company looking to deliver a compelling and meaningful experience on a phone — or even a tablet, which has roughly similar dimensions to a desktop, but significantly different user interactions.

Use cases are not meaningless. I can give Karen the benefit of the doubt — perhaps she really is just talking about content sites (though she did seem to indicate otherwise). Again, I agree that the use case for someone reading a newspaper is going to be the same on the desktop, tablet and phone — the use case is, “I want to read this article.”, and the subcases are “I want to read this article while sitting at my desk when I should be working”, “I want to read this article while I’m sitting on my couch drinking a cup of coffee when I should be playing with the kids”, and “I want to read this article while I should be paying attention to the road while I’m driving”.

But for web applications, the use cases can be completely, dramatically different. Take business software, for example — salesforce automation, analytics software, take your pick — there is no way the use case is the same across screens for these types of applications. And if you simply shrink down your desktop SFA solution onto your mobile device, you are doing your mobile users such a disservice that they are unlikely to use your software, you will lose your sale, you will re-enact Platoon scenes with Charlie Sheen, etc. etc. Don’t re-enact Platoon scenes with Charlie Sheen.

Screen specialization is important for your product. I don’t want to take the time to describe why, it just seems so self-evident to me. I could do it though, if I had to. I could point you to the mobile versions of LinkedIn (nope — not just “responsive web design”). Concur. RoamBI. Microstrategy. YouTube. Netflix. Zillow. Amazon. eBay. WordPress! Nope — not just “responsive web design”.

So, in summary — there’s a place for responsive web design. And it’s a big, big place — I’d say a vast majority of web sites are more content than application. But it isn’t the solution for everyone, and sometimes, you gotta fork.

One final word, though — I agree with Karen on content. Content should be display-agnostic, for the most part. Intelligent organization and inspection of media meta information should solve many of the issues related to retrieving appropriate assets for display. This is similar to back-end support for your front-end in rich internet applications: design your web services appropriately, for example, and you can leverage them in any of your front-ends. Now THAT’S responsive design.

RWD is not just CSS. It is an end-to-end development methodology that is too often oversimplified and positioned as the right, the only, approach for mobile solution development.