Entwicklung einer interaktiven Benutzeroberfläche zur individuellen

Transcrição

Diplomarbeit zum Thema
Entwicklung einer interaktiven
Benutzungsoberfläche zur individuellen
Tourenplanung
zur Erlangung des akademischen Grades
Diplom-Informatik
vorgelegt dem
Fachbereich Mathematik und Informatik der
Zhendong Chen
15. Mai 2008
Betreuerin: Inessa Seifert
Erstgutachter: Dr. Thomas Barkowsky
Zweitgutachterin: Prof. Dr. Susanne Maaß
ii
iii
iv
Danksagung
Zuerst danke ich Inessa, die mit mir dieses Thema entwickelt hat und ein ständiger
Ansprechpartner war.
Mein nächster Dank gilt Thomas und Susanne für ihre fachliche Unterstützung
und Beratung.
Meinen besten Freunden im Studium, Janina, Alex und Erik danke ich für ihre
Geduld bei der Korrektur meiner Arbeit und für ihre Bereitschaft, sich trotz ihrer
eigenen Arbeit Zeit für mich zu nehmen.
Ich danke meiner Familie und meiner Freundin, die mich während meines ganzen
Studiums unterstützt haben.
Alle diejenigen, die mir während meines Studiums in Deutschland geholfen haben und die noch nicht namentlich erwähnt wurden, möchte ich an dieser Stelle
danken.
v
vi
Eidesstattliche Erklärung
Hiermit versichere ich, die vorliegende Arbeit selbstständig und unter ausschließlicher Verwendung der angegebenen Literatur und Hilfsmittel erstellt zu haben.
Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.
Bremen, 15. Mai 2008
Zhendong Chen
vii
viii
Inhaltsverzeichnis
Inhaltsverzeichnis
ix
Abbildungsverzeichnis
xiii
Tabellenverzeichnis
xv
Abkürzungsverzeichnis
xvii
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
3
3
2 Stand der Technik
2.1 Grundlagen . . . . . . . . . . . . . . .
2.1.1 Softwareergonomische Kriterien
2.1.2 Interaktionsstile . . . . . . . . .
2.1.3 Interaktionselemente . . . . . .
2.1.4 Evaluationsmethoden . . . . . .
2.2 Vorhandene Systeme . . . . . . . . . .
2.2.1 Map24 . . . . . . . . . . . . . .
2.2.2 Falk . . . . . . . . . . . . . . .
2.2.3 ADAC TourPlaner . . . . . . .
2.2.4 Tripwiser . . . . . . . . . . . .
2.2.5 Zusammenfassung . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
10
13
15
19
19
23
26
29
32
3 Funktionelle Anforderungen
3.1 Region-basierte Richtungs-Heuristik .
3.1.1 Definition . . . . . . . . . . .
3.1.2 Beispiel . . . . . . . . . . . .
3.2 Anforderungen an die Funktionalität
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
38
41
.
.
.
.
ix
Inhaltsverzeichnis
3.2.1
3.2.2
3.2.3
Das Repräsentationsmodul . . . . . . . . . . . . . . . . . . . 42
Planungsmodul . . . . . . . . . . . . . . . . . . . . . . . . . 44
Informationsmodul . . . . . . . . . . . . . . . . . . . . . . . 46
4 Umsetzung
4.1 Ablauflogik . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Gestaltung der Benutzungsoberfläche . . . . . . . . . .
4.3 Karte anschauen . . . . . . . . . . . . . . . . . . . . .
4.4 Planungsvorgabe erstellen . . . . . . . . . . . . . . . .
4.5 Ergebnis ansehen . . . . . . . . . . . . . . . . . . . . .
4.6 Zusätzliche Umsetzungen für die Benutzungsoberfläche
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
51
52
60
69
74
5 Implementierung
5.1 Grundlagen . . . . . . . . . . . .
5.2 Klassenstruktur . . . . . . . . . .
5.2.1 Karte anschauen . . . . .
5.2.2 Planungsvorgabe erstellen
5.2.3 Ergebnis ansehen . . . . .
5.3 Anwendungsbeispiel . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
75
76
76
78
80
82
.
.
.
.
.
.
.
.
.
85
85
85
86
88
88
88
88
88
89
6 Evaluation
6.1 Vorbereitung . . . . . . . . . .
6.1.1 IsoMetrics Fragebogen .
6.1.2 Experiment konstruieren
6.2 Verlauf . . . . . . . . . . . . . .
6.2.1 Testumgebung . . . . . .
6.2.2 Testpersonen . . . . . .
6.2.3 Testaufgabe . . . . . . .
6.2.4 Durchführung . . . . . .
6.3 Ergebnis und Bewertung . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Fazit und Ausblick
93
7.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A Anhang
xix
A.1 Softwareergonomische Kriterien . . . . . . . . . . . . . . . . . . . . xix
A.1.1 Acht goldene Regeln von Ben Shneiderman . . . . . . . . . . xix
A.1.2 Zehn Heuristiken von Jakob Nielsen . . . . . . . . . . . . . . xx
x
Inhaltsverzeichnis
A.2 Grafische Benutzungsoberfläche . . . . . . . . . . . .
A.2.1 Symbole für die Orte . . . . . . . . . . . . . .
A.2.2 Symbole für die Symbolleiste . . . . . . . . . .
A.2.3 Menü für Aktivitätstypen . . . . . . . . . . .
A.2.4 Menü für Kategorien . . . . . . . . . . . . . .
A.2.5 Menü für Straßenverbindungen . . . . . . . .
A.2.6 Menü für Topografien . . . . . . . . . . . . . .
A.2.7 Hauptrichtung zeichnen . . . . . . . . . . . .
A.2.8 Symbolkasten für Aktivitäts-Constraints-Liste
A.2.9 Symbolkasten für Touren . . . . . . . . . . . .
A.3 CD-Inhalt . . . . . . . . . . . . . . . . . . . . . . . .
A.3.1 Systemvoraussetzungen . . . . . . . . . . . . .
A.3.2 Ausführen des Prototyps . . . . . . . . . . . .
A.4 IsoMetrics Fragebogen . . . . . . . . . . . . . . . . .
B Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xxii
xxii
xxiii
xxiv
xxiv
xxv
xxv
xxvi
xxvi
xxvii
xxviii
xxviii
xxviii
xxix
xliii
xi
Inhaltsverzeichnis
xii
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
Map24 - Interaktive Karte . . . . . . . . .
Map24 - Texteingabe . . . . . . . . . . . .
Map24 - Ergebnis . . . . . . . . . . . . . .
Map24 - Zwischenstation . . . . . . . . . .
Falk - Interaktive Karte . . . . . . . . . .
Falk - Texteingabe . . . . . . . . . . . . .
Falk - Routenplan . . . . . . . . . . . . . .
ADAC TourPlaner - Routenplan . . . . . .
ADAC TourPlaner - Zwischenstation . . .
ADAC TourPlaner - Routeberechnen . . .
ADAC TourPlaner - Routenplan Ergebnis
TripWiser - Tour Erstellen . . . . . . . . .
TripWiser - Zeitleiste . . . . . . . . . . . .
TripWiser - Routenplan und Dialog . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
21
21
23
24
24
26
27
27
28
29
30
31
3.1
3.2
3.3
3.4
3.5
RDH - Beispielkarte . . .
RDH - Planungsvorgabe .
GUI - Funktionalität . . .
Anwendungsfalldiagramm
Sequenzdiagramm . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
41
47
48
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
Aktivitätsdiagramm . . . . . . . . . . . . . . . .
Skizze der Benutzungsoberfläche . . . . . . . . .
Aktivitätsdiagramm (Karte anschauen) . . . . .
Beispielsymbole für die Orte . . . . . . . . . . .
Symbolleiste . . . . . . . . . . . . . . . . . . . .
Cursor-Hand . . . . . . . . . . . . . . . . . . . .
Vier Menüs für die Benutzungsoberfläche . . . .
Aktivitätsdiagramm (Planungsvorgabe erstellen)
Aktivitätsdiagramm (Aktivitätconstraints) . . .
Aktivitäts-Constraints-Liste . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
51
52
53
55
56
57
60
61
63
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xiii
4.11 Symbole für die Tour . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.12 Aktivitätsdiagramm (Ergebnis ansehen) . . . . . . . . . . . . . . . 70
xiv
5.1
5.2
5.3
5.4
5.5
Klassendiagramm-Menü (Karte anschauen) . .
Klassendiagramm-Karte (Karte anschauen) . .
Klassendiagramm (Planungsvorgabe erstellen)
Klassendiagramm (Ergebnis ansehen) . . . . .
Benutzungsoberfläche . . . . . . . . . . . . . .
.
.
.
.
.
6.1
6.2
Beispielfrage aus dem Fragebogen . . . . . . . . . . . . . . . . . . . 86
Evaluation - Ergebnis der Cut-Off-Analyse . . . . . . . . . . . . . . 90
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
A.9
Symbole für die Orte . . . . . . . . . . . . . .
Symbolleiste . . . . . . . . . . . . . . . . . . .
Menü für Aktivitätstypen . . . . . . . . . . .
Menü für Kategorien . . . . . . . . . . . . . .
Menü für Straßenverbindungen . . . . . . . .
Menü für Topografien . . . . . . . . . . . . . .
Hauptrichtung zeichnen . . . . . . . . . . . . .
Symbolkasten für Aktivitäts-Constraints-Liste
Symbolkasten für Touren . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
76
78
79
81
83
xxii
xxiii
xxiv
xxiv
xxv
xxv
xxvi
xxvi
xxvii
Tabellenverzeichnis
2.1
2.2
Design Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Vergleich verschiedener Systeme . . . . . . . . . . . . . . . . . . . 33
6.1
Aufteilung des Fragebogens . . . . . . . . . . . . . . . . . . . . . . 86
A.1 Acht goldene Regeln von Ben Shneiderman [Shneiderman2005] . . . xx
A.2 Zehn Heuristiken von Jakob Nielsen [Nielsen1993] . . . . . . . . . . xxi
xv
Tabellenverzeichnis
xvi
AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AC-Liste . . . . . . . . . . . . . . . . . . . . . . . . .
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
POI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDH . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WIMP . . . . . . . . . . . . . . . . . . . . . . . . . . .
WYSIWYG . . . . . . . . . . . . . . . . . . . . .
Aktivitäts-Constraint
Aktivitäts-Constraints-Liste
Application Programming Interface
Graphical User Interface
Human-Computer-Interaction
Point Of Interest
Region-based Direction Heuristic
Unified Modeling Language
Windows, Icon, Menüs, Pointing Device
What You See Is What You Get
xvii
xviii
Kapitel 1
Einleitung
1.1 Motivation
Eine wichtige Fragestellung der Forschung in der Informatik in den letzten Jahrzehnten ist die algorithmische Ermittlung einer Handlungsabfolge, um aus einem
Startzustand einen Endzustand zu erreichen. Durch die begriffliche Übereinstimmung lässt sich ein Planungsszenario sehr gut in einer Routenplanung veranschaulichen. Der Benutzer möchte von Punkt A nach Punkt B eine Route berechnet
bekommen, die er möglicherweise noch durch weitere Einschränkungsmöglichkeiten beeinflussen möchte.
Doch gerade in der Eingabe dieser Parameter liegt eine besondere Schwierigkeit.
Wie soll man dem Benutzer eine variable Anzahl von Eingabemöglichkeiten bieten, die vorher nicht definiert worden sind und auch von dem Benutzer variabel verändert werden können? Wie ist ein solches System, insbesondere die grafische Benutzungsoberfläche, als Schnittstelle zwischen Benutzer und Algorithmus
zu modellieren? Diese Fragestellung beschäftigt sich mit der Modellierung einer
Benutzungsoberfläche mit einem System, welches algorithmisch in der Lage ist,
mit variabler Parametereingabe eine Tour zu berechnen. Im Gegensatz zu einer
Route können bei einer Tour noch Aktivitäten in die Planung integriert werden.
Der Weg, um eine solche Benutzungsoberfläche zu erstellen, lässt sich in die folgenden Schritte unterteilen. An erster Stelle steht die Definition von Begrifflichkeiten rund um den Begriff Planung um eine eindeutige Zielsetzung zu erreichen.
Eine Analyse bestehender Systeme bildet dann zusammen mit aktuellen Benutzbarkeitsempfehlungen den aktuellen Stand der Technik als Grundlage für das zu
entwerfende System. Die Anforderungen sollten eine Kombination aus funktionellen Anforderungen, Anforderungen an die Bedienbarkeit und Erkenntnissen aus
1
Kapitel 1 Einleitung
der vorherigen Analyse sein. Auf Basis dieser Anforderungen wird dann die grafische Oberfläche unter Verwendung gängiger Modellierungssprachen wie z.B. UML
modelliert. Zur Evaluation dieser Modellierung wird eine Instanz des Entwurfs implementiert und diese Implementierung dann nach geprüften Evaluationsmethoden
bewertet. Die hier erwähnten notwendigen Schritte werden im Folgenden noch einmal erläutert.
Planung:
Wie erreicht man am effizientesten ein vordefiniertes Ziel? Um ein Ziel zu erreichen, sind oftmals mehrere Schritte notwendig, die sequenziell, parallel und oder
verschachtelt ablaufen können. Diese Aktionen bis zur Erreichung des Ziels müssen
geplant und durchdacht werden.
„Die Aufgabe, eine Folge von Aktionen zu finden, die ein Ziel erreichen,
wird auch als Planen (oder Planung) bezeichnet.“ [Norvig2003]
Doch Planung im zeitlich-räumlichen Bereich stellt sich für den Menschen als eine komplexe Herausforderung dar. Die Schwierigkeiten in der räumlichen Planung
lassen sich z. B. durch die Komplexität des Ermittelns der kürzesten Route (Traveling Salesman Problem [Applegate2006]) veranschaulichen. Aber auch der zeitliche
Faktor erschwert die Planung erheblich. Im Bereich der Tourenplanung sind sowohl
räumliche als auch zeitliche Faktoren relevant. Soll eine Tour in einer bestimmten
Zeit mit einer bestimmten Menge von räumlich auseinander liegenden Aktivitäten
geplant werden, muss die zurückzulegende Entfernung als auch die dafür aufgebrachte Zeit berücksichtigt werden. Zwischenstationen für Besichtigungen, Pausen
etc. wirken sich auf den Zeitfaktor und indirekt durch die zeitlichen Zielvorgaben
auch auf die räumliche Planung aus.
Stand der Technik:
Es gibt heutzutage Systeme, bei denen dem Benutzer eine computergestützte Optimierung seiner Planungsvorhaben angeboten wird. Viele davon finden sich im
Internet und sind unter dem Begriff Routenplaner kategorisiert. Die für diese Arbeit relevanten Werke werden in Kaptel 2.2 (Stand der Technik) vorgestellt.
Theoretischer Ansatz:
2
1.2 Zielsetzung
Für die Interaktion mit einem System sind im Laufe der Jahre Richtlinien, z. B. von
Ben Shneiderman [Shneiderman2005] und Jakob Nielsen [Nielsen1993], entwickelt
worden. Solche theoretischen Betrachtungen bilden den Rahmen einer Softwareentwicklung. Eine Filterung dieser Richtlinien auf die hier relevante Fragestellung
findet sich in Kapitel 2.1.1 wieder.
1.2 Zielsetzung
Zielsetzung dieser Arbeit ist die Modellierung einer Benutzungsoberfläche zur indivuellen Tourenplanung und ihre Evaluation. Für die Anforderungen werden bestehende Routenplanungssysteme auf Stärken und Schwächen analysiert. Zur Evalution wird eine komplexe Benutzungsschnittstelle implementiert und nach einer
allgemein anerkannten Evaluationsmethode bewertet.
1.3 Aufbau der Arbeit
Die Arbeit gliedert sich nach den in der Einleitung erwähnten Anforderungen. Die
Analyse wird in Kapitel 2 durchgeführt, in dem der aktuelle Stand der Technik
wiedergegeben und untersucht wird und die Grundlagen für die Entwicklung einer
Benutzungsoberfläche nach HCI-Standards erläutert werden.
Die Modellierung erfolgt mit der Definition der eigenen Anforderungen an die zu
entwickelnde Benutzungsoberfläche in Kapitel 3.2 und 4. Hier werden sowohl grafisch als auch textuell alle Anforderungen und Abhängigkeiten für die folgende
Implementierung ausgearbeitet.
Die Implementierung selber findet sich im gleichnamigen Kapitel 5. Die textuelle
Beschreibung der Realisierung dieser Lösungsinstanz wird durch Diagramme in
UML-Notation und Code-Auszüge ergänzt.
Die Evaluation folgt der Implementierung in Kapitel 6. Hier werden die bisher herausgearbeiteten Ergebnisse der Prüfung durch eine bekannte Evaluationsmethode
unterzogen.
Als Abschluss der Arbeit werden die Ergebnisse in Kapitel 7 zusammengefasst und
bewertet. Eine Betrachtung über die Relevanz der Arbeit wie auch ein Ausblick
auf zukünftige Entwicklungen schließen die Arbeit ab.
3
Kapitel 1 Einleitung
4
Kapitel 2
Stand der Technik
Dieses Kapitel werden vorhandene Systeme nach softwareergonomischen Kriterien
evaluiert. Diese Analyse ist in zwei Teile gegliedert. Im ersten Abschnitt werden die
Grundlagen der Interaktion mit einem System und die gängigsten Evaluationsmethoden vorgestellt. Im zweiten Teil werden vorhandene Systeme dann nach diesen
Kriterien untersucht. Abschließend werden die untersuchten Systeme verglichen
und bewertet.
2.1 Grundlagen
Die Grundlagen sind gegliedert in softwareergonomischen Kriterien, Interaktionsstile, Interaktionselemente und Evaluationsmethoden. Zuerst werden softwareergonomische Kriterien erläutert. Sie dienen zur Analyse der vorhandenen Planungssysteme und zur Entwicklung eines eigenen Systems. Die Interaktionsstile werden
nach Ben Shneiderman [Shneiderman2005] klassifiziert. Die Interaktionselemente,
die für ein Planungssystem verwendet werden, werden kurz vorgestellt. Im Anschluss werden die Methoden zur Evaluation eines Systems verglichen.
2.1.1 Softwareergonomische Kriterien
Ein Computersystem besitzt eine Benutzungsoberfläche um Informationen darstellen zu können. Der Benutzer kann durch Eingaben mit dieser Benutzungsoberfläche interagieren. Die Interaktion zwischen dem Benutzer und dem System
wird Mensch-Computer-Interaktion (nachfolgend: HCI1 ) genannt. Nach Teil 11 der
DIN EN ISO 9241 [DIN9241-11] müssen die Kriterien Effektivität, Effizienz und
Zufriedenheit erfüllt sein, um eine Benutzungsoberfläche zu gestalten:
1
Mensch-Computer-Interaktion: in Englisch Human-Computer-Interaction, Abk. HCI
5
Kapitel 2 Stand der Technik
• Effektivität: Der Benutzer kann mit dem System sein Ziel korrekt und
vollständig erreichen.
• Effizienz: Der Benutzer kann sein Ziel mit dem geringsten Aufwand korrekt
und vollständig erreichen.
• Zufriedenheit: Der Benutzer ist dem System positiv gegenüber eingestellt.
Außerdem wird der Benutzer nicht durch das System beeinträchtigt.
Weitere sieben Grundsätze in Teil 10 der DIN EN ISO 9241 [DIN9241-10] sind für
die Gestaltung und Bewertung eines Dialoges wichtig:
1. Aufgabenangemessenheit: Das System sollte den Benutzer bei der Erledigung seiner Aufgaben unterstützen. Es stellt alle benötigen Funktionen für
den Benutzer auf eine intuitive Art bereit, damit er sein Ziel erreichen kann.
2. Selbstbeschreibungsfähigkeit: Das System sollte dem Benutzer jederzeit
automatisch oder auf Anfrage des Benutzers mitteilen in welchem Zustand
es sich befindet. Der Benutzer sollte unmittelbar eine Rückmeldung über den
Fortschritt seiner Aktion erhalten.
3. Steuerbarkeit: Das System sollte vom Benutzer steuerbar sein. Dies bedeutet, dass der Benutzer jederzeit seine Richtung und Geschwindigkeit ändern
kann. Er kann jederzeit den Arbeitprozess unterbrechen oder wieder aufnehmen.
4. Erwartungskonformität: Das System sollte sich die bisherige Erfahrung
des Benutzers zu Nutze machen. Die Darstellung und Interaktion muss konsistent sein (z. B. konsistente Farbe und Dialog für Darstellung, konsistente
Funktionstasten für Interaktion).
5. Fehlertoleranz: Das System sollte Fehlern des Benutzers vorbeugen. Fehlermeldungen sollten aussagekräftige Informationen enthalten, damit der Benutzer die Fehler mit geringstem Aufwand beseitigen kann. Durch Vorschläge
innerhalb der Fehlermeldung kann dieser Vorgang beschleunigt werden.
6. Individualisierbarkeit: Das System sollte von dem Benutzer angepasst
werden können (z. B. Anpassung der Symbolleiste in einem Textverarbeitungsprogramm).
7. Lernförderlichkeit: Das System sollte dem Benutzer ein leichtes Erlernen
möglich machen. Anhand von Hilfefunktion oder einem Tutorial wird die
Funktionalität des Systems verdeutlicht.
6
2.1 Grundlagen
Diese Grundsätze werden dazu genutzt Systeme zu entwickeln oder vorhandene Systeme zu evaluieren. Ben Shneiderman ist einer der Pioniere der SoftwareErgonomie. Er hat acht goldene Regeln1 aufgestellt, die eine Benutzerfläche erfüllen
muss [Shneiderman2005]. Jakob Nielsen hat weitere zehn Heuristiken2 aufgestellt,
die auf seiner langjährigen Erfahrung in diesem Bereich beruhen [Nielsen1993].
Die großen IT-Firmen haben ihre eigenen Styleguides veröffentlicht wie z. B. Apple
[Apple1993], IBM [Ibm1993], Microsoft [Microsoft1994] und SUN [Sun2001]. Styleguides enthalten eine Zusammenfassung von Richtlinien (Normen, Regeln) und
Gestaltungsempfehlungen. Deren Ziel ist es, eine konsistente Benutzungsoberfläche für interaktive Systeme zu schaffen. Ein Styleguide spezifiziert das Aussehen
der Interaktionselemente (in Englisch „Look“), die Handhabung der Interaktionselemente (in Englisch „Feel“) und wann welche Elemente einzusetzen sind.
Die Normen, Regeln und Styleguides haben allgemein ein Ziel: Das Erleichtern
der Entwicklung und Gestaltung von interaktiven Systemen. Aufgrund der Firmenphilosophie unterscheiden sich die verschiedenen Styleguides. Daher werden
im Folgenden die Arbeiten von Shneiderman und Nielsen als Grundlage für weitere Vorgaben an die zu entwerfende Oberfläche genommen, und nicht die individuell
auf die Unternehmensanforderungen angepassten Styleguides.
Nach den sieben auf der vorigen Seite genannten Grundsätzen sind in Tabelle 2.1
der folgenden Seite 13 neue Prinzipien aufgestellt. Jedes Prinzip entspricht einem
oder mehreren Grundsätzen in Teil 10 der DIN EN ISO 9241. Diese Prinzipien
stellen die Schnittmenge der Regeln von Shneiderman1 und Nielsen2 dar. Die Zugehörigkeit wird mit einem „X“ gekennzeichnet. Diese in der Tabelle aufgestellte
13 Prinzipien werden im Folgenden erläutert:
1. Aufgabenorientierte Funktionalität: Das System sollte alle notwendigen
Funktionen bieten, damit ein Benutzer sein Ziel erreichen kann. Ein Routenplanungssystem muss zum Beispiel die Möglichkeit bieten, dass der Benutzer
einen Ort seiner Wahl eintragen kann.
2. Minimale mentale Belastung: Das System sollte derart gestaltet sein,
dass die mentale Belastung durch das System an den Benutzer minimal ist.
Dies bedeutet, dass nur notwendige Informationen dargestellt werden sollten. Beispielsweise sollte eine Menüstruktur nicht überladen werden, da die
1
2
Acht Goldene Regeln von Ben Shneiderman (siehe Tabelle A.1 auf Seite xx)
Zehn Heuristiken von Jakob Nielsen (siehe Tabelle A.2 auf Seite xxi)
7
Orientierung ansonsten verloren geht. Hierbei sollte die Kapazität des Kurzzeiggedächnises (7±2) nicht überschritten werden [Miller1956].
Nr. Prinzip
1
Aufgabenorientierte
Funktionalität
2
Minimale mentale
Belastung
3
Klassifizierte
Informationen
4
Klare Auswege
5
Universelle
Benutzbarkeit
6
Umkehrbarkeit
7
Feedback
8
Kontrolle
9
Konsistenz
10 Fehlervermeidung
11 Aussagekräftige
Fehlermeldungen
12 Individueller Dialog
13 Hilfe Funktion
Grundsätze
1
1
Shneiderman
2
Nielsen
X
1
X
X
1
X
X
1, 3
1, 4
X
X
X
1,
1,
3
4
1,
1,
X
X
X
X
X
X
3
2
5
3, 5
3, 6
1, 2, 7
3
X
X
X
X
X
X
Tabelle 2.1: Design Prinzipien
3. Klassifizierte Informationen: Informationen innerhalb eines Systems sollten in Gruppen klassifiziert werden. Dies dient hauptsächlich zur Orientierung des Nutzers.
4. Klare Auswege: Das System muss dem Benutzer klare Wege anzeigen. Beispielsweise muss dem Benutzer jederzeit eine Möglichkeit angezeigt werden,
wie er das System verlassen kann.
1
Sieben Grundsätze in Teil 10 der DIN EN ISO 9241 (siehe Aufzählung 2.1.1 auf Seite 6)
Acht Goldene Regeln von Ben Shneiderman (siehe Tabelle A.1 auf Seite xx)
3
Zehn Heuristik von Jakob Nielsen (siehe Tabelle A.2 auf Seite xxi)
2
8
2.1 Grundlagen
5. Universelle Benutzbarkeit: Das System sollte allen Benutzergruppen Zugang bieten. Dies bedeutet, dass ein System für Anfänger, sowie für Experten
nutzbar sein muss. Dies kann beispielsweise durch Tastenkürzel für Experten
gewährleistet werden.
6. Umkehrbarkeit: Das System muss dem Benutzer die Möglichkeit geben,
jederzeit seine Aktionen rückgängig zu machen.
7. Feedback: Das System sollte den Benutzer jederzeit über die laufenden Aktionen informieren. Dies geschieht anhand von Feedback, welches das System
dem Benutzer über den aktuellen Zustand gibt.
8. Kontrolle: Der Benutzer muss jederzeit die volle Kontrolle über das System
besitzen. Dies bedeutet, dass er jederzeit seine Richtung und seine Geschwindigkeit verändern kann. Weiterhin bedeutet dies auch, dass der Benutzer
jederzeit Zugriff auf alle benötigten Informationen hat.
9. Konsistenz: Das System muss konsistent sein. Dies bedeutet, dass alle Elemente innerhalb des Systems das gleiche „look and feel“ besitzen müssen
(z. B. konsistente Farben oder Begriffe). Weiter sollte auch die Steuerung
innerhalb des Systems an jeder Stelle gleich sein.
10. Fehlervermeidung: Das System sollte vorab versuchen Fehler zu vermeiden. Hierbei handelt es sich um Informationen, die dem Benutzer helfen, eine
richtige Eingabe zu tätigen. Beispielsweise sollte der Benutzer bei der Eingabe einer Kontonummer daraufhingewisen werden, dass die Eingabe nur aus
Zahlen bestehen kann.
11. Aussagekräftige Fehlermeldungen: Falls es dennoch zu einem Fehler
kommen sollte, muss die Meldung einen aussagekräftigen Charakter besitzen. Der Benutzer muss darüber informiert werden, wie er den Fehler beheben und zukünftig vermeiden kann.
12. Individueller Dialog: Dem Benutzer muss die Möglichkeit gegeben werden,
die Dialoge individuell an seine eigenen Bedürfnisse anzupassen. Beispielsweise kann in diversen Textverarbeitungsprogrammen die Werkzeugleiste angepasst werden.
13. Hilfe Funktion: Der Benutzer muss jederzeit Zugriff auf einen Hilfedialog
besitzen um weitere Informationen und Hilfestellungen anfordern zu können.
9
2.1.2 Interaktionsstile
Ben Shneiderman hat die Interaktionsstile in die folgenden fünf Kategorien eingeteilt: 1) Direkte Manipulation, 2) Menü Auswahl, 3) Formular ausfüllen, 4) Kommandosprache und 5) natürliche Sprache [Shneiderman2005].
1) Direkte Manipulation
Die grafische Repräsentation von Objekten und Aktionen wird direkt manipuliert.
Die Einsatzgebiete könnten z. B. Textverarbeitungsprogrammen, Tabellenkalkulation, Computerspiele, Navigationsystem, etc. sein [Shneiderman2005]. Die heutigen
Betriebssysteme (MacOS, Windows oder Linux) bieten die direkte Manipulation
für die Interaktion an. Das WIMP-Konzept1 wurde zuerst auf einem Xerox Star
[Byte1981] eingesetzt, die Desktop Metapher wurde auch damals zuerst verwendet.
Unter direkter Manipulation wird das WYSIWYG-Konzept2 verwendet. In Textverarbeitungsprogrammen wird zum Beispiel das WYSIWYG-Konzept angewandt.
Durch grafische Repräsentation von Objekten und Aktionen können die Benutzer
Aufgaben schnell lösen und die Ergebnisse sofort sehen [Shneiderman2005]. Eine
Beurteilung basierend auf Shneiderman [Shneiderman2005] ist in Vor- und Nachteile aufgeteilt.
Vorteile:
•
•
•
•
•
•
Erlaubt leichtes Lernen
Erlaubt leichtes Merken
Ermutigt zur Exploration
Kann Fehler vermeiden
Leistet hohe subjektive Befriedigung
Unmittelbare Rückmeldung
Nachteile:
•
•
•
•
1
2
Bei komplexen Aktionen aufwändig
Möglicherweise schwierig zu programmieren
Platzbedarf
Symbole kaum standardisiert
Windows, Icon, Menüs, Pointing Device
What You See Is What You Get
10
2.1 Grundlagen
2) Menü Auswahl
In einer Menüstruktur werden Funktionen in bestimmten Kategorien verschachtelt. Die oberste Ebene wird durch ein Schlüsselwort dem Benutzer jederzeit zur
Verfügung gestellt. Durch eine Aktion des Nutzers wird dem Benutzer dann eine
Palette von Funktionen unter diesem Schlüsselwort angeboten. Eine Beurteilung
basierend auf Shneiderman ist in Vor- und Nachteile aufgeteilt.
Vorteile:
•
•
•
•
Reduziert Tastendrücke, geringer Eingabeaufwand
Strukturiert die Entscheidungsfindung, einheitliche Auswahl
Verkürzt das Lernen
Wenig fehleranfällig
Nachteile:
•
•
•
•
•
Erfordert eine hohe Darstellungsgeschwindigkeit
Komplizierte Handhabung langer Menüs
Orientierungsprobleme bei partiell dargestellten Menüs
Symbole (Icons) nicht verständlich
Zu langsam für Experten
3) Formular ausfüllen
Ein Formular besteht aus Eingabe- und Anzeigenfeldern. Der Benutzer kann die
Eingabefelder dazu nutzen, Eingaben anhand der Beschreibungen (dargestellt durch
die Anzeigefelder) zu tätigen. Eine Beurteilung basierend auf Shneiderman ist in
Vor- und Nachteile aufgeteilt.
Vorteile:
•
•
•
•
Erfordert geringe Übung
Gute Möglichkeiten der Eingabeunterstützung
Übersichtliche und strukturierte Eingabemöglichkeit
Vereinfacht die Dateneingabe
11
Nachteile:
• Einschränkung der Steuerbarkeit durch Cursorsteuerung
• Platzbedarf
4) Kommandosprache
Ein Kommandosprache ist eine künstliche Sprache mit einer eingeschränkten Syntax und Semantik. Diese Kommandosprache wird direkt über die Tastatur eingegeben und es Bedarf gewisser Übung um sie effektiv Nutzen zu können [Shneiderman2005].
Eine Beurteilung basierend auf Shneiderman ist in Vor- und Nachteile aufgeteilt.
Vorteile:
•
•
•
•
Ausdrucksmächtig
Effizient für Experten
Flexibel
Keine speziellen Eingabegeräte erforderlich
Nachteile:
• Erlern- und Erinnerungsaufwand
• Hoher Eingabeaufwand
• Schwache Fehlerbehandlung
5) Natürliche Sprache
Interaktion durch die natürliche Sprache ist sehr intuitiv für den Benutzer. Allerdings ist die Nutzbarkeit momentan nicht gegeben [Shneiderman2005]. Eine
Beurteilung basierend auf Shneiderman ist in Vor- und Nachteile aufgeteilt.
Vorteile:
• Effizient bei beschränkten Kontexten
• Geringer Eingabeaufwand bei akustischer Eingabe
• Geringer Lernaufwand
12
2.1 Grundlagen
Nachteile:
• Geringer Wortschatz
• Hoher Analyseaufwand
• Hoher Eingabeaufwand bei schriftlicher Eingabe
Diese fünf Interaktionsstile von Shneiderman geben eine guten Überblick über die
wichtigsten Umgangsformen der HCI.
2.1.3 Interaktionselemente
Eine Benutzungsoberfläche besteht aus mehreren Interaktionselementen. Diese Elemente sind nötig, damit der Benutzer mit einem Planungssystem interagieren kann.
Nachfolgend wird der Einsatz der oben aufgeführten Interaktionsstile vorgestellt.
Schaltflächen
Eine Schaltfläche1 ist ein häufig verwendetes Element in einer Benutzungsoberfläche. Der Benutzer kann mithilfe von einer Schaltfläche Funktionen auslösen. Die
Repräsentation der Schaltfläche kann durch Text oder Symbole (siehe Icons auf
Seite 15) geschehen. Folgende Zustände kann eine Schaltfläche haben: neutral, hervorgehoben (Cursor darüber), gedrückt und nicht aktiv. Der Unterschied zwischen
diesen Zuständen sollte deutlich sein. Beispielsweise sollte eine nicht aktive Schaltfläche von einer aktiven leicht zu unterscheiden sein. Für die Größe der Schaltfläche
respektive der Schrift, deren Platzierung und weiteren Eigenschaften müssen die
Richtlinien der Softwareergonomie beachtet werden.
Eingabefelder
Eingabefelder2 sind Felder, mit welchen der Benutzer Daten in das System eingeben kann. Meistens werden Eingabefelder in Formularen verwendet. Durch das
Aussehen eines Eingabefeldes muss dem Benutzer verdeutlicht werden, wie seine
Eingabe aussehen sollte. Die Länge der Eingabe könnte zusätzlich begrenzt werden,
damit keine Fehleingaben getätigt werden. Beispielsweise sollte ein Eingabefeld für
eine deutsche Postleitzahl auf fünf Stellen begrenzt werden.
1
2
in Englisch „Button“
in Englisch „Textfeld“
13
Auswahlkasten
Der Auswahlkasten3 ist auch ein Standardelement in einer Benutzungsoberfläche.
Einen Kasten neben einer deutlichen Beschriftung oder einem Bild kann ausgewählt werden um eine bestimmtes Verhalten hervorzurufen. Ein Auswahlkasten
hat drei Zustände: Markiert, nicht markiert und nicht aktiv. Auswahlkasten sind
unabhängig voneinander, sollten aber dennoch in Gruppen arrangiert werden, damit ihre Bedeutung eindeutig wird.
Drop-Down-Listen
Um Platz auf einer Benutzungsoberfläche zu sparen, können Drop-Down-Listen
benutzt werden. Eine Drop-Down-Liste erlaubt nur einen Eintrag, daher verringert
sich durch dieses Element auch eine Fehlerquelle. Die Einträge in einer Liste sollten
alphabetisch sortiert werden. Wenn die Liste der Einträge zu lang ist, sollte der
Benutzer die Möglichkeit haben direkt zu einem Eintrag in der Liste zu springen.
Tabellen
Eine Tabelle kann nicht nur zur Informationsdarstellung genutzt werden, sondern
auch dazu, verschiedene Interaktionselemente in eine geordnete Reihenfolge zu
bringen. Eine Tabelle hilft, eine hierarchische und klassifizierte Darstellung zu
ermöglichen. Jede Spalte und Zeile sollte einen semantischen Zusammenhang zwischen dem Inhalt haben.
Bäume
Ein Baum stellt eine hierarchisch gegliederte Liste dar. Er besteht aus mehreren
geschachtelten Knoten, diese können auf- oder zugeklappt werden. Die hierarchische Darstellung sollte eindeutig sein, damit der Benutzer die Information schnell
finden kann.
Dialoge
Der Dialog ist ein spezielles Fenster der Benutzungsoberfläche. Ein Dialog stellt
auch gleichzeitig die aktive Kommunikation zwischen dem System und dem Benutzer da. Eine Anwendung kann dieses Medium benutzen um dem Benutzer ein
3
in Englisch „Checkbox“
14
2.1 Grundlagen
Ereignis bzw. Fehlermeldung mitzuteilen, oder den Benutzer nach einer Entscheidung fragen. Der Dialog sollte weiterhin so erstellt werden, dass er als nächstes
bearbeitet werden muss und der Benutzer solange keine anderen Informationen
abrufen oder Aktionen ausführen kann.
Icons
Der englischen Ausdruck „Icon“ bezeichnet bildhafte Objekte in einer Benutzungsoberfläche. Das Icon ist ein wichtiger Bestandteil der Benutzungsoberfläche. Anwendungen ohne Icons sind heute kaum noch vorstellbar. Icons sind nicht standardisiert, da es viele Funktionen gibt, die unter verschiedenem Kontext unterschiedliche Bedeutung haben könnte. Deshalb sollte ein Icon eine klar definierte
Information für jeden Benutzer möglichst unverfälscht darstellen können. Unterstützend kann Text die Bedeutung eines Icons verstärken (z. B. durch einen Tooltip). Durch abstrakte Grafiken oder Assoziationen mit der realen Welt kann der
Benutzer die Funktionen, welche hinter dem Icon stehen, schneller erfassen. Ein
Icon kann analog zu den Schaltflächen verschiedene Zustände aufweisen (z. B.
Aktiv, nicht aktiv).
2.1.4 Evaluationsmethoden
Bei der Evaluation geht es um die Bewertung eines Systems. Die Evaluationsmethoden unterscheiden sich in Inspektionsmethoden (expertenorientierte) und empirischen Methoden (benutzerorientierte). Bei Inspektionsmethoden bewertet der
Experte (Softwareentwickler) eine Benutzungsoberfläche auf bestimmte Kriterien.
Die Experten können sich in einen imaginären Benutzer hineinversetzen und die
korrekten Handlungsabläufe untersuchen - Cognitive Walkthrough [Lewis1994].
Die Experten können auch die Benutzungsoberfläche anhand Heuristik - Heuristische Evaluation [Nielsen1994] oder mit GOMS-Modell [Card1983] - Formale
Evaluation [Kahn1994] evaluieren. Bei der nutzerorientierte Methode werden die
Benutzer während der Ausführung des Systems befragt oder beobachtet. Durch
ein Interview, Fragebögen oder Aufzeichnung eines Log-Files kann das System
evaluiert werden. Im Folgenden werden diese Methoden kurz vorgestellt und verglichen.
Cognitive Walkthrough
Cognitive Walkthrough ist eine aufgabenorientierte Inspektionsmethode [Lewis1994].
Bei einer aufgabenorientierten Methode handelt es sich um eine konkrete Aufgabe,
15
die der Experte erledigen muss. Die Experten untersuchen die Funktionalität eines Systems indem sie sich in einen imaginären Benutzer versetzen. Die Experten
wählen die Aufgabe, die das System unterstützen soll, und führen diese Aufgabe aus. Folgenden Fragen sollen die Experten während Aufgabenbearbeitung zu
beantworten [Lewis1994]:
• Gibt es eine richtige Aktion zum Ziel?
• Wird der Benutzer eine richtige Aktion erkennen?
• Wird der Benutzer eine Verbindung zwischen der richtige Aktion und dem
gewünschten Ziel herstellen?
• Wird der Benutzer eine Rückmeldung von seiner Aktion erhalten?
Anschließend können die Experten die Ergebnisse analysieren und Verbesserungsvorschläge auflisten.
Heuristische Evaluationen
Bei der heuristischen Evaluation bewerten die Experten das vorhandene System
(Prototyp) anhand von Richtlinien bzw. Usability-Heuristik. Die Richtlinien oder
die Heuristik könnten internationale standardisierte Normen (ISO 9241), die goldenen Regeln von Ben Shneiderman [Shneiderman2005] oder die Heuristik von Nielsen [Nielsen1993] sein. Eine Evaluation kann von mehreren Experten durchgeführt
werden. 75% der Probleme können bei einer kleinen Gruppe (5 Experten) in einer
typischen Evaluationsdauer von 2 Stunden gefunden werden [Nielsen1994]. Eine
heuristische Evaluation ist sehr einfach, schnell und nicht aufgabenorientiert.
Formale Evaluation
Die formale Evaluation einer Benutzungsoberfläche kann anhand eines GOMSModelles [Kahn1994] durchgeführt werden. Ein GOMS-Modell beschreibt den Interaktionsvorgang zwischen dem Benutzer und dem System. Es besteht aus vier
Elementen: Ziel, Operation, Methode und Selektierungsregel. Das Ziel ist, was der
Benutzer im System erreichen will. Operationen sind die Aktionen, die zu einem
Ziel führen. Methoden bezeichnen eine Reihfolge von Operationen die zu einem
Ziel führen. Die Selektierungsregel beschreibt das Auswählen der Methoden.
Durch dieses Modell können die Experten die vorgegebenen Aufgaben unter Berücksichtigung des Benutzers analysieren. Das System wird Schritt für Schritt in
16
2.1 Grundlagen
logische Handlungen und Möglichkeiten zerlegt und auf deren Gebrauchstauglichkeit geprüft.
Interview
Bei einem Interview werden der Benutzer, der die Aufgabe in einem System gemacht hat, Fragen zu diesem System gestellt. Die Erfahrungen dieses Benutzers
werden durch ein Interview ermittelt. Ein Interview ist eine formlose, sehr subjektive aber kostengünstige Methode [Zühlke2004].
Fragebögen
Fragebögen sind eine sehr häufig eingesetzte Methode zur Evaluation einer Benutzungsoberfläche [Vogt2003]. Ein Fragebogen ist die schriftliche Zusammenstellung
von Fragen, oder Aussagen (so genannter „Items“), in einem Formular, mit verschiedenen Untergruppen. Der Benutzer führt die zu testende Benutzungsoberfläche mit bestimmten Aufgaben aus. Danach beantwortet der Benutzer selbstständig
den Fragenbogen. Der Aufwand für die Durchführung ist bei Fragebögen sehr gering. Das Ergebnis kann später mit wenig Aufwand ausgewertet werden.
Mehrere Fragebögen, als Muster für die Evaluation von Benutzungsoberfläche
werden bereits entwickelt. Als Beispiel gibt es „Questionnaire for User Interface
Satisfaction“ (QUIS) [Shneiderman2005], „Software Usability Measurement Inventory“ (SUMI) [Kirakowski1993] oder nach den Gestaltungsgrundsätzen spezieller Normen ISO 9241 Teil 10 [DIN9241-10] gerichtete Fragebögen ISONorm
[Prümper1993] und IsoMetrics [Hamborg1999]. Diese Fragebögen kann mit wenig
Anpassungsaufwand für eine Evaluation verwendet werden.
Log-Files
Eine Log-File Analyse ist eine quantitative Methode [Vogt2003]. Sie wird vom System erzeugt, während der Benutzer das System verwendet. Hier wird zum Beispiel
ein Mauseklick, die Mausbewegung, oder eine Tastatureingaben zwischen zwei Aktionen in ein Log-File geschrieben.
Vergleich der Evaluationsmethoden
Die Inspektionsmethode und die empirische Methode haben beide Vorteile und
Nachteile. In einer Inspektionsmethode werden die Aufgaben von einem erfahre-
17
nen Experten bearbeitet. Ein Experte kann nicht alle Probleme erfassen. Diese
Methode ist während der Entwicklung des Systems einsetzbar. Sie ist sehr schnell
und kostengünstig im Vergleich zu der empirischen Methode. Die empirische Methode ist die Bearbeitung der Aufgaben von repräsentativen Endnutzern. Je mehr
Benutzertests ausgeführt werden, desto vollständiger ist die Untersuchung des Systems. Sie kann erst in einer späteren Phase der Entwicklung eingesetzt werden
[Vogt2003].
In verschiedenen Situationen (z. B. Budget, Zeit) können verschiedene Evaluationsmethoden eingesetzt werden. Zur Analyse und Bewertung vorhandener Systeme
wird eine Inspektionsmethode verwendet. Die Bewertung bezieht sich auf Aufgaben, die bereits in der Einleitung beschrieben wurden. Anhand ausreichender
softwareergonomischer Kriterien werden diese Systeme bewertet.
18
2.2 Vorhandene Systeme
In diesem Abschnitt werden vier Planungssysteme vorgestellt. Die Funktionalitäten jedes Systems werden anhand von Beispielen aufgezeigt. In jedem Beispiel soll
eine Route von Punkt A nach Punkt B berechnet werden. Anhand dieser Beispiele
werden die einzelnen Planungssysteme unter Betrachtungen der Darstellung und
Interaktion mit Pro und Contra bewertet. Pro und Contra sind unter Berücksichtigung der softwareergonomische Kriterien bewertet. Am Ende wird ein Vergleich
der vier Planungssysteme zusammengefasst.
2.2.1 Map24
Map241 ist ein internetbasiertes Routenplanungssystem der Firma Mapsolute GmbH
in Deutschland. Monatlich wird Map24 ca. 15 Millionen Mal besucht [FOCUS2008].
Nach einer Umfrage von der Online-Marktforschungsgesellschaft Metrixlab ist Map24
die beste und beliebteste Navigationsseite des Jahres 2007 [WSDJ2007]. In Map24
können hausnummergenaue Straßenkarten eingesehen werden. Das Anzeigen von
verschiedenen Informationen, sogenannten „Point Of Interest“ (POI) ist durch Suche möglich. Es können standortbezogene Informationen z. B. Staus, Parkplätze,
Tankstellen und Sehenswürdigkeiten angezeigt werden. Ein Routenplan wird durch
die Eingabe der Start- und Endstation berechnet. Danach wird die Route in der
Karte angezeigt.
Funktionalität:
• In der interaktiven Karte (siehe Abbildung 2.1 auf Seite 20) kann durch eine
Symbolleiste navigiert werden (z. B. Verkleinern, Vergrößern oder Verschieben). Nicht nur die Straßenverbindungen, sondern auch die POIs können als
Symbole angezeigt werden.
• In dem Eingabefeld der Suche kann eine Adresse, oder POI eingegeben werden. In Abbildung 2.2(a) auf Seite 20 wird „China Restaurant, Bremen“ als
Beispiel für die Suche eingegeben. Das Ergebnis, die gefundenen Restaurants,
werden nummeriert und in der Karte angezeigt (siehe Abbildung 2.3(a) auf
Seite 21). Die Informationen zu dem Ergebnis können in der Karte abgelesen
werden.
1
http://www.map24.de/, letzter Zugriff: 22.01.2008
19
Abbildung 2.1: Map24 - Interaktive Karte
(a) Suche
(b) Routenplan
Abbildung 2.2: Map24 - Texteingabe
• In dem Eingabefeld kann auch ein Ziel eingeben werden. Dadurch wird
einen Routenplan erstellt. In Abbildung 2.2(b) sind „Bibliothekstraße 1, Bremen“ als Startstation und „Hamburg“ als Endstation eingetragen. Durch das
Anklicken der Schaltfläche „Route“, wird ein Route in der Karte angezeigt.
• Durch das Einfügen mehrerer Zwischenstationen kann die Routenplan erweitert werden. Um eine Zwischenstation (z. B. „Hannover“) einzufügen, muss
wie in Abbildung 2.4(a) auf Seite 21 eingesetzt werden. Auch können Stationen vertauscht werden (siehe Abbildung 2.4(b) auf Seite 21). Am Ende wird
die gewünschte Route berechnet und dargestellt (siehe Abbildung 2.3(b) auf
Seite 21).
20
(a) Suche Ergebnis
(b) Routenplan Ergebnis
Abbildung 2.3: Map24 - Ergebnis
(a) Einfügen
(b) Sortieren
Abbildung 2.4: Map24 - Zwischenstation
21
Zusammenfassung
Map24 ist durch direkte Manipulation bedienbar. Die Eingabefelder ermöglichen
die Benutzereingabe mittels Tastatur. Die Adressen und POIs können als Station
verwendet werden. Bei einer nicht deutlichen Eingabe kann mithilfe von einer
Drop-Down-Liste in den möglichen Stationen eine Auswahl getroffen werden. Die
POIs sind in einer Drop-Down-Liste realisiert und können hierdurch in der Karte
eingeschaltet werden. Das Ausschalten der POIs ist durch die Drop-Down-Liste
nicht möglich. Nach Berechnung eines Routenplans können die Kilometer zwischen
zwei Stationen und die ungefähre Fahrzeit ermitteln werden.
Bewertung - Darstellung
• Pro
–
–
–
–
Eine interaktive Karte mit ausführlichen Informationen.
Die Karte ist skalierbar.
POIs werden mit symbolischen Icons auf der Karte darstellt.
Während der Darstellung einer Route wird die Richtung in der Karte
angezeigt.
• Contra
– Teilweise ist die Schrift zu klein.
– Zu große Werbefläche, sehr viel Platzverschwendung.
Bewertung - Interaktion
• Pro
– Durch direkte Manipulation auf der Karte oder einer Navigationsleiste
kann die Karte verkleinert, vergrößert oder verschoben werden.
– Automatisches Korrigieren der Benutzereingabe durch Drop-Down-Liste
vermeidet Fehler.
• Contra
– Bei fehlender Zwischenstation, wird statt einer Fehlermeldung ein Hotel
in Frankreich als Zwischenstation genommen.
– Nach wenigen Minuten ohne Interaktion wird die Verbindung unterbrochen.
22
– Die POIs können nur eingeschaltet werden, während eine Route berechnet wird.
– Die POIs können nicht wieder ausgeschaltet werden.
2.2.2 Falk
Falk1 ist auch ein internetbasiertes Routenplanungssystem von der Firma FalkVerlag, die im Jahr 1945 in Deutschland gegründet wurde [Falk2008]. Sie ist auf
Stadtpläne und Landkarten spezialisiert. Der internetbasierte Service bietet nicht
nur einen Online-Stadtplan sondern auch ein Routenplanungssystem an. Als Routenplanungssystem sind die Funktionalitäten ähnlich wie Map24, aber die Darstellung und Interaktion sind unterschiedlich.
Funktionalität:
• Durch eine verschiebbare Symbolleiste kann in der Karte von Falk interaktiv
navigiert werden (siehe Abbildung 2.5). Auf der linken Seite der Karte ist ein
Formular dargestellt für die Planung der Route. Auf der rechten Seite der
Karte können die POI, durch Ankreuzen in der Karte anzeigt werden. Die
POIs in der Karte können direkt für den zukünftigen Routenplan als Start-,
End- oder Zwischenstation ausgewählt werden.
Abbildung 2.5: Falk - Interaktive Karte
1
http://www.falk.de/, letzter Zugriff: 22.01.2008
23
• In dem Eingabefeld kann eine Start- oder Endstation durch Eingeben des
Straßennamens und der Postleitzahl oder Stadt angeben werden (siehe Abbildung 2.6(a)). Das Einfügen einer Zwischenstation ist auch bei Falk möglich
durch die Eingaben der Adresse (siehe Abbildung 2.6(b)).
(a) Routenplan
(b) Zwischenstation
Abbildung 2.6: Falk - Texteingabe
(a) Berechnung
(b) Ergebnis
Abbildung 2.7: Falk - Routenplan
• Nach Einfügen mehrerer Zwischenstationen kann die Reihenfolge der Routenplan sortiert werden (siehe Abbildung 2.7(a)). Auch können die Stationen
modifiziert oder gelöscht werden. Nach der Berechnung wird die Route in der
Karte dargestellt (siehe Abbildung 2.7(b)).
24
Zusammenfassung
Auch hier findet direkte Manipulation statt. Die Interaktionen bei Falk sind ähnlich
wie bei Map24, aber für das Anzeigen der POIs wurden Auswahlkästen verwendet. Die POIs können dadurch nicht nur eingeschaltet sondern auch ausgeschaltet
werden. Das Suchen nach POIs ist hier nicht möglich.
• Pro
– Darstellung der Farbe ist identisch mit der Landkarte des Falk-Verlags.
– Durch eine verschiebbare Toolbox kann in der Karte navigiert werden.
Der Benutzer kann die Toolbox minimieren oder verschieben, falls die
Toolbox ihn stört.
– Durch eine Baumstruktur werden Informationen auf der rechten Seite
platzsparend dargestellt.
• Contra
– Die linke Seite für die Benutzereingabe kann nicht skaliert werden und
nimmt daher viel Platz ein.
– Zu große Werbefläche, sehr viel Platzverschwendung.
• Pro
– Die POIs können durch Auswahlkästen auf der Karte eingeschaltet und
ausgeschaltet werden.
– Bei einer falschen Eingabe im Textfeld, z. B. keine PLZ oder falsche
PLZ, wird immer eine deutliche Fehlermeldung ausgegeben.
• Contra
– Wenn der Cursor nicht zur rechten Seite bewegt wird, kann das Menü
auf der rechten Seite nicht gefunden werden.
– Eine eingetragene Zwischenstation kann nicht wieder ausgetragen werden. Dem Benutzer wird keine Möglichkeit gegeben, ohne eine Eingabe
weiterzumachen.
25
2.2.3 ADAC TourPlaner
Der ADAC TourPlaner 1 ist ein Routenplanungssystem von Deutschlands größtem
Verkehrsclub. Der Verein existiert seit 1903, mit mehr als 15 Millionen Mitgliedern
ist er der größte Verein in Europa [ADAC2008].
Funktionalität:
• Eine Interaktion mit der Karte ist beim ADAC TourPlaner zuerst nicht möglich. Im ersten Schritt muss eine Start- und Endstation durch Textfelder eingegeben werden (siehe Abbildung 2.8). Auch die Zusatzinformationen (Hotels, Tankstellen, Campingplätze, Sehenswürdigkeiten und Baustellen) können für den späteren Routenplan angekreuzt werden. Sie werden später in
der Karte bzw. Routenbeschreibung berücksichtigt.
Abbildung 2.8: ADAC TourPlaner - Routenplan
• Im nächsten Schritt ist das Einfügen einer oder mehrerer Zwischenstationen
möglich (siehe Abbildung 2.9 auf Seite 27). Auch können eine oder mehrere
Zwischenstationen am Ende angehängt werden.
1
http://www.adac.de/ReiseService/routenplaner/, letzter Zugriff: 25.01.2008
26
Abbildung 2.9: ADAC TourPlaner - Zwischenstation
Abbildung 2.10: ADAC TourPlaner - Routeberechnen
• Die Stationen können immer noch gelöscht oder modifiziert werden, bevor
auf „Route berechnen“ gedrückt wird (siehe Abbildung 2.10).
• Nach der Berechnung wird eine Routenempfehlung erzeugt. Sie besteht aus
einer Gesamtübersichtskarte und einer textuelle Wegbeschreibung. Außerdem wird durch einen Link eine interaktive Karte angeboten (siehe Abbildung 2.11 auf Seite 28). Die Karte kann verkleinert, vergrößert oder verschoben werden.
Zusammenfassung
Ein Abfahrtsdatum ist für die Berücksichtigung der zeitlichen Einschränkungen
(z. B. Wintersperren von Alpenpässen oder Baustellen) gedacht. Eine ausführliche
Bedienungsanleitung ist jederzeit aufrufbar, durch das Anklicken eines Links. Eine
ausführliche Beschreibung der Symbole ist auch vorhanden (siehe Abbildung 2.8
auf Seite 26). Im Vergleich mit Map24 und Falk ist eine interaktive Karte schwer
zu finden, sie hat geringe Funktionen und keinen Einfluss auf die Routenplan. Der
Benutzer kann nur fünf Arten von POIs in der Routenplan anzeigen lassen. Nur
durch die Eingabe der Adresse ist die Berechnung der Route möglich. POIs können
nicht als Station genommen werden.
27
Abbildung 2.11: ADAC TourPlaner - Routenplan Ergebnis
• Pro
– Hilfe-Funktion und Beschreibung jederzeit vorhanden.
• Contra
– Die interaktive Karte ist durch einen Link ganz klein dargestellt.
– Der Arbeitsbereich lässt sich nicht skalieren, sehr wenig Platz für die
Benutzung.
• Pro
– Stationen können nicht nur in der Mitte eingefügt, sondern auch ans
Ende angehängt werden.
– Klare Darstellung während der Eingabe der Routenplan.
28
• Contra
– Die Reihenfolge der Stationen ist nicht sortierbar.
– Eine eingetragene Zwischenstation kann nicht wieder ausgetragen werden.
– Die interaktive Karte hilft nicht bei der Erstellung eines Routenplans.
– Die interaktive Karte wird nur durch einen Link zugänglich.
2.2.4 Tripwiser
Tripwiser1 ist ein Tourenplanungssystem des gleichnamigen Unternehmens. Tripwiser berücksichtigt zeitliche Einschränkungen. Die Erstellung des Routenplans ist
hauptsächlich nach Tagen sortiert. Ein Routenplan hat ein Abfahrtsdatum, eine
Dauer, eine oder mehrere Stationen. Die üblichen POI-Information wie Aktivität,
Hotel und Restaurant können auch als Station für einen Tag verwendet werden.
Abbildung 2.12: TripWiser - Tour Erstellen
1
http://www.tripwiser.com/, letzter Zugriff: 25.01.2008
29
Funktionalität:
• Um einen Routenplan zu erstellen, ist die Angabe der Dauer erfordlich. Ein
Abfahrtsdatum und eine Hauptstation können auch im ersten Schritt eingegeben werden (siehe Abbildung 2.12 auf Seite 29). Auf der linken Seite
befindet sich eine Zeitleiste, die nach Tagen sortiert ist. Während der Eingabe einer Hauptstation oder anderer Stationen (Add Destination) erscheinen
automatische Vorschläge, die ausgewählt werden können. Nach dem Einfügen
der Stationen, wird diese Station in der Karte angezeigt.
• Nachdem die Schaltfläche „Create New Trip“ bestätigt worden ist, können die
Stationen durch Drag-und-Drop sortiert werden (siehe Abbildung 2.13(a)).
Die Stationen können auch gelöscht (siehe Abbildung 2.14(b) auf Seite 31)
oder einem neuen Tag an einer beliebigen Stelle zugeordnet werden.
• An jedem Tag können Aktivität, Hotel oder Restaurant usw. eingefügt werden (siehe Abbildung 2.13(b)).
(a) Sortieren
(b) Einfügen
Abbildung 2.13: TripWiser - Zeitleiste
30
(a) Routenplan
(b) Error
Abbildung 2.14: TripWiser - Routenplan und Dialog
• Eine Route kann auf der Karte dargestellt und interaktiv bedient werden
(siehe Abbildung 2.14(a)). Eine ausführliche Routenbeschreibung ist auch
vorhanden. Jede einzelne Aktivität kann auch in der Karte lokalisiert werden.
Zusammenfassung
Der Routenplan ist nach einer zeitlichen Reihenfolge erstellt. Jede Aktivität kann
in der Zeitleiste eingestellt werden. Die interaktive Karte ist durch die Google Maps
API1 [Google2008] realisiert. Die Dauer der erzeugten Route kann nicht mit der
Zeitleiste berücksichtigt werden. Jede Aktivität kann von jedem Benutzer erstellt
werden, somit können beliebige Aktivitäten definiert werden.
• Pro
– Übersicht der gesamten Tour durch eine Zeitleiste.
– Intuitive Symbole für die Aktivität.
– Konsistente Darstellung der Farben.
• Contra
– Die Texte für die Erläuterung sind zu klein.
1
Application Programming Interface
31
• Pro
– Gute Fehlermeldungen, vermeiden falsche Aktionen der Benutzer.
– Sortierung der Stationen per Drag-und-Drop.
• Contra
– Die Stationen können nicht direkt in der Karte ausgesucht werden.
2.2.5 Zusammenfassung
Die Planungssysteme haben sich in den vergangen Jahren weltweit verbreitet. Jedes System hat seine Vorteile, die andere Systeme übernehmen können und Nachteile die andere vermeiden sollten. Ein Vergleich aller Systeme ist in der Tabelle
2.2 zusammengefasst. Die Zusammenfassung ist nach Realisierung, Funktionalität,
Interaktionselemente, Darstellung und Interaktion klassifiziert.
System:
Realisierung:
Plattform
Programmiersprache
Kartematerial
Anzahl der POIs
Funktionalität:
Suche nach Adresse
Suche nach POI
Stationen in der
Karte wählen
Zwischenstation einfügen
Stationen sortieren
Sortierung der Route
Zeitliche Faktor eingeben
zeitlich-räumliche
Constraints
Hilfe und Dokumentation
1
2
Java Server Pages
Active Server Pages
32
Map24
Falk
ADAC
TripWiser
internetbasierte
Java Applet
Vektorgrafik
internetbasierte
JSP1
Rastergrafik
internetbasierte
ASP 2
Rastergrafik
29
55
5
internetbasierte
JSP, Ajax
Google
Map API
unbegrenzt
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Nein
Nein
Nein
Ja
Nein
Ja
Ja
Station
Nein
Nein
Ja
Ja
Station
Nein
Nein
Ja
Nein
Station
Ja
Nein
Ja
Ja
Tage
Ja
Nein
Ja
Ja
Ja
Nein
System:
Interaktionselemente:
Schaltflächen
Eingabefelder
Auswahlkasten
Drop-Down-Liste
Tabellen
Bäume
Dialoge
Icons
Darstellung:
Symbol für POIs
in der Karte
Platzierung der
Symbolleist
Platzierung der
Eingabeformular
Route mit
Richtungspfeilen
Interaktionen:
Karte zoomen
Karte verschieben
Karte filtern
Jederzeit
rückgängig machbar
Eingabe überprüfen
Gute Fehlermeldung
Map24
Falk
ADAC
TripWiser
Ja
Ja
Nein
Ja
Nein
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Nein
Ja
Ja
Ja
Nein
Ja
Nein
Nein
Ja
Ja
Ja
Ja
Nein
Nein
oben
verschiebbar
oben
oben links
oben
links
oben
links
Ja
Nein
Nein
Nein
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Nein
Ja
Nein
Nein
Nein
Ja
Ja
Nein
Ja
Nein
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Tabelle 2.2: Vergleich verschiedener Systeme
Realisierung:
Als Medium ist das Internet eine gute Plattform für Planungssysteme. Die aktuellen Informationen wie z. B. Staus, Umleitung, Restaurants und Hotels können
sofort in das System übernommen werden. Die Performanz kann ein Problem für
das browser-basiert Systeme sein (z. B. Bandbreite). Die Interaktion zwischen dem
Benutzer und dem System ist aus diesem Grund beschränkt.
33
Für die Entwicklung dieser Planungssysteme werden verschiedene Programmiersprachen verwendet. Durch ein Java Applet oder in Ajax kann das System mehr
Interaktionsmöglichkeiten anbieten. Die Darstellung kann auch dadurch verbessert werden. Die interaktiven Karten werden auf verschiedene Arten realisiert:
Vektorgrafiken sind schneller während der Übertragung als Rastergrafiken. Die
Navigation wird dadurch flüssiger. Google Maps bietet eine Schnittstelle zur Darstellung von Karten und Informationen an. Aber die zusätzlichen Informationen
können nicht von der Google Maps API extrahierte werden, da Google Maps die
geographischen Daten nur als Rastergrafiken zurückliefert. Jedes System hat eigene POIs definierte. Bei Tripwiser kann der Benutzer selbst die POIs definieren
und entsprechende Positionen in der Karte markieren.
Funktionalität:
Eine Such-Funktion durch Eingabe ist bei allem Systeme verfügbar. Zusätzlich können Stationen in der Karte ausgewählt und in den Routenplan eingefügt werden
(siehe Map24 und Falk). Die Stationen im Routenplan können durch Schaltflächen
oder per Drag-und-Drop sortiert werden. Die Routen sind entweder nach der Reihenfolge der besuchten Stationen oder nach Tagen sortiert. Keines der Systeme
berücksichtigt den zeitlich-räumlichen Konflikt. Es ist die Aufgabe des Benutzers,
seine Route in der vorgegebenen Zeit zu planen.
Interaktionselemente:
Alle Systeme haben Schaltflächen, Eingabefelder, Drop-Down-Listen und Icons
als Interaktionselemente verwendet. Für die Auswahl alternativer Lösungen werden Drop-Down-Listen verwendet. Icons sind in jedem System intuitiv dargestellt.
Für eine hierarchische Darstellung werden Tabellen beim ADAC und Bäume bei
Falk verwendet. Die mit Java-Applets (Map24) und Ajax (TripWiser) realisierten
Systeme haben Dialoge für Fehlermeldung benutzt.
Darstellung:
Gut gestaltete Interaktionselemente helfen dem Benutzer das System zu verstehen.
Die Symbole für POIs sind nach ihrer Bedeutung gestaltet, damit der Benutzer
diese schneller verstehen kann. Die verschiebbare Symbolleiste von Falk schafft
mehr Platz für die Darstellung der Karte. Die Symbolleisten der anderen Systeme
werden oben dargestellt. Für die Darstellung der Route in der Karte hat Map24
34
den Weg mit Richtungspfeilen gezeichnet, dadurch wird die mentale Belastung des
Benutzers verringert.
Interaktionen:
Eine interaktive Karte ist bei Planungssystemen immer verfügbar. Die gängigen
Interaktionen für die Navigation der Karte, wie „zoomen“ und „verschieben“ sind
auch identisch. Die Karten von Map24 und Falk können noch zusätzliche Informationen (POI) in der Karte darstellen, bei Map24 können diese Informationen nicht
wieder ausgeschaltet werden. Manche Aktionen können nicht rückgängig gemacht
werden (z. B. Einfügen der Zwischenstation). Bei Map24 wird die Eingabe auch
nicht überprüft.
35
36
Kapitel 3
Funktionelle Anforderungen
Im folgenden Kapitel wird eine Wegfindungsheuristik erklärt, welche als Grundlage
für das weitere System notwendig ist. Am Ende werden die Anforderungen an die
Benutzungsoberfläche durch Analyse von Algorithmen erstellt.
3.1 Region-basierte Richtungs-Heuristik
Die Region-basierte Richtungs-Heuristik (nachfolgend: RDH1 ) bietet eine neue
Methode die zeitlich-räumliche Planungsaufgabe zu lösen [Seifert2007b]. Sie berücksichtigt die fehlende Komponente der zeitlichen Einschränkungen bei der Erstellung einer Tour in einer bestimmten Zeit. Im folgenden Abschnitt wird diese
Heuristik anhand eines Beispiels erläutert.
3.1.1 Definition
Die RDH ist ein Algorithmus für zeitlich-räumliche Planungsaufgabe. Ein Beispiel
für unterspezifizierte zeitlich-räumliches Planungsproblem ist die Planung einer
Reise in fremde Staaten. Dieses Problem kann für RDH in folgenden sechs Punkten
definiert werden [Seifert2007b].
1. V ist eine Menge von Orten (z. B. Stadt oder Dorf), wo die Aktivitäten
stattfinden können. E ist eine Menge von Kanten (Straßenverbindungen),
die sich zwischen den Orten V befinden. Dann ist G = {V ,E} ein gerichteter
Graph (Karte).
2. Jeder Ort i in V beinhaltet einen Aktivitätstyp at (z. B. Stadtbesichtigung,
Wanderung, Schwimmen, Skifahren etc.).
1
Region-basierte Richtungs-Heuristik: in Englisch „Region-based Direction Heuristic“, Abk.
RDH
37
Kapitel 3 Funktionelle Anforderungen
3. Jede Kanten in E hat eine symmetrische und nicht negative Kosten Cij , die
Distanz zwischen Ort i und Ort j.
4. Eine Tour ist durch eine Liste von Aktivitäts-Constraints (nachfolgend: ACListe) AC-Liste = {ac1 , ..., acn } spezifiziert. Ein Aktivitäts-Constraint (nachfolgend: AC) ack = {(dck , atck , sak ) | 0 < k ≤ n} ist eine Liste, bestehend
aus Dauer der AC (dck ), Aktivitätstyp-Constraint (atck ) und räumliche Zuordnung (sak ).
5. Ein Aktivitätstyp-Constraint (atck ) beinhaltet eine Menge von einem oder
mehreren Aktivitätstype. Eine räumliche Zuordnung (sak ) kann ein spezifizierter Ort oder eine Menge von mehreren ausgewählten Orten sein. Eine
Dauer der AC (dck ) wird von dem Benutzer definiert.
6. Eine Start- und Endstation und ein gesamtes zeitliches Constraint Tmax werden auch von dem Benutzer definiert.
Die RDH funktioniert mit vordefinierten übergeordneten Regionen. Die übergeordneten Regionen gliedern eine Umgebung (Karte) in mehrere Teile. Die Relationen
zwischen Regionen ist durch neighbour-of Beziehung definiert, die eine der acht
Richtungsrelationen (East, South, North, West, North-East, North-West, SouthEast und South-West) beinhaltet.
Jeder Ort i in V steht in einer part-of Beziehung zu einer der Regionen. Die Orte
sind durch Kanten verbunden, die nicht negative Distanzkosten, sowie Richtungen
tragen. Die RDH benutzt die Hauptrichtung für die Suche nach passenden Orten.
Der Benutzer oder das System können die Hauptrichtung der Reise vorgeben, die
eine Sequenz der Regionen und deren Richtungen darstellt.
3.1.2 Beispiel
Nach der Definition wird eine Karte in Abbildung 3.1 auf Seite 39 erstellt. In Abbildung 3.1(a) auf Seite 39 sind mehrere Orte als Beispiel von L1 bis L6 für die Karte
bezeichnet. Der Benutzer erstellt eine Tour: er bleibt zwei Tage in L1, wandert
drei Tage in L2, hält sich zwei Tage in südwestlicher Region auf, besichtigt zwei
Tage Sehenswürdigkeiten und lässt drei Tage frei für beliebige Aktivität. Nach der
Definition kann diese Tour wie folgt geschrieben werden: AC-Liste = {ac1 (2,?,L1),
ac2 (3,’hiking’,L2), ac3 (2,?,[L3,L4,L5]), ac4 (2,’sightseeing’,?), ac5 (3,?,?)}. Das Symbol „?“ bezeichnet einen undefinierten Wert.
38
3.1 Region-basierte Richtungs-Heuristik
(a) Orten
(b) Hauptrichtung
Abbildung 3.1: RDH - Beispielkarte
Im nächsten Schritt kann eine Hauptrichtung der Tour definiert werden. Z. B.
die Tour beginnt in R1, durch R2 und R3, dann zurück zu R1 (siehe Abbildung
3.1(b)). Eine Hauptrichtungssequenz {R1, R2, R3, R4, R1} verbindet eine Richtungsrelationsmenge {South, East, North, West}. Die Relation zwischen R2 und
R1 ist in diesem Fall südlich (South).
Abbildung 3.2: Planungsvorgabe
gekennzeichnet)
(erfordeliche
Parameter
sind
mit
*
Nun ist eine Planungsvorgabe in Abbildung 3.2 erstellt worden. Der RDH-Algorithmus,
der diese Planungsvorgabe bearbeiten kann, wurde in einer Logik Programmier-
39
sprache - PROLOG implementiert. Die genaue Beschreibung dieses Algorithmus
ist in [Seifert2007b] Seite 8-9 nachzulesen. Wenn eine Tour alle Bedingungen der
AC-Liste erfüllt, ist diese Tour eine gültige Tour. Nach der Berechnung, werden
mehrere mögliche Touren gefunden. Das Ergebnis werden in einer bestimmten
Struktur zurückgeliefert. Ein Beispiel für die Anfrage sieht wie folgt aus: Die beiden L1 bestimmen die Start- und Endorte, 12 ist die Gesamtdauer der Tour.
[R1,R2,R3,R4,R1],["S","E","N","W"] sind die Hauptrichtungssequenz
und die Relationen zwischen diesen Regionen. Die folgende AC-Liste bezeichnet
die Aktivitäts-Constraints der Tour. Die erste Ziffer des Aktivitäts-Constraints ist
eine Nummerierung, die zweite ist die Dauer des Aktivitäts-Constraints, die dritte
beinhaltet die Aktivität und die letzte bezeichnet einen oder mehrere spezifizierte
Orte.
generateAlternativeSolutions(L1, L1, 12,
[R1,R2,R3,R4,R1],["S","E","N","W"],
[activityConstraint(1,2,[],[L1]),
activityConstraint(2,3,["hiking"],[L2]),
activityConstraint(3,2,[],[L3,L4,L5]),
activityConstraint(4,2,["sightseeing"],[]),
activityConstraint(5,3,[],[])
], Result).
Als Beispiel kann ein mögliches Ergebnis wie folgt aussehen: Das Ergebnis besteht
aus mehreren Touren. In diesem Beispiel sind drei Touren zurückgeliefert worden.
Jede Tour beinhaltet eine Route (z. B. [L1,L2,L5,L6] für die erste Tour) und
eine Aktivitätsliste, die einem AC entspricht. Die erste Ziffer der Aktivität ist eine
Nummerierung, die der Nummerierung von den AC entspricht.
[solution([L1,L2,L5,L6][activity(1,[L1]),activity(2,[L2]),
activity(3,[L5]),activity(4,[L5]),activity(5,[L6])]),
solution([L1,L2,L3,L5,L6][activity(1,[L1]),activity(2,[L2]),
activity(3,[L3]),activity(4,[L5]),activity(5,[L6])]),
solution([L1,L2,L4,L5,L6][activity(1,[L1]),activity(2,[L2]),
activity(3,[L4]),activity(4,[L5]),activity(5,[L6])])]
40
In Abbildung 3.3 werden das Planungssystem und die Beziehungen zwischen der
grafischen Benutzungsoberfläche (nachfolgend: GUI1 ), der Planungskomponenten
und der Datenbank gezeigt. Die GUI stellt die nötigen Informationen dar, die der
Benutzer für die Erstellung einer Planungsvorgabe braucht. Die Informationen für
die Darstellung sind in einer SQL Datenbank gespeichert. Die GUI fordert die
Informationen von der Datenbank an. Die erstellte Planungsvorgabe wird an die
Planungskomponente geschickt, die Planungskomponente berechnet ein Ergebnis,
der in der GUI für den Benutzer dargestellt wird. Aufgrund dieser Eigenschaften
können drei Module der GUI definiert werden:
1. Das Repräsentationsmodul (Information und Ergebnis darstellen),
2. Das Planungsmodul (Planungsvorgabe erstellen),
3. Das Informationsmodul (Abfrage und Ergebnis bearbeiten).
Aufgrund der Analyse der Datenbank und der Eigenschaften des RDH-Algorithmus
werden die funktionalen Anforderungen jedes Moduls erstellt.
Abbildung 3.3: GUI - Funktionalität
1
Graphical User Interface
41
3.2.1 Das Repräsentationsmodul
Zur Erstellung einer Planungsvorgabe benötigt man zunächst die Informationen
über die Umgebung z. B. Orte, Straßenverbindungen etc. Diese Informationen
sind in einer Datenbank gespeichert. Folgende Tabellen der Datenbank sind für
die Darstellung der Informationen wichtig:
• map(map_id, name): Zur Speicherung der Karte, z. B. map(22, CreteES)
• config(map_id, map_width, map_height, background): Zur Speicherung der Konfiguration der Karte, der Größe und des Hintergrundbildes,
z. B. config(22, 750, 500, “CreteEast.png“)
• node(node_id, name, map_id, raster_id, locationx, locationy): Zur
Speicherung eines Ortes, des Ortsnamens, zu welcher Karte der Ort gehört
und wo dieser Ort in der Karte lokalisiert ist. z. B. node(600, “big city
0“, 22, 21892, 96, 390)
• edge(startnode_id, endnode_id, distance, direction): Zur Speicherung die Kanten zwischen zwei Orten und deren Distanz und Richtungsrelation, z. B. edge(600, 632, 235, “N“)
• activitytype(activitytype_id, name): Zur Speicherung der Aktivitätstypen, z. B. activitytype(1, “sightseeing“)
• activitytype_of_node(activitytype_id, node_id): Zur Speicherung
des Aktivitätstyp für einen Ort, z. B. activitytype_of_node(1, 600)
• category(category_id, name): Zur Speicherung der Kategorien. Die Kategorie ist nicht wichtig für die Erstellung einer Planungsvorgabe, aber sie
beschreibt eine Eigenschaft des Ortes. Die Orte können als „Stadt“, „Dorf“
und „Verbindungsknote“ klassifiziert werden, z. B. category(1, “big
city“)
• category_of_node(category_id, node_id): Zur Speicherung der Kategorie eines Ortes, z. B. category_of_node(1, 600)
Die Karte ist als Rastergrafik mit vorgegebener Länge und Breite in der Datenbank
gespeichert. Die Orte samt Koordinaten sind durch Kanten verbunden. Jedem Ort
wurde ein Aktivitätstyp-Id zugewiesen. Ist eine Aktivitätstyp-Id „0“, dann beinhalt
dieser Ort keine Aktivität, sondern er es ist nur ein Verbindungsknoten. Folgende
Anforderungen können an das Repräsentationsmodul gestellt werden:
A1 Eine Karte mit Orten und Straßenverbindungen soll dargestellt
werden können.
42
Eine Karte mit Orten unterstützt den Benutzer bei der Erledigung der Planungsaufgaben.
A2 In der Karte soll navigiert werden können.
Die Navigation in der Karte kann durch Verkleinern, Vergrößern und Verschieben realisiert werden. Eine skalierbare Karte kann den Benutzer bei der
Erledigung der Planungsaufgaben unterstützen. Durch Verkleinern, Vergrößern und Verschieben können alle Stellen der Karte erreicht werden.
A3 Jeder Ort soll einund ausgeschaltet werden können.
Der Benutzer kann Orte ausschalten, wenn er die Informationen nicht benötigt. Jeder Ort kann hier zum Beispiel nach Aktivitätstyp oder nach Kategorie einund ausgeschaltet werden. Der Aktivitätstype ist wie POI bei
anderen Systemen, jeder Ort entspricht einem Aktivitätstyp. Wenn mehr als
7±21 Arten von Aktivitätstypen in der Karte dargestellt sind, kann sich der
Benutzer die Informationen schwer merken. Eine Filterung nach Aktivitätstypen kann den Benutzer dabei unterstützen. Die Orts-Kategorie können den
Benutzer unterstützen die Karte nach Bedarf zu filtern.
A4 Die Straßenverbindungen sollen einund ausgeschaltet werden können.
Die Straßenverbindungen zwischen Orten gehören zu einer standardmäßigen
Karte bzw. zu einem Stadtplan, der Benutzer kann hier bei Bedarf auch die
Straßenverbindungen ausschalten.
A5 Die Hilfe-Funktion soll jederzeit aufrufbar sein.
Eine Hilfe-Funktion steht dem Benutzer jederzeit zur Verfügung. Bei Unklarheiten kann der Benutzer die Dokumentation des Systems aufrufen.
Nach der Berechnung einer Planungsvorgabe sollte das System auch jede einzelne
Tour darstellen können. Ein Ergebnis beinhaltet mehrere Touren. Jede Tour besteht aus einer genauen Route. Die Start- und Endstationen der Route sind über
andere Orte durch eine Linie verbunden. Eine Menge von Aktivitäten gehört auch
zu einer Tour, die der Planungsvorgabe entsprechen. Diese Aktivitäten werden
vom System vorgeschlagen. Folgende Anforderungen sind zusätzlich notwendig:
A6 Jede Tour des Ergebnisses soll in der Karte darstellbar sein.
Die Darstellung der Tour ist eine der Basis-Funktionen eines Planungssystems.
1
Kurzzeitgedächnis Kapazität, siehe Design-Prinzipien Nr. 2 auf Seite 7
43
A7 Jede Tour des Ergebnisses soll umgeschaltet werden können.
Der Ergebnis beinhaltet mehrere Touren. Eine Umschaltungs-Funktion ermöglicht es dem Benutzer, mehrere mögliche Touren anschauen zu können.
A8 Jede Aktivität einer Tour soll in der Route erkenntbar sein.
Jede Tour des Ergebnisses besteht aus einer Route und einer Menge von
Aktivitäten. Der Benutzer kann erfahren, welche Orte in den Routen zu
welchem AC gehören.
3.2.2 Planungsmodul
Das Planungsmodul stellt die Hauptfunktion für das Erstellen der Planungsvorgabe dar. Die nötigen Informationen werden vom Repräsentationsmodul für den
Benutzer zur Verfügung gestellt. Folgende Anforderungen lassen sich aus einem
Beispiel-Planungsvorgabe in Abbildung 3.2 auf Seite 39 und der Bewertung bestehender Systeme ableiten:
A9 Eine Hauptrichtung der Planungsvorgabe soll von dem Benutzer
angegeben werden können.
Der Benutzer kann bei Bedarf eine Hauptrichtung der Planungsvorgabe eingeben. Daraufhin wird vom System eine Richtungsrelation berechnet. Die
Richtungsrelation ist für die RDH eine wichtige Eingabe (siehe Kapitel 3.1.1
auf Seite 37).
A10 Der Benutzer soll jedes Aktivitäts-Constraint erzeugen und löschen können.
Die drei Basis-Funktionen (Erzeugen, Modifizieren und Löschen) unterstützen den Benutzer bei der Erstellung einer AC-Liste.
A11 Für jedes Aktivitäts-Constraint soll die Aktivitätstypen ausgewählt
werden können.
Nach den Anforderungen der RDH können die Aktivitätstypen zur Erstellung einer AC-Liste eingegeben werden.
A12 Für jedes Aktivitäts-Constraint soll Orte eingefügt werden können.
Nach den Anforderungen der RDH können Orte zur Erstellung einer ACListe eingegeben werden.
A13 Für jedes Aktivitäts-Constraint soll eine Dauer eingegeben werden
können.
Eine Dauer ist die minimale Eingabe für ein AC.
44
A14 Die Gesamtdauer der Planungsvorgabe (zeitliches Constraint) soll
von dem Benutzer eingegeben werden können.
Nach den Anforderungen der RDH ist es notwendig eine Gesamtdauer der
Planungsvorgabe einzugeben.
A15 Der Benutzer kann eine Start- und Endstation für die Planungsvorgabe eingeben.
Die RDH benötigt eine Start- und Endstation zur Berechnung einer Planungsvorgabe.
A16 Nach Erstellung einer Planungsvorgabe soll der Benutzer die Planungsvorgabe an die Planungskomponente schicken können.
Der Benutzer kann durch das Ausführen einer Aktion die Planungsvorgabe
vom System berechnen lassen.
A17 Für die Erstellung einer Planungsvorgabe sollten noch mehrere
Punkte in Bezug auf die Anforderungen des RDH-Algorithmus
betrachtet werden, um Eingabefehler des Benutzers zu vermeiden
(siehe Kapitel 3.1.1 auf Seite 37).
A17.a Die Start- und Endstation muss eingegeben werden, und für diese darf
nur ein Ort festgelegt werden.
A17.b Jeder Ort in der Planungsvorgabe darf nur einmal ausgewählt werden.
A17.c Eine Dauer für jedes Aktivitäts-Constraint muss eingegeben werden.
A17.d Eine Hauptrichtung kann eingegeben werden, aufgrund der unterspezifizierten Eingabe des RDH-Algorithmus ist dies aber nicht notwendig.
A17.e Wenn der Benutzer eine Hauptrichtung eingegeben hat, muss sich jeder
Ort aus der AC-Liste auch in den Regionen befindet, die entlang der
Hauptrichtung liegen.
A17.f Jedes Aktivitäts-Constraint kann ein oder mehrere Aktivitätstypen beinhalten. Die Aktivitätstypen müssen nicht unbedingt eingegeben werden,
aufgrund der unterspezifizierten Eingabe des RDH-Algorithmus.
A17.g Jedes Aktivitäts-Constraint kann ein oder mehrere Orte beinhalten.
Die Orte müssen auch nicht unbedingt eingegeben werden, aufgrund
der unterspezifizierten Eingabe des RDH-Algorithmus.
45
3.2.3 Informationsmodul
Das Informationsmodul ist eine untere Ebene des Systems. Für die Darstellung
der Informationen müssen zuerst die Daten aus der Datenbank geholt, danach
umgewandelt und für den Benutzer zusammengestellt werden. Das Ergebnis der
Planungskomponente muss ebenfalls für den Benutzer dargestellt werden. Für die
Erstellung einer Planungsvorgabe benötigt das System auch Informationen aus
der Datenbank. Folgende Tabellen aus der Datenbank sind für die Erstellung einer
Planungsvorgabe zusätzlich notwendig:
• region(region_id, name, map_id): Zur Speicherung der Regionen, z. B.
region(42, “Region 1“, 22)
• part_of(node_id, region_id): Zur Speicherung der Beziehungen eines
Ort zu einer Region, z. B. part_of(600, 42)
• point_of_region(raster_id, region_id): Zur Speicherung welche Punkte in der Karte zu welcher Region gehören, z. B. point_of_region(19482,
42)
Das Repräsentationsmodul stellt eine Karte für den Benutzer dar. Zusätzliche Informationen sind darüber hinaus für die Erstellung einer Planungsvorgabe wichtig,
welche dem Benutzer verborgen bleiben. Übergeordnete Regionen sind in der Datenbank gespeichert; jede Region besteht aus mehreren Punkten (raster_id). Die
Punkte sind von links-oben zeilenweise bis nach rechts-unten nummeriert, jeder
Punkt entspricht einer X-Koordinate und einer Y-Koordinate. Wenn der Benutzer
mit dem Zeigegerät eine gewünschte Hauptrichtung der Planungsvorgabe in der
Karte zeichnet, sollte das System eine entsprechende Reihenfolge von Regionen
generieren können. Danach sollte eine Richtungsrelation berechnet werden. Für
das Informationsmodul sind folgende Anforderungen wichtig:
A18 Eine Schnittstelle zwischen GUI und Datenbank sollte implementiert werden.
Das GUI sollte die nötigen Daten von der Datenbank für die Darstellung der
Karte und der Erstellung der Planungsvorgabe abfragen können.
A19 Die Planungsvorgabe sollte für die Planungskomponente formatiert werden können.
Ein Format der Planungsvorgabe für die Planungskomponente wird definiert
(siehe Beispiel 3.1.2 auf Seite 40). Das System sollte die Planungsvorgabe in
dieses Format umwandeln und zur Planungskomponente schicken können z.
B. Berechnung der Richtungsrelation.
46
A20 Das Ergebnis der Planungskomponente sollte für GUI formatiert
werden können. Das Ergebnis der Planungskomponente hat auch ein definiertes Format (siehe Beispiel 3.1.2 auf Seite 40). Dieses Format sollte auch
umgewandelt werden können, damit das System die Ergebnisse dem Benutzer darstellen kann.
Abbildung 3.4: Anwendungsfalldiagramm (Drei Funktionen aus Sicht des
Benutzers)
Die drei eben vorgestellten Module stellen die Funktionalität des Systems dar. Aus
Sicht des Benutzers kann das System in drei Funktionen aufgeteilt werden: „Karte
anschauen“, „Planungsvorgabe erstellen“ und „Ergebnis ansehen“. In das Anwendungsfalldiagramm (siehe Abbildung 3.4) sind diese drei Funktionen dargestellt.
Ein Beispiel-Ablauf für die Erstellung einer Tour ist im Sequenzdiagramm in Abbildung 3.5 auf Seite 48 dargestellt. Der Benutzer startet das System und lädt
eine Karte. Das System holt aus der Datenbank die Informationen über die Karte und stellt die Karte für den Benutzer dar. Der Benutzer kann nun die Karte
anschauen und Informationen über die Karte erfahren. Danach kann der Benutzer eine Planungsvorgabe erstellen. Das System wandelt die Planungsvorgabe für
die Planungskomponente um, dann schickt es die Planungsvorgabe an die Planungskomponente. Nach der Berechnung von der Planungskomponente wandelt
das System das Ergebnis um und stellt es für den Benutzer dar.
47
Abbildung 3.5: Sequenzdiagramm (Ein Beispiel-Ablauf für die Erstellung einer
Tour)
48
Kapitel 4
Umsetzung
In diesem Kapitel werden nach den Anforderungen an die Funktionalität die Interaktionen zwischen dem Benutzer und dem System mithilfe von HCI Grundlagen
und der Bewertung vorhandener Systeme umgesetzt. Die Darstellung des Systems
wird ebenso umgesetzt.
4.1 Ablauflogik
Das Sequenzdiagramm in Abbildung 3.5 auf Seite 48 beschreibt den Austausch
der Informationen zwischen dem Benutzer und den Systemen (GUI, Datenbank
und Planungskomponente). Die detaillierte Bedienung des Systems wird in dem
Aktivitätsdiagramm in Abbildung 4.1 auf Seite 50 dargestellt.
Das Aktivitätsdiagramm in Abbildung 4.1 ist eine Verfeinerung des Anwendungsfalldiagramms in Abbildung 3.4 auf Seite 47. „Karte anschauen“ ist eine Aktivität,
die während der Benutzung des Systems immer verfügbar ist. Erst nach Erstellung
einer Planungsvorgabe ist es möglich, eine Tour anzuschauen. Wenn dem Benutzer
die Tour nicht gefällt, kann er die Aktivität „Planungsvorgabe erstellen“ noch mal
ausführen. Das System wird nach „Karte anschauen“ oder „Ergebnis ansehen“ beendet. Diese drei Aktivitäten entsprechen den drei Anwendungsfällen des Systems.
Die drei Anwendungsfälle „Karte anschauen“, „Planungsvorgabe erstellen“ und
„Ergebnis ansehen“ werden entsprechend der funktionalen Anforderungen umgesetzt. Jede Umsetzung wird nach den definierten Design-Prinzipien (siehe Tabelle
2.1 auf Seite 8) erstellt. Die berücksichtigten Prinzipien werden am Ende jeder
Umsetzung aufgezählt.
49
Kapitel 4 Umsetzung
Abbildung 4.1: Aktivitätsdiagramm (Aktivität der Benutzer für die Bedienung
des Systems)
50
4.2 Gestaltung der Benutzungsoberfläche
4.2 Gestaltung der Benutzungsoberfläche
Die Benutzungsoberfläche ist als Skizze in Abbildung 4.2 dargestellt. Die Karte ist das Hauptelement der Benutzungsoberfläche (siehe Umsetzungspunkt U1
auf Seite 52). Der Prototyp ist nach der kulturellen Gewohnheit des Benutzers
eingerichtet. Die Karte wird links oben in der Benutzungsoberfläche dargestellt.
Rechts oben werden die Menüs platziert. Unten wird die AC-Liste zur Erstellung
einer Planungsvorgabe platziert. Der Symbolkasten zur Bearbeitung der AC-Liste
wird rechts am Ende der AC-Liste platziert; der Symbolkasten für das Auswählen
des Ergebnisses wird darüber dargestellt. Die Symbolleiste ist innerhalb der Karte platziert und kann verschoben werden. Die Statusleiste ist zwischen der Karte
und der AC-Liste platziert (siehe Umsetzungspunkt U39 auf Seite 74). Die einzelnen Elemente der Benutzungsoberfläche werden in den folgenden 39 Umsetzungen
erläutert.
Abbildung 4.2: Skizze der Benutzungsoberfläche
51
Kapitel 4 Umsetzung
4.3 Karte anschauen
Für die Aktivität „Karte anschauen“ ist das Repräsentationsmodul zuständig. Es
sind fünf Anforderungen nach Analyse des RDH-Algorithmus und Datenbank definiert worden (siehe funktionelle Anforderungen Punkt 1-5 auf Seite 42). Diese
Anforderungen legen eine minimale Gestaltung des Systems fest. Das Aktivitätsdiagramm in Abbildung 4.3 für diesen Anwendungsfall beschreibt, dass der Benutzer die fünf Aktivitäten gleichzeitig ausführen und beenden kann. „Ort einund ausschalten“ kann durch mehrere Möglichkeiten realisiert werden, z. B. nach
Aktivität oder nach Kategorie.
Abbildung 4.3: Aktivitätsdiagramm (Karte anschauen)
A1 Eine Karte mit Orten und Straßenverbindungen soll dargestellt
werden können.
Eine Karte besitzt eine Länge und eine Breite, und ein entsprechendes Hintergrundbild ist ebenfalls in der Datenbank gespeichert. Jede Karte ist in Raster
eingeteilt und jedem Raster wird eine ID zugewiesen. Jeder Ort in der Datenbank
besitzt eine entsprechende ID für die Platzierung in der Karte. Die Benutzungsoberfläche stellt die Karte dar und zeigt jeden Ort mit der entsprechenden Raster-ID
an der korrekten Stelle an. Die Orte sind über Straßen miteinander verbunden.
U1 Die Karte ist das Hauptelement der Benutzungsoberfläche.
Die Darstellung und Interaktionen basieren auf einer Karte, diese Karte
soll wesentlich mehr Platz in der Benutzungsoberfläche einnehmen als andere Elemente der Benutzungsoberfläche. Diese Umsetzung lässt sich auch
52
4.3 Karte anschauen
bei der Map24 und Falk wiederfinden. In dieser Umsetzung ist das Prinzip
Aufgabenorientierte Funktionalität berücksichtigt worden.
U2 Die Orte werden entsprechend ihres Aktivitätstyps als Symbol dargestellt.
Jedem Ort wird ein entsprechender Aktivitätstyp zugewiesen. Diese Darstellung entspricht den POIs anderer Routenplanungssysteme. Die Orte werden in der Karte durch Symbole dargestellt. In der vorhandenen Datenbank
existieren vier Arten von Aktivitätstypen (Stadtbesichtigung, Wanderung,
Wassersport und Wintersport). An Orten, die Verbindungsknoten darstellen, besteht keine Aktivität. Diese fünf Arten von Orten sollten in der Karte
dargestellt werden können.
Abbildung 4.4: Beispielsymbole für die Orte
Zwei Gruppen von Symbolen werden für die Darstellung der Orte bereit
gestellt: Eine einfache Knotendarstellung sowie die Aktivitäts-Symbole. Als
Beispiel in Abbildung 4.4 werden die Symbole für die Wanderung dargestellt1 . Jede Gruppe hat fünf Modi, sie dienen verschiedene Interaktionen, z.
B. wenn ein Ort ausgewählt ist, wird das Symbol „ausgewählt“ angezeigt.
Falls dieser Ort schon in der Planungsvorgabe berücksichtigt wird, wird er
als „eingefügt“ angezeigt. Die symbolische Darstellung eines Orts erleichtert
dem Benutzer die Erkennung des Aktivitätstyps. Die andere Knotendarstellung dient anderen Interaktionen (wird in der nächste Umsetzung erläutert).
Die Farben der Symbole sind entsprechend der Eigenschaften ausgewählt, z.
B. steht grün für Wanderung und blau für Wassersport. Die Symbole sind
auch entsprechend der Bedeutung des Aktivitätstyps gestaltet, z. B. Schuhe
für Wanderung. Diese Umsetzung lässt sich auch bei der Map24 und Falk
wiederfinden. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte
Funktionalität, Klassifizierte Informationen und Universelle Benutzbarkeit
berücksichtigt worden.
1
Eine komplette Zusammenstellung der Symbole für die Aktivitätstypen wird im Anhang in
Abbildung A.1 auf Seite xxii dargestellt.
53
Kapitel 4 Umsetzung
U3 Die Symbole für die Orte können in zwei Darstellungsarten umgeschaltet werden.
Wenn die Karte skalierbar ist, kann der Benutzer die Karte auch verkleinern;
die Symbole für die Orte werden ab einer gewissen Größe schwer erkennbar.
Die Knotendarstellung in Abbildung 4.4 auf Seite 53 kann das Problem vermeiden. Das System kann die Symbole ab einer gewissen Größe automatische
umschalten, der Benutzer kann ebenfalls die Symbole für die Orte jederzeit
nach Bedarf umschalten. Eine Schaltfläche in einer Symbolleiste kann diese
Funktion realisieren (siehe Abbildung 4.5 auf Seite 55). Der Benutzer kann
durch das Anklicken der fünfte Schaltfläche in der Symbolleiste die Ansicht
für die Symbole wechseln. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität, Kontrolle und Individueller Dialog berücksichtigt
worden.
U4 Die Orte werden nach Kategorien dargestellt.
Orte können in drei Kategorien eingeteilt werden: „Stadt“, „Dorf“ oder „Verbindungsknoten“. Die gebräuchlichen Landkarten stellen die Städte nach ihrer Größe bzw. Anzahl der Einwohner mit unterschiedlichen Symbolen dar.
Die Benutzungsoberfläche bietet auch eine Ortsdarstellung mit unterschiedlicher Symbolgröße an, entsprechend der Ortsgröße. In dieser Umsetzung sind
die Prinzipien Aufgabenorientierte Funktionalität, Klassifizierte Informationen und Universelle Benutzbarkeit berücksichtigt worden.
U5 Die Orte werden über einer Gerade als Straßen miteinander verbunden.
Eine Gerade zwischen zwei Orten stellt die Straßenverbindung dar. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität und
Universelle Benutzbarkeit berücksichtigt worden.
A2 In der Karte soll navigiert werden können.
Die Karte ist skalierbar, daher sind die Funktionen zum Vergrößern und Verkleinern wichtig für den Benutzer. Bei Vergrößerung der Karte ist eine Verschiebung
der Karte sehr nützlich. Vorhandene Systeme realisieren die Navigation durch einen
Symbolleiste. Vorteile dieser Art von Navigation ist die leichte Erkennbarkeit und
das Einsparen von Benutzeraktionen im vergleich zu einer menügestützten Navigation.
U6 Die Navigation erfolgt durch ein verschiebbare Symbolleiste.
Die Symbolleiste ist verschiebbar, damit der Benutzer sie individuell einstel-
54
4.3 Karte anschauen
Abbildung 4.5: Symbolleiste
len kann. Die Symbole werden in der Symbolleiste waagerecht angeordnet.
In der Abbildung 4.5 ist die Symbolleiste mit der Erklärungen jeder Symbole dargestellt1 . Jedes Symbol hat drei Zustände: Standard, Fokusiert und
Ausgewählt.
Es sind drei Symbole für die Navigation in der Karte zuständig: Hand Symbol, Lupensymbol mit dem Pluszeichen und mit dem Minuszeichen. Das hand
Symbol dient zur Verschiebung der Karte. Das Lupensymbol mit dem Pluszeichen dient zur Vergrößerung, die Lupe mit dem Minus zur Verkleinerung
der Karte. Der Pfeil ist für den normalen Zustand des Systems. Die anderen Symbole werden in den nächsten Umsetzungen noch erläutert. Bei der
Gestaltung der Symbole für die Navigation ist die Bedeutung der Aktionen
berücksichtigt worden. Diese Umsetzung lässt sich auch bei der positiven Bewertung von Falk wiederfinden (siehe Bewertung-Darstellung auf Seite 25).
In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität,
Kontrolle und Individueller Dialog berücksichtigt worden.
U7 Der Cursor verändert sich bei Verschiebung der Karte.
Wenn das Hand Symbol in der Symbolleiste ausgewählt ist (siehe Abbildung
4.6 auf Seite 56), kann die Karte verschoben werden. Der Cursor wird in
das normale Symbol umgeschaltet. Während der Benutzer die Karte durch
Mausklicken verschiebt, wird der Cursor in das Verschiebungssymbol umgeschaltet. Nach der Verschiebung wird der Cursor in das normale Symbol
1
Eine komplette Zusammenstellung der Symbole für die Symbolleiste wird im Anhang in Abbildung A.1 auf Seite xxii dargestellt.
55
Kapitel 4 Umsetzung
zurückgeschaltet. In dieser Umsetzung sind die Prinzipien Feedback und Kontrolle berücksichtigt worden.
Abbildung 4.6: Cursor-Hand
U8 Die Karte kann durch das Anklicken der entsprechenden Symbole
skaliert werden.
Der Benutzer kann durch das Anklicken der entsprechenden Symbole in der
Symbolleiste die Karte vergrößern (Lupe mit Pluszeichen) oder verkleinern
(Lupe mit Minuszeichen). Nach die Umsetzungspunkt 3 auf Seite 54 findet
eine Umschaltung in die symbolische Darstellung eines Orte statt. Die Knotendarstellung und symbolische Darstellung schaltet während der Skalierung
bei bestimmten Ansichten automatisch um. Diese Umsetzung lässt sich auch
bei der anderen Systemen wiederfinden. In dieser Umsetzung sind die Prinzipien Universelle Benutzbarkeit und Kontrolle berücksichtigt worden.
A3 Jeder Ort soll einund ausgeschaltet werden können.
Die Orte sind hierarchisch darstellbar, entsprechend ihres Aktivitätstyps oder ihrer
Kategorie. Die Orte sollten nicht nur eingeschaltet, sondern auch ausgeschaltet
werden können. Eine menübasierte Interaktion kann diese Funktion realisieren
U9 Jeder Ort kann entsprechend seines Aktivitätstyps einund ausgeschaltet werden.
Die Aktivitätstypen sind unter einem Menü dargestellt. In der Abbildung
4.7 auf Seite 57 sind vier Menüs für das System dargestellt worden. Das erste
Menü ist für die Aktivitätstypen1 und wird durch das Stern-Symbol repräsentiert. Im Standardmodus werden die unteren Einträge des Menüs nicht
berücksichtigt. Nur wenn das Symbol ausgewählt ist, können durch weitere
vier Symbole mit Textbeschreibungen die Aktivitätstypen in der Karte einund ausgeschaltet werden. In der Abbildung 4.7 ist ein Menü ausgewählt,
die anderen befinden sich im Standard Modus. Das nach unten zeigende
1
Eine komplette Zusammenstellung der Symbole für diese Menü wird im Anhang in Abbildung
A.3 auf Seite xxiv dargestellt.
56
4.3 Karte anschauen
„Dreieck“-Symbol zeigt das vorhandene Untermenü zum ausgewählten Menü
an. Durch dieses Symbol kann das Untermenü einund ausgeschaltet werden.
Befindet sich der Cursor zum Beispiel auf dem Stern Symbol, wird das Untermenü zu dem Aktivitätstypenmenü automatisch angezeigt. In der Abbildung
4.7 werden als Beispiel die Aktivitäten Stadtbesichtigung, Wanderung und
Wassersport in der Karte aktiviert. Diese Umsetzung lässt sich auch bei der
positiven Bewertung von Falk wiederfinden (siehe Bewertung-Darstellung auf
Seite 25). In dieser Umsetzung sind die Prinzipien Klassifizierte Informationen, Kontrolle und Individueller Dialog berücksichtigt worden.
Bei der Gestaltung dieses Menüs und der entsprechenden Symbole sind die
Farben und Symbole entsprechend des Aktivitätstyps berücksichtigt worden.
Bei der Schriftgröße für das Gesamtsystem wird berücksichtigt, dass die Texte gut lesbar sind. Diese Umsetzung verbessert die negative Bewertung von
Map24 (siehe Bewertung-Darstellung auf Seite 22). In dieser Umsetzung ist
das Prinzip Konsistenz berücksichtigt worden.
Abbildung 4.7: Vier Menüs für die Benutzungsoberfläche
U10 Jeder Ort kann entsprechend seiner Kategorie einund ausgeschaltet werden.
Das Menü für die Kategorien ist wie das Aktivitätstypenmenü aufgebaut
57
Kapitel 4 Umsetzung
(siehe Abbildung 4.7 auf Seite 57)1 . Das Untermenü besteht aus drei vordefinierten Kategorien. Jede Kategorie kann durch die Schaltfläche einund
ausgeschaltet werden. In der Abbildung werden als Beispiel die Verbindungsknoten („Localities“) nicht in der Karte dargestellt. In dieser Umsetzung sind
die Prinzipien Klassifizierte Informationen, Kontrolle und Individueller Dialog berücksichtigt worden.
A4 Die Straßenverbindungen sollen einund ausgeschaltet werden
können.
Eine Straßenverbindung ist ein wichtiges Element für eine Karte. Die Straßen
können nach ihrer Eigenschaft klassifiziert werden z. B. Autobahn, Landstraße, etc.
Solche Elemente für den Verkehr können auch in einem Menü dargestellt werden.
U11 Die Straßenverbindung können einund ausgeschaltet werden.
In der vorhandenen Datenbank ist nur eine Art von Straßen definiert worden. Diese Straßen können in einem Menü einund ausgeschaltet werden
(siehe Straßenverbindungenmenü in Abbildung 4.7 auf Seite 57)2 . Die anderen Straßen sind daher im Deaktivierungsmodus und damit nicht wählbar.
Eine Schaltfläche für das Anzeigen der Städtenamen ist auch in diesem Menü
verfügbar, damit können Städtenamen in der Karte einund ausgeschaltet
werden. In der Abbildung 4.7 sind Städtenamen nicht ausgewählt und Hauptstraßen werden angezeigt. In dieser Umsetzung sind die Prinzipien Kontrolle
und Individueller Dialog berücksichtigt worden.
A5 Die Hilfe-Funktion soll jederzeit aufrufbar sein.
Eine Hilfe-Funktion kann den Benutzer bei der Bedienung des Systems unterstützen.
U12 Der Benutzer kann jederzeit Hilfe aufrufen.
Der Benutzer kann die Hilfe-Funktion durch das Anklicken einer Schaltfläche aktivieren. Das Symbol für die Schaltfläche ist ein Fragezeichen. Die
Schaltfläche wird rechts oben in der Benutzungsoberfläche dargestellt. Eine
Dokumentation wird durch das Anklicken dieser Schaltfläche aufgerufen. In
1
A.4 auf Seite xxiv dargestellt.
2
A.5 auf Seite xxv dargestellt.
58
4.3 Karte anschauen
dieser Dokumentation wird jedes Symbol der Benutzungsoberfläche erklärt.
Ein Beispiel wird auch in diesem Dokument gestellt. Diese Umsetzung lässt
sich auch bei Map24, Falk und ADAC wiederfinden. In dieser Umsetzung ist
das Prinzip Hilfe Funktion berücksichtigt worden.
Zusätzliche Umsetzungen für „Karte anschauen“
Es gibt noch zwei Punkte, die für die Aktivität „Karte anschauen“ umgesetzt werden könnten. Diese Punkte sind nicht in den Anforderungen an die Funktionalität
definiert worden, sie sind wichtig für eine Benutzungsoberfläche.
U13 Der Benutzer kann Informationen über jeden Ort aufrufen.
In einem Planungssystem ist es wichtig, dass der Benutzer auch Informationen über jeden Ort erfahren könnte, z. B. Wetter, Photo etc. (siehe Tripwiser
in Kapitel 2.2.4 auf Seite 29). Wenn der Benutzer die Schaltfläche mit dem
„i“-Zeichen in der Symbolleiste angeklickt hat (siehe Abbildung 4.5 auf Seite
55), kann der Benutzer Informationen über jeden Ort ansehen. Diese Funktion hilft dem Benutzer bei der Erstellung der Planungsvorgabe. In dieser
Umsetzung ist das Prinzip Aufgabenorientierte Funktionalität berücksichtigt
worden.
U14 Der Benutzer kann topografischen Informationen über die Karte
ansehen.
Topografischen Informationen sind ursprüngliche Informationen über eine
Karte. Topografische Informationen sind z. B. Relief, Flüsse, Wälder, Seen
und Berge sowie Parks oder vordefinierte übergeordnete Regionen. Solche
Informationen über eine Karte können auch in einem Menü untergebracht
werden. In der Abbildung 4.7 auf Seite 57 wird dieses Menü dargestellt1 .
Diese Umsetzung lässt sich auch bei Falk und Tripwiser als Satellitenkarte
wiederfinden. In dieser Umsetzung ist das Prinzip Aufgabenorientierte Funktionalität berücksichtigt worden.
1
A.6 auf Seite xxv dargestellt.
59
Kapitel 4 Umsetzung
4.4 Planungsvorgabe erstellen
Das Planungsmodul dient der Erstellung einer Planungsvorgabe. Bei der Umsetzung dieser Anforderungen liegt der Schwerpunkt mehr auf den Interaktionen. Es
sind neun Anforderungen (siehe funktionelle Anforderungen Punkt 9-17 auf Seite
44) nach Analyse der RDH-Algorithmus definiert worden.
Abbildung 4.8: Aktivitätsdiagramm (Planungsvorgabe erstellen)
Das daraus resultierende Aktivitätsdiagramm für diesen Anwendungsfall in Abbildung 4.8 ist in zwei Spalten aufgeteilt. Im Repräsentationsteil sind die Aktivitäten
dargestellt, die der Benutzer ausführen kann. Der Planungsteil stellt die Aktivitäten dar, die das System zur Überprüfung der Benutzereingaben ausführen muss.
Die Start- und Endstationen müssen eingegeben werden (siehe funktionelle Anforderung Punkt 17a auf Seite 45). Mit einer festgelegten Gesamtdauer kann eine
Planungsvorgabe erstellt werden. Wenn der Benutzer eine Hauptrichtung der Planungsvorgabe gezeichnet hat, muss noch die Richtungsrelation von dem System
berechnet werden. Der Benutzer kann auch ohne AC-Liste eine Planungsvorgabe
erstellen. Wenn der Benutzer eine AC-Liste eingegeben und auch eine Hauptrichtung der Planungsvorgabe gezeichnet hat, muss das System (siehe Planungsteil)
60
überprüfen, ob sich jeder Ort aus der AC-Liste auch in den Regionen befindet, die
entlang der Hauptrichtung liegen. Ansonsten muss der Benutzer entscheiden, ob
die Hauptrichtung ignoriert werden soll oder die Orte, die außerhalb der Regionen
liegen, gelöscht werden sollen. Die unterspezifizierte Eingabemöglichkeit von der
RDH-Algorithmus ermöglicht dem Benutzer diese Eigenschaften des Systems (siehe funktionelle Anforderung Punkt 17 auf Seite 45).
Die Aktivität „Aktivitäts-Constraints einfügen“ ist im Aktivitätsdiagramm in Abbildung 4.9 detaillierter erläutert. Nach den Anforderungen sind drei Anforderungen (siehe funktionelle Anforderungen Punkt 11-13 auf Seite 44) bzw. drei Aktivitäten „Aktivitätstyp einfügen“, „Dauer festlegen“ und „Orte einfügen“ definiert
worden. Die „Löschen“-Funktion für Orte und Aktivitätstypen bietet eine einfache
Rücksetzmöglichkeit. Diese drei Aktivitäten kann der Benutzer jederzeit beenden
oder mit anderen Aktivitäten kombinieren (siehe funktionelle Anforderung Punkt
17 auf Seite 45).
Abbildung 4.9: Aktivitätsdiagramm (Aktivitätconstraints)
A9 Eine Hauptrichtung der Planungsvorgabe soll von dem Benutzer
angegeben werden können.
Die Eingabe einer Hauptrichtung ist eine Besonderheit des RDH-Algorithmus, daher ist eine Eingabe des Benutzers wichtig für die Benutzungsoberfläche.
U15 Der Benutzer kann eine Hauptrichtung in der Karte eingeben.
Die Hauptrichtung der Planungsvorgabe ist eine Sequenz von vordefinierten übergeordneten Regionen (siehe Kapitel 3.1.1 auf Seite 37). Eine Geste
61
Kapitel 4 Umsetzung
ist eine metaphorische Interaktion für die Eingabe. Der Benutzer kann mit
einen Zeigegeräte, z. B. mit einer Maus, einem Stift oder mit einem Touchscreen die Hauptrichtung in der Karte für die Planungsvorgabe einzeichnen1 .
Durch das Anklicken des „Richtung zeichnen“-Symbols in der Symbolleiste
kann diese Funktion aktiviert werden (siehe Abbildung 4.5 auf Seite 55).
Bei Bedarf kann der Benutzer die vordefinierten übergeordneten Regionen
über das Menü für topografische Informationen ein- oder ausschalten. Die
mit dem Zeigegerät gezeichnete Linie sollte in der Karte deutlich erkennbar sein, und der Benutzer kann diese Richtung jederzeit durch das erneutes
Eingeben oder Löschen ändern durch das einmalige Anklicken in der Karte.
Die gezeichnete Hauptrichtung wird ständig in der Karte angezeigt. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität und
Kontrolle berücksichtigt worden.
A10 Der Benutzer soll jedes Aktivitäts-Constraint erzeugen und
löschen können.
Die AC-Liste besteht aus mindestens einer Startstation und einer Endstation (siehe
RDH-Algorithmus in Kapitel 3.1.1 auf Seite 37). Der Benutzer soll noch weitere
AC einfügen können. Jedes AC besteht aus einer Dauer, einer Aktivitätstypen und
einer Menge von Orten (siehe funktionelle Anforderungen Punkt 11-13 auf Seite
44).
U16 Der Benutzer kann Aktivitäts-Constraints zwischen Start- und
Endstation einfügen.
Das AC ist ein fachspezischer Begriff. In der grafischen Benutzungsoberfläche wird jede AC als „zeitliche Einheit“ beschrieben. Diese zeitliche Einheit
kann aus einem oder mehreren Aktivitätstypen und einer Menge von Orten
bestehen. In der Abbildung 4.10 auf Seite 63 wird eine AC-Liste als Beispiel
gezeigt.
Die linke Seite der AC-Liste zeigte, welche Bedeutung die einzelnen Bereiche
der AC haben. Der erste Bereich zeigt dem Benutzer die Orte, die der Benutzer in dem entsprechenden AC eingefügt hat (siehe Umsetzungspunkt U20
auf Seite 65). Der zweite Bereich zeigt dem Benutzer die Aktivitätstypen an,
die er ausgewählt hat (siehe Umsetzungspunkt U18 auf Seite 64). Der letzte
Bereich ist die Dauer des ACs, die der Benutzer selbst noch modifizieren
1
siehe Abbildung A.7 im Anhang auf Seite xxvi.
62
kann (siehe Umsetzungspunkt U23 auf Seite 65). Durch das Anklicken der
Schaltfläche „new“ kann der Benutzer ein AC beliebig oft einfügen. Jedes
AC wird nach dem Einfügung oder beim Auswählen hervorgehoben.
Die Reihenfolge der AC spielt keine Rolle für den RDH Algorithmus, daher
ist eine Sortierung nicht nötig. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität, Klare Auswege und Kontrolle berücksichtigt
worden.
Abbildung 4.10: Aktivitäts-Constraints-Liste
U17 Der Benutzer kann die Aktivitäts-Constraints durch das Anklicken
der „Löschen“-Symbole in der Symbolleiste löschen.
Um eine Aktion (Einfügen eines AC) rückgängig machen zu können, muss
der Benutzer auch das AC wieder löschen können. Wenn der Benutzer das
„Löschen“-Symbol in der Symbolleiste (siehe Abbildung 4.5 auf Seite 55)
angeklickt hat, kann er das AC mit der Maus löschen. Der Cursor wird in
ein „Löschen“-Symbole geändert, falls die Cursor darüber läuft. Nach einem
Mausklick auf ein AC, muss der Benutzer in einem Dialog erneut bestätigen, ob dieses AC wirklich löschen will. Start- und Endstation können nicht
gelöscht werden (siehe funktionelle Anforderung Punkt 17a auf Seite 45). In
dieser Umsetzung sind die Prinzipien Umkehrbarkeit und Fehlervermeidung
A11 Für jedes Aktivitäts-Constraint soll die Aktivitätstypen
ausgewählt werden können.
Ein Aktivitätstyp kann als Constraint für ein AC eingegeben werden. Die Aktivitätstypen sind eine unterspezifizierte Eingabe für den RDH-Algorithmus (siehe
funktionelle Anforderung Punkt 17f auf Seite 45).
63
Kapitel 4 Umsetzung
U18 Der Benutzer kann einem Aktivitäts-Constraint einen Aktivitätstypen durch das „Plus“-Symbol im Aktivitätstypenmenü hinzufügen.
Im Aktivitätstypenmenü ist neben jedem Symbol für einen Aktivitätstypen
ein Symbole mit Pluszeichen dargestellt werden (siehe Abbildung 4.7 auf
Seite 57). Wenn der Benutzer ein AC ausgewählt hat, kann durch das Anklicken dieses Symbols der entsprechende Aktivitätstyp eingefügt werden. Die
eingefügten Aktivitätstypen werden in dem AC als Symbole angezeigt (siehe
Abbildung 4.10 auf Seite 63). In dieser Umsetzung ist das Prinzip Aufgabenorientierte Funktionalität berücksichtigt worden.
U19 Der Benutzer kann die Aktivitätstypen in den Aktivitäts-Constraints
durch das Anklicken des „Löschen“-Symbol in der Symbolleiste löschen.
Der Benutzer kann jeden Aktivitätstypen in dem AC auch wieder löschen,
wenn er das „Löschen“-Symbol in der Symbolleiste anklickt (siehe Abbildung
4.5 auf Seite 55). Wenn der Cursor über dieses Symbol bewegt wird, kann
der Aktivitätstyp durch Anklicken gelöscht werden. In dieser Umsetzung ist
das Prinzip Umkehrbarkeit berücksichtigt worden.
A12 Für jedes Aktivitäts-Constraint können Orte eingefügt werden
können.
Die Orte sind eine unterspezifizierte Eingabe (siehe funktionelle Anforderung Punkt
17g auf Seite 45) und jeder Ort darf nur einmal für ein AC eingegeben werden (siehe
funktionelle Anforderung Punkt 17b auf Seite 45). Der Benutzer kann jeden Ort,
der in der Karte dargestellt ist, in ein Aktivitäts-Constraint einfügen. Jedes AC
kann gleichzeitig mehrere Orte beinhalten.
U20 Jeder Ort kann durch Anklicken eingefügt werden.
Wenn sich der Cursor über einem Ort befindet, wird dieser Ort hervorgehoben. Durch das Anklicken wird dieser Ort im ausgewählten AC eingefügt.
Das Symbol des Ortes wird entsprechend geändert1 . Wenn das AC ausgewählt ist, werden die dazugehörigen Orte als „ausgewählt“ angezeigt. Die
Orte von anderen Aktivitäts-Constraints, die schon in anderen AktivitätsConstraints eingefügt sind, werden dann als „eingefügt“ angezeigt. Die in
1
Eine komplette Zusammenstellung der Symbole für die Aktivitätstype wird im Anhang in
Abbildung A.1 auf Seite xxii dargestellt.
64
einem AC „ausgewählt“ bzw. „eingefügt“ Orte werden als kleine Symbole
angezeigt. Befinden sich mehr als vier Orte in einem AC, wird noch die Anzahl der Orte zur Erläuterung angezeigt (siehe Abbildung 4.10 auf Seite 63).
In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität
und Minimale mentale Belastung berücksichtigt worden.
U21 Jeder Ort kann durch eine Geste eingefügt werden.
Wenn der normale Modus der Symbolleiste aktiviert ist, kann der Benutzer
das Einfügen mehrerer Orte vereinfachen. Mit einer Geste durch ein Zeigegerät kann der Benutzer z. B. einen Kreis zeichnen um mehrere Orte auswählen zu können. Die Orte, die sich in diesem Kreis befinden, werden in dem
ausgewählten AC eingefügt. Der gezeichnete Kreis wird ständig in der Karte
angezeigt. In dieser Umsetzung sind die Prinzipien Universelle Benutzbarkeit
und Kontrolle berücksichtigt worden.
U22 Jeder Ort im Aktivitäts-Constraint kann wieder gelöscht werden.
Entsprechend dem anderen Element des ACs, sollte der Benutzer auch die
eingefügten Orte wieder löschen können. Der Benutzer kann durch erneutes
Anklicken auf einen schon ausgewählter Ort diesen Ort aus dem AC löschen.
Durch das Anklicken des „Löschen“-Symbol in der Symbolleiste kann der
Benutzer alle Orte in einem AC löschen, wenn er die erste Bereich im AC
anklickt. Entspricht dem Löschen-Vorgang eines Aktivitäts-Constraints oder
Aktivitätstypen. In dieser Umsetzung ist das Prinzip Umkehrbarkeit berücksichtigt worden.
A13 Für jedes Aktivitäts-Constraint soll eine Dauer eingegeben
werden können.
Nach den Anforderungen (siehe funktionelle Anforderung Punkt 17c auf Seite 45)
ist die Eingabe einer Dauer nötig. Eine Dauer ist eine natürliche Zahl, die der
Benutzer eingeben muss.
U23 Der Benutzer kann eine Dauer für ein Aktivitäts-Constraint modifizieren.
In der AC-Liste ist für jedes AC eine Dauer angegeben (siehe Abbildung
4.10 auf Seite 63). Die Dauer muss mindestens „1“ betragen. Der Benutzer
kann durch Anklicken des nach oben zeigenden „Pfeils“ die Dauer verlängern
oder mit dem nach unten zeigenden „Pfeil“ verkürzen. In dieser Umsetzung
sind die Prinzipien Aufgabenorientierte Funktionalität und Fehlervermeidung
65
Kapitel 4 Umsetzung
A14 Die Gesamtdauer der Planungsvorgabe (zeitliches Constraint) soll
von dem Benutzer eingegeben werden können.
Wie die Dauer für jedes AC ist eine Gesamtdauer für eine Planungsvorgabe nötig
(siehe Kapitel 3.1.1 auf Seite 37). Das ist das zeitliche Constraint für die Planungsvorgabe.
U24 Der Benutzer kann die Gesamtdauer der Planungsvorgabe modifizieren.
Eine Gesamtdauer ist vorgegeben(siehe Abbildung 4.10 auf Seite 63). Die
wird automatisch berechnet, wenn der Benutzer die Dauer jedes ACs modifiziert. Die minimale Gesamtdauer ist die Summe der Dauer aller AktivitätsConstraints. Durch das Anklicken des nach oben zeigenden „Pfeils“ kann die
Gesamtdauer noch verlängert oder mit dem nach unten zeigenden „Pfeil“ bis
auf die minimale Gesamtdauer verkürzt werden. In dieser Umsetzung sind die
Prinzipien Aufgabenorientierte Funktionalität, Minimale mentale Belastung
A15 Der Benutzer kann eine Start- und Endstation für die
Planungsvorgabe eingeben.
Nach den Anforderungen (siehe funktionelle Anforderung Punkt 17a auf Seite 45)
ist es notwendig, eine Start- und Endstation einzugeben.
U25 Die Start- und Endstationen sind in der Aktivitäts-ConstraintsListe einzugeben.
Die Start- und Endstationen sind spezielle Aktivitäts-Constraints in der Liste, da der Benutzer jeweils nur einen Ort einfügen kann. Das Einfügen eines
Aktivitätstypen ist nicht gestattet. Diese Aktivitäts-Constraints sind durch
„Start“ und „End“ deutlich in der Liste mit einer Beschriftung dargestellt.
und Fehlervermeidung berücksichtigt worden.
A16 Nach Erstellung einer Planungsvorgabe soll der Benutzer die
Planungsvorgabe an die Planungskomponente schicken können.
Um eine Tour für die erstellte Planungsvorgabe zu bekommen, muss der Benutzer die Planungsvorgabe auch an die Planungskomponente schicken können. Diese
Aktion wird von den Benutzern ausgeführt.
66
U26 Durch eine Schaltfläche kann der Benutzer die Planungsvorgabe
an die Planungskomponente schicken.
Eine Aktion kann durch eine Schaltfläche ausgeführt werden. Der Benutzer
kann die AC-Liste durch das Anklicken einer Schaltfläche an die Planungskomponente schicken, danach wird das Ergebnis in der Karte dargestellt.
Eine Schaltfläche („show in map“) in Abbildung 4.11(a) stellt diese Aktion zu Verfügung1 . Wenn sie ausgewählt ist, kann die AC-Liste nicht mehr
modifiziert werden. Das Ergebnis wird nach der Berechnung in der Karte dargestellt. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte
Funktionalität und Fehlervermeidung berücksichtigt worden.
(a) Symbolkasten für Aktivitäts-Constraints-List
(b) Symbolkasten für Routen
Abbildung 4.11: Symbole für die Tour
Zusätzliche Umsetzungen für „Planungsvorgabe erstellen“
Für die Aktivität „Planungsvorgabe erstellen“ gibt es weitere Umsetzungen, die
nach den definierten Design-Prinzipien wichtig sind. Diese sind anhand der funktionalen Anforderungen zusätzlich für die Benutzungsoberfläche definiert worden.
U27 Fehlerdialoge bei falscher Eingabe in der AC-Liste.
Falls bei der Eingabe des Benutzers Fehler auftauchen, unterstützt ein Fehlerdialog den Benutzer bei der korrekten Erstellung der Planungsvorgabe.
Falsche Eingaben können z. B. die Eingabe mehrerer Orte für Start- und
Endstationen sein (siehe funktionelle Anforderung Punkt 17a auf Seite 45)
oder keine Eingabe von Orten für Start- und Endstationen. Diese Punkte
1
Eine komplette Zusammenstellung der Symbole für dieses Menü wird im Anhang in Abbildung
A.8 auf Seite xxvi dargestellt.
67
Kapitel 4 Umsetzung
wurden im Aktivitätsdiagramm in Abbildung 4.8 auf Seite 60 berücksichtigt. Diese Umsetzung lässt sich auch bei Map24 und Tripwiser wiederfinden. In dieser Umsetzung ist das Prinzip Aussagekräftige Fehlermeldungen
U28 Auswahldialoge bei einen Konflikt zwischen der Hauptrichtung und
der AC-Liste
Wenn der Benutzer die Planungsvorgabe an die Planungskomponente schicken will, muss das System noch überprüfen, ob der Benutzer eine Hauptrichtung eingegeben hat (siehe Abbildung 4.8 auf Seite 60). Falls eine Hauptrichtung eingegeben wurde, muss das System überprüfen, ob sich jeder Ort aus
der AC-Liste auch in den Regionen befindet, die entlang der Hauptrichtung
liegen (siehe funktionelle Anforderung Punkt 17e auf Seite 45). Wenn die Orte nicht zu einer dieser Regionen gehören, wird ein Dialog mit drei Möglichkeiten angezeigt. Der Benutzer kann entweder die Hauptrichtung ignorieren,
die Konflikt auslösenden Orte löschen oder die Planungsvorgabe weiter modifizieren. Die Konflikt auslösenden Orte in der Karte und das entsprechende
AC werden in der Benutzungsoberfläche hervorgehoben. Diese Aktivität des
Benutzers wurde im Aktivitätsdiagramm (siehe Abbildung 4.8 auf Seite 60)
beschrieben. In dieser Umsetzung sind die Prinzipien Klare Auswege und
Aussagekräftige Fehlermeldungen berücksichtigt worden.
U29 AC-Liste erzeugen, speichern oder laden.
Um Arbeitschritte wiederholen oder unterbrochene Planungen weiterführen
zu können, kann eine AC-Liste gespeichert und geladen werden. In der Abbildung 4.11(a) auf Seite 67 sind drei weitere Schaltflächen für die Aktionen
Erzeugen, Speichern und Laden dargestellt. Wenn der Benutzer eine neue
Planungsvorgabe erstellen möchte, kann er dies mit der Schaltfläche „new“
durchführen. Oder er kann mit der Schaltfläche „save“ die Planungsvorgabe
speichern bzw. mit der Schaltfläche „load“ eine gespeicherte Planungsvorgabe laden. Diese Umsetzung verbessert die negative Bewertung von Map24
(siehe Bewertung-Interaktion auf Seite 22). In dieser Umsetzung sind die
Prinzipien Klare Auswege und Kontrolle berücksichtigt worden.
68
4.5 Ergebnis ansehen
Für die Aktivität „Ergebnis ansehen“ ist ebenfalls das Repräsentationsmodul zuständig. Drei funktionale Anforderungen sind definiert worden (siehe funktionelle
Anforderungen Punkt 6-8 auf Seite 43). Das Aktivitätsdiagramm für diesen Anwendungsfall in Abbildung 4.12 auf Seite 70 beschreibt, dass der Benutzer die
Planungsvorgabe nach Erstellung an die Planungskomponente schicken kann.
Das System überprüft zuerst, ob alle Eingaben korrekt sind, danach wird die Planungsvorgabe in das Format für die Planungskomponente umgewandelt. Falls die
Planungskomponente keine Tour zurückliefert, hat der Benutzer in den meisten
Fälle zu wenig Zeit eingegeben. Jetzt muss der Benutzer entscheiden, ob er die
Zeit anpassen oder eine partielle Tour anfragen will, die Planungskomponente kann
auch eine partielle Tour zurückliefern. Eine partielle Tour ist eine Tour, die nicht
alle AC erfüllt. Sobald das RDH eine Tour zurückliefert, wird diese dem Benutzer
angezeigt. Der Benutzer kann nun die Aktivitäts-Constraints im Ergebnis bzw. in
der Route ansehen und eine passende Tour auswählen.
A6 Jede Tour des Ergebnisses soll in der Karte darstellbar sein.
Durch die Schaltfläche („show in map“) kann der Benutzer die Planungsvorgabe
an die Planungskomponente schicken (siehe Umsetzungspunkt U26 auf Seite 67).
Nachdem ein Ergebnis berechnet wurde, soll die Benutzungsoberfläche jede Tour
dieses Ergebnisses darstellen können. Solange die Schaltfläche ausgewählt ist, kann
der Benutzer nur das Ergebnis ansehen, die Bearbeitung der AC-Liste ist nicht
möglich.
U30 Die Orte in einer Route werden hervorgehoben.
Jede Tour beinhaltet eine Route. Die Route besteht aus Orten und den Geraden zwischen jeweils zwei Orten. Die Orte, die auf einer Route liegen, werden
extra hervorgehoben; die Knoten, die nicht auf dieser Route liegen, werden in
einen Deaktivierungsmodus angezeigt1 . Somit kann der Benutzer die Orte in
der Route sofort erkennen. Diese Umsetzung lässt sich auch bei der anderen
Systemen wiederfinden. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität und Minimale mentale Belastung berücksichtigt
worden.
1
Eine komplette Zusammenstellung der Symbole für die Orte wird im Anhang in Abbildung
A.1 auf Seite xxii dargestellt.
69
Kapitel 4 Umsetzung
Abbildung 4.12: Aktivitätsdiagramm (Ergebnis ansehen)
U31 Jede Gerade zwischen zwei Orten werden hervorgehoben.
Zwei Orte sind über eine Gerade als Straße in der Karte miteinander verbunden. Die Geraden, die Orte einer Route verbinden, werden in der Karte
deutlich hervorgehoben, damit der Benutzer die Verbindungen besser erkennen kann. Diese Umsetzung lässt sich auch bei der anderen Systemen
wiederfinden. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte
Funktionalität und Minimale mentale Belastung berücksichtigt worden.
70
U32 Die Richtung der Route ist mit einem Pfeil am Ende jeder Geraden gekennzeichnet.
Damit der Benutzer die Richtung der Route vom Start bis zum End deutlich
erkennen kann, wird zusätzlich am Ende jeder Geraden zwischen zwei Orten ein Pfeil in Richtung der Route gezeichnet. Diese Umsetzung lässt sich
auch bei der positiven Bewertung von Map24 wiederfinden (siehe BewertungDarstellung auf Seite 22). In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität und Minimale mentale Belastung berücksichtigt
worden.
A7 Jede Tour des Ergebnisses soll umgeschaltet werden können.
Jedes zurückgelieferte Ergebnis beinhaltet mehrere Touren, die der Benutzer ansehen können. Daher ist eine Umschaltung zwischen den Touren notwendig.
U33 Die Anzahl der Touren wird als Zahl dargestellt.
Die Anzahl der zurückgelieferten Touren im Ergebnis ist eine wichtige Information für den Benutzer. Eine Zahl in dem Symbolkasten für Touren zeigt
dem Benutzer die Gesamtanzahl der Touren an (siehe Abbildung 4.11(b)
auf Seite 67). Die Zahl „10“ in der Abbildung 4.11(b) veranschaulicht eine
Beispiel Anzahl der Touren. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität und Universelle Benutzbarkeit berücksichtigt
worden.
U34 Das Umschalten wird durch Schaltfläche realisiert.
Umschalten zwischen den Touren ist durch Schaltflächen umgesetzt (siehe
Abbildung 4.11(b) auf Seite 67). Der Benutzer kann durch Anklicken die
vorherige oder nachherige Tour auswählen. Wenn noch keine Touren vorhanden sind, werden die beiden Schaltflächen in Deaktivierungsmodus angezeigt.
U35 Die aktuelle Tour wird als Zahl dargestellt.
Die aktuelle Tour wird auch als Zahl dargestellt, damit der Benutzer während
der Umschaltung die aktuelle Tour erkennen kann (siehe Abbildung 4.11(b)
auf Seite 67). Im Beispiel stellt die Zahl „2“ die aktuell ausgewählte Tour.
und Universelle Benutzbarkeit berücksichtigt worden.
71
Kapitel 4 Umsetzung
U36 Der Benutzer kann eine Tour auswählen.
Wenn der Benutzer mit einer Tour zufrieden ist, kann er diese Tour durch
eine Schaltfläche mit einem Haken auswählen (siehe Abbildung 4.11(b) auf
Seite 67). Die Tour wird dann ständig in der Karte angezeigt. Wenn der Benutzer keine Tour ausgewählt hat, und sobald der Benutzer die Schaltfläche
„show in map“ noch mal anklickt, wird keine Route mehr in der Karte dargestellt. Wenn keine Touren vorhanden sind, wird diese Schaltfläche ebenfalls
als deaktiviert angezeigt. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität und Individueller Dialog berücksichtigt worden.
A8 Jede Aktivität einer Tour soll in der Route erkenntbar sein.
Die Tour des Ergebnisses zeigt in der Karte nur die Route mit den Orten an.
Der Benutzer kann daher schwer erkennen, zu welchem definierten AC die Orte
gehören. Deswegen soll die Benutzungsoberfläche dem Benutzer in der Route auch
anzeigen, zu welchem AC welche Orte gehören.
U37 Der Benutzer kann ein AC auswählen, um die entsprechenden Orte in der Route ansehen zu können.
Wenn die Schaltfläche „show in map“ ausgewählt ist, kann der Benutzer die
AC-Liste nicht mehr modifizieren, aber er kann trotzdem noch jedes AC auswählen. Wenn ein AC ausgewählt ist, werden die entsprechenden Orte, die
sich in der Route befinden, ebenfalls als ausgewählt angezeigt. Somit kann
der Benutzer erkennen, zu welchem definierten AC die Orte gehören. Z. B.
wenn in einem AC „Wanderung“ als Constraint definiert ist, kann der Benutzer durch Auswählen dieses ACs erfahren, welche Orte in der Route dieses AC
erfüllen. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität, Minimale mentale Belastung und Kontrolle berücksichtigt worden.
Zusätzliche Umsetzungen für Ergebnis ansehen
So wie bei den anderen Anwendungsfällen, gibt es auch zusätzliche Umsetzung
für die Aktivität „Ergebnis ansehen“. „Ergebnis ansehen“ ist ein spezieller Anwendungsfall für die Aktivität „Karte anschauen“. Die Funktionalitäten und Umsetzungen für die „Karte anschauen“ können fast alle auch für „Ergebnis ansehen“
verwendet werden, z. B. die topografischen Informationen, die Straßenverbindungen etc.
U38 Auswahldialoge bei zu kurzer Dauer der Planungsvorgabe
Wenn die Planungskomponente keine Tour zurückliefert, hat in den meisten
72
Fällen der Benutzer zu wenig Zeit eingegeben. Ein Dialog für das Auswählen kann den Benutzer dabei unterstützen. Der Dialog gibt dem Benutzer
die Möglichkeit, die AC-Liste zu überarbeiten oder eine partielle Tour von
der Planungskomponente anzufragen. In dieser Umsetzung sind die Prinzipien Aufgabenorientierte Funktionalität, Klare Auswege und Aussagekräftige
Fehlermeldungen berücksichtigt worden.
73
Kapitel 4 Umsetzung
4.6 Zusätzliche Umsetzungen für die
Benutzungsoberfläche
Allgemein zu der Benutzungsoberfläche können noch eine Umsetzung realisiert
werden.
U39 Eine Statusleiste gibt dem Benutzer unmittelbare Meldung
Eine Statusleiste zeigt den Status des Systems an. Sie gibt dem Benutzer
eine Meldung, in welchem Zustand das System ist bzw. welche Aktionen der
Benutzer ausführen kann, z. B. wenn das Hand-Symbol in der Symbolleiste
ausgewählt ist, wird die Statusleiste dem Benutzer mitteilen, dass er die
Karte verschieben kann. In dieser Umsetzung sind die Prinzipien Universelle
Benutzbarkeit und Hilfe Funktion berücksichtigt worden.
74
Kapitel 5
Implementierung
In diesem Kapitel werden die in Kapitel 4 definierten Umsetzungen mit einer Programmiersprache realisiert. Zuerst wird die Programmiersprache dargestellt. Wie
in Kapitel 4 wird die Klassenstruktur der Benutzungsoberfläche mit Hilfe von Klassendiagrammen erläutert. Zuletzt wird die Benutzungsoberfläche mit einem Anwendungsfall demonstriert. Der Quellcode befindet sich auf der beigefügten CD1 .
5.1 Grundlagen
Der Prototyp wird mit der Programmiersprache JAVA2 entwickelt. JAVA ist eine
quelloffene, objektorientierte Sprache. Die mit JAVA entwickelten Systeme sind
plattformunabhängig ausführbar. Für die Implementierung einer Benutzungsoberfläche gibt es in JAVA zwei fundamentale Bibliotheken: AWT3 und SWING. AWT
und SWING dienen der Gestaltung von grafischen Benutzungsoberflächen. Mit den
beiden Bibliotheken können grundsätzliche grafische Elementen wie z. B. Punkte
und Linien dargestellt werden. Die Interaktionselemente werden auch zur Verfügung gestellt z. B. Schaltflächen, Eigabefelder oder Auswahlkästen. Jedes Element
kann farbig gestaltet werden. Die Interaktionselemente können auf eine Benutzeraktion (z. B. Maus klicken oder Tastatur drücken) reagieren und eine Behandlungsmöglichkeit ausführen. SWING basiert auf AWT, bietet zusätzlich noch mehrere Interaktionselemente und eine symbolische Darstellung der Schaltflächen. Die
Interaktionselemente in SWING können transparent und in beliebigen Formen
dargestellt werden. Für die Datenbank gibt es auch eine entsprechende Bibliothek
zur Erstellung der Schnittstelle. Die Operationen, wie einen Datensatz anfragen,
modifizieren oder löschen können mit dieser Bibliothek realisiert werden.
1
Die Erläuterung zu der CD befindet sich im Anhang A.3 auf Seite xxviii.
Sun Microsystems, Inc. http://java.sun.com/
3
Abstract Window Toolkit
2
75
Kapitel 5 Implementierung
5.2 Klassenstruktur
Der Prototyp für die Benutzungsoberfläche ist nach den Funktionalitätsanforderungen in drei Modulen (Repräsentations-, Planungs- und Informationsmodule)
definiert worden (siehe Kapitel 3.2 auf Seite 41). Dabei sind das Repräsentationsmodul und das Planungsmodule wichtig für HCI. Die beiden Module sind in
die drei folgenden Teilen umgesetzt worden: „Karte anschauen“, „Planungsvorgabe erstellen“ und „Ergebnis ansehen“. Diese drei Teile stellen für den Benutzer
eine Benutzungsoberfläche dar. Die Klassenstrukturen für jeden Teil werden im
Folgenden mit Hilfe von Klassendiagrammen erläutert.
5.2.1 Karte anschauen
Das ContentPanel ist das Hauptelement der Benutzungsoberfläche, es besteht
aus mehreren Panels, die für verschiedene Funktionalität zuständig sind. Das Klassendiagramm in Abbildung 5.1 illustriert die Beziehungen zwischen diesen Panels. TitelPanel, MapPanel, BottomPanel und MenuPanel stehen in einer
1-1-Beziehungen zu ContentPanel. BottomPanel und MenuPanel beinhalten
noch weitere Panels. Die Klassen werden im Folgenden detailliert erläutert.
Abbildung 5.1: Klassendiagramm-Menü (Karte anschauen)
76
5.2 Klassenstruktur
• TitelPanel: Zur Darstellung des Namens des Systems und des Namens der
aktuelle Karte.
• MapPanel: Zur Darstellung der Orte, Straßenverbindungen, Regionen etc.
• BottomPanel: Die Darstellung des aktuellen Status des Systems ist mit
StatusPanel realisiert und „Planungsvorgabe erstellen“ mit ACPanel
realisiert (siehe Kapitel 5.2.2 auf Seite 78).
• MenuPanel: Zur Darstellung der vier Menüs für das Auswählen verschiedener Informationen in der Karte. ActivityMenu (siehe Umsetzungspunkt
U9 auf Seite 56), CategoryMenu (siehe Umsetzungspunkt U10 auf Seite 57), ConnectionMenu (siehe Umsetzungspunkt U11 auf Seite 58) und
TopographyMenu (siehe Umsetzungspunkt U14 auf Seite 59) sind entsprechend der Umsetzung realisiert.
Das MapPanel dient hauptsächlich zur Darstellung der Orte, Straßenverbindungen, Hintergrundbilder und Regionens (siehe Abbildung 5.2 auf Seite 78). Dafür
sind DrawNodePanel, DrawEdgePanel, BackgroundPanel und RegionPanel zuständig. Die Symbolleiste ist in der Toolbar realisiert. Diese fünf GUIElemente bauen das MapPanel zusammen auf. Jedes Element steht in einer 1-1Bezienung mit MapPanel. Für die Navigation ist ein NavigationEventListener implementiert, es dient zur Verkleinerung, Vergrößerung und Verschiebung der
Karte (siehe Umsetzungspunkt U6 auf Seite 54). Die Klassen werden im Folgenden
detailliert erläutert.
• DrawNodePanel: Zur Darstellung jedes einzelnen Orts in der Karte. Die
Klasse Node sind stellt die Orte dar, die in der Datenbank gespeichert sind.
Die Attribute sind bereits in der Datenbank definiert worden. Die Methode
displayInfo() dient zur Darstellung der Informationen dieser Orte. Die
Klasse NodeEventListener behandelt die Events für die Orte. Die Methoden in DrawNodePanel können die Orte in der Karte einfügen, updaten
oder löschen. Die DrawNodePanel kann mehrere Nodes beinhalten.
• DrawEdgePanel: Zur Darstellung der Straßenverbindungen zwischen den
Orten. Die Klasse Edge beinhaltet die Straßenverbindungen, die in der
Datenbank gespeichert sind. Jede Edge bezieht sich auf zwei Nodes. Die
DrawEdgePanel besteht aus mehreren Edges.
• BackgroundPanel: Zur Darstellung der topografischen Karte. Mit dem
TopographyMenu kann man verschiedene topografische Informationen dar-
77
Abbildung 5.2: Klassendiagramm-Karte (Karte anschauen)
stellen (siehe Umsetzungspunkt U14 auf Seite 59). Die entsprechende Karte
wird in dieser Klasse als ImageIcon zugewiesen und danach angezeigt.
• RegionPanel: Zur Darstellung der vordefinierten übergeordneten Regionen,
der mit einer Geste gezeichnet Hauptrichtung und des Kreises für das Auswählen der Orte. Die Methode drawPointList() dient zur Darstellung
der mit einer Geste gezeichneten Liste aus Points.
5.2.2 Planungsvorgabe erstellen
Das Klassendiagramm in Abbildung 5.3 auf Seite 79 illustriert eine Klassenstruktur für die Anwendung „Planungsvorgabe erstellen“. Die Klasse ACPanel besteht
aus mehreren ACs und einer Klasse ShowPanel. Jedes AC ist äquivalent zu einem ActivityConstraint, das zu einer ConstraintList gehört. Für das Zeichnen
einer Hauptrichtung wird die Klasse PenListener für MapPanel implementiert.
Die gezeichnete Hauptrichtung wird auch in der ConstraintList gespeichert. Die
Klasse ShowPanel dient dazu, diese ConstraintList zur Planungskomponente
zu schicken.
• ACPanel: Die Klasse ACPanel realisiert die AC-Liste (siehe Umsetzungspunkt U16 auf Seite 62). Sie besteht aus mindensten zwei ACs (Start- und
78
5.2 Klassenstruktur
Abbildung 5.3: Klassendiagramm (Planungsvorgabe erstellen)
Endstationen) in Form einer Liste und einer Schaltfläche (JButton) zur
Erzeugung eines neunen ACs. Sie gehört zu BottomPanel, beinhaltet aber
zusätzlich noch ein ShowPanel, mit dem die AC-Liste behandelt werden
kann.
• AC: Zur Darstellung jedes einzelnen ActivityConstraints. Jedes AC ist äquivalent zu einem ActivityConstraint. Es wird zwischen ACs für Startstation, Endstationen und Zwischenstation durch die Attribute isStartAC
und isEndAC unterschieden. Die Methode setErrorBG() dient zur Darstellung eines hervorgehobenen ACs, falls ein Konflikt zwischen der Hauptrichtung und der AC-Liste entsteht (siehe Umsetzungspunkt U28 auf Seite 68).
Die andere Methode dient zum Einfügen oder Löschen eines Aktivitätstypen
oder zur Einstellung der Dauer dieses ACs. Die Benutzeraktionen wie das
Löschen oder modifizieren der ACs ist durch ACEventListener realisiert.
• ShowPanel: Die Klasse ShowPanel beinhaltet vier Schaltflächen (JButton).
Die Schaltflächen dienen der Behandlung der ConstraintList, z. B. Speicherung, Ladung oder zur Planungskomponente schicken. Die Methode makeConstraintsList() wandelt die ConstraintList in ein Format ent-
79
sprechend der Anforderungen der Planungskomponente.
• ActivityConstraint: Die Klasse besteht aus den Attributen, die in der
RDH bereits definiert worden sind. Die regionPointList speichert eine
Liste aus Point1 , falls der Benutzer einen Kreis mit einer Geste gezeichnet
hat.
• ConstraintList: Zur Speicherung der AC-Liste. Die Gesamtdauer der Planungsvorgabe wird durch das Attribut duration gespeichert. Die Liste
regionOrderList und regionOrderOrdinationList dienen der Speicherung der Hauptrichtung und der Relation zwischen vordefinierten übergeordneten Regionen. Es besteht aus mehreren ActivityConstraints als
eine activityConstraintList.
• PenListener: Die Behandelungsklasse PenListener dient dem Zeichnen
einer Hauptrichtung. Diese Klasse realisiert zusätzlich noch die Einfügung
der Orte mit einer Geste (siehe Umsetzungspunkt U21 auf Seite 65). Die
gezeichnete Hauptrichtung wird in der ConstraintList gespeichert. Die
ausgewählten Orte werden in dem entsprechenden AC eingefügt.
5.2.3 Ergebnis ansehen
Falls ein Ergebnis mit mehreren Touren von der Planungskomponente zurückgeliefert wird, wird dieses in der Klasse SolutionSpace, die aus mehreren Solution
besteht, gespeichert (siehe Abbildung 5.4 auf Seite 81). Das RouteSelectPanel
bietet Möglichkeiten zum Auswählen einer Tour an, dabei kann zu jeder Tour aus
dem SolutionSpace umgeschaltet werden.
• SolutionSpace: Zur Speicherung aller Touren. Eine solutionList speichert alle Touren, die von der Planungskomponente zurückgeliefert werden.
• Solution: Zur Speicherung jeder einzelnen Tour. Die Route für jede Tour
wird in einer routerNodeIDList gespeichert. Die activityConstraintNodeList speichert die Orte entsprechend der Aktivitäts-Constraints,
die im ACPanel definiert sind. Die beiden Attribute ermöglichen es eine
Route in der Karte darzustellen und während des Anklickens jedes AC im
ACPanel die entsprechenden Orte in der Karte innerhalb einer Route hervor
zu heben.
1
Eine Klasse aus JAVA Bibliothek java.awt.Point, bezeichnet eine Punkt mit X und Y
Koordinate.
80
5.2 Klassenstruktur
Abbildung 5.4: Klassendiagramm (Ergebnis ansehen)
• RouteSelectPanel: Zur Behandlung des SolutionSpace. Die Schaltflächen (JButton) leftRoute und rightRoute dienen zur Umschaltung der Touren im Ergebnis. Durch das Einschalten des JToggleButton
selectRoute kann man die aktuelle Tour ausgewählt werden. Das Attribut
routeSumLabel speichert die Gesamtanzahl der Touren und das Attribut
routeCurrentLabel speichert die aktuelle Tour, die gerade aktiviert ist.
Das RouteSelectPanel wird auch im ContentPanel angezeigt.
81
5.3 Anwendungsbeispiel
In Abbildung 5.5 auf Seite 83 ist die anhand der Umsetzung implementierte Benutzungsoberfläche dargestellt. Die Benutzungsoberfläche nimmt Eingaben von
dem Benutzer auf und schickt diese zur Planungskomponente zu. Danach werden
dem Benutzer die Touren angezeigt, die innerhalb der bestimmten Zeit gültig sind.
In einem Beispiel wird eine Planungsvorgabe mit der Benutzungsoberfläche definiert. Die in der Benutzungsoberfläche dargestellte Karte zeigte ein Insel. Dieses
Beispiel basiert auf dem Beispiel des RDH-Algorithmus (siehe Abbildung 3.2 auf
Seite 39). Die Startstation und Endstation sind identisch, die Tour ist ein Rundreise. Die Gesamtdauer der Reise beträgt 15 Tage. In Abbildung 5.5 auf Seite 83
werden nach Ablauf der Tourerstellung vier Schnappschüsse der Benutzungsoberfläche angezeigt.
Im ersten Schnappschuss in Abbildung 5.5(a) werden die Start- und Endstation an
der westlichen Küste definiert. Im nächsten Schritt werden fünf zeitliche Einheiten definiert (siehe Abbildung 5.5(b)). Es sind zwei Tage in der südlichen Region
mit drei Städten, drei Tage in der südliche Region mit fünf Städten, zwei Tage
wandern, zwei Tage schwimmen und drei Tage in der nördlichen Region mit drei
Städten. Danach wird eine Hauptrichtung der Planungsvorgabe definiert (siehe
Abbildung 5.5(c)). Mit der Schaltfläche „show in map“ kann diese Planungsvorgabe zur Planungskomponente geschickt werden. Nach der Berechnung liefert die
Planungskomponente zehn Touren zurück (siehe Abbildung 5.5(d)). Im Schnappschuss wird die zweite Tour des Ergebnisses in der Karte mit einer blauen Linie
angezeigt. Eine zeitliche Einheit wird ausgewählt: zwei entsprechende Orte sind in
der Route mit einer anderen Farbe hervorgehoben.
Dies ist ein Anwendungsfall für diese Benutzungsoberfläche. Der Benutzer kann
diese Tour übernehmen oder weiter modifizieren.
82
5.3 Anwendungsbeispiel
(a) Start- und Endstation definieren
(b) Orten auswählen
(c) Hauptrichtung definieren
(d) Ergebnis ansehen
Abbildung 5.5: Benutzungsoberfläche
83
84
Kapitel 6
Evaluation
In diesem Kapitel werden zu nächst die verwendeten Evaluationsmethode und die
Vorbereitungen zur Evaluation der Benutzungsoberfläche erläutert. Danach wird
die Durchführung der Evaluation beschrieben. Am Ende wird das Ergebnis der
Evaluation präsentiert und die Benutzungsoberfläche bewertet.
6.1 Vorbereitung
Für die Evaluation wird auf die empirische Methode zurückgegriffen. In dem Kapitel 2.1.4 wurden bereits zwei Arten der Evaluationsmethode verglichen. Für eine summative Evaluation der Benutzungsoberfläche wird eine Benutzerbefragung
unter Verwendung eines Fragebogens durchgeführt. Mit der summativen Evaluation kann die Qualität der Benutzungsoberfläche bewerten werden. Der IsoMetrics
Fragebogen wurde von der Universität Osnabrück im Fachgebiet Arbeits- und
Organisationspsychologie entwickelt [Hamborg1999]. Es gibt zwei Versionen der
Fragebögen: IsoM etricsS (kurz Version) und IsoM etricsL (lange Version). Bei
der IsoM etricsS handelt es sich um eine summative Bewertung und IsoM etricsL
beinhaltet neben einer summativen Bewertung noch eine formative. Da die Evaluation sich in der Endphase der Entwicklung befindet und eine summative Bewertung
benötigt, wird die kurz Version (IsoM etricsS ) verwendet. Demnächst wird die
Struktur der IsoM etricsS dargestellt und ein Experiment nach „Das IsoMetricsManual“ [Hamborg2000] konstruiert.
6.1.1 IsoMetrics Fragebogen
Die Gütekriterien der IsoM etricsS Fragebogen wurden mit verschiedenem System
bereits überprüft [Hamborg2000]. Sie beinhaltet 75 Fragen (Items), die sich nach
85
Kapitel 6 Evaluation
den 7 Grundsätzen in Teil 10 der DIN EN ISO 9241 richten (siehe Kapitel 2.1.1
auf Seite 6). Die Fragen können alle Problemfelder, die unter den vorgenannten
sieben Grundsätzen thematisiert sind, abdecken [Hamborg2000]. Die IsoM etricsS
Fragebogen ist nach den sieben Grundsätzen nummeriert, die Verteilung wird in
Tabelle 6.1 dargestellt. Jeder Grundsatz besteht aus 6 bis 15 unterschiedliche Fragen. Jede Frage kann mit einer Zahl zwischen 1 (stimmt nicht) bis 5 (stimmt sehr)
bewertet werden. Es gibt auch die Möglichkeit eine Frage mit „Keine Angabe“ zu
beantworten. In Abbildung 6.1 ist ein Abschnitt von Fragebogen dargestellt1 .
Grundsätze
Aufgabenangemessenheit
Selbstbeschreibungsfähigkeit
Steuerbarkeit
Erwartungskonformität
Fehlertoleranz
Individualisierbarkeit
Lernförderlichkeit
Anzahl der Fragen
15
12
11
8
15
6
8
Tabelle 6.1: Aufteilung des Fragebogens
Abbildung 6.1: Beispielfrage aus dem Fragebogen
6.1.2 Experiment konstruieren
Für das Experiment mit dem IsoM etricsS Fragebogen hat der Erfinder des Fragebogens ein Handbuch „Das IsoMetrics-Manual“ geschrieben, woraus der jeweilige
1
Die IsoM etricsS Fragebogen befindet sich im Anhang A.4 auf Seite xxix
86
6.1 Vorbereitung
Entwickler nach eigenem Bedarf, abgestimmt auf sein individuelles Experiment,
Fragebögen konstruieren kann. Nach dem Handbuch sollten mindestens acht Personen befragt werden. Für das Experiment sollten geeignete Testpersonen ausgesucht werden, die die Testaufgaben auf der Benutzungsoberfläche beantworten.
Der Verlauf des Experiments wird im nächsten Abschnitt beschrieben.
Wenn über 20% der Items im Fragebogen nicht beantwortet sind, gilt dieser Fragebogen als ungültig. Ansonsten werden diese Items durch die mittlere Bewertung
„3“ ersetzt.
Ein Fragebogen besteht aus positiv und negativ formulierten Fragen. Die negativ
formulierten Fragen1 sollten noch bei der Auswertung des Fragebogens umgerechnet werden. In Abbildung 6.1 auf Seite 86 ist das Item „A.1“ als Beispiel für eine
negativ formulierte Frage dargestellt. Falls die „1“ für das Item „A.1“ angekreuzt
wird, geht diese in der Bewertung mit „5“ ein.
Für die Bewertung des Ergebnisses wird die Cut-Off-Analyse verwendet. Für jeden Teil der Fragebogen wird die Anzahl der Items, die mit „4“ oder „5“ bewertet
sind, durch die Gesamtanzahl der Items geteilt. Der Prozentsatz für jedes Teil muss
noch am Ende durch die Anzahl der Teile („7“) dividiert werden - nun wird der
Gesamtprozentsatz ermittelt. Durch diesen Gesamtprozentsatz kann das System
feststellen, ob es positiv bewertet werden kann. Die Schwelle liegt bei 50%. Falls
der Gesamtprozentsatz über 50% liegt, ist das System als positiv zu bewerten. Im
anderen Fall, wenn der Gesamtprozentsatz unter 50% liegt, wird das System als
negativ bewertet.
1
Diese Fragen sind A.1, A.8, T.12, E.8, F.1, F.7, F.14, L.1 und L.7.
87
6.2 Verlauf
Das Experiment wird nach dem Handbuch beobachtet und angepasst. Zunächst
werden die Testpersonen ausgesucht, ihnen die Aufgabestellung mitgeteilt und
anschließend das Experiment mit dem einzelnen Probanden durchgeführt.
6.2.1 Testumgebung
Der Prototyp der Benutzungsoberfläche wird auf einem IBM Tablett Notebook
X41 durchgeführt. Die Benutzungsoberfläche kann mit der Maus oder einem Stift
bedient werden. Der Prototyp stellt bereits ein virtuelles Land „Cretopia“ für die
Testpersonen zur Verfügung. Im Land sind vier Aktivitäten verfügbar: Stadtbesichtigung, Wanderung, Wassersport und Wintersport.
6.2.2 Testpersonen
Insgesamt wurden 10 Testpersonen für das Experiment ausgesucht. Unter den
Probanden waren Studenten, Auszubildende und Angestellte. Alle Testpersonen
verfügen über EDV Kenntnisse.
6.2.3 Testaufgabe
Die Testaufgabe für dieses Experiment ist, eine Tour über 15 Tage in der virtuellen
Land „Cretopia“ zu erstellen. Die Testpersonen dürfen jede Orte als Start- bzw.
Endstation festlegen.
6.2.4 Durchführung
Als erstes bekommen die Testpersonen ein Video-Tutorial gezeigt. Im Video werden zunächst alle möglichen Funktionen der Benutzungsoberfläche vorgestellt und
anschließend beispielhaft die Erstellung von drei Touren gezeigt. Nach dem Video
werden an die Probanden mit der Testaufgabestellung, eine 15-tägige Tour über
die Benutzungsoberfläche zu erstellen, Fragebögen zu der Benutzungsoberfläche
verteilt. Für die Erfüllung der Aufgabe und Beantwortung der Fragebögen sieht
das Experiment keine Zeitbeschränkung vor.
88
6.3 Ergebnis und Bewertung
Durchschnittlich dauerte das Experiment ca. eine Stunde. Alle Testpersonen haben eine Tour erfolgreich erstellt. Die Bewertung der Fragebögen wurde nach dem
„Das IsoMetrics-Manual“ ausgeführt.
Alle Fragebögen sind vollständig bearbeitet, d.h. kein Fragebogen wies eine Nichtbeantwortungsquote der Items von weniger als 20% aus. Die nicht beantworteten
Fragen gehen mit „3“ in die Berechnung bzw. Bewertung mit ein. Die negativ
formulierten Fragen werden nach dem Verfahren umgerechnet.
Die Ergebnisse der Fragebögen werden summativ mit der Cut-Off-Analyse bewertet. Der Prozentsatz für jedes Teil des Fragebogens wird zuerst einzeln berechnet,
anschließend werden die einzelnen Prozentsätze jedes Teils zusammenaddierte. Der
Gesamtprozentsatz jedes Teils ergibt sich aus der Addition der einzelnen Prozentsätze durch die Anzahl der Testpersonen („10“). In Abbildung 6.2 auf Seite 90 ist
das Ergebnis der Cut-Off-Analyse abgebildet. In dieser Abbildung beträgt der Gesamtprozentsatz für die Aufgabenangemessenheit 82%. Abschließend werden alle
Gesamtprozentsätze jedes Teils (insgesamt 7) zusammenaddiert. Der sich hieraus
ergebender Mittelwert der beträgt 75,09%.
Da der Durchschnitt aller positiven Bewertung („4“ oder „5“) 75,09% beträgt, ist
das System als positiv zu bewerten. Die Analysepunkte der Tabelle werden im
Folgenden in drei Kategorien zur Erläuterung unterteilt.
Kategorie 1: Mehr als 82 %
In dieser Kategorie liegen die Punkte Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Erwartungskonformität, und Fehlertoleranz.
Die Selbstbeschreibungsfähigkeit wurde mit 87,50% am besten bewertet. Die Testpersonen konnten den Zustand der Benutzungsoberfläche jederzeit nachvollziehen.
Sie konnten die Aufgabe selbständig mit diesem System erledigen. Sie bekommen
jederzeit Meldungen über den Fortschritt ihrer Aktionen.
Kategorie 2: 75,09% - 82%
In dieses Spektrum fällt die Erlernbarkeit mit 76,25 %. Ein Benutzer kann sich
schnell in das System einarbeiten und es dadurch ohne großen Voraufwand schnell
89
Abbildung 6.2: Evaluation - Ergebnis der Cut-Off-Analyse
effektiv nutzen.
Kategorie 3: Weniger als 75,09%
Unter der angestrebten Prozentzahl liegen die Punkte Steuerbarkeit und Individualisierbarkeit.
Die Steuerbarkeit wurde nur mit 64,55% bewertet. Das resultiert aus den folgenden drei Fragen:
T4 Die Software bietet mir die Möglichkeit, von jeder beliebigen Menüebene direkt zum Hauptmenü zurückzuspringen.
T6 Es ist immer einfach, ein gerade benötigtes Bearbeitungsprogramm auszuführen.
90
T7 Es ist für mich einfach, zwischen unterschiedlichen Bearbeitungsbildschirmen
zu wechseln.
welche von mehr als 70% der Testpersonen nicht beantwortet werden konnten.
Diese Fragen passen nicht zu der dargestellten Benutzungsoberfläche. Ohne diese
Fragen hätte die Bewertung 88,75% ergeben.
Die Individualisierbarkeit der Benutzungsoberfläche ist mit 48,33 % deutlich unter
den angestrebten 75 % bewertet worden. Der Benutzer kann die Menge der dargestellten Informationen mit Hilfe des Menüs anzupassen. Aber die Möglichkeit
zur Umbenennung der Funktionen ist in dem Prototyp nicht realisiert worden. Die
individuelle Einstellung der Geschwindigkeit der Eingabegeräte, der Menüs oder
der Symbolleisten ist auch noch nicht möglich. In weiteren Entwicklungsschritten
würden solche Zusätze berücksichtigt und auch diese Bewertung in den angestrebten Bereich bringen.
91
92
Kapitel 7
Fazit und Ausblick
7.1 Fazit
Mit dieser Arbeit ist eine Benutzungsoberfläche für Planungssysteme entworfen
worden. Zur Spezifikation dieser Schnittstelle wurden repräsentative Benutzungsoberflächen für Routenplanungssysteme auf ihre Benutzerfreundlichkeit und ihre
Abdeckung der Anforderungen für eine dynamisch parametrisierte Benutzerinteraktion überprüft. Aus den Ergebnissen dieser Untersuchung mit einer funktionalen
Analyse der Anwendungsfälle wurde eine allgemeine Spezifikation für eine grafische Benutzungsoberfläche für Planungssysteme mit dynamischer Parametereingabe erstellt. Eine Instanz dieser Modellerierung wurde zur weiteren Evaluation
im Implementierungsteil dieser Arbeit vorgestellt. Sie erfüllt alle vorher definierten
Kriterien, so dass in der Evaluationsphase eine objektive Bewertung des Aufbaus
der Schnittstelle, im Bezug auf Bedienbarkeit und Funktionalität, erfolgen konnte.
Im Folgenden werden die einzelnen Schritte noch einmal rekapituliert.
Definition eines Plans:
Die Pläne, die von der Benutzungsoberfläche dargestellt werden, erfüllen die Definition eines Plans in Kapitel 1.1 auf Seite 2. Dabei sind in der Routenplanung
die einzelnen Aktionen einer Folge solcher die Wegpunkte und die Verweildauer an
diesen Wegpunkten. Das Ziel entspricht dem Endpunkt der Reise.
93
Kapitel 7 Fazit und Ausblick
Stand der Technik:
Die Analyse derzeitiger Systeme zur Tourenplanung hat ergeben, dass die Anforderungen an eine Benutzungsoberfläche mit unterspezifizierten Eingabemöglichkeiten nicht vollständig von diesen Systemen erfüllt werden können. Als wichtigster
Mangel ist hier die Nichtberücksichtigung einer Zeitplanung aufgefallen. Auch das
Ein- und Ausschalten von POIs, ein übersichtliches großes Menü, Darstellung von
Informationen als aussagekräftige „Icons“ und eine Hilfe bei der Eingabe von Parametern wurde als Schwachstelle herausgearbeitet, die in der hier umgesetzten
Software behoben wurde.
Modellierung und Implementierung:
Als Grundlage zur Modellierung der Benutzungsoberfläche wurden Designprinzipien dienten im Wesentlichen die Arbeiten von Shneiderman und Nielsen. Daraus
ist eine Liste aus 13 Designvorgaben entstanden. Diese diente als fundamentale
Grundlage für das implementierte System, aber auch für die Evaluation vorhandener Systeme.
Zusätzlich wurden die Anforderungen für eine Benutzungsoberfläche (unter Verwendung der gewonnenen Informationen aus der Analyse bestehender Systeme)
für ein Planungssystem aufgestellt. Auf Basis der Designprinzipien und der funktionalen Anforderungen wurde ein übergreifendes Modell in UML, ergänzt durch
textuelle Beschreibungen erstellt, dass für die Evaluation dann in einer Beisplielinstanz implementiert wurde. Dabei ließen sich alle definierten Anforderungen in
der grafischen Benutzungsoberfläche abbilden.
Evaluation:
Zur Evaluation der Benutzungsoberfläche wurde das IsoMetrics Verfahren verwendet. Dieses dient der Auswertung der Funktionalität und der Bedienbarkeit des Systems nach software-ergonomischen Kriterien nach DIN EN ISO 9241 [DIN9241-10].
Einzelne Punkte des Verfahrens, die nicht Teil des Prototyps sind, können erst nach
einer Erweiterung der Anforderungen aussagekräftig evaluiert werden. Diese Auswertung der restlichen Kriterien hat ergeben, dass alle implementierten Funktionen
die Erwartungen mehr als erfüllt haben.
94
7.2 Ausblick
7.2 Ausblick
Der Prototyp lässt sich in der Zukunft um weitere Anforderungen erweitern. Der
Prototyp basiert auf einer selbst definierten Landkarte. Weitere geografische Informationen und reales Kartenmaterial würden hier weitere Anforderungen und
Anwendungsfälle schaffen. Auch die Anzahl der POIs ist in dieser Version noch
sehr gering, weitere Arten von POIs, wie z. B. Hotels, würden einen weiteren
Mehrwert für eine Tourenplanung schaffen.
Bei einer größeren Menge von Nutzern, die das System frequentiert verwenden,
sollte Personalisierung als weiteres Feature in der Benutzerinteraktion eingepflegt
werden. Die hier entwickelten Anforderungen decken die Anforderungen an eine
Tourenplanung mit unterspezifizierten Eingaben ab. Mit wenigen Anpassungen
lässt sich die Oberfläche auch für andere Algorithmen modifizieren, die unterspezifizierte Planung unterstützen.
Weitere Plattformen könnten an dieser Stelle mobile Geräte wie PDAs oder Mobiltelefone sein. Hier stellen sich wieder neue Anforderungen der "Mensch-Maschine
Interaktion"definiert durch die Bedienbarkeit dieser Geräte. Als Eingabe könnte sich hier neben den zu den Plattformen gehörenden Eingabegeräten auch die
Spracheingabe als probate Eingabemöglichkeit herausstellen.
Insgesamt ist die Interaktion mit Algorithmen für unterspezifizierte Eingaben zukunftsträchtig, da der Mensch dort zur effizienten Durchführung Computerunterstützung braucht. Im Zuge dessen werden auch die Benutzerschnittstellen weiter
erforscht. Hier bilden die hier genannten Anforderungen und die Beispielimplementierung eine gute Grundlage für weitere Projekte.
95
Kapitel 7 Fazit und Ausblick
96
Anhang A
Anhang
A.1 Softwareergonomische Kriterien
A.1.1 Acht goldene Regeln von Ben Shneiderman
Nr.
1
Prinzip
Konsistenz
2
Universelle Benutzbarkeit
3
Informative
meldungen
4
Abgeschlossene
Operationen
5
Fehler verhindern
Rück-
Beschreibung & Beispiel
Das System sollte konsistent sein, konsistente Darstellungen (z.B. Aussehen eines Dialoges, Platzierung
von Elementen, Farben und Begriffen), konsistente Interaktionen (z.B. eine Aktion sollte immer die gleich
Auswirkung haben - Doppelklick der Maus für ausführen).
Das System sollte unter Berücksichtigung unterschiedlicher Benutzer und Aufgaben gestaltet werden.
Die Benutzer unterscheiden sich in Alter, Ausbildung
etc. (z.B. Das System sollte für Anfänger und erfahrende Benutzer geeignet sein).
Das System sollte bei jeder Aktion des Benutzers eine
Rückmeldung geben. Die Rückmeldung sollte aussagkräftig sein, nur die wichtigen Informationen anzeigen.
Das System sollte dem Benutzer eine Rückmeldung
über eine abgeschlossene Aktion geben (z.B. Progressbar für herunterladen).
Das System sollte Fehler vermeiden, falsche Eingaben
verhindern (z.B. Kontonummer darf nur aus Zahlen
bestehen).
xix
Anhang A Anhang
Nr.
6
7
8
Prinzip
Einfache Rücksetzmöglichkeiten
Benutzerbestimmte
Steuerbarkeit
Geringe Belastung
des
Kurzzeitgedächtnisses
Das System sollte den Benutzer eine Möglichkeit geben, dass er seine Aktionen rückgängig machen kann.
Der Benutzer kann das System immer steuern. Er
kann alle benötigen Informationen jederzeit zur Erledigung seiner Aufgaben von dem System erfahren.
Die Anzahl der angebotenen Informationen sollte auf
das minimal limitiert werden, um das Kurzzeitgedächtnis des Benutzers zu entlasten (z.B. Information
sollte gruppiert werden).
Tabelle A.1: Acht goldene Regeln von Ben Shneiderman [Shneiderman2005]
A.1.2 Zehn Heuristiken von Jakob Nielsen
Nr.
1
xx
Prinzip
Einfache und natürliche Dialoge
2
Ausdrucksweisen
des Benutzers
3
4
5
Minimale
mentale Belastung des
Benutzers
Konsistenz
Rückmeldungen
6
Klare Auswege
Das System sollte einfach, mit minimalen Funktionen,
gestaltet werden. Es sollte an den Arbeitsprozess des
Benutzers angepasst sein.
Das System sollte die Beschreibung und Information aus der Benutzerperspektive formulieren. Es sollte die Fachsprache des Anwendungsgebiets bzw. Landessprache verwendet werden. Es können auch Metaphern dafür benutzt werden.
Die Anzahl der angebotenen Informationen sollte auf
das minimale limitiert werden, um das Kurzzeitgedächtnis des Benutzers zu entlasten.
Konsistente Darstellungen und Interaktionen.
Das System sollte den Benutzer unmittelbar über den
Fortschritt des Arbeitsprozess informieren. Der Benutzer bekommt immer eine Rückmeldung über seine
Aktionen.
Das System sollte dem Benutzer immer einen klaren
Weg zeigen, damit der Benutzer mit diesem Weg sein
Ziel richtig erreichen kann. Der Benutzer kann jederzeit seine Aktion unterbrechen oder weitermachen.
A.1 Softwareergonomische Kriterien
Nr.
7
8
9
10
Prinzip
Abkürzungen
Gute Fehlermeldungen
Fehlervermeidung
Hilfe und Dokumentation
Das System sollte für den Benutzer auch eine Abkürzung für die Aktionen anbieten (z.B. ein geübter
Benutzer kann Tastaturkürzel oder Funktionstasten
benutzen).
Die Fehlermeldungen sollten dem Benutzer gut unterstützen können, um die Fehler zu beheben.
Das System sollte vorrangig Fehler vermeiden (z.B.
Kontonummer darf nur aus Zahl bestehen).
Das System stellt Hilfe und Dokumentation zur Verfügung um den Benutzer zu unterstützen.
Tabelle A.2: Zehn Heuristiken von Jakob Nielsen [Nielsen1993]
xxi
Anhang A Anhang
A.2 Grafische Benutzungsoberfläche
A.2.1 Symbole für die Orte
Abbildung A.1: Symbole für die Orte
xxii
A.2.2 Symbole für die Symbolleiste
Abbildung A.2: Symbolleiste
xxiii
Anhang A Anhang
A.2.3 Menü für Aktivitätstypen
Abbildung A.3: Menü für Aktivitätstypen
A.2.4 Menü für Kategorien
Abbildung A.4: Menü für Kategorien
xxiv
A.2.5 Menü für Straßenverbindungen
Abbildung A.5: Menü für Straßenverbindungen
A.2.6 Menü für Topografien
Abbildung A.6: Menü für Topografien
xxv
Anhang A Anhang
A.2.7 Hauptrichtung zeichnen
Abbildung A.7: Hauptrichtung zeichnen
A.2.8 Symbolkasten für Aktivitäts-Constraints-Liste
Abbildung A.8: Symbolkasten für Aktivitäts-Constraints-Liste
xxvi
A.2.9 Symbolkasten für Touren
Abbildung A.9: Symbolkasten für Touren
xxvii
Anhang A Anhang
A.3 CD-Inhalt
Die beigefügte CD beinhaltet den gesamten Quellcode des Tourenplanungssystems
sowie einen ausführbaren Prototyp. Die Beispielkarte für den Prototyp ist in einem
Mysql-Format gespeichert. Es sind folgende Dateien beigefügt.
|-prototyp
|
Quellcode des Prototyps
|-database
|
Cretopia-Karte in Mysql-Format
|-server.bat
|
Zum Starten der Planungskomponente
|-client.bat
|
Zum Starten des Prototyps
|-diplomarbeit.pdf
Diplomarbeit in der PDF-Fassung
A.3.1 Systemvoraussetzungen
Java Runtime Environment 5.0
A.3.2 Ausführen des Prototyps
Um den Server zu starten, muss server.bat ausgeführt werden. Der Prototyp kann
mit client.bat gestartet werden.
xxviii
A.4 IsoMetrics Fragebogen
A.4 IsoMetrics Fragebogen
xxix
IsoMetrics
Fragebogen
zur Evaluation von graphischen
Benutzungsschnittstellen
(Kurz-Version)
S
S
IsoMetrics
© Heinz Willumeit (1993) / K.C. Hamborg, G. Gediga (1995 .. 97).
Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieses Fragebogens oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer,
ohner vorherige ausdrückliche schriftliche Genehmigung durch den Urheber nicht gestattet.
Form und Inhalt dieses Fragebogens können ohne vorherige Ankündigung geändert und ergänzt werden.
Version: 2.01
Juni 1997
Universität Osnabrück
Fachbereich Psychologie
Seminarstr. 20
D - 49069 Osnabrück
Germany
Kontakt:
email: [email protected]
-2-
S
IsoMetrics
Über den Fragebogen 'IsoMetricss'
Liebe Untersuchungsteilnehmerin, lieber Untersuchungsteilnehmer
Der Ihnen vorliegende Fragebogen dient zur Einschätzung der Benutzbarkeit von
Anwendungsprogrammen, die mit graphisch gestalteten Benutzungsschnittstellen ausgestattet
sind. Durch das Ausfüllen des Fragebogens helfen Sie uns, die Schwächen und Stärken des in
Frage stehenden Produktes festzustellen.
Der Fragebogen enthält Aussagen zur Benutzungsfreundlichkeit von Software. Bitte schätzen
Sie Ihre Zustimmung zu jeder Aussage auf der unter der Frage befindlichen Skala ein. Hierzu
ein Beispiel:
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Gestaltungsgrundsatz
Index
0
Diese Software ist für mich ein
nützliches Arbeitsmittel.
Keine
Angabe
X
Wenn Sie der Meinung sind, daß diese Aussage für Sie zutrifft, sollte Ihr Kreuz bei "5" für
"Stimmt sehr" gesetzt sein. Falls Sie dieser Aussage nicht zustimmen können, sollte Ihre
Kreuz entsprechend bei "1" für "Stimmt nicht" gesetzt sein. Angekreuzte Zahlen zwischen
diesen Polen bedeuten eine graduelle Zustimmung oder Ablehnung. Für den Fall, daß Sie sich
aus irgendwelchen Gründen dazu nicht äußern wollen oder können, sollten Sie "keine
Angabe" ankreuzen.
Vielen Dank für Ihre Mitarbeit
-3-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Index
A.1
Die Software zwingt mich, überflüssige
Arbeitsschritte durchzuführen.
A.3
Mit der Software kann ich zusammenhängende
Arbeitsabläufe vollständig bearbeiten.
A.4
Die Software bietet mir alle Möglichkeiten, die ich
für die Bearbeitung meiner Aufgaben benötige.
A.6
Die Software ermöglicht es mir, Daten so
einzugeben, wie es von der Aufgabenstellung
gefordert wird.
A.7
Die für die Aufgabenbearbeitung notwendigen
Informationen befinden sich immer am richtigen Platz
auf dem Bildschirm.
A.8
Es müssen zuviele Eingabeschritte für die
Bearbeitung mancher Aufgaben durchgeführt
werden.
A.9
Die vom Programm erzeugten Ausgaben passen zu
meinen Aufgabenstellungen, d.h. sie erhalten keine
überflüssigen, zu knappen oder unverständlich
formulierten Informationen.
Die Software ist auf die von mir zu bearbeitenden
Aufgaben zugeschnitten.
A.10
A.11
Auf dem Bildschirm finde ich alle Informationen, die
ich gerade benötige.
A.12
Die in der Software verwendeten Begriffe und
Bezeichnungen entsprechen denen meiner
Arbeitstätigkeit.
A.14
Die Software bietet mir eine Wiederhol-Funktion für
wiederkehrende Arbeitsschritte.
Keine
Angabe
-4-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Index
A.15
Auch nicht routinemäßig auftretende
Arbeitsaufgaben lassen sich mit der Software einfach
bearbeiten.
A.16
Für meine Arbeit wichtige Befehle werden von der
Software so dargeboten, daß sie sich leicht auffinden
lassen.
A.17
Die mit der Software erzeugten Ergebnisse lassen
sich meinen Anforderungen entsprechend darstellen
bzw. ausgeben.
A.18
Die Darstellung der Informationen auf dem
Bildschirm unterstützt mich bei der Bearbeitung
meiner Aufgaben.
Keine
Angabe
-5-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Selbstbeschreibungsfähigkeit
Index
S.2
Bei Bedarf können für die Benutzung des Systems
Erläuterungen abgerufen werden.
S.3
Die Meldungen der Software sind für mich sofort
verständlich.
S.5
Wenn ich Informationen zu einem bestimmten
Eingabefeld benötige, lassen sich diese einfach
abrufen.
S.6
Wenn Befehle in bestimmten Situationen nicht zur
Verfügung stehen (gesperrt sind), ist dies leicht
erkennbar.
S.7
Auf Wunsch bietet mir die Software neben
allgemeinen Erklärungen auch Beispiele an.
S.8
Ich kann die Rückmeldungen, die ich von der
Software erhalte, eindeutig dem auslösenden
Vorgang zuordnen.
S.9
Die Software stellt mir auf Wunsch Informationen
über die aktuellen Bedien- und
Nutzungsmöglichkeiten zur Verfügung.
S.10
Die Software liefert für mich in ausreichendem Maße
Informationen darüber, welche Eingaben gerade
zulässig sind.
S.11
Es ist für mich unmittelbar ersichtlich, was die
Befehle des Systems bewirken.
S.12
Die von der Software verwendeten Begriffe sind für
mich sofort verständlich.
S.13
Die Software bietet mir stets visuelle Hinweise auf
die aktuelle Eingabestelle (z.B. durch Markierung,
Farbe, Cursorblinken, Mauscursor etc.).
S.14
Es ist für mich eindeutig unterscheidbar, ob die
Software Rückmeldungen, Sicherheitsabfragen,
Warnungen oder Fehlermeldungen ausgibt.
Keine
Angabe
-6-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Steuerbarkeit
Index
T.2
Die Software bietet mir gute Bedienungsmöglichkeiten, um mich in Dokumenten (Texten,
Datenbanken, Kalkulationsblättern etc.) zu bewegen.
T.3
Mit der Software ist für mich ein einfaches Bewegen
zwischen den unterschiedlichen Menüebenen
möglich.
T.4
Die Software bietet mir die Möglichkeit, von jeder
beliebigen Menüebene direkt zum Hauptmenü
zurückzuspringen.
T.5
Es besteht jederzeit die Möglichkeit, bei einer
Befehlseingabe abzubrechen.
T.6
Es ist immer einfach, ein gerade benötigtes
Bearbeitungsprogramm auszuführen.
T.7
Es ist für mich einfach, zwischen unterschiedlichen
Bearbeitungsbildschirmen zu wechseln.
T.8
Die Software erlaubt mir eine Unterbrechung des
Bearbeitungsschrittes, obwohl sie eine Eingabe
erwartet.
T.10
Die Bedienmöglichkeiten der Software unterstützen
eine optimale Nutzung des Systems.
T.12
Das System läßt sich nur in einer starr vorgegebenen
Weise bedienen
T.13
Die Auswahl von Menübefehlen kann wahlweise
durch die Eingabe von Abkürzungen (Buchstaben
oder Transaktionscodes) vorgenommen werden.
T 15
Die Software erlaubt es, einen laufenden Vorgang
abzubrechen.
Keine
Angabe
-7-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Erwartungskonformität
Index
E.8
Die Software erschwert meine Aufgabenbearbeitung
durch eine uneinheitliche Gestaltung.
E.1
Die Bildschirmdarbietungen (Bedienelemente,
Eingabemasken, Fenster etc.) in einer
Bearbeitungssequenz sind für mich vorhersagbar.
E.2
Die Bearbeitungszeiten der Software sind für mich
gut abschätzbar.
E.3
Begriffe und graphische Darstellungen werden in
allen mir bekannten Softwareteilen einheitlich
benutzt.
E.4
Gleiche Funktionen lassen sich in allen Teilen der
Software einheitlich ausführen.
E.5
Die Ausführung einer Funktionen führt immer zu
dem erwarteten Ergebnis.
E.6
Die Möglichkeiten zur Bewegung innerhalb und
zwischen allen Teilen der Software empfinde ich als
einheitlich.
E.7
Die Meldungen der Software erscheinen immer an
der gleichen Stelle.
Keine
Angabe
-8-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Fehlerrobustheit
Index
F.1
Bei der Arbeit mit der Software kann es passieren,
daß auch kleine Fehler schwerwiegende Folgen
nachsichziehen.
F.2
Eingegebene Informationen (Daten, Texte,
Graphiken) gehen selbst bei einer Fehlbedienung
nicht verloren.
F.3
Fehler bei der Eingabe von Daten (z.B. in
Bildschirmmasken oder Formulare) können leicht
rückgängig gemacht werden.
F.4
Befehle, die Daten unwiderruflich löschen, sind mit
einer Sicherheitsabfrage gekoppelt.
F.5
Ich empfinde den Korrekturaufwand bei Fehlern als
gering.
F.6
Eingaben, die ich mache, werden auf ihre Richtigkeit
hin überprüft, bevor die Daten weiter verarbeitet
werden.
F.7
Bei meiner Arbeit mit der Software treten
Systemfehler (z.B. "Absturz") auf.
F.8
Mache ich bei der Bearbeitung einer Aufgabe einmal
einen Fehler, kann ich die fehlerhafte Operation leicht
zurücknehmen.
F.9
Eine Eingabe von mir hat noch nie zu einem
Systemfehler (z.B. "Absturz") geführt.
F.10
Die Software ist so gestaltet, daß das versehentliche
Auslösen von Aktionen verhindert wird (z.B. durch
Sicherheitsabstände zwischen kritischen Tasten,
durch geeignete Bennung, durch Hervorhebungen
etc.).
In einer Fehlersituation gibt die Software konkrete
Hinweise, wie der Fehler behoben werden kann.
F.12
Keine
Angabe
-9-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Fehlerrobustheit
Index
F.13
Die Fehlermeldungen sind gut verständlich und
hilfreich.
F.14
Bei fehlerhaften Eingaben gibt die Software in
einigen Fällen zu spät Rückmeldungen.
F.15
Vor der Ausführung möglicherweise problematischer
Aktionen gibt die Software eine Warnung aus.
F.16
Die Software bietet mir die Möglichkeit, trotz der
Veränderung von Daten, die Orginaldaten weiterhin
verfügbar zu halten.
Keine
Angabe
-10-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Individualisierbarkeit
Index
I.1
Die Software bietet mir die Möglichkeit der Anpassung (z.B. bei Menüs, Bildschirmdarstellungen) an
meine individuellen Bedürfnisse und Anforderungen.
I.4
Die Software bietet einfache Möglichkeiten, sie an
meinen individuellen Kenntnisstand anzupassen.
I.6
Ich habe die Möglichkeit, die Menge der auf dem
Bildschirm dargestellten Informationen (Daten, Graphiken, Texte, etc.) meinen Erfordernissen
anzupassen.
Die Software bietet die Möglichkeit, Kommandos,
Funktionen, etc. individuell zu benennen.
I.7
I.8
Spezielle Eigenschaften (z.B. Geschwindigkeit) der
Eingabegeräte ( Maus, Tastatur, etc. ) sind
individuell einstellbar.
I.11
Ich kann die Reaktionszeiten der Software an meine
individuelle Arbeitsgeschwindigkeit anpassen.
Keine
Angabe
-11-
IsoMetricsS
stimmt
nicht
stimmt
wenig
stimmt
mittelmäßig
stimmt
ziemlich
stimmt
sehr
1
2
3
4
5
Erlernbarkeit
Index
L.1
Es hat lange gedauert bis ich die Bedienung der
Software erlernt habe.
L.2
Auch bei seltenem Gebrauch ist es kein Problem sich
wieder in die Software hineinzufinden.
L.3
Bei Bedarf bekomme ich Hilfestellungen, die das
Erlernen der Software erleichtern.
L.4
Bisher war es für mich nicht schwer die Bedienung
des Software zu erlernen.
L.5
Ich konnte die Software von Anfang an alleine
bedienen, ohne daß ich Kollegen fragen mußte.
L.6
Die Software ist so gestaltet, daß bisher unbekannte
Funktionen durch ausprobieren erlernt werden
können.
L.7
Um die Software bedienen zu können, muß ich mir
viele Details merken.
L.8
Die Bedienmöglichkeiten (z.B. Programmbefehle,
Kommandos,etc.) kann ich mir gut merken.
Keine
Angabe
-12-
Anhang A Anhang
xlii
Anhang B
Literaturverzeichnis
[ADAC2008]
Chronik
des
ADAC,
letzter
Zugriff:
http://www.adac.de/Wir_ueber_uns/.
20.01.2008.
[Apple1993]
Apple Computer Inc. Macintosh Human Interface Guidelines.
Addison-Wesley Professional, 1993.
[Applegate2006]
David L. Applegate; Robert E. Bixby; Vasek Chvátal und William J. Cook. The Traveling Salesman Problem: A Computational Study. Princeton University Press, 2006.
[Byte1981]
Thomas A Wadlow. The Xerox Alto computer. In Byte, Band
9/1981, Seiten 58–68. 1981.
[Card1983]
Stuart Card; Thomas P. Moran und Allen Newell. The Psychology of Human Computer Interaction. Lawrence Erlbaum
Associates, 1983.
[DIN9241-10]
Grundsätze der Dialoggestaltung. In Ergonomische Anforderungen für Bürotäigkeiten mit Bildschirmgeräten. Beuth Verlag Berlin, 1996.
[DIN9241-11]
Anforderungen an die Gebrauchstauglichkeit. In Ergonomische Anforderungen für Bürotäigkeiten mit Bildschirmgeräten.
Beuth Verlag Berlin, 1996.
[Dahm2006]
Markus Dahm.
Grundlagen der
Interaktion. Pearson Studium, 2006.
[Eberleh1994]
Edmund Eberleh; Horst Oberquelle und Reinhard Oppermann. Einführung in die Software-Ergonomie, Seiten 118–143.
de Gruyter, zweite Auflage, 1994.
Mensch-Computer-
xliii
Anhang B Literaturverzeichnis
[Falk2008]
Geschichte der Falk-Verlag, letzter Zugriff: 05.01.2008.
http://premium.falk.de/info/geschichte.html.
[FOCUS2008]
TOMORROW
FOCUS
AG,
letzter
Zugriff:
05.01.2008.
http://www.tomorrowfocus.de/Marken/Auto/Map24/index.html.
[Google2008]
Google
Maps
API,
letzter
http://code.google.com/apis/maps/.
[Hamborg1999]
Kai-Christoph Hamborg und Günther Gediga. IsoMetrics: Ein
Verfahren zur Evaluation von Software nach ISO 9241/10. In
H. Holling und G. Gediga, Herausgeber, Evaluationsforschung,
Seiten 195–234. Hogrefe, 1999.
[Hamborg2000]
Kai-Christoph Hamborg; Günther Gediga und Heinz Willumeit. Das IsoMetrics-Manual. Arbeitsgebiete Arbeits- und
Organisationspsychologie und Methodenlehre an der Universität Osnabrück, 2000.
[Ibm1993]
IBM Corporation. Object-Oriented Interface Design: IBM
Common User Access Guidelines. Que Pub, 1993.
[Kahn1994]
Michael J. Kahn und Amanda Prail. Formal usability inspections. In Jakob Nielsen und Robert L. Mack, Herausgeber,
Usability inspection methods, Seiten 141–171. John Wiley &
Sons, Inc., 1994.
[Kirakowski1993]
Jurek Kirakowski und Mary Corbett. SUMI: the Software Usability Measurement Inventory. In British Journal of Educational Technology, Band 24/3, Seiten 210–212. 1993.
[Lewis1994]
Clayton Lewis; Peter G. Polson; Cathleen Wharton und
John Rieman. The cognitive walkthrough method: a practitioner’s guide. In Jakob Nielsen und Robert L. Mack, Herausgeber, Usability inspection methods, Seiten 105–140. John
Wiley & Sons, Inc., 1994.
[Microsoft1994]
Microsoft Corporation. The Windows Interface Guidelines
for Software Design: An Application Design Guide. Microsoft
Press, 1994.
xliv
Zugriff:
26.01.2008.
[Miller1956]
George Miller. The magical number seven, plus or minus two:
Some limits on our capacity for processing information. In
The Psychological Review, Band 63, Seiten 81–97. 1956.
[Nielsen1993]
Jakob Nielsen. Usability Engineering. Morgen Kaufmann Publishers, 1993.
[Nielsen1994]
Jakob Nielsen. Heuristic evaluation. In Jakob Nielsen und
Robert L. Mack, Herausgeber, Usability inspection methods,
Seiten 25–62. John Wiley & Sons, Inc., 1994.
[Norman1988]
John P. Chin; Virginia A. Diehl und Kent L. Norman. Development of an instrument measuring user satisfaction of the
human-computer interface. In CHI ’88: Proceedings of the
SIGCHI conference on Human factors in computing systems,
Seiten 213–218. ACM, 1988.
[Norvig2003]
Stuart J. Russell und Peter Norvig. Artificial intelligence: a
modern approach, Kapitel 11, Seite 375. Prentice-Hall, Inc.,
zweite Auflage, 2003.
[Preim1999]
Bernhard Preim. Entwicklung interaktiver Systeme, Seiten
117–138;152–168. Springer, 1999.
[Prümper1993]
Jochen Prümper und Michael Anft. Die Evaluation von
Software auf Grundlage des Entwurfs zur Internationalen
Ergonomie-Norm 9241 Teil 10 als Beitrag zur partizipativen
Systemgestaltung: Ein Fallbeispiel. In K.-H. Rödiger, Herausgeber, Software-Ergonomie’93 - Von der Benutzungsoberfläche
zur Arbeitsgestaltung, Seiten 145–156. Teubner, 1993.
[Seifert2007a]
Inessa Seifert. Region-based Model of Tour Planning Applied to
Interactive Tour Generation. In Jacko, Herausgeber, HumanComputer Interaction. HCI Intelligent Multimodal Interaction
Environments., Band 4552/2007 von Lecture Notes in Computer Science, Seiten 499–507. Springer, 2007.
[Seifert2007b]
Inessa Seifert. A Region-based Direction Heuristic for Solving Underspecified Spatio-temporal Planning Problems. In
Bernd Schattenberg Stefan Edelkamp, Jürgen Sauer, Herausgeber, Proceedings of the 21th Workshop Planen, Scheduling
xlv
und Konfigurieren, Entwerfen (PuK). Universität Oldenburg,
2007.
[Shneiderman1987] Ben Shneiderman. Direct Manipulation: A Step Beyond Programming Languages, Seiten 461–467. Morgan Kaufmann Publishers, Inc., 1987.
[Shneiderman2005] Ben Shneiderman und Catherine Plaisant. Designing the user
interface: strategies for effective human-computer interaction,
Kapitel 1.2, Seiten 71–75;152–162. Pearson Education, Inc.,
vierte Auflage, 2005.
[Sun2001]
Sun Microsystems Inc. Java(TM) Look and Feel Design Guidelines. Addison-Wesley Professional, zweite Auflage, 2001.
[Vogt2003]
Sven Heinsen und Petra Vogt. Usability praktisch umsetzen.
Hanser, 2003.
[WSDJ2007]
Website
des
Jahres,
letzter
Zugriff:
http://www.websitedesjahres.de/winners.php.
[Zühlke2004]
Detlef Zühlke. Useware-Engineering für technische Systeme.
Springer, 2004.
xlvi
23.01.2008.

Entwicklung einer interaktiven Benutzeroberfläche zur individuellen

Transcrição

Documentos relacionados

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

Benutzerordnung - Albertus Magnus Gymnasium Friesoythe

Office 365 Admin Center – First Steps - RZ

Bedeutung von Peer-to-Peer Technologien für die

Übung 1

Full Text

320 /-320L - D-Link

Poesie für jedermann und jedefrau und jeden Tag in

TÜV-Zertifikat

Handbuch Benutzerverwaltung pro/premium - Lex