Over the past couple of years, I’ve been tagged with a reputation of being somehow an opponent to the technique Ethan Marcotte coined “Responsive Web Design” in his seminal A List Apart article of the same name. Ethan defines Responsive Web Design as a technique that incorporates fluid grids, flexible images, and media queries to deliver experiences that accommodate today’s multi-device world, and he has vigorously defended his brand name against any suggestions that there are other ways (besides fluid grids, flexible images, and media queries) to achieve the same effective result.
That’s fine. Ethan coined the term, and Ethan is therefore free to define it. The trouble I’m having is that because I have a handful of concerns with the specific techniques Ethan outlines (again, fluid grids, flexible images, and media queries), it’s perceived that I oppose the concept of interaction design that responds and adapts to the environment it’s used in. Nothing could be further from the truth. I’ve been talking up the idea of adapting to users’ contexts and environments for at least five years.
To me, it’s clear and obvious that responsive, adapting design is the most appropriate path forward for our industry. And Responsive Web Design™ (for the sake of clarity, let’s refer to Ethan’s concept that way) is part of that. But Responsive Web Design™ is narrow in its focus. First, it only applies to the web (or at least only interfaces rendered with CSS). Additionally, it really only deals with layout. Other design elements (content, IA/IXD, style, etc.) aren’t really accounted for. Also, it only allows for one technological solution to the issues it addresses, and shuts out others (for example, Ethan insists that using Javascript instead of media queries to determine breakpoints for layout changes doesn’t qualify as “responsive”).
But perhaps most interestingly to me, it doesn’t address the user’s context and environment outside of screen size and orientation. There are so, so many more factors that go into defining a user’s context. Some, off the top of my head: Where are they? Home? Work? Inside? Outside? Private place? Public? Moving? In a car? Driving (eeek!)? On a train? What’s the weather like? Who are they with? Are they alone? In a group? Are they likely to be sharing the contents of their screen with those nearby? Who are they virtually with? What kind of engagement do thy have with your product? Continuous? Intermittent? Full? Partial? How are they physically using your device? Is it in their hand? Pocket? Desk? Nightstand? Open? Closed? One-handed? Two? Are they sitting? Standing? Lying down? There are countless more questions you could ask about your user’s environment, and potentially react to, design-wise.
Responsive Web Design™ is a great technique, and one that may have many useful applications in your product. I am in no way opposed to it, and I’ve used it myself for several projects. If you find it works for you, that’s awesome. But, I’d encourage you to:
- Remember that Responsive Web Design™ is really just responsive layout, and consider what other aspects of your design can and should also adapt and react to user’s environments.
- Explore responsiveness to other aspects of users’ environments beyond screen size and orientation.
- Consider all the technological means to the end you’re looking for, rather than only those that fall into Ethan’s definition of Responsive Web Design™.
- Not limit your responsive and adaptive thinking to web products, or even those that are rendered with CSS. The concept is useful is nearly all fields of design (even beyond interaction design).
In the end, just remember that Responsive Web Design™ isn’t the only way to be responsive.
Jeff, I’d love to hear more about how you take into consideration some of the contextual possibilities you’ve mentioned. One of the toughest puzzles of web design as we move forward into an increasing fragmented landscape of devices is how to account for context and its double-edged sword.
The worry, of course, is that by designing to overly specific contexts (On a train? Lying down? In a box? With a fox?), we can overdesign and limit the functionality and usability for the rest of the possible contexts, which in almost any case will be a majority of users (all but that one specific context). The easy (conceptually, not technically) answer is to build an experience that responds to unique device capabilities to create on that device a single most robust experience possible. Without additional device capabilities and sensors to verify specific contexts, what strategies have you found effective to detect environmental aspects beyond device capabilities?
Matt, the thing to consider (and Jeff may agree with me) is that a responsive approach may mean building more than one site or application to fit the key contexts. Sites will become more and more broad due to the growing number of contexts and we will be building multiple interfaces for the same data, using some in certain contexts and not at all in others.
A mobile web site could have a unique experience defined by a different IA and UX from a “desktop” version. A native mobile app for the same brand could use the same data but have yet another IA and UX to be responsive for that most likely, or encouraged, context.
So being responsive isn’t a magic bullet to apply to a site. In some occasions it is all that’s needed and it suits the problem but more often being responsive requires deeper thought and a more involved approach.
You have a good point, however, I think there’s a limit to how far one can go with this. As Matt points out, “overdesigning” accessibility (as in: accessible by many devices/methods/etc) can lead to an opposite effect.
Lets take a chair on that level. Maybe a well designed chair is comfy to sit in for anyone from 4‘3” to 5‘10”. Anyone above or below that range that can still sit in the chair, it just may not be optimal. Equally, the chair is fine to leave out in the rain, however sitting in it, while in the rain is beyond my control as the designer of the chair. You are on your own, if you decide to put the chair in the rain, but if you use it in about 90% of the normal range of use cases, it’s going to do it’s job well. (again, not always optimal, but definitely doing it’s job). Think if you made a chair that catered to each and every use case possible, what would that chair look like? I dont think it would work well, in the 90% use case anymore.
I guess I should also note that I’m not saying that “Responsive Web Design” to me: would fall more under the idea that you are trying to get across.
Hence, why not use javascript elegantly to work around technical limitations and give an even broader user base. I completely agree that we shouldn’t limit a technology if it has the ability to solve the problem or expand the solution. (ie..better experience for more users/devices)
Matt and Dave-
Don’t misunderstand me. I’m not saying that you should always account for every aspect of a user’s environment that came to me while writing this, I’m just saying that you could, and therefore you should at least consider what possibilities exist, and whether or not they make sense for your app. Maybe they don’t, and that’s fine—as long as they’re considered.
Here’s a very simple, but practical example: assume a visual content-consuming experience (reading, viewing a video, etc.). Now assume you don’t have a device sensor at your disposal to determine the light level (ambient light sensor). You could considering adjusting the default brightness and contrast of your UI, say, after the sun goes down. Easy enough to get sunset times, so it’s technically very possible. Should you? I don’t know. Depends on your app. And if you do, should you offer a way to override this default? Yes, of course.
I’m simply asking you to think bigger. If you’re already thinking bigger and deciding the best thing for you is to simply focus on adapting for screen size and orientation, that’s great.
Interesting points, Jeff. I agree that Responsive Design is just that — all about design, and not really taking into account other aspects of interactivity with the user.
But that’s where we are right now. I’d love to hear your thoughts on the other aspects that you mentioned, and how those could shape the web in the future. It’s very out of the box thinking. The one that intrigued me most is “are you in a group?”. Right now the web is a VERY solo experience, not catered to groups of individuals.
Just think — a sort of group photo application that detects the presence, either by geolocation or some other method, of logged in users and their proximity, and shows all photos based on what it determines to be “a group of people together in the same room looking at the app”.
This all sounds pretty vague. And good luck with finding clients willing to greatly increase their budgets to get all of the contexts that you suggest we need to account for. The beauty of responsive techniques are that they can be applied to many different layouts without having to make special versions for different contexts. These techniques can be used without busting the budgets of small businesses and organisations that likely comprise many of our customers.
Your message is somewhat undermined by the snarky and rather childish use of the trademark symbol. It makes it seem like you have a grudge.
Simon: How’s come your comment sounds like it’s written to someone who didn’t just say “Responsive Web Design™ is a great technique, and one that may have many useful applications in your product?”
I’m not sure how much more clear I could be that I’m a fan of Responsive Web Design™ and that it is in no way contrary to the bigger, more conceptual thinking I’m suggesting.
I think that “Responsive Web Design”is a lot more than Ethan intended it to be even though he’s been quite clear about its definition. In reality it seems that its best use is for layout and you are quite right that it has further-a-field value.
If we change the name to be “Responsive UI” then it opens the doors to those that need it spelt out, and we can all go back to finding solutions to all these UI problems.
Don’t misunderstand me either. I’m far from arguing that RWD (with caps) is always the correct solution, and none of the mobile projects that I’ve actually worked on in the last year have been universal RWD projects, because it wasn’t the right solution for those clients.
I’m just generally and genuinely interested in your ideas about strategies to reliably detect some of the more obscure or specific contexts that could affect a user’s experience.
Additionally, while you make a valid point to caution against the perception of RWD as a universally appropriate solution for mobile (which, we can hopefully agree, it has never been argued for by Ethan and most of it’s prominent proponents), I’m making the similarly valid cautionary warning against the potential perception that you should always design for specific contextual assumptions.
I think the key issue here is that it’s hard to be an public, educational evangelist of something new, yet do that with the level of contextual analysis a working professional needs always apply when looking for a solution. Ultimately, I agree with Jeremy.
Matt, I completely agree with everything you just said, and definitely with Jeremy’s post that you linked to — and I don’t think anything I’ve said prior contradicts that.
I think the idea of context being an evolution of responsive is very important. A restaurant or a venue can have a lovely site that I fully appreciate on my laptop or even my ipad, but when I am mobile and need to pick up food or buy a ticket to an event, I need to be able to do that super efficiently, just that specific action.
Specifically, I do not want or need to see a responsive version of your slideshow of delectable food or next five concerts or movies. I need the site to present the specific info and action I am looking for as quickly as possible…phone, hours, menu or event list.
Businesses need to think about analyze scenarios for user pathing and optimize for that context. I’m not sure how all that can and should happen, but it is definitely important.