Strategies for choosing test devices

27 Replies

It’s been great to see a conversation developing around how to acquire test devices and  how to do so on a budget. But once you have a budget in place, how should you spend it? What makes a good test device, and why should you pick one device over another?

Most people naturally start with two criteria…popular and cheap. Popular is good because it’s (hopefully) representative of devices in use by the general population. Cheap is good for obvious reasons, but are those really the best criteria? When choosing devices, we’ve found it helps to consider a variety of factors.

1. Existing traffic

Often, teams begin a device collection (and later expand it) to suit the requirements of a project. This is great because it bases the decision on real-life data, and as a bonus, the project forces you to really get to know the devices you’ve purchased. So the first thing we recommend is to look at existing client traffic (if some exists). There’s no point ignoring browsers or devices that are already hitting your/your client’s site in significant numbers. And if you already know you need to buy an Android 2.3 device, you may as well choose a model that is frequently accessing the site. While it’s not uncommon to see a long-tail of 300-500 devices in your analytics, it often follows a classic 80/20 pattern. Focussing on the 20% of devices that produce 80% of the traffic is a great way to begin.

Be aware however that analytics can be deceptive. Many packages are still JavaScript based (or will at the very least provide this option as the default) so may not report traffic from devices with poor JavaScript support (…and will of course completely miss those with no JavaScript support). Even in the US and Europe, you can greatly increase the quality of your analytics results by choosing a server-side package such as the ‘mobile’ version offered by Google. On a recent project we convinced a client to switch and in less than 10 days doing so doubled the size of our Google Analytics devices list.

2. Regional traffic and market

Next, review overall market share and traffic in your region (or the regions you operate in) so that you can focus on the platforms that are most likely to access the site. If 80% of your traffic is from the US and Europe, there’s no point for example prioritising Symbian, but you will need to do so if your customers are primarily in APAC (or almost anywhere else). The information you glean from this step will often reinforce the data in the analytics from step 1 (and if it doesn’t…that’s always an interesting realisation).

Good sources for this type of data include the Global Mobile Stats page from MobiThinking, Statcounter’s mobile browser stats and the regular releases of market share statistics published by the likes of Comscore and Nielsen (although these will often be US only). Jason Grigsby has also compiled this huge list of sources.

Where possible, try to also review platform version statistics as new devices don’t necessarily come with the newest OS and users won’t always upgrade (if that option is even available to them). Your analytics package should be able to provide some version data, and regularly updated platform version stats can also be found on the Android and BlackBerry developer sites. (Apple sadly does not release these statistics but data released by native app analytics services such as Flurry can often provide an indication of platform version popularity).

Based on these first two steps, you should be able to devise a list of candidate devices/browsers while also eliminating devices that are completely unrelated to your market or product conditions.

3. Device-specific factors

The next step is to map this device list against the factors that make a good test device. This will help you pick the most useful models rather than simply opting for the cheapest (or sexiest) on the list. A great resource during this step is Device Atlas’ Data Explorer (login required) which enables you to query common device properties across thousands of devices. Another useful tool is GSM Arena which includes comprehensive (consumer-facing) device specifications, a robust advanced search/filter option, and a popularity meter providing a glimpse of the interest level for each device.

Here are the device-specific factors you should consider:

a) Form factor: Touch screens are increasingly popular but a good 30% of smartphones also have a keyboard, trackball or other indirect manipulation device so you want to make sure to test on multiple form factors.

b) Screen size: This is obviously a big one. You want to ensure you can test on a range of representative sizes (and orientations). Android devices are particularly handy as you can easily spoof the default viewport size by adjusting the Zoom Level. This is a great stop-gap if you only have a few devices on hand.

c) Performance: Devices vary greatly in CPU and overall performance (including factors such as quality of touch screen) so you want to ensure you don’t simply test on only really high or low-end devices.

d) DPI: Screen dpi also varies quite a bit and can greatly impact legibility. Although it’s hard to mitigate against poor dpi displays, testing on such devices can be hugely useful to get a feel for the many ways your site will look. And sometimes, a small tweak is all it takes to improve legibility on these displays while still maintaining a good balance for everyone else.

e) Screen conditions: This is also one that you can’t do too much about, but is good to keep in mind. Screen condition factors can include overall screen quality (which impacts sensitivity to touch input), variations in colour gamut, and the ability for users to adjust contrast. In general, the cheaper the displays the more potential for this type of variation. (Oddly however, some super cheap devices have a nicer display than more expensive ones…it’s all about where and how the designer chose to differentiate the product).

4. Project-specific factors

Next you want to double-check the list matches any project specific factors. If for example, you app revolves around “things that are nearby”, it’ll likely be important to test various flavours of geolocation implementation.

5. Budget

And of course, rounding this out is budget. In many cases, this will remain a primary consideration but following the preceding steps should enable you to better justify each purchase and convey to stakeholders the value of testing on each browser or device.

One OS, many flavours

Remember as well that there is no such thing as “testing on Android” or “testing on an iPhone”. An iPhone with iOS 5 is a different beast from one with iOS 4.3.n (or one where your user has installed Opera Mini). Be sure to track the OS versions found on your test devices, and think carefully each time you upgrade. Owning four BlackBerry devices with four different versions of the OS is infinitely more valuable than owning four with the same version.

And in the case of Android (…and I presume eventually Windows Phone), we also have the added layer of complexity that is the OEM. Owning five MotoBlur variants of Android is also not as useful as owning five Android devices from multiple manufacturers.

So ideally, you want to end up with a collection of devices that is representative of your audience, of overall market share, but also diverse in multiple ways. Something like this:

  1. iPhone 3GS, iOS 4.3.n, 320 x 480 px (no retina display)
  2. iPhone 4, iOS 5, 320 x 480 px (retina display)
  3. iPad, iOS 5, 1024 x 768 px (10″ tablet, no retina display)
  4. Android 2.1 – Motorola, 480 x 600 px (popular)
  5. Android 2.3 – HTC, 480 x 320 px (QWERTY)
  6. Android 2.3 – Huawei, 320 x 480 px (low CPU)
  7. Android 3.0 – Samsung, 320 x 480 (low CPU, low dpi)
  8. Android 2.3.4 – Kindle Fire, 1024 x 600 px (7″ tablet, proxied browsing)

And then…?

Once a site is launched, repeat the steps in this article every 3-6 months to ensure you keep abreast of changes in your traffic. This is a useful exercise even if you have no budget at that point. If you suddenly discover unexpectedly high traffic from a new OS or device, you can always use emulators to fill this gap. (As a general rule don’t bother rushing out to buy brand new models as it can take 3-6 months before you see any significant traffic from them).

And be sure to keep an eye out for edge cases that have the potential to become wildly popular. The Kindle and Kindle Fire are my favourite edge cases of late. They are cheap, popular, have a large screen, a good browser, but are in many other ways underpowered.

If all this seems a bit daunting, remember that it’s not that different from other types of decisions that rely on combinations of knowledge and experience. Kind of like when you first learn to cook Thai or Indian food, and have to stock up on spices and ingredients. If you try to do it all at once, the choice seems endless and it’s overwhelming. But after a while, you get to know those things you just can’t do without, what quantities you will need, and what goes well with what. You also learn when it’s safe to improvise.

Despite the seemingly crazy variety, acquiring test devices is not that different. If (as many smaller agencies do) you commonly/primarily build for one region of the world, you will quickly get to know the range of devices you need. You’ll also develop a list of “things you wish you had” and another of “things you have enough of”. All this will make the next round of testing easier and will help you prioritise when a bit of budget comes your way.

Phones are one thing…but what about the zombie apocalypse?

The future is admittedly a bit fuzzy but I think designing for (and testing on) phones will prove a useful transitionary stage. Diversity is on the rise and companies are working hard to release products that certainly qualify as complete edge cases today. Many of these products will (I hope…) take a good 3-5 years to become mainstream. These include  fridges, in car displays, devices that pair or share displays with unrelated devices, or maybe even contexts where there is no (visual) display at all.

How we will test for these contexts is less than obvious, but that’s also why we should very soon expand the conversation from the “how” of acquiring devices to some possibly larger questions.

Barring the obvious “does it work” factor, what is the role of testing in determining if a web product is fit for purpose (let alone “a great experience”)? How will that role have to change as design and functionality are further decoupled from a fixed screen or capabilities context? And how will we determine a pass or fail once the ‘experience’ and ‘device’ are no more than just an aggregate of random user agents chosen by the user.

Maybe in the future, our users should determine a pass or fail. (Maybe they already do….)

Viewports all the way down…

9 Replies

Bryan has been experimenting with the new  iBooks Author tool.

This morning, he created a random page. On it he placed an HTML (dashcode) widget (which is basically an embedded area containing HTML). Within that widget, he included a link to the Yiibu site. The whole thing took about 2 minutes.

Here’s what happens when you tap that link.

The Yiibu home page loads within the widget…within the iBooks page. This view is of course chrome-less, but still smart enough to launch (live) URLs and render the resulting content pretty flawlessly. And if that content happens to includes a hyperlink, you can load yet another page into the space occupied by the first. (If not for the lack of chrome and any ability to scroll…it’s basically a small custom browser).

Quick tests reveal a (slightly) different user agent string and dimensions that appear to be an aggregate of the native browser viewport, and that specified by the pixel dimensions of the widget we’ve embedded.

The entire exercise took five minutes. We didn’t need a developer account. Only a Mac, iBooks Author and an iPad.

The past few weeks have seen several conversations around diversity and fragmentation. A fair number of people feel that mobile browser and device fragmentation are “unsustainable” and that when it comes to properties such as screen size, “supporting leading…breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports”. In other words this is all temporary and more importantly, it’s something we can all start to affect through the way we design.

I understand the roots of this sentiment but i’m just not sure it will play out that way. Here’s the deal. Your grandma can now create a viewport. And so can the kid next door. These may not be ‘proper’ browsers, and they may not (yet) be fully interactive, but they can load a pretty sophisticated web page. A year from now, the most popular ‘browser’ may just be be the embedded web view full of ‘related’ links in a Stephen King iBooks bestseller.

Diversity isn’t going away. It’s about to get worse. Ignore it at your peril.

An introduction to the Yiibu Profile tool

3 Replies

We’ve recently been seeing interest in a little toolkit we developed for combined server-and-client-side device profiling. This little script constructs a device profile, (derived from multiple sources including the device itself) and makes this profile available right on first load. This profile can contain everything from ‘standard’ properties such as level of SVG or HTML5 selector support, but can also contain custom properties specific to your project. This profile can then be used as the basis for conditional asset loading or client and server-side adaptations to images, components and even content.

We first introduced Profile in 2009 on the Yiibu site, spoke about it in Muddling Through the Mobile Web, discussed it in more detail in Adaptation, and have now used it and adapted it for several projects. Profile has evolved a lot from the first iteration but still needs a lot of love. The reason we’re pre-releasing it today is that the conversation seems to recently have shifted. Thanks to projects such as Luke’s RESS (Responsive Design + Server Side Components), the community now appears willing to entertain using the server to expand the possibilities for adaptation.

So if you find this interesting please take a look. We’ve uploaded a user-facing Profile inspector that can be quite handy during device testing, but you can also download the full Profile source on GitHub. There is currently no formal documentation but our Adaptation slide deck explains the high level concepts. Expect *lots* of bugs (we weren’t planning on releasing it for a few months yet), but also expect things to evolve over the coming weeks.

Enjoy! (…all comments are most welcome…including criticisms of why the Profile Inspector looks rubbish on an iPhone at the moment :-) )

A plea for progressive enhancement

59 Replies

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.

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

8 Replies

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

The ‘trouble’ with Ice Cream Sandwich

7 Replies

I really feel I must write a follow-up to yesterday’s post given that i’ve just spent the morning playing with the Galaxy Nexus, Ice Cream Sandwich, and the new Chrome mobile browser.

Honestly, if you had any illusions of micro-managing the web experience on devices, this new OS and browser will make you cry. Here are some initial highlights of the new browser settings:

  1. Request Desktop Site is a lovely (prominent) little option that lets users request the desktop version of a site they are looking at. I presume Google simply switches to a known non-m.dot/.mobi/mobile/touch/iphone site (elegant how we name these isn’t it?). As you can imagine, if the site is responsive this option does absolutely nothing. Logical when you know what’s going on underneath, yet pretty confusing for users. Your responsive site will appear broken…even though it’s technically not. Not sure how to handle that one…
  2. Then come the Accessibility features! These are really quite awesome (for users…maybe not so much for designers and developers…can you feel a trend here)? These consist of all sorts of well thought out and (so far) well implemented settings. My favourite so far is Force enable zoom which enables users to “override a website’s request to control zoom behaviour”. I haven’t tried it yet but I presume this means overriding any custom viewport meta tag settings which prevent sites from auto-zooming at landscape mode. End result…you should now presume some users will see the width they want to see, not the one you’ve optimised/designed for.
  3. The old Zoom Level settings (the ones I mentioned in yesterday’s article) are still there, but they are now in the Advanced settings panel.
  4. To augment the zoom levels, we now have a cornucopia of alternate settings such as Text Scaling, a lovely slider with a default of 100% and a range of 50-200%. Then there is the Zoom on double-tap slider, enabling users to control how much the content will zoom (i.e. it no longer appears to simply fit to screen on tap…it can zoom at different increments, which can result in content pushed horizontally off-screen, even on a mobile site).
  5. Not to be outdone we also have a Minimum font size setting (OMG!!) ranging from 1pt to a whopping 24pt. I’m not sure what the default even was (10 or 12 maybe?) as i’ve already adjusted it and there is no implicit default for these types of things…you just go with what ‘feels’ right (especially as they’ve labelled it points, not pixels, ems or percentages).
  6. There is also a Save for offline reading option (was this there already?) that does exactly what it says, and in the process disables most real-time behaviours such as those triggered by JavaScript, hyperlinks, and even in-page anchor elements. The document becomes so static, it may as well now be a PDF…until that is, you hit the magic Go live option which brings it back to life with a subtle page refresh (you almost expect to see those animated stars that Tinkerbell used to summon up in old Disney cartoons).
  7. There is also the usual handy Load images setting (now quite prominent as one of the few things in the Bandwidth management section).
  8. And finally, to make the brand managers quiver there is a Contrast setting (which currently seems to be disabled)…just in case you really need to see those brand colours in super high or low contrast.

When all is said and done, users have totally won this time around. They can now adjust and control just about everything related to the display of content on their device.  And why shouldn’t they? The challenge now for the industry is to find that ‘happy place’ where we learn to control far less while still offering much more.

The slow death of a (good-enough) smartphone

1 Reply

How long does it take for a device model to disappear off the shelves? Clearly, it takes quite some time.

Last Christmas I watched an older lady buy three Samsung Tocco Lites at about £49 a piece. Given the cost and the time of the year, these may have been stocking stuffers for her grand children.

The Tocco was released in 2009, shortly after the now infamous Nokia “Tube” and was one of the many (pre-Android) first-generation touch devices. It sported a decent resistive display and a ‘first kick at the can’ touch operating system. While by no means advanced, it was easy to use, friendly and approachable. The phone included a so-so Jasmine browser (HTML 4.01, CSS 2, tidbits of CSS 3, basic JavaScript) and a collection of repositionable app-like contraptions on the home screen. I think there was even an app store.

So in other words, to the layman, it was (and still remains) a smartphone.

To be honest, by now I expected the Tocco to be history given the sheer number of £50-ish smartphones available at the moment (most of them running Android). And yet here it is again for Christmas 2011, this time for £39.95 (£10.50/mth on contract) sitting proudly side by side with the iPhone 4S, Galaxy Nexus and Galaxy SII.

In fact, I still see Toccos on the street on a regular basis. Developers (designers, product managers…) often assume an old phone must in fact be an “old” phone…just about to be replaced, when in fact, an old phone may be brand new to the person who just unwrapped it at Christmas.

Don’t presume that just because it’s old people won’t buy it. :-)

The ‘trouble’ with Android

33 Replies

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.