Page MenuHomePhabricator

Implement 'Category' filters and filter menu in the new UI
Open, Needs TriagePublic

Assigned To
None
Authored By
Pginer-WMF
Apr 20 2017, 11:13 AM
Referenced Files
F8412982: RC-cat-selected.png
Jun 8 2017, 1:40 PM
F8412970: RC-cat-empty.png
Jun 8 2017, 1:40 PM
F8399599: RC-cat-after.png
Jun 7 2017, 2:46 PM
F8399486: RC-cat-autocomplete.png
Jun 7 2017, 2:40 PM
F8399481: RC-cat.png
Jun 7 2017, 2:40 PM
F8399489: RC-cat-after.png
Jun 7 2017, 2:40 PM
F7663739: RC-advanced-filters-more-cat.png
Apr 20 2017, 11:13 AM
F7663949: RC-cat-autocomplete.png
Apr 20 2017, 11:13 AM
Tokens
"Doubloon" token, awarded by RandomDSdevel.

Description

Enabling users to filter by category will encourage and support the natural impulse people have to participate and organize around topics that interest them—and around particular workflows, which have used categories as a handy workaround for organizing their tasks.

The Category menu works the same as the main filter panel does--the same rollover, selection, close-menu, etc. behavior. Here are the Category filter-specific specs:

General Category menu functions

  • Selecting a category from the menu means that all edits made to articles and other pages in that category are shown in the Results area.
  • In terms of filtering logic, the entire Category menu is one filter "group." This means that when multiple categories are added to a search, each broadens the search, since all Category filters relate to one another via an OR.
  • In the Active Filter Display Area, Category names are prepended by a / in their respective Tag bubbles. E.g., /Legendary creatures.
  • Instruction text in the bottom of the panel reads: Search for any category by typing its name in the search bar, preceded by /.
  • A "?" icon (help link) leads users to an as yet unwritten Help page on using category filters.

Category search functions

  • When the Category menu is open, an / is displayed in the Search bar.
  • When a reviewer who hasn't used this tool comes to it for the first time, the system scans the user's Contributions and identifies 5 categories from the pages the user has edited most recently, excluding Hidden categories (harvesting from as few pages as are necessary to achieve 5). These categories are presented in the menu, in alphabetical order, under the heading "Categories of pages you recently edited."
    • If the reviewer has made no edits to page in categories, no categories are presented.
  • Reviewers can search for categories not on the "Recent categories you've edited" list by entering a category name in the search bar, prepended by /, like so /Legendary creatures.
  • As the reviewer types a category name, the system attempts to match it with category names in that wiki, showing the 10 closest matches, in alpha order, preceded by check boxes.
  • The reviewer can select a category by clicking its check box in the menu, or by hitting Return once a unique match has been achieved in the search bar.
  • The menu retains the 10 category names that the reviewer used most recently, gradually replacing prepopulated categories with categories the user actually searched for. These category names are listed in alphabetical order.
  • There is no Exclude mode for Category filters.

Mockups

Initial suggestionsSearch autocompletionCategory added
RC-cat.png (768×1 px, 220 KB)
RC-cat-autocomplete.png (768×1 px, 222 KB)
RC-cat-selected.png (768×1 px, 223 KB)
Initial suggestions (with previous selections)
RC-cat-after.png (768×1 px, 221 KB)
Initial suggestions empty
RC-cat-empty.png (768×1 px, 263 KB)

Related Objects

Event Timeline

This tool allows users to watch recent changes in a categories and its sub-categories.

I know there is a risk to have impossible to load results on categories with a complicated hierarchy, but have, at least, a way to search on 2 or 3 levels of depth for a given category may help patrollers a lot.

jmatazzoni renamed this task from Support filtering for categories in the new filters for edit review to Implement 'Category' filters and filter menu in the new UI.Jun 6 2017, 11:52 PM
jmatazzoni updated the task description. (Show Details)
jmatazzoni updated the task description. (Show Details)

@jmatazzoni I added some mockups in the description. Some comments below:

Instruction text in the bottom of the panel reads: Search for any category by typing its name in the search bar, preceded by /.

I updated the text but I wonder if the mention to ", preceded by /." may be interpreted by users to add an extra "/" or even "/."

When a reviewer who hasn't used this tool comes to it for the first time, the system scans the user's Contributions and identifies 5 categories from the pages the user has edited most recently (harvesting from as few pages as are necessary to achieve 5). These categories are presented in the menu, in alphabetical order, under the heading "Categories of articles you recently edited." @Pginer-WMF, Roan says this can be done relatively simply. Does this work for you?

The approach sounds good to me. Regarding the language, in the mockups I used "Categories of pages you recently edited.". Using "pages" is normally preferred over the Wikipedia-specific "articles" since it applies to more projects such as mediawiki.org.

If the reviewer has made no edits to page in categories, no categories are presented. @Pginer-WMF, please show a design of what this state looks like. Please note the updated search and label text used here.

For the case of editors with no edits to pages with categories, I was wondering if it is easy to obtain some more general categories. Some ideas (we just need to support one):

  • Recently edited categories by the community. Based on the list of recent changes (either applying the user selected filters or not) a few categories may be extracted from the results. This would be a natural generalisation of the proposed approach: if there are not recently edited categories by the user, look as those edited by others.
  • Top categories. Based on main topic classification or similar we may be able to present some of the top categories people may expect by default (arts, science, etc.). Here the challenge may be to obtain the equivalent categories for different wikis and languages.
  • Trending categories. I think there is an API to get trending pages based on the number of views, maybe we can extract their categories as a fallback.

If there is no reliable fallback approach we can think on providing an empty state. Based on this, I'll update the remaining mockup.

I know there is a risk to have impossible to load results on categories with a complicated hierarchy, but have, at least, a way to search on 2 or 3 levels of depth for a given category may help patrollers a lot.

I was going to say this is impossible, but @Trizek-WMF is correct that this would be very beneficial, so i'll ask. @Catrope, is it feasible to define a function that might crawl down one or two levels from the level named?

I know there is a risk to have impossible to load results on categories with a complicated hierarchy, but have, at least, a way to search on 2 or 3 levels of depth for a given category may help patrollers a lot.

I was going to say this is impossible, but @Trizek-WMF is correct that this would be very beneficial, so i'll ask. @Catrope, is it feasible to define a function that might crawl down one or two levels from the level named?

There is this tool on Labs that I've already mentioned. It allows RCs display for a given category and 10 sub-levels, but it only does that, nothing more.

Have at 3 sub-levels would help and be enough for most cases.

@Pginer-WMF thanks for your suggestions on ways to prepopulate the categories for users who somehow haven't edited anything. I think you're right that this is better than showing nothing. If I understand the intention of the feature, it is to give users an idea of what categories are and to, perhaps, interest them in Category search. Your idea of using Top Categories is a logical one, except that it runs into the tragic flaw of categories overall: the top categories, which should contain the most articles, actually contain no articles but only other categories.

But I think we can approximate the idea. I propose we pick some representative general areas, like Arts, Science, History, etc. Then crawl down the category trees until we get to a level where the categories do have articles ("19th Century painters," "Women scientists" "Articles that need copyediting") and use those as a default sample list. These will be labeled "A selection of sample subject categories."

In fact, if you like this idea, we could save ourselves the whole project of doing the scan of user contributions. It's just a fancier way of finding a probably random list (from most users' POV) of categories. In most cases, it won't actually produce a list that is meaningful to the user. Or we could do both...

(The other ideas seem too complicated to arrive at lists that will feel and be pretty random in most cases, I think.)

But I think we can approximate the idea. I propose we pick some representative general areas, like Arts, Science, History, etc.

The problem of hand-picking is that this may work for Wikipedia, but Recent Changes is also available on other wikis such as mediawiki for which we'd have to provide a fallback approach anyways (since there is no "Art" category there). This is the "challenge" I was referring to in my comment. If we don't find a general way for a wiki to tell us which are their top categories, we could only address the issue for some projects and need to provide a general fallback approach for the rest.

@Pginer-WMF wrote:

The problem of hand-picking is that this may work for Wikipedia, but Recent Changes is also available on other wikis

Ah, right. I talked to James and Roan, and they tried a few things but couldn't think of a good general solution for this. This is such an edge case, I think we should just create a design for the empty scenario and move on. (I mean, in general, what RC page user will have no edits with categories to look at? New users, mostly. It might be that this feature is not really for them anyway.)

@Pginer-WMF wrote:

The problem of hand-picking is that this may work for Wikipedia, but Recent Changes is also available on other wikis

Ah, right. I talked to James and Roan, and they tried a few things but couldn't think of a good general solution for this. This is such an edge case, I think we should just create a design for the empty scenario and move on. (I mean, in general, what RC page user will have no edits with categories to look at? New users, mostly. It might be that this feature is not really for them anyway.)

Makes sense. I added an empty state example to the description.

@Hagarshilo and @Mooeypoo, it looks like you didn't see this ticket. Or anyway, it wasn't connected to your proposal. So I added T190714 as a parent. This is good news: it turns out we worked out the interface for Category filters more than I had remembered.

This task will not be done as part of GSoC after all; during development, it became clear that the development of a new asynchronous operation inside RCFilters is more complex than we'd realized, and would not fit in the scope of a GSoC summer project. Please see the update on the GSoC proposal task for more information.

As for this specific feature -- I have a work in progress that might get us closer to get the behavior going, which I will connect to this ticket soon. We can continue discussing how and whether to continue working on this project as a separate task than the Google Summer of Code internship.

Change 436092 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] [wip] Create a generalized way to add dynamic/async groups

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

I just wanted to point out here that I think this functionality already exists via Related Change. See this link, in which I am filtering to all page linked from Category:Photography. Since "being in a category" really just means being linked on the category's page, this is displaying a list of all changes to pages in the photography category.

Change 436092 abandoned by Mooeypoo:

[mediawiki/core@master] [wip] Create a generalized way to add dynamic/async groups

Reason:

Old (very very old) WIP experimental refactor

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