Should unauthorized actions in the user interface be hidden, disabled or cause errors?

Question

It is a constant question for me that I have never been resolved, so I would like you to contribute. If I have actions that, as I know, the user will not be able to perform due to insufficient privileges or the state of the object, should the user interface elements for these actions be hidden from the user, be visible, but disabled or visible and lead to an error when trying ? What will be the rationale for your answer? If disabled, will you provide a reason why, and if so, how?

This is a web interface, so I already know that I need to check incoming messages / get permissions and handle errors there. I am primarily talking about how to handle the user interface.

This is similar to the Rules for disabling or hiding menu items , although I'm interested in all types of user interface elements, not just the menu.

Examples:

• I have a new page that allows the user to create a new event. Events can be main events or subventiles. To create a master event, the EditMasterEvent privilege is required, and to create a submenu, only the EditEvent privilege is required. I have a drop-down list that allows me to select an existing event as a parent (main event) or without a parent (this is the main event). If the option "Create a master event" is shown in the drop-down list or is skipped if the user has only the "Change Event" privileges.

• Removing events requires that you be an application administrator or have appropriate permission for the type of event. In the latter case, the event must be older than 5 years. Deleting an event leads to a serious cascade deletion of related data in the system and for legal reasons, this data must be stored for at least 5 years after the event. Since this operation is rare for the average user, a typical case is that the action is not available. Should it be displayed always or only when it is really possible?

Answer 1

Like almost all user interface questions, the answer is "it depends."

You need to weigh openness with user satisfaction, by the way. For example, allowing an invalid action gives you the opportunity to explain why something is invalid. This is especially useful if the answer to the question “why is it disabled” is not obvious. For an application in which most users are new, this is important.

On the other hand, it can be very difficult to see the control, click on it, only to receive a reward from the message "Sorry, you can not do it now." The application I inherited a couple of years ago was teeming with such things, and it made using the UI an exercise in frustration.

Completely hiding functionality is probably rarely a good idea. Imagine that you know some feature “was there a minute ago”, but now it has disappeared. Whether it's a menu item or a button on a toolbar, or something else that makes it hidden, it can be an upset exercise for the end user.

Try doing a little usability testing if you just ask the next person you see “hey, does it make sense to turn it off or show you an informative dialogue”. One other opinion is enough to make you look at a problem from a different direction.

On the bottom line: do what best serves the user. All scenarios you specify are valid in certain circumstances. As with all user interface issues, ask yourself (or, better, your users) what best suits their needs.

Answer 2

Hidden is the best approach for actions that are never available to the current user. It makes no sense to try to distract the mental effort from the user, figuring out why something is disabled, if there is no action that they can take to change it.

Disabled. This is the best approach to actions that are sometimes available, but not at the moment or in the current context. A disabled option should convey two things: firstly, the action is not available right now, and secondly, something that the user could do to make the action available (change some settings or permissions, select an item, enter the necessary data, etc.) d.). If you can specify what you need to do to enable the action in the tooltip, all the better. Enabling / disabling actions when a user enters data or changes the context provides excellent feedback on what the program requires.

Mistake to error is the worst choice. You should only resort to a bug report for operations that might work: you cannot say that it will fail, except when you try.

Answer 3

I will disable elements, not hide them. This way, the user knows that the option will usually be available, and I provide a tooltip to explain why this item is currently unavailable.

Answer 4

It depends. Do you want the user to know that an action is possible, just not for them? In this case, show them the button, but turn it off. For example, if the user does not have permission to delete, but other users, they need to know that the records can be deleted, so they may ask someone to do this for them if they need action.

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

Answer 5

Great question!

A few considerations:

If you place elements on the page but turn them off, there’s still a remote chance that the user will be able to disinfect the system and enable them using javascriptlet.

If you don't show them at all, the overall functionality may be a little confusing for the general user. "Shouldn't there be an edit button here?"

If you are going to display and disable or display and check items, I would definitely do the server side check. Do not leave validation in the hands of JavaScript; I think the reasons for this are obvious.

Answer 6

I tend to handle two different types of situations differently. This action is determined by the privilege and state of the object.

If a person does not have sufficient privileges to perform the action, I hide this option, they do not know that they can perform the action.

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

From your examples:

• I would not have a “Create Master Event” as an option. The user does not have sufficient rights to view it.

• I would click Delete for administrators. Then, depending on how you do the rest of the site (a lot of visible text, tooltips, help icon, etc.), I would like to follow this agreement to inform the user why the button is not currently being used. And, perhaps, put a timer on top, next to the button, or how much time has passed, or how much time until it is deleted.

Answer 7

Depending on the object, we will either hide them or disable them. If the user has access to a large function, but not to a small part inside it, then we will hide the smaller part. However, if the user has access to several great features, but not to others, we will leave them visible, but disable them as a marketing ploy to remind them that the features are available for purchase if they need to decide what they want them to be.

Answer 8

I also saw some programs that turned off the menu item and changed its text to "Login to do bl ..."

I like this because it does not leave me with "why doesn't it work?" and immediately tells me what to do to make it work. Not applicable in every case, but this is a good approach if you can implement it.

Answer 9

A general rule is to disable usage if the user can do something in the user interface to gain privilege. Disabled means that "you can execute this command, but only now not as it is." The "path of things" includes the current selection, so use on / off if the user has the EditEvent privilege for old objects, but not for new objects. There should be a clear indication of which objects are deleted, so users understand why related commands are disabled for some objects (for example, if users usually know that records should be kept for 5 years, a simple age field may be sufficient, possibly reinforced with graphic difference for records older than 5 years).

Use message blocks instead of disconnecting if there is no way to explain the reason for disconnecting the user for cleaning, if they have average domain knowledge. Tips for disabled controls, BTW, are a great idea, but may not be enough on their own.

Use hiding if the user never has privileges, regardless of what they do in the user interface, given their current position in the organization (for example, they are not the Application Administrator). This is a mess and frustration with the use of outages or messages for this occasion. As for users, actions for which they do not have privileges are not their task (otherwise they have privileges), so the corresponding controls simply do not have to exist in the user interface. Instructions on the documentation or procedures of the organization can inform users about how these actions are performed (for example, “Your supervisor is creating new events for you.”).

More information at http://www.zuschlogin.com/?p=40 .

Answer 10

I would say that it is disabled with a hang containing the reason.

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

Answer 11

I have a special hatred for apps that have disabled buttons. If you are an end user, you want to know why you cannot use this button. Having it greyed out doesn't tell you anything. How do you get to the state to turn it on? Hints are one of the solutions, but they are not the best, many users will struggle with hints (if you do not work with advanced users).

Answer 12

My personal feeling is that elements should always be present. If the user does not have enough rights to execute them, they should generate an error when clicked.

I know that translators really do not like to create two million different error messages with “permissions allowed”, so this is often not the case in localized applications, which tend to hide elements.

In practice, many people tend to hide their capabilities, even in non-localized applications.

Answer 13

Other people provided good answers with an informed suggestion to avoid hiding elements and instead turn them off and give some clues for reasons.

So, I would like to look at it from different points of view - but how to hide some elements of the user interface in cases where the user does not need to see them, regardless of whether or not he has rights to certain actions associated with the elements

For example, suppose users of a role are granted access to seller records in the system.

But then the business analyst says: “Listen, this form has a drop-down list of sellers, and we should not allow some specific roles to see it.”

The developer asks: "So, we just removed the permission of the" Sellers "from this role, right?" But the analyst replies: “No! This role should still be able to view sellers on the Sellers page. It's just this one form where we have to hide the list for some roles and show it to other roles.”

So, the developer adds a permission called the X seller’s drop-down list.

We have a problem. Access to the same data is controlled by two separate permissions. Now we need to figure out how to combine them. And what if there are several forms where the list of sellers should be hidden for some roles? How do we combine it with Read Seller List? For us developers, it’s somewhat clear that the “Read” permission should have a higher priority than “View”, so even if the user can “view” the list, he still should not see it (or see empty or disabled using a useful tip ) if he does not have permission to "Read". Developers and system analysts know this. But how does the system administrator know this? Should we teach him this? How can we guarantee that the administrator will not confuse all these "View" and "Read" for a single list of data?

As you can see, all this becomes messy for one reason - we mix data processing permissions with the user interface amenities in the list of role permissions.

I saw many projects where it becomes messy because server-side permissions are too closely related to the user interface, which poses problems and possible security holes (because you have several elements in the role resolution editor for the same actions on the same data).

Permissions relate to access and operations with some specific data. The user interface can react uniformly to permissions for the entire system (turning off prompts, hiding, etc.). We should never invent new permission entries for user interface purposes only.

Now the question remains - but how do we actually hide the user interface elements for some users of the system so as not to overload them with a huge number of elements that are always disabled? One solution might be a workspace. If we clearly know that users of a role will never need access to some specific data, we create a set of user interface controls, like permissions, but this time we do not call them permissions. And we can really truly imagine ourselves, even allowing users to customize their workspace and choose what they may or may not see. Of course, permissions will always have the highest priority, but this will only affect the data and state of the user interface elements, not visibility.

These are my two cents. Unfortunately, I myself did not work on such a system where the permissions and parameters of the user interface workspace are neatly separated, because I always start the project so late when the "damage has been done." But I hope that someday I will have a chance. I just hope to find a good example of how to do it right, but somehow Internet search does not give me anything useful. Does this mean that no one has come to the same conclusions as me? I do not believe that anyone in the world of enterprise design patterns should have noticed that this UI impedance impedance is a long time ago.