Dialog
Dialogs initiate a conversation between the service and the user. They are used when an input or a confirmation is needed from the user or when important information needs to be conveyed.
Usage
Example
Principles
- Dialogs capture the browser focus and the user is forced to react to the dialog.
- To emphasize this, a dark screen overlay must be used to cover the view content behind the dialog element.
- Dialogs are a very intrusive pattern and they should only be used when the immediate actions or focus from the user are needed.
- Be careful when including a separate close ("x") icon in the dialog. If there are more than one action available in the dialog, it can be ambiguous for the user which action is triggered when the close icon is pressed.
- Generally, it is a good practise to omit the close icon if the dialog has more than one action available.
- If your dialog contains form elements, follow HDS form and form validation patterns similarly as you would in a regular forms.
- As dialogs always contain buttons, pay close attention that the button labels describe the action it is going to trigger. You can read more information about this in the HDS Button documentation page.
- Following the same guidelines as the HDS Form pattern, dialog action buttons are placed at the left side of the dialog and the primary action will be the first one from the left.
- If some of the actions are destructive or irreversible, the button order should be reversed so so that the destructive actions are last in the button list. See Danger dialog example for more information.
- Opening a dialog should be always triggered by the user. Do not open dialogs without user action.
- Also make sure that the dialog is related to the current context.
- It is not recommended to open dialogs on top of other dialogs. However, this is supported by HDS Dialogs if it is needed.
When to use each dialog type?
| Type | When to use it? | Example |
|---|---|---|
| Info | Important information needs to be conveyed to the user. Only requires acknowledgment and no choices from the user. | Informing the user about changed terms of use. |
| Confirm | An action is required from the user. | Confirming that the user wants to continue even though all form fields are not filled. |
| Danger | An action is required from the user while the action results are destructive. | Confirming that the user wants to delete a blog post. |
Variations
Info dialog
Info dialogs are used to convey important information to the user. Info dialogs only include one button which the user can use to acknowledge the information.
Confirm dialog
Confirm dialogs are used when an action is required from the user. Confirm dialogs always include at least two actions; one primary action (e.g. Confirm) and one secondary action (e.g. Cancel). However, more than two actions are allowed if it is needed.
Danger dialog
Danger dialog is a variant of a confirm dialog. They are used in similar use cases but Danger dialogs are meant for situations where the action user is going to choose may be destructive or otherwise irreversible or very critical. Danger dialog emphasizes this by using HDS error status colours. Also, it reverses the action button order so that the destructive action is last in the button list.
Scrollable dialog
While not recommended, HDS supports scrollable dialogs if there is a large amount of content (e.g. terms of use). It is recommended to consider other options than a dialog to present the same data since it can be difficult for the user to form a clear understanding of the presented content.