Fehlverhalten bei der Bedienung von Benutzungsschnittstellen. Henning Wachsmuth 1

Transkript

1 Fehlverhalten bei der Bedienung von Benutzungsschnittstellen Henning Wachsmuth 1

2 Übersicht Grundlegende Ziele des Interface Designs bei automatisierten Systemen Das Dialogmodell am Beispiel eines Radioweckers Prinzipielle Problemtypen bei der Interaktion zwischen Mensch und Maschine Lösungsansätze für das Design korrekter Interfaces 2

3 1. Grundlegende Ziele Knowing what to abstract and how to abstract it is the foundation of any user interface design. Asaf Degani,

4 Ziele des Interface Designs Beim Entwurf von Interfaces stehen folgende Ziele im Mittelpunkt: Beseitigung aller Unsicherheiten des unterliegenden Systems Technische und praktische Korrektheit Einhaltung der Prinzipien der Benutzer- Interaktion Das Interface soll möglichst simpel sein. 4

5 Korrekte Interfaces (1) Ein technisch korrektes Interface genügt den folgenden Bedingungen: Aufgabe stets durchführbar Aktueller Zustand der Maschine bekannt Nächster Zustand in Abhängigkeit zur nächsten Aktion vorhersagbar Alle wichtigen Informationen werden angezeigt. 5

6 Korrekte Interfaces (2) Für ein (praktisch) korrektes Interface gilt über die technische Korrektheit hinaus: Es erzielt das gewünschte Verhalten Ist damit für praktische Zwecke geeignet Praktische Korrektheit impliziert technische Korrektheit: 6

7 Benutzer-Interaktion: Prinzipien Zu beachtende Prinzipien der Interaktion zwischen Mensch und Maschine: Konsistenz Navigierbarkeit und Orientierbarkeit Erwartungskonformität Einhaltung von Populations-Stereotypen (population stereotypes)... 7

8 Populations-Stereotypen Benutzer haben eine bestimmte Vorstellung, wie ein Gerät funktioniert. Ein Populations-Stereotyp beschreibt Erwartungen, die innerhalb einer Bevölkerungsgruppe einheitlich vorliegen. [Beispiel:] Minus links Plus rechts 8

9 2. Dialogmodell Interfaces lassen sich anhand von Dialogmodellen beschreiben: Hier verwendetes Modell ist eine Menge von Statechart-Diagrammen Befasst sich mit Zuständen des Interfaces und Ereignissen 2 Sichten auf das Interface: Maschinen- Modell, mentales Modell 9

10 Der Radiowecker Skizze des im Vortrag verwendeten Beispiels: 10

11 Ereignisse Bei Interfaces unterscheidet man zwischen 4 Typen von Ereignissen: User-initiated events: Vom Benutzer initiiert und vom System direkt aktiviert Timed events: Zustandswechsel nach bestimmter Zeit automatisch Guarded events: Zustandswechsel nach Erfüllung einer Bedingung automatisch Disturbance: Zustandswechsel durch technische Störung oder äußeren Einfluss 11

12 Ereignisse: Beispiele [Beispiel:] User-initiated event [Beispiel:] Timed event [Beispiel:] Guarded event 12

13 Maschinen- und mentales Modell Das Maschinen-Modell (machine model) beschreibt das unterliegende System: Enthält komplett aufgeführt vollständige Information des Systems Das mentale Modell (user model) zeigt, wie der Benutzer das System sieht: Anhand des Interfaces entwickelt (und ggf. der Anleitung) Enthält i.a. weniger Informationen als das Maschinen-Modell 13

14 Beispiel zu den Modellen (1) [Beispiel:] Maschinen-Modell der Modi-Einstellung 14

15 Beispiel zu den Modellen (2) [Beispiel:] Mentales Modell der Modi-Einstellung 15

16 3. Problemtypen Probleme bei Interfaces, die zu Benutzerfehlverhalten führen: Das Interface widerspricht den Erwartungen des Benutzers Es ist zu unübersichtlich oder zu komplex Es ist technisch oder praktisch nicht korrekt 16

17 Alarm-Einstellung: Modell [Beispiel:] Mentales Modell des Einstellens des Alarms 17

18 Nebeneffekte Ein Nebeneffekt (side effect) ist die automatische Änderung eines Werts/Zustands bei Auslösen einer Aktion durch den Benutzer. Ermöglicht ein Interface einfach bedienbar und übersichtlich zu machen Kann den Benutzer verwirren, da er die Änderung u.u. nicht mitbekommt 18

19 Alarm-Einstellung: Ablauf [Beispiel:] Möglicher Ablauf beim Einstellen des Alarms 19

20 Referenzwerte Ein Referenzwert (reference value) ist ein Parameter, der einem Gerät dazu dient, sein Verhalten zu steuern. Zeit, Frequenz, Lautstärke sind Beispiele für Referenzwerte Gleichzeitiges Ändern eines Referenzwerts und eines Modus widerspricht einem grundsätzlichen Populations-Stereotyp. 20

21 Der Wecker im Dunkeln (1) [Beispiel:] Maschinen-Modell der Alarm-/Licht-Funktion Schwarzer Hintergrund meint Dunkel 21

22 Der Wecker im Dunkeln (2) [Beispiel:] Mentales Modell der Alarm-/Licht-Funktion Schwarzer Hintergrund meint Dunkel 22

23 Nicht-Determinismus Ein Interface ist nicht-deterministisch, wenn der Benutzer nicht voraussagen kann, was in Abhängigkeit zur nächsten Aktion passieren wird. Liegt oft aufgrund unzureichender Anzeige oder schlechter Abstraktion vor Zentrales Problem des Interface Designs Technisch inkorrekt, wenn es der Erfüllung der Aufgabe entgegensteht 23

24 Alarm, aber kein Alarm: Modelle [Beispiel:] Maschinen-Modell und mentales Modell der Lautstärkeregelung Maschinen- Modell Mentales Modell 24

25 Eingestellt / Aktiviert Ein Modus ist eingestellt (engaged), wenn er lediglich eingetreten ist. Funktionalität technisch korrekt, praktisch nicht zwangsläufig Ein Modus ist aktiviert (activated), wenn er eingetreten ist und das gewünschte Verhalten erzielt. Technisch und praktisch korrekt 25

26 Alarm, aber kein Alarm: Ablauf [Beispiel:] Möglicher Ablauf beim Alarm 26

27 Lügende Interfaces Ein Interface lügt, wenn es seinen aktuellen Zustand nicht korrekt angibt bzw. falsche Informationen anzeigt. Lügende Interfaces sind technisch inkorrekt Nicht immer eindeutig entscheidbar, ob ein Interface lügt 27

28 4. Lösungsansätze Es gibt kein Kochrezept für das Design korrekter Interfaces, aber: Maschinen- und mentales Modell stets zu Interface entwickelbar Mentales Modell lässt sich bzgl. Maschinen- Modell verifizieren Es gibt Regeln und Empfehlungen, an die man sich halten sollte 28

29 Verifikation von Interfaces Ein Interface ist korrekt, wenn die Aufgabe erfüllbar ist und keiner der folgenden Zustände existiert: Error State: Vom Interface als aktuell angezeigter, aber nicht möglicher Zustand Augmenting State: Fälschlicherweise als derzeit erreichbar angezeigter Zustand Restricting State: Zustand, der dem Benutzer verschweigt, dass bestimmte Ereignisse auslösbar sind 29

30 Error State: Beispiel (1) [Beispiel:] Ausschnitt aus der Funktionsweise der set/light -Taste 30

31 Error State: Beispiel (2) [Beispiel:] Die set/light -Taste soll folgendes bewirken: B 31

32 Error State: Beispiel (3) [Beispiel:] Die resultierende Kombination an Zuständen existiert nicht 32

33 Konklusion des Vortrags: Empfehlungen (1) Niemals einen Zustand anzeigen, der so nicht gültig ist Nicht-Determinismus vermeiden, wo Konsequenzen wichtig sind Deutlich anzeigen, wenn gegen einen Populations-Stereotypen verstoßen wird Besondere Aufmerksamkeit gegenüber Ereignissen, die automatisch passieren 33

34 Empfehlungen (2) Abschließende Grundregeln für den Entwurf: Möglichst wenige, aber hinreichend viele Modi und Anzeigen Information ist die Grundlage eines guten Interfaces, nicht Ästhetik Zusammengehöriges gleich, Unterschiedliches verschieden anzeigen 34

35 Ende [...] good interface design is all about revealing the underlying structure to the user (and averting surprise). Asaf Degani,