The time it takes your favorite application to complete a given task doubles with each new revision. ?span>Lincoln Spector The present structure of computer software, consisting of an operating system under which application programs execute, is inherently modal. This implies that for an interface to be nonmodal, an approach that does not include applications in their present form is required. Because gestures, such as those that invoke commands, in one application may not be available in another, you must be conscious of which application is currently active. But you cannot reliably do this when your locus of attention is the task you are trying to accomplish. You will sometimes use a gesture with either no result or the incorrect result. A separate difficulty caused by application programs is the unavailability of the facilities of one application when you are in another; you wish to do a task that you could have done in application A, but you are in application B, which has no comparable command. Computer scientist Dan Swinehart called this the dilemma of preemption (Tesler 1981, p. 90). Three approaches at solving the preemption dilemma are well known. The most common method is to provide, in each application, all those facilities the user is likely to need. This was discussed in Section 5-1, where it was pointed out that every personal computer has many different text editors, each part of an application or other facility. Most personal computer word processors have multiple and different text editors; for example, a typical word processor has a weaker editor for typing a pattern into the Find dialog box than for working in the main body of the text. This approach forces applications to become gargantuan, as each of them must solve a host of user needs that are peripheral to the primary thrust of the software. For example, my word processor has an embedded drawing program so that I can create simple illustrations without having to leave the text editor. At the same time, my drawing program has an embedded text editor so that I can include formatted blocks of text in my drawings without having to leave the drawing program. The drawing facilities in the editor and the text-editing facilities in the drawing program are inferior to the software dedicated primarily to those tasks. Ideally, all of the commands and abilities of both the drawing and the editing programs should be available at all times. Similarly, every program has facilities for saving and retrieving named files. However, these facilities operate differently and have different features in different programs. This is confusing, difficult to operate, and requires immense amounts of largely redundant software, all of which you must pay for, learn to use, keep the documentation for, and provide adequate main memory and mass storage. The same is true of a host of other features, such as printing, that are duplicated or nearly duplicated among programs. There has been some industry recognition of these difficulties; a number of companies designed software that permits a single compound document to have parts created by different applications. When you click at any point in a compound document, the application that created that portion of the document becomes active. Once the compound document has been created, this technique allows you to avoid having to open the individual applications explicitly. Of course, to create such a document, you must still manually invoke the applications, create the parts of the compound document, and then assemble them, usually by cutting and pasting or by dragging. Although providing a modicum of convenience, the dilemma of preemption is not solved by this method, which is exemplified by Apple's OpenDoc, HP's NextWave, and Microsoft's OLE software and their descendants. When you are working in one part of a compound document, you do not have the facilities of the applications used to create the other parts of the document. Worse, you now have a document that seems to have no boundaries but whose behavior changes from place to place without warning. A table and a spreadsheet may look identical, but one operates according to the rules of the word processing program, and the other operates according to the rules of the spreadsheet program. This is modality with a vengeance. The only warning you get as you click here and there is that the menus, which are usually positioned far from the locus of attention, change. As we have seen, this is an ineffective means of alerting a user as to system state; there is, of course, no completely effective means. The original approach to eliminating the modes inherent in applications was to create the windowing paradigm. At Xerox PARC, Alan Kay proposed overlapping windows, in part to eliminate the modality of applications. He also wanted to eliminate the distinction between operating system and applications but succeeded primarily in making the functioning of the operating system visible in the form of the desktop. This was a true advance, but as PARC's Larry Tesler put it, "windows are, in a sense, modes in sheep's clothing" (Tesler 1981, p. 94). That is, windows do not eliminate the modality of applications but instead make multiple applications simultaneously visible and accessible. Kay's insight, and the other ideas developed around windowing, formed an important step forward that has benefited users for more than a decade, but the problem of modes and the preemption dilemma posed by the existence of applications had not been solved. Since that time, the sheep disguise has worn thin, and the wolf bites us all too often. Section 5-8 presents one way of dispatching the wolf completely. Calculator or Computer? It's true. Many of us keep a calculator beside our computers. Why do you need this simple-minded device when you have a whole computer in front of you? You need it because you have to go through contortions worthy of a circus sideshow in order to do simple arithmetic with the computer. There you are, tapping away at your word processor, when you want to do a division: 375 packages of Phumuxx cost $248.93; what is the price for one package? On my computer, I have to open up a calculator window. To do this, I move my hand from the keyboard to the mouse, which I use to do a click-and-drag to open the calculator. Transferring my hands back to the keyboard, I type in the numbers I need or tediously cut and paste them from my document. Then I have to press a few more keys and finally copy the results from the calculator window into my document. Sometimes, the calculator window opens right on top of the very numbers I need, just to add insult to injury. In that case, I must use the mouse to move the calculator window out of the way before proceeding. It is much faster to grab the pocket calculator. A better solution is a Calculate button or omnipresent menu command that allows you to take an arithmetic expression, such as 248.93 / 375, select it, and do the calculation whether you are in the word processor, communications package, drawing or presentation application, or just at the desktop level. In other words, it is an example of a universal function that can be used anywhere. Using an experienced computer and calculator operator as my test subject, with his word processing program open before him, I measured the total time it took for him to pick up a calculator, turn it on, do a simple addition, and return his hands to the keyboard to resume typing. It took about 7 seconds. I then measured the time it took for him to use the built-in calculator. He had to move the cursor to the menu bar at the top of the screen, find the calculator program, open the calculator, enter the sum, and then click back in the word processor so that he could resume typing. This took about 16 seconds. The same subject was asked to do the calculation from the middle of a document on a Canon Cat, which has a built-in Calculate key and can do arithmetic in text. The time was 6 seconds, using the top-line numeral keys for data entry. There is no time advantage to using an external calculator in this case. On the Cat, the result was left in the document, in the likely case you needed the result inserted. But the result was also left selected, so that a tap of the Delete key made it vanish if you did not want it in your text. Here's another facility that should be generally available: Anywhere a number can be entered, you should be able to enter an arithmetic expression that evaluates to the number. Commands such as Check the spelling of the current selection Treat the current selection as an arithmetic expression and evaluate it Transmit the current selection as an e-mail Transmit the current selection as a fax See what's at this URL on the web Execute the current selection as a Java (or whatever) program should be available at all times. It is eminently doable.
|
|
