Human computer interaction

TOPIC 2

INTERACTION DESIGN
} }

Interaction design is about creating interventions in often complex situations using technology of many kinds including PC software, the web and physical devices Design involves:
} } }

achieving goals within constraints and trade-off between these understanding the raw materials: computer and human accepting limitations of humans and of design

} }

The design process has several stages and is iterative and never complete. Interaction starts with getting to know the users and their context:
} }

finding out who they are and what they are like ... probably not like you! talking to them, watching them

} Scenarios
} }

are rich design stories, which can be used and reused throughout design:
they help us see what users will want to do they give a step-by-step walkthrough of users' interactions: including what they see, do and are thinking

} Users
} } }

need to find their way around a system; this involves:

helping users know where they are, where they have been and what they can do next creating overall structures that are easy to understand and fit the users' needs designing comprehensible screens and control panels

Software life cycle

} Software

engineering is the discipline for understanding the software design process, or life cycle for usability occurs at all stages of the life cycle, not as a single isolated activity

} Designing

Requirements specification

Waterfall model
Architectural design

Detailed design

Coding and unit testing

Integration and testing

Operation and maintenance

Activities in life cycle

Requirements specification
designer and customer try capture what the system is expected to provide can be expressed in natural language or more precise languages, such as a task analysis would provide

Architectural design
high-level description of how the system will provide the services required factor system into major components of the system and how they are interrelated needs to satisfy both functional and nonfunctional requirements

Detailed design
refinement of architectural components and interrelations to identify modules to be implemented separately the refinement is governed by the nonfunctional requirements

Software development process

}

Software engineering provides a means of understanding the structure of the design process, and that process can be assessed for its effectiveness in interactive system design. Usability engineering promotes the use of explicit criteria to judge the success of a product in terms of its usability. Iterative design practices work to incorporate crucial customer feedback early in the design process to inform critical decisions which affect usability. Design involves making many decisions among numerous alternatives. Design rationale provides an explicit means of recording those design decisions and the context in which the decisions were made.

hci fits into software development process

} Software

engineering and the design process for interactive systems engineering design and prototyping

} Usability } Iterative } Design

rationale

Requirements specification

The life cycle for interactive system design a linear cannot assume
Architectural design

sequence of activities as in the waterfall model

Detailed design

Coding and unit testing

lots of feedback!

Integration and testing

Operation and maintenance

Usability engineering concept

The ultimate test of usability based on measurement of user experience Usability engineering demands that specific usability measures be made explicit as requirements Usability specification
} } } }

usability attribute/principle measuring concept measuring method now level/ worst case/ planned level/ best case usability specification requires level of detail that may not be possible early in design satisfying a usability specification does not necessarily satisfy usability

Problems
} } }

part of a usability specification for a VCR

Attribute: Backward recoverability
Undo an erroneous programming sequence Number of explicit user actions to undo current program No current product allows such As many actions as it takes to program-in mistake A maximum of two explicit user One explicit cancel action Measuring concept: Measuring method: Now level: an undo Worst case: Planned level: actions Best case:

Iterative design concept

}

Iterative design overcomes inherent problems of incomplete requirements Prototypes

} }

simulate or animate some features of intended system different types of prototypes

} } }

throw-away incremental evolutionary

Management issues
} } } }

time planning non-functional features contracts

design rationale
Process oriented } Historical records of design decisions, used during the actual design discussions } Examples:
}

Issue-based information system (IBIS)

Issue-based information system (IBIS)

} } }

basis for much of design rationale research process-oriented main elements:

issues
hierarchical structure with one root issue

positions
potential resolutions of an issue

arguments
modify the relationship between positions and issues
}

gIBIS is a graphical version

structure of gIBIS Argument Position

supports responds to

Issue
responds to specializes

Position

objects to

Argument

Sub-issue
questions

generalizes

Sub-issue Sub-issue

Design space analysis } structure-oriented

} QOC

hierarchical structure:

questions (and sub-questions)

represent major issues of a design

options
provide alternative solutions to the question

criteria
the means to assess the options in order to make a choice

} DRL

similar to QOC with a larger language and more formal semantics

the QOC notation

Option Question Option Criterion

Option

Criterion

Question

Consequent Question

Psychological design rationale

} to

support task-artefact cycle in which user tasks are affected by the systems they use to make explicit consequences of design for users identify tasks system will support are suggested to test task

} aims

} designers } scenarios } users

are observed on system claims of system made

} psychological

explicit
} negative

aspects of design can be used to improve next iteration of design

Benefit design rationale

Design rationale is information that explains why a computer system is the way it is. Benefits of design rationale
} } } } } }

communication throughout life cycle reuse of design knowledge across products enforces design discipline presents arguments for design trade-offs organizes potentially large design space capturing contextual information

Standard for interactive system design

} set

by national or international bodies to ensure compliance by a large community of designers standards require sound underlying theory and slowly changing technology standards more common than software high authority and low level of detail 9241 defines usability as effectiveness, efficiency and

} hardware

} ISO

Example Scenarios-movie player

}

Brian would like to see the new film Moments of Significance and wants to invite Alison, but he knows she doesnt like arty films. He decides to take a look at it to see if she would like it and so connects to one of the movie sharing networks. He uses his work machine as it has a higher bandwidth connection, but feels a bit guilty. He knows he will be getting an illegal copy of the film, but decides it is OK as he is intending to go to the cinema to watch it. After it downloads to his machine he takes out his new personal movie player. He presses the menu button and on the small LCD screen he scrolls using the arrow keys to bluetooth connect and presses the select button. On his computer the movie download program now has an icon showing that it has recognised a compatible device and he drags the icon of the film over the icon for the player. On the player the LCD screen says downloading

Ways of improving interface of scenarios

} communicate
}

with others

designers, clients, users

} validate
}

other models

play it against other models

} express
} }

dynamics

screenshots appearance scenario behaviour

Propose design decision for given scenarios

what is wanted interviews ethnography what is there vs. what is wanted evaluation heuristics scenarios task analysis analysis design dialogue notations prototype implement and deploy architectures documentation help guidelines principles precise specification

Steps

} requirements
}

what is there and what is wanted ordering and understanding what to do and how to decide

} analysis
}

} design
}

} iteration
}

and prototyping

getting it right and finding what is really needed!

} implementation
}

and deployment

making it and getting it out there

Principles to support usability in interactive design

}Learn

ability }Flexibility }Robustness

principles of learn ability

} the

ease with which new users can begin effective interaction and achieve maximal performance
determining effect of future actions based on past interaction history operation visibility

Predictability
} }

Synthesizability
} }

assessing the effect of past actions immediate vs. eventual honesty

Familiarity } how prior knowledge applies to new system } guessability; affordance Generalizability } extending specific interaction knowledge to new situations Consistency } likeness in input/output behaviour arising from similar situations or task objectives

principles of Flexibility

the multiplicity of ways the user and system exchange information

Dialogue initiative
} }

freedom from system imposed constraints on input dialogue system vs. user pre-emptiveness ability of system to support user interaction for more than one task at a time concurrent vs. interleaving; multimodality passing responsibility for task execution between user and system

Multithreading
} }

Task migratability
}

Substitutivity
} }

allowing equivalent values of input and output to be substituted for each other representation multiplicity; equal opportunity

Customizability
}

modifiability of the user interface by user (adaptability) or system (adaptivity)

principles of Robustness
} the

level of support provided the user in determining successful achievement and assessment of goal-directed behaviour
ability of user to evaluate the internal state of the system from its perceivable representation browsability; defaults; reachability; persistence; operation visibility

Observability
} }

Recoverability
} }

ability of user to take corrective action once an error has been recognized reachability; forward/backward recovery;

Responsiveness
} }

how the user perceives the rate of communication with the system Stability

Task conformance
} }

degree to which system services support all of the user's tasks task completeness; task adequacy

situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout. 2. Enable frequent users to use shortcuts. As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user. 3. Offer informative feedback. For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial. 4. Design dialog to yield closure. Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.

Schneiderman's eight golden 1. Strive for consistency. rules of interface design Consistent sequences of actions should be required in similar

5. Offer simple error handling. As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error. 6. Permit easy reversal of actions. This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions. 7. Support internal locus of control. Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders. 8. Reduce short-term memory load. The limitation of human information processing in shortterm memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.