A good design is better than you think. ?span>Rex Heftman We are justifiably annoyed when a product, a piece of software, or a computer system imposes complexity beyond our needs and presents difficulties we do not understand. We want to do some simple word processing, but we are forced to take in hand hundreds or, as in the case of Microsoft Office, thousands of commands and methods that we do not need. If, on the other hand, we brought in each of those commands as we understood our need for them, then the feeling of imposition and the immense cognitive burden would be lifted, even if the eventual system turned out as complex as the original application. By applying the concept that a system should not be more complex than your present needs and by allowing the system to increase its power incrementally, the dream of providing products that are initially truly simple can be achieved without their being made to merely look simple and without impairing their flexibility. To understand one means of doing this, recall from Section 5-1 that almost all that a computer does involves the content that you provide or obtain and a set of operations you wish to perform on this content. Also recall that the interface to every such operation consists of two parts: choosing the content and invoking the operation. For example, in a game, you might shoot a monster, or, in our more prosaic terms, perform the operation of changing the image of a monster into an image of an explosion. The content is chosen by moving the cursor to the monster, and the operation is invoked by pressing the GID button a lovely interface, by the way: fast and satisfying. Invoking a command on a selection results in three possibilities: The operation can be performed on the selection. It makes no sense to apply that operation to the selection. The selection can be modified to make the operation possible.
In the first case, the operation is performed and the content modified. In the second case, the content is left unchanged. In the third case, another process must be invoked by the computer to modify the selection before the command can be performed. Suppose that you select a part of a photograph of a city street scene and try to apply the command that checks spelling. The command expects a sequence of characters (text), but what it finds is a photograph (a bitmap). Among the computer's capabilities is the ability to transform content from one data type to another.[12] In this case, the data type is bitmap and the command expects text, so the computer sees whether any transformer has bitmaps as inputs and text as output. Such transformers exist; they are called optical character recognition (OCR) programs. OCR programs are usually employed to convert input from scanners into editable text. (Some of the quotes in this book were obtained by scanning the article that contained the quote and then using an OCR program to convert the resultant bitmap into text.) Assume that the computer has an OCR program available. The OCR program is automatically invoked and inspects the bitmap. If it finds some characters it recognizes say, a stop sign and a partly obscured sign with the characters North First Stree, then these texts are presented to the spelling checker, which reports finding one unknown word (stree) and suggests that perhaps tree, strew, or street was meant. [12] This class of abilities is sometimes called filters, but the term filter implies selectivity rather than a general transformational ability. Thus, I prefer the term transformer, which is seldom used in computer science, outside of circuit descriptions, whereas filter has many uses, such as a digital filter program.
Instead of a computer's software being viewed as an operating system and a set of applications, the humane interface views the software as a set of commands, some of which are transformers that can be invoked automatically when the data type expected by the command does not match the data type of the object selected. More than one transformer may have to be invoked. For example, suppose that a computer with one transformer converts A to B and another that converts B to C; if the command expects data type C but the data type of the selection is A, both transformers will have to be applied before the command can be carried out. If no transformers are available to do the job, no change is made to the selection; the user is informed, if necessary, and the selection is left unmodified. Instead of providing application programs, software vendors will provide command sets that offer a collection of related operations. For example, instead of a program for doing photographic manipulation, a vendor would provide a number of independent commands that, collectively, provide exactly the same range of operations. The user would install as many or as few as she finds useful rather than having to install a huge application, of which only a fraction would be used. By means of Internet sales of software, a forward-thinking vendor could sell software on a command-by-command basis, perhaps with significant discounts for buying certain sets or certain numbers of commands. When users complain about the absurd complexity of applications and ask for simpler programs without what are perceived to be unnecessary bells and whistles, industry observers respond that "lite" versions of software packages tend not to succeed in the marketplace. There is good reason for the failure of lite packages. Because the user never knows which of the facilities offered by the complete package he might some day need, he purchases the whole package because that is the only way he can obtain these facilities. If he buys a limited, lower-cost version, the only way he can upgrade is by buying the complete package, even if it is only one small feature from the larger program that he would need to add to the lite version. Therefore, it is safer to purchase the full version from the beginning and to put up with the complexity. No wonder we feel trapped. Commands that could be purchased as needed are a more humane option. Various surveys report a range for the amount of typical software application features that are never used. The numbers have tended to rise over the last decade and have increased over that time from about 15 percent to the latest surveys nearing 50 percent. That is a lot of clutter. By providing command sets, each command of which can be installed independently, instead of applications, individual users can drive that statistic to nearly 0. Other advantages for vendors in this methodology are the ability to refine their products incrementally and to more easily and frequently provide (and sell!) new features, because they do not have to rerelease the whole package in order to do so. The web is an ideal medium for such repeated, piecemeal sales. Vendors, not necessarily the vendors of application command sets, will supply transformers. These, too, can be sold individually. If a majority of users regularly employ most of the word processing commands from vendor A, and vendor B thinks of a useful command that A does not provide, then B can sell that command to A's customers. However, B might use a different data structure. In that case, B would be wise to provide a pair of inverse transformers that go from A's data structure to B's data structure, and back again. If A's product has a very large customer base, then B might be wise to create a version of the command that works directly with A's data structure. Besides, another vendor, C, might be a specialist at providing transformers. It may become common practice for users to purchase transformers from such vendors and for command vendors to license the transformers they need. This commercial structure exists, in part, at present: Companies such as DataViz specialize in providing transformers. The pieces needed for a commands-plus-transformers computer environment also exist. It will not be difficult to put them together into a working system. Users will find such systems both easier to use and more flexible than today's application-bound designs. It is a solution that can decrease excessive feature bloat and complexity, incompatibility among applications, and the need to learn multiple solutions to the same problem. In the process, the operating system can disappear from the user's view entirely. If this program is carried out properly, not even the present, wool-coated version of the operating system the desktop will remain. Of course, not all programs require all this mechanism. A game, for example, would simply be launched and would run independently: This is done in the usual way by clicking on, or selecting, the desired game's name, probably from a text consisting of a list of names of games, and then using the Execute command. Section 6-2 discusses an alternative method. Considerate Programming: Applications as Visitors Consider that you have been invited to stay at the house of your good friends, the Grimbles. You even like their dog. The only problem is their beloved portrait of Aunt Ashtabula that hangs over the bed. It gives you and your wife the willies, and you can't possibly sleep in a room with Aunt Ashtabula looking on. You dare not tell the Grimbles how you feel, so how do you handle this situation when you visit? 1. Take down the picture and burn it. 2. Hide the picture in the wine cellar, where it will take the Grimbles a month to find it. 3. Put the picture in the closet, where they will find it sooner. 4. Put the picture in the closet and restore it to its original position just before you leave. Any considerate guest knows that option 4 is the best of those presented. The ethical principle is: Make a change in someone else's environment if you must, so long as you leave things just as they were before the host returns. Today's computers have many environmental parameters that can be set: speaker loudness, screen resolution and depth, menu behavior, and default system font. A Macintosh computer has hundreds of settings. In an IBM-compatible computer running Windows and Microsoft Office, the number is over 1,000. The parallel with the visit to the Grimbles? If you go and use somebody else's machine and change any settings, it would be considerate of you to change them back when you leave. Many programs demand a particular screen resolution, a certain number of bits per pixel, or another specific parameter setting to run properly. Their behavior, when the system does not have the correct parameter settings, ranges from genteel to uncouth to vandalism. Here is what various programs I tested do when they encounter incorrect display parameters: 1. Crash the computer, forcing a manual reboot. 2. Crash the computer, giving an indecipherable numeric message; you must press the Restart button to reboot the computer. 3. Give an error message saying that the screen settings must be adjusted, and when you click on the OK button, it crashes the computer. 4. Give an error message saying that the screen settings must be adjusted. When you click on the OK button, you can then open the appropriate control panel and adjust the settings. 5. Ask whether it should change the screen settings, and if you click on the OK button, the settings are changed. If you click Cancel, the program is not launched, and the screen settings are not touched. 6. Change the screen settings and run the program without comment. 7. Announce that it will change the settings in a dialog box. When you click on the OK button, it changes the settings and runs the program; when you quit the program, it changes the settings back to the way they were. A reader from the future may think that crashing the computer is a bit extreme. None of these methods goes all the way to being a good guest, although item 7 is close. The safest behavior is a combination of item 5's message and item 7's exit behavior. In the unlikely event that changing the screen settings will interfere with some other parallel or background process, you might decide not to run the program and might welcome the warning and a chance to opt out. 8. Change the screen settings and run the program without comment and reset the settings when exiting. In other words, you'd launch the program, and it would simply run: doing just what you expected and wanted, and no other program would be affected. That is my definition of a well-behaved computer system. But what if two programs requiring different screen settings are displaying pictures at the same time? That is a horse of a different color or a fish of a different resolution, perhaps. Item 7, which might seem acceptable and is in common use, fails us by giving us a "dialog" box that is no dialog. This is user abuse: The information imparted cannot be acted on, and it only wastes your time. (The transparent-message method of Section 5-2-3 solves this problem.) Application programs per se are an imposition, as this book argues, but so long as we are still saddled with them, let us make sure that they are well behaved (also see Raskin 1993). To summarize, a program or, in the future, a command should automatically reset whatever it needs in order to run; it should execute properly; and when the user dismisses it or when it is done, it should restore all parameters to the state they had when it was launched. If resetting is irreversible or could have an undesirable side effect, a warning explaining what damage might be caused can be given, so long as that message gives the user a choice as to proceed or not. Right now, you cannot run different resolutions on the same screen at the same time. But that's another kind of problem. In the meanwhile, I think that users would be happier if every user interface guideline added item 8. |
|
