Overlay and feedback blocks
Everything here interrupts. The blocks differ in how hard they interrupt and how long the message lasts, and matching those two to the thing being said is most of what separates an interface that feels responsive from one that feels noisy.
7 families, 29 blocks
- Modals4 blocksConfirmations, forms, quick actions
- Popovers5 blocksCoachmarks, share sheets, chart tooltips, password strength
- Alerts and Toasts5 blocksForm errors, background jobs, system status
- Notifications Feed2 blocksInboxes, activity centres, alerts
- Progress Bars5 blocksUploads, onboarding, usage meters
- Spinners5 blocksWaits with no end in sight, and the ones you can measure
- Onboarding Tours3 blocksFirst-run guidance, feature launches
What these are for
Rank them by cost to the reader. A spinner says wait and costs nothing. A progress bar says wait and here is how long, which is worth far more than it looks: a known wait is tolerated roughly twice as long as an unknown one. A toast reports something that already happened and is gone in seconds. A modal stops everything until it is answered, and is the most expensive thing in this list, which is why it should be reserved for decisions that genuinely cannot wait.
The second axis is whether the message has to survive. A toast is for outcomes that do not matter once seen — saved, copied, sent. Anything a reader might need later, or that arrived while they were elsewhere, needs somewhere to live, which is what the notifications feed is for. A destructive failure announced only in a toast is a failure the reader may never learn about.
Modals and popovers share the mechanics that are easy to get wrong and invisible when right: where focus goes on open, that it cannot escape while open, where it returns on close, and that Escape works. Every overlay here answers those, because they are the difference between an overlay and a trap.
Choosing between them
Modal or popover?
A modal blocks the page and demands an answer; a popover sits over it and is dismissed by looking away. Use a modal only for something that must be resolved before anything else can proceed — a destructive confirmation, a required decision. Anything informative, optional or supplementary is a popover, and a modal used for it will train readers to dismiss modals without reading, which is precisely the habit you cannot afford when a real one appears.
Toast or inline message?
Put the message where the thing happened whenever you can. A form that failed validation should say so at the field, not in a corner, because the corner is where the reader is not looking and the message will be gone before they look there. Toasts are for outcomes with no location on screen — a background job finished, an item was deleted from a list that has already closed.
Spinner or progress bar?
A progress bar whenever you can compute a fraction, and a spinner only when you genuinely cannot. The bar is not decoration: an unmeasured wait feels longer and is abandoned sooner. If the operation has steps, naming the current step beats an animated percentage, because it tells the reader that something is still happening and what.
Are onboarding tours worth it?
Rarely, and only for an interface whose value is not visible on arrival. A tour is a sequence of interruptions before the reader has any reason to tolerate one, and most are dismissed at the first step, which means the product has spent its one introduction on nothing. They earn their place for a genuinely novel interaction; they do not earn it for pointing at a navbar.
Questions
Do the modals handle focus and Escape?
Yes. Focus moves into the modal on open, is held there while it is open, and returns to whatever opened it on close; Escape and the backdrop both dismiss unless the modal is one that must be answered. These are the parts routinely missing from hand-rolled modals, and they are the parts that decide whether the overlay is usable without a mouse.
How long should a toast stay?
Long enough to read at a glance and no longer — a few seconds for a short confirmation, longer if it carries an action such as Undo, and indefinitely if it reports a failure the reader has to act on. Anything with an action needs to stay until it is dismissed, because a toast that disappears mid-reach has taken the action away with it.
Can these be driven from anywhere in the app?
The blocks are presentation: they render the state you give them. How that state is raised — a store, a context, an event bus — stays yours, which keeps the same toast block usable whether a single component or a global handler is raising it.
The other categories
All documentation
Getting started
Foundations
All components