Review Norman's "Seven Stages of Action" and his "Four principles of design"
These apply to UID as well as "design of everyday things"

These form a theory -- high-level, abstract, technology-independent

GOMS theory of HCI developed by Card, Moran, and Newell (The Psychology of HCI, 1983)

Used to predict time required to perform or learn interactive computerized tasks.

Developed for text editors and word processors. Has extended beyond that.

Goals : determine what to achieve and set of possible methods

Operators : "elementary perceptual, motor, or cognitive acts" required to achieve goal

Methods : procedures for achieving goal; consist of operators and other goals.

Selection rules : rules for determining which method to apply, if several possibilities exist.

Assume goal hierarchy, usually visualized as tree: root is main goal, children are subgoals, their children are sub-subgoals, etc. Solution is basically depth-first traversal.

Can also think of it as stack-based. Push goal onto stack when encountered, pop when achieved.

Problem with basic GOMS: only the "O" is directly observable!! Variation is: Keystroke Model.

(Communications of ACM 23:7, July 1980).

Focus on time required to press keys and work mouse (and accompanying physical movements). Use fixed estimates for cognitive operators.

Library does not have Psychology of HCI, but GOMS and Keystroke are covered nicely in User Interface Design by Ray Eberts (available in SMSU library).

In class exercise: MS Word file containing lines has just been opened. Goal is to move one line from near the bottom to near the top. (could use numbered lines). Write down step-by-step, how you will accomplish this. What are the subgoals?

Results: 14 students identified 14 distinct sequences! Some were strictly keyboard based, others utilized mouse to varying exent.

Layered 4-level model for HCI developed by Foley and van Dam in late 1970s.
1. conceptual level : user’s mental model
2. semantic level : meanings conveyed by I/O
3. syntactic level : how to assemble units that convey semantics
4. lexical level : precise mechanisms for specifying syntax.

Based on familiar compiler and programming language model:

• Keywords, symbols, numeric constants and identifiers are lexemes, lexical level.
• Valid arrangements of lexemes defines statement syntax, syntactic level.
• Action or meaning associated with statement is its semantics, semantic level.
• Conceptual level relates to goal of the program (what is its purpose).

How do elements of GOMS map to these?

How do elements of Norman's 7 stages map to these?

Other methods exist for specifying tasks using:

• Production rules
• BNF grammars
• State Transition Diagrams
• Data flow diagrams / Petri nets (?)

Commonalities:

• Can specify lexical/syntax sequences for correctly conducting task.
• Can also specify incorrect sequences!
• Can use complexity of spec itself to predict performance (e.g. number of rules/states)!
• Can also be coded into SW for various purposes (such as giving task guidance, looking for buggy behavior, monitoring performance). Examples?

==================================================================

Example of grammar for task specification: TAG

Developed by Payne and Green (1986)

TAG: Task-Action Grammar, is device to support interaction consistency (and completeness).

Works roughly like this:

• list the tasks (commands) and the actions required for each.
• Eliminate synonyms from action list (for consistency).
• Check action list for completeness (e.g. if "right", "left" and "up" are there, add "down").
• Each action becomes lexeme
• Build grammar rule (consists of lexemes) for each task

Good example on Shneiderman p. 59.

UI emphasis is on visual display of user task objects and actions for direct manipulation interface (DMI -- Shneiderman invented that term, by the way).

Designer must:

1. identify and decompose task objects
2. identify task actions: "high-level intentions" (plans) and decompose into "intermediate goals and individual steps".
3. create interface objects and interface actions: metaphoric representations of the identified task objects and actions
4. make interface actions visible to users

Step 1 requires understanding of task and domain.

In step 2, granularity is important. If too low, user will have to perform too many steps to achieve task. If too high, user may not be able to find right combination of steps to achieve some tasks.

Step 3 is usually a constrained process. You have to map task objects and actions to existing widgets. The advantage is that syntax is simplified and easier to learn (basic click, drag, drop) and few feedback methods needed (movement, highlight)

Last reviewed: 25 September 1998