Reprinted from Byte, issue 7/1983, pp. 166-182.

Visi On belongs to a new breed of office automation software that makes it possible for diverse application programs to interact. Instead of switching from one application program to the next, users can run several programs simultaneously and transfer data directly between them. Initially, Visi On’s open-ended system will accommodate spreadsheet, word processing, plotting, data manipulation, and communications software. Because it makes use of windows to implement the “desktop metaphor,” Visi On appeals to a wide variety of business users. (See A Guided Tour of Visi On, June BYTE, page 256, for a more detailed description.)

As system architects of Visi On, the major challenge we faced was to design a user interface that integrates varied applications and hides their differences while maintaining their power and potential to work together. After discussing the philosophy behind Visi On’s design, we’ll take a look at the factors that shaped it and how our design team met its challenge.

Project Goals

Visicorp’s Visi On project is an effort to produce an efficient and businesslike office-automation product using the most appropriate software and hardware technology. The first release, scheduled for late summer, is for machines in the same class as the IBM Personal Computer – those with bit-mapped displays, a Winchester hard disk, and at least 256K bytes of memory.

Our primary goal was to produce a nonintrusive problem-solving support system for the office professional: a workbench and tools that do the job without getting in the way. We wanted to design a system that integrates application packages by making data interchange simple and provides the appearance of concurrent application execution. We wanted it to be easy for a novice, casual user, or experienced user to learn. Finally, we wanted the system to be able to accommodate new and unanticipated applications.

Design Factors

Two major factors shaped Visi On’s design: the needs of the end user we had in mind and relevant available technology.

The market for Visi On is primarily office professionals, a varied group that includes middle and upper managers in large businesses, small businessmen, staff analysts, and planners. Time, pressure, and the need for quality results are critical to this group.

To be productive, efficient, and successful at their work, office professionals look for an office-automation product that fills three major needs. First, the product must help solve problems quickly without getting in the way. Second, it must enable users to gain expertise easily and make allowances for different levels of facility. Office professionals are casual users who may be experts in some parts of the system and novices in others. They are neither computerphiles nor touch-typists. Finally, the product must support different styles of problem solving. People vary widely in the way they solve problems; some may carefully plan and execute an attack, while others will indulge in a series of skirmishes until the problem is solved.

After identifying our target audience, we considered three communication concepts: representation, direction, and presentation.

Representation

A well-chosen and consistently applied metaphor is a key to successful interface design. By mirroring the behavior of systems that are already familiar to the user, a valid metaphor enables the user to correctly anticipate the operation of the system. Because the Visi On system must support concurrent operation of applications that manipulate objects familiar to the office scene, the interface design is based on the desktop metaphor. This representation identifies the user’s desk with the screen and, correspondingly, objects that might appear on the desk with objects on the screen.

Direction

The way in which the user directs the system should complement the metaphor and the user. Because the user is assumed to be casual and not a touch-typist, the design emphasizes recognition rather than recall. Thus menu selection was favored over command entry and pointing over keystroking.

Presentation

For the desktop metaphor to work effectively, users must have the feeling that the electronic objects are real. In other words, when objects are manipulated, they must behave in a manner analogous to the behavior of their physical counterparts. Part of this mimicry calls for the use of raster graphics in order to maintain objects lying about the screen.

The Design

Having defined our project goals and identified the audience and the technology available, we developed and carefully considered at least four contending design models. These included a Smalltalk-like model (object oriented, multiwindow), a Star-like model incorporating the desktop metaphor, an overlapped 4-window model, and an overlapped 2-window model. Because these models did not meet the project goals, they yielded to the current design, which is a variant of the desktop metaphor.

The Visi On design is menu driven, uses a mouse to select commands and some arguments, uses a verb-object rather than object-verb syntax (“delete text” rather than “text delete”), and supports a variable number of applications communicating with the user through individual, possibly overlapping windows. Because the design focuses on applications running in windows, the interface is application oriented as opposed to object oriented. Thus the objects on the user’s desk are applications operating on spreadsheets, documents, graphics, and the like, rather than the spreadsheets, documents, or graphs themselves. (The underlying system design, however, is object oriented.)

We rejected the Smalltalk and Star-like interface models primarily because they were object-oriented designs that made heavy use of icons. While both of these approaches have many desirable properties, our need to provide an environment that would allow fast and easy introduction of new applications and the relatively limited resolution of the targeted class of machines argued against their use. Whether the business market will accept icons is also unclear.

Our choice of a verb-object rather than object-verb syntax was based on the (unsubstantiated) hypothesis that users verbalize in this fashion (“fire Phil” rather than “Phil fire”) and consequently would tend to find it more natural. The marketplace will ultimately determine which, if either, is preferable.

We rejected the 2- and 4-window models, while conceptually simple, because they severely restricted the number of applications users could concurrently manipulate.

Two Important Design Concepts

The conceptual framework supporting the Visi On interface is the result of sifting and synthesizing ideas from many sources. Two areas in particular, application structuring and the help network, illustrate the thinking behind the interface.

The Visi On system and applications together must help novices and expert users alike. How should the behavior of individual applications be structured to support both groups?

Application behavior is what users experience when they interact with an application. Does it act predictably? Is the user in control? Is it clear what to do next? The correct answers to these and similar questions determine the effectiveness of the application as a tool in the user’s hands. The behavior of an application mirrors its internal structure, so application structure is important in determining behavior.

One goal of systematizing the structure of an application is to provide similar behavior in similar circumstances, to give the user a sense of familiarity. All menus, for example, look similar and work the same way. Another goal is to break the application into comprehensible pieces that are closely related to the way a user attacks problems (that is where I do my editing, this is where I do my analysis, this is where I do my plotting). A third is to provide a framework in which to state uniform interface guidelines.

By designing applications and their parts to look and feel alike and by breaking them into digestible pieces, it takes less effort for a new user to learn an application and less time for a semi-experienced user to add another application to his repertoire. Moreover, the casual user obtains reinforcement applicable to all applications each time he uses any one.

The Application Model: Parts

Figure 1: A general Visi On applications model

We used the application model illustrated in figure 1 to provide a conceptual framework for dealing with application behavior. In this model, an application consists of contents (spreadsheet, graph, document, and so on), characteristic views of contents (one aspect of total screen appearance), and functions that the user can invoke to change the contents or the way they are viewed. A spreadsheet application would be modeled as follows: the contents would consist of one or more spreadsheets, the characteristic views would be windows onto the sheets, and the functions would include content manipulators such as Insert Row, Recalculate, and Enter Formula and view manipulators such as Scroll and Freeze Border.

The Application Model: Places

From the user’s point of view, an application is a tool that helps solve a class of problems by providing a specific capability. This capability often breaks naturally into several subcapabilities that suggest a top-level structure for the application. For example, a stand-alone application like the Visitrend/plot program might be described as helping a user to solve graphical problems. Generally, solving these problems requires that the user be able to manage, edit, plot, and analyze data. This suggests what the application structure should be.

The application model captures subcapabilities by using the concept of places. Each place is a group of functions with its own characteristic display. At present, functions are organized into a static hierarchy and if properly constructed should satisfy these requirements:

	The user, even the first-time user, should intuitively know the kinds of things that can be done at a given place. If the place supports editing, the user should expect something like an Insert function and should not be surprised to discover a Delete function.
	Equally important, the user should intuitively know what cannot be done at a place and where the place is to do it.
	Because a place corresponds to a major step in the solution of a problem, the user should not need to shift frequently from place to place. If shifting is required, the place is not well conceived and should be reformulated because such shifting distracts the user from the problem being solved.
	Places should have associated characteristic displays so that the user always knows his location.

Places are organized into a small, static hierarchy and are named to reflect that. This aids the user in navigating in search of subproblem support not available at the current place.

Movement from place to place is always the result of an explicit user request. This provides a feeling of stability and predictability.

A place provides a palette of functions for the user and remains in a neutral state until he chooses one or moves to another place. While in the neutral state, the place exhibits neutral-state behavior. Neutral-state behavior is generally application and place dependent but will usually involve direct manipulation of the contents through the characteristic display. For example, in a word processor, neutral-state behavior would support repositioning the character cursor with the mouse and typing into the document.

Figure 2: The function-action cycle

All functions have a predictable behavior called the function-action cycle (see figure 2). Stereotyping function behavior provides a framework for specifying when and where user feedback is supplied. The function-action cycle begins when the user picks a function, providing zero or more arguments and an execution phase in which the requested function is performed. Function-action cycles always terminate in the neutral state.

Applications implement the argument-solicitation phase by using a small number of canned I/O (input/output) primitives called BITS (basic interaction techniques). This is one of the mechanisms employed to achieve uniform behavior. BITS support such things as multiple choice, line editing, and using the mouse to select objects.

The function-action cycle models reactive behavior. The application idles in the neutral state, waiting for the user to decide on a course of action, and then reacts in a predictable manner by jogging his memory for necessary actions (prompting), informing him of the continuing state of affairs (status), acknowledging his actions (sound and selection feedback), producing what was expected (status) or informing him why the result could not be produced, and ideally suggesting corrective action (error messages).

Guiding the User

The system must accommodate users who are not quite sure what to do next as well as those who have reached an impasse.

Users need help when they don’t understand some aspect of the system or application. They may be confused about the capabilities of an application, unclear prompts or error messages, or how to accomplish a particular task.

The Visi On system provides an extensive help network of individual frames linked together in such a way that any frame can be reached by following some sequence of interconnecting links. The more links that must be traversed, the farther apart the frames. Related frames are “near” in this sense; loosely related frames are farther apart. The Visi On help system interface provides a natural means of moving from frame to frame.

A user requests help by choosing HELP in the global menu and then pointing with the mouse at the object that needs to be explained. The object may be a menu choice in some application, an error message, a portion of a display, or anything on the screen that may require explanation.

The help system responds by opening a new help window and displaying the appropriate help frame. Once the window is open, the user is free to traverse the help network by picking commands in the help window’s menu or cross-references that may be embedded in the help text itself. Help windows behave just as any other application in the system and thus may be reframed, closed, or opened completely to fill the entire screen. Useful frames may be placed off to the side for frequent reference, tucked away for future reference by closing, or deleted.

The help network mechanism is so general that it is quite possible to design networks that hinder rather than help the user. To design an effective network, it is important to understand the various conditions that prompt users to solicit help.

The user who solicits help is generally in trouble. Thus help is a necessary distraction that will be tolerated to a greater or lesser degree depending on the nature of the problem the user is solving. If the problem is “getting to know the system better,” a spare-time activity, perhaps, the user will be willing to interact extensively with the help facility. On the other hand, if the problem is “getting the report out in the next half hour,” the user’s tolerance for help distractions will be low. In the first example, the user is essentially nondirected, a browser with no specific goal. In the second, he has a very specific goal.

Browsers do not have a sense of urgency and are willing to travel around the help system as their interests dictate. They require overview frames to orient themselves and detail frames to dig deeper into interesting areas, and they frequently use glossaries and references to indirectly related help materials.

Goal-directed users, in contrast, do have a sense of urgency, perhaps made acute by a deadline. They are put off by verbosity, involved non-focused traveling, and expositions that don’t seem to be leading them quickly to a better understanding of how to use the system to solve a problem.

The design and organization of help frames depend upon whether a user is browsing or in hot pursuit of a solution to a specific problem. To the extent that designers can anticipate this, the network may be tailored. An individual help frame catering to a browser might be almost tutorial in nature and look like a page out of a manual. Such a frame would be text intensive and have little white space. A frame supporting a directed user will look more like a viewgraph, with ample white space and a regular layout.

Goal-directed users enter a help frame thinking of their problem in terms of solution steps natural to them. They should emerge with potentially relevant actions directly supported by the application. These help frames serve to translate user subproblems into application actions. This implies that the frame should allow the user to quickly answer the following questions:

	Ballpark: Is this frame relevant? (Am I wasting my time reading it?)
	Target: Assuming it’s relevant, where is the information I need?
	Action: Assuming I’ve found the information, what do I do next?

Assuming that users read text from left to right and top to bottom but can quickly scan text vertically if it is organized in a regular, visually predictable manner, we are led to frames that have a tabular layout. This layout presents user concepts vertically on the left in frequency-of-use priority (if that is known or applicable) so that users can quickly answer the targetting question. Corresponding actions or further helps appear on the right, allowing the user to answer the action question. The purpose of the frame should be explicitly stated so that the user may quickly answer the ballpark question.

Conclusion

The concepts and structures underlying the Visi On interface are a synthesis of ideas from many sources, some theoretical, some applied, some tested, some previously untried. There are few proven methods in this technology, for this audience, and with our express goals. Based on our research and tests with sample users, we believe that Visi On will be all that we set out to achieve. The real test, though, will be in the marketplace with end users who are looking for a practical tool that gets the job done without getting in the way. We await their verdict.

by Dr. George Woodmansee

About the Author

Dr. Woodmansee is a staff engineer at Visicorp Inc. (2895 Zanker Rd., San Jose, CA 95134). He is responsible for the development and application of applied human-engineering technology.