[RFC] Filter Functionality UI/UX Refactor Discussion

[jeremymeyers]

Reworking Filtering / Search / Sort - Faceted Navigation

This will be a discussion around making adjustments and improvements to the interface for filtering the content that Stash displays.

Abstract

It is generally accepted that the current iteration of the Filter UI, while functional, can be confusing and overwhelming. Any changes would need to accomplish the following things

• Make the selection of filter criteria more visual and intuitive
• Organize the filter criteria in a way that is easy to understand, from a layout and word choice perspective
• Make the ability to save and recall 'favorite' filter combinations more intuitive

Additionally, we should ensure clarity around how the Filters functionality interacts visually and in workflow with the Search functionality as well as the Sort functionality. We can start by thinking about the default Scenes display as a "Search with no criteria", after which the user can narrow down the display.

My thought is to combine these functionalities (at least in terms of how they are thought of) into one larger "Find And Display" process. This will require a refactoring of what the search box does and the longer-form interface to build a filter query

Organization

I suggest this be split into a few sections

• Filtering Look and Feel - How the overall filter interface is displayed, as well as how selected filters look
• Filter Results Look And Feel - How a page with filtered results is displayed, and how changes can be made
• Saved Filters Look And Feel - I think this should be part of a separate PR, honestly.
• Workflow - How one adds a filter criteria to the current view, how one saves filters, how one recalls filters

Specific Feature Suggestions

My own wishlist to be included as part of the refactor would be

• Using [RFC] Organize Scene Filter Dropdown #1545 as a starting point, categorize filters into easier-to-understand groupings. see https://www.nngroup.com/articles/filter-categories-values/ for research.
• A cleaner and more intuitive bucket for currently active filter criteria
• Visual differentiators (icons, colors) for filter types to make at-a-glance easier.

Examples

I like the concept of a horizontal filter bar that lives above the content (possibly with an alphabet filter bar below (#1129 ). See: https://baymard.com/blog/horizontal-filtering-sorting-design

• Specifically the Crate and Barrel example above spoke to me, since it has

1. A bunch of different criteria, mostly explicitly displayed with a "More..." button for rarer filter categories
2. A combination of dropdowns with text fields and checkboxes for each category which seems like it would translate well (other than an OR vs AND)
3. The opportunity to make the categories more visual

I dont think Kodi, Plex, EMBY or Jellyfin do an especially good job of this (emby in particualr does not appear to have filter functionality at all)

Challenges

• Some of the additions I've suggested here may increase the weight of pages that contain filters. Thinking specifically of pre-populating dropdowns and adding more visual elements

Other relevant tickets

#1297
#1028

Further Reading

• Designing User-Friendly Faceted Navigation
• Death To Complexity: How we simplified advanced search shows a specific method by which 'advanced search' was improved.
• Crafting a kickass filtering UX is a good resource for research and recommendations around filter and search design
• Makes recommendations around horizontal filter bars

[QxxxGit]

I'd also suggest a multi sort functionality if filters get a refactor. Right now the sort is restricted to a single option but it would be nice for the user to add multiple i.e. "order by most recent first then by o counter"

[stg-annon]

A suggestion for refactor:
pipe Type filters into each other to allow for filters to automatically be extended when a base filter is extended, for example currently SceneFilterType has 3 different attributes to filter performer attributes performer_tags, performer_favorite, performer_age

instead allow SceneFilterType to accept a PerformerFilterType this way when PerformerFilterType is extended its functionality is automatically a part of SceneFilterType

[echo6ix]

@WithoutPants cited this thread in a Discord discussion about a conceptual search/filter/toolbar sidebar interface meant to replace the current interface. I'll provide feedback here; it might be relevant constructive criticism going forward.

My main objection is the concept simply relocated the current implementation in a way that uses a lot more screen space. A one line div versus an entire column sidebar that offers the exact same functionality and information is a massive tradeoff imo. Any move to a sidebar will use more screen space and thus should add new features, information, and improve upon the existing model.

Cited motivations for relocating the current search/filter/toolbar interface to a sidebar

New users find the current search/toolbar difficult

What percentage of new users and is it a significant amount? What do they specifically find difficult and is there a better way to improve it aside from simply relocating the buttons with a text heading? We already have tooltips on the buttons and a help icon on the navbar. Granted I don't think that help section provides any clarification on the search/filter/toolbar interface.

Perhaps if we relocate some items such as the button pertaining to the number of pagination items, operations button, and page view options away from the filter/search, we will have freed up enough space to add the strings "Filter", "Sort", "Saved Filters" beside their respective buttons. More on relocating these items below.

The current search/toolbar requires users to scroll up to perform operations

This will be a tradeoff between having to expand/collapse the sidebar (not all viewports are large enough to have the sidebar open at all times) or to scroll to the top of the page. They're both relatively easy tasks.

Maybe a better way to accomplish this is a bit more radical. Imitating modern projects and modern file managers, we can consolidate all view options and operations into their respective overflow dropdown menu buttons located on the right side of the navbar. This resolves requiring scrolling to the top or a sidebar.

Possible objection: The navbar will start to get cluttered by adding two more icon buttons.

Possible resolution: Consolidate the view options menu button and operations menu button into a vertical ellipses dropdown menu button. Each section, view options and operations would be visually partitioned with a horizonal line on the menu dropdown. This is already common on context menus that visually partition a sets of related tasks. This also has the benefit of using one recognizable navbar to show a context dependent menu dropdown throughout Stash that contains page tasks, view options, operations, etc. It basically trains the user to also go to that navbar button for page dependent options/tasks.

Active filters take up too much space on small mobile viewports

If a solution to this is to move the active filters to a collapsible sidebar that's hidden by default on small viewports, then similarly the solution to the current interface can be the same: collapse the div of active filters on small viewports into a button that expands/collapses their visibility.

Other ideas to reduce clutter/usage of space in this area of the UI

Relocate the items per page drop down form.

This button pertains to pagination, and (I think) the logical position of this button belongs on the pagination div, as the last button the div.

Replace the First, Previous, Next, and Last pagination buttons

To further reduce button sizes and overall clutter, we can replace the aforementioned pagination strings with their universal corresponding Unicode symbols. Previous <, Next >, First «, Last ».

[WithoutPants]

In my opinion/experience, the filtering use case flow definitely needs refining. One of the most common use cases I encounter in general use is to filter by tags, performers and studios. As is it currently, it takes 6 clicks to filter on one performer, and another 6 to filter further on studio. It's very onerous. In fact, I can do the first part quicker by clicking the performers page link, finding the performer (assuming they're on the first page) and clicking the scenes link. A minimum of two clicks.

I think the concept screenshot shown in the original post is a good starting point. Performers, Studios and Tags should be directly filterable, and other - more specialised - filter criteria should be behind a dialog. We could further expand this by only showing performers/studios/tags that have results and potentially a count. This would obviously require backend changes and would depend on the performance impact.

I agree that the active filters do take up too much space. I don't currently have a solution for this problem.

I have encountered the issue of having to scroll up to perform operations on selected objects. My preference here is to show a sticky control that gives access to the select all/none and operations buttons that only shows when at least one object is selected.

Note that we already replace the wordy pagination buttons with symbols on the smallest viewports.

[jeremymeyers]

Hey y'all-

I haven't had the time to be on discord or helping out lately but hope to be able to get back to it.

What the current filter interface does well is put a ton of functionality into a relatively compact interface. It does this by basically functioning as an SQL query builder with a bit of UI on top.

It doesn't do a great job of being end-user-friendly to people who aren t already familiar with how queries are built. And not to be crass or whatever, but often times when people are using stash they aren't exactly in a prime intellectual mental state for computations.

I would argue having everything in a dropdown gives things like "bit rate" and "performer" the same functional weight when in fact performer is much more likely to be needed. It also doesn't do a super job making the "you are building a query piece by piece composed of a combination of criteria and then you can save it" obvious.

I went through the archives of when I was putting together this RFC and realized I'd messed around with a more friendly query builder-style filter interface that I wanted to share here. I think this is possibly a lateral move in terms of functionality but also possibly an opportunity to improve usability.

As usual this is not at all a design recommendation (i'm aware that this is ...big.) but more of a "what if we made the existing concept more visual". It would need to be tweaked depending on which section a user is on, of course.

I hope this is helpful and will try to follow along as my time permits.

[cj12312021]

I think the nav bar should be a static item. It shouldn't transform based on what page you are viewing.

I feel people tend to overlook the presentation on mobile. All proposals need to transition well on mobile devices. Horizontal toolbars tend not to do well on mobile. I was looking through the link mentioned in the original post to find sites that still used a horizontal toolbar. Crate & Barrel and Nordstrom were mentioned as a site with a horizontal toolbar but looking at those sites today it seems like they updated it to use a sidebar. If anyone knows of a site that does the horizontal toolbar well, I'd love to play around with it.

Adult Time has been mentioned a few times as one of the most user-friendly sites out there. I know most won't be willing to pay for the sub to try out Adult Time's system, so I'll post a video on discord showing me navigating it. The video can be found here: https://discord.com/channels/559159668438728723/644934273459290145/983594433134067722. Their system is a bit worse in that they don't allow you to select multiple items from each category, but that is an area where we could improve. In our case, each filter type in the add filters menu could have a button on the sidebar that, when clicked, could display selection options directly on the sidebar instead of in a pop-up window.

WithoutPants edit:

[cj12312021]

Here is a rough horizontal toolbar concept I was playing around with in just CSS. I initially thought we could expand on it and be more verbose similar to the concept mentioned in the original post. On mobile, that would still need to be broken apart vertically. Note that that concept initiated the conversations that led to the sidebar concept I worked on. I think good feedback was given there on the subject.
https://discord.com/channels/559159668438728723/644934273459290145/982032316257931265

[echo6ix]

Adult Time has been mentioned a few times as one of the most user-friendly sites out there. I know most won't be willing to pay for the sub to try out Adult Time's system, so I'll post a video on discord showing me navigating it. The video can be found here: https://discord.com/channels/559159668438728723/644934273459290145/983594433134067722.

👍

Adult Time's implementation looks very good. It's concise (only relates to filtering), does not take up much space horizontally, yet it doesn't look like it compromises information, and it's very aesthetically pleasing -- it doesn't stand out, it's basically the same background color of the page. How does it look on a mobile viewport?

---

I've chosen two mobile apps that we might draw influence from because filtering is an integral part of their apps: eBay and Amazon.

eBay's mobile filter

Figure 1 - Filter button located at the top of the view port. Active filters aren't displayed, but a numerical indicator adject to the filter button displays the number of active filters applied.

Figure 2 - Screen shot displaying how filters are applied in a popup sidebar containing filter options.

Amazon's mobile filter with active filters displayed

Amazon is similar to eBay. Filter button located at the top of view port. A numerical indicator adjacent to the filter button displays the number of active filters. Amazon also has a unique and concise way of displaying active filters. See below.

Figure 3 - List of active filters are displayed as chips to the left of the filter button. Overflow chips are hidden but the user can see them by swiping left and right to scroll through all the active filters.

[cj12312021]

This link shows off how Adult Times system appears on mobile https://discord.com/channels/559159668438728723/644934273459290145/984911367930777631.

WithoutPants edit:

[cj12312021]

I'm posting an image of the design I was working on for reference:

[0xb0af]

This might be way out of left field but has anyone considered/proposed a filter query language based on boolean construction? This is presumably similar to how filters already work internally, but exposing it to the user via text would allow queries to be constructed much fast.

Let's say I want all videos of blondes under a minute. Currently I would click Filter, click the dropdown, find Duration in the list, click the comparison dropdown, find Is Less Than in the list, click the duration text field, highlight the current contents, press backspace to clear it, type 60, then click Add Filter. Then I would click filter again, open the dropdown and select Tags, open the second dropdown and select Includes, then open the third dropdown and select my tag for Blonde, and finally click Add Filter.

Imagine if instead I could go to the search box, type duration < 60 and tags includes blonde and press Return. If boolean logic was implemented correctly for 'and' then adding 'or' would be trivial.

A small bonus would be that (if the search terms corresponding to the currently-displayed results were displayed in the search box), this would also serve the function currently handled by the badge that gets created in between the search bar and the results that says Duration is less than 1:00

[pickleahead]

What do you think about a customisable navigation based on filters? The idea is to let users build their own filter navigation and leave the current filtering form for edge cases. Saved filters wouldn‘t be a simple list anymore, but a flexible and user friendly navigation. Of course there could be common presets too.

For example:

• Add a new menu item
• Set filter property to „performer“
• Set filter query options
• Set display to „list“
• Resulting in an expandable navigation item with a list of all performers

An item could be a single button for a single predefined filter (e.g. „4K“), a list of items (e.g. „performers“, „saved filters“), a filtered list of items (e.g. picked „tags“) or a tree of items (e.g. „studios“ with child studios).

In case users or profiles get implemented, each user or profile could have its own filter navigation. Would be awesome for multiple users or those, who use one database for big dividing categories. For example 2D and VR content.

[xx790]

I don't think most storefront filters are a good match. It seems to me they are likely to have the same flaw current filter system has - they are not very composable.

I think the current implementation is half-way there with "filter chips" (in Material Design terms, see their data tables with stackable filters). In theory it should allow to stack (compose with AND condition, narrow down) multiple independent conditions. (#2692 prevents it from being fully useful. I also have an issue with NULLs: #3159)

The way you add new "chips" or edit existing ones is where most UI improvement could be made compared to the current implementation.

I would definitely keep a panel for added filter chips (just tweaked it to look nicer) but think how addition of new conditions and editing of existing ones should look like.

(Update: the screenshot above includes the "Active filters" section and seems well organized. The most intriguing part, apparently, is going to be in a modal dialog behind "Add filter")

---

There is an interesting UI pattern used in old Discord role permissions screen - a set of buttons that allow to set behavior for an individual entity:
[+][/][-] - one of three (radio)buttons can be active, meaning Enable/Inherit/Disable accordingly. This might be adopted for a tag list or other properties with discrete set of options as Include/Ignore/Exclude.
Another related example - tag "chips" in Booru Nav Android app:
[-] tag [x] - allows to invert active tag condition or exclude it from query.

[xx790]

Query language is how I would've approached an MVP.
This is very natural for everyone interacted with boorus. But I guess the goal for Stash is to be friendly for "normies" as well. And also developing for GraphQL first, forcing a rigid query structure...

I wonder if there is any implementation in the wild that would look like Scratch for binary expressions, drawing bubbles instead of parentheses for AND/OR expressions...

Update:
There is an open request for query syntax:

• Query syntax #185

[DogmaDragon]

If anyone knows of a site that does the horizontal toolbar well, I'd love to play around with it.

IKEA uses a mix. Horizontal with the universal filters (fits all categories) and popout vertical toolbar for a full list.
E.g. https://www.ikea.com/nl/en/cat/bookcases-shelving-units-st002/

[DogmaDragon]

I was unhappy with the original concept of a vertical sidebar. While it does provide a lot more space for the page content hiding everything in a collapsible sidebar can easily lead to repetitive clicks just to change a viewing mode or adjust sort order where default filtering is not available.

So my immediate thought was to make it a split system. Though upon thinking about it more, I agree that a well-structured sidebar can be both practical and functional. My main issue with the current layout is pagination, it's cumbersome and takes up a lot of space. Replacing it with an infinite scroll would be ideal as it removes the need for a pagination bar while keeping all the functionality. Some visuals to illustrate my idea.

1. uses a button to open the sidebar
   
2. uses a "divider" similar to how the scene page allows collapsing certain sections
   

I'm not entirely happy with my own idea since it still keeps a whole row, but I can't think of a practical way to fill it without empty space while keeping view modes, not inside a sidebar. While #2122 (comment) suggestion of moving everything to the menu dropdown is very clean looking, I'm not sure how easy and practical it would be to use.

[0xb0af]

I would argue having everything in a dropdown gives things like "bit rate" and "performer" the same functional weight when in fact performer is much more likely to be needed. It also doesn't do a super job making the "you are building a query piece by piece composed of a combination of criteria and then you can save it" obvious.

This hits the nail on the head. Also agree strongly with WithoutPants

As is it currently, it takes 6 clicks to filter on one performer, and another 6 to filter further on studio. It's very onerous.

The best test for any replacement will be to watch how new users use it -- how many clicks does it take someone new to do the top 2-3 most common tasks.