Page MenuHomePhabricator

Notification panel: Control notification volume
Open, NormalPublic

Description

Not all notifications are equally important for a user all the time.

It makes sense to control the notification volume by starting from a specific instance right from the notification panel (close when the problem is identified). For example, the user getting too many notifications about a discussion page may want to adjust it to keep her informed only when she is directly mentioned.

Considerations

There are several aspects to consider:

Volume levels
There are several ways in which a notification can become les prominent:

  • Skip highlighting the notification badge to avoid distractions.
  • Mark it as read automatically to skip the list of pending items.
  • Hide it from the list of notifications, as if never was received.
    • (I.e. For page-based notifications, Keep the page in the watchlist, but don't send any notifications. Similar ideas in T121138)

A single option to "mute" can be supported by any of the above.

What to control
Notifications involve different pieces of information which may make it unclear in advance what are we controlling the volume about. For example, from a thanks notification from Cronopio about a comment in a discussion topic, should the volume options be about (a) the notifications from Cronopio, (b) the thanks notifications, (c) the specific topic.

The "type+page" seems to provide a reasonable level of control without leading to too complex rules.

How to control the volume
We need to define how to activate, deactivate, and check the current volume settings.
For some actions it may be convenient to use the notifications itself as entry point, for others a more general place such as settings may be needed.

Proposed solution

The proposed solution is to use "mark automatically as read" as the way to mute and provide access to this functionality through (a) the notifications, (b) the notification preferences and (c) special blacklist pages.

In this way, unimportant notifications will not distract the users or get in the way of the pending work, but will be still reachable in case it is needed (e.g., to understand why you were not notified about an event or revert the mute decision from the panel).

Prototype: Check this screencast illustrating the idea in action to get a better idea. This is based on this prototype which you can also interact with.

The proposal considers two different entry points for controlling the volume of notifications (which can be implemented at different stages):

Muting from the panel:

  • For each notification it is provided an option to mute all notifications of their kind for the current page.
  • Once muted, the current and future notifications of the same type for the same page will be marked as read automatically. The notification badge will not become highlighted when new notifications arrive.
  • Muted notifications will include a muted icon that helps to visually understand why a notification you have not seen before is now marked as read.
  • Muted notifications can be used to undo the muting action for those notifications in the same category for a given page, but only the current notification and new ones will be marked as unread again.
  • Muted notifications can still be marked as unread (no longer showing the muted icon on it). This will not affect other notifications, and once the current notification becomes read, the muted icon will be shown again.

Muting from preferences (and blacklists):

  • An action menu is provided for each notification category with the option to add pages to be muted.
  • If there are muted pages, the control shows the number of pages muted.
  • The control provides access to a specific black list where pages to be muted for a given category of notifications can be added to the list.
  • A more advanced UI can ce supported for dealing with lists of pages in the future.

Related tickets

Related Objects

Event Timeline

I think some of the most basic settings sholud be handled via Special:Preferences, because there is no sense to change the Settings I mean via the Notfiactions themselves. If the way of presenting Notifications mentioned my PerfektesChaos in T115845 or a similar way is chosen, the user sholud have the ability to change the priority of single sorts of Notifications via the Preferneces (I think 5 priorities would be enough), either with Radiobuttons or with a field in which the user can pick a number between 1 and 5.

I think some of the most basic settings sholud be handled via Special:Preferences, because there is no sense to change the Settings I mean via the Notfiactions themselves.

Just to clarify, the above mockup is not intended to be a proposed solution. It illustrates the idea of providing "some kind" of control over the visibility of notifications from the notifications themselves.

I agree that this mechanisms should be integrated with the settings view, but I think it still makes sense to quickly access some of these options. This is based on two aspects proximity and context:

  • Proximity. You are likely to perceive a kind of notification as annoying right after receiving one (or many) of them, and having to go through settings look for the specific kind of notification when you had it in front of your eyes just adds friction to the interaction.
  • Context. If you get a new reply to a talk page X, you may be able to mute further notifications about replies on talk page X. Acting on a specific notifications allow us to be more specific without the need for the user to specify additional information.

Most of these actions would be specific to the extension (e.g., a new Flow topic notification may include an option to subscribe to it in order to get more notifications about that topic activity). So we may just want to provide some guidelines and apply it where it makes sense. The basic options I'd expected for any notification would be (a) allow a quick option to mute notifications of this kind on the current content element, and (b) access to the notifications settings for further control (highlighting the current kind of notification for the user to easily continue adjusting settings about it).

I'm working on a prototype to illustrate this, so based on the feedback we get the ideas will evolve.
Thanks for your initial comments.

MGChecker added a comment.EditedNov 9 2015, 6:21 PM

I agree options like you told would be really useful, so you have more control over the Noatifiaction volume, but I think it's important o have a overwiev of all "special rules" in your user settings that it remains simple, but clear. (If this comment is at the wrong place, please tell me which would be better.)

Pginer-WMF updated the task description. (Show Details)Dec 1 2015, 1:10 PM
Pginer-WMF set Security to None.
Quiddity updated the task description. (Show Details)Apr 18 2016, 6:22 PM
Pginer-WMF updated the task description. (Show Details)Apr 27 2016, 4:04 PM
Pginer-WMF updated the task description. (Show Details)Apr 27 2016, 4:08 PM

One possible solution could be to use "mark automatically as read" as the way to mute and provide access to this functionality through (a) the notifications, (b) the notification preferences and (c) special blacklist pages.

In this way, unimportant notifications will not distract the users or get in the way of the pending work, but will be still reachable in case it is needed.

Prototype

Check this screencast illustrating the idea in action to get a better idea. This is based on this prototype which you can also interact with.

More details

The proposal considers two different entry points for controlling the volume of notifications (which can be implemented at different stages):

Muting from the panel

  • For each notification it is provided an option to mute all notifications of their kind for the current page.
  • Once muted, the current and future notifications of the same type for the same page will be marked as read automatically. The notification badge will not become highlighted when new notifications arrive.
  • Muted notifications will include a muted icon that helps to visually understand why a notification you have not seen before is now marked as read.
  • Muted notifications can be used to undo the muting action for those notifications in the same category for a given page, but only the current notification and new ones will be marked as unread again.
  • Muted notifications can still be marked as unread (no longer showing the muted icon on it). This will not affect other notifications, and once the current notification becomes read, the muted icon will be shown again.

Muting from preferences (and blacklists)

  • An action menu is provided for each notification category with the option to add pages to be muted.
  • If there are muted pages, the control shows the number of pages muted.
  • The control provides access to a specific black list where pages to be muted for a given category of notifications can be added to the list.
  • A more advanced UI can ce supported for dealing with lists of pages in the future.
Glaisher removed a subscriber: Glaisher.Apr 28 2016, 4:07 PM
Elitre added a subscriber: Elitre.May 12 2016, 1:12 PM
Pginer-WMF updated the task description. (Show Details)May 13 2016, 7:34 AM

I copied the proposal from T115264#2248740 to the ticket to capture it as the current proposed solution. There is still research to be done to make sure it works as intended, but this is the most promising solution we found, and keeping it on top will help to provide context and avoid getting buried in the conversation by further comments.

An example of related issues was provided in this comment.

JAnD added a subscriber: JAnD.May 13 2016, 8:39 AM
Pginer-WMF updated the task description. (Show Details)Aug 12 2016, 7:44 AM
Quiddity updated the task description. (Show Details)Aug 15 2016, 5:27 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptApr 19 2019, 8:08 PM