Is it better to prevent a forbidden action or display an error/explanation message?

Question

There are multiple examples, so I'll pick a specific one to focus the question.

Let's say a user can have specific characteristics (or permissions):
Admin, Virtual, External, Financial, etc.

To complicate things, users have different licenses too - Premium, Regular, Limited, etc.

You can probably see where this is going:
Let's say a user with a limited license cannot be an Admin or have financial permissions.

Possibilities:

• The admin goes to the profile of, let's say Zack and sees he cannot allow him to have financial permissions.
  The problem is that it's not clear to the admin why that is (the license info and the permissions are not displayed in the same location and even if they were, the admin would have to be aware of the system rule of "no financial permissions for limited users")
• The admin sees all the permissions (let's assume implemented via checkboxes) enabled and only when clicking gets an error message informing why the operation was denied.
  Now the reason is clear, but the admin had to "waste" a click to find that out.

Is there a way to both prevent the action and also explain why? Would a disabled control with a tooltip work? Any better ideas?

To briefly mention other examples - let's say you have an interactive graph and you can move most of the points on the graph, but some have to be stationary. You could draw them differently to indicate they cannot be moved (without explaining why), or you could let the user try to drag them and then show an error message.

Answer 1

Depending on the application, I often just don't display the parts of the page a user doesn't have access to. It sounds like you have users changing other user's rights, so this method may not work. I would recommend displaying an error message whenever you display a disabled input element. Users can become frustrated when they are unable to perform an action they expect to be able to do. If it is just disabled, they probably wont understand why and will just take it out on the program. Likewise, you want to make sure the message is as simple as possible and to the point. Long error messages are often ignored.

Answer 2

Before you completely hide a part of the UI for a feature which the user doesn't have access to, consider:

1. Will the user know about that feature?
2. Will they spend a lot of time hunting for it?
3. Would you be better off keeping it around in some kind of "disabled" state along with a tooltip or other indicator so that they can learn why it's not available?

Here's a simple example. Suppose that your application includes the option to print. When there is no printer available, should you completely hide the print menu command? Will this cause confusion and wasted time as the user hunts through all the menus and finally contacts your tech support team trying to find the "print" command? Will your tech support team even understand that this user is not seeing the "print" command? Will there be unintended side effects if, for example, the printer is attached but has turned itself off to save power?

As a general rule, I believe that in many cases, especially cases where an option is sometimes available, users are best served by a disabled option or even an enabled option that brings up an error message explaining WHY the option is not currently available.

Answer 3

I see two different approaches.

If the actions are disabled because of security I would actually try to remove them if at all possible. Easy with menu items or most toolbar buttons.

If the actions are disabled because you have a cheaper version of the software, I'd keep them present but disabled. This lets the user know "you could have this if you paid more" whereas if it were removed they would not know what they were missing. I view the "you can't do this because of license" popup to be bad UI since the user cannot tell if they can do an action without actually trying to do the action.

Answer 4

Another approach is to not show the action at all.

Stack Exchange is a good example of this. If I don't have "edit" rights to other people's posts I don't see an "edit" link at all. This means I don't try to click it and wonder why it doesn't work.

This might not work in all circumstances, but in your example the "admin" and "financial" options/links just wouldn't appear for limited users - even in the admin screens for those users. If the user was changed to a "Regular" or "Premium" user then those options/links would appear.

You might then consider displaying the type of user somewhere semi prominent so that the administrator can be reminded of why certain options/links aren't visible!

Answer 5

As other answers have stated, if the user doesn't have permission to perform an action within the system (as in, no edit/admin privileges), then the action shouldn't be displayed at all.

In cases where actions are disabled because of application state (can't edit a read-only file, can't copy/paste if no text is selected, user has a trial version of software that lacks a few features, etc) I personally think the action should be displayed, with a visual indication that the action can't currently be performed. Note that I don't say "disabled," because if the user tries that action, they should be able to find out why it is not doable. This way a user can see that the action is disabled, but they can also get a message explaining why.

I would be careful with the case where a user has a trial / under-licensed version of an app that lacks features. For instance, if you had an ISO reading/writing app that wouldn't rip CDs unless you paid for it, then you could show the "rip CD" option but not let the user perform it. But if your application has entire suites worth of features in the higher-end versions of them (visual studio for example) then displaying all of those things but not allowing them could get frustrating for the user. I don't want to open my IDE and see database, networking, integrated UML, testing, profiling, etc suites when I know that all I am licensed to do in it is write and build projects.

Answer 6

My rule of thumb is: If an action is not available to a user because of permissions, it is not visible. If an action is not available because of temporary context (this 'Save' button has no meaning until the user has entered something to save), then it is disabled.

"Permissions" covers both "admin user vs regular user" and "premium license vs cheapo license". Unusable UI elements are clutter - not the way to advertise your additional features.

Answer 7

Many answers seem to got this right, just wanted to sum it all up with one of Nielsen's heuristics, which points exactly at this. It states:

Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Source: http://www.useit.com/papers/heuristic/heuristic_list.html

Answer 8

I really like shemnon's answer. I would extend his second case and apply ign's referenced Nielsen commandment; if the user has a cheaper license, I would disable the option and replace the selection object with an icon that further makes plain the option's disabled state.

Something like

• O Option 1
• O Option 2
• Option 3
• O Option 4

As this suppositional product is still in development, I would also include at least a statement of the user's license level on the same page. That way, the admin sees that the user's license level at the same time that admin is looking at the system variables directly affected by that license.

A beauty of software is that all you have to do is call the information.

Edit: Additionally, I might employ a roles-centric permission scheme, where permissions can be assigned to roles and not individual users. This often mitigates a ton of overhead from needing to micromanage individual user permissions.

1. Admin opens role-editing screen.
2. Admin maybe selects a radio button for lowest license to which the role will be applied.
3. Permissions that aren't available to the selected role are disabled and "x"ed.
4. Admin selects permissions from remaining active options.
5. Later, in the user management screen or the user profile, admin sees list of roles that user can have based on license, and the admin selects one or many.

Answer 9

Some of the points above are great, and I don't want to re-iterate, but...

In this case, I would have all available options visible. The options that were not applicable in your rules, should be disabled (grayed out). It is common knowledge for a user of any interface to recognize that if something is grayed out, it typically means it's not applicable for some sort of rule set going on.

A tool tip coincides with a disabled button perfectly. In some special, more advanced cases such as yours above with licenses, if the user without the proper license was viewing an area that required a higher license, completely changing the art of the button to something like "Upgrade Now!" instead of graying it out would be better advertising for the product, and get the point across.

If the admin user was viewing it, they would obviously see that the financial option is grayed out, with a tool tip explaining why.

I do not fully know the context of your issue, there may not even be a product involved. But based on what I understood, that's my reaction to it.

Answer 10

In general, my rule of thumb goes like this (and I need to have a good reason for breaking it): If the reasoning behind the disabled component flows from the context or that understanding it should be easy for the user due to other reason, then blocking is the preferred solution. Else, user might be frustrated trying to figure out why it is like this, and worse, probably will not remember the reason for it (case he figured it out) next time he encounter it.

Answer 11

To answer your specific question, you want to display sufficient information so the users can understand the limitations before they click. In your example, you should list each user with their license as a read-only field visually connected (e.g., by proximity) with the controls to set their permissions. Or you could combine the license field dynamically with the label for the permissions (e.g., “Permissions (with Limited License):”).

Non-applicable permissions probably should be disabled, not enabled and not hidden. If it’s worth the clutter, include in-line text, hover text/ tooltips, or a link for explaining why the permissions not allowed by the license (in-line text may replaced the disabled controls if it lists the permissions; for example “Admin, Financial not allowed for Limited users”).

The general rule is use disabling if the user can do something in the UI to enable the command. Disabled means “you can do this command, but just not right now the way things are.” The “way things are” includes the current selection. Whenever you use disabling, there should be a clear indication so users understand why the associated commands are disabled for some objects.

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

Use hiding if the user never has the access to the command no matter what they do in the UI given their current position in the organization. For example, actions not authorized by the user given their permissions simply don’t appear. 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 rights for are not their job (otherwise they’d have access), 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 customer accounts for you” or “You need Financial permissions to edit accounts; see your administrator for the procedure to get approval to upgrade your permissions.”).

I’ve gory details at Controlling Your Controls.

Answer 12

Do Both: Backend and UI

This really shouldn't be an either or situation. The other answers list good reasons listed for showing unavailable options, and good reasons not to show them. But the thing is, either way, you need to handle it properly on the backend. You still need to properly check user inputs and permissions, even if you think that the only input they can give is a proper one.

This holds doubly true with any web-based application, where the user could artificially enable a disabled control/option/input. Don't let use of Firebug trump your app's ability to control what I can do. And in cases where they try to use an option that shouldn't be available, make sure you log the event.

Answer 13

The Windows UXGuide has quite a bit of resources that may help you decide on whether to show errors or prevent invalid input. Specifically there is a section that makes the below statement about ui.

Don't give error messages when users aren't likely to perform an action or change their behavior as the result of the message. If there is no action users can take, or if the problem isn't significant, suppress the error message.

Also this discussion reminds me a bit of what Karl Shifflett in his blog post titled "Fort Knox Business Objects ( yes / no )" where he weighs the pros and cons of whether to allow business objects to enter into an invalid state or not and how this decision effects user interaction.

Personally, I tend to prevent a user from making invalid entries or disabling controls that perform actions such as buttons most of the time but for some controls that involve complex text entry I tend to show inline warnings which are less obtrusive than message boxes but still get the point across.