Got an idea for an iPhone app? Chances are that you'll already find a number of apps very similar to it in the App Store. Things have changed since the App Store was launched two years ago. Not only are there more and better apps, there are many more experienced and creative developers.
How do you make your app stand out from over 100,000 apps? Most iPhone users have no idea what beautiful code looks like, but any user can take pleasure in a useful and well-designed app. User interface design is the single most important factor that differentiates the most successful apps from those that struggle.
How do you put a professional polish on your app? Ask someone who has developed a successful app. In this article, Joachim Bondo, creator of Deep Green Chess, describes how he solves a design problem and makes navigation more effective. (The rest of this article is excerpted from Apress's latest book, iPhone User Interface Design Projects.)
Yet Another Google Reader
Choosing to develop a newsreader
I'm Joachim Bondo, the developer of Deep Green Chess. In this article, I'm going to take you through the early design process of my next application on the App Store, Yet Another Google Reader.
I'm a heavy user of Google's Reader service (reader.google.com). It helps keep me informed about what's going on in my areas of interest, which include technology, programming, photography, watches, and design. It also helps me monitor the postings on the blogs of friends, peers, and competitors. Google's Reader Web site is optimized for the iPhone, so there's no horizontal scrolling, and the text is displayed in a comfortable size. I'd like to think I can make this experience better in a number of areas.
Making the navigation more effective
Two aspects of Google Reader that don't work so well are its sideways navigation (i.e., going from one feed to a sibling without first having to go one step up) and its ability to let the user know their current location in the navigation hierarchy. If I can create a navigation bar for my app that has these two features, it would make navigation easier for the user. The navigation bar should appear in the following four views and should offer the following navigational options:
- Top view shows list of groups and feeds: There is no navigation from this view.
- Group view shows list of feeds: Can move up and perhaps to neighbors or siblings.
- Feed l view shows list of items: Can move up and to neighbors and siblings.
- Item view shows item detail: Can move up and to neighbors.
The Top and Group views are nearly identical, except that the Group view will only show feeds because it can't contain other groups. When the user is at the Top view, there won't be any siblings to navigate to, so the navigation bar will not contain any such options. When in Group view, the navigation bar might offer direct navigation to other groups or possibly feeds.
When browsing news items, the user will spend the most time in the Feed view. When reading the news, he or she will be in Item view. When designing my navigation bar, I'll focus on how it will appear in Feed view, which will have the most options.
This is because the user should be able to navigate to only the next and previous items in the Items view. News items don't have a clear and simple visual representation, such as an icon. They have only data, such as a date, author, or title, and none of these are suitable for mass representation in the navigation bar. Visualizing several sibling news items in the navigation bar is not viable.
A news item may contain images that I could use, but these are often photos, which don't typically scale well to very small sizes (despite the iPod application's display of the album cover in the navigation bar). In addition, the user wouldn't know what the image represented. Therefore, in Item view, I'll have to provide simple navigational options such as next/previous arrows.
A feed, on the other hand, has an icon that clearly identifies it and distinguishes it from other feeds. The most common thing to use is the site's favicon.ico file. This is the icon you see in your Web browser's address bar. It's small (most often 16 x 16 pixels), but I don't want it to take up too much space anyway. There is an alternative. As the iPhone OS keeps gaining market share on the mobile browser market, more and more sites are providing a higher-resolution icon file—the apple-touch-icon.png file, which is typically 57 x 57 pixels in size. This is the icon that's used when you make a home screen bookmark from Mobile Safari on your iPhone or iPod touch.
With all this in mind, let's see what kind of steroids I can inject into the navigation bar. If I just used the standard implementation, it would look something like Figure 1.
Again, all you see here is the feed's title and its parent's name, or the portion of it that fits the back button. So if I want to display the siblings, I could simply line them up in the navigation bar as shown in Figure 2.
Tapping the feed icon next to the feed title would take us back to the Feed view, just as if it were a regular back button. This feature is nice, because that's where the user is accustomed to finding it.
The user would tap an icon in the row to activate that feed or drag horizontally to scroll for more feed icons, and when the finger is lifted, the feed in focus would be loaded. The arrows indicate that there are more icons in both directions. I probably wouldn't want to display them.
While scrolling, I could display the icon and name of the feed in focus in the area below the icons, although the user's finger would obscure that (see Figure 3)—not a good solution, but I won't completely write it off either.
The bar looks a little bit busy, which I'm not too keen on, but that might be solved by making the icons grayscale, which could look good in a black header. And the icon for the currently displayed feed could be shown in color. But I'm getting ahead of myself. For now, we're just working on the high-level UI design, not fine-tuning the graphic design.
Swapping the elements, so that the row of feed icons would be displayed underneath the current feed title as shown in Figure 4, is not desirable because this layout would imply that the sibling feeds were children of the current feed.
A third possibility, shown in Figure 5, could be to display the name of the feed in focus above the icon row, much like the dock in Mac OS X. But this layout is a little bit busy, takes up more vertical space, duplicates information, and is not very attractive.
I haven't found a solution I'm happy with yet, but I have a model I can keep improving until I am. And, even at this early point, I've achieved my goal—deriving a solution that lets us navigate sideways with a single tap and at the same time gives a better indication of where we are in the hierarchy. I've even managed to do it with the same UI elements, icons in this case, by giving them multiple roles: command and display.
iPhone User Interface Design Projects
$39.99 ISBN13: 978-1-4302-2359-7
The text in this article is an extract from iPhone User Interface Design Projects by Joachim Bondo, David Barnard, Dan Burcaw, David Kaneda, Craig Kemper, Tim Novikoff, Chris Parrish, Brad Ellis, Keith Peters, Jürgen Siebert, and Eddie Wilson; published by Apress.
The book presents practical advice on user interface design from ten innovative developers who have pondered how best to make use of the iPhone's minimal screen real estate. Their stories illustrate precisely why, with more apps and more experienced creative developers, no iPhone app can succeed without a great UI.