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?
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:
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.
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.
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 is what apple says about hiding application features according to its location:
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
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.
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:
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 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: