Articles Comments

GUI Journal » Controls, GUI Design, Mistakes » GUI Design: Check Box Checkup

GUI Design: Check Box Checkup

I am still amazed when I find current examples of standard GUI controls being used with non-standard functionality. The roles and purposes of check boxes and radio buttons, for example, have long been established. They should not be used interchangeably or have their functionality changed to match the other. Anything a designer or programmer might hope to gain by such a decision is far out-weighed by the confusion imposed on the user.

ECLIPSE® MISUSING CHECK BOXES

Figure 1 is a screen shot of the Eclipse® Preferences dialog showing the list of Installed JREs.

Figure 1. Eclipse® Preferences Dialog Displaying Installed JREs

 

Notice the check boxes along the left side of each item in the list. One could easily get the impression that these check boxes are for selecting items in the list. They are not. The check box actually indicates which of the items in the list is the one and only JRE currently in use. When an item is checked, any previously checked item automatically has its check mark removed. A checked item can be unchecked, but then the dialog shows an error, because one item is required to be checked. By definition, the standard control to be used in this case would be a radio button, because one and only one item in the list must be selected.

Notice that jre6 (the second item in the list shown in Figure 1) is highlighted. It’s a little difficult to detect because the focus is currently on the Remove button on the right side, not on the list. Figure 2 is a portion of a screen shot of the same dialog with no items in the list selected.

Figure 2. Eclipse Preferences Dialog with No Selections in the JRE List

 

Note that three of the buttons to the right of the list are now disabled. At least one item must be selected/highlighted for use with certain buttons, as follows:

  • Edit…  — One and only one selection.
  • Duplicate…  — One  or more selections.
  • Remove  — One or more selections, but at least one must not be selected.

 

Because the check boxes are unrelated to the checked item in the list, I have been confused by this display more than once when I needed to make a change. Part of the confusion comes from the fact that the check box column is not labeled as to its purpose and therefore is readily assumed to be for selecting items for actions to be performed. A column header stating In Use or similar would be very helpful for the column of check boxes (or preferably, radio buttons!).

It is interesting to note that since at least one check box must be selected—yet each check box can have its check removed as with a standard check box—extra functionality had to be added to handle a situation that would not have existed if the standard radio button had been used in the first place. Figure 3 is a portion of a screen shot of the same dialog with nothing checked.

Figure 3. Eclipse Preferences Dialog with No JRE Selected

 

Note that there are two changes that appeared when the check mark was removed:

  1. The OK button was disabled — because it’s not OK to have no JRE selected.
  2. The Installed JREs title was replaced with the error message Select a default JRE.

 

Removing a title is never a good idea. I realize the possibility that the point is trying to be emphasized that something needs to be done, but how about putting the error message next to the button that’s disabled because of the error? A user wanting to select OK will need to search the display in an effort to determine why the button is disabled. If the error message were directly to the left of the OK button, then the title could remain (always a good idea!) and the association between the error and the disabled button would be much more obvious.

All of these problems would have been avoided if the standard controls were used.

Figure 4 is a quick mock-up of a redesign with some features that I would recommend.

Figure 4. Proposed Redesign of Eclipse Preferences Dialog

 

The new features included in this redesign are as follows:

  1. A new In use column with radio buttons for showing and changing the current JRE.
  2. A column of check boxes for selecting individual items, with a check box in the column header for selecting all items in the list at once. The header check box can be used for the Duplicate option or for quickly selecting a long list and then removing the one item for the Remove option. (The option of clicking the rows should remain, but this new method for selecting items is much more obvious to the new user.)
  3. The names of the JREs are clickable for quick editing, instead of selecting the item and then clicking the Edit button.
(There are other changes I would also suggest, but  for now I’m restricting my comments to items related to the check boxes.)

 

MICROSOFT® WORD® MISUSING CHECK BOXES

 

It’s sad to say that even software applications from major vendors violate standards and misuse check boxes. Figure 5 is a screen shot of the Font dialog from Microsoft® Word® 2010.

Figure 5. Microsoft® Word® 2010 Font Dialog

Note the seven check boxes in the Effects section of the dialog. Multiple groups of these check boxes are mutually exclusive. Checking some of the check boxes will automatically remove the check mark from other check boxes, much like radio button controls. The mutually exclusive combinations are:

  •  Strikethrough and Double strikethrough.
  • Superscript and Subscript.
  • Small caps and All caps.

 

Those groupings make sense if one takes the time to consider them, but neither the controls used nor the layout make it obvious what will happen when the user attempts to have two in a group checked at the same time. Check boxes should not have been used in these cases. The dialog already contains examples of the correct controls to use. The Underline style: control is a select box that has “(none)” as the default option. This  same control should have been used for the StrikethroughSuperscript/Subscript, and Caps options. In the very least, the check boxes could have been grouped in the layout in such a way as to at least indicate some association between the associated options.

I generally like to look at the way history may have influenced design decisions, so I took a look back at MS Word 2002. Figure 6 is a portion of a screen shot of the Font dialog from that application.

Figure 6. Microsoft Word 2002 Font Dialog

All of the seven check boxes in the Effects section that are present in the 2010 version of this dialog also existed in 2002 and functioned in the same way as they do now. But notice that the older version of the dialog includes four more check boxes that are not only mutually exclusive, but interact in an even more complicated way.

In this version Shadow and Outline can both be checked at the same time, but neither can be checked when either Emboss or Engrave is checked. There is nothing intuitive about any of that. And the designers have made no effort to try to make the interaction of any of these check boxes clear to the user. The only way to learn the details is trial and error. There is not even a Help button. That’s not very kind. It’s also interesting that the choice was made to simply remove all of those options from the tab in Word 2010.

Another problem with this layout is the fact that so many check boxes really clutter things up. If similar (and mutually  exclusive) controls were grouped, at least the user would have an easier time finding what is needed. Radio buttons are a good choice when there is plenty of room on the display; however, select boxes which only display the current selection and not all of the other options make an otherwise busy display much cleaner and clearer for the user. The Font color: and Underline style: options, for example, would take up much more space if all of the available options for each were visible.

Figure 7. OpenOffice® Character Dialog, Font Effects Tab

I generally will also compare OpenOffice® Writer® with Word, because much of the functionality seems to simply mimic what Word does. This is one case where OpenOffice actually did a great job of implementing these features correctly rather than ignoring standards the way that Word does. Figure 7 is a portion of a screen shot of the Font Effects tab of the Character dialog from OpenOffice 3.4.1.

Notice the Relief control which includes the features Embossed and Engraved (similar to Word’s features), using the term “(Without) to turn them both off. It also includes a Strikethrough control with options of SingleDouble, and multiple others. Everything here follows standards and uses appropriate controls. The Font Effects tab of this dialog uses select boxes for all instances of this type of option, which is an excellent choice for reducing clutter and adding clarity. Radio buttons are an option, but would have been unmanageable in the given space. Figure 8 is a portion of a screen shot of the Position tab on the same OpenOffice dialog.

Figure 8. OpenOffice Character dialog, Position Tab

Notice here that the Superscript and Subscript options are grouped under the Position label with a third radio button for Normal. Radio buttons make sense here because of the available space. This is another example of appropriate use of controls by OpenOffice rather than misusing check boxes. Well done!

 

KEY DESIGN POINTS

  1. Don’t misuse or change the functionality of check boxes; follow the standards.
  2. Clearly label controls. (Unlike the check boxes in Figure 3.)
  3. Radio buttons and select boxes exist for a reason. Choose the correct control depending on space and layout.

Written by

Carl Andersen currently works for Micro Focus International as a Senior Development Manager. Carl has led teams at NetIQ, Novell, and WordPerfect and been the principal designer of multiple GUIs which have received analyst acclaim.

Filed under: Controls, GUI Design, Mistakes · Tags: , , , , ,

Leave a Reply

*


− 7 = one

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>