Dialogs

Reduce interruption

Use dialogs sparingly because they are interruptive. Their sudden appearance forces users to stop their current task and focus on the dialog content. Not every choice, setting, or detail warrants interruption. Alternatives to dialogs include menus or inline expansion, both of which maintain the current context.

Dialog prominence

Dialogs should never be obscured by other elements or appear partially on screen. Dialogs always retain focus until dismissed or a required action has been taken, such as choosing a setting.

Dialogs should avoid:

• Opening dialogs from within a dialog
• Containing scrolling content

Full-screen dialog exception

Full-screen dialogs may open additional dialogs, such as pickers, because their design accommodates additional layers of material without significantly increasing the app’s perceived z-depth or visual noise.

Alerts without title bars

Most alerts don't need titles.

They summarize a decision in a sentence or two by either:

• Asking a question (e.g. "Delete this conversation?")
• Making a statement related to the action buttons

Alerts with title bars

Use title bar alerts only for high-risk situations, such as the potential loss of connectivity. Users should be able to understand the choices based on the title and button text alone.

If a title is required:

• Use a clear question or statement with an explanation in the content area, such as "Erase USB storage?".
• Avoid apologies, ambiguity, or questions, such as “Warning!” or “Are you sure?”

Simple menus display options for list items, and they immediately commit choices upon selection. See Components > Menus > Simple Menus for more details.

Disambiguation: Simple dialogs display detailed options for list items or provide related actions. Simple dialogs can display the same content as simple menus. However, simple menus are preferred because they are less disruptive to the user’s current context.

Simple dialogs can provide additional details or actions about a list item. For example, they can display avatars, icons, clarifying subtext, or orthogonal actions (such as adding an account).

Touch mechanics:

• Choosing an option immediately commits the option and closes the menu
• Touching outside of the dialog, or pressing Back, cancels the action and closes the dialog

Reduce interruption

Simple dialogs are more interruptive than simple menus and should be used sparingly.

No explicit cancel button

Simple dialogs do not have explicit buttons that accept or cancel an operation.

Confirmation dialogs require users to explicitly confirm their choice before an option is committed. For example, users can listen to multiple ringtones but only make a final selection upon touching “OK.”

Touching “Cancel” in a confirmation dialog, or pressing Back, cancels the action, discards any changes, and closes the dialog.

Confirm a single value

Confirmation dialogs can use layouts other than lists, such as a date picker, but remain focused on specifying a single value (picking the date, but not picking the time and date).

Cancel and confirmation buttons

Confirmation dialogs provide both an explicit confirmation button and explicit cancel button. Touching the cancel button, Back button, or leaving the confirmation dialog will discard changes.

Avoid dialogs launching dialogs

Confirmation dialogs should avoid launching additional simple dialogs or simple menus, as they increase the app’s perceived z-depth and add visual complexity. If they are needed to complete a task, consider using a full-screen dialog instead.

Usage

Full-screen dialogs group a series of tasks (such as creating a calendar entry) before they may be committed or discarded. No selections are saved until “Save” is touched. Touching the “X” discards all changes and exits the dialog.

Full-screen dialogs enable complex layouts, minimize the appearance of stacked sheets of material (dialogs above dialogs), and temporarily reset the app’s perceived elevation to a higher baseline. They allow tasks to launch simple menus or simple dialogs as part of a complex operation.

Full-screen dialogs may be used for content or tasks that meet any of these criteria:

• The dialog includes components (like pickers or form fields) that require an input method editor (IME), such as a keyboard.
• When changes are not saved in real time
• When there is no draft capability in the app
• When performing batch operations or queuing changes prior to submitting them

Actions

Place confirmation and dismissive actions for full-screen dialogs at the top of the screen.

Confirmation

The confirmation action in the top right of the screen uses descriptive verbs, such as: save, send, share, update or create. Don’t use vague actions for confirming action, such as: done, ok or close.

The confirmation action is disabled until all mandatory fields in the dialog are met.

Discard

Both the discard action (the “X” at the top left of the screen) and the Back button close the full-screen dialog and discard changes.

• If no changes have been made, the dialog closes and no discard confirmation is required.
• If the user has made any changes, they are prompted to confirm the discard action.

Navigation

The “X” used in a full-screen dialog differs from an up arrow, which indicates the view’s state is constantly being saved. For example, an up arrow used in Settings indicates all changes are committed immediately without explicit confirmation or cancel actions.

Titles

Full-screen dialog titles don’t use dynamic type.

Titles should be succinct. They can wrap to a second line if necessary, and should then be truncated.

If the full-screen dialog uses titles of variable length or anticipates long titles (for example, because certain words are longer in different languages), place title text in the content area of the dialog instead of the app bar.