I captured some ideas to improve the filtering mechanism on Recent changes in the mockup below:

M184 Recent changes filtering

113

Looks good. What do you think the "Add filter" interaction should look like?

One concern I have is that this will shake up a lot of people who have been using Special:RecentChanges. Do you think it would be crazy to allow a user to toggle between the filtering UIs?

In T142785#2579178, @Halfak wrote:

Looks good. What do you think the "Add filter" interaction should look like?

The mockup includes several images to illustrate that (but Phabricator UI does not make that very clear). You can check this slide deck with a more detailed step-by-step walkthrough.

I'll provide a more detailed spec in Phabricator if this seems a promising direction to go.

One concern I have is that this will shake up a lot of people who have been using Special:RecentChanges. Do you think it would be crazy to allow a user to toggle between the filtering UIs?

Given that Recent Changes is as popular as Batman, I'd consider exposing the changes as a beta feature so that users can gradually get used to it (and surface the cases where it does not work as expected).

I also tried to restrict the changes only to the filtering system, avoiding changes in the list that users optimised their eyes to process. I really think that the current filtering model based on explicit "show X, hide Y" is not scalable and requires effort to even understand what is being filtered: you need to infer the status ("Wikidata itms hidden by default") from the action ("Show Wikidata"). So, I see no reason to keep the current approach as an alternative in the long term (especially if new kinds of filters are made available), but I'm open to hear reasons to do so during the beta stage.

Thinking about it, the beta feature strategy seems good. We already do have "Enhanced RecentChanges", so there's already a toggle in preferences that substantially changes the UI. I'm not sure we should add a third mode there. I do like the Transition-From-Beta-Feature plan.

hey @Pginer-WMF, we're working on an even more basic integration of "good-faith" into recent changes for MediaWiki-extensions-ORES. See T137966. Would you be able to spare some cycles to help us imagine a good way to signal good-faith and damaging independently? We're hoping to find something that would be easy to implement since we don't have much engineering time to dedicate to fixing the filters (as you have proposed here) on the #revision-scoring-as-a-service team.

In T142785#2582522, @Halfak wrote:

hey @Pginer-WMF, we're working on an even more basic integration of "good-faith" into recent changes for MediaWiki-extensions-ORES. See T137966. Would you be able to spare some cycles to help us imagine a good way to signal good-faith and damaging independently? We're hoping to find something that would be easy to implement since we don't have much engineering time to dedicate to fixing the filters (as you have proposed here) on the #revision-scoring-as-a-service team.

I'd be happy to help. Even if we aim for a long-term integration of filters, it makes sense to define simpler initial steps. I'll share some possible directions below, but first wanted to share some of my assumptions during the exploration:

• Filter vs. highlight. I think it makes sense to support both, (a) the ability for users to focus on a specific sub-set of contributions (e.g., supported by filtering), and (b) the ability of users to add an extra signal when processing a more general list of contributions (e.g., supported by highlighting some contributions without hiding the rest). While I think it makes sense to support both, I'm not sure on which of them should we prioritise, and a better understanding on how users process the list of contributions and use these layers of information would be helpful.
• Support multiple criteria. Even if we want to start by supporting ORES-based criteria, our solution should be able to integrate additional criteria. This avoids one-off solutions that clutter the interface as more criteria will be added and encourages users to combine multiple criteria in a simple way to focus on the changes of their interest (e.g., damaging by newcomers made in good-faith by newcomers on rock music articles).
• Changing significantly the way contributions are displayed is out of scope. Users are used to scanning the list of contributions. Experimenting on that area may require focused research on the different usecases supported by those listings. In the current exploration we are considering enhancing the information without deviating from the current text-based patterns used for the list.

Considering the above I captured two different directions below. Let me know if they seem to work well for the scenarios you had in mind.

Quality filter
as an initial step towards the idea of unifying the different filters, we can start by providing a simpler quality filter.

The selector can be a simple list and may provide aids to select options easily (auto-completion, adding multiple results as capsules/tags with options to remove them) or start as a simpler selector.

This will support the filtering case, and further steps could add support for highlighting the selected criteria as well as integrating more filter options through the same entry point.

Highlight controls
An alternative is to start with highlighting. We can provide a control for users to indicate how the items in the list can be highlighted. The idea is to allow users to indicate which criteria to use for each of the possible features of list items that can be highlighted.

In the example, users can decide how to highlight the whole row, the bullet next to it and the username of the author of the contribution. For each of these, users can select a criteria. Each criteria can highlight matching items in one or more colors (if the criteria requires highlighting different levels).
For example, the user can decide to highlight rows for good-faith edits (shown as green rows in the example) and use the bullets to highlight the damaging ones (showing the most likely damaging edits in red and those probably damaging in orange, while the rest of bullets are de-emphasised in grey).

@Pginer-WMF and @Halfak, I wanted to make sure you spotted that I'd collapsed a number of tickets that addressed this issue (listed immediately above) and rewritten the Description. I merged these partly because I made one dupe by accident and partly because this task got a little simpler when we decided to postpone contemplation, for the moment, of the special page we'd been talking about.

So now this task is both broader and narrower: broader because it's about three features instead of just one. But narrower because we're just focusing on Special:Recent Changes.

Also, we now have a better sense of the way forward for the RC page. Which is, from Monday's ERI meeting notes:

Update filter design: adopt Pau’s proposal for improving RC Page filtering tools generally, but in an incremental way. Incremental, meaning we provide improved tools only for the ERI filters at first. Lots of advantages:

• Because RC Page is a central tool and needs to be managed carefully, revamping the entire filtering system at once would require extensive design work and research.
• By going incrementally we get good feedback to make a transition to an all-new system like the one Pau proposes.

@Pginer-WMF, in meeting the other day we talked about the desirability of adding these changes to the Watchlist page and, probably, the Contributions page as well. There are two aspects to this:

• Add the ORES data display
• Add the filter panel.

Does it make sense to make these pages part of your design process? Or should that be a separate task do you think? And possibly in a later phase?

In T142785#2600021, @jmatazzoni wrote:

@Pginer-WMF, in meeting the other day we talked about the desirability of adding these changes to the Watchlist page and, probably, the Contributions page as well. There are two aspects to this:

• Add the ORES data display
• Add the filter panel.

Does it make sense to make these pages part of your design process? Or should that be a separate task do you think? And possibly in a later phase?

In general, I'd go one at a time. Although all these pages use asimilar filtering mechanisms and technically it may be easy to propagate the changes everywhere, they also support different usecases and they are used by different groups of people. Making sure we solve well the case of the recent Changes page first, and then move to the next place seems the right way to go in my opinion. The more focused and specific the ticket, the better.

In terms of design, it is ok to move some steps ahead and explore how the system would work in those pages. But I'd consider having separate tickets to be able to decide when to focus on what.

This prototype illustrates the idea of providing better filtering on the Recent Changes page. It is still in progress (notice pieces missing compared to the designs for the reference scenarios.