@RHo do you want to merge T297092: Support narrowing task search with topic selections with this one, or keep T297092: Support narrowing task search with topic selections separate as it also talks about a free text search as an option?

In T297117#7550179, @kostajh wrote:

@RHo do you want to merge T297092: Support narrowing task search with topic selections with this one, or keep T297092: Support narrowing task search with topic selections separate as it also talks about a free text search as an option?

Thanks @kostajh - I was looking for the filter tasks and missed this one! I think it makes sense to merge and add as a potential solution to this problem (it is in fact one of the potential solutions I was going to mock up)

From a backend perspective, we can easily include anything that can be turned into a search query filter - intersection of multiple topics, articles tagged with certain templates or categories, articles geotagged into a certain geographic area, hand-curated page lists as long as they aren't longer than 1-200 items (we could probably figure out something for longer ones too).

It's a bit complicated to handle things that can be used to rank search queries, ie. free-text searches and morelike: (which we used once as a not-so-successful topic filter but maybe it would work better for narrow topics). The difficulty here is that we randomize the search results (to avoid collisions) and so discard rankings; and while these can be used as boolean filters, they will probably give poor results. But with enough effort we could come up with a way to selectively not randomize things.

One option might be a global toggle at the top of the topic filter; with some styling and wording it might be more obvious to users about what it does? I also wonder if users might expect the narrower search to be the default, and widening the search pool to be the non-default choice.

Adding a free-text search option also seems like a good idea, but will function in a different way from ANDing the topic filters; ideally we could let users have both somehow.

In T297117#7671644, @kostajh wrote:

One option might be a global toggle at the top of the topic filter; with some styling and wording it might be more obvious to users about what it does? I also wonder if users might expect the narrower search to be the default, and widening the search pool to be the non-default choice.

Adding a free-text search option also seems like a good idea, but will function in a different way from ANDing the topic filters; ideally we could let users have both somehow.

Returning to the user intent and per our team discussion in the task description, I think providing the ability for people to enter in their narrowed topic combinations freely in a single field will obviate the need to create a separate control for "AND" to what are still quite broad categories. I would propose this first as having both would introduce more ambiguity about what filter method to use and whether the toggle affects the free search.

In T297117#7693120, @RHo wrote:

In T297117#7671644, @kostajh wrote:

One option might be a global toggle at the top of the topic filter; with some styling and wording it might be more obvious to users about what it does? I also wonder if users might expect the narrower search to be the default, and widening the search pool to be the non-default choice.

Adding a free-text search option also seems like a good idea, but will function in a different way from ANDing the topic filters; ideally we could let users have both somehow.

Returning to the user intent and per our team discussion in the task description, I think providing the ability for people to enter in their narrowed topic combinations freely in a single field will obviate the need to create a separate control for "AND" to what are still quite broad categories. I would propose this first as having both would introduce more ambiguity about what filter method to use and whether the toggle affects the free search.

Ah, I think I misunderstood, because it sounds like there are three proposals then:

1. A new interface element, using something like TextInputWidget that allows entering any arbitrary text, e.g. "cats" or "dogs" or whatever. The input would be sent along with the topic/task filters to search.
2. A new interface element, using something like MenuTagMultiSelectWidget that allows the user to choose from existing topics, and these are AND'ed together.
3. A new interface element, using something like ToggleButtonWidget that changes how searches using the existing Topic pills work

So to clarify, you are proposing something like option 2, the MenuTagMultiSelectWidget as a new field?

In T297117#7693215, @kostajh wrote:

Ah, I think I misunderstood, because it sounds like there are three proposals then:

1. A new interface element, using something like TextInputWidget that allows entering any arbitrary text, e.g. "cats" or "dogs" or whatever. The input would be sent along with the topic/task filters to search.
2. A new interface element, using something like MenuTagMultiSelectWidget that allows the user to choose from existing topics, and these are AND'ed together.
3. A new interface element, using something like ToggleButtonWidget that changes how searches using the existing Topic pills work

So to clarify, you are proposing something like option 2, the MenuTagMultiSelectWidget as a new field?

I was thinking about something that is like option 2 but with the flexibility to include free-text input (option 1). An example would be the following:

1. A user starts typing Fash and there is an autocomplete suggestion for topic:Fashion which they selected and it gets added as [topic icon]:Fashion
2. User then types Gucci for which there is no topic filter, so they enter it as is and it gets added as free-text search input Gucci
3. The filter that is set will find all task articles which are have the topic:Fashion AND contain the word Gucci

In T297117#7693251, @RHo wrote:

In T297117#7693215, @kostajh wrote:

Ah, I think I misunderstood, because it sounds like there are three proposals then:

1. A new interface element, using something like TextInputWidget that allows entering any arbitrary text, e.g. "cats" or "dogs" or whatever. The input would be sent along with the topic/task filters to search.
2. A new interface element, using something like MenuTagMultiSelectWidget that allows the user to choose from existing topics, and these are AND'ed together.
3. A new interface element, using something like ToggleButtonWidget that changes how searches using the existing Topic pills work

So to clarify, you are proposing something like option 2, the MenuTagMultiSelectWidget as a new field?

I was thinking about something that is like option 2 but with the flexibility to include free-text input (option 1). An example would be the following:

1. A user starts typing Fash and there is an autocomplete suggestion for topic:Fashion which they selected and it gets added as [topic icon]:Fashion
2. User then types Gucci for which there is no topic filter, so they enter it as is and it gets added as free-text search input Gucci
3. The filter that is set will find all task articles which are have the topic:Fashion AND contain the word Gucci

Got it, thanks for clarifying! So that sounds like MenuTagMultiselectWidget with allowArbitrary enabled.

In T297117#7693286, @kostajh wrote:

Got it, thanks for clarifying! So that sounds like MenuTagMultiselectWidget with allowArbitrary enabled.

hi @kostajh - I ended up created an "everything option" as part of my explorations for T301028 which I'd be interested to hear your thoughts on both feasibility (chaining several AND/OR statements) vs performance (how performant is the results), as well as how you consider the visual complexity now that you see it shown. I think it could be intimidating/convoluted for most people, so could do a simpler version where it's just the AND option in advanced.

T326244: Investigate using Search API Facets from ElasticSearch might be relevant to this work as well, see https://www.elastic.co/guide/en/app-search/current/facets-guide.html for some examples.