Software Expressions

Button theory

Buttons on Windows applications have been around since the first version of Windows. One would think that the patterns for using buttons would have been firmly established by now. In particular rules for disabling and enabling buttons.
Concerning visibility:

Buttons should never be made invisible based on some transient state. i.e. Don’t hide the button when the user is disconnected from the internet, or hide the button when the order has already been placed.

Users should expect to see buttons in the same order and same location for a given context.

Hiding buttons is good for things like user permissions. If you don’t have the permission to delete the customer information, there’s no need to see the button ever.

Concerning enable and disable:

If a button is no longer available due to a transient state, or state of the underlying object, disable it. This keeps the screens and button layout consistent.

Don’t disable the button without giving the user a reason. This may seem strange, but you can display a tooltip on a disabled button. Let the user know why they’re not able to perform the action. Don’t leave them guessing.

I suppose there could be exceptions to this. In some cases it may really be obvious.

If it’s not really obvious and you can’t display a tooltip on a disabled button, leave the button enabled and display a pop-up message indicating why.

The more rules there are that control whether or not the button is available, the more reasons there are to clearly communicate this to the user.

This entry was posted on Friday, November 14th, 2008 at 3:04 pm and is filed under User Experience. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Goto

Categories

Button theory

Leave a Reply