Even better in some cases than choosing the right keyboard is getting rid of the keyboard completely. Remember the dreaded high-school pop quiz? And how much easier it was when it was multiple choice instead of short answer? A limited set of options, all displayed in front of you, made for a better shot at dodging wrong answers. You didn't even have to strain your delicate adolescent wrist to write anything out; you just picked your answer and moved on. The same considerations apply to iPhone apps: picking from a menu of options is faster and less error prone than pecking out the full text on the keyboard. Wherever appropriate, put the keyboard away and give your grateful users a quick-tap menu of options to choose from. The standard iPhone controls include a few different tools to do exactly that.
The picker control installs slot-machine dials in your app to let people "spin to win," choosing from a set of options. The picker can consist of a single wheel, or you can squeeze several wheels side by side to ask your audience for several values at once. Pickers can (and should) include an optional selection bar, a translucent strip that hovers above the dials to make it completely clear which option is selected, and which can also display the units you're working with. Apps typically either fix pickers onscreen as a primary interface element, like the timer function in the Clock app, or keep it tucked away until summoned like a keyboard, skittering up from screen bottom when you tap a button or table cell to enter a value.
Figure 5-31. The timer screen of the Clock app (left) features a two-dial picker to choose the hours and minutes for your countdown. Note that labels for hour and minutes are fixed to the selection bar so there's no confusion about which dial is for what. Lose It!, the diet log at right, uses a picker to choose food portions. (Mmm, bacon . . .)
Pickers are especially handy for entering dates, and the standard toolkit includes a prefab date picker designed to do just that, with three dials for month, date, and year. This highlights the main advantage pickers have over displaying options in a table-view list: they can provide multidimensional options, a high-falutin' term for choosing several settings (like month, date, and year) all at once in a single control, providing a more compact interface than a straight list every could.
Figure 5-32. Urbanspoon's three dials let you browse restaurants across three categories. You call it dinner, but information designers call it multidimensional data. That's an enormous number of combinations that would be inconvenient to display in a single table view list, and the picker is also more compact than drilling down through several levels of a tree structure to browse the categories as lists.
Pickers aren't great for everything, though. Because only a few of a picker's options are visible at any one time, pickers are best for displaying either very familiar sets of options (dates, times, numbers) or very small sets, where only a few options are ever tucked out of view. For the same reason, the order of picker items should be very obvious—alphabetical or numeric—so that people don't spin back and forth through the list like some manic version of the Showcase Showdown, trying to find that elusive value.
For longer or less familiar collections of options, it's best to send the picker packing and instead use a table view, letting people tap an option from a plain scrolling list of options. The Settings app, for example, uses table views throughout to let people choose setting preferences. These full-screen lists have several advantages over pickers: they're easier to scan than a picker's tiny window; they provide built-in editing tools if you want users to customize the list; and where appropriate, table views also let you choose multiple items, marking each selection with a check mark in the cell's right side.
For very long lists, try to surface likely selections based on the user's history or, where appropriate, by community popularity. In Foursquare, for example, users "check in" to announce their arrival at a physical location; the app lists all the nearby restaurants, bars, and venues, but at the top it features "favorites," places you've checked in before. By highlighting these likely spots, the app saves you from searching through all the options. This is something lists can do much better than pickers, especially since lists can display headings to call out and explain these special option categories.
Figure 5-33. Surface favorite or recent picks in your selection lists. Foursquare's Places screen (left) floats personal favorites to the top of its list of places to speed selection. The PCalc scientific calculator app (right) provides a categorized list of constants to plug into your calculations but makes it easy to grab the last constant you selected (here, the Avogadro Constant).
Pickers or lists are the way to go for offering multiple-choice options for data entry or choosing preference settings, but when it comes to choosing among possible actions, Apple provides a very specific tool: the action sheet. Think of action sheets like flipped versions of the familiar pull-down menus of desktop software. There, menus drop down from a screen-topping menu bar to offer a selection of commands to choose from. Action sheets do the same thing but spring up from the bottom of the screen—often from the toolbar or tab bar—to present a sliding sheet of buttons. You most commonly trigger an action sheet by tapping a toolbar button, like the Reply button in Mail or the Add button in Safari. Conceptually, these toolbar buttons work the same as menu headings in a desktop menu bar: Tap to reveal the action sheet's spring-loaded collection of related commands.
Figure 5-34. In Safari (left), the Add button triggers an action sheet to file or share the web page. In Contacts (right), an action sheet is used to confirm the deletion of a contact, a last-chance fail-safe against accidental deletion.
Action sheets are another example of the hidden-door approach of tucking secondary controls offscreen until needed (page 85). They allow you to offer buttons and options that won't physically or cognitively fit on the iPhone's toolbar. Action sheets' text-based buttons may look different than elegant little toolbar icons, but their behavior is effectively the same as a toolbar button. Action-sheet buttons present options for editing, manipulating, or sharing the current screen of content. Like toolbar buttons, they often trigger a modal view (page 117) to handle the details of the selected action. The action sheet behind Safari's Add button leads to three different modal views for bookmarking, saving, or sharing a web page; the various reply options in Mail likewise call up a screen to compose a new message.
The main exception to triggering a modal dialog happens when you use an action sheet to confirm a potentially regrettable action. It's the "Seriously, you're really gonna wear that top with that skirt?" reality check for the iPhone interface. Confirmation action sheets are typically used to protect against destructive actions by throwing in a speed bump on the way to deleting content. Tap the Delete button in the Mail, Notes, or Photos toolbar, for example, and an action sheet slides up with Delete and Cancel options, forcing a second tap to complete the deletion. Well-intentioned as it is, this double-tap two-step sometimes creates more irritation than relief, slowing people down by putting their goal one more step away. (Mail even offers an option to turn these confirmations off.) Their utility fades over time, too. As we become accustomed to these confirmations, we tend to tap right through them without thinking; they become part of an action's muscle memory and their gatekeeper protection starts to fade. Cushioning people from accidental mistaps, particularly destructive mistaps, is a delicate and imperfect art, a topic that you'll explore further in Awkwardness for Self Defense.
Action sheets are themselves modal views: they temporarily pause the action and dim the main screen underneath until you choose an option. Because you must tap a button to move on, action sheets should always have a Cancel button to let people get out of there if they've changed their mind. The standard Cancel button is shaded slightly darker than other buttons and goes at the bottom of the action sheet, a good practice for both logical and ergonomic reasons. This bottom placement not only encourages people to read the other options first, but it also puts the button in the thumb's most comfortable tap zone. Be consistent on this. By making the Cancel button subtly easier to tap than the others and by always anchoring it in the same place, the "whoops, never mind" option is reliably easy to find, an understated protection against accidental taps.
Figure 5-35. In Instapaper's action sheet, the Archive action appropriately gets the red-button treatment even though it's not strictly a destructive action.
Destructive actions should always get similarly special treatment, with red-means-danger coloring and placement at the top of the sheet. This top placement makes a Delete button more visible while also putting it furthest from the thumb's hot zone to make a mistap less likely. Delete is the most common use of this red destruction button, particularly in confirmation action sheets, but it's appropriate to use it for other actions of similar permanence. Instapaper, for example, uses the red button to archive an article you're reading. Archiving doesn't actually delete the article from your Instapaper account, but it takes the article out of your reading flow by stashing it in a big bucket of already-read-it articles, a suitably major action to flag with the red button.
The text buttons of action sheets have the benefit of being explicitly descriptive—none of the guesswork that so often accompanies icon buttons—but the trade-off is that they present a slew of words to read at once. As you add more buttons, it's no longer a quick scan of options, and you ask more and more of your audience's neurons. Practically, of course, there's only so many buttons you can add anyway. It's wise to cap action sheets to five buttons, including the Cancel button, for both space and scannability. Even five buttons makes for a busy visual, though, presenting yet another opportunity to ask yourself: does this app really need all these features? As always, focus on primary activities and be ruthless about trimming unnecessary actions. If you still wind up with a list of five or more buttons, consider developing a custom alternative that's more compact and graphical than an action sheet (see Taming a Dense Thicket of Options for how Twitterrific tackled this).