| Date: | May 14, 2004 / year-entry #189 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040514-00/?p=39343 |
| Comments: | 18 |
| Summary: | When you're displaying a menu item or a dialog option, and the option is not available, you can either disable it or you can remove it. What is the rule for deciding which one to do? Experiments have shown that if something is shown but disabled, users expect that they will be able to get... |
When you're displaying a menu item or a dialog option, and the option is not available, you can either disable it or you can remove it. What is the rule for deciding which one to do? Experiments have shown that if something is shown but disabled, users expect that they will be able to get it enabled if they tinker around enough. So leave a menu item shown but disabled if there is something the user can do to cause the operation to become available. For example, in a media playback program, the option to stop playback is disabled if the media file is not playing. But once it starts playing, the option becomes available again. On the other hand, if the option is not available for a reason the user has no control over, then remove it. Otherwise the user will go nuts looking for the magic way to enable it. For example, if a printer is not capable of printing color, don't show any of the color management options, since there's nothing the user can do with your program to make that printer a color printer. By analogy, consider a text adventure game. The player tries something clever like "Take the torch from the wall", and the computer replies, "You can't do that, yet." This is the adventure game equivalent to graying out a menu item. The user is now going to go nuts trying to figure out "Hm, maybe I need a chair, or the torch is too hot, or I'm carrying too much stuff, or I have to find another character and ask him to do it for me..." If it turns out that the torch is simply not removable, what you've done is send the user down fruitless paths to accomplish something that simply can't be done. For an adventure game, this frustration is part of the fun. But for a computer program, frustration is not something people tend to enjoy. Note that this isn't a hard-and-fast rule; it's just a guideline. Other considerations might override this principle. For example, you may believe that a consistent menu structure is more desireable because it is less confusing. (A media playback program for example might decide to leave the video-related options visible but grayed when playing a music file.) |
Comments (18)
Comments are closed. |
I think a possible exception to this rule is context menus. For some of the programs I have worked on, there are a lot of possible options to show in a right-click menu so narrowing it down to just those that can be done in the current context seems to make sense. For example, “Paste” might disappear from a context menu if there is nothing on the clipboard so there is more room for other options. The only problem with this is that sometimes almost all options are available so the context menu can be very long (and dropping items to make space might not be acceptable as the user expects those items to be there).
But sometimes is a good idea to give the user an idea why the option is disabled.
(it is not the case of the adventure game "You can’t do that, goto to the cave to get it" :)
In this case the option would be enable (with some little difference perhaps) and when selecting it, show a description of why it is disabled.
But better than this would be to show the reason it is disabled in a tooltip or something similar (status bar?).
VERY true point! I spent hours trying to make my bar graphs transparent in Excel. The option is there, but disabled. Finally I found out that this is a Mac Office feature only :( What a waste of time. And not even a single word on that in the online help for that dialog or anything like that.
I’ve seen a Hewlett Packard printer driver that disables unavailable options and puts a small “information” icon which, when moused over, pops up a balloon describing why the option is not available.
Also, when I see a disabled option whose label sounds interesting, I tend to look for its What’s This.
indeed.
on a related note, something that i’ve always liked about novell’s file sharing is if you don’t have access to a directory, it won’t show it in directory listings.
One problem with showing and hiding menu commands, as opposed to enabling and disabling them, is that the commands below them jump around depending on whether they’re visible or not.
Take Notepad’s Edit menu, for instance: Cut, Copy and Delete are only available when there is text selected. If Notepad hid these commands when no text was selected, the Find command would be up near the top of the menu or near the bottom depending on whether you had text selected. So the user would need to read the Edit menu each time they clicked on it to figure out where the Find command was this time.
Another thing to consider with showing and hiding commands is that people don’t always remember which menu a command was under. Or at least I don’t. A grayed out item means you can’t do that right now. A missing item means… well, maybe it wasn’t in that menu, how about over here? no… maybe here? hm, maybe this program just doesn’t support that.
This is a great tip ! Is this written in a book somewhere ?
What about the Forward button in the explorer frame in Longhorn? Shouldn’t that be visible but greyed out if there isn’t a page to go forward to, rather than not visible at all? I’ve seen several people comment on it being missing.
I agree with the first poster. There’s very few things I ever think should be removed completely. Much better to disable, but provide an explanation as to why. There is nothing more frustrating than trying to walk through a manual, say for a foobie player, which says something like "to enable sound on your foobie player, go to setup->sound and click on "enable sound"". Then you go to that menu, property page, or whatever user control is currently in style and the enable sound choice is greyed out (or worse yet, completely absent) with no explanation.
That drives me nuts because it spawns all kinds of questions; do I have the right plugin installed, do I have the same version of the software, do I not have the right driver, where is the log for why the driver did or didn’t load, what driver would I even be looking for, etc.
One interesting problem on removing an operation entirely is diagnosis.
Example: If you can’t suspend your machine because of a non-powermanagement aware driver, you don’t get the suspend/hibernate options on the shutdown menu. But, now there is no event that can tell you which driver is at fault (assuming you don’t have a special keyboard key for this).
Some of this could be addressed by hiding the reason the option was removed in the event log. However, such locations are not easily discovered by the user. Furthermore, that may be an inconvienent place to launch a troubleshooter tool.
Sometimes I have no idea why a menu option is disabled. Take for example notepad. Sometimes the Go To option under Edit is disabled. I finally found out by debugging that it is the Word Wrap feature (which is persistent) that disables the GoTo feature. I wonder how non-developers are expected to find out why Go To is gone.
If you’re disabling menu items for the purpose of hiding functionality for versioning, be sure to not just disable the menu item, but do a check in the invoked method to make sure the user should really be there.
I’ve seen a lot of programs that use the same executable for their "demo" version and the real one, where you can quickly purchase a passcode/.reg/whatever online to enable the full functionality. Most of these dynamically disable (on parent menu open). It’s about ten minutes of work (would be two if I were faster) to bring up SoftIce and prevent the disabling… thus opening up the functionality.
I understand in this case that they’re trying to demonstrate "yes, Martha, this product really does do X". It’s just the way it’s implemented.
So, Raymond’s comment "Experiments have shown that if something is shown but disabled, users expect that they will be able to get it enabled if they tinker around enough." is particularly apt. ;-)
And, yes, this sort of thing isn’t the main thrust of Raymond. I agree in general that if there’s no way to enable it, don’t even bother showing it. That works as a general principle for me. But it doesn’t handle the marketing aspect, where the vendor *wants* you to see what you’re missing. If there were a second type of standard "disabled" look&feel, then you could show both.
As for the disabled Go To feature, Google for "notepad go to disabled". If you hit the "I’m feeling lucky" button it will take you right to http://blogs.msdn.com/oldnewthing/archive/2003/11/19/55744.aspx Or you could just read Raymond’s blog a bit more fastidiously :)
I prefer to use a program with fairly static menus, where items are enabled and disabled. For example, I always disable the dynamic menus in Word and in the Windows start menu.
Dynamically changing menus are disorientating.
Look at it this way. In one case a user may play around to try to enable a disable menu item. In the other case, he has to keep opening all the menus, to see if any new and interesting items have suddenly appeared!
I’m with Phil and the others. If you remove a menu item you change the position of other items in the same menu (in terms of their position from top/bottom). Since I know where menu items are I can usually just select the menu, move the mouse, and click, without looking too hard. If the item is disabled nothing happens (good or bad), but if it is missing then I just might nuke the USA by mistake (this could be good or bad depending on your viewpoint).
I have always hated dynamically changing menus because they go completely against my muscle memory.
Those ‘clever’ menus of lately always confuse me. Luckily up till now this feature can be disabled, but I dread the day that some *ssh*le that thinks he knows what’s best for me decides I don’t need to be able to disable those ‘personalized’ menus.
PingBack from http://schinckel.net/2008/07/02/disabling-menus/