Drop-down Filter - Submit button vs OnChange

Question

I have a dashboard that displays different table data based on a drop-down SELECT field. While I realize it's more efficient for calling the data from the database by having the user have to click a SUBMIT button to update the data but is it a better user experience if the data updates OnChange or with a Submit?

Answer 1

Traditionally, accessibility (e.g. W3C) standards have demanded that choices only be actioned when the user instructs the computer to do so. This means separating the choice (e.g. selection of radio buttons, check boxes or list boxes) from the actioning of this choice (e.g. a "submit" button).

There is also a general usability principle at work if you take this approach: help the user feel like they are always in control. When an interface changes immediately when a choice is made, it can feel like the computer has the control, not the human.

So, if I'm understanding things correctly, a button rather than OnChange will meet several goals. It will also degrade gracefully for those without Javascript (enabled).

Having said that, there is probably less of an issue with using OnChange if the selection can be easily "undone". Presumably this is the case in your situation: the user just keeps making selections and the data table refreshes, until they get the data they want.

All this assumes, however, that there is only one major choice to be made. If there are lots of different filters/selections, then this is another case where the submit button is probably more usable. Rather than the table being refreshed — and perhaps a call to the server and a pause — after every selection, the user can make all their choices then apply them at once.

Answer 2

If I get a page refresh upon OnChange sometimes it feels wonky. If I select something and then an AJAX spinner appears in the table data area that makes much more sense.

Answer 3

Balance the performance needs with the user needs. Many users expect OnChange to dynamically work, so they may be confused if nothing happens, especially if your associated submit button is small or understated.

One thing I saw work very well is to highlight the submit button OnChange. In other words, when they alter the drop down control, Ajax that submit button to be bright green, or pop up, or otherwise afford clicking. Once they click it, make it drab and uninteresting again since it won't do anything until the control changes.

As a corollary to this, make sure that it starts (the raw HTML/CSS) interesting and gets made drab by an OnLoad script, so that users with scripting disabled will see the button easily even without the animations.

Answer 4

For users - ajax is better. Animation should be shown while ajax call is working.

But you should send ajax calls not after every user click. If user will click space button on the beginning of typing or left arrow in the middle of the string - that means that string does not changed and ajax call is not necessary here.

Submit button should work too like sending ajax call if javascript is enabled or like simple submit action if javascript is disabled.

Good example: Google

Answer 5

I am a real advocate of OnChange refresh, when it comes to filters (but for navigation it's a horrific abuse!). The main reason is that when the user has chosen an item from the list, he explicitly tells you what he wants to see. Why wait for any further contemplation?

Usually, we wouldn't want to rush the system into motion too early, but changing of a filter is totally reversible. In contrast to @Formulate Information Design, I wouldn't see changing filter as an "action". Since no change has been made to the data, the user wouldn't normally feel that an action has been made. She it totally oblivious to the fact the system has fetched data from the server, and so she should be.

Having said all that, I think refreshing the filter by the OnChange event is better usability, and you should just check that the system responds in a sufficiently timely fashion. The experience is what should matter, and not volumes of information exchanged, or how much effort the computer has exerted.