Hacker News Reader

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.

[1] https://www.interaction-design.org/literature/article/make-i...

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

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.

I very much agree, there is nuance to it.

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.

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

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

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

How do I click Foo!?!? There is no Foo!!!

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)

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

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

Pressing dot (.) can help.

It's like tab completion, but in their web apps.

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

Feature flag for advanced users?

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.

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

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?”

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

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