If you think of an app's navigation model as the road your app travels, modal views are its cul-de-sacs—single-screen pull-offs for editing, viewing, or manipulating a screen's content. In computerese, a mode is a special circumstance where the app behaves differently than it usually does, often changing its interface in the process. Modal views are how you handle modes on the iPhone: a modal view is a screen that briefly hijacks your app's normal operation, swooping in to cover the current screen to let you perform some task related to that screen's content.
You just saw a pair of examples from Gowalla and Safari, which use modal views to browse content. Modal views are also commonly used to add or edit content. For example, the built-in Mail app uses modal views to move messages to a mailbox folder or compose new messages. These actions both summon a separate screen—the modal view—that lives outside Mail's normal tree-structure path of accounts, mailboxes, and messages. In both cases, those screens shoot up from the bottom of the screen—standard behavior for a modal view—and cover the previous screen while you take care of business. When you're finished, the screen retracts, letting you continue to browse and read your mail.
These task-focused, single-screen detours are full-screen examples of the hidden-door approach introduced in the last chapter for reducing interface chrome (page 85). Modal views neatly tuck away controls and interface elements that you need only occasionally for handling secondary tasks. By zooming up from the bottom to cover the current screen, modal views subtly reinforce their role as a temporary detour from the app's normal browsing, where screens typically swap out left and right, not up and down. Make sure you make it easy for people to get back to business as usual; in addition to including all the necessary buttons and other controls to complete the task, add a Done or Cancel button to let people bail out if they change their mind.
Figure 4-16. Mail uses a modal view to let you move a message to a mailbox folder. Tap the Move button in the toolbar of a message screen (left), and the Mailboxes screen shoots up from the bottom to cover the message until you file the message in a mailbox folder or tap Cancel. Like all modal views, the screen briefly interrupts the app's regular interface to complete a task. Tapping the Compose icon in the toolbar (left) likewise triggers its own modal view, this time with a screen for writing a new email message.
These cul-de-sac pages hang off of individual screens, which means they sit outside the flow of the navigation models you've explored so far. They're not the main cards in a stack of flat pages, and they don't rest on the main branches of a tree structure. Instead, modal views are accessories to those primary screens; you conjure a modal view to perform some related task and then dismiss it. While that means modal views are not the main screens of a standard navigation model, it's also true that for some apps, modal views are all the navigation you need.
Safari, for example, is essentially a collection of modal views dangling from the main browser screen. There's no tab bar, no app categories to browse. The entire app is about the main screen of web content, with various tools popping up in modal views to change or share the content in the browser. The iPhone's virtual keyboard springs up to help you type a Web address or search term; the Mail Link screen slides up to send an email; the Bookmark screen zips in to help navigate to a saved page; and the Windows screen lets you switch among your open web pages. The app has no formal app navigation where you flow from screen to screen. Instead, you pop in and out of these single-purpose spurs jutting off the main view.
Figure 4-17. Safari's operation relies on a collection of modal views instead of navigating a flowing series of screens. The keyboard as well as the email and bookmark screens are all modal views that you use to change or share the content of the main screen. They all briefly replace the browser window until you complete the task. (With the keyboard at left, the main browser window is visible underneath, but dimmed and inaccessible, peeking through the modal view that covers it.)
From elaborate tree-structure cascades to Safari's one-main-screen approach, you've seen lots of ways to organize the screens of your app using Apple's standard navigation models. When planning apps that have to juggle lots of content or tools, it's all too easy to get lost among these several options. When planning your app's navigation flow (and its occasional side-road detours), it helps to draw a roadmap to stay on course. Before you dive into the details of the standard iPhone controls, first sketch out how you'll put Apple's standard navigation models to use in your app. As you do this, think of your app as a story.