Page MenuHomePhabricator

Notification panel: Control notification volume
Open, MediumPublic

Assigned To
None
Authored By
Pginer-WMF
Oct 12 2015, 3:14 PM
Referenced Files
F31847372: Screen Shot 2020-05-29 at 4.34.44 PM.png
May 29 2020, 11:55 PM
F31847374: Screen Shot 2020-05-29 at 4.34.57 PM.png
May 29 2020, 11:55 PM
F31847376: Screen Shot 2020-05-29 at 4.37.55 PM.png
May 29 2020, 11:55 PM
F31789117: Screenshot from 2020-04-30 15-02-12.png
Apr 30 2020, 10:19 PM
F31789109: Screenshot from 2020-04-30 15-02-34.png
Apr 30 2020, 10:19 PM
F31789105: Screenshot from 2020-04-30 15-15-45.png
Apr 30 2020, 10:19 PM
F31789107: Screenshot from 2020-04-30 15-02-24.png
Apr 30 2020, 10:19 PM
F31789121: Screenshot from 2020-04-30 15-04-34.png
Apr 30 2020, 10:19 PM
Tokens
"Love" token, awarded by Quiddity."Love" token, awarded by Luke081515.

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:

muting.png (768×1 px, 346 KB)

  • 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):

mutted-settings.png (768×1 px, 206 KB)

  • 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.

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.)

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

muting.png (768×1 px, 346 KB)

  • 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)

mutted-settings.png (768×1 px, 206 KB)

  • 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.

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.

Change 592806 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] Add dynamic secondary action to mute/unmute page-linked notifications

https://gerrit.wikimedia.org/r/592806

Here's what the patch linked above implements, in conjunction with the patch for T46787: Allow excluding pages from the page links notifications:

Mute option on a regular (non-bundled) page-linked notification

Screenshot from 2020-04-30 15-15-45.png (118×487 px, 16 KB)

Mute option on a bundle of page-linked notifications:

Screenshot from 2020-04-30 15-02-24.png (174×487 px, 21 KB)

Mute option on an individual item in a bundle:

Screenshot from 2020-04-30 15-02-34.png (296×489 px, 34 KB)

Clicking the mute option makes the mute option disappear, and displays this message:

Screenshot from 2020-04-30 15-03-12.png (262×606 px, 34 KB)

Pages that are already muted have an unmute option instead:

Screenshot from 2020-04-30 15-02-12.png (146×492 px, 17 KB)

Message displayed after clicking the unmute option:

Screenshot from 2020-04-30 15-04-34.png (345×610 px, 44 KB)

Muting/unmuting a page adds/removes it in the list of muted pages created by T46787, see T46787#6073227 for a screenshot.

Change 592806 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Add dynamic secondary action to mute/unmute page-linked notifications

https://gerrit.wikimedia.org/r/592806

@kostajh @Catrope -- I just want to flag for you that this task needs to complete QA (@Etonkovidova), Design Review, and PM Review before it goes to users. Hopefully that can be completed in time for next week's train.

Etonkovidova added a subscriber: RHo.

I created a new phab task that includes the above patch ( https://gerrit.wikimedia.org/r/592806) to split from this task - T254197: Echo notifications: add mute/unmute page-linked notifications and moved my comments there.

We have only added the ability to mute and unmute page-linked notifications per task T254197 (and T46787). Placing this larger task to add the mute/unmute functionality for all Echo notifications back to the Growth-team backlog.

Catrope unsubscribed.