Cloud Four Blog

Technical notes, War stories and anecdotes

Responsive Web Design is Solid Gold

A few years ago I wrote an article entitled CSS Media Query for Mobile is Fool’s Gold. It garnered a lot of attention at the time, and I still see people reference it.

I’ve long wanted to write an update to that article, but never knew quite what to say until now. And because one inflammatory title deserves another, read on for why Responsive Web Design is Solid Gold.

Our default approach is now responsive web design

Back in 2010 when I wrote the Fool’s Gold article, our default approach for mobile was to use device detection. If a site was simple and the budget small, we might use responsive web design.

Some time ago our default approach switched. We now treat responsive web design as the default approach and look out for reasons why it won’t work instead of the other way around.

Why did our default approach change? Two reasons: performance and device diversity.

Update on performance

Much of my Fool’s Gold article focuses on performance problems with flexible images and CSS background images. One of the reasons why I’ve had trouble figuring out how to write a follow up is because the performance issues that I raised remain true today.

Let’s do a quick round up of the issues and updates on each:

Perhaps most importantly, most responsive web sites are still far too large on small screens.

So if most of these remain true and most responsive designs are bloated, why has my perspective changed?

Because it is possible to build responsive design responsibly and create fast experiences. The keys to doing so are:

  1. Build mobile first responsive designs
  2. Keep CSS background images in scoped media queries
  3. Conditionally load JavaScript and even HTML fragments based on screen size and capabilities
  4. Implement a responsive images solution
  5. Handle retina images very carefully and err on the side of performance

If you do these things and do the normal things you should do to make any web page fast, you will have a fast responsive design. It may not be easy, but it is possible.

But what about the fact that most responsive designs are bloated? As Tim Kadlec says, “blame the implementation, not the technique“.

I don’t blame device detection for the many sites that route people to the mobile home page instead of the article they’re looking for. And I don’t blame responsive web design for the fact that most implementations are bloated.

Can a responsive design ever be as fast as a page tailored for a specific device?

Probably not. But the web is a balancing act between many competing interests. A site that was completely tailored for search engine optimization would be unreadable by humans.

By the same token, performance is an extremely important factor, but is still just one of many factors that make a site successful. You can build responsive designs that are fast enough that the benefits of responsive design outweigh the potential performance improvements you might get from separate sites.

Especially when you consider device diversity.

Device diversity makes responsive design inevitable

Let’s assume for a moment that responsive design doesn’t work for your project. So you decide that you’re going to need to build mobile, tablet and desktop experiences. And let’s set aside for the moment the inevitability of new form factors like televisions, watches, etc.

Even in this scenario with different experiences for each of the three major form factors, you’re still going to end up needing responsive design—or at least responsive characteristics.

Yesterday, Samsung announced that it was launching a 6.3 inch phone. The range of screen sizes on mobile phones alone will likely force you to build something that will adjust from the small screen sizes of Blackberry Bolds and feature phones to the mammoth screens of some Samsung devices.

Tablets present a similar challenge ranging from 7 to 13 inch displays (and sometimes much bigger). And we’re all familiar with the large difference between ultrabook screens and cinema displays.

I wrote in much more detail about the impact of device diversity earlier this year and my conclusion that:

Any attempt to draw a line around a particular device class has as much permanence as a literal line in the sand. Pause for a moment and the line blurs. Look away and it will be gone.

So regardless of what techniques you use in addition to it, responsive web design will likely be part of your solution.

What about mobile context?

One of the other points I made in the Fool’s Gold article was related to mobile context. It is something I’ve struggled with for years.

I’m now firmly on the side that there is no mobile context. We have abundant data that shows that people use their mobile devices indoors and for a wide variety of things.

Luke captured it well when he wrote:

But if there’s one thing I’ve learned in observing people on their mobile devices, it’s that they’ll do anything on mobile if they have the need. Write long emails? Check. Manage complex sets of information? Check. And the list goes on. If people want to do it, they’ll do it on mobile -especially when it’s their only or most convenient option.

Amen.

So Jeremy Keith and Stephen Hay were right. There is no mobile web. Mea culpa.

Still No Silver Bullets

I concluded my Fool’s Gold article by stating the obvious: there are no silver bullets when it comes to adapting our existing apps and sites for mobile screens. At that point in time, people were touting media queries as a quick fix for mobile.

Since then, our profession has learned a lot more about the complexity of designing and building experiences for multiple devices. Now it is generally understood that supporting all the devices that may access our content and services isn’t easy, but that tackling problems that range from responsive images to legacy content management systems are the heavy-lifting that we must do in order to be future friendly.

And despite those challenges, I’m excited about where the web is heading and what we can do with progressive enhancement and responsive web design.

Responsive web design: it’s solid gold, baby. :-)

45 Comments on “Responsive Web Design is Solid Gold”

  1. I have had much the same to say about this, and come to totally the other conclusion. You /can/ do RWD (plus feature detection, plus a few other things) and do a really good solution without device detection. but NO ONE does. Statistically troublesomely so. Page sizes are HUGE due to all the things no one does right. Just like I can’t suggest hybrid apps anymore due to bad implementations, I am very leery of pure RWD.

    I also think I saw you drawing hard lines between device detection and RWD. What’s wrong with a common datastore, common functions, producing a small set of markup classes and then within those things are responsive? Seems the only smart way to go to me.

    And the dismissing of context thing bugs me still. Working with someone else on another article about this, but in deadly-simple summary:
    - Desktop is /almost always/ focused and sitting there staring at a screen.
    - Mobile is subject to interruption and distraction even in your home/office. You can’t talk about “second screen” for entertainment without admitting this.
    - A lot of the mobile context is the totally, totally different way the devices work. Not just touch vs. mouse (at all, with touch desktops) but how the many other sensors work to have presence data that can turn to info and intent data, or how seamlessly apps work together, to make an email form on a mobile site almost always fairly dumb.

    • Jason Grigsby says:

      Steven wrote:

      I also think I saw you drawing hard lines between device detection and RWD. What’s wrong with a common datastore, common functions, producing a small set of markup classes and then within those things are responsive?

      I was actively trying to avoid a hardline. Sounds like my writing failed me again. :-)

      That was the point I was trying to make about the fact that responsive design has a place regardless of what else you use in your implementation. You may bring other tools to bear as well, but RWD is going to be there in some capacity.

      I linked to Stephanie Rieger’s article that responsiveness is a characteristic. I still wholeheartedly agree with that.

      Desktop is /almost always/ focused and sitting there staring at a screen.

      Until it’s not. Or until the person disconnects their keyboard and it becomes a tablet. Or until someone interrupts them. Or until they’re on a beach reading email.

      A lot of the mobile context is the totally, totally different way the devices work. Not just touch vs. mouse (at all, with touch desktops) but how the many other sensors work to have presence data that can turn to info and intent data, or how seamlessly apps work together, to make an email form on a mobile site almost always fairly dumb.

      I wholeheartedly agree that you should try to take advantage of those capabilities, but if those capabilities are available on a 7″ tablet, are you not going to use them because that’s not a mobile phone? If that 7″ tablet is then hooked up to a keyboard in a manner that makes it look like an ultrabook, are you going to turn off those capabilities?

      • Three cheers for mixed approaches! Too many divide up into segregated approaches by default. Search for other blog posts and you’ll find too many that are separate-site vs. RWD. And half of those have flow charts to help you pick one and only one approach. Bleh.

        I’m probably not typing as well either: As far as context, I see a lot of folks take that “there is no mobile sort of use” thought and just stay in their happy space, fully embrace RWD as being a scale thing only. They’ve all used this to give up on believing in Mobile First (which they misinterpreted as Mobile Only) and now make desktop-only and scale to fit. Spent part of the day explaining why hovering megamenus don’t work, because of what you said: touchy computers and tablets can use desktop and become mobilized devices.

        We should talk about this more sometime.

  2. James Pearce says:

    Of course people use their mobile phones on the sofa. But if we are falling back to say there is therefore a homogeneity of need across every user, every device, every location, every moment, every context (or at least that web practitioners needn’t worry because of CSS support), then we’re being lazy. Or unambitious. Or something.

    We should care less about the architectural technique used to bring heterogeneity of service – one that is, ahem, ‘responsive’ to need – but we shouldn’t pretend that toggling menu location, resizing images, and such like will build us a competitive future web that serves the combinatorial challenges of 7 billion different human conditions.

    (Also: not quite first!)

    • Jason Grigsby says:

      Welcome back James! I’ve missed you my friend. I’m tempted to edit comment timestamps so you can have your honorary first post status back. :-)

      But if we are falling back to say there is therefore a homogeneity of need across every user, every device, every location, every moment, every context (or at least that web practitioners needn’t worry because of CSS support), then we’re being lazy.

      I would propose a different way of describing this:

      * People are likely to want to be able to do anything they can do on desktop on their other devices as well. And because for many people, these are the only way they can access the Internet, we have an obligation to make sure that they can do so.
      * People are also going to want to be able to utilize the full capabilities of their device. So if my device can confer interesting information about my location and some of the other things that Steven described, then it would be great if the services I consume would utilize that to provide a better experience.
      * People should also be able to select modes or applications that provide better experiences for the tasks they want to accomplish. For example, Vimeo has couch mode for watching television. View their site on a Google TV and you’re automatically in couch mode, but you can get out of it. View their site on desktop and you’re not in couch mode, but you can get into it. A similar example might be the information density settings in Gmail.

      That last bullet point is the idea that I’m still noodling on, but I think it has a lot of merit.

      By thinking about modes or views into services, we’re designing for user need not for a specific form factor or input especially since we know the lines between form factors are blurring and input is transient (not to mention undetectable from a web perspective).

      Put another way, I think there are enhancements we can make to services that would make them much smarter when the device has additional capabilities. I just no longer think about those capabilities as being specific to any form factor.

  3. Chris says:

    Hmmmm interesting read, we mix RWD and server side detection. So the site is responsive down to mobile and the detection chooses which images to serve up best suited to there device…also works for changing things up and loading in less scripts for mobile etc…seems to work pretty good. Been doing this for over a year now

    • Jason Grigsby says:

      Something I hope to write about soon is the distinction between Responsive Web Design as Ethan defined it and responsiveness as a larger concept. In an earlier comment, I mentioned Stephanie Rieger’s writings on responsiveness as a characteristic as being close to the way I think about it.

      Here’s the thing, even the Boston Globe site isn’t pure responsive design as it is defined. Responsive design has three pieces:

      1. Fluid grid
      2. Flexible images
      3. Media queries

      But the Boston Globe uses JavaScript to move things around on the page and to retrieve additional content. It checks the user agent string to make sure that Blackberry 5.x devices get the simplified layout because even though they pass feature detection tests, they are too slow to get the JavaScript enhanced version of the site.

      If someone built a site that was responsive for everything but images and for images relied on an image resizing service that used device detection, would that no longer be a responsive design?

      I feel like a lot of these discussions break down because people are intent on having black and white perspectives on these tools. If you’re building something and it makes sense to use responsive design and device detection, so be it.

  4. My god this guy talks sense.

    Nailed it again, Grigs.

  5. Simon Buerger says:

    I don’t think the danger is in assuming whether or not there is a ‘mobile context’. Sometimes there is, sometimes there isn’t. The danger lies in what you do with that information.

    So your analytics tells you that 90% of your mobile users are just looking for your phone number or nearest branch. Prioritising that information on smaller screens then just makes a lot of sense.

    However if your analytics tells you that 90% of your mobile users don’t use your article filters (or whatever feature) – you really can’t just say “Oh well, they don’t need that then” and hide it from them.

    For me the argument is all about what we do with any potential contextual information we have at our disposal, not over whether or not different contexts exist. Obviously contexts exist, but they’re seldom as simple as a ‘mobile’, ‘tablet’ and ‘desktop’. Contexts are far more about what the user is doing and not what device they’re on.

    Unfortunately the only information we have is about their device – so working with that we can make informed decisions about data/feature/menu prioritisation and page hierarchy. But we shouldn’t rob users of choice by hiding/removing things, because as has been repeated to the nth degree – mobile users can and will do everything desktop users do, if the need arises.

    Well that’s my take anyway.

    @Jason, can I just say that this is a superb piece. Thanks for the read :)

  6. Greg Hickman says:

    Hey Jason,

    Great post. Been a long time reader. Question…What are your thoughts on this when it comes to small businesses like local restaurants, salons etc where the search data shows that they are really only looking for hours, address, phone and possibly a menu?

    When it comes to cost and site speed, considering the searchers intent…does a “separate” (non-responsive) solution become a better fit?

    Obviously the challenge of constantly evolving screen sizes and resolutions is still in play here but curious on your opinion for the small business owner, on a budget that is looking primarily at converting on those key actions…

    Cheers!

    P.S. I’d love to get you on an episode of my podcast. You can check it out at MobileMixed.com.

    • Jason Grigsby says:

      What are your thoughts on this when it comes to small businesses like local restaurants, salons etc where the search data shows that they are really only looking for hours, address, phone and possibly a menu?

      I can’t tell from this question if you’re saying this is what they are seeing on mobile only or for all devices. I would assume that these things are what people want regardless of the device.

      When it comes to cost and site speed, considering the searchers intent…does a “separate” (non-responsive) solution become a better fit?

      For small sites, responsive design is almost always the better fit. I mean what’s simpler: media queries or installing and/or making API calls to a device detection database?

      Send me a note jason at cloudfour dot com about the podcast.

  7. Ethan says:

    Steven, those are some stellar points. I might disagree with your contextual assertions—the line between “desktop” and “mobile” and everything in between has been blurring for a few years now, and continues to do so—but of course, the needs of your audience could very well be different from the ones I’m designing for.

    That said, I did want to talk to a couple of your points:

    On performance. The question of performance is an interesting one. I think it’s interesting (or, y’know, slightly terrifying!) to note that if we put responsive design aside for a second, our work on the web in general is far, far too heavy. There are definitely some heavy responsive sites out there, true—but it’s a problem that affects non-responsive sites as well. Heck, the average page weight is hovering around 1.5MB—I mean, Facebook’s newly launched internet.org is around 4.3MB over here. But as Jason says, it’s not worth criticizing a technique over a specific implementation. What’s more, I completely agree that we should all be working to lighten the web up a bit: thankfully, there are a number of tools I’ve found that make it significantly easier to make nimble, lightweight responsive sites. And I think many others are working to the same goal.

    On optimizing for inputs and sensors. As for the different input modes you mention, I think of it as a line of negotiation between a.) designing for broad access and b.) smart optimization. I’ve worked on responsive sites that look for opportunities to enhance parts of the experience for specific input modes—I could see the extending to other sensors as well, especially once browser APIs mature a bit more. But that baseline level of access is, I think, key. It’s the web, after all. :D

    James, I quite honestly don’t know what any of that means.

    • James Pearce says:

      :-) I’m not really talking about web design.

      I think I always hoped the web would be something more than it was or is. Maybe I’m not very good at capturing what it could be. Maybe people think I’m ranting about CSS. Maybe just it never will be that thing.

  8. John Locke says:

    I still see the RWD is Fools Gold referenced in source codes here and there. Fast-forward a few years, and the design process and support for the techniques have matured greatly. Equal access for all is the basic component of the Web platform. It’s good to see that it has gotten easier for everyone to embrace mobile first, as that truly has become the default setting for most sites.

    • Jason Grigsby says:

      Yes. I’ve seen that too. It was referenced in HTML5 Boilerplate which means it has made it’s way into a lot of projects.

      FWIW, I never wrote RWD is Fool’s Gold. I was very precise in my language. But everyone read it that way regardless.

  9. Joe Bartlett says:

    Notable that browser support for cascading background-image overrides has improved dramatically since 2010. Your recommendation to use scoped media queries instead agrees with Tim’s finding that Androids 2 & 3 (including Kindle Fire) still download both variations, but as Tim points out at the end of his results, cascading for pixel ratio can be considered safe since there are no “retina” devices running using old enough versions of Android to be affected. Newer versions of Android and iOS support cascading background-image overrides just fine.

    Very useful update. Thanks!

    • Andres Gallo says:

      We launched a redesign of various sections of our website a few months ago using responsive design. Using device agnostic, along feature detection we are able to remove a lot of bloat where not needed. The overall structure just gets rid of a lot of the issues with responsive. http://marvel.com/

      With that said, some of the issues of responsive design are still there, but overall responsive design is indeed AWESOME.

  10. I agree wholeheartedly that responsive web design is solid gold, I love creating responsive web sites, but web designers and developers need to iron out the responsive mistakes that are tarnishing it.

    Responsive sites that load fast, consider the user at every viewport size and are a joy to use are still like gold dust.

  11. Ethan says:

    Hey Jason! Just saw this bit:

    Here’s the thing, even the Boston Globe site isn’t pure responsive design as it is defined. Responsive design has three pieces:

    1. Fluid grid
    2. Flexible images
    3. Media queries

    But the Boston Globe uses JavaScript to move things around on the page and to retrieve additional content….

    Hmm. Not sure I’d agree the Globe isn’t responsive as such. As you said, a responsive design has a fluid/flexible grid, flexible images/media, and media queries—but it isn’t limited to those three things. I mean, the presence of JavaScript for some (non-critical) content repositioning doesn’t make the grid or images any less flexible.

    (I might be misunderstanding your point. I haven’t had enough coffee yet.)

    If someone built a site that was responsive for everything but images and for images relied on an image resizing service that used device detection, would that no longer be a responsive design?

    Oh, yes—it would definitely be responsive. As long as the images, you know, work within the constraints of a flexible layout. I think the how of getting them to the client is irrelevant—whether you use something like picturefill or a UA-driven service.

    • Jason Grigsby says:

      Ethan,

      I’m pretty sure we’re saying the same thing. Perhaps if I had said that the Boston Globe isn’t “strictly” or “only” responsive design instead of “pure”, my point would have been clearer.

      Like I mentioned to you at AEA DC, I’m having trouble with the language around responsive web design because responsive web design seems larger than just those three techniques and yet it is clear that the definition is just those three things.

      So no surprise my comment would confuse you. I’m still trying to figure out how to describe what I’m thinking here.

      -Jason

  12. Ethan says:

    Gotcha, Jason—thanks for clarifying!

    Like I mentioned to you at AEA DC, I’m having trouble with the language around responsive web design because responsive web design seems larger than just those three techniques and yet it is clear that the definition is just those three things.

    Well, the way I think about it (and I may have said some of this in DC): Responsive design is the flexible/fluid grid, images/media that work in that flexible context, and media queries. That’s it, and yeah—that’s pretty broad. But a responsive design can potentially include more than those three things.

    I think the shorter definition gives us more room to negotiate. It lets more people experiment with responsive design, without being too prescriptive. From there, they can find their way into other best practices (like progressive enhancement).

    • Jason Grigsby says:

      @Ethan, I was going to send you this in email, but I love the fact that the comment threads on our site are informative and I’ve seen quite a few people tweet about enjoying the comments on this post, so I thought I would experiment with responding here. If it becomes unwieldy, let me know.

      Right after I saw you in DC, I did some consulting for a company. They were working on a extremely complex responsive application and were trying to retain all the same content regardless of screen size. I asked why not use something like the AJAX include design pattern, and they told me that they had been told that doing something like that was adaptive design instead of responsive design. I was stunned.

      Anyways, in the course of the conversation, I mentioned my difficulty with the labels we’re using for responsive design right now. One of the developers said something like:

      Yes, what you want to describe are a set of behaviors that make something responsive, but responsive web design is defined by technical terms. The problem is that the technical pieces will change, but the behavior will stay the same.

      I’m paraphrasing of course, but you get the idea. You should have seen me scramble to get my notepad to write what he had said down.

      I think this captures where I run into challenges. I often want to discuss responsiveness as a behavior because a lot of the challenges we’re working with clients on these days have little to do with the three technical underpinnings of responsive design, as those are pretty solid, but deal with making sure all the other things you need to do to make something truly responsive.

      I feel like there are broader behavioral characteristics of “responsiveness” that we’re aiming for and if we could find the language to describe them, that it would help add clarity to many of the conversations I’m having these days.

  13. Luca Passani says:

    Hi Jason, good article. Would you agree if I summarized this as “thanks to advancements in javascript, hardware and CSS, doing feature detection on the client makes more sense today than it did in the past” ?

    • Hi Luca,

      I think that it is partly the advances that you mention. I think it also an advance in the techniques that web developers are using to address the performance challenges.

      And finally, I think the blurring of lines between and within device classes was the thing that finally pushed me over the top. I found that I no longer care that much if it is a mobile phone or not. I only care what the device is capable of.

      -Jason

      • Andres Gallo says:

        After trying different approaches I agree that this is probably the best method of handling responsive/adaptive (what is the difference really right?). With applications being about content after all, the best method of delivery for this content wether visually or through interactions, is dictated by capabilities, screen size, window sizes after all.

      • Luca Passani says:

        > “there is no mobile web. Mea Culpa”

        I am perplexed by the fact that many (you included) are trying to turn this into a binary property of the web. Yesterday there was a mobile web. Today, no, no mobile web. Everybody please backtrack.
        Yet, in this very article you write: “…the web is a balancing act between many competing interests. A site that was completely tailored for search engine optimization would be unreadable by humans…”, which I agree with and which reveals good practical sense.
        Now, why can’t we apply the same logic to the web? for some having a UX tailored for tablet, mobile, smartTVs and google glass makes sense. For others, it would make no sense because too expensive in the context of their business models, particularly now that RWD/PE are solid alternatives.
        For years, web programmers/designers have stayed mostly away from mobile because the platform was mostly unstable and the server-side component made it unappealing to them. iPhone, Android and WebKit changed that and client-side adaptation has become possible. I think this is part of the natural evolution of technology, but what I don’t get is the need to derive dogmas about what is right and what is wrong that should be generally valid. To me, it is as simple as: investing more time and resources to tweak the UX for different kinds of HTTP clients makes sense for some and not for others. Who needs what can only be assessed case by case.

        Seriously, Jason, if, say, Netflix came to you, and asked you to help them create 28 separate UXes to better serve their customers on all devices, would you tell them: “No guys, you got it all wrong! there is only one web!”

        • Luca,

          My point was primarily about mobile context and the idea that people want to do something different on their phones because of the context is often a false assumption.

          Combine that with fact that the difference between device classes are blurring makes it less interesting that something is a mobile phone as opposed to what is the device capable of, what its screen size is, etc.

          If Netflix came to us and had the resources to build a bunch of different experiences (which I know they already do), then whether or not something fit into broad categories of mobile, tablet, or desktop is far less likely to derive the experience that they want to build than the capabilities of that device.

          We happen to know that a couple of years ago Netflix used the following to define different experiences:

          * User posture: Stationary, Lean back, on-the-go, shared
          * Input capabilities: pointer/keyboard, LRUD/OSK, Gesture/OSK
          * Navigation style: controls & windows, panes
          * Display capabilities: Hi-Res, near, far away, small, medium, large

          What you don’t see on that list is mobile phone or context. Using things like posture puts the decision into more tangible, if harder to detect, factors. And the on-the-go portion that their designing for I would question, but if they have the data, which they may, awesome. I love to build solutions based on real data.

          For devices outside the continuum of mobile to tablet to desktop, I think there is still good question about how to deliver to those devices. Right now, delivering something designed for TV cannot be done solely with responsive web design. But because of the variations in screen resolutions and issues like overscan, you’d likely end up using responsive design in your implementation of the separate experience for TVs.

          Overall, I think you’re arguing against points that I didn’t make. To me, it feels like you’re the one making my argument binary when that isn’t what I wrote. I didn’t prescribe a single dogma. I don’t have that power and it would be crazy of me to do so even if I could because my thoughts evolve over time and we pick our approach based on the needs of a project and client.

          I wrote about how our default approach is responsive web design. That’s true. We’re not afraid to augment it with other tools and techniques as needed to solve a client problem, but we’re going to start from there.

          -Jason

          • Luca Passani says:

            Jason, you wrote that “there is no mobile web” and that’s a quote from your article. To me this sounds dogmatic. Point taken that Netflix has a very elaborate strategy to segment their offering. For many large companies, desktop vs mobile vs tablets is a reasonable (and obvious) starting point to segment their offering.
            Now, I understand that you think responsive is a great starting point. I don’t disagree with that. I argue that RWD is a great starting point to address (surprise) the mobile context. Again, RWD does not get us rid of the mobile web. RWD is a way to build a mobile web experience.

          • @Luca A few questions for you if you don’t mind:

            * How do you define mobile context?
            * Does mobile context apply to the Samsung Galaxy Mega with a 6.3 inch display?
            * Does mobile context apply to the Nexus 7 LTE with 7 inch display?
            * Does mobile context apply to the ASUS Asus VivoTab RT LTE with 10 inch display and detachable keyboard?
            * If they are different, why? What makes mobile context apply in one spot versus another?

          • Luca Passani says:

            I define mobile context like pretty much everyone else has defined it over the past 12 years (small screen, limited input capabilities, low bandwidth, high latency, etc.). Anyway, I can see what you are getting at, but let me use an analogy. Would you say that dividing the animal world among mammals, reptiles and so on does no longer make sense because someone discovered a platypus in Australia? it is obvious that there are hybrid animals, but the general theory is still damn useful as a reference to make sense of the world we live in. By the same standard, how can you say that there is no mobile context?
            In fact, I am arguing that even RWD and PE are ways to address the mobile context. If the mobile context did not exist, we would happily be creating websites like mobile devices did not exist without the need for media queries and flexible grids. But, the reality is: the mobile context exists and users love it when they have an App/WebApp tailored to the feature of their device.

            I often hear the main people behind RWD state that RWD is not about mobile, but the reality is that companies are choosing RWD almost exclusively because it is an inexpensive way to serve the mobile context. Throw in a few Modernizr tests and lazy javascript loading and there you go: you are doing on the client what WURFL and WALL developers have been doing for years with a little help from the server.

          • Luca,

            Most of the time when I hear people talk about mobile context and designing for it, they argue that the person using the mobile phone is in a different setting (context) and thus the experience needs to be designed differently.

            Most of the arguments for mobile context go something like this:

            * Someone using a mobile phone is on the go, distracted, and doesn’t have time.
            * Therefore, you should provide a different experience for them which is more than simply reformatting content to fit their screen. It means re-prioritizing content. It means leaving out things that people on their mobile phones are unlikely to do.

            And this idea of mobile context, particularly the idea that people on mobile phones won’t want to do stuff that they do on other devices, is the reason why people bristle at the idea of mobile context. We have plenty of data to suggest that someone using a phone often isn’t on the go and we know they likely will want to do things we don’t think of as being something anyone would want to do on their phones.

            I think this article by SuAnne Hall on the Three Reasons We’ve Outgrown Mobile Context does a good job of summarizing both my understanding of what people are commonly referring to when they say mobile context and why it isn’t useful.

            What you wrote is different:

            In fact, I am arguing that even RWD and PE are ways to address the mobile context. If the mobile context did not exist, we would happily be creating websites like mobile devices did not exist without the need for media queries and flexible grids. But, the reality is: the mobile context exists and users love it when they have an App/WebApp tailored to the feature of their device.

            Having something tailored to the features of their device is not mobile context. Having something tailored to the person’s on-the-go, distracted while using their phone context would be mobile context.

            So if by mobile context you simply mean building an experience that is designed for the size of the screen and takes advantage of the capabilities of the device, then I don’t think we’d have any quarrel other than the fact I don’t think others use mobile context to mean the same thing and I wonder why mobile context is anything special when the same could be true for any device regardless of the classification.

          • Luca Passani says:

            OK, if you are restricting the mobile context to people being on the go, then the arrival of WiFi on smartphones around 2007 has obviously been a game changer, in that users are no longer so mobile and the network is no longer so limited (to be clear, it is not that they are no longer mobile, but rather that millions more users have started to use their phones on their couches and beds). This has made the mobile context less “brutal” for mobile developers than it was before.
            Yet, “no longer on the go” cannot be the only definition of mobile context or, for example, people would be accessing fully-fledged Facebook with their mobile browsers, while this is not the case: Millions of users are using the App and the mobile version of the FB website on their phone.
            I am sure there are people who write long emails on their phones. Most won’t. Some will look at complex data on their phones. Most won’t. We cannot let corner cases dictate the design of a mobile UI. Secondary tasks should be supported in ways that the main UI is not cluttered.
            To me, the bottom line is that there is value in tailoring the application to mobile devices and their features. A mobile app/site will always perform better than a RWD site on mobile devices, albeit the combinations of different factors (cost of development, maintenance, built-in mobile support) will easily make RWD the preferred choice for most companies in most scenarios.
            Do we agree on this?

          • I am sure there are people who write long emails on their phones. Most won’t. Some will look at complex data on their phones. Most won’t. We cannot let corner cases dictate the design of a mobile UI.

            For a significant portion of the world’s population, the only way they can look at complex data on the web or write long emails is by doing so on their phones. In the United States, 31 percent of mobile Internet users say their mobile phone is the primary way they access the Internet.

            This is what Pew Internet Research has started referring to as the new digital divide. People are unable to fill out job applications on their phones because who would ever want to do such thing?

            Those edge cases you dismiss lead to UI decisions that unnecessarily disenfranchise people.

            Secondary tasks should be supported in ways that the main UI is not cluttered.

            This should be true for all screen sizes. This isn’t mobile specific. This is just bad design.

            A mobile app/site will always perform better than a RWD site on mobile devices, albeit the combinations of different factors (cost of development, maintenance, built-in mobile support) will easily make RWD the preferred choice for most companies in most scenarios.

            If we’re talking performance as in speed, then yes, I wrote nearly the same thing above.

  14. Andres Gallo says:

    Really enjoyed the article by the way

  15. Great discussion going on here guys, im not throwing in my 2 cent’s because some of them air aired in others comments, but great reading.

  16. Edward Chung says:

    Great article. I have adopted responsive web design in my web projects and it is no turning back. With the proliferation of mobile devices with many different screen widths, RWD is indeed the only future.

  17. Bill says:

    I like to build a mini-site for mobile and redirect smartphone on that, all try the “easy’ universal approach w/o results.

  18. Eric Kuhn says:

    Great article and interesting discussion going on in the comments. Just to add a few things:
    1. The site recommends using RWD
    2. Using one domain for your SEO, instead of thinning out your page rank with a m-dot site.
    3. When people are device jumping it makes for an easier transition, and will reduce people turning away from your site.
    4. Keeping a separate mobile site can be a redirect disaster.

  19. Impressively nice article on web design. I have adopted responsive web design in my web projects and it is no turning back. With the proliferation of mobile devices with many different screen widths, RWD is indeed the only future.

  20. This is something that any designer is going to have to do eventually. Mobile designs aren’t going anywhere and are becoming more popular. Even then non-desktop users in general is on the rise. Better to get started now!

  21. Martin Hall says:

    Great article. In response to Bill, it’s pretty clear from my everyday work that a stand-alone mobile site is yesterday’s solution. I doubt if I’ll ever sell another dedicated mobile site. RWD is mainstream now.

  22. “… most responsive designs are bloated…” — True. And sometimes confusing and annoying for mainly desktop users.

  23. Buddyweb says:

    I m agree with you : responsive web design is solid gold, I love creating responsive web sites. Thank you for your post. I think responsive design is essential and becoming more popular.it’s a good thing for every designers and UX.

  24. approachnet says:

    I can agree that some responsive sites are a little bloated, but personally, I don’t mind. Nice article btw. I contemplated learning how to develop mobile apps for clients that want a mobile version of their sites, but RWD looks to deliver a suitable alternative to developing multiple versions of a site.

  25. Chris Love says:

    I have to say I agree with the position. When you wrote the fool’s gold article I was with you and I have also since changed. Your points are solid. We have a ways to go, but at this point there is a lot of positive inertia to solve the real issues we have today so we can refine for the next level sooner rather than later.