Prelude

Do this for me. Take your iPad or whatever iPad knockoff you’ve picked up at the local flea market, and just go ahead and duct tape it to your wall, about level with your forehead.

Make sure it’s on good and tight. That’s it, just duct tape that right on.

Now, stand in front of it and use it for about 10 minutes. Just go ahead and poke, slide, pinch, type, whatever. I’ll wait…

That was fun. How’s your arm feel? Did you have fun editing photos and Twittering?

More importantly, are you still all hot to use The Minority Report Total Upper Body Toner And User Interface, just like Tom Cruise?

Didn’t think so.

What’s Going On

The human-factors people recognized this fact way before we had any kind of ‘screens’ to play around with. It doesn’t matter whether you’re in great physical shape or not: if you try to accomplish any physical, precise task with your arms extended in front of you—even a little—you’re going to have to work harder to achieve the same degree of precision.

The same is not true of just moving things around with your arms.  Making large, imprecise movements, just moving things from place A to place B, is easy, and some people spend their entire working day doing so¹.

What causes the fatigue you would have felt if you’d actually taped the pad to the wall like I asked you to do is the need for quick, precise placement of your fingers, hands, and arms, with your arm supported only by the muscles of your upper body.

Why I Care

Annnnd here’s the nub of the story. Back in 2007, $theAgency was given the job of designing and developing the software for touch-screen retail kiosks for $theClient. They were a key feature of a high-profile retail reboot of $theClient‘s mobile phone stores².

I’ll leave aside the details of the marketing and sales goals of these kiosks³. Instead, I’m going to focus on the problems of designing for touch-screens in general, and why we repeatedly tripped over them on this assignment.

Know Your Target

I was able to find solid human-factors research that indicated a minimum physical button size of about 1 centimeter for upright kiosks. The tricky part was the same research also indicated that buttons that were to be used frequently would be more likely to induce arm fatigue, especially if the user needed to reach higher to press the button.

In the end, we decided on a visual hierarchy that accommodated this spectrum. More important, more frequently used buttons would be larger and placed closer to the center of the screen. Less important and rarely used buttons would be smaller (albeit with a larger hit box than their visual size would indicate), and placed closer to the bottom and edges of the screen. Here are some scans from the style guide for the project.

Defining the button interactions

First up, the minimum size for visual buttons, a requirement for a hit box as large or larger than the visual button, and some preliminary placement rules.

Click to view full size

Clarifying the visual design

We were working with an offshore development company chosen to integrate front and back-end code. This often resulted in communications issues, and we finally had to fall back to specifying every possible positional relationship. While the visual design is not mine, it fell to me to document and describe every significant placement rule.

Click to see full size

Click to view full size

Click to view full size

Tip: Never trust a locked layer

When you’re doing distributed Flash development across time zones, companies, and quite possibly languages, don’t assume that the pixel-perfect template you sent out, in the form of a well-formed Photoshop file with required layers locked, is going to survive the trip. We kept finding that some Flash jockey on the other side was in the habit of eyeballing placements, and wasn’t at all good at it. The result was controls and other elements jumping back and forth a few pixels during use.

Visual specs are the way to go.

Click to view full size

next

Prophecy

Somewhere right now, there’s a spotty post-teenager with OCD who copes with his affliction by mashing up cutting-edge game technology with decidedly non-game applications, and his work will eventually end up in Microsoft Natural UI v3.5.

And if you’re not paying attention, you’ll be in your business-class seat on your way to Delhi, hand-miming a tarantella in front of your laptop just to send a frickin’ email, and you will suddenly find out that the gesture for ‘Send’ happens to be very, very rude in the eyes of your Uzbekhi seat mate.

1. Sweatshop employees, for instance.
2. In case you haven’t read my intro, $theClient was our largest client, a national mobile-wireless carrier.
3. I’ll also spare you the problems we had with the retail furniture expert whose initial designs focused on the optimum height for standing use of a keyboard, not on interacting with a vertical touch-screen that topped out 15 inches above and 2 inches behind the keyboard.

We had to fix that one with bandsaws.

Once upon a time, I worked for the Mac group at a certain very large Seattle-area company. Our main product was … an office productivity suite.

I was reviewing one of the most detailed product specs I had ever encountered. It covered jamming a lightweight but feature-complete project management tool into an existing email client.

One could, if we were successful [and we were], run a small business with this email client and its project management tools. Certainly better suited for the task than Lotus Notes¹.

So. I’m checking to make sure all the bases are covered: content, workflows, element dimensions, control states, failure conditions, user interface, … wait a minute, WHAT THE…

What’s a thermometer doing in the mockup?

I scan the index page. No mention. I scan the entire UI section. Nada. Everything else is specified in pixel-accurate detail, all functionality described. What is this thing?

I email the design PM.

PM:   Oh, that’s the project completion meter. It shows how close the individual contributor is to fulfilling their assigned tasks.

Me:   WOW! That’s a great feature! But you haven’t specified how that’s calculated or any of the functional states.

PM:   Oops. Let me add that right now!

{ Five minutes later, with new version of spec }

USER MAY SET THE PROGRESS BY DRAGGING THE TOP OF THE RED THERMOMETER CONTENTS

Me:   Ummm … AND?!

PM:   That’s it. The user just drags the red bar to show his/her progress.

Me:   And this is communicated back to the project owner?

PM:   Nope. The user gets to set their current progress. That’s all.

{ I remind myself this PM is one of the brightest people I’ve ever met.}

Me:  What kind of project has a single dimension of progress?

… … …

I’ll condense the two-day argument that ensued. I argued that:

• the project members necessarily held a clearer picture of where they were on their project tasks than any single-dimension indicator could convey;
• without communicating their current status back to the project owner, the project owner couldn’t set her or his own completion status; and
• no one on a serious project, requiring an actual project management tool, should be spending their time playing around with a meaningless, zero-function control.

I believe at one point I may also have suggested ‘Project Mood Ring’ as an alternate UI, but I can’t find the mockup in my archives.

In any case, I got the thermometer cut. The project management feature is alive and well, and still waaay better than Lotus Notes¹.

Bottom Line

If you’re going to add a function to an existing application, please make sure it adds functionality and doesn’t detract from the existing functionality.

Alternatively, if you’re attempting to inject an element of fun, make sure actual ‘fun’ is a deliverable.

1. Wiki: Whore of Babylon
2. See also: Lotus Notes Fan club

In early 2009, $theAgency was asked to come up with a campaign to promote a mobile carrier’s leadership on the Android platform. The creative brief, in part, touched on the idea of getting the client’s message in front of known influencers in the tech community.

I proposed that $theClient, in partnership with the Google Android team and their major Android device partner, arrange and support a community-organized Android developer conference.

At the time, the very first Android DevCamps had just concluded in Europe, and none had yet been announced in the US. The most influential European Android developers had been well-represented, and the community response had been very encouraging for the platform.

I made the case that $theClient and their partners, by generously supporting the first North American Android DevCamp—without injecting their own agendas—would garner the best possible response from the developer and tech blogger communities. The impact among tech bloggers would be particularly influential if we scheduled the conference near the annual Apple developer conference.

As part of that argument, I offered the following mind map.

[NB: I've removed all references to $theClient from this version.]

Click to view full image

In the end, the campaign went in a more conventional direction, but I firmly believe that early outreach to the developer community, in a manner appropriate to that community, would have paid bigger dividends.

Bottom Line

Mindmaps are great for ordering your own understanding of a problem and developing a solution. Including them in your deliverables helps to shape the discussion and organize further details.