@Pginer-WMF , please look this over and add an updated screenshot or two. Then please move to RFP.

@Pginer-WMF What is the icon you would like us to use for the "Exclude" button in the namespace feature? Right now we're using the "article" icon from OOUI for the "Namespace" button, and the "tag" icon for the "Tag" button, but we don't have anything in OOUI that looks like the "yin-yang but with a straight line" icon that your prototype uses for the "Exclude" button. IIRC a previous version of "halfBright" looked kind of like that, but the current version doesn't.

In T166912#3311655, @jmatazzoni wrote:

@Pginer-WMF , please look this over and add an updated screenshot or two. Then please move to RFP.

I added the mockups and also a detail that was missing about the way items get greyed-out when selected if the "exclude" option is active:

The namespace items are greyed-out (to indicate they are not present in the results) while the rest of the namespaces items are shown with the regular white background. That is, the way to emphasise regular and greyed-out items is reversed.

In T166912#3312041, @Catrope wrote:

@Pginer-WMF What is the icon you would like us to use for the "Exclude" button in the namespace feature? Right now we're using the "article" icon from OOUI for the "Namespace" button, and the "tag" icon for the "Tag" button, but we don't have anything in OOUI that looks like the "yin-yang but with a straight line" icon that your prototype uses for the "Exclude" button. IIRC a previous version of "halfBright" looked kind of like that, but the current version doesn't.

I exported the icon (and added it to the ticket description):

The icon will be also used in white, but I think this can be adjusted via software. The icon is not completely symmetric, but I'm not sure directionality affects the meaning so I don't think LTR and RTL versions are needed. If any of these assumptions is wrong, I can prepare specific versions.

The namespace items are greyed-out (to indicate they are not present in the results) while the rest of the namespaces items are shown with the regular white background. That is, the way to emphasise regular and greyed-out items is reversed.

I'm highly skeptical of this. So far, in RCFilters, 'greyed-out' items note "no effect" -- either because they're full coverage or because they are subsets. We are now going to include a greyed-out item as having an effect but being a contrary (excluded) effect -- which is still an effect.
I think having the ":not NamespaceX" in bold is sufficient, and having the item greyed-out will be super confusing and will confuse the behavior we already have.

So while I wrote my 2 cents, I obviously defer to @jmatazzoni @Pginer-WMF's authority and expertise. If you still want to mute those, please approve, and I'll do that.

Also, just to verify: When we say "namespace items" we mean the selected tags/pills/bubbles at the top, not the menu items, right? (my objection to this is valid to either case, but I want to verify which one to actually apply this to if we're going that way)

@Mooeypoo, I don't know the answer, either, but perhaps looking at the mockup will clarify your question as to bubbles vs. menu?

In T166912#3316965, @jmatazzoni wrote:

@Mooeypoo, I don't know the answer, either, but perhaps looking at the mockup will clarify your question as to bubbles vs. menu?

Looks like it's about reversing the grey/white background colors in the menu, but not in the bubbles.

In T166912#3314542, @Mooeypoo wrote:

Also, just to verify: When we say "namespace items" we mean the selected tags/pills/bubbles at the top, not the menu items, right? (my objection to this is valid to either case, but I want to verify which one to actually apply this to if we're going that way)

I was referring to the menu items, and only the menu items (no effect on tags). Here are the mockups from the description:

The greying-out in the menu items works the following way: the properties that results may have are shown with white background, and the properties being excluded are shown in grey. For example, if I select newcomers, experienced users become greyed-out in the menu unless I select it explicitly or unselect the whole group. In the case of namespaces you can exclude some namespaces, thus showing them in grey communicates that you won't find those in the results.

Checked in betalabs
(1) all specs have been implemented, except

• A "?" icon (help link) leads users to an as yet unwritten Help page on using Namespace filters.

The following spec is implemented differently, see the screenshot below.

• The button label changes to "Excluding selected"

Note: 'Excluded' is placed differently (reserving the place for the highlight selection?).

Mockup	betalabs

(2) What is the purpose of Highlight when it's applied to 'Invert selection'?

(3) Should T168220: Namespace drop-down filter menu does not scrolls automatically when selected Namespace (Tag) filter capsule is clicked be fixed before deployment?

In T166912#3361181, @Etonkovidova wrote:

(2) What is the purpose of Highlight when it's applied to 'Invert selection'?

With the regular filters, we keep the highlight option also for those items not selected in a filter group. For example, you can select the "Registered" filter and still provide a highlight color to "unregistered". This is done to provide users freedom of movement as they explore their contributions of interest. If the user wants to change from viewing only "registered" users to view both in different colors it should be ok to change the highlights first and the filter status later. Not providing support to those intermediate steps would force the user to follow a much strict path to get to their filters of interest, adding friction to the exploration.

In order to avoid confusions, what we do in those cases is to show the items that are not having effect by other selections in their group to be greyed-out, suggesting also that the highlight is affecting items that are not displayed. This however, is missing in the case of the "exclude" option where the excluded filters should be greyed out from the list of filters (and the visible ones shown in white instead).

@Pginer-WMF Using your example with selecting both "Registered" and "Unregistered" and apply some highlighting to clearly see which items belong to results sets fetched by "Registered" and "Unregistered" (connected by OR), there will be the following result:

Also, makes sense do not select filters but use highlight only.

Now with Namespace filter, using highlight - when highlight applied together with selecting 'Invert selection', the result cannot be displayed. Viewing such state as some "intermediate steps" that user might consider to build up a set of filters seems to be a little bit far-fetched.

Note: greying out of not-selected Namespaces and hover over seems to be done according to the specs. There are also correct blue highlight states and grey hover-up.

In T166912#3363638, @Etonkovidova wrote:

@Pginer-WMF Using your example with selecting both "Registered" and "Unregistered" and apply some highlighting to clearly see which items belong to results sets fetched by "Registered" and "Unregistered" (connected by OR), there will be the following result:

My example was more about selecting "Registered" but setting highlights for both registered" and "unregistered". In that example, the highlight for "unregistered" is not visible because those results are "excluded" by your filter selection.

My point is that the case of an explicit exclude option is not that different to what we have already.

(1) The following spec has been implemented:

The namespace items are greyed-out (to indicate they are not present in the results) while the rest of the namespaces items are shown with the regular white background. That is, the way to emphasize regular and greyed-out items is reversed.

A "?" icon (help link) leads users to an as yet unwritten Help page on using Namespace filters.

QA Recommendation: Resolve

@Mooeypoo, pease fix the following:

• In the Invert state, the button label changes to "Excluding selected"
• The Namespaces filters don't work at all. (As you've already discussed with Roan, etc.)

In T166912#3402801, @jmatazzoni wrote:

• The Namespaces filters don't work at all. (As you've already discussed with Roan, etc.)

That's T169579: [betalabs-regression] Namespace filters do not work

Re. the item above to change the button label, Moriel suggests we make it:

• Exclude selected
• Excluding selected

That seems sensible, instead of introducing a the term "invert." We'll go with that.

@Mooeypoo, if you do this bit with Exclude / Excluding, I can close this ticket. Thanks.

In T166912#3402819, @jmatazzoni wrote:

Re. the item above to change the button label, Moriel suggests we make it:

• Exclude selected
• Excluding selected

That seems sensible, instead of introducing a the term "invert." We'll go with that.

I moved the requirement to add a help link to T167741

Change 365869 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Correct language for invert button

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

Change 365869 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Correct language for invert button

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

@Mooeypoo
Should we address the case when no selection is made (because no filters found or only highlighting is applied) but the button is still can be clicked?

(1) No filters found

(2) Only highlighting is selected - not the filter itself.

The filters are only excluded when they're selected, according to spec. We don't highlight excluded namespaces, because they're not there, so if the filter isn't selected and is just highlighted, it won't show the "not" message because it's highlighting the namespace itself. I wouldn't touch the active state of the button itself because that lets users choose the excluding namespaces even if none is YET selected.

Yes, it's an interesting question. Thanks for raising @Etonkovidova. But I think the behavior is OK.

@Mooeypoo The active state of the button 'Exclude selected' should be only available when a filter's selection is made. The active state and the wording 'Excluded selected' sends a strong message to a user.

Two scenarios of potential usability issues:

First scenario:

1. On RC page with default filters, I click on Namespace icon - and the dropdown list of available namespaces is displayed.
2. Without making any selection, I click on 'Exclude selected' and the button changes its label to 'Excluding selected' and the color is becomes dark blue (the active state). Nothing is changed (although the page is reloaded), not in the RC results and not in the selected filter area.

The active state of 'Excluding selected' will persists after discarding the drop-down although de-facto nothing was excluded; also, the no-action "Excluding selected" state can be saved as part of a a saved filter.

Second scenario (from my previous comment)

1. I click to highlight certain Namespaces (not selecting it)
2. I click to 'Exclude selected' - the button becomes active (dark blue) and the label changes to 'Excluding selected'.

Negative.

The state is either on or off; if we only display it as "on" when something is selected, then a user will press that button over and over again with no result (the button will remain non-active because nothing is selected) until the user selects something, in which case the button will finally respond.

I think the way things are right now are acceptable behavior. If anything, I'd say we can hide the invert button until at least one namespace is selected, and only show it in that case -- but the down side to that is that if a user intends to exclude namespaces, the fact they won't see that button may mean they won't immediately know HOW to go about doing that, rather than them seeing "oh, I have this button" and click it + the excluded filter.

In short, I think all behaviors have good and bad aspects -- and the current one is the one where whatever pros are overcoming the potential cons.

Thx, @Mooeypoo.

I think the description below is the correct one - the button label 'Exclude selected' gives a clear instruction to a user to select something, so to have it non-active when nothing is selected is logical.

if we only display it as "on" when something is selected, then a user will press that button over and over again with no result >(the button will remain non-active because nothing is selected) until the user selects something, in which case the button will finally respond.

If the current behavior is expected, the task can be sign off. All specs have been implemented.

QA Recommendation: Product should weigh in