Should unauthorized actions in the UI be hidden, disabled, or result in an error?

Question

This is a perennial question for me that I've never really resolved so I'd like your input. If I have actions that I know a user will not be able to perform due to insufficient privileges or object state, should the UI elements for those actions be hidden from the user, visible but disabled, or visible and result in an error if attempted? What would be the rationale for your answer? If disabled, would you communicate the reason why and, if so, how?

This is a web interface so I already know that I need to check the incoming post/get for permissions and handle errors there anyway. I'm primarily talking about how to handle the UI.

This is similar to http://stackoverflow.com/questions/79033/rules-about-disabling-or-hiding-menu-items, though I am interested in all types of UI elements not just menus.

Examples:

1. I have a New page that allows a user to create a new Event. Events can be master events or subevents. Creating a master event requires "EditMasterEvent" privilege, while creating a subevent requires only "EditEvent" privilege. I have a drop down that allows one to choose an existing event as the parent (master event) or no parent (this is a master event). Should the "Create Master Event" choice be shown on the dropdown or omitted if the user only has "EditEvent" privileges.

2. Deleting events requires that you be an application administrator or have the appropriate edit permission for the event type. In the latter case, the event must also be more than 5 years old. Deleting an event causes major cascading deletes of related data in the system and for legal reasons this data must be kept for at least 5 years after the event. Since this operation is rare for the normal user, the typical case is that the action is not available. Should it be shown always or only when actually possible?

Answer 1

I disable the elements instead of hiding them. That way the user knows the option would normally be available, and I provide a tooltip to explain why the element isn't currently available.

Answer 2

Depending on the item, we will either hide them or disable them. If the user has access to a large feature, but not to a smaller piece inside it, then we will hide the smaller piece. However, if the user has access to several large features, but not to others, we'll leave them visible but disabled as a marketing ploy to remind them that the features are available for purchase if they should decide they want them.

Answer 3

Great question!

A couple of considerations:

If you place the elements on the page but disable them, there's still a remote chance that the user could doctor the system and enable them using a javascriptlet.

If you do not show them at all, the overall functionality may be a bit confusing to the general user. "Shouldn't there be an edit button here?"

If you're going to either display and disable or display and verify the elements, I would definitely do server-side validation. Don't leave the validation in the hands of JavaScript; I think the reasons for this are obvious.

Answer 4

It depends. Do you want the user to be aware that the action is possible, just not for them? In that case, show them the button, but disable it. An example might be if a user doesn't have delete authority, but other users do, they should know that entries CAN be deleted, so they can ask someone to do it for them if they need the action.

On the other hand, if the user is not supposed to even know about the action (for example, a user who does not have read access to audit logs probably shouldn't know that these logs exist) should not be able to see the button, so hide it completely.

Answer 5

I've also seen some programs that disable the menu item and change the text of it to "Log in to do blah..."

I like this because it doesn't leave me with the "why isn't this working?" feeling and tells me immediately what to do to get it working. Not applicable in every case, but this is a nice approach if you can implement it.

Answer 6

I have a particular hatred of applications that disable buttons. If you're an end user - you want to know why you can't use that button. Having it greyed out doesn't tell you anything. How do you get to the state to enable it? Tooltips are one solution, but they aren't the best, a lot of users will struggle with tooltips (unless you're working with experienced users).

Answer 7

As with nearly all UI questions, the answer is "it depends".

You need to weigh discoverability with user satisfaction, among other things. For example, allowing an invalid action gives you an opportunity to explain why something is invalid. This is particularly useful if the answer to "why is this disabled" isn't obvious. For an application where most users are beginners, that's important.

On the other hand, it can be mightily frustrating to see a control, click on it, only to be rewarded with a "sorry, you can't do that now" message. An app I inherited a couple years back was rife with that sort of stuff and it made using the UI an exercise in frustration.

Completely hiding functionality is probably rarely a good idea. Imagine knowing some feature "was there a minute ago" but now it's gone. Whether it's a menu item or a toolbar button or something else entirely, making it hidden can be an exercise in frustration for the end user.

Try doing a little usability testing, if only by asking the next person you see "hey, does it make sense to disable this or show you an informative dialog". Just one other opinion is often enough to get you to look at the problem from another direction.

Bottom line: do what best serves the user. All the scenarios you mention are valid under certain circumstances. As with all UI questions, ask yourself (or better, your users) what best serves their needs.

Answer 8

My personal feeling is that the elements should always be present. If the user doesn't have enough permissions to do them, they should generate an error when clicked upon.

I know that translators don't really enjoy creating a zillion different "permission denied" error messages, so this is often not done in localised applications, which tend to hide the elements instead.

In practice a lot of people tend to hide the options instead even in non-localised apps.

Answer 9

I tend to handle the two different types of situations differently. Is this an action that is governed by privilege and by state of the object.

If the person does not have enough privileges to do an action, I hide the option, they do not know they can perform the action.

If the option is not available because the object is not in a state that can use that option, I disable it, allowing the option to be visible to the user, but no action can be done.

From your examples:

1. I would not have "Create Master Event" as an option. The user has insufficient privileges to view it.

2. I would have the Delete button visible to the administrators. Then depending on how you do the rest of the site (a lot of visible text, tooltips, help icon, etc) I would follow that convention about informing the user why the button is not usable at this time. And possibly putting a timer on, above, near the button with either how old the post is or how long until it can be deleted.

Answer 10

Hidden - This is the best approach for actions that are never available to the current user. There is no point in having the user waste mental effort figuring out why something is disabled if there is no action they can take to change this.

Disabled - This is the best approach for actions that are sometimes available, but not at the moment or in the current context. A disabled option should convey two things: first, the action is not available right now, and second, there is something the user could do to make the action available (change some setting or permission, select an item, enter prerequisite data, etc.). If you can indicate what needs to be done to enable the action in a tooltip - all the better. Enabling/disabling actions as the user enters data or changes context provides excellent feedback about what the program requires.

Fail with an Error - This is the worst choice. You should only resort to an error report for operations that might work: you can't tell that it will fail except by trying.

Answer 11

The general rule is use disabling if the user can do something in the UI to get the privilege. Disabled means “you can do this command, but just not right now the way things are.” The “way things are” includes the current selection, so use enabling/disabling if the user has the EditEvent privilege for old objects but not for new objects. There should be a clear indication which objects are delete-able so users understand why the associated commands are disabled for some objects (e.g., if users generally know that records must be kept for 5 years, a simple Age field maybe be sufficient, perhaps reinforced with a graphic difference for records over 5 years old).

Use message boxes instead of disabling if there is no way to make the reason for the disabling clear to the user assuming they have average knowledge of the domain. Tooltips for disabled controls, BTW, are a great idea, but may not be sufficient by themselves.

Use hiding if the user never has the privilege no matter what they do in the UI given their current position in the organization (e.g., they are not an Application Administrator). It is cluttering and frustrating to use disabling or message boxes for this case. As far as the users are concerned, actions they don’t have the privilege for are not their job (otherwise they’d have the privilege), and so the associated controls should simply not exist in their UI. Documentation or organization procedure manuals may tell users how such actions are accomplished (e.g., “Your supervisor creates new events for you.”).

I’ve more details at http://www.zuschlogin.com/?p=40.

Answer 12

I would say disable with a hover containing the reason.

It prevents the user from wondering what the hell is going on while at the same time letting them know certain actions are possible under the right conditions.