Talk:Edit Review Improvements/New filters for edit review

Jump to: navigation, search

About this board

Leave your thoughts and ideas here about the New Filters for Edit Review filtering tools and interface. These are now standard on Recent Changes and available as a beta feature on Watchlist. What works well? What could work better?

Leave feedback in any language.

How to provide feedback

  • do you have that bug when you are not logged-in?
  • explain how to reproduce the bug (step by step)
  • tell us what is your configuration (browser version)
  • say on what page it is happening -Recent Changes, Watchlist...)

Also see the FAQ.

Lerdthenerd (talkcontribs)

When using the filters the recent changes page doesn't update properly. It's moving too late.

Reply to "Too slow"

Suggestion: Filter language and /or translation related activity (e.g. from translate extension)

4
Summary by Trizek (WMF)
197.218.88.169 (talkcontribs)

Issue

Recently, a filter was added to filter some translation activity. However, this doesn't include subpages in the main namespace, e.g. Edit Review Improvements/New filters for edit review/fr.

Proposed solution

  1. Add a new flag to recent changes that hides these ( much like wikibase changes) by adding this to the related table (Manual:Recentchanges table#rc source), maybe something like "mw.ext-translate"
  2. Alternatively, flag these as language changes, maybe something like "mw.edit-lang-fr" in the same table, then users can at least hide all changes in languages they can't understand. This would remain the same for the content language. This could probably also be useful for wikidata, maybe with "wd.edit-lang-fr".
  3. Or both of the above. The ability to hide a specific language is useful by itself, and applicable to all wikis, and there are plenty of translate related activities that should be hidable.
197.218.88.169 (talkcontribs)

Hmm, having potentially thousands of filters (for each existing language, 5000+) might not be the best idea. Perhaps, it should be two options, e.g.:

  • Show me changes in the content language (primary language) of the wiki. Unregistered users would see this.
  • Show me changes in the language I speak. Registered users rely on their preferences.
Trizek (WMF) (talkcontribs)

Filter by languages has already been requested and explored: T164063.

It is possible to search for filters, like on Compact Language Links. That would leave a great latitude to the user to chose the best filters.

197.218.90.166 (talkcontribs)

My suggestion is mainly filtering all translation and language related activity.

Translate doesn't only create these pages, it also creates a lot of logs. Then there's also the content translation extension, and finally the ability to change the language of a page using mediawiki itself which isn't even covered by tags or anything else for that matter as far as I can see.

Chances are that this suggestion won't be implemented for a very long time, if ever. As a temporary measure, it might be useful to add a css class (e.g. ".mw-subpage") for subpages, e.g. page "buuu/baaa". Then such pages can be hidden using

.mw-subpage {
   display:none;
}

Frankly, those translation things have bothered me since the first time I used recent changes here. Currently, group changes is the only thing that makes them tolerable, and eventually perhaps I'll just use javascript to hide them all.

Reply to "Suggestion: Filter language and /or translation related activity (e.g. from translate extension)"
Evad37 (talkcontribs)

There are plenty of user scripts for the watchlist/recent changes, see w:en:Wikipedia:User_scripts/List#Listings. How can such scripts know when to run?

The usual strategy is to wait for document ready (by wrapping with $( function($) { });), then load dependencies (with mw.loader.using()), then run code that interacts with the page. With new filters active, this doesn't always work. E.g. with my WikidataWatchlistLabels script, it will sometimes work (show labels for wikidata Q and P numbers) on page load, and other times not work. And of course the results can be reset, e.g. if a filter is removed, and the script doesn't know that it should run again.

Trizek (WMF) (talkcontribs)

I've forwarded your question to the developers.

Roan Kattouw (WMF) (talkcontribs)

The recommended strategy for user scripts and gadgets modifying the content on the page is to use the wikipage.content hook:

mw.hook( 'wikipage.content' ).add( function ( $content ) {
    $content.find( 'li.mw-changeslist-src-mw-wikibase > span.comment > a.external' ).each( function () {
        // etc etc
    } );
} );

The wikipage.content hook is fired when the page first loads, and also by the new filters code every time the results are reloaded (and by some other pieces of code as well). The $content parameter tells you what was reloaded. On page load, it's the #mw-content-text div, and in the new filters UI it's the .mw-changeslist div and the .rcoptions fieldset (i.e. it's called twice for every refresh). Because the hook is sometimes called multiple times, and $content is sometimes something that doesn't contain the thing you're interested in, it's recommended that you use $content.find( '...' ) as much as possible, so that if $content is an unrelated part of the page, that'll find zero elements and do nothing.

Does that make sense? Unfortunately there isn't any good documentation about this on mediawiki.org :(

Evad37 (talkcontribs)

Thanks @Roan Kattouw (WMF), that works well!

Reply to "How can user scripts know when to run?"

Recent Changes on MediaWiki.org doesn't display more than 50 past edits

2
Summary by Trizek (WMF)
Ciencia Al Poder (talkcontribs)

I've created task T180577 for investigation

Trizek (WMF) (talkcontribs)

Thank you for catching this up. It is also broken on test wiki, which means it may be in the deployment train.

Nenntmichruhigip (talkcontribs)

First of all, I’m merely testing this as in „would it disturb my usual work“, I don’t see much use in it for myself. As such, everything in this post refers to the expanded watchlist.

So, let me just list the things I noticed as worse-than-before:

  • First of all, (even before the page finished loading for the first time :-) ) I noticed the main list is moved to the right by about a timestamp’s width, resulting in less space available.
  • Also the Legend comes in to it in the top-right corner, resulting in even less spave for the first three entryies. Even when collapsed (which would make the jumping-around worse) it would restrict the first entry.
  • So, page finished loading. Whoops, it just jumped down by two rows, I almost misclicked.
  • What’re those blue dots on the left? You know, those who seem to take half a timestamp’s width? Looks like selection, but doesn’t do anything on clicking. Couldn’t find any explanation (without looking for manual pages).
  • When expanding one of the first rows (to show all of today’s edits to a page), the Legend keeps taking up that width on the right for previously collapsed rows below it. Also, unexpanded rows which are now below it use that new space on the right, making them suddenly wider and more difficult to find again.
  • Ok, let’s try getting bot edits away. Took me a little to find how that’s done, but that’s just due to beeing used to it or not. Anyway, I click in that text box, the list opens and… moves up? Wait the whole page scrolled itself down? Why? To keep me from hitting „mark everything as watched“?
  • Now I selected to filter out Bot edits. Good. I see the list reloading already. A bit early imho, because I don’t want to waste all those reloads if I want to filter out more than just one type of edits.
  • Anyway, how do I get out of this filter list? The buttons in the top-right and bottom-right corners seem to do something else. Maybe by clicking somewhere outside of it? No, clicking on the background of the „active filters“ box or even the white space above it (the part that isn’t scrolled away) doesn’t cloe it. Maybe I missed a button? No. Is „highlight results“ maybe weirdly translated in my language? It does something else than closing the box, so apparently not. I figured it out by now: Clicking somewhere else, but not in the filter UI. Maybe an X button next to „highlight results“ would be good.
  • After I now filtered the bots out, the Legend is still in the same position and as large as before. But now everything of the list begins below it (plus some rather large padding), resulting in about six rows of white space between the filtering UI and the list.
  • Good, enogh testing for today, let me switch back now. Erm… that… looks like… is there something missing? Well, seriously now, I’ll open a second thread plus one on my local wiki’s help desk for this last issue, because it’s so severe an I really can’t solve it.
Trizek (WMF) (talkcontribs)

Thank you for your feedback, Nenntmichruhigip.

The page you describe looks very strange to me. Was your interface looking like this? If you have a different display, would you share a screenshot with me?

Can you explain what is a timestamp width? There is a lot of time and date indicators on a watchlist. :) Blue dits on the left are list elements. They are not supposed to take much room (see my link on the first paragraph). Maybe you have enabled "Group changes by page in recent changes and watchlist" in your preferences (in the RecentChanges tab).

The list of filter moved to give you the best overview of available filters. Concerning the reload for all filters, how long does it takes? Is your suggestion to select multiple filters and then apply the change?

To get out of the filter list, you list have to click on any blank space around the list, or hit Esc on your keyboard (like on quite all menues like this one). I'm afraid we can't implement a way to close the filter dropdown menu when you click again in the search bar: if a user searches for a filter in the menu, and then re-click on the search bar to type something in it, it may be confusing. I've reported the idea to examine it.

197.218.89.12 (talkcontribs)

> To get out of the filter list, you list have to click on any blank space around the list, or hit Esc on your keyboard (like on quite all menues like this one)

ESC generally cancels whatever selection and closes the menu. It isn't a good way to confirm the selection. That confirmation key would normally be ENTER, but because this menu uses a textarea and a drop down simultaneously it can't just close because someone might still want to select more things.

The solution for this case is pretty simple: Keyboard shortcuts (Control + ENTER), see Topic:Tynjkxyjz21aucvx . Maybe with an informative tooltip somewhere so the user knows it exists.

Those shortcut keys are pretty common in both wikis and other unrelated websites.

Nenntmichruhigip (talkcontribs)

Re „timestamp width“: The width of "00:00:00". Just a rough measurement anyway :-)

Re „blue dots“: Yes, this grouping thing is enabled. The distance from the left to the timestamp is approx. doubled with the beta feature enabled. I suspect there might be space reserved for some other indicators? Actually, could those dots just be dropped on the expanded watchlist? Imo it’s clear enough where a new line begins (at the timestamps).

Re „filter reload“: I don’t know how long it is, but as I’m on a slow computer everything feels slowed down due to it. Also depending on the internet connection, users may have to pay per Byte, so unneccessary reloads wouldn’t be desireable there. Yes, that’s my suggestion, maybe an „OK“ button in place of the „X“ suggested in the next bullet?

Re „exit filter list“: I didn’t mean clicking the text box again (though I expected that to work, because that’s how i.e. the URL bar or regular text entry boxes work here, though MediaWiki’s search box behaving as you described), but clicking the gray area above it, or even the white ~10px above that. Actually, I just noticed that the gray area also opens the list, which I understand when clicking nearby the active filters, but is unexpected when clicking far away from them on the far right.

(Sorry for the large text, I tried switching tabs while writing and don’t know how to undo that in this Flow discussion thing) (Fixed by Alsee)

Also, while trying around to solve the issue of the missing entries, I noticed I forgot one bullet: It takes longer to load. Like, I’m used to the watchlist taking very long to load, but with the beta feature, after it’s „loaded“, it takes a little more time to load the filtering interface. Granted, it’s not that much longer, but that would still be bad if this would be not just optional.

JMatazzoni (WMF) (talkcontribs)

Thanks for your feedback. We're making a lot of changes that should improve both the actual page load speed and perception of load speed (these latter have to do with some of the things you're talking about, like the results shifting around or not appearing to be clickable when they actually are or the list of abbreviations opening then closing). Some of these changes have already rolled out, so you should already see improvements. And more are coming.

Re. your comments about the layout, I'm pinging our designer, @Pginer-WMF, who will, I'm sure, have thoughts.

Nenntmichruhigip (talkcontribs)

I’ve finally had time to create three screenshots showing the spacing issues: File:New-Beofilter-Bugreport-1.png, File:New-Beofilter-Bugreport-2.png, File:NeNew-Beofilter-Bugreport-3.pngw-Beofilter-Bugreport-3.png

About my suggestion to drop the bullets: Actually, I just noticed it isn’t clear where a new line begins with the beta feature enabled. Currently, the timestamps are always on the first line of a watchlist entry. With the beta feature, they’re vertically centered, making it harder to spot where a watchlist entry begins/ends. But the bullets don’t help with that either, because they’re also vertically centered.

I also spotted another layout bug visible in the screenshots: the "jump to navigation/search" line (only visible when for example tabbing through the page, it’s fake-focused in the screenshots) doesn’t appear in the correct place.

Trizek (WMF) (talkcontribs)

Thank you for the screenshots, It helps a lot!

How do you get a time stamp formatted ad HH:MM:SS? The default is HH:MM. A gadget, probably? Why also is it displaying 00:00:00?

When they are compacted, the results keep space between the dots and the timestamp, to put the shortcut letters for bots edits, minor edits, new pages... Every letter has its own column. When you add to that the selector to collapse/uncollapse the results, it can take a lot of space. We should compact it a bit more, or consider to have a different design. I'll ask if it is possible to reduce the left margin on the results list.

Concerning the bullets, they are on the left on a line where edits are grouped, but they are clore to the results when you have the detailed view. There is probably a solution that would improve the reading, but without removing them. I will also ask for some input about it.

I'm not sure about what you identify as the "jump to navigation/search" line while I don't speak German. :) Are they the two links overlapping with the page title at the top? This is not a default feature. A gadget maybe?

(About the large text, you have created a title using the shortcut ctrl+1. Select the text afain and press ctrl+0 would have fixed it, or you could have switch to the wikitext input mode, using the pen on the right of a post reply form.)

Nenntmichruhigip (talkcontribs)

Sorry for the delayed response, I missed your reply since unread messages on Flow discussions aren’t highlighted on the watchlist (and because I’m rarely checking it on this wiki).

I'm suspecting the "Date format" setting at Special:Preferences#mw-prefsection-rendering for the time stamp format. The zeroes are just because of beeing test content :-)

The gap you’re describing isn’t surprising, as it’s no different from the current watchlist. But the gap left of it is: Currently, the collapse arrow is all the way on the right, directly under the "2" from "2017".

The "jump to" line is indeed the one with "Wechseln zu". It pretty certainly is a default feature. Try it: Click in the search box and hit the Tab key twice. Or look for id="jump-to-nav" in the page’s HTML code.

(Quite possible, as Ctrl+1 is used for tab switching at least in Firefox. Ctrl+0 conflicts with most browser’s zoom control btw… Thanks for the hint about the Wikitext mode, let’s see how well this goes :-) )

Reply to "How to not disturb"
The Polish (talkcontribs)

Is possible to hide flood edits on Special:RecentChanges? The Human (not bot) filter doesn't work and flood edits are visible.

197.218.91.243 (talkcontribs)

You'll have to define "flood". If you mean the flooder user group, then theoretically it would only work if "bot" (automated edits) is unchecked. If you mean detecting floods on the fly, then that is a complicated situation, but the primary fix would be to reduce the general editing rates of all accounts to reasonable limits (high rate editing means high rate mistakes, and server load) , see:

After sane limits are added, there are two ways the rest could be addressed with filters. Server side filtering, e.g. mark all revisions in which the editor exceeds a specific rate (possibly not technically feasible). Client side filtering, after all edits are fetched it is quite easy to show or hide visible results using javascript, e.g. calculate and hide revisions from editors with more than X visible edits.

This comment was hidden by 129.45.14.81 (history)
Trizek (WMF) (talkcontribs)

Massive edits made by users who don't have the bot flag will not be filters as bots, indeed. The community have to be firm about that: massive edits = bot flag.

197.218.91.242 (talkcontribs)
 The community have to be firm about that: massive edits = bot flag.

That's the source of the problem. Registered users === bots (in terms of editing rate). They can essentially edit freely without limits and may causes server problems, as the linked task shows. In other words, aside from bureaucracy (and some api specific actions) no registered user really needs bot rights.

There isn't a really good way to be firm because of that. That configuration change (https://phabricator.wikimedia.org/T56515) should be part of edit review improvements. Simply put high edit rates === increased number of errors === high burden for editors === unreadable recent changes === higher rates of spam. Just look at recent changes in wikidata (e.g. #quickstatements tag), massive number of people editing in a bot like manner, obliviously introducing many errors and treating a database system like an article.

No human can operate above a certain rate without making many more errors (see Diminishing_returns). Developers and the so-called communities are just fooling themselves if they think otherwise.

Reply to "Flood edits"

Suggestion: Introduce null highlight or way to hide irrelevant changes

6
Summary by Trizek (WMF)
197.218.90.179 (talkcontribs)

Issue

As a user I'd like to hide irrelevant changes without resetting ( fetching new) recent changes.

Background

Currently, recent changes has massive clutter. The only way to remove items from the list of changes is to remove / add a filter, which in turn fetches new changes. Highlighting somewhat reduces this problem, but it increases the cognitive load as the user must look for highlighted changes, and it provides no way to simply ignore the rest of the changes.

Proposed solution

  • A "null"/ transparent highlight filter that hides all changes that relate to the specific filter; or
  • A notion of primary filters that when applied simply hide "non-highlighted changes"

Notes

This can already be achieved by choosing a preferred color, and simply applying a display:none to it or those that don't have the specific html class. Of course this requires investigating the source code to identify the relevant colors, which are subject to change as that isn't an API.

197.218.90.179 (talkcontribs)

The easiest way to implement this is probably to add a new "color" (maybe something transparent) that simply hides stuff, rather than show.

Trizek (WMF) (talkcontribs)

Setup an highlighting in any way will reset the results.

197.218.88.3 (talkcontribs)

That used to be the case but isn't anymore. Adding highlighting after recent changes are loaded doesn't reset the results. Even just adding a new highlight without clicking the checkbox to add a new filter does the same thing.

This was a very good change that makes it possible to analyse the visible results, however, it still includes all other changes though. So this suggestion is simply building on that idea. Maybe a better way to think of it is "focus" rather than highlight, i.e. basically hide everything that is irrelevant.

197.218.81.218 (talkcontribs)

Thanks for linking the task, the easiest to currently do (or illustrate) this is:

.mw-changeslist-line:not(.mw-rcfilters-highlighted){
    display:none;
}

It will at least suffice until this is implemented or in case the suggestion is declined.

This comment was hidden by Trizek (WMF) (history)
Reply to "Suggestion: Introduce null highlight or way to hide irrelevant changes"

The icon to save a template should be visible even without changes in filters

4
Summary last edited by JMatazzoni (WMF) 18:45, 9 November 2017 8 days ago

The icon is now grayed out when unavailable.

ChristianKl (talkcontribs)

I was looking for the save button and it doesn't appear unless there are changes in the filter. That makes it harder for new users to discover that it exists. I would advocate to show the icon grayed out instead of letting it completly disappear. Alternatively, the function to save the filter could also be located at the bottom of the drop-down menu for "Saved Filters".

JMatazzoni (WMF) (talkcontribs)

Thanks @ChristianKl. You make an interesting point about discoverability. I've created a ticket for this and will discuss the idea with the team.

This comment was hidden by ChristianKl (history)
This comment was hidden by ChristianKl (history)

ORES filters not available anymore on frwiki ?

4
Summary by Trizek (WMF)
Shawn (talkcontribs)

It's been a few days now that we cannot use ORES filter anymore in recent changes page on french Wikipedia. Is this a known issue ?

Trizek (WMF) (talkcontribs)

Nothing I'm aware of... I have the same issue, only on fr.wp as far as I can tell.

Trizek (WMF) (talkcontribs)

Fixed. I have access to ORES filters. The change may require time to propagate itself.

Shawn (talkcontribs)

Thank you very much for quick assistance :) !

Hgzh (talkcontribs)

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.

JMatazzoni (WMF) (talkcontribs)

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!

Pginer-WMF (talkcontribs)

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.

Hgzh (talkcontribs)

@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.
Reply to "Bunch of feedback"