← Back to team overview

unity-design team mailing list archive

Re: When to use toggle switches

 

It seems like a good rule of thumb would be that whenever you're tempted to
use the word "enabled", to use a switch instead.

Connor

On Jul 4, 2012 11:49 AM, "Philipp Wendler" <ubuntu@xxxxxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> Am 04.07.2012 18:21, schrieb Matthew Paul Thomas:
> > Thorsten Wilms wrote on 07/06/12 11:59:
>
> >> If all you have to communicate is On/Off, what is wrong with
> >> checkboxes? They do have unclear target areas (in proper
> >> implementations, the label is clickable, too), but are well
> >> established and do not suffer from the problems switches have, as
> >> listed above.
> >
> > Good question.
> >
> > For some kinds of boolean setting, a checkbox feels too feeble to
> > control it -- it leaves you unsure whether it is actually turned on or
> > off right now. In the past, a pair of radio buttons, "On" and "Off",
> > was sometimes used to solve this. A switch control does the same job,
> > in a more compact and reassuring way.
>
> Really?
> Personally I absolutely feel the opposite.
> For a check box it is totally clear, whether it is on or off:
> Check mark is there -> on; check mark is missing -> on.
> Everybody knows this, because even paper forms follow the same principle
> (empty box vs. filled box), and radio buttons do so, too.
>
> On the other side, I've always found switches totally confusing since
> they have appeared in GUIs, and I'm still unsure about their state
> everytime I see one.
> I never know whether the word written on it tells me the current state,
> or the state that would be activated if I click it. I do confuse this
> because a switch looks much more like a button than a plain text label,
> and buttons are always labeled with their action, whereas labels are
> used to show state to the user.
> So why is this principle suddenly inverted for switches?
> If I use the mouse to drag the switch, it becomes worse: I have to drag
> the switch into the direction of the word "Off" in order to turn it on!
> This is the complete opposite of how (labeled) switches work in real life.
>
> The only thing saving me with the current Ubuntu switches is their color
> change. As soon as I see the highlighted color in one of their states, I
> know this is the "on" state, and the other has to be the "off" state.
> But if the switch is "off" when I see it, there is no indication that it
> would change color, and so there is no indication that it is actually off.
>
> In the end, I always try the switches out to find out in which state
> they are. For check boxes, I did this exactly once at the first time I
> sat in front of a computer, and I never had to learn this again after
> theme-changes, OS changes, or for new GUI toolkits.
>
> > Most boolean options either don't need that level of solidity, or
> > can't be labelled briefly enough for a switch, or both. They should
> > continue using checkboxes/checkmarks, or a pair of radio buttons/radio
> > items. "Show Time in Menu Bar", "Record file and application usage",
> > "In the clock, show: [/] Date and month", and so on.
>
> Then why use switches at all?
> If a checkbox is a good representation for most boolean options, why not
> for all?
> Why irritate the user with different input methods for the same type of
> question?
> For example in the "Brightness and Lock" settings page, there are a
> switch and a checkbox almost directly next to each other.
> What's the advantage of this for the user?
>
>
> I would really like to have switches abolished completely again. Please
> do not follow Apple's path blindly and use switches just because they
> are now cool.
> Although I don't have numbers, I am pretty sure that checkboxes would be
> at least as good for the users, if not even better (for me they would
be!).
>
> If you think the problem is their small target size, their size could
> probably be adjusted to be as large as that of a switch (at least in
> height).
>
> Greetings, Philipp
>
> --
> Mailing list: https://launchpad.net/~unity-design
> Post to     : unity-design@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~unity-design
> More help   : https://help.launchpad.net/ListHelp

References