User interface boo-boo #1: Disabled controls without explanations!

Today as I was configuring some build settings in Qt Creator, an otherwise really great product, I was faced with this extremely frustrating situation:

Screen Shot 2016-01-06 at 4.27.00 PM

I absolutely, definitely needed to configure the debugger. However, the controls required to do so were disabled, as can be seen by their greyed out visual state. Although it was easy to find the controls for configuring the debugger (good discoverability), it was impossible to find out exactly why the software would not allow me to do so.

What made this even more frustrating, is that it would have been straight-forward for the software to have shown me an informative tooltip or dialog box when I hovered over or clicked on the disabled controls. This message could have explained shortly why the control was disabled, and what exactly I needed to do to resolve the problem.

If you have or you were planning to use disabled controls in your next project without an easily discoverable (read: right on the disabled control itself) explanation of the reason (and fix) for having disabled them, I would like to say this:

JUST... JUST STOP.

I’ve singled out Qt Creator due to my experience today, but there are too many examples of this in modern user interfaces. Hooking up discoverable explanations to disabled controls is a small effort on the part of the programmer which multiplies to a significant time-saving and thus value-add for your users.

4 thoughts on “User interface boo-boo #1: Disabled controls without explanations!”

  1. OMG! I would shout this from a megaphone if developers would listen. I worked in an organisation that would often have log messages such as “In Fetch” as in, being in the fetch method, which only means something to the developer. I created many telephony integrations for said company and never did I get a ticket asking me what the problem was. Reason: my code always had very verbose logging, particularly when logging was set to verbose or debug, AND always suggested at least one reason why the error occurred and what to look for to fix it.
    If they were not in a different country, every time I found “unknown error” I’d want to wring their scrawny little necks!
    Okay yes, this is something I’m passionate about.

    Not quite the same as UI interaction as in your example, but the principle is the same. I think far to many developers rely on stack traces to provide information to support engineers rather than coding some helpful and easily understandable information.

    1. You are very right, thank you! The disabled UI control without explanation is just one example of the more general issue that you talk about. Software should have 100% discoverable (i.e. in your face when event X happens) information to help users to deal with various events!

Leave a Reply

Your email address will not be published. Required fields are marked *