Help users filter a list of items

[adamsilver]

Objective: let users filter a large number of items in a table such as a case list or something else like a timeline.

To make sure these designs are flexible and scalable we have tried to accommodate a large set of capabilities including search (see header), bulk actions, sorting (tables and other things), pagination, mobile, desktop in addition to filters. While also considering the varying levels of navigation and action buttons that may be present on screen.

We don't think there is a one-size-fits-all solution so there are a number of variants.

We explored filters that show above the list but this was difficult to lay out and accommodate a large set of filter options without resorting to select box menus (which are generally the least usable form control). And the filters then push the main information down the page which can be especially problematic when employing AJAX enhanced filters — not that we necessarily recommend using them until there is a clear user need.

So the way this filter works is by letting users batch select a number of options and then submitting them with a submit button (like any other form). Then the page will refresh with the filters applied and denoted in the “selected filters” section.

Users might arrive at the list by just navigating. Or users may search first. In the screens below users can only search for cases so the labelling is explicit. If search becomes more sophisticated we think there should be an interim page of all the entities (cases, users, events, payments, whatever) the search finds before being presented with filters because the information (and therefore their display) differs greatly across the entities.

[adamsilver]

Filtering a timeline (or something that's not a table)

[adamsilver]

Filtering a table. The table has bulk actions, sorting functionality and pagination.

This variant works the same way on big and small screens where the filter is toggled on and off and overlays the results.

Importantly, on mobile, the results are not completely obscured by the overlay.

The trade off with this variant (especially on larger screens) is that the filter is less discoverable and it's not currently clear which filters are applied when the filter is collapsed.

[adamsilver]

This variant shows the filters on the left. You may or may not need a toggle depending on your situation. For example, if it's a small table that doesn't need horizontal scrolling just show the filters when there's enough space.

[adamsilver]

@petegale and @johndoates asked me whether we need to show selected filters at the top.

Here's my answer:

Keeping selected filters in their original position alongside other selected filters is useful, because some users will remember where the filter was when they originally selected it.

We can help users by grouping the selected filters in a separate list at the top. This confirms to users that what they selected is being viewed. It also gives users easy access should they want to remove any of the active filters, without having to scroll through them scanning for the marked filters (some of which may be offscreen or collapsed)

[PeteWilliams]

With regards to selected filters being shown, I'd be more inclined to agree if these were on display permanently - so the user always has a strong reminder that there are filters applied, and what they are. Hiding this in the slide-away panel makes it less useful as you're already looking at filters rather than looking at your dataset and wondering why it doesn't look right.

You could potentially add them to the table view, but it might get a bit busy:

Also, I wonder if the 'Apply filters' button is necessary though? Thinking of other similar patterns users might be used to (Amazon, eBay, etc), they tend to apply the filter on click on the tickbox. I'd be a little concerned that people could miss this - especially as we effectively have a submit button before the form rather than at the end.

How are we thinking persistence would work here? When you go to another screen and come back, are your filters still applied? What about the next time you log in?

[adamsilver]

Thanks @PeteWilliams for this. I'll quote you and respond underneath...

With regards to selected filters being shown, I'd be more inclined to agree if these were on display permanently - so the user always has a strong reminder that there are filters applied, and what they are. Hiding this in the slide-away panel makes it less useful as you're already looking at filters rather than looking at your dataset and wondering why it doesn't look right.

Great point. We had/have the same concerns as you. Here's some thoughts about this:

(1) Our components allow users to have the filter panel constantly exposed on large viewports so they will be there. In other words, we don't have to let users toggle on big screens.

(2) If we were to let users toggle (on large screens), at least the user gets a little signifier that something is applied (via the button text) and that they were the ones who just applied the filters in the first place. Not ideal cognitively speaking like you say, but it's something. We could make this more obvious, through styling and placement (perhaps outside the button) for a simple iteration.

(3) It's really difficult to fit the selected filters on screen in a scalable way. But I think that's the first thing we should explore if we find in research that it's not working well enough. One idea could be to show selected filters on a separate “row” rather than trying to squeeze within the “action bar”.

Also, I wonder if the 'Apply filters' button is necessary though? Thinking of other similar patterns users might be used to (Amazon, eBay, etc), they tend to apply the filter on click on the tickbox. I'd be a little concerned that people could miss this - especially as we effectively have a submit button before the form rather than at the end.

Another great point. Dave House (GDS, formely GumTree), did some good research there which showed the same thing but going down that route is complex for a number of significant reasons. So I'd definitely like to avoid that before proving there's a problem in research.

How are we thinking persistence would work here? When you go to another screen and come back, are your filters still applied? What about the next time you log in?

Another great question. I don't think there is a one-size-fits-all solution to this. In some cases it would be good to persist perhaps, in others definitely not. Certainly, the problem you mentioned about selected filters becomes theoritically more problematic if filters persist. But I'd say overall, this definitely seems to be an “iteration 2 or 3” problem for me.

[adamsilver]

Pamela asked a question on slack...

“Have you got some thoughts on how this filter design would flex if the number of options increased?”

Yes—here's some of our thinking so far:

1. Potentially only show the most popular/useful options within each category
2. Make each category (such as Type) togglable (we have done a design)
3. Show the most popular/useful categories (in the design above we only have two categories, so not applicable)
4. Checkboxes are not the only filter option types — could use an autocomplete for example
5. It might be that, in the above example, we first let users toggle by “Type” before exposing “Status” as (some) statuses may depend on Type — again just for example

[PamelaWoods]

PUI won't be including this in MVP. Ready to be tested. Not likely to be in JUI by Dec 2018 to this level of detail. VH will use filtering and search for Admin users.

[adamsilver]

We've added the filter component, the pattern and some guidance. Will close this one for now.