Page MenuHomePhabricator

Introduce the New Filters to Watchlist users upon beta graduation (and provide instant opt-out)
Closed, ResolvedPublic

Description

NOTE: the functionality described below is the same as that in T169613, which introduced the New Filters on RC Page. The only differences are: 1) Improved wording for messages (see below), and 2) everything happens on Watchlist and works with Watchlist preferences, 3) we added an actual opt-out button to the the Notice that informs you about the ability to opt out.

When the New Filters graduate out of beta on Watchlist, we will:

  • Introduce the new filters to users getting them for the first time. This applies only to users that didn't have the beta feature enabled, but now will see the new feature since it become the default.
  • Provide a path to disable the new feature. We expect users to like the new filters, but providing them some flexibility to go back to the old system provides them an emergency exit to some issues (e.g., a specific gadget breaking the new tool), avoiding unnecessary stress.

The Introduction Popover

  • After graduation, when a user who was not previously opted in to the beta visits Watchlist for the first time, a popover will appear introducing the new features.
  • The popover remains visible for 4 seconds, and then disappears.
  • The user can also dismiss the popover by 1) clicking the "OK, got it" button, 2) clicking a link to navigate away from the page 3) clicking the page anywhere outside the popover.
  • Once it is dismissed or disappears on its own, the Introduction should not be shown to that user on that wiki again.
  • Different messages are shown to ORES vs. non-ORES wikis (wording below--Please note that I've suggested changed wording in both the message headlines and body text.).
  • A "Learn more" link is provided. The link opens a new tab/browser and goes to the RC Filters page on mediawiki.
  • The design of the popover will be based the same as the one we show for Recent Changes
    • The image used in the panel will be animated. A non-looping animated Gif for the animation is available at F5053416

The preferences Notice (and opt-out button)

After the Introduction disappears or is dismissed, another popover appears giving the user notice that the new features can be disabled.

  • The Notice appears below and points at the Preferences link in the top navigation.
  • The Notice includes a gear icon (see design below), a button to "Disable now", and a button to dismiss labeled "OK, got it."
  • If the user clicks the "Disable now" button, the opt-out preference on the Watchlist preferences tab is activated and Watchlist reverts to the old UI.
  • The notice persists until the user clicks "Disable now" or "OK, got it" or clicks the X in the corner or navigates to a different page.
  • The Notice will not be repeated for that user on that wiki.

Wording for popovers and notice

[INTRODUCTION, ORES VERSION]
Welcome to improved Watchlist filtering
Review edits more efficiently using new filters, the ability to save sets of filters, user-defined highlighting and the power of machine learning.

[INTRODUCTION, NON-ORES]
Welcome to improved Watchlist filtering
Review edits more efficiently using new filters, the ability to save sets of filters, user-defined highlighting and other improvements.

[NOTICE]
Access the Watchlist tab in preferences any time to opt out of the improved Watchlist.
[BUTTON 1] Opt out now [BUTTON 2] OK, got it

Implementation

For logged-in users, it should use preferences, as usual.
For anonymous users, it should use jquery.jStorage, with a TTL. I suggest a year.

Details

Related Gerrit Patches:
mediawiki/extensions/WikimediaMessages : masterFollow-up e650606e4eb: respect watchlist preference feature flag
mediawiki/extensions/WikimediaMessages : wmf/1.32.0-wmf.7Follow-up e650606e4eb: respect watchlist preference feature flag
mediawiki/extensions/WikimediaMessages : masterRCFilters: Add guided tour for Watchlist, with instant opt-out

Related Objects

Event Timeline

jmatazzoni triaged this task as Medium priority.May 23 2018, 10:57 PM
jmatazzoni created this task.

Regarding the initial dialog, the messaging works for me but I think we can adjust it to mention one of the features that is specially relevant for the watchlist ("saved filters") instead of the more generic "improved interface". If the other version is preferred, I can just update the mockup.

The text used is:

Review edits more efficiently using new filters, user-defined highlighting, saved filters, and the power of machine learning.

Regarding the preferences notice, the original intent was for the message to go away automatically after 3 seconds, which it does not seem to be the case. In this case, I think it makes sense to surface a more explicit choice and the dialog not to go away automatically:

If this make sense, I can create a sub-ticket and remove the "vanishing after 3 seconds" requirement from the description in the current ticket.

Regarding the initial dialog, the messaging works for me but I think we can adjust it to mention one of the features that is specially relevant for the watchlist ("saved filters") instead of the more generic "improved interface".

Review edits more efficiently using new filters, user-defined highlighting, saved filters, and the power of machine learning.

Some remarks about that sentence

  • Maybe change "review" by "watch", to match the purpose of the page
  • Shouldn't we be a bit more explicit about the saved filters ? Something explaining that they can allow multiple watchlists.

Tentative:

Watch edits more efficiently using new filters, user-defined highlighting, personal combinations of filters, and the power of machine learning.

If this make sense, I can create a sub-ticket and remove the "vanishing after 3 seconds" requirement from the description in the current ticket.

Definitely makes sense!

In T195427#4242815, @Trizek-WMF wrote:

  • Shouldn't we be a bit more explicit about the saved filters ? Something explaining that they can allow multiple watchlists.

I don't understand how this counts as multiple watchlists. Can you explain the use case you are imagining?

At the moment, you have on your watchlist all edits made on pages you watch, with a few filtering options.

Using saved filters can allow me to:

  • watch pages edited by newcomers
  • watch pages on the user talk: namespace (mostly for interactions between newcomers and others)
  • watch the Help: namespace, especially edits made by experienced users (to avoid edits that are out of scope)

Those are the main cases for which I have a saved filter. Selecting one filter combination or another makes me feel I have different watchlist.

Those are the main cases for which I have a saved filter. Selecting one filter combination or another makes me feel I have different watchlist.

I understand how the current filters cover your usecase for the different views you need. Both, saved filters and multiple watchlists are aimed at managing the complexity of long watchlists and have overlaps. However, I'd be cautious on making the claim that this solves the "multiple watchlist" case.

The "multiple watchlist" concept can be associated with the idea of having views based on different kinds of topics (e.g., watch my topics of interest on astronomy, or my favourite architects), for which we don't provide much support. The upcoming category filter support, will help to increase the overlap with the concept of "multiple watchlist", but still not to the 100% (i.e., arbitrary lists of articles of my choice). So a claim in that direction can result in unmeet expectations and requests to fill the remaining parts which are not in our immediate plans.

Trizek-WMF added a comment.EditedMay 30 2018, 5:49 PM

To avoid confusion, Joe and I just went for "the ability to create special-purpose filter sets and save them for re-use" in the announcement, instead of introducing a pseudo-multiple watchlist feature.

jmatazzoni updated the task description. (Show Details)

In T195427#4242548, @Pginer-WMF wrote:

Regarding the initial dialog, the messaging works for me but I think we can adjust it to mention one of the features that is specially relevant for the watchlist ("saved filters") instead of the more generic "improved interface". If the other version is preferred, I can just update the mockup.

Good idea. I updated the text above and added a "Not final wording" warning to your mockup. If you prefer to update the mockup, see the updated wording I've provided in the description above.

Regarding the preferences notice, the original intent was for the message to go away automatically after 3 seconds... I think it makes sense to surface a more explicit choice and the dialog not to go away automatically: If this make sense, I can create a sub-ticket and remove the "vanishing after 3 seconds" requirement from the description in the current ticket.

Again, I agree. I don't know that we need a separate ticket; I've updated the description above and added your mockup. I hacked the text in your image to capitalize the W in Watchlist, as per the text I supplied. It's your choice whether to update the image or live with the hack.

jmatazzoni renamed this task from Introduce the New Filters to Watchlist users upon beta graduation to Introduce the New Filters to Watchlist users upon beta graduation (and provide instant opt-out).May 30 2018, 11:21 PM
Pginer-WMF updated the task description. (Show Details)Jun 1 2018, 11:04 AM
Pginer-WMF updated the task description. (Show Details)

Ok. I updated the mockups in the description to illustrate the new messages.

Just to refresh my mind: what happen when, on the first pop-up, the person clicks on "Learn more"? How people can opt-out after clicking on that link? Do they get the pop-up until they have clicked on "Ok, got it"?

Speaking of "Ok, got it", don't you think people will have the feeling that it is not possible to opt-out when they read the first pop-out? Shouldn't we change that message to "Next" or something that would suggest that there is a new step after?

In T195427#4248632, @Trizek-WMF wrote:

Just to refresh my mind: what happen when, on the first pop-up, the person clicks on "Learn more"?

It's a good question. @Pginer-WMF? (While we want everyone to see the opt out message, we don't need to go to heroic measures to make sure they see it. But maybe it would be not too hard to track the two notices separately? So that if someone saw panel #1 but not panel #2, they would see the opt-out message (#2) the next time they visit the page? @Catrope, would that be a significant complication or pretty easy?

! In T195427#4249211, @jmatazzoni wrote:

In T195427#4248632, @Trizek-WMF wrote:

Just to refresh my mind: what happen when, on the first pop-up, the person clicks on "Learn more"?

@Catrope suggests a simpler suggestion than my idea above, but one that would—now that I've had a chance to think about it—change the spec above in ways we might not want to. His idea is to simply make users click the "OK, got it" button on the first panel. Until they do, we keep showing it.
That would definitely solve the problem of users who click Learn More.

However, our original spec for this states that

The popover remains visible for 4 seconds, and then disappears.
The user can also dismiss the popover by 1) clicking the "OK, got it" button, 2) clicking a link to navigate away from the page 3) clicking the page anywhere outside the popover..

So we'd have to throw all that overboard, which might make this popup a little annoying. @Pginer-WMF?

Some comparison to the RC filters popup (for the comparison testing after deployment).

Just to refresh my mind: what happen when, on the first pop-up, the person clicks on "Learn more"?

I re-checked the behavior of RC popups and it behaves according to the spec: "The link opens a new tab/browser and goes to the RC Filters page on mediawiki." A new browser tab is open but the popup is still displayed on a page.

How people can opt-out after clicking on that link?

For RC filters, the second popup provided some instructions: "Access your preferences any time to disable the improved version of Recent Changes."

Do they get the pop-up until they have clicked on "Ok, got it"?

Or to click somewhere on a page. We did not have the time limit spec for RC filters.

Speaking of "Ok, got it", don't you think people will have the feeling that it is not possible to opt-out when they read the first pop-out? Shouldn't we change that message to "Next" or something that would suggest that there is a new step after?

Comparing to RC filters - the second step appeared automatically after ""Ok, got it" and gave some instructions how to opt out, but a user might never get to that next step (which was acceptable for RC filter feature).

Change 436959 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/WikimediaMessages@master] RCFilters: Add guided tour for Watchlist, with instant opt-out

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

@Catrope suggests a simpler suggestion than my idea above, but one that would—now that I've had a chance to think about it—change the spec above in ways we might not want to. His idea is to simply make users click the "OK, got it" button on the first panel. Until they do, we keep showing it.

"OK, got it" sounds like "it will be enabled when you click the button". Which may confuse some users.

Change 436959 merged by jenkins-bot:
[mediawiki/extensions/WikimediaMessages@master] RCFilters: Add guided tour for Watchlist, with instant opt-out

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

Stryn added a subscriber: Stryn.Jun 5 2018, 2:14 PM

Ok, so more popups :(

If I had the beta enabled do I get the "The preferences Notice (and opt-out button)" popup?
I hope not.

So those who work cross-wiki it would be wise to enable the beta feature for them right now, otherwise they will get that popup spam on every wiki they visit. I think I will do it.

! In T195427#4257654, @Stryn wrote:

Ok, so more popups :(
If I had the beta enabled do I get the "The preferences Notice (and opt-out button)" popup?
I hope not.

No one who has the beta will see any popups, as per above:

After graduation, when a user who was not previously opted in to the beta visits Watchlist for the first time, a popover will appear introducing the new features.

So those who work cross-wiki it would be wise to enable the beta feature for them right now, otherwise they will get that popup spam on every wiki they visit. I think I will do it.

GlobalPreferences may help you, if they are deployed just before. :)

Change 437649 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/WikimediaMessages@master] Follow-up e650606e4eb: respect watchlist preference feature flag

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

Change 437650 had a related patch set uploaded (by Reedy; owner: Catrope):
[mediawiki/extensions/WikimediaMessages@wmf/1.32.0-wmf.7] Follow-up e650606e4eb: respect watchlist preference feature flag

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

Change 437650 merged by jenkins-bot:
[mediawiki/extensions/WikimediaMessages@wmf/1.32.0-wmf.7] Follow-up e650606e4eb: respect watchlist preference feature flag

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

Change 437649 merged by jenkins-bot:
[mediawiki/extensions/WikimediaMessages@master] Follow-up e650606e4eb: respect watchlist preference feature flag

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

Looks good in my testing, but @Etonkovidova is the expert. :-)

@Catrope - I checked for the users with previously enabled Watchlist beta feature, i.e.
up_property= rcenhancedfilters up_value= 1
It looks that they all will be seeing that invite tour.

To summarize:

(1) The popover does not disappear by itself. Btw, it's consistent with RC filters intro popup.

The popover remains visible for 4 seconds, and then disappears.

(2) Again, consistent with RC invite tour, the popup could be brought back by "Restore all default settings".

Once it is dismissed or disappears on its own, the Introduction should not be shown to that user on that wiki again.

(3) (minor)

A "Learn more" link is provided. The link opens a new tab/browser and goes to the RC Filters page on mediawiki.

Although there are lang-specific pages for 'Learn more' (e.g. https://www.mediawiki.org/wiki/Edit_Review_Improvements/New_filters_for_edit_review/es),the link will be alwayas redirect to English version - https://www.mediawiki.org/wiki/Edit_Review_Improvements/New_filters_for_edit_review

(4) (most likely test environment specific)
When ORES tables are present, but empty - e.g. betalabs eswikibooks - the popup will be present over the error page:

Some screenshots:

ORES wiki:

non-ORES wiki:

The second step:

Trizek-WMF added a comment.EditedJun 21 2018, 8:10 AM

The popover remains visible for 4 seconds, and then disappears.

For some languages, 4 seconds only may make the message very difficult to read. Only an action taken by the user should dismiss the popover. The current status seems to be right then.

The popover remains visible for 4 seconds, and then disappears.

For some languages, 4 seconds only may make the message very difficult to read. Only an action taken by the user should dismiss the popover. The current status seems to be right then.

I referred to this in T195427#4242548. The original proposal for making it go away automatically was intended for the original message of Recent Changes, where there were no controls for actions needed by the user. Here it does not make sense for the message to disappear automatically. Currently it seems it is not disappearing, so we can just leave it as it is.

The popover remains visible for 4 seconds, and then disappears.

For some languages, 4 seconds only may make the message very difficult to read. Only an action taken by the user should dismiss the popover. The current status seems to be right then.

I referred to this in T195427#4242548. The original proposal for making it go away automatically was intended for the original message of Recent Changes, where there were no controls for actions needed by the user. Here it does not make sense for the message to disappear automatically. Currently it seems it is not disappearing, so we can just leave it as it is.

I completely agree. I just marked the not-implemented requirements, not to imply that they must be done :)

I completely agree. I just marked the not-implemented requirements, not to imply that they must be done :)

So everything is ready! Cool! :)

I'm fine with requiring user action. Thanks for your input Pau.

Etonkovidova updated the task description. (Show Details)Jun 25 2018, 5:16 PM

@jmatazzoni - the following is not done:

After graduation, when a user who was not previously opted in to the beta visits Watchlist for the first time, a popover will appear introducing the new features.

QA Recommendation: Product should weigh in

As @SBisson suggested, we can use maintenance/initUserPreference.php to set the wlenhancedfilters-seen-tour preference based on the value of the beta feature (rcenhancedfilters).

Moreover, as @Pginer-WMF suggested, we can make sure new accounts registered after the deployment don't get the tour by setting the seen-tour preferences from an account creation hook (similar to what Echo does for some notification prefs).

Moving this back to In Dev. As per our discussion meeting June 25, we will fix this so that we make a hidden preference that records whether users had the beta or not. Or, as Roan put it:

In T195427#4312934, @Catrope wrote:

As @SBisson suggested, we can use maintenance/initUserPreference.php to set the wlenhancedfilters-seen-tour preference based on the value of the beta feature (rcenhancedfilters).

Meanwhile, I've created a subtask for this task to handle users who register AFTER beta graduation— T198141 —since we also don't want them to see these notices.

Vvjjkkii renamed this task from Introduce the New Filters to Watchlist users upon beta graduation (and provide instant opt-out) to secaaaaaaa.Jul 1 2018, 1:08 AM
Vvjjkkii removed Catrope as the assignee of this task.
Vvjjkkii raised the priority of this task from Medium to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed subscribers: gerritbot, Aklapper.
CommunityTechBot renamed this task from secaaaaaaa to Introduce the New Filters to Watchlist users upon beta graduation (and provide instant opt-out).Jul 2 2018, 4:31 AM
CommunityTechBot assigned this task to Catrope.
CommunityTechBot lowered the priority of this task from High to Medium.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added subscribers: gerritbot, Aklapper.
Etonkovidova updated the task description. (Show Details)Jul 5 2018, 5:05 PM

Checked in betalabs

  • users that had New filters as beta feature before won't see the intro popup - according to the specs
  • new user accounts created after New filters are out of beta, won't see the intro popup - according to the specs

However, FF 60 (on MacOS and Windows) shows additional weird fantom-like animation before displaying the full picture of popup:

It's noticeable but not too much interfering.

QA Recommendation: Product should weigh in

jmatazzoni closed this task as Resolved.Jul 9 2018, 5:23 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 9 2018, 5:23 PM
Stryn added a comment.Jul 16 2018, 6:31 PM

Checked in betalabs

  • users that had New filters as beta feature before won't see the intro popup - according to the specs

Not true.
I had it locally enabled on Meta and also globally, but I got the popup.
And now I get it in every wiki, wonderful.......

Checked in betalabs

  • users that had New filters as beta feature before won't see the intro popup - according to the specs

Not true.
I had it locally enabled on Meta and also globally, but I got the popup.
And now I get it in every wiki, wonderful.......

@SBisson, @Catrope I thought we fixed it so that the system would know who had had the beta? Is everyone going to see this everywhere?

We did, it just took a little while to catch on. I believe it should be fixed now.