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

Issue:

There is not enough information to know if the changed filters provide new results.

Concrete issues:

1. The new result set may contain new entries but it might not be obvious
2. No clear way to know how many of the filters groupings actually matched
3. The relationship between the filters is not clear in the "Active filter area" - Sometimes the relationship between filters is OR and sometimes it is AND.

Proposed solutions:

1. Add a clear count of total returned entries
2. Possibly add a sub-count of the specific filters - as this seems to be in the actual html of the returned results, it should be possible to retrieve these, e.g. 5 edits (registered), 3 deletions, etc.

Number 3 is kind of tricky, maybe this :

3. Add a word or sign to indicate the relationship between the results , e.g. Anonymous AND New pages OR Logs . Alternatively maybe something like "Anonymous" & "New pages" / "Logs"

The problem of course is that recent changes is a moving target. So it is not clear if the current result set is the same or changed. More often than not it is changed by the time someone adds new filters. A ranged datetime filter would probably reduce the uncertainty (https://phabricator.wikimedia.org/T162784#3330522).

As you say, the problem is that recent changes is a moving target. The most common use of RecentChanges is to get the last edits as they come. Display a result on a non filter by date page maybe confusing, no?

About the relations between filters, the pre-request is to have visible groups. I let @Pginer-WMF to have a look at this idea.

Not anymore confusing than not showing any visible sign that the filters actually matched something. Some of these filters use an OR relationship. So if someone looks for edits by anonymous OR Registered. A user can't be both, and the filter may have filtered results like "0 anonymous", "200 registered" edits.

Highlighting seems to solve the problem of identifying which filters matched the current results. Although it doesn't fix the problem of not knowing if the total results are as many as requested or expected.H

The current approach of of combining filters inside a group with "or" and those from different groups with "and" provide a good level of flexibility especially when the groups refer to very distinct aspects. For example, in an image search scenario looking "large medium red landscape" user expectation would be to find only red landscape images in either medium or large sizes. Exposing the underlying boolean logic directly may be more confusing than helpful.

In our particular case, groups are only reflected when the menu is expanded but not in the general view. We can explore ways to surface visually such groupings. Keeping the filters from the same group together could be a good initial step. We can also provide some visual separation between filters of different groups, but we need to be careful not to crowd the filters visually too much since the list of results are the main piece of information for the users to focus on.

Yes, crowding is certainly a problem. But there is a good reason why most reports (even hand written ones) have counts. It makes it possible for the user to verify the results. For example if someone created 100 pages within a month, and tries to search for this and only sees 20 results. Then either their memory is failing, the pages might have been deleted, or there was something wrong with the way the user defined the filters.

That is useful information to allow the user to correct the results and try again.