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:
- {T114350}
- {T114356}
- {T114357}
- {T115264}
- {T115581}
Check the above tasks for specific details, and [[ http://pauginer.github.io/prototypes/notifications/notification-panel/index.html | this prototype ]] to check some in action. Some general context for the Notification panel improvements is provided below:
# Goals
Basic needs:
- **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.
Advanced needs:
- **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.).
# Metrics
When users don't have visibility on what is going on, they need to make an effort chasing information (e.g., going to other wikis) and the chances of missing info or getting it late increases. Thus, with our changes we should expect to reduce the number of unread notifications and the time it takes to get them read. Some tickets about specific measurements:
- {T108208}
- {T113626}