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
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
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.
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.
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
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.
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
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
The Application Model: Parts
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.
|Figure 1: A general Visi On applications model |
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.
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.
|Figure 2: The function-action cycle |
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
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
|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.
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
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.