Comments on: Creating the perfect slider http://lea.verou.me/2009/04/creating-the-perfect-slider/ Life at the bleeding edge (of web standards) Fri, 10 Feb 2012 07:25:15 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Lucas http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-439 Lucas Tue, 16 Jun 2009 02:26:29 +0000 http://leaverou.me/?p=321#comment-439 Sorry, I forgot about Opera. You can really tell that Google Chrome has been influenced by it. Sorry, I forgot about Opera. You can really tell that Google Chrome has been influenced by it.

]]> By: Naked Geese Reunion http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-283 Naked Geese Reunion Tue, 05 May 2009 08:23:55 +0000 http://leaverou.me/?p=321#comment-283 Opera for the win, then, is it? ; ) Opera for the win, then, is it? ; )

]]> By: Lucas http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-236 Lucas Sun, 03 May 2009 20:13:26 +0000 http://leaverou.me/?p=321#comment-236 One thing to keep in mind is to make sure it compatible with other web browsers like firefox, google chrome, and IE (eh!). One thing to keep in mind is to make sure it compatible with other web browsers like firefox, google chrome, and IE (eh!).

]]> By: Naked Geese Reunion http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-171 Naked Geese Reunion Sat, 25 Apr 2009 01:22:51 +0000 http://leaverou.me/?p=321#comment-171 Wholeheartedly agree with the last paragraph here; key mappings for something like a color picker is /definitely/ a bit over-the-top. However, I don't reckon this is still a big issue; the (ideal, in my opinion) Firefox functionality of returning focus to the element that got blur()'ed is easily imitated by keeping track of the last element of your color picker to receive focus. Wholeheartedly agree with the last paragraph here; key mappings for something like a color picker is /definitely/ a bit over-the-top. However, I don’t reckon this is still a big issue; the (ideal, in my opinion) Firefox functionality of returning focus to the element that got blur()’ed is easily imitated by keeping track of the last element of your color picker to receive focus.

]]> By: Lea Verou http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-170 Lea Verou Fri, 24 Apr 2009 18:00:00 +0000 http://leaverou.me/?p=321#comment-170 I wholeheartedly agree with your remarks and already had them in mind (exept the unit tests *blush* ). However they are mostly implementation guidelines, so they are a bit out of the scope of this article (which is usability for the end user). Valid points though, all of them. :) I wholeheartedly agree with your remarks and already had them in mind (exept the unit tests *blush* ). However they are mostly implementation guidelines, so they are a bit out of the scope of this article (which is usability for the end user). Valid points though, all of them. :)

]]> By: Lea Verou http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-169 Lea Verou Fri, 24 Apr 2009 17:48:35 +0000 http://leaverou.me/?p=321#comment-169 That's actually possible. The event.wheelDelta (or event.detail) does contain this information. However, there are differences across browsers (for instance Safari reports about 4 times larger deltas) that make it quite difficult to implement this without browser sniffing. :( That’s actually possible. The event.wheelDelta (or event.detail) does contain this information. However, there are differences across browsers (for instance Safari reports about 4 times larger deltas) that make it quite difficult to implement this without browser sniffing. :(

]]> By: Lea Verou http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-168 Lea Verou Fri, 24 Apr 2009 17:46:37 +0000 http://leaverou.me/?p=321#comment-168 If you design the slider for a particular form, and don't want to make it reusable, setting the focus on the form's submit button would be a good idea. However, there's not always 1 submit button on a form. Sometimes there are none, while other times there are more than one, so it's not really feasible for reusable sliders. As for the focus, in Firefox if the user presses Tab after blur() is called, then the focus goes to the element that previously had focus (in our case, the slider thumb). In IE, Opera and Webkit, what you describe happens (the tab sequence starts over). I think you're right, it doesn't seem very useful now that I think about it. However, I can't think of anything else that the user might want to do when hitting Esc while the slider is focused, and I also saw it in various other implementations, so I adapted it as well. Configurable keyboard mapping might be useful for redistributable widgets, so that the developer can set the keyboard mappings without altering the slider code. However, for the end user, it sounds a bit far-fetched (for most applications). If you design the slider for a particular form, and don’t want to make it reusable, setting the focus on the form’s submit button would be a good idea. However, there’s not always 1 submit button on a form. Sometimes there are none, while other times there are more than one, so it’s not really feasible for reusable sliders.

As for the focus, in Firefox if the user presses Tab after blur() is called, then the focus goes to the element that previously had focus (in our case, the slider thumb). In IE, Opera and Webkit, what you describe happens (the tab sequence starts over).

I think you’re right, it doesn’t seem very useful now that I think about it. However, I can’t think of anything else that the user might want to do when hitting Esc while the slider is focused, and I also saw it in various other implementations, so I adapted it as well.

Configurable keyboard mapping might be useful for redistributable widgets, so that the developer can set the keyboard mappings without altering the slider code. However, for the end user, it sounds a bit far-fetched (for most applications).

]]> By: Sander Aarts http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-167 Sander Aarts Fri, 24 Apr 2009 17:31:49 +0000 http://leaverou.me/?p=321#comment-167 But if the focus goes nowhere it means that people who use their keyboard to navigate will probably have to tab al the way from the top of the page to wherever they want to go. Maybe that's what you want, but perhaps it's more useful to set focus on the form submit button. Unless that one is right next to the slider anyway, cause then tab will do. Perhaps you can make it so that users can configure their own keyboard mapping ;-) But if the focus goes nowhere it means that people who use their keyboard to navigate will probably have to tab al the way from the top of the page to wherever they want to go. Maybe that’s what you want, but perhaps it’s more useful to set focus on the form submit button. Unless that one is right next to the slider anyway, cause then tab will do.

Perhaps you can make it so that users can configure their own keyboard mapping ;-)

]]> By: kangax http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-165 kangax Fri, 24 Apr 2009 16:45:48 +0000 http://leaverou.me/?p=321#comment-165 Another thing to have mind is to make slider degrade properly (for non-JS clients) ;) As far as implementation, I find callback/event-based widgets the most flexible and easy to use. For example, instead of specifying an input field where a current value would be populated, a user would instead subscribe to "onchange" event (or a callback). That event (or a callback) would carry a new value, which user would decide what to do with herself (and could, for example, format it before an actual output, or maybe do not even output but send to a server with a certain interval). Other additions to consider are multiple handles (e.g. for specifying ranges) and custom step values (e.g. making it possible to specify a range of 50-150 with a step of 25). Oh, and of course unit tests are a must for any serious script. Unfortunately, there are very few scripts on the web which pay attention to testing. Hope this helps. Another thing to have mind is to make slider degrade properly (for non-JS clients) ;)

As far as implementation, I find callback/event-based widgets the most flexible and easy to use. For example, instead of specifying an input field where a current value would be populated, a user would instead subscribe to “onchange” event (or a callback). That event (or a callback) would carry a new value, which user would decide what to do with herself (and could, for example, format it before an actual output, or maybe do not even output but send to a server with a certain interval).

Other additions to consider are multiple handles (e.g. for specifying ranges) and custom step values (e.g. making it possible to specify a range of 50-150 with a step of 25).

Oh, and of course unit tests are a must for any serious script. Unfortunately, there are very few scripts on the web which pay attention to testing.

Hope this helps.

]]> By: Naked Geese Reunion http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-164 Naked Geese Reunion Fri, 24 Apr 2009 08:00:55 +0000 http://leaverou.me/?p=321#comment-164 It is perhaps just me, but I've rather always wished a slider would respond to the "fierceness" of my mousewheel actions. That is, if I just carefully push it up one tick, I'd like for the value to increase by one; if, however, I executed a very abrupt and forceful scrolling of the mousewheel down, it'd be fantastic to see the value drop by twenty or so. Just a thought... : ) It is perhaps just me, but I’ve rather always wished a slider would respond to the “fierceness” of my mousewheel actions. That is, if I just carefully push it up one tick, I’d like for the value to increase by one; if, however, I executed a very abrupt and forceful scrolling of the mousewheel down, it’d be fantastic to see the value drop by twenty or so. Just a thought… : )

]]> By: Lea Verou http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-163 Lea Verou Fri, 24 Apr 2009 04:46:56 +0000 http://leaverou.me/?p=321#comment-163 Hi again Sander Arts! Thanks for commenting. :) I had a horizontal slider in mind, because this is what I actually wrote earlier. (since the results of the <a href="http://bit.ly/colorsurvey" rel="nofollow">color survey</a> so far display an inclination towards horizontal sliders) For vertical sliders, up and down arrow keys would be far more suitable, definitely! As for horizontal ones, I think the keyboard mappings you are suggesting seem equally as usable as mine (I still prefer mine, but it's a matter of personal taste). However, we are both speculating and judging from ourselves. The best way to determine which keyboard mappings are actually better would be a usability test. However that's not something easily done for such a purpose. "Putting the bar high" is an english expression AFAIK, but bare in mind that English isn't my native language either ;) As for where the focus goes, I basically call blur() when the user hits Esc, so it goes to ...nowhere (?). Hmmm... Hi again Sander Arts! Thanks for commenting. :)

I had a horizontal slider in mind, because this is what I actually wrote earlier. (since the results of the color survey so far display an inclination towards horizontal sliders) For vertical sliders, up and down arrow keys would be far more suitable, definitely!

As for horizontal ones, I think the keyboard mappings you are suggesting seem equally as usable as mine (I still prefer mine, but it’s a matter of personal taste). However, we are both speculating and judging from ourselves. The best way to determine which keyboard mappings are actually better would be a usability test. However that’s not something easily done for such a purpose.

“Putting the bar high” is an english expression AFAIK, but bare in mind that English isn’t my native language either ;)

As for where the focus goes, I basically call blur() when the user hits Esc, so it goes to …nowhere (?). Hmmm…

]]> By: Sander Aarts http://lea.verou.me/2009/04/creating-the-perfect-slider/#comment-162 Sander Aarts Fri, 24 Apr 2009 04:32:25 +0000 http://leaverou.me/?p=321#comment-162 Sounds great! Personally I find it quite hard to make good intuitive and usable interfaces and judging most websites/applications others do to. It's nice see you put the bar high (is this a real English expression or am I just thinking Dutch, writing English?). Some remarks though on the keyboard navigation: Why not use up/down arrow keys? I'd suggest the following keys: - left/right arrow: big steps - up/down arrow: small steps (fine tuning) - ctrl + left/right: min/max I associate the left/right arrow keys with bigger steps/more speed than the up/down keys, probably because they're farther apart (well on most keyboard I know of anyway). Enabling all kinds of sliding to be done using the arrow keys makes sure the user can hold her hand in one position. Home/End could still be an alternative for min/max for people who have problems pushing two buttons at the same time (maybe because they have only one hand). Where does the focus go when you hit Esc? cheers! Sounds great!
Personally I find it quite hard to make good intuitive and usable interfaces and judging most websites/applications others do to. It’s nice see you put the bar high (is this a real English expression or am I just thinking Dutch, writing English?).

Some remarks though on the keyboard navigation:
Why not use up/down arrow keys? I’d suggest the following keys:
- left/right arrow: big steps
- up/down arrow: small steps (fine tuning)
- ctrl + left/right: min/max

I associate the left/right arrow keys with bigger steps/more speed than the up/down keys, probably because they’re farther apart (well on most keyboard I know of anyway). Enabling all kinds of sliding to be done using the arrow keys makes sure the user can hold her hand in one position. Home/End could still be an alternative for min/max for people who have problems pushing two buttons at the same time (maybe because they have only one hand).

Where does the focus go when you hit Esc?

cheers!

]]>