On designing content-out (a response to Zeldman and others)

From: Stephanie Rieger

(…reposted from a lengthy comment on Zeldman’s blog which i’m not sure has been posted due to lack of moderation feedback…)

“I love “content-out” as a strategy…setting a series of breakpoints based on ems (based in turn on font size) could create lovely context-based layouts that move fluidly from one state to another. They won’t match with device sizes but they won’t be trying to. There is a lot to think about and play with there.”

– Zeldman, State of the Web: Of apps, devices and breakpoints

There IS a lot to think about and designing content-out is quite liberating, but it’s also important to remember why we’re doing this.

Designing content-out works quite well. We’ve used this approach for a while now and have found that if there are wonky/awkward spots when you test by resizing the screen on the desktop, they will in most cases end up just as wonky on devices. An approach that is working quite well for us at the moment is to design using major and minor breakpoints. (More of this in our Pragmatic Responsive Design presentation ).

The major breakpoints create the broad stroke changes that are required when moving from the small(er) screen (‘mobile’), to a much wider one (often a tablet-like device), to an even wider one (often a desktop but increasingly there can be higher breakpoints for TVs etc). These major breakpoints are set using media queries in the document head. The minor breakpoints live within those 2-4 style sheets and provide (mostly) the tweaks needed to remove awkwardness. This in effect creates media queries within media queries and provides huge flexibility while keeping it clear why each breakpoint has been set.

As noted by others in the comments to Jeffrey’s post, these ‘tweaks’ most often include adjustments in font-size, line length, line height, gutters, padding and other elements that make the layout feel more balanced and improve legibility. Other useful tweaks are adjustments of the overall font size to ensure button/menu touch targets and form elements are large enough to manipulate on touch screens. If you’re going as high as TVs, text often needs to be enlarged quite a bit at that size, so changes don’t always follow a predictable upwards or downwards path.

Then you move on to final pragmatic tweaks to ensure nothing is wonky on key devices. (Some people would say you should do this first but I think this just encourages teams to think of it as a ‘device-x site’.) Most sites fall into an 80/20 pattern where you can easily identify the top devices (often a cluster of 10-15 devices which almost always include the iPhone and iPad.) Be mindful however of the remaining 20% which can include 20-30 (+) devices and may easily amount to tens of thousands of users a month.

So while content should always guide the design (which also helps prioritize useful stuff like document flow, markup structure, and information design), the whole process works best as a balancing act between the opportunities and constraints provided by the medium.

When all is said and done, the reason we’re even doing this is because of device diversity, which will likely not go away. We are well on the way to standardizing around WebKit but even if screen sizes also standardize (…big if…more on this in a later post), a device will always remain way more than just a screen size combined with a rendering layer. The problem with the (exclusive use of a) content-out approach is that it may be seen as an excuse for many not to think about the devices at all. As it stands, very few people currently test on actual devices (on actual 2G, 3G, etc networks). There are many reasons for this (cost being only one of them) but as an industry, we’re going to have to move past this somehow.

Testing on devices reveals all sorts of stuff that simply adjusting content never will, and that you won’t see by simply testing by resizing a desktop browser.

  1. Without device tests you know nothing of a design’s performance. Most modern CSS effects and techniques still work quite poorly on devices. Web fonts, CSS drop shadows, CSS gradients, CSS animations regularly grind sites to a halt (quite literally…that’s if they don’t crash the browser altogether). Testing on devices provides a reality check of just how far you can push the design and what range of devices it will work on. Sure some of these issues will improve due to better hardware but PCs are pretty advanced and we’re still building poorly performing desktop sites…i’d love to see those go away as well).

  2. Device capabilities (e.g. actual capabilities vs the boolean ‘pass’ the browser returns in a JavaScript test) can also only be tested on an actual device. Whether you choose breakpoints based on ‘popular’ screen sizes or not, you will probably end up compelled to use a 320px breakpoint simply because of the iPhone. At this size also sit older (often landscape orientation) BlackBerry devices, many Nokia feature phones and many brand new small, cheap Androids. This throws all sorts of varying capabilities into the mix at what appears to be a very safe, common breakpoint. Eventually some of these devices will go away but if you believe screen sizes will standardize, then it follows that within those common screen sizes there will always be some bleeding edge AND some older or ‘good-enough’ devices.

  3. Then comes form factor. It often feels as if new devices only support touch, but at least 30% of smartphones (and closer to 90% of feature phones) still have a keyboard (while others are both touch and type). There is no sign of this changing soon as a touchscreen greatly impacts a device’s bill of materials and a segment of users still prefer physical keys. The presence of any indirect manipulation control (be it keyboard, trackball, arrow keys etc) impacts how interactive elements behave and should be designed.

  4. Pixel density now ranges from about 150 to about 300 ppi. That’s a massive crazy difference. Testing on a desktop reveals nothing of this. Many OEMs have reset the browser viewport to preserve legibility but you still end up with all sorts of differences that should be considered in the design process.

  5. And finally comes the impact of the network. Latency is obviously a problem, often due to poor connectivity – but factors such as large numbers of concurrent requests from 3rd party services (Facebook widgets, hosted fonts etc) will also impact performance. Of course content itself may also be modified on many networks by server-side ‘tweaks’ and adaptations due to proxies, transcoders and related ‘optimisers’ which are all beyond your control.

Just to be clear, content-out design makes a lot of sense, but we’re going to need a mixture of content, device, and capability-based breakpoints going forward. The only way to develop a good understanding of these factors is to truly begin experimenting with devices, just as we experiment with design.

These devices (and ones we haven’t thought of yet) aren’t just a temporary diversion, they are the new ingredients of the web just as much as HTML5 or jQuery.