GOMS Model Notes

GOMS Model

Introduction to GOMS

The GOMS model, proposed by Card, Moran, and Newell in 1983, is a descriptive model outlining the knowledge a user needs to interact with a device or system. It represents the 'how-to-do-it' knowledge necessary for a system to accomplish intended tasks. The acronym GOMS stands for Goals, Operators, Methods, and Selection Rules.

GOMS Components

A GOMS model consists of descriptions of the Methods required to achieve specific Goals. These Methods comprise a series of steps involving Operators that the user employs to perform tasks. Methods may also call for sub-Goals, resulting in a hierarchical structure. When multiple Methods exist for accomplishing a Goal, the GOMS model incorporates Selection Rules to choose the appropriate Method based on the context.

Applications of GOMS

Once a GOMS model is developed, it allows for predictions of learning and performance. It serves as a way to characterize design decisions from the user's perspective, making it valuable during and after the design phase. Furthermore, it details what the user needs to learn, serving as a foundation for training and reference documentation.

GOMS Task Analysis

Performing a GOMS task analysis involves formally describing the Goals, Operators, Methods, and Selection Rules for a set of tasks. The person conducting this analysis is the 'analyst'. A key feature of a GOMS model is that the 'how-to-do-it' knowledge is described in an executable format. This distinguishes GOMS-based analysis from traditional task analysis, which is often informal or simply lists user goals.

Elements of GOMS Task Analysis

GOMS analysis requires defining and describing the user's Goals, Operators, Methods, and Selection Rules in a formal notation. Defining Goals and Methods often constitutes most of the work. Operators are largely determined by the hardware and software of the system. Selection Rules become relevant when there are multiple methods for the same goal; a good design clearly indicates when each method should be applied, simplifying the definition of Selection Rules.

Identifying User Goals

Identifying and defining user goals can be challenging, requiring a detailed examination of the task within the context of the system's use. This is particularly important when designing new systems to ensure the design fits both the task and the user's job context. Once a Goal is defined, the corresponding Method is often straightforward, answering the question of how to accomplish it on the specific system. Describing the methods in a formal notation, however, can be lengthy.

Scope of GOMS Analysis

Deciding what to include and exclude is critical in GOMS analysis. While user's mental processes are complex, many are unrelated to the interface design and don't require analysis. For instance, the reading process is complex, but interface design choices can often be made without detailed consideration of how reading works. Instead, reading mechanisms can be treated as a 'black box.' In a GOMS analysis, the reading process can be bypassed using a 'dummy' or 'place holder' operator. Determining what to bypass is a key part of the analysis.

GOMS Example: File Manipulation

A GOMS analysis can highlight interface consistency. Consider file manipulation tasks in PC-DOS and Macintosh Finder, focusing on user goals like deleting and moving files or directories.

GOMS Model for Macintosh Finder

The Macintosh Finder provides a specific method for each user goal. Each method is a step-by-step description of the actions needed to achieve 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.

These methods exhibit a simple pattern, regardless of whether a file or directory is being manipulated. Therefore, these four methods can be replaced by two generalized methods:

  • 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.

Drag Operation Submethod

In addition to moving and deleting methods, there is a general submethod for the drag operation, which is frequently used in Macintosh Finder file manipulations. This submethod acts as a subroutine.

  • 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

PC-DOS involves a larger number of specific methods. Some user goals, like moving a file, require calling other methods. There is no generalization over files and directories, as the PC-DOS command set necessitates different methods for these object types. Each method calls a general submethod for entering and executing commands.

  • 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.

General Submethods in PC-DOS

These are the general submethods 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 "".

    • 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.

Comparison of Macintosh Finder and PC-DOS

There is a significant difference in the number and length of methods between Macintosh Finder and PC-DOS. Macintosh Finder in its generalized form, requires only 3 methods with 18 steps to accomplish the user goals. PC-DOS requires 12 methods with total of 68 steps. A major value of a GOMS model is its ability to characterize and quantify method consistency. These Method descriptions can be used to derive predictions of learning and execution time. Learning time is linear with the number of steps, and execution time can be predicted using the Keystroke-Level Model by totaling individual operator times.