Vivareal.com.br recently ran a test, where they removed the Apply Filter button and instead updated the search results instantly (screenshot from goodui.org/evidence):
The results are weak but suggest a simple filter behavior might improve a deep metric like Leads (form submits). Given that many prominent sites are doing it, it gives the rest something to try. It also raises questions about what is the best implementation for a given site.
Progress Indicator Is Mandatory
On other sites, like Reverb.com, the transition is smooth. The search results go grey, then they populate in-place:
If search results take more than 200ms to update, use a spinner and/or grey out results, or use another progress indicator (see Jeff Johnson, 2010 for more on human timing requirements). Beyond that, the search filter won’t be perceived as instant and users will be off-put.
Autotrader.ca doesn’t show results instantly. To avoid confusion, they grey out the results and shows a green alert to confirm that user’s filter changes have not yet applied:
Page Refresh Or Not?
On many big sites like eBay and Amazon, filters behave as links. There is a delay and a full page refresh. Here’s eBay:
Some problems with this:
- The redirect always takes too long. And after a page refresh, I find I need a second to refocus and figure out what happened.
- I usually don’t find it obvious how to undo a filter or go back in that case, because the UI has changed. I’m probably not the only one.
- Change Blindness could obscure some important visual change (e.g., people may not notice that some other categories have been updated).
A page refresh may be necessary if there’s a long list of filters that goes past the fold. If you update listings immediately in that case, the top results could be out of sight, at the top. Many sites also update related categories and sub-filters based on the filter chosen, so essentially the whole page does have to change.
I would be very interested to see an alternative pattern to this that is less jarring, faster, and allows easy backtracking. For instance, an animated scroll back to the top may be a better option than a full page refresh in some cases.
Submit For Inputs Or Update As You Type
In the case of Reverb, notice there is a small submit button for the text inputs. All the other fields are instant, but you submit an input field manually when you’re done typing:
In contrast, on sites like Netflix and platforms like Apple TV, filter-as-you-type is heavily used and is very effective:
My recommendation is to use this only if you serve results FAST and if the search terms are bounded. For example, Netflix is a repository of movies and there are only so many movies that start with “Fast and”. So it’s a good solution for them. Likewise, on a stock site, showing the most common stocks might work, because stock symbols are a limited set.
Autocomplete
If filter-as-you-type is not feasible, consider using Autocomplete on the input fields. When using Autocomplete, you can delay showing results until enough characters are typed. And when you show matches, it’s text-only and right below, so it’s not distracting. Moreover, web users are all familiar with this pattern.
Reverb uses Autocomplete in its main search input on the home page, but not on the Keywords filter.
Do Not Freeze
When a search filter is clicked, it should not block the whole app. That is, a user could apply more filters while the previous ones are still fetching data. Similarly, removing a filter should apply opportunistically. For example, when I click an enabled checkbox filter, it should immediately show as “off”, even while the data is still being fetched.
Cache Results
If data sets take a long time to load, we should cache the results. That way when people undo a filter, we can go back to the previous view instantly. It may also be a good idea to keep the original results until new ones are ready. That way, if a user accidentally clicks a filter and then undoes it, you can just cancel the new lookup and show the original results.
Best For Simpler Searches
If a user is expected to enter multiple filters, then there is no point submitting after every search. A manual submit is best in this case. This is also true when there are many filters. For example, your basic search could be instant, but if the user pulls down the massive set of Advanced filters, then a submit button would be needed.
Also if the data set takes a long time to filter (because it’s vast or complex), a manual submit may be better. For example, the search filter for the ChemTrac municipal chemical data repository has an Apply button which filters a very busy map:
Estimate Search Time
It’s a good idea to log search times to see if it’s taking too long. If searches take more than 1 sec on average, then you could show the ETA using a progress indicator or countdown, rather than just a generic spinner. For example, the map for ChemTrac can take a few seconds to populate. Here’s what it might look like with an ETA:
What is your experience with Instant Filters?
Share your thoughts and additional criteria.