User Interfaces 2 - auf ThomasKaelin.ch

Transcrição

User Interfaces 2
User Interfaces 2
Zusammenfassung v1.0
Kälin Thomas, Abteilung I
HS 07
Kälin Thomas, Abt I
1/39
17.12.2007
User Interfaces 2
1. USABILITY - DEFINITION ............................................................................................................... 6
1.1. Unterstützung der Bedienbarkeit ....................................................................................... 6
1.1.1.
Erlernbarkeit (Learnability) ................................................................................................. 6
1.1.2.
Flexibilität (Flexibility)......................................................................................................... 6
1.1.3.
Widerstandsfähigkeit (Robustness)...................................................................................... 6
2. HCI – HUMAN.............................................................................................................................. 7
2.1. Informationsquellen ........................................................................................................... 7
2.1.1.
Sehen................................................................................................................................ 7
2.1.2.
Hören................................................................................................................................ 7
2.1.3.
Fühlen............................................................................................................................... 7
2.1.4.
Reaktionszeit ..................................................................................................................... 7
2.1.5.
Fitts’ Law........................................................................................................................... 7
2.2. Speichern – Gehirn ............................................................................................................. 7
2.2.1.
Sensor Speicher ................................................................................................................. 7
2.2.2.
Kurzzeitgedächtnis / Working Memory ................................................................................. 7
2.2.3.
Langzeitgedächtnis / Long Term Memory............................................................................. 8
2.3. Verarbeiten ......................................................................................................................... 8
2.3.1.
Deklaratives und prozuderales Wissen ................................................................................. 8
2.3.2.
Der menschliche Prozessor ................................................................................................. 8
2.3.3.
Lernen von Prozeduren / Power Law of Practice................................................................... 9
2.4. Denken................................................................................................................................ 9
2.4.1.
Schlussfolgerndes Entscheiden (Deductive).......................................................................... 9
2.4.2.
Induktives Entscheiden (Inductive) ..................................................................................... 9
2.4.3.
Erschliessendes Entscheiden (Abductive) ............................................................................. 9
2.5. Probleme lösen ................................................................................................................... 9
2.5.1.
Wie werden Probleme gelöst? ............................................................................................. 9
2.5.2.
Functional Fixedness ........................................................................................................ 10
2.6. Emotionen & Unterschiede ............................................................................................... 10
2.6.1.
Emotionen ....................................................................................................................... 10
2.6.2.
Unterschiede.................................................................................................................... 10
3. HCI – COMPUTER ....................................................................................................................... 11
3.1. Eingabe ............................................................................................................................. 11
3.1.1.
Tastatur .......................................................................................................................... 11
3.1.2.
Handschrifterkennung ...................................................................................................... 11
3.1.3.
Spracherkennung ............................................................................................................. 11
3.1.4.
Positionierung .................................................................................................................. 11
3.1.5.
Papier ............................................................................................................................. 11
3.2. Ausgabe ............................................................................................................................ 11
3.2.1.
Bildschirme ...................................................................................................................... 11
3.2.2.
Digitales Papier ................................................................................................................ 11
3.2.3.
3D Displays / Simulatoren / Virtual Reality ......................................................................... 11
4. HCI – INTERACTION ................................................................................................................... 12
4.1. Normans Interaction Model.............................................................................................. 12
4.1.1.
Slip vs Mistake ................................................................................................................. 12
4.2. Abowd and Beale .............................................................................................................. 12
5. KOGNITIVE MODELLE................................................................................................................... 13
5.1. Goal and task hierarchies ................................................................................................. 13
5.1.1.
GOMS – Goals Operators Methods Selection ...................................................................... 13
5.1.2.
CCT – Cognitive Complexity Theory................................................................................... 13
5.2. Linguistic models .............................................................................................................. 13
5.2.1.
BNF – Backus Naur Form .................................................................................................. 13
5.2.2.
TAG – Task Action Grammar............................................................................................. 14
5.3. Physical and Device Models.............................................................................................. 14
5.3.1.
KLM – Keystroke Level Model............................................................................................ 14
6. BEOBACHTEN VON BENUTZERN ......................................................................................................15
6.1. Allgemeines ...................................................................................................................... 15
2/39
17.12.2007
User Interfaces 2
6.1.1.
Wie Benutzer finden? ....................................................................................................... 15
6.1.2.
Hinweise für das Befragungs-Team ................................................................................... 15
6.1.3.
Informationen festhalten .................................................................................................. 15
6.1.4.
Nachbesprechung ............................................................................................................ 15
6.2. Structured Observations................................................................................................... 15
6.2.1.
Was und Warum?............................................................................................................. 15
6.2.2.
Übersicht ......................................................................................................................... 15
6.2.3.
Einschränkungen von „Self Reports“.................................................................................. 15
6.2.4.
Kombination .................................................................................................................... 15
6.2.5.
Naturalistic Observation.................................................................................................... 16
6.2.6.
Contextual Inquiry ........................................................................................................... 16
6.2.7.
Contextual Interview ........................................................................................................ 16
6.2.8.
Artifact Walkthrough ........................................................................................................ 16
6.2.9.
Naturalistic Usability Evaluation......................................................................................... 16
6.3. Rollenspiele ...................................................................................................................... 16
7. USAGE-CENTERED DESIGN ........................................................................................................... 17
7.1. Allgemeines ...................................................................................................................... 17
7.1.1.
Ziel ................................................................................................................................. 17
7.1.2.
Übliche Wege................................................................................................................... 17
7.2. Element 1 – Pragmatic Design Guidelines........................................................................ 17
7.2.1.
Usability Rules ................................................................................................................. 17
7.2.2.
UI Design Prinzipien ......................................................................................................... 17
7.3. Element 2 – Model Driven Design Process ....................................................................... 17
7.3.1.
Überblick ......................................................................................................................... 17
7.3.2.
Role Model ...................................................................................................................... 18
7.3.3.
Task Model ...................................................................................................................... 19
7.3.4.
Content Model ................................................................................................................. 20
7.3.5.
Operation Model .............................................................................................................. 22
7.3.6.
Implementation Model...................................................................................................... 22
7.4. Element 3 – Organized Development Activities ............................................................... 22
7.5. Element 4 – Iterative Improvement................................................................................. 23
7.6. Element 5 – Measure of Quality ....................................................................................... 23
8. GOAL DIRECTED DESIGN (GDD) ................................................................................................... 24
8.1. Allgemeines ...................................................................................................................... 24
8.1.1.
Einleitung ........................................................................................................................ 24
8.1.2.
GDD im SE-Prozess .......................................................................................................... 24
8.1.3.
Begriffe ........................................................................................................................... 24
8.1.4.
Wer macht GDD? ............................................................................................................. 24
8.1.5.
Team-Struktur ................................................................................................................. 24
8.2. Überblick über einzelne Phasen ....................................................................................... 24
8.2.1.
Research ......................................................................................................................... 24
8.2.2.
Modelling......................................................................................................................... 24
8.2.3.
Requirements .................................................................................................................. 24
8.2.4.
Framework ...................................................................................................................... 25
8.2.5.
Refinement ...................................................................................................................... 25
8.2.6.
Implementierung ............................................................................................................. 25
8.3. Phase 1: Research ............................................................................................................ 25
8.3.1.
Grundlegendes................................................................................................................. 25
8.3.2.
Untersuchungsobjekte ...................................................................................................... 25
8.3.3.
Methoden ........................................................................................................................ 25
8.4. Phase 2: Modelling ........................................................................................................... 25
8.4.1.
Grundlegendes................................................................................................................. 25
8.4.2.
Warum Personas? ............................................................................................................ 26
8.4.3.
Personas ......................................................................................................................... 26
8.4.4.
Benutzer Rollen................................................................................................................ 26
8.4.5.
Ziele................................................................................................................................ 26
8.4.6.
Konstruktion von Personas................................................................................................ 26
8.4.7.
Persona Typen ................................................................................................................. 27
3/39
17.12.2007
User Interfaces 2
8.4.8.
Andere Modelle ................................................................................................................ 27
8.5. Phase 3: Requirements..................................................................................................... 27
8.5.1.
Grundlegendes................................................................................................................. 27
8.5.2.
Context Scenario.............................................................................................................. 27
8.5.3.
Unterschiede zwischen Context Scenario und Use Cases..................................................... 27
8.5.4.
Vorgehen......................................................................................................................... 27
8.6. Phase 4: Framework ......................................................................................................... 28
8.6.1.
Grundlegendes................................................................................................................. 28
8.6.2.
Vorgehen......................................................................................................................... 28
8.7. Phase 5: Refinement ........................................................................................................ 28
8.7.1.
Grundlegendes................................................................................................................. 28
8.7.2.
Vorgehen......................................................................................................................... 28
8.8. GDD-Überblick .................................................................................................................. 29
9. LOW-FIDELITY PROTOTYPING ....................................................................................................... 30
9.1. Warum Prototypen ........................................................................................................... 30
9.2. Warum Low-Fidelity? ....................................................................................................... 30
9.3. Paper Prototyping............................................................................................................. 30
9.4. SILK .................................................................................................................................. 30
10. USER INTERFACE TESTS ............................................................................................................... 31
10.1. Labor- und Feldtests......................................................................................................... 31
10.2. Typen von UI Tests ........................................................................................................... 31
10.2.1. Cognitive Walkthrough ..................................................................................................... 31
10.2.2. Heuristic Evaluation.......................................................................................................... 31
10.2.3. Experimental Evaluation ................................................................................................... 31
10.2.4. Query Techniques ............................................................................................................ 31
10.2.5. Eye Tracking.................................................................................................................... 32
10.2.6. Observation ..................................................................................................................... 32
10.3. Usability Tests .................................................................................................................. 32
10.3.1. Einleitung ........................................................................................................................ 32
10.3.2. Usability Labor ................................................................................................................. 32
10.3.3. Usability Test Light........................................................................................................... 32
10.3.4. Aufgaben der Personen .................................................................................................... 32
10.3.5. Vorbereitung und Durchführung........................................................................................ 32
10.3.6. Auswertung ..................................................................................................................... 32
11. UI DESIGN IM WEB..................................................................................................................... 33
11.1. Posture für SW-Anwendungen ......................................................................................... 33
11.1.1. Sovereign Posture ............................................................................................................ 33
11.1.2. Transient Posture ............................................................................................................. 33
11.1.3. Daemonic Posture ............................................................................................................ 33
11.1.4. Auxiliary Posture .............................................................................................................. 33
11.2. Begriffe ............................................................................................................................. 33
11.2.1. Website ........................................................................................................................... 33
11.2.2. Webapplication ................................................................................................................ 33
11.3. Web vs GUI ....................................................................................................................... 33
11.4. Facts of Life (Krug) ........................................................................................................... 33
11.4.1. We don’t read pages, we scan them.................................................................................. 33
11.4.2. We don’t make optimal choices, we satisfice...................................................................... 34
11.4.3. We don’t figure out how things work. We muddle through.................................................. 34
11.5. Kommunikation ................................................................................................................ 34
11.6. Motiviation / Demotivation .............................................................................................. 34
11.7. User-Typen ....................................................................................................................... 34
11.8. Gestaltungsaspekte fürs Web .......................................................................................... 35
11.8.1. Prinzipien......................................................................................................................... 35
11.8.2. Sprache ........................................................................................................................... 35
11.8.3. Bilder .............................................................................................................................. 35
11.8.4. Wahrnehmung ................................................................................................................. 36
11.8.5. Navigation und Orientierung ............................................................................................. 36
11.8.6. Home Page...................................................................................................................... 37
4/39
17.12.2007
User Interfaces 2
12. USER INTERFACE VIELFALT ........................................................................................................... 38
12.1. Gadgets............................................................................................................................. 38
12.1.1. Scrollbar .......................................................................................................................... 38
12.1.2. Spin-Buttons / Slide-Spinner ............................................................................................. 38
12.1.3. Message Box.................................................................................................................... 38
12.1.4. Exctraction Controls ......................................................................................................... 38
12.1.5. Fisheye Menu................................................................................................................... 38
12.1.6. Flow Menu....................................................................................................................... 38
12.2. Filesystem......................................................................................................................... 38
12.2.1. Files & Save..................................................................................................................... 38
12.2.2. Andere Strukturen............................................................................................................ 38
12.3. Suchen .............................................................................................................................. 39
12.3.1. Typische Suchemaske ...................................................................................................... 39
12.3.2. Inkrementelles Suchen ..................................................................................................... 39
12.3.3. Sonderzeichen ................................................................................................................. 39
12.3.4. Suchen nach Multimedia ................................................................................................... 39
12.3.5. Filter- und Such-Interfaces ............................................................................................... 39
12.4. Visualisieren ..................................................................................................................... 39
12.5. Zoomable Interfaces ........................................................................................................ 39
12.5.1. Beschreibung ................................................................................................................... 39
12.5.2. Anwendung ..................................................................................................................... 39
12.6. Neuartige Anwendungen.................................................................................................. 39
12.7. Augmented Reality, Tangible UI’s .................................................................................... 39
12.7.1. Virtual Reality .................................................................................................................. 39
12.7.2. Augmented Reality ........................................................................................................... 39
12.7.3. Tangible User Interface .................................................................................................... 39
5/39
17.12.2007
User Interfaces 2
1. USABILITY - DEFINITION
Usability (Bedienbarkeit) wird definiert als die Eigenschaft, dem User mit Effektivität, Effizienz und
Befriedung eine auszuführende Aktion zu ermöglichen.
Die EFFEKTIVITÄT beschreibt dabei, wie umfassend der Benutzer sein Ziel erreicht.
EFFIZIENZ umfasst die aufgewendeten Ressourcen (Zeit, …) in Relation zum zu erreichenden Ziel.
BEFRIEDUNG misst die positiven Gefühle und die Zufriedenheit des Benutzers.
1.1.
Unterstützung der Bedienbarkeit
1.1.1.
Erlernbarkeit (Learnability)
VORHERSAGBARKEIT (PREDICTABILITY): Der Benutzer muss wissen, welche zukünftigen Effekte die
aktuelle Aktion bewirkt.
SYNTHETISIERBARKEIT (SYNTHESIZABILIITY): Vergangene Aktionen müssen einen erkennbaren,
verständlichen Effekt haben. Diese müssen mit unserem mentalen Modell in Einklang gebracht
werden können.
VERTRAUTHEIT (FAMILIARITY): In welchem Grad kann der Benutzer bereits Bekanntes wieder
verwenden? Kann ich daraus schliessen, welche Aktion möglich ist?
VERALLGEMEINERBARKEIT
(GENERALIZABILITY):
Bekanntes
Vorgehen
kann
andernorts
verallgemeinert wieder verwendet werden.
KONSISTENZ (CONSISTENCY): Aktionen sollten durch die ganze Applikation hindurch identisch
ausgeführt werden müssen. Beispiel: jegliche Beschriftungen gleich halten.
1.1.2.
Flexibilität (Flexibility)
DIALOGE / FREIHEIT: Keine Zwangsvorgaben von Dialogboxen durch das System. Nicht das System
soll Dialoge starten, sondern der Benutzer.
PARALLELITÄT (MULTITHREADING): Der Benutzer kann mehrer Aktionen parallel innerhalb der
Anwendung ausführen.
ERSETZBARKEIT (SUBSTITUTIVITY): Eine Methode ein Ziel zu erreichen kann über verschiedene Arten
umgesetzt werden. Beispiel: Maus, Keyboard-Shortcuts, Symbolleiste. Auch verschiedene
Möglichkeiten der Eingabe („8 oder 5 + 3“).
ANPASSBARKEIT (CUSTOMIZABILITY): Das User Interface kann entweder durch den Benutzer oder
durch das System angepasst werden. Gutes Beispiel durch Anpassung durch das System sind
Wiederherstellung von Tabs bei einem Browser-Absturz.
1.1.3.
Widerstandsfähigkeit (Robustness)
BEOBACHTBARKEIT (OBSERVABILITY): Der Benutzer kann jederzeit den aktuellen Status der
Applikation erkennen. Welche Aktionen sind erlaubt? Was sind Standard-Werte?
WIEDERHERSTELLBARKEIT (RECOVERABILITY): Falsche Aktionen können zurückgesetzt werden.
Typisches Beispiel sind Undo-Funktionen.
ANTWORTVERHALTEN (RESPONSIVENESS): In welcher Zeit reagiert die Applikation auf meine
Eingaben? Dieselbe Aktion sollte immer auch dieselbe Zeitdauer benötigen.
AUFTRAGSERFÜLLUNG (TASK CONFORMANCE): Wie genau / schnell erfüllt die Anwendung meine
Aufgabe?
6/39
17.12.2007
User Interfaces 2
2. HCI – HUMAN
2.1.
Informationsquellen
2.1.1.
Sehen
Wir besitzen ein zweistufiges Sehen: die physische Verarbeitung durch Auge und die Verarbeitung,
bzw. Interpretation durch das Gehirn. Das Auge bemerkt blinkende Elemente im Sichtbereich, der
Blick wird unwillkürlich auf diese Elemente gerichtet.
Beim INTERPRETIEREN spielen die Grösse und Tiefe, die Helligkeit und die Farbe des Objekts eine
Rolle. All diese Elemente beeinflussen die Interpretierung der Umwelt. Das Gehirn kompensiert
ausserdem Bewegungen und Farbwechsel. Optische Täuschen haben als Ursache eine
„Überkompensierung“ durch das Gehirn.
Das Lesen ist eine Spezialform des Sehens. Unser Blick „springt“ dabei durch den Text. Ausserdem ist
die Wortgrösse wichtig für das Erkennen von Wörtern. Darum ist es schlecht, alles nur in
Grossbuchstaben zu schreiben.
2.1.2.
Hören
Menschen hören im Bereich von 20HZ – 18kHz. Tiefe Töne können dabei wegen der geringen
Wellenlänge schlecht oder gar nicht geortet werden. Ausserdem kann unser Hörsystem
Hintergrundgeräusche wegfiltern („Party Phänomen“).
2.1.3.
Fühlen
Die Haut besitzt verschiedene Nervenzellen (Wärme, Schmerz, Druck). Nicht jede von diesen Zellen
hat dieselbe Reaktionszeit.
2.1.4.
Reaktionszeit
Die Zeit um auf einen Stimulus (Sehen, Hören, Fühlen) zu reagieren setzt sich wie folgt zusammen:
Aktionszeit = Reaktionszeit + Bewegungszeit
Die Reaktionszeit ist dabei abhängig vom Stimulus. Hören (~150ms) ist schneller als Sehen (~200ms),
Sehen schneller als Schmerzempfinden (~700ms).
2.1.5.
Fitts’ Law
Fitts’ Law beschreibt die Zeit, welche benötigt wird, um eine Aktion auf dem Bildschirm auszuführen.
Grob kann gesagt werden, dass Objekte so gross und Distanzen so klein als möglich sein sollten.
Bei sehr grossen Distanzen nimmt die Zeit weniger als linear zu. Das bedeutet also, dass im Falle von
grossen zurückgelegten Distanzen ein zusätzliches Stück weg keinen grossen Einfluss mehr hat. Bei
der Grösse der Objekte ist dies anders. Es gibt eine Grenze für die Objektgrösse, ab welche die
Aktionszeit stark anwächst.
Fazit: Die Maus eignet sich für grosse Distanzen, ist allerdings problematisch bei kleinen Zielen. Die
Tastatur eignet sich besser, wenn wenige Tasten gedrückt werden müssen.
2.2.
Speichern – Gehirn
Wir haben ein 3-stufiges „Speichersystem“. Informationen werden durch Aufmerksamkeit aus dem
Sensor Speicher in das Kurzzeitgedächtnis transferiert. Von dort wird es durch Üben in das
Langzeitgedächtnis überführt.
2.2.1.
Sensor Speicher
Die Sinne des Menschen haben einen sehr kurzen Speicher, welcher kontinuierlich überschrieben wird.
Mit Hilfe dieses kann beispielsweise aus einer grossen Zahl von Punkten eine Linie erkannt werden.
2.2.2.
Kurzzeitgedächtnis / Working Memory
Kurzzeitig benötigte Daten werden hier abgelegt. Es kann ziemlich schnell abgerufen werden, innert
~70ms. Es können allerdings nur etwa 7 +/- 2 Elemente gemerkt werden.
7/39
17.12.2007
User Interfaces 2
2.2.3.
Langzeitgedächtnis / Long Term Memory
Im Langzeitgedächtnis wird jegliches Wissen abgelegt. Es bietet einen riesigen Platz für
Informationen. Hier wird zwischen zwei Typen unterschieden: Episodisches (Erinnerung an eine Reihe
von Events) und semantisches (Fakten, Fähigkeiten) Wissen. Jegliches semantisches Wissen
entwickelt sich immer aus dem episodischen Wissen. Ds LTM ist wie ein Netzwerk aus verknüpften
Knoten aufgebaut. Zum Aufbau der einzelnen Knoten gibt es verschiedene Ansätze:
Frames
Rules
Scripts
<
SPEICHERN : Grundsätzlich gilt: je mehr das man eine Sache übt, desto mehr davon bleibt auch
übrig. Zusätzlich bringt es mehr, auf verschiedene Tage verteilt zu lernen, als alles an einem Stück
lernen zu wollen. Und schlussendlich ist es sehr sinnvoll, neues Wissen mit bekanntem in
Kombination zu bringen.
VERGESSEN: Einige Informationen Zerfallen einfach, andere werden bewusst durch neue
Informationen überschrieben. Auch können Emotionen das Ausblenden von Informationen
verursachen, beispielsweise bei einem Trauma oder Schock.
ABRUFEN: Wir unterscheiden zwischen unbewusstem „Erkennen“ und einem bewussten „Abrufen“.
2.3.
Verarbeiten
Nun kombinieren wir die vorherigen Dinge und kommen zu einem Modell des menschlichen
Prozessors.
2.3.1.
Deklaratives und prozuderales Wissen
DEKLARATIVES WISSEN beinhaltet das Wissen von Fakten und Daten. Es wird vielseitig verwendet.
Beim PROZEDURAL WISSEN geht es hingegen um das Wissen zu bestimmten Aktion, wie also reagiert
werden muss. Dieses wissen baut auf den LTM-Rules auf.
2.3.2.
Der menschliche Prozessor
Nachfolgendes Modell soll den Ablauf im menschlichen Körper vereinfacht darstellen. Ein Stimulus
taucht auf und wird von den Sinnen wahrgenommen (Dauer: ~100ms). Danach entscheidet der
kognitive Prozessor, was zu tun ist und legt die zu tätigende Aktion im WM ab (Dauer: ~70ms).
Anschliessend muss der Motor Processor noch die zu tätigende Aktion auslösen, auch dies dauert
nochmals ~70ms.
8/39
17.12.2007
User Interfaces 2
2.3.3.
Lernen von Prozeduren / Power Law of Practice
Die IF-THEN-Patterns werden zuerst durch das Lösen von Problem angeeignet. Durch Übung
entwickelt sich daraus eine Fähigkeit, welche sich durch noch mehr Übung in der höchsten Stufe zum
Automatismus entwickeln kann.
In diesem Bereicht gilt auch das POWER LAW OF PRACTICE. Dieses sagt aus, dass zu Beginn der
Lernphase die benötigte Zeit noch stark abnimmt. Nach ~100 Wiederholung flacht dies dann ab, die
Zeitersparnis wird immer geringer.
2.4.
Denken
2.4.1.
Schlussfolgerndes Entscheiden (Deductive)
Aus bereits gemachten Erfahrungen wird eine logische
Schlussfolgerungen müssen nicht zwingend richtig sein!s
2.4.2.
Schlussfolgerung
gezogen.
Diese
Induktives Entscheiden (Inductive)
Von gemachten Erfahrungen wird eine Allgemeinerung abgeleitet. Beispiel: Alle gesehen Elefanten
haben einen Rüssel, so gehen wir davon aus, dass jeder Elefant einen Rüssel hat. Bei diesen
Entscheidungen können wir immer nur beweisen, dass Sie falsch sind, jedoch nie, dass sie wahr sind!
2.4.3.
Erschliessendes Entscheiden (Abductive)
Hier wird von einem Ereignis auf die Ursache geschlossen. Kann jedoch auch zu falschen Entscheiden
führen. Beispiel für falschen Entscheid: „Sam fährt immer schnell, wenn er betrunken ist. Wenn er
schnell fährt, ist er betrunken.“
2.5.
Probleme lösen
2.5.1.
Wie werden Probleme gelöst?
Üblicherweise wird das Problem in kleinere Teilprobleme aufgespaltet und sich anschliessend das
Wissen zu jedem Teilproblem angeeignet. Auch werden Analogien zu bereits gekanntem gezogen.
Ausserdem gibt es keine „Aufwärmphase“, die Lösung stellt sich also nicht schrittweise ein, sondern
wie ein Blitz: Sie ist einfach da!
9/39
17.12.2007
User Interfaces 2
2.5.2.
Functional Fixedness
Ein grosses Problem beim Lösen ist, dass sich der Mensch meist in seinem Denken einschränkt. Es
wird die erst beste Idee verwendet und gar nicht erst nach weiteren Möglichkeiten gesucht. Beispiele
hierfür: 9 Punkte verbinden, 2 Seile Problem, …
2.6.
Emotionen & Unterschiede
2.6.1.
Emotionen
Zu dem gesagtem soll hier noch angemerkt werden, dass die Emotionen einen entscheidenden
Einfluss auf die Ausführung (Problemlösung) eines Menschen hat. Unter Stress sind auch einfachste
Aufgaben bedeutend schwerer. Wir lernen also daraus, dass wir mit unserem UI bei den Benutzern
möglichst positive Gefühle erzeugen sollten.
2.6.2.
Unterschiede
Natürlich ist auch jeder Mensch unterschiedlich. Es gibt langfristige (Geschlecht, Intelligenz, Wissen,
…) und kurzfristige (Müdigkeit, Stress) Einflussfaktoren. Auch können diese im Laufe der Zeit ändern,
beispielsweise durch Alterung.
10/39
17.12.2007
User Interfaces 2
3. HCI – COMPUTER
3.1.
Eingabe
3.1.1.
Tastatur
Erlaubt sehr schnelle Texteingaben. Das Tastaturschema QWERTY ist historisch bedingt (Zeichenköpfe
bei Schreibmaschinen). DVORAK erlaubt schnelleres Tippen und weniger Ermüdung. Weiter gibt es
verschiedene Abarten wie einhändig bedienbare Tastaturen und solche Varianten mit nur 5 Tasten,
bei denen Zeichen durch Kombination von mehreren Tasten erzeugt werden.
Auch der Zahlenblock der Tastatur / Taschenrechner oder die Zahlenfelder eines Mobiltelefons zählen
zu Tastaturen.
3.1.2.
Handschrifterkennung
Sehr gebräuchliche Interaktion, jedoch bedeutend langsamer als ein geübter Tastaturschreiber. Weiter
kämpfen die bei der Handschrifterkennung eingesetzten Programme mit technischen Problemen.
3.1.3.
Spracherkennung
Immer weiter verbreitet. Über Analyse der Stimme werden Befehle ausgeführt. Problem: System
müssen oft zuerst „trainiert“ werden, um gute Resultate zu erzielen. Auch ist das erkennbare
Vokabular meist sehr eingeschränkt.
3.1.4.
Positionierung
Weitgehend bekannt sind Maus, Trackball und Touchpad. Es ist jedoch auch eine Positionierung über
Augenbewegung denkbar. Ferner gibt es die Gruppe der diskreten Positionierungsgeräte. Hierzu
zählen beispielsweise Fernbedienungen (Up, Down) und Mini Joysticks (Up, Down, Left, Right), welche
zur Navigation durch Auswahllisten eingesetzt werden.
3.1.5.
Papier
Auch Papier kann ein Eingabegerät sein, indem die darauf gedruckten Daten mittels Scanner und OCR
in Text umgewandelt werden.
3.2.
Ausgabe
3.2.1.
Bildschirme
Früher meist CRT, heute hauptsächlich LCD eingesetzt. Grössere Bildschirme bieten Projektoren und
Plasma-Screens.
3.2.2.
Digitales Papier
Eine sehr dünne Schicht enthält kleine Kugeln. Soll ein Bildpunkt nun schwarz anzeigen, so dreht sich
diese Kugel entsprechend. Auch sind mehrere Farbabstufungen möglich, dazu befindet sich im Blatt
eine Art Röhre mit Kugel. Je weiter oben die Kugel in der Röhre ist, desto dunkler der Farbton.
3.2.3.
3D Displays / Simulatoren / Virtual Reality
Zum Bewegen im dreidimensionalen Raum eignen sich Data Gloves und spezielle 3D-Mäuse. Diese
können über mehr als nur zwei Achsen bewegt werden. Zur Ergänzung des „Erlebnis“ werden
mittlerweile oft hydraulische Systeme und Gerüche eingesetzt.
3D Displays werden üblicherweise in Kombination mit Spezialbrillen eingesetzt, welche
abwechslungsweise jeweils ein Bild ausblenden (natürlich so schnell, dass dies für den Menschen nicht
erkennbar ist). Dadurch wird ein Raumgefühl erzeugt.
11/39
17.12.2007
User Interfaces 2
4. HCI – INTERACTION
4.1.
Normans Interaction Model
Kennen wir aus UInt1 im Zusammenhang mit dem GULF OF EXECUTION (sieht man, was man machen
kann) und dem GULF OF EVALUATION (sieht man, was passiert ist). Es geht um folgende sieben
Schritte:
User etablishes the goal
Formulates intention
Specifies actions at interface
Executes action
Perceives system state
Interprets system state
Evaluates system state with respect to goal.
4.1.1.
Slip vs Mistake
SLIP: Fehlleistung, Aktion richtig gedacht aber falsch ausgeführt. Reduzierung von Slips erfordert ein
besseres UI-Design.
MISTAKE: Fehlentscheidung, falsches mentales Modell. Erfordert ein besseres Verständnis des
Systems.
4.2.
Abowd and Beale
Beim System von A&B gibt es 4 Teile: User, Input, System, Output. Jedes dieser Systeme hat seine
eigene Sprache. Interaktion beschreibt dabei den Übersetzungsvorgang zwischen diesen Sprachen.
Absicht des Benutzers
=> Übersetzung in die Aktion beim UI
=> Übersetzung in die Systemfunktion
=> Darstellung auf Ausgabegerät
=> Aufnahme durch den Benutzer
12/39
17.12.2007
User Interfaces 2
5. KOGNITIVE MODELLE
5.1.
Goal and task hierarchies
Hierbei geht es um das Formulieren von Zielen und Aufgaben. Meist werden aus den Zielen einfachere
Sub-Ziele gebildet. Ein gängiges Problem sind die Abstufungen: Wo fängt man an, wie stark teilt man
einzelne Aufgaben auf?
5.1.1.
GOMS – Goals Operators Methods Selection
Goms wird für die Vorhersagen des Benutzerverhaltens verwendet. Es erlaubt auf sehr tiefem Niveau
eine Abschätzung von Performance und Zeiten. Je tiefer der „Baum“, desto komplexer und
aufwendiger ist das Problem.
//Beispiel 1
GOAL: CLOSE-WINDOW
. [select
GOAL: USE-MENU-METHOD
. MOVE-MOUSE-TO-FILE-MENU
. PULL-DOWN-FILE-MENU
. CLICK-OVER-CLOSE-OPTION
GOAL: USE-CTRL-W-METHOD
. PRESS-CONTROL-W-KEYS]
//Beispiel 2
GOAL: PHOTOCOPY-PAPER
. GOAL: LOCATE-ARTICLE
. GOAL: PHOTOCOPY-PAGE repeat until no more pages
. . GOAL: ORIENT-PAGE
. . . OPEN-COVER
. . . SELCT-PAGE
. . . POSTION-PAGE
. . . CLOSE-COVER
. . GOAL: PRESS-COPY-BUTTON
. . GOAL: VERIFY-COPY
. . . LOCATE-OUT-TRAY
. . . EXAMINE-COPY
. GOAL: COLLECT-COPY
. . LOCATE-OUT-TRAY
. . REMOVE-COPY (outer goal satisfied!)
. GOAL: RETRIEVE-JOURNAL
. . OPEN-COVER
. . REMOVE-JOURNAL
. . CLOSE-COVER
5.1.2.
CCT – Cognitive Complexity Theory
Besteht aus „user production rules“ und „device description“. Gemäss LM jedoch nicht weiter relevant.
5.2.
Linguistic models
Diese Modelle werden zum Beschreiben und Übersetzen von Aufgaben in Input verwendet. Übliche
Modelle sind Sprachen und Grammatiken. Problematisch ist, dass alle Modelle für KonsolenAnwendungen entwickelt wurden. Somit für GUI’s nicht optimal einsetzbar.
5.2.1.
BNF – Backus Naur Form
Kennen wir aus Mathematik 2. Besteht aus Terminalen (C
CLICK MOUSE) und Nicht-Terminalen (D
Draw
Line). Wird auf sehr tiefem Niveau zur Messung der Komplexität einer Aufgabe verwendet. Je
schwieriger die Aufgabe, desto komplexer die Regeln.
draw line
::= select line + choose points + last point
select line
::= pos mouse + CLICK MOUSE
choose points
::= choose one | choose one choose points
choose one
::= pos mouse + CLICK MOUSE
last point
::= pos mouse + DBL CLICK MOUSE
pos mouse
::= NULL | MOVE MOUSE + pos mouse
13/39
17.12.2007
User Interfaces 2
5.2.2.
TAG – Task Action Grammar
Ist eine Erweiterung der BNF, welche auch auf die Konsistenz von Regeln Rücksicht nimmt. Wird auf
sehr tiefem Niveau zur Messung der Komplexität eines Interfaces eingesetzt.
file-op[Op] ::= command[Op] + filename + filename | command[Op] + filenames
+ directory
command[Op = copy] ::= cp
command[Op = move] ::= mv
command[Op = link] ::= ln
5.3.
Physical and Device Models
5.3.1.
KLM – Keystroke Level Model
Ist eine Ableitung von GOMS. Über einzelne Operatoren können verschiedene Alternativen zur
Ausführung von Aktionen verglichen werden. Dabei ist jedem Operator eine bestimmte Zeit
zugewiesen.
K
B
P
H
D
M
R
Press Key
Maustaste drücken / loslassen
Mit Maus zeigen (Fitts’ Law)
Home (Hand > Keyboard | Maus)
Drawing
Auf Aufgabe vorbereiten
Antwortzeit des Systems
~0.28s
~0.10s
~1.10s
~0.40s
~1.35s
-
14/39
17.12.2007
User Interfaces 2
6. BEOBACHTEN VON BENUTZERN
6.1.
Allgemeines
6.1.1.
Wie Benutzer finden?
Um Benutzer für die Beobachtungen zu finden ist es das beste, direkt bei einer Abteilung einer
Unternehmung der Zielgruppe anzufragen. Die Namen der Firmen können über
Marktforschungsfirmen oder das Internet ermittelt werden. Oft helfen auch Tipps aus dem
persönlichen Umfeld.
6.1.2.
Hinweise für das Befragungs-Team
Fragen sollten immer so offen wie möglich gestaltet sein, damit der Benutzer nicht in seiner
Wahrnehmung und Meinungsfreiheit eingeschränkt wird. Auch sollte man stets höflich bleiben und
eine dem Benutzer angemessene Sprache verwenden.
6.1.3.
Informationen festhalten
Die wichtigsten Unterlagen sind schriftliche Notizen, welche direkt während der Beobachtungsphase
festgehalten werden. Video- und Audioaufzeichnungen eignen sich nur bedingt, da unter Umständen
nicht alles ersichtlich oder bemerkbar ist. Empfehlenswert ist ausserdem das Vorgehen, dass eine
Person Fragen stellt, falls erlaubt, die anderen konzentrieren sich nur auf das Beobachten.
6.1.4.
Nachbesprechung
Die Nachbesprechung im Team sollte so schnell als möglich erfolgen, da so noch viele Informationen
und Erinnerungen aktuell sind. Auch sollten die Erfahrungen abwechslungsweise genannt werden,
damit das Beobachtungsteam direkt auf Aussagen eingehen kann.
6.2.
Structured Observations
6.2.1.
Was und Warum?
Hierbei handelt es sich um Methoden um qualitative Erkenntnisse zu erlangen. Anders als bei den
quantitativen Umfragen werden hier nur wenige Personen, dafür allerdings sehr aussagekräftige,
beobachtet. Die Informationen werden direkt vor Ort (Arbeitsumfeld) erfasst und dienen dem UIDesigner als Grundlage für die Gestaltung.
Die Beobachtungen sollten sehr früh erfolgen, damit das UI-Design sich in die passende Richtung
bewegt. Auch kann früh auf spezielle Bedürfnisse eingegangen werden.
6.2.2.
Übersicht
6.2.3.
Einschränkungen von „Self Reports“
Bei Self-Reports handelt es sich um die Ansichten und Aussagen eines Benutzers, welche
beispielsweise bei einer Befragung erfasst wird. Oft wird jedoch durch die Zielperson
selbstverständliches und unbewusstes vollständig ausgelassen. Andererseits werden manchmal auch
Dinge hinzugefügt, welche sie in der Realität gar nicht macht, beispielsweise Sicherheitsvorschriften,
die ignoriert werden.
6.2.4.
Kombination
In der Realität wird oft eine Kombination aus obigen Methoden eingesetzt. Beispiel: Zuerst eine
„Naturalistic Observation“ und anschliessend ein „Contextual Interview“.
15/39
17.12.2007
User Interfaces 2
6.2.5.
Naturalistic Observation
Das Team beschränkt sich hierbei nur auf das Beobachten der Zielperson. Es werden keine Fragen
gestellt und der Benutzer in seiner Arbeitstätigkeit nicht unterbrochen. Zu Beginn sollte die Person
vollständig über das Ziel und die Absichten informiert werden. Bei Filmkameras ist die Zustimmung
unbedingt einzuholen.
Schwierig an dieser Methode ist, dass oft nicht alle Tätigkeiten für die Beobachter verständlich sind.
Somit müssen Annahmen getroffen werden. Auch ist nicht immer das benötigte Fachwissen über ein
Arbeitsumfeld vorhanden.
6.2.6.
Contextual Inquiry
Auch hier beobachten wir den Benutzer, allerdings sind Zwischenfragen zur Informationssammlung
erlaubt. Dabei müssen darauf achten, dass wir dem Benutzer nicht ein Arbeitsschema aufdrängen
wollen („Lehrperson“).
6.2.7.
Contextual Interview
Hier wird am Arbeitsort eine Befragung des Benutzers durchgeführt. Er wird allerdings nicht bei der
Arbeit beobachtet.
6.2.8.
Artifact Walkthrough
Auch hierbei handelt es sich um eine Befragung des Benutzers, allerdings bringt dieser Elemente aus
seinem Arbeitsumfeld (Bücher, Geräte, Produkte, …) mit. Zu diesen soll er erklären, was er damit
macht und wie er es benutzt. Vorteil dieser Arbeitsobjekte ist es ausserdem, dass sich die Zielperson
an Dinge erinnern kann, welche sie sonst vergessen könnte.
6.2.9.
Naturalistic Usability Evaluation
Es wird mit einem Prototyp einer Anwendung direkt im Arbeitsumfeld eine Bedienbarkeitsanalyse
durchgeführt. Vorteil: Wirkliche Zielpersonen testen das Produkt mit realen Aufgaben.
6.3.
Rollenspiele
In diesem Ansatz wird so etwas wie ein Schauspiel veranstaltet. Dabei sollen die zu untersuchenden
Benutzer eine Tätigkeit durchspielen, welche sie ohne oder mit Hilfsmitteln erledigen würden. Dabei
sollen die Beobachter keine Inputs geben, sondern wirklich nur beobachten. Die Zielpersonen selber
sollen sich neue Ideen erarbeiten!
16/39
17.12.2007
User Interfaces 2
7. USAGE-CENTERED DESIGN
7.1.
Allgemeines
Beim Usage-Centered Design handelt es sich um eine Vorgehensweise bei der Softwareentwicklung,
welche als Ergänzung zu anderen Methoden (RUP) verwendet werden kann.
7.1.1.
Ziel
Gut bedienbare Software, da für den Endkunden das UI die Software ist. Ausserdem kann mit einem
guten GUI Geld gespart (Betreuung, erhöhte Produktivität) und verdient (Verkauf) werden.
7.1.2.
7.2.
Element 1 – Pragmatic Design Guidelines
7.2.1.
Übliche Wege
TESTEN: Qualität nicht ertestbar, braucht lauffähiges System
STYLE-GUIDES: Werden oft nicht beachtet, lösen nur einen kleinen Teil aller Fragen
RAPID PROTOTYPING: Kein Ersatz für Analyse und Design
PEER REVIEWS: Arten oft in langen Debatten aus, Entwickler haben meist persönliche Vorlieben
EXPERTEN: Eigentlich sehr gute Lösung, allerdings teuer
Usability Rules
ACCESS: Benutzbar ohne Hilfe für Kenner der PD.
EFFICACY: System soll für erfahrene Benutzer effizient sein. Bei neuen Benutzern Einarbeitungszeit!
PROGRESSION: System soll den Lernfortschritt mit geeigneten Mitteln unterstützen.
SUPPORT: Den Benutzern bei der Erfüllung seiner Ziele unterstützen.
CONTEXT: Software soll in echtem Umfeld einsetzbar sein.
7.2.2.
UI Design Prinzipien
Grundlegende Prinzipien: Klare Struktur, möglichst einfach,
Rückmeldungen an den Benutzer, Fehlertoleranz erlauben, …
7.3.
benötigtes
sichtbar
zeigen,
Element 2 – Model Driven Design Process
7.3.1.
Überblick
17/39
17.12.2007
User Interfaces 2
7.3.2.
Role Model
Das Role Modell besteht aus USER ROLE und einer User ROLE MAP. Dabei geht es zuerst einmal
darum, verschiedene Benutzer zu finden. Hierzu einige Beispiele von Benutzern, welche als
Datengrundlage verwendet werden können. Diese sind dabei nach absteigender Priorität geordnet.
REAL USER: Echte Endbenutzer. Optimale Lösung und unerlässliche Informationsquelle.
ERSATZ USER: Kunden (nicht Benutzer, wissen oft nicht was wirklich benötigt wird), Manager (haben
Potential um Verkaufsentscheide zu fällen).
USER SURROGATES: Domain Experts (kennen das ganze Fachgebiet, haben somit einen Überblick
über alles), Trainers (Ausbilder, wissen meist genau, wodurch Probleme entstehen) und Supervisor
(Überwachen die Benutzer, kennen die Abläufe).
INFORMANTEN: Marketing (gefährlich: verstehen nicht die Kundenbedürfnisse sondern den Markt),
Verkauf (Auch falsche Prioritäten) und technische Dienste (wissen nicht viel über die Problem
Domain, kennen allerdings auftretende Probleme).
INDIREKTE QUELLEN: Handbücher (hauptsächlich für Prozesse und Abläufe, stimmen meist allerdings
nicht mit der Realität überein).
Da wir nun die verschiedenen Informationsquellen behandelt haben, geht es nun dazu, aus den
einzelnen Personen Benutzerrollen zu abstrahieren: die USER ROLE. Zuerst wird abstrahiert, dann
sortiert und arrangiert, bis man sich schlussendlich auf die wichtigsten Rollen fokussiert.
Real User
=>
Candidate Roles
=>
User Role
=>
Focal User Role
Die so gefunden Benutzer Rollen werden nun in einer ROLE MAP grafisch dargestellt.
Weiter gibt es noch eine Strukturierte Art, solche Rollen zu erfassen. Dies
Betracht auf das Taskmodell. Wichtige dabei erfasste Punkte sind:
Erfahrungsniveau, Benutzungsarten, bearbeitete Informationen, Wichtigkeit
besondere Funktionen, Risiken, Einschränkungen bei physikalischen Geräten
durch die Umgebung.
18/39
kann hilfreich sein in
Ausüber der Rolle,
der Usability-Aspekte,
und Einschränkungen
17.12.2007
User Interfaces 2
7.3.3.
Task Model
Das Task Model besteht aus ESSENTIAL USE CASES und einer USE CASE MAP. Das Ziel von den Use
Cases ist es, in der Sprache des Fachbereiches vereinfacht und von der Technologie lostgelöst die
üblichen Abläufe zu formulieren.
Dabei muss darauf geachtet werden, dass die Absicht (und nicht die Aktion) sowie die Verantwortung
(und nicht Reaktion) aufgezeigt werden. Nachfolgendes Beispiel behandelt dabei den Fall „Geldbezug
an einem Bankomat“:
Use Case: gettingCash
User Intention
Identify Self
System Responsibility
Verify Identity
Offer Choices
Choose
Dispense Cash
Take Cash
Obige Darstellung ist die meist verwendete Variante. Es gibt allerdings noch eine weitere, weitaus
detaillierte Variante. In dieser kommen mehr Faktoren ins Spiel:
Das ist am ehesten mit den Fully Dressed Use Cases von Larman zu vergleichen. Die im Ablauf
zusätzlich verwendeten Elemente (optionally, in any order, …) kennen wir auch bereits von UI1.
Natürlich können auch, wie bei Software Engineering 1 gelernt, die Use Cases grafisch dargestellt
werden. Dies ist die so genannte USE CASE MAP. Nachfolgend noch Beispiele dazu:
19/39
17.12.2007
User Interfaces 2
7.3.4.
Content Model
Der Teil besteht aus dem CONTENT MODEL und der NAVIGATION MAP. Im ersten Unterpunkt werden
die vorgängig erstellten Use Cases auf benötigte Tools (=Werkzeuge) und Materials (=Daten)
untersucht. Ziel dabei ist es, die für eine bestimmte Aufgabe benötigten Werkzeuge und Daten zu
ermitteln. Üblicherweise werden jegliche gefundenen Elemente anschliessend auf Post-It notiert und
in den so genannten Interaction Context geklebt. Als Resultat aus des Content Models entsteht ein
abstrakter Prototyp, welcher noch an keine konkrete Implementierung gebunden ist.
Obiges Beispiel zeigt eine unvollständige Liste von Zuweisungen aus dem Use Case auf das
zugehörige Content Model. Obige Darstellung verwendet die Tools & Materials-Notation. In dieser
haben die Symbole eine besondere Bedeutung. Nachfolgende eine Auflistung der verschiedenen
Möglichkeiten:
20/39
17.12.2007
User Interfaces 2
Weiter ist hier noch zu erwähnen, dass die Namenswahl sich systematisch zusammensetzen sollte:
Name = Name des Inhalts (+ Holder / Container / …)
Name = Name der Aktion (+ Do / Start / …)
Das zweite Element des Content Models ist die NAVIGATION MAP. Diese stellt den Zusammenhang,
beziehungsweise den Weg, zwischen den einzelnen Interaction Contexts grafisch dar. Je nach Anzahl
der gleichzeitig dargestellten Views handelt es sich entweder um einen Behavioral View oder eine
komplette architektonische Sicht. Ferner kann sie zum Auffinden von Problem und zur Überprüfung
der Komplexität eingesetzt werden.
Obiges Bild zeigt eine Übersicht über die einzelnen Elemente der Navigation Map. Zur Beschriftung der
„Actions“ wird weiter folgende Namenskonvention empfehlen:
Menu:
Button:
Icon, Tool:
Datei | Öffnen | …
[Schliessen]
<Fett>
21/39
17.12.2007
User Interfaces 2
Auch hier soll ein Beispiel natürlich nicht fehlen. Dieses ist einer alten Windows-Version entnommen
und demonstriert das Problem, dass ähnliche Einstellungen (Netzwerk) auf mehrere Subviews verteilt
sind.
7.3.5.
Operation Model
Das Operational Model wird nicht detaillierter behandelt. Es enthält physikalische Aspekte und
Geschäftsregeln. Auch Risikofaktoren können erwähnt werden. Ist vergleichbar mit den Business Rules
von RUP.
7.3.6.
Implementation Model
Beim Implementation Model schlussendlich geht es um die Konkretisierung der abstrakten Modelle. Es
werden also zu der abstrakten Beschreibungen passende reale GUI-Elemente ermittelt. Natürlich
geschieht dies unter Beachtung der allgemeinen Regeln für die visuelle Gestaltung.
7.4.
Element 3 – Organized Development Activities
22/39
17.12.2007
User Interfaces 2
COLLABORATIVE REQUIREMENTS DIALOG: Requirements beim Kunden und den Benutzern holen,
meist durch Dialog erreicht.
TASK MODELLING: Kernaktivität beim UCD. Klares und umfassendes Bild des Arbeitsumfeldes
erlangen. Entspricht den Modellen Role Model und Task Model.
DOMAIN MODELLING: Entwurf eines konzeptuellen Modells (Domain Modell). Für RUP zentrales
Element, bei UCD allerdings nur Nebenaktivität.
INTERFACE CONTENT MODELING: Entspricht dem Modell Content Model. Dabei wird ein abstraktes
Modell in einer speziellen Notation entworfen.
IMPLEMENTATION MODELING: Entspricht dem Modell Visual Design, also der endgültigen
Implementierung nach allen Entwürfen.
USABILITY INSPECTION: Benutzbarkeit des Entwurfs auf Basis Visual Design überprüfen.
OPERATIONAL CONTEXTUALIZATION: Läuft parallel zu den anderen Aktivitäten. Es sollen spezielle
Gegebenheiten (Beleuchtung, Lärm, …) und Anforderungen (Behinderungen, …) erfasst werden.
STANDARD AND STYLE DEFINITION: Läuft parallel zu den anderen Aktivitäten. Erstellen von StyleGuides und Standards.
OBJECT STRUCTURE DESIGN: Auch eine Kernaktivität des normalen Software Engineering, wobei ein
Design Modell erstellt wird. Für UCD allerdings nebensächlich.
CONCENTRIC CONSTRUCTION: iterative Implementierung nach Use Cases, für SE zentral, für UCD
nebensächlich.
ARCHITECTURAL ITERATION: Architektur iterativ verbessern und weiterentwickelnt. Für UCD
nebensächlich.
USABILITY INSPECTION: Bewertung der Bedienbarkeit auf Basis der schlussendlichen
Implementierung.
HELP SYSTEM AND DOCUMENTATION: läuft parallel, Hilfe und Benutzungshandbuch entwerfen.
7.5.
Element 4 – Iterative Improvement
Iteratives Vorgehen. Kennen wir vom RUP.
7.6.
Element 5 – Measure of Quality
Metriken zur Messung der UI-Qualität.
23/39
17.12.2007
User Interfaces 2
8. GOAL DIRECTED DESIGN (GDD)
8.1.
Allgemeines
8.1.1.
Einleitung
GDD behandelt Teile des SE-Prozesses, orientiert sich allerdings hauptsächlich an den Benutzern und
deren Zielen. Es kann als Ergänzung zu anderen SE-Methoden eingesetzt werden.
8.1.2.
GDD im SE-Prozess
8.1.3.
Begriffe
GOAL: Was ist der Antreiber für die Aktionen, welche eine Person durchführt. GDD konzentriert sich
hauptsächlich auf diese Ziele. Erreicht werden soll dadurch, dass eventuell neue Tasks entstehen
und ausgearbeitet werden.
TASK: Eine Tätigkeit, welche eine Person durchführt, um ein Ziel (=Goal) zu erreichen.
8.1.4.
Wer macht GDD?
GDD wird von so genannten INTERACTION-DESIGNERN umgesetzt. Ihr Ziel ist es, dass Verhalten des
Produktes zu analysieren. Es handelt sich somit um den ersten Schritt in der Softwareentwicklung,
worauf weitere Arbeiten (Visuelles Design, UI-Design) aufbauen können. Es ist zu beachten, dass
Benutzer und Entwickler nicht als Designer eingesetzt werden, da diese auf Grund Ihrer Vorkenntnisse
kein unabhängiges Bild des Problembereichs besitzen.
8.1.5.
Team-Struktur
Üblicherweise wird bei GDD in zweier Teams gearbeitet, welche aus dem Interaction Designer und
dem Design Communicator bestehen.
-
8.2.
Interaction Designer
Liefert kreative Ideen
Entwirft Konzepte
-
Design Communicator
Hält Ideen ausführlicher fest
Dokumentiert sauber
Klärt Detailfragen ab
Überblick über einzelne Phasen
8.2.1.
Research
Es werden Feldstudien (Interviews mit Benutzern und Auftraggeber, Beobachtungen, Literator,
Technologien, bestehende Produkte) durchgeführt. Daraus entstehen BENUTZUNGSMUSTER und
BENUTZUNGSZIELE.
8.2.2.
Modelling
Es werden die Arbeitsabläufe analysiert, daraus die Benutzer und die Domain modelliert. Das Ergebnis
sind DOMAINMODELLE und PERSONAS.
8.2.3.
Requirements
Hier werden die benötigten Funktionen und Bedürfnisse ermittelt. Fokussiert wird dabei auf die Ziele
und Bedürfnisse der Benutzer, nicht auf die einzelnen Aufgaben. In diesem Schritt entsteht CONTEXT
SZENARIOS, welche für das Management als erste Entscheidungsgrundlage dienen.
24/39
17.12.2007
User Interfaces 2
8.2.4.
Framework
In dieser Phase werden Datenobjekte und Attribute entworfen, weiter der Grundaufbau der einzelnen
Views skizziert. Hier sind natürlich die grundlegenden Entwurfsregeln (Usability, …) zu befolgen. Als
Ergebnis entsteht eine INTERACTION FRAMEWORK DEFINITION.
8.2.5.
Refinement
Die vorher skizzenhaft ausgearbeiteten Entwürfe werden hier detaillierter ausgearbeitet. Erstmals wird
auch auf Feedback von Entwicklern zurückgegriffen, welche die Machbarkeit beurteilen sollen. Hier
entsteht eine Form and BEHAVIOUR SPECIFICATION, welche das GUI Pixel genau vorschreibt. Dies ist
das zweite entscheidungskritische Dokument.
8.2.6.
Implementierung
Ist auf obiger Grafik nicht mehr drin. Es geht hier darum, dass die Interaction Designer auch nach
Ihrer Arbeit den Entwicklern bei Fragen zur Seite stehen sollen.
8.3.
Phase 1: Research
8.3.1.
Grundlegendes
Es geht um das Erforschen der Domain und Benutzer. Es werden nur qualitative (was, wie, warum)
und keine quantitativen Erfassungen durchgeführt . Die hier erzielten Resultate dienen als Grundlage
und zur Rechtfertigung gegenüber Auftraggebern. Ausserdem wird ein gemeinsames Verständnis des
Zielbereiches etabliert.
8.3.2.
Untersuchungsobjekte
Existierende Produkte (Funktionen, Bedienung, …)
Potentielle Benutzer
Umfeld (technisch und geschäftlich)
Vokabular
8.3.3.
Methoden
STAKEHOLDER INTERVIEWS: Befragung von Schlüsselpersonen in der Organisation. Bevorzugt aus
verschiedenen Abteilungen. Sollte vor der Benutzerbefragung durchgeführt werden. Es soll
herausgefunden werden, was das Management sich vorstellt, wie viel es kosten soll, in welcher Zeit
es entstehen soll.
SUBJECT MATTER EXPERT (SME) INTERVIEWS: Befragungen von Domainexperten. Zu beachten ist,
dass SME ein gutes Fachwissen besitzen, jedoch keine Interaction Designer sind!
CUSTOMER INTERVIEWS: Befragung der Kunden, was wird sich von der neuen Lösung erhofft? Was
war an der alten schlecht?
USER INTERVIEWS: Aktuelle und zukünftige Benutzer nach Ihren Problemen fragen. Wie und warum
wird die Anwendung eingesetzt? Die Ziele des Benutzers müssen klar herauskristallisiert werden.
USER OBSERVATION: Den Benutzern ist ihr eigenes Verhalten nur teilweise bewusst. Deshalb besser
beobachten als nur auf Interviews zu verlassen.
LITERATURE REVIEW: Erarbeiten von Domain-Kenntnissen, Analyse des Markts und bestehender
Technologien, aktuelle Meldungen zum Fachbereich.
PRODUCT AUDITS: Produkte der Konkurrenz analysieren.
CONTEXTUAL INQUIRY / ETHNOGRAPHIC INTERVIEWS: Kennen wir bereits von „Beobachten von
Benutzern“. Der Designer beobachtet die Zielperson in Ihrem realen Arbeitsumfeld bei den
getätigten Arbeiten, stellt zwischendurch klärende Fragen. Es ist ferner wichtig, eine geeignete Zahl
an Personen zu beobachten, da je nach Alter / Land / Firmengrösse völlig andere Arbeitsmuster
möglich sind. Ein grober Ansatz sagt, dass pro Benutzerrolle mindestens 4 Personen befragt werden
sollen. In den Befragungen selber soll man sich primär darauf konzentrieren, die Ziele des Benutzers
zu erfahren, nicht wie er diese umsetzt.
8.4.
Phase 2: Modelling
8.4.1.
Grundlegendes
Hier geht es um das abstrahieren von Benutzern und deren Ziele. Daraus entsteht die wichtigste
Grundlage: eine präzises Modell des Benutzers und seinen Zielen.
25/39
17.12.2007
User Interfaces 2
8.4.2.
Warum Personas?
Ausgehend von den vorgängig gesammelten Informationen werden nun
Verhaltensmuster der realen Benutzer analysiert und in Modelle (Personas) umgesetzt.
gemeinsame
Personas sind darum wichtig, da ein UI-Entwurf für bestimmte Benutzer mit speziellen Bedürfnissen
designed wird. Ein UI mit breiter und möglichst vielfältiger Funktionalität führt zu einem komplexeren
und schwer benutzbaren UI für alle.
Weiter wird durch die Formulierung von Personas erreicht, dass jeder Entwickler dasselbe Modell in
seinem Kopf hat. Weiter wird vermieden, dass die Designer das UI für sich entwerfen, da genau
festgelegt ist, welche Bedürfnisse und Ziele vorliegen.
8.4.3.
Personas
Wie bereits erwähnt wurde repräsentieren Personas eine Klasse von Benutzern, beziehungsweise ein
bestimmtes Benutzungsmuster. Zur besseren Unterstützung der Designer kann den Personas sogar
ein Passfoto mit Lebenslauf zugewiesen werden.
Zu beachten ist, dass schlussendlich nicht nur eine Durschnitts-Persona entsteht. Für eine Aufgabe
entsteht eine ganze Sammlung von Personas. Wichtig ist dabei immer, dass jede Persona eine
Motivation in Form von Zielen besitzt.
8.4.4.
Benutzer Rollen
Als Abgrenzung zu den Benutzerrollen kann gesagt werden, dass sich diese auf die auszuführenden
Aufgaben konzentrieren, nicht auf die Ziele der einzelnen Personen. Ausserdem handelt es sich um
Gruppen, nicht Personas.
8.4.5.
Ziele
LIFE GOALS (LEBENSZIELE): tiefe Ziele, innere Motivation. („Sei der beste!“)
EXPERIENCE GOALS (ERFAHRUNGSZIELE): Gefühle bei der Benutzung des Produktes („glücklich“)
END GOALS (ERGEBNISZIELE): konkrete Ergebnisse aus der Produktbenutzung („Auftrag abwickeln“).
Es müssen die End und Expierence Goals befriedigt werden, da sich andernfalls der Benutzer schlecht
fühlt oder eine Anwendung ohne sinnvollen Nutzen entsteht.
8.4.6.
Konstruktion von Personas
IDENTIFY BEHAVIORAL VARIABLES: Es müssen Unterscheidungsmerkmale für die Klassifizierung
einzelner Gruppen ausgearbeitet werden. Dazu können noch einige demografische Variablen
hinzugefügt werden, insgesamt sollten etwa 20-30 Merkmale gefunden werden.
MAP SUBJECTS TO BEHAVIORAL VARIABLES: Jetzt müssen die einzelnen befragten Personen für jedes
der vorgängig gefunden Merkmale klassifiziert werden. Ein Beispiel hierzu findet sich weiter unten.
IDENTIFY SIGNIFICANT BEHAVIOR PATTERNS: Nun wird probiert aus den vorgängig Positionierten
Gruppen gemeinsame Elemente zu Bilden. Diesen Mustern werden Namen gegeben.
26/39
17.12.2007
User Interfaces 2
LIST CHARACTERISTICS AND RELEVANT GOALS: Für die wichtigsten Muster werden jetzt ausführlichere
Informationen zusammengetragen. Es sollten der übliche Tagesablauf und die gemeinsamen Ziele
klar herausgefiltert werden. Wichtig ist hierbei, dass Ziele herausgefunden werden, da diese das
wichtigste Element von GDD darstellt.
CHECK FOR COMPLETENESS: Hier wird noch mal überprüft, ob die zusammengetragenen Muster
wirklich komplett sind und ob es Überschneidungen gibt.
DEVELOP NARRATIVE: Im letzten Schritt wird nun noch ein ausführlicher Text zu den einzelnen
Mustern geschrieben. Es entsteht somit Personas. Einzelne Stichworte genügen hierbei nicht, es
sollten wirklich vorstellbare Personen entstehen. Dazu können auch persönliche Details hinzugefügt
werden.
8.4.7.
Persona Typen
PRIMARY: Für diese Persona wird das UI entworfen. Pro primäre Persona entsteht ein UI.
SECONDARY: Wird durch das Interface der primären Persona befriedigt. Eventuell eine Erweiterung
um 1-2 Bedürfnisse möglich.
SUPPLEMENTAL: Ergänzende Persona, werden durch primäre UI befriedigt.
CUSTOMER: Wird wie Sekundär behandelt.
SERVED: Keine Benutzer, sind jedoch von der Benutzung des Produktes betroffen. Sollten wie
sekundäre behandelt werden.
NEGATIVE: Keine Benutzer, dienen zur Abgrenzung. Für diese wird nicht designed.
8.4.8.
Andere Modelle
WORKFLOWS: Arbeitsablauf beachten, verwendete Informationsquellen, Resultate der Arbeiten.
Denkbar sind auch Abläufe zwischen mehreren Personen. Können in Aktivitätsdiagrammen
aufgezeichnet werden.
ARTIFACT MODEL: Sind verwendete Materialien es wert, in der Anwendung abgebildet zu werden?
CULTURAL MODEL: Jede Kultur hat Ihre Unterschiede. Diese sollten in die Personas eingehen.
PHYSICAL MODEL: Das physikalische Umfeld hat auch Einfluss auf die Benutzung der Applikation.
8.5.
Phase 3: Requirements
8.5.1.
Grundlegendes
Bei dieser Phase geht es darum, die Anforderungen aufzunehmen. Dabei geht es um die benötigten
Funktionen, Daten, allfällige Probleme und Randbedingungen. Anders als bei Use Cases wird hier
allerdings nicht detailliert auf diese eingegangen, sondern auf nur auf einem hohen Level
festgehalten. Das Ziel ist es, dass auch die Entscheidungsträger des Projekts den Text verstehen
können.
8.5.2.
Context Scenario
Ein Context Scencario (=CS) ist eine erzählende Beschreibung von Personas. Es wird darin darauf
eingegangen, wie diese ihre Ziele erreichen. Anders als bei Use Cases (=UC) wird bei CS allerdings
nicht so stark ins Detail gegangen. Im Vordergrund liegen mehr die Aktionen und Ziele der Personas,
weniger eine detaillierte Spezifizierung der einzelnen Tätigkeiten.
8.5.3.
Unterschiede zwischen Context Scenario und Use Cases
CS erzählt viel ausführlicher, eventuell einen ganzen Tagesablauf. UC enthält nur die wirklich für das
System wichtigen Elemente.
Bei CS steht die Person und Ihre Ziele im Vordergrund, bei UC die einzelnen Tätigkeiten und
Reaktionen des Systems.
8.5.4.
Vorgehen
CREATING PROBLEM AND VISION STATEMENTS: Wo liegt das Problem? Was ist das Ziel?
BRAINSTORMING: Bestehende Ideen werden festgehalten um den Kopf für unkonventionelle
Lösungen frei zu bekommen.
IDENTIFYING PERSONA EXPECTATIONS: Was erwarten die unterschiedlichen Persona? Was sind Ihre
Ziele? Funktionale Anforderungen? Anforderungen an Daten?
CONSTRUCTING CONTEXT SCENARIOS: Pro primärer Persona wird nun ein CS erstellt. Üblichweise wird
ein optimaler Tagesablauf im realen Umfeld beschrieben.
IDENTIFYING NEEDS: In den entstandenen CS werden die konkreten Bedürfnisse gesucht.
27/39
17.12.2007
User Interfaces 2
8.6.
Phase 4: Framework
8.6.1.
Grundlegendes
In diesem Schritt wird das UI entworfen. Dazu werden benötigte Elemente ermittelt und die
räumliche, bzw. zeitliche Anordnung dieser bestimmt.
8.6.2.
Vorgehen
DEFINING FORM FACTOR AND INPUT METHODS: Worauf soll die Anwendung laufen? Was sind die
Eingabe- und Ausgabegeräte?
DEFINING VIEWS: Welche primären Screens werden zur Erfüllung der End-Goals benötigt?
DEFINING FUNCTIONAL AND DATA ELEMENTS: Welche Funktionen und Daten müssen dargestellt
werden?
DETERMINING FUNCTIONAL GROUPINGS AND HIERARCHY: Gruppierung der Elemente, grundlegende
Positionen (Beispiel: Navigation immer links) festlegen.
SKETCHING THE INTERACTION FRAMEWORK: Grober Entwurf des Aufbaus. Das Interaction Framework
ist eines der Artefakte von GDD.
CONSTRUCTING KEY PATH SCENARIOS: Skizzierung des Hauptablauf durch das GUI.
8.7.
Phase 5: Refinement
8.7.1.
Grundlegendes
Die in der letzten Phase erstellten Entwürfe werden nun detaillierter ausgearbeitet. Die Modelle
werden ausserdem genauer beschrieben.
8.7.2.
Vorgehen
DRAFTING THE LOOK AND FEEL: Visuelles Design festlegen. Das könnten zum Beispiel die Schriftart,
Schriftfarbe, Abstände und ähnliches beinhalten.
CONSTRUCTING VALIDATION SCENARIOS: Die Screens und Views für die weniger wichtigen Ziele
werden entworfen. Hierbei handelt es sich um Erweiterung von bestehenden Abläufen und oft auch
Grenzfallabdeckungen.
FINALIZING THE DESIGN: Aus all dem wird nun ein endgültiger GUI-Entwurf erstellt, eventuell sogar
mit Prototyp.
28/39
17.12.2007
User Interfaces 2
8.8.
GDD-Überblick
29/39
17.12.2007
User Interfaces 2
9. LOW-FIDELITY PROTOTYPING
9.1.
Warum Prototypen
Prototypen werden dazu eingesetzt, ein frühes Feedback zu unserem Design zu erhalten. Ausserdem
können mit ihrer Hilfe verschiedene Lösungsansätze miteinander verglichen und Anforderungen auf
Richtigkeit geprüft werden.
9.2.
Warum Low-Fidelity?
Der Ausdruck „Low-Fidelity“ sagt aus, dass es sich hierbei um Prototypen auf sehr tiefem Niveau
handelt, also um Skizzen ohne grosse Details.
Übliche Methoden (Visio, GUI-Bilder) benötigen sehr viel Zeit. Mittels Prototypen auf tiefem Niveau
kann sehr viel Zeit eingespart werden, ausserdem sind keine teuren Anschaffungen nötig. Da bei
dieser Idee keine reale Implementierung existiert, muss einer der Designer dabei natürlich immer den
Computer „spielen“, bzw. die Reaktionen des Computers der Testperson erläutern.
Als Nachteil muss erwähnt werden, dass das Umsetzen von Low-Fidelity Prototypen in ein
elektronisches Format nicht automatisiert werden kann. Auch das Archivieren von Entwürfen in
Papierform ist aufwendiger (Scannen, …).
9.3.
Paper Prototyping
Hier wird mit üblichen Bastelutensilien (Papier, Stifte, Post-It, Schere, Leim) ein UI entworfen, welche
anschliessend mit einer Testperson durchgespielt wird. Aktionen des Systems werden dabei vom
Designer vorgenommen.
Ein weiterer Vorteil hierbei ist, dass die Designer in Ihren Ideen nicht durch ein Design-Tool
eingeschränkt sind. Ferner wird die Ideensammlung angeregt.
9.4.
SILK
Zu erwähnen bleibt hier noch SILK. Hierbei handelt es sich um eine Software, mit welcher UI-Skizzen
gezeichnet werden können. Die SW erkennt anschliessend anhand der gezeichneten Formen die
Funktion, bzw. Bedeutung des jeweiligen Element. Darauf hin kann in einen Testmodus geschaltet
werden, in welchem das GUI direkt am Computer getestet werden kann.
30/39
17.12.2007
User Interfaces 2
10.
USER INTERFACE TESTS
10.1. Labor- und Feldtests
Der grosse Vorteil von Feldtests ist, dass diese im natürlichen Arbeitsumfeld stattfinden und somit
auch über längere Zeit problemlos durchgeführt werden können. Allerdings muss man dabei auch die
entstehenden Störeinflüsse (Lärm, Unterbrechung) in Kauf nehmen. Üblicherweise werden Feldtests
dann eingesetzt, wenn das Arbeitsumfeld wichtig ist.
Im Labor hingegen kann auf ein spezialisiertes Equipment und eine ruhige Atmosphäre zurück
gegriffen werden. Allerdings fehlt somit natürlich das reale Umfeld. Für gewöhnlich werden Labortests
dann eingesetzt, wenn das reale Umfeld zu gefährlich ist oder der Benutzer „beeinflusst“ werden soll.
10.2. Typen von UI Tests
10.2.1. Cognitive Walkthrough
Beim Cognitive Walkthrough wird die Erlernbarkeit der
Anwendung durch einen Experten überprüft. Der Experte
geht dabei ein Entwurf / Konzept Schritt für Schritt durch
und überprüft es auf potentielle Probleme.
Benötigt werden dafür eine Spezifikation oder ein
Prototyp mit den zugehörigen Aufgaben.
10.2.2. Heuristic Evaluation
Bei diesem Test wird ein Design auf Basis von 10
Usability Kriterien überprüft. Das Hauptziel ist es dabei,
grundlegende Design-Probleme zu erkennen und
beheben.
10.2.3. Experimental Evaluation
Hier wird im Labor eine konkrete Implementierung mit
Testgruppen überprüft. Dabei werden oft verschiedene
Varianten miteinander verglichen. Es steht offen, ob eine
Testgruppe immer alle Varianten überprüft oder nur
jeweils eine einzelne.
Die Beobachter legen sich für die Durchführung messbare
Testkriterien fest, welche anschliessend statistisch
ausgewertet werden.
10.2.4. Query Techniques
Hier wird zwischen Interviews und Fragebögen
unterschieden. Vorteil der Interviews ist es, dass auf
spezielle Antworten genauer eingegangen werden kann.
Dafür benötigen sie sehr viel Zeit.
Bei Fragenbögen hingegen ist es umgekehrt: es kann
schnell eine grosse Zielgruppe erreicht werden, allerdings
kann bei unklaren Antworten nicht detaillierter darauf
eingegangen werden.
31/39
17.12.2007
User Interfaces 2
10.2.5. Eye Tracking
Hier wird über eine spezielle Hardware die
Augenbewegungen der Testperson verfolgt. Je mehr
Augenbewegungen bei der Bedienung der Anwendung
nötig sind, desto komplexer ist diese auch.
Wird oft für Websites verwendet, damit man
herausfindet, wohin die Benutzer als erstes schauen.
10.2.6. Observation
Ein sehr grosse Kategorie, in welcher viel möglich ist.
Detaillierter auf diesen Punkt wird bei den „Usability
Tests“ eingegangen.
Gemeinsamkeiten aller Lösungen: Es wird meist eine
konkrete Implementierung durch eine Testperson
verwendet, die Beobachter schauen bei der Verwendung
zu.
10.3. Usability Tests
10.3.1. Einleitung
Bei Usability Tests wird eine Anwendung (oder ein Gerät) auf ihre Bedienbarkeit geprüft. Dazu wird
mit Versuchspersonen unter Beobachtung im Testlabor ein Test durchgeführt.
Das grösste Problem bei UT sind, dass ein funktionsfähiges System benötigt wird. Daher sind sie meist
erst gegen Ende der Programmierung durchführbar, anschliessende Änderungen werden somit sehr
teuer bzw. sind gar nicht mehr möglich. Allerdings können gut alte Produkte oder Konkurrenzprodukte
vor einer Neuprogrammierung getestet werden.
10.3.2. Usability Labor
Üblicherweise wird der Test in einem Labor durchgeführt. Dabei existiert ein Test- und ein
Auswertungsraum.
10.3.3. Usability Test Light
Da in der Realität nicht immer ein voll ausgestattetes Labor verfügbar ist kann der Test auch in einer
abgespeckten Form durchgeführt werden. Dabei arbeitet die Testperson an einem Computer und wird
dabei durch den Facilitator durch die Aufgabe geführt. Über eine Kamera werden die Aktionen
aufgezeichnet und in einem separaten Raum durch Beobachter / Entwickler mitverfolgt.
10.3.4. Aufgaben der Personen
Testperson: Führt den Test durch.
Facilitator: Einzige Ansprechperson für Testperson. Sollte den Test mindestens einmal vorher selber
gemacht haben und sich in die Testperson einfühlen können. Allerdings sollten die Testpersonen
nicht in ihrer Tätigkeit gelenkt werden.
Beobachter: Hat keinen direkten Kontakt zur Testperson. Konzentriert sich darauf, die
Beobachtungen zu dokumentieren. Auch die Entwickler befinden sich im „Beobachtungsposten“.
10.3.5. Vorbereitung und Durchführung
Begrüssen, Labor und Test erklären. Klar machen, dass die Software und nicht die Person getestet
wird, anschliessend die Aufgaben und den Ablauf („Lautes Denken erwünscht!“) erklären.
Anschliessend den Test durchführen, dabei mit Kamera aufzeichnen
10.3.6. Auswertung
Das Video anschauen und die einzelnen Beobachtungen untereinander diskutieren. Auch Fragebögen
sind möglich. Das ganze wird anschliessend in einem Bericht festgehalten.
32/39
17.12.2007
User Interfaces 2
11.
UI DESIGN IM WEB
11.1. Posture für SW-Anwendungen
11.1.1. Sovereign Posture
Die Applikation beherrscht den Desktop und wird vom Benutzer lange Zeit mit hoher Aufmerksamkeit
bedient. Beispiele: Word, Excel.
11.1.2. Transient Posture
Hierzu gehören kleine Applikationen und Fenster, welche nur kurz am Rande verwendet werden.
Danach werden sie gleich wieder geschlossen. Beispiele: Lautstärkeregelung, Taschenrechner.
11.1.3. Daemonic Posture
Anwendungen dieser Kategorie laufen unsichtbar im Hintergrund und sind meist nur als Icon in der
Status-Bar ersichtlich. Beispiel: Druckvorgang.
11.1.4. Auxiliary Posture
Diese Gruppe wird innerhalb einer sovereign als Hilfsfenster verwendet. Beispiel: Hilfe im Internet
Explorer.
11.2. Begriffe
11.2.1. Website
Eine Website bietet dem Benutzer hauptsächlich Informationen an. Von der Darstellung her handelt es
sich dabei um ein sovereign Posture (bildschirmfüllend), vom Verhalten allerdings um ein transient
Posture (nur kurze Benutzung, Klick auf einen Link).
11.2.2. Webapplication
Webapplikationen haben die Eigenschaft, dass diese transaktional verwendet werden. Es werden
Ansichten dynamisch aus einer Datenbank generiert, das Verhalten ist wichtiger als der Inhalt.
Hier kann man zwischen drei Kategorien unterscheiden. Die erste Kategorie sind APPLETS, also nur
sehr kleine Anwendungen und fallen somit in die Kategorie transient Posture. Dann gibt es
ECOMMERCE-Anwendungen, welche nur die Aktivität transient anbieten (Kauf). Und die letzte Gruppe
sind SOVEREIGN ANWENDUNGEN, welche sich wie SW-Anwendungen verhalten, beispielsweise ein
Webmail.
11.3. Web vs GUI
Eine GUI-Anwendung wird üblicherweise gekauft und installiert, anschliessend für einen bestimmten
Zweck eingesetzt. Daher sind die Benutzer auch bereit, Zeit in das Erlernen der Applikation zu
investieren.
Bei Web-Anwendungen ist das anders. Hier wollen die Benutzer Informationen gratis erhalten,
möglichst ohne Zeitverlust. Das heisst für uns also, dass die Webseiten auch ohne Nachdenken klar
verständlich sein müssen. („Don’t make me think!“)
11.4. Facts of Life (Krug)
11.4.1. We don’t read pages, we scan them.
33/39
17.12.2007
User Interfaces 2
Benutzer sind üblicherweise nicht bereit komplette Texte zu lesen. Deshalb sollten wir in erster Linie
Akzente setzen (Titel, Schlüsselwörter, Bilder) um den scannenden Surfer zu einem lesenden Surfer zu
machen. Die relevanten Inhalte müssen klar ersichtlich sein, lange Texte sollten durch
Hervorhebungen und Zusammenfassungen zum skimmen einladen.
11.4.2. We don’t make optimal choices, we satisfice.
Benutzer betrachten nicht erst alle Optionen und wählen anschliessend die beste. Benutzer gehen
durch die Liste und wählen die erste Möglichkeit, welche vernünftig erscheint und zufrieden stellend
ist. Möglicher Grund: Es gibt keine Bestrafung für falsche Selektionen, wir haben keine Zeit für eine
ausführliche Analyse.
11.4.3. We don’t figure out how things work. We muddle through.
Kennen wir alle: wer liest beim Kauf eines neuen Gerätes schon die komplette Bedienungsanleitung
durch? Lieber gleich ausprobieren und sich irgendwie „durchwursteln“. Dasselbe gilt für die Bedienung
einer Website.
11.5. Kommunikation
Eine Website ist auch eine Art der Kommunikation. Sie kann dabei als indirekt, unpersönlich,
unfokussiert, unsymmetrisch, unverbindlich, selbstbezogen und humorlos charakterisiert werden.
Wie wir ausserdem seit KomIng wissen: wer kommuniziert definiert die Beziehung. Wir müssen beim
Benutzer deshalb positive Gefühle erzeugen. Dies kann durch Verständlichkeit der Inhalte und
nonverbale Kommunikation (Schrift, Look & Feel, Sprachwahl) unterstützt werden.
11.6. Motiviation / Demotivation
MOTIVIEREND: Erotik, Auktionen, Communities, Service, Spiele
DEMOTIVIEREND: Blabla, Werbung, Flash-Intros, Wartezeiten
11.7. User-Typen
SCHNUPPERER: orientiert sich an Offline-Marken, wechselt schnell von Seite zu Seite. Sehr viele
verschiedene Themengebiete.
CONVENIENCE: hat lange Erfahrung im Netz, sucht nach Nützlichem. Verbringt wenig Zeit auf einer
Website und besucht auch weniger als der Durchschnitt.
KONTAKTER: Neu im Web, besucht wenige Seiten. Oft nur Maildienste, 61% Frauen.
ROUTINIERS: Sucht schnell und gezielt, verbringt wenig Zeit online. Liest hauptsächlich News und
Information, diese dafür länger als der Durchschnitt.
SURFER: Nutzt ein sehr breites Angebot, gehen jeden Trend mit. 88% Männer.
SCHNÄPPCHENJÄGER: Stöbert und kauft, hauptsächlich bei Auktionen anzutreffen.
ENTERTAINMENT: Surfen zur Unterhaltung, oft für Hobbies oder Spiele. Sind lange im Netz und
verbringen durchschnittlich doppelt so viel Zeit auf einer Website als normale Benutzer.
34/39
17.12.2007
User Interfaces 2
11.8. Gestaltungsaspekte fürs Web
11.8.1. Prinzipien
Bei ENTSCHEIDUNGEN kommt es zu einer Handlungstendenz durch höheren Nutzen, geringere Nähe
oder geringere Kosten. Deshalb sollte man die Alternativen in einem überschaubaren Rahmen halten,
Attraktivität der Ziele verdeutlichen und die Distanz zu den wichtigen Elementen minimieren.
Andernfalls droht die Gefahr durch Ablenkung durch weniger nützliches.
Für HANDLUNGEN ist entscheidend, wie viel Aufwand zur Erreichung eines Zieles betrieben werden
muss. So kann man als Beispiel sagen, dass durch jeden Klick vom Start zum Ziel 20% der Benutzer
verloren gehen. Daraus folgt, dass Handlungen strukturiert und möglichst einfach /schnell
durchgeführt werden sollten. Auch eine Rückmeldung nach jedem Teilschritt bringt Vorteile.
11.8.2. Sprache
Die Sprache sagt viel über die Beziehung zwischen Autor und Leser aus. Eine DIALOG-ÄHNLICHE („Wir
begrüssen Sie“) ist dabei einer BESCHREIBENDEN („Die Firma X begrüsst Ihre Kunden“) Schreibweise
vorzuziehen.
Ein anderer Aspekt ist die Unterscheidung zwischen DEONTATION (Bedeutung des Begriffes, bewusst
wahrgenommen) und KONNOTATION (Gedankenverbindung, unbewusst wahrgenommen). Gerade die
Konnotation hat für jeden Leser eine unterschiedliche emotionale Bedeutung. So sollte man bei
wichtigen immer überlegen, was für Gefühle (einladen / abschreckend, interessant / langweilig, …)
beim Leser erzeugt werden könnten. Nachfolgend ein Beispiel dazu:
Als letztes Thema zu „Sprache“ soll hier noch die NAVIGATIONSMÖGLICHKEIT dieser erläutert werden.
Falls diese für die Navigation eingesetzt werden soll, so muss diese eindeutig, überschneidungsfrei
und vertraut sein. Es ist jedoch trotz allem schwierig, gute Menüs zu realisieren, da die
Kommunikationsfähigkeiten stark begrenzt sind. Aus diesem Grund ist Moderation zu empfehlen.
Dabei handelt es sich um an die Nutzer gerichtete kurze Textpassagen, welche bei
Navigationsentscheidungen hilft.
11.8.3. Bilder
Bilder brauchen ausreichend FLÄCHE, um zu wirken. Darum ist es besser, weniger Bilder zu
verwenden, diese dafür grösser zu machen. Auch muss man ständig beachten, dass bei der
Verwendung von Bildern die Ladezeiten stark ansteigen können. Aus diesen gründen sollten diese
sehr sorgfältig gewählt werden.
Es ist zwar grundsätzlich möglich, eine Seite ganz ohne Bilder zu gestalteten (was umgekehrt nicht
klapp!), allerdings sind diese für die Ästhetik einer Seite wichtig.
Falls man Bilder als NAVIGATION verwenden will, so müssen diese immer mit einem Text versehen
werden. Nur so werden diese auch wirklich richtig verstanden. Es gibt allerdings auch einige, wenige
Ausnahmen (Haus, Lupe, Drucker).
35/39
17.12.2007
User Interfaces 2
Ähnliches gilt auch für normale Bilder. Diese sollten immer mit einer BILDUNTERSCHRIFT versehen, da
diese die Aussage des Bildes beeinflusst. Andernfalls werden diese wohlmöglich falsch verstanden und
interpretiert.
Ein anderes hier noch zu erwähnendes Thema sind Key Visuals. Bei diesen Schlüsselbilder handelt es
sich um Symbole, welche bestimmten Inhaltsbereichen zugeordnet werden. So sind zum Beispiel alle
Seiten zum Thema „Finanzen“ mit einer Geldnote markiert.
11.8.4. Wahrnehmung
Wir haben zwei getrennte Varianten der visuellen Verarbeitung, die zentrale und periphere
Wahrnehmung. Diese werden wie folgt charakterisiert:
Wenn wir obige Tabelle analysieren, so können wir daraus ableiten, dass ANIMATIONEN die periphere
Wahrnehmung aktiviert. Dadurch wird der Seitenbesucher jedoch in seinem Denkvorgang gestört und
vom wesentlichen abgelenkt. Animationen sollten darum nur dann eingesetzt werden, wenn diese
auch wirklich verwendet werden sollen (Wetterkarte, Bewegungsablauf). Auch FLASH-INTROS lenken
nur unnötig vom wesentlichen Inhalt ab und werden deshalb meist übersprungen.
Um die AUFMERKSAMKEIT eines Benutzers zu gewinnen können Grösse, Kontrast, Farbe, Position und
Reihenfolge eingesetzt werden. Ziel: Auf allen Seiten den Benutzer lenken und auf Wichtiges
hinweisen.
Dasselbe Ziel verfolgen die EYE-CATCHER, welche auf der Startseite eingesetzt werden. Nachfolgend
die üblichen Mittel:
BEWEGUNG: höchste Wirksamkeit, stören allerdings schnell. Vorsichtig einsetzen.
FARBEN: Besonders rot wirkt, Buntheit ist störend.
AUGEN: Erzeugt eine Alarmwirkung beim Benutzer.
GESICHTER & MIMIK: Unser Gehirn ist auf Gesichter spezialisiert (Kommunikation).
EROTISCHE SIGNALE: Hoher Reiz, jedoch kaum in seriösem Umfeld einsetzbar.
11.8.5. Navigation und Orientierung
Beim Suchen wird zwischen zwei User-Typen unterschieden: dem LINK-DOMINANTEN und dem
SUCHBOX-DOMINANTEN. Der erste klickt sich dabei lieber durch Hierarchien, der zweite verwendet ein
Suchfeld.
Beim Browsen (Link-Dominanter Typ) existiert allerdings das Problem, dass man meist keinen
Überblick über die Grösse einer Website hat. Auch der Orientierungssinn ist ohne Hilfsmittel nicht zu
gebrauchen. Hauptziel einer Navigation muss es deshalb sein, dem Besucher mitzuteilen wo er ist
(Orientierung) und ihn bei seiner Suche nach der gewünschten Information zu unterstützen.
Bei einer PERSISTENTEN NAVIGATION ist diese auf jeder Seite immer an demselben Ort vorhanden. Ein
Logo sollte dabei mitteilen, auf welcher Seite man sich gerade befindet. Die Kategorien sollten in
Sektionen (Hauptgruppen) und Untersektionen (Untergruppen der aktuellen Hauptgruppe) gegliedert
36/39
17.12.2007
User Interfaces 2
werden. Auch Utilities (Links zu wichtigen Elementen: Home, Kontakt, …) dürfen nicht fehlen.
Nachfolgend die Website von Amazon als gutes Beispiel:
Logo (ID), Hauptgruppe und Untersektionen sowie Utilities sind vorhanden. Einzig die Suchbox kann
bemängelt werden. Besser wäre eine einfacheres Inputfeld mit einem „Suchen“-Button.
Eine weitere Navigationshilfe sind BROTKRUMEN. Diese befinden sich jeweils ganz oben auf einer
Website und zeigen, in welcher Kategorie man sich gerade befindet. Der letzte Eintrag sollte dabei
immer fett formatiert sein.
Sie sind hier: Home > Arts > Visual Arts > Phototgraphy
11.8.6. Home Page
Die Gestaltung der Home Seite ist ein komplexes Problem. Es gilt viele Dinge auf sehr wenig Platz
unterzubringen. Hier einige Beispiele: Aufgabe, Hierarchie, Suchfunktion, Shortcuts. Unverzichtbares
Hauptziel ist es jedoch auf jeden Fall, dem Besucher das BIG PICTURE zu übermitteln: Was ist das?
Was gibt es? Was kann ich tun?
Eine (und auch die beste) Möglichkeit dazu sind TAGLINES. Dabei handelt es sich um kurze Slogans,
welche neben der Seiten-ID (Logo) stehen. Sie sollten klar, informativ und clever gewählt werden.
Taglines sollten immer verwendet werden, ausser es handelt sich um sehr grosse Firmen wie eBay.
Eine andere Möglichkeit sind WELCOME BLURBS. Dabei handelt es sich um einen Willkommenstext,
welcher dem Benutzer mitteilt, was er auf der Seite erwarten kann.
Auf der Startseite kann ausserdem ausnahmsweise auch eine andere NAVIGATION verwendet werden
– sofern diese nicht allzu anders ist. Denkbar ist eine ausführlichere Version, beispielsweise mit
beschreibendem Text. Um Platz zu sparen werden oft Rollovers oder Pulldowns verwendet. Nachteil:
diese sind schwerer lesbar und müssen zuerst gefunden werden.
Weitere vermeidenswerte Inhalte für die Startseite: Zu viel Promotion, zu viel Cross-Promotion
(Werbepartner, zu viel und zu klein) und die Gier nach User-Daten (Registrierung vor Angebot nötig).
37/39
17.12.2007
User Interfaces 2
12.
USER INTERFACE VIELFALT
12.1. Gadgets
12.1.1. Scrollbar
Problem: Wenn zuviel gescrollt muss für die Korrektur ein langer Weg zurückgelegt werden.
Weiterentwicklung: An beiden Enden „Doppelpfeile“, verkürzt Weg.
Ausserdem benötigt die Bar viel Platz für wenig Funktionalität. Zur Verbesserung werden beim
Scrollen oft Titel angezeigt oder Lesezeichen ermöglicht.
12.1.2. Spin-Buttons / Slide-Spinner
Kennen wir von Eingabefeldern. Diese sind oft mit kleinen Pfeilen zum Ändern der Werte im Feld
ergänzt. Ein Slide-Spinner ist eine Weiterentwicklung, wobei bei langem drücken des Spin-Buttons ein
Slider angezeigt wird, um schneller die Werte zu verändern.
12.1.3. Message Box
Problem: modaler Dialog, stoppt laufende Aktivität und verdeckt die Arbeitsfläche. Zeitverlust beim
Arbeiten, eventuell sogar Verlust von Informationen im STM. Alternative: Transparente Boxen, welche
bei Click oder Tastendruck verschwinden.
12.1.4. Exctraction Controls
Kennt man von Outlook 2003. Dort wird beim Eintippen einer Adresse automatisch die jeweiligen
Feldinformationen richtig auf die Kontaktinformationen zugeteilt. Auch Datumsfelder erkennen oft
intelligent verschieden Datumsformate.
12.1.5. Fisheye Menu
Kennt jeder Mac-User: Beim näher kommen mit dem Mauszeiger vergrössern sich einzelne Objekte.
Weiter entfernte Objekte werden nur sehr klein angezeigt. So können lange Listen (Schriften, Namen,
…) kompakter anzeigen.
12.1.6. Flow Menu
Bekannt aus Videospielen. Ein Menu ist konzentrisch um den Mauszeiger arrangiert, durch Auswählen
der Buttons auf dem Kreis erscheinen andere Menus. Vorteil: Kein weites „scrollen“ nötig, alles direkt
beim Zeiger ausführbar.
12.2. Filesystem
12.2.1. Files & Save
Das Implementierungsmodell (HD -> RAM -> HD) erzeugt beim Programmierer den Eindruck, dass
Daten „gespeichert“ werden. Für den Benutzer ohne Vorkenntnisse ist dies jedoch absolut
unverständlich, will er doch beim Ändern eines Textes, dass seine Anpassungen übernommen werden,
speichern bedeutet ihm nichts!
Ein weiteres Beispiel ist die „Save as…“-Option. Man könnte fälschlicherweise annehmen, dass dabei
eine Kopie gespeichert wird. Allerdings wird mit der Datei fortgefahren, die gerade gespeichert wurde,
also dem neuen Namen.
Idee zur Reduzierung des Problems ist eine Umgestaltung des „Datei“-Menus. Dabei sollen
aussagekräftigere Beschriftungen gewählt werden („Save as…“ => „Rename“), welche besser mit
dem mentalen Modell der Zielperson übereinstimmen.
12.2.2. Andere Strukturen
Es gibt verschiedene Ansätze, welche probieren, eine Dateisystem ohne Dateien oder Dateinamen zu
realisieren. Die Struktur wird dabei vom System selber erstellt und ist für den Enduser nicht
ersichtlich. Dies ist für Power-User allerdings eine riesige Umgewöhnung!
Beispiel: Jedes Dokument trägt einen Titel, über die Volltextsuche kann dann nach dem benötigten
Dokument gesucht werden.
38/39
17.12.2007
User Interfaces 2
12.3. Suchen
12.3.1. Typische Suchemaske
Eine typische Suchmaske besitzt ein Eingabefeld und einen Button. Erst beim Click auf diesen Button
wird gesucht, was eventuell sehr lange dauern kann.
12.3.2. Inkrementelles Suchen
Hierbei haben wir auch ein Eingabefeld, allerdings beginnt die Suche bereits nach dem 1. Buchstaben
und wir bei jeder weiteren Eingabe verfeinert. Hier ist somit kein Button mehr nötig, was die Suche
beschleunigt.
12.3.3. Sonderzeichen
Können mittels zusätzlichem Menu oder Kürzel eingegeben werden. Einige Zeichen („Eingabetaste“)
könnten auch so erkannt und in einen Zeichencode umgesetzt werden.
12.3.4. Suchen nach Multimedia
Viele Multimedia-Daten können nicht einfach so erfasst werden. Darum ist für eine sinnvolle Erfassung
ein „Tagging“ mit Beschreibung zu den Multimedia-Dateien dringend nötig.
12.3.5. Filter- und Such-Interfaces
Hierbei wird für die Suche ein Filtersystem eingesetzt. Über Aktivierung bestimmter Parameter (Alter,
Geschlecht, …) werden die Suchergebnisse immer mehr eingegrenzt.
12.4. Visualisieren
Zu diesem Punkt gibt es nicht viel zu sagen. Die Unterlagen bestehen hauptsächlich darin, dass Videos
von besonderen Visualisierungen („Alice im Wunderland“) gezeigt wurden.
12.5. Zoomable Interfaces
12.5.1. Beschreibung
ZOI zeichnen sich dadurch aus, dass die Navigation durch Zoom-In und Zoom-Out Aktionen
durchgeführt wird. Bei einem Zoom-In werden dabei mehr Details sichtbar, bei einem Zoom-Out wird
der sichtbare Ausschnitt grösser, allerdings gehen Details verloren.
12.5.2. Anwendung
Wird hauptsächlich für navigationslastige Anwendungen (Dateisysteme, Informationssysteme)
eingesetzt. Hauptziel: grober Überblick gewinnen, anschliessend Details von bestimmten Elementen
anschauen.
12.6. Neuartige Anwendungen
In diesem Kapitel werden Anwendungen vorgestellt, welche die üblichen Lösungen überarbeiten und
neue Interaktionskonzepte einbringen. Meist geht es darum, die Probleme und Schwierigkeiten mit
bestehenden Lösungen zu entfernen.
12.7. Augmented Reality, Tangible UI’s
12.7.1. Virtual Reality
Bei der VR wird vom Computer eine komplette Welt generiert und simuliert. Wird hauptsächlich dann
eingesetzt, wenn die reale Welt zu teuer oder gefährlich wäre. Ein anderer Einsatzbereich sind
natürlich die Videospiele.
12.7.2. Augmented Reality
Hier wird die reale mit der virtuellen Welt kombiniert. Dies bedeutet, dass über die reale Welt
simulierte Bilder gelegt werden.
12.7.3. Tangible User Interface
Bei einem TUI interagiert der Benutzer mit einem physikalischen Objekt. Die durchgeführten Aktionen
werden anschliessend vom Computer berechnet und auf das virtuelle Objekt umgewandelt. Vorteil
dieser Variante: Der Benutzer ist sie gewöhnt, mit physikalischen Objekten zu interagieren.
39/39
17.12.2007

User Interfaces 2 - auf ThomasKaelin.ch

Transcrição

Documentos relacionados

SPORTVEREIN TREPTOW 46 eV BERLIN

project sheet - SCHMIDTz KATZE FILMKOLLEKTIV

WIN-911®

¨Ubungsblatt 6 Aufgabe 1: Codebreaker (6 Punkte, B)

AGB herunterladen als PDF-Datei

Folien - Medienwissenschaft Universität Bayreuth

Phishing und Pharming: Diebstahl im Netz

Benutzerordnung - Albertus Magnus Gymnasium Friesoythe

Office 365 Admin Center – First Steps - RZ

ALLGEMEINE GESCHÄFTSBEDINGUNGEN