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?
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?
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.
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.
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
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
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!