Safari Developer Library

Developer

iOS 7 Design Resources iOS Human Interface Guidelines

Download PDF

Temporary Views

Alert

An alert gives people important information that affects their use of an app or the device.

image: ../Art/alert_2x.png

An alert:

  • Displays a required title and an optional message

  • Contains one or more buttons

The infrequency with which alerts appear helps users take them seriously. It’s best to minimize the number of alerts your app displays, and make sure each one offers critical information and useful choices.

Avoid creating unnecessary alerts. In general, alerts are unnecessary in the following scenarios:

If an alert does this...

Do this instead of using an alert...

Provides information related to the standard functioning of an app

Design an eye-catching way to display the information, one that harmonizes with the app’s style.

Updates users on tasks that are progressing normally

Use a progress view or activity indicator (described in Progress View and Activity Indicator) or integrate status information into the app UI.

Asks for confirmation of user-initiated tasks

Use an action sheet (described in Action Sheet).

Informs users of problems they can do nothing about

If the problem isn’t critical, integrate the information into the app’s UI; otherwise, use an alert.

As you read the guidelines for designing alert text, it’s useful to know the following definitions:

  • Title-style capitalization means that every word is capitalized, except articles, coordinating conjunctions, and prepositions of four or fewer letters when they aren’t the first word.

  • Sentence-style capitalization means that the first word is capitalized, and the rest of the words are lowercase unless they are proper nouns or proper adjectives.

Succinctly describe the situation and explain what people can do about it. Ideally, the text you write gives people enough context to understand why the alert has appeared and to decide which button to tap.

image: ../Art/alert_title_only_2x.png

Keep the title short enough to display on a single line, if possible. A long alert title is difficult for people to read quickly, and it might get truncated or force the alert message to scroll.

Avoid single-word titles. Single-word titles, such as Error or Warning, rarely provide any useful information.

When possible, use a sentence fragment. A short, informative statement tends to be easier to understand than a complete sentence.

As much as possible, write a title that makes it unnecessary to add a message. For example, you might be able to avoid adding a message if you use a question—or, less frequently, two sentences—for the alert title.

Don’t hesitate to be negative. People understand that most alerts tell them about problems or warn them about dangerous situations. It’s better to be negative and direct than it is to be positive but oblique.

As much as possible, avoid “you,” “your,” “me,” and “my.” Sometimes, text that identifies people directly can be ambiguous and can even be interpreted as insulting or patronizing.

Use capitalization and punctuation appropriately. Specifically:

When the alert title...

Use...

Is a sentence fragment or a single sentence that is not a question

Title-style capitalization and no ending punctuation

Is a single sentence that is a question

Sentence-style capitalization and an ending question mark

Consists of two or more sentences

Sentence-style capitalization and appropriate ending punctuation for each sentence

If you must provide an optional alert message, write a short, complete sentence. If possible, keep the message short enough to be displayed on one or two lines. If the message is too long, it will scroll, giving users a poor experience. Use sentence-style capitalization and appropriate ending punctuation in the message.

image: ../Art/alert_title_with_msg_2x.png

Avoid lengthening alert text with descriptions of which button to tap. Ideally, the combination of unambiguous alert text and logical button labels gives people enough information to understand the situation and their choices. If you must provide detailed guidance, follow these guidelines:

  • Be sure to use the word “tap” (not “touch” or “click” or “choose”) to describe the selection action.

  • Don’t enclose a button title in quotation marks, but do preserve its capitalization.

Be sure to test the appearance of an alert in both orientations. Because in landscape the height of an alert is constrained, the alert’s appearance may differ from its appearance in portrait. It’s recommended that you optimize the length of the alert text so that it can be read without scrolling no matter what the orientation.

image: ../Art/two_button_alert_2x.png

Generally, use a two-button alert. A two-button alert is often the most useful, because it’s easiest for people to choose between two alternatives. A single button alert is less likely to be helpful because it informs people without giving them any control over the situation. An alert that contains three or more buttons is significantly more complex than a two-button alert and should be avoided as much as possible. If you add too many buttons to an alert, it can cause the alert to scroll, which is a bad user experience.

Place buttons appropriately. Ideally, the button that's most natural to tap should meet two criteria: It should perform the action that users are most likely to want and it should be the least likely to cause problems if a user taps it inadvertently. Specifically:

  • When the most likely button performs a nondestructive action, it should be on the right in a two-button alert. The button that cancels this action should be on the left.

  • When the most likely button performs a destructive action, it should be on the left in a two-button alert. The button that cancels this action should be on the right.

Give alert buttons short, logical titles. The best button titles consist of one or two words that describe the result of tapping the button. Follow these guidelines as you create titles for alert buttons:

  • As with all button titles, use title-style capitalization and no ending punctuation.

  • As much as possible, use verbs and verb phrases that relate directly to the alert text—for example, “Cancel,” “View All,” “Reply,” or “Ignore.”

  • Use “OK” for a simple acceptance option if there is no better alternative. Avoid using “Yes” or “No.”

  • Avoid “you,” “your,” “me,” and “my” as much as possible. Button titles that use these words are often ambiguous and can appear patronizing.

Action Sheet

An action sheet displays a set of choices related to a task the user initiates.

On iPhone, an action sheet emerges from the bottom of the screen

image: ../Art/action_sheet_iphone_2x.png

On iPad, an action sheet is always displayed in a popover

image: ../Art/action_sheet_ipad.pdf

An action sheet:

  • Appears as the result of a user action

  • Displays two or more buttons

Use an action sheet to:

  • Provide alternative ways to complete a task. An action sheet lets you to provide a range of choices that make sense in the context of the current task, without giving these choices a permanent place in the UI.

  • Get confirmation before completing a potentially dangerous task. An action sheet prompts users to think about the potentially dangerous effects of the step they’re about to take and gives them some alternatives.

On iPhone, include a Cancel button so that users can easily and safely abandon the task. Place the Cancel button at the bottom of the action sheet to encourage users to read through all the alternatives before making a choice.

On iPad, base the way the action sheet is displayed on the way the user initiates the task. Specifically:

If the task is initiated from...

Display the action sheet...

Include a Cancel button?

Outside of a popover

Without animation—that is, the action sheet and the popover appear simultaneously

No, because users can tap outside the popover to dismiss the action sheet

Inside a popover

With animation—that is, the action sheet slides up on top of the popover’s content

Yes, because users need to be able to dismiss the action sheet without closing the popover

On all devices, use red for the button that performs a potentially destructive action. Display a red button at the top of the action sheet, because the closer to the top of the action sheet a button is, the more eye-catching it is. And on iPhone, the farther a destructive button is from the bottom of an action sheet, the less likely users are to tap it when they’re aiming for the Home button.

image: ../Art/action_sheet_red_button_2x.png

Avoid making users scroll an action sheet. If you include too many buttons in an action sheet, users must scroll to see all their choices. This is a disconcerting experience for users, because they must spend extra time to distinguish the choices. Also, it can be very difficult for users to scroll without inadvertently tapping a button.

Modal View

A modal view—that is, a view presented modally—provides self-contained functionality in the context of the current task or workflow.

image: ../Art/modal_view_mail_compose_2x.png

A modal view:

  • Occupies the entire screen or, on iPad, can occupy the entire area of a parent view (such as a popover)

  • Contains the text and controls that are necessary to complete the task

  • Usually displays a button that completes the task and dismisses the view and a Cancel button that abandons the task and dismisses the view

Use a modal view when you need to offer the ability to accomplish a self-contained task related to your app’s primary function. A modal view is especially appropriate for a multistep subtask that requires UI elements that don’t belong in the main app UI all the time.

On iPad, choose a modal view style that suits the current task and the visual style of your app. You can use any of these styles, defined here:

Modal view style

Appearance

Recommended for

Full screen

Covers the entire screen.

Presenting a potentially complex task that people can complete within the context of the modal view.

Page sheet

Has a fixed width of 768 points; the sheet height is the current height of the screen.

In landscape, the area of the screen that’s visible on both sides of the modal view is dimmed.

Presenting a potentially complex task that people can complete within the context of the modal view.

Form sheet

Has fixed dimensions of 540 x 620 points and is centered in the screen.

When the keyboard is visible in landscape, a form sheet modal view moves up to just below the status bar.

Gathering structured information from the user.

Current context

Uses the same size as its parent view.

Displaying modal content within a split view pane, popover, or other non–full–screen view.

On iPad, don’t display a modal view on top of a popover. With the possible exception of an alert, nothing should display on top of a popover. In rare cases when you might need to display a modal view as a result of an action the user takes in a popover, close the popover before you open the modal view.

On iPhone, coordinate the overall look of a modal view with the appearance of your app. For example, a modal view often includes a navigation bar that contains a title and buttons that cancel or complete the modal view’s task. When this is the case, the navigation bar should use the same appearance as the navigation bar in the app.

On all devices, display a title that identifies the task, if appropriate. You might also display text in other areas of the view that more fully describes the task or provides some guidance.

On all devices, choose an appropriate transition style for revealing the modal view. Use a style that coordinates with your app and enhances the user’s awareness of the temporary context shift that the modal view represents. To do this, you can specify one of the following transition styles:

  • Vertical. In the vertical style, the modal view slides up from the bottom edge of the screen and slides back down when dismissed (this is the default transition style).

  • Flip. In the flip style, the current view flips horizontally from right to left to reveal the modal view. Visually, the modal view looks as if it is the back of the current view. When the modal view is dismissed, it flips horizontally from left to right, revealing the previous view.

If you vary the transition styles for modal views in an app, do so in a way that makes sense to users. Users are quick to notice behavioral differences in an app and will assume that they mean something. It’s best to establish a logical, consistent pattern that users can easily detect and remember, and avoid changing transition styles without a good reason.