UIKit offers a lot of flexibility in the way an
application notifies users of events, errors, or state changes such as
losing Internet connectivity. The most obvious is a class called UIAlertView, which displays a pop-up box
that shows the alert message along with one or more buttons that must be
clicked to dismiss the box. Alerts are modal, which means they are
presented on top of the current view, often blocking all interaction with
the current application and stealing the focus of a user.
Another type of modal alert is an action sheet, invoked with the
UIActionSheet class. An action sheet is similar to an
alert box in its effect, but it has a different look. Action sheets can
contain many buttons and shouldn’t display text. Designers use action
sheets primarily to let users confirm an action. For example, the Mail
application uses action sheets to confirm the deletion of an email.
The bullhorn anti-pattern is the overuse of alerts that require
users to make choices or otherwise manually dismiss the alert. In other
words, the pattern causes disruptive notices that shouldn’t merit such
brute-force methods.
Examples of user interaction that probably don’t require taking
control of the interface and monopolizing user attention are:
Switching from Wi-Fi to 3G or 2G service, or losing
connectivity.
Touching an illegal square in a chess game.
The end of a turn or round in a game.
A form submission failing due to a typo.
A successful post to a web service.
Any successful operation.
Events do occur that may have significance for users, but you should
still avoid shouting the news. The cell signal strength indicator or
Internet access indicator in the status bar are excellent examples of
passive indication. Other good options are as follows:
Inline messaging and highlighted form fields can signal problems
with user input.
Subtle sounds can communicate that a game piece has been moved
to the wrong space. Even better, you can simply reject the move and
animate the piece back to its original location.
You can use a passive visual cue like a checkmark instead of a
progress indicator when a Twitter submission succeeds.
You can change the text of a button if a download fails. For
example, change “Update Feeds” to “Retry Feed Update” if the first
attempt fails.
Figure 1 shows a timeout error in
Tweetie, an excellent Twitter client. An alternative to
using an alert could be to display a concise but meaningful message in the
main view, perhaps with an option to try again.
Figure 2 shows two alerts used in the
Black and White application.
Generally, alerts should be no more forceful than the impact of the
event. An alert box not only sends a device-level notice to users, but it
also requires users to acknowledge the error by clicking an “OK” button.
There are excellent cases for such a disruptive notice, but such cases are rare.
The iPhone elegantly communicates the current battery level to users. The battery level indicator is a
small, passive icon in the status bar. When the available power drops
below 20%, an alert box notifies the user. This is especially useful when
a user is immersed in a full-screen experience, such as an OpenGL game or
a video podcast. A second alert shows when the battery reaches 10%. Apple
chooses not to bother users unless there is a risk of the battery dying.
The same judicious restraint should be used for alerts in iPhone
applications.
Figure 3 shows subtle messaging of
network failures in two Apple applications: Stocks and App Store.
