Methodology I: Task Analysis - Foundations for Designing User-Centered Systems - page 315

example, how an author right now is working through this chapter making changes
to improve the text and how students revise lab reports.
The loop has several types of substeps. These steps can store state (e.g., what
the current task is); they can perform conditionals (if); and they can subgoal
(Perform unit task). Within the unit tasks (not fully shown), information can be
obtained from the display and mental and physical actions performed. GOMS
manuals provide a full list of the actions (e.g., Kieras 1999 ) and when to include
mental operators to retrieve task structure, but in practice these lists can be
extended to include unusual devices such as joysticks or different types of manual
controls (such as different knobs or toggle switches). The analysis in Table 11.4
does not include all the details of all the subtasks that can be performed, and not all
the details of how to do a unit task.
Table 11.5 shows a model for dialing a cell phone. In this example the tasks are
slightly smaller and the interaction and memory aspects are more prominent.
11.5.3 Summary
GOMS models sometimes appear structurally quite similar to other hierarchical
task analyses of goals/subgoals. The main difference is that GOMS has formalized
its components to a greater level of detail. It is assumed that the methods are
known before the GOMS analysis is carried out, and that they are not developed
during task performance. The particular strengths of GOMS lie in assessing how to
make interfaces easier to use by comparing alternative models, or methods, for a
particular task.
Many people question the utility of GOMS analyses, arguing that there is no
such thing as error-free, expert performance. This limitation can be somewhat
ameliorated by incorporating the error correction strategies in the analysis.
Probably the biggest limitation of GOMS, however, is that the interface has to be
implemented or at least described in enough detail to be able to identify the actions
for a particular task. There is also a lack of a clear specification of what can be
used in Selection rules—there is an implication that it should be the current task
context, but real behavior, for example, undoubtedly allows choices to be based on
previous selections. It is also difficult to do a vanilla GOMS analysis when mul-
titasking or task interleaving is involved. CPM-GOMS was developed to address
this, but at the expense of making it more difficult to create models.
11.6 The Keystroke Level Model
A simplified version of GOMS is the keystroke level model (KLM) of Card et al.
( 1983 ). Like GOMS, it is a method that can be used as part of a CTA, but we include
it here in its own right because of its close relationship with the field of HCI.