Context

I swear there’s some kind of quantum entanglement going on between Ethan’s brain and mine. Demonstrating spooky action at a distance, just as I was jotting down my half-assed caveat related to responsive design, he publishes a sharp and erudite explanation of what responsive design is and isn’t attempting to do. He uses fancy learnin’ words and everything:

When I’m speaking or writing about responsive design, I try to underline something with great, big, Sharpie-esque strokes: responsive design is not about “designing for mobile.” But it’s not about “designing for the desktop,” either. Rather, it’s about adopting a more flexible, device-agnostic approach to designing for the web. Fluid grids, flexible images, and media queries are the tools we use to get a bit closer to that somewhat abstract-sounding philosophy. And honestly, a more unified, less fragmented approach resonates with my understanding of the web on a fairly profound level.

Meanwhile Mark has written a beautiful encapsulation of the sea change that responsive design is a part of:

Embrace the fluidity of the web. Design layouts and systems that can cope to whatever environment they may find themselves in. But the only way we can do any of this is to shed ways of thinking that have been shackles around our necks. They’re holding us back.

Start designing from the content out, rather than the canvas in.

Both Ethan and Mark are writing books. I can’t wait to get my hands on them.

In the meantime, I wanted to take an opportunity to clear up some misunderstandings I keep seeing coming up again and again in relation to responsive web design. So put the kettle on and make a nice cup of tea while I try to gather my thoughts into some kind of coherence.

Breaking it down

To paraphrase , web design is filled with quite a few known unknowns. Here are three of them:

  1. Viewport: the dimensions of the browser that a person uses to access your content.
  2. Bandwidth: the speed of the network connection that a person uses to access your content.
  3. Context: the environment from which a person accesses your content.

Viewport

With the proliferation of mobile devices, tablets and every other kind of browsing device imaginable, there’s a high number of possible viewport sizes. But here’s the thing: that’s always been the case.

For over a decade, we have pretended that there’s a mythical perfect size that every person will be using. To start, that size was 640x480, then it was 800x600, then 1024x768 …but this magical ideal dimension was always a phantom. People have always been visiting our websites with browsers open to varying dimensions of width and height—the rise of “mobile” has simply thrown that fact into sharp relief.

The increasing proliferation of different-sized devices and browsers means that we can no longer cling to the consensual hallucination of the “ideal” viewport size.

Fortunately this is a solved problem. Liquid layouts were a good first step. Once you add media queries into the mix it’s possible to successfully deal with a wide range of viewport sizes.

Simply put, responsive web design solves the viewport question.

But that’s just one of three issues.

Bandwidth

Using either media queries or JavaScript, we can test for a person’s viewport size and adapt our layouts accordingly; there is no equivalent test for the speed of a person’s network connection.

This sucks.

The Filament Group are experimenting with responsive images and I hope to see a lot more experimentation in this area. But when it comes to serving up different-sized media to different people, we are forced to make an assumption. The assumption is that a small viewport equates to narrow bandwidth.

‘Tain’t necessarily so. If I’m using my iPod Touch I’m surfing with a fairly small screen but I’m not doing it over 3G or Edge—same goes for anyone idly browsing on the iPhone or iPad on their work or home connection.

Likewise, just because I’m using my laptop doesn’t mean I’m connected with a fat pipe. When I took the train from Seattle to Portland there was WiFi available …of a sort. And many’s the hotel connection that pushes the boundaries of advertising itself as “high speed.”

Once again, the “solution” to this problem for the past decade has been to ignore it. Just as with viewport size, we engage in a consensual hallucination of ideal bandwidth. Just as with viewport size, the proliferation of new devices is highlighting a problem that was always there. Unlike viewport size, the bandwidth issue is a much tougher nut to crack.

Responsive web design doesn’t directly solve the bandwidth question. I suspect that the solutions will involve a mixture of server-side and client-side trickery, most likely involving clever for nice-to-have content. I’ll be keeping an eye on the work of Steve Souders.

In the meantime, the best we can do is stop assuming a best-case scenario for bandwidth.

Context

You don’t know what a person is doing when they visit your website. It’s possible to figure out what viewport size they are accessing your content with and it might even be possible to figure out how fast their network connection is but short of clairvoyance, there’s no way of knowing whether someone is in a hurry or looking to spend some time hanging out on your site.

Once again, this has always been the case. Once again, we have up ‘till now ignored the problem by pretending the person visiting our website—the same person with the perfect viewport size and the fast internet connection—doesn’t mind being served up dollops and dollops of so-called “content”, very little of which is directly relevant to them.

The rise of services like Readability and Safari’s Reader mode demonstrate that the overabundance of page cruft is being interpreted as damage and routed around.

The context problem—figuring out what a person is doing at the moment they visit a site—is really, really hard.

Responsive web design does not solve the context problem. It doesn’t even attempt to. The context problem is a very different issue to the viewport problem—which responsive web design does solve. As Mark put it:

It’s making sure your layout doesn’t look crap on diff. sized screens. Nothing more.

He was responding to Brian and Kevin who I think may have misunderstood the problems that responsive web design is trying to solve. Brian wrote:

anyone that claims “responsive design” as a best practice clearly has never actually tried to support multiple contexts or devices.

Those are two different issues: contexts and devices. The device issue breaks down into viewport size and bandwidth. Responsive design is certainly a best practice when tackling the viewport issue. But Brian’s right: responsive design does not solve the problem of different contexts. Nor did it ever claim to.

As I’ve said before:

The choice is not between using media queries and creating a dedicated mobile site; the choice is between using media queries and doing nothing at all.

If responsive design were being sold as a solution to the context problem, I too would be annoyed. But that’s not the case.

The mythical mobile context

As with the viewport issue and the bandwidth issue, the context issue—which has always been there—is now at the fore with the rise of mobile devices. As well as trying to figure out what a person wants when they visit a website, we now have to think about where they are, where they are going and where they have just been.

This is by far the toughest problem.

Bizarrely, this is the very known unknown that I see addressed as though it were solved. “Someone visits your site with a mobile device therefore they are in a rush, walking down the street, hurriedly trying to find your phone number!”

Really?

The data does not support this. All those people with mobile devices sitting on a train or sitting in a cafe or lounging on the sofa at home; they are all in a very different context to the imaginary persona of the mobile user rushing hither and thither.

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.

Rather than creating one site for an imaginary desktop user and another for an imaginary mobile user, we need to think about publishing content that people want while adapting the display of that content according to the abilities of the person’s device. That’s why I’m in favour of universal design and the One Web approach.

That’s also why responsive web design can be such a powerful tool. But make no mistake: responsive web design is there to help solve the viewport problem, not the context problem.

Update: Of course the usual caveat applies. Also, here’s some clarification about what I’m sugguesting.

Have you published a response to this? :

Responses

Hidde de Vries (@[email protected]) is a web enthusiast and accessibility specialist from Rotterdam (The Netherlands). He currently works on web standards for the Dutch government and is a participant in the Open UI Community Group. Previously, he work

From 21 April, Google will start preferring sites it considers “mobile friendly”. The criteria are listed in a blog post and Google provide a tool for web masters to check whether they deem websites eligible for the label.

First, we should define what we are trying to be friendly for here. What’s the ‘mobile’ in ‘mobile friendly’? Is it people on small screen widths, people on the move, people with a slow connection? The latter is interesting, as there are people using their fast home WiFi on a mobile device on the couch or loo. There are also people who access painfully slow hotel WiFi on their laptops.

Assumptions are pretty much useless for making decisions about what someone is doing on your site. Mobile, as argued before by many, is not a context that helps us make design decisions. We’ll accept that for the purpose of this article, and think of mobile as a worst-case scenario that we can implement technical improvements for: people on-the-go, using small devices on non-stable connection speeds.

Great principles to start with

So what are Google’s criteria for mobile friendliness? According to their blog post, they consider a website mobile friendly if it:

  • Avoids software that is not common on mobile devices, like Flash
  • Uses text that is readable without zooming
  • Sizes content to the screen so users don’t have to scroll horizontally or zoom
  • Places links far enough apart so that the correct one can be easily tapped (Source)

Websites that stick to these criteria will be much friendlier to mobile users than websites that don’t. Still, do they cover all it gets to be mobile friendly?

It passes heavy websites, too

At Fronteers, we celebrated April Fool’s by announcing, tongue-in-cheek, that we went all Single Page App. We included as many JavaScript libraries into the website as we could, without ever actually making use of them. It made the page much heavier in size. We also wrapped all of our markup in elements, with no actual JavaScript code to fetch and render content. The site became non-functional for users with JavaScript on. External scripts were included in the <head> of the page, so that their requests would block the page from rendering. With JavaScript turned off, the site was usable as usual, with JavaScript on, all the user saw was an animated spinner gif.

All the user saw was an animated spinner gif

Probably not particularly funny, but it showed a problem that many modern websites have: loading content is made dependent on loading JavaScript, and lots of it. This is not user friendly, and certainly not friendly to users on wobbly mobile connections. In our extreme case, the content was made inaccessible. Still, as Krijn Hoetmer pointed out on Twitter this morning, the joke —still live on the page announcing it (view the source) — passed Google’s test for mobile friendliness:

Nope, Google, a media query doesn’t make a site “Mobile-friendly”. Your algo needs some love: google.com/search?q=site:… pic.twitter.com/GPgEfkpKLV

I think he is right, the algorithm could be improved. This is not trivial, because the algorithm has no way to find out if we intended to do anything more than display a spinner. Maybe we really required all the frameworks.

The tweet inspired me to formulate some other criteria that are not currently part of Google’s algorithm, but are essential for mobile friendliness.

Even more friendly mobile sites

There are various additional things we can do:

Minimise resources to reach goals

Slow loading pages are particularly unfriendly to mobile users. Therefore, we should probably:

  • Be careful with web fonts Using web fonts instead of native fonts often cause blank text due to font requests (29% of page loads on Chrome for Android displayed blank text). This is even worse for requests on mobile networks as they often travel longer. Possible warning: “Your website’s text was blank for x seconds due to web fonts”
  • Initially, only load code we absolutely need On bad mobile connections, every byte counts. Minimising render-blocking code is a great way to be friendlier to mobile users. Tools like Filament’s loadCSS / loadJS and Addy Osmani’s Critical are useful for this. Possible warning: “You have loaded more than 300 lines of JavaScript, is it absolutely needed before content display?”
  • Don’t load large images on small screens Possible warning: “Your website shows large images to small screens”

Google has fantastic resources for measuring page speed. Its tool Pagespeed Insights is particularly helpful to determine if you are optimising enough. A reason not to include it in the “mobile friendly” algorithm, is that speed is arguably not a mobile specific issue.

Use enough contrast

If someone wants to read your content in their garden, on the window seat of a moving train or anywhere with plenty of light, they require contrast in the colours used. The same applies to users with low brightness screens, and those with ultramodern, bright screens who turned down their brightness to deal with battery incapacity.

Using grey text on a white background can make content much harder to read on small screens. Added benefit for using plenty of contrast: it is also a good accessibility practice.

Again, this is probably not mobile specific; more contrast helps many others.

Attach our JavaScript handlers to ‘mobile’ events

Peter-Paul Koch dedicated a chapter of his Mobile Web Handbook to touch and pointer events. Most mobile browsers have mouse events for backwards compatibility reasons (MWH, 148), he describes. That is to say, many websites check for mouse clicks in their scripts. Mobile browser makers decided not to wait for all the developers to also check for touch behaviour. So, mobile browser makers implemented a touch version of the mouse click behaviour, so that click events also fired on touch.

Most mobile browsers listen to touch events, like touchstart or gesturechange (iOS). So maybe we could measure mobile friendliness by checking if such events are listened to? This is a tricky one, because a script that only listens to click events can be mobile friendly, because of backwards compatibility.

Depending on the functionality, JavaScript interactions can be improved by making use of mobile specific events. Carousels (if you really need to) are a good example of this: adding some swipe events to your script can make it much more mobile friendly. Or actually, like the two above, it would make it friendlier for all users, including those with non-mobile touch screens.

Even more friendly sites

Page speed, colour contrast and touch events may not be mobile specific, but I would say that goes for all four of Google’s criteria too. Legible text helps all users. Tappable text also helps users of non-mobile touch screens.

If we are talking about improving just for mobile, Google’s criteria are a great start. But we need to work harder to achieve more mobile friendliness. Above, I’ve suggested some other things we should do. Some can be measured, like improving load times and providing enough contrast. These things are friendly to all users, including mobile ones. Other things will have to be decided case by case, like including ‘mobile’ events in JavaScript, but probably also how much of our CSS or JavaScript is critical. As always, it depends.

Related posts

Media queries with display-mode

I never would’ve known about the `display-mode` media feature if I hadn’t been writing about it.

Fanfare for the common breakpoint

“Common” breakpoints are the new fold.

Ethan Marcotte: The Responsive Designer’s Workflow

Liveblogging Ethan’s talk at An Event Apart in Boston.

Clarification

A follow-up on responsive web design.

Related links

Great Works of Fiction Presents: The Mobile Context | The Haystack.

A really great article from Stephen on how we are mistakenly making assumptions about what users want. He means it, man!

Tagged with

Deciding what Responsive Breakpoints to use | Tangled in Design

Another call for design-based (rather than device-based) breakpoints in responsive sites.

Tagged with

Creating a Mobile-First Responsive Web Design - HTML5 Rocks

A great step-by-step tutorial from Brad on developing a responsive site with a Content First mindset.

Tagged with

Jordan Moore | Web Design, Northern Ireland, Bangor, Freelance

A sweet little meditation on the nature of the web and responsive design.

Tagged with

JoshEmerson.co.uk · Blog · The Responsive Process

Josh goes through the talking points from the recent Responsive Summit he attended. Sounds like it was a great get-together.

Tagged with

Previously on this day

19 years ago I wrote Reckoning

Shock and anger.

20 years ago I wrote Simple Storage Service

Amazon’s newest web service has no face, but I think it’s got legs.

23 years ago I wrote iPays my money, iTakes my choice

I’m upgrading my iBook.

24 years ago I wrote J.E.R.E.M.Y.

Journeying Electronic Replicant Engineered for Mathematics and Yardwork

24 years ago I wrote FilmWise

I’ve just spent hours trying to figure out what films these invisible people are in.

24 years ago I wrote Paying lip-service to usability

Here’s an article about usability in The Guardian.