Ethan, the guy who kicked off the craziness, defines responsive design in part by @media queries—I think they count as necessary but maybe not sufficient. Responsive design is all about how we build a site to respond to information. And I think we’re confused about what kind of information we have, how we get it, and the relationship between it all. So here’s a pretty picture to get us started.

This colorful table demonstrates two ways a site can respond, based on two types of information.

When layout responds, we adjust how the content is displayed, ordered, or styled.

When content responds, we adjust what’s being pulled from the server and displayed by the client (usually a browser).

Capability is information about what can be done, based on the device, the internet connection, the browser, etc.

User intent is information about what should be done to meet the users’ needs as best as we can.

We’re getting all these things mixed up.

Layout by capability

This is the genius of Ethan’s A List Apart article. We can use CSS to determine a few things about the width of the viewport, the orientation, etc. and build our sites to respond to that information by adjusting the layout accordingly. This is the heart of responsive design right now because this is the information we’re most accurately able to gather with the tools we have.

Of course, @media queries are ignored by Internet Explorer and many of the browsers found on mobile phones. To fix this, the smart folks at Filament Group have developed some JavaScript to endow many older browsers with the power to process @media queries. As a failsafe, Bryan Rieger suggests we build the default stylesheet for a small-screen layout and use @media queries to adjust the layout up from there.

Still, the 17 users with a decently large-screen device running a sufficiently old browser with JavaScript disabled may have to deal with a funky looking layout. Otherwise, this part of responsive design should work for everybody.

Content by capability

This seems to be a big reason why people fight against responsive design. Sure, we can push some pixels around the page, but what good does it do if we’re shrinking down 1300×900 pixel images for a 320px wide screen? Using @media queries can optimize layout, but what about optimizing the content, too?

We can’t do much with this yet. Those Filament Group go-getters are working on some crazy JavaScript voodoo for serving different size images, but good information about bandwidth, upload/download speed, etc. is hard to come by, for now. Which doesn’t mean we can’t optimize content at all (we might think about whether we need those 1300x900px images at all). More on that later.

This is probably the area with the most room for responsive innovation, and until that innovation happens, people are suggesting we optimize content based on what the user wants. Which is really a conversation about intent, and not capability. See? It’s confusing.

Layout by intent

User intent is the holy grail of user experience design. We make a series of guesses (some more educated than others) about what people might want to find on our site, how they might want to find it, and how to organize and label everything so it’s easy to find.

But here’s where the biggest mix-up almost always happens.

We can’t reliably determine a user’s intention based on the capability information we collect from her device or internet connection.

By pretending we can, we’re like a shop owner who rearranges his entire store every time a car pulls into his empty parking lot. He notes the make and model of the customer’s car and makes a few appropriate changes. Mini-van drivers want milk and gum and mac and cheese, of course, so these get pushed to the front. And of course they don’t want to see those nudey magazines in the display racks, so they get stashed away in the stock room. And so on.

Even if those things were true in the shop owner’s case, he could achieve a similar effect by keeping those magazines out of direct plain sight and making sure the food aisles are neatly labeled for people to find. It’s easy to forget that the mini-van driver pulled into your parking lot, so they obviously intend to shop at your store. It’s probably not necessary to guess exactly what they want to do on each individual visit, especially when a wrong guess can hinder them from doing what they want to do (Uncle James may have taken the mini-van to the store to pick up his nudey magazine, after all).

Content by intent

If we assume we can accurately guess the user’s intentions based on capability information, we might be tempted to remove irrelevant content from that user’s view. Jeremy Keith responds to this kind of assumption better than I can, so I won’t try to duplicate it.

We have once again created a consensual hallucination. Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.

More and more people are using mobile devices as a primary means of accessing the web. The number is already huge and it’s increasing every day. I don’t think they’re all using their devices just to look up the opening times of restaurants. They are looking for the same breadth and richness of experience that they’ve come to expect from the web on other devices.

Hence the frustration with mobile-optimised sites that remove content that’s available on the desktop-optimised version.

Making drastic changes to content based on what we assume a user wants on any particular visit gives more credibility to our assumptions than I want to give.

The point about user intent: it’s design, stupid

We can be responsive to what our users want, but we do it at the point of design, not at the point of visit. In other words, when a user visits a site, we can gather information about the capabilities that user has available to him, and rearrange layout and content accordingly. But we can’t reliably and accurately use that information to determine what the user wants, enough so that we can remove content that we assume he doesn’t need.

Again, a pretty picture, this time with a few more words.

Some people go so far as to say that all web design is responsive design, which is hard to argue with, but there are subtle differences. Build a site that works for your users (design) and build it with enough flexibility to adapt, subtly, to various capability levels (responsive design). The semantic difference is trivial, but the end result is the same: we need more responsive design, not less.

One web to rule them all

You either build for a device or you build for the web. You can’t build a web-app that’s just for the iMac. If you try, people will access it from other devices and rightfully expect to be able to use it, because that’s what the web is. When we build for the web, our initial design should respond to what we know about our users, and the layout and content should be able to subtly respond to a user’s capabilities on the fly.

That’s how we build a more responsive web. Not a mobile web, or a desktop web, or an iPad web, or any other kind of web we might try to predict.

Comments

14 Responses to More Responsive Design, Please

Regarding your last paragraph about designing for the web, not devices, I think a lot of people develop for a sphere around their own usage.
For example if a developer has high speed internet on their desktop and their iPhone, they’ll tend to forget those that don’t and cater best for other users with similar speeds (maybe not deliberately).

And as someone without internet on my phone now, I’m sure I’ll start to think more about mobile when that becomes something I use personally.

One the surface, it appears that those who think responsive design is not an effective tool are objecting to its use as a “one tool for all” solution. In the sense that “I need to pound a nail and the tool at hand is a chainsaw so I’ll pound it in with that, because a tool’s a tool” doesn’t make sense, that idea holds water.

But for those who would use it as one weapon in our arsenal, the objection doesn’t hold.

There are many more issues in coming up with a layout to suit, and there are other options for them: don’t use a javascript library unless an intended platform can support it; use only a small image in your non-media-query stylesheet, and so on.

I haven’t produced a website in a while, but when I next do, these are some of the tools I intend to brush up on, and with them hopefully achieve an appropriate experience for the time.

Thank you for this thought-provoking article and the links to supporting and contrasting discourse.