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

Everything is out of place and much more difficult to use and reach, notably the namespace list which passed from the easy dropdown list to a very buggy and user unfriendly radio button list. Much more slower than before as well, and the daunting button "mark everything as read" that I NEVER want to touch, bigger than ever. So horrible that I'm very - but very - happy to find that this is only a beta feature, and the watchlist nightmare I was sent in when somehow this hideous beta feature activated will be finally over.

Some potential with the namespace combinations, and the potential use of colours - but it's so difficult to reach and use that I'll deactivate this beta feature as soon as I get back to my home wiki. Please do not implement it as it is.

(BTW, I used to appreciate ORES, and I'm sad that I'll had to deactivate it because of the way the watchlist was completely wrecked and defaced by the recent "features". It became basically unusable. I'm VERY glad I could deactivate it, even having to say goodbye to ORES)

No worries, we will not implement it as it is. As you have noticed, it is a Beta feature so anyone can try it and tell us what needs to be fixed.

Please tells us what are the bugs you have encountered so we can fix them. What is the issue with the namespace filters, for instance?

I agree with DarwIn in the general impression, lots of potential but very problematic layout. The old interface provides instant access to the most common filters (hide bots, minor edits, show this or that namespace).

The new interface, besides being slow to load (and changing the page layout when it finish loading), only allows fast access to remove the active filters (which I will rarely want to do, as I expect the filters to be restored to the default state when I navigate away), not to activate them; inserting a filter requires opening a drop down, and navigating way down a long list with lots of scroll to find the category of filter I want to use; and Namespace filters are hidden beyond two layers of indirection.

The design of "Active filters" has been optimized for the less common case (disabling an active filter) and the interface is good for defining new filters or accessing the ones rarely used, but for it's not good for the main use, which is accessing the most frequent ones - which should be the primary action, and thus the one optimized for.

To match the functionality of the previous interface, the new tool should come with Saved filters pre-configured with the same filters available in the old one (in order to ease migration to the new tool), and the most common saved filters should be exposed flat with one-click buttons, not hidden under a drop down.

Do you know you can bookmark your favorite sets of filters and define one set as default? Also, have you tried to search filters using the search bar and the shortcuts for namespaces (they have a shortcut icon on the right side of the interface - assuming a LTR interface)?

Most common saved filters may vary between users. I don't know if we can track the most popular ones to define some shortcuts.

Do you know you can bookmark your favorite sets of filters and define one set as default?

Yes, but this doesn't solve the problem I described, which makes the new interface worse than the previous one for common usage. Saved filters are still under a drop-down menu, not exposed in plain sight in the default view like they do in the current interface.

Also, have you tried to search filters using the search bar and the shortcuts for namespaces

Yes, and it's way more inconvenient than having them exposed in plain sight in the default view like they do in the current interface (where they're available with just one click, without the need to reach for the keyboard). Also it's less discoverable - I need to recall the name of the filter, instead of recognizing it from the screen.

As I explained, searching solves the problem of defining new filters, but most of the time I will be re-using the same filters again and again, and the interface for bookmarks/saved filters is worse in this interface than the classic interface for available filters.

Most common saved filters may vary between users. I don't know if we can track the most popular ones to define some shortcuts.

That's not really needed. It's enough that you allow each user to put their own preferred bookmarks as buttons exposed by default - probably using an interaction similar to the one to "Set filter as default".

Hi @Diego Moya:. Thanks for going into detail; I know it's time consuming. You write that "I will be re-using the same filters again and again." Given that, I would think that the bookmarking/Saved Filters, and the ability to save one filter set as a Default that loads every time, would work well for you. What about that system is a problem for you?

Re. the interface, one thing you might not be factoring in is that a lot of new functionality has been added. This is the same interface (and toolset) as is being used on Recent Changes, for which it was primarily designed. But in time I think users will find a lot of it useful on Watchlist as well. The old interface simply could not accommodate all the new functionality; it wouldn't scale. So a new paradigm was needed.

Given that complexity, we understood that Saved Filters would be important. So I want to understand your issue.

Given that, I would think that the bookmarking/Saved Filters, and the ability to save one filter set as a Default that loads every time, would work well for you. What about that system that is a problem?

Well, as a feature set it more or less solves my case, although it forces me to jump through more hoops. The problem I have is with the interaction techniques used in the beta interface, which make my most frequent interactions much more cumbersome and less desirable than with the old interface. I've already explained my pain points in the previous posts, so I'll put them here in bullet points for reference:

• The saved filters/bookmarks are hidden behind a drop down control, so they require an extra click and scanning through a vertical list to find the filter I want to use. In the old interface, I can see all the common filters laid out in a horizontal table from the beginning, and I can activate any of them with just one click.
• The saved filters/bookmarks are hidden behind a drop down, so when the page finishes loading I can't see what filters are available; I need to start an interaction before the list of filters is shown. And there are three places where my desired filter may be hiding (Saved filters if it's a common one, search filters if it's not saved, "advanced" if it's a namespace), so I'm forced to remember which was the proper place to go and look for my common filter. In the old interface, I can instantly see whether my desired filter is there or not, without initiating any interaction.
• The Default filter is not enough. I want to change between four or five configurations quickly, not just one.
• The saved filters could work as long as I can force them to pile-up, combining two or more saved filters on the fly to create one configuration, just as I do now. In the beta, loading a saved filter replaces completely whatevdr filters are loaded in the current configuration, they can't be combined.

All these small paper cuts are mentally taxing and add up to an unpleasant experience for my most commonly used feature. This may be acceptable if you activate a filter or two every other day, but is too much grinding when activating a dozen or so of filter combinations in fast succession, several times a day, like I do.

An example of my routine could be, in a single session over the Watchlist: -show only articles, -show articles and their talk pages, -show only Wikipedia pages, -show Wikipedia pages and Wikipedia talk, -show only Wikipedia talk, -show Draft and Draft talk.

(If you couldn't follow all the above, I could record a short video of the routine for you).

But every day I may try them in any order, or create different combinations of these and other filters (at any step in the above routine, I could apply over the current filter: hide bots, hide minor edits, reverse the value of any filter...) I can do all the above in the current interface very fast, only with the mouse, with just one to three clicks per step, never reaching for the keyboard.

Every step might either add the new filter to the previous one - e.g. adding the "associated namespace", or remove the previous filter - first clearing all filters by re-entering the Watchlist.

Re. the interface, one thing you might not be factoring in is that a lot of new functionality has been added. This is the same interface (and toolset) as is being used on Recent Changes, for which it was primarily designed. But in time I think users will find a lot of it useful on Watchlist.

Oh, I don't doubt that, and of course I've been taking into account all the new functions (filters for problematic edits, applying color highlights, etc.). I'm not denying the utility of any of them; as I said above its great that you expand the possibilities of the tool, and I could put many of those features to good use. But the Recent changes doesn't include so many different namespaces, and it shows that the design was created for a simpler case.

Note that I'm not requesting that you remove any of the features in the new tool, so no need to be defensive; just make sure to also support what was possible in the old tool and it is still not included in the beta.

The old interface simply could not accommodate all the new functionality; it wouldn't scale. So a new paradigm was needed.

You're right about such need. But what I don't want in any way is that you take away the features and interactions that I use every day, dozens of times in a row, or that you make them slower and more cumbersome. A tool doing that could never be an improvement, no matter how many new features it provides.

More so when I HAVE SUGGESTED A POSSIBLE ADDITION THAT WOULD SUPPORT MY USE CASE IN THE NEW PARADIGM, and which is actually using the FEATURES THAT YOU HAVE ALREADY DEVELOPED, just adding a few new interactions to them. Just allow users to pin any filter to the screen, adding it to a quick launch pane ("Fast filters"?), where it can be activated with one click. This will go miles to help us, power users, to tweak the interface to our real needs. User-defined quick launchers are a true and tested classic interaction technique for adding flexibility to a tool.

After thinking about the problem a bit more, it wouldn't be enough to be able to pin the saved filters; I'd also need to pin any entry in the drop down list of filters and convert them into always-visible buttons. Pressing a pinned button should launch exactly the same command as selecting it from the drop down list; the fast filter would just remove the need to search for it in the drop downs every single time.

I'm even stronger: Horrible with no potential. Give us back the old layout of the watchlist!

@Ysogo:, you can get back the old Watchlist UX by just opting out of the New Filters for Edit Review beta on the Preferences>Beta page.

@JMatazzoni (WMF): I'm "experencied" enough to know how to switch on/off the beta functions. My feedback was intended to prevent that future investment on the evolution of the UI would be diverted only to this version. In my opinion it has totally missed a target audience, it is designed for newbies but is offering alternatives that requires long experience to be familiar with. Whatever before could be done in few clicks always having all info in front of you it is now nested in different places that you need to navigate loosing the birdeye view, I don'y think, as stated in the feature page, that this could not be accomodated into the old interface: it just required to change few radio-button into combo-boxes and adding a couple of criteria. End of the story: my suggestion is that rather than spending any other hour to solve issues of this new UX, it is better you spend them to add fetaures on the tradiitonal one.

Thanks for taking the time to explain your issues and for suggesting improvements @Diego Moya:. I'm going to ping designer @Pginer-WMF: to see if he has thoughts on these questions.

Hello Trizek, the namespaces are much easier to reach by the dropdown list, as it is now, than with the Beta radio button system. I found that new system useful to chose more than one namespace at a time, the color codes seem to have a lot of potential as well, and it would be really great if we could somehow chose general topics (nature, sports, history - maybe using categories) - But the dropdown list should be kept. It could even be improved, by adding the functionality of choosing more than one namespace to it (allow multiple choice).

Also, I can't fathom why the search box does not look in all available filter collections, instead requiring special syntax for namespaces and tagged edits. This means that if I type "visual" or "draft" or "mobile" there will be "no filters found". This forces the user to know in advance they have to type "#visual", ":draft" or "#mobile" instead, providing no visual feedback that this is even a possibility.

I don't get the sillines of all this unneeded syntax; it's not like you have thousands of filters that would cause dozens of hits that required disambiguation into namespaces to avoid collisions. Even typing the common "user" keyword brings up no more than nine results (but not the one I most likely want, the User: namespace).