I think all of your ideas sound really good. Maybe the best approach, as you say, is to try them and do some usability studies. There’s only one surefire way to prove a theory–try it!

I wonder, for your drag and drop, you could place the message for invalid drop options as a semi-transparent message that gets applied right over the invalid drop location? Just a thought.

Thanks for the link!

Only minor drawback is that the tool tip itself has a disabled look as well (i.e. gray text on yellow background instead of black text).

I’ll put this into the next version of Trace Modeler (a UML sequence diagrams editor), because there are some ui elements of which it might not be immediately obvious why they disabled (like ’split activation’).

Incidentally, I can think of another area where a similar approach might be useful : drag & drop operations.

When you drag elements in Trace Modeler, they can only be dropped in specific areas. Currently I’m using an indicator to show where the element will attach itself when dropped and hide the indicator if it cannot be dropped.

But for novice users it might not be clear why it cannot be dropped in certain places, perhaps an explanation might be useful. However, in this case I think a tooltip may not be the best solution because it is rather intrusive to the whole drag & drop operation (it takes quite a bit of screen real estate). Perhaps something to put in the status line?

I’ll have to check if the ui lib I’m using (java, Swing) allows tooltips on menu items and displays them when the items are disabled.

Btw, perhaps something of interest to you : “Good defaults UI pattern applied to diagrams.

Very nice. Thank you.

How about a fourth option, instead of disabling them, give them a visual cue so the user knows they’re not applicable but give some explanatory message when the user clicks them?

Would that be the best of both worlds?

I shouldn’t have worded my opening so harshly. I don’t COMPLETELY disagree–just disagree on his assessment. He knows far more than I ever will about this business. I love his blog and really appreciate the way he runs his company.

What I disagree with is his assessment that users get confused by disabled menu items.

As I stated in my post, I think the disabled options help provide context for where the user is at.

There seems to be three schools of thought on this matter. Hide menu items which are not available, show them but provide a message when the user clicks on them, and show them but disable them. I disagree with the first two methods. I guess I subconsciously used this post as a way to argue my point and argue against the other two.

I didn’t mean to allude that Mr. Spolsky was in favor of hiding the menu options, but looking back at my post, I certainly came across that way. His idea of showing the menu item enabled with a message is better than hiding the item, but I prefer the visual clue the disabled item provides.

Thanks for keeping me honest.

Nowhere does Spolsky say you should hide such menu items, to the contrary, his advice is :

“Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.”

What gives?