What is a good criterion or rule-of-thumb for determining when a control should be greyed-out and when should it be completely invisible?
possible duplicate: Don't hide or disable menu items?– Ben BrockaFeb 7, 2013 at 15:30
It depends an awful lot on how you expect the application to be used.
If all your users are power-users (like Photoshop in @edgarator's answer) then you typically want to grey out rather than hide - you want your users to know that the feature is there, and they're going to be using your app for a while.
However if your users are less technical or (more likely) only occasional then you don't want to clutter the interface with controls that they're never going to get round to using. They're not going to hang around to find out why a particular action or control is disabled.
In these cases I switch to a few rules:
If the action is never going to be available to the user (for instance if they don't have rights or they haven't purchased the feature) then always hide it. I hate blank buttons on the dashboard of a new car.
If the action can be enabled by user action on the same page/screen (for instance a next button that needs a mandatory input box filled in first) then mostly disable.
If the action can be enabled by the user by doing something on a different page/screen then it comes down to whether you want them to go find how to enable any greyed-out options. Usually I find that it means you'd be better off rethinking how the pages/screens flow through what the user is trying to do.
If there is a lot of disabled functionality, for instance a whole extra block of form inputs then it's a judgement call. I tend to hide it and then highlight it should the user need it.
Basically the goal is always that the user can use it with the minimum of manual, so grey out something when you want them to know that there's something they can do to enable it. Hide an action to avoid distracting them.
Grey it out when you want the person to know that the control exists, but that it is disabled.
Hide it (make it completely invisible) when it doesn't matter whether they know that it is there or not.
In general I would opt to grey out controls rather than hide them, because someone could remember seeing a control somewhere that then not be able to find it again if it is now hidden. And there would be no indication why they can't find it again. When you grey out a control, you can have a little icon or something similar to let a person see why it is disabled.
Microsoft ran into this problem a number of years ago in MS Office, were they would hide menu items that you hadn't used in a while. It caused so many support issues, that they eventually dropped it.
Note that, however, there is one important exception to this rule: If the software assigns different roles to different groups of users, the ordinary users should not be aware of the advanced functionality available to more privileged users. For example, a forum moderator could be allowed to ban users, delete entire topics, etc. In such a case, the advanced buttons (menu entries) should be completely missing from the ordinary users' GUI (and not just grayed out).
This reminds me of Woocommerce, where they hide the all-important add to card button unless all options have been chosen.
Take a look at this:
vs the subsequent screen which shows the add to cart button and the number of items you want to buy. What if you wanted to buy two shirts but different sizes?
Hiding the most important parts of your navigation or CTA buttons is not a good idea in this case. In most of the cases, you can make use of greying out as a subtle indicator of optional functionality:
That's a weird one. Also, I think they were trying to be cute, but does "Flavour" actually refer to the color?– OliviaFeb 12, 2013 at 22:51
This question is very general. Without context it's hard to give an answer that would help. So this answer will be very general as well.
There are generally two reasons why an element can be active or not:
- The action the control would cause can't be invoked (e.g. a disabled "save" button because not all required data has been specified)
- The application is in a mode that doesn't support the control (e.g. disabled font dropdown while an image is selected)
In most cases, disabled or hidden controls are a result of modes: Showing a disabled element suggests that this element can, somehow, be enabled – usually by changing the mode your application is in. Think switching characters in a game: different characters will allow different actions, thus the player is in the same application (the game), yet what they can or can't do is determined by the mode they are in (the character they currently control).
Modes are a very troublesome thing for users, since the same UI may or may not allow different actions depending on the mode. The big problem is how to let the user know in which mode they are, and to make obvious how they can change it. This is where most applications fall short: Users find themselves desparate because a control can't be clicked, and the only clue the application gives is e.g. a small icon in the status bar.
Be assured: Users will look for a way to enable disabled elements.
Invisible controls may lead to confusion and disorientation.
Disabled controls may lead to investigative behaviour (which can be a good thing).
One general piece of advice: Keep the amount of hidden/visible and inactive/active controls at a minimum. Usually, there's a better solution.
This is what apple says about hiding application features according to its location:
People should be able to find all the available features in your app. Don’t hide features by failing to make commands available in a menu. Menus present lists of commands so that people can see their choices rather than try to remember command names. Avoid providing access to features only in toolbars or contextual menus. Because toolbars and contextual menus may be hidden, the commands they contain should always be available in menu bar menus as well.
Some disabled UI elements may hint users on application's behavior. When you hide them that hint is gone.
Take for example Photoshop, when you're in Indexed Mode (Like working with a GIF) you get this screen.
As you can see, the buttons in the bottom right are disabled. And that's typically what hints me that I need to go and change the image mode (between parenthesis next to
Untitled-1 @ 100%).
Now they are enabled!
As you can see the mode change is usually subtle, but the application manages to communicate the mode in many ways. If you just hide the buttons, you would just thing that the toolbox was closed at that point or start wondering about whether the application is running properly.
You should only make something invisible if it has no relevance to what the user is currently doing and doesn't provide any value for the user.
Forms are a good example. There's no point in asking a user to fill out employment history form if they never been employed or asking them to fill out a credit card form if they are paying with a gift card.
Greyed out controls suggests that the item is not active or disabled, but the user should be aware that it exists.
In error scenarios also we can hide. Assume I need to show a checkbox on page load, if there is a failure to get the current toggle status, disabling that would confuse the user, as he didn't make any mistake or his actions didn't cause it, it is a failure in fetching the information. So I assume in this case also we can hide.