6th
Notes on High Fidelity UI
My last batch of notes from Eric Hope’s talk on iPhone User Interface Design Essentials from the Toronto Tech Talk.
A High Fidelity user interface : “Most are not white lists.”
(Bummer. My initial iPhone application design is…)
“Make it iPhone-like.”
Apple has put all of their user interface design secrets into a single document, which is available for free: “Read the HIG.”
Make a brand, tell a story.
For example, Convertbot. “It could have been boring.” Hope draws attention to the tactile design. Things pop and click. There are metal and leather touches in these rich applications. “Materials cost nothing! You’re not paying a per-unit cost at a factory.” with the right look and feel, the application starts to approach the experience you would find in a luxury vehicle.
“I would love to buy a luxury car for three dollars!”
Start with paper prototypes. Work out every screen. On paper. It costs nothing to throw away something you’ve drawn on paper. The NPR application liked their application mockups so much they had them framed and mounted in their offices.
Dynamic content. “Your application needs a pulse… dynamic data.” Why do so many iPhone applications have a short shelf life? In comparison to the desktop, where most applications are serious, for user-generated content, iPhone is primarily about consuming content. Constant consumption leads to staleness, and
“…most people don’t enjoy dead things.”
If you update your application and simply note, “bug fixes,” you’ve failed. Users actually take the time to read the notes before deciding whether to download a free update to applications they own. This is a chance for the developer to write a love letter to their customers. “Be transparent, let them get to know you.” In return, this leads to better feedback in reviews. Improving the quality of dialogue goes both ways.
Some suggestions for updates: Put something good at the end. People will play through your game again to reach something new. Hide gems and people will repeat and share. “People love people.” Include social elements. Facebook Connect. Twitter.
In-App Purchase is an obvious way to extend the life of your application. Again with Ramp Champ: “Ramp Champ’s in-app purchase is gorgeous.”
Add animation and sound—to minimize UI. For example, if your mail is sent successfully, you hear “Whoosh!” They don’t throw a modal dialog in your face each time (“Your mail was sent successfully, click OK to continue!”)
“Animation and sound is so easy to add, yet relatively unused.”
Another example is the reorder/delete mode in the Springboard. “The icons are all quivering with excitement—either anticipating they’ll be placed on your home screen, or fearing they will be deleted.”
Sound is the forgotten frontier. But if you have sound in response to one action, you have to do it for all your actions. And sound needs to be symmetrical—if you have a sound going in, you need a sound going out. And you need high-quality sounds. (Hmm, I wonder why people don’t commit to adding sounds…)
Take advantage of search and scope controls. Remember icons are 29 pixels high there.
For push notifications, you can customize the notification sound. This is a huge branding opportunity. And you really need a custom sound to stand out from all the other notification sounds.
Anecdotally, there seems to be evidence for two classes of users. Younger users, under 25 years old, tend to prefer using devices in landscape mode and typing with their thumbs. Older users stick to portrait mode and poke with their index fingers. “If you ignore landscape mode, you alienate the users with the most disposable income.” This was questioned by a couple of people. Hope would not cite any sources for this. “This is anecdotal,” he emphasized.
(Personally, I took it as a strike against my intention of locking my iPhone application to portrait mode since I hate auto-rotation. Darn.)
Modal dialogs put people into flight-or-fight mode. Don’t throw up a dialog saying, “You won the game! OK?” since at best, this is a mixed message.
Make sure you’ve implemented your push notifications correctly. If you do it wrong, users will block your app at a system level from push notifying forever, and you will never have a second chance to get it right. For example, bundle notifications if you get a lot of them.
Your application needs an Application Definition Statement.
This is a solution, not a list of “nice to have” features. What are you doing? For whom? And what makes your solution different?
(differentiator)(solution) for (audience) …and not just “iPhone users.”
For example, changing “easy to use digital photo sharing for consumers” to “easy to use digital photo sharing for professionals” distinguishes iPhoto from Aperture.
Apple selects the fewest features, which are most used, by the most people.
For iPhone Apps, these must make sense in a mobile context.
And by sticking to your application definition statement, you can ward off each person who has their pet feature. An application is not a bundle of features.
“Sign up for a UI audit.”
