Manifesting Months of Expectations, Designing Experiences for iPhone
The following is based on a talk I gave at the NYC iPhone Dev Camp. It contains most of what was discussed as well as some additional ideas that I’ve had since then. Remember that there isn’t a single guideline for designing an application’s look and feel and that while it may make sense to produce something that closely resembles what Apple ships on the phone, this isn’t something that should be considered limiting. Innovation is what drives the market forward and if a developer comes up with a great idea that makes sense in ways no one ever previously considered, Apple would have no hesitation in adopting the idea themselves1.
Know Your Audience
This extends in a few different directions but first, recall that developing an application for the iPhone doesn’t mean that it’s only meant for the iPhone. Cocoa Touch is an API targeting Aspen, the embedded version of OS X that presently powers both the iPhone and iPod Touch. There is nothing, however, preventing Apple from expanding the line of devices that run this OS. As close siblings, both devices are nearly indistinguishable from one another save for the absence of telephony capabilities on the iPod Touch and in many ways; this completely changes the playing field for it. Going from a device that is almost constantly connected to the Internet to one that may only have such a luxury 50% of the time means that you cannot assume that your application will always be able to push and pull data remotely. Save some data locally so that a user can interact with recent content and then worry about syncing it back when an Internet connection becomes available. Similar rules apply to things like vibration and Bluetooth.
Consider how a typical user spends his or her day. The mobile device serves a very different purpose than the laptop and the convenience of pulling your iPhone out and working on it instantly makes it the perfect platform for quick and easy edits. This means that full-scale word processors make less sense for the phone than notepad style applications2. Also, make use of the advanced technology present in the phone to minimize interaction with your user - on a mobile device less really is more. For instance, consider a To-Do list application that knows to mark a task as being completed based on the location where the task must be performed. Applications that require less input from the user will almost certainly win out in the end.
Degrading Gracefully
As I mentioned before, it’s a typical usage pattern that mobile applications are controlled with a single finger. While a multi-touch screen makes an incredible number of things possible, it also requires more than a single finger (and consequently, more than a single hand). Think about how gestures can enhance your application without being essential to its functionality. Similarly, as mentioned before, don’t require an Internet connection if you don’t need to. In the second revision to the iPhone OS, even web applications can take advantage of local storage on the phone so use this to your advantage whenever you can. Assume nothing about where, when, and how your application will be used. Life isn’t ideal.
Make Use of What You Have
On the reverse side, build your application so that under ideal conditions it behaves incredibly well and makes full use of everything the iPhone and iPod Touch has to offer. Many users prefer to orient their phone horizontally, give them the option by providing a horizontal view. Use gestures to provide access to non-critical tasks that also map perfectly to the way they’re used today. Change zoom level with the pinch gestures. Use swipes in the same way users expect them to work. In the future, Apple may introduce new gestures and be prepared to add them to your application as well.
Design, Then Develop
Before launching XCode, go buy some coffee, sit down, and consider how you use your phone. Think about how you’d use your application on your phone and never stop thinking about that. What is the smallest subset of features that it needs to exist? Do you need to include more? Even on a desktop with a 30” display, a reduced UI is infinitely more pleasurable than one consisting of dozens of buttons. One good rule that I’ve come up with for defining the ideal mobile application is to apply a template: “My application does [blank].” If [blank] includes the word “and” you might be in trouble. Someone doesn’t launch Mail to check their e-mail and browse their contacts on the iPhone; there are separate applications for separate purposes. Don’t be afraid to cut features out and if you feel they are essential, consider writing a second application if necessary and building in handlers so the applications can interact - the worst you’ll do is sell another license.
Build your application on paper first. Paper prototyping lets you see the exact workflow that a user might go through and initiates the process of experiencing what it’s like to use your application without wasting time trying to think of how to do things in Interface Builder. From there, go on to Photoshop or your favorite pixel-pushing tool and then to Interface Builder. IB is a tool for putting a UI together, not for prototyping. Its library of components makes it seem like an almost ideal candidate for such a task but it really doesn’t perform well in the role and shouldn’t be used as a replacement for a paper or digital model.
Be a Good Citizen
Behave in a way that the user expects. If you produce audio, adhere to the standards of the system and don’t force audible alerts if the system is muted. If your application sends mail, use the standard mail composer rather than trying to write your own. If you need to access the camera, use the Image Picker and store the photos in the camera roll so that the user always has access to that later. Remember that any information that the user inputs into the device is almost always something that he or she wants to make use of and exploit; don’t assume that your application is the only one that is going to be used. It should be noted also that a typical way of accessing data of the phone when a sync either isn’t desired or isn’t possible is to email data. Be sure that if your application produces information that the user might need on another device that some means exists to get it off the phone - E-Mail is great for this type of task. Build your application so that its settings can be changed in the global settings panel. This both places the data in the location where the user expects it as well as freeing up valuable real estate in your application’s UI.
Build Confidence
If a user presses the home button, even accidentally, your application is going to quit. Prepare for that and save whatever he or she was doing whenever it happened. Aside from being good manners, if you don’t your user will switch to your competitor the instant they see it does this. Similarly, never force the user to consider whether doing something will or won’t save. Always save unless they explicitly chose to cancel3.
Build the Type of Application That Makes Sense
If you already have a web application, considering adoption of new WebKit technologies for CSS and HTML5. With animation and transformation available in Safari via CSS, impressive experiences can be delivered without ever needing to touch Objective-C. Similarly, HTML5 facilitates local storage in an SQLite database so that even if a user goes offline, he or she is never disconnected from your application. There are many examples of applications where more than this is complete overkill and over WiFi, the experience is certainly pleasurable. The iPhone SDK ships with Dashcode, a tool previously used to develop Dashboard Widgets but that now supports building full iPhone Web Applications using optimized native widgets. When possible, make use of it rather than hand designed images and CSS. Safari on the 2.0 OS goes further as well and supports gestures in the experience layer so that JavaScript can easily respond to pinching, swiping, and more.
If you require something that isn’t available through Safari but have an app that still really does make sense as a web app, consider the hybrid application model. Aspen treats a web view just as it would any other view save for the fact that it can display remote web content without the need for XML-RPC or a REST architecture. And using this type of model, you can easily exploit frameworks like CoreLocation in your application by letting it handle passing the obtained data to the web.
If your application doesn’t display a lot of complicated data and requires almost no user interaction, consider the dashboard widget like style of the utility class of applications. These can be found in Weather and Stock. These make perfect sense as they are free standing applications that perform a single task and never change modes beyond their initial set up.
In Conclusion
If you were at iPhone Dev Camp you’ve heard most of this before but it’s worth another look through as I probably skipped over some stuff during the session (and probably forgot some of what was talked about by the time I got to writing this). It’s important to remember that designing the way your user interacts with your application is more important than designing how your application does what it does in many ways. Always strive to simplify workflows and to make the process of using your application as enjoyable as possible.
If you have any questions, feel free to contact me. rob AT thenewhighstandard DOT com
Here are some good references to check out that may help in building your killer iPhone application. I hope to see great things in June!
Footnotes
1. Coda’s Toolbar and the Three Pixel Conundrum
2. Though I have no doubt that there is indeed a small market for a “full” word processor
3. There is some debate over whether going back in a navigation bar should cancel or save. Presently, in cases where no save button is presented the act of going back saves. In all other cases, it still saves. As a general rule, where all interaction indicates state changes have been saved (via sliders, switches, and picker for instance) it is not necessary to provide a save button to confirm that a save is occurring. But in the case some text entry is necessary or where many controls are present, provide a save and cancel button. My preference is that navigating back should cancel.