It might also be a good idea to provide more info about mute (https://www.mediawiki.org/wiki/Help:Notifications#mute) and/or more information on how they can see their current email/mute list on Special:Preferences

In T218265#5126252, @dmaza wrote:

It might also be a good idea to provide more info about mute (https://www.mediawiki.org/wiki/Help:Notifications#mute) and/or more information on how they can see their current email/mute list on Special:Preferences

Good idea! I'll made that into a separate ticket because we already estimated this one. T221811: Add a Help link to Special:Mute. Thanks. :)

@Niharika After discussing with @dbarratt we agreed that for this task it is not necessary to have a checkbox since the only available option will be to mute or unmute emails (for now). We propose to have a message indicating what action would happen depending if the user is already muted or not.

Here is a screenshots to illustrate what I mean. (Text subject to change).

Very similar screen will be shown with a slightly different text explaining that the user is already muted and that they can unmuted it if they choose to do so by clicking on the blue button.

Let me know what you think.

To clarify, we can only go with that display if we are committing to combine the two lists soon after.

In T218265#5211619, @dmaza wrote:

@Niharika After discussing with @dbarratt we agreed that for this task it is not necessary to have a checkbox since the only available option will be to mute or unmute emails (for now). We propose to have a message indicating what action would happen depending if the user is already muted or not.

Here is a screenshots to illustrate what I mean. (Text subject to change).

Very similar screen will be shown with a slightly different text explaining that the user is already muted and that they can unmuted it if they choose to do so by clicking on the blue button.

Let me know what you think.

+1. That looks good to me! We will add the checkboxes as part of T220163: Allow user to mute notifications from Special:Mute page then, I assume?

Actually, that's a great catch; this should probably also be the fallback for wikis where Echo isn't installed.

Her are all the screens for this feature (so far)

1. Mute User: When a user gets to the page and the "target user" IS NOT in their email blacklist already

2. Un-Mute: When a user gets to the page and the "target user" IS already in their email blacklist.

3. Success: After clicking confirm. Either to mute or un-mute a user

4. Invalid User: If the username provided on the URL is not valid or if no username is provided

5. wgEnableUserEmailBlacklist config set to false: this will only happen if the user tries to access the page directly since the links to it should not be visible.

Any and all messages are "placeholders". If you wish to change them please let me know which ones and in what screen

We were also discussing the possibility of having a default message if a user tries to access the page directly without providing a username instead of displaying the "invalid user" message (#4)

In T218265#5217661, @Mooeypoo wrote:

Actually, that's a great catch; this should probably also be the fallback for wikis where Echo isn't installed.

Makes sense

In T218265#5217631, @Niharika wrote:

+1. That looks good to me! We will add the checkboxes as part of T220163: Allow user to mute notifications from Special:Mute page then, I assume?

Yes, since we are not unifying the lists atm (as per our conversation in other channels)

In T218265#5218762, @dmaza wrote:

Yes, since we are not unifying the lists atm (as per our conversation in other channels)

I just want to point out that if we do not unify the lists, then the message will need to change. For instance, we cannot say "You have requested to mute" or "You have requested to unmute" because we will not know what the user is attempting to do. This is because the user they are performing an action on, could be in a mixed state (not mutted or unmutted).

If we do unify the lists, the messaging (and the clarity of the action(s) being performed) can remain, which is what I would do. This can be done at a later date, but I would prefer to unify the lists over adding the checkboxes.

In our standup yesterday, we discussed this. @Niharika made it clear that she would prefer to have the checkboxes. I'll let her provide her reasoning if she wishes.

In T218265#5221267, @aezell wrote:

In our standup yesterday, we discussed this. @Niharika made it clear that she would prefer to have the checkboxes. I'll let her provide her reasoning if she wishes.

okie dokie. Then I don't think we should have verbs on this page just to remove them later, since we can't add verbs to links either (i.e. we cannot say "Mute user" or "Unmute user").

In T218265#5211696, @dbarratt wrote:

To clarify, we can only go with that display if we are committing to combine the two lists soon after.

@dbarratt Based on T216185#5018338, I would agree with Trevor's comments there that the data does not give us conclusive evidence that merging the lists is a good idea. As a first step, I would like us to move the two mute lists on the same page in Special:Preferences because it is hard to discover the existence of the other list when you are on one. We can then get a better view of whether users add someone to both lists or just one.
Also we can collect some data from this special page - see how often users check both boxes when muting a user.

In T218265#5221514, @Niharika wrote:

@dbarratt Based on T216185#5018338, I would agree with Trevor's comments there that the data does not give us conclusive evidence that merging the lists is a good idea. As a first step, I would like us to move the two mute lists on the same page in Special:Preferences because it is hard to discover the existence of the other list when you are on one. We can then get a better view of whether users add someone to both lists or just one.
Also we can collect some data from this special page - see how often users check both boxes when muting a user.

I don't think we'll ever have conclusive evidence that merging is a good idea unless we do user testing.

But if you'd like to keep them separate, that's totally fine, but the mocks that @dmaza shared will need to be updated as they mix state and actions. We need a way to display the current state (which is ambiguous) and perform whichever action(s) they want (mute/unmute/both).

@dmaza I agree with David that "mute" by itself is ambiguous here. We should indicate that they are attempting to mute emails. So, for the first case, it should be like: "You have requested to mute emails from User:Vandal" and similarly for others.

In T218265#5221553, @Niharika wrote:

@dmaza I agree with David that "mute" by itself is ambiguous here. We should indicate that they are attempting to mute emails. So, for the first case, it should be like: "You have requested to mute emails from User:Vandal" and similarly for others.

The problem is, is that we can't display both the state and perform an action. For instance, if there are checkboxes and you click the link to "Mute the user" would the checkbox be checked or unchecked? The verbage would say "checked" but then you aren't displaying the current state (what if the user is already muted?). I think it would be better to leave this more ambiguous and instead change the email to something like "Mute Preferences" so the user is not performing any action at all (and can decide the action to take once they get to this page and see the state).

What @dbarratt is describing is similar to how Special:Preferences currently works: you arrive at Special:Preferences with the current state and a disabled "Save" button. If you change the state, the "Save" button is enabled, signalling that you've made a change.

If we decide to make Special:Mute work like this, then we would be duplicating Special:Preferences (albeit putting all the muting on one page that can be linked to directly). If we do that, then would it not be better just to make a new "Muting" tab under Special:Preferences, and link to that?

@dbarratt Agreed. We should change the link to be more ambiguous. We discussed this elsewhere too. I'll update the ticket. Also, agree with @Tchanders that we should represent state the same way Special:Preferences does - button is disabled unless state of checkboxes changes (which indicates what is the existing state).

I think we are not duplicating Special:Preferences because we are putting the mute options on one page and making the muting process much more straightforward. In future, we can also have an input box with search to allow users to find other users to mute (instead of only through links). If we use Special:Preferences, we will have to find a way to make users get to that page with the list(s) pre-filled with the usernames they want to mute. I don't know how easy/hard it is to do that. If it's actually easier, I am very much okay with us going that route instead.
Having a singular tab for muting will be helpful for users to find both mute lists too. I think design will have some considerations because we already have too many preference tabs but that's minor.

That's true, the model is different for this page and Special:Preferences. This page is changing the mute preferences of a single user where Special:Preferences is changing the muting preferences for multiple users.

In T218265#5221553, @Niharika wrote:

@dmaza I agree with David that "mute" by itself is ambiguous here. We should indicate that they are attempting to mute emails. So, for the first case, it should be like: "You have requested to mute emails from User:Vandal" and similarly for others.

Sure

I wanna bring back the attention to the mocks. Let me know which of those messages I should change and to what. Some of them are very short and "cold".
Also, this page could also use a bit more text documenting how things work. Maybe adding a paragraph to clarify things? Or maybe not ?

The rest of the comments so far are discussing behavior after T220163: Allow user to mute notifications from Special:Mute page. Not sure if there is anything that applies here. Another thing to consider for T220163: Allow user to mute notifications from Special:Mute page is what happens when one of the two lists are disabled. As @Mooeypoo pointed out one option would be to fall back to a text based interface like this one or we could just show 1 checkbox. In any case, it should probably be added to the task description once a decision is made.

In T218265#5225458, @dmaza wrote:

I wanna bring back the attention to the mocks. Let me know which of those messages I should change and to what. Some of them are very short and "cold".
Also, this page could also use a bit more text documenting how things work. Maybe adding a paragraph to clarify things? Or maybe not ?

1. Mute User: When a user gets to the page and the "target user" IS NOT in their email blacklist already

The text should be changed to something like "Mute Preferences for Vandal. Change how you would like the user to be muted and click "Save""
then there should be a checkbox with a label like "Emails". The checkbox should, by default, reflect the current state. In this instance, it will be unchecked.

2. Un-Mute: When a user gets to the page and the "target user" IS already in their email blacklist.

This page will be the same as the first, but the checkbox will be checked.

The rest of them are perfect.

The rest of the comments so far are discussing behavior after T220163: Allow user to mute notifications from Special:Mute page. Not sure if there is anything that applies here.

No. My point is that we need to make them checkboxes now, and avoid using verbs when arriving at this page. For instance, the email will need to say "Mute options for Vandal" rather than saying "Mute Vandal." (a compromise could be something like "Prevent Vandal from sending me emails" since that feels ambiguous enough)

Another thing to consider for T220163: Allow user to mute notifications from Special:Mute page is what happens when one of the two lists are disabled. As @Mooeypoo pointed out one option would be to fall back to a text based interface like this one or we could just show 1 checkbox. In any case, it should probably be added to the task description once a decision is made.

Yes. A single checkbox is the direction that @Niharika decided on in T218265#5222660. I'm not a fan of this approach, but if we are leaving the lists separate, I think it's really the only option we have.

No. My point is that we need to make them checkboxes now, and avoid using verbs when arriving at this page.

This is what I was doing initially and we talked and agreed on not using a checkbox because there is only one option and it was bad UX (merging the lists or no)

@Niharika your last comment T218265#5221553 is about modifying the text on the mocks and not changing it to a checkbox. Can we make a decision and update the task description? Progress is better than perfection and both options work. We just need to pick one. We can always change it later.

In T218265#5226012, @dmaza wrote:

This is what I was doing initially and we talked and agreed on not using a checkbox because there is only one option and it was bad UX (merging the lists or no)

I only think the checkboxes should be removed if we can commit to merging the lists (but the merging does not have to happen before this task). If we want to keep them as separate, then core is making an explicit decision to allow extensions to add additional mute lists, in which case, we cannot have a binary mute state. Therefore, we have to add a page that reflects the complete state to the user and allows them to modify that state.

The only other option is to make this page only work for email blacklist and not support extensions, but I don't think that's a good idea because it implies to the user that you are muting them, when really you are only partially muting them. I don't think it's wise to communicate to the user that another is muted, when they are not, because the user cannot be "muted" they can only be "muted from X"

I think I understand what @dbarratt means about not using verbs in the text that the user clicks to get to the preferences. That seems right to me.

It could say something like, "Manage mute preferences for Vandal" and then link to a page with checkboxes (even if there's only one right now) that the user could manipulate. The text on that page could be "Set the mute preferences for Vandal and click Submit."

The overall idea being that we are instructing the user to manage preferences via the link(s) and not implying that clicking the link will perform any particular action. It will only get them to the place where an action can be performed.

@dbarratt @Niharika @aezell Can any of you update the task description and summarize how this should look/behave/text in the page and so on? I'm not 100% sure what's the consensus here.

@dmaza On it. After thinking some more about this, I think it is best to go with the checkboxes even if there is only one setting (email) for the sake of consistency. I don't think it makes a massive difference in user experience either way. I am working on updating the ticket description. For the messages, I can suggest placeholders for now but I would love Prateek and Sydney to look at it before it is deployed in production. Maybe on AHT wiki.

In T218265#5226643, @dmaza wrote:

@dbarratt @Niharika @aezell Can any of you update the task description and summarize how this should look/behave/text in the page and so on? I'm not 100% sure what's the consensus here.

I took a stab at it.

@dmaza I updated the task description. The things in bold are new. Did I manage to answer everything?
Sorry that the scope on this ticket keeps changing. :(

In T218265#5227205, @Niharika wrote:

@dmaza I updated the task description. The things in bold are new. Did I manage to answer everything?
Sorry that the scope on this ticket keeps changing. :(

No worries. Right now I only see one thing that needs clarification. (and I quote from the task description)

5. wgEnableUserEmailBlacklist config set to false: this will only happen if the user tries to access the page directly since the links to it should not be visible.

Replace with: Your mute preferences are disabled. You may enable them in Special:Preferences. Return to Main Page.

There are two ways the above could happen (assuming Echo's blacklist is disabled or Echo is not installed)

1. When wgEnableUserEmailBlacklist is set to false
2. When wgEnableSpecialMute is set to false (this would be the new feature flag for this page)
3. When the user has not confirmed their email address

For #3 I think the message that's currently on the description works. For the other two I think we should just redirect to a 404 ( I assume we have one of those )

@dmaza If the user has not confirmed their email address, we should inform them of that. Something like: You must confirm your email address before you can mute a user. You may do so from Special:Preferences. Return to Main Page.

In case the feature flag for the page is turned off, the page will not show up in list of Special pages or anywhere else. It will automatically route to 404 in that case, I believe.

In T218265#5231025, @dmaza wrote:

There are two ways the above could happen (assuming Echo's blacklist is disabled or Echo is not installed)

1. When wgEnableUserEmailBlacklist is set to false
2. When wgEnableSpecialMute is set to false (this would be the new feature flag for this page)

In CommonSettings.php, we can conditionally set a config variable based on another, so if wgEnableUserEmailBlacklist is set to false, we can not enable wgEnableSpecialMute. Example.

Change 511781 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/core@master] [WIP] Add Special:Mute page

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

@Niharika @dmaza There are a few places where the acceptance criteria don't match the behaviour of the patch (PS20). I suspect in some cases the acceptance criteria might just be old, so commenting here instead of in code review.

(Some of these acceptance criteria have been discussed in comments, but they haven't been updated, so I'm not sure whether there was a consensus...)

Checked status of checkboxes

• The link takes the user to the special page (Special:Mute) with the Mute emails from this user already checked. The user is added to the mute list once they hit save. If the user is already muted on that option, the button is checked and the "Submit" button is disabled. It gets re-enabled if the state of the checkbox(es) change.

PS20: The link takes the user to the page with the checkboxes checked according to their current preferences, and the "Confirm" button disabled. (This is the same whether or not the user to be muted was already muted.)

Messages 1 (not already muted) and 2 (already muted)

Keep the messaging from mock (F28688373) [...]

Same as above. [...]

PS20: The message is: Please select your mute preferences for User:ABC. (This is the same whether or not the user to be muted was already muted.)

Message 3

• After save, the checkbox and save button go away and a confirmation message displays: User:ABC has been muted. See all muted users in Special:Preferences. [...]

Replace with: Your mute preferences have been successfully updated. See all muted users in Special:Preferences. [...]

PS20: The message is: Your mute preferences have been successfully updated. [...], rather than: User:ABC has been muted. [...]

Message 5

Replace with: Your mute preferences are disabled. You may enable them in Special:Preferences. Return to Main Page.

PS20:
With $wgEnableUserEmailBlacklist = false, the message is: Muting users from sending you emails is not enabled. Return to Main Page.
With $wgEnableUserEmailBlacklist = true, but email not confirmed, the message is: You must confirm your email address before you can mute a user. You may do so from Special:Preferences

For what it's worth, I'd favour keeping the behaviour of the patch and updating the acceptance criteria.

@Tchanders The messaging looks great to me. I updated the task to be accurate.

Change 511781 merged by jenkins-bot:
[mediawiki/core@master] Add Special:Mute as a shortcut for muting notifications

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

@Niharika emails from Special:EmailUser are in plain/text. Currently the default email footer looks as follow if I use the plain msg:

This email was sent by Admin to Vandal by the "Email this user" function at devwiki. If you reply to this email, your email will be sent directly to the original sender, revealing your email address to them.
[http://dev.wiki.local.wmftest.net:8080/wiki/Special:Mute/Admin Manage email preferences for ‪Admin‬.]

That's not what we initially agreed on 'cause we didn't considered plain/text. Is it ok if we do something like:
To manage email preferences for Admin please visit <http://dev.wiki.local.wmftest.net:8080/wiki/Special:Mute/Admin>

enwiki has edited the footer message[1] to include a link in plain text. We'll basically be using the same "format" for the Special:Mute link when it is appended to the footer

[1]https://en.wikipedia.org/wiki/Special:AllMessages?prefix=emailuserfooter&filter=all&lang=en&limit=50

@dmaza Yeah, I think To manage email preferences for Admin please visit <http://dev.wiki.local.wmftest.net:8080/wiki/Special:Mute/Admin> is perfectly fine.

enwiki has edited the footer message[1] to include a link in plain text. We'll basically be using the same "format" for the Special:Mute link when it is appended to the footer

Makes sense.

Change 519278 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/core@master] Change Special:Mute link on email footer to be in plain text

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

@dmaza The email footer I see now (in my MUA at least) is: To manage email preferences for Steve please visit &lt;http://192.168.122.72/T218265/index.php/Special:Mute/Steve&gt;.

In T218265#5288275, @dom_walden wrote:

@dmaza The email footer I see now (in my MUA at least) is: To manage email preferences for Steve please visit &lt;http://192.168.122.72/T218265/index.php/Special:Mute/Steve&gt;.

Let me look into this

Change 519278 merged by jenkins-bot:
[mediawiki/core@master] Change Special:Mute link on email footer to be in plain text

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

The email footer now appears fine for me. Including with RTL usernames (converting the username to url encoded hexadecimal in the Special:Mute link).

Also tested using the PEAR Mail backend.

Functionally, I have seen no problems muting and unmuting users via Special:Mute. The correct users are muted/unmuted when viewed in Special:Preferences.

Special:Mute correctly reflects the status of preexisting mutes (checkbox is checked/unchecked as appropriate). Including no-JS.

Without JS, the Confirm button remains always enabled and the form is submittable. But, there are no problems with duplicate mutes (indeed, there is code in there to prevent this).

I briefly tested the form using the mobile frontend. It is so simple I cannot imagine any cross-platform issues.

I was only able to test this locally (cbc4219 and ed13d3f), as it has not been enabled on beta.

@Niharika Just to confirm. Should the form header include User: as part of the text or just the username?
E.g
"Please select your mute preferences for ‪User:Vandal‬."
vs
"Please select your mute preferences for Vandal‬."

There's a bit of an issue with including "User" in the human-readable text. In English it reads well. But what do I do in Russian? There are several issues:

• It will be translated as "Пожалуйста, выберите настройки уведомлений от User:$1." or "... от Участник:$1." In the first case there's an English word in a Russian sentence, which is not great. In the second case, it is grammatically awkward because the word Участник (User) in Russian is supposed to be declined be grammatical case. Участник:Vandal looks OK as a title of a user page, but it was not made to appear in a sentence.
• What will happen if the user interface language is different from the wiki language? This happens quite often, for example on sites like Meta or translatewiki. It it's a link, it will be broken.
• There is also the consideration of gender. In some languages, the User: namespace prefix has gender aliases.

And of course, Russian is just one example. There are other problems in other languages.

To sum up, "User:" is kind of OK for a standalone title, but it's not good for human-readable text in a sentence. Link targets that aren't supposed to be human-readable should use the English prefix because it works everywhere.

If it's important to include the word "user", it's better to have it as a word in a sentence and not as a namespace prefix, e.g.: "Please select your mute preferences for user [[User:Vandal|Vandal‬]]".

@dmaza I prefer the non-prefixed version as I think User: is unnecessary context.

In T218265#5313664, @dbarratt wrote:

@dmaza I prefer the non-prefixed version as I think User: is unnecessary context.

I do too and one of the initial versions of the message was without it. I thought you wanted the prefix since you updated the task description and acceptance criteria several times.

@Amire80 T218265#5313454 You have a solid argument here. Thank you

In T218265#5313776, @dmaza wrote:

I thought you wanted the prefix since you updated the task description and acceptance criteria several times.

Unintentional oversight. Though we probably should leave it up to @Niharika. :)

@dmaza @dbarratt My concern is that sometimes it might not be obvious that we are talking about a username. Like Please select your mute options for Optional (Actual user). How about we say - Please select your mute preferences for user Optional like Amire suggests? I like that option.

That works for me!

Change 520939 had a related patch set uploaded (by Tchanders; owner: Amire80):
[mediawiki/core@master] Improve links in several specialmute-*

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

Change 520939 merged by jenkins-bot:
[mediawiki/core@master] Improve links in several specialmute-*

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