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 Rules about disabling or hiding menu items, though I am interested in all types of UI elements not just menus.
Examples:
-
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.
-
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?
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.