4 Ways to Improve Your Mobile Metaphors

In my last post, I mentioned that one way custom controls on a mobile device work well is if they mimic a real-world control. Let’s look at a turntable metaphor as an example: an app that looks like an old turntable might have a moveable needle, knobs to turn, and the ability to scratch (I found out that apps similar to this actually exist, but I’ve not checked them out).

This might be Apple’s favorite rule to break. To see what I mean, check out the calendar app on an iPad. It looks a lot like a traditional datebook with all of those flippable pages, but it’s the tiny arrows at the bottom that you have to tap to flip the page. There’s no option to use a swipe for page turning.

The iCal app doesn’t allow page turns by swipe

In an effort to do what they say and not what they have done above, let’s look at some ways that you can deliver a consistent experience that makes sense to the people who will be using your app:

Get off the computer. In as many ways as possible, the abstraction should work as the subject itself. If you are building the turntable app that I mentioned earlier, then by all means get your hands on a turntable! Put a record on, adjust the knobs, listen to the crackle of the needle against vinyl, pay attention to the details that make it an enjoyable experience. Take notes.

Improve on “real life.” The advantage of having a turntable or a datebook on a multi-touch digital device in the first place is that you can do all manner of things you can’t do on a real turntable or datebook. Increase enjoyment by improving upon the real world object where possible, both in appearance and technical ability.
For example, being able to swipe to flip the page of an eBook is a fun interaction but becomes a chore if you are forced to do it. A digital turntable might have secondary controls that don’t require the users who are in a hurry to set the needle or pick a new album. Plan for advanced or frequent users of your app by creating alternate task flows that focus on efficiency.

Try it before you build it. The more you can experience the app you’re making before it’s built, the more you gauge how well the metaphor is coming across and where the holes are. A cheap and effective way to do this is through paper (or even felt) prototypes, where you can “act out” the interactions with printouts or drawn mockups.
So, in our turntable example, you could demonstrate that you want the needle arm to snap to the edge of the record when it’s tapped once, but dragging allows it to be placed anywhere. This activity is instantly collaborative since it’s not on someone’s personal computer and leads to lots of clarifications. Make sure to invite the developers; they will think in terms of execution and can bring technical opportunities and limitations to the discussion.

Think through details. I like to think of developers as the directors that pull the working parts together into a cohesive unit, telling the “actors” where to go and when to make the story believable. It makes the process much smoother and takes the pressure off if these interactions have been discussed beforehand. That’s why it’s best to avoid the temptation to sweep even small areas of vagueness under the rug during the planning and design phases.
It’s all too tempting to say, “the developer can flesh those details out, we don’t have time to worry about all those interactions right now.” Remember that your metaphor will be fail without detail-oriented production; it’s the direct manipulation and carefully planned responsiveness that makes the app feel “right.”

Chances are that you are building an app where more standard controls are optimal and there’s no need to make it look like something else. If you’re not sure, take into account who’ll be using your app, what purpose the metaphor would have, and the unique value the metaphor would bring to the people using your app. Don’t forget that enjoyment counts as value!

Emily Smith is an information architect and usability consultant for the web and Apple devices. She co-works with other web professionals in Greenville, SC and can be found online at emilysmith.cc.

shmlco

Agreed. Despite having popularized the idea of using gestures in apps and on their computers, Apple is extremely lax at actually implementing them in THEIR apps.

My favorite app to hate is the App Store app itself. Instead of presenting apps in scrollable lists, they absolutely LOVE those stupid little rectangular boxes that present groups of apps four sub-pages at a time.

Which would be fine if you could swipe from page to page, but you can’t. In order to navigate, you have to find and tap on one of four minuscule arrows. It sucks.

Not to mention the way they tend to lose your place should you check out a particular app. Or the way they almost always manage to forget the current sort mode (Most Popular, etc.)

The iTunes app suffers from many of the same issues. Apple needs to hire someone to redesign their stores. And do it right.

http://htmlblox.com samanime

Excellent article. I recently read “Magic Ink” which talks along these same lines. If you’re involved in interaction design at any level it’s a must read!

You want uses to be able to just use your app, not spend forever learning how. That’s why the closer it mimics real life, the less they have to learn, the more time they’ll spend using it.

Emily Smith

@shmico Oh, you are right on. Those little arrows drive me bonkers! I think I remember reading in the HIG awhile back that they recommend using those arrows (or other similar “app-y” controls) as pagination for iPad visitors to your web site. I understand it more as a web element, but it is just not the best solution in an app.

@samanime Thanks! Do you have a link for “Magic Ink”? For some reason I had a hard time finding it. I’d love to check it out.