If all filters update the results dynamically, do you still need a 'Show Results' button?

Question

If you have a table of results with an associated filter panel and all the data is able to be filtered dynamically 'live' when the user selects anything, do you still need a 'Show Results' button? Even a 'Search' field can potentially work dynamically too, depending on how the data is retrieved / stored in the backend).

I'm still of the belief that applications should still work if JavaScript isn't running, but this might be an outdated mindset. In that case a button would be required in order to update the results.

Also, from an accessibility perspective it isn't clear that the results will update as they're going (particularly if the filter panel is large and the results appear below the fold), so a button that basically just scrolls the page down to the results or contracts the filter panel to make the most of the screen real-estate also feels appropriate - however this does mean the button is no longer actually triggering the filters, so it's a little misleading (is that even a problem though?)

Is a 'Show Results' button really necessary these days?

Answer 1

I don't think the button is necessary, but at the same time I think the selection mode of each filter should show a more advanced methodology of how the type of search is carried out, so that it's more implicit the results appear dynamically.

A clear example is the myfonts.com filter system where there's no SHOW RESULTS button but the filters at the top have sliders that favors the perception that it's acting automatically. Even with the possibility of slider and text fields for the same filter, where both the slider and the text edition update the filter's result automatically.

I think the option is: when removing a relevant element, offer a better alternative.

Answer 2

I don’t believe a button for “Show results” is necessary IF:

You show the selected filter options on the results page or panel, preferably at the top, and if possible, show a total that says something like “total results (filtered)” besides the selected filtered options. And I think this is a good idea even with a “Show results” button.

The example of my fonts.com provided by the other answer here is a good example of what I’m talking about (cf. the blue bubbles that say “number of styles 1-105”, etc). This makes it very clear that results are being shown, and exactly which filters are added when, in response to user interaction.

However, these indicators should also be coupled with a numeric indicator of the (filtered) total, which would make it exceptionally clear to users of all levels and forms of accessibility that the results have in fact changed, and by what magnitude. Such a declaration can be read by screen readers, for example. (e.g. “103 filtered results. Filtered by size, where size is one to one hundred, filtered by weight, where weight is bold”).

A loading graphic + text between the filtered states can also help. If not on the whole page or results area, perhaps because it loads too quickly, you can at least make an obvious loading state or entry animation for the filter indicators themselves on the results page. For example, when a filter is changed, added, or removed, animate the updating/entry/exit of the element (the blue bubble in the myfonts.com example), making it “pop” or “slide” or appear after a spinner runs for a second in its place before showing it. It’s all about feedback.

One other thing in the myfonts.com example that is useful in conjunction with the above is changing the style of the selected filters on the filter panel itself—notice how the selected filters shown on the results panel in the blue bubbles are shown in the filters panel with blue check marks, with a kind of “active” state style. The stylistic coordination and highlighting of the selected filters works well.

I think all of these things together definitely make up for any lost usability.

As far as not having JavaScript enabled, it depends on how you’re doing everything else. If you have a fallback mode where users without JavaScript enabled can still send a POST request to the server and get back a new page, then in that mode, where you detect whether users have JavaScript enabled or not, just show button for “show results” to submit the form. If they do have JavaScript enabled, then you can hide the button and include the UX features I recommended above.

Edit: I’m new to posting here, but I’ve been doing this professionally for 25 years.

Answer 3

There are a few reasons to still show a button (and allowing changes only on clicking that button or pressing enter). Let me elaborate on those reasons:

Problem: Table filters are usually above the table as the table often needs all the width it can get. This means that changes to the data set can happen out of the viewport and left unnoticed. This also counts for changes to the filter that had no effect on the results.

Solution: Notify the user when the filter is busy loading data. Use a spinner or progress bar for example. When the filter is done loading show a message with the amount of found items: "Filter active: found 12 items (shown below)". You don't even have to auto-scroll, which is very annoying especially when directly loading data on input changes.

This would mean that the spinner/progress bar should reset on every change made. A button makes it a more explicit choice by the user to interrupt the search.

I would always opt for having a button unless there are just a few filters and changes are quick enough to make the spinner flicker (show/hide/show/hide). Still account for network issues and show that spinner (maybe after a few seconds) and add error messages when it totally fails. When that happens, a button is also a good backup and loads the results with a page reload. But it isn't only helpful on errors: It is possible users are able to interact with the page while javascript is not loaded yet (again: network issues can be in play).

---

A note on the <noscript> element:

More and more web applications are build on complex javascript frameworks and fully rely on them. Most of those frameworks have built-in accessibility solutions so there is really a very small amount of users that can't access the application. Sites that needs to account for non-javascript clients should not rely on javascript. Like the submit button for the filter, it can easily have a form element with a target attribute, but when javascript is enabled it will prevent it from reload and use AJAX to get the data in the background. More complex javascript applications should not allow non-javascript clients. For those users the noscript element can still show a message that javascript is needed. Putting noscript elements everywhere is no option as it will make the application difficult to maintain.

Answer 4

You can separate the Filters and Search. Filter data can be populated in the result table when filters are changed without any call to action button. Once you get the results, use the search filed inside the table to further narrow down your result.

For filter applied again and results update simple show message with overlay on the table for few seconds(2-3) The overlay with the message will act as an indicator that the filters are applied/changed and results are update.

Hope that helps!