The notification panel provides a good overview of new notifications. However, it has several limitations that affect both regular and advanced users. This #Epic ticket will be decomposed in multiple sub-tickets.
- **Become aware of what’s new (even across languages)** A basic goal for the panel is to communicate what is new. If we consider surfacing activity from different projects, we need to consider how much to separate local an external notifications.
- **A clear way to act on notifications.** Each notification should communicate an event in a succinct way. Making it easy for users to quickly process and react to notifications. Currently, there are some inconsistencies in the way notifications are presented: (e.g., including multiple actionable links in addition to a default action on the notification item).
- **Get additional details when needed.** Notifications may involve multiple pieces of information for which several relevant actions may be possible. We need to provide access to those secondary actions in a clear way but without adding complexity to the panel.
- **Triage action items (todo/inbox-like use).** Users that take part in many on-wiki activities may get many different notifications. In the current panel this is hard because (a) marking a notification as read cannot be reverted, and (b) bundled notifications can only be acted at the group level. So a user receiving a bundle "100 new topics on Foo" notification is forced to process all 100 replies or lose track of them. By providing more flexibility in dealing with notifications in the panel, users could be able to better triage the items worth acting on and keep track of the rest for later. It is important to decide the right level of control in order to avoid the support for the complex cases to make the experience unnecessarily complex for the simple ones. For more advanced control mechanisms, we can consider extending the Notification page where more room is available.
- **Volume control for notifications.** Users that take part in many on-wiki activities may get many different notifications. By allowing users to adjust the volume of notifications using more or less strict criteria, users can get notifications that better meet their interests and less noise. The challenge is to keep the volume configuration clear considering that many levels are possible (completely muted, only wen directly mentioned, any new activity) and different elements are involved in a notification (notifications of the same kind, involving the same page, from the same user, etc.).
# The panel
The notification panel will show unread notifications on top and read notifications at the bottom as it currently does. If there are unread notifications from other wikis, they will appear at the end of the unread notifications section.
# Notification items
Notification items are structured in the following way:
- Icon based on the type of notification.
- Mark as read "X".
- Notification text. Can be rich text but not include links since clicking anywhere should trigger the default action.
- Default action. It will lead to the main piece of content associated to the notification when clicking anywhere (except on secondary actions and menus).
- Secondary actions. One or two actions (different from the default one). Actions will have an icon, a label and a short description (shown as a tooltip). These actions are specific to the notification and are initially visible.
- More menu. A menu for additional actions either specific for the notification item or general (including marking as read/unread and volume controls)
# Bundled notifications
Bundled notifications provide a secondary "expand" action to allow users to access the individual items.
# Cross-wiki notifications
Notifications from other wikis are bundled and presented at the bottom of the unread notifications. Once they are expanded, individual notifications are organised by project and language (only showing the labels that are relevant depending on the context). In the cases where there are few notifications, the bundling or the groupings may not be necessary (examples below).