Components-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.
Behavior:¶
They retain focus until dismissed or a required action has been taken.
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 :¶
Beyond standard dialogs :¶
Dialogs are a sub-type of modal windows, and the examples covered here are for standard material system 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. 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.
Scrollable content exception¶
Some dialog content requires scrolling, such as lists of ringtones.
Displaying additional content¶
Use Inline Expansion with in the Content area to view additional content in dialog. 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.
Alerts¶
Alerts are urgent interruptions, requiring acknowledgement, that inform the user about a situation.
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 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¶
Mobile and tablet only
Simple dialogs¶
Simple dialogs can provide additional details or actions about a list item.
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.
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.
Confirmation dialogs¶
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.
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.Tapping the cancel button, Back button, or leaving the confirmation dialog will discard changes.
Full-screen dialogs¶
Mobile Only.
Specs¶
For specs of Component-DIalogs Click Here.