Page MenuHomePhabricator

Explore designs for including filtering for users, edit tags, and namespaces
Closed, ResolvedPublic

Description

As we apply the new filtering system to more pages such as the Watchlist and User Contributions (T145155) we may want to better integrate some of the more complex filters such as filtering by a specific user, edit tags and namespaces.

The complexity of those filters is due to a combination of:

  • A search space too large. Listing all users in the single list is not feasible. Even a shorter list such as edit tags or namespaces could unbalance the original filter list if they were aded just as another section.
  • Additional options are required. Namespaces present some particular relations between the options. Editing tags cannot be presented inside a single group if the expectation is for them to be combined with an AND.

In this context, we probably should aim for a solution that:

  • Integrates with the current system to avoid unnecessary duplication.
  • Provides specific aids for the particular needs of each of those filters.
  • Is scalable: allows to be expanded with more similar filters in the future.

Proposed solution

We can apply the following ideas to support each of the complex filters:

  • A specific entry point is provided for users to add the new filters. For example, there will be an "add user" action to add a new filter to view contributions of a given user. Clicking on it will lead you to the process of adding such filter.
  • The active filter area will be reused. Complex filters will appear as tags when they are active in the same way as the regular filters do.
  • The search bar will be reused with support for special prefixes. Users can search in the same search bar for regular and complex filters. However, complex filters require a specific prefix: @ for users, # for tags and : for namespaces. These prefixes can be added manually by the users or as a result of clicking on the specific entry points. The entry points will include tooltips where the prefixes will be mentioned, to help establish the connection.
  • The filter panel will transform to accommodate the particular needs. For example when the user search for an edit tag (either by typing "#" in the search bar or clicking on the "add tag" button), a specific panel showing the list of tags will be shown.
  • The filter panel will include a footer with access to the specialised filters. In addition to the dedicated entry points, at the end of the list of regular filters, access to additional filters will be provided as a continuation for the user.

Some mockups to illustrate the idea:

Filtering for specific users

An entry point is provided to add specific usersA specific panel for user addition shows relevant results to facilitate the selection (e.g., users the current user interacted with recently).Typing the user can look for a specific user.Filtering for a specific user adds the corresponding tag with the rest.When closing the panel, prefixes are cleared for the regular panel to be shown by default the next time.

Filtering for edit tags

The edit tags can be added by selecting the "add tag" action, or starting a search with "#"The list of tags are shown in the panel.Selecting tags shows edits having all of them (they are AND-ed)When more than one edit tag is selected for filtering, a message is shown at the panel to communicate how tags are combined.

Filtering for namespaces

An entry point is provided to limit the namespace for which contributions are displayed.Namespaces are grouped by their associated pairs. Selecting multiple namespaces will provide the results in any of them (since an edit can only be part of one namespace).Additional "exclude" options are provided to facilitate the excluding a namespace without having to add all other namespaces (crowding the list of tags).When a namespace is excluded, filters in the list look greyed-out and show an "excluded" label, their tag also includes an indicator (notice the "not") to communicate that the criteria is reversed.

Additional entry point at the filter panel


At the end of the filter panel, the advanced filters can be provided as an option to find more options for those interested in additional filters. It cannot be considered as a main entry point (since it is at the end of a long list), but can be useful for those exploring all existing options.

Related Objects

Event Timeline

I like the direction you're going here. If I understand correctly, the User, Namespace and Tags buttons produce special-purpose menus (i.e., these lists are not part of the existing filter dropdown). I think that is better than adding these into the filter panel.

Here are some initial thoughts plus one big question: how do these new filters fit into the existing AND/OR scheme? What logic is appropriate?

Namespace

Logically, namespaces want to be a "group" in our current scheme—meaning that they'll relate to one another via OR but to other groups via AND, This is logical because a change can be only in one namespace (with one minor exception). So,

Adding something from the Namespace "group" restricts the search (AND). But adding multiple namespaces broadens it (OR)--meaning you're saying something like: Search = (filter a1 OR filter a2) AND (filter b1 OR filter b2) AND (namespace1 OR namespace2)

I think this feels relatively logical.

Exclude
The Exclude button seems like a necessary tool here--it basically handles the current "Invert" functionality. Having to select something and then exclude it seems awkward. I suppose the alternative might be a "select all" button, but I'm not in love with at.... Also, I'm not sure how the Exclude button interacts with the Highlight tools.

Tags

These are a bit different from Namespace, since it seems equally probable that users would want to combine tags to narrow a search (AND) as it is that they would want to gang them up to broaden the search (OR). Enabling users to combine tags with AND would require a new interface--i.e., I don't think we can make the interface look the same but act differently.

However, Roan says that combining tags via OR would be a lot simpler on the back end. And since people never had the ability to have multiple tags at all before -- OR or AND -- then it's already better than what they had, so it's probably OK.

Users

Interesting, but what is the use case here? I know we have been leery in the past of functions that would enable stalking...

I like the direction you're going here. If I understand correctly, the User, Namespace and Tags buttons produce special-purpose menus (i.e., these lists are not part of the existing filter dropdown). I think that is better than adding these into the filter panel.

Yes they have special-purpose menus. Content is not mixed with the default one. However, the menus should feel more like a single menu that adapts to the context since the user can go back and forth though them using the prefixes.

Here are some initial thoughts plus one big question: how do these new filters fit into the existing AND/OR scheme? What logic is appropriate?

Namespace

Logically, namespaces want to be a "group" in our current scheme—meaning that they'll relate to one another via OR but to other groups via AND, This is logical because a change can be only in one namespace (with one minor exception). So,
...
I think this feels relatively logical.

Yes, makes sense.

Exclude
The Exclude button seems like a necessary tool here--it basically handles the current "Invert" functionality. Having to select something and then exclude it seems awkward. I suppose the alternative might be a "select all" button, but I'm not in love with at.... Also, I'm not sure how the Exclude button interacts with the Highlight tools.

The note I added at the end of the description is related to this. We need to know better what can be done technically about filtering namespaces. Is it possible to select 3 different namespaces (e.g., Talk, User, and File)? If the answer is no, it won't be possible to exclude an option by selecting the rest since selecting more than one option will be restricted.

In summary: the UI for the namespaces needs more work, and we need to figure out if the current options in the Recent Changes UI represent all that it is possible or we have more freedom to focus the selection in a different way.

Tags

These are a bit different from Namespace, since it seems equally probable that users would want to combine tags to narrow a search (AND) as it is that they would want to gang them up to broaden the search (OR). Enabling users to combine tags with AND would require a new interface--i.e., I don't think we can make the interface look the same but act differently.
However, Roan says that combining tags via OR would be a lot simpler on the back end. And since people never had the ability to have multiple tags at all before -- OR or AND -- then it's already better than what they had, so it's probably OK.

I think the most likely expectation is for them to be combined with an AND since they correspond to a mis of different criteria. If someone selects "Mobile edits" and "possible vandalism", I think the user would be looking for vandalism on mobile edits rather than all vandalism and all mobile edits.
There are tags that belong to the same group (mobile vs desktop), where AND leads to no results, but you always have the alternative of applying tags one at a time. We can consider grouping the tags in groups that make sense, but since those are added by individual extensions, it does not seem a simple task.

Users

Interesting, but what is the use case here? I know we have been leery in the past of functions that would enable stalking...

In T159444 I identified that this functionality is part of the Contributions page (for example you can check the recent contributions of Jimmy Wales). So the goal is to be able to use the new filter systems in that page with feature parity.

Users

Interesting, but what is the use case here? I know we have been leery in the past of functions that would enable stalking...

In T159444 I identified that this functionality is part of the Contributions page (for example you can check the recent contributions of Jimmy Wales). So the goal is to be able to use the new filter systems in that page with feature parity.

Plus, this is not going further than what people have already access to concerning other's contributions.

I like the direction we are taking here, too!

Pginer-WMF updated the task description. (Show Details)Apr 18 2017, 11:43 AM
Pginer-WMF updated the task description. (Show Details)Apr 18 2017, 11:51 AM
Pginer-WMF updated the task description. (Show Details)Apr 18 2017, 11:59 AM
Pginer-WMF updated the task description. (Show Details)Apr 18 2017, 12:12 PM
Pginer-WMF updated the task description. (Show Details)
Pginer-WMF updated the task description. (Show Details)
Pginer-WMF updated the task description. (Show Details)Apr 20 2017, 11:21 AM
Pginer-WMF updated the task description. (Show Details)Apr 20 2017, 1:24 PM

About the exclude button: I think we should have a single "exclude" button for the entire namespace dropdown, not per namespace.

The reason for this is that mixed settings (a mix of "include A, B, C" and "exclude X, Y, Z") don't make sense and are always redundant. For example, if I select "User" and "User talk" and "not Template", I either mean "only list User and User talk" (but then "not Template" is redundant), or I mean "show me everything except Template" (but then including User and User talk is redundant). If mixed settings never make sense, then the only kinds of settings that do make sense are settings that consists only of inclusions or only of exclusions. So the only degrees of freedom you have are 1) selecting which namespaces and 2) choosing whether you are including or excluding. If you can't make different choices about include/exclude on a per-namespace basis, then IMO there should not be per-namespace buttons.

I had semi-realized this earlier, and this is kind of what I was trying to get at during the discussion meeting today, but I had forgotten the details which is why I wasn't making any sense this morning, I hadn't quite understood it myself yet. Moriel and I then realized this when discussing implementation strategies later in the day.

Change 350114 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core@master] RCFilters: OOUI'fy the namespace widget

https://gerrit.wikimedia.org/r/350114

About the exclude button: I think we should have a single "exclude" button for the entire namespace dropdown, not per namespace.
The reason for this is that mixed settings (a mix of "include A, B, C" and "exclude X, Y, Z") don't make sense and are always redundant.

Your analysis is correct. As soon as there are individual namespaces excluded, the rest of the included namespaces become redundant. However, it is not clear whether that prevents the user from getting the results she was looking for (i.e., there is no contradiction).

In any case, I think it makes sense to try to reduce the options provided to those that are truly relevant, and I agree that a global option at the panel level could work. The mockups below illustrate the approach:

Thoughts?

Change 350114 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core@master] RCFilters: OOUI'fy the namespace widget
https://gerrit.wikimedia.org/r/350114

@Mooeypoo, since this ticket is very general, would it be possible for you to create sub-tickets capturing the specific aspects that code changes intend to support. Otherwise it may be unclear for QA or anyone checking the general ticket to know whether the associated patchsets are intended to do what the ticket says. I think breaking this into sub-tickets with smaller scope would be useful in general.

Mooeypoo added a comment.EditedApr 25 2017, 5:18 PM

@Mooeypoo, since this ticket is very general, would it be possible for you to create sub-tickets capturing the specific aspects that code changes intend to support. Otherwise it may be unclear for QA or anyone checking the general ticket to know whether the associated patchsets are intended to do what the ticket says. I think breaking this into sub-tickets with smaller scope would be useful in general.

Yes, I opened a child task: T163521: Replace "Namespace" widget in RCFilters with a user-friendly OOUI version

The commit is connected to both tasks - one is the implementation task, and the other has the design features, so it seemed to make sense. I can remove the link to the parent if it's confusing, though.

Change 350268 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core@master] RCFilters UI: Create base classes for shared objects

https://gerrit.wikimedia.org/r/350268

Change 350268 merged by jenkins-bot:
[mediawiki/core@master] RCFilters UI: Create base classes for shared objects

https://gerrit.wikimedia.org/r/350268

Yes, I opened a child task: T163521: Replace "Namespace" widget in RCFilters with a user-friendly OOUI version
The commit is connected to both tasks - one is the implementation task, and the other has the design features, so it seemed to make sense. I can remove the link to the parent if it's confusing, though.

My bad, I missed that one. Thanks for pointing to it!

Quiddity removed a subscriber: Quiddity.May 5 2017, 7:39 PM

Change 350114 abandoned by Mooeypoo:
[wip] Add namespaces to RCFilters

Reason:
Implemented in I7e83f0800

https://gerrit.wikimedia.org/r/350114

Pginer-WMF updated the task description. (Show Details)May 17 2017, 11:02 AM
Pginer-WMF updated the task description. (Show Details)May 17 2017, 11:20 AM

Change 353201 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] [wip] RCFilters: Add 'views' concept and a namespace view to RCFilters

https://gerrit.wikimedia.org/r/353201

At the moment, it is possible to filter selected namespace, or to exclude selected namespaces. I have a request to exclude edits made by a particular user, for example not Ludmilla on F7608430.

At the moment, it is possible to filter selected namespace, or to exclude selected namespaces. I have a request to exclude edits made by a particular user, for example not Ludmilla on F7608430.

It would be interesting to hear more about the purpose behind that. For example, if the request is motivated by filtering out "trusted users", it may be better to approach it by creating a specific filter for that user category rather than making editors to exclude users individually. If the purpose is completely different, maybe another solution (including individual user exclusions among the possibilities) may be better suited.

Trizek-WMF added a comment.EditedMay 29 2017, 12:25 PM

I see you have asked directly.

I see some cases:

  • mathematically, there is more users you don't trust than you trust - no matter what is their experience. Exclude users that you trust is easier to do than exclude users you don't trust (the universe minus a few)
  • you don't want to see some edits made by a particular user, because you know you don't appreciate this user edits or you already know this user edits (I have the case when I see in my watchlist edits made by Trizek (WMF) when I'm logged in as Trizek).
  • a user has started an automated process without a bot flag and is polluting a list of results with regular new updates and you want to exclude him temporary from the RC page

Change 356056 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] [wip] RCFilters: Add edit tags drop down

https://gerrit.wikimedia.org/r/356056

jmatazzoni renamed this task from Support filtering for users, edit tags, and namespaces to Explore designs for including filtering for users, edit tags, and namespaces.Jun 2 2017, 7:23 PM

This is a general design task. I'm going to declare it done, and open up separate tasks for these jobs. That way we can start afresh with the new designs that Pau is working on.

jmatazzoni closed this task as Resolved.Jun 2 2017, 8:24 PM

Change 353201 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Add 'views' concept and a namespace view to RCFilters

https://gerrit.wikimedia.org/r/353201

Change 356056 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Add edit tags drop down

https://gerrit.wikimedia.org/r/356056