About Face 2.0(c) The Essentials of Interaction Design

Display controls are used to display and manage the visual presentation of information on the screen. Typical examples include scrollbars and screen splitters. Controls that manage the way objects are displayed visually on the screen fall into this category, as do those that display static, read-only information. These include paginators, rulers, guidelines, grids, group boxes, and those 3D lines called dips and bumps. Rather than discuss all of these at length, we focus on a few of the more problematic controls.

Text controls

Probably the simplest display control is the text control, which displays a written message at some location on the screen. The management job that it performs is pretty prosaic, serving only to label other controls and to output data that cannot or should not be changed by the user.

The only significant problem with text controls is that they are often used where edit controls should be (and vice versa). Most information stored in a computer can be changed by the user. Why not allow the user to change it at the same point the software displays it? Why should the mechanism to input a value be different from the mechanism to output that value? In many cases, it makes no sense for the program to separate these related functions. In almost all cases where the program displays a value that could be changed, it should do so in an editable field so the user can click on it and change it directly. Special edit modes are almost always examples of excise.

For years, Adobe Photoshop insisted on opening a dialog box in order to create formatted text in an image. Thus, the user could not see exactly how the text was going to look in the image, forcing her to repeat the procedure again and again to get things right. Finally Adobe fixed the problem, letting users edit formatted text directly into an image layer, in full WYSIWYG fashion—as it should be.

Those darned scrollbars

Scrollbars are a frustrating control, fraught with difficulties, hard to manipulate and wasteful of pixels. The scrollbar is, without a doubt, both overused and under-examined. In its role as a window content and document navigator—a display control—its application is appropriate. In many cases, though, it is used inappropriately only because designers and programmers don't seem to have any better ideas. That's a poor rationale for any aspect of software design.

The singular advantage of the scrollbar—aside from its near-universal availability—is its proportional rendering of value. The scrollbar's thumb is the small, draggable box that indicates the current position, and, often, the scale of the "territory" that can be scrolled.

A scrollbar can be used to grossly represent ratio. For example, the user can see that a scrollbar whose thumb is about equidistant between its endpoints represents a quantity of roughly 50 percent. The fact that the scrollbar conveys no information about its terminal values detracts considerably from its usefulness as a sliding value selector; but nonetheless, the scrollbar's proportional rendering, flawed in implementation though it may be, is an excellent type of visual feedback.

Another shortcoming of the scrollbar is its parsimonious doling out of information to the user. It should instead generously inform us about the information it is managing. The best scrollbars today use thumbs that are proportionally sized to show the percentage of the document that is currently visible. But scrollbars could also tell us:

Additionally, the scrollbar is stingy with functions. It manages the bulk of our navigation within documents; it should give us powerful tools for going where we want to go quickly and easily. It could:

Recent versions of Microsoft Word make use of scrollbars that exhibit many of these features. The scrollbar also demands a high degree of precision with the mouse. Scrolling down or up in a document is generally much easier than scrolling down and up in document. You must position the mouse cursor with great care, taking your attention away from the data you are scrolling. Some scrollbars replicate both their up and down nudge arrows at each end of the scrollbar; for document viewers that will likely stretch across most of the screen, this can be helpful; for smaller windows, such replication of controls is probably overkill and simply adds to screen clutter.

One final annoyance about scrollbars: In maximized windows, the scrollbar is on the far right of the screen, so you'd expect that if you slammed the mouse to the right, clicked, and dragged, something would happen. But the right-most two pixels of the screen are not part of the scrollbar, even though they look like they are. This means that you must again exert fine motor control to ensure you haven't overshot to the edge of the screen before you start scrolling. If there's a reason why the active area of the scrollbar can't extend to the edge of the screen, the authors haven't been able to identify it.

Sliders and dials

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. The most important thing to remember about sliders is that they are bounded, non-proportional controls. 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.

Dials are an idiom borrowed directly from mechanical age metaphors of rotating knobs. They are very space efficient, but are extremely difficult to manipulate with a mouse because of the circular motion they imply. They are inadequate as bounded controls, and worse as unbounded controls. Even the best implementations of dials on screen are a chore for users, and this idiom should be avoided when possible.

Thumbwheels

The thumbwheel is a variant of the dial, but one that is much easier to use. On screen 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.

Splitters

Splitters are useful tools for dividing a sovereign application into multiple, related panes in which information can be viewed, manipulated, or transferred. Movable splitters should always advertise their pliancy with cursor hinting. Though it is easy and tempting to make all splitters movable, you should exercise care in choosing which ones to make movable. In general, a splitter shouldn't be able to be moved in such a way that makes the contents of a pane completely unusable. In cases where panes need to collapse, a drawer may be a better idiom.

Drawers and levers

Drawers are panes in a sovereign application that can be opened and closed with a single action. They can be used in conjunction with splitters if the amount that the drawer opens is user configurable. A drawer is usually opened by clicking on a control in the vicinity of the drawer. This control needs to be visible at all times and should either be a latching button/butcon or a lever, which behaves similarly, but typically swivels to indicate an open or closed state. Microsoft Internet Explorer makes use of latching butcons to control its History and other drawers, whereas IE on the Mac uses vertically oriented tabs that extend from the edge of the drawer to accomplish the same thing. The tabs are a bit awkward and end up covering browser real estate, but they do a better job of associating themselves with the drawer than do the butcons in their sister application on Windows.

Drawers are a great place to put controls and functions that are less frequently used, but when they are used, it is in conjunction with the main work area of the application. Drawers have the benefit of not covering up the main work area the way a dialog does. Property details, searchable lists of objects or components, and histories are perfect candidates for putting in drawers.

Although the big-picture principles discussed in Section Two can provide enormous leverage in creating products that will please and satisfy users, it's always important to remember that the devil is in the details. Frustrating controls can lead to a constant low-level annoyance, even if an overall product concept is excellent. Be sure to dot your i's and cross your t's, and ensure that your controls are well-behaved.

Related

Категории