Shadows work pretty well, but all those grids and shadows can get in the way visually. An alternative is the use of a single floor grid and a pole. Poles work in conjunction with a horizontally oriented grid. When a user selects an object, a vertical line extends from the center of the object to the grid. As she moves the object, the pole moves with it, but the pole remains vertical. The user can see where in 3D
space she is moving the object by watching where the base of the pole moves on the surface of the grid (x- and y-axes), and also by watching the length and orientation of the pole in relation to the grid (z-axis).
Guidelines and other rich visual hints
The idioms described in the previous section are all examples of rich visual modeless feedback, which we will discuss in detail in Chapter 25. However, for some applications, lots of grids and poles may be overkill. For example, Google’s SketchUp is an architectural sketching program where users can lay down their own drafting lines using tape measure and protractor tools and, as they draw out their sketches, get color-coded hinting that keeps them oriented to the right axes. Users can also turn on a blue-gradient sky and a ground color to help keep them oriented. Because the application is focused on architectural sketching, not general-purpose 3D modeling or animation, the designers were able to pull off a spare, powerful, and simple interface that is easy to both learn and use (see Figure 19-13).
25_084113 ch19.qxp 4/3/07 6:09 PM Page 418
418
Part III: Designing Interaction Details
Figure 19-13 Google’s SketchUp is a gem of an application that combines powerful 3D architectural sketching capability with smooth interaction, rich feedback, and a manageable set of design tools. Users can set sky color and real-world shadows according to location, orientation, and time of day and year.
These not only help in presentation but also help orient users. Users also can lay down 3D grid and measurement guides just as in a 2D sketching application.
Camera rotate and zoom functions are cleverly mapped to the mouse scroll wheel, allowing fluid access while using other tools. ToolTips provide textual hints that assist in drawing lines and aligning objects.
Wire frames and bounding boxes
Wire frames and bounding boxes solve problems of object visibility. In the days of slower processors, all objects needed to be represented as wire frames because computers weren’t fast enough to render solid surfaces in real time. It is fairly common these days for modeling applications to render a rough surface for selected objects, while leaving unselected objects as wire frames. Transparency would also work, but is still very computing-intensive. In highly complex scenes, it is sometimes necessary or desirable, but not ideal, to render only the bounding boxes of unselected objects.
25_084113 ch19.qxp 4/3/07 6:09 PM Page 419
Chapter 19: Pointing, Selecting, and Direct Manipulation
419
Input issues and idioms
3D applications make use of many idioms such as drag handles and vertex handles that have been adapted from 2D to 3D. However, there are some special issues surrounding 3D input.
Drag thresholds
One of the fundamental problems with direct manipulation in a 2D projection of a 3D scene is the problem of translating 2D motions of the cursor in the plane of the screen into a more meaningful movement in the virtual 3D space.
In a 3D projection, a different kind of drag threshold is required to differentiate between movement in three, not just two, axes. Typically, up and down mouse movements translate into movement along one axis, whereas 45-degree-angle drags are used for each of the other two axes. SketchUp provides color-coded hinting in the form of dotted lines when the user drags parallel to a particular axis, and it also hints with ToolTips. In a 3D environment, rich feedback in the form of cursor and other types of hinting becomes a necessity.
The picking problem
The other significant problem in 3D manipulation is known as the picking problem. Because objects need to be in wire frame or otherwise transparent when assembling scenes, it becomes difficult to know which of many overlapping items a user wants to select when she mouses over it. Locate highlighting can help but is insufficient because the object may be completely occluded by others. Group selection is even trickier.
Many 3D applications resort to less direct techniques, such as an object list or object hierarchy that users can select from outside of the 3D view. Although this kind of interaction has its uses, there are more direct approaches.
For example, hovering over a part of a scene could open a ToolTip-like menu that lets users select one or more overlapping objects (this menu wouldn’t be necessary in the simple case of one unambiguous object). If individual facets, vertices, or edges can be selected, each should hint at its pliancy as the mouse rolls over it.
Although it doesn’t address the issue directly, a smooth and simple way to navigate around a scene can also ameliorate the picking problem. SketchUp has mapped both zoom and orbit functions to the mouse scroll wheel. Spin the wheel to zoom in towards or away from the central zero point in 3D space; press and hold the wheel to switch from whatever tool you are using to orbit mode, which allows the camera to circle around the central axes in any direction. This fluid navigation makes manipulation of an architectural model almost as easy as rotating it in your hand.
25_084113 ch19.qxp 4/3/07 6:09 PM Page 420
420
Part III: Designing Interaction Details
Object rotation, camera movement, rotation, and zoom
One more issue specific to 3D applications is the number of spatial manipulation functions that can be performed. Objects can be repositioned, resized, and reshaped in three axes. They can also be rotated in three axes. Beyond this, the camera viewpoint can be rotated in place or revolved around a focal point, also in three axes. Finally, the camera’s field of view can be zoomed in and out.
Not only does this mean that assignment of meta-keys and keyboard shortcuts is critical in 3D applications, there is another problem: It can be difficult to tell the difference between camera transformations and object transformations by looking at a camera viewpoint, even though the actual difference between the two can be quite significant. One way around this problem is to include a thumbnail, absolute view of the scene in a corner of the screen. It could be enlarged or reduced as needed, and could provide a reality check and global navigation method in case the user gets lost in space (note that this kind of thumbnail view is useful for navigating large 2D diagrams as well).
Object Connection
A direct-manipulation idiom that can be very powerful in some applications is connection, in which a user clicks and drags from one object to another, but instead of dragging the first object onto the second, a connecting line or arrow is drawn from the first object to the second one.
If you use project management or organization chart programs, you are undoubtedly familiar with this idiom. For example, to connect one task box in a project manager’s network diagram (often called a PERT chart) with another, you click and drag an arrow between them. In this case the direction of the connection is significant: The task where the mouse button went down is the from task, and the task where the mouse button is released is the to task.
As a connection is dragged between objects, it provides visual feedback in the form of rubber-banding: The arrow forms a line that extends from the first object to the current cursor position. The line is animated, following the movement of the cursor with one end, while remaining anchored at its other end. As a user moves the cursor over connection candidates, cursor hinting should suggest that the two objects may be connected. After the user releases the mouse button over a valid target, the program draws a more permanent line or arrow between the two objects.
In some applications, it also links the objects logically. As with drag-and-drop, it’s vital to provide a convenient means of canceling the action, such as the Esc key or chord-clicking.
25_084113 ch19.qxp 4/3/
07 6:09 PM Page 421
Chapter 19: Pointing, Selecting, and Direct Manipulation
421
Connections can also be full-fledged objects themselves, with reshape handles and editable properties. This sort of implementation would mean connections could be independently selected, moved, and deleted as well. For programs where connections between objects need to contain information (such as in a project-planning application), it makes sense for connections to be first-class citizens.
Connection doesn’t require as much cursor hinting as other idioms do because the rubber-banding effect is so clearly visible. However, it would be a big help in programs where objects are connected logically, to show which currently pointed-to objects are valid targets for the arrow. In other words, if the user drags an arrow until it points to some icon or widget on the screen, how can he tell if that icon or widget can legally be connected to? The answer is to have the potential target object engage in some active visual hinting. This hinting for potential targets can be quite subtle, or even eschewed completely when all objects in the program are equally valid targets for any connection. Target objects should always highlight, however, when a connection is dragged over them, in order to indicate willingness to accept the connection.
25_084113 ch19.qxp 4/3/07 6:09 PM Page 422
26_084113 ch20.qxp 4/3/07 6:09 PM Page 423
20
Window Behaviors
Any book on user interface design must discuss windows (with a lowercase w), a hallmark of the modern graphical user interface. While windowing systems provide modularity and flexibility to user interfaces, they can be horribly abused. In this chapter, we’ll first place these omnipresent rectangles in some historical perspective and then discuss important design considerations for the use of windows in applications.
PARC and the Alto
Modern GUIs all derive their appearance from the Xerox Alto, an experimental desktop computer system developed in the mid-1970s at Xerox’s Palo Alto Research Center (PARC), now PARC, Inc. PARC’s Alto was the first computer with a graphical interface and was designed to explore the potential of computers as desktop business systems. The Alto was designed as a networked office system where documents could be composed, edited, and viewed in WYSIWYG (what you see is what you get) form, stored, retrieved, transferred electronically between workstations, and printed. The Alto system contributed many significant innovations to the vernacular of desktop computing that we now regard as commonplace: The mouse, the rectangular window, the scrollbar, the pushbutton, the “desktop metaphor,”
object-oriented programming, drop-down menus, Ethernet, and laser printing.
26_084113 ch20.qxp 4/3/07 6:09 PM Page 424
424
Part III: Designing Interaction Details
PARC’s effect on the industry and contemporary computing was profound. Both Steve Jobs and Bill Gates, chairmen of Apple Computer and Microsoft, respectively, saw the Alto at PARC and were indelibly impressed.
Xerox tried to commercialize the Alto itself, and later a derivative computer system called the Star, but both were expensive, complex, agonizingly slow, and commercial failures. It was widely felt that executive management at Xerox, then primarily a copy machine company, didn’t have the vision or the gumption to put a concerted effort behind marketing and selling the “paperless office.” The brain trust at PARC, realizing that Xerox had blown an opportunity of legendary proportions, began an exodus that greatly enriched other software companies, particularly Apple and Microsoft.
Steve Jobs and his PARC refugees immediately tried to duplicate the Alto/Star with the Lisa. In many ways they succeeded, including copying the Star’s failure to deal with reality. The Lisa was remarkable, accessible, exciting, too expensive ($9995 in 1983), and frustratingly slow. Even though it was a decisive commercial failure, it ignited the imagination of many people in the small but booming microcomputer industry.
Meanwhile, Bill Gates was less impressed by the sexy “graphicalness” of the Alto/Star than he was by the advantages of an object-oriented presentation and communication model. Software produced by Microsoft in the early 1980s, notably the spreadsheet Multiplan (the forerunner of Excel), reflected this thinking.
Steve Jobs wasn’t deterred by the failure of the Lisa. He was convinced that PARC’s vision of a truly graphical personal computer was an idea whose time had come. He added to his cadre of PARC refugees by raiding Apple’s various departments for skilled and energetic individuals, then set up a skunk works to develop a commercially viable incarnation of the Alto. The result was the legendary Macintosh, a machine that has had enormous influence on our technology, design, and culture.
The Mac single-handedly brought an awareness of design and aesthetics to the industry. It not only raised the standards for user-friendliness, but it also enfranchised a whole population of skilled individuals from disparate fields who were previously locked out of computing because of the industry’s self-absorption in techno-trivia.
The almost-religious aura surrounding the Macintosh was also associated with many aspects of the Mac’s user interface. The drop-down menus, metaphors, dialog boxes, rectangular overlapping windows, and other elements all became part of the mystique. Unfortunately, because its design has acquired these heroic proportions, its shortcomings go unexamined.
26_084113 ch20.qxp 4/3/07 6:09 PM Page 425
Chapter 20: Window Behaviors
425
PARC’s Principles
The researchers at PARC, in addition to developing a revolutionary set of hardware and software technologies to create the Alto, also pioneered many of the concepts held as gospel today in the world of GUI design and development.
Visual metaphors
One of the ideas that emerged from PARC was the visual metaphor. At PARC, the global visual metaphor was considered critical to a user’s ability to understand the system, and thus critical to the success of the product and its concept. As we discussed in Chapter 13, the use of metaphor in interaction design can be severely limiting. It isn’t surprising, though, that early interface designers found the approach compelling in the face of a potential user population largely unfamiliar with computers.
Avoiding modes
Another principle associated with the modern GUI is the notion that modes should be avoided. A mode is a state the program can enter where the effects of a user’s action changes from the norm — essentially a behavioral detour.
For example, older programs demanded that you shift into a special state to enter records, and then shift into another state to print them out. These behavioral states are modes, and they can be extremely confusing and frustrating. Larry Tesler, former PARC researcher and former Chief Scientist at Apple, was an early advocate of eliminating modes from software and was pictured in an influential magazine wearing a T-shirt with the bold legend “Don’t mode me in.” His license plate read,
“NOMODES.” In a command-line environment, modes are indeed poisonous.
However, in the object-verb world of a GUI, they aren’t inherently evil, although poorly designed modes can be terribly frustrating. Unfortunately, the don’t-mode-me-in principle has become an unquestioned part of our design vernacular.
Arguably, the most influential program on the Macintosh was MacPaint, a program with a thoroughly modal interface. This program enabled users to draw pixel-by-pixel on the computer screen. A user selected one tool from a palette of a dozen or so and then drew on the screen with it. Selecting a tool is entering a mode because, when a tool is selected, the behavior of the program conforms to the attributes of that tool. The program can only behave in one way.
26_084113 ch20.qxp 4/3/07 6:09 PM Page 426
426
Part III: Designing Interaction Details
The PARC researchers weren’t wrong, just misunderstood. The user-interface benefits of MacPaint, when compared with contemporary programs, were great, but they didn’t accrue from its imagined modelessness. Rather, they resulted from t
he ease with which the user could see which mode the program was in and the effortlessness of changing that mode.
Overlapping windows
Another Mac fundamental that emerged from PARC (and which has metastasized in Microsoft Windows) is the idea of overlapping rectangular windows. The rectangular theme of modern GUIs is so dominating and omnipresent that it is often seen as vital to the success of visual interaction.
There are good reasons for displaying data in rectangular panes. Probably the least important of these is that it is a good match for our display technology: CRTs and LCDs have an easier time with rectangles than with other shapes. More important is the fact that most data output used by humans is in a rectangular format: We have viewed text on rectangular sheets since Gutenberg, and most other forms, such as photographs, film, and video also conform to a rectangular grid. Rectangular graphs and diagrams are also the easiest for us to make sense of. There’s something about rectangles that just seems to work cognitively for humans. Rectangles are also quite space-efficient.
Overlapping windows demonstrated clearly that there are better ways to transfer control between concurrently running programs other than typing in obscure commands. They were initially intended to represent overlapping sheets of paper on a user’s desktop. Okay, but why? The answer again goes back to the global metaphor of the desktop. Your desk, if it is like ours, is covered with papers; when you want to read or edit one, you pull it out of the pile, lay it on top, and get to work. The problem is that this works only as well as it does on a real desktop and that isn’t particularly well, especially if your desk is covered with papers and is only 21 inches across diagonally.
The overlapping window concept is good, but its execution is impractical in the real world. The overlapping-sheets-of-paper metaphor starts to suffer when you get three or more applications and documents on the screen — it just doesn’t scale up well. The idiom has other problems, too. A user who misclicks the mouse a couple of pixels in the wrong direction can find his program disappearing, to be replaced by another one. User testing at Microsoft showed that a typical user might launch the same word processor several times in the mistaken belief that he has somehow
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 57
