Responding to Responsive Web Design

This article originally appeared on joecritchley.com

‘Responsive Web Design’ has started to shape the way designers and developers create sites and applications. I’ve often heard it mentioned in meetings with clients; explaining it as a lever for fundamental design decisions.

But I now feel like it’s time for it to evolve into something else entirely.

Initial intentions #

Briefly going back to May 2010, when the term was coined by Ethan Marcotte, there’s no denying that he was restricting the idea (at that point) to device’s size. Utilising CSS3 media queries to modify a page’s presentation to the user. Yet still, this is massively inspiring, and has sparked many debates in the design community.

Have we responded? #

But nearly 2 years later… have we responded with our own ideas to what Ethan has proposed? I don’t think we have. We have a narrow mindset, sticking to media queries, basic grid patterns, and native image dimensions. But that’s all still adapting to only one condition - the device’s size.

My point is actually quite simple: there’s a lot more out there, of which we can creatively respond to. We are surrounded by conditions that are spawned from the device, the user and the content. And we can do anything we want with them.

Sample conditions #

Here are some examples of how we could adapt a user interface:

1. Performance — not everyone can view a product with the same computational power. Some developers be pushing the use of 3D for all capable browsers; but what if the user’s machine is outputting a frame rate of 10 FPS? Maybe we should be ‘listening’ to the frame rate, and degrade the aesthetics accordingly, giving a smoother experience.
2. People — if the user has connected your app to their social network, perhaps we can utilise this data to provide them with a more personal experience. I’m not necessarily talking about personalisation of content (as that moves away from the interface); but instead, personalisation of the UI.
3. Quantity — Imagine a grid of photos. The user needs to see an overview of these photos, so its no good displaying a 1-up layout. The ideal situation is that the photos fill up the screen whenever possible, so if there’s just 2, they each take up about 50% of the panel; but if there’s 20, then they are evenly distributed at about 5% each. There would obviously need to be realistic boundaries in this kind of situation, but it can be applied in other situations too, namely navigation menus.
4. Behaviour — users’ behaviours and tendencies change over time that’s spent using a product. They become more used to controls and layout. If you accurately measure how familiar they are with your application, you could for instance show a tutorial on the workflow of using certain features, if they have not yet explored them.
5. Time — I’m not exactly meaning seasonal header banners when it reaches the holidays here. I’m referring to the importance of time. It’s often the case that the latest activity is the most important. On the other hand, users may need to access older data more than you think. Facebook’s Timeline is a perfect execution of this.
6. Bandwidth — You only realise how much of an issue bandwidth still is when you experience it yourself. I was stuck with using a 3G dongle in quite an enclosed area for 3 months, and everything was slow. And I knew that all I needed was the primary content, otherwise I was waiting for hours. If sites could just recognise that the user has low bandwidth, and degrade everything but the core content, that would be so useful!
7. Controls — Ok, so we often consider a device’s size. But what about the method of primary controls? There’s a lot to handle if the user is touching the site, or if they’ve got a keyboard. Maybe we need to inform the user of certain ways to navigate a website. If they’ve got a keyboard, tell them they can use it. Similarly, don’t tell them to touch the screen if they’re on an iMac!!
8. Tone — I think this already exists in the form of some blogs, when an article’s page style has its own unique design. But what if this was automated within the UI? If the author tags an article as “serious” and “dark”, their content style automatically reflects this, being displayed with very readable humanist type, on a dark background.

–

The ultimate condition #

It’s great to consider all the above when possible, but more importantly, is the project’s conditions. The most common question when it comes to responsive design, is whether using media queries to full affect the layout or building a separate mobile version is the best option. Just remember to fully consider the project’s constraints, rather than the latest Web trends. But more importantly, remember that both methods are completely responsive, as you’re responding to a condition.

Conclusion #

Okay, so it seems like I’ve racked my brain to come up with examples there. But the fact is, there are endless conditions in UI Design, and a lot of them will be completely project-specific.

I would love for responsive design to be considered in our discovery process; not just when implementing the UI. I’m effectively proposing that we change the definition of the term, so that we can open our minds in fresh ways every time a new client comes to us.

I don’t think there’s any reason to give this way of thinking a new name. Responsive design is suitable, and has its roots in building architecture, which is very inspiring. We just need to move the Web forward.