iPhone User Interface Design Projects
published at Apress is a great book for reading about the experience of other iPhone developers that published their applications in the AppStore and were successful. Mostly focusing on the user interface and user experience aspect, the book also covers product management, marketing, testing, tools and team dynamics.
The path of perfecting my mobile development skills is a long one and, as many paths, it’s not meant to be walked alone. Recently, one of my partners in crime shared this great book, written by a great bunch of iPhone developers, designers and entrepreneurs, about their experience of building applications for the AppStore.
Each developer get it’s own chapter, covering most of the reasoning behind making an iPhone application.
As you might have guessed from the title and by what iPhones implies, the user interface and the whole experience of using their applications gets extra attention.
Apple already provides majority of the UI objects you will need for your application. Take great care in creating new design patterns for interaction; this isn’t the Wild West of UI design like the Web can be sometimes. Respect the fact that your users have become familiar with the common objects in iPhone applications, and they will expect your application to behave the same way.
Eddie Wilson, Snow Reports
Interface constrains
Aside from the over-used statement that the screen is smaller than the desktop, the developer of Gas Cubby expresses another point about user experience:
One of the most interesting things I learned by watching users interact with my applications is that iPhone users expect tactility. Pretty much every touch of the screen should have some sort of visual reaction, even if it doesn’t actually accomplish anything. This is something that I should have learned while studying Apple’s own UI interactions, but it didn’t occur to me until I watched family and friends interact with my applications for the first time.
David Barnard, Gas Cubby
The Team
When a small team decides to make an application for the iPhone, if they want the final product to succeed, sometimes compromises must occur.
If you’re ever looking for a way to send your marriage into divorce territory, try choosing a bunch of colors with your spouse. Imagine picking a color to paint your house. Now imagine picking the colors for all the houses on your street. And imagine that the choices you make will be judged by millions of people around the world. But in the end, we came up with a winning combination that we both loved (see Figure 5-32), and we didn’t even have to involve any lawyers!
Craig Kemper, Zentomino
One of the biggest benefits of working in a two-person team with one designer and one developer is how facile we can be in implementing and modifying the design. If Jim needed me to revise a graphic, he would leave me a message (on Basecamp, of course), and I would reply within a few hours with the graphic. Certain elements could not be built in Xcode (the primary iPhone development environment) the same way I would craft them in Photoshop. We wanted to use a custom header color, for example, but the gloss is applied automatically in Xcode. For this situation, Jim quickly came up with something close, and I helped refine, through iChat, using requests like, “Could it be just a tad more saturated and a little lighter?” Altogether, we were able to get the right look in about 10 minutes.
David Kaneda, Outpost
The product approach
Before making an iPhone application, it’s obviously a good idea to check out what else is already in the App Store and make sure that you’re making a new contribution. My own experience tells me that even if you see others going for the same functionality, if they don’t get the UI right, the market is still there for the taking. Apple knows this quite well too, as it was not the first ones to make a phone with a built-in browser and music player, but it was the first to make a really slick one. (sorry Treo.)
Tim Novikoff, Flash of Genius: SAT Vocab
<Your differentiator> <your solution> for <your audience>
In my case, I’ve chosen to formulate it as follows: an effective Google Reader client for the aesthetically aware news consumer.
My differentiator is “effective”, the solution is “Google Reader client,” and my audience is “the aesthetically aware news consumer.”
By stating that the application is effective, I’m addressing all my complaints about the existing applications in one word. It’s a little bit generic and very subjective, though. Being effective will mean different things to different users. But I still find “effective” to be the best descriptor, because that’s the goal I’m trying to achieve, and it allows each user to attach individual emotions or values to being effective—and hopefully, I’ve achieved that too.
The target audience is the news consumer (i.e., people who read news). Online news feeds are implied by the saying this is a Google Reader client. And by targeting the aesthetically aware news consumer, I’m also saying that it’s a tasteful and beautiful application.”
Joachim Bondo about his upcoming feed reader
The balance
Ultimately, designers have the luxury of making iPhone applications look however they choose. The challenge of this is finding a balance between using default controls, like navigation lists, and completely customized designs that can alienate the user. As illustrated in this chapter, we created many conventions within Outpost. Some were structural, like using a flip transition to switch between two exclusive modes of the application. Some were purely cosmetic, like changing the button styles. Throughout our application design process, though, our primary goal was very straightforward—create an application that felt native and custom at the same time, had the features we wanted, and stayed out of the way of the user.
David Kaneda, Outpost
All professional designers must know a bit about programming for the environments that they design for. In my opinion, this is a requirement if you want to design for the Web, desktop, or mobile devices. Knowing the capabilities and limitations of the environment I am working in enhances my design work. I can foresee, to some extent, how a programmer will work with my designs to implement them effectively. During the implementation process, I am able to talk to the programmers and understand and diagnose issues they run into. Much of what we consider “design” lies in programming the flow and interactions of a web site or application. As an interactive designer, my job truly begins when I finish a Photoshop document. This is never truer than when designing for the iPhone.
Eddie Wilson, Snow Reports
The tools
Getting the bounce to behave realistically and at a speed that kept the application from feeling unresponsive required many iterations. To help the process, we even used a motion graphics application (Motion from Apple’s Final Cut Studio suite) to model the animation timing. Apple’s visual graphics programming tool Quartz Composer, which comes with Mac OS X, is another great way to tryout animations.
Chris Parrish and Brad Ellis, Postage
Testing
Ideally, your test subject will be somewhat familiar with the scope of your application. In my case, my wife made the perfect test subject for Trip Cubby. Her job required quite a bit of driving, and she had been tracking her reimbursable mileage with a convoluted combination of sticky notes and scribbles in her calendar. Plus, she had been using an iPhone for a few months but was definitely not a power user.
Next, you need to set up a scenario and ask the test subjects to actually use your application. The first time I had my wife test Trip Cubby, I handed her the iPhone and said, “You just drove 33 miles to give a presentation at 123 Main Street. Try entering that information into Trip Cubby.”
Once your test users are in action, it’s time for you to observe and resist the urge to intervene. It’s best to have the test subjects vocalize their thoughts as they perform the actions. By watching people interact with your application and listening to their thoughts as they walk through various scenarios, you should start seeing potential improvements in the UI. If no one figures out that your cute little disk icon means “save,” maybe you should just use the word Save onscreen. If the testers keep tapping the wrong button on a cramped toolbar, maybe you should leave a couple buttons off and make the remaining buttons bigger. If users are completely stumped, and you have to intervene with several minutes of explanation, you should consider a complete overhaul of the UI!
David Barnard, Gas Cubby
I recommend iPhone User Interface Design Projects to anyone who’s fooling around with the idea of iPhone development or who already has experience in this battle field.
