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.
(me)
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.
May 09, 2012 @ 18:20:55
So have you ever developed a responsive site or web application?
May 09, 2012 @ 19:11:44
Hi Josh –
I’ve done both… Or I should say, I successfully deployed a responsive application, and for another I had to burn it down and build separate applications. In both cases, we were able to leverage 100% of the back-end.
The successful one was a site that was fairly interactive in nature, but definitely geared towards content consumption. A very simple app for the marketing team at a pharmaceutical company. We were able to use media queries and some minor branching within the JavaScript code to achieve a single codebase for the software.
The failure was a much more complex tool that ran analytics on back-end datamarts (also for a pharma, but a different one). It also had collaboration functionality, salesforce features and made use of GPS. We went the route of responsive design, and it so badly bit us in the butt. We were developing a desktop/tablet/iPhone solution, and there was just too much we wanted to do specific to each platform, with different use cases, that it became unmanageable. We dropped back ten and punted — we were able to pull out a majority of the javascript code into a library that was used by all versions of the app, so we didn’t lose a ton there. We abstracted out our function calls (because there’s no real inheritance or overload capabilities in js) for screen-specific functionality. We did essentially the same thing for our css — pulled out all the stuff we could leverage across the different screens, and then dynamically loaded css at runtime when we determined what we needed based on the client device.
So, overall — we reduced as much as possible the duplication of code by abstracting and a proper distribution of cross-screen code. Ironically, the code of our failed effort helped us tremendously (since we didn’t set out to do this from the start) — all we had to do was look for the spaghetti in our code, and we knew we had to push something down into the screen-specific variants of our libraries.
May 09, 2012 @ 20:45:54
I read the same article from Karen and came to this site actually from a link you provided in her comments.
I respect you opinion based on what you have written, because you clearly know what you are talking about. Responsive design is not a magic bullet and is much more appropriate for what you would probably call “brochure” sites (although the definition of what that means is a bit vague considering the change in the use of website in the last 10 years). In building solutions, it is typically is ambiguous where the line for the need for an “application” begins and ends unless you clearly need access to phone-specific features that can only be accomplished through the iOS API, for instance.
With that said, it seems like you are being very hard on Karen. I did not read that she was suggesting that responsive design was always the correct approach. Karen appears to be suggesting that the mobile experience should re-use existing content rather than “fork” it and create a nightmare of administration. It is hard to argue that this approach is incorrect and any sane person would agree that in an “ideal” world we should re-use the content. Unfortunately, we don’t live in the ideal world and people don’t act sane. And yes, there are always exceptions to every rule and/or organizations with enough money and requirements not to worry about the administration nightmares.
I don’t make comments very often on blogs, but thought that calling her out in the manner that you did was inappropriate. Mentioning that she brought the topic up is one thing, but it almost seems like an attack. It’s your blog, though, so maybe this approach was just to drum up conflict and passion for the subject, which worked on me to get me to respond.
Now, I will happily tweet your blog post, because it has some fantastic information in it and I appreciate the depth of knowledge.
May 09, 2012 @ 21:43:44
Hi Chris —
Thanks for your feedback, and I’m glad you find it informative.
I’m certainly not trying to be inappropriate — and I even revised some of my text after reading your comments, because it is absolutely not my goal to be insulting in any way. Maybe not to the extent that you would want, though, because I am trying to raise the level of discourse.
Karen’s blog seemed to me to suggest that, because forking is the devil, RWD is universally applicable and should be universally applied. The suggestion that forking creates an administration nightmare is only true if you have bad development practices.
Forking can be a huge advantage if done right, if you create appropriately organized code, and have a decent source code repository. Is it more difficult than managing a single codebase? Sure. That’s a no-brainer. Do the benefits of well-managed forking outweigh the administrative challenges of well-managed forking? Yes. That, too, is a no-brainer. It is not a question of sanity versus insanity, it is a question of providing the best possible solution on each of your target screens, and simply claiming that RWD is the only reasonable, sane approach to this does a disservice to people seeking direction.
So, while I appear to be attacking Karen, it is only because I wanted to reference a recent blog that posits the same thing that so many other bloggers regurgitate. I am attacking the position, but I suppose that implicitly attacks the writer.
May 10, 2012 @ 13:00:42
Nowhere did I say responsive design is universally applicable or is the only acceptable solution. I explicitly said choosing responsive design or any other approach “is a pragmatic choice based on how you want to allocate time and resources for development and maintenance.”
I will direct your attention to my statement: “The hype and the debates around responsive design are missing the real problem.” You missed the whole point of my article.
May 10, 2012 @ 13:19:49
Karen — that didn’t seem to be the case, since your primary claim is that “whether you are talking about content or code” you want to “guard against…creating multiple versions” which is a “forking nightmare from a maintenance perspective” (which I strongly disagree with — see my response above regarding this). So, after you lay the groundwork for not forking code (which would suggest you are going to be a proponent for an alternative to forking), you then assert that if you “put the effort in to developing one set of code that will adapt to different screen sizes… you’ll save time in the long run.” So, you outline the problem (forking) and prescribe a solution (RWD). That’s what I take issue with.
So, no, I didn’t miss the whole point of your article. If you had constrained your article to talking about content forking, I would’ve agreed with you completely. But when you try to loop “website”, which many people define as encompassing not only brochure-type sites but also interactive web applications, into your overall argument, and suggest that forking application code is a bad idea, and that RWD is a real solution to forking application code… I don’t want that sort of advice to be propagated without the appropriate caveats.
May 10, 2012 @ 15:32:11
Which is why I said:
“The decision about whether to develop a responsively designed site or to maintain different templates for desktop, phone, and everything in-between is a pragmatic choice based on how you want to allocate time and resources for development and maintenance. There are good reasons for both approaches – often rooted in the specifics of how your CMS functions – and what works for one organisation may not work for another.”
and:
“The challenge for most organisations in the long run won’t be maintaining multiple sets of front-end code for different templates. It will be maintaining variations of duplicate content.”
The whole point of the article was that these sorts of debates about responsive design are a distraction from the real problem, which is that many content management systems do not effectively support multi-channel publishing, and thus organizations risk forking their content.
You seem to be reading my article very selectively so you can use it as a straw man in your argument against responsive web design, specifically for interactive web applications. You make good points, but you don’t need to use my article as a jumping off point, because I’m talking about content forking — and I’m not arguing that responsive design is universally applicable.
May 10, 2012 @ 17:45:17
Karen — Based on some of the comments on your blog, it would seem your article is open to misinterpretation. I appreciate the clarification, but it certainly wasn’t clear that you were only talking about content forking. It still seems as though you, er, forked your article a bit and perhaps went off your original track. I think to start an article by talking about code forking being a maintenance challenge sets the tone.
The idea of RWD as an end-to-end architectural methodology, as opposed to just a client consideration, is what I am a proponent of, for many reasons — not the least of which is that it is grounded in reality, doesn’t suggest that there are shortcuts to be had and that bootstrap.js is all we need to make the world a better place, and doesn’t start us down the path of nonspecialized solutions for non-desktop screens. It is all about mindset — that executive you were talking to, who thinks he understands RWD, probably really doesn’t. And he would read your article, and as likely as not interpret it as “forking is bad, two versions of my web site is bad”, and there — you’ve propagated, perhaps inadvertently, misleading advice. I’m using him as an example, of course — I don’t know what he is an executive of — but if it is for a company that has a web-deployed solution that is anything more than a content delivery vehicle, he’s selling his customers short if he thinks forking is bad and dictates that his techies architect his solution that way.
In any case — I am in agreement where you talk content management. Having adaptive mechanisms for content is critical to this methodology, just as adaptive mechanisms for web services, and appropriate abstraction of code and stylesheets to maximize reuse throughout your application.
May 10, 2012 @ 17:36:24
Josh –
I am very new to the RWD discussion, and have greatly appreciated this discourse. Thank you. RWD is still a new concept. Good discussion will help us all become better.
Too much of my career, sadly to say, has been focused on whose resources get the biggest hit with web design and development – IT or marketing. Sometimes that argument takes the form of who has the biggest hit NOW vs. LATER, because quick delivery is what it’s all about. Your blog helps me, a communications professional, understand the significant up-front hit to the developers with the extensive CSS and JavaScript work needed for RWD. So, for what it’s worth, I’ve learned something!
Something I’d like to add to the mix of this discussion is this – I’d love to see a web CMS deliver content for multiple devices and multiple (targeted) audiences. An organization always has multiple audiences. This is especially true for transaction-oriented sites. For example, if I’m on a site offering financial advice and services, I would expect to have different content served up if I’m nearing retirement than if I’m a college graduate just starting my investment life.
Our web CMSes are becoming more robust. But I don’t think they’re quite keeping up with the complex needs of organizations. At least from what I know of them.
I agree with you that we have to go back to the use cases first. Then the budget you have to work with. And your time-to-market. And your need for flexible content and functionality (on your multiple devices). Many factors go into the decision for the solution best for you.
Thanks for the discourse. Stuff to chew on.
May 11, 2012 @ 08:41:49
Gayle —
Yeah, I’ve been on the receiving end of hits to IT, I understand your pain. And I’m not so naive to say that you should cut marketing instead of IT, because, if you’ve got a good squad, marketing will give you great direction for your different screens.
You also bring up a great point regarding targeted audiences. That’s another layer of the onion. It sounds like you’re looking for a built-in CMS capability that takes into account the demographic of your user and serves up appropriate content. I won’t claim expertise in CMS — generally, my “content” comes from relational databases — but I will claim expertise in other types of business software where we have done exactly the same thing.
The concept in salesforce automation, for example, is called coverage. Ignoring demographics for a moment (as those are just additional attributes of a user’s profile — or their geographic location, if you are leveraging census-style data). In coverage, a user is assigned to (or covers) one or more nodes — a territory, for example, and a product line. When the user signs into the system, the hierarchical relationships of these nodes (up and down from the product, up and down from the territory) will dictate the type of content that they will see.
But the bulk of that is done, for lack of a real word, programmatically. The developer uses the coverage information (as well as the demographic information) in a way that an off-the-shelf CMS probably isn’t equipped to divine. And when those relationships get tougher, and when your marketing department determines that targeting more granular classifications of users is important — show this content when the user is from a zip code that is predominantly Hispanic with such-and-such an income level if they are signing in at a certain time of day — that’s where you’re probably extending the heck out of CMS with your tech crew.
May 16, 2012 @ 05:52:25
Nice article, Sir.
May 21, 2012 @ 04:39:28
Some good arguments here and ones I’m seeing more and more at the moment which go a long way to explaining a the distinct lack of large scale, fully responsive/single codebase sites out there.
I’ve been a big fan of the tools and methodologies available to us when using RWD and the scale of sites (including a large travel/ecommerce site) I typically work on have so far been ok to make use of RWD without too many drawbacks.
I’ve certainly been thinking a lot about separate versions on very high traffic sites because they may be more efficient in economic terms even maintaining two codebases (more on that here http://pastebin.com/uRSxqCga)
Enjoyed your post, some good food for thought.
J.
Apr 16, 2013 @ 23:15:03
I recently came across your blog. I don’t know what to say except that I have enjoyed reading. Very informative and nice blog.