Should “toggle buttons” show what they do or the system status? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

And

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.

Answer 3

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.

Answer 4

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.