Currently, some notifications get marked as read when the user visits their associated page.
That makes sense in those cases when accessing a page implies to get the message that the notification was intended to communicate. This is useful to avoid duplication between the contents the user monitors regularly and those that the user tracks through the notification panel. Otherwise a users may get notifications about a given message just to realise that they already replied to it.

However, this may become problematic if navigation silently causes users to lose track of a notification they cared about. These are issues we want to observe once users have more control to keep notifications for later (T73564).

Based on those observations we may find some appropriate solutions, but here are some initial ideas based on the identified process gaps (awareness of notifications being marked as read, control on which notifications can be marked as read, and findability of the affected notifications):

Highlight when notifications get marked as read.

When a user visits a page that makes a notification to become read, some subtle highlighting can be shown to communicate the status change. If the user opens the notification badge, the affected notifications can also become highlighted.

More explicit pinning.
As discussed in T73564, it may feel strange that a notification explicitly marked as "unread" becomes read again automatically (when visiting a page). Similar to what is proposed for alerts, we can consider that those explicitly marked as unread become to a more persistent "pinned" state.

The above mockups illustrate a model where the transitions have been simplified to avoid exposing too much choice to the user.

• For both read and unread, an action is provided to turn the notification into "pinned" since it is an explicit action.
  • For the case of read notifications, it is presented as "marking as unread".
  • For the case of unread notifications, it is presented as "keep as unread".
• Pinned notifications remain as unread until the used clicks on the "X" icon. Even when the user opens them, visits related pages or opens the alerts panel.
• The model does not allow to move from read to regular unread status (since the difference with pinned is too small to provide too much choice). We can consider a transition from pinned to regular unread ("Don't keep as unread") if we identify there is a real need for it.

Filter notifications about the current page.
Another way to facilitate users to operate with notifications on the pages they visit often is to provide access to a view of the panel where only those notifications associated with the current page are shown. That could be useful to easily find the notifications associated with the current page (e.g., to decide whether to mark them as unread for later processing).

The mockups above illustrate some possible ways to show notifications about the current page (integrated or as a separate view), but we need to be careful with increasing the complexity of the notification panel. An alternative could be to surface the last visited page in the filters provided on the notifications page (T115316). In that way a user can click on "app notifications" and quickly filter the notifications based on the page the user was viewing.