Topic on Talk:Edit Review Improvements/New filters for edit review

First, I'm glad how this beta feature evolved. When I saw the first version, I was really concerned if the Recent Changes list would be usable for patrolling in the future (due to long load times etc.) But now, I think I have a benefit in using this. Here are some points I noticed in the past weeks:

• I like the 'view newest changes' button and the blue/gray line above the last seen change. But sometimes the line was not where it had to be (skipped some edits). But I couldn't reproduce, it seemed to be just coincidentally.
• When I click in the 'filter recent changes' field, the page automatically scrolls down. I don't like this behaviour. The user should be in control of the page scrolling.
• The 'other review tools' and 'saved filters' buttons are not in the same horizontal line, so there is an unsightly space beliow the 'other review tools' button.
• The 'save current filter settings' icon seems to be a little bigger than the 'clear all filters' icon, this looks weird. Same with the 'filter results by namespace' and 'filter results using edit tags' icons.
• In my opinion, there is too little left padding in the 'Advanced filters' box
• The position of the legend is unfavorable as it breaks the first lines of the recent changes list. I had to hide it using the css page.
• The 'live updates' are a nice gimmick, but not really usable for patrolling. It may be that the list reloads while I'm just clicking somewhere and I'll miss my target. This could result in false rollbacks etc. It would be better if the list could 'freeze' when the mouse enters a specific area and updates not until the mouse leaves again.

So far my thoughts.

PS: I just realized that FlaggedRevisions have been integrated now. Great, thank you.

Hi @Hgzh. Thanks for taking the time to provide this really useful feedback—and for giving the beta a chance. I'm glad you see the progress we've been working hard to make.

Page scrolling: Other users commented on this so we made some adjustments recently. Perhaps it's improved? The idea, I think, is to enable reviewers to see more of the filter menu and the results area (important especially for users who keep the "other review tools" box open). Can you say what about the motion displeases you? Is it that you just don't want to have any motion?

Other review tools alignment, icon sizes, padding: You must be a designer! I see what you mean. I'm pinging our designer, @Pginer-WMF, to see what his perspective is on these and some of the other issues.

Legend position:  We're going to fix this. The issue is tracked in ticket T178326.

Live updates: This feature has been a big hit with many users, though I confess I feel a bit as you do. It's possible that Live Updates is more useful on smaller wikis or for patrollers who use more restrictive filters. I.e., when the volume of changes is low. I'm not sure I'm convinced by the solution you suggest, but maybe I don't understand the idea fully. Care to expand?

Thanks again!

Thanks for your feedback, @Hgzh.

With the scrolling to the filter panel, we provide it as a direct response to the the user intent to focus on the filters. I agree with the general principle of not taking control from the user, but in this case the viewport transition seems aligned with the user goals, helps focusing on the task at hand and reduces the need to move through two different scrollable layers which is often painful. As Joe said, we have been polishing the behaviour to avoid some cases where scrolling felt unexpected and we are interested in hearing about more.

The size inconsistency on the bookmark icon was reported in this ticket, and I expect that the upcoming process of icon updates will help with this problem at some point.

Regarding the alignment between 'other review tools' and 'saved filters', you are totally right. I created a ticket to correct such deviation from the intended design. Thanks for catching it!

Regarding "Live updates" the main intention is to support a "background monitoring" scenario we have been learning about as we talked with different reviewers. For wikis with a high volume of changes, I'd expect users to either use highlight to notice when a set of relevant edits appear or filter the results heavily for the edits to appear at a reasonable pace to act on, but definitely not acting on a moving "waterfall" of changes. Hearing from users that used Real-time Recent Changes (RTRC) and their own user scripts to refresh the page, we decided to provide some initial support for live updates, observing how this is used in practice will help us to understand better any possible further step.

@Pginer-WMF@JMatazzoni (WMF) Thanks for your answers!

• auto-scrolling: I see your point for this kind of scrolling, maybe it is just a personal preference for me. I don't like that the top navigation bar (user, talk page etc.) disappers as a result of this. Another point to this: If I click 'filter recent changes', the page gets scrolled, I scroll manually back to the top and then switch the tab. If I'm switching back to the tab with the RecentChanges page, the page gets scrolled again. Maybe you could implement that the page is only scrolled once after the user clicked in the field.
• Live updates: Ok, I did not think about smaller wikis. I personally use the 'view newest changes' button, so it is not a big problem to me. I thought about to do just live updates if the mouse is not hovering a link (or a line of the changes page) to avoid false clicks.

Recent Change list should load more items after it filters out items