If you disable something, tell your users why!

If you disable something, tell your users why!

I bet there is hardly a person who has never experienced this situation: You want to do something in an application, but the control (UI widget) which does it is greyed out – and you have no fracking idea why!
This is a frustrating situation, and that is why it’s common sense among UX professionals that you should never disable a control without telling users why it is disabled. However, even though this immediately made sense to any developer I told about it as well, I find it implemented in practice very rarely.
Now the question is: How and when do you tell users why something is disabled? Following the same principle as in my last post, that information should be given to users exactly when and where they need it: At the moment they want to use the control which is disabled. The easiest way to do this is to simply add a tooltip to disabled controls with a short explanation of the reason why, and ideally what the user needs to do to get it enabled (again). Even if a control is disabled, users tend to move the mouse to it anyways, which is when they get the information they need. On touch devices you cannot display a tooltip on hover, so you should display it when the disabled control is touched.
Not all users might hover or touch disabled controls intuitively, but if this gets widely implemented in an ecosystem such as KDE, users will learn to expect that information once they’ve found it in some applications.
Now I encourage all developers and interaction designers: Whenever you implement or design a disabled control, put a tooltip on it, you will spare your users a lot of frustration!
Update, thanks to Kevin’s comment:
If a control already has a tooltip when it’s enabled, write the reason in brackets behind the usual tooltip when it’s disabled.
Example:

• Tooltip while enabled: Go to the next unread message
• Tooltip when disabled: Go to the next unread message (No unread messages left)