University of California, Santa Cruz
The Design of a User Interface for an
Interactive Simulation Environment
A thesis submitted in partial satisfaction of the requirements
for the degree of
Master of Science
in
Computer and Information Sciences
by
James Rodden
June 1996
Abstract
In this paper, I describe the process and rationale behind my design for
a new human-computer interaction model and associated interface for Simlab---a
tool for performing simulations of mathematically based systems. I believe
that this new design, once fully implemented, will bring together the flexibility
and expressiveness found in traditional programmatic simulation systems
along with the highly interactive and experimental capabilities found in
several pre-packaged simulators.
Keywords: user centered design, user interface, discrete time based
simulation environment, Simlab
Acknowledgments
Thank you to my family, friends, and project partner for all your love,
support and encouragement.
The most important social evolution within the computing professions
would be to create a role for the software designer as a champion of the
user experience...What is design? ...It's where you stand with a foot in
two worlds---the world of technology and the world of people and human purposes---and
you try to bring the two together.
- --- Mitchell Kapor
Software design is the act of determining the user's experience with a piece
of software. It has nothing to do with how the code works inside, or how
big or small the code it. The designer's task is to specify completely
and unambiguously the user's whole experience....The most important thing
to design properly is the user's conceptual model. Everything else should
be subordinated to making that model clear, obvious, and substantial. That
is almost exactly the opposite of how most software is designed.
- --- David Liddle
This paper is also available in PostScript.
Introduction
After a brief description of Simlab's conceptual foundations and development
history, I will compare its capabilities with those of other popular simulation
tools and analyze its functional architecture from a usability standpoint.
The remainder of this paper contains a summary of the interface design process
and resulting user interface. The analysis stages of the work presented
here represents a cooperative effort between myself and Gil Fuchs, a former
instructor of a course in which Simlab is used.
Motivation
My original motivation for participating in the Simlab project was simply to
gain Macintosh programming experience, however I soon came to realize that
Simlab's underlying architecture makes it inherently superior to many other
simulation tools. While other tools tend to emphasize one aspect of computer
modeling --- either system definition or experimentation --- disproportionately
over another, Simlab allows for a high degree of experimentation without
sacrificing its ability to describe complex systems very clearly. The only
major limitation to Simlab's realization of this potential is in the creaky
and hobbled user interface placed upon an otherwise robust package. I decided
to remedy this situation by defining an interface worthy of such a sound
theoretical and experimental foundation.
Simlab Description
Simlab is a discrete time based simulation environment used to model physical
systems via systems of difference equations. It has been used for many years
as the principal instructional tool in an undergraduate introductory computer
science course at the University of California, Santa Cruz. Simlab has its
own language for describing systems to be modeled, known as Model
Description Language (MDL). The resulting modeling and simulation capabilities
provide a great depth of expressiveness based largely on the simplicity of
the underlying programming model.
At the core of Simlab's functionality is the Model Description Language---a
lexically scoped, imperative simulation language that
incorporates several elements from many of the major programming languages of
the last fifty years. Foremost, it is a language for defining models using
Systems Analysis Theory. The basic paradigm is that of a discrete time
simulation. The only flow of control is an implicit cycle of execution in
which all statements theoretically occur simultaneously. This provides the
essence of discrete time simulations---each value within the system is
defined in terms of previous time steps and an initial state.
Although the essence of the Model Description Language is embodied by its
implicit time step, another
noteworthy feature is its support for modular abstraction. Referred to as
submodels and most like ANSI C's file scoping mechanism, MDL's data and
behavioral abstraction units also contain elements of other languages such as
Simula-67, ANSI C, C++, Modula-2 and Ada [Fuchs, Rodden]. Certain traits of the submodel's
implementation are revealed along with the interface definition, however
interactions with a submodel must strictly comply with its interface. A
submodel can range from a small set of operations encapsulated for
convenience to a fully operational and logically complete model in itself. In
fact, a submodel is defined to be an otherwise standard model with a few
constraints placed upon its input and output operations. Although never fully
exploited, this means that submodels could be executed completely independent
of the containing model; all that is necessary is the input/output
interactions synchronized by time step.
The remainder of the Simlab system is that of a translator that either
interprets or compiles Model Definition Language definitions into a form
suitable for execution
within a runtime environment. The runtime environment exposes for
manipulation and observation the values of the model's inputs, outputs,
constants, and state variables as set forth in the MDL definition. The
human-computer interface for controlling this runtime environment is the
primary focus of this paper.
Background
As mentioned above, this work is only the latest in a long history of
improvements to Simlab, and Simlab is far from the only tool available for
running model simulations. For the sake of completeness of presentation and
understanding, I shall present a brief history of the tool and place it in
context with other simulation tools.
Simlab History
Simlab was originally developed in the early 1980's as an outgrowth of the
introductory computer science course Systems and Simulations at the
University of California, Santa Cruz. At the time, the coursework for the
class involved programming computer simulations of physical systems using
third generation languages such as C and Pascal. As a result, students often
spent much of their time concentrating on techniques for developing time
based simulations, storing data structures, and related low-level programming
issues that aren't directly related to systems modeling itself. In an attempt
to relieve students of the burden of rediscovering various means of
simulating time in their projects, and to allow them to concentrate on the
concepts related to simulations of system models, Dr. Roger Wellington-Oguri
developed Model Description Language (MDL) under the supervision of Professor
R. Michael Tanner. Simlab was designed to be a companion runtime simulation
environment for MDL's compiled, intermediate, or "virtual machine"
executable models.
Although MDL and Simlab were designed for use on Unix systems and centered
around a command line user interface, both were ported to the Macintosh
shortly after its introduction and a new, more graphical user interface was
created. Both versions have undergone several revisions, but the Macintosh
version has survived and is still used by the same undergraduate course.
However, due to its multitude of revisions and numerous contributors---record
of which has been reduced to a mere list of project participants---Simlab has
grown weak and difficult to engineer.
In early 1993, as an undergraduate under the supervision of Professor Charlie
McDowell, I first began my work on Simlab by upgrading it to be compatible
with the most recent version of the Macintosh operating system, now known as
the Mac OS, System 7. Independently in early 1994, as I began my research on
redesigning Simlab, Paul Ausbeck, another UCSC graduate student, rewrote the
MDL compiler to generate standard ANSI C source code.
Existing Systems
Reflecting the breadth of application, computer-based modeling systems serve
many purposes and exist in many forms. Available simulation tools can be
grouped into two general categories: general purpose and domain specific.
General Purpose Simulators
General purpose simulation tools are those in which specific simulations must
be programmed into the system, and the nature of such simulations is not
limited to any single domain or discipline. They are most widely used in
education and research and offer a spectrum of expressiveness, flexibility,
and programming style. Simlab lies fairly evenly in the middle of this
spectrum.
SimScript
Created in the era in which FORTRAN was the only high level programming
language, SimScript is probably the oldest of all simulation tools, and the
first simulation specific language. Its relationship to FORTRAN is very
evident in its syntax and structure. Although there is now support for modern
debuggers and graphical tools, SimScript is a programming language, not a data
analysis or experimentation tool. Aside from debuggers and an iterative
development strategy, SimScript does not provide support for exploration of,
or experimentation with developed models. This system is also geared more
toward simulations of real-world systems, such as the dynamics of customer
lines in a grocery store or network traffic, for which the underlying
mathematical relationships between simulation elements are not known
before-hand [CACI, Fuchs].
Stella
The closest in applicable domain space to Simlab, Stella offers a high-level,
direct manipulation, graphical programming language for describing systems to
be modeled. Although this language utilizes many of the same constructs and
notations as Model Description Language, they are entirely graphical and
highly notational. The user
must be fully versed in the notation used in Stella and be nearly capable of
programming an entire simulation before even simple experimentation with a
pre-programmed model is possible. In contrast, Simlab allows a much more
gradual learning curve for new users because the programming language can be
entirely ignored until it is needed. This is also an advantage for more
experienced users of Simlab who only want to experiment with a model without
concentrating on its inner workings [HPS, Fuchs].
KidSim (Cocoa)
Aimed at young children, KidSim's emphasis is on teaching the most basic
fundamentals of rule oriented simulations. In fact, there is essentially no
programming language for this tool. Instead simulations are "programmed" by
demonstrating discrete behaviors to the system. Once the method of
"teaching" behaviors is fully understood, it quickly becomes quite
cumbersome and anything more than trivial simulations seem extremely
unwieldy [Cypher].
Domain-Specific Simulators
This category contains tools designed for specific types of simulations---for
instance, simulating Newtonian physics, computer circuitry, structural
dynamics, an ecosystem, or the federal budget. Such simulators are typically
programmed in either a high level language such as SimScript, C, or
SmallTalk, or a so-called Fourth Generation Language such as a spreadsheet
macro language or a scripting language. These simulators make up the bulk of
commercial and a significant portion of research applications of
computer-based modeling. As the category name implies, domain specific
simulators cannot be used in anything other than their target domain.
Comparison to Simlab
Because Simlab consists of both a simulation environment and a programming
language, it provides an elegant combination of the best features of the
generalized simulation tools. Without losing the expressiveness, flexibility,
and ease of learning present in a dedicated programming language, Simlab
enables the same degree of high-level observation and iterative
experimentation found in Stella and KidSim. In fact, Simlab goes even further
by facilitating varying levels of observational granularity that allow the
user to pay attention to as much or little detail as desired. These latter
benefits are principally enabled by the interface to the runtime environment.
Simlab Simulation System
Although previous Simlab documentation tends to use the term "Simlab" to
refer to the actual simulation engine, I prefer to view the tool as a system
itself. The pieces of this system are essentially the same as those used in
an Integrated Development Environment (IDE) to support the edit-compile-execute
cycle of software development. This similarity is due to the fact
that the process of developing and running a model simulation is also
essentially identical to that supported by such development environments.
Component Descriptions
The pieces of the Simlab System are:
- An Editor ---
A modified text editor for entering the Model Description Language code
representing a physical or mathematical system. Possible modifications
include syntax coloring and checking, support for different views or
representations (possibly graphical) of the source code, aides to
modularization, and integration with source code control systems for large
modeling projects.
- A Compiler ---
The notion of a discrete compiler is largely a remnant of
both the original incarnations of Simlab and the heritage of computer systems
in general. Dynamic compilation performed by a compiler that is largely
transparent to end users is vastly superior to one that must be explicitly
invoked each time a change is made to a model's source code. Even in
so-called "dynamic languages," however, there is still a static compiler
lurking somewhere in the background.
- The Runtime Environment (Simulation Engine) ---
The runtime, or simulation, environment is actually composed of two parts: a
simulation engine and the user interface for controlling and monitoring a
running simulation. While the form of the engine portion, and even its very
existence, is dictated by or equivalent to the nature of the compiler and its
target, the user interface to a running simulation is distinct. This
controller interface was the focus of the design effort.
Inter-Component Communication
In order to be an effective Integrated Development Environment, each of the
components outlined above must
communicate with one another and at least appear to act as a single unit. The
basic cycle of communication is as follows:
- The editor invokes the compiler (upon user command) and the compiler returns a
status result indicating success or failure along with relevant error or
warning messages to the user.
- If the compilation was successful, the runtime environment is started and the
executable model is loaded. The user is presented with the simulation
interface and proceeds with exercising the simulation.
- At any point, the user may return to the editor to revise or simply view the
Model Description Language source. If revisions are made, the compiler must be invoked (and the
simulation stopped) before any changes are reflected in the executable
simulation.
User Interface Design
The primary intent of this project was to completely overhaul the user
interface in such a way that it concisely conveyed the various aspects of
modeling and simulation, yet remained scalable to a wide variety of user
levels. The human-computer interface can make the difference between an
application that seamlessly integrates with the user's thoughts and actions,
and one which hopelessly obscures the tasks being performed behind layers of
complexity [Borenstein, Heckel, Laurel, Winograd, Wurman]. The following sections describe the goals, methodology, and
results of this project.
Design Goals & Considerations
Before any specific design work or prototyping was done, Gil Fuchs and I
agreed upon some very general long range goals in order to generate a
framework from which we could proceed. These high-level goals then acted as a
basis for discussing how Simlab might be used and what each user would want
and/or expect from the system. At the same time, the goals enabled us to
identify and label certain implementation oriented design considerations as
out-of-bounds for our discussions, essentially deferring them until the
design is ready to be fully implemented.
From the onset, cross platform portability was high on the list of design
goals, if for no other reason than to allow the widest possible distribution
and usage of the new tool. Most importantly though, multiple platform
distribution provides a means of addressing different audiences and needs in
terms of performance---as an educational tool or as a research tool. Given
that most platforms now have fairly extensive, and fairly similar graphical
user interfaces (GUIs) available in one form or another, we decided not to
seek a lowest common denominator approach.
Another, slightly more ambiguous form of portability arose from the notion of
producing executable model simulations---artifacts of the model development
process. Should these models be data files used by a simulator or stand-alone
(executable) application units? The former implies multiple runtime
environments for each target platform while the latter brings up the specter
of choosing a single microprocessor or set of microprocessors as the target
of compilation. Simlab originally dealt with this issue by utilizing a
virtual machine optimized for discrete time step simulations (the former
idea) with a controller interface targeted to a single platform. Paul Ausbeck
addressed this issue in his work by choosing the second option. Although not
immediately identifiable as an interface design concern, the nature of each
simulation is an aspect of the conceptual model presented to the user. Debate
over the merits and demerits of each approach plagued the design process
throughout the project's lifetime and this issue is still unresolved.
Above all, I wanted the interface to scale to a wide range of typical users
and a variety of usage patterns. I viewed each user as an intersection of two
mostly orthogonal scales. Those scales are that of general computer literacy,
and familiarity with discrete time based simulations and computer modeling.
Interface scalability is most easily achieved by taking advantage of each
user's prior knowledge in a related domain [Borenstein, Card, Heckel, D.Norman, Wurman].
This meant that each interface
element must directly relate to something representative of the experience
level expected of the user. In cases where the user is new to a particular
domain, this means introducing such knowledge. For instance, model
programming is representative of general computer programming and requires
that the user is ready to learn or already holds such skills, so metaphors
from the programming domain may be used where model design and debugging are
concerned. Alternatively, experimentation with a pre-programmed model
represents general "browsing" through computer systems, therefore only
generalized "browsing" metaphors may be used (scrolling lists, text-edit
fields, slider controls, etc.).
The synthesis of developing and experimenting with a simulation should be
very seamless and rapid in order to encourage a high level of exploration.
The development process should be as tightly integrated with run-time usage,
or experimentation, as possible in order to allow iterative and dynamic
development. Aside from an edit-run cycle, there should be no separation of
development modes in the user experience [Apple].
Human-Computer Interaction (HCI) Goals
In many ways, the overall HCI goal of this project was to develop a new
paradigm for computer simulations. At the beginning of the design stages I
briefly examined other systems for simulating mathematical models; two were
most pertinent---SimScript and Stella---and neither embodied all the elements
that make up Simlab's user model. Elements of programming, scientific
visualization, real-time systems, and data analysis are all part of the
conceptual model to be presented. Each facet has its own set of challenges
and demands. Accommodating them all was extremely difficult.
Some of the concrete user interface design goals were:
- Reduce or eliminate modality(1).
The original Macintosh interface made heavy use
of modal dialogs for collecting information with no distinction between
static, dynamic, or real-time information. During experimentation, a running
simulation had to be stopped and a modal dialog brought up in order to change
any of the model's constants. To the extent that modality can be eliminated,
human-computer interaction becomes a conversation in which user actions are
given immediate feedback upon which further actions can be based [Brennan, Borenstein, Heckel].
- Allow for a highly fluid mapping between each of the inputs to a simulation
and the corresponding output effects. Simulation parameters (constants)
should be easily manipulatable as the model is being simulated and the
effects of those changes immediately visible in the model outputs. This too
raises the interaction between the system and its user to the level of a
conversation [Tognazinni].
- Convey the notion of a simulation as a "black box" with external "knobs and
switches" (input variables, setup variables, and simulation parameters) yet
still allow the "lid" on the box to be removed so each model can be viewed
as a "white" or "transparent" box if desired.
- Support richer analysis by allowing varied views of model data and
frequent modifications to those views. The original Simlab contained very
effective x-y graphs of a model's outputs, however the graphs were cumbersome
to set up and very static.
Methodology
The methodology employed was based upon practices commonly used in similar
interface design projects [Bewley, Borenstein, Heckel, Johnson, Rettig, Smith, Winograd].
Detailed analysis of user tasks were used to guide
all aspects of prototyping, analysis, and user testing of interface elements.
Usage Scenarios
A standard design exercise when creating and evaluating the effectiveness of
an interface is that of a usage scenario. This is done by imagining a user or
category of users with as much detail as possible about their preconceptions,
needs, and goals when using a particular tool or technology and trying to see
how such users might interact with the tool or technology being evaluated.
The advantage of centering discussions around usage scenarios is that you can
examine how the tool will work within the context of typical applications.
The prospective audiences for the new version of Simlab include users with a
wide spectrum of computer experience and systems modeling literacy. End users
will be expected to be reasonably computer literate, however much of this
requirement can be satisfied by basic Macintosh literacy and awareness of
built-in help facilities. Due to the large intended audience, the goal for
this project was to develop a user interface that presents a unified user
model that is both scalable to various experience levels and provides
adequate depth of conceptual expressiveness to all users. I used the
following three scenarios to represent the range of projected Simlab users
and their needs:
Exploration
This scenario covers the majority of users who are new to computers or
computer modeling, or even just Simlab itself as a new simulation tool. The
naive user end of the exploration stage is exemplified by the average student
in the Systems and Simulation undergraduate course at the University of
California, Santa Cruz. The first couple of
assignments in the course are also typical of the types of tasks this
category of user is interested in accomplishing---gaining familiarity with
the simulation environment in particular, and simulations in general.
Initially, the user must learn about the mechanics of controlling a
simulation, input/output values and their interactions before proceeding to
more advanced concepts. As the user gains more experience and knowledge, s/he
will want to use one (or more) of several pre-written models that demonstrate
certain key simulation concepts such as state values, feedback loops,
dependent and independent variables, and the notion of stability or
instability inherent in a model and its input and constant values.
At this stage, the primary means available to a user for learning how to
operate a new tool is his or her prior knowledge of both computer based and
non-computer based tools [Card, Gaver, D.Norman]. This means that the interface must leverage the
skills the user already has---not only in terms of other computer programs,
but also in terms of non-software tools such as radios and VCRs. One of the
major advantages of any standardized interface such as the "Windows, Icons,
Menus, Programs" (WIMP) interface is that it provides users and designers
alike a common pool of skills that can be mapped from one application to
another. By conforming to such a set of known interaction behaviors, the user
is encouraged to explore and experiment with the interface to see what
happens in response to various user actions [Gaver, Tognazinni]. New skills can then be derived
by observing these new behaviors [Card, Hutchins].
Another important aspect at this stage is the creation of a conceptual model
in the user's mind. Each interaction between the user and the interface will
shape the way the user thinks about the system and how to accomplish various
tasks [Borenstein, Heckel]. This is another area in which the user's prior skills and knowledge
play a significant role; careful selection and usage of real-world metaphors
can quickly and concisely convey a great deal of information to the user by
directly or indirectly mapping portions of the conceptual model of another
system onto the new one. The learning curve of any tool can be tremendously
flattened with the proper application of this technique.
Experimentation
The experimentation category of users runs the gamut of skill levels not
encompassed by the exploration stage described above. Users that fit into
this scenario understand the fundamentals of Systems Analysis Theory and at
least some of the more advanced concepts; the bulk of these users are either
formulating a full understanding of the advanced concepts or using those
concepts to explore all the dynamics of a specific model or group of models.
These users wish to make full use of Simlab's simulation capabilities and
want the interface to help them understand a given model itself rather than
the simulation process. However, the interface does not necessarily need to
become "transparent" to the user at this point, but can instead enhance the
user's work by anticipating his or her needs and participating in a fluid
conversation, or exchange of information [Brennan, Tognazinni]. Of course, this rapid feedback
requires a very high performance interface so that it does not become a
burden or obstacle between the user and his or her goal.
Model Development
Once a user has reached the experimentation stage of usage, s/he will
eventually want to develop his or her own models for simulation and
experimentation. At this point, the user will need to use Simlab's Model Description Language
programming and debugging facilities---the editor and compiler features
described above. This usage scenario is indirectly related to the
simulation environment interface because the simulation
environment itself is required for the model development process in the
testing/debugging stage. As an element of the compile-test-debug cycle, the
model developer's requirements for the runtime environment are the same as
those of an advanced user within the experimentation scenario.
Rapid Prototyping & Frequent Analysis
The two most important and powerful techniques used during the interface
design process were frequent iterations of rapid prototyping and frequent
analysis of the result of each iteration. This enabled us to discuss,
compare, and contrast different interface elements in concrete terms rather
than in abstract terms in which different mental interpretations and fading
memories might cloud our understanding. After each discussion, changes were
incorporated into drawings which led into the next discussion. Over time,
certain conceptual themes developed and we were able to identify and
concentrate on the aspects that were giving us the most trouble.
Each iteration typically consisted of running user-task case scenarios on the
latest interface elements and evaluating their effectiveness in terms of
conceptual clarity, expressiveness, efficiency of user actions, and relevance
to the user-task and underlying design goals. These case scenarios were done
from a variety of typical perspectives that varied in user skills,
understanding of the modeling concepts utilized, and educational or research
objectives of the user.
Many tools were used for constructing the prototypes but the most valuable
was a pixel-oriented paint program. Drawings of windows and menus were
examined on screen or printed out for convenience. As visual elements began
to solidify, high-level visually oriented scripting tools were used and some
lower-level implementations were created. At no point was any single tool
completely abandoned in an effort to "move-on." Every piece of the
interface was open to re-examination and re-design throughout the project.
User Testing
Once the design seemed to be converging into a single representation, we
performed a paper prototyping experiment as described in [Rettig]
with a typical end-user. Our sample user was an inexperienced
computer user who was currently taking the undergraduate course that centers
on Simlab and did not have difficulty with the modeling concepts presented in
the course. We purposely selected a user who did have prior experience with
both the Macintosh and the previous version of Simlab so that we could test
the improvements in efficiency, fluidity, and conceptual expressiveness
without having to worry about basic Macintosh literacy or any
misunderstandings of the underlying simulation concepts.
For the most part, the experiment successfully confirmed that the changes
dramatically improved the overall ease of use and clarified the conceptual
model present in both versions of Simlab. In fact, the user noted a better
understanding of the current implementation after experimenting with the
paper prototype. The biggest difficulty and frustration we experienced was an
inability to completely convey the visually dynamic aspects of the interface
upon which much of the design relies. This is an inherent limitation of the
paper prototyping technique---any highly visual, or dynamic interface element
cannot be fully exploited or understood by the user. For instance, popup
menus, scroll bar like widgets, and text edit fields can only be simulated
with paper drawings and verbal explanations to a certain extent. Just as it
is impossible to learn how to ride a bike without actually experiencing it
first-hand, such interface elements cannot be fully explained with static
pictures and words. For this reason, I decided that computer-based testing
would most likely yield more useful results.
Unfortunately, I lacked adequate tools for quickly developing computer-based
prototypes. The prototypes I was able to produce weren't flexible enough to
accommodate the rapid change required by the design process. For these
reasons, a user-testable implementation never fully materialized. This is a
chicken-and-egg problem indicative of the disparity between implementation
and design: implementation is too slow and static to keep up with design
changes thereby nullifying much of its usefulness until the design is solid,
however working prototypes are needed to fully express the dynamics of
complex interfaces.
We did, however, continue to informally present portions of the design to a
variety of typical users. Most importantly, we discussed aspects of the
design and solicited comments and feature requests from a group of
undergraduates who were using Simlab in a large independent study. The
difficulty we experienced in these encounters was that the users were so
overwhelmed by and anxious for the features we described that they could
hardly contain themselves and only offered encouragement for our ideas and
requested a completed version as soon as possible.
Design Summary
This section presents a brief visual history of the design process along with
a narrative of the associated design decisions. Of note is the fact that the
visual representation of a simulation and its controls is inexorably
intertwined with the underlying conceptual model presented to the user.
As shown in Figure 1, modal dialogs were prevalent in my
initial designs. This fact was largely a carry-over from the original
Macintosh interface---all state changes to the current model, or the graph
views of that model, were done through modal dialogs. Modality like this
breaks the natural flow of information exchange facilitated by graphical
interfaces and reflects a direct mapping of the state-machine modality of
command-line interfaces. For this reason I set out to move the presentation
and collection of information associated with each of these dialogs into the
forefront of the overall interface. This eventually led me to the notion of a "Model
Window" as shown in Figure 2 and described below.
Figure 1: Modal dialogs were prevalent in the first Macintosh
implementation and initially carried over to the new interface design. The
first three dialogs (Submodels, Model Settings, and Graphs) were superseded
by additions to the primary interface, however the notion of sub models had
many thorns attached.
Two of the dialogs shown in Figure 1 represent features new
to the simulation environment: explicit support for model/submodel
relationships, and model settings. The former proved to be very difficult to
represent and was never fully resolved, but the latter may end up becoming a
tremendous enhancement to the exploration and experimentation processes.
During experimentation the user frequently modifies model settings in order
to achieve different dynamics in the state and output variables such as
stable, chaotic, or terminal behavior. As this experimentation proceeds, and
especially when a model is being prepared for demonstration in the
exploration phase of Simlab usage, the user may want to save various
combinations of variable values in the form of named settings.
The Preferences dialog in Figure 1 shows a small improvement over
previous Simlab interfaces and highlights a significant shortcoming of those
designs. Previously, simulation execution followed a batch processing model
in which the simulation would run for a set number of time steps. The user
could control the number of time steps each execution cycle would cover, but
all changes to model parameters could only be made in between these batch
execution cycles. Once I realized that this assumption was built into not
only the implementation of the simulation engine, but also the entire
interface itself, I eliminated the batch processing model entirely and
moved to a continuously running/stopped model of
execution. Under this new paradigm, parameter values would be shared between
the interface and the simulation engine and changes to variables during
execution would have immediate effects upon the simulation. This change
provides a much greater level of fluidity of
both usage and understanding for users; fewer steps will be required to
change execution parameters and those changes will be immediately visible in
the running simulation.
Figure 2: Early designs for the Model Window. Files indicates
source code files for the current model and its sub models. Views lists
various (non-graph) representations of the current model. Graphs lists x-y
plots of selected data. On the right, RAM usage information was added.
Double-clicking an item from the list (read as a single column) would open a
window containing the selected information.
The "Model Window" shown in Figure 2 was inspired by the
"Project Window" found in many Integrated Development Environments (IDEs)
and serves two main purposes. First, it gives visual feedback to the user
that an executable model is loaded into the simulation engine and ready for
execution (or currently running). Second, it consolidates key properties of
the corresponding model into a single view that is always accessible, thereby
removing the need for presenting the information found in
Figure 1 as modal. The problem with this form of the Model
Window is that it only contains meta-information about the model and
therefore does not serve as a tangible metaphor for the model itself. Fixing
this shortcoming became a major focus of my efforts and is discussed further
below.
Figure 3: Minimal redesign was considered for the individual
graph windows because they were largely successful in the first Macintosh
implementation. This has been and is expected to be the primary focus of
users' attention. Only cosmetic and some navigational changes (for instance,
hyper-linking to the Graph Definition window, depicted below) are necessary
here.
The most effective piece of the previous Macintosh-based interface is the
graph views of the current simulation. These x-y plots, shown in
Figure 3 above, are most often the focus of user interest and
interaction. Any combination of a model's output variables can be placed on
each graph and the user is free to select the x-axis. Two especially nice
features of these graphs are that each variable can have its own scale for
the y-axis, so that each graph is actually a composite of overlaid graphs
that share a common x-axis, and the configuration of each graph---its x-axis,
constituent variables, and y-axis scales---are persistent across simulation
sessions. The independent y-axis scales allow each graph to be configured to
highlight a key relationship between variables or to simply focus in on the
most interesting part of the graph. The configuration persistence allows
these "interesting" parts of the graph to be stored for later examination
or used as examples during the exploration stage of use.
Figure 4: The Graph Definition window is a cross between a
settings window common to many graphical user interfaces and the "Get Info" window in the
Macintosh Finder. Aside from the graph windows themselves, the basic layout
of this window is the most significant surviving artifact of the original
Macintosh interface.
Due to the overall effectiveness and appropriateness of the graphs
themselves, very little design effort was geared toward them. However, there
is room for improvement in the way the graphs are created, managed, and
configured. Foremost, the only means of creating and configuring graphs was
through modal dialogs. As noted above, this breaks the natural exchange of
information between the user and the system, thereby blocking fluid "trains
of thought" for the user [Brennan]. For example, the only time the user is allowed to
attach a meaningful name to a graph is when it is first created---prior to
actually configuring its x-axis and constituent variables. The problem here
lies in the fact that it is through configuring and experimenting with the
graph that the user is most likely to come up with a descriptive title. Under
the previous interface, the user would have to create an entirely new graph
with the desired name and configure it to match the graph the user used for
experimentation. Conversely, by allowing the graph's title to be simply
another property that is no less configurable than any other property, just
as a file system allows you to rename a file, this barrier to free flowing
information, or conversation, between the user and the system is eliminated.
Further, the configuration of a graph can easily be elevated to the levels of
exploration and experimentation by incorporating greater direct manipulation
and some hyper-linking. For instance, rather than using either a modal or
even modeless dialog to add a variable to a graph (via the checkbox list of
variables in Figure 4), the user should be able to drag a variable or a set
of variables from some global list of graphable model variables directly onto
the graph. In addition, the graph can be focused into "interesting" areas
by zooming and dragging the graph and its axis directly in the same manner as
the Graphing Calculator which is bundled with Power Macintosh systems allows.
Hyper-linking each graph to its corresponding "settings" window
(Figure 4) via double-clicking on the graph is much more
natural and fluid than searching for the graph by its title in a menu or list
of graphs. Another important improvement to the graph management facilities
is to eliminate the artificial restriction that only output variables can be
graphed.
Figure 5: The notion of a toolbar controller was borrowed from
source code debuggers found in popular C/C++/Pascal development environments.
Modeled after a VCR or tape player set of controls, the idea is to
encapsulate all the high-level controls needed to manipulate the model
simulation. Several variations of button styles and placement were considered
for the toolbar. The string in the lower left changes according to the
execution state of the model (no model, stopped, running, paused, etc.) The
control bar would always float above all the other windows.
Following the change from a batch processing model of execution to a
continuously running paradigm came the need for an omni-present controller or
toolbar as shown in Figure 5. This toolbar further strengthens
the user's conceptual model of continuous execution within a black box as
found in other, non-computer based tools such as tape players, VCRs, and
radios. The symbols used, their placement, and style all relate to other
tools and help the user map their prior skills and knowledge to Simlab.
Figure 6: Fluidity, consistency, and visual importance were
important considerations in state variable representation. These early
designs for displaying the three types of model variables (input, output, and
internal state) convey the difficulty in avoiding placing inappropriate
emphasis on one type of state data over another. The top two pictures show
user-manipulatable variables ("knobs and switches" external to the model)
as part of the control bar. The bottom window is a look inside the black box
of the model simulation. The amount of accessibility and manipulation control
to be afforded to the user was a key consideration in these designs. Although
the variables were originally placed within the floating toolbar in order to
align them with the notion of controlling the simulation, they were later
moved because the floating nature of this window presented two problems:
window positioning could quickly become very problematic for the user, and it
placed undue emphasis on one set of simulation properties over another.
The toolbar also offered the opportunity to package all the pieces that make
up the external controls (the "knobs and switches" on the black box) into a
single interface element as shown in Figure 6. This would
concisely convey to inexperienced users the fundamental relationship between
model parameters and overall model control while distinguishing those
parameters as concealable fine-tuning controls just like those found on many
other devices. The fine-tune controls would always be accessible or
dismissable by a single click (the "turny triangle" to the far right of the
toolbars shown in Figure 6 would collapse the toolbar to the
state shown in Figure 5). Internal "control" variables such
as state variables would be accessible in their own non-floating window via
the Model Window shown in Figure 2. However, this is where
the "fine-tune controls" conceptual model began to fall apart; all the
variables (input, state, and constant) affect the simulation in conceptually
equivalent ways, yet this design placed an unequal emphasis on one over the
others and introduced two disparate means of access: the toolbar and the
Model Window. In addition, the floating toolbar may become unwieldy as more
variables enter the user's field of interest and they obscure other views of
the simulation.
Figure 7: The consolidated Model Window depicts a "dashboard"
style interface to observing and manipulating the components of a currently
running model simulation. All the elements of a model are represented in this
window. Double-clicking in the upper-left portion opens the corresponding
graph, the same action in the upper-right portion opens a spreadsheet-style
chart for the selected data (see below). Constants can be manipulated as the
model simulation is run and the effects of changes observed in the various
data views. A popup window in the lower left allows sets of constant values
to be stored and loaded. The "volume" style sliders nicely convey the
notion of direct manipulation of the inner workings of a model with
detectable ("audible") feedback results. However, the sliders do not
adequately distinguish between constrained and unconstrained variables, nor
do they lend themselves to changing the bounding values for the constrained
variables.
Borrowing again from design languages found [Winograd] in other programming and software
development environments, I attempted to transform the Model Window from a
listing of meta-information into a single representation of the model and its
simulation. The goal here was to provide a centerpiece for all user
interaction and control of each specific simulation that can become the
user's conceptual model of the simulation itself. Figure 7
depicts an early attempt and Figure 8 presents my final
version of this transformation. The key features to note in each version are
the slider controls in Figure 7, and the complete visual
separation of model variables (inputs, state variables, outputs, and
constants) and default graph in Figure 8. The slider
controls in Figure 7 work in the same way as similar
controls found on most stereo equipment. The advantages to this style of
controller are threefold: the sliders lend themselves well to exploration and
discovery, they emphasize the notion that the associated variables are
external "knobs and switches" that control the underlying simulation, and
the permutations of their horizontal arrangements aid in quickly assessing
the current configuration, or setting, of the model. A few of the failures of
this initial consolidation which led to the refinements found in
Figure 8 are: the lack of adequate support for constrained vs.
unconstrained constants, potentially differing resolutions between adjacent
slider controls due to different valid ranges of values, the lack of
immediate feedback when the model's simulation is running---the only
distinguishable change would be the time-step counter which is too
minor---and the inclusion of the list of graphs---they do not act as controls
for the simulation, they are merely views of the simulation.
Figure 8: A further refinement of the Model Window. All aspects
of the inner workings of the model's simulation are directly viewable and
manipulatable. The triangle buttons in the input and constant sections bring
up pop-up/drop-down slider controls when pressed. The graph in the lower
right gives immediate feedback when the simulation is running---rather than
requiring an open graph to view variable changes qualitatively.
The Model Window depicted in Figure 8 sacrifices some of the
advantages found in Figure 7 in order to solve the more
significant disadvantages listed above. The explicit (and screen-space
hungry) slider controls were replaced by pop-up/drop-down slider controls
that act as scrollers when held at either end. When "popped" (active), they
will scroll their range of values up or down when held at the right or left
end, respectively. The feedback when running is provided by the default graph
which also has its own set of advantages; it provides a qualitative view of
all variables to parallel the quantitative views in each variable list
(although variables may be removed or added to the graph in the same manner
as the other graphs), and the user can focus on any part of the graph and
easily get precise values for all variables by moving the dotted vertical
bar. The default graph, in conjunction with the ability to export variable
value-histories to separate data-analysis tools, may obviate or minimize the
need for additional graphs within Simlab. This last point, however, has not
been explored in depth.
Figure 9: Spreadsheet-style charts for repositories of
simulation data history. This is one area where a component software approach
such as OpenDoc makes the most sense in the overall design. Tabular data can
be exported to data analysis applications.
The last remaining piece of the new user interface for Simlab's simulation
engine is the ability to view model variables in tabular, or historical, form
rather than only as single time-step/value combinations. The most obvious way
to present tabular data is to mimic the now ubiquitous spreadsheet. Since
there is no simulation specific behavior appropriate here, and because the
typical usage of such a presentation is to perform more detailed or
specialized data analysis, a fairly minimalist approach coupled with
straightforward data exportation facilities should be most effective. The
problem here is how to introduce a new view/interaction-style without
diluting the overall interface. Since tabularized data is inherently no
different than the x-y graphs described above---in fact they are merely
quantitative/qualitative counterparts to each other---I decided to expand the
notion of a graph to that of a "data view" which can be presented either
graphically or tabularly depending on the user's needs.
Future Directions
Although this latest stage of Simlab's development is still incomplete,
several future directions have been considered, primarily relating to
potential applications. The near term goal, however, is to produce a fully
usable implementation based on the design discussed in this paper and publish
that implementation as an adjunct to a new textbook on modeling and
simulation targeted toward lower division university and advanced high school
curriculums. Specific application directions are described below.
Native Modeling
Rather than compiling models to a virtual machine target, utilize an
intermediate language such as ANSI C in order to enable optimal execution on
the native processor. This may be facilitated by using a Java based
simulation environment and a Java-C translator.
SK8, Integration with Other Services
SK8 is an experimental "meta-tool" used within Apple Computer's ATG
division. Incorporating many media types, SK8 is intended for use in building
customizable, domain specific authoring tools. The ability to include a
general purpose, state modeling system such as Simlab in derivative tools
could provide for even more powerful experimentation within specific domains.
OpenDoc integration may provide this capability.
Parallel Modeling
Separating the execution of a model simulation from a constrained, single
virtual machine environment to one that can migrate a single simulation or
its component submodels across multiple processors while retaining the same
console-type controller interface would be an important step toward enabling
very large scale and high performance simulations.
Conclusion
Using established design principles and techniques, and with careful
iteration, I developed a design for a robust and highly interactive user
interface for Simlab. Once fully implemented, this interface will raise the
level of interaction and information exchange between the user and the
simulation environment to that of fluid conversation and exploration. Not
only will this improve the overall usability of the Simlab Simulation System,
but it will also enhance the experience of computer modeling and simulation
by addressing the needs of its users.
Footnotes
- Modes are contexts in which a
user action is interpreted differently than the same action would be interpreted
in another context. In other words, the same action, when completed in two different
modes, results in two different reactions. A mode typically restricts the
operations that the user can perform while the model is in effect --- [Apple].
References
- Apple Computer, Inc. Human Interface Guidelines: The Apple Desktop Interface. Addison-Wesley. 1987.
- Steve Aukstakalnis, David Blatner. Silicon Mirage. Ch.1, pp 1-24. (ed) Stephen Roth. Peachpit Press. 1992.
- William Bewley, Teresa Roberts, David Schroit, William Verplank. Human Factors Testing in the Design of Xerox's 8010 'Star' Office Workstation. Human-Computer Interaction. (ed) Jenny Preece and Laurie Keller. Prentice Hall. 1990.
- Nathaniel S. Borenstein. Programming As If People Mattered. Princeton University Press. Princeton, NJ. 1991.
- Susan Brennan. Conversation as Direct Manipulation. The Art of Human-Computer Interaction. (ed) Brenda Laurel. pp 393-404. 1990.
- CACI Products Company. SIMSCRIPT II.5 Home Page. <http://www.caciasl.com/simscript.html>.
- Stuart Card and Thomas Moran. User Technology: From Pointing to Pondering. Proceedings of the ACM Conference on History of Personal Workstations. pp 183-198. Palo Alto. Jan 1986.
- Allen Cypher. KidSim Home Page. <http://www.atg.apple.com/Allen_Cypher/KidSim/KidSim.html>.
- Raimund K. Ege and Christian Stary. Designing Maintainable, Reusable Interfaces. IEEE Software. V9 N6. pp 24-32. Nov 1992.
- Gil Fuchs, MDL: Analysis & Synthesis. <http://www.cse.ucsc.edu/~gil/darrell_doc.html>. Final Paper for UCSC:CIS203. Spring 1994.
- Bill Gaver. Technology Affordances. CHI '91 Conference Proceedings. pp 79-84. ACM Press 1991.
- James H. Gerlach and Feng-Yang Kuo. Formal Development of Hybrid User-Computer Interfaces with Advanced Forms of User Assistance. The Journal of Systems and Software. V16 N3. pp 169-183. Nov 1991.
- Paul Heckel. The Elements of Friendly Software Design. Sybex. 1991.
- High Performance Systems Inc. Stella II Home Page. <http://www.hps-inc.com/stella.html>.
- Edwin Hutchins, James Hollan, and Donald Norman. Direct Manipulation Interfaces. User Centered System Design. (eds) D. Norman and S. Draper. Ch.5, pp 87-124. Erlbaum. 1986.
- Jeff Johnson, Teresa Roberts, William Verplank, David Smith, Charles Irby, Marian Beard, Kevin Mackey. The Xerox Star: A Retrospective. Human-Computer Interaction Toward the Year 2000. (ed) Baecker, Grudin, Buxton, Greenberg. Morgan Kaufmann. 1995.
- Brenda Laurel. Computers as Theatre. pp 1-33, 184-188, 199-214. Addison-Wesley. Reading-MA. 1993.
- William Mitchell. City of Bits. Ch.4. <http://www-mitpress.mit.edu/City_of_Bits/welcome.html>.
- Donald Norman. The Psychology of Everyday Things. Ch.1, pp 1-33. New York. Basic Books. 1988.
- Kent Norman. The Psychology of Menu Selection. Ch.6, pp 126-144. Ablex. 1991.
- Robert E. Opaluch and Yao-Chung Tsao. Ten Ways to Improve Usability Engineering--Designing User Interfaces for Ease of Use. AT&T Technical Journal. V72 N3, pp 75-88. May/June 1993.
- Marc Rettig. Prototyping for Tiny Fingers. Communications of the ACM. V37 N4. pp 21-27. April 1994.
- James Rodden. MDL & Simlab: Heir to SimScript? Simulation's SmallTalk?. <http://alumni.cse.ucsc.edu/~rodden/mdlpaper.html>. Final Paper for UCSC:CIS203. Spring 1994.
- Bruce Tognazinni. The Advent of Agents. Tog on Interface. Ch.20. pp 159-163. 1992.
- Christopher Wickens. Attention in Perception and Display Space. Engineering Psychology and Human Performance. Ch.3, pp 74-115. Scott Foresman. Little Brown. 1992.
- David Canfield Smith, Charles Irby, Ralph Kimball, Bill Verplank, Eric Harslem. Designing the Star User Interface. Human-Computer Interaction. (eds) Jenny Preece and Laurie Keller. Prentice Hall. 1990.
- Terry Winograd. Bringing Design to Software. <http://www-pcd.stanford.edu/winograd/book.html>. Reading. MA: Addison-Wesley. 1996.
- William Verplank. Graphic Challenges in Designing Object-Oriented User Interfaces. Handbook of Human-Computer Interaction. (ed) M. Heiander. Elsevier Science Publishers. Holland. 1988
- Richard Saul Wurman. Information Anxiety. pp 59-65, 74-81, 142-148. Doubleday. 1989.
Appendix
During my investigations and prototyping, I generated a lot of C++ source
code that builds on the PowerPlant object-oriented application framework.
Among these artifacts of my work, three distinct general purpose utility
libraries emerged and two have been released as shareware code on the Metrowerks
PowerPlant Contributed Archives <http://www.metrowerks.com/tools/>
and Celestin Apprentice CD <http://alumni.cse.ucsc.edu/~rodden/apprenticeinfo.html>.
The full source listings for these libraries and the prototype code for
the Simlab simulation interface itself are included below.
- 3DAdditions -- supports a three-dimensional
appearance in visual displays.
- CBetterListBox -- builds
upon the basic List Manager support of PP's LListBox class.
- CDragAndDrop -- greatly eases
Drag And Drop Manager use.