message channel · Feedback and notices
Notification
A message about an event or state that may persist, include actions, and remain available beyond the immediate moment.
Decisive boundary
Notification is a channel and lifecycle concept, not a single visual shape.
Definition and intent
What is a Notification UI pattern?
Use the behavior, not the silhouette
A message about an event or state that may persist, include actions, and remain available beyond the immediate moment. The term is used here as a message channel whose timing, persistence, urgency, and actions must be specified. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Keep event information available when users may need to revisit or act later. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Notification, the boundary is: Notification is a channel and lifecycle concept, not a single visual shape.
Do not implement it as Toast for disposable confirmation and Banner for a page-wide current condition. If those requirements describe the real task better, use the related pattern page or the full Feedback and notices comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Keep event information available when users may need to revisit or act later.
Define opening and closing
A user-relevant event, update, or system condition. Read, dismiss, archive, or state resolution depending on the channel.
Specify access behavior
Does not steal focus when delivered; actions are available when users open it. Notification lists and actions follow normal focus order.
Reject the near miss
Toast for disposable confirmation and Banner for a page-wide current condition.
Behavior contract
What must survive the build
- trigger
- A user-relevant event, update, or system condition.
- dismissal
- Read, dismiss, archive, or state resolution depending on the channel.
- modality
- Usually non-modal.
- focus
- Does not steal focus when delivered; actions are available when users open it.
- keyboard
- Notification lists and actions follow normal focus order.
- interactive
- May include durable actions or navigation to details.
- persistence
- May remain until read, dismissed, archived, or resolved.
- placement
- Inline, in a notification center, or in a managed message region.
- mobile
- Distinguish in-app notification UI from operating-system push notifications.
Failure modes
Common wrong builds
- Calling every toast a notification without defining persistence.
- Stealing focus on arrival.
- Leaving read and dismissal state ambiguous.
Observable checks
Verify the result
- Delivery does not steal focus.
- Read and dismissal states are clear.
- Actions remain available long enough.
- Users can revisit when promised.
- The channel does not duplicate the same event endlessly.
Coding-agent handoff
Implementation brief template
Pattern: Notification Purpose: Keep event information available when users may need to revisit or act later. Trigger: A user-relevant event, update, or system condition. Dismissal behavior: Read, dismiss, archive, or state resolution depending on the channel. Modality: Usually non-modal. Focus behavior: Does not steal focus when delivered; actions are available when users open it. Keyboard behavior: Notification lists and actions follow normal focus order. Interactive content: May include durable actions or navigation to details. Placement: Inline, in a notification center, or in a managed message region. Mobile behavior: Distinguish in-app notification UI from operating-system push notifications. Do not implement as: Toast for disposable confirmation and Banner for a page-wide current condition. Acceptance checks: - Delivery does not steal focus. - Read and dismissal states are clear. - Actions remain available long enough. - Users can revisit when promised. - The channel does not duplicate the same event endlessly.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Notification UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Notification in web UI?
A message about an event or state that may persist, include actions, and remain available beyond the immediate moment. In this reference set it is a message channel whose timing, persistence, urgency, and actions must be specified.
When should I use a Notification?
Keep event information available when users may need to revisit or act later. The decisive boundary to confirm is this: Notification is a channel and lifecycle concept, not a single visual shape.
What keyboard and focus behavior does a Notification need?
Notification lists and actions follow normal focus order. Does not steal focus when delivered; actions are available when users open it. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Notification behave on mobile?
Distinguish in-app notification UI from operating-system push notifications. Its modality is a separate requirement: Usually non-modal.
How do I verify a Notification implementation?
Start with observable checks: Delivery does not steal focus. Read and dismissal states are clear. Actions remain available long enough. Then verify the remaining checks and compare the result with the linked source guidance.