Copied relevant comments from T115264:

In T115264#6173809, @MMiller_WMF wrote:

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

For @RHo Design Review

(1) From the task T115264 description

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

The implemented solution includes the following:

• mute/unmute page-linked notifications functionality (the functionality for excluding pages was addressed in T46787: Allow excluding pages from the page links notifications )
• echo notifications will be blocked, not "automatically marked as seen"as proposed in the task description

(2) Works as expected - the screenshots from this task description (the same as in @Catrope's comment illustrate perfectly the UI implementation.

(3 )The only one omission - to make echo notifications that are from muted pages look different from unmuted pages - e.g. as in the first mockup in the task (the crossed-out bell icon)
No indication whether a page is muted or unmuted unless the dropdown is open:

vs the mock displaying the cross-out bell icon:

(4) the functionality for non-javascript users was also checked.

Thanks @Etonkovidova - I agree with your note on item #3, and also spotted a weird bug whilst testing functionality (under item #1), but not sure these would be considered blockers. Moving to PM for @MMiller_WMF to review:

In T254197#6183296, @Etonkovidova wrote:

[...]
(1) From the task T115264 description

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

The implemented solution includes the following:

• mute/unmute page-linked notifications functionality (the functionality for excluding pages was addressed in T46787: Allow excluding pages from the page links notifications )
• echo notifications will be blocked, not "automatically marked as seen"as proposed in the task description

This seems fine except for a bug on the action menu whereby after the action is selected the "..." icon disappears from the notification panel until is re-opened and finishes reloading, and on the Special:Notifications page the "..." never reappears until the page is refreshed:

Disappearing "..." icon on Notifications panel (re-appears after panel reloads)	Disappearing "..." icon on Special:Notifications (requires refreshing page entirely)
https://youtu.be/Fit8dvaMtoE	https://youtu.be/J8aJ_NQEwQY

@MMiller_WMF - I have created T254276 to track this bug separately. Since users can unmute/mute via the Preferences page even if they don't realise the icon re-appears though, it's not ideal but not a dealbreaker.

(2) Works as expected - the screenshots from this task description (the same as in @Catrope's comment illustrate perfectly the UI implementation.

LGTM as well.

(3 )The only one omission - to make echo notifications that are from muted pages look different from unmuted pages - e.g. as in the first mockup in the task (the crossed-out bell icon)
No indication whether a page is muted or unmuted unless the dropdown is open:

vs the mock displaying the cross-out bell icon:

So I am assuming partly the reason is because since the proposed mock was made, there has been a change to the Notifications panel whereby the top right corner of a notification shows a read/unread toggle icon where the muted bell was shown?
Again, not sure if this is a blocker but it would be nice to show the muted unbell icon in place of the unread/read toggle icon so that users can see that the notification has been muted without having to open the menu. This is my proposed update:

Muted notification	Nested muted notification

Checked in testwiki wmf.35 - seems to work as expected.

In T254197#6186533, @RHo wrote:

Thanks @Etonkovidova - I agree with your note on item #3, and also spotted a weird bug whilst testing functionality (under item #1), but not sure these would be considered blockers. Moving to PM for @MMiller_WMF to review:

In T254197#6183296, @Etonkovidova wrote:

(3 )The only one omission - to make echo notifications that are from muted pages look different from unmuted pages - e.g. as in the first mockup in the task (the crossed-out bell icon)
No indication whether a page is muted or unmuted unless the dropdown is open:

vs the mock displaying the cross-out bell icon:

So I am assuming partly the reason is because since the proposed mock was made, there has been a change to the Notifications panel whereby the top right corner of a notification shows a read/unread toggle icon where the muted bell was shown?
Again, not sure if this is a blocker but it would be nice to show the muted unbell icon in place of the unread/read toggle icon so that users can see that the notification has been muted without having to open the menu. This is my proposed update:

Muted notification	Nested muted notification

Thanks, @RHo - I filed it as T254294: Mute/unmute icons in Notifications for page-linked notices.

I just tested things out in Beta and the functionality seems to work right. I have two issues below, and I'd like to know if @RHo thinks they are blockers, should be fixed quickly on the next train, or should be fixed at some point not urgently. I think that the issues that @RHo and @Etonkovidova found are not blockers, but should be considered for the next train.

Shortening message

I think the message to mute/unmute is too long. I don't think it needs to include the page title. You can see in the images below that on mobile, the page title never makes the cut, and on desktop, only the first two letters make it. How about we just make them say, "Unmute link notifications" or "Mute link notifications"?

State changes

In the gif below, you can see that I have notifications for many links made to the same article. This means that in my notifications list, I have multiple rows to choose from where I can select to mute or unmute notifications. When I unmute (or mute) via one of them, I think there are two issues:

1. When I open the menu again on that same item, the option to undo what I just did is not there. This might be concerning to a user who was just experimenting around, and wants to undo their muting.
2. When I open the menu on the other occurrences of that same article in the list, they still say the original option -- their state hasn't changed. So I may have just unmuted, but then have the option to unmute again on the other articles, instead of now having the option to mute.

@RHo -- what do you think of this?

In T254197#6186533, @RHo wrote:

(3 )The only one omission - to make echo notifications that are from muted pages look different from unmuted pages - e.g. as in the first mockup in the task (the crossed-out bell icon)
No indication whether a page is muted or unmuted unless the dropdown is open:
[...]

So I am assuming partly the reason is because since the proposed mock was made, there has been a change to the Notifications panel whereby the top right corner of a notification shows a read/unread toggle icon where the muted bell was shown?
Again, not sure if this is a blocker but it would be nice to show the muted unbell icon in place of the unread/read toggle icon so that users can see that the notification has been muted without having to open the menu.

It might be that the mocks we were working from predate the mark-as-unread feature, and that they assumed a muted notification would always be read, never unread (the mock shows a read notification, at least). Putting the unbell icon where you suggest would break the ability to mark a notification for a muted page as unread, but that's not a very important action. We could also bury the mark-as-unread action in the dropdown menu for those notifications.

If you have an unread notification for a muted page, this would be more of a problem, because you presumably want to be able to mark those as read, and you shouldn't have to dig into the dropdown to find that option (especially since, when you went into the dropdown to mute the notification, the mark as read option wasn't there yet). One way we could consider mitigating this is to automatically mark a notification as read when you mute it(*). On the one hand, that seems like it could be intuitive, but on the other hand, I'm not totally sure that it would be desirable because marking notifications as read unbundles them (if they were bundled), and also makes them jump down (because we sort unread notifications above read ones). Users may or may not expect these things to happen.

Either way, I'd be happy to put the unbell icon there, I think it's a good idea and it'd be easy to do, but I think the conflict between it and mark as read/unread needs to be addressed. That could be done through the suggestions above, or more simply by putting the unbell icon somewhere else where it doesn't block the read/unread control (maybe right next to it, to its left?)

(*) When muting a notification that's part of a bundle, we'd want to mark the entire bundle as read, as all notifications in the bundle will become muted, since they are about the same page. In the case of page-linked notifications, notifications that mute together also bundle together, so that's convenient. This isn't true for some other notification types, but we don't have a mute feature for any of those.

In T254197#6187383, @MMiller_WMF wrote:

Shortening message

I think the message to mute/unmute is too long. I don't think it needs to include the page title. You can see in the images below that on mobile, the page title never makes the cut, and on desktop, only the first two letters make it. How about we just make them say, "Unmute link notifications" or "Mute link notifications"?

This will be mitigated by this change. It reverses the direction of the dropdown menu when it needs the space, so the message will be more likely to fit. I had expected that change to get reviewed and merged before the larger change implementing the mute feature, but it didn't. I'll ask Moriel to review it again, or I can ask Kosta and Gergő once we're less busy with the final stretch of the guidance feature.

Before	After

State changes

In the gif below, you can see that I have notifications for many links made to the same article. This means that in my notifications list, I have multiple rows to choose from where I can select to mute or unmute notifications. When I unmute (or mute) via one of them, I think there are two issues:

1. When I open the menu again on that same item, the option to undo what I just did is not there. This might be concerning to a user who was just experimenting around, and wants to undo their muting.

This bothered Rita too, and she filed T254276: Echo notifications: Action menu more "..." icon disappears when mute/unmute action is selected

1. When I open the menu on the other occurrences of that same article in the list, they still say the original option -- their state hasn't changed. So I may have just unmuted, but then have the option to unmute again on the other articles, instead of now having the option to mute.

Incidentally, this sort of state synchronization, where the same state needs to be correctly reflected in multiple places in the UI, is one of the categories of things that's a bit of a pain to do in OOUI but that Vue (and particularly Vuex) makes easy. We can fix this, but it'll be another moment where I'm grumbling "can I have Vue already" to myself while doing it. (That's a bit of a non sequitur but maybe that helps you understand why Vue is exciting for engineers.)

In T254197#6187556, @Catrope wrote:

In T254197#6187383, @MMiller_WMF wrote:

Shortening message
I think the message to mute/unmute is too long. I don't think it needs to include the page title. You can see in the images below that on mobile, the page title never makes the cut, and on desktop, only the first two letters make it. How about we just make them say, "Unmute link notifications" or "Mute link notifications"?

This will be mitigated by this change. It reverses the direction of the dropdown menu when it needs the space, so the message will be more likely to fit. I had expected that change to get reviewed and merged before the larger change implementing the mute feature, but it didn't. I'll ask Moriel to review it again, or I can ask Kosta and Gergő once we're less busy with the final stretch of the guidance feature.

@MMiller_WMF - this fix seems fine to me. Whilst I do like the brevity of the copy change, at the same time it seems useful to specify what is being muted, especially for future when mute may be on other notification types where the object of the mute may not be as clear-cut.

State changes
In the gif below, you can see that I have notifications for many links made to the same article. This means that in my notifications list, I have multiple rows to choose from where I can select to mute or unmute notifications. When I unmute (or mute) via one of them, I think there are two issues:

1. When I open the menu again on that same item, the option to undo what I just did is not there. This might be concerning to a user who was just experimenting around, and wants to undo their muting.

This bothered Rita too, and she filed T254276: Echo notifications: Action menu more "..." icon disappears when mute/unmute action is selected

– To confirm @MMiller_WMF - should T254276 be worked on for the next train?

2. When I open the menu on the other occurrences of that same article in the list, they still say the original option -- their state hasn't changed. So I may have just unmuted, but then have the option to unmute again on the other articles, instead of now having the option to mute.

@RHo -- what do you think of this?

Incidentally, this sort of state synchronization, where the same state needs to be correctly reflected in multiple places in the UI, is one of the categories of things that's a bit of a pain to do in OOUI but that Vue (and particularly Vuex) makes easy. We can fix this, but it'll be another moment where I'm grumbling "can I have Vue already" to myself while doing it. (That's a bit of a non sequitur but maybe that helps you understand why Vue is exciting for engineers.)

– @MMiller_WMF - I think this is not so good. However, since it is only on the page-linked notification type for now, which is more of a power-user feature request, I would be OK to let it go especially if @Catrope is saying that once we switch to Vue this will fix such issues. Though actually another proposal I have is to only show the mute/unmute action on the parent item. This makes it clearer also that the action is to mute notifications for all links to that page.

Thanks for explaining, @Catrope. @RHo and I agreed that nothing blocks this being in production tomorrow. We'll file and triage the remaining issues separately.

@Trizek-WMF -- has this already been announced in Tech News? Or will it be announced soon?

I forgot to log it there, but yes, it has been announced on Tech News.