The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Menu items - to grey out or not to grey out?

A typical UI will have menus or links that allow the user to view, edit and remove data in various ways.

Please may you help me decide on the following...

If the user isn't authorised to do perform a certain action, should the menus and links be hidden or disabled in the UI?

An alternative is to display a friendly message after the user has selected a menu or link that is not authorised.  At least then the user can learn how to enable the option.

Are there any strong agrument for and against disabling or hiding menus or links from a usability perspective?

Tuesday, May 29, 2007
Disable items only if it's obvious why the item is disabled, such as File -> Save when there is no active document.  Leave the item active and show a message if there's some complex reason why an action could not be performed.
Chris Nahr
Tuesday, May 29, 2007
For me, it all depends on the reason why the item is not accessible.

If it is a security issue, and the user should not have access to the item, then I am in favor of hiding.

If the item is normally available, or would be available if the state of the item were different, then I go with disabling. I like to use a hint or tooltip explaining the reason for the item being disabled.

There are always exceptions to consider.

A trainee who will eventually be able to perform action X, needs to request Action X be performed by a 'level 2' - it might be reasonable to disable it, and explain the security reason with a hint on the disabled item. If X is a necessary step that needs to be done, not showing the user can cause him to feel stuck... Or, you can write a task/approval system and capture that the user wants to X, but it needs to be approved by a level 2... in enterprise applications, sure, but in a utility to track recipes, this is a *bit* heavy...

The problem with using hints to explain disabled items is that if you start with it, you should be consistent, and that means putting hints on everything that would be disabled, writing the text, etc... but maybe that is another discussion.

The fewer options a user has to 'eye over', the better, the simpler his experience will be. Options that are NEVER enabled for a user clutter the view and can be annoying.
I still code in Delphi
Tuesday, May 29, 2007
+1 for "I still code in Delphi" explanation.
Eric D. Burdo Send private email
Tuesday, May 29, 2007
If the user will never be authorized to perform that function unless their system-credentials are modified, I'd be in favor of hiding the items. In that case, showing these functions is merely distracting and causing unnecessary clutter in the UI.

It's also a way of teasing your user with a carrot that's perpetually just out of reach, and therefore frustrating to a certain class of users . You don't want your users frustrated with your software, now, do you?
Tuesday, May 29, 2007
Unavailable always for this user ---> hide

Unavailable just for the moment, e.g. on this bit of data ---> grey

I don't really like the idea of showing an item, and then when the user clicks it saying "Ha ha tough luck, you can't because...".  That seems to break the Windows style guidelines, although it may unavoidable in some cases if takes a lot of processing to figure out if a particular option can happen at a particular time. 

If you want to display a complex explanation of why an item is unavailable, I'd put it in a tooltip, or in the status bar when the user moves the mouse over the button/menu. This fits the existing Windows standards - if you highlight different menu items, even greyed ones, it's quite normal for the status bar to explian the option and what it does and when it's allowed in more detail.
Sunil Tanna
Tuesday, May 29, 2007
I take the US Navy "Submariners" point of view on this.  Which is, that everybody should be (eventually) trained in everything, even things which aren't (currently) their role.

Thus an 'operator' may not have 'supervisor' status.  But it's still helpful for the 'operator' to know what his supervisor can do, and when to go to the supervisor for help.  Keeping 'greyed' out menu entries, that only the 'supervisor' can access when logged in as 'supervisor', is thus helpful to the 'operator'.  He knows what options are available, even if activating that option requires him getting the 'supervisor'.

If you 'vanish' stuff, then when the 'supervisor' logs in and all those 'hidden' menu entries appear, the 'operator' can be confused as to what's going on. 

Also, nothing is more common than having an organization wanting to 'migrate' options from role to role.  It turns out while using the software that some common 'supervisor' option is needed a LOT for 'operators' -- so it now needs to be enabled for 'operators'.  If they've NEVER seen the option before, again this can be confusing.
Tuesday, May 29, 2007
This is actually one of those things that has been debated ad infinitum over the years.

Disabling is much better than removing because disabling doesn't change the spatial arrangement and muscle memory of the other items.

I can see that if something is permanently not available to a person, then you could toss it. But the point that a junior and supervisor might switch roles is well taken. Also, some programs will disabled the items of their 'pro' version, providing a bit of an advertisement about all the features you'd get if you'd pony up the cash.

As to disabling vs a message, disabling is considered better. This requires interactive controls that update in real time. As soon as the specified data goes bad, the [OK] button needs to be disabled so the person can see through discovery why it was disabled.

But I have found situations where a normal person will never find a feature if it is just always disabled like this because the valid data situation is some combination of factors that is not obvious. In these very rare cases, I use a message which is customized to the specific validity situation.
Meghraj Reddy
Tuesday, May 29, 2007
Whoa. Apostrophe overload...

I don't agree with you there. Showing options that an operator can only use with they are promoted to supervisor may make a confusing and unfriendly UI.

Raymond Chen discusses it here:

1. Only grey out option, if, by some other user driven action  or event, it may become enabled again.
2. If it can never be enabled, no matter what the user does, hide it.
Tuesday, May 29, 2007
The user can log in as supervisor to enable it, so it  should be shown. Or he can buy the pro version, so it should be shown. The key is that the user should be able to figure out what this action is that makes it work. Some programs have special glyphs in the menu to indicate that the option is available in some other mode, such as supervisor or pro. By your interpretation of Chen's remark, you should not show files in the file system that are owned by root and not readible by users, forgetting that su is available.
Meghraj Reddy
Tuesday, May 29, 2007
Talk to your users. I worked with one group that wanted everything visible and enabled no matter what. If the user clicked on something that didn't work at the moment, we had to explain why. This customer's top priority was nothing should change state (visible, enabled) based on rules the user might not know. The explanations we popped up might be surprising, but never mysterious. I thought it was an odd choice, but they paid the bills.
Stan James Send private email
Tuesday, May 29, 2007
IMO, you should definetely hide stuff they can never use. The more debatable point is what to do when they temporarily can't use something (eg. you can't modify an order that has been filled).

We took the approach of graying out, but after living with this a while, I think that unless the reason it's grayed out is brain-dead obvious to everyone (which would rarely be the case), enabling it and providing an explanation why they can't do it (if they select it) is better.
Greg Send private email
Tuesday, May 29, 2007
If the user cannot do the action, don't put it in the menu.  If there are separate modes of operation, for example, supervisor vs. normal user, treat these as separate applications and hide the supervisor options or put them on a separate screen altogether.  Absolutely do not let me select the item and show me a screen saying "No, you can't do this."
Wayne M.
Tuesday, May 29, 2007
"Absolutely do not let me select the item and show me a screen saying "No, you can't do this." "

I hate this sort of thing, I click, choose some option, and THEN I am told "No you can't!" No thank you! That is entirely frustrating!
I still code in Delphi
Tuesday, May 29, 2007
Don't HIDE it, gray it out. Let people get used to the structure of the menu instead of shuffling it around.
Wednesday, May 30, 2007
> Let people get used to the structure of the menu instead of shuffling it around.

You and Meghraj are missing the point

If the user can _never_ access that option, no matter what he does, then there's nothing to get used to, and muscle memory etc., simply don't apply.

And BTW, I hate to see the Unix SU file system used an example to emulate - and anyway it's irrelevant, because hiding is for the user can _never_ access these options, but Meghraj is talking about an example where they can access these options thru a system route.

Anyway some other points in favour of hiding:

1. It can free up screen real estate, making the workers who use the app, more productive

2. It saves time in training, manuals, etc.:  If you have lots of greyed options, every training session for worker drones the questions will come up "What are these back-up, restore, password management, user management, database reindex, reporting, data-mining, etc., options?". 

And if there are a lot of options that are not available to most users, the above is greatly magnified.  Imagine for example that you wrote the system that managed orders in a car rental chain... would you really want to clutter the app that people actual working in the rental stores use, with lots of unavailable options that these people can never access? 

Wouldn't it be better to give Joe sales clerk, only a "Rent car" option, and Sally branch manager, "Rent car, Review Branch report" options, and  Tina regional manager a lot more options, and so on.
Sunil Tanna
Wednesday, May 30, 2007
I will add a little thing in order to add to the confusion... :)

With the software I am working on, user expects to be able to start a complex acquisition using his electronic microscope, this is the main purpose of our software. But in order to start the complex acquisition, we need a very simple acquisition first.

In the first design, the complex acquisition was just grayed out until the user had done a simple acquisition. As the complex acquisition was impossible and needed a simple acquisition to be done before, we thought that it was a good thing to just disable it.

Recently, I made a little change to the application. The complex aquisition is no longer grayed out and user can activate it immediately. If a simple acquisition is not available, we just suggest the user to let the software do an automatic one before starting the complex acquisition.

This is more natural now because the main feature of our application is not disabled when you start the application. Although it cannot be done in the current state, we just provide the user with a way to do want he wants the software to do.

Better, we actually are educating our user about how our application work. Educating is a good path to trust :)

So, sometimes, disabling and hiding are not the answer. You have to think why the feature is unavailable, and if the user is expecting the feature to be unavailable. If he is not, there is a good chance that he will find your UI disturbing because he can't do what he wants to do.

Another option is to let him do what he wants and to take him by the hand in order to help him achieve it. Maybe the next time, he will use the standard way of doing because he learnt how your software works.
Vincent Robert Send private email
Wednesday, May 30, 2007
From a UI design point of view I use the following rules.

If the feature is hidden it doesnt exist.  If the feature is greyed then it is not accessable at that point of time.

One would normally hide a feature for security purposes. ie. That user cant do that option ever.  ie. A general user would never see admin users options.

One greys out a feature to indicate that it is not possible to perform that action in the current context. For example, one cannot perform a paste unless a copy or cut operation has been performed.
AndyW Send private email
Saturday, June 02, 2007
It sounds like we got the archetypal cases down: Disable if the prerequisites are obvious and the user can complete the prerequisites immediately in the current window. Hide if the users cannot complete the prerequisites without essentially changing who they are (e.g., change job position, role, security clearance, or authority). For in-between cases, where the prerequisites are relatively non-obvious but completable, I’d build off of Vincent Roberts suggestion --enable the control but on selection provide the means complete the prerequisites. Don’t show an error message saying, “You must set your Foo before you can Bar.” Instead, present a dialog box with a Foo dropdown list for the user to set. You can even provide some hints to the control’s behavior by dynamically adding and removing the ellipsis from the control’s caption depending on whether the prerequisites have been met or not. At the very least, provide a button in the error message box that navigates the user to the proper window and objects to complete the prerequisites.

One thing more: even when it’s “obvious” the prerequisites are not met, it may not be obvious to certain users under certain circumstances, so it’s preferred to provide context-sensitive help on the reason for any disabling. I’ve always wondered if a tool tip for the disabled  control could be used for this (e.g., “Select text or object to copy”).
Michael Zuschlag Send private email
Monday, June 04, 2007
"I hate this sort of thing, I click, choose some option, and THEN I am told "No you can't!" No thank you! That is entirely frustrating!"

Not as frustrating (IMO) as floundering around trying to figure out WTF a particular menu item is disabled... "Oh, I didn't realize this account has a negative balance. So THAT'S why the 'Write Cheque' option is grayed out!"
Greg Send private email
Wednesday, June 06, 2007
You can't please everyone, but in the real world it's better to make the state of the application visible than to hide everything behind buttons.

If there's a reason why an action is unavailable, you need to make it visible why it's unavailable. It's difficult work, but that's why we're not being paid minimum wage.

And if you can't do the job, maybe you should try working as a WalMart greeter.  I hear they don't have to do so much difficult thinking.

Thursday, June 07, 2007
""I hate this sort of thing, I click, choose some option, and THEN I am told "No you can't!" No thank you! That is entirely frustrating!"

Not as frustrating (IMO) as floundering around trying to figure out WTF a particular menu item is disabled... "Oh, I didn't realize this account has a negative balance. So THAT'S why the 'Write Cheque' option is grayed out!""

That is an excellent point, and one that leads us back to the tedious developer job of providing 'disabled hints'.

procedure TUIHelper.SetControlDisabled(AControl: TControl; const ADisableReasonId: Integer);
  DisableReasonText: String;
  DisableReasonText := GetResourceString(rstTextHint, ADisableReasonId, gSession.GetLangId());
I still code in Delphi
Friday, June 08, 2007
"Another option is to let him do what he wants and to take him by the hand in order to help him achieve it. Maybe the next time, he will use the standard way of doing because he learnt how your software works."

Devil's advocate: Since it worked the way he did it, why should he change?


Gene Wirchenko
Gene Wirchenko Send private email
Friday, June 08, 2007
All of your points are valid and well taken.
If we "hide menu items.. the user will never use" we are assuming, in many cases this user will NEVER have the security rights to use them. I think the choice should be application dependent. In a orginazation with many security levels, it is often likely that users will assume higher security levels as time passes, and/or they move up the orginazation ladder. If their security rights are changed, and they are allowed more user rights and these prevoisly greyed out optiona are now available to this user, I believe it makes for an easier transition, and better understanding of the application if they have 'seen' these options before, and they are not brand new.
Of course, if the option to exlpain why an option is greyed out, via a ToolTip is a good idea.
...and yes, I HATE, clicking an option only to be told, no you are not high enough on the ladder, or smart enough, to use this feature. Very demoralizing to a user.
R. Austin Send private email
Saturday, June 23, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz