1262541 - No way to disable all filters in search UX

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Search, defect)

Description

[Eric Shepherd [:sheppy]]

What did you do?
================
1. Opened the search page at https://developer.mozilla.org/en-US/search
2. Typed getIntPref (part of nsIPrefBranch XPCOM interface)
3. Clicked all the default-enabled filter checkboxes, trying to disable all filters


What happened?
==============
As soon as I click the last one, they all automatically get re-checked. And there's no "no filters" option.

What should have happened?
==========================
There needs to be a way to do an unfiltered search, and there isn't one. This makes it impossible to find pages if you're not aware of the right tags or filters to apply.

Is there anything else we should know?
======================================

Comment 1

[John Whitlock [:jwhitlock]]

Unfiltered search was the default until recently. See https://bugzilla.mozilla.org/show_bug.cgi?id=1261274#c2 for details, and a pro tip for unfiltered search.  It will require dev work to add the UI element + backend changes for unfiltered search, about a day.

Comment 2

[Stephanie Hobson [:shobson]]

Sounds like we can work around this with some front-end work.

Two things we discussed in the triage meeting:
1) add &topic=none to template search links
2) add an option to the search filters in the right column for topic=none

The "none" topic does not actually exist.

This is a work around for the fact that if you do not include a topic the default topics get applied. These changes may not be a permanent solution.

Comment 3

[Eric Shepherd [:sheppy]]

From a UX perspective, simply adding a "Search all" checkbox which applies the &topic=none (or &topic=DoozyMcFlarnyFoo, to avoid potential tag conflicts later).

Comment 5

[Eric Shepherd [:sheppy]]

Kadir:

We could use some decision-making input on this one. The issue doesn't impact a large percentage of users (about 200,000, according to Florian), but we are getting complaints in IRC and some core users are impacted (since default search is leaving out stuff that Firefox contributors and add-on developers often search for).

What we need is some input on prioritization of a fix for this. We have some options, and we can do any number of them in pretty much any order; the question is which we do and when.

* We can add a button to the search UX to add "&topic=none" to the URL so that the search looks at all pages instead of a tag-filtered subset of pages.

* We could also stop automatically resetting to the default set of filters when the user manually tries to turn them all off. (This one personally confuses me; overriding a user's explicit behavior like this seems like a terrible UX mistake)

* We could revert to our old behavior, which would get rid of the problem of searches that leave out stuff that aren't tagged correctly or that aren't open web related, but would return to the problem of flooding web developers with stuff they don't need to see (although this could be a temporary solution while we work on something better, too). Probably not a good idea, but perhaps a useful one to consider for a very short term if it becomes a big issue for some reason.

* We could add code to save the user's last set of filters and using them as a default (or offer a way to set the default filters), since users will typically search on the same general topics -- a Web dev will search on CSS, HTML, JavaScript, etc, while a Firefox developer would search on those plus Gecko, XPCOM, XUL, and so forth.

Just a few options. I'm sure there are others. Do you have any input on this?

Comment 6

[Kadir Topal [:atopal]]

Let's go with #1 for now.

Comment 8

[Stephanie Hobson [:shobson]]

Just to recap, what we want is:

-  at the top of the search column on the right side bar, either immediately above or immediately below "topics"
- a check box with the label "all topics"

Potential avenues for exploration are:
- client-side
-- when checked it: removes all other topics, adds topic=none and performs a new search
-- appears checked if topic=none is the *only* topic in the query string

- server-side
-- alter the search filter admin pannel[0] to allow creation of a filter that does we want
-- this is not as simple as creating a filter and adding all tags to the tags field, since not all documents on MDN have tags :/

[0] https://developer-local.allizom.org/admin/search/filter/add/

Comment 9

[Erin]

Information about setting up search on local dev environment: https://kuma.readthedocs.io/en/latest/elasticsearch.html

Comment 10

[MDN Team (:mdn-dev)]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/2b60f33632363cde1471d3501869db662a8ca887
bug 1262541 - Add an 'All Topics' filter that allows user to search all topics. Clear out that value when other topics are selected via js. Add a filter test.

https://github.com/mozilla/kuma/commit/025fdd0529be7593908624cbf0459852a073dcf2
bug 1262541 - Add localization to All Topics filter, remove legend style to reduce size.

https://github.com/mozilla/kuma/commit/92ec2a86b53627b6d61563878f6b5602f3627832
bug 1262541 - Append to active_facets only if filter_tags has value.

https://github.com/mozilla/kuma/commit/870a8d9e4c168fcbf34120712e8935898c19ee53
Merge pull request #3915 from caktus/1262541-disable-filters-search

bug 1262541 - Add an "All Topics" filter that will clear out checkboxes on search page

Comment 11

[John Whitlock [:jwhitlock]]

Fix is in staging and production. A new checkbox "All Topics" is available above the Topics list, that does not filter results by topic.