APPS SHOULD BE GOOD LISTENERS. Tapworthy apps pay careful attention to touchscreen instructions and then dutifully deliver the requested info, gameplay, or action. Every so often, though, apps pipe up with commentary of their own: an alert warns something has gone wrong, a push notification announces a news headline, a progress bar says work is underway. There are lots of ways your app can get its message across, and the voice and method you choose has both practical and personal impact. Does your app shout or whisper? Does it interrupt the action or slip a subtle note? Etiquette matters, even to apps, and politesse requires careful thought about both words and manner.
Etiquette maven Emily Post shared her secret for good conversation nearly a century ago, and her lesson turns out to apply as well to apps as it does to people: "There is a simple rule, by which one can at least refrain from being a pest or a bore. And the rule is merely, to stop and think. Think before you speak. Nearly all the faults or mistakes in conversation are caused by not thinking."
This chapter helps you do that thinking by taking your app to iPhone charm school to review the art of polite conversation. You'll review the iPhone's communication conventions, including the discreet use of alerts, notifications, activity indicators, and progress bars. Most of all, you'll discover how to signal important info to your audience without slowing them down or, worse, getting on their nerves.
An alert is an app's emergency brake. It's the blue box that pops up in the middle of the screen, stops the action, and makes an announcement. Like a modal view (page 117) or action sheet (page 169), an alert interrupts the flow and demands attention. That's why they're also called modal alerts. Until you specifically dismiss the alert, you can't continue using the app—which means the alert better be worth it.
Figure 10-2. Three different uses of alert boxes. The app can't go (left): Stitcher is an app for streaming Internet radio and appropriately displays an alert when you request local stations outside of its supported area. Suggest a workaround (middle): the Settings app offers a way around an email problem. Ask permission (right): the iPhone checks to make sure it's okay before sharing your location with an app.
Don't use modal alerts lightly. Alerts are for urgent information and using them for mundane announcements is like calling 911 to ask for the time. Don't cry wolf: trivial messages train people to ignore alerts and tap through them. When something truly important happens, your alert may go unnoticed as a result. Here are some appropriate uses for alerts:
The app can't go. When something is very wrong, or when conditions prevent the app from working at all, show an alert. If your location-based app doesn't work in the current country, for example, or if there's not enough data available to perform an action, an alert is the place to say why. In general, avoid using alerts for more transient issues like a flaky network connection. Instead, limit alerts to more fundamental problems that prevent the app or feature from working, period.
A little help here? An alert is the right place for an app to ask for assistance if it can't complete a requested task. If airplane mode is turned on when you ask to download data, for example, an alert offers to take you to the Settings app to turn it off. The best alerts suggest a workaround when there's a problem: this isn't working; want to try another way? You do this by adding buttons to the alert box, typically just two of them: 1) a default button to dismiss the alert and cancel the action, and 2) a button to trigger the alternate action. Avoid crowding more than two buttons into an alert; if you need additional options, an action sheet is usually more appropriate.
Permission please. Use an alert box to check before doing something the user might not be aware of—and could regret. Protecting privacy is a common example: the iPhone OS, for example, asks for permission before allowing an app to share your location. You should likewise do the same if your app wants to soak up other personal info behind the scenes, like contacts or events. If an action may have a consequence that your user doesn't anticipate, you should also ask for permission. In Safari, for example, clicking the Back button to a page that will resubmit a form triggers an alert to let you know and ask if it's okay to go ahead.
There's a subtle difference between this style of asking for permission and confirmation messages of the "do you really want to delete that?" flavor. Use alerts for events and warnings that your audience probably didn't see coming—conditions that are not a direct result of their own actions. Think of alerts as interruptions that break into the flow of normal events to announce unexpected breaking news. Confirmation messages, on the other hand, are the direct result of a specific request. You should instead handle those with action sheets, as described in Multiple Choice: Pickers, Lists, and Action Sheets.
Alas, alerts are easy for developers to code—easier than coding an entire screen, at least—and we all love easy. The irresistible appeal of the lazy way out makes alerts all too common for relatively unimportant messages. Here are some uses to resist:
Don't use an alert as a welcome screen. As you learned in Chapter 7, it's always great to roll out the welcome wagon for first-timers, but introductory tips and instructions are best accomplished with a purpose-built welcome screen, not an alert. The subtext of an alert is "something's wrong"—not a great vibe to strike on an app's first launch.
Don't ask for an App Store rating. Some apps pop up an alert box at occasional intervals to encourage you to rate the app on the App Store. Hey, we've all gotta make a buck, but interrupting me to ask for some stroking is neither welcome nor polite. Always keep the focus on the user's goals and tasks—don't make it about you. If you're determined to include an App Store link, tuck it away in an "About Us" screen in the app's settings.
Don't use alerts for fleeting foibles. Avoid sounding the alarm for passing problems like flaky network connections or a missing GPS signal. While you shouldn't stay quiet about these issues, alerts aren't the way to go. Instead, find other opportunities in the interface to indicate trouble instead of the full-throated shout of an alert box. The Twitter app, for example, briefly flashes an error message instead of using an alert that would require a tap to dismiss. (Bad networks, cloudy days, and just plain bad luck do occur—and frequently—in the chaotic and variable environments of your mobile app. Be sure to test your app under lousy conditions, including airplane mode, to make sure that it handles problems gracefully.)