Toast

There was a time when the only way to report the result of an action was to open a window. "Saved" plus an OK button landed in the middle of the screen, and the user stopped, cleared the window, and only then continued. Every notification broke the flow once. The window was doing two jobs at the same time, reporting a result and demanding acknowledgment, and only the second one ever registered.

Early Pagedeck screens worked that way. A save confirmation appeared every time someone edited a document, and when Noa ran a usability test all five participants pressed OK without reading the sentence. One of them pressed it twelve times in thirty minutes. Nothing that was meant to be communicated arrived; twelve clicks did.

A toast moves that notice out of the center and into the margin. Whoever wants to read it reads it, and everyone else keeps working. One condition comes attached: it can only carry content that's safe to miss. A sentence placed somewhere that vanishes in a few seconds is, for anyone who didn't look, a sentence that was never there.

It appears at one edge right after an action completes and removes itself when its time is up. Requiring nothing from the user to clean up is what separates it from other notifications.

Six things get decided in advance.

1. The position. Pick bottom center or top right and keep it. If it moves between screens, users spend time looking for it, and it disappears while they look.
2. The duration. Use around four seconds as a baseline for one line and extend it as text grows. Shorter than reading speed leaves only the fact that something flashed. About one second per five words is a usable starting point.
3. Stacking. When several actions finish in a row, stack them or release them in turn. Three on screen at once with the rest queued behind works well enough. Past that it stops reading as a notification and starts reading as a wall.
4. Dismissal. Give it a close control so users can clear it early. While a pointer rests on it the timer has to pause, or a sentence disappears mid-read.
5. The content. One sentence saying what happened. The cause of an error, or how to fix it, does not belong here. A notice anyone would want to re-read is already in the wrong element.
6. Being read aloud. Mark it with the live region that Accessible Rich Internet Applications (ARIA) defines so it reaches users who aren't looking at the screen. Without that mark a screen reader says nothing about what just happened.

One rule runs through all six: never ask for a decision or an action. Put a button somewhere that vanishes in three seconds and it becomes a button that must be pressed within three seconds. The same logic rules out links inside a toast: a destination nobody can reach in time is worse than no link at all.

Use it to report the result of an action the user just took. The document was saved, the link was copied, the invitations went out, the setting took effect. The user already knows what they did, so missing the sentence costs nothing. It also suits confirmations that would otherwise need a screen of their own, since it leaves the page they belong to untouched.

Three places it doesn't fit.

1. Actions that need an undo. A notification with an undo control on it is a snackbar. Deleting or archiving — anything where a mistaken click causes loss — belongs there.
2. Things the user has to answer. Asking whether to really delete something goes to a modal, which blocks the screen behind it. Work that can't proceed without an answer can't live somewhere that disappears.
3. Notices that have to stay. A failed payment or a full storage quota goes into a banner that stays pinned to the screen.

Errors the user has to fix don't go into a toast either. "This field is required" has to sit under that field, so where to fix it travels with the message. Keep the wording short but keep the substance, which means applying the rules of microcopy, the short text that lives inside screens. "Done" is worse than "3 invitations sent."

"Let's move this to a toast. It isn't worth making people press OK."

Lowering the weight of a notification so it stops breaking the flow.

"Put undo in a toast and it becomes a button you have three seconds to press. That needs a snackbar."

Actions don't belong on a notification that disappears.

"Don't put payment failures in a toast. Clear the space and people walk right past it."

Whether the content is safe to miss is the test for choosing this element.

After Noa replaced the save confirmation with a toast, the pointless clicks during editing went away, and participants stopped as often in the same task. A month later a different complaint arrived: someone had deleted a document by accident and couldn't find a way to get it back.

The cause was that removing the confirmation window had swept deletion into a toast along with everything else. Once "Deleted" faded after four seconds, the user had nothing left to work with. Deleting and saving had looked like the same kind of event on the spec sheet, and only the complaint separated them. Noa moved deletion alone to a notification with an undo control and left success notices in toasts. The standard became splitting by the nature of the action rather than unifying on one element.

The most common reading is that this is how you make notifications quiet. No window opens, so nothing interrupts. But not interrupting is the same thing as not guaranteeing delivery. Moving important news into a toast doesn't quiet it down; it makes it vanish. It shows up as a rise in support questions after a storage-full notice becomes a toast. The fix there is not a longer duration but an element that persists.

Assuming a short appearance is safe for accessibility is the other one, since not covering the screen feels considerate. Four seconds is not four seconds for everyone, though. It can end before a screen reader gets to it, or flash outside the visible area of someone using heavy magnification. A minimum duration, plus pausing the timer while pointer or keyboard focus rests on it, has to come with it.