Today as I was configuring some build settings in Qt Creator, an otherwise really great product, I was faced with this extremely frustrating situation:
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:
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.
I’m reading some more juicy bits from the Microsoft Windows Official Guidelines for User Interface Developers and Designers. This section details the specific layout of controls in windows and dialog boxes. At least now the dialogs I design are more or less consistent with some standard. :)
So, here we have the Aqua Human Interface Guidelines (i.e. the MacOS-X user interface guidelines), the GNOME Human Interface Guidelines, the KDE User Interface Guidelines and of course the Microsoft Windows Official Guidelines for User Interface Developers and Designers (I came back in January of 2018 to fix this link — also interesting is the section on margins and spacing).
Apple says that “The default button for dismissing a dialog should go in the lower-right corner. If there’s a Cancel button, it should be to the left of the default button.”. Gnome seems to imply that the default button should be on the bottom right, with other buttons to its left, which is more or less consistent with the Apple guidelines.
Microsoft says: “Lay out the major command buttons either stacked along the upper right border of the dialog box or lined up across the bottom of the dialog box. Position the most important button — typically the default command — as the first button in the set.” The KDE User Interface Guidelines don’t seem to set specific constraints on this kind of button placement, but judging by many of the standard KDE 3.1 applications, the dialogs seem to follow the Windows convention.
Continue reading “Where should that dang button go?”