Page MenuHomePhabricator

Build user interface for Active Filter Display Area
Closed, ResolvedPublic

Description

The Active Filter Display Area of the new RC page filtering interface shows a "tag" for all filters that are currently active (view in prototype). This task details the behaviors of this area:


Default State

- The following filters are active and tags displayed in this order by default when the page loads or the "Restore Defaults" button (see below) is clicked : “Page edits”, “Human (not bot)”, “New pages," "Log actions". Note: the default filter names were changed to “Human (not bot)”, “Page edits”, “Page creations," "Logged actions".

Adding and Removing

- Selecting or highlighting a filter in the dropdown panel adds a tag to the Display Area.
- Clicking the X in each tag removes the tag from the area and unselects it in the filter/highlight panel.
- Tags can also be added and removed via the Trashcan/Restore Defaults button.

Trashcan / Restore Defaults

- The Trashcan icon at Right of the Display Area clears all active filters and highlights.
- The Trashcan has a tooltip that says "Clear all filters"
- The Trashcan toggles with the "Restore default filters icon." Clicking this restores the defaults (see above).
- The tooltip for this says "Restore default filters"
- The Restore Defaults icon also displays if the user manually removes all filters.

Actions

- Clicking the highlight area where no buttons or tags are opens the filter dropdown. If the panel is open, clicking closes the panel.
- Clicking a filter tag causes opens the dropdown and scrolls to the filter that was clicked. The filter will display with a blue background.

Filter Tags

- Tags in the Display Area indicate the current filtering and highlight status.
- Tags display the filter name as label, and the filter description as a tooltip.
- When an active filter is highlighted, the tags display a circle indicating the color used for highlight.
- When a filter is inactive but highlighted (i.e., highlight only), colored circle is displayed but the tag is grayed.

'No Effect' Display States

Two special display states communicate to users that they've made choices that don't have any effect. There are two variations:

  1. The user selects all members of a so-called "full coverage" filter group (currently that includes all groups except the ORES filters and the Experience group); functionally, this is the equivalent of no choice at all. In such a case, the tags are all grayed, and a special tooltip is shown explaining that your choices cancel each other out (see T149385 for final tooltip wording).
    • Here are the complementary sets where this condition will apply: Unpatrolled/Patrolled, Minor/Nonminor, Registered/Unregistered, My Edit/Edits by Others, Bots/Humans.
  2. In one of the ORES filter sections, the user selects a filter or filters that constitute a subset of an already selected filter. In such a case, the subset has no effect, so will be grayed out, but the broadest filter is still shown in the "active" state. A special tooltip for the grayed tags is made available suggesting the user may want to try highlighting the redundant filters with a color (see T149385 for final tooltip wording). Here are the filters that are subsets of others:
    • Quality filters: May Have Problems is a superset of both Likely and Very Likely Have Problems. Likely Have Problems is a superset of Very Likely.
    • Intent filters: May Be Bad Faith is a superset of Likely Bad Faith.

Note that if the user selects a highlight color for a redundant filter of either of the types above, all the filters in the group are shown in the Active state.

Conflict Display States

This functionality has been moved to T156427

Related Objects

StatusAssignedTask
ResolvedDannyH
ResolvedDannyH
Resolved jmatazzoni
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
Resolved jmatazzoni
ResolvedNone
InvalidNone
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
ResolvedSBisson
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Pginer-WMF updated the task description. (Show Details)Oct 31 2016, 1:20 PM

I have a question for @Pginer-WMF and @Halfak. In light of the discussion above under 'No Effect' Display States, section #1, should we include the following two in the list of self-canceling pairs?

  • Very likely good + May have problems.
  • Very likely good faith + May be bad faith.

These filters can be presented as cancelled unless a "grey area" exists where it is possible from some edits to fall in neither of those buckets. With the ranges we were discussing ("very likely good"= 0-15% and "may have problems": 55-100%) there seems not to be room for such "grey area" (unless some edits get no score from ORES or there is some "undefined" value, @Halfak can confirm if such situation is possible).

From my reading, it looks like they'd fully cancel each other out. That does seem to be difficult for UX. It should be intuitive to the user when two selections have canceled out. I'm afraid I don't have any good ideas.

For these aspects our goal is to provide some cues to emphasise consistency, not to alert the users or warn them telling they did anything wrong.
It is totally valid to select both "registered" and "unregistered" editors to review. Some users may do it to be sure these are listed or assuming there may be another kind of users not listed. In any case our approach is to emphasise what is active and de-emphasise what has no effect. In any case, the users will get the results they are looking for.

Pginer-WMF updated the task description. (Show Details)Nov 2 2016, 11:48 AM

Change 326208 had a related patch set uploaded (by Mooeypoo):
RCFilters UI: Add 'remove' and 'restore defaults' to filter list

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

Mooeypoo added a comment.EditedDec 11 2016, 12:22 AM

General UI interaction question came up as we had a technical discussion about how to properly implement the "restore to defaults" feature, requiring input.

Right now, the spec states that the 'clear' button at the end of the active filters list has 2 behaviors -

  • If there are any active filters, the button has the 'trash' icon, and clicking on it eliminates all filters (results in "display all" behavior)
  • If there are no active filters, the button has a different icon ('history') with a 'Restore default filters' text. Clicking that results in filling in filters that are defined as default.

The question is -- do we really need those two behaviors? Would it not be simpler for this button to always restore filters to default?

There aren't many default filters as it is, so if the user wishes to "view all" the action of manually removing the 3-4 default filters doesn't seem to require that much; however, if the user's intent is to restore to their default view, they will need to click the button twice - once to clear, another to restore to defaults - and each time the API will be called to return results. How much do we think users will really want to use this?

I have to admit, I can see either side of this; I can see a use case for removing all filters (current behaviors) and I can also see the use case of reverting to defaults. However, I think that the behavior might be a little confusing and unnecessarily complicated for normal use.

The current patch (attached above; https://gerrit.wikimedia.org/r/326208 ) implements the complete behavior stated in the ticket (one click removes all, another restores defaults) - but the question is, should it remain like that or change to have the button always restore defaults instead?

We can also decide to start with the dual-behavior and test whether it is needed. If we decide that -- should we add some logging features? Maybe check how many users use the 'clear' function (and stop to look at results) vs. how many click the button twice, to essentially go from whatever filters they have immediately to default filters..?

What do you think, @Pginer-WMF and @jmatazzoni ?

Change 326064 had a related patch set uploaded (by Mooeypoo):
[wip] RCFilters UI: Read preferences as base state

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

The question is -- do we really need those two behaviors? Would it not be simpler for this button to always restore filters to default?

I think we want to support both behaviours. The concept of "defaults" may not be clear for everyone accessing the page, and providing a way to remove everything (instead of leaving some arbitrary filters) and making it explicit the addition of defaults seems to provide clear actions without surprises in the results. We have not found any issues related to this in the different testing sessions where these actions have been used regularly. Even for the cases where the intent is to restore the defaults, the two step process does not seem to introduce any friction in the process for users.

If the number of requests is the issue, we need to consider that removing filters individually also generates a new request on each change. In addition, in the future we may want to allow users to define their own defaults (T151994), so we cannot assume that could be removed in just three clicks.

In any case, I'm totally for instrumenting the filters in a way that allow us to better understand how are those used in practice.

I had an idea for a small improvement to the design of the Active Filter Display Area. In the design currently, the label "Active filters" sits on its own line above the filter tags. I find it a little disconnected from the tags it describes, and those two words alone use up about 50 px of vertical space on the page. Screenshot below:

But it struck me that if we put the label on the same line as the first row of tags and added a colon after "Active Filters," then a) we'd tighten up that vertical space and b) the colon would visually connect the label to the tags more. Like this:

I like the visual rhythm better this way and think it's easier to understand. @Pginer-WMF, what do you think?

What would this look like when the filters are empty, @jmatazzoni ?

Right now, there's a placeholder text in the prototype "No active filters. All contributions are shown." which actually seems to look nice when it's under the label "Active filters"... would it look awkward if it's all in the same line?

What would this look like when the filters are empty, @jmatazzoni ?
Right now, there's a placeholder text in the prototype "No active filters. All contributions are shown." which actually seems to look nice when it's under the label "Active filters"... would it look awkward if it's all in the same line?

We can decide if we go this way. But I'd say either put the "No active filters..." message after the colon, or just suppress the "Active filters" label altogether and only display the "No active..." message. Since it would never happen that the user would see "No active..." state until after he/she had been interacting with the tags (either by manually closing them or clicking the trashcan) we're safe in assuming that a user seeing the "No active..." state understands already that this is the "Active filter" display area. So I'd go with suppressing "Active filters" label and showing only the "No active..." message. Whew!

I like the visual rhythm better this way and think it's easier to understand. @Pginer-WMF, what do you think?

Similar to what happens with the alignment of labels in forms, placing the label at the top or the side has several pros and cons. With the proposal we save 50px of vertical space, but it is not clear to me that saving vertical space should be our main goal in this context:

  • During testing we've observed that some users ignored the filters area because they focus their attention on the main list of data. Making the filter area slightly more noticeable and keeping a clear vertical scan line may help users to recognise it.
  • We are already saving vertical space compared to the current situation. Moving towards a more unified entry point for filtering already helps in having a more compact entry point than the current "Recent Changes options" box.
  • Filter tags need room. The gain in vertical space comes with a loss of horizontal space in the list of filter tags. If we want to encourage people to use more filters to better target their edits of interest, we may want to leave them room to do so. Your mockups only include the default filters, and the tags already take a significant portion of the space. We expect people to add more filters (some cases going to a second line of tags), so it makes sense to me to keep the area as clean as possible.

In terms of clarity, as I noted above, I think the few issues with the initial recognition of filters have been related to "skipping the whole thing and jumping to the data", not because of getting confused about what the label refers to. However, I think these potential confusions are worth checking based on how people use the feature once it is available to filter real data. So I'd definitely keep this as one of the aspects to observe.

Change 327419 had a related patch set uploaded (by Mooeypoo):
Create active/inactive behavior for complementary filters

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

Change 327419 merged by jenkins-bot:
Create active/inactive behavior for complementary filters

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

@Mattflaschen-WMF, @Mooeypoo suggested I point out to you that I added a new section in the description above, for "Conflict between Logged Actions or Wikidata Edits and any ORES filter". She says it relates to the system you're building that creates the definitions of the filters. Please have a look and let me know if you need anything.

Quiddity removed a subscriber: Quiddity.Jan 25 2017, 2:09 AM

So the exclusion behavior is implemented (and merged now), but we are missing implementing the actual exclusion rules in the rcfilters.init (while the backend object is worked on)

We can't implement the ORES filter exclusions yet because they're not included but #1 and #3 from T149452: Build user interface for the Dropdown Filter Panel can be implemented (the filters that are not ORES or Wikidata)

Mooeypoo added a subscriber: Etonkovidova.EditedJan 25 2017, 3:41 AM

@Etonkovidova for testing -- the only active/inactive states that are implemented at the moment are the group-wide rules (if you choose the entire group, it is all "excluded" / "greyed out" )

The specific exclusion rules for Experienced/Newcomer/etc should be implemented in a separate child task.

Change 326064 merged by jenkins-bot:
RCFilters UI: Read default states of filters

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

Change 326208 merged by jenkins-bot:
RCFilters UI: Add 'remove' and 'restore defaults' to filter list

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

(1) @Pginer-WMF The position of the trash can icon is different from your spec - it's placed at the upper right corner instead of more toward the lower corner. Should it be corrected?


vs your design

(2) No tooltips yet (including the cases for 'No Effect' Display States and 'Conflict Display States' tooltip)
(3)

Clicking a filter tag causes opens the dropdown and scrolls to the filter that was clicked. The filter will display with a blue background.

Not implemented yet.
(4) No highlighting yet
(5) No ORES filters yet

(1) @Pginer-WMF The position of the trash can icon is different from your spec - it's placed at the upper right corner instead of more toward the lower corner. Should it be corrected?

The position of the trash can and the "Active filters" labels need some adjustments.
I created two mockups to illustrate the layout and the final result showing showing the cases of one and two lines of tags:


  • The separation between the "Active filters" label and the filter tags should be consistent with the rest of the separations (10px, or whichever approximation Ems allowed for the margins around the other elements).
  • The trash can is presented at the top-right corner of the area where the tags are, not the whole panel as currently happens.

Logged Actions and Wikidata Edits are not scored by ORES.

Wikidata edits themselves are scored by ORES (see https://www.wikidata.org/w/index.php?title=Special:BetaFeatures and RecentChanges on that wiki).

Wikidata also propagates edits to the client wikis. E.g. when you're on English Wikipedia RecentChanges and someone adds a language link (via Wikidata) to an entity English Wikipedia has an article on, you'll see it on English Wikipedia. This is what will affect the initial release (until the new UI is enabled on Wikidata).

I confirmed we don't yet support ORES for this use case. However, we should at some point, since it's relevant (see above example), and the information needed by the ORES service (the diff ID) is here. Filed as T158025: Support ORES for propagated Wikidata edits.

Mattflaschen-WMF updated the task description. (Show Details)

Change 339580 had a related patch set uploaded (by Mooeypoo):
Align trash icon with filter list

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

I updated the Conflict Display States section to 1) include mention of the Results Area Messages and 2) to put Wikidata Edits back in as something that conflicts with ORES filters.

Change 339580 merged by jenkins-bot:
RCFilters: Align trash icon with filter list

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

Change 340262 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
RCFilters UI: Add 'select' state and styles to capsule items

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

@Pginer-WMF I implemented the color styling of the capsule widgets + the 'active' state when you select one by clicking on it.

Can you add the color values for the 'conflict' state? I am not sure which reds to pick, and while the conflict messaging is still under development, we actually already have the conflict state available, so I can add that styling in now.

@Pginer-WMF I implemented the color styling of the capsule widgets + the 'active' state when you select one by clicking on it.
Can you add the color values for the 'conflict' state? I am not sure which reds to pick, and while the conflict messaging is still under development, we actually already have the conflict state available, so I can add that styling in now.

We are using "Red50" from the color palette (M82), which is #DD3333

Change 340262 merged by jenkins-bot:
RCFilters UI: Add 'select' state and styles to capsule items

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

@SBisson, I see you moved this to QA. Does that mean the Conflict state stuff has been done? If not, do you want us to split that off into a separate ticket?

@SBisson, I see you moved this to QA. Does that mean the Conflict state stuff has been done? If not, do you want us to split that off into a separate ticket?

I moved it to QA because it was in "Needs Review" and I merged the patch associated with it. I didn't know there was more to it than the current patch.

I'll let @Mooeypoo, who is assigned to this task, decide how to handle the rest of the work.

@SBisson, I see you moved this to QA. Does that mean the Conflict state stuff has been done? If not, do you want us to split that off into a separate ticket?

At this point, I'd suggest opening another task (could be child task to this one) for conflict state text and behavior -- it is going to be a larger work to finish it that depends on back end pending work.

I moved all the Conflict Display States functionality and messaging to the child task T156427, which I renamed from "More forcefully communicate "Conflict" filter settings to the user" to "Implement the Conflict display states and messages".

Etonkovidova updated the task description. (Show Details)Mar 20 2017, 6:29 PM
Etonkovidova updated the task description. (Show Details)Mar 20 2017, 8:39 PM

The Trashcan toggles with the "Restore default filters icon." Clicking this restores the defaults (see above).
The tooltip for this says "Restore default filters"

'Restore default filters' does not need a tooltip since screen readers can read the label itself (per @Mooeypoo and @Catrope)
Everything else is according to the specs.

QA recommendation: Resolve.

jmatazzoni closed this task as Resolved.Mar 20 2017, 11:24 PM