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

Issue:

The new interface contains a lot of duplication and needless labels that make it feel like a huge change, and in some ways make it worse than the older one.

Concrete problems:

1. Related filters can be added in any order
2. Tags have no link to their description page - some tags are random things like "wp"
3. No easy way to exclude categories of namespaces, e.g. Content namespaces, Discussion namespaces, Project related namespaces (Project: , Help:)
4. All tags are not created equally, some tags are more useful than others

Proposed solutions:

1. Group related filters in the active filters area , e.g. user groups "learner", "experienced", "wikidata" instead of something like "learner", "wikidata", experienced". Maybe give them similar symbols to show their grouping.
2. Some tags have bad descriptions and names. It is a good idea to always add a link to the tag pages encouraging admins to add more useful descriptions.
3. Extra options in the namespace to select or deselect these
4. Tags defined by software that detect possible vandalism (e.g. page blanking) should be prominent (recommended) and separate from the clutter.

While registered users may have saved filters, unregistered users shouldn't need to know the secret handshake to find out what content namespaces are (they vary from wiki to wiki) or use cumbersome workarounds to hide all discussions (multiple clicks), if they wish to focus on main namespaces.

It is obvious that the design won't change to take all these suggestions into account, but hopefully something here will be considered and improved.

Re. problem #2, good point. We'd intended to include a link to Help docs for this, but needed to update the Help links first. That is done now, so I've filed this task.

Tracked in Phabricator
Task T176661

Thanks also for the rest of your thoughtful analysis. I'm bringing in our designer, @Pginer-WMF: who will I'm sure be interested.

Meanwhile, re. your comment that some tags are more useful than others, I will just mention that we'd wanted to list tags in the menu by order of popularity, with the most used tags at top (as can be done on the Special:Tags page). But this was not feasible (I can't remember why exactly but I think fetching the data caused an unacceptable delay). I like the idea in principle of organizing the tags by category, but since tags vary from wiki to wiki, I'm not sure how this would be accomplished short of a real rethinking of the whole system.

I'm not sure I fully understand your idea to combine Namespace and Tag functionality. Can you say more?

Oh, there are two types of tags. Those defined on wiki by users (e.g. "OAuth CID: 159", "Possibly unreferenced material by new user") and those defined by developers in extensions or mediawiki itself (e.g. visualeditor, mobile edit, massmessage , contentmodelchange) .

The suggestion is that those defined by developers should be grouped separately from the others (these are hardcoded somewhere in mediawiki / extensions), e.g.:

Suggested
contentmodelchange
massmessage
mobile edit
visualeditor
Other (defined by admins)
OAuth CID: 60
Possibly unreferenced material by new user

It is not a perfect solution, but it is better than the alphabetical non-descriptive approach. Long term it might be better to have tag types (content based, discussion based, vandalism, informative), but in the short term listing them separately is pretty good. I'm sure that admins will quickly design a hack that puts the more useful tags prominently, e.g. "1 Important edit , 2 Vandalism 3 Check this quickly" or alternatively "[Vandalism] deleted references , [Vandalism] Added fake references, [Informative] - new editor added image to template". This will likely happen if these tags remain sorted alphabetically.

Oh, the namespace thing is separate, e.g. the current workflow if someone wants to see all changes in that don't involve discussions is to:

• Click the dropdown for namespaces
• Click 10 times on subject namespace checkboxes (one by one)

Instead of just

• Click checkbox "Subject namespaces only"

If someone wants to see recent changes from content namespaces, e.g. in mediawiki.org these are wgContentNamespaces ( a javascript variable) - help:, extension:, manual:, etc. They need to actually guess or know that, rather than simply clicking a checkbox that will select all of the above.

It might also be a good idea to prune (delete or deactivate) some of those software defined ones, for example, the HHVM tag was probably useful some years ago. But nowadays it is pointless, and simply times out: https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&tagfilter=HHVM.

A short term alternative to selecting some tags or namespaces other than Topic:Tynjkxyjz21aucvx , might be implementing buttons (none / all) similar to the search page: Special:Search&profile=advanced&search=&fulltext=1.

Thanks for the feedback. It is definitely useful, and I appreciate that you included both a description of the problem and proposed solutions. Some comments about the specific feedback:

1) Keeping the added filters in their order of definition (instead of the order in which they are added) could help to better understand which filters are applied. We need to check that the expectation of getting new things added to the end of the list is not too strong in this case to cause problems if we break that pattern. I think the general understanding on which kind of results are displayed already improved based on the previous state (where users had to infer it from a set of "hide X"/ "show X" links), but your suggestion seems worth considering to improve this further (I created a ticket to capture the idea).

2) As Joe mentioned, we have some pending work to provide access to more information on tags. More on tags below.

3) Regarding the namespaces groups, that is very interesting. If I understand this correctly, this is something that could not be done with the previous version of the tool either. For some of the tool we planned to provide initial backwards compatibility, and based on the use and feedback iterate further. Knowing that certain namespaces may be selected together is definitely useful to consider future options to facilitate such selections.

4) We wanted tags to be more explorable, but we are also considering it iteratively. Starting by exposing the list of tags allows users to get the full list (as they could do by going to a separate page before), we could make them more visible and encourage people to provide better names and descriptions for them. Being able to group them into logical groups would be ideal, and the initial grouping you proposed seems a good initial approach until there is a way to define groups for related tags.

Regarding the support for anonymous users, the filter status is reflected in the URL so keeping it could be used as a replacement of the "saved filters" feature. This still requires some extra work from your side, but it may help until some of the improvements are supported.

Thanks!

> I think the general understanding on which kind of results are displayed already improved based on the previous state (where users had to infer it from a set of "hide X"/ "show X" links)

Yes, it improved in most cases. Although, with complex filters it has considerably increase the cognitive load. It also didn't change the fact that the user is still not truly aware when the results are not filtered at all, especially now that more filters can cancel each other out.

It might be a good idea to have a simple message that indicates when the results include all entries, e.g when filters cancel each other out.

>  Regarding the namespaces groups, that is very interesting. If I understand this correctly, this is something that could not be done with the previous version of the tool either.

It is possible to select all namespaces using the older user interface. There is also already small paired groupings of "associated namespaces". So selecting "Talk" will automatically include changes from (Main). It didn't include groupings such as "content namespaces", but it is trivial to do so by changing the URL.

> Regarding the support for anonymous users, the filter status is reflected in the URL so keeping it could be used as a replacement of the "saved filters" feature.

Yes, bookmarks help here. Though they don't help identify the current content namespaces.