Page MenuHomePhabricator

Implement Namespace filters and filter menu in the new UI
Closed, ResolvedPublic

Description

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

General Namespace menu functions

  • When the Namespace menu is open, a colon is displayed in the Search box.
  • The menu reproduces all the namespaces in the current namespace menu, in numerical order, with each namespace and its associated talk space displayed next to each other.
  • In terns of filtering logic, the entire Namespace menu is one filter "group." This means that as users select more namespaces, they broaden the search, since all Namespace filters relate via an OR.
  • In the Active Filter Display Area, Namespace names are prepended by a colon in their respective Namespace tags. E.g., :User talk.
  • Users can search for Namespaces by prepending their search with a colon, like so :Article
  • A "?" icon (help link) leads users to an as yet unwritten Help page on using Namespace filters. [Moved to T167741]
  • An "Exclude" button inverts the function, so that if "Article" is selected in Exclude mode, everything but articles are shown. When multiple items are excluded, the logic is Not A OR Not B--everything but A and B (to be crystal clear, items don't have to be both A and B—which is impossible here anyway).
  • All Namespace selections must either be in Exclude or Include mode; these modes cannot be mixed. This means that when a user makes the "Exclude selected" button active or inactive, all previous selections will turn to the new mode (and, obviously, all future selections will be in that mode). If the mode is reversed, all selections are also reversed in function and display.

Exclude mode functions & display behavior

When the "Exclude selected" button is pressed, the following happens:

  • The button turns blue. The user is now in Exclude mode, and all selections will be Exclude selections.
  • The button label changes to "Excluding selected"
  • Any currently active namespace filters go into Exclude mode in function and display (see below)

In Exclude mode, when an item is selected, the system shows the following UX behavior

  • The word "Excluded" is displayed in the menu in the line of that namespace item.
  • 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.
  • In the Active Filter Display area, the following formula is prepended to the namespace name in the tag, in boldface, ":not". E.g., ":not Talk"

Mockups

An example where the talk namespace is selected and reverted is shown below:

namespaces - initial.png (479×799 px, 39 KB)
namespaces - selected.png (479×799 px, 42 KB)
namespaces - excluded.png (479×799 px, 44 KB)

Visual assets

The icon for the "Exclude selected" action:

Related Objects

Event Timeline

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

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

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

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

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:

namespaces - initial.png (479×799 px, 38 KB)
namespaces - selected.png (479×799 px, 41 KB)
namespaces - excluded.png (479×799 px, 43 KB)

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.

jmatazzoni renamed this task from Implement Namespace filter in the new UI to Implement Namespace filters and filter menu in the new UI.Jun 7 2017, 12:04 AM

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

Mockupbetalabs
Screen Shot 2017-06-19 at 9.10.23 PM.png (358×685 px, 35 KB)
Screen Shot 2017-06-19 at 9.09.42 PM.png (305×727 px, 31 KB)

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

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

Screen Shot 2017-06-20 at 6.25.53 PM.png (653×1 px, 216 KB)

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.

Screen Shot 2017-06-20 at 6.44.49 PM.png (453×866 px, 101 KB)

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.

Screen Shot 2017-06-20 at 6.43.49 PM.png (572×781 px, 56 KB)

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

Screen Shot 2017-06-20 at 17.19.00.png (671×902 px, 131 KB)

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.

Screen Shot 2017-06-29 at 4.22.28 PM.png (644×652 px, 51 KB)

(2) The following will be implemented later

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

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.

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

Screen Shot 2017-07-20 at 3.38.30 PM.png (260×768 px, 30 KB)

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

Screen Shot 2017-07-20 at 3.37.45 PM.png (307×776 px, 29 KB)

The button changed its state to "Excluding selected" but there is no indication in the Active filter area - the filters do not display 'not' .
Screen Shot 2017-07-20 at 3.44.23 PM.png (356×708 px, 38 KB)

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.

Screen Shot 2017-07-21 at 2.29.31 PM.png (520×811 px, 70 KB)

From a user point of view it seems as the state is changed - the button clearly says that something has been excluded and the page was reloaded.

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

Screen Shot 2017-07-20 at 3.37.45 PM.png (307×776 px, 29 KB)

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

Thanks for these observations @Etonkovidova. Users successfully excluded using this function in testing with no issues. So I think we can proceed as is.