Kursusgang 6. - Formål og evaluering - Hidtidige kursusgange - Resten af kurset. Oversigt: Kursusforløb:

Transkript

1 Kursusgang 6 Oversigt: Kursusforløb: - Formål og evaluering - Hidtidige kursusgange - Resten af kurset Metoder til HCI-design Modellering af brugere i design Design af brugerflader 6.1

2 Formål og evaluering Semestermål - Viden og erfaring med design og implementation af et edb-værktøj Kursusformål - Give indsigt i principper, retningslinier og omgivelser til design og implementation af grafiske 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. Grundlæggende HCI og brugbarhedstest (kun Dat1) 2. Videregående HCI 3. Værktøjer og biblioteker til implementering af brugergrænseflader 4. Programmering af brugergrænseflader (kun Inf1) Evaluering - Evalueres gennem projektet. Design af brugerflader 6.2

3 Hidtidige kursusgange Grundlæggende HCI: Menneskelig informationsbehandling - Kognitionsteori - Gestalt-love Computeren - Input/output-enheder Interaktion - Interaktionsformer Interaktionsdesign - Paradigmer - Principper Andre teknikker til test (udførelse) Brugbarhedsevaluering: Definition af brugbarhed Placering i udviklingsprocessen Aktiviteter: - Etablering (rammer) - Planlægning (testrapport) - Forberedelse (situation) - Udførelse (tænke-højt) - Fortolkning (problemer) Præsentation Design af brugerflader 6.3

4 Resten af kurset Hidtil Resten Design af brugerflader 6.4

5 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 - Usability engineering - Prototyping Problem: hvordan skal vi vælge og kombinere metodiske anvisninger? To løsninger: - Kontingensfaktorer - Mombineret metode Design af brugerflader 6.5

6 Vandfaldsmodellen Det klassiske eksempel på en lifecycle 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 Design af brugerflader 6.6

7 Vandfaldsmodellen i Dix Hvad betyder faserne? Hvad er produkterne? Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance Design af brugerflader 6.7

8 Relation til OOA&D Requirements specification Architectural design Analyse af problemområde Krav til brug Analyse af anvendelsesområde Detailed design Model Design af komponenter Beskrivelse af komponenter Coding and unit testing Beskrivelse af arkit ektur Integration and testing Design af arkitektur Operation and maintenance Design af brugerflader 6.8

9 Erfaringer med vandfaldsmodellen Projektledelse er simpelt: Hvorfor? Virker ikke i praksis! Design af brugerflader 6.9

10 Problemer med Life-cycle modellen Baserer sig udelukkende på specifikationer, men de er vanskelige at lave og forstå Mange negative effekter af de udviklede systemer Svært at uddestillere brugernes viden om deres arbejde Krav ændrer sig over tid Ikke-tekniske aspekter er svære at beskrive Fungerer kun, når vi ved hvad vi vil have, og vi kan beskrive det præcist og utvetydigt Tilbagekobling bliver nødvendigt 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. Design af brugerflader 6.10

11 Designregler En anden måde at støtte designerne på Eksempel: en standard for GUI-design Går fra generelle principper til specifikke anvisninger Variende krav om, hvor meget de skal følges Design af brugerflader 6.11

12 Usability engineering Forsøg på at specificere, hvad brugbarhed konkret er i et givet projekt Eksempel: videobåndoptager (VCR) Specifikationen sammenholdes med kriterier for brugbarhed Design af brugerflader 6.12

13 Prototyping Brug af prototyper er et andet alternativ til life-cycle modellen 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. Design af brugerflader 6.13

14 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. Design af brugerflader 6.14

15 Kontingensfaktorer Hvad gør man med de mange metoder? Relevansen af life-cycle 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 Design af brugerflader 6.15

16 En simpel kontingenmodel Complexity High Low System Life Cycle Prototyping Mixed Methodology Prototyping Low High Uncertainty Reference: Burns & Dennis Design af brugerflader 6.16

17 Kombineret metode 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 Design af brugerflader 6.17

18 Modellering af brugere i design Hvorfor er det nødvendigt? Interaktive systemer Modellering af krav - Sociotekniske metoder: ETHICS Modellering: systembeskrivelse i Florence Design af brugerflader 6.18

19 The Payroll System: Computerizing A classical IS. All employees are paid on a monthly basis. The monthly payment is calculated manually. Computerization: The IS replaces the manual work in the payroll department. The working hours are registered manually and then typed onto a tape. Batch mode: the data processing calculates the payment for the month and updates the accumulated information. hours of work in current month for each employee Typing Information about all employees: Salary rate Tax rate Accumulated year-to-date Update hours of work in current month for all employees Data processing Payments Design af brugerflader 6.19

20 Consequences of the Payroll System The first generation of administrative information systems replaced repetitive manual work (e.g. payroll). The information system was integrated into and used by the department that performed the original manual task. A new typing function was introduced, often conducted in a separate department or office. Benefits: - Reduction of simple manual work. - Faster processing. - More accurate calculations. Problems: - A group of clerical workers become superfluous. - Work in the typing department is extremely repetitive. - New type of errors because input data are not checked when output data seem unreasonable. - Data are only correct right after processing. Design af brugerflader 6.20

21 The Payroll System: Modernizing A second generation of administrative systems that modernized the first generation. Going from batch processing to on-line: - Data are captured at their source: Employees enter their working hours directly into the system. - Data are processed when they are needed. The information system becomes the communication channel between departments. Advantages: - The database is always up to date. - Capture of data is integrated into the work that produces the data. - Fewer errors because data are registered in their context. Organizational changes: - The typing department becomes superfluous. - More people (all employees) are using computers which may require more training. - New relationships between departments. Design af brugerflader 6.21

22 Systemudviklerne forstår ikke 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 Design af brugerflader 6.22

23 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. Job Job satisfaction: satisfaction: the the attainment attainment of of a good good 'fit' 'fit' between between What What the the employee employee is is seeking seeking from from his his work: work: job job needs, needs, expectations expectations and and aspirations aspirations What What he he is is required required to to do do in in his his job: job: the the organisational organisational job job requirements requirements which which mould mould his his experience. experience. Design af brugerflader 6.23

24 Step 3. Example of input/output analysis of one section of a Purchase Invoice Dept. This department checks and passes for payment the invoices of firms who supply goods and services the Company. Inputs Outputs ETHICS: Methodology Mail Clerks sort invoices VAT clerks edit invoices Comp operator check invoices Invoice is microfilmed one copy one copy data prep Commercial or Production Invoice Clearance Sections Here invoices are matched with GRNs Goods Received Notes 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 Goods received notes are batched and checked 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. data prep 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 Design af brugerflader 6.24

25 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. Design af brugerflader 6.25

26 System Description in Florence 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 of work in different wards. Design af brugerflader 6.26

27 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. 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. 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 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). Design af brugerflader 6.27

28 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. Design af brugerflader 6.28

29 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. Design af brugerflader 6.29

30 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. Design af brugerflader 6.30

31 Hvilke typer information om brugere modelleres Information is used for something by somebody (application domain) - E.g.: by a bank clerk for assessing whether a customer should be granted a loan. Information is about something (problem domain) - E.g.: about the financial situation of a person. An information system is based on an understanding of these contexts. Problem domain User System Application domain Design af brugerflader 6.31

32 Transfer Knowledge (Nonaka) A key reference in knowledge management Question: how can you transfer knowledge to others? Distinguishes between explicit and tacit knowledge Tacit knowledge To Explicit knowledge Tacit knowledge From Explicit knowledge Socialization Transfering tacit knowledge through shared experiences, apprenticeships, on-the-job training, talking at the water cooler Internalization Converting explicit knowledge into tacit knowledge; learning by doing; studying previously captured explicit knowledge (manuals, documentation) to gain technical know-how 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 Design af brugerflader 6.32