views:

77

answers:

6

GUI: should a button represent the current state or the state to be achieved through clicking the button? I've seen both and it sometimes misleads the user. what do you think?

+7  A: 

The label on the button should reflect what the button does, i.e. it should describe the change the button makes.

For example, if you have a call logging system a button should say "Close Call" and the user can click it to close the call. The button should not have the label "Call is Open" and the user clicks to change the call status as that's very counter-intuitive, since the button is effectively doing the opposite to what it says on it.

In my opinion the label - and so the function - of a button should rarely, if ever, change. A button is supposed to be a like a physical button and they usually only do a single thing. (There are a few exceptions like play-pause on a media player where it's OK for the button label/icon to change, but at least this is copying a button from a real physical device.)

To carry on the example from above, I would say usually you would want two buttons, "Open Call" and "Close Call" and disable whichever one is not appropriate. Ideally you'd have a field elsewhere displaying the status of the call.

In summary, buttons are for doing things not for passing on information to the user.

Dave Webb
I agree. But I've seen the opposite, and it's confusing.
Petruza
A: 

It should represent the action taken when clicking the button. States should always be presented by other means.

But I know what you mean. My car radio has buttons with text that shows the current state. It is really confusing.

Terje Mikal
A: 

This depends on the function which will be triggerd by the button click.

  1. if the click changes the state of an entity i would suggest that the button represents the state the entity will enter after clicking the button

  2. if the click triggers some kind of functionality the button should represent the function.

Holger Kretzschmar
+4  A: 

The button should represent the action to be executed, not the state.

Bruno Rothgiesser
+1  A: 

Some buttons are actions and are not ambiguous, like "Save", "Print" or "Enable user".

When a button represents a state that can be toggled, like Enable and Disable something, I do one of the following:

Change the button text, and make it always point to the state that will be achieved; (i.e. make the button point to actions, not states); - Keep the button's text the same, but use one of those sticky buttons that will stay pressed, representing that the current state is "on" or "off". I prefer the former approach, though.

rodbv
A: 

The appearance of the button is also a clue to its state. It should follow the standards of the environment if any exist (example, beveled edge / shadow appears on mouse click in Windows).

phaedra