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.

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

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.

In T195427#4243446, @Trizek-WMF wrote:

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.

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.

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.

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

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"?

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

In T195427#4249494, @jmatazzoni wrote:

@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

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.

In T195427#4257654, @Stryn wrote:

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:

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.

In T195427#4304448, @Trizek-WMF wrote:

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.

In T195427#4304583, @Pginer-WMF wrote:

In T195427#4304448, @Trizek-WMF wrote:

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

In T195427#4305634, @Etonkovidova wrote:

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.

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

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

In T195427#4400618, @Etonkovidova wrote:

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

In T195427#4428609, @Stryn wrote:

In T195427#4400618, @Etonkovidova wrote:

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.