Dude, these are great, ignore the haters. People understand slider toggles and, for top level, high value on/off values or mobile versions of a UI these will be fine.
Just keep polishing them and getting them cross browser. I'll be forking the project and using them.
I'd like to second this sentiment. Instead of tearing down someone's significant effort to build something cool, the community should constructively communicate their issues with the project and offer suggestions for improvement.
I was personally impressed that drag actions were supported, because that's a frequently overlooked aspect when people roll their own slider toggles. Without looking at the source, I would guess that implementing mobile touch events would go a long way towards making this library cross-browser.
I feel that there is a mix of legitimate criticism and “hating.” Of course I don't like to read the actual hating, but I also don't understand why we on HN should unquestioningly praise everything posted here simple because someone worked on it.
I would strongly advice against using these. While these type of toggle switches work great on mobile, they can we really confusing on desktop/mobile web: where does one click to change state, which state is active etc.
That article is about a particular implementation of toggle switches that makes a number of usability mistakes. He contrasts that implementation with iOS' implementation, and highlights how the iOS version avoids these mistakes.
The buttons linked follow the example from iOS and avoid the mistakes he talks about.
It's actually poor UX for desktop users too. It is possible to slide the buttons with a mouse drag and have them fail to change state. I see this behavior on many sites trying to optimize for mobile, but it degrades the desktop UX.
I had toggles like this on my site and found that a checkbox was a lot less confusing. It is just too hard to tell if state is successfully saved and if clicking things turns it on or off.
The behavior I ended up implementing is... when the box is clicked, it is immediately hidden and replaced with a loading animation while the ajax request is hitting the server saving state. When that finishes, it shows a icon-thumbs-up for a second and then the checkbox again (either checked or unchecked).
I'm wary of these, because form elements tend to be very, very very veryvery platform-dependent, and users (like me!) develop expectations about how toggles (i.e., checkboxes) should behave on the platform they're using.
I know this isn't your intent, but when the behavior of something like this fails to match my expectations, it is extra irritating, because I feel the author thought having something pretty and iOS-looking was more important than it being usable for me. Either that, or else s/he decided that I'm too stupid to know what I like, and decided to shove an iOS form-control down my throat.
That being said, I must admit that these are visually gorgeous, and their behavior seems pretty excellent at first blush. (But again, I am unsure how I will feel once I start seeing them pop up and inevitably being even slightly misused in the wild. I also haven't tried them on my phone yet.)
Mattia DMed me about this earlier today asking if it could be included in the Bootstrap core. For the time being, I've decided against it as it's another custom form element and we're not implementing anything like that at this point.
That said, if any iOS style switches were done very well, we can explore adding them down the line. I'm not against them 100%, but custom form elements can get tricky. I'm not going to discourage their development—tons of folks have created their own implementation of this. I look forward to them improving over time.
Looking at this again, I'll try to shoot him some feedback so he can improve them and we can get closer to a solution that's fit for the Bootstrap core.
I'm mixed on using these buttons. I've seen people in user research tests use them well, and then I've seen people use them horribly in such a situation too. However, there are times when they're perfectly acceptable.
I've forked and pull requested.
The background states were light at the top and darker at the bottom giving a button feel, rather than an inset feel. :)
These are terrible for ui/ux. not only do they not behave as you would expect, by actually sliding Them, but this pattern is inconsistent with mobile ui native to both IOS and especially android recently where they actually slide.
Someone should come up with an unofficial list of all these bootstrap additions. They're really great, but I always forget about them when I'm actually get to doing work.
I'm the creator of Bootsnipp.com and I will put a nice centralized resources page on bootsnipp soon, right now I have all the resources in the Bootsnipp twitter account @bootsnipp. Hopefully that will be helpful!
It seems to me that the on state of the button should have the outline around the blue area (of the default button) also be blue instead of gray. Keeping the border gray when the slider goes to "on" gives the button the wrong appearance. The blue area doesn't look like it has been uncovered but instead looks like a tab sticking out of the side.
Awesome, one suggestion I would make is that the buttons should ignore input in when translating between on and off. It seems awkward that it will just keep switching on and off even though I have stop giving it input, or accidentally double clicking on it and set it back to what ever it was.
[+] [-] carsongross|13 years ago|reply
Just keep polishing them and getting them cross browser. I'll be forking the project and using them.
[+] [-] brendn|13 years ago|reply
I was personally impressed that drag actions were supported, because that's a frequently overlooked aspect when people roll their own slider toggles. Without looking at the source, I would guess that implementing mobile touch events would go a long way towards making this library cross-browser.
[+] [-] notJim|13 years ago|reply
[+] [-] jorde|13 years ago|reply
Matt Gemmell wrote a good post about toggle switches some time ago: http://mattgemmell.com/2011/11/01/on-off-switches/
[+] [-] notJim|13 years ago|reply
The buttons linked follow the example from iOS and avoid the mistakes he talks about.
[+] [-] mybuddymichael|13 years ago|reply
[+] [-] bmuon|13 years ago|reply
[+] [-] tricolon|13 years ago|reply
[+] [-] southpolesteve|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] latchkey|13 years ago|reply
The behavior I ended up implementing is... when the box is clicked, it is immediately hidden and replaced with a loading animation while the ajax request is hitting the server saving state. When that finishes, it shows a icon-thumbs-up for a second and then the checkbox again (either checked or unchecked).
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] notJim|13 years ago|reply
I know this isn't your intent, but when the behavior of something like this fails to match my expectations, it is extra irritating, because I feel the author thought having something pretty and iOS-looking was more important than it being usable for me. Either that, or else s/he decided that I'm too stupid to know what I like, and decided to shove an iOS form-control down my throat.
That being said, I must admit that these are visually gorgeous, and their behavior seems pretty excellent at first blush. (But again, I am unsure how I will feel once I start seeing them pop up and inevitably being even slightly misused in the wild. I also haven't tried them on my phone yet.)
[+] [-] dreamdu5t|13 years ago|reply
https://github.com/component/component https://github.com/component/component/wiki/F.A.Q
Twitter bootstrap isn't modular or supported by a package manager.
[+] [-] jfarmer|13 years ago|reply
The assumption that the "toggle" is 50% of the width is hard coded into the library. I went to change it and, holy cow, the code is a mess.
I got it to work, but had to disable the click-and-slide behavior.
Be warned if you decide to change any of its behavior!
[+] [-] a904guy|13 years ago|reply
Two things,
#1: If you modify the attribute checked of the input, the state doesn't change.
#2: I don't see a programmatic way of changing the state from your source without re-initializing all the elements?
[+] [-] fox91|13 years ago|reply
#2 You're right
[+] [-] markdotto|13 years ago|reply
That said, if any iOS style switches were done very well, we can explore adding them down the line. I'm not against them 100%, but custom form elements can get tricky. I'm not going to discourage their development—tons of folks have created their own implementation of this. I look forward to them improving over time.
Looking at this again, I'll try to shoot him some feedback so he can improve them and we can get closer to a solution that's fit for the Bootstrap core.
[+] [-] zachinglis|13 years ago|reply
I've forked and pull requested.
The background states were light at the top and darker at the bottom giving a button feel, rather than an inset feel. :)
[+] [-] hayksaakian|13 years ago|reply
[+] [-] arrowgunz|13 years ago|reply
[+] [-] J-H|13 years ago|reply
[+] [-] blaze33|13 years ago|reply
[+] [-] msurguy|13 years ago|reply
[+] [-] dmix|13 years ago|reply
[+] [-] shtylman|13 years ago|reply
[+] [-] maytc|13 years ago|reply
[+] [-] darronz|13 years ago|reply
[+] [-] ryduh|13 years ago|reply
[+] [-] synor|13 years ago|reply
[+] [-] Tyr42|13 years ago|reply
[+] [-] ripperdoc|13 years ago|reply
[+] [-] javajosh|13 years ago|reply