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.