This is vitally important people so listen up. The web now connects a third of our planet. Over 1.2 billion people [1] use the web on devices, and this number is rising fast. Mobile already amounts to close to 6.5% of web traffic worldwide, and large sites such as Facebook and YouTube routinely report mobile traffic of at least 30%. By 2015, the ITU predicts mobile traffic will exceed desktop traffic and the ‘mobile-mostly’ group already make up a staggering 20% of users in the US and UK.

For this ubiquity to truly benefit all of us (not just those of us with a high income, or the latest phone) we have to start building sites using solid, future friendly principles such as progressive enhancement…not just when it’s handy or simple, but all the time. Here’s a very timely example of why…

Last night Brad Frost posted a picture of the lovely sliding side menu contraption on Barack Obama’s new responsive campaign site. As shown in the image below, It looked quite nifty. You tap on the icon next to the word Menu, and the menu slides open from the left hand side. So I decided to try it out on my iPhone 4.

And the menu failed. Never even opened. Suddenly, the site was without navigation…at all.

On a hunch, I tried it on a handful of popular devices. The results were pretty devastating. These are the browsers (and devices) where the menu worked as expected.

• Galaxy Nexus (hot off the assembly line last week with Ice Cream Sandwich and a mobile version of Chrome)
• iPhone 4 (with iOS 5)

These are the ones where it didn’t.

• iPhone 4 (with iOS 4.3.5…the prior version of iOS)
• iPod Touch (still very popular, especially with youth)
• Nexus One (old but top of the line Google reference device in its day)
• Nokia Lumia 800 (brand new Windows Phone 7 device with Internet Explorer 9)
• HTC ChaCha (popular QWERTY phone with dedicated Facebook button and Android 2.3.3 )
• HTC Wildfire (very popular mid-range phone with Android 2.3.3)
• Huawei Blaze (brand new, £50 phone with Android 2.3.5 )
• Galaxy SII (top of the line device with Android 2.2.3)
• Galaxy Mini (cheap, low-spec phone with Android 2.2.1 )
• Blackberry 9810 Torch (one of their newest devices with WebKit-rich Browser 7.0)
• Blackberry 9300 (a slightly older 6.0 device with a WebKit browser)
• Galaxy Tab 7″ (first generation tablet with Android 2.3)
• Galaxy Tab 10″ (second generation tablet withAndroid 2.3)
• Amazon Kindle Fire (proxied Amazon Silk browser)

These devices are pretty new. With the exception of the Nexus One and the older Galaxy Tab, all these devices are for sale in the UK right now. Most are also for sale in the US. And at least four of these are top of the line, flagship devices for their brand. And to be clear, the menu wasn’t merely a bit flaky on these devices. It never opened at all (and this is a big, presumably important menu…with 20 sub-navigation items).

On all devices except the Galaxy Nexus, Kindle Fire, and 10″ Tab, at least a third of the content also loaded offscreen, resulting in a perpetual horizontal scroll. To make matters worse, the viewport meta tag had been set to ‘maximum-scale=1′ [2], preventing most browsers (and therefore users) from zooming to temporarily rectify the horizontal scroll issue.

We also tried the site on some lower end devices (70% of the US and about half the UK still use feature phones) but gave up. The site was too heavy and complex to render gracefully on many of these devices. (And incidentally didn’t load at all past the ‘splash page’ using Opera Mini on the iPhone).

This on a site whose goal was to reach as many Americans as possible, regardless of age or income level. As it stands the site only appears suitable for the Google staff who received a Galaxy Nexus for Christmas, and the maybe 5% [3] of Americans who own (and have recently updated) their iPhone.

I can’t speak to exactly what’s causing the menu to fail, but I can take a pretty good guess. I’m also fairly sure that a progressive enhancement approach (combined with a good dose of testing) would have solved (and certainly uncovered) all the problems we encountered. As a matter of fact, we’ve recently been working on a (still to be launched) client project with a similar (but far simpler) collapsible, sliding menu and went to great pains to ensure things like this didn’t happen.

First, we built the menu to fail gracefully. In this case, it meant building a menu that was open by default, and only closed once the page had loaded. If the JavaScript failed, the menu would simply never close. It might not look terribly graceful, but it would still be fully usable (to navigate…not to slide open and shut triggering fancy animations…that’s not the menu’s actual job.)

Secondly, we built the menu using ‘normal’ JavaScript rather than jQuery, as we’ve found jQuery still doesn’t work reliably across the devices we need to support [4]. We also tested the JavaScript based functionality all the way back to dinky, underpowered little phones like the Nokia N95. This served as a reality check and helped further minimise our points of failure. If it works on a 5 year old browser, it’s considerably less likely to fail on today’s devices.

And finally, we identified browsers with inadequate levels of JavaScript or DOM manipulation support and served an entirely different menu to this group. We swapped this out server side to ensure these devices didn’t receive the JavaScript at all, and newer devices didn’t have the client-side burden of negotiating the switch from one menu to the other. Incidentally, we also built the site ‘mobile-first’ (i.e. for the simplest device first…and no, that device is not the iPhone), so the ‘fancy’ menu doesn’t even kick in until you reach a screen size of 320 px (regardless of whether JavaScript may be supported). This may penalise the tiny number of devices that happen to be below 320 px in width, and have awesome JavaScript, but also minimises the chance that weaker, older devices will try to load the menu accidentally.

Despite all this, we still had issues, namely with general DOM manipulation flakiness and inconsistencies caused by device-specific events such as zooming, reorientation, or adjustment of Zoom settings (especially on Android…and especially on HTC). For this reason, we found that the calculations required to correctly trigger and execute the animation sometimes failed, resulting in an only partially open menu. So in the end, we removed the animation altogether (especially as this problem wasn’t limited to lower-end devices so it wasn’t possible to simply conditionally load the animation based on say…the browser version).

A final problem was the visual disruption caused by a menu that initially loads open, but then quickly closes. To be honest, we still haven’t decided what to do about this. This is a site with a strong accessibility (as in access…) mandate so the idea of shipping a menu that may sometimes never open doesn’t sit well with any of us. So we’re still discussing it. Given this site’s small proportion of traffic from low-end devices, and the measures we’ve taken to ensure the menu will work most of the time, we may still choose to chance it and go the other way.

These are complex problems. Problems that cause us to examine the true goals of what we’re building and very often greatly test our assumptions around the value of design. Even seemingly inconsequential decisions such as constraining the zoom level can have unintended consequences. But progressive enhancement doesn’t just happen. It needs to be planned from the start, then iterated and carefully discussed when things go wrong. And on mobile, the only way to know that things have gone wrong is to test on actual devices. Given that a good 80% of the Android devices we tested displayed content off-screen, we’d be surprised if barackobama.com had been tested on Android at all.

We have an opportunity to make the mobile web a million times more useful and relevant than the desktop web has been. The failure of the Obama site was not in the use of new techniques like responsive design, it was in forgetting that older principles and techniques still have an important role to play in building a better web. If anything, they are more important than ever before. Without progressive enhancement, responsive design is simply a site that looks pretty when you resize your desktop browser. With progressive enhancement, the mobile web truly becomes a tool, capable of reaching and connecting all of us. Which is it going to be?

—————-

[Update Jan 6: I'm happy to report that over the past 24 hours, the site has improved. The animated transition on the menu appears to have been removed. The menu now opens intermittently on my iPhone but during this time, the site is extremely sluggish. On the Android (we only re-tested 3-4 devices), as of this morning the menu opens, but the incorrect viewport is still a problem and now also impacts the menu which on some devices opens partially off-screen. Oddly, on initial load, the viewport is now correct, but within a few seconds it snaps into the wrong state. We'll try testing again next week.]

—————-

[1] A statistic from analyst Tomi Ahonen’s awesomely useful 2011 Phone Book.

[2] We’ve been getting reports of some people not seeing the max-scale value in the meta tag so did some further snooping. See my comments to Nicolas Gallagher below for details.

[3] 5% is an educated guess. Current Nielsen figures show US smartphone penetration at 38%. The iPhone is 28% of that 38%. The number of people with an iOS 5 capable iPhone is smaller, and the number who will have upgraded is smaller still.

[4] See my comments to Scott Jehl for additional context regarding use of on jQuery Core on mobile.

(…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.