How Controls Work

This section explains some basic characteristics exhibited by all types of controls, lists the standard controls, and introduces the concept of custom controls. It is followed by sections that cover in detail the appearance and actions of standard controls.

Basic Control Functions

When a user acts on a control with the mouse or keyboard, two things happen:

• The control's appearance changes, to let the user know it is responding. Each type of control responds to specific mouse and keyboard actions and changes its appearance in specific ways. These reactions are part of its definition.
• The control sends some instructions to the application. The instructions associated with a control are designed and implemented by the application developer. They are part of an application's definition.

You can compare these two characteristics of graphical controls with control devices in the real world. A mass-produced switch, for example, can be installed on a variety of different machines. The manufacturer of the switch provides it with a user interface, which invites specific user actions, but product engineers give those user actions different meanings in different machines.

Standard Controls

As you develop an application, you design the actions that you want it to perform and identify the states that users will be able to set. Then you need to decide which control will best represent these actions to your users.

The App Kit supplies a number of standard controls, and each has an appearance and behavior option. For most actions or states you implement, you should be able to find a standard control that works well. The standard controls are covered in the following order:

• Buttons
• Text fields
• Sliders
• Color wells
• Scrollers
• Browsers and selection lists
• Menu commands (See Chapter 6, "Menus.")

If you cannot find the appearance and action you need in one of the standard controls, you can create a custom control.

Custom Controls

The App Kit makes it relatively easy to design your own controls, but you should follow these guidelines:

• A control must provide immediate feedback to let the user know that it is responding and initiating an action. Just as users can look at a dial on a stove to see whether it has been turned, a graphical control must change its appearance in response to user actions. Don't assume that users will notice a reaction elsewhere in the application as user feedback.
• A custom control should have a distinctive appearance and behavior. Do not design controls that look so much like standard controls that users will confuse them.
• The behavior of a control should be apparent from its appearance. Users who are familiar with OpenStep should be able to recognize new types of control objects and know, almost instinctively, how to operate them.

Buttons

Buttons are the most common controls. They are used in title bars (the miniaturize and close buttons), on attention panels (for Cancel and the other options that close the panel), and in most other situations that call for a control.

You can create buttons in a variety of different shapes and sizes. Figure 7-1 shows the standard types.

How Buttons Work

There are some differences in function among the buttons; this makes different buttons suitable for different situations. The most significant difference is between buttons that act and buttons that set a state:

• Action (or one-state) buttons tell the application to perform a task, such as scrolling a document forward or beginning a search.

Figure 7-1

• Two-state buttons set a state on or off. A typical example is the button that lets users indicate whether the text search should find only whole words. Standard two-state buttons include switches and radio buttons. This category also includes pop-up lists.

Another difference is the specific user action that will sends a button's instruction to the application:

• Most buttons respond to a complete click and send their instructions to the application when the user releases the mouse button (assuming the pointer is still over the button when the mouse button is released). If the user presses over the button but moves the pointer away before releasing the mouse button, the instruction will not be sent.
• Other buttons respond when pressed. They send their instructions to the application as soon as the user pushes the mouse button down. This type of button typically repeats its instruction at regular intervals if the user holds the mouse button down and keeps the pointer over the button. This user action (holding down the button on a scroller, for example) gives the

appearance of continuous action. Users who keep the mouse button down can drag away from the control button and then back again to stop and restart the action. They can also press, release, and press again to restart the action.

All types of buttons respond visibly as soon as the mouse button goes down, and they maintain this "responding" appearance until the mouse button is released or the pointer is moved away. Even when the mouse button is released, control buttons maintain a responding appearance until any action the user initiated is complete. (In most cases this effect is momentary, and the user generally sees the button changing as soon as the mouse button is released.)

Buttons That Open Lists

The Application Kit supports two kinds of button/list combinations: pop-up lists and pull-down lists. Pressing the button for either of these controls opens a list, which stays open as long as the mouse button stays down. Users can drag through the list and choose an item.

Pop-up lists and pull-down lists look similar, and users choose items with the same action. One is an action button, however, and the other is a multistate button. This means that you use them in different situations.

Pop-Up Lists A pop-up list functions like a set of radio buttons--it presents a set of values from which users can choose. (Compared to a set of radio buttons, the pop-up list saves screen space and prevents overcrowding in panels.) Each list is controlled by a button with a special symbol:

. When users press the button,

the list pops up. It stays open while the mouse button is down. See Figure 7-2.

When users open a pop-up list, the item that matches the button's label appears on top of the list. Users can drag through the list and release the mouse button on another item, which selects it. When a new item is selected, the button's label changes. The button displays the new selection, but no action is taken.

Pull-Down Lists A pull-down list looks like a pop-up list, but it initiates an action rather than setting a state. See Figure 7-3. The button that controls a pull-down list has a different symbol

.

Figure 7-3

Users can drag through a pull-down list and release the mouse button to select an item. When they do, the control initiates the selected action, and the list closes without changing the label. Notice that this behavior of pull-down lists is like the behavior of a menu.

Implementing Buttons

Before you implement any type of button, you must do three things:

• Design the button's action.
• Choose an image, a label, or both for the button.
• Decide how to manage the button's appearance when it is clicked.

Of course, before using a button you should be certain that it is the best control for the job. Reading "Choosing the Appropriate Control" later in this chapter, should help.

Designing the Button's Action

A one-state (action) button should always perform the same action. It may seem efficient to vary a button's action according to the application's state--to switch between Erase and Restore, for example--however, it is better to provide separate buttons for each action and disable those that become irrelevant. This lets your users click safely on the same location whenever they want to perform an action without considering which state the application is in. It is acceptable, however, to change buttons that initiate time-consuming actions into Stop buttons while the action is in progress. See "Implementing Stop Buttons" later in this chapter.

One-state buttons are generally labeled with a verb or verb phrase that describes the action (such as Find), but some have only a graphic image (such as the arrowhead in a scroll bar button). Guidelines for assigning labels are covered in "Choosing the Button's Image or Label" in the next subsection.

Two-state buttons should never perform actions. Keep in mind, however, that changing a state can change the display. An inspector panel for a graph document might, for example, have a set of radio buttons that represent options for the graph type (line, bar, and so on). When the user clicks on one of these, it resets the graph's type, and the graph is redrawn. However, it would not be acceptable for the radio button to create a second graph of the new type.

Ideally, the display should be updated whenever a user clicks on a two-state button. This is not practical, however, when updating would take a long time or would be difficult to reverse. Consider giving users control over the display in these situations. If redrawing a graph takes a long time, you could provide a Redraw Graph button. (Remember that the button's own appearance must change immediately.)

Buttons with more than two states are not recommended; it is very difficult to convey their significance to the user.

Choosing the Button's Image or Label

A button's label should indicate what will happen when it is pressed or clicked. Keep in mind that a label identifying the current state (such as AM or PM), will probably be misunderstood. Users are more likely to assume the label represents the state they will set by clicking. A button labeled On, for example, is more likely to be interpreted as "Press here to turn something on" than as "This is now on."

To avoid this, use images and highlighting to show the current state, and use the button's label to indicate what it does. Labels that display the current state, such as one that switches between AM and PM, should only be used when the information they refer to is clearly visible. AM/PM buttons will probably be understood if you put them next to a digital representation of the time, but not if they stand alone. These and other two-state buttons are shown in Figure 7-6.

• Buttons should clearly look like action buttons or two-state buttons. Two-state buttons that do not have two distinct states and action buttons that do not look like they performs actions will confuse your users.
• Button labels should be dimmed (using gray text) whenever their buttons have no effect. Dimmed buttons are completely disabled--pushing them should not highlight, push in, or transform their appearance in any way.
• Button labels should be capitalized like menu commands. The first and last words should begin with capital letters, and the words between should be capitalized as they are in titles.
• Buttons that always open panels (except warning panels) should have three dots (...) at the end of the label.
• Action buttons that can be chosen with the Return key should display the Return symbol in their labels (see the Create button in the left panel in Figure 7-4). Some user actions, such as activating another application and moving key window status away from the panel, will prevent Return from choosing the button. In these situations, remove the Return symbol to prevent user confusion (see the right panel in Figure 7-4).

---

Programmer's Note - App Kit panels automatically remove the Return symbol when the panel loses key window status. So will attention panels created with NSRunAlertPanel() and its related functions.

For other panels, you need to explicitly manage the Return symbol. Do it in your implementations of the windowDidResignKey: and windowDidBecomeKey: delegate methods of the NSWindow class.

---

Changing the Button's Appearance During a Click

A control button's appearance should be transformed when the mouse button goes down, to indicate that it is responding. (This transformation should also reflect what the button will do; buttons that set a state should reflect the new state as soon as the mouse button goes down. See Figure 7-6, in which the Bold button uses a check mark to represent its state, for an example of this.) There are three ways of doing this:

• You can highlight it.
• You can highlight it and change the shading so it appears to be pushed in.
• You can change the image it displays.

In most situations, you should respond to user actions by highlighting the button and pushing it in. When buttons are right next to each other (such as scroll buttons and graphical radio buttons) you should not push them in, because they have no space around their bezeled edges and look less three-dimensional than normal. (It is possible to have a button pushed in without highlighting it, but this is not recommended because it is difficult for users to see.)

---

Note - Highlighting can be done automatically by the Application Kit or by changing the image to a custom "highlighted" image.

---

Figure 7-5 shows the recommended transformations for action (one-state) buttons.

Figure 7-5

Figure 7-6 shows the recommended transformations for two-state buttons.

Figure 7-6

Implementing Pop-Up and Pull-Down Lists

You must provide the titles for pop-up lists. The normal way to do this is with a titled box around the pop-up list's button. Figure 7-7 shows a box titled "Units" providing the title for a pop-up list.

Figure 7-7

Pull-down lists do not need titled boxes because their labels do not change.

When you use a pop-up or pull-down list, make sure the list does not blend with nearby objects when it opens. An open list may also place items next to another object's label, leading users to interpret them together. Finally, an open list can obscure other objects that would help users decide what list item to select.

---

Programmer's Note - When an item in a pop-up or pull-down list opens an attention panel, default behavior for the list is staying open until the panel is closed. But the list is in a higher tier than the attention panel, and it will cover the panel. To avoid this, dismiss the list before opening the attention panel. Have the list item call the performSelector:object:afterDelay: method to schedule the execution of a method 1 millisecond in the future. This method should then open the attention panel.

---

Implementing Link Buttons

Link buttons are usually created by users rather than developers. Since they often appear in custom content areas which are usually unique to an application, link buttons need a little more support from the application than the other types of buttons. When you implement link buttons, make sure they have the following behavior:

• Clicking a link button highlights it (briefly) and opens the document that contains the information referred to in the link. An unmodified click should never select the link button.

  If the user presses the mouse button with the pointer over a link button and drags away without releasing the mouse button, the link button should lose its highlight. If the user keeps the mouse button down and drags back over the link button, the link button regain its highlight.

• Shift-clicking a link button selects it.

Implementing Stop Buttons

Users who initiate actions that might continue for some time can cancel those actions by holding down the Command key and pressing the period (.) key. (This is described in "Implementing Keyboard Alternatives" in Chapter 3).

You can make it more obvious to your users that they can interrupt the action if you give the button that controls the action a stop state. If you implement a stop state, use the transformations shown in Figure 7-8.

Figure 7-8

The button's action should be started when the user completes the first click (releases the mouse button). Similarly, the button's action should be terminated when the user finishes clicking the button in its stop state.

Text Fields

Text fields are controls that allow users to type a single line of data, such as a file name, a part number, or an address. See Figure 7-9. Users can select text and edit it. If the user types more text than will fit in the field, the entry automatically scrolls so that the insertion point stays visible. The data is processed only when the user presses Return or clicks on a button that is associated with the field.

A text field should have a white background and be surrounded by a bezeled border that makes it appear inset from the surface of the screen. When the text field is temporarily disabled, the text becomes gray (just like the label of a button), but the background color does not change.

A text field that is not usually edited or selected but can be (such as a name associated with a file icon in the File Viewer) should display text on a gray background and have a border with no bezel. When the user selects the text, the text field's background should turn white, and the selected text's background should turn light gray.

Text fields can be titled and arranged in groups to produce an on-screen form, such as the one illustrated in Figure 7-10.

When there is more than one text field in a window, the Tab key moves the selection--the point where typing will appear--from one field to another. Refer to Table 7-1.

Table 7-1

Character	Action
Tab	Moves from one text field to the next one in the series. In Figure 7-10, Tab moves the current selection from the Name field to the Street field to the City field, and so on.
Shift-Tab	Moves from one text field to the previous one in the series.

When the user presses Return after typing in a text field, the field usually initiates an action. Data might be entered and processed, a search might begin for text that matches the string in the field, or a document might be saved to a file name the user typed. Exactly what happens is in the application's definition.

You should include a button that has the same action as Return (and is marked with the Return symbol) on the window or panel. This button's label is an explicit statement of what Return will do. From the user's point of view, Return is simply a shortcut for the action of the button.

Figure 7-11 shows a button with the Return key's action. The user can start printing a document by clicking on the Print button or pressing Return while a text field is selected. When the user presses Return, the Print button is pushed in and highlighted, as if the user acted on it directly.

Figure 7-11

• If the action associated with Return is one that the user is likely to repeat with different values in the text field, you can have the Return action select the text in the current field, allowing the user to replace it and press Return again.
• When you combine text fields in a form, you might decide that Return should not perform an action that processes user input. Instead, it will simply do just what Tab does--move the selection to the next field. Users must act on a button or other control to enter the data they type into the form.

Text fields generally accept data without restrictions on type, but in some situations you need to control the data type of the input. Typical examples of restrictions you can place on input data include:

• Unsigned or signed integers
• Unsigned or signed floating-point numbers
• Dates

If a user types data that is not accepted, the contents of the text field should be selected and highlighted. The user can make any necessary corrections and try again.

Sliders

Sliders are controls that let users set a value on a scale (between some maximum and minimum). The scale can be continuous or incremental (divided into intervals). It consists of a vertical (Figure 7-12) or horizontal (Figure 7-13) bar and a knob that moves on the bar.

Figure 7-12

The position of the knob indicates the current value. Users can change the value by moving the knob, or by positioning the pointer somewhere over the bar and pressing the mouse button. The knob will jump to the pointer's location; releasing the mouse button will fix the knob in its new location, dragging will move it along the bar.

When the slider has an incremental scale, the knob jumps to the nearest incremental position when the user releases the mouse button. Users can press the Alt key and drag the knob to values between the normal scale.

Users should always be able to see some feedback when they manipulate the slider's knob--this is usually done in a text field or label next to the slider (as shown in Figure 7-13).

Figure 7-13

---

Programmer's Note - Your application should specify the increment amount to be used for Alt-dragging. Otherwise, Alt-dragging has the same effect as unmodified dragging.

---

Color Wells

Color wells are controls that let users manage the colors in their documents. See Figure 7-14. They give users access to all of OpenStep's color definition tools, but the sequence of user actions required to use them is more complex than the actions required for other controls. You typically implement color wells on Inspector panels, where they allow users to set the colors of document objects.

To work with a document object's colors, the user selects the object and opens its Inspector panel. The panel should have color wells, one for each part of the object with a color. In Figure 7-14, the Inspector has two color wells because the selected object has two colors: fill and line.

When the Inspector is first opened, the color wells should display the object's current colors. Users can change the colors in the wells and apply the new colors to the objects. These are separate actions, so users can perform some complex operations that copy colors from one object to another or create a new color and apply it to several objects. The basic user operations are:

• Setting the color in a color well.

  To do this, the user drags a color into it, from either the Colors panel or another color well. Users who want to define a color on the Colors panel can open it by clicking on the color well's border.

  If the user selects the color well's border, the color in the well will change when a new color is selected in the Colors panel (every time the user clicks on a color). This is a good way for users to preview colors, but users who don't understand the selection mechanism might find it confusing. The application should deselect the color well's border whenever the user is not actively selecting colors. For example, you should deselect all color wells when the panel thy appear on is miniaturized.

• Applying the color to a document object.

  When a object is selected, the color wells should change color to reflect the object's colors. For example, if a white box with a red border is selected, then the Fill well shown in the previous figure should contain white, and the Line well should contain red. When the user changes the color in a well, that change should be reflected in the selected object. For example, dragging a swatch of green from the Colors panel into the Line well should immediately make the outline of the selected box green.

  Whether or not a color well's border is selected should have no effect on whether the well affects the object that is currently selected

When deciding whether or not to user color wells, consider the following:

• They are powerful because they give access to whole color section mechanism, but indirect, so you should use them only when users need the full range of color choices.
• An alternative to using a color well, when the group of acceptable colors is small, is to use graphical radio buttons (as pictured in "Buttons" earlier in this chapter).
• Another alternative, when a wide range of colors is needed, is to use the Colors panel alone. The user can change an object's color by selecting it and then choosing the new color in the Colors panel.
• You could also use a custom control that is more appropriate in appearance and functionality than a color well.

The Colors panel is an Application Kit panel, covered in Chapter 5, "Panels." It opens when users selects a color well's border; they can also open it directly with the Colors command.

Scrollers

Scrollers are controls that allow users to work with documents larger than the display area, by moving the display area to different parts of the document. You will probably add scrollers to most viewing areas in your application.

Figure 7-15

Figure 7-15 shows the area on a window which is available for viewing documents, along with the document itself, which is much larger than the viewing area. Scrollers move the viewing area over the surface of the document.

How Scrollers Work

Figure 7-16 shows the three parts of a scroller: the bar, the knob, and the scroll buttons (which are optional). This scroller is vertical and scrolls the viewing area up and down. A horizontal scroller scrolls it from side to side.

Figure 7-16

If the viewing area has scrollers but the document fits in the viewing area, the knob and the scroll buttons are removed, leaving a scroller in the form of a plain gray strip. This residual scroller indicates that functional scrollers will appear whenever the document becomes larger than the viewing area or the viewing area is reduced in size.

The Bar and Knob

The relative dimensions of the bar and knob indicate how much of the document is visible in the viewing area. The length of the bar represents the entire document, and the knob represents the part of the document that is currently visible. When the user deletes material from the document, the knob grows because the visible area is a larger percentage of the whole document; when the user adds material, the knob shrinks because it represents a smaller percentage of the entire document. The knob never becomes smaller than a square.

The location of the knob indicates which piece of the document is currently displayed. If it is at the top of the bar, the top of the document is being displayed; if it is at the bottom, the bottom of the document is displayed. The knob in Figure 7-16 indicates that about one third of the document area, near its top, is displayed in the viewing area.

Users scroll the viewing area by moving the knob in the bar. The knob responds to four kinds of user action:

• Dragging it to a new location. The viewing area moves as the knob moves.
• Pressing the mouse button in the bar but not on the knob. The knob jumps to the pointer, and the viewing area moves accordingly. If the user keeps the mouse button down, the knob can be dragged to a new location. With this technique, users can jump to the general part of a document they want to view (by pressing in the bar) and then fine-tune the viewing area (by dragging the knob).
• Pressing or clicking on a scroll button. The knob (and the viewing area) will move in the direction indicated by the arrow on the scroll button.
• Selecting something in the document and then extending the selection past the edge of the viewing area. This automatically scrolls unseen portions of the selection into view.

Fine-Tuning Mode

If a document is large, even small movements of the knob will make large changes in the display area. This makes it difficult for users to adjust the display area accurately by dragging the knob.

To help with this, scrollers have a fine-tuning mode that is activated by holding down Alt and dragging the knob. This changes the responsiveness of the knob, so that it (and the display area) move only slightly when dragged by the mouse. The knob moves in the direction it is dragged, but does not move as far as the pointer does. It moves slowly, representing the motion of the display area.

Once the Alt key is released, any subsequent dragging action will cause the knob to jump to the position of the pointer.

Scroll Buttons

The scroll buttons permit more precise scrolling than direct manipulation of the knob. In a text document, clicking on the vertical scroll button scrolls the viewing area by one line of text. When pressed, it scrolls continuously in one-line increments. Horizontal scroll buttons work in a similar way, scrolling a small, fixed amount either left or right.

• If the user drags from one button on a scroller to the other, without releasing the mouse button, each button acts as it is pressed. (Users cannot drag a scroll button on one scroller to a scroll button on another scroller.)
• If the user holds down Alt and clicks on a scroll button, the viewing area moves by an amount based on its own dimensions. Alt-clicking on a vertical scroller moves the bottom line (or two) to the top of the display area or the top line (or two) to the bottom. This provides users with a bit of overlap, so they know that nothing was skipped.
• Sometimes scroll buttons are displayed without the rest of the scroller. Since there are no knob and bar to indicate when the viewing area has reached a vertical or horizontal limit, you should dim the arrow on the corresponding scroll button.

---

Note - Interface Builder makes it easy to put scrollers around a document display area. The App Kit handles all scrolling characteristics, including Alt-clicking and Alt-dragging. You may want to adjust the amount the viewing area moves for a single click (even for graphics, it should be the distance comparable to a single line of text) and optimize drawing performance so that scrolling is as fast as possible.

---

Automatic Scrolling

When the user begins a selection (usually of text) in the display area and then drags to extend the selection beyond it, the display area will scroll continuously to bring the moving edge of the selection into view. This continues until the user releases the mouse button and sets the final edge of the selection. The amount scrolled increases as the edge of the selection moves farther from the display area. The application brings the location under the mouse pointer into view.

As the document scrolls, the scroller knob is adjusted to reflect the current position of the display.

Implementing Scrollers

If a document is taller than the display area, it should have a vertical scroller. If it is wider than the display area, it should have a horizontal scroller.

---

Note - When users scroll, they move the display area over the surface of a document. They often perceive, however, that the document moves (not the display area). This means that the knob and the document appear to move in opposite directions. To avoid confusion, documentation for your application should explain scrolling in terms of adjusting the visible portion of the document, rather than adjusting the document to make it visible.

---

The scroll buttons for both vertical and horizontal scrollers should occupy the lower left corner of the display area, where the two scrollers meet. This makes it easy for users to move from one set to the other.

If you use controls that operate on the document view, such as the page-scroll buttons as shown in Figure 7-17, you can put them in the area normally occupied by the scrollers (beneath and to the left of the document). Other types of control should not be put in this area.

Controls that you can put in the scroller area include:

• An editable text field that displays the current page number can be located at the far right of the horizontal scroller (see Figure 7-17).
• A pop-up list that lets the user scale the display can be located in the horizontal scroller (see Figure 7-17).
• A pop-up list that controls the viewing mode (for example, preview versus drawing mode in a graphics application) can be located in the vertical scroller.
• Page-scroll buttons, which scroll from page to page or in increments matching the dimensions of the display area, can be grouped next to the scroll buttons. There is no current Application Kit support for page scroll buttons, and a precise arrangement is not specified. (See Figure 7-17 for typical page-scroll buttons.)

Browsers and Selection Lists

Browsers and selection lists are controls that display lists and let users select one or more items in the list. Browsers show several lists side-by-side, allowing users to work with data organized hierarchically, such as:

• Files and folders
• Cities, counties, and states
• Management structure of a company

Selection lists display data that exists on a single level. They usually have scrollers, but this is not required. See Figure 7-18.

Figure 7-18

"Selecting Objects With the Mouse" in Chapter 3 summarizes the mouse actions that select items in a browser or selection list. Browsers and selection lists can also include text fields, in which users can select by using the keyboard and typing in the name of an item. The browser on the Save panel includes a text field that allows users to select from files appearing in the browser by typing.

If double-clicking on items appearing in a browser or selection list does anything, it should perform the same action as pressing Return (that is, the same action as the button marked with the Return symbol).

Choosing the Appropriate Control

In some situations, it is clear which control will best represent an action or state to your users:

• Scrollers are used when documents are displayed in display areas that might be too small for a complete document.
• Sliders are used when your users need to set a value within a bounded range (of colors, numbers, or sound levels, for example).
• Text fields are used whenever it is impossible or impractical to provide a list of all possible values.
• Color wells are used only with the Colors panel, and only where complex color characteristics are needed.
• Browsers are used only for data that is organized hierarchically.

In other situations, the choice is less clear. You can use a button or a selection for most of them, but these controls have many variants, and you want to pick the one that "feels right." The rest of this section analyzes different kinds of actions and states that must be represented by controls and identifies the buttons or selection lists that will work best.

Controls That Represent Actions

Actions your users can start should usually be represented by menu commands or buttons.

• In some cases, an action can be represented by both a menu command and a button.

• Although text fields can initiate actions when users press Return, they do not identify the action nor provide feedback to the users. You should always supply a nearby button that represents the action, labels it and responds when Return is pressed.
• Some actions are unimportant or rarely used and you don't want to use screen space to represent them as individual buttons. In these situations, you can make them into items in pull-down lists. Another possibility is to implement them as menu commands.

The Figure 7-19 shows a single action, printing, implemented by a menu command, a button, and a pull-down list item. Any of these controls opens the print panel. Print is normally implemented as a menu command.

Figure 7-19

Controls That Represent Settable States

Settable states can be represented by two-state buttons, pop-up lists, and selection lists. Menu commands should never be used to show state. A settable state can be more or less independent of other settable states, and the degree of independence influences your choice of a control to represent it:

• In some situations a settable state is completely independent of any other state represented on the panel. (The display size of text in a document is an example.) These states can be represented by a single control.
• Some settable states (options) are related to other options on the panel, but there is no fixed relationship among them. Users can choose any combination of options.
• In other cases, there is a mutually exclusive relationship among a group of options. Users must choose one, and only one, of the related options.

---

Note - Selection lists allow a relationship in which either no choice or one choice can be selected.

---

Controls that represent a state should only be used to show and set state and not to initiate actions. There are two apparent exceptions to this rule:

• Double-clicking an item in a selection list can initiate an action, but the double-click is actually a shortcut for selecting the item and then clicking on a button.
• Setting a state can have visible consequences, such as changing the displayed format of a document to change, but this is actually feedback that the state has changed, and not an action.

Displaying a Single Option

When a single option is truly independent of the other options on a panel, a switch is the preferred control. You could also represent it as a graphical two-state button, as long as it is very clear that the button has two states. Refer to Figure 7-20.

Displaying a Group With an Unrestricted Relationship

When you want to represent a number of related options that work together to determine something but do not have a mutually exclusive relationship, use one of the controls illustrated in Figure 7-21:

• Group of switches
• Group of graphical two-state buttons (they should not look like graphical radio buttons)
• Selection list

Figure 7-21

Switches and graphical two-state buttons are preferred. Selection lists are less attractive and do not indicate how many selections can be made. (If you use two-state buttons, be careful that they do not look like radio buttons.) A selection list might be more appropriate when the list of choices can increase or decrease dynamically, or when space on the panel is restricted.

Displaying a Group With a Mutually Exclusive Relationship

Several kinds of controls can be used to represent options with a mutually exclusive relationship. These controls let the user choose one and only one option:

• Group of radio buttons (standard or graphical)
• Pop-up list
• Selection list

Figure 7-22 shows these controls as they would be used to set the background color of a text field. Because this use is inherently graphical and there are only a few valid choices, graphical radio buttons are the best choice, followed by standard radio buttons. A pop-up list is marginally acceptable for this use, and a selection list is the least appropriate choice.

Figure 7-22

The following considerations might help you decide which control to use:

• If the control will be used frequently, consider using radio buttons (standard or graphical), since they are easier to operate and more accessible to the user.
• If text does not adequately describe the choices, consider using a group of graphical radio buttons.
• If space is limited or the window or panel looks too complex, consider using a pop-up list.
• If the list of choices can increase or decrease, consider using a pop-up list or a selection list.
• If the list of choices can grow larger than the screen, use a selection list with a scroller.
• If the user needs to see more than one of the choices on screen to understand them, avoid using a pop-up list.
• If the control will usually appear at the edge of the screen, you might want to avoid a pop-up list.

---

Note - : A pop-up list usually pops up so that the current selection is under the pointer. If, however, the list is long and near the edge of the screen, it shifts so that the entire list can appear on screen, which may change the selection under the pointer. Users might unwittingly make a new selection while intending only to see what is in the list. When considering a pop-up list, think about whether it is important to avoid this result.

---

• If many ordinary text-based buttons are in the panel, a pop-up list might fit in better graphically.