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 :(
I’m very new to k8s, so forgive me if this is a silly question, but how is this different than Lens [0]?
One of the first tools I was told to download by a k8s expert friend of mine was Lens, and it has made the experience of learning about clusters, nodes, and pods much easier.
> One of the first tools I was told to download by a k8s expert friend of mine was Lens, and it has made the experience of learning about clusters, nodes, and pods much easier.
Second that! Lens is awesome. Use it pretty much every day.
> 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.
This results in much worse UX, as the user is oblivious to what actions are unavailable due to their permissions!
Back a little over 20 years ago, we would just grey out the button, to indicate that it was "disabled". (I'd also add that I think hovering over such UI ought to offer an explanation as to why that particular action is unavailable, and possibly, what steps to take to effect it.)
And it can be downright confusing if someone is giving instructions: are you misinterpreting their instructions, are their instruction wrong, or is it that the software is hiding the UI from you?
The BEST UI for K8S is.... VSCode's K8s plugin. Use it all the time, and it has all the things you want instantly: terminal into container, port forward something, view logs. Beyond that, I guess there might be a different crowd that is more interested in CPU usage and RAM usage.
Are there any powerful tools like these from command line(shell)? I prefer to use GUI to quickly navigate or do some advanced ops over remembering multiple commands.
The more the merrier, I guess. I've always been comfortable using kubectl. The only UI I am forced to use is the Google Cloud Console one. Which is ok. For newcomers I would recommend using the cli tooling and dive as deep as you can before you zoom back out. If you run k8s, then you are probably big enough a company that you have prometheus or something like that which collects metrics for cpu/ram usage.
From a Developers POV it's definitely easier to interact with a GUI.. and I '+1' on what u/rhacker said: the best UI in that case is probably the VSCode plugin.
Very good advice, I second this. For developers I also usually recommend VSCode plugin or Lens for those who can't stand VSCode for any reason. It seems to be a common choice.
If you are into that kind of thing I can also recommend Infra App (Mac, Windows, Linux): https://infra.app
I'm using it from time to time to quickly log at logs or other things which is sometimes easier than the CLI. I think that design-wise it's the best looking one of the Kubernetes GUIs that I tested. Not affiliated, just a happy user.
How is the performance with larger clusters? We have clusters with 20,000 to 40,000 containers. We have had to use things like Thanos and InfluxDB to get prometheus/grafana to work ok.
That OpenShift UI is IMHO one of the best things about it. If you don't work at a place with OpenShift anymore you should check out OKD. It's pretty usable now.
> 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.