38

How many times did you use a desktop app or an online page and you come across one or more menu items which are disabled and you have no idea why its disabled. Using help or documentation is of no use. It gets frustrating because it's stopping you from moving forward.

I have NEVER seen this usability practice used. Hover over the disabled item and a tooltip lists you the reasons and you go "Oh.. ok. now I know". Your other option is you have to contact support or post in a forum, explain what you were doing. Wait for what possibly be days tell you get an answer, if any. This is the difference between black & white. Getting instant help by a simple hover or get frustrated and wait for hours.

If you are the one developing the app, you know exactly why an item is disabled because you disabled it in your code. So it's not hard to show the reasons to the user. Is it?

This little tip could have saved thousands of tech support calls. There are millions of posts on the web of Why something is disabled or grayed out.

8
  • 1
    I think it is a great idea. +1
    – Sruly
    Commented Aug 27, 2010 at 0:17
  • Why is this community wiki?
    – Sruly
    Commented Aug 27, 2010 at 0:18
  • Because it's a discussion type of question. Commented Aug 27, 2010 at 4:21
  • I do this in my applications. Typically on forms that require the user to fill out each field. I have the Submit button disabled while the form is not complete. And the user can clearly see the fields that need attention, and they can also mouse over Submit to see an explanation as to why it's disabled.
    – user708
    Commented Aug 27, 2010 at 5:42
  • I really find the marking of "discussion" questions as "community wiki" to be a complete waste of time and space. Either this is a Q&A site, or it isn't, meaning either discussions are not okay, or they are. Commented Aug 31, 2010 at 18:07

12 Answers 12

12

This is a good idea. To make the tooltip easier to find, you can add a little help icon to disabled controls. Since adding an extra icon beside the control may disturb the layout, you can add the icon to the control itself:

alt text

2
  • 2
    If only it was easy to get tooltips to work on disabled items in most UI frameworks. Trying to show a tooltip on a disabled item has given me lots of problem in WinForms.
    – Ian
    Commented Oct 6, 2010 at 9:18
  • 1
    The tooltip can be added as a separate ui item. Commented May 6, 2011 at 16:46
11

I generally have found that users don't read anything. Especially tool-tips. It would help the power user, but I really don't think "thousands of tech support calls" would be saved.

With that said...it doesn't hurt. Why not? For the few customers who appreciate it and read it would have a very nice friendly impact.

3
  • I agree with Glen. It would be a nice surprise for the users who notice. Plus it is usually really easy to implement. If you don't mind, I might steal the idea the next time I need to disable something and still leave it visible(I usually just don't display it if they don't need it, but sometimes it's necessary.) Commented Aug 27, 2010 at 2:48
  • 1
    When you get a customer call and you help them out and you tell them about that tip, I think you will save money from future calls from the same person. Commented Aug 27, 2010 at 4:27
  • When stuck, I believe many users seek those hints around the UI, instead of staring at it looking for the answer. It also explains the often tried right-click, because many users have come to expect helpful commands to lie there.
    – Dvir Adler
    Commented Dec 17, 2012 at 8:45
3

I might be repeating myself here, but the only way to know for sure if this would be an improvement is to test it. So I can agree or disagree, but it doesn't really matter because I'm just a pundit. Real users will kick all our asses.

1
  • This needs training for the users because it's not easily discoverable. In fact I expect most users to find it by chance. So you need to mention the hover tip in the help file, in one of those tip screens when a app launches and so on. They need that single initial hook to let them know about it and hopefully they will use it often. Commented Aug 27, 2010 at 22:48
3

Disabled items are something weird. In real life, if a button doesn't work, something is broken.

Now if something has to be disabled, it should be an exceptional case. And exceptional cases should be announced when the occur (to have the attention of the user) with a clear and simple statement (and preferably not in a "ok" dialog, because they get clicked away unread).

So the real solution IMHO is to not have disabled stuff in the ui.

IF you stick to having disabled items, what do you tell your user? It probably comes down to either "Sorry, its disabled, because some internal stiffy-stuff is not how it should be, but you can't do anything about it" or "Hey user, obviously our interface is not intutitive enough, but we'd rather tell you: do 'this' first"......

2
  • Sometimes life is weird! Sometimes there's edge cases to deal with and you need to balance out the experience for the majority and the minority. Sometimes disabled is that middle ground. That's when one needs to be respectful of the minority and provide an appropriate explanation.
    – rsb
    Commented Feb 28, 2013 at 0:36
  • 2
    I disagree to this answer. In the physical world, it is much harder to provide clear feedback to controls that won't work in the current context, but the world is full of them anyway. One simple example is that most of the knobs and buttons in your car won't work until you turn your key to some setting in the ignition. There is, however, no feedback on what will and what will not work. There is no reason to impose the limits of the physical world on our work in software.
    – André
    Commented Feb 28, 2013 at 8:50
2

I have categorize this 2 case:

1) If its disabled and user can not do anything about then is better to not show at all, or if you show it no need for tooltip.

2) If its disabled because you need from your user to select an option that is very near (eg above the button) then you need to tell him with a tool tip, please select your option then click on me.

2

That's a nice idea, we actually implemented it quite consistently in our http://www.taskconnect.com Outlook addin, as we know how frustrating it is when you cannot do what you want and you don't even know what's wrong.

It looks like this: (in a picture there is a list of connected and disconnected Work Item stores (TFS), the connected ones open to show their projects, and the disconnected ones are greyed out, with tooltip containing the error message from the server)

We also did this to a toolbar buttons (when you cannot edit the task, the tooltip tells you why).

Another practice of interest is that we made tooltips to appear instantaneously, so that this functionality is easily discoverable, this also works well with toolbar icons, as user is reminded almost subconsciously about their function every time they use them.

In practice, users who know what each button does aren't annoyed, as the toolbar pops in for milliseconds, but once they strive a little, they have a reminder at hand. What do you think?

4
  • There's an inherit problem with tooltips which pop instantly. When there's quite a few disabled items on the screen and you're mousing around, all kinds of tooltips start popping which can get annoying and you start manouvering around to avoid the disabled items. Maybe a setting to delay the popups could be helpful. Commented Aug 27, 2010 at 22:55
  • Also unless explicitly changed Windows tooltips disappear after a few seconds, making multi-line tooltips hard to read (unless you're a power user and know the trick of nudging the tip back and forth with the mouse while reading - very user-friendly ;) Commented Oct 8, 2010 at 9:17
  • Tony: Thanks, I'd be interested in what the users think about it - I personally hate waiting for tooltip to open, when I am using interface I am not used to. Maybe we'll leave it like this to get user comfortable with new UI, and then, after some time, switch it back to normal tooltips. Commented Dec 15, 2010 at 14:49
  • Oskar: Thanks for idea, but we have thought of this - our tooltips stay as long as you keep the mouse over the btton. Commented Dec 15, 2010 at 14:50
2

Brilliant, simple and really really helpful.

But on the other hand, i would hide any unusable elements all together unless users expect to see them, like submit buttons or list of contacts, i dont want the user to freak out of not seeing his contacts now do i?

I like it, and i like it simple, no icon, no flashy tooltip, because not a lot o users would hover anyway, very short tooltips, and default browser tooltips, otherwise it would be too much code for too little value, and i'm almost sure next technical architect is gonna cut out this feature if its any less simple...

But I love it :)

2

If something is disabled then it doesn't need to be there, UNLESS it doesn't require an explanation.

Otherwise it's just noise for the user.

A perfect example of good "disabling" is the "send" button on the iPhone's native SMS app. It's disabled until you enter text. No explanation is needed, yet it does need to be there.

Again, if a UI element needs to be disabled, then you should ask yourself, does it really need to be there at all.... OR, can I change the UI so it doesn't require explanation?

3
  • 4
    I recall to have come across research that claimed removing and inserting items in e.g. menu dropdowns is a bad idea because it confuses people's spatial memory. Unfortunately I don't have a reference at hand. The MS team, for their redesign of Office 2007 abandoned the expanding and collapsing dropdowns of Office 2003 for the same reason according to: blogs.msdn.com/b/jensenh/archive/2008/03/12/…
    – agib
    Commented Apr 1, 2011 at 6:57
  • 2
    It doesn't demand removing or adding elements. Many of the situations requiring disabling of controls can be solved with additional feedback. For example, upon clicking "Submit", when there's an error on the form, a message would be much more helpful than a disabled button.
    – Dvir Adler
    Commented Dec 17, 2012 at 8:49
  • I am disabling features (sharing/collaborating/inviting) in a demo/free mode. I want the user to know the feature exists and provide an incentive to upgrade. Commented Oct 5, 2016 at 5:46
1

Another alternative is to leave the item enabled, and then, if the user clicks it, provide feedback about what's required before the item can be used. I don' think this is an appropriate solution for all situations, but could be helpful to a novice, and for an item that gets occasional-by-few usage.

Incidentally, I think a disabled item can be better than a hidden item ebcause once you find it, you can stop looking and deal with the enxt problem: WHY is it unavailable? ;)

2
  • 1
    That would be a wasted click. I would find that annoying.
    – Sruly
    Commented Aug 27, 2010 at 8:26
  • It won't be a wasted click if the user can take some action to rectify the situation.
    – rsb
    Commented Feb 28, 2013 at 0:43
1

You could also have a small question mark icon next to the disabled item that would show a tooltip when hovered over. That way, if the user wondered why an item was disabled, the icon would be an obvious indicator that there might be information on why that item is disabled. That could save some support calls.

But I have to agree with others that disabling controls is not a good option. Either hide it conditionally or design the UI better so it isn't necesssary.

Edit: After some thought, there are places where disabling works in my view, but the disabled item should be enabled by a setting in close proximity, and the fact that there is a setting that enables the item should be abundantly clear (and why that's the case ideally as well).

1

Think of why this option is disabled, for what application and at what point in the experience. Then make a call accordingly.

Some considerations could be: - Can the user take some action to enable it? - Is this a show stopper for the user? Is there justifiable value in solving this situation? - Are there easy alternatives to this disabled option? (Probably should just hide the disabled option in that case)

0

The idea has some perspective, since tooltip help (as opposed to help separated from context) is "just-in-time-and-place".

However, there are some cases to consider, e.g.:

  • Touch-based interaction: On touch interfaces you don't have hover states per se.
  • Complex apps/settings in apps where the disabling of a control is due to a series of causes (which cannot be explained briefly in a tooltip).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.