I have a slider - it's actually 2 jquery slider bars where the user can select 2 values, then press a button to go to the next page.

The question is do I really need a button or is it just taking up space without any real purpose?

enter image description here

  • Can you include an image of what you've got, or use the built-in wireframing tool to add a sketch? – dennislees Jun 1 '16 at 16:17
  • 77
    "then press a button to go to the next page." Without a button how would you go to the next page? Seems like you'd need it without further context. – DasBeasto Jun 1 '16 at 16:32
  • 5
    What does the next page do? Because whether you need the button depends on whether you need the page. – Jan Hudec Jun 2 '16 at 7:22
  • 8
    @JohnO You're thinking in terms of being technically feasible, DasBeasto is thinking in terms of the user. – icc97 Jun 2 '16 at 9:13
  • 7
    @JohnO "if both are set" - do sliders have an unset state? that's something i've never seen, and therefore bad UX even if you can conjure up an implementation. but then how do you differentiate a deliberate choice from an intermediate step made by the user on their way to their desired value? do you proceed after some arbitrary timeout since they last moved either slider? what's that timeout, and how does it accommodate people who prefer to work more slowly? there are a lot of reasons i could list that this seems like a really bad idea. – underscore_d Jun 4 '16 at 1:18

Keep the button

In this case the button is used for the user to tell the application to navigate to the next page. If you remove the button, you say in your comment above,

I don’t think that’s an issue — an auto postback would do it. I have code that wraps the sliders, so it’s possible to determine if both are set, and if so....

What if a user sets the first bar, then tries to slide the second to "8 months", they scroll over and drop it accidentally on "7 months"? Oops. Too late: the page goes off navigating to the next page retrieving data they do not want.

This violates Shneiderman's "Eight Golden Rules of Interface Design"

7 Support internal locus of control.

Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.

Let the user, not the system, initiate the action of navigating: keep the button.

  • 59
    Also what if the user likes the default options? There is no way to continue without jiggling the sliders to get the events to trigger. – Chro Jun 2 '16 at 8:54
  • 2
    @Chro Good point I hadn't even considered that, I imagine that'd be quite annoying – DasBeasto Jun 2 '16 at 10:53
  • 9
    +1. Never consider slider movement as a definitive action, in particular, never trigger hidinr a slider by its movement. – yo' Jun 3 '16 at 12:41
  • 1
    @icc97 True. But in this case I'd say drawing in a possible customer by making the process as thoughtless as possible (i.e. provide decent default values) would be a high priority. I think defaults on sliders + a button is the best option. – Chro Jun 3 '16 at 14:04
  • 1
    Consider adjusting any of the slider controls, much more both. The user needs to signal when they are finished with the inputs. – IT Gumby Jun 3 '16 at 17:37

I say dump the button but keep the results on the same page.

Those two sliders are something that users will want to experiment with. So rather than forcing them to go back to the start show them the results in the same page and then update them as they move the sliders.

This is obviously dependent on you being able to return results fast enough.

  • 9
    Very annoying, especially when you're in a low-bandwidth situation. And before you say "move to a first world country", try staying for a while in a hotel with mostly-broken wifi then get back to me. :) The more the web sticks to the "action and reaction" principle, the better. No need to make it more complex or "snazzy" than that. – Lightness Races in Orbit Jun 4 '16 at 23:49
  • 1
    @LightnessRacesinOrbit You're quite right - I did try to make the point in my answer. "This is obviously dependent on you being able to return results fast enough." – icc97 Jun 5 '16 at 19:40

Ask yourself instead "Do I need my interactions to be stateful?" What's the value in having the user go between pages? Does it make sense to have the sliders adjust whatever they adjust before the user goes to the next page? If not, then maybe you should have just one page and reactively update a result based on the user's tweaks. If a stateful approach does make sense, then by all means include a button to allow navigating between pages. You can try all you like to avoid forward and back buttons, but you'll end up doing lots of user testing just to find that everyone clearly understands a button that reads "Next Page >"

In the case of a loan calculator, personally I would be annoyed to not see a result immediately when the sliders are tweaked. I wouldn't be considering getting rid of the button, I would get rid of the sliders and leave them til the next page where the calculator obviously is. Trying to detect whether the sliders have been moved or not isn't going to be good user flow because you're making a false consensus about whether or not a user would feel the need to make any changes in the first place.

Start with a common set of parameters and give the common answer, and let the user interact or choose to not interact. Never assume that they will want to interact. Like this: http://www.nytimes.com/interactive/2014/your-money/student-loan-repayment-calculator.html

  • I completely get what you're saying - and the sliders are just a piece of design at this stage - a teaser, which is why I was contemplating not having a button. The user does need to go to another page where they could easily do the same thing, but it does seem like a common industry feature. – John O Jun 1 '16 at 17:03
  • Welcome to the site, @Wray. Can you clarify what you mean by "Never assume that they will want to interact"? – Graham Herrli Jun 1 '16 at 17:34
  • 1
    Assuming you did go to a single-page format, with slider events triggering immediate calculations, you may still want to consider a button. With an incremental control like a slider, if each movement causes a redraw/recalculation, anything short of instant feedback will be jarring. Also, in some cases a (short) delay between pressing a button and getting a result is desirable, since it gives the impression of a calculation being performed. – Harrison Paine Jun 2 '16 at 12:27
  • @GrahamHerrli Plenty of users would rather not be bothered to use a tool. Pre-filling the settings for a tool so that it doubles as a reference eases use for those users. Reference-like content is great for robotic users that will never click on anything such as search engines, screen readers, social media screen capture thumbnails, browsers' reader modes, site scrapers, RSS feeds, etc. Just the same as anyone hoping for a quick copy-paste, a quick print, or a quick answer. (also thanks for the welcome, i should have joined years ago) – Wray Bowling Jun 2 '16 at 15:52

How are the users going to know how to go to the next step?

Without the button you will confuse them because they won't know how to continue the process. Even worse how you are going to decide when to go to the next step in the process?

Imagine this scenario: the user is playing with the sliders to see the borrow options and suddenly the site loads the next page before the user has agreed on a sum to borrow. This will probably lead to immediate leaving of the site. Without a button you might pick the wrong time to transfer them to the next page of the process.

So don't try to be too minimalistic by excluding the call to action button, as this is essential part in your process.

Keep the button.

This is technique H32, satisfying success criterion 3.2.2 of WCAG 2.0.

This not only allows for a better UX for sighted users with no intellectual impairment (as many of the previous answers have stated), you're also making your site more accessible for the non-zero percentage of web users who don't fit into this category ;-).

The fundamental tradeoff

Number of clicks vs. user's control of navigation

If you want, you can remove the button and enable a quick correction mechanism on the following page in case the user makes an error as described by DasBeasto

If this is your landing page, it might make sense to have the button since the user is new to your design. But on any other page, having the sliders autosubmit values and show results instantaneously (JQuery, AJAX) is more intuitive

  • Care to elaborate ? – icequeentanz Jun 5 '16 at 1:21
  • See some of the higher-voted answers. – Lightness Races in Orbit Jun 5 '16 at 12:16
  • Why dont you give me a more elaborate answer. I have already read the other answers. Design questions do not come with a single answer - it's about applying principles and creatively coming up with a solution. I'd love to see some concrete rebuttal to my point. – icequeentanz Jun 6 '16 at 15:25
  • The higher-voted answers explain it perfectly well. I see no reason to duplicate that information here. – Lightness Races in Orbit Jun 6 '16 at 15:32

Just feel like I have to add a personal story:

Well, you know for example my smart phone is with an age of 5 years already pretty much outdated. And the touch functionality isn't working that consistent anymore (did it ever do?!).

It happens not that rarely that a slider just looses its grip while I'm still sliding. Then the browser its ~getting onto the next page~ is quiet a performance peak for my phone as well.

Now when a page I'm on would ever dare to take the losing grip of my finger to the slider as an command of going to the next page while the input is wrong anyway. I would just close the app and say to myself, "No you don't want to be customer of a service where the developers are THAT incompetent" (Nothing against you, that is just what I say to my self in such situations) and would never ever try to get into contact with this service/company.

SO: YES, YOU DO NEED IT!

  • 2
    This is a very long way of saying "You need the button because the user might accidentally let go of the slider too soon." – David Richerby Jun 5 '16 at 10:37
  • @DavidRicherby: Thats true, but I don't know enough about UI/UX to be able to do this break down. And before inducing wrong assumptions into my text I just wanted to make it an expression of a clear empirical expierience I had. – Zaibis Jun 6 '16 at 7:16

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.