unjokingly I think the fact that we removed grayed out buttons for "the button just doesn't appear" is one of the more confusing UI trends of our day and the sight of a grayed out button warms my heart
> Reconsider disabled controls. Disabled controls can be hard to use because users literally have to deduce why they are disabled. Disable a control when users expect it to apply and they can easily deduce why the control is disabled. Remove the control when there is no way for users to enable it or they don't expect it to apply, or leave it enabled, but provide an error message when it is used incorrectly.
> Tip: If you aren't sure whether you should disable a control or provide an error message, start by composing the error message that you might provide. If the error message contains helpful information that target users aren't likely to quickly deduce, leave the control enabled and provide the error. Otherwise, disable the control.
Unfortunately, that nuance has been lost in the modern version of the guidelines with no mention of disabled buttons at all [2]
> Remove the control when there is no way for users to enable it
That guidance is unhinged, and is exactly the anti-pattern that upthread points to that needs to die.
Removing the control is like gaslighting the user: they're looking for "how to do X?" and documentation, Internet searchable screenshots, and, god help us, now AI, are pointing them at a button that does not exist. I cannot tell you how many times I've frustratingly circled that mulberry bush as a user, for a wide range of products.
No, the button (and all other UI elements) should always present/be visible, and if there is a disabled control, there should be a HIG-standardized way to determine why it is disabled. (I.e., a mandatory tool-tip that states what actions would cause the control to enable, though I'd accept that tool-tips themselves are not always discoverable. You could have a small, standardized icon on the disabled control, like an :information-symbol-emoji: that might hit towards the tool-tip, or just put in underneath.)
I agree, just gray it out and have a little question mark button next to it.
Also, way more question mark buttons. I don’t care how well named people think things are. They’re not, and there’s always some hidden behavior you just have to know behind every setting. Include the question mark.
I think the button shouldn't appear if the user doesn't have the access to do it (eg. not an admin, has view rights only, etc).
However, if the user can and they expect to do it, but is in a mode/state which doesn't allow them to do it, greyed out buttons absolutely.
In some cases, greyed out buttons should be clickable (eg. forms) and that should tell the user what is wrong. Looking at you, billion dollar airline, where I couldn't complete my checkin due to this annoyance.
Also, what happened to hover messages and little (?) marks? Every software behaves like it expects me to know what to do from Day 1.
I agree for admin stuff, but certain lack of permissions hiding stuff is annoying. It's nice for things to be disabled and have a hover text explaining why it's disabled. Also, yes, (?) and hover text in general is severely underused in popular software.
I wish every button or menu option that has a shortcut would show me its shortcut on hover or in-place so I didn't have to find it in the manual or buried in the settings menu.
Worse is when the hotkey is underlined but doesn't actually work (multiple buttons with same hotkey, and instead of switching between them it just doesn't do anything. Admittedly this is rare). Or when the list is an MRU that can be navigated with the first letter of the item names, but some letters are reserved for static functions (looking at classic shell start menu: I can't start certain programs from the MRU or pinned list without the mouse because (A)pps Sh(u)tdown (S)ettings are reserved. Numeric helps with MRU, but can't be used in multiple places for the same reason)
> Also, what happened to hover messages and little (?) marks? Every software behaves like it expects me to know what to do from Day 1.
I truly hate fast-food kiosks for this reason: most expect me to be familiar with their offerings and the menu system of that kios. I relatively rarely visit such places and I was better off with a human asking me 1-3 short questions and paying. I'm not paid to know this shit, I'm the customer. Guess I'm just too old, younger people love this crap for some reason.
Younger people love not having to wait in line.
If I'm really hungry and I'm stopping at McDonald's because it's the only place close enough to the bus stop, then I want to order and pay, not wait for the person ahead of me.
If I only have one item at the market/drug store, I want to use a self-checkout machine, and I don't want to be waiting behind someone with a cart full of items who doesn't know they have to actually unload their cart for the cashier, or who decides to go back for "one more thing" that happens to be at the back of the store where they get caught up talking to someone they know.
> Reconsider disabled controls. Disabled controls can be hard to use because users literally have to deduce why they are disabled. Disable a control when users expect it to apply and they can easily deduce why the control is disabled. Remove the control when there is no way for users to enable it or they don't expect it to apply, or leave it enabled, but provide an error message when it is used incorrectly.
> Tip: If you aren't sure whether you should disable a control or provide an error message, start by composing the error message that you might provide. If the error message contains helpful information that target users aren't likely to quickly deduce, leave the control enabled and provide the error. Otherwise, disable the control.
Unfortunately, that nuance has been lost in the modern version of the guidelines with no mention of disabled buttons at all [2]
[1]: https://learn.microsoft.com/en-us/windows/win32/uxguide/top-...
[2]: https://learn.microsoft.com/en-us/windows/apps/develop/ui/co...