HCI - Human Computer Interaction II

Theories, Principles, and Guidelines

emerging designers follow some guidance

user interface displays could be improved

High Level Theories

explanatory

predictive

Taxonomies

input devices

tasks

structured vs unstructured, controllable vs immutable personality styles

convergent vs divergent, field dependent vs independent

technical aptitudes

spatial visualization, reasoning

user experience levels

novice, knowledgeable, expert

user-interface styles

menus, form filling, commands

Many theories...

compete for attention

continuous refinements

extended by critics

applied by eager and hopeful designers

implementers must keep up with developments not only in s/w tools but also in theories

Subject satisfaction

researchers in media and advertising recognize the difficulty in predicting emotional reactions

theoretical predictions are combined with intuitive judgements + extensive market testing

broader theories: small group behavior,organizational dynamics, sociology of knowledge

barriers to new technology may be analyzed via social psychology and anthropology

coming up with a god theory is not simple

Conceptual, semantic, syntactic and lexical model

Foley & Van Dam (1970)

conceptual: user’s mental model of the interactive system

a line editor models a word processor program

semantic: describes meanings conveyed by the user’s command i/p + comp. display

syntactic: how the units are assembled into a complete sentence

lexical deals with device dependencies + precise mechanisms by which a user specifies the syntax

Advantages

the above model is clear since it is top-down

matches the s/w architecture

allows useful modularity during design

designers move from conceptual to lexical and carefully record mappings between these 2 levels

Keystroke-level model

attempts to predict performance times for error-free task execution

different activities are considered: key-stroking,pointing, homing, drawing, thinking, waiting for system response

the sum of all insured times provides performance times

these models hold for experienced users and error-free performance

no emphasis on learning, problem solving, error handling, subjective satisfaction and retention

GOMS:goals, operators, methods & selection rules

Card, Moran and Newell (1980-3)

users formulate goals (edit documents) and subgoals (insert word) by using methods or procedures

move cursor by following a sequence of arrow keys

operators are elementary perceptual, motor or cognitive acts whose execution is necessary to change any aspect of the user’s mental state or to affect the task environment
press up-arrow key, move hand to mouse, recall file name...

methods-selection rules these rules are used to choose one possible way of achieving the task

Again on GOMS

Kieras and Polson (1985)

Kieras and Polson formalized GOMS by using production rules

via these rules predictions of learning and performance time were given when interacting with a text editor through 5 different actions:

insert, delete, copy, move and transpose

Natural GOMS

Kieras (1988)

"the GOMS analysis did not explain how the notation works, it is clumsy, detached from the underlying cognitive theory"

GOMS was refined into Natural GOMS Language (NGOMSL)

Find when the task-analyst must make: a judgement call

assumptions about how the users view the system
bypass a complex hard-to-analyze task
check for consistency

Method descriptions

Elkerton and Palmiter (1991)

They applied NGOMSL to implement on-line Help

introduced method descriptions breaking down the actions necessary to accomplish a goal into steps

decide, accomplish, report goal accomplished

introduced selection rules whenever alternative methods exist

empirical evaluation with 28 subjects proved that NGOMSL version of help halved the time to complete information searches

Stages of action

Norman (1988)

7 stages of action to model HCI:

forming the goal
forming the intention
specifying the action
executing the action
perceiving the system state
interpreting the system state
evaluating the outcome

similar to Foley and van Dam’s separation of concerns:

conceptual intention - reformulation into commands
syntax construction - production of lexical tokens

Norman’s contribution

taking care of

cycles of action
evaluation

the process of action is considered dynamically (i.e. in evolution)

alternative models only consider what is in the user’s mind at execution time

Two new concepts:

gulf of evolution which separates user’s intentions from allowable actions plus
gulf of evaluation separating system’s representation from user’s expectation

Four principles

Norman’s four principles for good design

state and action alternatives should be visible
there should be a good conceptual model with a consistent system image
the interface should include good mappings that reveal the relationships between stages
the user should receive continuous feedback

Study errors - they often occur when moving from goals to intentions to actions and to executions

Exploring the interface

Polson and Lewis (1990)

when users explore an interface and try to accomplish their goals, they pin-point 4 critical points where failures may occur:

users can form an inadequate goal
users might not find the correct interface object because of an incomprehensible label or icon
users may not know how to specify or execute a desired action
users may receive inappropriate or misleading feedback
Franzke (1995)
the bottom 3 failures may be prevented by improved design or time consuming experience

Consistency through grammars

consistency (coerenza!) is elusive with multiple levels

it may be even positive to be inconsistent !

a command language or set of actions should be:

orderly - predictable - describable by a few rules
easy to learn - easy to retain

these overlapping concepts are shown by an example showing 2 kinds of inconsistencies...

Consistencies-Inconsistencies

Consistent +	Inconsistent A	Inconsistent B
delete/insert character	delete/insert character	delete/insert character
delete/insert word	remove/bring word	remove/insert word
delte/insert line	destroy/create line	delete/insert line
delte/insert paragraph	kill/birth paragraph	delte/insert paragraph

all actions are the same in + but vary in version A

the inconsistent verbs are all acceptable but their variety suggests they will be more difficult to learn, to remember, will slow down users, will be error-prone

version B is more malicious: only one inconsistency (remove) but may be easier to remember...

Task Action Grammar

Payne and Green (1986)

expanding on Reisner (1981) they addressed:

multiple levels of consistency (lexical, syntactic and semantic)
aspects of completeness (complete set of tasks

once the full set of task-action mappings is written down, the grammar of the command language can be tested for completeness

Command Language Grammar

e.g. a TAG definition of cursor control:

move-cursor-one-character-forward
[Direction = forward, Unit=char]
move-cursor-one-character-backward
[Direction = backward, Unit=char
move-cursor-one-word-forward
[Direction =forward, Unit=word]
move-cursor-one-word-backward
[Direction =backward, Unit=word]

High rule schemas describing the commands syntax

Rules

These schemas generate a consistent grammar

move cursor one character forward	CTRL-C
move cursor one character backward	ESC-C
move cursor one word forward	CTRL-W
move cursor one character backward	ESC-W

Again on consistency

notation and approach (for TAGS) are flexible and extensible

consistency is subtle, multiple levels, may also hinder some implementation details - Reisner (1990)

understanding consistency is instrumental for implentors, researchers and designers - Grudin (1989)

Widget level theories

reductionism approach may be fallacious, i.e. details may become misleading in the evaluation of a GUI

validity of simple summations of time periods may be questionable

alternatively, one may use a model based on widgets (interface components)

layout appropriateness (frequently used widgets should be adjacent, left-to-right sequence should be matched to the task-sequence description,...)

higher-level patterns appear by widget composition

Object-Action Interface Model

syntactic-semantic model of human behaviour - Shneiderman (1980)

this model describes programming, database manipulation facilities, direct manipulation

a distinction was made between

acquired semantic concepts (delete - copy)

and

rote-learned syntactic concepts (function keys)

the first were stable in memory and well organized, the second were arbitrary and had to be rehearsed to be maintained

Objects and Actions: differences

task domain concepts (stock-market portfolios)

computer domain concepts (folders)
OAI model

GUIs have replaced command languages substituting complex syntax with direct manipulation

emphasis is now on the visual display of user tasks objects and actions

stock-market portfolios could be represented by leather folders with engraved certificates
actions represented by trashcans, shelf icons,etc

Object-Action design

action syntax is easier than command language expressions even if precedence rules must be known (file/folder to the trashcan and not viceversa)

mouse clicking, mouse retention, gestures also obey rules

design starts with a clear identification of the task/s - including the universe of real world objects + user intentions + actions required

high level task objects could be stock-market statistics, a photo library, a scientific journal

Task and Interface concepts

Task

OAI Model

the two pictures show

the objects of the universe (shelves, cupboards, books in a library)
the actions satisfying the intentions of the user
the objects of the interface visualizing (through pixels)
the actions to be performed by the user (via mouse clicks)

in this way, the interface is easy to learn and to use since it maps the world domain with the metaphoric domain

it focuses on task objects and actions and on interface objects and actions

OAI reflects design at high level as when programmers use widgets in usr-interface-building tools

standard widgets have a simple syntax:click, double-click, drag, drop

OAI follows the object-oriented approach

Hierarchies

when problems are complex: break them down!

intentions may be decomposed into smaller action steps

building: surveying, building the frame, raising the roof
symphony: movements, measures, notes
baseball: innings, outs, pitches

people learn task objects & actions independently of their implementation

people learn by studying & practicing

Application domains

designers must learn via

training courses
books
interviews

designers generate a hierarchy of objects and actions to model the user’s tasks

the model is the basis for designing the interface objects and actions + their representation in pixels on the screen, in physical devices or audio cues

users must firstly become proficient in their task domain

next, they may learn the equivalent computer program

Interface objects

the interface includes hierarchies of objects and actions at high and low levels

storage is a high level concept: computers store information

by means of the directory and files (objects)
a directory is made of entries (lower level objects)
each entry is made of a name, length, creation date, owner, access control,...
each file has lines, fields, characters, fonts, pointers, binary numbers,...

Interface actions

both high and low level actions like

permissible file types, sizes, error conditions, responses to h/w or s/w errors
and finally...clicking on a pull-down menu

Familiar examples

a designer will build interface objects and actions based on familiar examples

tune those objects and actions to fit the task

for a real estate business, geographical maps and houses will be available as well as their properties, cost, distance, size and location (familiar concepts) will be mapped on the screen

to explain "saving a file", icons representing a disk drive and the directory will show where the file will be stored

a demonstration will be performed to enable the user a logical understanding of the process

Metaphors

they map a meaning from one known domain to another one

they may be abstract, concrete or analogical

they are used to avoid long, tiresome training of new concepts

most icons user representations which are visual metaphors (which, in itself, is a metaphor)

interface objects and actions have a logical structure which is easy to memorize in a stable way

Bottom-up modelling

task objects made explicit

user’s task actions laid out clearly

next, interface objects are identified

and interface actions follow...with the OAI model

many years ago users had to remember device dependent details (format instruction in Fortran, number of i/o device to be deployed,etc.)

or, which action deletes a character: delete, backspace, CTRL-H, CTRL-G, CTRL-D, rightmost mouse button or Escape

which action inserts a new line after the third text line: CTRL-I, INSERT KEY, I3, I 3, 3I,...

Remembering...

problem 1: details vary across computer platforms

problem 2: arbitrariness of minor design features reduces the effectiveness of paired-associate learning

repeated rehearsals for rote memorization

moreover, syntactic knowledge is hampered by the lack of a hierarchical or modular structure to cope with complexity

Example

within e-mail:

press RETURN to terminate a paragraph
CTRL-D to terminate a letter
Q to quit the e-mail subsystem
logout to terminate the session

for the novice these similar termination commands bear no logical connection

Syntactic knowledge

it is system-dependent

different

keyboards, commands, function keys, sequences of actions

some overlap may exist (e.g. with arithmetical operations)

s for sending a message - s for saving a file - ...

to overcome these problems, new interfaces show familiar objects and actions representing the user’s task objects and actions

standard widgets are easily available

[Previous] [Home Page] [Next]