An Inventory of UI Controls

Key ideas#

Buttons#

• A command button should act when the mouse button is released over it, not when it is pressed. This protects against accidental clicks.
• Label it with a verb that names the action, such as “Save” or “Delete”, not “OK”. The label also helps users pick up again after an interruption.
• Golovach considers an Apply button harmful: once it has been pressed, OK and Cancel no longer mean what they say. A preview, plus separate Close and Apply buttons, is clearer.
• A button that opens a menu works best split in two: the main area runs the most likely action, and the arrow opens the alternatives.

Checkboxes and radio buttons#

Both set options rather than run commands. Checkboxes are independent choices. Radio buttons choose exactly one of at least two options and always have a default. A pair of radio buttons can become one checkbox, unless the meaning of “off” would be unclear. Labels should be positive (no negations), similar in length, and should not repeat a shared word; move it to the group label instead. On the web, make the label clickable, not just the box. By Fitts’s law, a bigger target is faster to hit.

Lists and inputs#

• A drop-down list saves space but needs a click just to see the options. On the web, never navigate as soon as a value is selected. Require a button, or a slip of the mouse becomes an unintended jump.
• Scrolling lists should show at least four rows, preferably eight. For multiple selection, a set of checkboxes is clearer than a multi-select list.
• An input field should be no wider than the longest valid entry.
• Put labels above fields on frequently used screens, where they are easy to skip, and to the left on rarely used ones, where they are sure to be read.
• For numbers, Golovach recommends a spinner: users don’t have to move a hand to the keyboard, and only valid values can be entered. A slider suits ordered values, especially when there are many.

Menus#

Put the meaningful word first in each item. Show toggled options with a checkmark rather than by swapping the text (“Show grid” / “Hide grid”). An ellipsis signals that a dialog follows. Group items the way users think, not the way the code is organized; Golovach recommends card sorting with at least four or five target users. Deep menus risk cascading errors, where one wrong choice at the top makes every later choice wrong. Showing popular next-level items reduces that risk. Context menus are used mostly by experienced users, so keep them flat and put the most frequent items nearest the pointer.

Windows, tabs and wizards#

• Modal windows break context and the sense of control. Avoid them, except sometimes for data-entry forms.
• In the title bar, put the most important information first: the document name, not the program name.
• The status bar is underused. It is the right place for system state and progress.
• A window should scan as blocks and read like a sentence when spoken aloud. Important items go top left; closing buttons go bottom right, because choosing options comes before acting.
• Tabs hide content, and users distrust hidden content. With many sections, use tabs for the main ones and a list for the rest. Don’t pad tabs to make them equal.
• Wizards are justified when the sequence is naturally fixed, or the task is rare and complex. Allow free movement back and forward, show how much remains, keep the size and position constant, show the data entered so far, and title each step as an instruction.

Icons, color and sound#

Golovach calls icons overrated: context carries most of their meaning, and recognition without context is poor. Use standard images, minimal detail and one style, and give icons only to important items. Never use color as the only signal, because color perception varies. Sound is unreliable in offices.