While the current notification system fits the needs of casual users (catch up with the activity in the few places they are involved), as users get involved in a higher volume of activities the current system becomes less useful. In particular, this ticket will focus on Flow notifications since it is a representative case, but the solutions proposed can be applied to other kinds of notifications.

This is a general card to describe the problem, explore solutions, and discuss the work we need to solve it. More specific tasks will be created as blockers to this one.

Goal

Allow users to better organise and control notifications:

• Avoid missed notifications by providing a balance between the overview and the details. That is, communicate the general amount of pending work without overwhelming the user, but give enough information to decide which pieces of work to take.
• Make notifications more meaningful by aligning the volume of notifications received with the user interest on a given subject. That is, the user will receive more (and more detailed) notifications on the topics that is interested the most.

Scenarios and user needs

To illustrate different needs, let's imagine the following notifications:

1. Keep me up to date with topics I'm interested in. When the user is interested on a page (and watches it) or participates in a discussion (gets automatically subscribed to a topic), the user will get notifications on new topics (Notification A) and new activity in those the user participated (created or replied to). This usecase seems properly supported with the current solution and we should make sure new solutions are not breaking it.
   1. The only missing use-case is T121138: Enable a way for us to choose whether to autowatchlist each new flow topic
2. Act on individual items. Notification B represents 30 new topics. Presenting those groupde together helps to avoid the panel to get too crowded with different topics mixed. However, the single notification item does not make it easy to act on each of those 30 new topics: The user cannot check what these are about to evaluate which are the important ones to reply. Once the user access the notification, the user will reach the flow board with the relevant topics highlighted (only for the current session) which forces to reply to all of them in the current session or lose track of the pending ones.
3. Interest on a topic evolving in time. Users that watch changes on a page may not be interested on new topics, or with any activity at all. Users noticing a new topic may want to immediately subscribe to it. Users overwhelmed by a big group of notifications due to a temporary controversy may want to skip notifications on that topic for a while. Users very interested on a specific board may want to check every single notification. All that may happen for different topics or the same topics at different points in time.
4. Check what is new about a subject area. Even with bundled notifications, notifications from the same board can be all around the place (e.g., A and E). Users that are interested on checking what i new on a given board may not find it easy to get that overview with other notifications getting in the way. That can result in a loss of efficiency as te user has to move back and forth.

Research and instrumentation

The above issues were identified ad summarised based on input from different people in the team based on reports from the community but a deeper understanding from quantitative and qualitative perspectives will be helpful:

• User research needs captured at T100650.

• Instrumentation needs:
  • The value of notifications. Understanding how often is the notification badge ignored (e.g., number of times a user opens the panel when there are pending notifications) we can set a baseline of how much the kind of information notifications provide is useful for users or it just becomes too crowded to even pay attention to it. The global number of ignored notifications per user (or users with more than X ignored notifications) can be also a good metric to focus on reducing.
  • Overview vs. detail. Understanding how much are individual vs. bundle notifications accessed, we can identify when grouping too many notifications together discourages users to go through them.
  • Better conversations. In the long term, people tracking the conversations they care abut should lead to more (and better) participation. Tracking the number of topics with no replies can be interesting to check the overall effect of a better notification system that makes advanced users more productive.

Exploring ideas

We have explored several design directions (you can check the very initial notes if you are interested):

Expand bundled notifications and control the notification volume

• Prototype. You can expand the first bundle notification and control the volume of the first two, the fifth one, and the whole board from the talk page.

The current notification panel can be be extended to:

• Allow bundled notifications to be expanded. Bundled notifications can provide an affordance to show the individual notifications they contain. We may want to keep just one notification expanded at a time, visually connect the group and keep the expanded state across different panel openings (since users may want to access topics in sequence).
• Allow to access options to quickly control topic or board notification patterns. The sound volume metaphor can be used to provide the users control from each individual (topic volume) or bundled notification (board volume). The volume levels can include (as anything, subject to discussion): mute (no notifications), direct mentions (no notifications unless the user is explicitly mentioned), topics the user is involved (to exclude new topics), al activity (notification for topic replies and new topics in the case of boards), and all activity with individual notifications (preventing bundling). In addition, the same control should be provided from the board itself (to be able to revert topics that became muted).

This solution doe not cover the scenario #3, for which some of the solutions below (enhancing the table of contents or providing a specific inbox-like UI can help with)

Control of read/unread status on the board
We can help with he issues from the board itself by:

• Mark as read only when the user scrolls. In that way even if a user access the board through a bundle of 30 notifications, only a subset of those will be marked as read as the user scrolls. This does not easily support the pattern of making an overview and acting on the most important items leaving the rest for later.
• Allow to undo the "mark as read". Since marking as read happens as the user scroll, we can provide an affordance to revert that.
  
• Make sure the recently notified elements are highlighted in the table of contents. As the table of contents show recent activity (T99785) it can be used to highlight unread topics based on pending notifications.

Never bundle notifications
Bundling is part of the problem, and removing it completely is worth considering. However, it may clutter the notification list by volume and lack of organisation (keeping new topics of the same board all around the place increasing the user back-and-forth navigation).

Provide an inbox-like view for events
Turn the "all notifications" view into a more powerful UI where the user can filter and organise the pieces of pending work. If the user needs to cover are too complex to be served by the notification panel. Instead of stretching the notification panel too much, we can support them with a specific view. This may align well with the idea of Flow feeds where the user can track conversations from different boards.

Crosswatch is a related project which supports displaying and filtering all your notifications, and we can learn about some of their usecases (more details in crosswatch).