Headlamp: a new UI for Kubernetes
kinvolk.io
kinvolk.io
> 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.
"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
This has reduced the amount of confusion for new users. Less overwhelming
If you need permissions, it should be known ahead of time
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.
“Where is the ‘start job’ link” —> “did you log in?”
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.)
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.
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-i...
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.
How do I click Foo!?!? There is no Foo!!!
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.
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.
It's like tab completion, but in their web apps.
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.
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.
Headlamp looks remarkably similar.
Second that! Lens is awesome. Use it pretty much every day.
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?
I actually didn't realize there was already quite a few options: https://medium.com/dictcp/kubernetes-gui-clients-in-2020-kub... (+ infra.app)
I do use k9s (https://github.com/derailed/k9s), however it still lacks lot of functionality.
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.
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.
Does this thing scale well?
I’ll have to give this a try!