A banner stays until it is handled or dismissed
Aliases: in-page banner · alert banner · non-modal alert
What it is
A banner is a non-modal notice slotted at the top or bottom of the content flow. It stays until the user dismisses it, or until the condition it describes is resolved. The split with a toast is who owns the ending: a toast is taken by a timer; a banner hands the end of reading to the person. It therefore fits “the app or this page is in a state you need to know”—an account about to expire, read-only mode, a dead license, an unfinished mandated task. It is not a larger success confirmation, and it is not a dialog: the primary task can continue, but the state is pinned in view until the condition lifts.
Why it happens
Persistence repairs a mismatch between the attention window and the lifetime of a state. People do not stare at the edge; if one glance misses the message and it is still there, the next glance can catch it. A banner occupies a stable layout slot, so re-reading does not depend on working memory. Dismiss-or-resolve is the end condition because a banner usually states a situation that remains true, not an event that already finished. Events take transient feedback; situations take persistent feedback. If the banner vanishes while the situation still holds, the interface lies: read-only mode is still on, the notice is gone, and a later failed edit feels arbitrary. Closing must be an explicit act; the system must not treat “it was shown” as “it was handled.”
Studying it
Compare three ending policies for the same status message: auto-dismiss on a timer, must be closed, and stays until the condition clears. The primary task is to keep working under that condition (try to edit a read-only document, try to save on an expired account).
Independent variables: ending policy, whether the banner sits near the primary control, how long the condition lasts. Dependent variables: whether people can later state the current restriction, whether they still attempt a forbidden action, and whether dismissing is mistaken for the restriction being lifted.
In the lab the banner appears while participants watch the screen, so the benefit of persistence is under-measured. A better probe inserts an unrelated task and then returns, asking who can still say why editing is blocked.
Where it stops holding
A finished one-shot event (“draft saved”) left in a persistent banner becomes indelible noise; people learn to close banners on sight and then skip the real ones. When a choice must be made now and the primary task cannot continue, a banner is too weak—use a modal. The reverse error is a banner that outlives the condition: the restriction is gone, the notice still fabricates a constraint. In another window or a background tab the banner exists only on that page; when the user returns it must still be there, not omitted because “it was already shown.”
Applying it
- Split messages into events and situations: events take transient feedback; situations take a banner, with an explicit end condition of user dismiss or condition cleared.
- Remove the banner the moment the condition clears; do not wait for the next reload. If the user dismissed it and the condition still holds, show it again on the next visit to that page.
- Make dismiss findable and keyboard-operable; dismissing is not resolving—do not treat close as a silent success.
- Verify by holding the condition for ten minutes, switching away, and coming back. The banner still present and still accurate is persistence; vanished or stale copy means the end condition is wrong.