Loading navigation…
User
Usage
Modal overlays the page with a single focused task: confirm a serious action, collect required fields, or surface information the operator must not miss. It demands attention and temporarily suspends the background. The mental model is "stop, decide, continue"—and the component earns its weight only when the alternative is silent data loss or a mis-sent decision. Overuse trains users to dismiss without reading, so a dispatch console should have few modals, and each one should be consequential.
Opening a chatroom pulls the current call's CAD context and notifies the on-call supervisor.
Deleting an incident record, removing a user from an agency, revoking an integration token—anything that cannot be silently undone belongs in a modal. The friction is the point. The title names the consequence ("Remove responder from incident?"), the body lists the side effects, and the primary button repeats the verb ("Remove").
When the user can't safely continue without making a decision—assigning an AQA review, selecting a target agency for a transferred call, confirming a license expansion—a modal holds the context still until the required input is collected. Treat the modal as the smallest possible form that captures the decision; longer workflows belong in TakeoverModal or a dedicated page.
If a message must persist until the operator explicitly acknowledges it (license warnings, on-call handoffs, training debriefs), a modal is the right weight. A dismissible Snackbar or inline Callout lets the user miss it; a modal guarantees a click.
Non-blocking help, inline filters, and contextual summaries belong in Popover or inline expansion. Forcing them into a modal interrupts the flow and trains operators to dismiss modals reflexively.
When users need to keep a data table, incident, or transcript visible while they work, use Drawer (anchored side panel) or TakeoverModal (full-screen workflow). A modal hides the context behind a backdrop; long flows feel airless inside one.
Background-sync toasts, save-succeeded confirmations, and other disposable outcomes belong in Snackbar. Modals should not announce routine events.
If the content could live inline (policy notes, read-only detail), a modal adds weight without adding clarity. Ask whether the user needs a blocking moment or just information—if it's the latter, a Callout or static section is better.
| Shape | Purpose | Emphasis |
|---|---|---|
| Standard confirm / form | Single decision or short form | One primary action, explicit cancel |
| Destructive primary | Irreversible operations | Destructive type on the primary button; body lists impacts |
| Non-dismissible | Required user choice | Rare; disable Escape and backdrop close only with product approval |
| Stacked | Secondary confirmation on top of the first | Keep depth shallow; each layer must add clarity, not noise |
Every modal renders three slots: a header with a title and close control, a body that holds the task, and a footer with the action cluster. The footer follows a trailing-primary convention across the product: secondary action on the left, primary on the right. When an action is destructive, the primary button uses the destructive type so its styling matches its consequence.
Specific, not generic. "Remove responder from incident?" rather than "Are you sure?" The title is the accessible name for the dialog; it should read sensibly without the body.
Short, scannable. Use bullets for lists of impacts and keep the body under one visual beat. If the consequence lives in paragraph five of a wall of copy, nobody will read it—pull it up.
Primary button names the outcome ("Remove", "Save", "Confirm transfer"). Cancel is explicit ("Cancel", "Keep editing") and never relies on the close icon alone. Match the button type to the action: destructive primaries for destructive verbs, primary for commits, secondary for de-emphasized alternates.
formatMessage; test the longest expected translation inside the modal's width before shipping.Do
Don't
Focus management, dialog semantics, Escape handling, and screen reader announcements carry real operational weight—see Accessibility for the component-vs-app contract, runnable focus examples, and the open/close announcement pattern.
On this page