Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Possible Duplicate:
Should a toggle button show its current state or the state to which it will change?

I find inconsistency in "toggle buttons" (I just invented the name now. See screenshot to know what I mean). I see GUI controls that may show the action that will be done or the system status. This is confusing, because I don't know the convention.

I feel that the more natural way of rendering toggle buttons would be to show what they do instead of system status, just like multimedia buttons (play, pause, next, etc). For example, if media is playing, the "play" button is rendered as pressed, just like on cassette players.

What's the best practice? Should they show those buttons show system status or should they display what the buttons do? Are there cases when it's better to show system status or vice-versa?

share|improve this question
add comment

marked as duplicate by Rahul Feb 7 '12 at 10:11

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers

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

Online [Go offline]

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

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.

share|improve this answer
I agree this is the best approach, and just thought I should add for clarity that the flipped state of the example "Online [Go offline]" should display "Offline [Go online]". And if you want to display an icon indicating the current status too, then it should be on the left of the text - i.e. {icon} Online [Go offline] - but to avoid the issues raised in the original question it should NOT be clickable. –  MarcusT Jun 24 '10 at 9:27
add comment

The problem is rather old. Here's a quotation from the Humane Interface by Jef Raskin:

As often happens when toggles are used on buttons or in menus, users read the label as an indicator of state. And they are justifiably confused.

Raskin tells that what can help is to use a check box rather than a button. Or if we have more space we can use radio buttons. In this case the user can clearly see not only the current state but also the alternatives.


It is important to label them with adjective, which describes the state of the object affected, rather than verb, which describes an action, in which case the user does not know whether the action has taken place or is yet to take place.

share|improve this answer
Interesting. Jef Raskin's son, Aza, probably has a lot to do with the example I presented, because he's the head of Mozilla's UX. Did he explicitly say in another instance that he recommends a check box rather than a button? Check boxes are usually better than buttons only if more options can be toggled than one. Also, buttons can be rendered as toggled (by displaying it as pressed down). Maybe, at that time of writing, buttons weren't commonly rendered as pressed down when toggled. –  Allan Caeg Mar 30 '10 at 14:33
As for the importance of labeling with an adjective, it's tricky. For example, when we want to play a song, on apps and websites, people usually look for the play icon. They won't look for the "stop" icon when they want to start playing sound. The same thing goes for online/offline status. I won't look for the "online" icon to make myself offline. –  Allan Caeg Mar 30 '10 at 14:38
@Allan - "Check boxes are usually better than buttons only if more options can be toggled than one." I don't know where you are getting that idea from. Maybe you are mistaking checkboxes for radio buttons? Checkboxes are THE element designed to be used to differentiate between two states. That's why they have two states, checked and not checked. –  Charles Boyung Apr 6 '10 at 19:59
@Charles I meant, in a set of checkboxes, you can activate more than one. On the other hand, in a set of radio buttons, you'll only have to choose one :) –  Allan Caeg Jun 22 '10 at 2:01
I agree that this is an old and potentially messy problem, but I strongly disagree with using adjectives rather than verbs. Buttons invoke action. We learned in elementary school that verbs are "action words". "Show Options" "Connect" "Hide Properties" Carefully chosen verbs have no ambiguity. "Connected" does indicate state, but does not simultaneously indicate that this is how you change that state. Depending on the graphic implementation, it may be easily read as being only an indicator. Of course, the original question apparently referred to unlabeled buttons, which is a different issue. –  mickeyf Aug 10 '10 at 19:19
add comment

It is confusing and there apparently isn’t any standardization or general human tendency. For example, MS Windows UX Interaction Guidelines specifies four basic kinds of toggling progressive disclosure control. Three out of four show the state-when-activated, while one shows the current state. I suspect this is a controversy that needs some innovation and research to resolve.

Toggle buttons are an established control in the Gnome, where they appear to be functional synonyms for option (radio) buttons. They are also described in the Apple Human Interface Guidelines, along with very similar "segmented controls," which are often used to set a view or presentation. IMO, toggle buttons should specifically be used for what you’re talking about: starting and stopping processes. This might be the way to resolve the controversy.

For use to start and stop a process, a toggle button should be labeled unambiguously with the action that yields its affirmative (running) state irrespective its current state. For example, for an email client, it should be labeled “Connect,” not “Online.” The current state is indicated by the toggle button’s graphic appearance, not its labels. When Off, the toggle button should look “raised,” so it appears like a command button. When On, the toggle button should “stick” in a sunken state, like a state indicator (e.g., a read-only text box).

For minimal ambiguity, you want two mutually-exclusive toggle buttons (e.g., one to Connect and one to Disconnect), consistent with the Gnome guidelines. However, this consumes double the real estate, and I suspect you can do okay with just one toggle button for processes like Connect that have simple True and False states (analogous to using a check box rather than two option buttons).

The appearance and behavior of a toggle button is consistent with physical toggle button switches (like the Play buttons on older physical tape recorders you allude to). It’s also consistent with option buttons, check boxes, and state menu items, which all show their affirmative states through standard graphics. When the control looks like a command button (raised appearance), it’s labeled like a command button, the label indicating the action committed like any command button (Connect). When it looks like a state indicator (sunken), its labeled suggest its current state (connected).

An alternative is swapping labels to indicate action/state like you describe. This works for ordinary command buttons if you use text labels that unambiguously indicate the action committed on activation. Don’t use an icon and don’t use state labels like “Online” and “Offline” because command buttons indicate their actions, not states. Use labels like “Connect” and “Disconnect.” The disadvantage of this approach is that you may get longer wordier labels in some cases and the user needs to do a mental transformation to read the affirmative state (“It says I can disconnect, therefore I must be online now”).

Swapping labels in a state indicator control like text box should have unambiguous labels of their state, not the action committed (“Online”/“Offline”). The problem with this approach is that state indicators do not traditionally execute commands, so users may not think to click on them to start/stop a process.

A check box control can be used for in some cases, but that seems more appropriate for changing an attribute value rather than starting and stopping a process.

share|improve this answer
add comment

I agree with Bennett; separating the status display and the command is the only way to avoid this dilemma. This goes along the recommendations of Alan Cooper in "About Face 3.0" where he states, "The control can either serve as a state indicator or as a state-switching selection control, but not both".

However, most video players do exactly that: they combine the "Play"/"Pause" button in one single control. I can tell from my own experience that this works fine for me, and I can only guess why. One of the reasons is that you have the visual feedback from video playing in which state you are. Another reason I can think of is that the big video sites like youtube and vimeo are using this pattern consistently so it has become widely used, some kind of a standard even.

To design a toggle control in an unambiguous fashion, you should separate state and action, choose your wording carefully, and be consistent throughout your application.

You might want to check out a pattern I designed, the "flip-flop button". It has been designed specifically for touch screens; the entire site deals with UI patterns for safety-critical applications.

share|improve this answer
+1 for the example flip-flop button. (very similar to toggle buttons in other platforms, ie iphone) –  Scott Newson Jun 22 '10 at 14:19
Great discussion- I found this site uncharted.designmap.com/?p=321 to be helpful in a further distinction- toggle vs lightswitch. –  Leslie M Nov 26 '13 at 20:50
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.