Web to mobile - Testing how well it will work

Lately at work, everyone's gotten back into actually doing the right thing and being multi-channel. At least a little. Like, "make sure it works on the iPad." Well, that's easy to me. There are several attributes to this, but a good, key one these days is touch target sizes. I was about to send everyone this very nice, concise writeup of General Touch Interaction Guidelines from the appendix of Designing Mobile Interfaces. Then it occurred to me it's almost too concise. I still run into many more people who design to pixels instead of real, human scales, for example. So, I wrote up a longer explanation of how to do some of this basic validation. And as usual when I develop something not totally secret, and which I haven't shared before, I blog about it.
Assuming you are validating a design that is not exclusively built for mobile capacitive-touch devices, there are three key things you need to check for:

1. Legibility and readability – Design for desktop tends to assume good lighting conditions, but that's not at all true even there, and gets worse on mobiles. Even indoors, glare and viewing angles will change more. Start in Photoshop, knocking back the output levels by 20%; first each end independently, then both together. It'll look washed out and awful, but if readable, you are probably okay. Then, of course, test comps in the actual environment you expect it to be used in.
2. Click actions – Less about testing than evaluating your design. Does anything work on hover? Is hover required? If so: fail. Hover actions are fine for extra information, but stop making hover flyout main menus. If you can't, then at least tweak the design, and test the production code to make sure they can work on click. Most touch interface browsers interpret the first click action on an area with no click behavior as a hover action, so your menus will open. But, this is as prone to bugs as anything; in a recent test I performed the existing markup worked flawlessly on a dozen platforms. But not on the iPad. Oops.
3. Double-click actions – Never put another button, to undo (or commit a catastrophic change) in the exact same place as the initial button or link. People accidentally double click. If you just have to, then have a brief (100-250 ms) lockout period where the second click won't do anything..
4. Touch target suitability – The rest of this article focuses on that.

Make a Plan

Before you actually start testing on devices, or with any in mind, take a look at the test plans you have in place for desktop. I'll bet they are not "make sure it works!" Probably more like "IE 6,7 on Windows 7," and so forth. Very specific ones. You need the same sort of specific plan for testing off desktop. I'll ask you to try to find out what your customers actually use, instead of just making sure it works on the executives' iPads, but there's only so much I can argue about that. Regardless, you need to set up a routine, so results can be reproduced, between individuals and from one release to the next. Define it all, so everyone is on the same page.

• What devices, exactly? Most devices have generations and variants. For handsets especially, there will be regional and carrier variations that matter. "iPhone" is not enough by a long shot.
• What OS? If there are readily-available versions, like the regular updates to iOS, specify which of these you test for.
• What browser? I have fully seventeen on my one Android. If you don't define it, someone will test on their favorite. Or, you might miss that 30% of your customers use a third party client. It happens.
• Zoom? For tablets especially, does it have to work perfectly at default rate, or are customers expected to zoom in due to the type of content included.
• Orientation? Similarly, don't assume a default orientation. Things look different in landscape and portrait. And if you are zoomed in, sometimes in unpredictable ways.

Viewing Images

The crux of this test methodology is viewing images on actual devices. If you are very on the ball, you can probably convert pixels to real world measurements in your drawing program, and might even be smart enough to remember to do several conversions. If so, you probably aren't reading this as you know (or think you know) what to test for. So enough of you. For everyone else, or just to make sure you are accounting for device specifics, we're going to get raster images onto the screen. Specifically, you have to load it into the browser. For this latest project, we conveniently share everything in Basecamp. If not, then just shove them into a dark corner of your website and send a link, or something. Be sure nothing gets scaled. If you use a photo posting tool, or something, then they often get scaled to fit the posting tool. Avoid that. So, why the browser? I mean, they are all full-screen, right? Well... sorta. There are scrollbars that appear on move for some. There's chrome, at least for the top of the page. And even just render oddities. Yeah, I know it's a raster image, not rendering the html, but why screw around with it and use some image viewer instead. Get it into a browser. Be sure to scale the image up or down to fit plausibly. Even if the raster image is correct, it may be centered or just not loaded right. Compare to typical sizes, or the current site, or something else to guide you. Get as close as you can to the actual size it should appear as in production. Oh, yeah, and if you want to use prototypes, go ahead. I tend to say, use it after this as another validation step, but if you go straight to prototypes, do not leave them on the desktop and use math. Get them onto your targeted devices one way or the other.

Measuring Physical Sizes

Moving on, now what we're going to do is measure touch targets on the actual hardware. I like to do this with a circle template. Yes, old school, but that's me. I actually carry one of these in my bag at all times, along with a pad of paper, a ruler, pens and pencils, etc. Officially for drawing, but also useful here. These are still readily available but since you only need a couple of circles, your decision on buying is more on convenience. I use this little circle/square/hex one partly as its small. The circle we are going to use is the 3/8" one, or 10mm if you are metric. This is the size of pretty much everyone's fingers. I did some primary research of my own, and everyone has the same finger contact area. Seems to be that kids are less precise, which makes up for their smaller size. When I say contact area, I am talking about the fact that the user has an elliptical contact patch. We use a circle as people don't have it oriented any particular way. Variations in individual physiology, as well as different ways of grasping and using make it hard to tell if the ellipse is oriented any particular angle. I found no correlation yet, so call it a circle. Most devices will only accept input from the centroid of the contact area. In this way, you can tap on tiny, tiny targets still. But, as other items intrude into the target area, the chance of errors goes up. I've found that accuracy (CEP, if you wish) is close to the size of a finger. So, I've fudged the distinction on purpose. You might ask why you don't just poke the design with your finger. Two reasons:

1. Interference – The device is touch sensitive, so you'll scoot it around. As long as you grab the edge of the template, it won't be sensed. It is dielectric, so if you touch the template on the screen, it will be sensed.
2. Occlusion – Your finger is not transparent. It's easier to see what is going on with the template.
3. Science – Actually, repeatability and regularity. Why rely on your finger when it is different from everyone else's? A perfectly-repeatable proxy is the way to go.

Passing and Failing

To test, what you do is overlay the template on every link, button and UI widget on the interface. In all states. If there's a pop-up, test that, and be sure to test in place, over the top of whatever it is likely to appear on, for example. You will test for:

• Size – The visible target should be at least as large as the 3/8" contact area in at least one axis.
• Proximity – No other touch target should be within the 3/8" contact area at any point.
• Overlaps – Like I said above. Will any transient condition items be able to click past themselves. Lists, pop-ups, etc. Make sure edge-adjacent selections are over blank spaces, or they are modal and require an unambiguous dismissal action.
• Edges – As shown below, if you have something right up against the edge of the viewport, you can use a sort of Fitts' Law behavior to live with smaller targets. Unlike relative pointing devices (mouse, direction keys) it's not infinitely deep, but it can be functionally deeper than what is visible. This is ONLY for overlapping the bezel, not any other borders or edges, so is only so useful for web design, even on full-screen mobile browsers.

So, for example, this "View Product" link is pretty safe. There are no unlabeled areas that are clickable, just links, and nothing else is adjacent to the center. Good link. Pass. Let's try these two iconic elements instead. The big cart button is safe as houses. But that little delete icon is both very small, and rather too adjacent to other items. Does it fail? Well, it depends.

• Legal – Does it pass the basic size test? If not...
• Almost legal – Is it almost legal? I find that 20% smaller targets are fine for deliberate or secondary interactions. If not...
• Adjacency – If it's too small, so what? Is there something else that is a click target within the full-size (or worse, the 20% reduced) circle? If so...
• Consequences – If accidental activation of another link occurs, what will happen? Actually, you need to pay attention to this even for adjacent items when the circle is up to double the normal test size. Or, for any action on the page. People slip, or misunderstand, so check out the principles of cancel protection and otherwise avoid letting users make catastrophic actions easily.
• Orientation or Zoom – For each test, is the user likely to zoom, or switch to landscape, and if so does this help? In the example below, the delete button in landscape is just big enough to pass the 20% reduction in size regardless of accidental click actions.

Here, the delete button passes okay at landscape. And all the actions have escape mechanisms. They simply open spaces, or load pop-ups. And accidentally pressing the trashcan loads an undo in the line item right there so it can be undone easily. Oh, and one last thing. Check every widget. This scrollbar, for example, is a bit dicey. It is sometimes just fine, but sometime very close to the checkboxes. Which might not be bad, but it might be. Again, you have to know what is adjacent to it, so you can tell.

Fixing Your Design

This is all about being pragmatic. Ideally, you designed for all platforms up front, and serious errors require going back to the drawing board. But often, we don't have time. Or, the iPad access is just an offshoot of the desktop web, and you have no real time to address the changes. You need to look at the last bullet list, and decide how important errors are. You need to think about all platforms, if you cannot make custom versions for each. Does spacing out for iPad, for example, make it stupid on the desktop? Can you just implement interactive changes to reduce catastrophic consequences, if not the actual click errors.
Ideally you will design for mobile, or multi-channel, from the ground up. If not now, then certainly for the next release. Start thinking like that by reading up on the principles of design, how to design for mobile first (or always). And get lots of specifics by grabbing a copy of Designing Mobile Interfaces or checking out the resources on the associated design wiki.