Talk:Edit Review Improvements/New filters for edit review

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.

Edit Review Improvements (ERI)
Edit Review ImprovementsEdit Review Improvements GlossaryHelp:Edit Review Improvements/Glossary Features New filters for edit reviewEdit Review Improvements/New filters for edit review Quick tourHelp:New filters for edit review/Quick tour DocumentationHelp:New filters for edit review FilteringHelp:New filters for edit review/Filtering Advanced filtersHelp:New filters for edit review/Advanced filters HighlightingHelp:New filters for edit review/Highlighting function Quality and Intent FiltersHelp:New filters for edit review/Quality and Intent Filters Save your filters setsHelp:New filters for edit review/Bookmarking Live updatesHelp:New filters for edit review/Live updates FAQHelp:New filters for edit review/FAQ FeedbackTalk:Edit Review Improvements/New filters for edit review ResearchEdit Review Improvements/New filters for edit review/Research Huggle improvements (proposal)Edit Review Improvements/Proposed Huggle improvements Technical How to implement a filterEdit Review Improvements/New filters for edit review/How to implement a filter Objective Revision Evaluation Service (ORES) ReviewStreamEdit Review Improvements/ReviewStream Translate this template

Collaboration team is announcing plans to graduate the New Filters for Edit Review out of beta on Watchlist by late June or early July. After launch, this suite of improved edit-search tools will be standard on all wikis. Individuals who prefer the existing Watchlist interface will be able to opt out by means of a new preference.

The New Filters introduce an easier yet more powerful filtering interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting, the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning. If you’re not familiar with the New Filters, please give them a try on Watchlist by activating the New Filters beta feature. In particular, it would be very helpful if you can test the new functionality with your local gadgets and configurations. The documentation pages provide guidance on how to use the many new tools you’ll discover.

Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us now with a post on this talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed.

This is neither here nor there, but on an old machine (2009 macbook, 8gigs ram, SSD) the filters take a very long time to load on a large watchlist. I really enjoy them but use the old design rather than wait for the page to load. I'll be opting out, but look forward to using them with a new machine!

Hi @Amorymeltzer. Thanks for the kind words about the filters, but I'm sorry to hear load time is such a problem for you. Frankly, a 2009 Macbook isn't all that old. We'd like to look into this a bit more. Can you tell me a) how many pages are on your Watchlist, b) how many items you choose to show at a time, c) what browser you use?

If you have time, it would be especially helpful if you could turn on the New Filters beta and put in the settings you use, then copy and paste the URL (which contains all the settings) for us, so we can see what you're trying to do. i

I'm copying @Catrope and @Etonkovidova, since they will be interested in this thread.

@JMatazzoni (WMF): Sure. For starters, I use Modern with a dumb amount of userjs, including a number of scripts that dramatically slow down the watchlist (e.g., user highlighting, shading out already-seen pages, cross-out blocked users). In the interest of this, I've tested it using vector, for which I have no customizations or js loaded.

I'm on OSX 10.11.6, running Firefox 60.0.02. My watchlist just hit exactly 5,500 pages (although I had the same issue when I had it pruned to around 3, 3.5k), and I show 1,000 changes (that's ostensibly over the last 7 days, but assuming there's minimal drama at enWiki (lol), it usually spans about 24 hours).

Without the filters, it took about 13 seconds to load, whereas with the filters it took 27 seconds. Nearly all the extra time was with the loading dots for the filters. That url is: https://en.wikipedia.org/wiki/Special:Watchlist?hidebots=1&hidecategorization=1&hideWikibase=1&limit=1000&days=7&enhanced=1&urlversion=2 (no bots, page edits, page creations, logged actions). From there, adding a paramter (https://en.wikipedia.org/wiki/Special:Watchlist?damaging=verylikelybad&hidebots=1&hidecategorization=1&hideWikibase=1&limit=1000&days=7&enhanced=1&urlversion=2 aka very likely have problems) takes about 12 seconds to show. The interface itself is fairly laggy, often requiring a second or two after clicking an option before something registers.

FWIW, with modern and my userjs, it was 17 with the old system and 30 with the filters. Happy to provide more info if you like; I know I'm an edge case, so I appreciate the thought regardless.

Hi @Amorymeltzer. Thanks for all the detail. The engineers request that you try adding the following to your URL and see if it changes the times: ?safemode=1

That will turn off gadgets and user scripts, which will be a big help in diagnosing where the delay might be coming in. Let us know what you find!

@JMatazzoni (WMF) Sure, safemode is no issue. Below is average of two trials for each skin.

• Vector: 18s with beta filters, 8s on the old system
• Modern: 20s with beta filters, 9s on the old system

As before, majority of extra time is waiting for the panel to load, so technically the watchlist itself is visible.

@Amorymeltzer As you might have figured out, 12 seconds is the amount of time it takes to query the database and figure out what the recent edits to pages on your watchlist are and which of them match the filters you chose. This is a known problem with large watchlists, unfortunately, and affects both the old and the new UI. You also get hit by that 12-second delay every time you change your filters, because it has to rerun that query. There may be some optimization we can do for large watchlist, I'll look into that later if I have time.

As for the additional delay caused by the new filters UI, that should only depend on the number of results. I tried with 1000 results on RC (my watchlist isn't that big) in Firefox, and it only spent 0.6 seconds in the loading dots stage. I suspect gadgets and/or user scripts may be interfering here, which is why Joe suggested using safe mode, which disables those. If it's still slow with safe mode, we can do a more detailed performance analysis of your particular case; if you're interested in that, get in touch with me on IRC (RoanKattouw) or email/gchat (roan at wikimedia dot org) and I'll walk you through it.

Whoops, our messages crossed. It looks like it's still quite slow for you in safe mode, which I'm very surprised by. If you're willing to spend some time investigating this issue with me 1-on-1, I would be quite interested in that; it's hard to impossible for us to fix issues that we can't reproduce or observe ourselves.

Yeah, I figured as much — I just tried dropping down to 100 from 1000, and the whole page with new filters loaded in about 9 seconds with safemode=true. At any rate, I know I'm an edge case here, so I do appreciate the thought. The filters really are excellent. And yes, anything that can every be done to speed up large watchlists will always be appreciated!

Just to add a little observation I had after seeing this interesting discussion. With my very tiny Watchlist consisting of only 29 pages and absolutely no user scripts that customize what appears in Watchlist, it took me 2 seconds for the list to appear and around 3 more seconds for the panel itself to load 500 changes. This is on a Firefox Nightly 62.0a1 on a Dell Inspiron 3542 running Debian 9. fast.com reports my internet speed as 4.8 Mbps which I find to be a decent speed in the place I live.

I'm reporting this as I find this very slow as compared to the 0.6s observation by Roan Kattouw (WMF).

I forgot to mention that this was for the URL,

https://en.wikipedia.org/wiki/Special:Watchlist?hidebots=1&hidecategorization=1&hideWikibase=1&limit=500&days=7&urlversion=2&safemode=1

I'm also seeing severe performance issues. The old watchlist takes 8 seconds to fully load, and is usable after ~4 seconds (the remaining 4 seconds are for the ORES highlighting to load). The new watchlist takes 34 seconds to load. While the watchlist comes on screen after 4 seconds, I cannot interact with it in any way until the three grey dots go away 30 seconds later.

I'm using the corporate-mandated IE11 running on a fairly modern computer, albeit inside a virtual machine. However, performance on other websites isn't this bad.

If the issue is large watchlists (mine has ~9000 pages), perhaps the new system should fall back to the old one once the watchlist is above a certain size. However, despite what @Roan Kattouw (WMF) said, my huge watchlist doesn't take 12 seconds to load in the old watchlist page despite my list being larger. I suspect that this comes down to server-side processing being faster than whatever the new watchlist is doing.

Thanks for your report @Ahecht. Can you please copy and paste the url when you're using your default filter set, so we can look for any patterns with that? Meanwhile, I'm pinging @KHarlan (WMF), who's also looking into this issue.

@JMatazzoni (WMF) https://en.wikipedia.org/wiki/Special:Watchlist?hidemyself=1&hidebots=1&hidecategorization=1&hideWikibase=1&limit=500&days=7&enhanced=1&damaging__verylikelybad_color=c5&urlversion=2

@Ahecht thank you for the URL. A few questions:

1. Can you please try appending &safemode=1 to the URL, starting IE11 in "No add-ons mode" by running the Run command from the Start menu, and then typing iexplore.exe -extoff into the box, and then visiting your Watchlist page again?
2. Could you please elaborate on "I cannot interact with it in any way until the three grey dots go away" -- you cannot click on links in the watchlist? Are there other things that are blocked, scrolling for example?
3. Do you also encounter performance problems on Special:RecentChanges?

thank you for your help!

@KHarlan (WMF):

1. After my last post, I took the opportunity to trip my watchlist down to 6750 items, which brough the load time to 20s. &safemode=1 shaved off about 1.5 seconds, and starting IE in no add-ons mode didn't have a measurable impact.
2. Yes, I cannot click any links or scroll. I should mention that the three dots also stop animating about halfway through.
3. Looks like I have the same issue with RecentChanges taking about 20-30 seconds to load. Hadn't noticed that before, as most of my recent changes patrolling is using Huggle.

@JMatazzoni (WMF) With 250 changes, it brings is down to a little over 10 seconds (with safemode)

Thanks @Ahecht, could you also please let us know the load time with a limit of 100 items, and also if you find the performance with 100 items (page load, toggling filters, etc) to be acceptable?

@KHarlan (WMF)That brings it to 6 seconds. While 6 second by itself is acceptable, the fact that I'd have to load the page 10 times (for a total of 1 minute) to see the same number of pages that I get on the old watchlist (which loads in 6 seconds now that I've trimmed down my watchlist) isn't.

@Ahecht I hear you :) thank you for this information, we will look into it further.

@Ahecht, the team is looking into this, so please answer another question. What happens if you reduce to 250 changes (instead of 500). As a side note, if you do end up reducing the search in this way, it might work for you to try using the "Unseen" filter (in the Watchlist Activity group). With that filter on, once you've looked at the first batch, you can move on to the next. But anyway, we're just trying to figure out how the system is working, and none of us has a test account as large as yours!

I don't mind the new interface (can't say I've found a use for it either), but I've had to disable it because of the poor performance. For me it takes 5-10 seconds for the edit filters to load (perhaps because I have a lot of pages on my watchlist?), and during that time the whole watchlist is unresponsive. Like most Wikipedia addicts I'm constantly opening/reloading my watchlist so this gets really irritating really fast. By contrast the old filters load instantaneously for me. If the plan is to make this the new default I really hope something can be done to it speed up before it leaves beta.

The load wait when you first arrive is annoying and for me the filters are a hindrance. But I can't find the instructions on how to switch it back to the old, fast, alpha, better interface :(

If you go to the "Beta features" tab in your preferences, you can untick "New filters for edit review" to disable it. Make sure you also untick "Automatically enable all new beta features", otherwise it will instantly re-enable the new filters when you click save!

Thanks for the reply, but it didn't work for me :( I'm using this on Wikimedia Incubator.

The slowness of this tool makes it tedious to use. I like the idea but am unable to tolerate the ~5 second load time in the workflow habits I have for using my watchlist.

We just fixed a longstanding bug that made ORES searches much slower on Watchlist, so if you have been using any ORES filters, you should notice a big change.

Meanwhile, our tests show that the average WL load time with the new UX is around 3.5 secs on en.wiki (check the top graph on the right). According to different tests, that is about a second slower than the old UX on first page load (see cell E50) and about a half second slower on subsequent, "hot cache" reloads (E59). Oddly, Recent Changes loads faster on average, so we continue to look for ways to speed Watchlist up.

Thinking about this speed issue more, I have a question. It sounds like this might be how you are using WL: to check a page, you click on it and go to the page, then use the Back button to go back to WL. Is that right? If so, it's understandable that load time would be an important consideration, since you are reloading the entire WL each time. (As noted above, because you are coming from a different page, this causes the full, "cold cache" reload, which is the slowest.)

I wonder if you might instead consider using right-click or the equivalent to open a new tab when reviewing changes?

A new feature we added might make this approach work particularly well. You may have noticed the blue "View Newest Changes" link, which appears right above the search results. The link appears whenever new changes are available. WL looks for them every few seconds in the background. So if you don't see the link, there is no need to reload the page; you can be certain you are seeing the latest. And if you do see the link, then clicking it just fetches the new results, which is faster than reloading the whole page.

I know this would require a change to what may be a longstanding routine. But other than that, what do you think? It seems like it should be a net timesaver, since it would entail fewer page reloads overall (even if the ones you did have to do were a half sec slower). @Joe Roe, @Bluerasberry, if this technique wouldn't work for you, I'd genuinely like to understand why? Thanks.

Thank you for the detailed response! I use Wikipedia throughout the day to procrastinate while I'm working, so my workflow (such as it is) is basically to open my watchlist every half an hour or so, look through any changes either using the popup script or new tabs, then close it again. So no I don't leave and reopen the page frequently. If I'm actively editing I'll leave it open in a tab and reload every now and again.

I had noticed the "View Newest Changes" feature, and it is cool, but for me it doesn't make any appreciable difference to the load times. To clarify, above I was talking about the time it takes the edit filters to load after the watchlist itself has rendered (during which time the watchlist is unresponsive). For me at the moment, it takes about 4 seconds for the page to load, then less than a second for the old edit filters to load (in fact until now I hadn't noticed there was a lag). With the new filters enabled, it takes about 5 seconds for the page to load (I timed it a few times to be sure it is actually longer), and then after that a further 9 seconds for the filters to load. It's the second part that's really annoying, and it's only about 2 seconds quicker if I use the "View Newest Changes".

So I'm not sure changing my workflow would help. Also, I did these timings just now, so the change to ORES unfortunately does not seem to have made a difference – I don't think I am/was using any ORES filters. I can't explain why my experience has been so different to your stats. I guess I'm just an outlier?

I am very sorry to hear that delay is hitting you. Yes, you appear to be an outlier, but that doesn't mean we want to ignore your situation. Two things: I'm pinging our lead engineer, @Catrope, to see if he has any ideas for following up on this, and can you please say how many pages are on your Watchlist? Also, just checking, are you using a reasonably fast broadband account?

Thank you. I have 5,031 pages on my watchlist, and a 24 mbps broadband connection.

@Joe Roe Thanks for the detailed breakdown of the loading time, that helps a lot. It's remarkable to me that the second stage takes 5 seconds. It doesn't take that long for me. I'd like to investigate that, and I have some questions:

1. If you use safe mode (a URL parameter that disables gadgets), does that make it any faster?
2. Which browser do you use?
3. After the watchlist finishes loading the address bar will display a URL that looks like /wiki/Special:Watchlist?lots of stuff here. Could you send me that stuff?

I also noticed that it takes about a half-second longer for me than it used to, so I'll try to figure out why that is.

@Roan Kattouw (WMF) Worse, the second stage takes 9 seconds!

1. Safe mode doesn't seem to make a difference. It's still 5 seconds to render the page + 9 seconds for the new edit filters to load.
2. Chrome, the 64-bit stable branch
3. ?hidebots=1&hideWikibase=1&limit=1000&days=7&damaging__likelybad_color=c4&damaging__verylikelybad_color=c5&highlight=1&urlversion=2

Thanks for taking the time to investigate.

I've done a bit of messing around. Removing the two ORES highlighting filters (so the query string is ?hidebots=1&hideWikibase=1&limit=1000&days=7&highlight=1&urlversion=2) shaves about 3 seconds off the time it takes the edit filters to load. That's still a bit long for me to stick with the new filters (5 secs + 6 secs), but perhaps it means something to you guys.

@JMatazzoni (WMF) @Roan Kattouw (WMF) I see this is being switched on properly now. Has this been fixed?

Hi@Joe Roe, thank you for following up on this. A few questions:

1. Could you tell me a bit about your computer – RAM, CPU, and operating system?
2. What is the load time like if you set the limit to 100, and at 250?
3. Do you see the same performance issues on Special:RecentChanges with the same query that you use on Watchlist?

I'm pinging @KHarlan (WMF), who's also looking into this issue.

Tracked in Phabricator
Task T197476 Invalid

Turning on "New filters for edit review" in Beta has also turned on "New wikitext mode" without me selecting it in preferences. Is this deliberate? If so, it is mistaken to do that, if not, it is a bug. I'm using the monobooks skin.

Is the "Automatically enable all new beta features" option checkmarked? If so, that could be the cause of enabling the "New wikitext mode". See whether de-checkmarking the option and "New wikitext mode" works.

@George Ho has raised the most probable case. Can you confirm if that's the origin of your problem, @Spinningspark? Thanks!

Of course that's not the problem. If I had all beta features automatically enabled it would have been on ''before'' I turned on the new filters. But today it seems to be on permanently and I can't turn it off at all.

I tried to reproduce the issue at English Wikipedia but found none. I tested out the feature in various skins in older wikitext editors, including the one without the toolbar. The wikitext editor is not affected.

I even used IE11, Chrome, and Firefox to find the problem but found no issues that you asserted. Maybe it's your browser's cache? Have you enabled a gadget that can clear out, i.e. "Purge", your cache? More can be read at Help:Locating broken scripts.

Ok, purging the cache doesn't help. Turning on safemode doesn't help. Switching browsers (Firefox, Chrome) doesn't help. Below is the output of the console. There appears to be an error with $button.toggleClass(...).data(...) but I've no idea where that is coming from. It's not directly in my js page but may possibly be imported from other js.

Use of "mw.toolbar" is deprecated.

load.php:154:52

Use of "mw.toolbar" is deprecated.

load.php:154:52

JQMIGRATE: jQuery.fn.bind() is deprecated

load.php:140:200

jQuery.Deferred exception: $button.toggleClass(...).data(...) is not a function updateToolbarButton@https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=ext.3d%2CCodeMirror%2Ccharinsert%2CeventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.CodeMirror.data%2Clib%7Cext.CodeMirror.mode.mediawiki%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.eventLogging.subscriber%7Cext.math.editbutton.enabler%7Cext.uls.common%2Ceventlogger%2Cinit%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.supportCheck%2CtargetLoader%2CtempWikitextEditorWidget%2Ctrack%2Cve%7Cext.wikimediaEvents.loggedin%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CRegExp%2CString%2CTitle%2CUri%2Capi%2Ccldr%2Ccookie%2Cexperiments%2Cicon%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Ctoolbar%2Cuser%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.edit%7Cmediawiki.action.edit.collapsibleFooter%7Cmediawiki.api.options%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.widgets.visibleLengthLimit%7Coojs%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui-widgets.styles%7Coojs-ui.styles.icons-editing-advanced%2Cicons-editing-styling%2Cicons-moderation%2Cicons-movement%7Cschema.UniversalLanguageSelector%7Cskins.monobook.mobile%7Cskins.monobook.mobile.echohack%2Culs%7Cuser.defaults%7Cwikibase.client.action.edit.collapsibleFooter&skin=monobook&version=0rq8z53:6:700

addToolbarButton/</<@https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=ext.3d%2CCodeMirror%2Ccharinsert%2CeventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.CodeMirror.data%2Clib%7Cext.CodeMirror.mode.mediawiki%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.eventLogging.subscriber%7Cext.math.editbutton.enabler%7Cext.uls.common%2Ceventlogger%2Cinit%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.supportCheck%2CtargetLoader%2CtempWikitextEditorWidget%2Ctrack%2Cve%7Cext.wikimediaEvents.loggedin%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CRegExp%2CString%2CTitle%2CUri%2Capi%2Ccldr%2Ccookie%2Cexperiments%2Cicon%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Ctoolbar%2Cuser%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.edit%7Cmediawiki.action.edit.collapsibleFooter%7Cmediawiki.api.options%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.widgets.visibleLengthLimit%7Coojs%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui-widgets.styles%7Coojs-ui.styles.icons-editing-advanced%2Cicons-editing-styling%2Cicons-moderation%2Cicons-movement%7Cschema.UniversalLanguageSelector%7Cskins.monobook.mobile%7Cskins.monobook.mobile.echohack%2Culs%7Cuser.defaults%7Cwikibase.client.action.edit.collapsibleFooter&skin=monobook&version=0rq8z53:8:489

mightThrow@https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%7Cmediawiki.legacy.wikibits&only=scripts&skin=monobook&version=18kdz1s:49:590

resolve/</process<@https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%7Cmediawiki.legacy.wikibits&only=scripts&skin=monobook&version=18kdz1s:50:269

undefined

load.php:52:398

TypeError: $button.toggleClass(...).data(...) is not a function[Learn More]

Can you please do the following and tell us what happens?

1. Go to beta preferences, remove both beta features.
2. Make absolutely sure that the checkbox is not checked; make sure it didn't accidentally (or through a bug) got checked on its own
3. Save preferences, and then go on to Wikipedia and clear cache
4. Go back into preferences, and select "New Filters for Edit Review"
5. Save, check to see if the problem re occurs.

Thanks.

Hi Trizek, I'm pretty sure I've tried all of that already, but just to make sure, I've gone through it again following your instructions exactly. Note that "New wikitext mode" is on permanently regardless of whether I have "New filters for edit review" turned on. I've also tried completely removing all personal js. Still got the wikitext mode stuck on.

On Windows 7, which I'm using, enabling the feature for my Watchlist while in beta doesn't change my wikitext mode. I turned on and off the new wikitext editor. The old editor still remains unaffected in my account.

I don't know which OS you are using. If Windows, maybe you want to check your "Task Manager" (via Ctrl+Alt+Del) to see your CPU and RAM performances. If that's not the case, how about checkmarking the "Temporarily disable the visual editor while it is in beta" option in the "Editing" tab? Maybe either clearing out your browser's cache or resetting your Preferences to Default would solve the issues, but I'm uncertain whether either is worth the risk because either you would lose your browser data or you have to reconfigure the Preferences settings.

I'm using Windows 10. I don't know what you wanted me to look for in task manager but nothing stands out as problematic. Temporarily disabling visual editor in beta does nothing and I am not using VisEd in any case. I've cleared my browser cache without effect. That was not likely to be the problem anyway since I still have the problem if I switch to Chrome. I'm reluctant to reset my preferences, that's likely to cause me all sorts of grief.

This is definitely account related. Only seeing the enhanced wikitext in editing mode in my main account. Not while logged out or logged in to an alt account.

Ok, I fixed the problem by taking the plunge and resetting my preferences. That was a bit of a pain because I had to save a copy of all the settings and remake them, but the only annoying things that have happened is my watchlist token has been reset and my saved watchlist filters have been lost.

The problem was not actually caused by any setting in preferences. It was that I had inadvertently turned on (or it got turned on through a bug) syntax highlighting in the (old style) edit window toolbar. I did not even realise that this button had been added to the toolbar. I wish people would leave the old skins alone. There is a reason people use them; they don't want to change to something new.

Glad you've managed to fix that @Spinningspark. We have looked for reasons from what you gave us but found nothing. While you're the only one reporting this, we think that was on your side. If you experience any new disturbance, please tell us!

Tracked in Phabricator
Task T197686

Hi Supporters :) I'm taking care of the german de:Portal:Ethnologie (Ethnology) and find your tool very helpfull. I have added it into a category info template to link to the (german) "Spezial"-page to show all edits of pages linked by the categorie, in the form of: [https://de.wikipedia.org/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten?hidebots=1&hidecategorization=1&target={{FULLPAGENAMEE}}&limit=999&days=30&enhanced=1&urlversion=2 page changes] = page changes, example: de:Kategorie:Ethnologie.

My questions:

1. Do I have to use an url link - or could I use a normal wikilink?
2. Does my code need optimization?
3. Is there a way of adding category depths to the list?
4. and: How can I remove my own filter from my view? I have 1 saved ("links from the page Portal:Ethnologie"), but can't get rid of it without deleting it, and also I can't judge the effect this permanent filter has when I list category pages...

Thanx, and keep up your good work :) --user:Chiananda about 16:30, June 17 2018 (sorry, I don't know how to place my signature here)

Hello Chiananda, and thank you for your feedback. That usage of the filters is very interesting.

They way you've built that tool is great, because you can replicate it on numerous categories.

Concerning your specific feedback:

1. I'm sorry but you will have to use an URL like the one you use. That's due to the multiple parameters that have to be set and that are used to display the filters.
2. I don't think so.
3. It is not possible for now, due to performance issue. We are exploring a way to add category filtering on Recent Changes and depth is would be limited.
4. It is not possible to replace an existing filters on the saved filters menu. You need to delete the existing one and replace it with your new set. I4ll report you need.

Thank you for your nice appreciation, I'll report it to the development team as well. :)

(You don't need to sign or timestamp here. This is done automatically here.)

An optimization: change 999 to 500, while recent changes are capped to 500.

Thanx for your answer, Trizek :)

I have 2 more questions, an error report and a proposal for optimization:

1. What's the meaning of the parameter "enhanced=1"?
2. What's the meaning of "urlversion=2"?
3. I always get 0 results when I filter "article talk pages" (german: "Diskussion")! But it would be helpful if one could check for user contributions to article talk pages...
4. The "advanced filters" ("Erweiterte Filter") are right at the bottom of the long list of filters -- my proposal is to place them at the top of the list to avoid necessary scrolling, possibly a bit smaller and on a single line.

Shortcut for advanced filters.

My pleasure. :)

1. Well... honestly, no idea. :D I'll ask.
2. Same thing. That's the first time I'm ask for those.
3. Can you share with me the link with that particular filter?
4. You have a shortcut on the left (see picture) and you also can use typing shortcuts:
   • : (a colon) to access the Namespaces menu
   • # (a hash) to produce the “Tagged edits” menu.

• enhanced=1 is to group results by page
• "urlversion=2" helps track the state of the application"

Trizek, both shortcuts don't work for me, neither on the page nor on the filters list :-(

For talk pages I tried many different approaches and filter combinations -- always 0 results and the message "Keine Änderungen während des angegebenen Zeitraums entsprechen diesen Kriterien."

Here's one for the "de:Kategorie:Schamanismus" without any filters, only with activated "Diskussion" (top of the name space list, below the "Artikel"), and a vivid discussion going on at the article "de:Schamanismus":

https://de.wikipedia.org/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten?target=Kategorie%3ASchamanismus&namespace=1&limit=999&days=30&enhanced=1&urlversion=2

For the de:Portal:Technik, which is one of the most frequented portals in deWiki:

https://de.wikipedia.org/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten?target=Portal%3ATechnik&namespace=1&limit=999&days=30&enhanced=1&urlversion=2

For "de:Kategorie:Mathematiker (20. Jahrhundert)" with 4.330 pages:

https://de.wikipedia.org/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten?target=Kategorie%3AMathematiker+%2820.+Jahrhundert%29&namespace=1&limit=999&days=30&enhanced=1&urlversion=2

For "de:Kategorie:Liste (Biografien)" with 4.807 pages:

https://de.wikipedia.org/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten?target=Kategorie%3AListe+%28Biografien%29&namespace=1&limit=999&days=30&enhanced=1&urlversion=2

Shortcuts that don't work are really an issue. Can you tell me if they work if you click on that test link?

Concerning discussions, the link you give me has no edits on talk pages. Can you made an edit on one of the articles so that we can check again? Because if there is no edit on talk pages for the last 500 edits, that's a bit difficult to filter. ;)

Still the shortcuts don't work (on your test link) -- possibly a problem of the de:keyboard setting? And sorry: the name space button on the top right of the interface slipped my attention ;-)

Your test link ([https://de.wikipedia.org/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten?target=Kategorie%3ASchamanismus&namespace=1&limit=999&days=30&enhanced=1&urlversion=2&safemode=1 shamanism] = 0 results) includes the main article de:Schamanismus with fresh discussions, see de:Diskussion:Schamanismus, which shows results only for itself:

https://de.wikipedia.org/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten?target=Diskussion%3ASchamanismus&namespace=1&limit=999&days=30&enhanced=1&urlversion=2&safemode=1

Possibly I'm misunderstanding your tool: I'm trying to find new edits on talk pages of articles, but as talk pages generally are not linked from any article or portal pages the tool can't find them... Any hint or workaround?

I think you found it yourself as to why you don't get any results when you filtered for changes to dicussion pages in the related changes page of a category. As neither the category nor it's child categories link to any discussion pages, there aren't any changes shown when you filter for changes to discussion pages. To clarify a little, it's not about the tool (new edit filters) it's about how Related changes work. You wouldn't get any results even with the old interface. You would get a result only if the category or one of if it's children link to a discussion page. Hope that helps.

About the shortcuts not working, I'm not sure what's causing issues with you but they work for me in the test page Trizek pointed out. See linked screen shot to get an idea of how it would look like when shortcuts work.

1. The '#' shortcut
2. The ':' shortcut

Addition: I once tried to find changes on talk pages with PetScan, but never got a single result.

> I'm trying to find new edits on talk pages of articles, but as talk pages generally are not linked from any article or portal pages the tool can't find them... Any hint or workaround?

Ha! I think you've found the reason: looking for changes on Kategorie:Schamanismus may only look for changes on pages listed on that category but not their talk pages. I've tried that by adding the French Wikipedia's sandbox talk page to a category I was monitoring and it worked. That's something we should fix, I've filled a task for that.

Now we have to fix that keyboard issue:

@Chiananda, I don't think that's the case. Colons : are at least on all keyboards... Maybe your specific keyboard combination? Do you have the opportunity to try that on another computer? I've asked a friend to help us, by testing the shortcut on another German keyboard.

@Kaartic, do you still have the typing shortcuts when you don't use the safemode link I've provided?

Okay, got it :) And the shortcuts do work -- when I type them into the input field, also work when not in safe mode. Me dummy was just pressing keys without having placed the cursor properly ;-)

Now I understand the situation with talk pages, but still wonder why PetScan doesn't find any, even when I configure it for the shamanism category containing the shamanism article who's talk page I edited yesterday: https://petscan.wmflabs.org/?language=de&project=wikipedia&depth=10&categories=Schamanismus&combination=union&ns%5B1%5D=1&ns%5B7%5D=1&ns%5B11%5D=1&ns%5B101%5D=1&sortby=ns_title&interface_language=en&

I know that's not your construction area, but possibly there's an explanation for that effect? Cheers :)

Re the PetScan issue[1], the reasoning is quite similar. As I stated before, it can only see pages that belong to a particular Category[2] or one of it's children (sub-categories). It doesn't know about the association between pages and their corresponding talk pages as we as humans do. From the perspective of PetScan (or any other tool, for that matter) a talk page is just another page and so if a talk page belongs to one of the categories in your query (with appropriate parameters) it gets listed else it doesn't. Hope that clears your confusion. If not feel free to contact me on my talk page about it!

[1]: I incidentally happened to use PetScan recently for one of my projects. It's quite a powerful tool, indeed. [2]: a set of categories, for that matter

Adding to the talk pages problem: There used to be a bot for that, but longtime offline, this used to be the url: ...toollabs:drtrigonbot/cgi-bin/sum_cat_disc.py|wiki=de&cat=Shamanismus&start=&period=700

Nowerdays there seems to be no way of overviewing talk pages, so nice that you considered to fill a task for that :)

> Me dummy was just pressing keys without having placed the cursor properly ;-)

:D Happy to see it is working like we've deigned it.

I have no idea about PerScan, a tool I don't use at all.

The task has been filled to have talk pages edits listes on Related Changes. It will take a couple of weeks to have it reviewed, given the fact that the development team in charge doesn't have their weekly task triage meeting today.

Thank you for the great discussion, btw. It is really pleasant to work with people like you both @Chiananda and @Kaartic! :)

> The task has been filled to have talk pages edits listes on Related Changes.

It's nice to have a task for that but I think it would complicate the RelatedChanges a bit and might possibly trigger controversies and conflicts with people who like the way in which RelatedChanges works now ;-)

It might be better to do this as an additional feature rather than a modification to the existing feature. A feature possible possibly called "Show changes in pages linked from (and their corresponding talk pages)" or so. (Noted in the phab task.)

> It is really pleasant to work with people like you both @Chiananda and @Kaartic! :)

My pleasure, thanks :)

Personally, I've occasionally or seldom used "Recent changes" pages because I found it too long to browse and seek. Also, it's not one of my high priorities to use. Nevertheless, I found the new filters feature refreshing, but I'm unsure whether it would make me use the page(s) more. Curiously, I wonder why the "Other review tools" box is collapsed by default; maybe I'll discuss it in another section.

Have the communities agreed with the default enabling of the feature? One of WMF staff says that 70,000+ people are using the feature under beta. Out of the people, 30,000+ English Wikipedia users are using it. The UTCLiveClock gadget has been used by 32,000+ en.WP users, but it's not enabled by default, especially to users. 47,000+ en.WP users use the pop-up feature, which is not enabled by default.

Hi @George Ho. Thanks for your question. The "Other Review Tools" area is collapsed by default for a number of reasons. In general, users are very sensitive to use of vertical space on search pages like this: they want to get to their results as soon as possible and see as many as possible on the screen. From an interface perspective, when you put things at the top of a page, you're saying "look at this, it's important." But on many wikis the contents of that box have grown over time, becoming a deep panel of up to 100 items in some cases—with most of those items having little or nothing to do with the page they're on or edit reviewing at all. This can be quite confusing to new users. Many links were simply to settings for the page the user is on (e.g., on English Wikipedia, this link to "IP contribs"). In the new UI, the Saved Filters functions make such links unnecessary. We did some testing on representative wikis and found that on these wikis, where Recent Changes got tens of thousands of page views a week, only a handful of the available links got more than 2 clicks. This is a strong indication that they're not earning their top spot on the page.

On some wikis, that spot is used as a kind of notice board for important announcements. Since such notices are meant to be seen by as many people as possible, this is a legitimate use. There is a slot above the Other Review Tools box—which does not collapse—that we recommend wikis use for this type of important information. (I could look up what it's called in case you'd like your wiki to begin making use of that space). So this gives wikis the ability to make judgements about what should be seen by everyone and what can be available for use if and when you need it. And, of course, for anyone who likes to see Other Review Tools, all they have to do is open the box one time; the box stays open, as I'm sure you've discovered.

Regarding your other comments, I will just say that beta features are not meant to last forever; they are a testing stage on the way to becoming standard. In this case, a new UI paradigm was really necessary to accommodate all the new functionality we added. Also, it makes sense for Watchlist and Recent Changes, which share almost all their functionality, to work in the same way. This type of standardization makes the wikis tools easier to learn and easier to maintain. Now that the New Filters have been through more than eight months in beta, we're pretty sure they are safe and effective. This New Filters UX is the new standard for this type of page, and we want to bring it to more people, including new users, who otherwise might not discover it as a beta for a long time.

I hope you give the New Filters a try on Watchlist. But in recognition that the new tools won't work for everyone, opting out will also be pretty painless.

I've tested out the feature in Beta for my Watchlist. I'm unsure whether the newer layout is necessary. The plus of the new feature is showing all contributions unfiltered per choice. However, the de-filtering of all contributions occurs only at the newer feature. (See my latest post)

If I want to keep the old version, can the option to show/hide other past (i.e. non-recent) contributions be added? That way, I don't have to use the new feature. Personally, I am not thrilled with the layout for it looks too distracting and gimmicky at best. Also, I am not thrilled with the defaulting of filters.

> can the option to show/hide other past (i.e. non-recent) contributions be added?

I'm not sure which feature you're referring to here. What is the name? Do you mean the Seen/Unseen filters, perhaps?

> Also, I am not thrilled with the defaulting of filters.

The New Filters provide default function that is infinitely more flexible than previously. Simply set the filters to any combination you like, then click the bookmark icon to launch the "Save current filter settings" panel and, while there, check "Set as default." Now that combination will be your new default.

Either I can select both "Latest revision" and "Not the latest revision" to see all contributions within the past whatever days I can select as long as it is no more than 30 days, or I can use the trash can icon to clear out the filters and then still see all my (oops) contributions of articles that I put into my watchlist.

Using the new interface, you filter your whole watchlist. If you remove all filters, you will then have all pages you watch displayed. Then, you can add filters to narrow down the results.

I mentioned in the below post that I can see all changes in the old Watchlist UI by enabling one of the options.

The old Watchlist UI has its filtering system. How is the new UI feature a much improvement to the older one?

To quote what I've written below, it adds live page updating, user-defined highlighting, the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning, filters tagged edits and (coming soon) categories. All those new features required to have a new interface to handle every possible filtering options, that has been tested with users during the development process.

Oh, wait... I found out how to see all the changes: checkmarking the "Expand watchlist to show all changes, not just the most recent" option at the Watchlist tab.

Edit: Default enabling of the feature is not the same as graduating it out of beta. Now that I enabled that option, IMHO enabling the feature without community consensus is too premature. Can you set up a plan to ask for further feedback, like creating a discussion at Village Pump, or has it been already done?

Can any WMF staff answer why the new watchlist filter feature must be enabled by default? I see no reason for any community to shift to a layout change. Moreover, only registered users have access to watchlist.

Over 70,000 people have activated the New Filters beta across the wikis, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us now with a post on this talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed. Are you aware of any technical issue we should look at, beyond how the interface looks?

That tool introduce new features, like easier yet more powerful filtering interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting, the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning, filters for tagged edits and (coming soon) for categories. If you’re not familiar with the New Filters, the documentation pages provide guidance on how to use the many new tools you’ll discover. I can also help you in that discovery phase.

Don't forget that if you don't like those filters, you will be able to opt them out immediately. You also have a long experience editing, and the familiarity you have with Watchlists like there are since a while may not be the case for beginners. Tests made during the whole development process have been used to explore interface options and reduce all UX blockers and make the new interface usable.

Also, a message has been left on Village Pumps.

I see that the filters graduating out of beta were announced very briefly and in detail. However, I don't see discussion or community feedback about changing the default of watchlist.

Also, why not "opt-in" option? And what are the flaws about the old (current) Watchlist UI?

Edit: BTW, thanks for the lengthy reply.

A detailed announcement was given to the enwiki Village pump about two weeks ago and is now in the archives. Link to the announcement: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_166#Plans_to_graduate_the_New_Filters_on_Watchlist_out_of_beta

The opt-in option was the Beta phase. During that Beta phase (so as with the announcement), people were asked to provide comments and feedback. Now that there are no blockers from the feedback we've received since 6 months, we move on to offer the new tools to everyone. There is still an option to opt-out that anyone can use anytime in their account.

The old UI was not supporting the new tools. Its UI wasn't that much clear. For instance, Watchlist options we all compacted at the same place. While adding new tools, we have tried to provide the right tool at the right place, and then tested it to offer a better, easier to read and more accessible experience to users. you can read more about the reasons on Edit Review Improvements page.

Tracked in Phabricator
Task T197065

See the Phabricator task for details; just posting here as this might be a more visible venue, given it is where the feedback link leads.

Ping @JMatazzoni (WMF), Trizek (WMF):

Sorry I've missed that one, @Evad37. I'll follow up on the task, thanks!

Taken to enwiki.

With the new filters enabled, the padding above the announcement on the Watchlist page ("The Collaboration team plans to...") seems to be gone almost entirely – previously there was a bit of space there, but now the text is right up against the page title.

Hello

I assume you are on English Wikipedia? Which skin do you use?

I've checked on my side using Vector skin. There is a margin below the first line "For User (View relevant changes | View and edit watchlist | Edit raw watchlist | Clear the watchlist)", when you don't have the filters. That line is removed because those links are located elsewhere.

The fix would be to add to the common.css of English Wikipedia the following code (or something similar) to add a margin with an equivalent value:

.mw-rcfilters-enabled .mw-specialpage-summary {margin: 1em 0;}

Can you share what with your local admins? If not I'll be happy to help.

Yep, on enwiki, using Vector. I will mention it at the enwiki village pump. Thanks!

I'm not sure if this has been fixed yet, but when these rolled out in beta on watchlist, I had to disable because deletion logs were not being shown. Just commenting so it can be checked on.

@TonyBallioni Have you checked which filters you're using? They show up fine for me as I have "Logged actions" as one of the active filters.

@TonyBallioni I manage to filter logs. I've highlighted them in blue in that filters combination.

Tracked in Phabricator
Task T195738

There should be a way to filter for all non-tagged edits (just as you can filter for specific tag(s)).

Thank you for that idea. I've created a ticket to track it.

We need the ability to set as default an already created filter. At the moment, we can only set the default during the filter creation process.

Inside "Saved filters" when you click "...", you will have the ability to set the filter as default.

Thanks, obvious now you've pointed it out!