Change 363859 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Basic implementation of live updates

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

Change 364266 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Enable experimental RCFilters live update feature in beta

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

Change 364266 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable experimental RCFilters live update feature in beta

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

Change 365408 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] RCFilters: Allow experimental live update feature to be enabled with query string parameter

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

Change 365408 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Allow experimental live update feature to be enabled with query string parameter

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

Change 365413 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@wmf/1.30.0-wmf.9] RCFilters: Allow experimental live update feature to be enabled with query string parameter

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

In T167743#3415106, @Trizek-WMF wrote:

@jmatazzoni, how do you plan to do this dark-launch?

Sorry for the late answer: the live update feature will be inaccessible except if the user manually edits the URL to add liveupdate=1. This way we can test it (including in @dchen's user tests) in an environment with real traffic without exposing it to all beta users before it's ready. It's more of a grey launch than a dark launch at this point, not sure what to call it :)

Change 365413 merged by jenkins-bot:
[mediawiki/core@wmf/1.30.0-wmf.9] RCFilters: Allow experimental live update feature to be enabled with query string parameter

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

I've tried the feature and asked the community liaisons to do the same. Feedback:

• It is not possible to know when the next batch of recent changes will arrive. It is confusing, because while you are looking at some results, everything moves and you loose the line where you were.
• It is not possible to identify the new items that have appeared
• The blinking blue button is a point of concern: "I would not be surprised if the blinkiness is the major complaint." Advanced users son't like that much fancy things like this. Suggested: "make the pulse slower", "have it blinking three times and it is over".
• How will it work on a wiki with a lot of updates? How will it work on a wiki with a very few updates?

In T167743#3465837, @Trizek-WMF wrote:

I've tried the feature and asked the community liaisons to do the same. Feedback:

Thanks for the feedback! Some notes below:

• It is not possible to know when the next batch of recent changes will arrive. It is confusing, because while you are looking at some results, everything moves and you loose the line where you were.

This is intended to support a "background monitoring" usecase. From what we got from users the expectation seems to be to view edits as they happen so they assume things will move as the wiki is being edited. If updates go too fast, they have two options: (a) filter more to target more specific edits or (b) stop the live updates for a while to inspect the static list. I think it is important not to show live updates enabled by default, users explicitly enabling this help for them to have those expectations and know how to revert their decision.

• It is not possible to identify the new items that have appeared

Paying attention to how well people can keep track of the updates is definitely something we want to observe.

In this case we try to provide a soft transition. We didn't wanted to highlight changes more prominently since we expect the Recent Changes highlight feature to be useful in this scenario. For example, a user can keep the live updates with a red highlight for vandalism and pay attention only when a red item appears in the list.

• The blinking blue button is a point of concern: "I would not be surprised if the blinkiness is the major complaint." Advanced users son't like that much fancy things like this. Suggested: "make the pulse slower", "have it blinking three times and it is over".

The purpose of the pulse is to signal that we are looking for updates even if those are not happening. This is especially useful for low-volume cases where the lack of movement in the list does not help to communicate that live updates are active. Anecdotally, in a recent user research session a user had a particular combination of skin and browser that made the icon and pulse not to appear, and this generated a significant confusion when results took some time to appear.

In any case, it is totally possible we need to make adjustments on the intensity and timing of the pulse to make sure it provides the right balance to be noticeable when needed but not distracting.

• How will it work on a wiki with a lot of updates? How will it work on a wiki with a very few updates?

Regarding the pace of updates, you can scroll down on Listen to Wikipedia to view a real-time list of recent changes. There are options to pick different wikis, so you can check the cases of high and low volume wikis.

Thank your for your reply, I'll share it.

Concerning the blinking, I've been thinking about it while on vacations and maybe have the three-waiting-dots with a sentence saying "waiting for new updates" would be a possible option, more clear than the button.

After a discussion with @SBisson, I added the following to the list of requirements in this feature in the Description at top:

• Live update works differently in "Group changes by page" mode than normal mode. In normal mode, results are simply added to the top of the results page; this is the intended way to use this. In "Group changes by page" mode, the entire page will update each time, so that the new results can be integrated where relevant with the other changes from their same page. [This may prove fairly unsatisfactory, so we should have a look when it's ready and see if we need to make any adjustments to this plan.]

Stephane or @Catrope , if that's not what we you think we said, let me know.

In T167743#3488270, @jmatazzoni wrote:

In normal mode, results are simply added to the top of the results page;

This reminded me of some special cases I wanted to comment. Most filters target properties that never change (e.g., an edit by an IP will always be created by an IP, forever). However, other properties may change over time: patrolled/unpatrolled and latest/not-latest revision are aspects that may evolve during the life of an edit.

In the case of live updates, what should we do if we are filtering for unpatrolled and some edits in the middle of the list become patrolled? Should they disappear?

On the one hand, making them disappear would avoid the issue of users stepping in their toes by reviewing outdated edits, and makes the list truly real-time. On the other hand, removing them may make the list less stable/predictable.

I guess we'll learn more about the user expectations as we observe users making use of the feature on a more realistic environment.

In T167743#3488270, @jmatazzoni wrote:

After a discussion with @SBisson, I added the following to the list of requirements in this feature in the Description at top:

• Live update works differently in "Group changes by page" mode than normal mode. In normal mode, results are simply added to the top of the results page; this is the intended way to use this. In "Group changes by page" mode, the entire page will update each time, so that the new results can be integrated where relevant with the other changes from their same page. [This may prove fairly unsatisfactory, so we should have a look when it's ready and see if we need to make any adjustments to this plan.]

That's also my understanding and that's what has been implemented.

Note that during the implementation I ended up adding a machine readable timestamp to every change. If we ever want to try it, it's technically possible to add a visual cue, even in enhanced mode, that a change is new since last reload.

In T167743#3488559, @Pginer-WMF wrote:

In T167743#3488270, @jmatazzoni wrote:

In normal mode, results are simply added to the top of the results page;

This reminded me of some special cases I wanted to comment. Most filters target properties that never change (e.g., an edit by an IP will always be created by an IP, forever). However, other properties may change over time: patrolled/unpatrolled and latest/not-latest revision are aspects that may evolve during the life of an edit.

In the case of live updates, what should we do if we are filtering for unpatrolled and some edits in the middle of the list become patrolled? Should they disappear?

On the one hand, making them disappear would avoid the issue of users stepping in their toes by reviewing outdated edits, and makes the list truly real-time. On the other hand, removing them may make the list less stable/predictable.

I guess we'll learn more about the user expectations as we observe users making use of the feature on a more realistic environment.

It is currently implemented in such a way that old changes that do not match the filters anymore disappear.

Like you said, it makes the list "more live" for things like patrol and oversight (and potentially revert in the future). If you care about things jumping around, Live Update may not be for you ;)

The implemented specs are marked with the green checkmark.

The following has not been implemented yet:

Tooltips for the Live Update button are as follows.
When the button is in inactive mode: Display new changes as they happen.
When the button is in active mode: Turn off live updates.

If a user with it LU OFF scrolls down the page, or uses the "Older 100 >" button to page back in the queue, and then turns LU ON, the following happens: the page reloads with the user at the top of the queue and the currently selected X results showing, and the Live Updates begin rolling onto the page.

In "Oldest first" mode, Live Updates is unavailable and the button is grayed out.

There are screenshots and additional commonets on T163426: Add 'View Newest Changes' option into the Integrated Filters

In T167743#3491521, @Etonkovidova wrote:

The implemented specs are marked with the green checkmark.

The following has not been implemented yet:

Tooltips for the Live Update button are as follows.
When the button is in inactive mode: Display new changes as they happen.
When the button is in active mode: Turn off live updates.

If a user with it LU OFF scrolls down the page, or uses the "Older 100 >" button to page back in the queue, and then turns LU ON, the following happens: the page reloads with the user at the top of the queue and the currently selected X results showing, and the Live Updates begin rolling onto the page.

In "Oldest first" mode, Live Updates is unavailable and the button is grayed out.

I moved the requirement about "Older 100 >" to the ticket about the paging UI, and will move the "Oldest First" bit to a ticket I need to write about Oldest First. Both of these requirements have been crossed out in the Description, above.

@SBisson please add the tooltips, unless there is some problem with doing so. Moving this back to In Dev for that.

Checking Live Updates on English Wikipedia I noticed that a bunch of updates happen at the same time followed of a waiting period. This makes it feel less like a continuous stream of changes.

So I was wondering if we can make the changes to update more continuously. Maybe checking the server at the current pace but showing the updates to the user in smaller chunks until it is time for another update could help improve the perceived fluency.

I made a video comparing both our current approach to Live updates and the Listen to Wikipedia one, where the later seems much more fluent.

In T167743#3492569, @Pginer-WMF wrote:

Checking Live Updates on English Wikipedia I noticed that a bunch of updates happen at the same time followed of a waiting period. This makes it feel less like a continuous stream of changes.

It easier to watch changes that way, than having a continuous flow IMO (also see [[T172213#3492438]]).

In T167743#3492569, @Pginer-WMF wrote:

Checking Live Updates on English Wikipedia I noticed that a bunch of updates happen at the same time followed of a waiting period. This makes it feel less like a continuous stream of changes.

That's exactly how it's implemented. We check for new changes, show them, wait 3 seconds and check again... We cannot listen to a stream at the moment because of the rendering constraints with the RC lines.

So I was wondering if we can make the changes to update more continuously. Maybe checking the server at the current pace but showing the updates to the user in smaller chunks until it is time for another update could help improve the perceived fluency.

I guess we could phase in the changes over 3 seconds to give the impression they are streaming in but it would jump N times more often (1 jump per change instead of 1 jump per batch of N).

I made a video comparing both our current approach to Live updates and the Listen to Wikipedia one, where the later seems much more fluent.

I personally don't see how live update can be usable other than for a screensaver. I assume reviewers zero in on a change, go do something about it somewhere else (read, revert, discuss, block, etc) and come back where they left off looking for the next thing. I can see that working very well with "show new changes" where you page forward the stream of changes but with live updatem what you miss while blinking seems completely arbitrary.

In T167743#3493370, @SBisson wrote:

I personally don't see how live update can be usable other than for a screensaver. I assume reviewers zero in on a change, go do something about it somewhere else (read, revert, discuss, block, etc) and come back where they left off looking for the next thing. I can see that working very well with "show new changes" where you page forward the stream of changes but with live updatem what you miss while blinking seems completely arbitrary.

I was of the same opinion, and expected a proper "view the newest changes" mechanism (T163426) to cover all these needs. However, several users described a "background monitoring" scenario where they keep the a live updating list on a separate browser window to keep glancing at it. Currently they were using tools such as RTRC and user gadgets that provided auto-refresh capabilities to Recent Changes. In our case, I think that highlights can make the feature even more useful to make it easy to notice a particular kind of change.

Let's move this on down the road. Are we waiting for anything besides the tooltips? @SBisson what do we need to do to get the current beta into the "dark launch" on production, so we can see the new state of the art on this in action?

In T167743#3493829, @jmatazzoni wrote:

Let's move this on down the road. Are we waiting for anything besides the tooltips? @SBisson what do we need to do to get the current beta into the "dark launch" on production, so we can see the new state of the art on this in action?

Yeah, let's do this to collect more opinions. :)

In T167743#3493829, @jmatazzoni wrote:

Let's move this on down the road. Are we waiting for anything besides the tooltips? @SBisson what do we need to do to get the current beta into the "dark launch" on production, so we can see the new state of the art on this in action?

The big patch for "show new changes" that included some changes on "live update" was merged on Monday this week (July 31st) and should have been rolling the deployment train since. If by "prod" you mean enwiki, then it's going out (in dark more) tomorrow. Unless there is something wrong with deployment this week @Catrope?

Change 369712 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCFilters: set live update button title

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

In T167743#3493921, @SBisson wrote:

The big patch for "show new changes" that included some changes on "live update" was merged on Monday this week (July 31st) and should have been rolling the deployment train since. If by "prod" you mean enwiki, then it's going out (in dark more) tomorrow. Unless there is something wrong with deployment this week @Catrope?

Nothing weird going on AFAIK, the train appears to be on schedule. After tomorrow afternoon's train deploy, the feature (sans tooltips) should be dark-deployed on English Wikipedia and accessible with ?liveupdate=1 as it was before.

Change 369712 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: set live update button title

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

In T167743#3494644, @Catrope wrote:

In T167743#3493921, @SBisson wrote:

The big patch for "show new changes" that included some changes on "live update" was merged on Monday this week (July 31st) and should have been rolling the deployment train since. If by "prod" you mean enwiki, then it's going out (in dark more) tomorrow. Unless there is something wrong with deployment this week @Catrope?

Nothing weird going on AFAIK, the train appears to be on schedule. After tomorrow afternoon's train deploy, the feature (sans tooltips) should be dark-deployed on English Wikipedia and accessible with ?liveupdate=1 as it was before.

Belay that, the train is blocked by T172320. If that's fixed quickly, it might still go ahead on schedule. You can monitor the state of deployments at https://tools.wmflabs.org/versions/ (the version with the new live update is wmf.12, and enwiki is in group 2).

@SBisson, I added clarifications in the Description (and in T163426) re. the interaction of Live Update and View Newest Changes. I apologize for not thinking of this when I wrote the original spec. I've actually been going back and adding more detail on both Newest changes and LU in a lot of tickets, like T172240 and T163429. I see on beta that we're currently moving the Previously Viewed Changes marker every time an Update happens. Please drop that, as per the new requirements above. I'm moving this back to In Dev to make that change.

(Once we see what this looks like on en.wiki, it's entirely possible we'll decide that a marker of some sort between updates is desirable. My own sense is that if we do that, that marker—which will be constantly on the move—will need to be visually simpler than Previously Viewed Changes.)

Change 369905 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCFilters: Remove new changes visual cue for Live Update feature

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

Change 369905 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Remove new changes visual cue for Live Update feature

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

In T167743#3492569, @Pginer-WMF wrote:

Checking Live Updates on English Wikipedia I noticed that a bunch of updates happen at the same time followed of a waiting period. This makes it feel less like a continuous stream of changes.

So I was wondering if we can make the changes to update more continuously. Maybe checking the server at the current pace but showing the updates to the user in smaller chunks until it is time for another update could help improve the perceived fluency.

@Pginer-WMF and @SBisson, as of this morning we can finally see Live Update with the fade-in (for the entire group of new changes) on en.wiki (with &liveupdate=1 appended). The "Previously viewed changes" marker, which was not in the spec. is part of the feature at present. I've been playing with it and I think it's a VERY GOOD experience—easily good enough to put out to the public in the beta. Therefore, I think we should:

• KEEP the "Previously viewed changes" marker (or, rather, put it back, since Stephane removed it at my request, though that change isn't live yet on beta).
  • Possibly make adjustments to the marker, as discussed in T172213 (but don't hold the feature for that).
• Don't change the fade-in to a new system Pau discusses above, where we'd fade in the results a few at a time.
• Remove the dark launch code and let this go live to beta.

Re. the marker: I thought it would be too distracting and jumpy, but it isn't at all. It's actually quite helpful. It orients you when you're watching it live, providing an anchor. And on slower moving wikis or when you've got filters on, it lets you look away and then look back and know where you are. I like it!

Re. the fact that the changes come out all in a burst: I think the original group fade-in that Pau specified—and which we can now finally evaluate on production—makes the experience much, much better than before, when they all just appeared with no transition. Whether fading in the results one or two at a time would be better, I don't know; it might well make this worse. What I do know is that what I see now is actually quite pleasant and, dare I say, pretty cool! It's definitely good enough to stop tinkering with and get some response—and we are in the part of the quarter where that's what we need to do. If we get this out there sooner rather than later, this greatly desired feature might just make it into beta graduation.

(Also, as I say, I think the gradual-fade experience might possibly be worse. Right now, surprisingly, you can actually evaluate the entire group more or less at once—or at least I think that experienced reviewers will be able to, given that they are usually looking for particular clues. Graduating in the results might just make this harder for them, since in effect it would mean we'd be "holding back" or slowing down some of the results that would have been available for review, giving reviewers less time to scan the new group.)

So, bottom line for immediate action: @SBisson, please put the marker back in and let's move forward with this. I'm ready to approve what we've got and close this ticket as soon as you confirm that's done.

In T167743#3502058, @jmatazzoni wrote:

[...]
So, bottom line for immediate action: @SBisson, please put the marker back in and let's move forward with this. I'm ready to approve what we've got and close this ticket as soon as you confirm that's done.

This is the patch to bring back the marker in Live Update mode: https://gerrit.wikimedia.org/r/#/c/370244/ Someone needs to review/merge it.

I agree the feature is good enough to let beta users play with it. We can put up a config patch to enable it next week and clean up the feature toggle code a week or so later if it doesn't blow up.

The only thing I'm not thrilled about is the marker that can be clicked to hide it. I would prefer to launch with the marker being inert (non clickable) and add behaviour as needed. I have been hammering this nail for a while already so I won't bring it up again if I'm the only one thinking this is superfluous.

Other thoughts

This feature is increasing the number of requests to Special:RC by A LOT so there's probably someone we should give a heads up to (@Catrope?) Also, we should probably distinguish navigating to Special:RC vs. filter change vs. polling for new changes for page view stats purposes.

• The line separator has been removed
• the interaction with "View newest changes" link is according to the specs

According to

If a) the Previously Viewed Changes separator and/or the View Newest Changes link are displayed, and b) the user clicks Live Update, then: the Previously Viewed Changes separator and/or the View Newest Changes link should disappear entirely when the page makes its first update.

there will be the state when a user will see simultaneously the active button 'Live updates' and "Previously viewed changes" separator. As soon as a new change appears, "Previously viewed changes" line will disappear according to the specs.

QA Recommendation: Resolve

! In T167743#3502140, @SBisson wrote:

The only thing I'm not thrilled about is the marker that can be clicked to hide it. I would prefer to launch with the marker being inert (non clickable) and add behaviour as needed. I have been hammering this nail for a while already so I won't bring it up again if I'm the only one thinking this is superfluous.

Actually, from a conversation with Pau I'm pretty sure we all agree that some alteration in the marker would be a good idea. We'll work on simplifying this in T172213.

In T167743#3502259, @Etonkovidova wrote:

• The line separator has been removed...

QA Recommendation: Resolve

I've asked Stephane to reinstate the separator, which he says (above) he's done. Should we leave this ticket open to make sure that reinstatement goes through?Or do you want to close this and make a separate ticket to track the reinstatement? @SBisson, when will that reinstatement show up on beta, so Elena can test it?

In T167743#3502401, @jmatazzoni wrote:

[...]
I've asked Stephane to reinstate the separator, which he says (above) he's done. Should we leave this ticket open to make sure that reinstatement goes through?Or do you want to close this and make a separate ticket to track the reinstatement? @SBisson, when will that reinstatement show up on beta, so Elena can test it?

The patch to reinstate the separator was merged on Friday. It is visible in beta. Production still has it since the patch to remove it never made it there.

@jmatazzoni The following state seems rather confusing to me, especially in :

1. Click on 'Live Updates' to make it inactive - the separator (and the new updates) appear
2. Click on 'Live updates' again to make inactive - the separator is still displayed along with 'View newest changes'
   

In T167743#3514478, @Etonkovidova wrote:

@jmatazzoni The following state seems rather confusing to me, especially in :

1. Click on 'Live Updates' to make it inactive - the separator (and the new updates) appear
2. Click on 'Live updates' again to make inactive - the separator is still displayed along with 'View newest changes'

You make a good point. A subtle one—but hey, that's our business. When the View Newest Changes link appears (meaning there are new changes available), it would be better if the Previously Viewed Changes marker disappeared at the same time. I think. @Pginer-WMF, does that sound right?

Elena, would you mind writing a ticket for this? Go ahead and put it in RFP, but don't add it to the list of blockers.

In T167743#3514549, @jmatazzoni wrote:

You make a good point. A subtle one—but hey, that's our business. When the View Newest Changes link appears (meaning there are new changes available), it would be better if the Previously Viewed Changes marker disappeared at the same time. I think. @Pginer-WMF, does that sound right?

Makes sense. In T172213 it is proposed to show a blue line initially that turns grey after a second, but we can consider removing completely when switching live updates off if the mark is not that relevant.