| ▲ | cube00 7 hours ago | ||||||||||||||||
Microsoft had some excellent guidance[1] on this: > 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... | |||||||||||||||||
| ▲ | inigyou 2 hours ago | parent | next [-] | ||||||||||||||||
Not just this one. It seems like all usability guidelines have been forgotten. The guidelines that remain are not for usability. | |||||||||||||||||
| ▲ | deathanatos 4 hours ago | parent | prev [-] | ||||||||||||||||
Excellent? No, > 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.) | |||||||||||||||||
| |||||||||||||||||