Notification User Experience
Summary
An employee encounters notifications in two places: the header bell on every page, and the inbox screen. The journey is read-only apart from read state — there is nothing an employee can configure.
Audience
Engineers, QA, support, employees, product owners and architects.
The journey
An employee sees the bell badge update on a 60-second cycle. Opening the drawer shows recent items with a mark-all action and a link through to the full inbox. On the inbox they can filter, refresh by button or pull gesture, open an item to navigate to its target, or mark items read individually or in bulk.
Opening an item always marks it read first, then navigates when an action URL is present. An item without an action URL is marked read and nothing else happens — there is no detail view to fall back to.
What the employee controls
| Capability | Available |
|---|---|
| See unread count | Yes |
| Read notification content | Yes |
| Filter by category | Yes, client-side over loaded items |
| Mark one or all read | Yes |
| Navigate to the related record | Yes, when an action URL exists |
| Refresh | Yes, button and pull gesture |
| Choose channels or opt out | No |
| Mark unread again | No |
| Delete or archive | No |
| Search | No |
| Load older notifications | No |
Verified experience gaps
Silent write failures. Every mark-read and mark-all call swallows its error and updates local state regardless. A failed write renders as success until the next load, at which point the item silently reverts to unread.
No pagination. The inbox loads one server page and filters client-side. An employee cannot reach older notifications through any control, and nothing indicates that more exist beyond what was returned.
Truncation is invisible. The legacy list endpoint caps its result, and the screen displays whatever it receives with no total, no count and no more-items indicator.
Unreachable category. The interview category can be inferred but has no filter chip, so those items appear only under the all or unread filters.
Inconsistent unread source. The header badge prefers a server count while the inbox computes its badge from loaded items. The two can disagree — for example when the server count exceeds what the list returned.
No real-time delivery. The only refresh mechanisms are the 60-second poll on the shell, the inbox's explicit refresh and the pull gesture. A notification created while the inbox is open does not appear until one of those fires; the inbox itself does not poll.
Accessibility
Some accessibility attributes are present and some are absent. The bell button declares a title, an accessible label and an expanded state. The filter strip declares a region label.
Not present: the drawer has no dialog role or focus trapping, the toast has no live-region announcement, list items are rendered as nested buttons inside articles without list semantics, and the pull-to-refresh gesture has no keyboard or pointer equivalent — though the refresh button covers the same action.
Category is conveyed by icon and colour tone alongside a text label, so the label carries the meaning rather than colour alone.
Mobile considerations
The inbox is explicitly built mobile-first: a constrained shell width, a horizontally scrolling filter strip, a pull-to-refresh gesture and an on-screen hint stating that pulling down refreshes. Touch handling guards against firing mid-scroll.
Classification
Transitional.
Requires confirmation
Whether write failures should surface to the user, and whether pagination and search are planned, require confirmation.
Related Articles
See Also
Keywords
- Notification database
- User Experience
- Draft database documentation
Source References
UI/salary-ui/apps/client-hrms-portal/src/pages/NotificationsPage.tsxUI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsxUI/salary-ui/apps/client-hrms-portal/src/ess/EssPages.tsxControllers/NotificationsController.cs
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Review cycle: Quarterly