This is cool, but I really dislike those kinds of switches. Pretty, yes, but also confusing to users unfamiliar with them.

Say the switch is to the right, and then word ON is to the left. If you click the switch, it moves to the left. Does that mean you turned the switch on, since the switch moved to where the word "ON" was? Or does it mean the switch is off because now the word "OFF" is visible?

Even knowing the answer, as an only-occasional mobile user I still find these switches require extra cognitive load, which is not what you want from a UI element.

I feel like I have this argument on every project I'm involved in. Designers seem to love these switches but end-user testing has always been lukewarm as users can't quite tell the actual state.

I think there is a reason there is no HTML element for this and that zurb/bootstrap (and their earlier ilk) don't include them either.

But, given that I lose this argument every time I appreciate projects that make them easier to implement. Thanks for sharing.

Good point. On android the state is written on the slider itself, so that there's no question of what the state is.

If it says on it's on, when you slide it the other way it will no doubt be off.

I don't like these switches either, but I doubt they are generally confusing. They've been around for a long time in the physical world. http://blogs.hillandknowlton.com/scottmckenzie/files/2012/03...

It's easy to tell when a light switch has been turned on or off. Not quite as easy when the switch is on a settings option called "email me a digest every week" or similar.

Which is exactly when websites want users confused.

I remember Real Player had a bunch of 'opt-in' email options, they where in a scroll box. By default the visible ones where unticked, but if you scrolled down there where pages of preticked ones.

I would not rely on people reading that text... But usually the physical world gives you a bit more feedback on the actual state the switch controls. If the electricity just went out and you go to the fusebox and find a row of breakers where one is pointing the other way and says off, it's pretty obvious what it does - and you get immediate feedback when you flip it.

I doubt people really know ON/OFF by reading the text. More of a sense of alignment. In India, you don't have text on the switches. Also, it's opposite to the direction of the switches in US (Pressing down is ON). Further, if you have 2-way switches there is no way of labeling them.

I don't believe I have ever seen a switch like that (UK) so your comment isn't universal.

It's better to have the labels outside the control itself:

ON [--O] OFF

But that kind of defeats the purpose of the design in the first place.

I can't find the article but someone posted a rather elegant solution to this which basically involves cutting a hole in the switch so you can see the word beneath it.

My suggestion last time I commented on this was to do it like a real sliding switch, put the labels outside the control, something like:

  ON |XX  | OFF

(Where XX is the sliding part).

Yes, I remember reading that blog post. Couldn't find the link now. The author tried explaining various types of switches and provided best alternatives - one among those is having a hole in the switch. One more is having a 'push' effect on the switch.

Sorted!

It's easy to do it right: Put a hole in the sliding panel, so you can slide it over ON to "check" it and over OFF to "uncheck" it.

Simple checkboxes work really well. Get fancy with an addon if you need more than just a label http://jsfiddle.net/Ah6dz/

Why use jQuery for this when it can be done with CSS?

http://codepen.io/freshyill/pen/KavfD

This has actually been problematic for me and I'm sure others. I'm currently working on an app that is Angular based and trying as hard as I can to avoid a jQuery dependency, mostly because I have no direct use for it and would rather avoid the dependency as it is rather large in file size, actually my largest. I've gone through multiple states of 'this library fits my needs right now and is fast to implement, but I need jQuery' using it, then immediately placing a TODO to get rid of it ASAP when I have time to work something else into being what I want.

This comment shouldn't be taken as a rant or complaint, I know why the current state of libraries is what it is, just an observation that jQuery seems to be, at least for me, transitioning from being 'an assumption' into 'the thing I want to get rid of'.

I could be wrong, but if you use a CDN, won't jQuery be already cached for 99% of users? I can definitely imagine that filesize is an issue with less popular frameworks, but I'd wager that it really doesn't matter with jQuery.

If anyone has statistics on this, I'd love to see them!

You're in fact wrong, the chance that users will have exactly the same version of jQuery cached is pretty small. [1] If you want to read more about jQuery on cdns, there is a long discussion on html5boilerplate github page. [2]

[1] http://statichtml.com/2011/google-ajax-libraries-caching.htm...

[2] https://github.com/h5bp/html5-boilerplate/pull/1327

Well dang, thanks for pointing out my error and providing sources to back it up.

If you are using Angular already, you have a lite jQuery lib loaded. Perhaps it covers the cases you want to use jQuery for?

http://docs.angularjs.org/api/angular.element

I've tried this but have found that in almost all cases jqLite doesn't implement something needed for a given lib. Moreover, a single lib not working with jqLite spoils the entire thing.

For Angular there's https://github.com/import-io/angular-toggle-switch

That switch isn't draggable. It becomes a UX antipattern – a false affordance – if you can't swipe it on/off.

You know, I forgot that people actually drag these things. Now that you can't get with CSS, as far as I'm aware.

It's draggable for me (on Chrome).

Looking at the source itself, there's no way it's "draggable" unless you're just toggling it coincidentally with drag gestures. Perhaps your drags are just coinciding with the 0.3s ease animation, or we have a different expectation of what it means to drag a switch…in iOS, those types of switches will follow the finger's drag motion, not just be toggled by the existence of one.

I definitely didn't make it to be draggable. When I made it, I wasn't even thinking that people actually did that.

Confirming draggable for me too. Chrome version 28.0.1500.95 on Fedora Linux 17. It probably means nothing at all but it only works if my cursor stays on the "label" bit. If I move the cursor up or down off the label while dragging it snaps to whichever option is closest

* Missed the bit where I can drag it halfway one way and then back to the original position

It's not draggable for me on Chrome. Version 28.

:checked isn't supported in oldie

The phrasing "Switch on" is terrible: are you telling me that the switch is currently "on" or that clicking it will turn it on?

That's why I made it so easily customizable. Generally, you'd probably want to have more of a label or some context for a control like this. In this case, if you're smart about the wording, it can serve as its own label.

Think of the light switches in your house. They do have a label (look closely), but there's also context: By switching it one way or the other, you'll immediately see the effect when the lights turn on or off.

This is nice work.

I don't know if it's just me, but IMO switches like these are inappropriate as a replacement for a checkbox in most forms. I could see it being useful in an app that changed the presentation of something (charts, styles, etc).

If I click and drag the switch without taking my mouse off it gets stuck. I feel like if my mouse goes up the switch should go on or off, not stay in an inconsistent state.

This no longer fits with the bootstrap aesthetic :)

Ancillary question: What would be the motivation behind making a domain for something like this?

This is great! I'll be using it in the coming weeks!

should we always expect that the hidden input checkboxes are being checked? Wish the documentation addressed this...

The animated switch is nice. Good work.

The animation feels wrong to me. It is too slow, and a switch should not ease-out.

This is pretty easy to fix with:

    transition: left 0.3s;
    transition-timing-function: linear;

The animation also gets stuck from time to time. The overall experience is way better without it.

Awesome. Was looking for something like this. Switch from jQuery Mobile sucks on the phone.

Edit: nevermind, extremely laggy on mobile.

The first ones are laggy on my iPhone 4, but the one after "Colors can be changed too:" is quite snappy.