Automating CPM-GOMS

Bonnie John
1
, Alonso Vera
2
, Michael Matessa
2
, Michael Freed
2
, and Roger Remington
2


1
Human-Computer Interaction Institute
Carnegie Mellon University
5000 Forbes Ave., Pittsburgh, PA
+1 412 268 7182
bej@cs.cmu.edu


2
MS 262-4
NASA Ames Research Center
Moffett Field, CA 94035
+1 650 604 6294
avera@arc.nasa.gov

ABSTRACT
CPM-GOMS is a modeling method that combines the task
decomposition of a GOMS analysis with a model of human
resource usage at the level of cognitive, perceptual, and
motor operations. CPM-GOMS models have made accurate
predictions about skilled user behavior in routine tasks, but
developing such models is tedious and error-prone. We
describe a process for automatically generating CPM-GOMS
models from a hierarchical task decomposition expressed in a
cognitive modeling tool called Apex. Resource scheduling in
Apex automates the difficult task of interleaving the
cognitive, perceptual, and motor resources underlying
common task operators (e.g. mouse move-and-click). Apex’s
UI automatically generates PERT charts, which allow
modelers to visualize a model’s complex parallel behavior.
Because interleaving and visualization is now automated, it is
feasible to construct arbitrarily long sequences of behavior.
To demonstrate the process, we present a model of automated
teller interactions in Apex and discuss implications for user
modeling.
Keywords
GOMS, Apex, Task/User Modeling, Tool Support for
Usability Evaluation.
INTRODUCTION AND MOTIVATION
One of the difficulties in developing human interfaces to
complex systems is anticipating the response of users to the
large space of possible system states and design options.
Even extended empirical user testing can fail to uncover
serious difficulties. It would be useful to have a
computational representation of the user that would allow the
designer to simulate user responses to a variety of situations
and design options. Though the field is far from having a
complete model of the user, several computational modeling
approaches have been successful in making accurate
predictions of user choices as well as task completion times
(e.g., [15, 25, 29, 31, 32]). Of the several architectures
available to model human users, the Goals, Operators,
Methods, and Selection (GOMS) method [6, 21] has been the
most widely used, providing accurate, often zero-parameter,
predictions of the routine performance of skilled users in a
wide range of procedural tasks [6, 13, 15, 27, 28].
GOMS is meant to model routine behavior. The user is
assumed to have methods that apply sequences of operators
and to achieve a goal. Selection rules are applied when there
is more than one method to achieve a goal. Many routine
tasks lend themselves well to such decomposition.
Decomposition produces a representation of the task as a set
of nested goal states that include an initial state and a final
state. The iterative decomposition into goals and nested
subgoals can terminate in primitives of any desired
granularity, the choice of level of detail dependent on the
predictions required.
Although GOMS has proven useful in HCI, tools to support
the construction of GOMS models have not yet come into
general use. Several tools have emerged from the research
world, e.g., QGOMS [3], CATHCI [30], GLEAN [24]. All of
these tools aid the modeler to some extent, but all have
drawbacks that prevent them from being heavily used in
design practice today [2]. In addition, none of them automate
any part of the modeling process. However, limited
demonstrations of the potential for automating some portions
of GOMS modeling have been made [4, 16, 26].
We extend these promising directions with a tool that
automates part of the GOMS modeling process using an
existing computational architecture, Apex [9, 10]. Our work
differs from that of our predecessors because Apex served not
only as an implementation platform but provided new insights
into GOMS modeling itself. In addition, the previous work
focused on the higher-level members of the GOMS modeling
family (KLM, CMN-GOMS and NGOMSL; [21]) whereas
our use of Apex emphasizes the lowest-level GOMS
modeling technique (CPM-GOMS). Employing reusable
templates of behavior, our tool allows the modeler to specify
procedural knowledge at a task-level and automates the
translation of that knowledge into interleaved cognitive,
perceptual and motor operators.
Copyright 2001 Association for Computing Machinery. ACM acknow-
ledges that this contribution was authored or co-authored by a contractor or
affiliate of the U.S. Government. As such, the Government retains a
nonexclusive, royalty-free right to publish or reproduce this article, or to
allow others to do so, for Government purposes only.
CHI 2002, April 20-25, 2002, Minneapolis, Minnesota, USA.
Copyright 2002 ACM 1-58113-453-3/02/0004…$5.00.

minneapolis, minnesota, usa • 20-25 april 2002 Paper: Controlling Complexity


Volume No. 4, Issue No. 1 147

The next section will introduce key aspects of CPM-GOMS
and the procedure for constructing such models by hand.
Then we will describe Apex, the insights it afforded, and the
procedure for constructing a CPM-GOMS model with that
tool. Finally, we will present an example use of the tool and a
comparison of the resulting CPM-GOMS model to user data.
CONSTRUCTING CPM-GOMS MODELS
John & Kieras [21] described four varieties of GOMS
modeling techniques. Three make the assumption that all
operators occur in sequence and usually do not contain
operators below the activity level (e.g., type-string, move-
and-click-mouse). These three are the original formulation by
Card, Moran and Newell [5, 6] termed CMN-GOMS, the
Keystroke-Level Model (KLM) also formulated by Card
Moran and Newell [6], and NGOMSL [23]. The fourth,
called CPM-GOMS [17, 18], uses operators at the level of
the Model Human Processor (MHP, [6]) and assumes that
operators of the cognitive processor, perceptual processor,
and the motor processor can work in parallel to each other
subject to information-flow constraints. The first three
techniques have been supported by research tools for about a
decade, where modelers can draw hierarchical goal
decomposition in a tree diagram (QGOMS, [3]), program it
in a dedicated programming environment (GLEAN, [24]) or
even automatically generate most of the model simply by
demonstrating a task (CRITIQUE, [16]).
Unlike the first three GOMS methods, CPM-GOMS human
performance predictions are constructed from primitives that
include estimates of the time for the elementary cognitive,
motor, and perceptual operations. These primitives are
hypothesized to underlie actions such as typing a key or
moving a mouse. Much of the power of CPM-GOMS to
predict skilled behavior comes from its ability to model
overlapping actions by interleaving cognitive, perceptual, and
motor operators. Although it could be argued that CPM-
GOMS has been the most economically successful of the
GOMS methods (saving a telephone company $2 million per
year [15]), it has had no dedicated tool support to date.
Crafting CPM-GOMS Models by Hand
CPM-GOMS models have traditionally been expressed in
PERT charts, a representation familiar to project managers.
Every operator is represented as a box (a task) with a duration
(in milliseconds). If an operator must have information that is
the output of another operator, then it is said to be dependent
on that operator and must wait for it to complete before
starting itself. Likewise, if two operators use the same
processor of the MHP (e.g., cognitive processor, vision, or
the right hand), one must wait for the previous to complete
before starting. Thus, a CPM-GOMS model of a user’s task
consists of boxes with durations and dependency lines
between them. Figure 1 shows a model of a person carefully
moving a mouse to a target on the screen and clicking on that
target.











Figure 1: Model of carefully the cursor to a target and
clicking the mouse button (adapted from [11]).
Procedure for constructing a CPM-GOMS model with
MacProject
Models were created using MacProject, a project
management tool originally produced by Apple, improved by
Claris, and no longer commercially available. The key feature
of MacProject that made it possible for CPM-GOMS models
to be constructed is that pre-established patterns of operators
could be stored in a library file and then copy-and-pasted into
a new canvas, preserving all relevant information about the
patterns (e.g., duration, dependencies, position on the page).
These patterns, which we called “templates” [20], were of
commonly recurring task-level activities in HCI. Each
template was very short, some encompassed just a fraction of
a second and others were up to several seconds. Templates
exist for HCI tasks including typing, visually getting
information from a screen (with or without eye-movements),
pressing a single key, having a short conversation, etc. The
pattern shown in Figure 1 for selecting a target is an example
of a template.
To build a CPM-GOMS model, the modeler would start with
a hierarchical goal decomposition, usually in the form of a
CMN-GOMS model. This goal decomposition would
continue until the leaves formed a sequence of keystroke-
level activities necessary to complete the task. After
completing the goal decomposition, the modeler would
choose the templates that achieve the activities and copy and
paste them into a blank workspace. The modeler then drew
dependency lines between operators from adjoining templates
that use the same processor, i.e., from one template’s last
cognitive operator to the next template’s first cognitive
operator, etc. Since each template was on the order of a
second long, an interesting model would include scores of
templates and be comprised of hundreds of MHP-level
operators and their dependencies.
After copying the appropriate templates into the model, each
operator in each template had to be given a unique name to
allow the modeler to keep track of the model as they scrolled
through many screens of MacProject. Furthermore, the
modeler had to remember to fill in durations for some of the
initiate-move-
cursor
perceive-
target
290
0
attend-
target
50
initiate-
POG
50
verify-
target
pos
50
move-
cursor
182
POG
30
mouseDn
100
initiate-
mouseDn
50
mouseUp
100
new-cursor-location
perceive
cursor
@target
100
50
verify
cursor
@target
50
attend
cursor
@target
50
Paper: Controlling Complexity CHI changing the world, changing ourselves


148 Volume No. 4, Issue No. 1