Talk:Edit Review Improvements/New filters for edit review

Jump to navigation Jump to 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.

Clean Copy (talkcontribs)

It would be much clearer and cleaner to have the active filters and saved filters buttons spatially related.

A very small tweak would solve this: Put saved filters directly under active filters by exchanging the saved filters and live updates buttons.

(Sure to be contested bonus from the change: live updates would then be where I, at least, would intuitively expect it, at the upper-right-hand corner of the box.)

This is probably too late...

Reply to "Slight layout tweak?"
Florentyna (talkcontribs)

I think after some tries and 2 million edits it is too complicated. Too much switches, not really saying where to find what. Even the diasable button for the new feature is heavily to find. In the old version, I needed three clicks to solve everything, now 10+. ~~~~

Reply to "Too complicated"

Can't find the page refresh date and time anymore

Moonian (talkcontribs)

Where are they now??

Trizek (WMF) (talkcontribs)

You mean the last time you've refreshed your watchlist?

Moonian (talkcontribs)


Trizek (WMF) (talkcontribs)

Thank you for the precision.

On the new interface, you have the "View newest changes" link if the watchlist needs to be reloaded because there is something new to display. Would it be sufficient or is there another use case you think about that would need to display the last refresh timestamp?

Moonian (talkcontribs)

Well, as I always leave that Watchlist page open in my browser (and I hibernate my computer instead of a complete shutdown when switching off it), I wish to have a timestamp to remind myself when that page was refreshed last time.

Mraslat (talkcontribs)

Please reset the timestamp. Thank

Trizek (WMF) (talkcontribs)

So do I (keep the watchlist open), and I now rely on the "View newest changes" link to know that I have to reload the watchlist: that link only appears if there is a change on any page you watch.

While there is no more developments scheduled for that new interface, I'm wondering if that "View newest changes" link is an acceptable alternative for you. If not, I'll create a ticket to track that suggestion of displaying the timestamp. But I need a justification for displaying the date again, because the product development team will certainly say "but there is the 'View newest changes' link now". :)

Moonian (talkcontribs)

Never encountered that feature yet, so can't be sure if that alternative is acceptable (for now).

Trizek (WMF) (talkcontribs)
Moonian (talkcontribs)

OK, found it - but IMHO it turns out it's just a fancy F5-key alternative + annoying nag screen ("Hey, something's changed, refresh the page NOW!!!!!" - I would like to decide when it will get refreshed myself and so don't tell me if there're changes or not, thank you very much). In other words, the new design has something quite useful got taken away while added something else that's not so useful.

Mraslat (talkcontribs)

To see when you last refreshed the page manually.

Trizek (WMF) (talkcontribs)

@Mraslat, have you noticed the "View newest changes" link? That link only appears if there is a change on you Watchlist. If you don't see that link, it means that nothing has changed since the last time.

Mraslat (talkcontribs)

Yes. "View newest changes" That link only appears.

Trizek (WMF) (talkcontribs)

Is that link enough? Why do you need to have time and date? I need to know why you need that feature, so that I can fill a feature request.

Reply to "Can't find the page refresh date and time anymore"
Tenbergen (talkcontribs)

I like that there is now a filter for these. I was wondering, though: will the resulting entry's diff link only show that last change as well, or will it show all changes since my last visit. There is now highlighting in the history tab that shows which were after my last visit, so it appears the data would be there to do this.

If it only shows the most recent edit's diff I think I would still need to review all edits on our wikis, since I would miss small bad edits otherwise.

Matěj Suchánek (talkcontribs)

Under "### changes, # days" you can enable "Group results by page" which provides such diffs (this is called "enhanced rc").

Tenbergen (talkcontribs)

Maybe this has changed in the newest version, but in 1.30 I think it would only group them for that day. So, if I review recent changes after a week, and there have been 10 edits on 3 days, I will still get 3 listings. Does the new grouping group those 10 edits to one entry, then? If it grouped them only to the last day, but diffed the changes of all 10 edits, that would be the most useful for us. As it is, even with grouping, people often see the earlier diff and start editing there. We have educated about it, but it occasionally I even make the mistake as I crank through dozens of reviews and miss the "not the most recent version" msg.

Matěj Suchánek (talkcontribs)

I see what you mean. I agree this would be helpful (I usually work around this by scrolling to the latest seen change to the page and using "cur" link). By the way, it's tracked in phab:T10681.

Reply to "Latest Revision filter"
Nihonjoe (talkcontribs)

Could a condensed, more compact version be implemented of the edit filter section at the top of the watchlist? The "new, improved" version takes up about five times the space the previous one did (the one with the small radio buttons). Thanks, 日本穣 Nihonjoe (talk) 22:07, 17 July 2018 (UTC)

ElKevbo (talkcontribs)

I second this request. This is a legitimate usability issue.

Nihonjoe (talkcontribs)

I'm just not a fan of the current trend to make everything huge. I can understand having it as an option (for those who need larger fonts and such, for example), but making it so everyone has to use up so much screen real estate for six/seven huge buttons? That's just a little ridiculous. Maybe I'm just old school in that respect.

Tenbergen (talkcontribs)

I third it. Let's keep this compact.

Trizek (WMF) (talkcontribs)

It may surprise you, but, based on the team observations, the overall new interface is as high as the old one on most wikis; it is even sometimes a bit more compact that the previous one.

View of the compact mode link ("hide") for recent changes and watchlists.

Have you seen the "hide" link on the top-right of watchlist and recent changes pages, below the "saved filters" option? It displays an interface more compact than ever.

Tenbergen (talkcontribs)

I use MW1.31 and I don't get the hide button. I guess that must be a more recent addition. I still run MW1.30 on another wiki, and the new version's filter GUI really is only a little big taller, maybe 1 line, but it is taller. The "hide" could make things better, especially if it can hide by default. However, even when "hidden" the top area still has those big buttons and a lot of whitespace. I just took a screen shot of it, and at my resolution the font in the buttons is 11 pixels high, where the font on the page (eg the change links) is 9 px high. Maybe it would look less bloated if the font were the same size?

ElKevbo (talkcontribs)

Trizek, for me (Chrome on Windows 10) that button collapses one menu to the left and moves everything else up a little bit but it mostly creates a bunch of new whitespace.

Here is a screenshot of my Chrome window with the new watchlist: That's a maximized window at 1080p resolution. Between the normal Wikimedia UI and the watchlist UI the substantive content - the actual watchlist - doesn't begun until about 2/3 down the screen. That's a legitimate usability issue. It's not the end of the world and it doesn't mean that the tool is broken but it does mean that it needs to be polished.

I readily concede that the new watchlist doesn't take up any more screen real estate than the old one; I think the whitespace just makes it really obvious how much space the UI of this tool takes up.

Nihonjoe (talkcontribs)

EkKevbo's screenshot is how it appears for me in Firefox 61.0.1 (64-bit) in Windows 7. And it is quite a bit higher than the previous appearance. There is no way to hide all of the tools, but if they could be made more compact, perhaps on a single toolbar (similar to the edit toolbar when editing an article), that would be awesome. Even if it was just an option to display it that way, so everyone else who likes the humongous new version can keep using it.

Reply to "Condensed / Compact version?"
Steven Walling (talkcontribs)

These new Watchlist filters are great, but what I'd really love is also to be able to filter by Category. Tools like HotCat are able to do autocomplete on category names, so I assume that wouldn't be too hard?

Yair rand (talkcontribs)
Trizek (WMF) (talkcontribs)
JMatazzoni (WMF) (talkcontribs)

Yes, you are in luck @Steven Walling. That feature will be available later this summer. As you probably know, categories are not a perfect technology, so the feature will have limitations (e.g., the broader the category, the fewer the results—contrary to most normal systems). Our assumption is that users will be able to get around some of this by using Saved Filters (bookmarking) with multiple categories included.

We will be very curious to learn how the feature works for you—keep us posted!

Tenbergen (talkcontribs)

I would be really interested in a filter-by-category as well, even more so in a filter-by-NOT-category. Wonder what @JMatazzoni means by "the broader the category, the fewer the results", though... Even if a filter by category is tough, if there was a way to use categories in the highlighting that would be helpful.

Trizek (WMF) (talkcontribs)

@Tenbergen, if you filter a big, parent category (like "Science" or "History"), you will get fewer results than in a specific category like (fictional examples) "Mono-cellular organism" or "History of France during 19th century". That's due to two factors:

  1. broad categories tent to only list other categories (Science category on English Wikipedia has 34 categories and 18 pages)
  2. the more you sub-categories you explore, the more exponentiel are the results. Display all those results is not technically manageable so only pages directly in the category you search would be displayed (can be zero; would be 18 for the "category:science" example).
Tenbergen (talkcontribs)

Thank you for the example. I mostly use mediawiki in a private wiki, and for various reasons we usually have a page in its category, and its subcategory. (I understand that is not how it's done on wikipedia...). In our setting, then, if I had a change in a page in both "science" and "monocellular", and asked RC to restrict to category "science", the page would be listed, correct? In other words, the reason for fewer pages being listed is simply that the filter would only list pages in the category, not in its subcategories?

JMatazzoni (WMF) (talkcontribs)

What Trizek says is correct. But to clarify one of his statements:

> Display all those results is not technically manageable

He means as a standard feature of the search. I.e., we can't make it so that search routinely includes two or three levels of subcategories for each category you include, because the results would quickly get out of control. However, it will be possible for you to use bookmarking/Saved Filters to create searches of groups of categories. This seems like a viable strategy and we will be very interested to see how it works in practice.

Reply to "Filter by category?"
Arcy (talkcontribs)

I‘m a programmer an from my opinion thefilter is far to complex. The former one was easy and usable. Just allow both with the complex one as scond choice or default by user settngs.

Kdammers (talkcontribs)

I didn't even know about the previous filtering, but I found the description of the new set of filters land and not especially simple. Will anyone who is not a computer person or a native speaker (probably both) take advantage of the filters with this description?

JMatazzoni (WMF) (talkcontribs)

I'm sorry you find the new interface too complex. Changing the interface was required to accommodate all the new functionality that was added. If your work doesn't require any of the new tools (highlighting, the Seen/Unseen filters on Watchlist, the machine-learning filters on selective wikis, Live Update...), you can easily opt out on the Watchlist or Recent Changes tabs of Preferences.

Trizek (WMF) (talkcontribs)

We can also help you in exploring the new interface. Please ask for the use cases you are blocked with or you miss.

I now use the filters on my volunteer account and, like @JMatazzoni (WMF) reports, I had to accommodate myself with the new features. Now I can't work without them.

Clump (talkcontribs)

Some thoughts I had on this, as I tend to agree with the first two comments that the complexity of the filter interface is excessive.

I think it comes mainly down finding the category structure rather confusing and hard to control. I understand that each category represents a set of related suboptions, but the logic that controls that is not always easy to understand. For example, "Significance" includes "Minor edits" and "Non-minor edits". I can see those as mutually exclusive, and I realize that checking both ORs them together, but so does not checking them both. Why am I being given 2 ways to express the same thing? This does not make much sense. I tend to think of checkboxes as switches, and a design that results in leaving all switches off having the same meaning as leaving them all on is just bizarre.

It becomes more complex in larger categories where it is less obvious how the coverage of the individual options interacts. For example, on "Watchlisted pages", I can select "On Watchlist" and "Not on Watchlist". Logically, ORing those together, that should cover everything, but there's a third option "New Watchlist changes". So if I don't select that, then I would see pages on my watchlist, but not if they are new changes? That's either a contradiction or at least a peculiar combination to support, and moreover makes it even less clear what the design principle is. The options within a category are ORed together, but how are they derived----they are clearly not meant to be covering (partitioning the space), since they include negative versions, but they also do not sum to 0 (cover in both positive and negative senses). Having some options subsumed by others results in unclear combinations (A OR not-A, but not (B subset A)?).

Basically, an AND/OR structure to the across/within categories does makes some sense and is easy to reason about abstractly, but it does not always seem clear how this works with the way the options within categories are formed, using positive and negatives that sometimes includes overlap.

I imagine lots of thought was put into the logical design and that other interface designs were considered. Just to be sure, though, were there reasons why a simple list of selectable, non-overlapping, positive-only options (perhaps only stylistically separated into categories) was not sufficient?

Other, more specific issues I have noted:

  1. . I have checked all filters in the "user registration and experience" category, so I can highlight some of them differently. This works, but in the list of active filters they are all shown greyed out, and any that I did not change the highlighting for are declared as having no effect. However, having selected some to highlight, had I not selected the remaining ones those would be excluded. So, contrary to the mouseover text, they actually are having an effect.
    After some investigation, digging through the help text, I did find out that highlighting and filtering are independent. So I guess I could leave them all unchecked, and just modify highlighting to generate the same effect. This, again, comes down to the confusing ability to specify the same thing in two ways. It also points to an interface design problem----the filtering and highlighting are in the same row, prefixed by the filter checkbox, visually implying the checkbox controls both features. Perhaps putting the highlight drop-down prior to the checkbox would make it more obvious that these are independent.
  2. Bots are shown despite selecting "Human (not bot)" and not selecting "Bot". For example, "Bawolff bot" edits continue to be shown. That doesn't gibe with my understanding of how this works at all, so either I remain confused, or this is a bug.
  3. Under the "Translations" category I originally selected "Not translations", and not any of the other options, hoping to exclude translations. But translations still showed up! I understand (now) that this option is referring to the separate sub-pages for translation units, but those unit-pages are an (obscure, low-level) artefact of how translations are implemented. Certainly it did not match my expectation of what it meant to show or not show "translated pages".

Note that despite the above comments I do find these filters very useful, and I will continue using them on Recent Changes. It's just that my effective use of them has been based more on repeated, slightly frustrating trial-and-error than any kind of well reasoned methodology or clear abstract model given by the interface.

JMatazzoni (WMF) (talkcontribs)

#2 sounds like a bug--either of our system or of the bot. I haven't really seen bot results coming in on that setting. As to the rest, I'm pinging the designer of the UI, @Pginer-WMF, who may have thoughts about your observations. (talkcontribs)

The #2 issue isn't a bug. It is a deliberate design choice by developers. Recent changes mostly focuses on actions rather than groups. For example, learners aren't neatly tucked into any group, and it only considers an action by a bot if it explicitly uses the bot flag. Admins for example, can act like a bot and have their changes hidden without ever belonging to the bot user group.

It could be changed but it would still be confusing, for example, a user makes a bot action, then later gets the bot group removed. Their actions would then suddenly have to appear in recent changes. Adding the BOT user group expliclity, will just add to the complexity of the interface, not reduce it. Furthermore, the older recent changes does / did the exact same thing.

Steelpillow (talkcontribs)

It's not just the complexity, it is not adequately self-explanatory and some options are not there where you think they should be.

  • For example by clearing all filters I get everything, so I would expect that checking only the Wkidata filter would filter OUT Wikidata edits. But no, it filters out everything else! Very counter-intuitive and I am at a loss to know what will happen if I click a bunch of filters, or all the filters in a given box, or whatever.
  • Then when I go to the Saved Filters toy, there is no way to edit them, and no way to save more - the tooltip saying to use the bookmark icon in a different toy disappears once a filter is saved: the bookmark widget really belongs in the Saved Filters menu.

RTFM should not be necessary with a smart tool like this. Whether or not the complexity proves ultimately useful, it is certainly not clear or usable for the average editor yet.

Having said that, I do think it has great potential, so do please keep up the good work!

JMatazzoni (WMF) (talkcontribs)

Hi @Steelpillow. Thanks for sharing your views.

As you've noticed, the logic of the old interface was focused on what you wanted to exclude. In the new system, users specify what they want to include.

Although that change may seem strange at first, for most users this logic feels pretty familiar once they start using it because it's common on big sites like Amazon. On such sites, your initial search—for "men's shoes" let's say—returns very broad results, which you then refine by selecting options. The options are presented in groups: style, color, brand, price range, etc. Within any group ("style," let's say) all options in the group are included until you pick one or two (e.g., "sandals" and "slip-ons"), at which point only results matching those options are included and all others are excluded.

My observation is that this system of grouped filters can be confusing at first, especially when users try to analyze or describe just what's happening. But in practice they quickly come to understand and use it perfectly. Meanwhile, the ability to include or exclude exactly what you want provides more control over your results.

I hope you get used to the change and come to appreciate the increased control. If not, you can opt out on the Watchlist tab of your preferences. Good luck!

Steelpillow (talkcontribs)

Thank you for explaining the paradigm. It makes sense once one has got the message. However the UI does not make it as obvious as it might, and the learning curve will put some editors off. I would suggest that a slightly plainer styling with smaller tickboxes would help to make the mental connection with both shopping and academic selectors, both of which are usually like that. Also, I am not "shopping" for specific types, I still want to exclude types I am not interested in. On many similar forms, such as selecting academic resources, there is a "Select all" option. One can then go through and de-select anything one is not interested in. This would be a welcome addition for me. (Don't forget the accompanying "Clear all" option for the focused shoppers among us!)

Pginer-WMF (talkcontribs)

Just to add a bit of context. During our initial user research we found that it was not easy to understand which was the state of the filters in the original version. As the screenshot below shows, the filters had a combination of "show" and "hide" options that users had to process to understand which types of edits were displayed (e.g., "show bots" means that bot results are not included). In addition, the way to operate the filters was not very flexible (e.g., you can include "minor edits" or remove them, but you cannot focus to view only these).

We wanted the system to communicate the status in a consistent way. Displaying the properties that edits have in the "active filters" area you can read and adjust the properties for the results. In addition, we wanted to cover more usecases with the filters (e.g., fight vandalism but also thank newcomers doing a good job), and adding more hide/show links was not a scalable solution.

Reply to "To complex for ordinary writer"
Diego Moya (talkcontribs)

Buttons in the "Active filters" panel for filters with a highlight color are not removed when the filter is disabled. This allows us to enable and disable the filter with just two clicks (one to open the dropdown panel, the other to enable/disable the filter check).

Could we get the same behavior for the buttons of filters without a highlight color associated? I.e. do not delete the button when the filter is disabled, only when the "x" in the button is pressed. The buttons may even have a checkbox of their own, to allow enabling/disabling the filter with just one click, like in the following image.

Trizek (WMF) (talkcontribs)

Your goal is to have a way to enable/disable quickly a given filter? That would go for a set of filters you've defined, on which you would make changes quickly. Have you considered to bookmark those close sets of filters?

Filters not enabled but with a highlight are visible as "active" filters because they will surface a result. They are in grey.

Diego Moya (talkcontribs)

I want to enable/disable quickly several individual filters in a group of filters in fast succession, and the order in which I want to enable/disable them depends on the results of the current combination of filters, so saving all possible combinations as pre-defined bookmarks is not an option.

Since buttons for highlight colors stay always available as shortcuts for the filter in the drop-down panel, I'd want a way for the other buttons to behave exactly the same way. Basically, disabling the filter in the drop-down panel would fade the button to grey, not remove it, just as it happens with the buttons for "highlight" filters.

Is it possible to just add a "transparent" or "white" color to the "Select a color" panel in the drop-down, that would allow me to keep any button around? This would allow me to do exactly what I want, without having to develop any new feature nor changing the design substantially.

Diego Moya (talkcontribs)

Heck, even a configurable color option would suffice.The five different available colors are too limited anyway, I keep repeating the same highlight color for different filters.

Trizek (WMF) (talkcontribs)

First, you need to know that, as we speak, there is no planned improvements for those filters. (except adding filtering options by categories). You comment is alas a bit late, and would have been very welcome during the Beta phase. I'll however document any possible improvement for a future development phase.

We usually encourage people to narrow down their filtering options (and save the most used ones) so that the can have more specific results and then use the colors the best way. But you case apparently goes beyond that.

That "white button" would be used to display the filter in the filters list but not active? That may be a bit confusing to add a third state for filters.

Can you develop a bit about the workflow you have when you need to quickly change the filters? From your screenshots, I guess you want to check page edits and then page creations back and forth, right?

Diego Moya (talkcontribs)

I made the same comment during the Beta phase, presenting my use case, and it was ignored >:-(

Maybe you should review your feedback process? (I got some replies that my then suggested solution would be too complicated, and there was never any further work to support my use case).

If a "white button" is confusing, a "configurable color" would be not, and it would allow all filters to work in the same way as the highlight filters, making all buttons homogeneous (currently you have two different behaviors of buttons depending on whether they have a highlight color associated or not).

(BTW, I've read the Help page about highlighting, and the assumption that "you probably don't need to use more than two colors at a time" and thus five options is enough, well, it's wrong).

Trizek (WMF) (talkcontribs)

> I made the same comment during the Beta phase, presenting my use case, and it was ignored >:-(

Oh! I'm really sorry about that. :( Are you referring to that discussion? At that time, @JMatazzoni (WMF) was in charge of that project and was your direct contact. I haven't read your discussion at that time, while I was handling other feedback.

On that first discussion, you give examples of filters combinations you wish to quickly switch between. I think a possible workaround would be to create a gadget that would display the content of the bookmarked filters outside of the dropdown. That way, you could directly click on the matching link to have access to the different combinations you need: show only articles, show articles and their talk pages, show only Wikipedia pages, etc.

Diego Moya (talkcontribs)

Yes, that was the thread, which was already a summary of yet another older thread, which itself had been ignored for several months.

As I explained then, "Every day I may try these views in any order, or create different combinations of these and other filters", so having a large number of pre-defined bookmarks for all possible combinations could never support the stated flow; the list of saved bookmarks would quickly grow unmanageable.

The Bookmarks interface was designed on the assumption than just a few different pre-defined configurations were needed, but I had stated a different use case, which was never incorporated in the design.

Reply to "Disabled filters"
Scarpy (talkcontribs)

Why can't I just see a list of all the changes and then filter out what I don't want if I decide i don't want something? It's not clear what is and isn't being filtered.

Trizek (WMF) (talkcontribs)

I'm not sure to give you a correct answer, so do not hesitate to ask for clarifications. :)

To see all changes, you can clear all the filters (example). Then, you have two options:

  • select what you only want to see, by using the checkboxes. Here I'm only filtering changes done by humans.
  • highlight some particular results, by using the highlight options. Here, I'm only highlighting (in yellow) changes done by humans.
Scarpy (talkcontribs)

It's still not clear what the filters are doing for several reasons.

- Does a filter mean what you ARE seeing or what you ARE NOT seeing? E.g. does it mean I'm filtering something out, or that my filter only allows what I've selected?

- If I select "Human (not bot)" and "Logged actions" (whatever that means) does that mean I'm seeing things matching "Human (not bot)" AND "Logged actions?" Or does it means I'm seeing things matching "Human (not bot)" OR "Logged actions?"

- I'd guess OR but that would mean that the categories are generally mutually exclusive, which seems... unexpected.

- Why is there not a NOT operator? You just have to select all the filters in a category except the one you don't want?

... It seems possible enough to figure all of this out, but it's just confusing from a UI perspective. It should be more obvious what adding or removing a filter means in something more analogous to a SQL query (SELECT updates FROM wikipedia WHERE NOTBOT IS TRUE AND UNREGISTERED IS TRUE") something where you can see the logic being applied and not have to infer it. Something more of the form "condition operator condition" would make more sense. Would also love to see it give options like a contains search, or to filter by groups of users or projects or categories or something like that.

Another way to do this would be to show all of the conditions that apply to each diff, and then do something like a "filter matching" or "show matching" link. It's not clear to me what conditions of the ones I've selected apply to any given diff.

I suppose I'll get used to it, but the interface is just not intuitive and it will take a long time before I can trust that I'm seeing what I want to see. For the moment it's just a great way to obscure data... I hate to sound negative, just a really frustrating interface to use.

Trizek (WMF) (talkcontribs)

Basically, selecting only one filter will display that filter result. Selecting two filters will depend on the group they are on:

  • enable a filter (check the checkbox) will display what is on that filter label. If you check the "humans (not bots)" filter, you will only see edits made by humans
  • Select "Human (not bot)" and "Logged actions" (means whatever is recorded in a log: account creation, moving pages...) will narrow down the result and act ar a AND, because they are in a different group ("automated contributions" vs "type of change").
  • If you select filters from the same group, like "newcomers" and "learners" (both in "User registration and experience" group), you will get results from newcomers OR learners. You can then highlight one of the two groups to surface it.

You seem to have an advanced level of understanding concerning queries. I don't have your skills but I think making those SQL queries more visible would have confused people. For a person not knowing how to maque Boolean queries, what is the difference between "I want to see 'learners' AND 'newcomers'" (that wouldn't work because they are exclusive to each other) and "I want to see 'learners' OR 'newcomers'" (that would work but is not really understandable because you will get the first AND the second ones)?

Concerning filtering by username, those filters are for the next but unscheduled development phase. Group of users are handled by status (loggin/logged-out) experience - check the "User registration and experience" group. You would like to filters actions by users roles?

Categories filters are under development through an internship. Projects are filterable using the namespace filters, if the wiki has a proper namespace for wikiprojects; it doesn't seem to be the case of English Wikipedia. What do you mean by "contains search"?

Concerning the "filter matching" or "show matching" link, I'm not sure of what you mean. You want to have more information about a given link, that would show you the reasons why a particular diff matches the current filters? If that's it, you can test the system using the highlights. Here is an example on Recent Changes (the system is the same as on Watchlists) where you will see potentially problematic edits in highlighted red and orange and beginners contributions (newcomers and learners) in green and blue. Sometimes you will see some edits that trigger filters from the two groups, with, for instance, two dots (red + blue) and a mixed background color (and, possibly red+orange+another color).

I understand your concerns and I'm here to help you discovering the interface (hoping to doing that well). You don't sound negative at all; in fact I appreciate how you share your critiques constructively. :)

Reply to "I liked the only one."
Summary by Trizek (WMF)
CapnZapp (talkcontribs)

First off, now I can't even start a new talk page section without massive confusion!

Anyway. Where's the frequently asked question "HOW DO I MAKE IT STOP"

Even if the answer is only as below, you should include it. In fact, you should never have gone live without including it in the first place!

Q. How do I return to the old watchpage? A. You can't. We've decided what's best for you. Have a nice day.

Matěj Suchánek (talkcontribs)
Trizek (WMF) (talkcontribs)
Screenshot of the opting-out popup for filters for Watchlists

When you had first access the watchlist, you had that pop-up offering you to opt-out. If not, I'm sorry about the inconvenience, but you may have a script or a gadget conflicting with that notice (and probably other stable tools).

In any case, there is an option in your preferences, Matěj gave you the link.

CapnZapp (talkcontribs)

I went here immediately, since the optout popup is hidden behind the first.

In the future, please consider adding a "Get me outta here/Bring everything back as it was" button already to the first popup.

Btw, how do I get back to the regular talk pages? (Suspecting each wiki has its own setting; please add "luddite" option to globally make any and all new developments opt-in) CapnZapp (talk) 10:42, 17 July 2018 (UTC)

Trizek (WMF) (talkcontribs)

Have the opt-ing out button on the first pop-up is definitely a lesson learnt.

Concerning the talk pages, all talk pages are using Structured discussions on You can't opt them out. (And you don't need to sign anymore.)

CapnZapp (talkcontribs)

The amount of white space is blinding. I realize this is not the place, but please tell the "structured" devs to add a "condense" option so less screen estate is wasted. Please don't "beginnerify" Wikipedia (or rather, do, but for new users)

Having to sign is obviously something I can live without, though.

Trizek (WMF) (talkcontribs)

Have a more dense version of structured discussions has already been asked. But for now the development is stalled.

CapnZapp (talkcontribs)

Sorry that is unacceptable - I call that hit and run development. Revert back the introduction of new features if the programmers are unavailable right after release to polish their new stuff properly, that should lit a fire under their collective arses.

CapnZapp (talkcontribs)

Testing - does this create an indent?

CapnZapp (talkcontribs)

What the frak - if discussions are now linear only with no indentation levels, all hope is lost.

CapnZapp (talkcontribs)

Please direct me to the proper feedback/discuss page of "structured" talk pages, so I can give my mind to those responsible: leaving development in this shape is unacceptable.

Trizek (WMF) (talkcontribs)
CapnZapp (talkcontribs)

"learn more about indentations" - why not simply say "indentation is not supported"? That page says "you don't need to indent anylonger" as if that's a good thing?! No wonder English Wikipedia rejected this mess. Luckily I'm not a frequent contributor to mediawiki, so I leave it to others to battle down this misguided and overwrought mess. The simple truth is that the Flow Project should have been shut down entirely; its team members dispersed over many other projects so their collective will is broken. It's not unheard of for smaller communities like this one to be usurped by a fanatical core of devs who ignore common sense arguments, and I will certainly not waste anymore effort here. For your sakes, I hope the flow programmers are ousted sooner than later. Signing off (because I want to), yours truly CapnZapp (talk) 09:44, 18 July 2018 (UTC)

Trizek (WMF) (talkcontribs)

I hope that next time the discussion would be more open and pleasant.