Components – Dialogs

Dialogs

Dialogs inform users about a specific task and may contain critical information, require decisions, or involve multiple tasks.

Dialogs contain text and UI controls. They retain focus until dismissed or a required action has been taken. Use dialogs sparingly because they are interruptive.

Some dialog types include:

  • Alerts are urgent interruptions that inform about a situation and require acknowledgement.
  • Simple menus display options for list items, whereas simple dialogs can provide details or actions about a list item.
  • Confirmation dialogs require users to explicitly confirm a choice.

Behavior

Dialogs should never be obscured, either by other elements or the screen edge. Dialogs always retain focus until dismissed or a required action has been taken.

Full-screen dialogs (Mobile only)

Full-screen dialogs are best suited to complex tasks, or require an input method editor, as they group a series of tasks together before they can be saved.

Behavior Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Beyond standard dialogs

Dialogs are a sub-type of modal windows, and the examples covered here are for standard material system dialogs. (Other modal window constructions aren’t covered here because they have too much variation, such as branded buttons for purchasing flows, non-standard UI form elements, or unique layouts.)

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.

Example of dialog content

Example of a full-screen dialog

Scrollable content exception

Some dialog content requires scrolling, such as lists of ringtones.

  • For scrollable lists of options, the dialog title remains pinned to the top. This ensures that a selected item remains visible with the title, regardless of the item’s position in the list.
  • Otherwise, the title scrolls off with the content. Actions always remain in place when content scrolls.

Dialogs are separate from the underlying parent material and do not scroll with it.

Displaying additional content

To disclose additional content in a dialog, do so using inline expansion within the content area. Or consider alternative components that are optimized for large amounts of content.

Dismissing dialogs

Dialogs may be dismissed either by tapping outside of the dialog, or tapping the system back button (on Android). Alternatively, the user’s ability to dismiss a dialog may be disabled, so that one of the actions must be chosen before proceeding.

Make the dialog title fixed when viewing a scrollable list of options ensures that both the title and the selected item are simultaneously visible.

Alerts Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Alerts are urgent interruptions, requiring acknowledgement, that inform the user about a situation.

Disambiguation from Snackbars: Snackbars present optional information after an action, such as confirming the discarding of a draft. They often allow a user to undo an action just taken.

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

Do.

The affirmative action text “Discard” clearly indicates the outcome of the decision.

Don’t.

The dismissive action text “No” answers the question, but does not suggest what will happen afterwards. A better action pair would be an explicit “Cancel” and “Delete.”

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?”

Do.

This dialog poses a specific question, concisely elaborates on its impact, and provides clear actions.

Don’t.

This dialog poses an ambiguous question and its scope of impact is unclear.

Simple menus Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Mobile and tablet only

Simple menus display options for list items, and they immediately commit choices upon selection. See 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.

Examples of a simple menu

Simple dialogs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

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.

Example of a simple dialog

On mobile, a dialog’s width is based on a multiple of a unit. That unit can be either:

  • An increment
  • A specific distance from the screen edge

No explicit cancel button

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

Don’t.

This simple dialog has an explicit “Cancel” button.

Don’t.

This simple dialog has an explicit “Cancel” button.

Specifications

  • Row heights can vary in simple dialogs
  • Simple dialogs are displayed centered vertically and horizontally on the screen.
  • The dialog's distance from the screen edge is at least 40dp on the left and right, and at least 24dp on the top and bottom
  • The dialog's content is 24dp from the dialog edge

Avoid text wrapping

If any text in a simple menu wraps to another line, use a simple dialog instead.

Do.

This simple dialog has varying row heights.

Confirmation dialogs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

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.”

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

Avoid dialogs launching dialogs

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

The ringtone choice in the following confirmation dialog will not be set until the user taps “OK.”

Example of a confirmation dialog with controls positioned on the left side of text.

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).

The date choice is set by the user tapping a date and the “OK” button.

The user selects the hour by moving the clock hand and tapping “OK.”

Cancel and confirmation buttons

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

Do.

Provide explicit confirmation and cancel buttons.

Don’t.

A single dialog button makes the system Back action ambiguous: does Back cancel or confirm?

Full-screen dialogs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Mobile only: Due to limited space, full-screen dialogs may be more appropriate for mobile devices than dialogs used on devices with larger screens.

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

The full-screen dialog supports a simple dialog used to pick dates.

Date picker opened from full-screen dialog

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

Don’t.

Don’t use vague terms like “Close” for confirmation actions.

Do.

Prompt users to confirm the discard action if they have made any changes.

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.

The up arrow in this Settings example indicates that any changes will be immediately saved upon selection.

Touching the “X” in this Settings example will discard all changes. Changes will be saved only upon touching Save.

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.

Don’t.

Avoid using titles of variable length in the app bar.

Do.

Place long titles in the content area of the full-screen dialog.

Specs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Dialogs contain content, actions, and an optional title.

Optional title

The title briefly describes the type of choice being made. Titles should always be displayed in their entirety and only used when necessary. For example, a title may indicate to which part of a task the dialog relates, or identify what will be affected by the decision.

Content

Dialog content typically consists of text and/or UI control elements. It is focused on a specific task, such as confirming item deletion or choosing a setting.

This dialog contains a title, content, and actions.

Actions

Dialogs present a focused and limited set of actions, which are generally affirmative or dismissive.

  • Affirmative actions are placed on the right side and continue the process. Affirmative actions may be destructive, like “Delete” or “Remove.”
  • Dismissive actions are placed directly to the left of affirmative actions and return the user to the originating screen or step in the process
  • Dismissive and affirmative action text can be “Cancel”/“OK” or specific active verbs or verb phrases that indicate the outcome of the decision.

Don’t.

Dismissive actions are always placed directly to the left of affirmative actions.

Dialog actions should present a clear choice directly related to the dialog’s title and content.

Don’t.

Avoid presenting users with ambiguous or unclear choices. In this example, “Cancel” doesn't make sense in relation to the title because there's no clear action being proposed.

Acknowledgement actions

In situations where users are required to acknowledge the dialog’s content to proceed, an alert may contain only one action. Use this type of alert sparingly as it is interruptive. Consider other methods of communicating the information to users, such as in-line with a view’s content.

Number of actions

Dialogs should not include more than two actions. A third action, such as “Learn more,” navigates away from the dialog, potentially leaving the task unfinished.

Avoid using a “Learn more” action to access help documentation; in-line expansion within the dialog should be used instead. If more extensive information is needed, provide it prior to entering the dialog.

Don’t.

The “Learn more” action navigates away from this dialog, leaving it in an indeterminate state.

Color

Dialog actions use system colors by default, but they should reflect your product's color palette. Use a contrasting color, such as the palette’s accent color, to distinguish dialog actions from dialog content.

Languages without capitalization

For languages without capitalization (such as Chinese, Japanese or Korean), it is important to maintain consistent placement, spacing, and colors for actions to distinguish them from regular text.

The consistent placement of actions and text color helps distinguish actions from regular text even when the affirmative action is disabled.

Affirmative actions are more likely to be disabled until a choice is made. Dismissive actions are never disabled.

Content guidelines

Padding around content area: 24dp
Padding between title and body text: 20dp
Padding around buttons: 8dp
Button height: 36dp
Action area height: 52dp
Dialog elevation: 24dp

Content padding

Within the content area, the 24dp of padding below the content helps separate it from the actions.

Dialog content bottom padding: 24dp
Button height: 36dp
Button margin: 8dp

Content padding for a dialog in a scrolled state

Button width and padding

Button height: 36dp
Minimum button width: 64dp
Internal button padding: 8dp
Padding between buttons: 8dp

Detail of button widths and padding

Button height: 36dp
Button area height: 52dp
Left button padding: 24dp
Right button padding: 8dp
Padding between buttons: 8dp

Detail of button area

In a scrolled state, a stroke delineates the dialog’s content area from actions.

Side-by-side buttons

Side-by-side buttons are recommended when the text of each label does not exceed the maximum button width, such as the commonly used OK/Cancel buttons.

Use the following formula to calculate maximum button width for a given dialog:

The maximum width for buttons in a dialog =

(Dialog width - 8dp - 8dp - 8dp)/2

For example:

The maximum width for buttons in a 280dp wide dialog =

(280dp - 8dp - 8dp - 8dp)/2 = 128dp

Button height: 36dp
Padding between text and action area: 24dp
Padding around buttons is: 8dp

Stacked full-width buttons

When text labels exceed the maximum button width, use stacked buttons to accommodate the text. Affirmative actions are stacked above dismissive actions.

Touchable target height for each button: 48dp
Padding between text and touch target: 24dp
Padding below touch target to dialog edge: 8dp
Padding between button text right edge and dialog edge: 16dp

Simple dialog keylines

Vertical keyline at 24dp from the left and right edges. Content associated with an icon or avatar aligns 80dp from the left edge.

Keylines for a simple dialog

Simple dialog content guidelines

It is recommended that simple dialogs have titles, but titles can be omitted based on your product’s needs.

Title

  • Top padding: 24dp
  • Bottom padding: 20dp
  • Text size: Roboto Medium 20sp
  • Text line height: 28dp

Content

  • Row height of single-line list with avatars: 56dp
  • Bottom edge padding: 8dp

redlines for a simple dialog

Full-screen dialog titles

Full-screen dialog titles can wrap to a second line if necessary, and then should be truncated. Titles should be succinct, but in some situations, such as when words are longer in different languages, titles may need to wrap.


App bar height with a single line of text: 56dp
App bar height with two lines of text: 80dp
Title text keyline: 72dp
Title text: 20sp
Title text top and bottom padding: 20dp
Dismissive action padding from left edge: 16dp
Affirmative action text: 14sp
Affirmative action text padding on the left and right: 16dp

Detail of a full-screen dialog app bar

Full-screen dialog with an app bar containing a single line of text.

Note that this image is for illustration purposes only. Long titles should be placed in the content area of the full-screen dialog.