Complex Filters UX
Too often dealing with filters can be frustrating. Let’s get them right. That means never freeze the UI on a single input, provide text input fallback and never auto-scroll users on a single input. Here’s why.
Dealing with complex filters in enterprise environments can be quite a challenge. Usually we know where to place them, but not necessarily how to show them. What if you have literally hundreds of these filters? Showing them all at once might be quite intimidating, to say the least.
FinViz, a financial stocks screener, appears to be quite complex.
FinViz, a popular financial stock screener, is an example of just that. Our first hunch would be to regroup filters, break them down, reorganize, reshuffle. That’s an important step, but it’s probably not going to be enough.
Drop-downs are rarely a good idea, they are slow and perform poorly in usability tests. The sheer amount of filters is overwhelming. And choosing the right option is tiring at best.
What’s the alternative? Well, we can’t remove complexity, but we can orchestrate it better, with better design. To do so, we query user’s intent and allow them to choose filters of interest, without overwhelming them with all available options.
Query Constructor Pattern #
Financial Times Screener uses an alternative approach for their equity screener. Rather than showing all filters at once, Financial Times groups all filters into click-through menus along with autocomplete suggestions. The UI queries user’s intent first, and hides complexity by default.
FT Screener: the screener that doesn’t show it all (by default).
Users have to specify relevant criteria first, and add them to the list of selected filters before changing them in all the fine detail. Additionally, FT suggests predefined equity screens in the sidebar that people can use and adjust if needed. No drop-downs in use here.
FT Screener, with a large click-through menu of filters that can be added to the list.
Horizontal Layers #
A common way to deal with complex filters is to allow users to construct filtering queries, rather than showing all available filters at once. While FT uses click-through-menus, we can also use a similar pattern to allow users to build their queries step-by-step in a sort of workflow constructor pattern, with one row indicating every applied filter.
Yahoo! Screener, with a workflow constructor-alike UI.
Yahoo! Finance Screener isn’t very different from FT. It also allows users to select the filters that they find relevant for them first, and the define the specifics for each of the filter. Rather than using click-through-menus, here overlays are used, along with search for every type of filter as well.
Filtering Overlay #
Airtable uses a very similar pattern, with the filtering overlay appearing on top of the data table. As filters are added, the overlay grows vertically, making best use of available horizontal space — each filter takes up the width of the entire content area.
Airtable uses an overlay to allow users to construct their filtering queries.
Trigger Condition Action #
Sometimes we end up with a slightly different kind of filtering though. You might have a trigger, that, based on a particular condition, might prompt a particular action. Rather than just filtering data, we define automated actions. The patterns listed above could be applied here, too.
Smartsheet with a visual constructor for triggering actions.
Smartsheet displays the constructor overlay in a separate view, with each trigger, condition and action receiving a dedicated collapsible card. Items of the same kind are grouped as they are added to the list. So everything finds its place in the UI. It’s complex, but not necessarily complicated.
IFFFT is simple: there are no drop-downs as users explore filters by clicking through cards. Large view.
Wrapping Up #
Filtering can be complicated if we expose all complexity to our users at once. However, more often than not it’s just unnecessary. We can allow users to choose what filters are relevant for them first, and show these filters when requested. We could use the same approach for forms, too.
Of course the techniques listed above might not be an ideal solution at all times, but if we have a lot of options, we can use it to reduce complexity of the interface, while leaving its functionality in tact. And that’s a good start.
