Arguments against general-purpose interfaces: The case for specialization

Abstract

We believe that the general nature of the computer has been over-emphasized, and has led to the development of a general-purpose tool that attempts to serve all purposes. We believe this emphasis is wrong. Instead, we argue for specialization, for the development of specific, stand-alone applications, each with its own physical shape and mechanical components tailored for the needs of that application, each with whatever specialized forms of interaction are appropriate for the tasks to be performed. Such applications will not look like computers, they will look like applications. As a result, users will not need to know how to work computers. Instead, they will simply need to understand their applications.

Where do interface problems come from?

There is much concern about the appropriate form of the human interface to computers. The concern is justified because today's computer systems can be difficult to learn and difficult to use. We believe this is a side-effect of the inappropriate development of computer technology. The problem is that the industry has focused upon the general power of the computer and its seeming ability to serve in any task. The result is an attempt to build more and more powerful "personal computers," desktop devices that have general applicability to just about everything. We believe this approach is wrong. It forces the user first to learn how to use the general-purpose tools, and then to figure out how to apply these general-purpose tools to specialized tasks. The result is that these tools are not only less powerful than they might be, but they are also harder to use. The alternative approach is to develop highly specialized systems, each of which addresses one and only one task. Specialized solutions are apt to be more efficient and easier to learn than generalized ones, and will tend to be more powerful and useful for their specific application. With such systems, average users need not be aware of the computer or its interface; they need only be aware of and expert in the application.

The argument against general-purpose computer systems seems to go against all conventional wisdom. How can we say such a thing? Note that we are not saying that there should be no computers. In fact, we are arguing for more computers, many more than even the most optimistic computer manufacturer now contemplates. We think that the average home or office should have perhaps tens or even hundreds of computers. Each would do only one thing, but would do it well. In fact, it would be tailored so specifically for that one thing, and would be so embedded within that thing that it wouldn't look like a computer at all. Our goal is for average users not even to be aware of these computers, only of the applications. As far as they are concerned, there would be no computers in their lives, even though they would be surrounded by them.

Problems with generalized systems

Current general-purpose workstations or personal computers provide a large number of general services: document preparation, electronic mail, filing, perhaps drawing and other graphical tasks. Such systems, while powerful, pose serious problems:

• Interface definition and coordination. Specific tasks have specific requirements, and it is difficult to find a single style of interface that can satisfy the requirements of multiple tasks. Different tasks require the manipulation of different kinds of data structures: the arrays and matrices of a spreadsheet, the geometric objects of a graphics program, the textual fragments of a word processor. Many specialized systems come with special-purpose input/output devices and special keys or arrangements of keys that reflect these requirements of the task. In contrast, a general-purpose system can only have keys marked "control", "escape", and so on, and the user must infer or remember the mapping between these abstract labels and the actions required by the current task.
• Competition for resources. The general-purpose computer has only one screen, one keyboard, one pointing device, and so on. Consequently, the applications must compete for these resources, which raises many classic interface problems:
  • How can space available on the screen be divided up among the applications? How does the user manage the resulting subdivisions?
  • How does the computer — and the user — know which application has control of the keyboard and other input devices?
  • How does the user switch between applications?
  • How can the disruptions inherent in these competitions be minimized?

Thus far in the development of computer systems, the field has been willing to put up with these problems, at best trying to minimize their effects. This state of affairs has been accepted because of the great value placed on the general-purpose nature of computers. Their ability to address a wide range of problems has been seen as an inherent part of what makes a computer a valuable and powerful tool. We have no argument with the usefulness of this power, but we believe that the current way in which the power is made available requires too much of the users. Forcing people to adapt to the requirements of a single, general-purpose computational tool is the wrong solution.

The advantages of specialization

The major theme to our argument is that special-purpose devices are the best way to accomplish a task. Different tasks have very different and special demands. The problem of attempting to do all of these with a general-purpose computer is that we are forced to do so with generalized, limited tools. These general-purpose devices can approximate the needs of each task, but they fall far short of meeting the task's real requirements. Elsewhere in the world, humans have devised thousands of special-purpose tools for the varied tasks of everyday life. The variations in devices that one sees on the marketplace exist for a purpose: each makes control and operation easier and more efficient, but only for a specific task. Go into a hardware store, a cooking goods store, a stationery store, or a office supplies store and marvel at the variety of specialized instruments. Go into a knife store and note the wide variety of forms a single instrument can take, depending upon its intended use. We contend that the reasons that specialization has proven superior for these tasks can also apply to those tasks that are performed with computers.

Some advantages of specialization can be seen in computer systems today. Note how often the most effective computer systems require special-purpose input/output devices and interface techniques that are highly specialized to their task. Computer music systems are quite sophisticated, but the professional uses them with piano keyboards or other specialized musical devices serving as input controllers, and with special-purpose sound generators for output. The professional musician thinks of such devices as a new form of instrument or composing device, not as a computer. Drawing programs are also quite sophisticated, but again, the professional uses them coupled with specialized (and reasonably traditional) drawing devices and specialized plotters and display devices. Flight simulator programs are wonderful games when controlled by the general-purpose interfaces of the general-purpose computer, but they should not be confused with professional-quality simulators. When professional pilots use flight simulators, they are coupled to extremely realistic cockpits in which the inputs to the simulator come from switches, pedals, and control sticks in the cockpit, and the outputs go to the meters, gauges, and displays in the cockpit and to the sight, sound, and motion simulators of the environment. The pilots do not think of themselves as using a computer, they think of themselves as flying an airplane.

Making the move away from general-purpose systems

An argument against the previous discussion could go like this. The need for specialized technology is clear when there are highly specialized input/output requirements. However, most computer-based tasks do not have such needs, and can easily take place as part of a general-purpose computing environment.

Let us respond by considering a simple example, one that does not appear to have such specialized input/output requirements: the problem of scheduling appointments and managing one's calendar. There are many good reasons why a calendar should be implemented on a computer. Such a calendar could schedule things automatically, act as an intelligent reminder, help plan meetings, and do all the other things we so often dream of. However, if the calendar were a program residing on a workstation, then we could not use it in the flexible way that we have come to expect of our existing personal calendars, daily diaries, or appointment books. We couldn't pick it up and carry it with us to another office, or to a meeting, or on a trip. We would have a nice computational device, but it would be one that does not really meet our needs from a sociological perspective.

We suggest that the calendar of the future should look and function like our present-day calendar. It should do all the things that a calendar can do, plus whatever advanced features are relevant to calendars. It should fit in the pocket, or at least the briefcase, and should allow us to know the appointments of the hour, day, week, or year, using whatever display format is most appropriate. It should also connect to other calendars and applications through a communication channel. It should let new appointments be entered by pencil, keyboard, or, perhaps, voice. It should be intelligent enough that it can figure out the best time for a meeting given its description. However, it most definitely should not try to be a spreadsheet and a graph plotter and a writing assistant. Adding other tasks would necessarily take away from the portability and power of the calendar. They require different input and output devices, and different processing and memory requirements.

Note that it is not enough that specialized systems simply mirror the existing functionality of present-day tasks. For instance, we should be able to schedule a meeting with the members of our research group "when all of them are back in town, but after the department meeting, whenever that is", and let "the system" figure out the best time to have this meeting. We should also be able to view the information contained in the calendar in multiple ways: alternatively viewing the events of the next few hours and the next few months, or viewing events of different types (e.g., "Show me all the conferences I'm planning to attend in the next six months"). The idea of a computer system with these capabilities is nothing new. However, there are some points worth making:

• Meetings cannot be scheduled without access to the schedules of all the people involved in the meeting, and any one person's portable calendar probably does not contain all of this information. Consequently, there must be, in the background, some general-purpose machine or network of machines that coordinates the activities of all these specialized tools. However, as users, we need not know how this network operates any more than we need to know how the electric motor in our washing machine works: these devices are used only indirectly, in the guise of specific activities.
• It is almost certain that the portable calendar does not have the processing capacity to plan meeting times. This is a task for a larger machine with more powerful capabilities, so again the link between the portable device and some other machine becomes important.
• The link between the calendar and the larger system need not be present all the time, as the calendar system is meant to be portable. Users should be able to make notes in their calendars and then take the calendar back to their offices, where their notes are sent to the central system that handles the planning of the meetings.

Of course, people need more than calendars: they also need spreadsheets, plotters, and writing tools. We believe that these capabilities should be made available in devices that, like our calendar, are specialized to their own purposes. By summing over a number of specialized devices, users should end up with more capabilities than now, not less. Basing the computational environment on more than one device requires that these different systems be able to communicate with each other and exchange information. We believe that the support for the task is best done through specialized tools, that the need to do different tasks at different times is best handled by different systems specialized for these tasks. The inter-device communication aspect of this problem needs to be addressed, but there are many ways in which this can be done, only one of which is the current approach of basing all the applications in a single, general-purpose computer.

One of the major benefits of specialization is to allow designers to place significant constraints on the system's interface. Specialized interfaces can provide direct links between the actions that users want to carry out in the task and in the interface. The interface to a calendar system will be carefully tuned to the needs of people working with calendars, and will probably be quite different than the interface to a mail system or a spreadsheet. However, these systems would not suffer from the problems characteristic of inconsistent interfaces, because the semantics of the tasks provide the major constraints on their interactions: the appropriate ways of working with these systems follow from the tasks.

Of course, there are operations that are, at some level of abstraction, common to many applications. One deletes characters in a text editor, messages in a mail system, and files in a file system. There are also common operations across some of these applications: one will type, and thus need to delete characters, in almost any application. Some standardization of commands across applications will be necessary to insure that these similar operations are performed by similar actions.

Extending and customizing the system

Most of the problems with a specialized approach to interfaces lie in the area of customizations and extensions. Specialized tools work well only if the needs and requirements of users are anticipated properly. General-purpose systems have the advantage that they can be used for purposes not anticipated by the designer. Specializing the devices might eliminate the possibility of such novel uses, thereby unnecessarily limiting the power of the system.

We think this problem can be solved. Today's approach to customization and extension is to provide hooks into the internals of the system, or to provide access to general-purpose programming languages, as in the internal Lisp of the Emacs text editor or the shell programming of UNIX. But these certainly are not the only alternatives. What users of a specialized application really need is the ability to extend that application in ways relevant to the task. Within the context of a specific task, these extensions might be less than the full capabilities of a general-purpose programming environment. Thus, for instance, the Scribe document formatting language makes it easy to customize the appearance of documents, but this is done in a way that stops considerably short of dropping the user into a full-featured programming environment. We are not arguing that customizations or extensions should not be made, but only that they should be made in terms of the task, where the semantics of the domain can guide their use, and not in terms of general-purpose, abstract programming languages.

Limitations on the desirability of specialization

This paper is an exercise in advocacy: we have taken a strong position in favor of specialization, with the intent of pushing it as far as we could. From a calmer perspective, however, it is clear that there are some problems with this position, and we should acknowledge them.

One problem with specialization is that, if the functionality of a general system is divided into several specialized devices, one loses functionality if a particular device is not present: If your spreadsheet machine is not with you, then you lose the ability to do spreadsheets. In contrast, with a general-purpose system, you can call up any of the programs that are available on that system, including the spreadsheet. Even if the interfaces to these generalized systems are not as good as what might be available on a more specialized system, access to a wide range of functionality is always available.

This example is one in which the user's need for generality is itself the most important aspect of the tool. People who travel a great deal, or who use certain applications only casually might be willing to trade off some of the efficiency and power that can come from multiple specialized devices for the knowledge that, with a generalized device, they would be able to do almost anything they wanted to do. Other examples of the need for arise from considerations of the task. A highly-specialized, full-featured spreadsheet would be most appropriate when the user's task is to "analyze financial information". If, however, the task is the higher-level one of "preparing business reports", then the most appropriate tool might be a more general tool that is some combination of a word processor, spreadsheet, and data plotting system. Here, the extremely tight integration of these capabilities is critical, and extreme power and flexibility in the individual tools can be sacrificed in exchange for this integration. Of course, we may still be right here — such a system could be thought of as still another form of specialization, with the only question being the level of granularity at which the specialization has taken place.

We have little argument with these positions. There is surely a role for general computer systems in the world. Our argument in this paper has been that the supposed need for generality has led to sacrifices in the ease of use and power of computer systems — that the needs of the task have not driven the design of these systems. In the cases above, the needs of the task and the user are dominating the design of the systems, which is all that we arguing for. We simply don't want to see generality-induced limitations arising in places where the advantages of generality are not really needed.

Summary

We argue that current computer systems are weak because of the attempt to handle a large number of quite different applications with the same, general set of input-output devices and interface techniques. These limitations lead to a lowest common denominator approach to interface design, where interfaces are driven by the technology that is available and common to a large number of very diverse applications. This leads a designer to approach the problem of developing a new application from the perspective of "How can I make a computer behave like this application?"

We propose exactly the opposite approach. Start instead with the application — the address book, the calendar, the drafting board — and ask "How can I enhance this application by using a computer? The intent is to preserve the functions that have evolved over many years, while augmenting them with the kinds of information, knowledge, and communication processing at which computers excel. The task requirements dominate. This requires that we pay careful attention to the communication systems that would allow these devices to share their information, and to the support systems that are responsible for integrating and manipulating that information. By doing so, we believe that the resulting collection of devices and computing environments can offer their users levels of power and ease of use that present-day, more general systems deny them.