@Prtksxna Hello! I'm pinging you to see what you think of this behavior. In estimation, we discussed the fact that the current pop-up seems to hang around for a rather long time. It makes sense for it to stick around for a bit of time (so users can notice that temporary watch is available & make a selection), but perhaps 15 seconds is more reasonable? Meanwhile, when a page is unwatched or when a temporary selection is made, it would be great if the behavior follows the current dismissal time on production (which seems to be about 3 seconds). Curious to hear your thoughts!

@dom_walden Do you know if we can determine the current dismissal time of the pop-up after the user watches the page (on production), so we can follow the same dismissal time when users unwatch a page or make a temporary watch selection? Thanks!

@ifried, our original idea was to have it show up for 6 seconds, that is twice as long as the current time (see T249259 task description). Some of the community feedback you collected put this number between 5-10 seconds. I think the last time we discussed it we thought we'd start with 6 and increase to 10 if we think that is required.

Could you tell me a bit more about trying 30 seconds and 15 seconds?

@Prtksxna Apologies for my confusion; I think there was a miscommunication! Yes, let's go ahead with your 6 second recommendation.

BTW, here's what probably happened (i.e. source of miscommunication): I think we originally didn't know the recommended time when the ticket was first written. Then, perhaps I forgot to write down somewhere that we had chosen 5-10 seconds or forgotten to update the ticket (and apologies for that) when the decision was made (so it sorta slipped in my memory). For that reason, I think @HMonroy picked a time (30 seconds), just so it could be implemented. Meanwhile, when the ticket was being tested, I assumed the 30 seconds was based on some prior communication between you & Harumi (so I thought we may as well test it out & see how we felt). But, of course, when it was up and available to test, I thought, "This is too long. Let's change it. Maybe cut in half to 15 seconds?" So, there's the story!

So, in short: Thanks for clarifying, and I have added 6 seconds in the acceptance criteria :)

To the second point, do you think 3 seconds sounds good for when the user unwatches the page or when they make a temporary selection? Right now, we have 30 seconds for all behaviors, so we'll need to update the time for unwatching and selecting a temporary period as well. Thanks -- and sorry again for any confusion!

In T258662#6333239, @ifried wrote:

To the second point, do you think 3 seconds sounds good for when the user unwatches the page or when they make a temporary selection? Right now, we have 30 seconds for all behaviors, so we'll need to update the time for unwatching and selecting a temporary period as well. Thanks -- and sorry again for any confusion!

Yep, we should use 3 seconds when the user unwatches the page. But, for a temporary watch we should use 6 seconds because that popup has the dropdown and the user has the option of changing the time period again.

Thanks, @Prtksxna! Since a common agreement has been met, I will now move this ticket onto the team's Kanban board.

@HMonroy I just discussed this ticket with @Prtksxna, and we have added in one more point into the acceptance criteria. Let us know is it's okay or if you have any questions.

Quick point that got brought up (and thanks @Mooeypoo for thinking about this!). We want to make sure that 6 seconds is enough time for people who use common keyboard shortcuts rather than the mouse/trackpad. Is 6 seconds still sufficient? Pinging @Prtksxna & @dom_walden to see if they have any insights on the best way to test & verify this. Thanks!

@ifried @dom_walden @Prtksxna A mw.notify pop-up closes in 5 seconds by default when it is set to auto hide. There is an autoHideSeconds setting that only accepts an alias string: short (5 seconds) or long (30 seconds). I set the pop-up for watch/unwatch via the star to long; hence, you experience the 30 seconds period. Currently, the mw.notify does not support passing a dismissal time period in seconds. We can add more options (like medium = 6 seconds) but now 3 seconds feel too short, since the default is 5 seconds, and 6 seconds does not feel long enough. Please let me know your thoughts.

@HMonroy I think I understand the problem you are explaining: In other words, it doesn't make sense to create a new time period (6 seconds) and label it "medium" when it is only 1 second longer than the "short" time period (5 seconds). For this reason, is it recommended to go with the short time period (5 seconds), long time period (30 seconds), or create a new one (and, if we create a new one, what would "medium" be equal to)? Is that a correct explanation?

If so, I have one follow-up question: Does it make this ticket much bigger/add a lot more complexity to add a "medium" time period?

I have 2 ideas:

• Idea 1: We start with "short" (since the recommended time range mentioned by Prateek was 5-10 seconds), and then see what feedback we get. If people say it's too short, we implement a "medium" time period (with a duration based on the feedback we get).
• Idea 2: We go ahead and create a "medium" time period, which is a bit longer (say, 8 seconds), which we use for the pop-up upon initial watch. It would be a bit longer than we initially planned, but not by much -- and, if folks think it's too long, we can change it to "short."

I'm kinda leaning toward option #1, but I don't feel strongly either way. Curious to hear your thoughts, @Prtksxna :)

In T258662#6347248, @ifried wrote:

• Idea 1: We start with "short" (since the recommended time range mentioned by Prateek was 5-10 seconds), and then see what feedback we get. If people say it's too short, we implement a "medium" time period (with a duration based on the feedback we get).

Yep, I agree, this makes sense.

If we do implement a "medium" in the future I suggest we start with 10 rather than 8 seconds, so that the difference is more noticeable.

Yup, sounds good. I have also reached out to @Prtksxna & we have come to an agreement, which is the following:

1. We will first implement the "short" period for all 3 states (watch permanently, watch temporarily, and unwatch).
2. If we hear feedback from users that it's too fast, we will create a new "medium" watch period, which is 10 seconds, and we'll implement it for the permanent watch.

Okay, @HMonroy, you can go ahead & work on step 1. We may not need to do step 2, if people are generally happy with the time period after implementation. I'll update the acceptance criteria.

Change 617528 had a related patch set uploaded (by HMonroy; owner: HMonroy):
[mediawiki/core@master] Update time period for watchlist expiry pop-up

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

Change 617528 merged by jenkins-bot:
[mediawiki/core@master] Update time period for watchlist expiry pop-up

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

Change 617445 had a related patch set uploaded (by Samwilson; owner: HMonroy):
[mediawiki/core@REL1_35] Update time period for watchlist expiry pop-up

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

• Note for testing: Can we see if people have time to select a temporary time period with keyboard shortcuts within the "short" time period? This would be good for us to know.

@ifried The expiry dropdown appears in a different place than the watchstar in the tab order, so after clicking the watchstar (or pressing alt + shift + w), you have to tab 20+ times to get to the expiry dropdown.

There probably isn't quite enough time to select an expiry (testing in Firefox on beta and testwiki).

I am not sure how we expect people to use this with a keyboard. And I don't know if we can change the tab ordering to make it more convenient. (Perhaps @Prtksxna knows more about accessibility.)

• If the user hovers the pop-up (for watching or unwatching the page), it should not be dismissed until they are no longer hovering over the pop-up (and the "short time period" should be reset)

@HMonroy When I first load a page and click the watchstar, the popup disappears after 6 seconds even if you are hovering over it. Afterwards, without refreshing the page, if you unwatch and watch again the behaviour is as described above. This is on Firefox and Chromium on beta (MediaWiki 1.36.0-alpha (72ac5e1) 06:44, 31 July 2020). Do you see this as well?

Thanks for the information, @dom_walden! I'll add your findings into our team notes. Since there are 2 other ways to watch temporarily (via edit and action=watch), and the 20+ tabs would be rather lengthy to wait for, perhaps we can see if the current dismissal time via star is sufficient enough to cover most uses cases (other than watch via keyboard). If not, we can reassess once we hear user feedback. What do you think, @Prtksxna?

@HMonroy When I first load a page and click the watchstar, the popup disappears after 6 seconds even if you are hovering over it. Afterwards, without refreshing the page, if you unwatch and watch again the behaviour is as described above. This is on Firefox and Chromium on beta (MediaWiki 1.36.0-alpha (72ac5e1) 06:44, 31 July 2020). Do you see this as well?

@dom_walden yes, I can see the popup disappear after 6 seconds when we first load the page. Great catch! I was able to replicate this in en.wikipedia so it looks like it's an existing issue. I'm looking into it.

Change 617445 merged by jenkins-bot:
[mediawiki/core@REL1_35] Update time period for watchlist expiry pop-up

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

Change 620384 had a related patch set uploaded (by HMonroy; owner: HMonroy):
[mediawiki/core@master] Fix popup disappearing on its first load

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

Change 621096 had a related patch set uploaded (by HMonroy; owner: HMonroy):
[mediawiki/core@master] mediawiki.visibleTimeout: Fix the returned visibleTimeoutId in set()

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

Change 620384 abandoned by HMonroy:
[mediawiki/core@master] mediawiki.notification: Fix timeoutId check in pause()

Reason:
https://gerrit.wikimedia.org/r/c/mediawiki/core/ /621096 is the proper solution.

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

Change 621096 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.visibleTimeout: Update the nextVisibleTimeoutId value

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

Change 621489 had a related patch set uploaded (by Samwilson; owner: HMonroy):
[mediawiki/core@REL1_35] mediawiki.visibleTimeout: Update the nextVisibleTimeoutId value

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

Change 621489 merged by jenkins-bot:
[mediawiki/core@REL1_35] mediawiki.visibleTimeout: Update the nextVisibleTimeoutId value

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

All the acceptance criteria appear to be fulfilled, with the possible exception of 2:

• When the user makes a temporary selection, the pop-up should display for the "short" time period before being automatically dismissed

On Firefox we have found that the the popup disappears immediately after the selection is made. This is not the case on Chrome, IE11 or Safari. I will raise a separate bug (if there is not already one).

• If the user hovers the pop-up (for watching or unwatching the page), it should not be dismissed...

This is true even when hovering over the expiry dropdown. This was not the case before.

The popup remains when you hover with the mouse, but I could not get it to remain when I had it focused with the keyboard (e.g. if I was using the keyboard to select an expiry value). This might make it awkward to use with a keyboard.

However, fixing this might be hard as I imagine interacting with the popup with the mouse (e.g. selecting an expiry value) will also give it focus, but in these circumstances we don't necessarily want the popup to remain.

I did some brief regression testing on test2wiki (which does not have watchlist expiry) on Firefox and Safari, to check that we haven't made any changes to the normal popup.

Test environments:

• (mainly) https://en.wikipedia.beta.wmflabs.org MediaWiki 1.36.0-alpha (211a61b) 07:50, 26 August 2020
• vagrant MediaWiki 1.36.0-alpha (211a61b)
• (for regression testing) https://test2.wikipedia.org MediaWiki 1.36.0-wmf.5 (rMWddfbb3cc6a23) 11:23, 24 August 2020

Browsers:

• Firefox 68 (mainly)
• Chromium 83
• IE11
• Safari 13

FYI, I only tested this on Vector skin. Because we are using standard OOUI components, I hope it will just work on other skins.