Mobile is just the beginning

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

(…reposted from a lengthy comment on Zeldman’s blog…)

“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.

9 Responses to “On designing content-out (a response to Zeldman and others)”

  1. Patrick H. Lauke

    Wonderful, comprehensive reaction and summary. It’s great that, out of the discussion, we’re managing to crystallise some truths to help us shape the way forward.

    Of course, having a horse in the race ourselves (full disclosure: I work for Opera in the Developer Relations team, etc), I’d take “We are well on the way to standardizing around WebKit” with a pinch of salt, not just because of Opera, but also looking at Firefox/Fennec and the quite capable IE9 on WP7. And, to be honest, as we (the browser engines) are all moving slowly but surely towards a reasonable feature parity with HTML5/CSS3 (with obvious bleeding-edge features appearing first in those engines that propose the new additions to the living standard), and considering that “WebKit” itself is so fragmented, developers should still be able to code to the standard – with reasonable fallbacks for older/exotic versions of WebKit, and for other engines that may not have implemented feature X yet…basically, as they should already now anyway – without any major issues, unless they’re really going for the latest whiz-bang tech demo. Sure, there’ll always be differences, but even within the same rendering engine space there are wildly different interpretations and implementations of specific aspects of the specs, so the nirvana of “it’s all just standardised to WebKit” still wouldn’t, in practice, result in the hoped-for “write once, run anywhere” solution.

    Reply
    • steph

      You just had to go and mention that :-P

      I almost phrased it as “we may find ourselves lucky if we achieve webkit standardisation” but thought it would be a bit harsh and overtly pessimistic. I do agree that even the notion of a ‘mobile WebKit’ is causing confusion as people presume parity in support and features. The fact that most features only return a boolean ‘supported’ or not value when tested doesn’t help. Achieving feature parity amongst/despite competing rendering engines would be quite an accomplishment (and likely better for everyone in the long run).

      Until then we can console ourselves with the fact that most devices have standardised on a common USB charger/connector! That’s a start isn’t it?

      Reply
      • Dustin Wilson

        Scarcely 10-12 years ago we had a situation where one browser had nearly 100% of the market. The Web standards movement that followed was born out of the desire to get out of this morass of sameness and non-standards. Now it seems many of the same people are wishing for the old days of one browser for all again — at least one browser engine.

        Webkit is indeed fragmented, but there are problems that arise from using the exact engine in different browsers. Webkit deviates from standards especially with special -webkit CSS prefixes, and its bugs are becoming to many like IE bugs were in the past — believed to be the intentional behavior. Many browsers are considering supporting -webkit CSS prefixes; it’s quirks mode all over again. It is simply dangerous to wish for “standardization around Webkit”.

        Reply

Leave a Reply

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS