Usability Engineering in der Praxis Beispiel: WebTravelOffice

Transkript

1 HCI Inhalt - Analyse: Anforderungen & Benutzerprofile - Prototyping: Navigation - Prototyping: Dialog-Layout - Qualitätssicherung: Usability Test - Zusammenfassung: Requirements Tracking

2 Methodik für das Usability Engineering HCI

3 Methodik für Usability Engineering HCI

4 Analyse: Req. / User - Basis für Qualität: Anforderungen und Merkmale ergonomische Qualität = Erfüllung der Ergonomie-Anforderungen durch Merkmale des (G)UI HCI

5 Analyse: Req. / User - Beispiel aus dem ecommerce: Travel Office - Benutzergruppen: - 2 Szenarien: - Anforderungen a) Vielflieger b) Urlauber a) Effizientes Buchen b) Info über billige des Business Trips Urlaubsreisen - Urlauber: natürliche Terminologie, einfache Eingabe (Dauer & Destination), umfangreiche Info & Hilfe - Vielflieger: Benutzung der IATA-codes, Spezialfunktionen wie Stop-over, keine redundante Eingabe von Daten, Shortcuts HCI

6 Analyse: Req. / User - OOA: Anforderungen (Use Cases, Klassendiagramm...) Es gibt keine benutzerspezifischen Informationen. Wie kann ergonomische Qualität entstehen? HCI

7 Analyse: Req. / User - OOA: benutzerspezifischen Informationen? Ergonomie? - Lösung (1. Versuch): Detaillierung durch Activity-Diagramm HCI Nach wie vor keine benutzerspezifischen Informationen

8 Analyse: Req. / User - OOA: benutzerspezifischen Informationen? Ergonomie? Lösung (2. Versuch): User- und Task-Analyse - Befragung der Personen (Flugbuchung im Internet): - Frau A: Ich will in den Urlaub fahren und suche nach einem Flug - Student B: Ich mache eine Sprachreise und fliege nach Paris - Herr E: Ich fliege jeden Monat einmal zu meiner Familie - Frau C: Mein Flug zum Kunden geht in dieser Woche nach - Identifikation der Benutzergruppen - Anfänger (keine IT-Kenntnisse + keine Erfahrungen mit Flugbuchungen) - Anfänger (IT-Kenntnisse + keine Erfahrungen mit Buchungen) - Sporadischer Nutzer (IT-Kenntnisse + einige Erfahrungen mit Buchungen) - Experte (IT-Kenntnisse + viel Erfahrungen mit Buchungen) - Benennung der Benutzergruppen und Charakterisierung (Profile) - Anfänger = Urlauber (Holiday Maker) - Experte = Vielflieger (Frequent Flyer) HCI

9 Analyse: Req. / User - OOA: User- und Task-Analyse - Benennung der Benutzergruppen und Charakterisierung (Profile) Schema für Aufgaben- und Benutzer-Profiling HCI

10 Prototyping: Navigation - Ergonomie: Benutzergruppen und Benutzerprofile HCI Wie können die Profile berücksichtigt werden?

11 Prototyping: Navigation - Dialog(-kandidaten) für Urlauber Basis: UC-/Act.-Diagr. +User-Profile HCI

12 Prototyping: Navigation - Navigationsraum für Urlauber HCI

13 Prototyping: Navigation - Dialog(-kandidaten) für Vielflieger Basis: UC-/Act.-Diagr. + User-Profile HCI

14 Prototyping: Navigation - Navigationsraum für Vielflieger HCI

15 Prototyping: Layout - NavSpaces für Requirements Analyse & UI Design - Konstruktive QS für Ergonomie / Usability - Zeigt Struktur (statische Bereiche) des User Interface (UI) (class model) & basiert auf Geschäftsprozessen -> kein State Transition oder Sequence Diagramm - Keine Abdeckung aller ergonomischen Aspekte (Fokus: Aufgabenangemessenheit, Steuerbarkeit, Erlernbarkeit) - Voraussetzung: Requirements (Use Cases, GPs), User Profile und Konzeptmodell (class model) - Literatur: A UML-based Methodology for Hypermedia Design (Rolf Hennicker & Nora Koch, Uni München): Navigation Space Model, Navigational Structure Model

16 Prototyping: Layout - NavSpaces für Requirements Analyse & UI Design - Vorteile der Vorgehensweise - Brücke von Requirements zum SW-Produkt - Zwang: Profile & Navigationskonzept für Benutzergruppen - Einsatz der UML und ggf. Prozess-Standards, z.b. RUP - Frühe & einfache Messung der Usability, z.b. Click Stream - Basis für Automatisierung: UI-Generierung & Re-Engineering - Problembereiche - Neues Modell: YEMTU-Effekt - (noch) kein Werkzeug -> vorhandene Case-Tools - nur für bestimmte Anwendungen geeignet

17 Prototyping: Layout - NavSpaces für Requirements Analyse & UI Design - Verschiedene User Interfaces. Individualisierung? -> Nein (Nielsen) - Entwicklung zu teuer? -> Nein (OO,Components...) - Wer versteht NavSpaces? -> Jede(r) mit UML-Kenntnissen - Was ist zu tun, wenn User- Profile nicht verfügbar sind? -> Kein User Interface entwickeln... - Ist ein NavSpace hilfreich auf der I-Elementebene? - Nein!

18 Prototyping: Layout Focus Groups - Experten/User (Evaluatoren) konstruieren Task-Szenarien - Verschiedene Modi denkbar, z.b. Gemeinsames Rollenspiel -> imaginäre / reale Anwendung - Screen mockups / Prototyp hilfreich bzw. interaktiver PT - Gut geeignet in der frühen Phase des Design Lifecycle - Wenig Formalisierung, aber klare Fokussierung - Agenda, Moderator (Facilitator), Prokollant notwendig - Follow-Up durch Moderator / Projektleiter

19 Prototyping: Layout - Screen-Layout/Design: parallel zum Prototyping - Interaktionsstile und -bereiche, z.b. Dateneingabe, Navigation - Interaktionselemente und Interaktionsgruppen - Einsatz von Formen und Farben - Primäre und sekundäre Farbschemata verwenden - Nicht mehr als 3 Farben für Bereiche & Gruppierungen (bei Graphik: bis 5) - Konsistente Verwendung über verschiedene Bereiche - Dialoge: keine gesättigten Farben für Font, Vorder-/Hintergrund - Ausreichender Kontrast / Helligkeit

20 Prototyping: Layout - Screen-Layout/Design: Einsatz von Farben

21 Usability Test - Usability Test: Focus Group - Prüfung der Anwendung, 2 Aspekte werden fokussiert: -Navigation -> Benutzergruppe -Farbgebung -> Standards (z.b. Java Look&Feel DG) - Agenda (für ca. 2*2 Stunden): - Screening: Auswahl und Erstbefragung von 6-12 Personen (User) durch einen Facilitator (Moderator) - Introduction: Vorstellung der Beteiligten - Product Demonstration (Live / Video) - Background Discussion: Offene Diskussion über das Produkt und den Aspekt (geführt durch Facilitator) - Key Question: Facilitator stellt entscheidende Frage(n) - Summary of Findings: Zusammenstellung der Ergebnisse

22 Usability Test - Focus Group (Navigation) - Background Discussion - Key Question - Herr A: Der Ablauf für den Urlauber ist sehr restriktiv... - Frau B: Nein, er kann vor, zurück und abbrechen... - Herr A: Die Buttons sind an der falschen Stelle... - Facilitator: Ist die Navigation für den Urlauber verständlich und klar vorgegeben? - Herr A: Nun, so gesehen: Ja... - Summary of Findings - Facilitator: Die Navigation entspricht den Anforderungen, die für die Benutzergruppen gelten.

23 Usability Test - Focus Group (Farbgebung): Java Look & FeelDesign Guidelines Secondary Colors The visual elements of Java look and feel applications use the secondary colors as follows: - Secondary 1 for the dark border that creates flush 3D effects for items such as command buttons - Secondary 2 for inactive internal window borders, shadows, pressed buttons, and dimmed command button text and borders - Secondary 3 for the background canvas, the background of noneditable text fields, and inactive title bars for internal windows The usage is shown in the following figure.

24 Usability Test - Focus Group (Farbgebung): Java Look & FeelDesign Guidelines

25 Usability Test - Focus Group (Farbgebung): Java Look & FeelDesign Guidelines Black and White Black and white have defined roles in the Java look and feel color model. In particular, black appears in: - User text, such as the entry in an editable text field - Control text, such as menu titles and menu items - Title text in an internal window - Button text in command buttons - Tab text in tabbed panes - Text in noneditable text fields White is used for: - Highlighting the flush 3D appearance of such components as command buttons - Background of editable text fields

26 Usability Test - Focus Group (Farbgebung) - Background Discussion - Herr A: Die Eingabefelder sind klar erkennbar - Frau B: Ja, aber dieselbe Farbe wie der Hintergrund... - Herr A: Weiß ist doch eine neutrale Farbe... - Key Question - Facilitator: Entspricht der Hintergrund den Vorgaben? - Herr A: Nun, so gesehen: Nein... - Summary of Findings - Facilitator: Die Farbgebung für den Hintergrund (Sekundärfarbe 3) entspricht nicht den Guidelines.

27 Requirements Tracking Requirements Tracking Requirements und Bug Tracking: Verfolgung der Anforderungen und Fehler, z.b. Navigation: Steuerbarkeit

28 Requirements Tracking Requirements Tracking Requirements und Bug Tracking: Verfolgung der Anforderungen und Fehler, z.b. Navigation: Steuerbarkeit