Dialog

About

A Dialog is a pop-up window that prompts users with high importance information or requires users to take action. Users need to interact with a Dialog before they can proceed with the main content in the background.

Anatomy

A Dialog may exist of three slots:

• Header: a header is the top area of a Dialog. A header allows for a headline and has a mandatory close icon.
• Body: a body is the middle area of a Dialog. This is were a Dialog’s content lives. The content is fully customisable. A scroll container and bar might be added if the content makes a Dialog exceed the maximum width.
• Footer: a footer is the bottom area of a Dialog. A footer allows for buttons to allow users to take actions. A footer is not mandatory, since a Dialog may also be used for just sharing (critical) information.

Looking at the anatomy details, a Dialog exists of the following mandatory and optional elements:

1. Container
2. Close icon
3. Headline
4. Body text (optional)
5. Buttons (optional)
6. Background overlay

When to use a Dialog

Dialogs should be used for:

• Informing users about errors that block an apps’ operation;
• Requesting users for critical information that specifically requires their response or input.

When not to use a Dialog

• When the importance of the message isn’t high, consider other Notification components instead;
• When the information you want to communicate is contextual, consider other Notification components instead.

Behaviour

Variants

There are 3 different variants of a Dialog:

• Informative Dialog: this variant should be used for communicating critical information to users without the need for them to take any action. The only action that users can perform is closing a Dialog. There’s no need to use the footer slot in this variant.
• Confirmation Dialog: this variant allows users to provide input and then confirm or confirm something right away. The body slot would contain the information and/or input fields to enter data. The footer slot would contain buttons to take action such as confirming or canceling.
• Multistep Dialog: this variant should be used for Dialogs that need one or several extra steps, allowing users to go back and forth between those steps. It’s important that all slots are used (header, body, footer) and better alternatives are researched (e.g., full page) because of accessibility.

Multistep best practices

• Make sure each step uses the same Dialog size;
• The Back/Next button pattern should be used, which means it will be Secondary button/Primary button.

Modal behaviour

A Dialog always behaves modal. This means that a Dialog gets a background overlay indicating to users they cannot interact with the main content until the notification is closed.

Scroll behaviour

The body slot of a Dialog automatically gets scroll behaviour if the body content makes the height of a Dialog exceed. This means a native scroll bar will be visible. Users will be able to interact with this scroll bar to scroll down for more content.

Keyboard behaviour

• Users would be able to navigate through the interactive elements within a Dialog by pressing the Tab key and Arrow keys;
• Users would be able to close a Dialog by focusing on the close icon and press the Enter key;
• Users would be able to scroll through the body content with the focus on the scrollbar and using the Up and Down keys.
• Esc key

If there’s no input needed (informative variant) or provided yet, users are able to close a Dialog by pressing the Esc key. However, to ensure users won’t loose input, a Dialog cannot be closed by pressing the Esc key (by accident) when users have provided input already.

Size & placement

The width of a Dialog component spans between 375 - 800 px. You can use the default sizes to keep Dialogs in your UI more consistent. If needed you can adjust this as well, as long as the width is between this min-max span.

The height of Dialogs is flexible to their content but should not go over its max limits.

• Small: Width: 375 px, Height: depending on content (max 250 px)
• Medium: Width: 600 px, Height: depending on content (max 600 px)
• Large: Width: 800 px, Height: depending on content (max 720 px)

Figma usage

A Dialog in our Figma library can hold regular text or it can be used together with slot components, which will let you (designers) add their custom local components. For example, you can add a form as their content to place inside a Dialog.

Content

Headline

The headline should be short and convey a clear message.

Button labels

The button labels should allow users to understand the result of their action right away.

Button alignment

In a Dialog, buttons are left aligned as it is considered a best practice, for the following reasons:

• English text is read left to right and downwards, following an F-shaped pattern. Consequently, users often look towards the left edges as they scroll down;
• Right-aligned buttons can be overlooked, especially on large screens or by users employing screen magnification;
• Placing the most important button first reduces interaction cost for the majority of users.

Other best practices

Nesting components

A Dialog can use:

• Icon component
• Button component
• Input component
• Select component
• Checkbox component
• Radio button component
• Text area component
• Toast component

A Dialog can be used in:

• Notifications

Resources

• https://www.nngroup.com/articles/modal-nonmodal-dialog/
• https://www.nngroup.com/articles/popups/
• https://medium.theoremone.co/button-ambiguity-alignment-order-a42736e25334
• https://uxplanet.org/5-essential-ux-rules-for-dialog-design-4de258c22116
• https://carbondesignsystem.com/patterns/dialog-pattern/

In development backlog

The Dialog component is not yet released as a developed component. Usage documentation is published since Figma component is ready.