Spinners
Spinner controls are a common form of numeric entry control that permit data entry using either the mouse or keyboard. Spinners contain a small edit field with two half-height buttons attached, as shown in Figure 21-16. Spinners blur the difference between bounded and unbounded controls.
Spinners blur the difference between bounded and unbounded controls. Using either of the two small arrow buttons enables a user to change the value in the edit window in small, discrete steps. These steps are bounded — the value won’t go above the upper limit set by the program or below the lower limit. If a user wants to make a large change in one action or to enter a specific number, he can do so by clicking in the edit window portion and directly entering keystrokes into it, just like entering text into any other edit field. Unfortunately, the edit window portion of this control is unbounded, leaving users free to enter values that are out of bounds or even unintelligible garbage. In the page setup dialog box in the figure, if a user enters an invalid value, the program behaves like most other rude programs, issuing an error message box explaining the upper and lower boundaries (sometimes) and requiring the user to click the OK button to continue.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 460
460
Part III: Designing Interaction Details
Figure 21-16 The Page Setup dialog from MS Word makes heavy use of the spinner control. On the left side of the dialog, you see a stack of seven of these controls. By clicking on either of the small, arrowed buttons, a user may increase or decrease the specific numeric value in small, discrete steps. If the user wants to make a large change in one action or to enter a precise setting, he can use the edit field portion for direct text entry. The arrow button portion of the control embodies bounding, whereas the edit field portion does not. Does that make this a bounded control?
Overall, the spinner is an excellent idiom and can be used in place of plain edit fields for most bounded entry. In Chapter 25, we will discuss ways to improve control error handling.
Dials and Sliders
Dials and sliders are idioms borrowed directly from Mechanical-Age metaphors of rotating knobs and sliding levers. Dials are very space efficient, and both can do a nice job of providing visual feedback about settings (see Figure 21-17).
27_084113 ch21.qxp 4/3/07 6:10 PM Page 461
Chapter 21: Controls
461
Figure 21-17 Native Instruments’ Reaktor, a modular software synthesizer, makes heavy use of dials and sliders. These are effective interface elements, not only because musicians and producers are familiar with them from hardware, but more importantly because they provide users with more visual and easy-to-comprehend feedback about parameter settings than a long list of numbers, which aren’t that exciting to look at while making music.
Improperly implemented, dials can be extremely difficult to manipulate. Sometimes programmers erroneously force users to trace a circular arc with their mouse, which can be quite challenging. Proper implementation of a dial should allow linear input in two dimensions: clicking on the dial and moving up or right should increase the value of the dial, and moving down or left should decrease the value.
Of course, this idiom must be learned by users (otherwise, they may be inclined to try to mouse in an arc), so dials are best suited for specialized applications where users become accustomed to the idiom. Sliders are often a better option, because they visually suggest the fact that movement is along just one axis. Because of their compact size and visual qualities (not to mention heritage), they are popular in audio software.
Although sliders and dials are primarily used as bounded entry controls, they are sometimes used and misused as controls for changing the display of data. For most purposes, scrollbars do a better job of moving data in a display because the scrollbars can easily indicate the magnitude of the scrolling data, which sliders can’t do as well. However, sliders are an excellent choice for zooming interactions, such as adjusting the scale of a map or the size of photo thumbnails.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 462
462
Part III: Designing Interaction Details
Thumbwheels
The thumbwheel is a variant of the dial, but one that is much easier to use.
Onscreen thumbwheels look rather like the scroll wheel on a mouse, and behave in much the same way. They are popular with some 3D applications because they are a compact, unbounded control, which is perfect for certain kinds of panning and zooming. Unlike a scrollbar, they need not provide any proportional feedback because the range of the control is infinite. It makes sense to map a control like this to unbounded movement in some direction (like zoom), or movement within data that loops back on itself.
Other bounded entry controls
Breaking free from the heritage of traditional GUI controls and the baggage of mechanical analogs, a new generation of more experimental user interfaces allows more visual and gestural idioms. These range from a simple two-dimensional box where a click at any point defines the values for two input mechanisms (the vertical and horizontal coordinates each drive the value of a parameter), to more complex direct manipulation interfaces (see Figure 21-18 for examples). These controls are typically bounded, as their implementation requires careful thought about the relationship between gesture and function. Such control surfaces often provide a mechanism for visual feedback. These controls are also most appropriate for situations where users are attempting to express themselves in regards to a number of variables, and are willing to spend some effort developing proficiency with a challenging idiom.
Figure 21-18 Ableton Live, a computer-based music production and performance tool, employs a variety of two-dimensional bounded input controls. These provide good visual feedback, allow users to adjust multiple parameters from a single control, and support more expressive gestural user interactions. Their bounded nature also provides users with context about how the current settings fit within the allowable ranges, and eliminates the chance that a user will make an invalid entry (because no musician wants to be stopped by an error dialog).
27_084113 ch21.qxp 4/3/07 6:10 PM Page 463
Chapter 21: Controls
463
Unbounded entry: Text edit controls
The primary unbounded entry control is the text edit control. This simple control allows users to key in any alphanumeric text value. Edit fields are often small areas where a word or two of data can be entered by a user, but they can also be fairly sophisticated text editors. Users can edit text within them using the standard tools of contiguous selection (as discussed in Chapter 19) with either the mouse or the keyboard.
Text edit controls are often used either as data-entry fields in database applications (including Web sites connected to databases), as option entry fields in dialog boxes, or as the entry field in a combo box. In all these roles, they are frequently called upon to do the work of a bounded entry control. However, if the desired values are finite, the text edit control should not be used. If the acceptable values are numeric, use a bounded numeric entry control such as a slider, instead. If the list of acceptable values is composed of text strings, a list control should be used so users are not forced to type.
Sometimes the set of acceptable values is finite but too big to be practical for a list control. For example, a program may require a string of any 30 alphabetic characters excluding spaces, tabs, and punctuation marks. In this case, a text edit control is probably unavoidable even though its use is bounded. If these are the only restrictions, however, the text edit control can be designed to reject nonalphabetic characters and similarly disallow more than 30 characters to be entered into the field. This, however, brings up interaction issues surrounding validation.
Validation
In cases where an unbounded text-entry field is provided, but the field may only accept entries of a certain form, it may be necessary to help users to construct a
“valid” entry. Typically, this is done by ev
aluating a user’s entry after she has finished entering it, and throwing up an error message if it is invalid. Obviously, this can be irritating for users, and ultimately undermine their effectiveness.
As we’ve been alluding to, the best solution to this problem is to use bounded controls to make invalid entries impossible. (A common example of this is providing a drop-down list of months, rather than requiring a user to properly spell “February.”) In other cases, this isn’t immediately practical (a serial number on a registration screen, for example). Programmers have dealt with this dilemma by creating validation controls, or a type of unbounded text-entry control with built-in validation and feedback. Many data-entry types are commonplace, including formats such as dates, phone numbers, zip codes, and Social Security numbers. Specialized text edit controls are commercially available; you can purchase variants of the text-entry
27_084113 ch21.qxp 4/3/07 6:10 PM Page 464
464
Part III: Designing Interaction Details
control that will only allow numbers or letters or phone numbers, or reject spaces and tabs, for example.
Although the validation control is a very widespread idiom, most such controls can be improved. The key to successfully designing a validation control is to give users generous feedback. An entry control that merely refuses to accept input is just plain rude and will guarantee an angry and resentful user.
One fundamental improvement is based on the design principle: Visually distinguish elements that behave differently (Chapter 14). Make validation controls visually distinct from nonvalidation controls, whether through the typeface used in the text edit field, the border color, or the background color for the field itself.
However, the primary way to improve validation controls is to provide rich feedback to users. Unfortunately, the text edit control, as we know it today, provides virtually no built-in support for feedback of any kind. Designers must specify such mechanisms in detail, and programmers will likely need to implement them as custom controls.
Active and Passive Validation
Some controls reject users’ keystrokes as they are entered. When a control actively rejects keystrokes during the entry process, this is an example of active validation.
A text-only entry control, for example, may accept only alphabetic characters and refuse to allow numbers to be entered. Some controls reject any keystrokes other than the numeric digits 0 through 9. Other controls reject spaces, tabs, dashes, and other punctuation in real time. Some variants can get pretty intelligent and reject some numbers based on live calculations, for example, unless they pass a checksum algorithm.
When an active validation control rejects a keystroke, it must make it clear to the user that it has done so. It should also alert the user as to why it made the rejection.
If an explanation is offered, users will be less inclined to assume the rejection is arbitrary (or the product of a defective keyboard). They will also be in a better position to give the application what it wants.
Sometimes the range of possible data is such that the program cannot validate it until the user has completed his entry (rather than at each individual keystroke).
The validation then takes place only when the control loses focus, that is, when a user is done with the field and moves on to the next one. The validation step must also take place if a user closes the dialog — or invokes another function if the
27_084113 ch21.qxp 4/3/07 6:10 PM Page 465
Chapter 21: Controls
465
control is not in a dialog box (for example, clicks “Place Order” on a Web page). If the control waits until a user finishes entering data before it edits the value, this is passive validation.
The control may wait until an address is fully entered, for instance, before it interrogates a database to see if it is recognizable as a valid address. Each character is valid by itself, yet the whole may not pass muster. The program could attempt to verify the address as each character is entered but could introduce some undesirable latency with the extra workload. Besides, while the program would know at any given instant whether the address was valid, the user could still move on while the name was in an invalid state.
A way to address this is by maintaining a countdown timer in parallel with the input and reset it on each keystroke. If the countdown timer ever hits zero, do your validation processing. The timer should be set to something around half a second.
The effect of this is that as long as a user is entering a keystroke faster than once every half a second, the system is extremely responsive. If the user pauses for more than half a second, the program reasonably assumes that he has paused to think (something that takes months in CPU terms) and goes ahead and performs its analysis of the input so far.
To provide rich visual feedback, the entry field could change colors to reflect its estimate of the validity of the entered data. The field could show in shades of pink until the program judged the data valid, when it would change to white or green.
Clue Boxes
Another good solution to the validation control problem is the clue box. This little pop-up window looks and behaves just like a ToolTip (but could be made distinguishable from a ToolTip by background color). Its function is to explain the range of acceptable data for a validation control, either active or passive. Whereas a ToolTip appears when the cursor sits for a moment on a control, a clue box would appear as soon as the control detects an invalid character (it might also display unilaterally just like a ToolTip if the cursor sits unmoving on the field for a second or so). If a user enters, for example, a non-numeric character in a numeric-only field, the program would put up a clue box near the point of the offending entry, yet without obscuring it. It would say, for example, 0–9. Short, terse, but very effective.
Yes, the user is rejected, but he is not also ignored. The clue box also works for passive validation, as shown in Figure 21-19.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 466
466
Part III: Designing Interaction Details
Figure 21-19 The ToolTip idiom is so effective that it could easily be extended to other uses. Instead of yellow ToolTips offering fly-over labels for butcons, we could have pink ones offering fly-over hints for unbounded edit fields. These clue boxes could also help eliminate error message boxes. In this example, if a user enters a value lower than allowable, the program could replace the entered value with the lowest allowable value and display the cluebox that modelessly explains the reason for the substitution. The user can enter a new value or accept the minimum without being stopped by an error dialog.
Handling out of bounds data
Typically, an edit field is used to enter a numeric value needed by the program, such as the point size of a font. A user can enter anything he wants, from 5 to 500, and the field will accept it and return the value to the owning program. If a user enters garbage, the control must make some kind of decision. In Microsoft Word, for example, if you enter asdf as a font point size, the program issues an error message box informing you: This is not a valid number. It then reverts the size to its previous value. The error dialog is rather silly, but the summary rejection of my meaningless input is perfectly appropriate. But what if you had keyed in the value nine?
The program rejects it with the same curt error message box. If instead the control were programmed to think of itself as a numeric entry control, it could perhaps behave better. It doesn’t bother me if the program converts the nine into a 9, but it certainly is incorrect when it says that nine is not a valid number. Without a doubt, it is valid, and the program has put its foot in its mouth.
Units and measurements
It’s nice when a text edit control is smart enough to recognize appropriate units. For example, if a program is requesting a measurement, and a user enters “5i” or “5in”
or “5 inches,” the control should not only report the result as five, but it should report inches as well. If a user enters “5mm,” the control
should report it as five millimeters. SketchUp, an elegant architectural sketching application, supports this type of feedback. Similarly, well-designed financial analytics applications should know that “5mm” means five million.
Say that the field is requesting a column width. A user can enter either a number or a number and an indicator of the measurement system as described above. Users could also be allowed to enter the word “default” and the program would set the column width to the default value for the program. A user could alternately enter
27_084113 ch21.qxp 4/3/07 6:10 PM Page 467
Chapter 21: Controls
467
“best fit” and the program would measure all the entries in the column and choose the most appropriate width for the circumstances. There is a problem with this scenario, however, because the words default and best fit must be in the user’s head rather than in the program somewhere. This is easy to solve, though. All we need to do is provide the same functionality through a combo box. The user can drop down the box and find a few standard widths and the words default and best fit. Microsoft uses this idea in Word, as shown in Figure 21-20.
Figure 21–20 The drop-down combo box makes an excellent tool for bounded entry fields because it can accommodate entry values other than numbers. The user doesn’t have to remember or type words like Page Width or Whole Page because they are there to be chosen from the drop-down list. The program interprets the words as the appropriate number, and everyone is satisfied.
The user can pull down the combo box, see items like Page Width or Whole Page, and choose the appropriate one. With this idiom, the information has migrated from the user’s head into the program where it is visible and choosable.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 62
