Consecutive toasts should queue rather than overwrite
Aliases: snackbar queue · notification collision · toast overwrite
What it is
Queueing means that when several toasts fire in a short burst, a later one waits until the earlier one has finished its visible cycle, instead of replacing its pixels in the same slot. Overwrite leaves the user with only the last frame. A save-succeeded toast covered by a network error can be read as “save failed”; an error covered by a later “Copied” silently cancels the failure. Queueing protects each message’s chance to be seen as its own event. It does not decide how long a single toast should stay, or whether that toast was must-read.
Why it happens
When an object at one screen coordinate is instantly swapped for another, vision keeps the later object; the earlier identity is not stored as “something that disappeared.” A toast has no log to re-read, so overwrite is physical deletion. Bursts are common: one action may emit “Saved” then “Synced,” and a bulk action may emit one toast per item. Overwrite compresses many events into one, and people judge the whole episode by the valence of the last line. Queueing restores temporal segmentation, but a long queue turns feedback into a slideshow whose later items arrive after the action has left working memory. The queue is for short bursts, not unbounded accumulation.
Studying it
After a single user action, fire two or three toasts with different meanings, comparing overwrite against queueing.
Independent variables: gap between messages, whether they concern the same object, whether the later message semantically supersedes the earlier one (“Saving” replaced by “Saved”), maximum queue length. Dependent variables: whether both contents are reported, whether order is preserved, and whether the later valence is used to judge the earlier action.
The critical contrast is “later message negates the earlier” versus “later message adds to the earlier.” Overwrite can be right in the first case and systematically wrong in the second. After the trial, ask the two facts—“did the save succeed?” and “did the copy succeed?”—not “did you see a notice?”
Where it stops holding
Status updates of the same object should merge, not queue: 30% then 70% should not become two toasts. When the later message truly replaces the earlier (“Saving” → “Saved,” “Send failed” → “Retried successfully”), replacement is the correct policy; queueing would keep a stale state alive for another cycle. More than a handful still waiting means the grain of feedback is wrong: collapse into one summary (“12 saved, 2 failed”) or put detail beside the objects. OS-level banners may ignore the in-app queue, and queueing again inside the app then doubles the interruption.
Applying it
- Give toasts a bounded FIFO queue; allow replacement only when the later message is marked as a status update of the same object.
- Do not emit one toast per item in a bulk action; emit one summary at the end and leave failures in the list.
- Cap the queue (for example at three) and fold the rest into “n more notices” so the UI does not become a parade.
- Verify by forcing a copy or a sync failure during a save, then asking for both outcomes. If only the last line can be named, overwrite is deleting information.