Mobile is just the beginning

A plea for progressive enhancement

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.

77 Responses to “A plea for progressive enhancement”

  1. Terence Eden

    Although statistics around handset usage are subject to pretty big caveats, without a doubt the majority of people in the USA are not using smartphones.

    Neilsen reckon that ~40% of the installed base of US phone are smartphones.

    Now, you can argue about how many feature phones are regularly accessing the Internet, but, without a doubt, they do use the Internet.

    There is a trend for under reporting. Three main reasons for this.

    Feature phones don’t access the “big name” sites – they visit mobile optimised sites
    The major stats packages use JS to count visitors – which ignores simpler browsers
    They simply aren’t consuming as many MB as the smartphones

    As you’ve correctly identified, for a campaign which needs to target the majority of Americans – this falls well short of the mark.

    Reply
    • steph

      The stats packages are a big issue. When you say the ‘major’ ones…who do you count as major? Just curious as i’ve been meaning to write up some of our (positive) experiences with Google Analytics when using their server-side ‘mobile’ script instead of the Javascript based one which definitely under-reports.

      Reply
      • Terence Eden

        Google Analytics JS package is good – I’ve found the JS version less reliable.

        Omniture I found to be really poor at correct mobile detection.

        The largest problem for server-side detection is the use of CDNs and caching proxies.

        Reply
  2. Nicolas Gallagher

    You said that:

    the viewport meta tag had been set to ‘maximum-scale=1′

    But according to the source, this is their viewport meta:

    I’m pretty sure it has been this way since the redesign launched. So I’m wondering why zoom wasn’t working for you and if there might be another problem. And ideas?

    Reply
    • steph

      Sorry, your second code snippet was munched by WordPress. :-( Do you not see a max-scale=1?

      Reply
      • Nicolas Gallagher

        You should be able to recover the original comment in the WP admin area. But yeah, there is no maximum-scale set. The viewport on the site is this:

        <meta name="viewport" content="width=device-width,initial-scale=1">

        Reply
        • steph

          Hi Nicolas,
          We think they’re generating the max-scale parameter dynamically on the client. If you look at the response from the server, there is no max-scale

          <meta name="viewport" content="width=device-width,initial-scale=1">

          when you inspect it client-side in developer tools, you get this

          <meta content="width=device-width,minimum-scale=1,maximum-scale=1" name="viewport">

          …so it appears they are doing some sort of client-side adaptation to the viewport meta tag.

          Reply
  3. Ken Hood

    Menu also doesn’t appear on my Atrix 4G (running Honeycomb, using default browser). As far as zoom/offscreen issues go…I did notice a significant lag (over private wifi) in detecting and applying the correct width.

    Reply
    • steph

      Yeah..the lag was interesting. The poor HTC ChaCha took (no word of a lie) about 2 minutes to finish loading something or other. Until then, the page was somewhat in limbo from a width point of view. The fact that it took this long may also indicate they were trying to ‘manually’ detect and set a viewport size rather than just let the browser do whatever it was going to do. This could also explain why so many device widths were out of whack. If you simply keep things flexible, set the viewport meta tag to ‘device-width’, and dont try to override anything, it usually just works…out of the box so to speak.

      Reply
  4. Sylvia Egger

    I think it only depends on iOS – my now older iPod Touch with iOS5 has no problem to use the menu.

    And there is only initial-scale, no max-scale. I can scale the site on my iPod Touch. The problem is when the menu is open you don’t get the rest of main content – it’s kind of cropped. You can scale but you cannot reach the cropped content.

    But of course I think you are right. You get people to optimize on iPhone and Android – always the newest OS -, you get some to check with some other simulators – but that’s it. Mobile Development get’s often narrowed on a small selection and devices.

    Mostly one says “hey, look – the website looks quite good an iPhone and iPad” – and everyone is clapping. To get mobile more broadly we all have to progressive enhance ourselves. :)

    Reply
    • steph

      Hi Sylvia,
      You’re right about the iPhone/iPod touch. I can stil scale on those devices but on the majority of Android that we tested, we could not pinch to zoom the layout. See my response to Nicholas above for more details on what is happening with the meta tag.

      Steph

      Reply
  5. Chris

    As a developer it would be nice if devices like this would help us out with some sort of standard. I really dont want to be supporting 1000′s of different browser’s / versions of said browsers in the next 10 years. Its getting ridiculous as it is.

    Reply
  6. Scott Jehl

    Hey Stephanie!
    Interesting post, as usual. :)

    ” we’ve found jQuery still doesn’t work reliably across devices (in particular for tasks such as DOM selection)”.

    Would you be able to point us to the platform(s) where you’ve seen this? A jQuery Core bug report would be ideal, but at the least, I’d be curious to hear where you’re seeing DOM-selection (or other known) problems occur.

    Thanks.

    Reply
    • steph

      Hi Scott,
      I’ve revised my post slightly as it was implying a bit too much without the room or context to adequately clarify. I should write a separate post about this later as well.

      We’re getting to the point where we will likely start to use jQuery Core given that traffic has considerably shifted to Android where the support is quite good. Historically, however we haven’t been able to due to the need to support what you classify as B and C grade devices (in particular older BlackBerry and most Symbian), along with the general flakiness in early Android browsers. The way we see it, if we know we can make it work without jQuery (and will have to write the extra code regardless to support some devices)…why write it twice (and have to negotiate branching and conditional loading for certain browsers).

      As an aside however, mobile sites that use jQuery can still be very klunky. In particular on some of the lower-cost Android which are turning out to be quite popular but often just don’t have that same oomph (when combined with gradients, rounded corners, drop shadows and animations), or run an older version of Android even if the device is brand new.

      We may end up using jQuery extensively in a project we’re starting today actually and will in that case have the opportunity to test on 30-40 devices + browser variants. If so, we’ll document as much of it as we can.

      Reply
  7. Brian

    A hefty and important call to action; thanks for this, Stephanie!

    FYI: on the HTC Sensation, running WebKit 533.1, I got the same view as you showed for the Galaxy Tab in your visual, and the menu didn’t appear at all.
    It let me zoom in but not out…

    Reply
  8. Amy Stephen

    Really great article and very timely.

    You mentioned that you swapped the menu out on the server side for devices with inadequate levels of JS and that a screen size check of more than 320 px was used to assign the fancy menu.

    My question relates to the server side checking. What method(s) did you use to detect JS capabilities and screen size on the server side? A cookie? (If so, did you use Modernizr and force a reload on the first visit?) Or, was server side device detection used? Or, did you detect on the frontend and redirect to a separate mobile site/specific URL?

    This is such a challenging topic given that advancements in hardware are outpacing browser/server standards. I appreciate you sharing your experiences.

    Reply
    • steph

      Hi Amy,
      At the moment, we use a combination of methods to get around the fact that front-end optimisations can be quite taxing (and on some browsers won’t be supported) and the fact that on first request/first-load (i.e. before client-side detection can even occur), you know nothing of the device at all.

      The clearest explanation available can currently be found in two of our presentations: Adaptation: why responsive design begins on the server and (to a lesser extent) Pragmatic responsive design.

      Please feel free to post any additional questions :-)

      Reply
  9. James Pearce

    Spectacular as ever. Though I do suspect progressive enhancement for fully-featured apps is a different ball game to progressive enhancement for esoteric visual effects on a document.

    For example: the “how will this semantic markup work without JavaScript” argument becomes absurd when you’re talking about a complex application built entirely with, er, JavaScript. That’s not to say that applications shouldn’t be responsive to the capabilities (or lack of) of a device. But toggling on or off entire modules of app functionality – say, a social client that both does and does not provide a photo upload feature – is non-trivial engineering.

    (PS the argument that such applications aren’t the web would also be absurd ;-) )

    Reply
  10. Rose Weisburd

    Love it! Especially well put: usable (to navigate…not to slide open and shut triggering fancy animations…that’s not the menu’s actual job.)

    Reply
  11. ian homer

    Fascinating that eye-candy so often trumps accessibility and optimisation. Someone gets emotional attached to a sliding menu and has just got to use it at the expense to wide usability. Thanks for the write up, your clarity and concrete examples are always refreshing.

    Reply
  12. Shelly

    I have an HTC Evo, running WebKit 533.1. No menu for me either. Great post, great blog.

    Reply
  13. Jim Newbery

    Great post again, Stephanie, and so timely for me in at least three different ways :-).

    I would echo Amy’s comment and would love to see a detailed technical post at some point to accompany your description of developing a responsive menu. It seems to me that few sites have adopted a thorough RESS (Responsive Design + Server-Side components) approach because there are very few technical examples out there.

    Reply
    • steph

      Actually, that’s nice to know. We (yiibu) have been talking about server side adaptation for a while now but it’s never been really clear if the community was interested in this approach. Many people are currently focussed entirely on the client and consider a server-side approach too akin to ‘old mobile’ practices like UA sniffing. So to date, other than the detailed conceptual explanations provided in some of our presentations, we haven’t bothered to elaborate too much.

      If there’s an interest, we can find some time to put a more detailed explanation together. I suspect Luke will have some stuff to demonstrate soon as well.

      Reply
  14. Luc Desaulniers

    This post is so accurate. I am redesigning my company website with mobile in mind. Which translate in no Java and no Flash. Funny enough, even if I deal with a specialized mid size design firm, mobile is not in their priority right out of the gate. I had to insist.

    Reply
  15. Luiz Roberto Meier

    No problem, I can’t see any issue here only money to earn to make the things looks good in the right position. I hope to have tons of calls saying: my site needs an update. I’ll make money with that.

    Reply
  16. erin wells

    Any approach in life that leads to increasing complexity, in my experience, is an indication that we have chosen the wrong path. Good solutions tend towards simplicity, not complexity I think we are getting to the point where we need a technical reset on web technology. It has become too unwieldy and unnecessarily complicated!

    Reply
    • Kzqai

      I actually have to agree with that. If there’s a consideration of whether the technique will actually work right on – desktop – devices, that’s a “solution” that I would steer clear of. There are so many possibilities out there that going with a very complex solution and trying to make it progressive is kinda at odds.

      Reply
  17. Jerome

    I agree with you in theory but I think you made the picture worst than it is
    First I can get the menu on my galaxy s (website is slow to load in its whole but probably slow on a desktop too… too much in one page!)
    Second i think there are still a lot of content to access without the menu. enough for mobile i dare to wonder

    Reply
  18. Régis Kuckaertz

    Question related to jQuery: if the selector engine is all you want to use, why don’t you just choose Sizzle? do you have any experience with it, or any recommendation on a custom jQuery build?

    Reply
  19. Touch & prod websites | welcomebrand

    [...] larger agencies blogging about their latest project they’ve tested on hundreds of devices (be careful though -it’s still tricky). The pragmatic part of me knows that this is always going to an unrealistic thing for small [...]

    Reply
  20. Daniel Fris

    Great thoughts Steph! I have a hard time getting accurate data across mobile devices that are not in my physical grasp. How do you recommend access to a wider range of test devices?

    Reply
  21. Craig Sullivan

    Hi, another great article and an approach I completely support.

    We do a heap of device analysis to see exactly who’s attempting to use our sites (continually) and then focus test plans on them. We do device sniffing at network level for redirection first of all and then on the mobile site (m.safelite.com, m.autoglass.co.uk) we use 2 x CSS stylesheets to handle 97% of the devices.

    Yes, boringly enough, we sat down with a list and debugged using deviceanywhere (rent devices remotely – install apps, visit urls, use GPS, throttle speed) and crossbrowsertesting.com – this enabled us to crunch through about 120 devices, and it all works rather well. Page transitions are about 7-10Kb load and our google speed stats show the vast majority of people get <2 seconds for each load.

    It's not a classic responsive design but it is brutally focused on maximum audience reach. In the UK, US, Canada, for example, Blackberry devices convert higher than iPhones – for two reasons – many sites provide a lousy experience for blackberries and secondly, because it's hard to get right sometimes. The payback is that these visitors convert at a higher rate than iPhone or Android handsets, so it was worth our time being inclusive.

    I put all of our story of the UCD build, lab work, testing and outcomes into a slide deck here – hope you see why your writing resonates so much with my experience:

    http://www.slideshare.net/sullivac/mobile-presentation-sydney-online-retailer-26-sep-2011

    The sites may be small, fast and seemingly quite limited and simple – that's precisely what people wanted, and it works. That device focus enables the mobile website to take 5M a month – about 100x more than the app generates.

    Reply
  22. Alejandro rodriguez

    love your post! responsive mobile web is what I offer all my clients as basic. I just had when website are not working at 100%. I try my best to always test my websites out. they always work well. but I do remove some of the manor fancy stuff

    Reply
  23. マルチデバイスレイアウトパターン―Luke Wroblewski記事翻訳 | MobileFirst.jp [企業スマートフォン戦略の実践情報サイト]

    [...] しかし、それが複数の画面サイズに対応してレイアウトすることなのではないのでしょうか?それは、自分たちの選択肢を現在把握しているものに限定する場合に限られます。事実、レイアウト調整用のスペースは、表示画面上よりも、画面の外に常にもっと多くある、という意見もあるかもしれません。 上の図のように、マルチデバイス・レイアウト用のオフキャンバス・パターンでは画面の外のスペースを活用し、もっと大きな画面で表示できるようになるか、ユーザーがそれを表示させるようなアクションを起こすまで、画面外にコンテンツやナビゲーションを隠しておきます。このパターンは、各種のモバイルWebサイトのデザインやネイティブ・モバイルアプリケーションにいくつか見受けられます。 FacebookのモバイルWeb版では、表示ウインドウの左にあるスペースを使ってナビゲーションオプションを隠してあり、リンクをクリックして表示させます。そうすると、画面の外にあるコンテンツが横から滑り込んできて表示される仕組みです。同様のアプローチ(下記の例)を取っているレスポンシブデザインはいくつかあります。しかし、利用デバイスによってはアクセス面で難があるものもあります。 [...]

    Reply
  24. 多设备的Web布局模式

    [...] Facebook的移动Web利用了左边的空间,把导航选项隐藏在这里,直到有人点击链接展开它。在这时候,屏幕外的内容就展示在屏幕当中。有些响应式设计采用了相似的方法,但是其中有些遇到了可访问方面的问题。 [...]

    Reply
  25. Today’s Links | JohnAspinall.co.uk

    [...] relatively complex and opens the door to problems. As Stephanie Rieger points out in her post “A Plea for Progressive Enhancement,” Obama’s navigation fails on a whole load of mobile devices: “And the menu failed. Never [...]

    Reply

Leave a Reply

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

Subscribe to this comment feed via RSS