Left to our own devices

In the final part of his series on responsive design in .net magazine, Paul talks about testing:

The key thing to remember here is that any testing is better than no testing. Build up a test suite as large as you can afford, and find opportunities to test on other devices whenever you can.

I agree wholeheartedly and I think that any kind of testing with real devices should be encouraged. I find it disheartening when somebody blogs or tweets about testing on a particular device, only to be rebuffed with sentiments like “it isn’t enough.” It’s true—it isn’t enough …but it’s never enough. And the fact that a developer is doing any testing at all is a good thing.

There are some good resources out there to help you get started in putting together a collection of test devices.

• Testing for dummies is a great blog devoted specifically to testing responsive designs on mobile devices.
• Luke gathered a number of links to device arsenals on this Bagcheck post.
• Stephanie wrote about strategies for choosing test devices.

Actually, you should probably just read everything on Stephanie’s site: it’s all thoughtful and useful. In her post on the value of 1000 Androids she wrote:

The dirty little secret is that the more you test—the more accurately you will determine when it’s ok not to.

That’s crucial. I think there’s a common misunderstanding that testing on many different devices means developing for many different devices. Nothing could be further from the truth. Just as in the world of the desktop, we shouldn’t be developing for any specific devices or browsers. That’s why we develop with standards.

In fact I’ve found that one of the greatest benefits of testing on as many different platforms as possible is that it stops me from straying down the path of device-specific development. When I come across a problem in my testing, my reaction isn’t to think “how can I fix this problem on this particular device?”, which would probably involve throwing more code at it. Instead I think “how can I avoid this problem?” The particular device may have highlighted the issue, but there’s almost always a more fundamental problem to be tackled …and it’s very rarely tackled by throwing more code at it.

I wish I had more devices to test on …even if it might increase the risk of me getting reported to the police. At the same time, I realise that it’s a pretty crumby and expensive situation for developers, particularly freelancers. As Paul wrote:

Not only does it present a potential barrier to entry for anyone wanting to build responsive websites, but it encourages the purchase of yet more devices and gadgets.

I’ve been keeping my costs down by shopping in dodgy second-hand electronics shops that sell devices that have fallen off the back of a lorry. Most of them sell phones with a classification of A, B, or C. If something is labelled A, it is mint condition. If something is labelled C, there might be something wrong with it or you might not get all the cables or the box. But for my purposes, that’s absolutely fine. If anything, I’m usually hunting for outdated devices with older versions of operating systems.

So far I’ve got:

• An HTC thingy running Windows Phone 7.5,
• Another HTC thingy running Android 2.3.4,
• A little Samsung running Android 2.2,
• A Blackberry 9800 (Torch, right?),
• A Blackberry Playbook,
• A Kindle,
• An iPod running iOS 3.1.3,
• An iPad running iOS 5.something,
• And I’ve got my own iPhone 4 and Kindle Touch.

I don’t know about you, but my eyes glaze over when it comes to phone models and operating system numbers, especially when they just end up sounding like condoms. Luckily we’ve got people like PPK to help us figure out the smartphone browser landscape.

You’ll notice plenty of glaring omissions in my paltry list—there’s nary a Nokia device to be found—but I aim to plug those gaps as soon as I can.

In the meantime I’ve been setting up a desk at the Clearleft office for these devices so that they can stay charged up and within reach.

We’ve always had an open-door policy here, so if you want to pop around, use our WiFi, and test on our devices, you’re more than welcome. Give me some advance warning on Twitter and I can put the kettle on for a cup of tea. We’re at 28 Kensington Street, Suite 2.

Think of it as a quick’n’dirty, much smaller-scale version of Mobile Portland’s Device Lab.

Emmet Re:view — fast and easy way to test responsive design in multiple viewports

It’s no substitute for testing with real devices, but the “device wall” view in this Chrome plug-in is a nifty way of getting an overview of a site’s responsiveness at a glance.

Research with blind users on mobile devices | Accessibility

Some interesting outcomes from testing gov.uk with blind users of touchscreen devices:

Rather than reading out the hierarchy of the page, some of the users navigated by moving their finger around to ‘discover’ content.

This was really interesting - traditionally good structure for screen readers is about order and hierarchy. But for these users, the physical placement on the screen was also really important (just as it is for sighted users).

Perth Device Lab – An Open Device Lab brought to you by Humaan

This might be the most remote open device lab yet. Looks pretty great.

Twitter Blog: Overhauling mobile.twitter.com from the ground up

A great behind-the-scenes look at the redesign (and redevelopment) of Twitter’s mobile subdomain silo. Man, I would love to see this progressively enhanced up to the current widescreen view for “desktop” browsers without the need for separate URLs for any class of device.

But I digress …this is good stuff.

Setting up a mobile testing suite | words from Cole Henley, @cole007

If you’re based anywhere near Frome in Somerset, get in touch with Cole—he’s putting together a communal device testing lab.