Page MenuHomePhabricator

[Epic] Media Search: Ability to filter by namespaces in the Categories and Pages tab
Closed, ResolvedPublic


As an experienced Commons user, I want to be able to filter my search on the Categories and Pages tab by namespace, so that I can find what I'm looking for without having to filter through too many results.

As we try to bring more functionality that is currently possible on special:search to Media Search, we want to add a Namespace filter to the Categories and Pages tab. It won't be a dropdown/select like the other filters but a dialog instead to allow for more complex interactions and more space to use comfortably.

Design: desktop and mobile (current special:search for reference at the top)

Screen Shot 2021-02-17 at 10.40.56 AM.png (1×2 px, 428 KB)

Acceptance criteria:

  • Crete a dialog that allows the user to select their preferred namespaces
  • Dialog options include 4 radio buttons: All, Discussion, General Help, and Custom
  • Nested underneath the Custom radio button is all of the available namespaces for the tab, and they should be able to be selected individually as checkboxes. The user should be able to select as many as they'd like.
  • Mobile web is a full screen dialog
  • Default is no longer an option
  • "Remember selection..." is no longer an option
  • If the user clicks "Submit", the search on the Categories and Pages tab should be filtered to only include their selected namespaces
  • The user can click the "X" in the upper right hand corner to dismiss the dialog without saving their selections. The search results should not change.

Event Timeline

Special:Search allows selecting multiple namespaces at once.
None of our current filters support that IIRC - what would that look like (if at all possible)?

One idea for this is to create two top level radio buttons and allow users to switch to custom and select any checkboxes they want.

This deviates from the current special:search implementation by removing the buckets "Default", "Discussion", and "General Help", which we could make radio button options if we thought it was worthwhile.

name_space_filter_2.jpg (718×1 px, 122 KB)

This is a tough one!

Regarding the mockup, the other pattern we could follow is, instead of using the radio buttons, just have a checkbox group with an "All" checkbox at the top. This checkbox would be technically separate from the group and would toggle all of them on/off. And, as soon as you uncheck one of the boxes in the group, "All" would become unchecked.

The benefits here would be avoiding mixing radio buttons and checkboxes, and saving us from having to build a radio button component.

However, as mentioned above, there is some communication that would have to happen between the "All" checkbox and the checkbox group, and I'm not sure how, from a design standpoint, to ensure that the "All" checkbox is clearly delineated from the group (or if that's even necessary?)

Also, we should think about what happens when someone checks or unchecks a box. Certainly, we'd want to keep the dropdown open. But do we want to perform a new search immediately? And, if so, does that mean the user will have to manually click outside the dropdown to close it? I wonder if a submit button would be worth including to avoid extra search API calls and to close the dropdown when the user has clearly indicated that they're done using it.

I'm also a little concerned about ease of use. This seems like a component that might take some care to operate. It would be easy to scroll down the page instead of down the dropdown list, or to accidentally click/tap off of it and close it.

Thanks for the feedback Anne! Also chatted with Eric who brought up some similar concerns.

Some quick mockups of the ideas from both of you

Bigger dropdown box

01.jpg (718×1 px, 123 KB)

Dropdown box with checkboxes only, "All" would select everything and interacting with anything else would automatically uncheck "All"

02.jpg (718×1 px, 124 KB)

Moving towards a dialog since this might be tricky to complete in a dropdown and gives us a clear save / submit button

03.jpg (718×1 px, 95 KB)

Dialog with only checkboxes

04.jpg (718×1 px, 93 KB)

Dialog on Mobile would be full screen

05.jpg (2×1 px, 175 KB)

Although I'd prefer for all the filters to be dropdowns so the experience is expected and consistent, I'm starting to feel like a dialog would help do the heavy lifting for this particular use case in a more easy to use format.

I'm in favor of the dialog with only checkboxes, with the full screen version on mobile. What do you think of changing the wording of "save" to "submit"? "Save" feels to me like something you'd do when actually changing a page or a file, not changing filters.

Per our meeting yesterday, I updated the namespace selector filter dialogs to map a little closer to the special:search experience. Two questions: Do you think that we need that "Default" selection choice? I'm not sure I have enough context to know what to do there. And should we support the "Remember selection for future searches" checkbox, is that a lot of work?

Current Special:Search options at the top of this screenshot for reference.

Screen Shot 2021-02-17 at 10.40.56 AM.png (1×2 px, 428 KB)

mwilliams updated the task description. (Show Details)

Based on discussions, it seems like we don't want to support "Default" or "remember selection for future searches" right now. If we hear feedback after implementation that it's missing, we can consider implementing it later.

Minor questions

  • So the de-facto default is "All"?
  • "Discussion" and "General Help" labels assume that users do know which namespaces are included in those groups?
  • "Custom" label might be viewed as implying that something is "custom" with namespaces not with the selection of namespaces

So the de-facto default is "All"?

Yup! Default is all the namespaces that apply to the Pages & Categories tab

"Discussion" and "General Help" labels assume that users do know which namespaces are included in those groups?

Yeah, hoping that those terms are obvious enough on their own to help people find what they are looking for.

"Custom" label might be viewed as implying that something is "custom" with namespaces not with the selection of namespaces

Good point, hoping that the list of checkboxes nested underneath will aid comprehension of what is going on but we should keep your point in mind.

I've been keeping a list of all these types of interaction questions, I'll run a quick usability study to push a little harder on some of these choices when we have a bit longer list of questions to resolve.

Per the discussion in T275662, we will likely just follow the path taken in MachineVision for now: create a dialog "widget" that relies on OOUI's ProcessDialog class, and launch it using an OOUI WindowManager. Eventually we will want to migrate away from any reliance on OOUI, but we can do that at the same time we port over MediaSearch's UI to a more standardized set of UI components.

AnneT renamed this task from Media Search: Ability to filter by namespaces in the Categories and Pages tab to [Epic] Media Search: Ability to filter by namespaces in the Categories and Pages tab.Mar 2 2021, 6:48 PM
CBogen claimed this task.