Kursusgang 1 Oversigt: Kurset - Indhold: HCI disciplinen - Forml og - - PowerPoint PPT Presentation

DIEB 1.1

Kursusgang 1

Oversigt:

• Kurset
• Indhold: HCI disciplinen
• Formål og evaluering
• Designprocesser
• Vandfaldsmodellen
• Prototyping
• Specifikation eller prototype
• Spiralmodellen
• Modellering af brugere
• Hvem er brugerne
• Modellering af krav
• Modellering af systembrug
• Tre eksempler

DIEB 1.2

Design, implementering og evaluering af brugergrænseflader

• Design af brugergrænseflader er baseret på den disciplin

inden for datalogi, som kaldes

• Menneske-maskin interaktion
• Human-computer interaction: HCI
• Designet består i at udforme computerens grænseflade så

mennesker kan interagere fornuftigt med den

• Hvorfor er det vigtigt?
• Hvad er udgangspunkt og resultat?
• Hvilke problemstillinger involverer det?

DIEB 1.3

HCI: Hvorfor er det vigtigt Operatørernes fejl? (1)

Three Mile Island, Harrisburg, Pennsylvania: 28. marts 1979 28/3-79, kl. 4.00 stopper dampturbinen automatisk. Operatørerne kontrollerer, at to kølevandspumper starter men er ikke klar over, at de pumper vand ind i lukkede rør, fordi to ventiler ved en fejl er lukkede. Der er to indikatorer på værkets enorme kontrolpanel, som viser ventilernes

• position. Men ventilerne er aldrig lukkede, og den ene indikator er dækket af

et reparationsskilt på knappen ovenover. 8 minutter senere bliver operatørerne klar over, at noget er galt, og de opdager

• fejlen. Men da er der allerede sket væsentlige skader. Da kølevandspumperne

ikke fungerer, koger dampgeneratoren tør, temperaturen stiger, og kontrolstængerne aktiveres automatisk for at stoppe kernereaktionen. Operatørerne aktiverer et manuelt kølesystem, men kan ikke lukke ventilen hertil, da der er lukket tilstrækkeligt meget vand ind. På kontrolpanelet viser en indikator, at der er afgivet en impuls til ventilen, så operatørerne tror, at den er lukket. Lidt senere styrer operatørerne på to trykmålere, der burde vise ensartede værdier, men gør det modsatte. De antager, at en af dem er i stykker men ved ikke hvilken.

DIEB 1.4

HCI: Hvorfor er det vigtigt Operatørernes fejl? (2)

De to målere var faktisk i orden, og kunne have indikeret for operatørerne, at en katastrofal situation var under udvikling. En tredie indikator kunne have ledt dem til den korrekte slutning, men den regnedes for uvæsentlig og var placeret forneden på bagsiden af et 2 meter højt kontrolpanel. I kontrolrummet var der op til 40 personer, tre lydalarmer aktiveret, og et stort antal af de 1600 kontrollamper lyste eller blinkede. Lydalarmerne blev ikke slået fra, fordi det også ville fjerne de relaterede informationer. Computeren var overbelastet, og det varede flere timer, før de relevante informationer blev skrevet ud. To en halv time senere blev den tredie indikator checket, og operatørerne nåede frem til den rigtige konklusion. De fik kølingen sat i gang, men det varede

• ver 14 dage, før man var helt sikker på, at der ikke ville ske en nedsmeltning

af reaktoren.

De efterfølgende undersøgelser konkluderede, at årsagen var

• peratørernes tåbelige fejl

Charles Perrow (1984). Normal Accidents. Living with High-Risk Technologies. New York: Basic Books

DIEB 1.5

En anden forklaring på hvorfor operatørerne lavede fejl

• 1. Mange fejl i menneske-maskin interaktion (HCI) skyldes dårligt

design, som ikke indtænker menneskers evner og fejlbarlighed. Dette fortolkes ofte som åbentbart forkert betjening og menneskelige fejl.

• 2. Godt design indtænker altid menneskers evner.

Hvordan kan man så gøre det bedre?

Ulykken på Three Mile Island kan forklares ved hjælp af to enkle begreber

• Mapping
• Relationen mellem det vi ønsker at gøre og det som det er muligt at udføre

Eksempler: komfur, British Midland

• Three Mile Island: Der var problemer med mapningen af deres intentioner over på

systemets funktioner: de manglede information og funktioner

• Feedback
• Information om udførelsen af en handling og dens resultat
• Three Mile Island: Der var i flere tilfælde ikke feedback

DIEB 1.6

HCI: Hvad er udgangspunkt og resultat

• Udgangspunkt:

analyseresultater

• Hvem: aktørtabel
• Hvad: klassediagram
• g funktionsliste
• Hvordan: brugsmønstre
• g tilstandsdiagrammer
• Design og

implementering af brugergrænsefladen

• Resultat:

et evalueret design af brugergrænsefladen

Cash Withdrawal

Use Case: Cash withdrawal is started by the account owner, when he wishes to use his credit card to withdraw cash from an ATM. The account owner inserts his card in an ATM, and is then requested via the screen to type his PIN code. The screen will either show a polite denial, the card will be rejected from the ATM and the process will be cancelled; or the screen will show a menu requesting the account owner to choose an amount of money by typing on the ATM’s keyboard. A new screen requests the account owner to approve the transaction. If the transaction is not approved the account owner is again requested to type an amount. Otherwise the use case ends by the ejection of the card, and the desired amount of money being paid. Objects: (to be added later) Functions: (to be added later)

DIEB 1.7

Problemstillinger: HCI som disciplin (1)

• Brug af computere eller

informationsteknologi i menneskelig aktivitet

• Temaer
• HCI
• Mennesker
• Computere
• Interaktion
• Brugbarhed:
• Betydning
• Vurdering

Computer Human

DIEB 1.8

Problemstillinger: HCI som disciplin (2)

• ACM komite til

design af HCI- uddannelser (1992)

• Se supplerende

litteratur på spiseseddel

DIEB 1.9

DIEB-kurset: Formål og evaluering

• Semestermål
• Viden og erfaring med design og implementation af et edb-system
• Kursusformål
• Give indsigt i principper, retningslinier og omgivelser til design og

implementation af brugergrænseflader.

• Forstå de teorier og erfaringer, der udgør grundlaget for principper og

retningslinier.

• Opnå praktisk erfaring med, hvordan design og implementering af en

grafisk brugergrænseflade kan udføres.

• Dele (1 modul hver):
• 1. Videregående HCI-metode
• 2. Værktøjer og biblioteker til implementering af brugergrænseflader
• 3. Grundlæggende HCI-begreber og brugbarhedstest (kun Dat1)
• 4. Programmering af brugergrænseflader (kun Inf1)
• Evaluering
• Evalueres gennem projektet.

DIEB 1.10

Spiseseddel

• To versioner

af Dix

• Fokus på de

væsentlige afsnit

DIEB 1.11

Designprocesser

• Vandfaldsmodellen
• Prototyping
• Specifikation eller prototype
• Spiralmodellen

DIEB 1.12

Vandfaldsmodellen

• Det klassiske eksempel på en life-

cycle model

• Hvad er ideen?
• Udviklingsprocessen gennemløber

et antal faser

• Hver fase har et klart defineret

produkt

• Produktet af en fase valideres i

forhold til bestemte kriterier

• Produktet af en fase er

udgangspunktet for den næste fase

DIEB 1.13

Vandfaldsmodellen i Dix

• Svarer til den generelle

vandfaldsmodel

• Lidt andre navne på

faserne

Requirements specification Operation and maintenance Architectural design Detailed design Coding and unit testing Integration and testing

DIEB 1.14

Relation til OOA&D

Requirements specification Operation and maintenance Architectural design Detailed design Coding and unit testing Integration and testing

Krav til brug Model Beskrivelse af komponenter Beskrivelse af arkitektur

Design af komponenter Design af arkitektur Analyse af anvendelses-

• mråde

Analyse af problem-

• mråde

DIEB 1.15

Erfaringer med vandfaldsmodellen

• Projektledelse er simpelt:

Hvorfor?

• Virker ikke i praksis!

Tænk på et af jeres tidligere projekter som eksempel

DIEB 1.16

Specifikationer: Transfer of Knowledge (Nonaka)

• Et nøglebegreb i knowledge management
• Spørgsmål: hvordan kan man overføre viden til andre?
• Skelner mellem ”explicit knowledge” og ”tacit knowledge”

From

Tacit knowledge Explicit knowledge

To

Tacit knowledge Explicit knowledge

Internalization Converting explicit knowl- edge into tacit knowledge; learning by doing; studying previously captured explicit knowledge (manuals, documentation) to gain technical know-how Socialization Transfering tacit knowledge through shared experiences, apprenticeships, on-the-job training, talking at the water cooler Externalization Articulating and thereby capturing tacit knowledge through use of metaphors, analogies, and models Combination Combining existing explicit knowledge through exchange and synthesis into new explicit knowledge

DIEB 1.17

Problemer med vandfaldsmodellen

• Baserer sig udelukkende på

specifikationer, men de er vanskelige både at lave (overførsel af viden) og forstå

• Svært at uddestillere

brugernes viden om deres arbejde

• Mange negative effekter af de

udviklede systemer

• Krav ændrer sig over tid
• Ikke-tekniske aspekter er

svære at beskrive

• Tilbagekobling bliver

nødvendigt

• Fungerer kun, når vi ved hvad

vi vil have, og vi kan beskrive det præcist og utvetydigt

Effects (Zuboff)

• Sensory satisfaction with handling of

physical objects (forms, books, etc.) was missing.

• Experienced less interaction with

humans (customers, supervisors) and more with computers.

• Did not fully understand where data on

their screens came from and what it meant.

• Reduced feeling of certainty and control

because of lack of concreteness (no names, no history, etc.).

• Less skill and knowledge of insurance

claims required (the computer knows it).

• More computer skills required.
• Routine work, just ”pushing buttons”.

DIEB 1.18

Prototyping

• Brug af prototyper er et

andet alternativ til vandfaldsmodellen

• Hvad er en prototype?
• En prototype realiserer

bestemte egenskaber ved et system

• Brugerne kan arbejde og

eksperimentere med den for at illustrere deres krav

• Der findes forskellige former

for prototyper

• De bruges på forskellige

tidspunkter i udviklingsprocessen

• Quick and dirty

Early implementation without prior analysis and design. Revised until the users are satisfied. Revisions become complicated and maintenance is very expensive.

• Throw-away

Development in order to enquire into and express requirements. Is often described as a ”running” requirements specification.

• Design-driven

An implementation of a design which is as close to the final systems as possible. Often used for technical experiments, e.g. with the technical platform.

• Mock-up

A cardboard or similar non-executable model of the system.

• Evolutionary

A modifiable, running model of part of a

• system. Is gradyally developed into the

final version which becomes the system.

DIEB 1.19

Eksempel: Mock-up

• UTOPIA project
• Tools for graphical workers for page

make-up and image processing.

• Oppose the deskilling that occurred

when computers were introduced.

• Started describing requirements to a

tool, but that was too abstract for the graphical workers.

• Made mock-ups to simulate how the

computerized system would work.

• The mock-ups were made of cardboard

boxes, overhead projectors and projector screens.

• Simulation involved people performing

the operations of the computer.

• A prototype was developed from the

experiences with the mock-ups.

DIEB 1.20

Specifikation eller prototype

• Vi står over for to mulige arbejdsformer: vandfaldsmodellen

(specifikationsbaseret) eller prototyping

• Hvordan vælger vi?
• Hvilken arbejdsform skulle vi vælge til udvikling af:
• Et system til registrering af køb af øl og sodavand i Kaffestuen
• Et mobilt system til køb af biografbilletter
• Et system til styring af et atomkraftværk

DIEB 1.21

Kontingensfaktorer

• Relevansen af specifikationsbaserede metoder og

prototyping kan afgøres ud fra kontingensfaktorer:

• Kompleksitet
• Usikkerhed

Kan simpelt defineres ud fra den tingængelige information:

Quantity Too much Too little Quality Too difficult Too unreliable Complexity Uncertainty

DIEB 1.22

En simpel kontingenmodel

System Life Cycle Prototyping Mixed Methodology Prototyping High Low High Low Complexity Uncertainty

Reference: Burns & Dennis

DIEB 1.23

Typiske kontingensfaktorer (1)

• System developers
• knowledge about the application

and problem domains

• ability to make a complete and

consistent design specification

• experiences with specification of

requirements in co-operation with prospective users

• ability to implement the

requirements with the available technical environment.

• Users
• ability to describe the

application and problem domains in a logical and structured fashion

• ability to specify requirements

in cooperation with the systems developers

• experience with systems

development and prototyping

• understanding of design

specifications and the available computer technology

• ability to review the proposed

design specifications of the computer system.

DIEB 1.24

Typiske kontingensfaktorer (2)

• Application Domain
• lack of clarity and consistency
• f the organizational tasks
• unclear boundaries of the

application domain

• broadly diverse, complex, or

unstructured tasks

• tasks are continously shifting in

response to a turbulent

• rganizational environment
• Problem Domain
• includes many complex objects

with complex relationships

• includes many complex
• ccurrences of events
• the boundaries of the problem

domain are not clearly defined

• boundaries are continously

changing due to environmental turbulence

DIEB 1.25

Typiske kontingensfaktorer (3)

• Computer System
• ambiguous and inconsistent

computer system requirements exist

• the computer system entails a

database with interactive, transaction processing and reporting

• there are specific computer

system performance and network data communication requirements

• the computer system to be

developed is partly incompatible with the development environment

• Development Environment
• unreliability in the target

computing machinery or systems software

• unreliability in the development

computing machinery or software

• insufficient or ambiguous

documentation of the development environment

• linkages to externally controlled

technologies like standardized internet clients or servers

DIEB 1.26

Kombineret metode: Spiralmodellen

• Spiralmodellen kombinerer

prototyping og vandfaldsmodellen

• Baseret på cykler, som indeholder

fire typer aktivitet

• Den radiale dimension svarer til

den samlede indsats på et givet tidspunkt

• Vinkeldimensionen svarer til hvad

der er opnået I en enkelt cykel.

• Ved hver passage af x-aksen

(klokken 3) tages en beslutning

• Beslutningen baserer sig på

risikoanalyse

• Når alle risici er eliminerede, fases

der ud I en vandfaldsmodel

DIEB 1.27

Metoder til HCI-design

• ”Metode” – hvad er det?
• Hvad skal vi med metoder?
• ”Metodiske anvisninger” – blødere
• Dix: fire kategorier af metodske anvisninger for

designprocessen:

• Life-cycle eller vandfaldsmodellen
• Designregler (senere)
• Usability engineering (senere)
• Prototyping
• Problem: hvordan skal vi vælge og kombinere metodiske

anvisninger? To løsninger:

• Kontingensfaktorer
• Mombineret metode

DIEB 1.28

Modellering af brugere

• Hvorfor er det nødvendigt?
• Hvem er brugerne: stakeholder analysis
• Modellering af krav
• systembeskrivelse i Florence-projektet
• Sociotekniske metoder: ETHICS
• Modellering af systembrug
• GOMS
• Keystroke

DIEB 1.29

• fordi systemudviklerne ikke forstår

brugerne og deres arbejde

• Jeg har brug for hjælp til at udfylde

min SU-ansøgning

• Vi starter på Aalborg Universitets

web-sted:

• Vi finder aldrig den nødvendige

hjælp; kun samlinger af regler og bestemmelser

DIEB 1.30

Hvem er brugerne

• Dix foreslår stakeholder

analysis

• Eksempel: airline booking

system

• Primary stakeholders: travel

agency staff, airline booking staff

• Secondary stakeholders:

customers, airline management

• Tertiary stakeholders:

competitors, civil aviation authorities, customers’ traveling companions, airline shareholders

• Facilitating stakeholders: design

team, IT department staff

• Primary stakeholders er dem vi

er mest interesserede i

• Svarer til aktører i OOA&D

System Problem domain Application domain User

DIEB 1.31

Eksempel: System Description in the Florence Project

• Analysis of work conducted in

a three-day seminar where both nurses and system developers participated.

• The purpose of the seminar

was to establish a detailed and precise understanding of nursing.

• The flow of data was to be
• described. At the seminar the

participants were trained in making data flow diagrams (Yourdon 1982), and were then supposed to apply this tool to describe their work.

• Three groups of nurses were

established: A, B, and C.

• Each group included nurses

from three different wards and a systems developer.

• An external consultant with

extensive development experience circulated between the three groups.

• The nurses’ experience was

chosen as the starting point. While working with the descriptions it became clear that their experience was different:

• Varying degrees of skill.
• Differences in the organization
• f work in different wards.

DIEB 1.32

Group A

• In group A, the work was mainly

led by the nurses. The systems developer was primarily acting as an advisor.

• The description concentrated on

relations between the manual routines of nursing and it focused

• n the physical situation in the

three wards of the participants.

• It reflected how work was actually
• rganized and carried out.
• It was an attempt to describe

human information processing instead of simple data transformation and the contents of the forms applied.

• The rules of the method were not

strictly observed:

• A special signature for informal

communication between various persons was introduced.

• The routines were not described in

the exact way in which the incoming data flows were transformed to the

• utgoing data flows. Instead, the

group focused on criteria that were influencing the major decisions.

• Various time consuming activities

were included in the description, even though they were not of direct importance to the data transformation.

• The description also included the

nurses’ relation to customers and local management (the manager of the ward).

DIEB 1.33

Group B and C

• The descriptions made by group B and group C differed

much from that of group A.

• In both groups, the system developer was the most

dominant person.

• Much weight was attached to observation of the rules and

guidelines of the method, and in this sense the descriptions produced were more correct.

• The participants were surprised that these two descriptions turned
• ut to be very different anyway.
• In group B, there was an experienced nurse, and her

understanding of work in the ward in which she was employed influenced the description very much.

• In group C, the participants were more equal. This implied that

their description gave a more generalized picture of the work in the three wards.

DIEB 1.34

Comparison

• On the last day of the seminar,

the descriptions were presented.

• The nurses stressed that all

three descriptions gave a strongly biased impression of “actual” nursing.

• Group A gave the most

relevant picture of their work.

• The consultant emphasized the

quality of the description from group C.

• After the seminar, system

developers, who did not participate in the seminar, were presented to the descriptions.

• They had problems in

understanding the descriptions.

• This especially applied to the

description produced by group A but also to the descriptions produced by group B and C.

DIEB 1.35

Florence Results

• The descriptions were only applicable to a limited extent.
• To supplement them, a number of prototypes were

developed.

• A prototype was developed in collaboration with the nurses

at two different hospital wards.

DIEB 1.36

Alternativ ETHICS: Basics

• Information system development method

created by Enid Mumford.

• Effective Technical and Human Implementation
• f Computer-Based Systems.
• Focus on the interaction of technology and

people

• Result: work systems that are both technically

efficient and have social characteristics which lead to high job satisfaction.

• ”All change involves some conflicts of interest.

To be resolved, these conflicts need to be recognised, brought out into the open, negotiated and a solution arrived at which largely meets the interests of all the parties in the situation ... successful change strategies require institutional mechanisms which enable all these interests to be represented, and participation provides these.” Job satisfaction: the attainment of a good 'fit' between

• What the employee

is seeking from his work: job needs, expectations and aspirations

• What he is required

to do in his job: the

• rganisational job

requirements which mould his experience. Job satisfaction: the attainment of a good 'fit' between

• What the employee

is seeking from his work: job needs, expectations and aspirations

• What he is required

to do in his job: the

• rganisational job

requirements which mould his experience.

DIEB 1.37

• ne copy

• ne copy

ETHICS: Methodology

1.

Why Change?

2.

System boundaries

3.

Description of the existing system (5 different levels, operative tasks to whole system)

4.

Definition of key objectives

5.

Definition of key tasks

6.

Definition of key information needs

7.

Diagnosis of efficiency needs

8.

Diagnosis of job satisfaction needs

9.

Future analysis

• 10. Specifying and weighting efficiency and

job satisfaction needs and objectives

• 11. The organisational design of the new

system

• 12. Technical options
• 13. The preparation of a detailed job design
• 14. Implementation
• 15. Evaluation

Step 4 - Examples of key objectives of the Purchase Invoice Dept.

• Key objectives are to ensure that the Company obtains goods and services from suppliers which

are of the right quality and price and arrive on the date promised. Also to provide a satisfying, stimulating work environment for Purchase Invoice and Treasurer's Dept. staff.

• Relationships with suppliers are often very poor due to inaccurate or delayed payment of

suppliers accounts. This is affecting the quality of the supplier's service. Step 5 - Examples of key tasks of the Purchase Invoice Dept.

• The fast, correct payment of suppliers accounts
• The fast, correct answering of suppliers queries
• The fast, accurate notification to suppliers' of rejected goods and requests for

financial compensation

• The monitoring and improvement of the suppliers' service

Step 6 - Example of key information needs

• Operating Information
• Information on suppliers and the state of their accounts
• Information on payments made
• Problem prevention/solution information
• Accurate goods received information
• Which suppliers have not been paid and why
• Co-ordination information
• Which receipts have been transferred from Purchase Invoice to Treasurer's Dept. for

payment

• Development Information
• Which suppliers are antagonistic to the Company and why
• Control information
• The extent to which goods and services provided by suppliers are meeting company

quality standards

DIEB 1.38

ETHICS: Discussion

• Common reaction to ETHICS: it is impractical because
• Unskilled users cannot do the design properly.
• Management would never accept it.
• To reaction 1: Mumford argues that users can and do, design
• properly. They need training and help, but this can be provided

relatively easily. More importantly, they have the skills of knowing about their own work and system, and have a stake in the design.

• To reaction 2: Mumford’s experience is that managers have often

welcomed participation and can be convinced of its benefits.

• Examples:
• A group of secretaries at Imperial Chemical Industries (ICI) designed

new work systems for themselves in the wake of the introduction of word-processing equipment.

• A group of purchase clerks helped design a major on-line computer

system.

• The first major use of ETHICS in the development of a large system

was DECs XSEL, an expert system for their sales offices, used to configure DEC hardware systems for particular customers.

DIEB 1.39

Modellering af systembrug

• GOMS og Keystroke er teknikker til modelleringaf brugen af

et system

• De kan bruges i design
• De bruges også til evaluering, hvor man ”teoretisk” regner

ud, hvor lang tid det tager at udføre en funktion – dette sammenlignes så med virkelige observationer

DIEB 1.40

Tre eksempler

• Indlæggelse af en patient (hospital)
• Kommunikation i et sikkerhedskritisk domæne (kraftværk)
• Samarbejde om beslutningstagning i en dynamisk situation

(opmænd)