Appendix B. SwyftCard Interface Theory of Operation

Some of the principles discussed in this book were first published in the SwyftCard manual, released in 1984. SwyftCard, which plugged into the then highly successful Apple II, was simple by today's standards. Appendix B of its manual contained an unusual feature: Along with the usual theory of operation of the hardware, it also contained a theory of operation of the software and what is probably the first appearance of a user interface theory of operation in any commercial product. In a way, that appendix was the beginning of this book. The quoted material is from the second edition (Alzofon and Raskin 1985).

The paradigms used in SwyftCard were invented to cure a host of problems shared by almost all current systems—most of them small enough in their own right, but which taken together make learning and using conventional software far more time-consuming than necessary, and which make using computers a frustrating and annoying process.

We have always wondered why, for example, you have to format disks—isn't the computer smart enough to see if a disk isn't formatted and do it if necessary? We find cursor control keys far too slow, and when you consider the number of auxiliary commands they require (move to next /previous word, sentence , paragraph, page, move to beginning/end of line, document, file...) we find them too complex. The GID is only a small improvement because most of them take your hands away from the keyboard, and uses up much screen space for menus, scroll bars, and the rest of the associated GID apparatus. We are annoyed when we are put through menus instead of being able to do what we want right now, and we are puzzled by the huge number of commands in most systems. We hate disk systems that allow you to lose work through trivial human error. We are amazed that many word processors cannot keep up with human typing speed.

SwyftCard shows that with proper design all these questions and bothers—and many others that have plagued us for years —can be answered and fixed. And the system works on an inexpensive computer with only one disk drive, with minimal memory requirements. Our product does what most people need done—without an operating system, expensive price tag, or bells and whistles.

The major design principles include numerous innovations, as well as applications of what we have learned from the work of others.

1. The cursor LEAP concept, whose average time to target is about three times faster than that of the most advanced method in common use up until now: the mouse.

2. The cursor itself, whose two parts show you exactly where what you type will appear and where delete will operate . The cursor also collapses upon being moved so that you do not have to aim "one off" if you want to delete.

3. A very small set of fundamental operations that allows you to accomplish a wide range of tasks with ease.

4. The elimination of an operating system, thereby allowing all operations to be performed directly and immediately from the editor without having to go into different modes.

5. The elimination of modes in general, which makes habit formation easy because you do not have to think about what state the system is in to figure out what a command will do. This property is called modelessness.

6. Not providing many ways to do a task—again so that you do not have to think about alternate strategies when you are about to do something. We call this principle monotony. Like modelessness, monotony aids habit formation.

7. The emphasis on habit formation is itself a fundamental principle of the design, and one often overlooked by other designers. We consider it important that after a brief period of learning, a user should not have to think about the system while using it.

8. The DISK command, which simplifies the usual complexities of a DOS (Disk Operating System) into one simple command. It also provides protection against most common mistakes that would cause a loss of data on other systems. The technique of making one disk correspond to one Text is what makes this command possible.

9. The emphasis on making speed of operation proportional to frequency of use (often-done tasks must be very fast, seldom-done tasks can be slow).

10. What you see is what you get—the way it looks on-screen is the way it prints on paper. (This principle was violated for underlining due to a limitation in Apple display hardware.)

11. Noun-verb design of commands. First you specify what you are going to work on (that gives you time to make sure you are right and to make corrections), then you give the order as to what to do. Some systems work the other way around, or even worse , mix the two styles.

12. It is very hard to louse yourself up or clobber something you are working on. It's not impossible , but it's hard enough to do that it is not likely to happen by chance or a momentary lapse of attention.

13. The inclusion of programming and communications within a general purpose environment, where the output is placed in the editor/retrieval environment.

14. The allowance of months of testing and reworking time in the schedule, so that purchasers of the system are not being used as test subjects.

This is only a barest sketch—the system specs run to some 50 pages—but we hope it gives you a feel for what led us to design SwyftCard the way we did.