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!