How Apex Automates CPM-GOMS
Michael Freed*º, Michael Matessa*, Roger Remington*, Alonso Vera*
* MS 262-4 NASA Ames Research Center / Moffett Field, CA 94035 / USA
º IHMC / University of West Florida / 40 South Alcaniz St. / Pensacola, FL 32501 / USA
Abstract
Although acknowledged to be a powerful technique
for predicting skilled behavior, CPM-GOMS (John
and Kieras, 1996) is not widely used in interactive
system design. We hypothesize that this is because
creating CPM-GOMS models requires extensive
expertise and is tedious and error-prone. To address
these problems, we used the Apex architecture (Freed,
1998b) to automate critical parts of the CPM-GOMS
analysis process. This paper describes how modelers
represent CPM-GOMS models in Apex and how Apex
translates those representations into predictions of
skilled behavior. This information should prove
helpful in reproducing CPM-GOMS capabilities in
other cognitive architectures.
Introduction
This paper describes an approach to applied human
performance modeling based on the automatic
scheduling of low-level cognitive, perceptual, and
motor (CPM) resources that underlie actions such as
moving and clicking a mouse, pressing a button, or
speaking a phrase. Specifically, our computational
architecture, Apex, automates a modeling technique
known as CPM-GOMS (Gray, Atwood and John,
1993; John and Kieras, 1996). The practical value of
CPM-GOMS is that it has been shown to provide
very accurate zero-parameter predictions of human
performance in highly practiced tasks. Its capacity for
making accurate predictions for tasks of practical
significance is well illustrated by its use in Project
Ernestine (Gray, Atwood and John, 1993). A CPM-
GOMS model was used to generate predictions of the
average time for a telephone operator to handle a
customer transaction using newly designed equipment
and procedures. Accurately, but contrary to the
system designer’s expectations, the model predicted
an average task duration .63 seconds greater than that
required with existing equipment. With each second
of transaction time costing NYNEX three million
dollars annually, purchasing the new equipment
would have been a costly mistake.
Given successes like project Ernestine,
CPM-GOMS is acknowledged in the human-
computer interaction community as a powerful
predictive technique. However, CPM-GOMS is also
considered an onerous and error-prone process that
requires a great deal of specialized expertise to apply
(John, Vera, Matessa, Freed and Remington, 2002).
These factors have almost certainly inhibited CPM-
GOMS from coming into widespread use.
Elsewhere (John et al., 2002) we have
described the benefits of using the Apex cognitive
architecture (Freed, 1998b) to automatically construct
CPM-GOMS models, and demonstrated the validity
of the resulting human performance predictions.
Here we describe in detail how Apex automates
CPM-GOMS. In keeping with its goal of providing a
simplified modeling framework for engineering
domains, Apex provides a flexible behavior
representation language that permits the Apex
modeler to represent behavior at a relatively high
level, thus facilitating model development.
Underlying this high-level language is a complex
action selection architecture that selects and
schedules tasks and resources. A more detailed
treatment of how the Apex architecture interprets the
high-level representation of task knowledge will be
useful in developing human performance models in
Apex. The description also attempts to highlight
abstract properties needed for any automation of
CPM-GOMS, and should facilitate its implementation
in other computational architectures.
GOMS and CPM-GOMS
CPM-GOMS (John and Kieras, 1996) is an extension
of GOMS (Card, Moran and Newell, 1983), a
methodology for predicting how long a person will
take to carry out a well-learned machine-interface
task. GOMS represents tasks in terms of Goals,
Operators, Methods, and Selection rules. For
example, an analysis of the task of deleting a file
from one’s computer directory structure might start
with a top-level goal such as (delete-file oldpic.jpg).
Methods are generalized action sequences for
decomposing goals into subgoals. For example, a
method for goals of type delete-file might consist of
the sequence: visually find target file icon, move
mouse pointer to icon, hold mouse button, move
mouse pointer to trash-icon, release mouse button.
Selection rules are used to choose between
alternative methods for accomplishing a goal – e.g. a
rule might choose between the file removal method
above and a text-based method depending on whether
a graphical or command-line interface is being used.
Method-based goal decomposition continues
recursively on (sub)goals, stopping if the goal
corresponds to a primitive operator. What
constitutes an operator is decided by the modeler
based on how fine-grained an analysis is desired.
Usually, GOMS modelers define operators at the
level of interface actions such as clicking a mouse or
reading a value off a display.
The process of recursively applying methods
to non-primitive goals (those that do not correspond

to an operator) produces a goal hierarchy. Ordered
by a depth-first traverse, the leaf nodes of this
hierarchy form a sequence of operator-level actions
(o
1
.. o
n
) whose total execution time (_o
i
) is the
predicted total time for the task. This approach to
predicting task duration makes strong assumptions
about operator independence – that operators are
executed in strict sequence and that the specific
nature of an operator has no effect on the time
required to execute other operators in the sequence.
These assumptions do not hold for highly practiced
sequences where the execution of adjacent operators
may overlap in time and the degree of overlap can
depend on operator order and identity (cf. Agre and
Shrager, 1990). As a result, the sum duration of
operators whose assigned individual durations are
correct in isolation will tend to predict excessive
overall task duration.
The CPM-GOMS method extends GOMS to
account for overlapping execution. A CPM-GOMS
analysis is derived from a GOMS analysis of the
same task. However, the interface-level behaviors in
the resulting sequence are no longer considered
operators. Instead they are template-level goals. We
denote the template-level goal sequence (t
0
.. t
n
).
Unlike operators, which cannot be further
decomposed, and unlike regular goals in the goal
hierarchy which are decomposed using methods, a
template-level goal is decomposed using a new
structure called a template.
A template specifies decomposition of an
interface-level goal into discrete cognitive, perceptual
and motor (CPM) actions consistent with the Model
Human Processor (e.g. Card, Moran and Newell,
1983); see also Gray and Boehm-Davis, 2000). Each
of these actions is considered an operator and each is
considered a user of a particular cognitive, perceptual
or motor resource. Operators in a template can be
carried out concurrently if they use different
resources and are not order-constrained by the logic
of the task. For instance, two eye-movement
operators cannot be carried out concurrently, nor can
an eye-movement and a hand-movement if the former
is used to visually identify a target for the latter.
In CPM-GOMS, operators from one
template-level goal in the sequence can sometimes
begin before all operators from a preceding template-
level goal have finished. Several kinds of constraints
(described below) govern the interleaving of
operators from different templates. The essence of
the interleaving phenomenon is that activities
specified by a template do not use all resources all of
the time; idle time (slack) in the use of a resource by
one template’s operators represents an opportunity for
operators from a later template to “slip back” and
begin execution. Interleaving at the level of CPM-
GOMS operator-level goals corresponds to overlap in
the execution of higher-level goals – i.e. at the level
of classic GOMS operators – and thus accounts for
the different predictions of the CPM-GOMS and
classic GOMS approaches.
The problem of determining how to
interleave operators from a sequence of template-
level goals can be formulated as a scheduling
problem with three kinds of constraints determining
what constitutes a correct schedule. Logical
constraints, where one action is required to specify
or enable another and therefore must precede it, may
apply between operators within a single template or
across templates. Within a template, logical
constraints can be represented as explicit orderings
between operators. To enforce logical constraints
across templates requires representing each operator’s
preconditions and effects. A logical constraint exists
if the effect of executing an operator from an earlier
template is required to satisfy a precondition for an
operator of a later template. Since CPM-GOMS
allows operators from one template to slip back into
the temporal scope of earlier templates, enforcing
cross-template logical constraints is required to
guarantee correct behavior.
Unary resource constraints specify that
when two operators use a non-sharable, non-
depletable resource (e.g. the left-hand), they cannot
be carried out concurrently. Within a template,
operators requiring the same resource must be
explicitly sequenced. Across templates, operators
must follow a template precedence rule – i.e. given
template sequence t
1
.. t
n
, operator A from template-
level goal t
i
that requires resource R, operator B from
t
j
that also requires R, and i<j, operator A has
precedence. An important nuance in applying this
rule applies in situations where the earlier template
has an interval of slack time immediately prior to A
that is not long enough for B to run to completion.
The template precedence rule extends to this case; B
cannot be scheduled for that interval.
Slack exclusion constraints are restrictions
a template places on the use of slack time by
operators that are brief enough to fit into a slack
interval but have some “undesirable” property.
Templates in the model described by John et al.
(2002) employed a slack exclusion constraint on
cognitive operators representing the initiation of a
motor response. In particular, the model employed a
cognitive initiation exclusion rule defined as follows:
given a set of operators A
1
..A
m
from template-level
goal t
i
that all use resource R, operators B and C from
template-level goal t
j
where C uses R and B
represents a cognitive action that initiates action in C,
and i<j, B cannot execute until A
1
..A
m
are complete.
This rule contributed to very accurate predictions in
the referenced model; however, its generality and
scientific basis are a topic of ongoing research.
So far, we have provided an architecture-
independent characterization of the CPM-GOMS
framework implemented in Apex. The remainder of
the paper will describe how task knowledge is
represented in Apex and how these representations
can be made to meet the specific requirements of a
CPM-GOMS analysis as described above.