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]
[1]: https://learn.microsoft.com/en-us/windows/win32/uxguide/top-...
[2]: https://learn.microsoft.com/en-us/windows/apps/develop/ui/co...
> 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.)
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.
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 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.
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.