Chris Armstrong's avatar

Chris Armstrong
29th April 2011

The Goldilocks Approach to Responsive Design

With over 4 billion mobile devices in use around the world, mobile browsing is rising fast. We can no longer assume that our sites will be viewed on a desktop monitor with an average resolution. Perhaps we never could.

UPDATES:

The answer, proposed by Ethan Marcotte, is Responsive Web Design. Instead of building separate sites for each device, we build one site that adapts to each device. However, the current approach to responsive design is still based on a few popular devices and, as a result, is likely to become obsolete as fast as they do.

What if we could create a truly universal design that was device independent – one that, no matter what device you viewed it on, looked like it was designed just for that device? At New Adventures, Mark Boulton talked about designing from the content out, rather than the canvas in, and we think this makes good sense. Perhaps the only way to create a design that will work on any device is to forget about the device altogether.

Current Practice

The current approach to responsive design binds the design to the device. It uses pixel widths based on the dimensions of the most common devices, but we don’t think this approach is good enough. It results in designs that are based on two big inconstants:

  • device resolution; and,
  • pixels.

Device resolution

There are thousands of different devices out there, with millions of potential contexts. We can’t support them all, so we end up choosing a few popular devices, basing our designs on their resolutions, and ignoring the rest of the products on the market. When technology moves on and resolutions increase, our sites will look as outdated as a 600×400 site does now.

Pixels

Pixels sizes aren’t constant – or at least the display of them isn’t. 16px text on an iPhone can be ~60% the size of 16px text on a Macbook. Basing designs on pixel measurements creates inconsistency in viewing size across devices and can negatively affect readability and usability.

The Device Doesn’t Matter

So how do we do as Mark Boulton suggests and go about designing from the content out? In practice, it means starting with the most common form of content, the paragraph element, and building up to a full layout.

It’s tempting to first set the body font size. But the manufacturer or the user has already set the browser’s default size for readability, and we don’t think you should mess with it without good reason.

However, if you base your entire design on this base font size (using ems), then as it increases or decreases, so will your design. Using ems allows your designs to be resolution independent.

Next, use max-width to set the line length of the paragraph to be as readable as possible (~66 characters per line). This will vary from font to font, but something around 30em usually does the trick. This sets the width of your single column layout, making it ‘just right’ for readability.

The Goldilocks Approach

Now, no matter which device your design is viewed in, the space available will be bigger, smaller, or just right, and you can use media queries to make the most of it.

Too big

If there is substantially more space than the single column width, then you can consider moving to a multi-column layout. For example, if the single column width is 28em (plus 1em margin on either side), and the screen width is more than 45em, then you have enough room to move to a three-column layout with 13.5em columns and 1em gutters, with the main content spanning two columns (so remaining the optimum width for readability).

Too small

If there’s less space than what’s required for optimum readability, then you need to make the most of the space you have. For example:

  • halving the outer margin (but not removing it); and/or
  • bringing any hanging punctuation inline (so it isn’t cut off).

Just right

If the space available is just right for your single column, then you’ve nothing to worry about. Your work here is done. Go make a cup of tea.

We’re not saying that a single column layout is the best layout for every site. We don’t know which layout a user will be viewing, so our sites need to work just as well in a single column state as they do with multiple columns. However, in practice, we’ve found that it helps to get the single column state right and then work up or down.

The Perks

We think this approach has a quite a few benefits.

With the current approach, even if you only designed for Apple devices (lucky!), you would require up to five different states:

  1. iMac (large display)
  2. Macbook (smaller display)
  3. iPad (tablet – could be portrait or landscape)
  4. iPhone 4 (Retina)
  5. iPhone (non-retina).

The Edenspiekermann site seems to take this approach and does it very well, but it’s just not a scalable solution. With the Goldilocks approach, you only have to consider three states:

  1. multi column (too big)
  2. narrow column (too small)
  3. single column (just right).

By taking the device resolution out of the equation, you get layouts that should work across all devices and contexts, even ones that haven’t been invented yet. If, for whatever reason, a user has their base font size set to 80px, then this approach should still produce an appropriate layout for the space available. Talk about device independence.

And finally, technology changes, but the human body has stayed pretty constant for the past few thousand years. By designing for human constraints (readability) rather than technological constraints (device size and resolution), your layouts won’t date any time soon.

And so the designers lived happily ever after…

Responsive design requires a new way of thinking, and there’s still plenty of discussion and exploration to be had before we can settle on what is ‘best practice’. We’ve found this approach to work well for us, but how do you think it would work for you? Let us know in the comments.


Previous Article

Next Article


Comments

Robbie Manson said

Well put, Chris. Great to hear design agencies thinking like this, and being vocal about it too. Whilst I don’t work in an agency any more, my previous experience was of a fairly linear, rigid process: plan → IA → design concepts → design development → template build → CMS integration.

I’d be interested to hear more about how your “Goldilocks” approach works as part of the larger workflow at Front. In what format are design concepts ‘signed off’ by clients, and how do you go about explaining to your clients the way a site will adapt without actually building it? Is there even a design ‘sign off’ milestone, or do you work in a more agile way, prototyping and gathering constant feedback as you go? If so, how does that impact on the difficulty of estimation and budgeting?

Sorry if this stuff is a bit outwith the scope of the article! Perhaps an article in itself? :)

Robbie

1 year, 10 months ago

front said

front's avatar

Yeah there’s probably another article in that!

*makes note*

In brief though, this has had an impact on every part of our process, and to be honest we’re still working it out.

The aim of all this is to find an efficient way to build sites that are responsive by default, just as we build standards-based sites by default (without budgeting extra to make them standards-based). We’re not there yet, but that’s the goal!

Some techniques we’ve found helpful are Pattern Translation (how does a design pattern that works well in multi-column translate to a single column state?) and using a Modular Scale (so the designers and developers are singing from the same hymn sheet).

1 year, 10 months ago

Stephanie Rieger said

First, let me say that I love the analogy to Goldilocks! :-P

There are unfortunately some problems with the “device doesn’t matter” approach. I do agree that the device doesn’t matter in the sense that there are now (and will continue to be) too many devices for you to identify each one and try to design for it. You do unfortunately need to design for the bandwidth context and the performance capabilities of the device.

This is the primary problem with RWD as a *sole approach* to supporting multiple devices. There are already far too many examples of RWD sites that serve 1-3MB of content to a mobile device because while the layout may now be flexible, the content has an inherent fixed weight. This is hugely deceptive for users who are experiencing an appropriate layout but still downloading inappropriate content. It’s also tricky to entirely rely on client-side adaptation to swap these and other elements such as scripts (e.g. jQuery libraries that may work on the desktop but not on the device).

So even if you design ‘mobile first’ ie. start with the most lightweight representation and use each style sheet to enhance for the larger/wider context, you are still left with images, scripts and other media that are designed for one layout and end up being carried over to the next (usually simply left unused in other contexts or hidden using display:none). This is unsustainable as a long-term approach.

So in the end, we’re finding that an approach that combines both server and client-side adaptation (e.g. layout progressively adapted on the client but using the server to swap media/images and adjust the occasional markup) still yields the best results.

Some reference material you may find useful:
http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu

http://www.slideshare.net/yiibu/beyond-themobilewebbyyiibu

if you’re interested there’s also a great conference coming up on the topic of mobile web http://mobilism.nl/2011

1 year, 10 months ago

front said

front's avatar

Some great points Stephanie, thanks!

However I still think the device doesn’t matter, but context does. The distinction is important.

We absolutely need to find a way to provide the best content for the context, but even on a single device the context can vary hugely. Mobiles and tablets can be used on mobile networks or over wifi, so device resolution isn’t a good indicator of what size of images we should serve up. Neither is it a good indicator of whether we should use a touch-based or cursor-based UI – just because I have my browser window small doesn’t mean I need buttons to be bigger. We need to find a better way of defining context.

That said, we have to be practical. Device independence is the ideal, and hopefully we’ll get there, but in the meantime each device is going to have it’s quirks and – depending on the needs of the project – you may need to support one device a bit better than another. However the idea is to at least have a basic level of support for all devices by default and – as we get better at it – increase that basic level over time. Progressive enhancement, effectively.

1 year, 10 months ago

Stephanie Rieger said

Yeah…the context issue is a thorny one. Going forward, we need to provide a multi-device user experience baseline (e.g. reasonable layout, content and page weight as default). Ideally some aspect of context would be part of that baseline.

Certainly the context of touch vs non-touch needs to be (although by rough estimates, about 30% of devices are multi-manipulation anyhow). APIs to detect battery life are already being discussed and many of us are involved in the various standards bodies to discuss other useful, contextual APIs.

There’s a browser manufacturer panel at the Mobilism conference that I expect will get pretty heated on the subject of context APIs! :-P

1 year, 10 months ago

Peter Bailey said

I’m sorry, but this isn’t much better than applying IE6 hacks. The real problem is device manufacturers who alter website’s appearances. Android has done a brilliant job at standardizing the OS, and therefore the browser, and Apple is pretty much there too.

With my smart phone I can view a website as if it were on a desktop computer, so there isn’t any need for special design for those devices. It’s the 20/30% who use devices which render websites like 1998 WAP.

1 year, 9 months ago

Rick Monro said

In parallel with the challenge presented to the designer by responsive design, there is a challenge also in managing the client’s expectation of how their site should appear in a small screen. We have had at least one comment, on seeing a site reform itself for a small viewport, that “the site is broken”... A discussion for another day perhaps.

We clearly have some way to go until best practice is set in stone for this, and I would share at least one of the views that Stephanie has raised. But it is a hugely exciting time to be working in the industry as these changes take hold, and this piece is a very constructive contribution to the wider discussion.

1 year, 9 months ago

Chris Armstrong said

Chris Armstrong's avatar

Thanks Rick. I agree, we need to work out how best to involve our clients in discussions around responsiveness, and communicate it’s benefits (shouldn’t be too difficult) so it isn’t a surprise to them.

When we’re designing layouts with different states in mind it definitely impacts our design decisions (i.e. solution X works for multi-column but not for single column, solution Y works for both so we go with it). If we’re not effectively communicating what has influenced these decisions then they could appear arbitrary – never a good thing!

1 year, 9 months ago

Stephanie Rieger said

Re: “It’s the 20/30% who use devices which render websites like 1998 WAP.”

iPhone users surf *far* more than other smartphone users and I routinely speak to companies with 75% iOS traffic (then followed by Android, BlackBerry and Nokia…frequently but not always in that order..depends on the country) however smartphones are still only about 25% of *all* the phones out there (globally). Even in the US, smartphone penetration is less than 50%.

There is lots of data to show that the other 75% of people (even ones with really bad browsers) are using the web (or at least trying to). In countries where smartphone penetration is very low (sometimes as low as 2-5%) there is high use of Opera Mini as it’s free and can give you an excellent web experience on even a basic phone. Opera Mini hasn’t caught on quite as fast in the US and EU so right now, these users pretty much get no experience at all. As a result, it’s becoming harder and harder for brands to justify completely ignoring non smartphone users.

1 year, 9 months ago

Peter Bailey said

If you check out the stats you’ll find that Symbian (and iPhone) web users are dramatically falling. More users are turning to Android - phones which render websites as if they were on a desktop. If the trend sticks in a few years those devices will just be a fraction compared to Android, which can supply a standard mobile web experience.

Using Opera Mini on a Blackberry for years before buying an Android I can say the browser is far from “an excellent experience” as you put it. But it’s very commendable that Blackberry is allowing browsers which try to come as close to the standard as possible. And as I said, that’s what is needed.

1 year, 9 months ago

Chris Armstrong said

Chris Armstrong's avatar

@stephanie out of interest, what is the rate of adoption for smartphones vs stupidphones (or whatever they’re called :D)? I assume that someday all phones will be smartphones… is this the case and if so how long do you think it will take?

@Peter the point of this approach, and responsive web design in general, is that it doesn’t matter what device they are using, they are given a layout that is appropriate to their context.

1 year, 9 months ago

Russell Bishop said

One thing I’d like to see here is a working example. I see a lot of people talking about their ideal spin-offs of responsive design, but I rarely see them progress to an example or a case study.

I think Robbie’s thinking earlier was spot on though; if you were to adopt a technique such as this, you’d have to make some serious fundamental changes to your processes.

Cheers!

1 year, 9 months ago

Chris Armstrong said

Chris Armstrong's avatar

Hi Russell, we have used it successfully on a recent client project but unfortunately it’s not live yet. We’re working on an example now actually, will post an update when we have it ready.

We’re also writing a follow-up article on how we’ve adapted our process, and some techniques we used and developed. Keep an eye on our twitter feed for updates!

1 year, 9 months ago

Chris Armstrong said

Chris Armstrong's avatar

Actually, in the meantime, our Project Planner landing page uses this approach: http://www.designbyfront.com/resources/planning-a-web-project

1 year, 9 months ago

Stephanie Rieger said

Hi Russell,
Our web site uses a modified approach of responsive web design that addresses many of the issues raised in the comments. A description of what we’ve done (and why) can be found at http://yiibu.com/about/site.

We also know of 3-4 large organizations that are working on or planning a responsive web redesign of their site and plan to incorporate improvements such as image and content adaptation for various contexts.

I think that by the end of the year there should be far more examples available for the community to draw on.

1 year, 9 months ago

Stephanie Rieger said

Hi Chris (sorry…just noticed your question today.)

Smartphone penetration is rising quite fast in some markets but far more slowly in others. What is often happening in developed economies is an increase of about 100% each year (but that’s from values like 5% penetration a few years ago…so that type of increase can only continue for so long…similar to the 3000% increase of Android in year one which inevitably levelled off).

What is also happening is that featurephones are getting smarter. Many now have a version of webkit and many now have touchscreens. So generally, phones are getting better but globally we’re still at less than a quarter penetration, which leaves about 4 billion people with featurephones. It’s highly unlikely (especially when you consider cost factors) that all 4 billion people will upgrade to smartphone level devices any time soon.

There are some useful stats for this starting on slide 14 of this presentation:
http://www.slideshare.net/yiibu/its-about-people-not-devices

In regards to a past comment about the likelihood that everyone (or most people) may have an Android in the near future, that is also a bit unlikely. There is already too much fragmentation and Android volumes still don’t compare to those of Nokia and the combined volume of several Asian manufacturers. Some of these manufacturers have been using Android but as Google has recently put restrictions on the platform, almost everyone has started considering other options (and there are at least a few other options to consider). Android is also already fragmented and it sounds like it may get worse as some manufacturers are already purposely adopting older versions (and forking them) rather than play by Google’s most recent rules.

Interesting times…

1 year, 9 months ago

Wiebke said

Dear Chris,

I just read your article several times. In our company we discussed the “Goldilocks Approach to Responsive Web Design” a lot during the last week.
But still there is one thing that we didn’t understand and I would be very glad if you could answer it: What exactly is the advantage of using em instead of pixels as a unit for widths and heights?
I know that it scales with the base font size and we already use it for font-sizes and the margins of text. But we never thought about using it as the unit for widths and heights.
Again, I would be very glad if you could answer this question (of which I know that it is a few months too late, sorry.

1 year, 7 months ago

Chris Armstrong said

Chris Armstrong's avatar

Hi Wiebke, thanks for the comment!

The point of using a relative unit (ems or %) for width and height is so that the layout is independent of the device resolution. Once you set a dimension in pixels, you guarantee that some day it will look too small, as resolutions keep increasing (remember when 640px was big for a website?).

Whether you use ems or % for widths and heights depends on the project. For the text-heavy sites this approach is aimed at, I prefer ems because the layout is then based on what is right (and most readable) for the text, rather than defining a grid based on the device size and squeezing the text into it. For sites that are more image-focused % may be a better unit to use.

Did that make any sense? :D

1 year, 7 months ago

Matthijs said

Very interesting approach. Thanks for writing this down and sharing it. I’m definitely going to look more into this combination of em-based layouts and media queries.

There’s one thing though: in Firefox (v5) when you increase the font-size enough, at some point the media query kicks in and the third column drops down. Exactly like when you would decrease the browser window size. And exactly like you would want it to work, in my opinion. This solves the problem I normally have with em-based layouts: when increasing the font-size enough, you get both a horizontal and vertical scroll bar. I find that very annoying (and not very usable, imho).

However, in quick tests in both Safari and Chrome, increasing the font-size at some point makes the columns overlap each other. Instead of the media query adjusting the layout. That’s definitely not acceptable. Have you given that scenario a thought?

Maybe setting the columns in a % and the content (text) in ems is a solution, I’ll have to do some experimentation with that.

1 year, 7 months ago

Chris Jacob said

Excellent approach. KISS is just what Responsive Design needs to gain quicker adoption + this approach seems more future proof then most.

One thing we often forget in terms of “context” is we already have an excellent resource to query…. the person. Seriously. Give them the option to change to either of these 3 layouts via javascript. Make “smart” assumptions up front with media queries… but always include controls for the user to take back control.

Also I love that by using EM’s you have a natively “zoomable” UI by increasing fontsize ... this could work wonders then scaling up to TV size displays.

Responsive Images (+ video & audio & other assets) do still need to be considered when thinking “moile first”... but at least there are now only 3 layouts to accomodate for… and bandwidth speed is only going to improve with time - where as viewports are only going to become more and more fractured.

Great work!

1 year, 4 months ago

Chris Armstrong said

Chris Armstrong's avatar

Hi Chris, that’s a great idea about giving the user controls to change context. It would be great if this was a browser control though, like standard zooming in.

And yes, there’s just so many benefits to using ems once you bite the bullet, easy scaling being one of them. Actually working on something interesting to help with this, watch this space… :D

You’re right though, Goldilocks only focuses on one part of responsive design, the responsive layout. Responsive images are a whole other problem we need to deal with :D

1 year, 4 months ago

Chris Jacob said

Oh, I should point out that even tho I compare this to being basically layouts of 960px, 480px and <480px fluid… it’s important to remember that you haven’t based this on the device widths - it’s focused on the “content” width. “Content” being paragraphs… so the the container width is based on optimum reading width for the font-size used on that paragraph (aprox 66 characters per line @ 16px font-size).

1 year, 4 months ago

Chris Jacob said

One last piece of feedback… I found on the iPad in Portrait orientation the single column layout at first seemed like perhaps it has a little too much left/right white space; but was clearly still an excellent reading experience (very content focused). But what what I really enjoyed was that with a simple Double Tap on the first paragraph the iPad does it’s native zoom in. I like to have a larger font-size on the iPad when reading so this suited me very well + baked right in ^_^

1 year, 4 months ago

Stephanie said

If interested in responsive images, here are a couple things you might want to look at:

Large two-part retrospective of responsive image techniques just published by Cloud Four in Portland.
http://www.cloudfour.com/responsive-imgs/

Part 2 (coming soon) will include a detailed analysis of known techniques (preview available here https://docs.google.com/spreadsheet/ccc?key=0AisdYBkuKzZ9dHpzSmd6ZTdhbDdoN21YZ29WRVdlckE&hl=en_US)


Some specific details of approaches that use both server and client can also be found here:
http://www.slideshare.net/yiibu/pragmatic-responsive-design
http://www.slideshare.net/yiibu/adaptation-why-responsive-design-actually-begins-on-the-server

1 year, 4 months ago

Chris Armstrong said

Chris Armstrong's avatar

@Chris great feedback thanks, gives me an idea… :D

@Stephanie wow those are fantastic thanks! What techniques have you found yourself using?

1 year, 4 months ago

Stephanie said

Hi Chris,
We combine server and client. Basically…do some detection/filtering/adaptation on the server, which ensures the device only downloads something appropriate..but then accept that appropriate may not be the *best* thing, so back this up with additional client-side detection and further adaptation if needed (most common scenario being the re-orientation of the device..which may require new assets but you could also adapt aspects of the DOM client-side if needed).

So overall, the approach is “heavy lifting” on the server and “tweaks” on the client.

You can see an example of this approach live at http://browser.nokia.com (which specifically needed to support a wide range of devices, many of which had poor JavaScript support on the client). We will eventually publish the source for the server-side stuff to GitHub..(hopefully this month).

1 year, 4 months ago

Stephanie said

Hi Chris,
Here is part two of that series on responsive images.

http://www.cloudfour.com/responsive-imgs-part-2/

A part 3 is also apparently in the works. :-)

1 year, 4 months ago

Chris Armstrong said

Chris Armstrong's avatar

Brilliant, thanks! Some weekend reading for me there… :D

Re: your Nokia site, it’s interesting that the webfonts don’t appear until a certain size. Would love to hear your reasoning behind that :)

1 year, 4 months ago

Chris Leonard said

@Chris Jacob The iPad portrait problem is a known bug related to the settings in the meta viewport tag. Scott Jehl has a nice writeup about it, http://filamentgroup.com/examples/iosScaleBug/

It drove me insane but I found a feasible fix, (https://gist.github.com/901295).

@Stephanie I read the yiiibu about page awhile back and following your techniques, developed a desktop/mobile form that uses server side detection to push specific content based on device. No unnecessary scripts, css or fields. No extra overhead.

Currently revolves around UA detection, but as mentioned here is not a scalable solution. From what I’ve been reading feature detection is better.

The Nokia dev site suggests using multiple server/client adaptations to limit problems but I’m curious if anyone has played or can offer some insight on HTML5’s caching and network information API techniques.

1 year, 1 month ago

Neil said

On your demo, the right side column fits directly underneath the first paragraph when viewed on an iPhone. How can I get this to appear at the bottom of the main content?

Thanks!

1 year, 1 month ago

Chris Armstrong said

Chris Armstrong's avatar

@Neil positioning the <aside> element below the main <article> element in your markup should do the trick?

1 year, 1 month ago

Stephanie Rieger said

@CHRIS LEONARD
Hi Chris,
We actually use very little UA detection per se. We use a device database (which uses UA detection mapped to 1000s of UAs) to deal with the first load only. Based on the information we can glean from the database, we make any initial decisions/adaptations (typically regarding image sizes but can be all sorts of other stuff) then store this device info as properties in a cookie.

We then query the device (at/during first load) and feature detect as much as we need, saving all that back to the cookie. So server and client now have the same info. The device typically has the final say (over the database) especially given that certain parameters such as viewport size are bound to change with use (e.g. reorientation).

All feature detection still has issues however given that the response it typically pass/fail. There is no real granularity so ‘knowing’ that Canvas is supported doesn’t necessarily reveal what is well implemented vs. barely functional. This is still a big problem regardless of whether you use a device database, run your own tests or use a toolkit such as Modernizr. We attempt to make up for this by implementing final tweaks based on ‘stuff we know’ rather than stuff the device has implicitly told us. Ideally, you want to do this as little as possible but it can be very handy.

Don’t have much experience yet with caching but I do know it’s still quite flaky. Steve Souders has completed some excellent research on the subject. Look for the video of his talk at the Breaking Development conference in Nashville last year.

1 year, 1 month ago

FRONT, Alexander House, 17a Ormeau Avenue, Belfast, N.Ireland, BT2 8HD • 028 9032 0970