Page History
...
How a modal is dismissed and the effects thereof depend on the content of the modal. For more information, read "Use Cases for Modals".
Best Practices
Usage
Use a dialog when the system must briefly interrupt the current workflow. The user has to decide, confirm, or enter something before they can continue. Typical cases are destructive actions, small edits, or acknowledging an important consequence.
If the information is not critical, choose a lighter pattern. Status updates, hints, and non-urgent messages belong in inline or toast notifications. When users need to
...
work with larger data sets or several views, use a dedicated page, dashboard, or boardlet instead. Content in a dialog must always relate directly to the action that triggered it. Do not turn dialogs into sub-applications or complex configuration screens that users visit repeatedly.
Choosing dialog and modal behavior
A non-modal dialog allows interaction with the underlying page. It works well for supportive and reversible tasks. It is useful when the user should still see and sometimes use the background, for example filter panels or optional settings. Avoid non-modal dialogs when ignoring them could lead to unclear states or data loss.
A modal dialog blocks interaction with the rest of the interface. Use it when the user must finish or cancel the task before continuing. Typical examples are confirmations or short forms in a one-time flow. If users need to switch often between the dialog and the page, reconsider the design. In that case move the task to a full page or simplify it.
Avoid nested dialogs. When an interaction contains several dependent subtasks, use a process dialog or a dedicated process page instead.
Basic dialogs and process dialogs
A basic dialog is suitable for self-contained tasks that fit into a single view. It needs a concise title, only the necessary fields, and a clear primary action. If the content grows into many sections or needs long scrolling, the pattern is no longer a good fit.
A process dialog breaks a larger interaction into clear steps. Use it when the user must follow a defined sequence such as “Details → Options → Summary”. The sidebar or process area provides orientation. It shows which steps are completed, which one is active, and which ones follow. Users should be able to move backwards and forwards without losing their input. If the steps or options make the dialog feel like a small application, move the flow to a full page.
Types of Modals
| Type | When to use | Key characteristics |
|---|---|---|
| Passive modal | To present urgent, workflow-related information without requiring input. | Does not collect input. Closes once the user has read the message and returns to the task. |
| Active dialog | When the user must confirm or reject an action, such as delete or apply. | Contains a clearly labeled primary action and an option to cancel. |
| Acknowledgement dialog/modal | When the system needs explicit confirmation that information was seen and accepted, e.g. legal or irreversible changes. | Usually contains a single action such as “OK”. Should be used sparingly. |
| Focus modal | For very important decisions that need full attention. | Text is short and centred on one question. Actions are limited and clearly described. Avoid side tasks or long explanations. |
| Progress dialog | For multi-step tasks and guided processes. | Guides the user through several steps. Shows where the user is, gives feedback after each step, and avoids too many choices at once. For longer-running work, use clear progress indication and, if possible, an option to cancel. |
Whenever a modal starts behaving like a notification or a full page, change the pattern and use the more suitable option instead of keeping both.
Behaviour and interaction
Dialogs are always triggered by a visible user action such as a button, icon, or link. The label of the trigger should prepare the user. Examples are “Delete”, “Configure”, or “Edit settings”. Avoid dialogs that appear without a clear cause.
When a dialog opens, set the input focus to the first meaningful element. This is usually the primary field or the dialog container. Keep the focus inside the dialog while it is open so that users can complete the interaction with the keyboard alone. After closing, return focus to the original trigger.
Keep dialog content short and easy to scan. The title describes the goal from the user’s perspective. Place important hints close to the inputs they affect. If the dialog requires extensive scrolling, consider a process dialog or a page instead.
Validate user input before closing. When there are errors, leave the dialog open and highlight the affected fields. Show concise, helpful messages that explain what went wrong and how to fix it. For simple dialogs, it is acceptable to allow dismissal via close icon, cancel action, Escape key, or clicking outside the dialog. For critical or destructive actions, require an explicit button press. Consider disabling outside clicks to prevent accidental loss of data
- Use it to focus the user's attention.
- For completing non-simple to complex tasks.
- To collect input from the user.
- To display relevant information.
When not to use a dialogue
- Do not use if the content is unrelated to the current workflow.
- Do not use for displaying complex or large amounts of data.
- Do not display a sub-application or other dashboard in a dialogue box.
- Do not use if the user has not triggered the dialogue.
When to use what type of Modal
- Passiv: Presents information the user needs to be aware of concerning their current workflow. Contains no actions for the user to take.
- Active: Requires an action to be taken in order for the modal to be completed and closed. Contains a cancel and primary action button
- Acknowledgement: System requires an acknowledgement of the information from the user. Contains only a single button, commonly "OK".
- Fokus: Focused and action to be taken. Contains a Secondary and Primary action button.
- Progress: Requires several steps to be completed bevor it can be closed. Contains a cancel, previous, and next/completion button.
Behaviour
Trigger
Dialogues are triggered by a user's action and not generated by the system. Common components that can trigger a dialogue include buttons, links or icons.
Focus
Once the dialogue box is open, set the initial focus to the first location that allows user input. The focus should then remain in the dialogue until it is closed.
Process
The modal component has a fixed maximum height. If the content of the dialogue is longer than the height of the dialogue, the main part should be divided into so that the user can scroll through the process. For this case, only the process dialogue may be used.
Validation
Validate a user's input before closing the dialogue. If an input is invalid, the dialogue should remain open with the input marked with an error status and an inline error message. The message should inform the user what has happened and give advice on next steps or possible solutions. An effective and immediate error message can help the user understand and resolve the problem.
Button Placement
Look for footerbar actions
...
- X: clicking the close x icon in the upper right will close the modal without submitting any data and return the user to their previous context.
- Task Complete: clicking the primary action will complete the task and automatically close the modal.
- Esc: Pressing ESC on the keyboard will close the modal and send user to the previous context.
Focus
Focus modals are used to contain very important user decisions. The focus here is the focused headline. The focused modals have only ghost buttons. After confirming, the user will be informed about their conformation via inline notification.
...
