If you'll forgive a bit of shaking-fist-at-clouds...
> Role-aware UI
> One problem with many read-write (CRUD) user interfaces is that they are not aware of underlying access controls. For example, displaying the update/delete buttons is misleading if the user has actually no permissions to modify the resource. So Headlamp checks Kubernetes RBAC settings and displays only those controls whose actions can be performed. So, if the user does not have permission to edit a resource, the edit button will not be displayed.
> This results in a much better UX, because it is obvious to the operator what actions are available based on their permissions at the time.
I strongly disagree. It's quite the opposite, in fact. Hiding UI based on permissions creates an infuriating UX, because there's no way for the operator to tell what actions are possible-but-forbidden, and those they simply can't find in the interface.
Click Edit -> "Access denied" -> Ah, I need to ask my admin for additional permissions
No Edit button at all -> Where the f... -> Ah, this software sucks
Of course, this is not to say the the underlying idea is bad. By all means, check the user's permissions proactively and disable the buttons (with explanation of why the button is disabled). And this is very much a case-by-case thing: it would obviously be silly for Amazon product pages to show everyone a disabled edit button.
But please, if you're designing administrative software for power users, don't dumb it down.
YES YES YES! I say this all the time to frontend people and they brush it off as the rantings of a backend CLI user who should never design UIs.
I strongly recommend disabling buttons instead of hiding them. It makes it immediately clear that the action is normally possible but not available for some reason. Hiding buttons gaslights people.
> I say this all the time to frontend people and they brush it off as the rantings of a backend CLI user who should never design UIs.
The UX concepts of "Discoverability" and "Learnability" [1] pretty much directly contradict these frontend people. Hiding controls is literally the opposite thing of making them discoverable.
> I strongly recommend disabling buttons instead of hiding them. It makes it immediately clear that the action is normally possible but not available for some reason.
100% agreed. To go the extra mile, put a tooltip that appears on hover/click that actually states _why_ the button is disabled.
Seeing "You don't have permission to perform this action" lets me immediately go ask an admin (or if I have access, to go check permissions/configuration myself).
Not seeing the expected button makes me hunt around for several minutes thinking I must be doing something wrong, then get angry that the software is making me feel stupid, which in turn makes me hate the software.
I mostly agree with this (and I'm convinced you're right about the posted software FWIW), but there are obvious counter-examples. It'd be weird and silly if your comment here had a disabled "delete" button like my own, or if when I order an Uber I have a disabled "ban" button next to the driver.
Out of interest do you know of any good reading on exactly when disable vs hide is better from a UX perspective? An idea that comes to mind is to disable when it's something the user can fix (eg. by logging in or asking someone for more permission), but that falls down with HN where you'd show disabled "delete" buttons on everything to non logged in users because logging in might enable some of them.
It feels like there's some nuance there and it's not just common sense/obvious or the creator of this software wouldn't end up on the opposite side to you.
Just my opinion of course, but I think you're already on the right track. With something like HN where there may be buttons that only make sense for 2 users and there is basically nothing a "normal" person could ever do to make them enabled, hiding them is the appropriate thing to do. A less clear HN example is the down arrow. When I first came on I didn't realize anybody could downvote and was super confused when I would see people complaining about downvotes. It led me to believe that there must be a ton of moderators out there doing controversial things. Would have been totally cleared up with a disabled down button with a hover text saying, "You need 500 karma points to down vote."
The example of a user who isn't logged in however, I think that case is mostly fine to hide things, so long as it's clear that you can log in. It's quite intuitive to have things be read only or dashboard mode without authenticating.
But of course some of these rules go out the window depending on the audience.
So long story short, I agree with you completely, there's a lot of nuance.
Exactly we have non trivial trading application and disabled submit button can have a dozen different reasons, some of them temporary (as in lasting for seconds).
Google's cloud console does this and it drives me mad. People will be explaining where to go to do something, and I look around madly... only to find out that UI elements are hidden because I don't happen to have permissions.
Knowing what access you need versus what you have is important, but just hiding stuff is not the right solution. There should be some explanatory text like "you need role foo.bar.baz to run this command".
(To be fair to Google, they try to do things like showing what API call or gcloud command you would run to replicate the UI in your own program/script, which is very helpful of them. Every UI should do this. Some good ideas in there, some bad ideas in there.)
Make sure to make the disabled controls a subtly different colour of black so the user can't tell if it's disabled or not unless the buttons right next to a non-disabled one... /S
Atlassian does this as well, and it’s the dumbest thing, because you just go around thinking Bamboo has shit features (not to say it doesn’t).
Tools for creators should always tell you what’s possible. If you can’t do it, you may need to find someone who can. But going without or trying to write code to do it are the consequences of information hiding.
I could not agree more! And I think this comes about from the UX correctly identifying a critical frustration but them failing completely to address it in a good way.
The purpose is of cause to avoid a frustrated user who clicks delete on something that cannot be deleted. But when a user does that it’s because they want to delete it. So what the UI should do is: 1 gray out the button to clearly communicate “this is an option that you do not have” and on a mouse over communicate what privilidges you lack. Then on the disabled button put a drop down or something that provides a path for you to temporarily or permanently gain the needed privilidges.
The idea here is to make it clearly visible what is going on and provide a way to rectify it. Instead of silently hiding the options that are not currently possible.
I find this particularly exasperating, especially in so far as it lead to misleading documentation. “Click ‘Foo’ to load Foo management screen. Then....”
100% Agree. One cannot explore the interface, if nothing is shown because of role-awareness. In our startup, I've strongly advocated for showing almost all features all the time, with appropriate messages based on roles or other criteria (except for very sensitive things, of course)
Laravel Nova handles this particularly well, with separate "can see" and "can run" concerns. Nova is essential an admin panel for CRUD operations over your Laravel resources. Basically we use them this way:
"can see" = false: not a valid action (resource should not be created manually for example)
"can see" = true && "can run" = false: valid action in the system, user is not permitted to perform
"can see" = true && "can run" = true: valid action, user has access to perform
I wish someone at Atlasian would understand this. After N iterations of changing the Jira UI, only God knows if I don't have permissions or I can no longer find the action :(
> Role-aware UI
> One problem with many read-write (CRUD) user interfaces is that they are not aware of underlying access controls. For example, displaying the update/delete buttons is misleading if the user has actually no permissions to modify the resource. So Headlamp checks Kubernetes RBAC settings and displays only those controls whose actions can be performed. So, if the user does not have permission to edit a resource, the edit button will not be displayed.
> This results in a much better UX, because it is obvious to the operator what actions are available based on their permissions at the time.
I strongly disagree. It's quite the opposite, in fact. Hiding UI based on permissions creates an infuriating UX, because there's no way for the operator to tell what actions are possible-but-forbidden, and those they simply can't find in the interface.
Click Edit -> "Access denied" -> Ah, I need to ask my admin for additional permissions
No Edit button at all -> Where the f... -> Ah, this software sucks
Of course, this is not to say the the underlying idea is bad. By all means, check the user's permissions proactively and disable the buttons (with explanation of why the button is disabled). And this is very much a case-by-case thing: it would obviously be silly for Amazon product pages to show everyone a disabled edit button.
But please, if you're designing administrative software for power users, don't dumb it down.