Filtering Results: Parallel Selection: Checkboxes vs Links

Question

I'm trying to resolve a discussion with a colleague and gain some insight into a common practice for search refinement behavior.

I've read Best Practices for Designing Faceted Search Filters and seen some discussions that touch upon the subject, but I've yet to encounter anything regarding what I conceive to be a misuse of form elements.

Granted, when offering multiple selection choices in a standard form, one would use checkboxes. I also understand how checkboxes found their way into result refinement menus; after all, when offering a parallel selection you should make it apparent that multiple selections are available.

Here's where I need some help:

Correct me if I'm wrong on this– I believe that when using form elements, which happens, well, in a <form>, you must provide a submit button (W3C reference). That being the case, how come an exception is made by numerous websites in the instance of refining results using parallel selection? I'm talking specifically about auto-refreshing results when a refinement checkbox is checked buy the user.

Is this not a case of inherently misusing form elements? I mean, if a form requires a submit button and since checkboxes are not intended to initiate a form submission, how come many sites override the default behavior as such? It seems to be more ideal to eliminate the checkboxes for parallel selection.

Answer 1

I do not believe it is a misuse of form elements, because in the W3C reference you provided the following stood out to me:

• The intended use of a submit button is to generate an HTTP request that submits data entered in a form

However in the Test section (emphasis added):

• If [having a submit button] is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

What we have is a requirement that "an HTTP request [...] submits data entered into a form" and one technique is to use a submit button. If that is the technique you choose to use, then to test you would verify that every form has a submit button.

However, using a client side script to auto-refresh the results on user click of the element is another technique that satisfies the requirement of sending an HTTP request.

The real question is: what is best for the user?

Automatically refreshing the facets and the results has a specific use case that makes it a valid technique appropriate for certain use cases. If by selecting a facet the resulting dataset does not include some of the other facets, then you need to indicate that to the user and prevent them from selecting them.

After each selection, auto refresh will give immediate and accurate feedback to the user. It informs them that by selecting option A you have eliminated option B from your search and prevents them from taking an action that would result in an invalid/undesired state.

This is exactly what faceted searches are good for -- eliminating irrelevant data from your user's experience.

Using a submit button where you wait for a user-initiated post back it can be argued that it would require more clicking and more messaging explaining that no results for the user defined facets exist. The user would not be served as well by this design.

When designing interactions for real people trying to achieve real goals, the letter of any specification is more of a guideline. Knowing the rules and following them is a good practice, but it is also your prerogative to "break" those rules when it would result in a better experience.

Although in this case, I don't really agree that it is a "rule" that you have to have a submit button as the language in your link implies it is just one technique without specifying alternatives.