Kursusgang 1 Oversigt Kurset Indhold HCI disciplinen Forml

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

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 2

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 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 3

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 over 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 operatørernes tåbelige fejl Charles Perrow (1984). Normal Accidents. Living with High-Risk Technologies. New York: Basic Books DIEB 4

En anden forklaring på hvorfor operatørerne lavede fejl 1. 2. 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. 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 5

HCI: Hvad er udgangspunkt og resultat • Udgangspunkt: analyseresultater Hvem: aktørtabel Hvad: klassediagram og funktionsliste Hvordan: brugsmønstre og tilstandsdiagrammer • Design og implementering af brugergrænsefladen • Resultat: et evalueret design af brugergrænsefladen DIEB 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) 6

Problemstillinger: HCI som disciplin (1) • • Brug af computere eller informationsteknologi i menneskelig aktivitet Temaer HCI Mennesker Computere Interaktion Brugbarhed: • Betydning • Vurdering DIEB • • • Computer Human 7

Problemstillinger: HCI som disciplin (2) • • ACM komite til design af HCI uddannelser (1992) Se supplerende litteratur på spiseseddel DIEB 8

DIEB-kurset: Formål og evaluering • Semestermål • Kursusformål Viden og erfaring med design og implementation af et edb system 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): • Evaluering 1. 2. 3. 4. DIEB Videregående HCI metode Værktøjer og biblioteker til implementering af brugergrænseflader Grundlæggende HCI begreber og brugbarhedstest (kun Dat 1) Programmering af brugergrænseflader (kun Inf 1) Evalueres gennem projektet. 9

Spiseseddel • • DIEB To versioner af Dix Fokus på de væsentlige afsnit 10

Designprocesser • • Vandfaldsmodellen Prototyping Specifikation eller prototype Spiralmodellen DIEB 11

Vandfaldsmodellen • • Det klassiske eksempel på en life cycle model Hvad er ideen? DIEB 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 12

Vandfaldsmodellen i Dix • • Svarer til den generelle vandfaldsmodel Lidt andre navne på faserne Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance DIEB 13

Relation til OOA&D Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance DIEB 14

Erfaringer med vandfaldsmodellen • Projektledelse er simpelt: Hvorfor? • Virker ikke i praksis! Tænk på et af jeres tidligere projekter som eksempel DIEB 15

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

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 DIEB 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”. 17

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

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 19

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: DIEB 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 20

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 Quality DIEB Too much Too little Too difficult Too unreliable Complexity Uncertainty 21

En simpel kontingenmodel Reference: Burns & Dennis DIEB 22

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 DIEB 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. 23

Typiske kontingensfaktorer (2) • Application Domain DIEB lack of clarity and consistency of the organizational tasks unclear boundaries of the application domain broadly diverse, complex, or unstructured tasks are continously shifting in response to a turbulent organizational environment • Problem Domain includes many complex objects with complex relationships includes many complex occurrences of events the boundaries of the problem domain are not clearly defined boundaries are continously changing due to environmental turbulence 24

Typiske kontingensfaktorer (3) • Computer System DIEB 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 25

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 26

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: DIEB Kontingensfaktorer Mombineret metode 27

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

- 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 29

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 DIEB 30

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. DIEB • • 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 of work in different wards. 31

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 on the physical situation in the three wards of the participants. • The rules of the method were not strictly observed: • It reflected how work was actually organized and carried out. • It was an attempt to describe human information processing instead of simple data transformation and the contents of the forms applied. DIEB 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 outgoing 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). 32

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 out 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 33

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

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 35

Alternativ ETHICS: Basics • • • Information system development method created by Enid Mumford. Effective Technical and Human Implementation of 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. ” DIEB 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 organisational job requirements which mould his experience. 36

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 DIEB 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 37

ETHICS: Discussion • Common reaction to ETHICS: it is impractical because • 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: • • Unskilled users cannot do the design properly. Management would never accept it. 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 38

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 39

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) DIEB 40