Human-Computer Interaction

CS 6751 Winter 1996

GOMS example

The following is a summary of the GOMS analysis done in today's lecture. This example is extracted from:

David Kieras, A Guide to GOMS Task Analysis, University of Michigan Technical Report, Spring, 1994.

Copies of the above report will be supplied by the instructor upon request.

1. INTRODUCTION

What is a GOMS Model?

A GOMS model, as proposed by Card, Moran, and Newell (1983), is a description of the knowledge that a user must have in order to carry out tasks on a device or system; it is a representation of the "how to do it" knowledge that is required by a system in order to get the intended tasks accomplished. The acronym GOMS stands for Goals, Operators, Methods, and Selection Rules. Briefly, a GOMS model consists of descriptions of the Methods needed to accomplish specified Goals. The Methods are a series of steps consisting of Operators that the user performs. A Method may call for sub-Goals to be accomplished, so the Methods have a hierarchical structure. If there is more than one Method to accomplish a Goal, then the GOMS model includes Selection Rules that choose the appropriate Method depending on the context.

Once the GOMS model has been developed, predictions of learning and performance can be obtained as described below. A GOMS description is also a way to characterize a set of design decisions from the point of view of the user, which can make it useful during, as well as after, design. It is also a description of what the user must learn, and so can act as a basis for training and reference documentation.

What is a GOMS Task Analysis?

Describing the Goals, Operators, Methods, and Selection Rules for a set of tasks in a relatively formal way constitutes doing a GOMS task analysis. The person who is performing such an analysis is referred to as "the analyst" in this Guide.

One important feature of a GOMS model is that the "how to do it" knowledge is described in a form that can actually be executed - somebody (or an appropriately programmed computer) can go through the GOMS description, executing the described actions, and actually carry out the task. This distinguishes a GOMS-based analysis of a task from the traditional forms of task analysis, which are either very informal, or consist only of a list of the possible user goals.

What Does a GOMS Task Analysis Involve?

Actually carrying out a GOMS analysis involves defining and then describing in a formal notation the user's Goals, Operators, Methods, and Selection Rules. Most of the work seems to be in defining the Goals and Methods. That is, the Operators are mostly determined by the hardware and lowest-level software of the system, such as whether it has a mouse, for example. Thus the Operators are fairly easy to define. The Selection Rules can be subtle, but usually they are involved only when there are clear multiple methods for the same goal. In a good design, it is clear when each method should be used, so defining the Selection Rules is (or should be) relatively easy as well.

Identifying and defining the user's goals is often difficult, because you must examine the task that the user is trying to accomplish in some detail, often going beyond just the specific system to the context in which the system is being used. This is especially important in designing a new system, because a good design is one that fits not just the task considered in isolation, but also how the system will be used in the user's job context.

Once a Goal is defined, the corresponding method can be simple to define because it is simply the answer to the question "how do you do it on this system?" The system design itself determines what the methods are. However, describing the methods in the formal notation can be a long and tedious job.

One critical process involved in doing a GOMS analysis is deciding whatand what not to describe. The mental processes of the user can be of incredible complexity; trying to describe all of them would be hopeless. However, many of these complex processes have nothing to do with the design of the interface, and so do not need to be analyzed. For example, the process of reading is extraordinarily complex; but usually, design choices for a user interface can be made without any detailed consideration of how the reading process works. We can treat the user's reading mechanisms as a "black box" during the interface design. We may want to know how much reading has to be done, but rarely do we need to know how it is done. So, we will need to describe when something is read, and why it is read, but we will not need to describe the actual processes involved. A way to handle this in a GOMS analysis is to "bypass" the reading process by representing it with a "dummy" or "place holder" operator. This is discussed more below. But making the choices of what to bypass is an important, and sometimes difficult, part of the analysis.

2. Example of GOMS Analysis

Before presenting the details of the GOMS modeling methodology, it is useful to examine a sample GOMS analysis and see how it can capture an important aspect of interface "consistency." The tasks and systems are some file manipulation tasks in PC-DOS and Macintosh Finder. The set of user goals considered are:

The example consists of a list of methods for each system, expressed in the NGOMSL notation introduced in detail later in this Guide. One of the virtues of this notation is that it is pretty comprehensible without having studied its formal definition first. This example is intended just to give the overall flavor of what a GOMS model looks like, so no detail or explanation of the notation will be given at this time.

GOMS Model for Macintosh Finder

There is a specific method for accomplishing each one of the user goals under consideration. Notice how each method is simply an explicit step-by-step description of what the user has to do in order to accomplish the goal.

Method for goal: delete a file.

	Step 1. Accomplish goal: drag file to trash.

	Step 2. Return with goal accomplished.



Method for goal: move a file.

	Step 1. Accomplish goal: drag file to destination.

	Step 2. Return with goal accomplished.



Method for goal: delete a directory.

	Step 1. Accomplish goal: drag directory to trash.

	Step 2. Return with goal accomplished.



Method for goal: move a directory.

	Step 1. Accomplish goal: drag directory to destination.

	Step 2. Return with goal accomplished.
We can see from the above methods that they all have a simple pattern; it doesn't matter whether a directory or a file is being manipulated. So we can replace the above four methods with only two generalized methods, one for deleting and one for moving:

Method for goal: delete an object.

	Step 1. Accomplish goal: drag object to trash.

	Step 2. Return with goal accomplished.



Method for goal: move an object.

	Step 1. Accomplish goal: drag object to destination.

	Step 2. Return with goal accomplished.
In addition to the specific moving and deleting methods, there is a general submethod corresponding to the drag operation; this is the basic method used in most of the Macintosh Finder file manipulations. It is called like a subroutine by the above methods.

Method for goal: drag item to destination.

	Step 1. Locate icon for item on screen.

	Step 2. Move cursor to item icon location.

	Step 3. Hold mouse button down.

	Step 4. Locate destination icon on screen.

	Step 5. Move cursor to destination icon.

	Step 6. Verify that destination icon is reverse-video.

	Step 7. Release mouse button.

	Step 8. Return with goal accomplished.

GOMS Model for PC-DOS

There are a large number of specific methods, and some of the user goals, such as moving a file, are accomplished by calling other methods. Notice also that there is no generalization over files and directories, because the PC-DOS command set forces us to use very different methods for these two types of objects. Each of these methods calls a general submethod for entering and executing a specified command.

Method for goal: delete a file.

	Step 1. Recall that command verb is "ERASE".

	Step 2. Think of directory name and file name and retain as first filespec.

	Step 4. Accomplish goal: enter and execute a command.

	Step 6. Return with goal accomplished.


Method for goal: move a file.

	Step 1. Accomplish goal: copy a file.

	Step 2. Accomplish goal: delete a file.

	Step 3. Return with goal accomplished.


Method for goal: copy a file.

	Step 1. Recall that command verb is "COPY".

	Step 2. Think of source directory name and file name and retain as first filespec.

	Step 3. Think of destination directory name and file name and retain as second filespec.

	Step 4. Accomplish goal: enter and execute a command.

	Step 5. Return with goal accomplished.


Method for goal: delete a directory.

	Step 1. Accomplish goal: delete all files in the directory.

	Step 2. Accomplish goal: remove a directory.

	Step 3. Return with goal accomplished.


Method for goal: delete all files in a directory.

	Step 1. Recall that command verb is "ERASE".

	Step 2. Think of directory name.

	Step 3. Retain directory name and "*.*" as first filespec.

	Step 4. Accomplish goal: enter and execute a command.

	Step 5. Return with goal accomplished.


Method for goal: remove a directory 

	Step 1. Recall that command verb is "RMDIR".

	Step 2. Think of directory name and retain as first filespec.

	Step 3. Accomplish goal: enter and execute a command.

	Step 4. Return with goal accomplished.


Method for goal: move a directory.

	Step 1. Accomplish goal: copy a directory.

	Step 2. Accomplish goal: delete a directory.

	Step 3. Return with goal accomplished.


Method for goal: copy a directory.

	Step 1. Accomplish goal: create a directory.

	Step 2. Accomplish goal: copy all the files in a directory.

	Step 3. Return with goal accomplished.


Method for goal: create a directory.

	Step 1. Recall that command verb is "MKDIR".

	Step 2. Think of directory name and retain as first filespec.

	Step 3. Accomplish goal: enter and execute a command.

	Step 4. Return with goal accomplished.


Method for goal: copy all files in a directory.

	Step 1. Recall that command verb is "COPY".

	Step 2. Think of directory name.

	Step 3. Retain directory name and "*.*" as first filespec.

	Step 4. Think of destination directory name.

	Step 5. Retain destination directory name and "*.*" as second filespec.

	Step 6. Accomplish goal: enter and execute a command.

	Step 7. Return with goal accomplished.
These general submethods are called by the above methods. They reflect the basic consistency of the command structure, in which each command consists of a verb followed by one or two file specifications. 

Method for goal: enter and execute a command.

Entered with strings for a command verb and one or two filespecs.

	Step 1. Type command verb.

	Step 2. Accomplish goal: enter first filespec.

	Step 3. Decide: If no second filespec, goto 5.

	Step 4. Accomplish goal: enter second filespec.

	Step 5. Verify command.

	Step 6. Type "<CR>".

	Step 7. Return with goal accomplished.


Method for goal: enter a filespec.

Entered with directory name and file name strings.

	Step 1. Type space.

	Step 2. Decide: If no directory name, goto 5.

	Step 3. Type "\".

	Step 4. Type directory name.

	Step 5. Decide: If no file name, return with goal accomplished.

	Step 6. Type file name.

	Step 7. Return with goal accomplished.

GOMS Comparison of Macintosh Finder and PC-DOS

Clearly there is a substantial difference in the number and length of methods between these two systems. The Macintosh Finder, in its generalized form requires only 3 methods to accomplish these user goals, involving a total of only 18 steps. To accomplish the same goals in PC-DOS requires 12 methods with a total of 68 steps. Thus we have a clear characterization of the extreme consistency of the Macintosh Finder compared to PC-DOS; only a few methods are required to accomplish a variety of file manipulation goals. A major value of a GOMS model is its ability to characterize, and even quantify, this property of method consistency.

The Guide describes below how these Method descriptions can be used to derive predictions of learning and execution time. The user must learn these step-by-step methods in order to learn how to perform these tasks. According to research results, the learning time is linear with the number of steps. The execution time can be predicted as in the Keystroke-Level Model, as a total of the individual operator times.

Back to Winter 96 CS 6751 Home Page