The prerequisite for proper human engineering is a deep understanding of the user's particular goals and operating methodologies. Also useful is a general understanding of the way humans interact with machines. When programmers are unaware of these issues, they make assumptions that are intuitive to them in the hope that all will work right. The result is often inconsistent both at the user-interface level and internally in the code. Attempts to rectify the user interface are fraught with difficulties because the code becomes complicated, hard to maintain, and full of bugs.
When the task has been modeled correctly, the other aspects of human engineering proceed easily. Command language syntax becomes obvious because it maps directly from the task to the program internals. The same is true of the information display and the nature of the feedback. Also, a truly consistent task model agrees with the users' notions of what is difficult and what is simple, reducing the frustration of using time-consuming operations.
Thus the first step in building a VLSI design system is developing an understanding of electronics and design so that a sensible model can be made. Chapter 1 discussed the circuit-design process and Chapter 3 showed some representations for VLSI CAD: topological, geometrical, and hierarchical data structures. Every synthesis and analysis tool needs a combination of these data structures to work best.
The next step in building any user interface is developing an understanding of the way humans interact with machines. This interaction has only recently been analyzed and some quantitative results are now available [Card, Moran, and Newell]. Essentially, the human performs three different operations when interacting with a computer: perception, cognition, and motion. A perception is the operation of observing the screen to obtain some information. Experiments have shown that a single perception action takes from 50 to 200 milliseconds, averaging 100 milliseconds or 0.1 seconds. This means, for example, that any display action such as motion that occurs at least 10 times per second will appear continuous to an observer. The cognition operation is the step that humans make when deciding how to react to a perception. After a cognition step, which averages 70 milliseconds, the human may do another perception or, more likely, a motion. Motion actions include striking a key or moving the pointing device. Basic motion actions take only 70 milliseconds, but this presumes that the user's hand is already on the device. If the user's hands are incorrectly placed and must switch devices, the delay is 400 milliseconds. Thus, while the mouse or joystick may be faster to use, the setup time is so high that for short operations preceded and followed by keyboard activity, the keyboard is still the preferred device.
Card, Moran, and Newell also describe larger operations that relate more directly to the use of a design system. Typing, which combines perception, cognition, and motion, averages 0.2 seconds per key. Moving the cursor to a spot on the display takes 1.1 seconds. Mental preparation for a new command or new part of a command takes 1.35 seconds. These figures are certainly simplifications, but they allow design functions to be evaluated for their relative efficiencies.
These timings can be used to evaluate the relative merits of
different human-interaction methods.
For example, the "replace" command substitutes a new object in place
of the currently selected object.
This command can be issued in the traditional way by typing the
string rep new-object
or it can be issued with menu picks.
The menu method starts by selecting the "replace" entry and
then selecting the new object from an object menu (which may
actually have to be two menu hits to select a class of objects and then
an object in that class).
The typing method requires four steps: type the command keyword (rep
),
terminate the keyword (a space), type the new object name (average of 10
characters), and terminate the command (a carriage-return).
Each of these operations requires a mental operation to initiate it followed
by a number of keystroke operations (see Fig. 10.1).
The menu-pick method requires three button pushes to select the command, the
new object class, and the new object.
Each pick involves a mental operation, a cursor movement, and a button push.
The figure shows that this is slightly faster than the keyboard method,
but many factors could alter this, such as the need for an additional menu hit,
delays of machine response time, or the need to
move hands between the keyboard and the mouse.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FIGURE 10.1 Comparative timings of keyboard and mouse commands. |
Another aspect of proper task modeling is the correct use of terminology. Programmers should avoid making up new words to describe a situation and should instead find out what the right jargon is. This will make the code more readable and also will keep internal error messages from being totally obtuse. The user will then be able to help in those unusual circumstances in which otherwise hidden parts of the system suddenly surface.
In addition to using correct terminology, the programmer must consider the best way to keep the terms clear in the user's mind. The problem of terminology confusion is called interference and it occurs in two forms: acoustic and semantic [Card, Moran, and Newell]. Acoustic interference is caused by having two words sound alike. This problem occurs more often in short-term memory, when new words are presented for immediate use. For example, a library with the cell names "hit," "fit," and "kit" may make sense to the user when their functions are first introduced, but the acoustic interference between them will damage the user's ability to recall the names a short while later.
Semantic interference is caused by having two words or concepts share their meaning. This problem appears in long-term memory, where word meanings are learned. For example, teaching a second computer language causes semantic interference that damages the ability to use the first computer language.
There is a very simple test of the quality of a task model. Look at the sequence of commands for a complex operation and decide whether they are comfortable and intuitive or are merely a recipe of mindless commands. Avoid having to tell the user to "issue these commands without worrying about what they mean" because users do worry about the meaning of what they are typing. Recipes are bad and encourage ignorance on the part of users and maintainers alike. When a correct task model is provided, the need for complex and confusing sequences is greatly reduced.
Previous | Table of Contents | Next | Static Free Software |