 |
 |
|
|
The command language is the channel for user input and it must be capable of expressing all possible transactions, whether they are issued from the keyboard or from some graphical pointing device. Even when the number of different devices grows large, it is necessary for the command language to have a uniform design so that it is easy to learn and extends cleanly. Important functions should be redundantly available on different devices for ease of invocation, and there should be options for rearranging the location of different commands. Other desirable features of a command language are minimal use of modes, convenient abort, online help, and proper error recovery. The next two sections discuss device-specific aspects of command languages, followed by a general discussion of command-language features.
The keyboard is and will remain the most powerful input device because it can transmit the most complex and specific commands. Since the user of a CAD system typically types a certain number of operating-system commands in order to use the machine (login, run programs, and so on), it is to the advantage of the CAD system to mimic that command language. This does not mean duplicating commands, but rather using the same style of command structure. For example, on a UNIX operating system [Ritchie and Thompson], switches are prefixed with a "-", and on a DEC operating system [Digital] the switches begin with a "/".
Since CAD is very much an editing task, another possible model that can be used for the command interface is to mimic the current text editor. For example, if the CAD system runs on a machine that provides the EMACS editor [Stallman], it might allow similar concepts such as dynamic key binding, single-key commands, and the use of special keys as a prefix for longer commands. General editing concepts--for example, the semantics of action verbs in the command language and the syntax of operands--can be shared.
The preceding discussion raises the issue in keyboard command languages of whether or not to use the keys individually as complex function buttons. Many systems allow a single keystroke to do a full action such as creation and deletion. Systems without this capability require a full line of text to be typed including a carriage-return. Since full commands are more powerful they must always be available, even in single-keystroke environments. This option can be provided by having a special single key that prefixes the typing of longer commands, as in Caesar [Ousterhout] and Electric.
When typing long commands, it is helpful to have
command completion.
With this feature, originally found in the TENEX operating system
[Bobrow et al.],
the command interpreter fills out any partially typed keyword
if enough letters have already been entered to identify that keyword uniquely.
For example, if the system expects the commands "compile," "compose,"
or "create"
and the user has typed cr, then the system knows which command has
been selected and can append
the letters eate when a carriage-return or other delimiter is typed.
Command-completion systems also provide special keys for immediate
completion and for help.
The special completion key, for example an escape, fills out the keyword
without terminating the line or taking any other action.
The help key, often a "?", lists all options at the current point.
If, in the preceding example, the user were to type co and an escape,
the system would append mp but nothing more because
there is ambiguity after that.
The system could also give some indication that the keyword is not
complete (a beep or flash).
If the user then types a "?", the system will list the options--"compile"
or "compose"--and then return the user to the input after "comp."
This example shows the need to select the keywords in a command language carefully. If the user is going to have the advantage of abbreviating commands for reduced typing, then a comfortable command set will be unique in the first few letters. Having two commands that both begin with the same four letters requires that the user type five letters in order to abbreviate minimally, and that is not much of a saving over typing the full command. In the example, the programmer would be well advised to change "compose" to "assemble" or any other word that does not conflict with "compile."
There is a feeling among computer users that the keyboard is an inappropriate input device for what is essentially graphical activity, and that its use should be minimized. Instead, a mouse or other pointing device would seem better suited to the job. Actually, the keyboard is potentially very powerful and can provide much more bandwidth than can a mouse, but this requires that the user be experienced. To make novices more comfortable, a mouse is convenient and experiments indicate that it is faster to use [Card, Moran, and Newell]. Of course, the keyboard cannot be totally replaced because there will always be names and numbers to type, but command input can be shifted away, making the keyboard a secondary device. In some systems, the keyboard is used to enhance the pointing device by having single keystrokes act as pointer buttons, thus giving many more options to a pointing action. However, this requires a shift of attention from the screen to the keyboard, a delay that human engineering seeks to avoid. In a proper graphical command language, the input device must be programmed for maximum convenience or else the user will demand to use the keyboard again.
Menus are an obvious choice for implementing a graphically based command language. Although the time taken to select a menu entry was reported earlier to be 1.1 seconds, this time is actually dependent on the menu-entry size and its distance from the current cursor position [Card, Moran, and Newell]. To understand this dependency better, it is necessary to examine menu picking in more detail.
Returning to the model of human activity, it can be seen that the action of moving the cursor toward a menu entry requires one perception action (to see where the hand is going), one cognition action (to determine what to do), and one motion action (to do it). These three operations require 240 milliseconds, according to the time values given earlier. However, this does not put the cursor in the menu, but rather moves it some fixed percentage toward its goal. The actual time to get to the menu is therefore an exponential function based on distance and accuracy. This function, called Fitt's Law, states that the time to a menu entry will be:
| I | × | log2 | 2D |
There are, of course, other ways to indicate a command graphically, such as cursive-script recognition. The Ledeen character recognizer [Curry], a simple and effective method of distinguishing handwritten letters, can be used to identify a large set of commands that are the result of stroke combinations. The Bravo3 design systems use this as their primary command interface [Applicon].
Although graphical command languages have the advantage of easily specifying screen positions, they are unable to give precise coordinates or other exact numeric values. One solution is to provide a number menu that mimics familiar devices such as telephones or adding machines. This menu works like its physical analog and allows the user to "punch up" a desired value. Further, it supplies the same functionality as a real device including sign entry, decimal point, backup, and abort.
An alternative to the tedium of selecting individual digits when defining an exact value is to use a graphical number wheel [Thornton]. The screen displays a wheel and the current value on that wheel, so that when the user points to it and moves the cursor, the wheel is "rolled" and the value changes. The wheel can keep spinning after a "pull," and additional pulls can speed it up. Slower pulls will advance the value more slowly and a single grab will stop the spinning, thus completely mimicking a physical wheel and giving the user a familiar feel to number selection.
For some tasks, the inaccuracy of the cursor can be made more precise in special-purpose ways. If a drawing task has known regularity, it may be helped by enforcing that regularity. For example, when objects are drawn, their placement can be snapped to a grid that is used to align everything on the screen. The size of the grid should be controllable, as should the option of displaying it so the user can see the spacing. As another example, when drawing demands that all lines be at right angles or at 45-degree increments, the cursor position can be adjusted from where the cursor is to the closest point that meets this requirement.
| When the cursor approaches an object, it is often meant to touch that object. Thus, when the user is pointing on the screen, the cursor can snap to the closest other object if a connection is desired. In situations in which a connection may or may not be as necessary, the cursor can snap to another object only when near that object. This proximity area, called a gravity field, is larger around vertices than around edges because the vertices are the preferred cursor locations (see Fig. 10.7). |
|
There are certain attributes that all command languages should possess, regardless of whether they are issued from a keyboard, a pointing device, or even speech input. The interface should be friendly, mode-free, and able to abort, undo, or recover from errors.
The most important command language feature is friendliness. Error messages must be positive in nature, suggesting alternatives to the user's situation. The negative message "cannot do . . . " should instead be "must do . . . first."
In addition, help needs to be available at every opportunity for user input. Not only should online help be available for all commands, but each prompt should be prepared to explain more fully what is wanted. The online help information is best when it is structured in the same way as the actual commands being explained. This means that tree-structured command languages should have tree-structured help systems. Also, the method of obtaining help should be consistent and easy to guess-for example, the "?" key. Besides basic help, there can be help guidance to suggest the proper questions to ask for given subjects and there can even be a tutorial available to present basics. The ultimate system has an intelligent agent that watches and critiques user actions. With such a facility, a total neophyte can use the system without any confusion or human assistance.
One aspect of command languages that programmers attempt to avoid but rarely do is modes. Modes are collections of commands that are tailored for specific tasks. Although they are convenient for that particular task, they are confusing to learn and to use because they tend to overload manual operations, redefining them at different times. For example, the user might learn that the "X" key means erase when in "placement mode" and it means undefined when in "simulation mode." This inevitably leads to issuing the right command in the wrong mode, which does arbitrarily bad things.
If modes are to be used (and they are nearly impossible to avoid), then they should be kept to a minimum. The current mode should be clearly displayed in the permanent message area, and those functions that have meanings that change in each mode should have their current meaning displayed. Most important, the user must be able to recover from mistakes, whether they be due to mode confusion or the result of just plain stupidity. This means allowing the abort of any partially completed action and the undo of any finished mistake.
Abort options do not belong only in likely trouble spots; they must exist in all prompts to the user. They should be an obvious option and should revert to a sensible state for the continuation of work. Undo control is harder to implement because it may require the tracking and resetting of large amounts of state. In addition to undoing the last command, it should be possible to undo many previous actions and to undo an undo, which amounts to a redo. Beware of complex undo control that allows the user to make inconsistent change requests.
The ultimate error recovery is, of course, safety from crashes. It is no small thing to insist that a large computer system be immune to crashes. People spend years debugging programs and writing diagnostics, yet systems still fail. Even after the perfect, bulletproof program has been written, there will always be external sources of error such as operating-system faults and hardware failure. In short, no program is safe from crashes and the only way to make a program robust is to have it recover properly.
When a change is made to a circuit, that change is probably not permanent because most systems change only the memory representation and not the disk version. It is only when the circuit is saved on disk that the changes are committed, or made permanent. Highly robust database systems have explicit commit steps after every change so that a secure disk record is made of the action. In most CAD systems this is too expensive. Also, users are not willing to commit until they finish an editing session.
In systems that update only memory, a crash will cost all of the changes made since the last save. One way to provide recovery in this situation is to checkpoint the circuit automatically by saving it on disk every few commands. The user will then be able to use the most recently checkpointed version, which will be only a few changes behind. Unfortunately, VLSI design files may be so large that saving them frequently is more annoying than is redoing lost work.
An alternative to saving the design is to save changes to the design. This information is much more compact and can be written to disk frequently and quickly. Since a design system transforms user input to database changes, either end of that processing pipe can be saved. If the user input is saved, then each keystroke, pointer position, and button push is recorded in a session log file. If the database changes are saved, then each new object, modification of an object, or object deletion is recorded.
Recovery using change files requires that the files be "played back" to re-create the last state of the database. User input playback will more precisely show the steps that led to the crash and are thus more helpful in debugging. In addition, user input files are smaller than database change files because users typically give very little information in relation to what is produced. After all, it is the job of the CAD system to translate brief user requests into circuits that are increasingly complex. Thus user-input logging is the most concise and effective way to recover from crashes. It also makes a nice demonstration of a design system to see an entire circuit built at the high-speed of session playback.
The one thing to ensure in user-input files is that there is enough information recorded to reproduce the session correctly. If, for example, a "select" command is issued when the cursor is over two identical objects, the database state will determine which object is selected first. If that database state cannot be guaranteed during playback, a different object may be selected, causing incorrect recovery. To overcome this problem, additional command-specific information may have to be recorded in the logging file.
|
Previous |  |
Table of Contents | Next | |
Static Free Software |  |
