The navigation bar is the "You Are Here" beacon of iPhone apps. The navigation bar hugs the top of the screen, just below the status bar, and always includes some combination of screen title, back button, or other app controls. While the navigation bar isn't limited only to tree-structure apps—it can display the screen title and tools for any type of app—it's especially essential in drill-down apps because it lets you drill back up, too, thanks to the all-important back button. The navigation bar helps users keep their bearings as they move up and down your app's tree of information and features.
Figure 5-4. The standard arrangement of the navigation bar (left) displays a back button at left and the screen title at center, but you can customize the navigation bar with your own colors, controls, labels, or graphics, as shown in the examples at right. As shown here, the navigation bar is 44 pixels tall in portrait orientation, but when you flip to landscape, it shrinks to 32 pixels. (For more on this and other considerations of landscape layouts, see Chapter 9; Chapter 9 is all about working in landscape orientation.)
Behind the scenes, the navigation bar is divided into three regions—left, center, and right—where you can pour in text or buttons. In the standard setup, the left displays a back button, the center announces the screen title, and the right is blank. You can override that arrangement to fill those regions with your own controls or display elements, but go cautiously before you start making replacements. The screen title, for example, is a helpful way to cue your audience where they are in the app. In fact, at the top level of a tree-structure app, the screen name is often the only thing in the navigation bar. That's logical enough: since you haven't yet drilled down into the app when you arrive at the main screen, there's no back button to show. That changes when you venture at least one level down, where the navigation bar automatically sprouts a standard back button on the left. Tapping it takes you to the previous screen, one more level up toward the app's main screen.
Figure 5-5. In the to-do list app Things, the navigation bar in the app's top-level screen says simply, "Lists," the screen title shown at left. Tap a list to view, and the navigation bar updates to show the title of the new screen, with a back button to return to the Lists screen.
Honor thy back button. Treat its home at the left side of the navigation as sacred ground, and avoid planting any other controls in that spot, a space that should be used only to return to the previous screen. On the Home screen, where there is no back button, it's a good practice to leave the left side of the navigation bar empty; don't be tempted to fill it with another control just because you've suddenly got unused space. Because the back button always stakes out such familiar and frequently tapped real estate, putting a different button there inevitably invites a mistap. That's especially true when you're deep inside a tree-structure app, busily tapping your way back up to the surface. An empty slot at the top level signals that you've arrived at the main screen—there's meaning in the button's absence—but if you put some other control there instead, an eager over-tapper will eventually keep on going, tapping right through your button switcheroo. In particular, avoid putting an Edit, Logout, or other similar button that could change the state of the app (or its data) in some significant and surprising way. Don't make 'em think: be consistent with your placement of controls and, whenever possible, reserve the left side of the navigation bar for the back button or nothing at all. (In modal views, for example, this is a good place for a Cancel button, which is functionally the same as a back button in that context.)
The right side of the navigation bar, however, is all yours. Add any button or control that you like: a labeled text button, your own custom icon, or one of the many standard icons that come bundled with the iPhone coding toolkit (page 145). As you saw in Chapter 3, the right corner of the screen is, ergonomically, one of the most out-of-the-way locations for wandering thumbs, a good place to plant controls that are infrequently needed or that you don't want users tapping accidentally—actions that add or delete data, for example. The Edit button makes frequent appearances in this slot; you'll learn more about the Edit button in The Search Bar.
If the left side is sacrosanct and the right is anything-goes, the navigation bar's center is, yes, somewhere in the middle. Be cautious about commandeering the center of the navigation bar for something other than the screen title. It's common to slap an app's logo in that space, for example, but it's best to limit that usage to the app's top-level screen. Chances are, your app's branding is more important to you than it is to your audience. They already bought your app, and they're actively using it—they know who you are. No need to bludgeon them with your logo branding on screen after screen. Go ahead and slap your logo on the first screen's navigation bar if you must, but then switch back to using the traditional screen title on other screens. Except in cases where the content of the screen is bluntly self-explanatory, avoid losing that title. It performs an important no-nonsense usability role by telling users where they are, fending off navigation vertigo as they spin deeper into your app. The iPhone's tiny screen reveals only a sliver of your overall app at any one time, and a titled screen helps people stay oriented.
Figure 5-6. The New York Times app drops the screen title from the navigation bar on many screens. Top-level sections (left) instead show the Times logo, compensating by including the screen title (the name of the content section) in the content area below. That means less room for headline content, though. Space could be saved by putting the screen title in the navigation bar instead. On article pages (right) where most headlines won't fit in the navigation bar, the app wisely keeps the title in the content area. The extra space is used for previous/next buttons to step through the articles of the current section.
For screens that require more explanation than a meager title, the navigation bar also accommodates prompt text. This is especially handy on modal views where you're manipulating content in a way that might require a hint about what to do, like moving an email message to a new folder in Mail. When moving an email message to a new folder in Mail, for example, the app displays the prompt text, "Move this message to a new mailbox."
Like the screen title and prompt text, back buttons also provide grounding context, albeit more subtly. In addition to helping you get around, the back button normally shows the title of the previous screen, a reminder of where you came from and of what lies on the other side of the back button. Some apps replace that title with the blandly unhelpful label "Back." Avoid watering down the content of the back button, except where tight space causes the previous screen's title to be lopped off so much as to be meaningless. The back button is a road sign, and taking that contextual information away removes one of the locators that keeps your audience grounded in the app.
Figure 5-7. Prompt text appears above the navigation bar's usual collection of controls, extending the navigation bar's height by 30 pixels to an overall height of 74 pixels in portrait view.
An even better way to keep people from getting lost is to limit how far they can wander in the first place. Try to limit the depth of tree-structure apps so that your users don't disappear down a rabbit hole that takes them forever to climb back from. As a user, if you find yourself deep inside one category but want to switch to another primary category, you first have to tap all the way back to the surface before drilling down again. If you can't limit your app's navigation depth to just a few levels, then consider some creative shortcuts for jumping back to the top of a deep stack of screens. The standard iPhone toolkit doesn't provide a way to instantly teleport back to the start, but a few apps have pioneered some workarounds by adding custom swipe or tap gestures on the navigation bar. The Twitter app (formerly known as Tweetie) lets you leap back to the main screen by swiping left-to-right across the navigation bar. Facebook lets you do the same by tapping the screen title. (You'll learn all about working with gestures in Chapter 8.) Any app with significant content depth should consider rigging a similar escape hatch.
The navigation bar can stage its own escape, too. You're not obliged to include the navigation bar on every page, and you can send it packing when you want to devote the full screen to your content, useful for photos and long-form content, for example. When you take away the navigation bar and its back button, of course, you have to provide some other way to leave the current screen. For tree-structure apps, which need a navigation bar, the standard way to do this is to toggle the display of the navigation bar with a tap of the screen. When you do that, it's often appropriate to make the navigation bar partly transparent, too; even when the interface chrome is visible, the full-screen content still shines through. For more about handling transparency and color for navigation bars and toolbars, see Gussying Up Familiar Pixels.
Figure 5-8. Ebook reader Eucalyptus (left) and the built-in Photos app (right) both perform the disappearing chrome trick: tap the screen to toggle the display of both navigation bar and bottom toolbar. Even when visible, the toolbars in both apps are translucent to allow the underlying content to remain visible.
While the navigation bar can accommodate tools to work with a screen's content, you should let its primary role remain, well, navigation. Leave the navigation bar as uncluttered by controls as possible so that it can clearly announce the current location and offer a way back to previous screens. The main home for screen controls should instead be the toolbar at screen bottom.