Should a UI display actions that are not available?

Question

What is currently regarded as best practice in UI design for displaying actions that are not available in the current context.

For example, A page displays customers who can have many associated contracts. I do not wish to allow the user to delete a customer if there are active contracts. From a usability and UI perspective what is considered the best for the user experience.

1. Always show the delete option but warn the user when he selects it that the option is unavailable because there are active contracts.
2. Show the delete option but grey it out.
3. Do not show the delete option at all

Always showing the option has the benefit of consistency and the relevant actions are consistently in the same place etc, but conversely what is the point of showing them something they can't do.

Greying the option out still has consistency but does not allow them to select the action that they can not perform.

Not showing the option at all lacks consistency but will perhaps not be so confusing.

Before yesterday I would not have even asked the question and would have gone straight for option 2 (Greying out) however having watched a user try to click on the greyed out image many times and eventually asking me why they couldn't click on the button I am no longer sure what the best option is.

What do people with usability and UI testing experience feel is the best option?

Answer 1

For that scenario use 2, but add a question mark besides that explains why it is disabled. Update 1: Notice that it gives you the opportunity to be really clear on when it will be active/disabled.

Answer 2

I prefer showing the options, but greyed out. Here is why. If an action is sometimes available and sometimes not, the UI gets confusing. It seems like magic that I can sometimes see the delete and sometimes not. On the other hand, if it is greyed out, at least I know where to look for the option later.

Answer 3

I was always taught that removing objects from the UI was far more disconcerting for a user than disabling. Don't design for the .01% who cannot be helped!

Answer 4

My approach (and recommendation) would be that the button be grayed out as per your option #2.

When the UI is sparse and sufficient real-estate is available, having inline (up-front) contextual hints (such as the question mark approach suggested by Freddy, next to the button, detailing the problem in-line e.g. always display under the disabled button "No users to delete. Add some by going to (link)this tab(/link)!") can be desirable.

However, such inline hints or question marks that appear occasionally can complicate layout or hamper the effectiveness of the interface when real-estate is at a premium. In such cases it may be better to have an overlaid hint (a baloon or tool-tip) that appears when hovering over the disabled button as well as when clicking on the disabled button (i.e. the user manifests intent by approaching the disabled button with his/her cursor); the tip should explain why the button is disabled and grayed out, i.e. "There are no users to delete."

The above should take care of all (typical as well as pathological) cases. It combines the advantages of your #2 and #3 options, with hopefully none of the disadvantages.

Cheers, V.

Answer 5

You want your UI to be consistent, whatever the particular state. A lot of users rely on visual memory to remember the location of commands. Having to search for particular action every time is too much effort and is drawing the users attention from their main work in the app.

Thus, it's best to show the action to keep it in the visual context. However, visibly indicate that the state of this action is modified. This will give the user feedback that the action exist while still suggesting some condition needs to be met to allow the user to undertake the command.

Changing the color saturation is the most common approach to representing the disabled state. It makes the UI element to fade out in the background.

Answer 6

There are times when removing toolbar buttons is the correct way, but generally.

Removing it just makes the user wonder where it is. Whereas, disabling lets the user know where it is, but that it's not available. So instead of wasting time trying to see where the option is, they can spend the time finding out why it's not available.

Answer 7

I suggest option 1). I'll tell you why.

Option 3) (Worst) "Do not show the delete option at all" This doesn't even make the user aware that there is even such a feature existing. So it is the worse way to deny.

Option 2) "Show the delete option but grey it out"

Better than 3) but user may keep wondering why he is denied the functionality. He may also start to think that he is not a priviledged user and is lacking rights.

Option1) "Always show the delete option but warn the user when he selects it that the option is unavailable because there are active contracts."

This will clearly tell the user what is missing and educate him about the exact functionailty. Users are always happy to work on a transparent system which doesn't throw them puzzles.

Answer 8

Just apply the Principle of Least Surprise: don't do anything unexpected.

A greyed out option clearly mean that it's not available in the current context.
A missing option could mean anything.

One area where you would consider completely removing UI elements from sight would be when your application provides multiple levels of accessibility (for instance, Novice, Intermediate, Expert) or when user accounts follow some security roles where a 'guest' user isn't meant to access the full interface that a 'manager' user would for instance.

Answer 9

The second option, greying out the delete option should be enough. Adding a questionmark to explain, as suggested, seems like a good idea to me. Otherwise, the user probably has no idea why he can delete some customers, some not.

But you always have to consider the possibility that while user A has already opened the UI, with the delete option enabled, user B enters a new active contract. So if user A wants to delete the client, you still need to check that there are no active contracts, and show an error message if there are. In other words, you still have to implement everything the first option requires. For that reason, I'd likely choose the first option, always show leave the delete option visible and active, to avoid duplication of code and to offer the most consistent behaviour.

Answer 10

Raymond Chen (of The Old New Thing fame) provides good guidelines:

When do you disable an option and when do you remove it?

From the blog entry:

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.

Answer 11

For this particular case, option 2 is the best choice. When deciding whether to hide something or disable it, the general rule I follow is:

If the user cannot perform an operation and there is something they can do to enable it, then it should be disabled.

If the user cannot perform an operation and there is nothing they can do to enable it, then it should be hidden.

In your example, if the user gets rid of the active contracts then they can delete the customer. So the delete operation should be disabled since they have control over enabling it. However, say the user could not delete the customer because they did not have the “delete customers” permission. In this case, the delete operation should be hidden since there is nothing the user could do that would allow them to be able to delete the customer (they cannot give themselves the permission).

Whenever an option is disabled, it should be clear what needs to be done to enable it. In this example, when the user moves the mouse over the delete button, they should see a tooltip explaining why the operation is disabled.

On a side note…if users are trying to click your disabled buttons, it may not be obvious enough that the buttons are disabled. Try changing the style of the buttons so there is a greater distinction between enabled and disabled (assuming you are not using standard controls).