I have a quick question about buttons that toggle between two states. (Think Play/Pause, or Shuffle/Regular Play.) As the title says, should the toggle show it's current state or the state to which it will transition?

I think people are used to the Play/Pause convention. But the Shuffle/Regular play might be more confusing if you show the transition state instead of current. For example, the built in music player on the XBox 360 does it this way: when it's in shuffle mode, it shows the icon for direct play and vice versa and it always confuses me (am I in shuffle mode or straight play).

It see it this way. Play/Pause is more like an action as in begin playing or pause playing. Yes behind the scenes it is a state transition but to the user there is an action. Whereas Shuffle/Straight Play is an option and it's best to show the current state (and possibly have only one icon and change button to show that the option is enabled/disabled). Thoughts?

What about using a checkbox, especially if the selection between the two options can be summarized in a yes/no question?
– vszFeb 21 '13 at 22:44

long time ago, but - I'd stay away from these categories (action vs. option). I'm surprised at how often I think these are clear, and "my" users have never thought about them, much less a clear distinction.
– virtualnobiDec 12 '13 at 12:20

Only a comment but I put the text Mode: in front of all toggle buttons and make them a different color. It is less space than radio buttons. I use it when the toggle needs to be in a certain orders
– paparazzoOct 20 '14 at 19:19

21 Answers
21

In About Face 2.0 (there is a v3 but I haven't got it) Cooper and Reimann (2003, pp. 341-2) treat this subject under the heading "Flip-flop buttons: A selection idiom to avoid". I strongly suggest to consult this book as I will only present an excerpt:

Flip-flop button controls are very efficient. They save space by controlling two mutually exclusive options with a single control. The problem with flip-flop controls is that they fail to fulfill the second duty of every control - to inform the user of their current state. If the button says ON when the state is off, it is unclear what the setting is. If it is OFF when the state is off, however, where is the ON button? Don't use them. Not on buttons and no on menus!

The authors (and I think of these as an authority on the subject) presents two possible solutions: You should either spell the button's action out as a verb phrase (e.g., Switch to portrait mode, thereby sacrificing some of the saved space) or use some other technique entirely (e.g., two radio buttons).

We have an industrial control process with flip-flop buttons everywhere. Whenever things are running, they are RED to indicate that it will stop if you push the button. If it's stopped, they are GREEN. It's the most confusing UI I've ever seen. A screen full of red means everything is running smoothly! o_O
– Andy SOct 25 '11 at 18:28

Quite a late answer, but I'm surprised no one here pointed this out before -- it is possible for a toggle switch to show its current state and the state to which it will change simply by having text outside the button, instead of on it.

Long Answer:

As dotancohen points out:

The problem is that in English "on" and "off" are both adverbs and adjectives.

Buttons that have text outside of their body use this very fact to their advantage! Read on...

Take the iOS switch design:

Let's focus on the state that's blue and says ON for example.

Can you tell if the switch is ON currently, or if it will go on if you move/click/tap the slider? Is the text obvious? Is "ON" here a state(adjective) or action(verb)? Unclear. Is the color of any use to help you decide this? Probably, but not certainly -- iOS users may be habituated to the states of this design, but there's no telling how non-iOS users would interpret this. To see what I mean, take this real life trip-switch, which has the same design as the iOS switch -- can you tell for sure if the trip switch is currently ON?

The switch below is along the lines of the iOS design, but far worse...

...it's not even clear which half the slide/click handle is!

On the other hand, the OS X switch design leaves no room for ambiguity:

The question from jensgram's quote...

If the button says ON when the state is off, it is unclear what the setting is. If it is OFF when the state is off, however, where is the ON button?

...never arises here since the button neither says ON nor OFF -- it just stands by itself. Also, there's no confusion about the context of the words ON and OFF -- they are very clearly states (adjectives) since clicking on them (in the normal design) would do nothing!

It may be interesting to note that a modification to this design would allow for the text on the far side of the button to be made click-able/tap-able. If so, the word closer to the switch-handle is the state, while other one is the action, and the roles are reversed when the switch is toggled.

Even so, the user's perspective of the switch isn't altered -- at no point is the user confused about the current state of the switch. In fact, the design could be further enhanced for user friendliness by highlighting the current state:

The Windows Metro UI design for the switch goes a step further, and removes the "action" text from the button, and retains just the "state" text:

The color of the button indicates the current state (lit up = ON, as in real life), and the words On/Off underneath the option text reassure the user of the current state.

Good point about having the text outside. Just want to point out that it's not about on/off being verbs. On/off are certainly not verbs (guess they could be adverbs - "to turn OFF/ON"). It's about the perception of buttons doing things when you click on them. And as the text on buttons usually say the action to perform and not the opposite of the state you want to go to, it can be hard to tell what the button actually does.
– Jonathan AzulayFeb 27 '14 at 0:56

2

Excellent point. Surprising to see OS X get it right while iOS is a bit ambiguous.
– TboltJun 26 '14 at 13:34

2

The outside labelling works for me. The only caveat I'd add is that the total length of the "slide area" must be clearly more than double the size of the button. The first example, below "On the other hand, the OS X switch design leaves no room for ambiguity", just achieves this, but I've seen examples where the slider is exactly half the width and it can be very difficult to tell which half is the slider.
– TripeHoundApr 24 '15 at 16:00

1

One of my favorite answers on stackexchange. Are there any more compact options without sacrificing clarity? I.e. what if you showed the current stay: active, paused, then on hover showed a popover with the toggle you have suggested.
– ckarbassJun 23 '15 at 22:12

I don't think it's a bad example, the effect on mouseover gives enough information to understand how it works. But it may still be confusing on a touch screen, without mouse hover.
– A.LFeb 21 '14 at 11:27

11

@n.1 Typically you wouldn't mouse over and stop if there was a change of state, you would go in and click with one intention and all of a sudden the button flips on you hoping you will pause long enough to recognize the change. Mostly this results in accidental clicking more often than not.
– Sammy GuergachiMay 11 '14 at 1:39

37

+1 for the very shy mouse that seems apprehensive about clicking the button.
– user31914Aug 29 '14 at 5:26

It doesn't answer the subject when you have switch button to toggle SIMPLE VIEW/ADVANCED VIEW where the simple view is the full table of contents (tree view) and advanced view is the table of contents with only nodes which are opened.
– pierre lebaillyJun 11 '13 at 5:55

2

"On" and "off" are certainly not verbs, though I suppose they might be interpreted as abbreviations for phrases like "switch on". In any case, the distinction between labelling a control "enable" or "enabled" is too subtle to make for a clear, usable interface.
– Bennett McElweeDec 18 '13 at 21:54

The "Very late edit" is not an edit; it is a completely different answer (and a great one, I would say, that deserves its own votes). You should submit it as a separate answer. (Yes, a user is permitted to give multiple answers to the same question, and in this case it would make sense to do so.)
– OchadoFeb 11 at 20:44

Perhaps buttons that perform an action and have their behavior toggled when clicked should not really be considered Toggle Buttons but instead just regular buttons that have their behavior dependent on the action that is currently being performed.
– jpiersonFeb 7 '11 at 17:42

A reasonable compromise would be to have the button not highlighted (have a neutral background color perhaps) when it is on the off state, and highlight it (change background color) when it is in the on state.

For example, looking at this screenshot of the Spotify (web)app, do you think shuffle is on or off?

I would say that it depends on the case, as ChrisF said, it's important to have a distinction between an action button and a state button.

If your button has text, you could change the text to show that clicking it will do something (ex: "Turn shuffle play on"). However, in your case, since it's only an icon, I would go with only a shuffle icon that looks enabled/disabled depending on the state. If it's disabled, then it should be clear to the user that it's straight play. You could light it up or show the button as pressed down.

I believe that iOS switch is a total failure. Look at the image on the image provided in the comment above and try to answer the fundamental question. What is the current state?!
– DenzoMay 23 '11 at 8:19

9

And when it is on it is a blue "On" on the left side. This is the opposite of a total failure. It is briliiant.
– Matt RockwellMay 24 '11 at 17:59

28

I find that utterly incomprehensible. If it's off "because OFF is the only thing visible," then do I turn it on by clicking the OFF button or the empty space to the left of it?
– Adrian McCarthyAug 1 '11 at 23:04

10

@Adrian: Exactly what jensgram said: "If it is OFF when the state is off, however, where is the ON button?" I think jezmck was right in the original post: Show both states, and highlight the active one.
– l0b0Nov 17 '11 at 15:24

7

@l0b0: With only two choices, it's very difficult to show two options and highlight one in an unambiguous way. Is it highlighting off because the state is off because the only thing I can do is turn it off? I look at the Airplane Mode graphic above and keep thinking it's on because OFF looks like a button, and buttons should be labeled with the action they perform.
– Adrian McCarthyNov 17 '11 at 22:16

I'd suggest toggle buttons are acceptable in the case where there is a clear on and off state. This can occur, for instance, when you have a line of grayed buttons that become colored when you click them.

This is the reason Play/Pause works in many cases. The play button is not so much a toggle between two states as an enable/disable. It turns bright green when on (I'm playing!), it turns gray and shows a || when off (I'm not playing!).

The other buttons do the same, so the consistency adds to the affordance. It's probably also based on our historical perceptions of a tape deck or VCR, which had buttons you pressed in (i.e. on state) or depressed (i.e. off state) and I think this is a great mental model to keep in mind when considering a toggle.

But in any case where they are not simply "activated", where you couldn't replace the toggle with an uglier checkbox, I'd default to "don't use them," for all the reasons already mentioned.

ADDITION

I just noticed today that Evernote has a pretty effective toggle. They took the approach of a mouseover, which actually worked pretty well. Note that this is another case of an on/off style control.

ADDITIONAL ADDITION

I found this interesting switch today and was reminded of this UX Q&A. Note how the state is immediately obvious, and the fact that it's going to switch when you touch it is also made obvious by the textured "handle" (i.e. affordance)--I just know that when I grab that raised knob, it will switch to the opposite side and say the opposite of what it says now; it's just like an airplane lavatory.

Looking at your right "lavatory" button, I tend to move it to the left to switch it "on".
– maaartinusOct 19 '14 at 18:47

1

For a lavatory, green usually means "you can walk in!" and then you go in and know that you must lock it, whereupon it turns red, indicating that it is "locked" and also, "you can't go out". But you know whether you have gotten in or not so the state is obvious. In cars, the lock lever tends to show red when it is unlocked, meaning perhaps "unsafe"? I find this irritating. The only safety in locking yourself inside is if someone walks up to the car. On the highway, you want it unlocked so that you can get out and people can help if there is a crash. So, red / green is problematic for doors.
– user67695Sep 6 '16 at 14:41

There's already 18 answers here so this might be late to the party, but it makes sense to use checkboxes in such situations. Some examples:

And when selected:

This is similar to the "dim / lit" approach that Facebook's "Like" uses, but is combined with a checkbox for better visibility. In any case, the key point is to use only one word (or set of words) instead of trying to make the user decide between multiple words.

Also, make it a point to avoid using negative prefixes ("Not", "Non-", "Un-", "Dis-", "Im-", "Mis-", "In-", "Il-", "Ir-") otherwise the user would then have to do a "double negative" in his mind when he had unchecked the checkbox:

I have been using Toggle Button to "Add" and "Remove" elements to a collection using simple Toggle Button (one with state visible at a time) which had following states.

ADD (if button wasn't clicked ever)

REMOVE (if the button was previously clicked and an item was now part of the collection)

BUT this always pinched me as for a novice user (age 50+), it was initially hard to understand what has happened and why is button asking to "Remove" even before I learned that item was now part of the collection. The missing bit in this case was a notification message which would say "Item Successfully Added". I am using a Javascript Based Status Message which appears on the top of screen (using http://twitter.github.com/bootstrap/javascript.html#alerts) but since it was visually displaced from the element of interaction, I only solved a part of the problem for some users.

Another Issue

Your button changes its "Stance" or "Flips its sides" after every click. Sometimes it says "I am the add button" and some times the same button (in the same column among other add buttons) it says "I am remove button". Changing colors help but these are still two opposite roles taken up by one button. NOT SO RIGHT.

My Solution:

My solution to this minor and well discussed issue is to replace the toggle button with something like that.

Button which has Caption "Add" when not clicked
After Click, Button replaces itself with a message "Successfully Added" and shows a small 24x24 button which has label "X" and which allows you to cancel your last act which is always "Add". Thus you never click a "Remove" button but only "cancel" your previous "Add Operation". Also you don't need to show a separate "Successfully Added" notification on the page.
Down side of this approach is that that you need more space to put "Successfully Added" label and a "Button to Cancel" but this in my opinion is one of the less confusing approaches.

What if you start with a state where some things are already present (possibly added by a different user or a long time ago)? Do you show a mix of Add / Remove / Added to my list[X] / Removed from my list[X]?
– maaartinusMay 18 '14 at 4:56

1

Toggle button has two states. If you had to introduce a third one, for example add/remove from "global-list" and add/remove from "my-list", I would group two toggle states visually together and place the third button "add to my-list" button next to them. As a UX designer, you can consider simplifying user-flows and interaction rules. If you could separate "my-list" interactions from "global-list" interactions, that would be the right thing to do.
– Salman EhsanMay 23 '14 at 1:04

E.g. in the case of shuffled/regular play: just use a checkbox with a "shuffle" label next to it, and nobody will get confused...

And in the case of a play/shuffle button, it's maybe not necessary to change the label on the button either. You could use a "pressed" button to indicate "playing", and an "up" button to indicate "not playing". Or you could put an indicator somewhere else in the UI of course (that's what my stereo system does...).

It's not because some company starts to use a certain widget that all of a sudden it should be used for everything...

In this particular case, the check box is not performing a command. Rather, when checked the music player should select a random song after this song ends; when unchecked the music player should proceed to the next song in order. Checking the box changes program state, but does not have an immediate "command" effect.
– Jon of All TradesFeb 10 '15 at 22:21

On Facebook's Android app, the like is on a button and it's a grayed when off and highlighted blue when on. See screenshots below.

Basically, I agree with them - emphasize the positive and don't mess with users' brains (minimum change).

I'm not sure if it's a good way for color blinded. Perhaps they should have done the indication more bold.

On Facebook's web-app, the pattern is different. The button's text changes to indicate the action - what happens on click. This is confusing. BUT, this makes sense because they have a lot of space and have a separate indication that a user likes a post.

Labelled buttons (toggle buttons) are often confusing or even ambiguous, as you point out. Instead,show the status and the action, like this:

OnlineGo offline

So we have a non-clickable label clearly indicating the current status, and a clickable button to carry out an action to change the status.

If you click the "Go offline" button, then the label changes to "Offline" and the button changes to "Go online".

Showing both the current status and the action at the same time is the only way to be completely clear. Radio buttons would do this, but the label + button solution is better because it offers a clear visual distinction between the two. Also it is naturally more compact than radio buttons.

As for the alternatives, I think it's agreed that toggle buttons can be problematic. Even checkboxes may be confusing:

Online

The checkbox is not checked, so the application is offline. But this isn't particularly clear. If you glance at it, the first thing you see is the word "Online", so it's easy to draw the wrong conclusion.

The trouble is that all you can see is a single label. You have to think for a bit before you can decide whether the label indicates a status or a command. This problem is common to checkboxes and buttons, and trying to consistently use adjectives (or verbs or whatever) may improve things but will not make the problem go away.

Checkboxes are good when actions can manipulate state directly and instantly; the problem with the "Online" checkbox is that it has no standard and unambiguous way of showing "Connection requested and in progress" or "Disconnect requested and in progress" states. The "verbs" approach can handle that if the "Go offline" button changes to a "Going offline" indicator while the "Online" indicator changes to "Go Online".
– supercatFeb 10 '15 at 18:08

@supercat The status+action approach works perfectly in your situation too. "Online [Go offline]" simply changes to "Going offline [Cancel]" while disconnection is in progress, then to "Offline [Go online]". I think your suggestion of switching status and action around during disconnection would lead to confusion.
– Bennett McElweeFeb 10 '15 at 21:56

I think there should be a button which means "I want the system to be on-line" and one which means "I want the system to be off-line", possibly in addition to status text below them. The button which corresponds to either the system's current or "target" state should be disabled, but someone who wants the system to end up in a particular state should be able to have a clear course of action to get there.
– supercatFeb 10 '15 at 22:18

@supercat It seems as if you'd prefer to do away with toggle buttons completely. This seems quite reasonable too.
– Bennett McElweeFeb 11 '15 at 1:57

1

Toggle buttons are fine for things which have exactly one bit of state and it can be controlled directly by the button. I consider them problematic for things which have state beyond what the button can directly control.
– supercatFeb 11 '15 at 15:56

For the Play/Pause example, I'd show the current state normally and the opposite on mouse-over (when that's appropriate i.e not on touch screens). That item has 2 natural states and no unifying verb. On/Off on the other hand can be simplified to Power with the On state being lit and the off state, well, not.

I'd always go with current state. I think the play/pause idiom is the exception rather than the rule. I think play/pause being like it is, is possibly a holdover from the days of old cassette tapedecks. When play/pause were combined on CD players, I remember thinking how cool & innovative that was.

Anyway, one way to make it obvious that the current state is "selected" is to make the button glow a bit, or outline it with some magic looking blue.

As another example, I have 3 different cameras settings that are toggled by a single button: orthographic 1-up, orthographic 4-up, and perspective. A single button cycles through these 3 states, and I'm showing the current state on the face of the button.

Single buttons for multiple state are not that confusing once you get used to them. They are great because they group mutually exclusive settings, and they save cluttering the UI up with many distinct buttons. In a way, they are like a compact radio button.

Other options I could think of are:

Show current state, and pop out a menu to change state (even if there are only 2 options)

An example of this is how Mac os shows you the state of your BlueTooth or Airport -- it even has a popout with full sentences about what each action will do:

It shows its current state (faded gray means off), and it shows next states via a popup menu with full sentences.

I always preferred separate "play/pause". For video players, "pause" can then easily double as a "frame-step" function, and on players where the play button may not react instantly, the effect of pushing the play button when playback has been requested but not visibly started is ambiguous.
– supercatFeb 10 '15 at 18:25

@Kato's answer images from Evernote put it clear: there is the label communicating what is controlled by the toggle ("Auto save"), and the toggle, which doubles as a state indicator (O | I).
The problem with some toggles is trying to use the same bit for two different purposes: communicating the state, and communicating th action.
My home´s lights, for example, have an anonymous toggle and a bright indicaror, which is the light itself (when the bulb fails we usually can´t tell if the toggle is in the on or off position).
The play | pause arrangement also has a clear on indicator, the sound of the music itself. The toggle fulfills one function (control), the music fulfills the other one (communicate state).
The shffle vs. linear toggle controls the state, but doesn't communicate it. You would need to grab the CD case, wait for a theme to finish, and check if the one that starts after is the next in the list or not (and repeat to be sure). But if you think it as a shuffle | not-shuffle binary option, then you might label after the behaviour it controls ("shuffle" as a verb) and communicate the state by illuminating it.
As I see it, in any case you need to communicate the state.
A friend of mine is mad about his car's lock remote control. It has a state printed and he doesn't know if it's the action or the feedback.

The play/pause toggle concept only works in cases where the effects are instant and obvious. If the playback button doesn't always have immediate effect, then it's unclear what action should be expected if the user pushes the button and, having observed no response, pushes it again. In some such cases, the user might want to cancel or delay the upcoming playback, but in other cases the user might be wanting to ensure that the device will in fact commence playback as soon as it is able. With separate buttons, both cases can be handled easily. With one button, it's a mess.
– supercatFeb 10 '15 at 18:28

@supercat: you are right, for the cases where the immediate behaviour doesn't provide immediate feedback. On the other hand, it is really nice to be able to alternate stop and play of a video without repositioning the mouse, like in youTube. Different cases would require adequate solutions.
– Juan LanusFeb 15 '15 at 14:46

There are times when toggle functionality is helpful, but also times when it's helpful to be able to perform a specific known action. I wonder how well it would work to have adjacent play and pause buttons, but when either is clicked have it turn into a double-wide toggle button which would remain in that state until the mouse went elsewhere?
– supercatFeb 15 '15 at 17:21

I like the idea, but the single letter difference means it takes ages (at least now when my eyes are tired). The colors are highlighting the current state but they also invite me to push them down. The gray area look like pushed... so much negative points from a newbie here, no offense meant!
– maaartinusMay 18 '14 at 5:07

@maaartinus None taken. Ideally the sliders should look more like grips than like buttons, however, I was too busy to draw them and just used PowerPoint for the sketch.
– Danny VarodMay 18 '14 at 14:26

It should show the next state always, and to avoid confusion it should say "push to... NEXT STATE not just NEXT STATE. Why? because 99% of users go to seek the "switches" when they "NEED" to change something. Few users go to "see" the "switches" when they are happy with the current state of their app.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).