Dialog

Best practices

Although very similar to the Modal, the main difference is that a Dialog is primarily used when users are completing more complex tasks that require intensive interaction and focus. Tasks should be self contained, meaning that users should be ale to complete them without needing additional information on the page underneath.

Never, ever, display more than one Dialog at a time.

Do not use more than two buttons (primary and secondary). This prevents unclear action hierarchy and crowding on mobile screens.

When to use

• For lengthy or complex tasks, like larger forms and editing settings.
• To introduce information progressively through steps, revealing details as users advance in their tasks to avoid overwhelming them.
• To break users out of their flow to complete an action.

When not to use

• For crucial actions or information.
• For conditional decisions or actions.
• If there’s an existing Dialog already displayed. Never use more than one Dialog or Modal at a time.
• At points in the user journey that risk hindering progress, like checking out or payments.
• When the amount of content requires users to scroll, consider a page instead.

Make sure to select an overlay solution fitting of the context. To sense check and support a decision, this Decision tree chart and high-level overview of available options might be helpful.

Anatomy

1. Backdrop
2. Modal surface
3. Heading – The Dialog title
4. Content body – The items necessary for completing tasks.
5. Footer – Contains a primary action and the ability to cancel and close the modal, alternatively a previous and next action.
6. Close button

Behaviour

Dismissal

Dialogs close when users press the X button, a Cancel button, the Esc key, or, in some cases, when users click or tap the area outside the modal. On Mobile, a swipe-down gesture also closes the modal.Content guidelines

Animation & motion

All Dialogs are animate as they enter and leave the view. As they enter, the backdrop fades in slightly before the container fades in with a slide up motion. This staggered effect should help the user to find focus more easily. When the Dialog leaves the view, the inverse staggered effect aims to help the user orient themselves back to the page content.

On mobile, all motion happens in one single event – no staggering.

Overflow

Page overflow – the Dialog container expands below the visible window area and scrolling moves the entire container up and down, just like a page. This means that the headline and cross icon, as well as the footer with all actions, can be out of reach for users.

Container overflow – the Dialog container expands only within the visible window area. After that, headline and footer remain visible while the inner container becomes scrollable. This means actions are always available to users without any additional interaction.

Desktop

Dialogs on desktop scroll inside the container, making the headline and actions available at all times.

Mobile

Dialogs on mobile support both page and container overflows.

Responsive behaviour

All Dialogs types and sizes are responsive up to a max-width, which is the initial size straight out of the library. When adding contents, respect the dimensions set by the modal to maintain responsiveness.

Focus

When the Dialog opens, focus moves to an element contained in it (by default, the first element that can be focused), and the focus should stay in and cycle through the Dialog's content. Focus shouldn't return to the underlying page until the user closes the Dialog.

Content guidelines

Headline

Headline should display the title of the content, process, or task.

Body

Primarily task oriented content, typically form elements, are recommended. See Forms for more guidance.

Button group

Avoid offering more than one primary action and a cancel action. In rare cases when necessary, primary and secondary buttons can be used with a tertiary button for cancel.

Alignment – Buttons are right aligned or along the edges of progressive Dialogs.

Sort order – Always begin with primary actions and continue in order of importance.

Progressive disclosure

Sometimes, it’s better to split up large and complex tasks into smaller more digestible sections. In such cases, sort order is turned around to give a sense of forward motion and encourage users progress with the tasks.

Variants

Default

Default Dialogs are used for tasks that require more than one form element. These elements allow users to affect or interact within a specific section without having access to the main interface flow. User interaction is task and process related.

Progressive dialog

Progressive Dialogs are used for complex processes that benefit from being broken up into smaller steps to avoid overloading users. Users progress with “next” and “previous” actions.

Custom dialog

This type of Dialog is available so that designers are able to create Dialogs with content specific to the context they’re designing solutions for. With this flexibility also comes the responsibility to make sure content guidelines are followed.

To use this variant, create a component with the custom content. Select the slot component and make an instance swap.

Size

Small

Dialogs are limited to size Small to better support form elements and single line editing. Dialogs are responsive up to their max-width, which is the initial size straight out of the library.

Mobile

Unlike Modals, Dialogs on mobile take up the full screen width. This is to provide more space as content is task oriented and typically interactive. Dialogs are responsive up to their max-width, which is the initial size straight out of the library.

Articles

Button Ambiguity: Alignment & Order – Jon Lehman on Medium

Best Practices For Modal Window Design - Nick Babich on UX Planet

Modal & Nonmodal Dialogs: When (& When Not) to Use Them – NNg