5 ms·

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 u

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.

ex3ndr 6y ago
Came to the comments to note this, very bad for UX, but at least you can grey them out, not hide.
- derision 6y ago
  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
jeppesen-io 6y ago
Can't agree. Jenkins does this, hides elements you can't use This has reduced the amount of confusion for new users. Less overwhelming If you need permissions, it should be known ahead of time
- dkdk8283 6y ago
  Feature flag for advanced users?
- JackFr 6y ago
  Disagree strongly. In general Jenkins UI is abysmal. I want to love Jenkins. I’ve been using it on and off since the Hudson days, but it’s UI is horrendous. I almost feel bad saying something so mean, but the Jenkins UI Is so bad it looks like something I would come up with.
  - oblio 6y ago
    It's old and created as internal software. And then it kept backwards compatibility with the plugins, so it was frozen in time circa 2005 :-)
- theamk 6y ago
  Just the opposite, our new users are often confused by this, especially given Jenkins’ habit of short auto-logout timeout. “Where is the ‘start job’ link” —> “did you log in?”
jrockway 6y ago
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.)
freedomben 6y ago
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.
- gregmac 6y ago
  > 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. [1] https://www.interaction-design.org/literature/article/make-it-easy-on-the-user-designing-for-discoverability-within-mobile-apps https://www.interaction-design.org/literature/article/make-i...
  - mirekrusin 6y ago
    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).
  - mcintyre1994 6y ago
    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.
toadi 6y ago
Totally agree. Have this issue in most issues. Even Jira does this.
JackFr 6y ago
I find this particularly exasperating, especially in so far as it lead to misleading documentation. “Click ‘Foo’ to load Foo management screen. Then....” How do I click Foo!?!? There is no Foo!!!
hinkley 6y ago
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.
andyroid 6y ago
Additionally, this breaks completely if another authorizer than RBAC is involved.
boublepop 6y ago
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.
virgilp 6y ago
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 :(
- xorcist 6y ago
  Pressing dot (.) can help. It's like tab completion, but in their web apps.
neeleshs 6y ago
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)
aequitas 6y ago
> Click Edit -> "Access denied" -> Ah, I need to ask my admin for additional permissions Please don't let me click twice just to tell me I can't do something (once to try the action, second to dismiss the error). Instead make the action control disabled (not hidden), with possibly a tooltip to explain why you can't do it.
- londons_explore 6y ago
  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

ex3ndr 6y ago

Came to the comments to note this, very bad for UX, but at least you can grey them out, not hide.

derision 6y ago
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

jeppesen-io 6y ago

Can't agree. Jenkins does this, hides elements you can't use This has reduced the amount of confusion for new users. Less overwhelming If you need permissions, it should be known ahead of time

dkdk8283 6y ago
Feature flag for advanced users?
JackFr 6y ago
Disagree strongly. In general Jenkins UI is abysmal. I want to love Jenkins. I’ve been using it on and off since the Hudson days, but it’s UI is horrendous. I almost feel bad saying something so mean, but the Jenkins UI Is so bad it looks like something I would come up with.
- oblio 6y ago
  It's old and created as internal software. And then it kept backwards compatibility with the plugins, so it was frozen in time circa 2005 :-)
theamk 6y ago
Just the opposite, our new users are often confused by this, especially given Jenkins’ habit of short auto-logout timeout. “Where is the ‘start job’ link” —> “did you log in?”

jrockway 6y ago

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.)

freedomben 6y ago

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.

gregmac 6y ago
> 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. [1] https://www.interaction-design.org/literature/article/make-it-easy-on-the-user-designing-for-discoverability-within-mobile-apps https://www.interaction-design.org/literature/article/make-i...
- mirekrusin 6y ago
  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).
- mcintyre1994 6y ago
  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.

toadi 6y ago

Totally agree. Have this issue in most issues. Even Jira does this.

JackFr 6y ago

I find this particularly exasperating, especially in so far as it lead to misleading documentation. “Click ‘Foo’ to load Foo management screen. Then....” How do I click Foo!?!? There is no Foo!!!

hinkley 6y ago

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.

andyroid 6y ago

Additionally, this breaks completely if another authorizer than RBAC is involved.

boublepop 6y ago

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.

virgilp 6y ago

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 :(

xorcist 6y ago
Pressing dot (.) can help. It's like tab completion, but in their web apps.

neeleshs 6y ago

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)

aequitas 6y ago

> Click Edit -> "Access denied" -> Ah, I need to ask my admin for additional permissions Please don't let me click twice just to tell me I can't do something (once to try the action, second to dismiss the error). Instead make the action control disabled (not hidden), with possibly a tooltip to explain why you can't do it.

londons_explore 6y ago
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