When comparing a front-end jquery slider widget against a list of links that filter by price range, within the context of faceted searches that reduce the number of items in a catalogue, which of the two aforementioned interface elements is best when considering the speed at which a user can restrict the catalogue products to the range that represents the amount they want to spend?
Slider has more cognitive load for a user. Also interaction implementation using slider could lead to some time losses.
In a scenario when user keep in mind the intended price range for a product, possible issues are:
- User should constantly map the intended number and slider position. Even if the intended number is displayed in the slider, some users still will no just click but will slide there. The need of constant feedback loop leads to high cognitive load.
- Take into account space requirements for usable slider.
- Lack of visibility
- Immediate content loading on slider change will lead to content flickering and network load. So it's better to convince if the slider position is final. Add this waiting time to resources' loading time. So it could be time-critical for a user.
Having the set of price ranges as hyperlinks, user interaction consists of just two steps:
- Recognize needed link.
- Click it.
2 arguments in favor of sliders:
If I'm shopping for foo, I'm usually operating with an upper price boundary but not a lower one. Not always, but usually. A slider lets me keep my lower limit at $0 while I tweak my upper limit. Links to set price ranges force me to chunk out my search for the perfect foo (click link > scroll through lowest price range > click second lowest price range > scroll through ...) instead of getting all results together on one page.
Given how I use sliders in this context I have definitely (and I'd wager others have too) shopped with an initial spending limit and tweaked the upper limit higher since I wasn't satisfied with the results I got with my initial search. I decided I needed to spend more money to get what I wanted, which is a win for whatever store I'm buying from.
That said, I'd love if anyone had any data — or anecdata — on real-world results with the slider.
I just ran across this alternate design at newegg.com. Checkboxes for each price tier allow a wide range of prices to be selected for your search.
Note that in their implementation the page auto-reloads when you select a price range, which makes the specific use case I outlined above (selecting a wide range from the lowest price to a personal spending maximum) realllly annoying. Every. Click. Reload. Page. A live filter or a 'submit' button would mitigate that problem, though.
Sliders give free choice of the price range.
Problems with Sliders
However, since they are usually one of multiple criteria, and the majority of the screen should present results rather than the filter, they are usually quite small.
Picking a specific price requires pixel-perfect positioning (or - in case of a hard limit - isn't even achievable).
Range needs to be limited by other query aspects as to not having to span $.01 .. $10k in a single linear slider, but that often gives awkward steps.
Selecting $100..$200 might give exactly two results and hide dozens of options at $99.99.
Affordance is two drag-and-aim operation, vs. a single click.
Why would I even want to filter by price?
I might have a hard budget limit, or a soft one, "$99.99, not a cent more" vs. "about $100 for a quality kettle is fine"
An upper limit can also be used to rule out unwanted product features: I don't want an talking kettle with an integrated recipe browser.
A lower limit is usually used to exclude incorrect matches, e.g. I've searched for kettles, and get two pages of kettle stickers for $.99, or for a perceived minimum quality - I want a heavy duty kettle, not the flimsy mostly-plastic ones.
Note that price is often a convenient proxy for another attribute that's hard(er) to filter for.
Two sliders or a range slider are usually the simplest implementation.
Price ranges need either manual configuration, or a decent algorithm. A good algorithm can look for price clusters and automatically suggest meaningful ranges that actually reflect the available results.
$25..$75 (25 items) $89.99..$130 (30 items) $180 and up (12 items) [custom]
To vercome the fixed limits, a "custom range" popup can be used, employing large size sliders with "natural" steps and ideally immediate feedback how many results would be in that range.
Alternatively: Price is in almost all applications the primary sort condition. This could be exploited in the presentation of results.
When prices differe significantly, instead of showing all results, group by price range. E.g. instead of two pages of kettle stickers, show the top 5 and a link to "more for less than $1"
You could also provide navigation aids, e.g. when sorting by price, instead of page numbers, use a price indicator.
I would be okay with price sliders if the filtered results changes while the user is sliding, and user doesn't have to click another button to apply the filter.
Much like pricing slider on Heroku here https://www.heroku.com/pricing
As long as you can show apply filter while user is sliding the filter (assuming that all the data is already loaded), then slider will be helpful.
Otherwise, it will become even more tedious for the user to first move the slider by dragging his mouse, then you will download the filtered values and then show them.