Mobile is just the beginning

The ‘trouble’ with Android

I’ve noticed that Brad Frost (and others) keep resurfacing this old Tweet I posted a while back.

There is no “mobile WebKit” & there is no “Android” http://yfrog.com/ob5kndj snapshot of 500 Android screen sizes on EU site #fftweet #ffly

The screenshot in the Tweet looks something like the image below, and reflects the vast number of Android screen size variants within a client’s analytics.

This client of ours isn’t unusual. They are UK based and their audience reflects a wide cross-section of consumers. If anything, the audience probably skews a bit older (and therefore if you believe the stereotypes) less likely to be experimental with new technologies. So why the incredibly wide range in Android screen sizes?

What we in fact are seeing is a classic case of unintended consequences. In this case, the consequences of a wide ecosystem coupled with some of Android’s more user-friendly design decisions.

The first culprits are embedded web views—browser views embedded within apps such as Twitter or Facebook, enabling users to consume links and content without ever leaving the app itself. These views often incorporate their own chrome which results in slightly smaller (or at the very least different) dimensions than the native browser. The number of apps using web views for this purpose is huge and (although I have no specific stats to back this up), I wouldn’t be surprised if a sizeable chunk of mobile traffic currently originated within web views (especially given that top social sites such as Twitter and Facebook already receive 30-50% of traffic from mobile).

But this is only the half of it. On Android specifically, a series of personalisation and accessibility settings further contribute to screen size diversity. The most disruptive setting by far is Zoom Level. This manual setting (found within the browser in Settings) enables users to reset the viewport through generic settings such as Far, Default and Close. What these terms map to will vary, but common widths include 240px, 640px and whatever Default size has been enabled (often, but not always 320px). If that wasn’t disruptive enough, manufacturers can alter which zoom settings are available, or create their own. On the Kindle Fire for example, screen widths in portrait mode (at various Zoom settings) range from 450 to 800, with a whopping 1540px width in landscape mode using the Far setting.

And as if that weren’t enough, screen size can also change through the browser’s handling of viewport size on reorientation. Most mobile browsers (including iOS Safari) natively adjust the viewport in landscape mode to improve legibility. Combine this with differences in chrome height at each orientation, and you end up with even more unanticipated screen sizes. The Kindle Fire is for example 600 x 819 px in portrait orientation, but 1024 x 395 px in landscape, in this case due entirely to changes in chrome.

(Note: I’ve used the Kindle Fire as an example because I have it on hand but these tests can be replicated on just about any Android device. None of this is new. The Zoom setting has been there since version 1.6 but there is now simply far more diversity, so what initially appeared to be a quirk, is now a full blow well-distributed characteristic of a platform with over 550,000 activations per day. Even more important, while these features may annoy us, they remain useful additions to a well-evolved platform, so should be considered features rather than bugs.)

Nonetheless, this wide range in screen sizes has all sorts of unintended consequences. On responsive web sites, a change in Zoom Level can trigger a media query. (I say ‘can’, not because it doesn’t always work…but because a media query may simply not exist to match that breakpoint). Depending on the device implementation, an Android may therefore have anywhere from 3-6 actionable screen sizes (3 zoom settings x 2 orientations), spanning multiple media query breakpoints, including breakpoints we typically presume to be ‘tablets’ and smaller sizes that will be completely missed if structuring a style sheet ’320 and up’ to suit the iPhone.

If instead, you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and adjust layout dimensions dynamically to suit user-configured settings or serendipitous conditions is just asking for trouble.

And finally, if (as we likely all are), you’re using screen size to determine how heavy a site should be, this is yet another example that screen size reveals nothing of circumstance, context, or intent. Maybe from now on, all sites should be lightweight, not just the ‘mobile’ ones.

33 Responses to “The ‘trouble’ with Android”

  1. Terence Eden

    Great post – thoroughly agree. What stumps me is why people do this in the first place.

    In the bad old days when I was creating layouts for Windows Apps (we used to call them programs…) we never assumed what size or shape the user’s screen was. Even if we had known the resolution, the user could have resized the window, scaled their fonts, or done any of a dozen things to change the layout.

    Then when we started playing with the web – the rules were the same. Assume that your user was going to fiddle with their preferred CSS, or at the very least resize their window.

    When did programmers get so lazy?

    I know that designers tried to use Flash to create the same static, inflexible layouts they had in print magazines. But surely even they have learned their lesson?

    I suppose that’s the genius of Apple. Pander to the disinclination to do the right thing in favour of the fast and easy thing.

    Reply
  2. André Luís

    Damn. We always knew that relying on screen size only told half the story. But while half is better than none, that’s still an infortunate fragmentation. One question: even if there is a viewport meta tag, will the “zoom level” option still kick in and affect media query breakpoints?

    Well… regardless of that, NetworkAPI [1] or something similar can’t come soon enough. ;) That’s for sure.

    [1] https://wiki.mozilla.org/WebAPI/NetworkAPI

    Reply
  3. steph

    @andre luis
    The behaviour definitely occurs if the meta tag has been set to ‘device-width’ (which is what we always recommend clients do). I’m not entirely sure what happens if you are reseting the meta tag dimension dynamically however, if the user has specifically set a different size, it would be quite disruptive for the developer/designer to override it. On certain devices (Kindle Fire and some other Android-based tablets), i’ve noticed that the Default zoom level is in fact pretty ‘far away’. The Close setting works way better so I for one would be very annoyed if I couldn’t reset this due to a meta tag setting.

    Reply
  4. Michael Sullivan

    Very interesting article. What are the implications of this for device databases? From the article it would seem to make them even less reliable…. and a good reason to adjust media queries and make sure that lower-width css is all percentage based.

    Reply
  5. steph

    @michael Yeah…i’ve been thinking about that.

    What we’ve been doing for some time is using the device database for the stuff we can’t get anywhere else, or the times when you know nothing about the device (…which always occurs on the very first load). We then complement this with what the device tells us about itself. So in this way you get the best of both worlds. You can make intelligent choices right away, without the need to do a roundtrip on first load, but you can also adapt things on the fly if the user changes a setting or reorients the device.

    All that said, there are still some very flaky bits to all of this. I’m about to post a follow-up article about the new Ice Cream Sandwich OS that introduces even more complexity that I’m just beginning to consider the implications of.

    And I agree…we don’t design anything with fixed values any more. They’re just not worth all the workarounds you will need to ensure they behave gracefully on a wide range of devices.

    Reply
  6. Jason Arnold

    I totally agree, this is the fragmentation problem you get with a wide ecosystem like the android from the standpoint of different device dimensions. iPhones also see the same issue with applications such as Facebook and Twitter. I think the time of device databases is slowly but surely coming to an end, people just don’t realize it yet. The problem device databases now face is not only must they keep track of every device but they must also be aware of the major applications running on specific devices too. Now that many applications are themselves custom browsers, device detection provided by things like DeviceAtlas will need to also store application information (at least the major ones). As a real world example, when YouTube rolled out their recent redesign it work great on my iPhone browser and I got the mobile view. However, when I would click on YouTube links in either my twitter application or facebook application I was taken to the Desktop view where I was promptly shown the Adobe Flash player instead of the HTML5 view normally present in my iPhone Safari view. They have since fixed this issue, but it’s a good example of how we need to be building websites with flexibility in mind.

    Reply
  7. Jason Knight

    That’s why even THINKING about a specific fixed width is a STEAMING PILE OF FAILURE AT WEB DESIGN, even with media queries.

    It’s called fluid or semi fluid, USE IT. If you have layout elements that don’t fit fluid or semi-fluid layouts, they are non-viable for web deployment and should be thrown away… there’s a reason I call it the “But I can do it in photoshop” idiocy.

    Reply
  8. @keithdoyle

    I wouldn’t write off fixed-width designs. On a desktop browser, the page padding can be fluid and the content area fixed. See http://www.zeldman.com as an example of this. On a mobile device, no matter how fluid the layout, it appears fixed-width to the user. Besides, those of us who use graphic designers need to give them some sense of what width to work with. And when I’m prototyping in the early stages, I’m not going to mess around with fluid layouts in Balsamiq or Axure.

    The more important issue to me is that the web developer community is engaged in a dialogue with user experience professionals, graphic designers, and browser / device manufacturers. We need a more consistent implementation of flexible / responsive designs which are user-friendly, give confidence, and encourage browser & device manufacturers to support user-experience standards.

    Thanks for the post – looking forward to the ice cream!

    Reply
  9. Mike Dallwitz

    “I wouldn’t write off fixed-width designs. On a desktop browser, the page padding can be fluid and the content area fixed. See http://www.zeldman.com as an example of this.”

    Yes. And see what happens as soon as you make the window width less than the width of the content.

    Reply
  10. Evan Wiener

    First generation web designers mostly came from a print background, which has a finite canvas, so many of us leaned toward fixed widths once CSS was available. Liquid or fluid layouts work well for sites that are primarily content and marketing sites, but I find many trade-offs with fluid CSS grids when applied to web applications. Some UI elements must be placed with precision based on proximity and context to other elements and allowing them to be dynamically moved could cause problems. Many designers and clients are still learning what it means to design for a viewport with an infinite 2-dimensional canvas with 4-dimensional content.

    I don’t find elastic layouts valuable on large desktop displays or high-denisty laptop screens, since they are used most commonly for having multiple application screens open, with browser windows sized to only a portion of the device screen. The pixel density is increasing on laptop displays and we’re probably just a few years away from super high-density laptop screens requiring resolution independent UI elements.

    Why are Android devices sized so wildly? Android device makers are competing for consumer attention amongst themselves and screen size is the most visceral difference in a phone retail store display. General consumers barely know the meaning and value of internal hardware specs being marketed to them. The context of what they mean for the user experience is barely communicated in any valuable way, but screen size is obvious to anyone with eyes or hands.

    Reply
  11. Régis Kuckaertz

    According to what some comments may infer, it may be worth to clarify what responsive design is and is not:

    * RD is not fixed width. It is all built using %-based horizontal dimensions (i.e. fluid grids) along with flexible images and media queries.

    * RD is not designing for specific screen size. Let me nuance that: it is designing for specific screen *ranges*. The difference is subtle but fundamental. It is up to the designer to choose which ranges make sense, “320 and up” is just one example out of virtually an infinite array of choices.

    * RD is not designing for specific screen size (2). As mentioned above, RD uses media queries, that means any property a media query can test can serve as a basis for a design. Pixel ratio, screen size, screen aspect ratio, orientation, etc.

    * RD is not being lazy at all. Actually, it is quite the opposite because of the added work at each stage of the design process (content, IA, visuals, interactions, et al).

    In the end, RD is all about providing the best experience under various circumstances, making the content readable and interactions easy depending on the context; something other techniques can’t do at all.

    Although the technique is still in its infancy and there are problems that need to be solved, it is undoubtedly the best solution to design websites if you care about your content. Think about it as liquid layouts on steroids. The difference between the two? Liquid layouts fail to make content readable in many situations: large desktop screens and small smartphone screens suffer of extremely bad typesetting. Responsive designs fail in just a few situations: those that the designer did not account for. The latter can be accomodated rather easily: just look at the stats and evolve the design accordingly. The former cannot.

    Finally, I don’t think Apple decided the iPhone/iPad would have only one size because it would bring fixed-width designs back to the table, but rather because the design of the device takes human factors (e.g. hand/finger sizes and motion capabilities) into account as well as a slew of other strategic factors. Android cannot do that because it does not control the hardware obviously.

    Very good article, I think it surfaces one important problem that just needs to be addressed. Nothing insurmontable with a responsive design. If you think about it, that a website should work in all circumstances has always been a myth: things like page/text zoom and screen magnifiers always break something at some point, technology itself has its limits.

    Reply
  12. Vlad Gleba

    I think responsive design is a brilliant solution to a tough problem: finding a way to provide as much users as possible the best experience possible. It is not the only approach, but it is an approach that will move the web forward.

    Reply
  13. Craig

    If you continue with fixed width sites, that actually helps in this situation. People can pinch and scroll. What’s the problem? They can’t expect a large site to condense into something sensible on a tiny screen. It’s just not the same experience, not even close. If you try to please all the people all the time, they won’t learn and won’t be pleased.

    Reply
    • Bridget Stewart

      Pinch/zoom only works if the user scalable setting is not set to none or 0. If that setting is activated, pinch/zoom doesn’t solve anything. Granted, that setting isn’t “on” by default, but I have still tried to use “desktop content” on my handheld device that was unpleasant to experience if I had to zoom into the content and then scroll horizontally in order to read it.

      Just as an example, look at this on your phone: http://www.android.com/us/developer-distribution-agreement.html. That hurts me. :)

      Reply
  14. Mobile Baby Steps | Kristofer Layon

    [...] Zeldman started a great conversation about mobile web design. He noted some gnashing of teeth by Stephanie Rieger and Marc Drummond, who were lamenting the many challenges in designing for the range of Android OS [...]

    Reply
  15. Blake Meike

    This is a really interesting article with lots of good points. One of the most interesting things about it, though, is that it seem to be written from the point of view of a developer/designer who wants to control, absolutely, the appearance of the screen on *my* phone. All of those knobs discussed here? They are things I can use to adjust browsing so that it looks the way *I* want it to look. That may be a trouble for you, but I like it!

    Reply
    • steph

      I’m hoping my sarcasm slipped through into the article’s title…maybe it didn’t. :-P Some call these bugs. I see them as features (albeit challenging ones from a design and development point of view). Someone (I think in The trouble with Ice Cream Sandwich) comments suggested that you can’t please everyone, and that users may not want all these features but i’m not so sure we should dismiss them so quickly just because they are inconvenient (to us).

      Reply
  16. The “Trouble” with Android | Links

    [...] The “Trouble” with Android takes a look into many different screen configurations available on Android devices and is further proof to why designing for a certain sized screen is synonymous with shooting yourself in the foot. [...]

    Reply
  17. Michael Kozakewich

    This is an old thread, but I wanted to chip in since it’s near the top of the Google results on the topic. I’ve got the Note II, with its beautiful 5.5″ HD screen, and so I’ve used the advanced debug settings (visit “about:debug” a few times to make it show up in your settings) to make the experience more desktop-like.

    What I’ve found is that, with the default settings, the viewport is set to whatever size based on your default zoom, but allows you to zoom out on big sites even if they’re bigger. If you turn off Wide Viewport, the default zoom will just become the maximim size and if you zoom in the page will re-render around the new smaller dimensions. For example, this site (it’s well-designed!) reflows nicely with no horizontal panning needed and is probably at about 300px wide. Large fixed-width sites, though, render bigger than the viewport and I’m not allowed to zoom out to see it all.

    I guess the reason I’m posting this is that I recognise the issue is caused by the default zoom level, which sets the maximum I can zoom out. I’m looking for a way to increase that, because frankly even if I set it to 3000px or something silly, I could still zoom in to refactor the page. With Wide Viewport turned off, that number just sets the maximum amount I can zoom out, and that’s about it.

    Reply

Leave a Reply

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

Subscribe to this comment feed via RSS