"Tabs"-like GUI for filtering search results by kind / type

[towerofnix]

This is a suggestion by Makin (#hsmusic-chat) from May 2024:

slack (and now discord) has multiple tabs for result types, like "messages" "users" "channels". maybe the same could be done here for songs (default), artists, groups, flashes, etc

Lan added:

Oh neat, yeah. I think I'd want the default to be "all", unfiltered, but that's a pretty good UI for filtering down to the interesting kind. Not too hard to code either, actually.
[...]
It's a useful feature to have right away because, um, it's a very dumb kind of filter: the wiki can't make the wrong choice because you're making the choice. Of course it matters if a bunch of seemingly random tracks show up above the artist you're looking for, but it has much less impact if you can just click to get to the artists, dang it.

We added this filtering functionality by letting you type keywords like "album" or "artist" as part of the query, but there is no analogous graphical interface.

Basic presentation and behavior details:

• The interface we're expecting probably visually resembles Scratch: "pills" you can click to select a particular type to filter by.
• Filters are presented in a row above search results, beneath the input box.
• The filters row is only visible after results are available.
• The filters row is populated only with the relevant options.
  • No special-case for there being only one kind of result (e.g. only tracks, only artists). This is implied by there only being one filtering button.
• The default filter is no filter (all results).

Apart from clearly highlighting the chosen one, presentation after choosing a filter can go one of two ways:

1. Hide all other filters. Show an "(x)" pill/button to go back to all results. Could also be "(all results)" or - when hovered - "(x all results)". Left-aligned makes consistent click target, right-aligned lets us change the text when hovered (wouldn't displace the active filter).
2. Don't hide other filters. Keep a 100% stable interface i.e. nothing moves around, disappears, appears, etc. This requires an "All" pill at the front, which disables the filter. Main question is how to present the "All" filter before vs after you've chosen a filter: we don't want it to be distracting (if you weren't planning to use a filter anyway) but it still needs to be clearly active.

Technical background:

• ATM "kind" filtering is handled completely on the search-worker.js backend, not the sidebar-search.js frontend. This is basically fine wrt internal interfaces - we want any search frontend to be able to use this behavior - but the guts inside search-worker might need work.
• ATM "kind" filtering is based on the presence of a term (in kindTermSpec) in the search query, see processTerms. This is called by (basically) top-level queryGenericIndex and the resulting kind is queriedKind, processed later.

Technical details:

• We currently aren't stressing about performance wrt "does changing the filter re-perform the entire search". Searches are virtually instantaneous. That's the key factor, or we would consider it worth implementing kind filtering in DOM-land (i.e. the filtering behavior itself specialized for each frontend).
• There are two routes for providing the GUI-chosen filter to the search-worker.
  1. Add the relevant kind as a literal term/word into the query, invisibly. (Don't literally put it in the search input box, just combine before passing to wiki-search.)
  2. Provide the relevant kind as an additional option in the options arg for searchAll -> performSearchAction -> queryGenericIndex.
• Performing a search w/ kind filters has to always provide which filters are available under "all results", as if the search were performed w/o filter. This isn't that complicated to implement because filtering by kind is the very final step of search anyway. We need to get all the available kinds based on the unfiltered results, and return that as a list alongside the actual (filtered) search results.
• As usual the actual filter pills/buttons need to be generated as part of content generation code, not on the client. The labels have to be localized.
  • kindTermSpec probably needs to be accessible everywhere (see below too).

Pain in the ass details:

• If we keep "kind" filtering based on query terms, we have to at least basically integrate these two modes of filtering together.
• We figure this integration needs to be on the frontend. If you search "dog artist" then you're not going to get any results besides artists to begin with, so the filters will be "All" and "Artists" (or "Artists" and no filter). Both options show the same results.
  • Awareness on the frontend of filter kinds in the query means kindTermSpec needs to be moved somewhere accessible to both backend and frontend, although this would be useful in the first place anyway.
• Presentationally we can still show the filters row, but make it inert. No "All" or "all results" option, just show the term-recognized filter. And show a cue indicating the filter is because of a term in the query, just some language text. ("Filtered by your query" or something like that, "…because you wrote 'artist'", etc.)
• If we yeet "kind" filtering based on query terms, boo hoo. We don't want to, but strictly it is an option, and avoids the complexity above.
• If we use special keywords for "kind" filtering, like "kind:artist", we have the same integration complexity, but users will obviously never ever run into it by accident.
• If we integrate "kind" filtering based on query terms more tightly-magically, we can avoid the UI complexity. In this approach typing "dog artist" would replace the query in the input box with "dog" and automatically select the "artist" filter pill.
  • We do however need to figure out what to do when the typed filter isn't available in the results at all, i.e. "dog" comes up with no artist results (so there is no "artist" pill to select).
  • This is cool but IMO just too magic to work nicely. Editing a user's typed query is always going to be seen as taking away agency where it's most taken for granted, and that's a huge nope.

[towerofnix]

WRT integration w/ term-in-query: If we get fancy with contenteditable, we can cue/highlight the relevant term right inside the input box. I figure (-lan) we'll sweeping-animate a color: var(--primary-color) mask effect over this, and maybe boldly underline it. This effect should only happen after the search is activated and the results are available and shown—no effect while typing. (Obviously don't screw w/ cursor position / de-focus the input box after pressing enter.)

Also to note, "album" does not get picked up by kindTermSpec. This isn't exactly on purpose but it is worth being aware of - the particle (presumably fed to Flexsearch as "album"!) still works for matching the word "album" in whichever, uh, fields/properties search uses.