Page MenuHomePhabricator

Mute: Add links to disable email and mute specific user to emails sent via Special:EmailUser
Open, NormalPublic5 Story Points

Description

If a user creates a Wikimedia account and verifies their email address, their preferences are automatically configured to allow direct email from other users.

These emails do not include links in the footer to adjust any preferences. The user may want to disable emails from a specific user, if the emails are undesired.

English WikipediaDefault MediaWiki

Acceptance criteria

  • Extend the email footer to include links to configure preferences
    • Consider using a new message that is not customizable so local wikis cannot override the links.
  • Clicking the links will take the user to a special confirmation page with text to explain what will happen and a button to click to confirm the action:
    • Rough design:
      (note that this task is only about adding the first checkbox. second one in T220163})
    • If Echo is disabled or one of the lists are disabled, only one option is shown (still a checkbox)
  • The link should be:
    • Manage email preferences for $USERNAME
  • 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.
  • 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. - the link goes to Special:Preferences on the wiki they are on.
  • If user is logged-out, the user is taken to the login page before redirecting them to Special:Mute.
  • The special page is behind a feature flag.
Messages:

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

Keep the messaging from mock (F28688373) with only one checkbox if the other option is not enabled.

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

Same as above. Keep the checkbox checked but the "Submit" button disabled to indicate the user is already muted. If the user unchecks the checkbox, the button gets enabled and on click, the user is unmuted.

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

Replace with: Your mute preferences have been successfully updated. See all muted users in Special:Preferences. - the link goes to Special:Preferences on the wiki they are on.

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

Replace with: The username requested could not be found. Return to Main Page.

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

Event Timeline

Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptMar 13 2019, 9:28 PM
aezell updated the task description. (Show Details)Apr 4 2019, 6:40 PM
Niharika triaged this task as Normal priority.Apr 4 2019, 6:44 PM
Niharika set the point value for this task to 5.
Niharika added subscribers: aezell, dmaza, dbarratt and 2 others.EditedApr 4 2019, 8:54 PM

@dbarratt @Tchanders @dmaza @aezell. I came up with this mockup for the special page:


I thought it would be a good idea to allow users to mute someone from both emails and notifications in the same view. We can do this without unifying the lists. This way the user has the flexibility to mute either notifications or emails but the UX is much better. If the user comes to this from email links, we check the Mute emails from this user by default. If they come from notifications, we check Mute notifications from this user by default.

What do y'all think?

I know this ticket is only about email mute. I can make another one for the mute notifications part if you all think this is a valid idea.

This wouldn't replace the existing Mute management fields in Special:Preferences right? It's just a landing page for links from the email/notifications?

I like that it's the same view. It lets the user do what they want to do but also gives them the opportunity to further protect themselves.

This wouldn't replace the existing Mute management fields in Special:Preferences right? It's just a landing page for links from the email/notifications?

Yep. We can add a user-search feature to this page in the future too if it seems useful. We can't pull the lists away from preferences because that would break global preferences compatibility.
I would like to add some instrumentation here to see -

  1. How many users land on this page over a given time period
  2. How often both boxes are checked by user before saving

I think this data would be helpful in evaluating if we are making an impact in usability of this feature by introducing the special page.

I'm not sure it should replace the existing fields... wont that break GlobalPreferences?

Oh nevermind, I read that backwards. :) I think we're all in agreement. :)

Niharika updated the task description. (Show Details)Apr 17 2019, 5:31 PM
Niharika updated the task description. (Show Details)
dmaza added a comment.Apr 19 2019, 8:56 PM

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

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

dmaza claimed this task.

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

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

{F29236553}

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.

dmaza added a comment.Tue, May 28, 9:01 PM

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

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

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

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

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


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

Makes sense

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

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

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.

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

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

Tchanders added a comment.EditedWed, May 29, 4:57 PM

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.

dmaza added a comment.Fri, May 31, 4:56 AM

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

dbarratt added a comment.EditedFri, May 31, 12:20 PM

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.

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

dbarratt added a comment.EditedFri, May 31, 1:04 PM

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.

dmaza added a comment.EditedFri, May 31, 5:28 PM

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

dbarratt updated the task description. (Show Details)Fri, May 31, 7:52 PM

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

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

Niharika updated the task description. (Show Details)Fri, May 31, 8:10 PM
Niharika updated the task description. (Show Details)Fri, May 31, 8:13 PM

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

dmaza updated the task description. (Show Details)Mon, Jun 3, 4:40 PM
dmaza added a comment.Mon, Jun 3, 4:47 PM

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


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

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