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.
I thought it was pretty common knowledge that users don’t read message boxes. Anyway, I’m squarely in the disable-menu-items-that-aren’t-applicable camp, and I never hide items.
Take the Refresh Data menu item in Excel. It’s disabled unless the activecell is part of a pivot table, external data range, or probably some other things. If MS wanted to use the Spolsky method, they would have two options. First, they could make a five word message box that would be so cryptic as to be no help or second, they could write a 30 word message box and nobody would read.
No, I think disabling irrelevant menu options is the way to go. But I’m willing to listen. Thoughts?
Never, ever let the user do something and then complain to them that they’ve done it. It makes both of you look stupid, and that’s no way at all to get people to use your software.
Hello Dick,
I agree for the most part with Joel Spolsky, especially with the hidden items. Take for example the 2007 ribbon; I prefer a steady/static menu that shows me the full capability of Excel. In previous Excel versions a lot of people in Excel choose to always ‘show full menus’ instead of just displaying the items you use most.
About the disabled items; I have seen people frustrated because they knew what they needed, but the button was disabled (people always seem to have little time and patience). I then prefer a message telling the user what to do, instead leaving them without a clue of knowing why it is disabled. They might even learn from it.
Rob, if you make it a friendly message the user doesn’t have to feel stupid and can be guided in the right direction. That is how I see it.
Kind regards,
Bastien
I get thoroughly confused when menu items are removed.
Most users are smart enough to get confused as well. :-)
I think they get it when items are disabled.
Amen to what Rob said.
I was surprised by Joel’s statement.
It appears there’s pretty much unanimous disagreement with that statement. I have some quick-and-dirty macros that graduated to my add-in menu for which I never bothered with enabling/disabling. Even though I wrote the code and have used it for years, I still manage to occasionally trigger it in an inappropriate setting and screw things up. I don’t see a message box telling me I shouldn’t have done that being any more useful than the VB error box.
This whole discussion reminds me of my favorite windows application ever, the appropriately named Windows Enabler. It allows you to totally disregard the programmer’s intentions and re-enable those disabled controls to see what happens.
http://www.angelfire.com/falcon/speedload/Enabler.htm
I mostly agree, but I think there are gray areas. For example, one of my addins allows you to save a workbook in a certain format. It doesn’t work if the workbook hasn’t been saved yet, i.e., it’s still “Book1?. I don’t disable the item in that situation though, because I think it would be more confusing to the user. Instead if they click it there’s a “This workbook must be saved first” message. I don’t know how else I’d explain it as effectively beforehand. Of course, I should really offer the chance to save the workbook right then and continue, so, bad example…
Maybe a better one is if you try to print a blank worksheet. You get the “nothing to print” message. I think that’s better than greying it out, which could be more confusing. I’d also argue the same for the message you get if you try to sort or filter in an empty area. Except the message you get is not much help either…
I mostly go with disable rather than hide on a form, but also use Messages for command sequence problems when the user has to have done something first ie “Please get history data before doing forecast”. I guess I dont have hard and fast rules: it all depends on context.
Preferably I consider workboooks and documents as data storage facilities. The most important VBA instruction I use is Application.visible =false. Communication with the user is being handled with a userform.
Essential prerequisite is a thorough analysis of the tasks the computer has to perform and which instructions (and in what order) the user has to give to the computer. I try to let the computer work ‘for’ the user instead of letting the user work ‘with’ the computer.
If in some cases user-involvement in unavoidable (for instance when assessing the result of the computer’s work: products in Word) I usually disable all commandbars and design a special commandbar fitted for the task that is being performed. If users ‘complain’ I consider that as feedback on where I missed something in the analysis of the task the computer has to perform.
I’m with Rob.
In menus etc I really don’t like hiding stuff, disable would be me preference. For forms sometime I might hide a child section till required.
I tend to work by position so I know roughly where I expect to find stuff and scan from there till I find it. I can only assume whoever came up with personalised menus (and the Ribbon) works completely differently.
I’d get quickly annoyed if I was offered a bunch of identical looking commands and half of them just fired a message box saying they weren’t allowed, wasting me 2 clicks to learn what greyed shows with zero.
Lets split the atom:
Disable, not hide,
Error messahe when you click a disable option telling you what to do?
Do i win Dick? lol!
In a lot of the new .Net/SQL 05/08 there is loads of error handing stuff that ponits to help files and web sites etc. 2 things to note about this, pointing to help on a web site that is not there is WORSE that totally f@#king useless, if you put URL in you code make sure they are going to work for the next ten years, or I will shoot you, you idiot. Next thing, if you going to write help file, for goodness sack make them usefull and actually helpfull, I can count of the fingers of one hand the number of times MS help file have helped me. Why can a chap working at his day job, and writing somthing up quickly be soooooo much better at write help topics that some MS gimp boy who does it for a full time job?
and another thing…..
I’m going to guess that Joel Spolsky’s opinion is based on writing software for sophisticated software users (e.g., software developers). Using a Windows vs Unix difference, Windows will ask if you really mean to run a command like
> del c:*.* /s
while Unix shells won’t grumble about running
# rm -r /*
provided the user has sufficient privileges/rights.
Classic paternalistic vs libertarian dichotomy. Windows (paternalistic) approach is don’t let users say ‘Do X’ when Windows can detect that it can’t do X. Unix (libertarian) approach is allow users to say ‘Do X’ for any & all X, but then tell users the system can’t do X along with the reasons it can’t do X.
From my perspective, the paternalistic approach has everything to do with everyone avoiding looking bad (as Rob says), and NOTHING to do with teaching anyone anything/anyone learning anything. The libertarian approach is all about teaching/learning with no concern at all for who may look bad.
So, if your users care squat all about learning anything but WILL NOT TOLERATE looking bad, then hide/disable unavailable commands.
FWIW, there’s a middle ground: use the Status Bar – when the mouse pointer is over anything in the menu/ribbon, display a short synopsis of the command in the Status Bar. When it’s disabled, indicate so and include a prompt to press F1 (or [Ctrl]+[click] the menu item) to display a dialog with the likely reasons it’s disabled. Perhaps better still, if the user has hovered the mouse pointer over a disabled menu item for more than [user-selectable] seconds, display a modeless text box with such information.
Seeing a grey disabled option that is not applicable is great because it tells you if you get things right you could be on to a winner with some clever new function that you otherwise didn’t even suspect could be done.
Allowing a user to click on a stupid black menu item and then throw up an error is stupid and no one likes that inefficient misleading teasing.
Hiding a function that is not applicable can some times be sensible but if the option is something that is currently not available but could be if you tweaked your options, then you are just hiding the information from the users and they will never be able to hunt around for the settings that they need to unleash this hidden functionality.
Viva la grey options !
Hiding was just wrong and MS took a lot of well-deserved flack for it in Office, I’d suggest.
As for enabling, I think Joel’s wrong to make it an absolute. I hate “you got it wrong” or “you can’t do that here” messages, especially the MsgBox(OK|Cancel) ones. They’re almost always the result of insufficient thought on the part of the designer/programmer.
If something more constructive can be done, like perhaps displaying a dialog that will walk the user to putting the app into a state where the menu item is valid, then good. Otherwise disable.
But maybe better application design would lead to menus where everything could be in context? Or maybe we’d get rid of menus in a better-designed app? Office 2007, anyone?