Speak To Me!
Trend: Disabled States
Using disabled states for buttons, links and other ui components are an important way to provide feedback to the user. Think about a stop light for a minute; if it were always green then the driver would expect that they could drive through causing collisions with cars going the other way. To prevent this, the red light steps in to tell the driver they have to wait. Just like stoplights allow traffic to run more smoothly, the disabled state allow UI interactions to be more efficient—the user knows that they don’t need to waste their time trying to click anything disabled. In addition, it helps hierarchy because applicable actions stand out whereas unapplicable actions push back. Disabling an action communicates important information to the user which, coupled with their interaction with the product, help them to understand how that product works.
For example, when the link button is disabled (shown, below), I infer I have to do something to allow that button to become active: I have to highlight the text before I am allowed to add the link not click the link button and then tell it what text to insert for the link.

Other Examples:

I think disabling components is a must! Vote ‘em up!

Romulo AB
Oct 23, 2009
11:01 am
I think it’s only ok if the user has a clear notion of the reason why the control is disabled, or it’ll only be perceived as a “random state”.
I’ve read somewhere that one alternative is to keep the control enabled and inform to the user the reason why the requested action could not be performed, preferably suggesting next what steps could make the action behave as expected, with some sort of hints or tooltips (no scary dialog boxes).
uberVU - social comments
Oct 24, 2009
7:34 pm
Social comments and analytics for this post…
This post was mentioned on Twitter by webmagfi: Speak To Me! http://bit.ly/3RWaBo…
Allan
Oct 26, 2009
7:11 am
The disabled control is a half-hearted UI that has driven me nuts for years. The main problem is that, contrary to the UI programmer’s world view, it is often *NOT* apparent why a control is disabled. I think disabled controls should allow an activation (click?) that tells the user why that control is disabled and/or how to get it activated.
(As a developer) I consider myself a very advanced computer user and have been stumped from time-to-time as to why a control is disabled. It can happen to anybody.
Jaime
Oct 29, 2009
10:21 am
I like this article. I think the disabled state provides feedback that a user needs. One question though…how would you handle a situation where an action is available and the user takes action, but after that action is taken it can not be revisited? It is no longer available. Would you leave the action displayed, but disable it or would you remove the action all together?
Dave
Oct 30, 2009
2:12 pm
A button that is sometimes disabled and sometimes not for reasons unknown to the user still provides more information than a button that is graphically identical whether it is functional or not.
Kate Vander Ploeg
Oct 30, 2009
3:18 pm
I like the point that Allan and Romolo brought up. Like anything, disabling a control isn’t always enough especially with more complex UI’s. But it also doesn’t mean they are any less imperative. We should most definitely take into consideration that sometimes the control needs more explanation like adding a tooltip or making sure it is documented in help.
@Jaime, it sounds like either disabling or removing the action would be the thing to do in the situation you described. I have seen both done successfully as long as they are consistent so the user can understand the pattern.
Martin LeBlanc
Nov 10, 2009
12:11 pm
If you use disabled buttons and other controls, it is ultra important to explaing the user WHY the button isn’t working. You can perhaps leave it grey, but have a message when you click and hover it.
I personally hate disabled controls.
Dave A
Nov 12, 2009
4:00 am
I think disabled controls are great, I find it incredibly annoying when I press a button that presses but doesn’t do anything. You tend to think that the application is broken when that happens.
I agree with some of the posters above that it’s also infuriating if you don’t know why the control is disabled, and what you can do to enable it.
How about the idea of having tooltips or similar to explain the steps to use the button? I haven’t tried this, but it’s possible that tooltips normally don’t work when a control is disabled…
Eric Kolotyluk
Feb 1, 2010
10:45 am
Disabled controls have become a real problem because the reason they are disabled is often a mystery. Also, meaning can often be ambiguous: is the control disabled because the value does not apply, or does the value apply but is read-only? This subject is not covered well, or at all, in the leading UI guidelines: Apple, Microsoft, Sun, IBM, etc.
I have started putting tool-tips on disabled controls to tell the user why they are disabled, but the problem of ambiguity often remains. Also, unless the user commonly mouses over for tool-tips, the reason the control is disabled is hidden.
Sometimes I will replace controls that do not apply with a label “Not Applicable” with a tool-tip as to why it does not apply. Sometimes I will replace a control that is read only with a label containing the read-only value.
I’m beginning to realize that being able to disable or “gray-out” controls is one of the biggest cop-outs in UI design history and has lead to a generation of lazy UI designers and implementers.