In T149391#2753219, @jmatazzoni wrote:

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).

In T149391#2753266, @Halfak wrote:

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.

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

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

In T149391#2862399, @Mooeypoo wrote:

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?

In T149391#2891721, @Mooeypoo wrote:

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!

In T149391#2891712, @jmatazzoni wrote:

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.

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)

@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?

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

In T149391#2978866, @Etonkovidova wrote:

(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.

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.

In T149391#3059913, @Mooeypoo wrote:

@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?

In T149391#3063136, @jmatazzoni wrote:

@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.

In T149391#3063136, @jmatazzoni wrote:

@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".

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.