Extension of ARGuide – A Multimodal User

Transcription

Extension of ARGuide – A Multimodal User Interface
Component for an Augmented Reality Mobile User
Guidance System
Diplomarbeit im Fach Informatik
Vorgelegt von
Marco Thum
Geboren am 28.12.1976 in Koblenz
Institut für Computervisualistik
Arbeitsgruppe Computergraphik
Betreuer:
Prüfer:
Intracom S.A.
Content Delivery Systems
Peania, Athen, Griechenland
Dr. Thanos Demiris
Prof. Dr.-Ing. Stefan Müller
Juli 2005
2
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als
der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher
Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer
Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß
übernommen wurden, sind als solche gekennzeichnet.
Die Richtlinien des Instituts für Studien- und Diplomarbeiten habe ich gelesen und anerkannt, insbesondere die Regelung des Nutzungsrechts.
Koblenz, den 15. Juli 2005
Unterschrift
3
Danksagung
Ich möchte mich bedanken
bei Dr. Thanos Demiris für die Ermöglichung und die Betreuung meiner Diplomarbeit.
Ohne sein Engagement wäre diese Arbeit nie zu Stande gekommen. Er hat mich stets mit
konstruktiver Kritik unterstützt und mir die richtigen Impulse gegeben.
Ich möchte mich bedanken bei Nikos Ioannidis und Nikos Pronios als Stellvertreter von
Intracom S.A. für das Vertrauen in das Gelingen des Projekts und den finanziellen Rückhalt während meines Aufenthalts in Athen,
bei Prof. Dr. Stefan Müller für die Herstellung des Kontakts zu Thanos, die Begutachtung meiner Arbeit und die Unterstützung seitens der Universität Koblenz-Landau,
bei Jens Weidenhausen vom Fraunhofer IGD für die stetige und geduldige Beantwortung
all meiner Fragen rund um den ARBrowser,
bei dem gesamten Team der Abteilung Content Delivery Systems in Intracom S.A. für
seine großartige Hilfsbereitschaft in allen Aspekten des Lebens in Griechenland, die innerhalb von 9 Monaten auftauchen können,
bei meiner Familie für die finanzielle Unterstützung und ihrem konsequenten Rückhalt
während meines gesamten Studiums und insbesondere während meines Auslandsaufenthalts. Ihr gilt mein ganz besonderer Dank.
Und schließlich möchte ich allen anderen Menschen in Deutschland und Griechenland
danken, die mich in der Zeit begleitet und mit ihren Ideen bereichert haben.
4
Inhaltsverzeichnis
1
Einleitung
11
2
Grundlagen
15
2.1
Plattformen und Lösungen . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.1.1
intGuide
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.1.2
intCulture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.1.3
ARGuide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.1.4
ARBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.1.5
Microsoft® Speech API . . . . . . . . . . . . . . . . . . . . . .
19
Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.2.1
Multimodale Schnittstellen (MUI) (nach Oviatt) . . . . . . . . .
21
2.2.2
Graphische Schnittstellen (GUI) . . . . . . . . . . . . . . . . . .
23
2.2
3
State-Of-The-Art
25
3.1
Augmented Reality User Interfaces . . . . . . . . . . . . . . . . . . . . .
26
3.1.1
Generelles Design von Benutzerschnittstellen für tragbare Geräte
26
3.1.2
Haptische Benutzerschnittstellen („Tangible UI“) . . . . . . . . .
30
3.1.3
Freihandbenutzerschnittstellen („Hands-free“ UI) . . . . . . . . .
34
5
6
INHALTSVERZEICHNIS
3.2
4
3.1.4
Hybride Benutzerschnittstellen („Hybrid UI“) . . . . . . . . . . .
36
3.1.5
Multimodale Schnittstellen (MUI) . . . . . . . . . . . . . . . . .
37
3.1.6
Avatargesteuerte Schnittstellen . . . . . . . . . . . . . . . . . . .
39
3.1.7
Spielbasierte Schnittstellen („Game-Based Interfaces“) . . . . . .
42
Eingabegeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.2.1
Gloves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2.2
Touchpads . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.2.3
Gamepads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.2.4
Remote Controls (RC) . . . . . . . . . . . . . . . . . . . . . . .
46
3.2.5
Mäuse und verwandte Geräte . . . . . . . . . . . . . . . . . . . .
47
3.2.6
Kombinationen von Ein- und Ausgabegeräten . . . . . . . . . . .
48
Design der Benutzerschnittstelle
51
4.1
Hypothesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.1.1
Aufgabenangemessenheit . . . . . . . . . . . . . . . . . . . . .
52
4.1.2
Selbstbeschreibungsfähigkeit . . . . . . . . . . . . . . . . . . . .
55
4.1.3
Steuerbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.1.4
Erwartungskonformität . . . . . . . . . . . . . . . . . . . . . . .
58
4.1.5
Fehlertoleranz . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.1.6
Individualisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . .
59
4.1.7
Lernförderlichkeit . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.1.8
Benutzerführung . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.1.9
Multimodale Interaktion . . . . . . . . . . . . . . . . . . . . . .
63
4.1.10 Graphical User Interface (GUI) vs Multimodal User Interface (MUI) 69
4.2
Ziel des initialen Prototypen . . . . . . . . . . . . . . . . . . . . . . . .
70
INHALTSVERZEICHNIS
4.3
Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.4
Anwenderszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.5
Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.5.1
Multimodale Ereignisverarbeitung . . . . . . . . . . . . . . . . .
77
4.5.2
Aktive und passive Interaktionskonzepte . . . . . . . . . . . . . .
78
4.5.3
Präsentationskonzepte . . . . . . . . . . . . . . . . . . . . . . .
86
Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
4.6.1
Multimodale Systemarchitektur . . . . . . . . . . . . . . . . . .
91
4.6.2
Komponentenkommunikation . . . . . . . . . . . . . . . . . . .
92
4.6.3
Patterns und Komponenten . . . . . . . . . . . . . . . . . . . . .
94
4.6
5
7
Realisierung
97
5.1
Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.1.1
Ereignisse der Eingabegeräte . . . . . . . . . . . . . . . . . . . .
97
5.1.2
Ereignisse der Lokalisierungsgeräte und Kontrolle der Ausgabegeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.1.3
Ereignismanagement . . . . . . . . . . . . . . . . . . . . . . . .
99
5.1.4
Ereignisse mit Zusatzinformationen . . . . . . . . . . . . . . . . 102
5.1.5
Verarbeitung multimodaler Ereignisse . . . . . . . . . . . . . . . 103
5.1.6
Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2
Präsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.2.1
Präsentationsmanagement . . . . . . . . . . . . . . . . . . . . . 107
5.2.2
Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2.3
Feedback Logging . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.2.4
Sitenavigation . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8
6
INHALTSVERZEICHNIS
Evaluation
6.1
6.2
121
Konzeptanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.1.1
Exponatmenü . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.1.2
Sitenavigation . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.1.3
„Schwebende“ Menüs . . . . . . . . . . . . . . . . . . . . . . . 123
6.1.4
Signalisierung der Stimmlautstärke . . . . . . . . . . . . . . . . 124
6.1.5
Transparenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.1.6
3D-Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.1.7
VRML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.1.8
Nicht realisierte Konzepte . . . . . . . . . . . . . . . . . . . . . 127
Benutzertests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.2.1
Testparcours . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2.2
Konzept des Fragebogens . . . . . . . . . . . . . . . . . . . . . 131
6.2.3
Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7
Fazit
151
8
Ausblick
155
8.1
Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8.2
Präsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
8.3
Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
8.4
Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A Zum Inhalt des Anhangs
161
B Eingabegeräte
163
INHALTSVERZEICHNIS
C Anwendungsdiagramme
9
169
C.1 Generelle Benutzerinteraktionen . . . . . . . . . . . . . . . . . . . . . . 170
C.2 Unterteilung der Museumssite . . . . . . . . . . . . . . . . . . . . . . . 172
C.3 Benutzerbedürfnisse im Detail . . . . . . . . . . . . . . . . . . . . . . . 174
D Anwendungsszenarios
181
D.1 Kind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
D.2 Hörgeschädigter Erwachsener . . . . . . . . . . . . . . . . . . . . . . . 182
D.3 Unterschiede von AOI und POI am Beispiel eines Erwachsenen . . . . . 183
E Mockups
185
F Sequenzdiagramme
187
G Fragebogen
191
G.1 Aufgabenangemessenheit . . . . . . . . . . . . . . . . . . . . . . . . . . 191
G.2 Selbstbeschreibungsfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . 192
G.3 Steuerbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
G.4 Erwartungskonformität . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
G.5 Fehlertoleranz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
G.6 Individualisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
G.7 Lernförderlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
G.8 Benutzerführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
G.9 Multimodale Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . 197
10
INHALTSVERZEICHNIS
Kapitel 1
Einleitung
Jeder, der schon einmal eine Museumsausstellung oder antike Stätte besucht hat, kennt
das Gefühl, dass man mehr über dieses oder jenes Gemälde oder über diesen oder jenen
Tempel erfahren möchte als der lokale Museumsführer, Karten oder Informationstafeln
erklären können. Manchmal möchte man sehen und verstehen können, mit welcher Technik ein Gemälde gemalt oder wie eine Steinskulptur gemeißelt wurde. Die Ruinen eines
Tempels lassen oftmals nicht erkennen, wie groß und mächtig dieser einstmals auf dem
Kaphügel erschien geschweige denn, wie imposant die Messen der Ortsgemeinde im Altarraum gewesen sind. Statische Bildrekonstruktionen mögen einen ersten Eindruck hinterlassen, aber das Bedürfnis, die Geschichte selbst noch einmal erleben zu können, bleibt.
Man fragt sich nun, auf welche Art und Weise sich einem Besucher solch ein Erlebnis
vermitteln lässt. Viele Forschungen auf dem Feld der (virtuellen) Kulturgutrekonstruktion
(Cultural Heritage / Virtual Heritage) haben sich schon mit der Problematik auseinandergesetzt. Es muss beachtet werden, wo und wann welche Medien dargestellt werden sollen,
wo sich der Besucher aufhält, in welche Richtungen er schaut und vor allem, welcher Informationsträger für die gewünschte Zusatzinformation verwendet wird. Hatte man anfangs
nur einen tragbaren Audiotouristenführer, der einem von Exponat zu Exponat dessen Historie und Bedeutung erklärt, so bietet sich mit mobilen Augmented-Reality-Plattformen
die Möglichkeit, dem Besucher komplette virtuelle Szenarien in der Ausstellungsumge-
11
12
KAPITEL 1. EINLEITUNG
bung zu präsentieren. Die Mobilgeräte reichen von in Rucksäcken oder an Gürteln untergebrachten Kleinrechnern in Verbindung mit HMD über Tablets bis hin zu Handhelds
(PDA) und Mobiltelefonen.
Die Verwendung mobiler AR-Systeme ist mit passiven Informationspräsentationen aber
noch nicht ausgereizt. Der Besucher soll aktiv bestimmen können, welche Medien zu
welchen Exponaten er ansehen möchte. Vielmehr soll er in das interaktive, virtuelle Szenario eingreifen können. Es besteht also ein besonderes Interesse darin, eine benutzerfreundliche, der Vielfalt an möglichen Interaktionen angepasste Benutzeroberfläche („user
interface“ (UI)) zu gestalten. Der Besucher soll in der Lage sein, sich mit Hilfe der UI zu
orientieren, zu navigieren und Objekte des Szenarios zu manipulieren. Nun kennt man
schon zahlreiche Interaktionsmetaphern für den dreidimensionalen Raum, wie sie etwa
in [BKLP04] ausführlich vorgestellt werden. Fraglich wird aber die Akzeptanz für die
Schnittstelle sein, wenn die Metaphern und Eingabemodalitäten erst einmal fremd sind.
Viele Besucher mögen bereits das WIMP-Konzept (Windows, Icons, Menus, Pointer)
kennen. Gedacht für zweidimensionale Interaktionen in graphischen Benutzerschnittstellen („graphical user interface“ (GUI)) ist es für den mobilen Einsatz aber zu statisch. Um
den Besucher an solch ein System zu gewöhnen, muss es erweitert werden.
Multimodale Schnittstellen („multimodal user interfaces“ (MUI)) können GUI durch die
Anbindung natürlicher, erkennungsbasierter Eingabemodi wie Sprache, Gestik, Mimik
oder Körperbewegungen ergänzen oder auch ersetzen. Statt dem WIMP-Konzept entsprechende Interaktionselemente („Handler“) reagieren dann Multimedia-Präsentationen direkt auf die Benutzereingaben, wie Abbildung 1.1 erklärt.
Dennoch soll dem Besucher weiterhin sichtbar bleiben, wie er welche Interaktion zu welchem Zweck durchführen kann und dies mit GUI-Elementen repräsentiert werden. Natürliche Modi sind Besucher aus ihrem Alltag gewohnt und es liegt an dem Konzept der
MUI, die Eingaben effektiv zu verwerten. Multimodalität bedeutet nämlich, dass die Daten
mehrerer Eingabedatenströme miteinander kombiniert und interpretiert werden können.
So lassen sich mehrere Metaphern wie etwa die Deutung auf ein Objekt, der Sprachbefehl
13
Abbildung 1.1: Interaktion in GUI und MUI
zur Auswahl des Objekts, die Bewegungsdeutung zum Verschieben des Objekts an einen
anderen Punkt und ein letzter Sprachbefehl zur Ablage des Objekts in einer zusammenhängenden Aktion ausführen (vgl. „Put-That-There“-Metapher [Bol80]).
Sprache und andere Modi müssen als Kommunikationsmittel nicht mehr erlernt werden,
lediglich ihre Anwendung. Da davon ausgegangen wird, dass Sprachbefehle einfacher zu
erlernen, zu erweitern und in der GUI zu symbolisieren sein werden als etwa Gesten, wird
Sprache als Eingabemodus verwendet werden. Ein weiteres Eingabegerät wird erst in Kapitel 3.2 ausgewählt. Um dem Benutzer möglichst viele Freiheiten zu gewähren, muss
darauf geachtet werden, dass die Modi sich nicht nur multimodal ergänzen, sondern auch
weiterhin unimodal verwendet werden können.
In der Abteilung Content Delivery Systems der Firma Intracom S.A., Peania, Athen, Griechenland, in welcher diese Diplomarbeit durchgeführt wurde, werden nun Konzepte und
Lösungen im Allgemeinen und Speziellen zur plattform(un)abhängigen, kontext- und positionsbasierten Präsentation von dynamischen Inhalten entwickelt. Angefangen bei der
globalen Konzeptplattform intGuide reicht die Produktpalette über die Lösung intCulture
für das Anwendungsgebiet Cultural Heritage bis hin zu ARGuide, einer Teillösung von
intCulture zur Augmentierung von Inhalten in Head-Mounted-Displays, auf Tablets und
PDA (u.a. in Kombination mit Monoculars).
Die multimodale Schnittstelle soll schließlich ARGuide mit dem Ziel erweitern, dem Be-
14
KAPITEL 1. EINLEITUNG
sucher bedacht ausgewählte Interaktionen möglichst benutzerfreundlich an einem Exponat
zu bieten und ihn ohne Ablenkung durch die Interaktionen mit der Schnittstelle anzuleiten. Die Interaktionen sollen die wichtigsten Informationsbedürfnisse von Besuchern abdecken, nämlich die Beantwortung der Fragen „Wo bin ich?“ (primär), „Was kann ich hier
sehen?“ (sekundär) und „Was ist in der Nähe?“ (tertiär). Die Bedürfnisse haben sich empirisch in der Arbeit von Intracom mit Projekten aus der Cultural Heritage und Virtual
Heritage herausgestellt. Durch Benutzertests ausgewertete softwareergonomische Richtlinien werden dann entscheiden, ob und inwieweit multimodale Interaktion einen Gewinn
für die Navigation in der AR bringt.
Kapitel 2
Grundlagen
Im Folgenden wird eine Übersicht zu der Plattform intGuide, zu dessen Anwendung intCulture und der Client-Applikation ARGuide sowie zu der Trackingkomponente ARBrowser gegeben. Die Funktionsweise der verwendeten Microsoft® Speech API zur Spracherkennung ergänzt den Überblick. Es schließt sich eine Einführung in die wesentlichen Charakteristika multimodaler und graphischer Schnittstellen an.
2.1
2.1.1
Plattformen und Lösungen
intGuide
IntGuide [DVM+ 05] ist eine Plattform zur Realisierung generalisierter, skalierbarer Systeme zur Verwaltung und Präsentation kontextsensitiver Inhalte. Sie sieht unter anderem
Profilmanagement, Personalisierung von Inhalten und Interaktion, Authoring von Inhalten
und Abläufen, Datenbankspeicherung, Anwenderlokalisierung, Ablaufkontrollen und die
Portierung auf ein breites Spektrum an Plattformen vor. Zu den potenziellen Geschäftsfeldern zählen etwa Provider von Netzwerkinfrastrukturen, Organisationen auf dem Gebiet
Cultural Heritage, Rundfunksender, Dienstleister, Hersteller von Touristenführern, Ausstellungshallen oder Themenparks.
15
16
2.1.2
KAPITEL 2. GRUNDLAGEN
intCulture
IntCulture [DVI04] ist eine Anwendung von intGuide im Gebiet Cultural Heritage. Die
Lösung bettet Techniken zu Authoring von Inhalten, XML-basiertem, plattformübergreifendem Publishing, standortbasierter Präsentation von Inhalten, Unterstützung mobiler
Empfänger in öffentlichen und lokalen kabellosen Netzwerken, Monitoring der Verteilung von Inhalten, statischer Auswertung der Nachfrage an Inhalten und Management von
Benutzerprofilen ein.
Der Besucher eines Ausstellungsgeländes erfährt anhand von zuvor erstellten Touren Details zu Exponaten und anderen markanten Punkten. Abhängig von Position, Orientierung
und Profil werden ihm Informationen in diversen Medienformaten präsentiert („contextawareness“). Er kann Annotationen aufnehmen, mit anderen Besuchern kommunizieren
und dynamische Hilfen abrufen.
2.1.3
ARGuide
ARGuide ist eine Teillösung von intGuide in intCulture mit Unterstützung durch ARTracking-Komponenten zur Ausgabe auf Geräten wie HMD oder Tablet. Zum Zeitpunkt
des Starttermins dieser Arbeit befand sich der ARGuide im Zustand eines fortgeschrittenen
Prototypen. Interaktions- und Darstellungskonzepte wurden aber überarbeitet. Es bleibt allerdings die grundsätzliche Komponentenstruktur von intCulture erhalten. Die multimodale Schnittstelle mit Präsentationseinheit wird an die vorgesehenen Komponenten für Sitemanagement, Medienmanagement und Tracking angebunden. Da sich die Arbeit auf die
Ausgabegeräte HMD (Abb. 2.1) und Binoculars (Abb. 2.2), die mit einem Sub-Notebook
(Abb. 2.4) verbunden sind, konzentriert und die Entwicklung von intCulture sich momentan stärker an mobilen Assistenten (PDA, Abb. 2.3) orientiert, sind jene Komponenten
allerdings noch nicht angepasst.
17
2.1. PLATTFORMEN UND LÖSUNGEN
Abbildung 2.1: i-Glasses mit
SVGA-Display (mit 800 x 600
betrieben).
2.1.4
Abbildung 2.2: n-Vision Binoculars
mit Firewire-Kamera und Kompass
(mit 800 x 600 betrieben).
ARBrowser
Zum Feintracking und zur Augmentierung wird der vom Fraunhofer IGD in Darmstadt,
Deutschland, entwickelte ARBrowser [SW03] eingesetzt. Er verwendet den in Zusammenarbeit von IGD und ZGDV entwickelten AVALON-Renderer1 , der unter anderem in
der Lage ist, in VRML definierte Szenen und Objekte darzustellen. Desweiteren integriert
die Komponente markerlose und -basierte Trackingverfahren.
Markerloses Tracking basiert auf dem Vergleich von Referenzbildern mit aktuellen Aufnahmen zu verfolgender Objekte [Str01]. Wird ein Referenzbild erkannt, so wird das zugehörige Überlagerungsobjekt (Overlay) anhand einer Transformationsmatrix, die die Position des Overlay relativ zum Referenzbild repräsentiert, gerendert. Als Overlays können derzeit gängige Graphikdateiformate wie (animierte) GIF, JPEG, TIF und PNG sowie
in XML spezifizierte Primitive wie Pfeile und Kreise eingesetzt werden. Tracking und
Augmentierung geschehen folglich zweidimensional. Imitiertes 3D-Tracking ist mit Hilfe
einer 3D-Rotationsmatrix möglich, wird aber im Rahmen dieser Arbeit nicht eingesetzt.
2,5D-Rendering kann durch vorgerenderte statische Szenarien, die dynamisch an die berechnete Position angepasst werden, hergestellt werden. Da ohnehin keine „Rundumper1
http://www.zgdv.de/avalon/
18
Abbildung 2.3: PDA im „ragged case“.
Abbildung 2.4: Dell Sub-Notebook.
spektiven“ möglich sind und somit die Kamera weitestgehend fixiert ist, entstehen dabei
nur minimale Verzerrungen. Aufgrund fehlender Interaktionsmöglichkeiten und des zusätzlichen Arbeitsaufwandes wird auf diese Möglichkeit aber verzichtet. Stattdessen werden Konzepte zur Interaktion mit statischen Overlays entwickelt.
Markerbasiertes Tracking kommt für den Einsatz in Museen nicht in Frage. In Innenräumen stören Marker den Blick auf die Exponate. In Außenbereichen sind die Entfernungen
des Betrachters zu Monumenten meist zu groß, um Marker erkennen zu können [Str01].
Außerdem würden sie in archäologischen Stätten nicht akzeptiert werden.
Der ARBrowser wird als ActiveX-Control in Webapplikationen und in herkömmlichen
Windowsapplikationen integriert. Er wird mit Hilfe von Konfigurationsdateien, die Referenzbild, Overlay, Trackingverfahren, Positionsmatrix des Overlays und diverse Trackingparameter enthalten, für jede Position neu initialisiert. Es können aber beliebig viele Referenzbilder der gleichen Position dynamisch zur Laufzeit hinzugefügt werden. Ebenso
lassen sich Overlays austauschen. Die vorhin genannten Primitiven, die sich gut zur Deutung und Markierung von Objekt- bzw. Overlaymerkmalen eignen würden, werden indes
nicht eingesetzt und durch andere Konzepte ersetzt.
2.1. PLATTFORMEN UND LÖSUNGEN
2.1.5
19
Microsoft® Speech API
Zur Anbindung von Spracherkennung (und später -synthese) wird das Microsoft Speech
Application Programming Interface (SAPI) in der Version 5 verwendet [Mic02]. Das zugehörige Software Development Kit (SDK) ist in der Version 5.1 frei verfügbar2 .
Andere gängige Spracherkennungssysteme wie Dragon NaturallySpeaking3 oder IBM ViaVoice4 werden strikt getrennt in SDK und eigenständige Erkennungsapplikationen, die
Sprachereignisse erkennen und sich an laufende Applikationen andocken, um die Ereignisse weiterzuleiten. Die Systeme müssen extern trainiert werden (Kommandos und ihre
Bedeutungen) und können nicht von der kommandoempfangenden Applikation gesteuert
werden. Die SDK sind sehr kostspielig und kommen für den Prototypen erst einmal nicht
in Frage. Eine dokumentierte API ist für Audient von Neuvoice5 verfügbar. Das Modul
scheint nach Berichten nicht weit verbreitet und erprobt, wurde aber als zu evaluierende
Alternative für den nächsten Prototypen ausgewählt. Das SAPI ist schon länger verfügbar
und liefert eine umfangreiche Dokumentation mit. Es bietet als Basis ein Erkennungsmodul für englisch gesprochene Eingaben.
Die Funktionsweise des SAPI ist schematisch in Abb. 2.5 erklärt. Eine Applikation erhält
erkannte Spracheingaben als Strings oder Textdateien. Zuvor muss das Erkennungsmodul
(Recognizer) initialisiert werden, welches sich wiederum an den eingehenden Audiodatenstrom des Systems ankoppelt (Audio Stream). Audio kann vom Mikrophon des Anwenders oder von einer Datei stammen. Schließlich sind über ein von Applikation und
Erkennungsmodul gemeinsam genutztes Interface (Recognition Context) die Grammatiken für relevante Sprachelemente aufzustellen. Diese können zur Laufzeit neu generiert
und gewechselt werden. Über das Interface erhält die Applikation erkannte und nach Ereignistypen (erkanntes Datum, Grammatiktyp, Lautstärke, Hypothese (s. Kap. 4.5.2), etc.)
kategorisierte Daten des Erkennungsmoduls.
2
SDK abrufbar unter http://www.microsoft.com/speech/download/sdk51/
http://www.dragonsystems.com/naturallyspeaking/
4
http://www-306.ibm.com/software/voice/viavoice/
5
http://www.neuvoice.com/products/audient.php
3
20
Sprachsynthese („Text-To-Speech“ (TTS)) wird im Rahmen dieser Arbeit hingegen nicht
Abbildung 2.5: Funktionsweise der Spracherkennung in SAPI
eingesetzt, obwohl es ein bevorzugtes Ausgabeformat für multimodale Schnittstellen ist.
Nach ersten Tests besteht die Vermutung, dass die mitgelieferte, sehr unnatürlich klingende Computerstimme zu künstlich und eher störend auf den Besucher wirken könnte.
Alternative Stimmen sind entweder sehr aufwendig selbst zu generieren oder teuer käuflich zu erwerben. Stattdessen sollten aufgezeichnete Audiokommentare mit menschlichen
Stimmen in Betracht gezogen werden.
Darüber hinaus handelt es sich um ein sprecherabhängiges Erkennungssystem, das vor
der Verwendung mit einem auf Systemebene (Windows®XP) integrierten Sprachtrainer
trainiert werden muss, um Betonungen und andere Charakteristika der Sprecherstimme in
einem Profil abzulegen. Es lautet die Regel: je größer die Trainingsmenge, desto effizienter die Erkennung. Es wird allerdings in Zukunft davon ausgegangen, dass Besucher die
Spracherkennung nicht trainieren müssen und ein sprecherunabhängiges System stattdessen verwendet wird. Jene sind derzeit aber noch sehr kostspielig.
2.2. DEFINITIONEN
2.2
2.2.1
21
Definitionen
Multimodale Schnittstellen (MUI) (nach Oviatt)
Nach der in [Ovi02] aufgestellten Terminologie zu multimodalen Schnittstellen sind diese
durch die koordinierte Verarbeitung der Anwenderdaten zweier oder mehrerer kombinierter Eingabemodi bestimmt. Es zählen hierzu etwa Sprache, Pen, berührungsempfindliche
Geräte, Handgesten, Mimik sowie Kopf- und Körperbewegungen. Das System antwortet mit Ausgabe multimedialer Präsentationen. Ein wesentliches Ziel ist die Einbindung
natürlicher menschlicher Kommunikationsformen und -verhaltensweisen. Erkennungsbasierte Verfahren sind ein notwendiges Mittel zur Detektion relevanter Merkmale in diesen
kontinuierlichen Eingabedatenströmen.
Aktive Eingabemodi
Vom Anwender absichtlich und gezielt eingesetzte Aktionen werden als aktive Eingabemodi bezeichnet.
Passive Eingabemodi
Vom Anwender unabsichtlich und unauffällig erbrachte Aktionen werden als passive Eingabemodi bezeichnet.
Gemischte multimodale Schnittstellen
Als gemischte multimodale Schnittstellen oder auch „blended multimodal interfaces“ bezeichnet man Systeme, die mindestens einen passiven und einen aktiven Eingabemodus
erkennen und gemeinsam verarbeiten. Oviatt teilt einen Modus stets entweder nur der Kategorie der aktiven oder der passiven Modi zu (z.B. Sprache ist aktiv, Gesichtsausdrücke
sind passiv). Die Vermutung liegt aber nahe, dass einige beide Kriterien erfüllen (z.B.
Sprachkommandos sind aktiv, Stimmvolumen ist passiv).
22
Zeitlich versetzte multimodale Schnittstellen
Dieser Typ einer multimodalen Schnittstelle verarbeitet zwei oder mehrere Eingabemodi, deren Daten die Schnittstelle zeitlich versetzt („temporally cascaded“) erreichen. Der
später eintreffende Modus kann die Interpretation des früheren beeinflussen. Die Eingabemodi sind entweder nur aktiv, nur passiv oder gemischt.
Wechselseitige Begriffsklärung
Wenn mehrere eventuell fehleranfällige, erkennungsbasierte Ereignismodi verarbeitet werden müssen, können sie ihre Missdeutungen gegebenenfalls gegenseitig aufheben („mutual disambiguation“). Unimodale Fehleranhäufungen, die für den Anwender besonders
auffällig sind, werden in einem multimodalen System kaschiert und sind nicht mehr so
offensichtlich.
Merkmalsbasierte Verkettung
Werden parallele Eingabeströme gleich auf ihrer Merkmalsebene miteinander verknüpft
(z.B. Phoneme bei Sprache, Viseme bei Lippenbewegungen), spricht man von merkmalsbasierter Verkettung („feature-level fusion“ oder „early fusion“).
Bedeutungsbasierte Verkettung
Wurden parallele Eingabedatenströme bereits interpretiert, können ihre Bedeutungen miteinander verknüpft werden, so dass eine neue multimodale Interpretation entsteht. Man
spricht dann von einer „semantic-level fusion“ oder „late fusion“.
Rahmenbasierte Integration
Wird ein Mustervergleich vorgenommen, um die von zwei Eingabedatenströmen kommenden Attributwerte in eine semantisch relevante Information zu übersetzen, spricht man von
rahmenbasierter Integration („frame-based integration“).
2.2. DEFINITIONEN
23
Vereinigungsbasierte Integration
Werden interpretierte Fragmente zweier Eingabedatenströme mit Teilbedeutungen durch
logikbasierte Methoden miteinander zu einer gemeinsamen Bedeutung verknüpft, spricht
man von einer vereinigungsbasierten Integration („unification-based integration“).
2.2.2
Graphische Schnittstellen (GUI)
Graphische Schnittstellen basieren oftmals auf dem Konzept von WIMP. Zumindest gilt
dies für die meisten Desktop-Applikationen. Menüs, Panels, Labels, Knöpfe, Listen, Leisten und andere Bestandteile einer GUI werden im Folgenden zur Verallgemeinerung Steuerelemente oder „Controls“ genannt. Einige Controls können andere Steuerelemente beinhalten oder gruppieren („Container“). Der Rootcontainer einer Applikation ist die „Form“.
Die zitierten Begriffe entstammen der Dokumentation6 der Klassenbibliothek des Microsoft .NET Framework SDK7 . Alle übrigen haben begrifflich einen sehr engen Bezug zu
allgemeiner definierten Bezeichnungen (vgl. [MS95]).
Rahmenbedingungen
Entscheidungskriterien für das Framework bzw. C# als objektorientierte Programmiersprache, in welchen alle Komponenten dieser Arbeit implementiert sind, waren integrierte ActiveX-Hosts für den ARBrowser und Nachteile anderer Sprachen wie etwa in C++
fehlende, spracheigene UI-Widgets. Ebenso musste eine Lösung gefunden werden, Steuerelemente über dem Fenster des ARBrowser, der das eigensinnige Double-Buffering von
OpenGL einsetzt, ohne Flimmern und Leistungseinbußen konstant zu rendern. Java etwa
unterscheidet in JFC / Swing bzw. AWT zwischen „Lightweight“- bzw. „Heavyweight“Komponenten, die beim Rendering unterschiedliche Prioritäten zugewiesen bekommen.
Alle Steuerelemente sind „lightweight“, der ARBrowser wäre „heavyweight“. „Lightweight“ über „heavyweight“ ist aber nicht ohne weiteres möglich, wie Erfahrungen im
6
7
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/cpref_start.asp
http://msdn.microsoft.com/netframework/
24
Projekt MELISA8 gezeigt haben.
Fokussierung und Selektion
Für die Interaktion mit den Steuerelementen sind die Begriffe Fokussierung und Selektion
entscheidend. Fokussierung bedeutet, dass der Anwender zu der Control navigiert und
sie dadurch hervorhebt. Eine Selektion wählt die Control aus und führt die zugehörige
Funktion aus.
8
http://melisa.intranet.gr/
Kapitel 3
State-Of-The-Art
In der noch jungen Geschichte der Augmented Reality steht die Forschung auf dem Gebiet
von adaptiven, personalisierbaren Benutzerschnittstellen noch am Anfang. Bedingt durch
verschiedene Anwendungsgebiete und stetig wechselnde Anwendungszwecke verfolgen
die meisten Anwendungen verschiedene Ansätze hinsichtlich Interaktionsmethoden und
der Darstellung von Systemfeedback. Sicherlich sollte aber das Ziel darin bestehen, durch
die Festlegung von Richtlinien optimale Schnittstellen zu entwerfen, die auf die individuellen Bedürfnisse des Anwenders angepasst sind. Daher werden im folgenden Kapitel
die Konzepte ausgewählter Schnittstellen aus verschiedensten Anwendungsgebieten untersucht.
Im Vordergrund der Analyse steht die Herausarbeitung von Vor- und Nachteilen der Schnittstellen für den Anwender hinsichtlich Benutzerfreundlichkeit und Anwendbarkeit. Vereinzelt wird gesondert auf die Verwendbarkeit für den Anwendungsbereich Cultural Heritage
eingegangen. Ein übergeordnetes Ziel ist die Aufstellung von Richtlinien aus den Projekterkenntnissen für die Gestaltung der multimodalen Schnittstelle. Sie ergeben sich teils aus
Evaluationsergebnissen und Feststellungen des Projekts, teils aus eigenen Ableitungen. In
einigen Projektvorstellungen sind desweiteren schon vom Projekt erarbeitete Richtlinien
enthalten.
25
26
KAPITEL 3. STATE-OF-THE-ART
Das multimodale Design der Schnittstelle steht im Vordergrund. Die Gestaltung anderer
Typen von Interfaces lässt aber ebenso Rückschlüsse auf gute Designkonzepte zu. Schließlich sollte die Problematik effektiver Mensch-Maschine-Kommunikation generell erfasst
werden, um Benutzerfreundlichkeit herzustellen.
Im Anschluss folgt ein kurzer Überblick über gängige Eingabegeräte und -modi, die als
Ergänzung zu Sprache in Frage kommen. An dieser Stelle werden die alternativen Eingabegeräte ausgewählt, die den Anwendern während der Evaluation zur Verfügung stehen
werden. Eine ausführlichere Auflistung aller recherchierten Eingabegeräte findet sich in
Anhang B.
Die folgenden Kategorien sind durch den Typus einer Schnittstelle bestimmt. Jeder Kategorie folgt eine Auflistung von Richtlinien und Bedeutungen für die multimodale Komponente.
3.1
3.1.1
Augmented Reality User Interfaces
Generelles Design von Benutzerschnittstellen für tragbare Geräte
Das Design einer UI für tragbare Geräte ist normalerweise streng an die verwendeten Einund Ausgabemodi gebunden. Mit der Absicht eine möglichst erlebnisreiche Immersion zu
erzielen, haben beide Modi den gleichen Stellenwert für das Design der Schnittstelle. Auf
PDA’s etwa ist der sichtbare Bereich eingeschränkt. Desweiteren muss der Benutzer den
PDA korrekt positionieren, um ein augmentiertes Bild zu erhalten. Gibt das System keine
Hinweise, welche relevanten Objekte sich in der Umgebung befinden, müsste der Benutzer
sogar wissen, zu welchen Objekten Informationen in der Datenbank gespeichert sind. Als
Einschränkung mag auch gelten, dass die Systemressourcen im Vergleich zu Tablets oder
Notebooks knapper und weniger erweiterbar sind. Für Mobiltelefone fallen diese Bedingungen umso drastischer aus. Jedoch wurde von [MLB04] bereits ein Toolkit für diesen
Gerätetypus entwickelt. Voraussetzung ist natürlich eine eingebaute oder angeschlossene
3.1. AUGMENTED REALITY USER INTERFACES
27
Kamera. Es wird davon ausgegangen, dass es eher im Interesse eines Touristen ist, wenn
das System ihn zu möglichst viel Information leitet, ohne dass er interagieren muss oder
durch beschränkte Displaygrößen in seiner Informationsaufnahme eingeschränkt wird.
Das im letzten Kapitel erwähnte System intCulture verfolgt in diesem Sinne diverse Konzepte zur Einbettung von positions- und kontextabhängiger Information.
Beim Tragen eines Head-Mounted-Display könnten sichtbare Elemente der UI, die nicht
unmittelbar am Objekt selbst untergebracht sind, den Benutzer ablenken und seine klare Sicht auf die Umgebung behindern. Denn einerseits ist der Blickwinkel eingeschränkt
und andererseits ist es umständlich, das am Kopf fixierte Gerät während der Benutzung
an- und abzulegen, um die natürliche Sicht wiederherzustellen. Daher sollten entweder so
wenig wie möglich graphische Steuerungselemente verwendet werden oder diese so untergebracht sein, dass sie den Benutzer weder in seiner Sicht noch in seiner Interaktion einschränken. [SBG98] verwenden eine limitierte Anzahl aufgabenrelevanter Steuerelemente unter Berücksichtigung der Verhaltensweisen eines Benutzers während des „Laufens,
Gehens und Stillstands“. Schließlich sollte jene Schnittstelle in der Lage sein, folgende
Restriktionen zu umgehen:
• Graphische Elemente können die Sicht des Benutzers einschränken,
• Pointing-Metapher sind nicht einsetzbar,
• die Interaktionsmöglichkeiten sollten nicht zu komplex ausfallen,
• der Benutzer nimmt visuelle Aktivität nur in einem kleinen Bereich rund um den
aktuellen fokussierten Punkt wahr.
Die resultierende UI verwendet einen reduzierten Satz an ansteuerbaren Elementen, angeordnet in einer elliptischen Form an den Grenzen des Sichtfeldes („Bulleye“). Mittels
simpler Interaktion durch Maustasten kann der Benutzer durch die einzelnen Elemente
blättern und die jeweils hervorgehobenen selektieren. Zusätzlich betonen Audiosignale
oder -kommentare die Auswahlprozedur.
28
Richtlinien und Bedeutungen
Vermeide jede Ablenkung der Sicht des Benutzers auf die reale Umgebung. Jedes
zusätzliche graphische Element kann die Sicht des Benutzers einschränken. Sogar, wenn
diese sich unmittelbar auf das augmentierte Objekt beziehen, könnten sie als „weltfremde“
Elemente erfasst werden und somit irritieren. Daher sollte entweder der verbrauchte Platz
oder die Anzahl der Steuerelemente begrenzt werden.
Die Unterbringung von so wenig wie möglich Steuerelementen am Rande des Bildschirms
hat sich an der „7±2“-Regel [Mil56] orientiert. Sie ist zur Reduzierung der Komplexität
der Interaktion gedacht, dient in diesem Zusammenhang aber auch zur Reduzierung des
zur Interaktion verwendeten Bildschirmbereichs. Jedoch bleiben die Steuerlemente stets
sichtbar. Der Anwender wird also in jedem Fall in seiner Sicht beeinträchtigt.
Ein Ansatz zur Lösung dieser Einschränkung wäre die Anbringung eines Steuerelements
zum Verstecken der Schnittstelle. Während des Versteckmodus sollte zumindest ein visuelles Steuerelement vorhanden sein, um die sonst sichtbaren Elemente wieder hervorzubringen. Infolgedessen könnte der Anwender aber die Kontrolle über die Interaktion verlieren,
wenn er sich nicht an Kommandos erinnern kann. Werden Interaktionsmöglichkeiten aber
in den augmentierten Bereich verlagert, so dass sie mit dem betrachteten Objekt getrackt
werden, so bleibt die Sicht auf das Objekt selbst frei. Alternativ könnte Transparenz helfen, Teile der Steuerelementhintergründe zu entfernen. Ein klarer Kontrast zum Videobild
muss dabei erhalten bleiben. Dennoch ist die Sicht auch hier nicht komplett frei.
Mit einem alltäglich verwendeten System wäre ein Benutzer in der Lage, jene Kommandos dauerhaft zu erlernen und sie ohne sichtbare Repräsentation zu verwenden. Ein Tourist
wird den ARGuide aber nur für wenige Stunden oder Ausstellungstouren nutzen. Die Interaktionsmodi müssen also unmittelbar verstanden werden können. Daher sollen die Steuerelemente anhand ihrer Beziehung zur Schnittstelle unterschieden werden (vgl. „screen-“
und „world-stabilized“[HFT+ 99]):
• Primäre, dynamische Steuerelemente, die sich auf die Interaktion mit und Manipulation von augmentierten Objekten beziehen,
29
• sekundäre, statische Steuerelemente, die sich auf das Abrufen nicht-objektrelevanter
Information und die Interaktion mit dem System selbst beziehen.
Während der Überlagerung eines Objekts können diejenigen Steuerelemente, die es manipulieren oder nach Kategorien sortierte Informationen liefern können, zusätzlich am
Overlay ausgerichtet werden, um ihren Bezug zum Objekt zu betonen. Zur physikalischen
Repräsentation des Interaktionsmodus können die Steuerelemente ein Teil des Overlays
selbst sein. Beispielsweise könnte der Eingang eines Tempeloverlays hervorgehoben und
mit einer Textrepräsentation versehen werden. Die Metapher würde als Kommando zum
Erhalt einer Einführung in die Geschichte des Tempels dienen. Der Ansatz kann als Ableitung von Interaktionen mit realen Umgebungen verstanden werden, in welcher Steuerelemente stets am Objekt selbst angebracht sind (z.B. Türklinke, Schalter am Fernseher etc.).
Andererseits können sekundäre Informationen wie etwa Benutzerstatus oder allgemeine
Ausstellungsinformationen, die sich außerhalb der Benutzerreichweite befinden und in einem Repository abgespeichert sind, als statische, im Bildbereich fixierte Steuerelemente
präsentiert werden. Durch diesen Ansatz wird verhindert, dass die Steuerelemente permanent getrackt werden müssen.
Vermeide WIMP. In einer Augmented-Reality-Umgebung müssen andere Interaktionsmetaphern als in WIMP verwendet werden, weil der Anwender nicht mehr in einer simplen
zweidimensionalen Welt agiert. Vor allem die in WIMP verwendete Pointing-Metapher ist
in solch einer Umgebung nicht genau genug. Ein Benutzer wird ein flaches Steuerelement
nicht ohne weiteres deuten können, während er sich und ein Eingabegerät frei im dreidimensionalen Raum bewegt. Jedoch sind verschiedene fortschrittlichere Geräte als Maus
und Tastatur auf dem Markt erhältlich, die bei der Navigation, Interaktion und Manipulation in der interaktiven Welt behilflich sind. Zwar konnten vor der Realisierung der Schnittstelle keines der gefundenen Geräte (siehe Anhang B) getestet werden, allerdings wird
prinzipiell davon ausgegangen, dass die meisten eine gewisse (längere) Gewöhnungszeit
benötigen. Daher soll das Design der Schnittstelle die Herausforderung akkurater Interaktion lösen und die Eingabegeräte einfach gehalten werden.
Die Ideen des Desktop-Konzepts bleiben aber immer noch nützlich. Die meisten poten-
30
ziellen Anwender des ARGuide dürften mit dieser Art Interaktion vertraut sein. Daher
könnten sie das System intuitiver bedienen, wenn einige dieser Ideen integriert sind. Besonders für die statischen Steuerelemente sollte das Konzept in Betracht gezogen werden.
Dennoch scheint dies nur eine Übergangslösung zu sein, da das Ziel sein soll, alle Elemente der Schnittstelle in den augmentierten Bereich zu verlagern. Dies entspricht eher
den alltäglichen Interaktionsszenarios in der realen Welt.
Reduziere aufgabenlösende Schritte. Wie vorhin bemerkt, wurde eine Regel angewandt, um die Komplexität der Interaktion zu minimieren. Um eine gestellte Aufgabe
zu lösen, sollte ein Anwender so wenig wie mögliche Interaktionsschritte ausführen müssen. Zu viele Ausführungsschritte könnten einen kognitiven Ballast erzeugen. Zum einen
müsste ein Tourist aus einem Überfluss an Möglichkeiten auswählen und dabei nicht die
Hauptfunktionalität herausfinden, zum anderen würde er wahrscheinlich nicht in der Lage
sein, die Schritte in Erinnerung zu behalten. Nichtsdestotrotz soll die Anforderung gelöst
werden, für ein Exponat so viele Informationen wie möglich zu präsentieren. Ein Ansatz
könnte sein, das Layout der sichtbaren Schnittstelle dynamisch anzupassen, anstatt alle
Interaktionsmöglichkeiten auf einmal darzustellen.
Verwende Audio als Feedbackmodus. Die meisten Benutzerschnittstellen verwenden
Audio sekundär als Warnungs- oder Bestätigungssignal. Wenn aber visuelle, sichtverdeckende Elemente möglichst vermieden werden sollen, kann Audio jede Benutzeraktion
kommentieren. Neben simplen Tönen können Audiokurzkommentare („Audio Cues“) als
Feedback verwendet werden. Dennoch sollte auf die Gestaltung der Audiodateien großen
Wert gelegt werden, damit sie den Anwender nicht belästigen (z.B. das Rotieren eines
Overlays und gleichzeitige Bestätigung jeder einzelnen Gradänderung).
3.1.2
Haptische Benutzerschnittstellen („Tangible UI“)
GUI verwenden teilweise sehr abstrakte Repräsentationen der Interaktionsoptionen, z.B.
Ikonen. Es kann dann vorkommen, dass ein Anwender ihre Bedeutung interpretieren muss,
besonders dann, wenn keine Textrepräsentation vorhanden ist.
31
Tastbare Benutzerschnittstellen verwenden dagegen die physikalischen Objekte der realen Welt, um den Status des Systems zu ändern. In [PTB+ 02] wurde eine „tangible UI“
zur Evaluation von Cockpitkonsolen in Flugzeugen entwickelt. Marker werden zur Augmentierung von Interaktionsobjekten und -modi als physikalische Schalter („Handler“)
oder Datencontainer verwendet. Das Muster auf dem Marker ist eine Abstraktion des augmentierten Symbols. Die Marker werden hier „Tiles“ genannt.
Alle gleichzeitigen Anwender des Systems haben einen gemeinsamen Arbeitsbereich, in
welchem sie sowohl mit physikalischen als auch digitalen Handlern interagieren („Phicons“), auch wenn sie keine See-Through-Displays tragen. Die „Tiles“ werden in „Data“,
„Operation“ und „Help Tiles“ unterschieden. Alle Operationen werden durch Kombination dieser Marker durchgeführt, und zwar genau dann, wenn diese sich annähern oder
nebeneinander gehalten werden.
Vermeide es, den Benutzer von seiner Aufgabenlösung abzulenken. Neben der Richtlinie die Sicht eines Anwenders nicht unnötig zu blockieren, sollten Anordnung und semantische Abstimmung der Steuerelemente gut überlegt sein. Wenn ein Anwender nicht
weiß, woher er kommt oder wohin er mit den nächsten Schritten gehen kann, könnte dies
zu Verwirrungen führen. Wenn zu viele Interaktionen nötig sind, um eine bestimmte Aufgabe zu lösen und diese nicht direkt mit dem eigentlichen Ziel in Verbindung gebracht
werden können, könnte der Benutzer die Schritte vergessen und müsste sie vorher trainieren oder sich jedesmal an sie erinnern. Ziel sollte es aber sein, mit der Schnittstelle intuitiv
zu interagieren, ohne den Weg zum Ziel, sondern nur das Ziel selbst zu kennen.
„Tiles“ benötigt nur eine geringfügige Anzahl von Steuerelementen für die Interaktion.
Platz wird durch die Selbstmanipulation eines Steuerelements eingespart. Es wechselt seine Bedeutung, nicht aber Position und physikalische Präsenz. Durch das Erlernen weniger
operationaler Aufgaben kann ein Anwender das gesamte System manipulieren.
32
Verwende die physikalische Umgebung zur Anpassung der Schnittstelle. Erfahrungen zufolge, ist es aus didaktischer Sicht essenziell für den Lernprozess, fühlbaren Kontakt mit den Objekten zu haben, von denen oder über die gelernt werden soll, insbesondere, wenn Abläufe geschildert werden (vgl. Gebrauchsanleitung). Unterbewusst könnten
das Erkennen von und Erinnern an Formen und Strukturen einem Anwender helfen, das
Verhalten von Steuerelementen zu erfassen. Demnach werden die „Tiles“ in Händen gehalten („Operation“) oder können auf dem Whiteboard bewegt werden („Data“). Unnötige
Elemente sind infolgedessen niemals vorhanden und müssen nicht versteckt werden. Stattdessen werden ihre Inhalte manipuliert, um ihnen ein anderes Verhalten zu geben.
Jedoch sind die meisten Ausstellungen unglücklicherweise nur zur Anschauung gedacht.
Ihre Exponate verbergen sich hinter Vitrinen, dürfen nicht angefasst werden oder können
nur aus der Distanz betrachtet werden. Direkte Manipulationen sind also nicht möglich. Erschwerend kommt hinzu, dass dynamische Eingriffe in die von der Kamera aufgenommenen Umgebung keinen Einfluss auf das Tracking haben. Markerloses Tracking nutzt Referenzbilder quasi als natürliche Marker. Im aktuellen Entwicklungsstadium des ARBrowser
sind mehrere Referenzbilder für eine Konfiguration möglich, allerdings kann nicht jedem
Bild ein eigenes Overlay zugewiesen werden. Und das Laden einer neuen Konfiguration
kann nur durch ein Anwender- (z.B. Tastendruck) oder Systemereignis (z.B. Positionswechsel) ausgelöst werden, nicht aber durch Veränderungen im Videobild. Später wird es
dann eventuell möglich sein, Interaktionen durchzuführen, wie sie in den Nachstellungen
3.1 und 3.2 als Sequenz dem „Tiles“-Modell nachempfunden sind.
Binde Personen in die Interaktion ein, die kein AR-Equipment tragen. Untersuchungen und persönliche Erfahrungen haben gezeigt, dass nach der Diskussion und Verifizierung gelernter Inhalte mit anderen Personen Informationen dauerhafter und lückenloser
gespeichert werden können. In einer Ausstellung nehmen viele Menschen Informationen
auf, was aber nicht notwendigerweise bedeutet, dass sie auch ihre Bedeutung verstehen.
Die Beteiligung anderer Personen könnte helfen, komplexe Prozeduren zu verstehen. Zum
Beispiel könnte ein Rollenspiel eine Situation nachempfinden, die sich im Leben der antiken griechischen Bürger abgespielt hat. Jede Person muss das Verhalten und den Lebenslauf seines Charakters erlernen und verbreitet das neue Wissen durch das Spielen der
Abbildung 3.1: Geste „Daumen
rechts“ führt zum Wechsel des
Overlay.
33
Abbildung 3.2: Geste „Daumen
rechts“ zeigt nächstes Overlay.
Rolle. Technisch gesehen, würde dies zu Tracking, Klassifikation und Augmentierung von
Personen anstatt von Objekten führen.
Nach dem Ansatz von „Tiles“ ist jeder in der Lage, mit der Umgebung zu interagieren,
selbst wenn er keine sachgerechten Geräte trägt. Durch das Diskutieren verschiedener
Konstellationen von Steuerelementen auf der Cockpitkonsole mit vielen Expertenmeinungen könnte ein besseres Design erzielt werden.
Verwende ein aktives dynamisches Hilfesystem. Anstatt Hilfen erst nach direktem
Aufruf entsprechender Funktion zu erhalten, könnte das System das Benutzerverhalten
aufzeichnen, auswerten und entsprechend adaptiertes dynamisches Feedback zurückliefern. Ein Anwender soll sich nicht nach wertvollen Tips erkundigen müssen. Stattdessen
könnte die Schnittstelle Erscheinung und Verhalten den Benutzeraktionen entsprechend
anpassen. „Tiles“ verwendet einen speziellen Marker, der an andere angelegt werden kann,
um zusätzliche Informationen zu erhalten. Nichtsdestotrotz muss der Anwender immer
noch aktiv eingreifen, aber die Hilfsinformation wechselt dynamisch.
34
3.1.3
Freihandbenutzerschnittstellen („Hands-free“ UI)
Bisherige Konzepte benötigen stets ein physikalisches Instrument, um mit der Schnittstelle zu interagieren. Eine komfortablere, weil natürlichere Idee, dürfte die Verwendung
freihändiger Interaktionstechniken sein, bei welchen Teile des Körpers zum Eingabegerät
werden (Kopf-, Lippen-, Augenlid- oder Armbewegungen, Gesten, Sprache, etc.). Andere,
körperfremde Geräte sind eher eine weitere Abstraktionsschicht zwischen Anwender und
Schnittstelle.
Das Projekt „Tinmeth“ [PT03] befasst sich mit freihändiger Navigation und Manipulation in Außenbereichumgebungen. Anwender sollen in der Lage sein, dreidimensionale
Objekte in der Außenwelt zu erstellen und sie in der Umgebung zu überlagern. Als Eingabegerät werden simple Pinch Gloves verwendet, deren Daumen mit herkömmlichen Markern in-side-out getrackt werden. Das (visuelle) Interface wird nun anhand von Position
und Orientierung der Daumen in das Sichtfeld eingeblendet. Es wird also dynamisch in das
wahrgenommene Videobild gerendert, auch wenn die Steuerelemente selbst statisch sind
und sich nicht direkt auf Objekte in der Umgebung beziehen. Die Menüs können durch das
Drücken eines Daumens und eines Fingers, der auf einen Eintrag zeigt, angewählt werden.
Achte auf konsistente Darstellung augmentierter Elemente. Die Augmentierung einer Schnittstelle anhand von Trackingkoordinaten, die der Anwender selbst aktiv definiert, hat gegenüber statischen Versionen einige Vorteile. Sie wird dort dargestellt, wo
der Benutzer es positioniert haben will, und kann auf einfache Weise durch Weghalten
der Handschuhe aus dem Kamerawinkel versteckt werden. Die Hände müssen wohl aber
ruhig gehalten werden, wenn der Anwender alle Elemente ohne Verwacklungen und Flimmern wahrnehmen möchte. Auch könnte ständiges Ausstrecken der Arme den Benutzer
ermüden lassen, da sie sich im Blickfeld der Kamera befinden müssen.
Ermögliche schnellen und freien Zugriff zu Menüelementen. Softwareergonomischen Richtlinien für den Desktop zufolge [fN95] [fN98a] ist es sehr wichtig, einen kom-
35
pletten Überblick über die Systemfunktionen zu haben, auch wenn die Anzahl der Interaktionsmöglichkeiten hoch und komplex ist. Daher sollten Menüs oder - als eine von
WIMP unabhängigere Definition - „Interaktionsschalter“ („Handler“) schnell und frei erreichbar sein. Infolgedessen sollte ein Benutzer Einträge ohne langes Suchen finden und
sie unmittelbar selektieren können. In der Umgebung von „Tinmeth“ kann ein Anwender alle Einträge durch das Zusammendrücken von Daumen und Zeigefinger auswählen.
Er muss kein (körperfremdes) Interaktionsgerät bewegen oder komplexe Schritte ausführen. Alle benötigten Elemente sind auf dem Bildschirm sichtbar. Darüber hinaus wurden
viele weitere konkrete Interaktionsmetaphern entwickelt. Da sie aber eng an die Aufgabe
der Außenweltmodellierung gebunden sind, werden sie an dieser Stelle nicht im Detail
beschrieben.
Halte die Hände des Benutzers frei. Eine Intention von „Tinmeth“ ist es, die Hände
des Benutzers möglichst frei zu halten. Er verwendet stattdessen seine Hände selbst als
natürliches Interaktionsgerät. Aus diesem Grund kann er stets nicht-AR-relevante Aufgaben (z.B. das Öffnen einer Tür) lösen, ohne das System zu verlassen. Zudem benötigt er
keine Trainingsphase zum Erlernen der Funktionalität eines Eingabegerätes. Ein erwartetes, aber missverstandenes Verhalten des Gerätes wird ebenso vermieden.
Stelle verschiedene Interaktionsmodi zur Verfügung. Zwar wurden die fortgeschrittenen Interaktionsmetaphern zur Erstellung der Außenwelt nicht vorgestellt, dennoch sind
sie überaus wichtig, um die Aufgaben schnell und erfolgreich abzuwickeln. Es wurden
verschiedene Techniken entwickelt, um dreidimensionale Primitive und komplexe Objekte augmentiert in der Umgebung darzustellen. Für einen Anwender kann es also hilfreich
sein, eine Aufgabe auf mehrere Weisen zu lösen. Manche sind weniger komplex, manche
schneller und andere wiederum komfortabler. Die Vorzüge des Anwenders würden über
die Auswahl entscheiden.
Die Idee des Projekts betont das Ziel, dem Anwender eine simple, aber funktionsreiche
Schnittstelle für jeden Benutzertypus zu geben. Ein elektronischer Touristenführer muss
ebenso ein breites Feld an Benutzerfähigkeiten abdecken können. Jedoch wird das Ziel der
36
multimodalen Komponente nicht sein, eine Vielzahl an Interaktionsmetaphern zu bieten,
sondern wenige für die Bedienung des gesamten Systems (z.B. „Show < media > of <
item >“ mit < media > als Medientyp Video, Text, Audio, etc. und < item > als Exponatbezeichner). Ein Benutzer wird nicht zwischen verschiedenen Modi wechseln müssen,
vielmehr kann er sich jederzeit frei für eine Methode entscheiden.
3.1.4
Hybride Benutzerschnittstellen („Hybrid UI“)
Im Projekt „MARS“ wurde eine sogenannte „Hybrid UI“ [HFT+ 99] zur Kollaboration von
Outdoor- und Indoor-AR-Systemen entwickelt. Hauptanliegen ist es, die Modifikation des
mobilen Outdoorinterface durch die Manipulation des Indoorinterface zu ermöglichen. Im
Außenbereich wird eine Kombination von HMD, GPS-Sensor, Trägheitssensor und/oder
einem PDA zur Navigation verwendet, wogegen im Innenbereich mittels eines Desktopsystems oder eines (immersiven) Projektionsbildschirms das Weltmodell verändert und
mit Informationen belegt werden kann. Das System unterstützt verschiedene Arten von
Medien wie etwa Text, Audio, statische Bilder, Videos, 3D-Graphiken und Panoramabilder.
Die Outdoor-Schnittstelle ist in zwei Typen von Steuerelementen unterteilt. „World-stabilized“ Objekte sind an realen Weltmodellobjekten orientiert und ausgerichtet und bewegen sich mit Benutzerposition und -orientierung. „Screen-stabilized“ Objekte überlagern
ortsfest das ebene Videobild der Sicht des Benutzers auf dem Ausgabegerät. Dagegen ist
die mobile PDA-Schnittstelle nicht immersiv und präsentiert das Weltmodell als zweidimensionale Karte. Ein Anwender kann die Repräsentation modifizieren und damit einen
unmittelbaren Informationsaustausch im dreidimensionalen Modell auslösen. Im Innenbereich kann das Modell auf einem nicht-immersiven Desktop angezeigt werden. Fenster
(„Windows“) dienen der Auf- und Verteilung der Information der 3D-Umgebungskarte.
Dagegen kann er in die immersive Projektion per Handinteraktion eingreifen.
Unter Beachtung der Erkenntnisse von „MARS“ muss eine Benutzerschnittstelle für eine
Augmented-Reality-Plattform nicht notwendigerweise uniform sein und auf einem spezifischen Gerät bedient werden. Vielmehr können mehrere unterschiedliche Einzelgeräte
37
ein Gesamtsystem bilden. Es ist wichtig, den Zweck der Benutzerschnittstelle zu definieren, um die Systemkomplexität zu reduzieren. So ist es dem Anschein nach einfacher,
Objekten Informationen über einen nicht-immersiven Display zuzuordnen als über einen
immersiven HMD.
Ordne die Elemente der Schnittstelle nach Relevanz. Üblicherweise werden die untergeordneten Steuerelemente zu einem Thema ihrer Bedeutung nach durch graphische
Features und räumlich zusammengehörige Anordnung gruppiert [MS95]. In einer ARUmgebung muss dieser für Desktop-Oberflächen gedachte Ansatz in die dritte Dimension
verlegt werden (z.B. in „MARS“ farblich hervorgehobene Gebäudeoverlays zur Gruppierung von Gebäuden derselben Fakultäten auf einem Campus). In „MARS“ werden Elemente primär nach ihrer Zugehörigkeit unterschieden. Entweder sie beschreiben Informations- und Interaktionspunkte in der getrackten 3D-Landschaft, oder sie steuern Systemzustände, die das augmentierte Modell indirekt beeinflussen. Interaktionen mit der Welt
sind also strikt getrennt von denen mit dem System. Wichtig ist hier, dass die Steuerelemente nicht nur räumlich und graphisch getrennt sind, sondern wahrscheinlich auch durch
verschiedene Interaktionsmetaphern. Wie aber einige Abschnitte zuvor festgestellt wurde,
soll deren Anzahl möglichst gering sein.
3.1.5
Multimodale Schnittstellen (MUI)
Nach der Definition einer klassischen multimodalen Schnittstelle [Ovi02] werden typische
Steuerelemente wie in graphischen Benutzerschnittstellen (GUI) durch direkte kombinierte Verarbeitung mehrerer Eingabedatenströme abgelöst. In GUI müssen Steuerelemente
mit dem Eingabegerät betätigt werden, und in MUI fängt ein unsichtbarer Interpreter die
Datenströme von Interaktionsgeräten ab und integriert sie in ein einzelnes Datum, welches
ein multimediales Feedback des Systems auslöst. Als Medientypen kommen u.a. Text-ToSpeech (TTS), Non-Speech Audio, Graphiken und Animationen in Frage. In MUI fällt also
theoretisch die abstrakte graphische Ebene zwischen Benutzer und Applikation, repräsen-
38
tiert durch Ikonen, Menüs, Tabulatoren, Fenster etc., weg und wird durch unmittelbare, im
Hintergrund ablaufende Interpretation ersetzt.
Für eine AR-Anwendung bedeutet das Fehlen herkömmlicher GUI-Steuerelemente auch
der Wegfall bzw. die Reduzierung zweidimensionaler Interaktion mit einer dreidimensionalen Umgebung. Der Anwender muss also nicht von 2D nach 3D abstrahieren. Durch
die Addition natürlicher, erkennungsbasierter Eingabemodi könnte zudem die Abstraktion
von Eingabegerät zu Interaktion entfallen (z.B. Flystick und Piemenü (GUI) vs. Sprache
und Pen (MUI)).
Natürlich kommt es immer auf den Anwendungszweck an, um die Frage zu beantworten,
wann welche Arten von Schnittstellen eingesetzt werden sollten. Im Projekt „Smart Sight“
[YYDW99] wurde eine multimodale Schnittstelle für einen elektronischen Touristenführer eingesetzt. Zwei vernetzte Rechner teilen sich die Prozesse um Aufnahme, Verarbeitung und Feedback. Das Teilsystem auf dem in einem Rucksack verstauten, leichtgewichtigen Sub-Notebook übernimmt die Aufgaben des GPS-Positionstracking, der Spracherkennung, -analyse und -synthese, der Audioeingabe und -ausgabe sowie der Verwaltung
von Informationsdatenbank, Positionskarten und Dialogsystem. Das zu einem am Gürtel befestigten Kleinrechner übertragenen, multimodal interpretierten Feedback wird über
einen HMD ausgegeben. Jenes Teilsystem sendet zuvor wiederum die Daten von Gestenund Zeichenerkennung, die über eine Miniaturkamera aufgenommen wurden, an den Interpreter auf dem vernetzten Gerät. Zeichenerkennung bedeutet in diesem Zusammenhang
die Untersuchung des Kamerabildes auf klassifizierte Muster und Textphrasen wie etwa
Warnschilder oder Wegweiser.
Anhand einer Beispielapplikation wurde gezeigt, dass Touristen mit dieser Systemarchitektur in der Lage sind, Schnappschüsse und Kurzvideos aufzunehmen, sie zu organisieren
und zu kommentieren („Tourist Diary“). Ein weiteres Beispiel zeigt, wie die Umgebung
bilderkannt und semantisch interpretiert werden kann. So können etwa Bezeichnungen auf
Schildern erkannt und in die Sprache des Anwenders übersetzt werden.
39
Das System kennt die Umgebung besser als der Anwender. Datenbanken mit detaillierten Standortinformationen in Kombination mit Positions- und Orientierungsdaten des
Anwenders erlauben eine kontextsensitive Präsentation von Informationen für die Exponate einer Ausstellung. Ohne dass ein Anwender eingreift, kann das System anhand der Daten, die das Tracking liefert, automatisiert Inhalte anzeigen („context-awareness“). Wann
immer möglich soll die Schnittstelle den Anwender ohne dessen Aufforderung bei seinen
Interaktionen unterstützen.
Nutze möglichst viele, einfach und schnell auswertbare Informationsquellen aus. In
einer multimodalen Umgebung lassen sich zusätzlich die Daten passiver Eingabeströme
analysieren, wie etwa die Frequenz von Tastendrücken, das Stimmvolumen oder aufgeregte Handbewegungen. Zeichnet man auch die aktiven Benutzeraktionen auf, könnte die
Analyse beider Datenströme im Vergleich zu Systemnachrichten Rückschlüsse auf korrektes oder fehlerhaftes Systemverhalten geben. Das Ergebnis der Analyse ließe sich dann
dazu verwenden, die Schnittstelle dem Benutzerverhalten anzupassen oder zumindest Hilfestellung zu schwierig erscheinenden Interaktionen zu geben.
Lass den Anwender die Kontrolle der UI stets bewahren. Damit der Anwender den
Dialog verstehen kann, muss das System ihn durch Feedback anleiten können. Reaktives
Feedback erfolgt schon dann, wenn das System korrekt auf die Anfragen des Anwenders
reagiert und ihn dadurch in seiner Interaktion bestätigt. Besser scheint es aber, wenn das
System durch vergangene Aktionen auf mögliche zukünftige vorausschaut und den Anwender anleitet. Feedback kann in Form der schon erwähnten Multimediatypen, Text oder
Farb- und Helligkeitsunterschiede erfolgen.
3.1.6
Avatargesteuerte Schnittstellen
Einem herkömmlichen realen Szenario nachempfunden, kann ein elektronischer Touristenführer durch einen Avatar repräsentiert werden. Die Notwendigkeit, zu einem unper-
40
sönlichen System zu abstrahieren, entfällt, denn alle Interaktionen erfolgen über den Avatar.
Im Projekt „GEIST“ [AGS04] etwa wurde ein derartiger Touristenführer als Lernplattform für Besucher der Stadt Heidelberg in Deutschland entwickelt. In einem erzählenden
Dialog informiert er den Besucher über die Geschichte zur Zeit des Dreißigjährigen Krieges („Digital Storytelling“), abhängig von seiner Position und Orientierung, die von GPS,
Trägheitssensoren und Videotracking über Binoculars an einem besuchten Ausstellungsort
erfasst werden. Der Anwender interagiert mit sogenanntem „Magic Equipment“ wie etwa
einem „Magic Book“, das seine Erfahrungen über bereits besuchte Orte aufführt.
Der Besucher erlebt die Geschichte als nicht-lineare Erzählung. Er kann sich frei bewegen
und informieren. Der Avatar passt sein Verhalten den Benutzerpräferenzen und -aktionen
kontinuierlich an. Durch das Lösen von Quests soll der Lernprozess gezielt gefördert werden. Die Gestaltung von Geschichte, Inhalten und Quests wird von Experten aus Pädagogik, Stadtplanung und Historik sowie Touristenführern mit Hilfe eines Autorensystems
übernommen.
Lass den Anwender den Kontext spielerisch lernen. Ein Hauptziel von „GEIST“ besteht darin, dem Besucher Geschichte spielerisch zu erklären. Er soll die Informationen
durch gezieltes Lösen von Aufgaben in einer Quest erhalten. Erfahrungen zufolge ist Eigeninitiative ein wichtiges didaktisches Konzept zur dauerhaften Speicherung gelernter
Inhalte.
Dagegen sprechen Erfahrungen im Rahmen von Archeoguide [VIK+ 02] und intCulture
dafür, dass Touristen Inhalte gerne ohne eigene Interaktion präsentiert bekommen möchten. Die Systeme liefern die Informationen dementsprechend „context-“ und „locationaware“, also abhängig von Eingaben, die nicht aktiv durch den Anwender erfolgen. „GEIST“
berücksichtigt diesen Wunsch. Der Avatar kennt die Umgebung und liefert auch automa-
41
tisiert Informationen. Lediglich soll der Anwender das nächste zu besuchende Exponat
selbst bestimmen, und zwar unter Berücksichtigung von Lösungsmöglichkeiten gestellter
Aufgaben. IntCulture sieht hier vorkonfigurierte Touren vor, die der Besucher abgehen
kann. Zusätzlich hilft er dem Anwender bei der Wegfindung.
Die multimodale Schnittstelle soll aufgrund der unterschiedlichen, aber begründeten Ansätze beide Konzepte integrieren. Der Anwender wird selbst auswählen können, wie er die
Ausstellung kennenlernen möchte. Das Lernkonzept von „GEIST“ könnte vor allem für
Kinder und Jugendliche interessant sein.
Immersion erhöht den Komfort. Es wird angenommen, dass der Besucher sich umso
immersiver in der Geschichte fühlt, desto weniger er zwischen Interaktionsgeräten bzw.
Schnittstelle und System abstrahieren muss. Aus Erfahrungen aus der Didaktik ergeht zudem, dass möglichst viele Sinne angesprochen werden sollen, damit sich der Lerninhalt
vom Lernenden entfremdet (visuell, auditiv, taktil, olfaktorisch, gustatorisch).
„GEIST“ bestätigt dies durch die Verwendung des „Magic Equipment“, welches eher als
Bestandteil der virtuellen Welt als der realen angesehen werden kann. Durch die Binoculars, die jederzeit abgesetzt werden können, wird der visuelle Sinn angesprochen. Das
zur Audiowiedergabe eingesetzte Headset bedient den auditiven Wahrnehmungssinn. Die
Schnittstelle von „GEIST“ baut durch Digital Storytelling eine virtuelle Welt in der realen
auf, ohne dabei eine der beiden zu verlassen. Der Avatar in der Rolle des „menschlichen“
Touristenführers übernimmt durch seine Kenntnisse und seinen Charakter ebenso die Rolle des Lehrenden. Überdies merkt der Anwender nicht, dass er eigentlich eine Datenbank
anspricht, wenn er Informationen im „Magic Book“ abruft.
Interaktion ist notwendig zum Verstehen von Beziehungen und Sachverhalten. Aus
der Kombination von aktiver, investigativer Interaktion und der strukturierten, in eine
Handlung eingebetteten Präsentation von Informationen lässt sich folgern, dass dies nach
den Expertenmeinungen eine wichtige Voraussetzung für das Verstehen der Beziehungen
und Sachverhalte der Geschichte war. Da die Evaluation von „GEIST“ nicht vorliegt, kann
42
dieser Rückschluss allerdings nicht überprüft werden. Die multimodale Schnittstelle soll
dem Anwender aber denselben Freiraum bei seinen Interaktionen überlassen.
3.1.7
Spielbasierte Schnittstellen („Game-Based Interfaces“)
Wie in [Die04] festgestellt, sind die Schnittstellen von Computerspielen immer speziell
auf die Anforderungen ausgerichtet. Vergleicht man sie mit herkömmlichen DesktopApplikationen, die sich in den meisten Fällen nur durch die Anordnung der Steuerelemente, nicht aber durch Interaktionskonzepte unterscheiden, so fallen sie vor allem durch
einfache Funktionalität, angepasste Schwierigkeitsgrade und Hilfestellung leistende Tutorials auf. Als Fazit dessen seien die Spieler durchweg motiviert. Die Idee war nun, die
Vorteile dieser Schnittstellen auf arbeitsaufgabenrelevante Applikationen anzuwenden.
Anzumerken ist, dass es sich bei den nun vorgestellten Beispielapplikationen nicht um
AR-Anwendungen handelt. Die Konzepte geben aber dennoch Ideen für das Design der
multimodalen Schnittstelle.
In der Applikation „ContextControl“ passt sich die Schnittstelle kontinuierlich an den
Erfahrungsgrad des Anwenders an. Um ihn nicht zu irritieren, werden ungenutzte oder
momentan nicht benötigte Inhalte und Funktionen ausgeblendet. Außerdem erlernt der
Anwender die Applikation Stück für Stück, indem ihm notwendige Interaktionen schrittweise erklärt werden.
Bei der Beispielanwendung „Net-Fly“ handelt es sich um ein graphisches Visualisierungssystem zur Anfrage von Suchmaschinen. Jedem Suchresultat wird eine Metapher zugeordnet, um dessen Relevanz und Bedeutung klarzustellen. Außerdem schlägt das System
zusätzliche Stichworte vor, mit denen sich die Suche verfeinern lässt.
Motivation ist einer der Schlüssel zur Benutzerfreundlichkeit. Benutzerfreundlichkeit bedeutet in diesem Zusammenhang, dass der Anwender motiviert wird, das System
3.2. EINGABEGERÄTE
43
und dessen Fähigkeiten kennenzulernen. Allerdings sollen sich schon zu Beginn Lernerfolge einstellen, die nicht nur die Handhabung des Systems betreffen, sondern auch den
eigentlichen Anwendungszweck der Applikation erfüllen. Zur Erfüllung der in [Die04]
genannten Kriterien von Spieleschnittstellen soll die multimodale Schnittstelle neben den
in den Beispielapplikationen erwähnten Techniken vor allem Feedback verwenden. Statt
aber die Benutzeraktionen nur mit Verifizierung oder Falsifizierung zu kommentieren, sollen Alternativen zur Lösung einer Arbeitsaufgabe vorgeschlagen werden. Das bedeutet,
dass Inhalte auf unterschiedliche Art und Weise abgerufen werden können. Beispielsweise
soll der Anwender wählen können, mit welchem Eingabegerät er die Schnittstelle bedienen möchte.
Die Interaktion mit der Schnittstelle soll generell immer simpel sein. Der Anwender soll
nicht darüber nachdenken müssen, wie er eine Aufgabe zu lösen hat. Unter Zuhilfenahme
der Tutorialtechnik soll dem Anwender jede Funktion erklärt werden, die er zum ersten
Mal ansteuert. Die Hilfe soll natürlich auch danach stets zur Verfügung stehen. Darüber
hinaus soll der Modus der Interaktion der Funktion angepasst sein. Einfache Selektionsund Navigationsaufgaben können unimodal bearbeitet werden, komplexere Manipulationsaufgaben könnten durch multimodale Eingabe vereinfacht werden.
3.2
Eingabegeräte
Prinzipiell kann sich eine multimodale Schnittstelle aus vielen Arten von Eingabegeräten
zusammensetzen. Den Vorzug erhalten allerdings natürliche, erkennungsbasierte Modi. So
steht Sprache als erstes Werkzeug bereits fest. Eigentlich sollte die Wahl des alternativen
bzw. ergänzenden Eingabegerätes nach dem Design der Schnittstelle erfolgen, wenn genau
feststeht, welche Ansprüche an die Interaktion die Funktionen stellen. Eine grundsätzliche
Anforderung soll aber sein, dass jedes beliebige Gerät verwendet werden kann, um das
System zu steuern. Ergo wird die Auswahl von der Bedienbarkeit und dem Komfort für
den Anwender anhängig sein.
Im Detail sollen folgende Anforderungen erfüllt werden:
44
• freihändige Bedienung,
• natürliche Handhabung,
• beschränkte Anzahl an Knöpfen und anderen Interaktionsmodalitäten,
• leichtes Gewicht,
• bei mobiler Anwendung Anbringung am Ausgabegerät oder Körper möglich,
• kurze Eingewöhnungszeit.
3.2.1
Gloves
Das Angebot an Handschuheingabegeräten reicht von Pinch Gloves (elektrischer Kontakt
zwischen zwei Fingern) über Data Gloves (Drahtverbindung für jedes positionsgemessene
Gelenk) bis hin zu Cyber Gloves (dünne elektrische Drucksensoren, deren Verformung
Auskunft über die Stellung der Finger geben). Die Hände sind (fast) frei, da die Sensorik in den Handschuh eingebunden ist. Je nach Ausstattung sind die Handschuhe verkabelt
oder kabellos, mit unterschiedlicher Anzahl an Sensoren. Allerdings müsste ein Anwender
sich an das ständige Tragen gewöhnen, was beispielsweise bei warmen Außentemperaturen auf Dauer unangenehm werden könnte. Im Alltag werden Hände zur Gestikulierung
und zu jeder Art taktiler Handlung verwendet. Ein Anwender muss also nicht abstrahieren. Dennoch sind spezifische Gesten zu erlernen, um etwa Objekte zu selektieren und zu
bewegen, die real eigentlich nicht greifbar sind. Eine gewisse Trainingsphase würde also
notwendig sein. Gleichwohl ändert sich an der Art der Eingabe aber wenig nach der Eingewöhnungszeit. Es könnten also stetig neue Gesten erlernt werden, ohne dass die Geräte
viele Interaktionsmodalitäten bereitstellen müssten. Die Schnittstelle selbst, die die Gesten erkennt, definiert die Erweiterbarkeit der Eingaben.
Trotz der Erfüllung nahezu aller Anforderungen kommen Handschuhgeräte derzeit für den
Einsatz nicht in Frage. Zum einen gibt es Zweifel am Komfort, zum anderen müsste der
Anwender Gesten trainieren und dauerhaft erlernen. Es besteht die Frage, ob die Schnittstelle derart viele Funktionen bereitstellen wird. Desweiteren muss die Schnittstelle die
3.2. EINGABEGERÄTE
45
Gesten- bzw. Fingerdruckerkennung selbst implementieren, was im Rahmen dieser Arbeit
zu umfangreich werden könnte.
3.2.2
Touchpads
Touchpads eignen sich gut zur zweidimensionalen Gestenerkennung. Dem Beispiel der
Mausgesten folgend (z.B. integriert in die Webbrowser Opera1 und Firefox2 ) können durch
Fingerkuppenbewegungen auf den Oberflächen der Pads Linienzüge verfolgt werden. Im
Angebot finden sich sogar Pads, die eine Erkennungssoftware mitliefern und einfach angebunden werden können. Außerdem gibt es unabhängige Softwarekits (z.B. StrokeIt3 ),
die im Hintergrund arbeiten und sich als Listener an spezifizierte Deviceports einhaken
(Hook). Die Eingabe erfolgt relativ natürlich und der Eingabewortschatz ist ebenso erweiterbar wie der der Handschuhgesten. Problematisch ist allerdings die freihändige Bedienung. Das kleinste gefundene Pad hat immerhin noch Ausmaße von etwa 12cm in der
Breite. Entweder es muss in der Hand gehalten, oder an einem erreichbaren Teil des Körpers angebracht werden. Es wurde auch an selbstgebaute Pads gedacht, wie etwa ein an
das Handgelenk gebundenes, flexibles Touchpad (z.B. von Synaptics4 ). Dies ist aber zu
aufwendig, da zusätzlich noch Lösungen für Datenübertragungswege, Halterungen etc.
gefunden werden müssten.
Touchpads werden vor allem wegen ihrer Unhandlichkeit momentan nicht an die Schnittstelle gebunden. Sie eignen sich noch nicht für die mobile Verwendung. In puncto Erweiterbarkeit haben sie zwar denselben Vorteil wie die Handschuhgeräte, allerdings lassen
sich keine dreidimensionalen Metaphern ausführen. Ebenso erfordern Gesten eine gewisse, möglicherweise längere Eingewöhnungszeit, die einem Touristen bei seinem Ausstellungsbesuch meist nicht zur Verfügung steht.
1
http://www.opera.com/features/mouse/
http://optimoz.mozdev.org/gestures/
3
http://www.tcbmi.com/strokeit/
4
http://www.synaptics.com/
2
46
3.2.3
Gamepads
Gamepads entsprechen eigentlich nicht den gewünschten Anforderungen. Um sie adäquat
zu bedienen, müssen sie in beiden Händen gehalten werden. Sie liegen zwar ergonomisch
in der Hand, aber der Benutzer muss zwischen Knöpfen und Bedeutung der Interaktion
abstrahieren, ergo handelt es sich nicht um ein natürliches Eingabegerät. Die Vielfalt an
Knöpfen, die wahrscheinlich nicht alle verwendet werden müssen, können den Benutzer
irritieren. Außerdem können Gamepads nur schwierig verstaut werden. Die Eingewöhnungszeit dürfte von der Anzahl verwendeter Knöpfe und deren Kombination abhängig
sein. Jene Kombinationen könnten praktisch auch multimodal, und das an nur einem Gerät, interpretiert werden, wie dies schon in zahlreichen Computerspielen der Fall ist (z.B.
Trigger 1 gedrückt plus Steuerkreuz links vgl. Trigger 2 gedrückt plus Steuerkreuz links
oder Knopf A vor Knopf B vor Knopf C). Dies ist gleichzeitig der größte Vorteil von Gamepads.
Derzeit sind zahlreiche Varianten erhältlich. Sie sind ausgestattet mit kabelloser Verbindung, Force Feedback oder Trägheitssensoren. Jene speziellen Eigenschaften findet man
selten (vor allem kombiniert) an anderen Geräten. Zu Testzwecken wurde deshalb ein
Gamepad mit Trägheitssensoren ausgewählt (siehe Abb. 3.3). Die Sensoren erfassen allerdings nur die Handorientierung. Es kommt wegen seiner Nachteile aber nicht für die
Benutzerevaluation in Frage.
3.2.4
Remote Controls (RC)
Fernbedienungen sind Mausgeräten eigentlich sehr ähnlich. Viele Modelle können Mausaktionen imitieren, mit dem Vorteil und gleichzeitigen Nachteil, dass sie in der Hand gehalten werden können bzw. müssen. Durch eine Art Halfter könnte das Gerät aber am Körper untergebracht werden, während es nicht benutzt wird. Wie Gamepads warten Fernbedienungen mit vielen Interaktionsmodalitäten auf. Natürliche Eingabegeräte sind sie daher
zwar nicht, dennoch kommen sie im Alltag ständig zum Einsatz. Anwender könnten mit
dem Umgang also prinzipiell vertraut sein.
3.2. EINGABEGERÄTE
47
Abbildung 3.3: Microsoft™Sidewinder Freestyle Pro Gamepad.
Es sind einige unterschiedliche Modelle erhältlich. Einige davon sind nicht kabellos und
speziell für die Navigation im Dreidimensionalen ausgerichtet. Sie müssen dafür aber mit
einer eigenen Trackingeinheit ausgestattet werden. Die Wahl fiel daher auf eine mit abschaltbaren Trägheitssensoren ausgestattete, kabellose Fernbedienung, die außerdem über
mausähnliche Tasten verfügt (GyroRemote™, siehe Anhang B). Wie die des Gamepads simulieren die Sensoren lediglich ein (zweidimensionales) Pointing (Simulation des Mauszeigers).
3.2.5
Mäuse und verwandte Geräte
Desktopmäuse sind eigentlich nicht für den mobilen Einsatz gedacht. Sie sind unhandlich
und senden nur bei Bewegungen auf flachem Untergrund zweidimensionale Positionsdaten. Die Interaktion ist stark abstrahiert und auf das WIMP-Konzept abgestimmt. Jedoch
gibt es ein Angebot an weiterentwickelten Geräten, die entweder in Form einer hardwareergonomischen RC mausgleiche Funktionen bieten oder handfreundlicher und mit Trägheitssensoren ausgestattet sind. Die Sensoren erfassen nur zweidimensionale Koordinaten
zum Pointing auf der Bildschirmoberfläche. Darüber hinaus gibt es minimal kleine Laptopmäuse, die ohne dritte Maustaste und Scrollrad auskommen. Sie sind komplett greifbar
und lassen sich notfalls in der Hosentasche verstauen. Sie könnten sich etwa gut für Kin-
48
derhände eignen. Ein in Anhang B aufgeführtes Modell wurde für diese Benutzergruppe
ausgewählt, in der Evaluation aber nicht eingesetzt.
Aufgrund beschränkter Interaktionsmodalitäten, 2D-Tracking, seiner Handlichkeit und eventueller gewohnter Akzeptanz unter den Benutzern kommt die kabellose Gyration UltraGT
Maus als alternatives Eingabegerät in Betracht. Desweiteren wird eine herkömmliche Desktop-Maus zu Testzwecken dienen.
3.2.6
Kombinationen von Ein- und Ausgabegeräten
Das als Ausgabegerät verwendete video-see-through Binocular besitzt zwei Tasten zur Interaktion auf der Oberseite. Sie können aber aufgrund fehlender Treiber nicht als Eingabe
verwendet werden. Eine Programmierung des seriellen Ports, zu dem die Tasten ihre Signale senden, erscheint im Rahmen dieser Arbeit zu aufwendig. Kommende Prototypen
sollten sich verstärkt auf die Kombination von Ein- und Ausgabegerät konzentrieren.
3.2. EINGABEGERÄTE
49
Alle evaluierten Eingabegeräte sind in Anhang B mit Beschreibung, Vor- und Nachteilen
aufgeführt.
50
Kapitel 4
Design der Benutzerschnittstelle
In den folgenden Abschnitten wird anhand der Erkenntnisse des State-of-the-Art-Kapitels
(s. Kap. 3) ein Konzept für die multimodale Benutzerschnittstelle erstellt. Ein Katalog von
Anforderungen und zu beweisenden Hypothesen führt zu gezielten Anwendungsfällen in
der Kommunikation mit dem Touristenführer. Anhand eines hieraus erstellten Anwendungsszenarios werden verschiedenste Konzepte zur Umsetzung der Richtlinien erstellt.
Schließlich wird eine komplexe Systemarchitektur gebildet, die sich in der Implementation
eines initialen Prototypen widerspiegelt.
4.1
Hypothesen
Fehlende Richtlinien, Normen und anerkannte Styleguides erfordern die Erstellung eines
eigenen Maßnahmenkatalogs unter Berücksichtigung von Evaluationen und Erfahrungen
von und mit aktuellen Benutzerschnittstellen im Bereich Augmented Reality. Zusätzlich
können allgemeine Erfahrungen aus der Mensch-Maschine-Kommunikation miteinbezogen werden. Allerdings würde ein eigens erstellter Styleguide weitreichendere Bedeutung für zukünftige Entwicklungen haben, der die Meinung anderer Kompetenzgebiete
berücksichtigen sollte. Aus diesem Grunde wurde anhand der vorherigen Untersuchungen ein Katalog von Hypothesen aufgestellt, die es mit der Konzeption und Realisierung
der Benutzerschnittstelle zu bestätigen gilt. Die Evaluation anhand von Benutzertests wird
51
52
KAPITEL 4. DESIGN DER BENUTZERSCHNITTSTELLE
schließlich zeigen, inwiefern die Vermutungen korrekt waren.
Als allgemeine Richtlinie werden die „Grundsätze der Dialoggestaltung“ [fN95] des Europäischen Komitees für Normung verwendet, die zum Ziel haben, den generellen Anspruch
an die Mensch-Maschine-Interaktion zu definieren. Die Hypothesen sind durch die Einsortierung in die Grundsätze gegliedert. Darüber hinaus hat das Komitee noch weitere Normen verabschiedet, auf die im Rahmen dieser Arbeit allerdings nicht näher eingegangen
werden kann. Hervorzuheben ist allerdings die Richtlinie zur „Benutzerführung“ [fN98b],
unter welche nicht unter [fN95] kategorisierbare Hypothesen generell gelistet sind. Im
Speziellen dienen Oviatt’s „Mythen multimodaler Interaktion“ und andere Feststellungen
[Ovi02] als Orientierung für die Vermutungen zu multimodaler Interaktion. Schließlich
werden die wichtigsten Unterschiede von GUI und MUI (nach [Ovi02]) vorgestellt. Allgemeines Grundwissen zur Softwareergonomie vermittelt [EOea94]. In [MS95] finden
sich empirisch evaluierte Gestaltungsgrundsätze für zweidimensionale graphische Benutzerschnittstellen. Hilfestellung zu der Gestaltung von dreidimensionalen Benutzerschnittstellen gibt [BKLP04]. Wie später gesehen werden kann, kommt jedoch nur ein Bruchteil
der aufgeführten Empfehlungen für die Schnittstelle in Frage.
4.1.1
Aufgabenangemessenheit
„Ein Dialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seine
Arbeitsaufgabe effektiv und effizient zu erledigen.“
Transparenz oder Unsichtbarkeit von Steuerelementen erleichtern die Sicht, wenn
jene nicht in Gebrauch sind.
Angesichts des eingeschränkten Sichtfelds und aktueller Auflösungen von HMD und Binoculars steht nur wenig Platz zur Anzeige von Steuerelementen zur Verfügung. Um den
Blick auf die reale Welt und somit auch auf das augmentierte Objekt nicht zu blockieren,
sollten die Interaktionselemente versteckt werden oder zumindest transparent sein können.
[SGBT00] schlugen bereits Alternativen vor, um das Blickfeld zu vergrößern.
4.1. HYPOTHESEN
53
Nur für die aktuelle Benutzeraufgabe bestimmte Steuerelemente sind sichtbar.
Diese Hypothese leitet sich aus der Evaluation in [Kaa03] ab. Passen allgemein verfügbare Sprachkommandos, Steuerelemente und andere visuelle Objekte nicht in den momentanen Kontext, können sie auch nicht verwendet werden und nehmen notwendigen Platz
ein. Vielmehr muss der Benutzer aus einer Mehrzahl die relevanten Kontrollen erkennen.
Im Gegenzug vermeidet eine Einschränkung der sichtbaren Elemente auch, dass sich der
Benutzer an deren Funktionalität gleichzeitig erinnern muss. Jede Aktion zeigt dann eine
auf den Kontext passende Wirkung. Für die Sprachsteuerung bedeutet es zudem eine Einschränkung des zu erkennenden Vokabulars, wenn nur die kontextabhängigen Kommandos
verfügbar sind.
Multimodale Interaktion, insbesondere mit „natürlichen“ Eingabemethoden, benötigt wenig Gewöhnung an die Eingabegeräte und der Benutzer kann sich auf seine
Aufgabe konzentrieren.
Sprache ist eine „natürliche“ Eingabemethode und muss nicht mehr erlernt werden. Lediglich das Vokabular muss man sich einprägen. Diese Prozedur fällt allerdings weg, wenn
Kommandos auch sichtbar sind. Die Ansteuerung erfolgt also unmittelbar. Darüber hinaus
sollen die Ansteuerungskommandos mit nicht-natürlichen Modi beschränkt bleiben.
Keine Eingabemethode wird verwendet, um eine andere zu aktivieren.
Wenn man sagt, dass der Benutzer sich auf seine Aufgabe konzentrieren soll, kann man
daraus schließen, dass seine Interaktionen sich unmittelbar auf den Abruf gewünschter
Informationen beschränken. Daraus ergibt sich, dass man ein Eingabegerät nicht zur Modifikation der Interaktion selbst verwendet, auch deshalb, um die Anzahl der Schritte von
Aufgabenstellung bis zur Lösung zu reduzieren.
54
Durch eingesetzte Kombination von Ein- und Ausgabegeräten konzentriert sich der
Fokus des Benutzers auf die Information anstatt auf deren Handhabung.
Ständiges Wechseln des Fokus zwischen Ein- und Ausgabegeräten und Ausstellungsstück
führt zu einem „Gefühl der Isolation“ („sense of isolation“[Hsi02]).
Weder wird der Zugang zu Informationen unnötig blockiert, noch wird zuviel an
Information präsentiert.
Einerseits sollte ein Benutzer stets über zugängliche Information und Interaktionsmöglichkeiten informiert sein, andererseits sollte nicht zuviel an Information angezeigt werden,
um nicht die Übersicht zu verlieren. Diese Erkenntnis ergibt sich aus den Untersuchungen
in [CDMF00].
Der Freiheitsgrad der Interaktionen ist zur Handhabung der Schnittstelle ausreichend.
Ein mobiler, elektronischer Touristenführer hat den Anspruch, dass der Tourist im dreidimensionalen Raum navigieren und agieren kann. Die Interaktion mit dreidimensionalen
augmentierten Objekten kann eine Erhöhung des Freiheitsgrades und somit komplexere
Metaphern bedeuten. Das Ziel soll allerdings sein, die Komplexität der Metaphern mit natürlicher multimodaler Eingabe bei gleichzeitig hohem Freiheitsgrad gering zu halten. Die
Funktionalität soll dadurch nicht beeinträchtigt werden.
So ist etwa die aus WIMP bekannte Pointing-Metapher ungeeignet für den dreidimensionalen Raum [SGBT00], wenn deren Eingabegeräte nicht getrackt werden. Sprache ist
allerdings omnidirektional und könnte deswegen diesen Gegensatz aufheben.
4.1. HYPOTHESEN
55
Das visuelle Design und die Anordnung der Elemente des graphischen Teils der
Schnittstelle behindern nicht die Sicht auf die Ausstellungsstücke.
Graphische Steuer- und Informationselemente dienen lediglich der Interaktion mit der
Augmented Reality und sollen daher nicht im dauerhaften Fokus des Benutzers stehen.
Der begrenzte Blickwinkel eines HMD schränkt die Sicht weiter ein. Die Anzahl der graphischen, nicht objektbezogenen Elemente sollte daher minimal sein [SGBT00].
4.1.2
Selbstbeschreibungsfähigkeit
„Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt
durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem
Benutzer auf Anfrage erklärt wird.“
Kurze Kommandos und Kommandophrasen sind einprägsam.
Der Dialog zwischen Mensch und Computer basiert im Wesentlichen auf einer Reaktion
des Systems nach einer Aktion des Benutzers. Diese Interaktion kann von einem kurzen
Mausklick bis zu einer im Dialog vorgetragenen vollständigen Satzstruktur reichen. Die
Vermutung ist allerdings, dass komplexere Eingabestrukturen, beispielsweise die Filterung
von Stichwörtern aus einem Satz, auch höheren Lernaufwand und Überlegung während
der Benutzung zur Folge haben. Die Sprachsteuerung soll daher über kurze Kommandos
oder Kommandophrasen erfolgen.
4.1.3
Steuerbarkeit
„Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf
zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das
Ziel erreicht ist.“
56
Durch konsistente Navigation in der Benutzerschnittstelle gelangt der Benutzer zu
jeder vorhandenen Information.
[Kaa03] schlägt zur idealen Navigation die Unterbringung von Elementen und Diensten
vor, mit der die Benutzergruppe „vertraut“ ist, da ansonsten die Erwartungshaltung an die
Aufgabe des Elements von der gedachten variieren kann.
Durch Positionierung aller „notwendigen Informationen für eine gegebene Aufgabe in einer einzigen Ansicht“ [Kaa03] kann der Benutzer die Schnittstelle in einem
einzigen Arbeitsschritt manipulieren.
Kann ein Benutzer alle Informationen durch „direkte Manipulation“ [fN99] abrufen, so ist
eine Navigation durch verzweigte, nicht offensichtliche Menüstrukturen nicht erforderlich.
Ebenso bleibt der Fokus auf einer Ansicht und wechselt nicht, wenn sich die Information
verändert. Eine evaluierte Regel lautet, dass „soviel Funktionalität wie möglich in sowenig
wie möglichen Menüstrukturen“ („interaction range“) [Kaa03] untergebracht sein soll.
Die Verwendung von Sprache als Eingabemodalität schadet nicht der Kommunikation mit Unbeteiligten in der Umgebung.
In einem Museum ist ein Besucher selten allein. Vielmehr ist er umgeben von anderen Besuchern, die wiederum untereinander oder mit einem Museumsführer einen Dialog führen.
An dieser Stelle muss man Mensch-Mensch- und Mensch-Maschine-Interaktion voneinander trennen [BKLP04], um die Kommunikation beider Dialogpartner nicht zu stören.
Die Benutzerschnittstelle muss folglich erkennen können, wann Informationen für sie bestimmt sind und wann nicht.
Ein eingeschränktes Vokabular hilft, sich an notwendige Kommandos gut zu erinnern und sie schnell auszuführen.
Wenn Shneiderman sagt, dass „der Teil des menschlichen Gehirns, der für Sprechen und
Zuhören verwendet wird, derselbe ist, der für das Lösen von Problemen zuständig ist“ [Shn00],
4.1. HYPOTHESEN
57
dann bedeutet dies für die Spracheingabe, dass sie nur dort verwendet werden soll, wo sie
die Interaktion wirklich erleichtert, und nicht innerhalb des gesamten Aktionsradius. Lässt
man die Aufgabe von Sprache zur Problemlösung außen vor, bleibt ein eingeschränktes
Vokabular, das eher der Navigation dient als der Manipulation von Objekten.
Kombiniert man Sprache allerdings mit einem weiteren Eingabegerät führt dies zu folgender These.
Durch die Kombination von Sprache und alternativem Eingabegerät lassen sich komplexe Interaktionsaufgaben durchführen.
Erst die Kombination zweier paralleler Eingabedatenströme hilft, ein Eingabekommando
eindeutig von anderen zu unterscheiden [BKLP04]. Die von [Bol80] eingeführte „PutThat-There“-Technik ermöglichte erstmals multimodale Eingabe zur Ausführung eines
einzelnen Kommandos. Einerseits muss sich der Benutzer an die Kombination zweier
Kommandos zu einer Aktion erinnern, andererseits erhöht dies aber die Vielfalt an Interaktionen, ohne sie misszuverstehen.
In den folgenden Designschritten wird allerdings festgestellt werden müssen, ob diese
erweiterte Interaktionsvielfalt überhaupt notwendig ist.
Nicht nur die Eingabegeräte, sondern auch die Interaktionsmetaphern der Benutzerschnittstelle bestimmen die Qualität ihrer Funktionalität. Die Eingabegeräte entsprechen den Anforderungen der Schnittstelle.
Die Auswahl der Eingabegeräte und -modalitäten wurde nach der Analyse gängiger ARSchnittstellen und aktueller Eingabegeräte anhand des Anwendungsgebiets und der Benutzergruppe getroffen. Der Vorteil der Multimodalität ist die Flexibilität in der Handhabung
verschiedenster Geräte. Demnach handelt es sich bei der Erstkonfiguration um einen ersten Gehversuch, dem sich weitere Geräte anschließen können. Ausgeschlossen werden
soll der umgekehrte Fall, dass die Funktionalität eines Eingabegerätes die Gestaltung der
Oberfläche bestimmt. Wie sich nach Intracom’s Erfahrungen herausstellte, überfordern
58
Ausstellungsbesucher zu viele Optionen am Gerät.
Die Schnittstelle ist zu jeder Zeit verfügbar.
Dem Besucher sollte es jederzeit möglich sein, den Touristenführer zu deaktivieren, beispielsweise um die Ausstellung aus vollkommen realer Perspektive zu erkunden. Das System sollte aber in der Lage sein, dessen Status immer zu kennen, um bei Reaktivierung
relevante Informationen anzeigen zu können. Untersuchungen haben gezeigt, dass Touristen „spontanen und gelegentlichen“ Bedarf an der Benutzung haben [Kaa03].
4.1.4
Erwartungskonformität
„Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.B. den Kenntnissen aus dem Arbeitsgebiet, der
Ausbildung und der Erfahrung des Benutzers sowie den allgemein anerkannten Konventionen.“
Der Dialog ist konsistent und der Erwartungshaltung eines Besuchers einer bestimmten Stätte oder eines Museums entsprechend gestaltet.
Wenn die Akzeptanz des Systems in der relevanten Benutzergruppe erreicht werden soll,
muss die Applikation in der Lage sein, die Ansprüche von Touristen an einen Museumsbesuch zu erfüllen. Zumindest muss sie dieselben Informationen liefern können wie ein
menschlicher Touristenführer. Diskussionen und Analysen in Zusammenarbeit mit Museologen und Pädagogen scheinen notwendig. Im Rahmen dieser Arbeit bleibt dieses
Wissen aber auf Intracom’s Erfahrungen mit den Projekten Archeoguide und intCulture
beschränkt.
4.1. HYPOTHESEN
4.1.5
59
Fehlertoleranz
„Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz
erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem
Korrekturaufwand durch den Benutzer erreicht werden kann.“
Vorschläge zur Lösung einer Aufgabe sind hilfreicher als die Korrektur von Eingaben.
Der Anwender soll durch den Vorschlag von Interaktionsschritten und anleitendem Feedback die Handhabung des Systems erlernen, ohne dass er aufgefordert wird, seine bisherigen Aktionen zu korrigieren. „Fehler“ sollen hierdurch präventiv vermieden werden. Jede
Korrektur einer Eingabe kostet zusätzliche Schritte bis zur Aufgabenlösung.
4.1.6
Individualisierbarkeit
„Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an
die Erfordernisse der Arbeitsaufgabe, individuelle Vorlieben des Benutzers
und Benutzerfähigkeiten zulässt.“
Eine multimodale Schnittstelle fördert die Verwendung von alternativen Ansteuerungen für ein und dieselbe Aktion.
Ist nur eine einzige Eingabemodalität vorhanden, ist der Benutzer gezwungen, sich deren Handhabung anzueignen. Zwar könnte man auch argumentieren, dass es eigentlich die
Aufgabe der Schnittstelle ist, eine intuitive und einfache Eingabemöglichkeit zu finden
und die Interaktionsmetapher so zu gestalten, dass sie selbst komplexe Aufgaben simpel
lösen kann, allerdings mag dies den Anspruch an die Gestaltung immens erhöhen. Infolgedessen orientiert sich das Design an [Die04] und fordert einen stufenweisen Ausbau der
Flexibilität der Schnittstelle, basierend auf dem Erfahrungswert des Benutzers.
60
Darüber hinaus steht neben der Kombination der Eingabedatenströme ihre separate Verwendung zur Verfügung. Dem Benutzer wird es frei überlassen, welches Eingabegerät er
als das komfortableste und geeignetste empfindet. Erfahrungen haben allerdings gezeigt,
dass Besucher nur begrenzt bereit sind, einen Touristenführer zu individualisieren. Insbesondere sollte es nicht ihre Aufgabe sein, ein einziges Eingabegerät wählen zu müssen.
Die Wahl sollte also nicht statisch zu Beginn, sondern dynamisch während der Benutzung
geschehen, ohne dass dazu die Änderung eines Profils notwendig wäre.
Freie Individualisierbarkeit ist für den Benutzer eines Touristenführers nicht relevant.
Die Zeit eines Besuchers für die Besichtigung einer Ausstellung ist begrenzt. Der Anspruch lautet also bekanntlich maximale Information in minimaler Zeit zu liefern. Individualisierung und Profilierung benötigt den Fokus des Benutzers außerhalb der eigentlichen Verwendung der Benutzerschnittstelle. Außerdem wird davon ausgegangen, dass
eine gewisse Gewöhnungszeit notwendig ist, bis der Benutzer die Oberfläche eigenständig anpassen kann, wozu die Kenntnis der Elemente notwendig wäre. Diese Vermutung
steht ganz im Gegensatz zu den Personalisierungseigenschaften des intCulture-Konzepts,
welches vorkonfigurierte Gestaltungsprofile für gewisse Benutzergruppen bereithält und
dem Benutzer die individuelle Konfiguration abnimmt. Diese Form der Adaption an Benutzerpräferenzen ist eher geeignet.
[KSH02], [CDMF00] und [ZSB02] zeigen detaillierte Erfahrungen im Bereich der Individualisierung von Schnittstellen.
Die Positionierung der visuellen Elemente in einer einzigen Perspektive ist geeignet
zur Ansteuerung der Schnittstelle. Frei positionierbare Elemente sind nicht notwendig.
[MS95] schlägt zwei Konzepte zur Gestaltung einer visuellen Oberfläche vor. „Modulbasiertes Design“ ermöglicht die flexible Kombination und Anordnung von Komponenten.
Sie können separat und unabhängig voneinander aktiviert und positioniert werden. „Alles-
4.1. HYPOTHESEN
61
in-einem“ basiertes Design stellt dagegen nur eine einzige Perspektive mit fester Anordnung bereit. Letztere Methode ist in diesem Kontext die geeignetste, da, wie vorher schon
festgestellt wurde, der Benutzer nicht darüber nachdenken sollte, welche Komponente er
als nächstes benötigt. Eine Mischung beider Vorschläge ließe eine automatische Auswahl
notwendiger Komponenten durch das System zu. Hinsichtlich der Erwartungskonformität
müssen Position, Erscheinung und Verhalten dann allerdings konsistent bleiben.
4.1.7
Lernförderlichkeit
„Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet.“
Die Verknüpfung von sichtbarem Steuerelement und Sprachkommando ist sinnvoll,
um den Dialog zu erlernen.
Wenn der Benutzer nur die Elemente aktivieren kann, die er unmittelbar vor sich sieht,
ohne sich an ein Kommando erinnern zu müssen, so ist die Annahme, dass er den Dialog
mit dem Touristenführer leicht erlernen kann und sie schließlich intuitiv verwendet. Im
Gegenzug bedeutet dies, dass Aktionen, die nicht durch Sprache ausgelöst werden sollen,
von dem anderen Eingabegerät übernommen werden müssten. Dies setzt dann wiederum
eine zusätzliche Interaktionsmetapher voraus.
Nicht nur das Dialogsystem, sondern auch die bereitgestellten Informationen lassen
sich leicht erlernen.
Neben der intuitiven Handhabung der Schnittstelle soll der Tourist auch die Informationen zu den Ausstellungsstücken des Museums lernen können. Ein Benutzer lernt am effizientesten durch Erkundung, Beobachtung, Untersuchung und Kritik [Hsi02] [Aeb85].
Demgegenüber stehen die Erkenntnisse früherer Beobachtungen im Rahmen von intCulture und ARGuide, dass ein Besucher nur begrenzt aktiv in die Präsentation von Inhalten
eingreifen möchte und sich stattdessen das System um relevante Informationen kümmern
sollte. Ein Benutzer sollte nicht zu sehr mit Eigeninitiative konfrontiert werden [Kaa03].
62
4.1.8
Benutzerführung
Die Signalisierung von Interaktionen durch „Audio Cues“ [SGBT00], Text und farblich hervorgehobene Steuerelemente unterstützt die Erwartungshaltung an die Schnittstelle und die erfolgreiche Navigation zur gesuchten Information.
Jede Aktion sollte mit Feedback des Systems beantwortet werden, um Erwartungskonformität und Steuerbarkeit zu gewährleisten. [BKLP04] bezeichnet dieses Verhalten als
„Frage-und-Antwort Mechanismus“.
Kontinuierliches, unmittelbares und auf den Kontext zugeschnittenes Feedback ist
nicht störend, sondern unterstützt die Handhabung der Benutzerschnittstelle auf
dem Weg zur gesuchten Information.
Das Prinzip besteht darin, den Benutzer schon während der Eingabe von Daten über eventuelle Folgen seiner Eingabe zu informieren und nicht die Daten erst nach Abschluss der
Aktion zu validieren. Sowohl Mensch als auch Maschine können so vorzeitig in die Interaktion eingreifen, um „korrekte“ Resultate zu erhalten.
Das Verhältnis von „Fokus“ und „Kontext“ [BM02] ist ausgeglichen. Die Aufnahme momentan fokussierter Information wird nicht durch die umgebene kontextuelle
Information beeinträchtigt.
Laut Definition ist der „Fokus“ derjenige „Teil der Information, welcher für den Benutzer
im Moment am wichtigsten ist. Er sollte in der höchsten Detailstufe angezeigt werden.“
Die für den Touristen wichtigsten Informationen erscheinen die Inhalte, die sich unmittelbar mit dem betrachteten Objekt befassen. Dagegen ist der „Kontext“ „der Rest der
Information, welcher präsentiert werden könnte, sich aber momentan nicht im Fokus des
Benutzers befindet. Alle Inhalte sollten in geringster Detailstufe angezeigt werden.“ Alle
Navigationssteuerelemente und Statusinformationen sind essenziell für den Weg zur Information, aber die Informationsaufnahme selbst konzentriert sich am Objekt.
4.1. HYPOTHESEN
63
Durch die Aufteilung der sichtbaren Elemente der Schnittstelle in „world-stabilized
and screen-stabilized items“ [HFT+ 99] lassen sich objektbezogene und kontextbezogene Informationen eindeutig unterscheiden.
Die Informationen, die der Touristenführer bereitstellt, lassen sich in kontextbezogene
Status- und Navigationsdaten sowie in objektbezogene Fakten aufteilen. Erstere sind hinsichtlich ihrer Position und Größe fest im sichtbaren Bereich integriert und lassen sich nur
begrenzt manipulieren, letztere werden zusammen mit dem Objekt, auf welches sie sich
beziehen, getrackt und augmentiert.
4.1.9
Multimodale Interaktion
Die folgenden Hypothesen entstanden teils aus eigenen, aus Erfahrungen abgeleiteten Ansprüchen an das System und teils aus den umfangreichen Recherchen und Feststellungen
in [Ovi02].
Die Kombination von natürlichen, erkennungsbasierten Eingabemodi und nicht auf
Mixed Reality spezialisierten Modi verringert die Komplexität der Interaktion bei
gleichzeitiger Erhöhung der Freiheitsgrade.
Es wird erwünscht, dass sich ein Anwender nicht zeitaufwendig an ein Eingabegerät gewöhnen muss, um die Schnittstelle zu bedienen. Ebenso wird davon ausgegangen, dass
das Angebot an manipulativen Interaktionen in einem elektronischen Touristenführer derart beschränkt ist, dass avanciertere Geräte wie etwa Spacemäuse, Flying Joysticks oder
Datenhandschuhe nicht notwendig sind. Das Ziel soll vielmehr darin bestehen, die Eingabe
mit „einfachen“ Geräten, also ohne große Anzahl von Knöpfen o.ä., so effektiv zu gestalten, dass sie die gleichen Resultate hervorbringen wie Geräte mit automatisch erhöhtem
Freiheitsgrad.
64
Mittels kurzen Kommandos und Phrasen anstatt eines Dialogs kann Sprache für
mehrere Zwecke als für temporale oder nicht-räumliche Informationsangaben angewandt werden.
Wie [Ovi02] festgestellt hat, eignet sich Sprache außerordentlich für die Eingabe temporaler und nicht-räumlicher Informationen, und zwar besonders dann, wenn die Angaben im
gesprochenen Dialog gemacht werden. Ein Anwender sollte dagegen aber nicht die Syntax
lernen, in welcher der Dialog gesprochen werden müsste, um das gewünschte Resultat zu
erhalten. Da komplexe Informationsangaben nicht notwendig, sondern automatisch abhängig vom Kontext des Anwenders bestimmt werden sollen, sollen sich die Spracheingaben
auf kurze Kommandos und Phrasen beschränken und trotzdem gleiche Ergebnisse erzielen.
Die Multimodalität verstärkt das Immersionsgefühl.
Es wird behauptet, dass ein Anwender sich umso fremder in der Umgebung fühlt, desto mehr Konditionen ihn dazu zwingen, von der Schnittstelle und der sichtbaren Umgebung zu abstrahieren. Ungewohnte Geräte und komplexe Eingaben können dazu beitragen.
Sprache ist hingegen ein alltäglicher, gewohnter Modus und soll dank seiner Natürlichkeit diese Barriere aufheben. Die ausgesuchten ergänzenden Eingabegeräte sind allerdings
nicht natürlich und nicht erkennungsbasiert. Eine gewisse Abstraktion wird wohl notwendig werden. Nichtsdestotrotz soll deren multimodale Kombination das Immersionsgefühl
verstärken.
„Blended multimodal interfaces“ [Ovi02] unterstützen permanentes Feedback durch
den Guide.
Mindestens der passive Datenstrom wird analysiert, wenn ein Benutzer keine aktive Dateneingabe leistet. Ein Feedback kann folglich immer gewährleistet werden.
4.1. HYPOTHESEN
65
Multimodale Interaktion bedeutet nicht notwendigerweise, dass der Benutzer zwei
oder mehrere Eingabemodi gleichzeitig zur Ausführung einer Interaktion benutzen
wird, obwohl die Möglichkeit stets zur Verfügung steht. Vielmehr mag sich ein Besucher nach einer Weile für einen Modus entscheiden, oder zumindest neigt er zur
Verwendung eines bestimmten Eingabegerätes. Dennoch tendieren Benutzer eher zu
multimodaler als unimodaler Interaktion (nach [Ovi02]).
Diese Behauptung wurde evaluiert und soll in den Benutzertests bestätigt werden. In einem Museum ist es normalerweise sehr ruhig, wenn sich Besucher dessen Ausstellungsstücke anschauen. Sprache könnte befremdend wirken, wenn der Dialog mit einem nichtmenschlichen Kommunikationspartner stattfindet. Maus und Remote Control könnten zu
abstrakt für den Anwender sein. Wenn die Schnittstelle auch unimodal angesteuert werden
kann, könnte also die Tendenz zu einem bestimmten Gerät gehen. Wenn aber multimodale
Eingaben möglich sind, so ist die Vermutung, dass deren Komfort das Benutzerverhalten
wieder umkehrt.
Nicht unbedingt jedes Kommando wird weiterverarbeitet (nach [Ovi02]).
In parallelen Eingabeströmen findet sich eine Fülle an Informationen, die analysiert und
interpretiert werden müssen. Gelegentlich passt die Information aber nicht in den aktuellen
Kontext und wird verworfen oder es ist inhaltlich zuviel und wird eigentlich nicht für eine
korrekte Antwort des Systems benötigt.
Multimodale Steuerbefehle werden häufig während der Modifikation und Manipulation von Information verwendet sowie bei der Auswahl aus einer großen Datenmenge
(nach [Ovi02]).
Wenn die gesuchte Information schwierig zu umschreiben ist, z.B. räumliche Angaben im
Sprachmodus, erleichtern multimodale Befehle die Beschreibung dieser Aktion.
66
Aufgrund des „blended multimodal interface“ werden Benutzer nicht äußern, dass
sie multimodal interagieren, auch wenn passive Eingabedaten nicht unmittelbar mit
aktiven verarbeitet werden (nach [Ovi02]).
Bisher steht es noch offen, ob multimodale Befehlskombinationen überhaupt zum Einsatz
kommen werden. Dies wird von der Komplexität der Interaktion abhängig sein. Die Anwender würden dann also eher unimodal interagieren. Dennoch wird mit dem passiven
Datenstrom eine zweite parallele Eingabeform zur Verfügung gestellt, die mit Sprache
multimodal kombiniert werden kann, aber nicht muss. Der Anwender soll dessen Verarbeitung aber nicht bemerken.
Die bereitgestellten aktiven Eingabemodi werden nicht simultan verwendet. Darüber
hinaus müssen sie nicht simultan betätigt werden, um korrekt verarbeitet werden zu
können (nach [Ovi02]).
Simultanität bedeutet parallele Verwendung der aktiven Eingabemodi während der unmittelbaren Befehlseingabe, nicht zu verwechseln mit deren gleichzeitiger Verwendung
innerhalb der Benutzungszeit. Vermutet wird, dass simultane Anwendung kognitiv zu belastend ist. Stattdessen werden die Eingaben in sequentieller Reihenfolge im Sinne der
„Put-That-There“-Metapher erfolgen.
Alle Eingabekommandos sind nicht zweideutig (nach [Ovi02]).
Zweideutig werden Befehle dann, wenn ihre Interpretation vom Anwender in einen anderen Kontext als den passenden eingeordnet wird.
Bei korrekter multimodaler Verarbeitung werden Benutzer weniger Sprachkommandos verwenden, dafür aber zusammen mit dem zweiten aktiven Eingabemodus (nach
[Ovi02]).
Das Prinzip ist, dass die Kombination aus mehreren Modi die Verwendung eines einzelnen
reduziert, weil sich die Befehle gegenseitig ergänzen.
4.1. HYPOTHESEN
67
In einem multimodalen System interagieren die Benutzer nicht immer multimodal,
sondern auch unimodal mit gelegentlichem und spontanen Wechsel des Eingabemodus (nach [Ovi02]).
Wenn es die Interaktion nicht erfordert, müssen multimodale Befehle nicht unbedingt zum
Einsatz kommen. Wenn auch unimodale Befehle eingegeben werden können, so ist die
Vermutung, dass Anwender diese auch, abwechselnd mit unterschiedlichen Geräten, verwenden.
Sprache ist nicht die primäre Eingabemethode (nach [Ovi02]).
Es existieren Behauptungen, dass Sprache aufgrund ihrer Natürlichkeit und Einfachheit die
bevorzugte Eingabemethode in multimodalen Systemen ist. Dies gelte sowohl für die Designentscheidung als auch für die Präferenzen eines Anwenders. Der Anwendungszweck
entscheidet aber schließlich, ob Sprache die qualifizierteste Methode ist.
Die multimodale Verflechtung von Eingabedatenströmen ersetzt keineswegs deren
unimodale Verwendung. Die Inhalte sind nicht redundant (nach [Ovi02]).
Effektiv wird gleichzeitige multimodale und unimodale Ansteuerung erst dann, wenn deren Befehle sich nicht gegenseitig aufheben und das Befehlsvokabular damit erweitert
wird.
Die multimodalen Befehle sind einheitlich und verständlich (nach [Ovi02]).
Eigentlich wird behauptet, dass multimodale Befehle nicht immer einheitlich und verständlich sein können. Das Design der Schnittstelle soll diesen Anspruch aber einhalten
können, um dem Benutzer ein klareres Bild der Interaktionsmöglichkeiten zu liefern.
68
Die verschiedenen Eingabemodi senden unterschiedlichen, nicht unmittelbar vergleichbaren Content (nach [Ovi02]).
Aufgrund ihrer Beschaffenheit können erkennungsbasierte Eingaben wie Sprache, Gesten
oder Mimik nicht immer eindeutig sein. Ebenso sind sie nicht direkt vergleichbar, sondern
benötigen zuerst eine Interpretation und ein Mapping auf eine gemeinsame Semantikebene. Die Aufgabe der Schnittstelle ist es demnach, die Gemeinsamkeiten herauszufinden.
Der Vorteil einer multimodalen Schnittstelle besteht nicht in der Performanz der
Verarbeitung, sondern in der intuitiveren Handhabung und Benutzerfreundlichkeit
(nach [Ovi02]).
Mehrere Datenströme erfordern zwangsweise aufwendigere Verarbeitung als Einzelereignisse. Jedoch kann das Ergebnis der Verarbeitung diesen Nachteil wieder aufheben, wenn
sich dadurch komplexere Aktionen einfacher umschreiben lassen.
Multimodale Befehle dienen am meisten der Manipulation, insbesondere der von
augmentierten Objekten (analog zu [Ovi02]).
Einfache Aktionen wie etwa das Verstecken visueller Elemente können durch simple Befehle ausgedrückt werden. Komplexere wie etwa die Rotation eines Objektes um eine
bestimmte Gradzahl oder das Messen der Entfernung zwischen zwei Ausstellungsstücken
benötigen umfangreichere Beschreibungen.
Die Maussteuerung kann die Sprachsteuerung ersetzen.
Nach [Ovi02] sollen sich die Eingabemodi in einem multimodalen System ergänzen. Redundante Befehle sollen möglichst nicht existieren. Um aber dem Anwender zu überlassen,
wie er mit der Schnittstelle interagieren möchte, sollen sowohl unimodale als auch multimodale Eingaben unabhängig voneinander die gleiche Ansteuerung ermöglichen. Demnach müssen Maus und RC dieselbe Funktionalität wie Sprache bieten können. Folglich
4.1. HYPOTHESEN
69
sollen sich die Eingaben bei unimodaler Ansteuerung ersetzen und bei multimodaler komplettieren.
Kurze Eingabekommandos erhöhen die Performanz linguistischer Verarbeitung und
verringern die kognitive Belastung des Benutzers (nach [Ovi02]).
Kurze Sprachkommandos und Dialoge können das gleiche Vokabular besitzen. Die Spracherkennung muss aber unterschiedlichen Aufwand leisten, um korrekte Eingaben zu finden. Ebenso muss der Anwender den Dialog konstruieren und dort Wörter des Vokabulars
unterbringen, was seine kognitive Belastung erhöhen könnte.
Die Schnittstelle ist „generell, robust und skalierbar.“ (nach [Ovi02])
Die meist gewünschten Eigenschaften einer multimodalen Schnittstelle sind Generalisierbarkeit, Robustheit und Skalierbarkeit. Dynamischer Kontext und die zahlreichen Informationen in erkennungsbasierten Eingabedatenströmen erfordern ein komplexes Interpretationssystem im Hintergrund, das die Daten syntaktisch zerstückelt und semantisch wieder
zusammensetzt. Ziel dieser Arbeit ist es, diese drei Ansprüche einhalten zu können. Dies
ist außerdem wünschenswert für das Konzept von intCulture bzw. intGuide.
4.1.10
Graphical User Interface (GUI) vs Multimodal User Interface
(MUI)
[Ovi02] unterscheidet eindeutig zwischen einer graphischen und einer multimodalen Benutzerschnittstelle. Wie aber in der Aufgabenstellung zu dieser Arbeit festgehalten wurde,
soll der multimodale Ansatz den graphischen nicht vollständig ersetzen. Vielmehr sollen
sie sich ergänzen und beider Vorteile ausnutzen. Im Folgenden sind die bedeutendsten Unterschiede (nach [Ovi02]) aufgelistet und werden später anhand des Prototypen untersucht:
• Einzelner Ereignisdatenstrom (GUI) vs. kontinuierlicher, simultaner Eingabe von
parallel ankommenden Strömen (MUI)
70
• Atomare, eindeutige Ereignisse (GUI) vs. erkennungsbasierte Ereignisse mit wahrscheinlichkeitstheoretischen Methoden der Verarbeitung und wechselseitiger Begriffsklärung (MUI)
• Statische singuläre Implementierung (GUI) vs. vernetzte Erkennung und Interpretation des Kontext (MUI)
• Farb- und Helligkeitsfeedback (GUI) vs. Text-To-Speech, Non-Speech Audio, Graphik und Animation (Multimedia) (MUI)
4.2
Ziel des initialen Prototypen
Der Prototyp soll den Anspruch erfüllen, möglichst viel an Information über ein einzelnes
Ausstellungsstück präsentieren zu können. Erfahrungen zufolge bestehen die Hauptinteressen eine Besuchers darin, zu erfahren, wo er sich befindet, was er an seiner aktuellen
Position sehen kann und was er dort unternehmen kann.
Das Konzept wird sowohl Ideen zur Interaktion als auch zur Präsentation der Schnittstelle enthalten. Vorrangig ist die Interaktionskomponente. Wenn das System aber am Benutzer getestet werden soll, ist die Darstellung von Resultaten der Interaktion zwingend
erforderlich. Die Implementation wird sich dennoch zuerst mehr auf Funktionalität und
Umsetzung der Konzepte als auf visuelle Korrektheit konzentrieren.
4.3
Anwendungsfälle
Unter Beachtung der in Kapitel 3 vorgestellten Richtlinien und der daraus hervorgehenden Hypothesen wurden verschiedene Anwendungsfälle skizziert, die auf mögliche Benutzeraktionen und Ansprüche eines Besuchers - beobachtet von [Hsi02] - passen. Jene
Interaktionsbedürfnisse bestehen aus Erkunden, Nachfragen nach Informationen, Dokumentieren und Erinnern, Empfehlen und Führen lassen, Erklären lassen, Nachforschen
sowie Kontrollieren. In adäquate Aktionen umgewandelt entstehen Anwendungsfälle für
4.3. ANWENDUNGSFÄLLE
71
Einführung vorspielen lassen, Frage an den Guide stellen, Objekt auswählen, Navigationsinformation erhalten, Erklärungen erhalten, Unterbrechen und Wiederaufnehmen, sowie Information überspringen. Vereinzelt wurden aus dem Projekt Archeoguide [VIK+ 02]
bekannte Anwendungsfälle eingebaut, die in den Diagrammen in Anhang C blau gekennzeichnet sind.
Dem erwünschten Ziel des Prototypen folgend wird nicht die gesamte Museumssite betrachtet, sondern ein einzelnes Ausstellungsstück. Dies wird definiert als „Area of Interest“
(AOI). Jedes AOI kann mehrere „Points of Interest“ (POI) besitzen, welche markante Bestandteile dessen, wie etwa die Metope eines Tempels oder das Gesicht einer Statue, sein
können. Im weiteren Sinne kann ein AOI auch ein größeres Areal innerhalb der Site sein,
das mehrere andere Standorte mit POI beinhaltet. Relevante Aktionen an diesen Punkten
zeigen die Diagramme in Abb. C.3 und C.4.
Um ein weitsichtigeres Gesamtkonzept zu schaffen, behandeln die Anwendungsfälle ein
AOI als größeres Areal mit mehreren AOI und POI als untergeordneten Objekten. Wenn
ein Anwender nun das Areal erkunden möchte, so soll er Fragen an den Guide stellen und
Navigationsinformationen erhalten können (siehe Abb. C.5). Nahezu alle Aktionen haben
gemeinsam, dass der Guide ein Repository nach gewünschter Information abfragt.
Gezieltes Nachfragen nach Informationen kann vielfältige Arten von Daten liefern (siehe
Abb. C.6). Der Anwender soll nach vorgegebenen Themen wie etwa Architektur, Athletik, Zeitgeschichte oder Kulturelles relevante Medien präsentiert bekommen. Er soll spezifische Informationen rund um seinen Standort, Wegweisungen zu anderen AOI, lokale
Informationen zu einem POI des AOI und detailliertere Medien über das aktuelle AOI
abrufen können. Festgelegte, AOI und POI identifizierende Navigationspunkte in den UIMenüs, die mittels 2D-Interaktion per Maus/RC und/oder per Sprachkommando angesteuert werden, dienen der Dialogsteuerung zu den gewünschten Daten. Um dem Benutzer die
Kontrolle über den Präsentationsablauf zu überlassen, kann er den Vorgang jederzeit unterbrechen, wiederaufnehmen oder komplett überspringen.
Um einem Besucher eine nachhaltige Erinnerung an den Museumsbesuch zu verschaf-
72
fen, kann er für jedes beliebige AOI oder POI ein Bookmark setzen sowie es selbst kommentieren oder kommentieren lassen. Es sollen Möglichkeiten zur Aufnahme von Sprachkommentaren und Schnappschüssen zur Verfügung stehen. Darüber hinaus werden seine
Aktionen im Groben festgehalten, so dass er etwa verfolgen kann, welchen Weg er innerhalb des Areals gegangen ist. Das Diagramm in Abb. C.7 zeigt den Vorgang im Detail.
Einige der wichtigsten Ansprüche an einen Touristenführer sind selbstverständlich das
Empfehlen von Höhepunkten des Museums und Wegbeschreibungen zu deren Standorten
sowie Vorschläge zu den interessantesten Informationen hierzu (siehe Abb. C.8). Ein Besucher soll dem demnach sowohl Einführungen als auch detaillierte Daten präsentiert bekommen. Konkrete Interaktionsmöglichkeiten und navigative Hilfen unterstützen ihn bei
diesem Vorgang, der eng mit denen des Erkundens und Untersuchens verbunden ist.
Manche Lösungsansätze zu den Benutzerbedürfnissen sind sich sehr ähnlich. Ausstellungsstücke zu erklären bedeutet demnach auch, dem Anwender passende Informationen
in Form von themenbezogenen, einführenden und detaillierteren Medien sowie standortsensitiven Daten zu präsentieren (siehe Abb. C.9). Letztere können entweder Textstücke,
Sprachkommentare, Videos oder Bilder (statisch oder Overlays) sein. Jedes Medium soll
hervorgehobene Schlüsselwörter enthalten, die bei Aussprache zu neuer Information weiterführen (für Sprache etwa gesondert betonte Wörter, in Videos und Bildern speziell markierte Bereiche). Wenn ein Anwender nachforscht, so beinhaltet dies auch Erklärungen.
Ein interessanter didaktischer Aspekt ist das selbstständige Erkunden des Museumsgebiets. Der Besucher forscht eigenständig nach für ihn relevanten Informationen ohne Vorschläge des Guides zu beachten. Er wechselt von der passiven, informationskonsumierenden zur aktiven, informationsrecherchierenden Rolle. Dies bedeutet umgekehrt aber
nicht, dass Passivität keine didaktische Bedeutung hat [Aeb85]. Der Guide übernimmt
dann lediglich die Aufgabe, automatisch relevante Information zu präsentieren. Schließlich scheint wohl der Inhalt der Medien selbst verantwortlich für den Lerneffekt. Der Besucher begibt sich also selbstständig zu AOI und POI (evtl. ohne Navigationsinformation
und nach Auflistung vorhandener Standorte), wählt aus einer Ausstellungsstückliste des
Areals enthaltene Objekte aus und erhält wiederum passende Medien. Diese können ent-
4.4. ANWENDERSZENARIEN
73
weder in einem eigenen Showcase oder in Form von Overlays gezeigt werden.
Kinder sollen die Ausstellung spielerisch durch die Lösung von Quests (vgl. [AGS04])
erforschen können. Den Ablauf der Interaktion zeigt das Diagramm in Abb. C.10.
Eigentlich sollte der Guide selbst alle notwendigen Einstellungen vornehmen, damit sich
der Anwender in der Umgebung und mit dem System wohlfühlt. Dennoch können eventuell nicht alle Vorlieben im Voraus bestimmt werden. Beispielsweise wünscht der Benutzer,
Kontrast und Helligkeit zu ändern oder die Lautstärke des Headsets zu regeln. Zur Kontrolle des Systems gehört darüber hinaus die schon angesprochene Möglichkeit, Präsentationen jederzeit zu unterbrechen, wiederaufzunehmen und zu überspringen. Diagramm
C.11 zeigt entsprechende Anwendungsfälle.
4.4
Anwenderszenarien
Anhand der Anwendungsfälle wurden Anwenderszenarien für drei potenzielle Besuchertypen beschrieben: Erwachsene, Kinder und hörgeschädigte Erwachsene. Im Betrieb wird
jeder Benutzertyp natürlich wieder unterschieden werden müssen. Die Vielfalt an Benutzervorlieben und -kenntnissen ist schlichtweg zu groß. Das Konzept von intGuide sieht
aber Personalisierungsmethoden vor, um den Anwender einordnen und ihm ein möglichst
passendes System anbieten zu können.
Die Benutzertypen wurden bewusst zur Beschreibung der Szenarien ausgewählt. Kinder
sollen das System auf spielerische Art und Weise kennenlernen und handhaben können.
Der Guide soll sie Schritt für Schritt einweisen. Quests sollen (vgl. [AGS04]) eingebaut
werden, die die Informationen nach Lösung von Rätseln und durch das Finden von AOI
oder POI präsentiert. Zusammen mit anderen Kindern sollen kombinatorische Aufgaben
zu lösen sein. In Form von „visuellen Belohnungen“, die die Motivation aufrecht erhalten sollen, können die Kinder Punkte sammeln und sich somit untereinander vergleichen.
Inwieweit dies ein Indiz für den Lernerfolg der Informationen ist, müsste anderweitig analysiert werden.
74
Körperlich beeinträchtigte Besucher sollen die gleichen Informationen und den gleichen
Bedienkomfort haben können wie unbeeinträchtigte. Der Hauptunterschied ist der Medientyp, der zur Erklärung verwendet wird. Aber auch die Ansteuerung muss adaptierbar
sein. Sprachgeschädigte Besucher könnten Spracheingabe nicht verwenden, Sehgeschädigte könnten die visuellen Informationen nicht sehen und körperlich beeinträchtigte Besucher könnten Handgeräte wie Maus / RC / Gamepad nicht bedienen.
Das Szenario des Erwachsenen bildet die Grundlage für ein detaillierteres Systemdesign.
Es ist im folgenden ausführlich wiedergegeben, die übrigen Szenariobeschreibungen finden sich in Anhang D:
Ein englischsprachiger Tourist besucht das antike Olympia in Griechenland. Er betritt
die Eingangshalle und fragt nach verfügbaren Museumsführungen. Ein Museumsassistent stattet ihn mit einem elektronischen Führungssystem aus, welches aus einem HeadMounted-Display mit einem angebrachten einseitig funktionalen Headset, einem Rucksack mit einem leichtgewichtigen Laptop mit integriertem GPS-Sensor und elektronischem Kompass, und einer kabellosen Computermaus mit Trägheitssensoren besteht. Während das System auf dem Laptop nach Sprache und Alter des Besuchers konfiguriert wird,
wird der HMD auf seinem Kopf justiert.
Der Besucher betritt das Museumsareal und beginnt herumzuwandern, um mehr über die
Ausstellung und ihre Exponate herauszufinden. Im Display des HMD erscheint eine kleine, zweidimensionale Karte, welche eine Teilansicht der gesamten Ausstellung darstellt.
Er sieht seine eigene Position auf dieser Karte als einen deutlich hervorgehobenen Punkt.
Andere Punkte auf der Karte zeigen ihm die Lage interessanter, in der Nähe befindlicher
Exponate. Er wählt den nächstliegenden Punkt aus und erhält die zugehörige Kurzbeschreibungsliste aller Exponate, die sich thematisch auf jenes beziehen. Danach markiert
er einen schematisch angezeigten Tempel durch Aussprache des Wortes „Temple“ in das
Mikrophon. Dessen exakter Standort wird auf der Karte hervorgehoben und ein Pfeil im
Display zeigt die Richtung an, in welche der Besucher gehen muss.
Als er den Ruinen näher kommt, weist ihn eine Audioerzählung in die Charakteristika
des Gebietes ein. Er unterbricht den Audiokommentar, weil er das Gebiet selbst erkun-
4.4. ANWENDERSZENARIEN
75
den möchte. Als er unmittelbar vor dem Tempel steht und das gesamte Gebäude in seinem Display sehen kann, werden die Ruinen mit einem virtuellen Bild überlagert, das
die Grundstruktur des Gebäudes einschließt. Da er keine Kamera mit sich hat, aber gerne eine digitale Erinnerung behalten möchte, selektiert er die Ikone „Bookmark“, welche
permanent im Seitenbalkenmenü zu finden ist. Die Aktion löst einen Schnappschuss aus,
der im Repository gespeichert wird und nach dem Besuch abholt werden kann, z.B. durch
Zugriff auf die Museumswebseite mit einem Codewort, das nach dem Besuch ausgehändigt wird. Zeitstempel, Datum und Standort werden festgehalten. Zusätzlich spricht er
einen Audiokommentar in das Mikrophon. In der Zwischenzeit erscheint ein Menü, dass
ihm verschiedene Medien vorschlägt, durch welche er zusätzliche Informationen über den
Tempel erhalten kann. Dem Menüeintrag „Animation“, den er durch Drücken und Halten
eines Mausknopfes ausgewählt hat, folgt eine Animation, die die Erscheinung des Tempels in Anlehnung an die Zeitgeschichte des Tempels im Laufe der Jahrhunderte zeigt.
Die Beschreibung der angezeigten Epoche wird in der Statusbar im unteren Bereich des
Displays angezeigt. Um mehr Informationen über die markantesten Teile des Tempels zu
erhalten, wählt er eine Beschriftung auf dem überlagerten Bild aus, das sich nahe bei dem
bezeichnenden Detail im Bild befindet. Wieder erscheint eine zusätzliche Liste mit verfügbaren Medien, die sich auf die Schlüsselwörter in der Erzählung beziehen. Durch Scrollen
des Mausrades und Klicken eines Knopfes navigiert er zu einem „Showcase“, in welchem
ein kurzer Videoclip abläuft, der den Hintergrund des Interessenspunktes beschreibt.
Als ein Freund von ihm ein Gespräch beginnt, schaltet er das Mikrophon stumm und versteckt die sichtbare Schnittstelle. Später holt er sie wieder hervor und fährt mit seiner
Erkundung fort.
Es besteht nun die Frage, inwieweit eine multimodale Schnittstelle die im Szenario aufgeführten Aktionen und mit ihnen einhergehende Schwierigkeiten lösen kann. Zuallererst
erkennt man, dass der Besucher in den meisten Fällen eindeutig unimodal interagiert, also
nur mit einem Eingabegerät. Prinzipiell soll es möglich sein, dass jede Aktion alternativ
mit einem der verfügbaren Modi ausgeführt werden kann, wenn ihre Komplexität keinen
multimodalen Datenstrom erfordert. Solche Daten erscheinen dann besonders notwendig,
wenn zur exakten Spezifikation der gesuchten Information verschiedene Datentypen benötigt werden. [Ovi02] zufolge ist jeder Eingabemodus nur für die Eingabe bestimmter Da-
76
tentypen geeignet. Sprache etwa sei geeignet für zeitliche und nicht-räumliche Angaben,
während ein Wand oder einfacher digitaler Stift Ortsangaben gut deuten kann. Der Typus
der Aktion ist genauso entscheidend. So erscheint es einfacher, durch Scrollen des Mausrades zu einem UI-Tool zu gelangen als mit einem Sprachbefehl im Sinne von „Nächstes
Tool“. Die Vorlieben des Anwenders werden dies schließlich entscheiden.
Wenn der Besucher nun etwa einen Punkt auf der Navigationskarte selektieren will und
dieser der nächstgelegene sein soll, oder er alle Exponate in einem bestimmten Umkreis
auswählen möchte, oder er gar eine Tour selbst planen möchte und dazu interessante Punkte miteinander verbindet, um die Route festzulegen, so sind möglicherweise mehrere unterschiedliche, hintereinander abfolgende Aktionen notwendig. Multimodale Befehle erfordern zwar auch diesen Ablauf, sind sich syntaktisch aber näher. Im Sinne von Bolt’s
„Put-That-There“-Metapher [Bol80] erfolgen die Aktionen „in einem Fluss“, also unmittelbar hintereinander folgend, ohne das Ergebnis einer Aktion abzuwarten. Durch die engere Kombination soll die Formulierung des Befehls natürlicher und intuitiver wirken. Die
Verwendung erkennungsbasierter Eingabemodi wie Sprache, Gestik, Mimik, Körperbewegungen etc. unterstützt den kontinuierlichen Datenfluss, einhergehende kontinuierliche
Verarbeitung und die Natürlichkeit der Interaktion.
Die Multimodalität kann auch in dem Sinne verstanden werden, dass ein Anwender jederzeit ein Eingabegerät wechseln kann, ohne dass das System beeinflusst wird. Es wurde
nach anderen möglichen alternativen Eingabemethoden als Sprache und Maus / RC / Gamepad recherchiert, doch kann in Richtung Hardwareergonomie im Rahmen dieser Arbeit
leider nicht evaluiert werden. Die Auswahl an Geräten bleibt beschränkt und der Benutzer
muss das Gerät mit dem für ihn besten Komfort wählen. Jede Funktion der Schnittstelle
soll dann auch mit jedem Gerät ansteuerbar sein.
Das Szenario kann natürlich noch weiter verfeinert werden. Etwa könnte das Showcase
dreidimensionale Objekte anzeigen, die sich rotieren, skalieren und animieren lassen. Die
gleichen Manipulationen könnten auch mit dem Overlay geschehen. Je nach Aufwand
können multimodale Befehlskombinationen die Interaktionsschritte verkürzen und vereinfachen.
4.5. KONZEPTE
77
In den nächsten Designphasen wird klar werden, inwieweit multimodale Interaktion einsetzbar sein wird und muss. Primär wird das System auf unimodale Befehlseingaben ausgelegt sein und sekundär auf multimodale. Dennoch soll das Design so generalisiert sein,
dass die Sekundärziele jederzeit umsetzbar sind, wenn das Szenario es erfordert.
4.5
Konzepte
Die im Szenario beschriebenen Anforderungen werden im Folgenden in generelle Konzepte umgesetzt. Sie werden strikt in Interaktions-, Präsentations- und - gesondert - multimodale Interaktionskonzepte unterschieden.
4.5.1
Multimodale Ereignisverarbeitung
Die Bedeutung eines „blended multimodal user interface“ ist im Szenario nicht genau wiedergegeben, da der passive Eingabedatenstrom keine bewusste Handlung des Benutzers
darstellt, sondern vom System registriert und verarbeitet wird. Nach Definition [Ovi02]
sollen aktive und passive Datenströme zusammen die Eingabe für den multimodalen Interpreter bilden, ganz so wie beliebig viele aktive. Da nach Szenario primär unimodale
Eingaben erfolgen, kann der passive Datenstrom auch getrennt behandelt werden. Wie die
Daten verwendet werden können, wird sich später zeigen.
Nun stehen dem System drei Arten von Eingabedaten zur Verfügung: der konstante Textfluss von Sprache, statische Einzelereignisse von Maus, RC und Gamepad und die zweidimensionalen Positionsinformationen derer Trägheitssensoren. Die Spracherkennung liefert zusätzlich den Lautstärkelevel der Sprecherstimme. In einem korrekt arbeitenden multimodalen System müssen alle Ereignisdaten, die parallel oder sequentiell innerhalb eines
vordefinierten Zeitrahmens eingehen, mittels einer Grammatik interpretiert werden. Da
in den Hypothesen behauptet wird, dass simultane Eingaben nicht erforderlich sind, wird
78
eine Lösung zur sequentiellen Verarbeitung vorgestellt. Der Ansatz ist nach [Ovi02] als
„frame-based integration“ definiert. Eine skizzenhafte Umsetzung findet sich in [PBT02],
wonach die Daten nach syntaktischem Parsing in einem Puffer zwischengespeichert und
nach Ablauf eines Zeitfensters zusammen semantisch interpretiert werden. Ein ähnliches
Prinzip soll für den Prototyp angewandt werden (siehe Abb. 4.1). Die Ereignisse werden
auf Relevanz gefiltert, zwischengespeichert und nach vorgegebenem Timeout als gesamtes
Ereignistupel mit der Syntax der dem Ereignismanagement bekannten Tupel verglichen.
Nach Verifizierung wird das Tupel semantisch in eine Systemnachricht zur Auslösung einer Reaktion übersetzt.
Vorausgesehen, dass parallele Eingabedatenströme einen hohen Erkennungs- und Verar-
Abbildung 4.1: Multimodale Ereignisverarbeitung
beitungsaufwand benötigen und das System für verteilte Berechnungen nur bedingt netzwerkfähig ist (z.B. ist das Informationsrepository ausgelagert), wird an dieser Stelle keine
Lösung hierfür vorgestellt (siehe [YYDW99] für ein derartiges Konzept).
4.5.2
Aktive und passive Interaktionskonzepte
Entgegen multimodalen Konzepten, nach welchen der gesamte Datenstrom als Eingabe
gesehen und nach einer gegebenen Grammatik analysiert wird, reagiert das System auf
schon durch das Gerät selbst gefilterte und somit statische Einzelereignisse, wie sie in
gängigen GUI-Toolkits implementiert sind. Jene gehen aber davon aus, dass der Benutzer
4.5. KONZEPTE
79
mit visuellen Steuerelementen interagiert. Die Benutzeraktion resultiert in einer Reaktion
des Systems nach aktiver Interaktion mit der Control. In multimodalen Systemen wird das
Ereignis aber schon am Eingabegerät abgefangen.
Interaktionsmanagement
Wenn der Interaktionsablauf grob in Eingabe, Verarbeitung und Ausgabe (EVA) unterteilt
wird, so setzen sich diese zusammen aus Anbindung, Handhabung und Ereignisüberwachung der Eingabegeräte zur Eingabe (E), Verarbeitung der Ereignisse (V) und Ausgabe
als systemrelevante Information (A). Alle Komponentengruppen (wie etwa Geräte, Ereignisse etc.) werden von eigenständigen Managern initialisiert und beobachtet. Daten einer
Gruppe laufen immer über den zugehörigen Manager, der sie entsprechend weiterleitet.
Neben einem Gerätemanager, der im übrigen auch Ausgabe- und Lokalisierungsgeräte
verwaltet, übernimmt der Ereignismanager die für die Interaktion bedeutendste Rolle. Er
empfängt die Rohereignisdaten eines Gerätes, vergleicht das Ereignis mit vordefinierten,
akzeptierbaren Einträgen und sendet eine für die übrigen Systemkomponenten verständliche Antwort an alle interessierten Empfänger.
Biometrisches Feedback
Feedback als Antwort des Systems auf die Ereignisinterpretation wird dem Benutzer auf
verschiedenen Wahrnehmungskanälen, wie etwa Audiokommentare für das Hören sowie
Farb- und Helligkeitsfeedback und Textfeedback für das Sehen, geliefert. Unter Verwendung des passiven Datenstroms der Trägheitssensoren und des Mikrophons kann dem Benutzer sogar konstant Hilfestellung gegeben werden. Der Typ dieses Feedbacks wird als
„Biofeedback“ definiert. Mit Hilfe der Trägheitssensoren können die Handbewegungen
des Anwenders verfolgt und analysiert werden. Die Bewegungen werden in horizontaler
(X-Koordinate) und vertikaler Richtung (Y-Koordinate) über einen vorgegebenen Zeitraum gemessen. Die Differenzen zwischen den Messwerten gleicher Richtung werden
aufsummiert. Nach Ablauf des Zeitfensters wird das Ergebnis mit einem Schwellwert verglichen. Wenn der Wert überschritten wird, wird dies als Nervosität oder Ungeduldigkeit
des Anwenders gewertet. Man stelle sich etwa die Situation vor, dass das System nicht
80
nach seinen Erwartungen funktioniert und er das Eingabegerät aus Frust schüttelt. Eine
passende Reaktion wird für horizontale Bewegungen wie folgt ermittelt (vertikale analog):
xAxisDistance = currentXP
osition − lastXP osition




currentXP osition ,wenn xAxisDistance >
lastXP osition =
minDistT reshold



lastXP osition
sonst
sumOf AllXAxisDistances = sumOf AllXAxisDistances + lastXP osition
reaction ⇔ sumOf AllAxisDistances < minM oveT reshold
∨
sumOf AllAxisDistances > maxM oveT reshold
Das gleiche Messprinzip wird für die Knöpfe eines Gerätes angewandt. Die Anzahl der
gedrückten Knöpfe wird über einen Zeitraum aufgezeichnet und schließlich mit einem
Schwellwert abgeglichen („nervous buttons“). Eine vorzustellende Situation ist hier, dass
der Anwender wahllos und schnell die Knöpfe bedient, weil er nicht zufrieden mit den
Reaktionen des Systems ist. Als passiver Datenstrom wird auch der stetig wechselnde
Lautstärkelevel der Anwenderstimme registriert. Vorausgesetzt, die Umgebungslautstärke
beeinflusst die Sensitivität des Mikrophons nicht, gibt der über einen Zeitraum gemessene,
durchschnittliche Pegel Auskunft über das Stimmvolumen („shout level“). Wiederum ein
Schwellwert wird über die Verwertung für entsprechendes Feedback entscheiden, sei es eine zu leise oder gar stumme Stimme, die auf Passivität oder Fraglosigkeit des Anwenders
hinweist, oder eine zu laute Stimme, deren Ursache eventuell eine nicht reagierende Spracherkennung ist und die andere Museumsbesucher stören könnte. Das durchschnittliche
Stimmvolumen wird wie folgt ermittelt:
shoutV alue = shoutV alue + currentShoutLevel
shoutRatio = shoutV alue/shoutCount
reaction ⇔ shoutRatio > shoutLevelT reshold
81
4.5. KONZEPTE
Natürlich sind diese Ideen nur Vermutungen, die psychologisch ausgewertet werden müssten.
Räumliches Audiofeedback
Laufbewegungen des Besuchers werden mittels GPS-Sensor, Kopfbewegungen mittels
elektronischem Kompass aufgezeichnet. Die Daten lassen sich neben Navigationsaufgaben für räumlich sensitives Feedback in Form von raumwirkenden Tönen verwenden. Das
Repository verfügt über eine skizzenhafte Navigationskarte N mit der Ausdehnung (x, y)
des Ausstellungsgeländes, auf der alle AOI und POI mit ihren Koordinaten verzeichnet
sind. Seien nun zwei verschiedene Areale AOI1 mit Mittelpunkt M1 (x1 , y1 ) und Radius
r1 sowie AOI2 mit Mittelpunkt M2 (x2 , y2 ) und Radius r2 gegeben. Ein Besucher V (x, y),
der sich außerhalb dieser Bezirke aufhält, hat eine Distanz d1 zu AOI1 und eine Distanz
d2 zu AOI2 , die sich ergeben aus:
d1 = ||M1 − V ||
d2 = ||M2 − V ||
Nimmt man das Maximum max einer Richtungsausdehnung von N , dann ergeben sich
die Lautstärken l1 für den Raumton von AOI1 und l2 für den Raumton von AOI2 aus den
normalisierten Distanzen d1 und d2 :
d1
max
d2
=
max
l1 =
l2
Sind der Norden des Museumsplans und der 0te bzw. 360te Grad des Kompass aufeinander ausgerichtet, so liefert der Kompass zusätzlich den Winkel zwischen dem vom Benutzer ausgehenden Vektor Richtung Norden und dem Distanzvektor zum AOI. Anhand der
Gradzahl g lässt sich feststellen, ob sich das Gebiet vor oder hinter und links oder rechts
von der Besucherposition befindet. Die Abschnitte A mit l für links von V , r für rechts
82
von V , f für vor V und b für im Rücken von V sind definiert als:
Arf ⇔ 0 ≤ g ≤ 90
Arb ⇔ 90 ≤ g ≤ 180
Alb ⇔ 180 ≤ g ≤ 270
Alf ⇔ 270 ≤ g ≤ 360
Die Identifizierung des Gebietes im Winkelbereich ist aber nur dann unbedingt notwendig, wenn ein zweiseitiges Headset verwendet wird, damit entschieden werden kann, auf
welcher Seite der Ton abgespielt wird. Andernfalls sollte für die Gebiete, die sich auf der
jeweils gegenüberliegenden Seite des angesprochenen Ohrs befinden, eine Dämpfungskonstante dampconst ∈ ]0, 1[ die Lautstärke des Tons verringern, so dass sich ergibt:
volume = l1∨2 ∗ dampconst
Abbildung 4.2: Räumliches Feedback außerhalb der AOI.
Abbildung 4.3: Räumliches Feedback innerhalb eines AOI.
Das Rendern von dreidimensionalen Klängen ist eigentlich weitaus komplexer. Weiterführende Konzepte sind etwa in [BM02] zu finden.
Sprache als Eingabegerät
Ein Ziel dieser Arbeit ist es, die Arten der Eingabegeräte auf das Konzept der Schnittstelle
abzustimmen anstatt zu evaluieren, wie mit vorgegebenen Geräten ein flexibles System
4.5. KONZEPTE
83
erstellt werden kann. Die Vorgabe lag dennoch auf der Verwendung von einer erkennungsbasierten, natürlichen Eingabemethode und eines ergänzenden, abstrakteren Gerätes. Sprache erschien die am einfachsten zu „erlernende“ (nur die Verwendung, nicht die
Anwendung) und am wenigsten „fremde“ Variante, da für Gesten oder Mimik neue Metaphern erlernt werden müssen. Außerdem können sie nicht freihändig eingesetzt werden,
sondern benötigen avanciertere Erkennungsmethoden, wie Pinch Gloves, Touchpad oder
eine Kamera, die das Gesicht des Anwenders fokussiert. Überdies scheint Mimik nicht
trivial erkenn- und interpretierbar. Sprache wird darüber hinaus im Alltag oft zur Dialogsteuerung zwischen Gesprächspartnern eingesetzt. Sprachliche Dialoginhalte sind sowohl
für den Anwender als auch für das System „leicht“ zu erlernen. Der Anwender wird das
verfügbare Vokabular im visuellen Teil der Schnittstelle zu sehen bekommen und kann es
somit direkt aussprechen. Das System wiederum nimmt die sichtbare Repräsentation in
sein eigenes Vokabular auf.
Maus und Remote Control als Eingabegeräte
In der Annahme, dass ein Besucher mit minimalen Interaktionsmöglichkeiten am Gerät
maximale Aktionen mit der Schnittstelle durchführen kann und ihm der Modus in gewisser Art und Weise bekannt ist, wurden Maus und Remote Control (RC) als potenzielle,
Sprache ergänzende Geräte ausgewählt. Aufgrund ihrer Ähnlichkeit kann man auch ähnliche Interaktionskonzepte aufstellen und diese später evaluieren, so dass die Tester im
Praxiseinsatz herausfinden können, welches das am ehesten geeignete ist. Allen ist die
Verwendung von Knöpfen bzw. Tasten als „Handler“ und ein integrierter Trägheitssensor
gemeinsam. Sie unterscheiden sich in Form, Handgefühl und Anzahl der Knöpfe. Andere
Vor- und Nachteile finden sich in Kapitel 3.2 und Anhang B.
Grammatikbildung für die Spracherkennung
Wie schon angesprochen basiert die Sprachverständigung auf einem festgelegten Vokabular. Ein Dialogsystem mit vollständigen Sätzen, die natürlicher Sprachkommunikation
wohl am nächsten kommen, wird für den Prototypen erst einmal nicht zum Einsatz kommen. Stattdessen verhalten sich kurze Kommandos und Phrasen wie Ereignisse, die von
84
RC und Maus gesendet werden. Die Spracherkennung und das Eventmanagement sind
aber so dynamisch, dass sie beliebig viele, unterschiedliche Vokabeln - auch während des
Gebrauchs - aufnehmen und verarbeiten können. Das Vokabular oder auch die Grammatik
wird anhand vorgegebener Regeln kontinuierlich neu generiert, wenn neue Wörter hinzugefügt werden.
Nach dem Konzept der Microsoft® SAPI (s. Kap. 2.1.5) bilden die Regeln zusammen
ein Zustandsübergangsdiagramm mit den Wörtern als bedingende Ereignisse, versehen
mit Übergangswahrscheinlichkeiten. Die Wahrscheinlichkeiten entscheiden, welche Wortzusammensetzungen eher als erkannte Phrase geliefert werden sollen. Dem Sprachmodul können nun einleitende Kommandowörter („Show“, „Hide“, etc.), Kommandophrasen
(„Show guide“), Einzelwortkommandos („Play“) und Schlüsselwörter („Temple of Zeus“)
für die Grammatik übergeben werden. Schlüsselwörter können sich auch aus mehreren
Einzelwörtern zusammensetzen, sie sind aber als Ganzes die Bedingung für einen Zustandsübergang, während Kommandophrasen sich aus einleitendem Kommandowort und
Schlüsselwort oder schließendem Kommandowort zusammensetzen. Die Grammatik bildet so auch Wortkombinationen, die eigentlich nicht direkt übergeben wurden („Show
Temple of Zeus“). Unerwünscht generierte Kombinationen werden dann spätestens durch
das Eventmanagement abgefangen. Die Regeln sind im Folgenden in EBNF skizziert:
Rule ::= CommandP hrase | SingleCommand | Keyword
CommandP hrase ::= P reCommand W ord
P reCommand ::= W ord
SingleCommand ::= W ord
Keyword ::= W ord [„ „] {W ord}
W ord ::= Char {Char}
Char ::= „a„| . . . |„z„
4.5. KONZEPTE
85
Dynamisches Vokabular
Das Management allerdings kann ein Schlüsselwort nicht eigenständig interpretieren, denn
dessen Bedeutung ist abhängig vom Kontext. Daher muss es kategorisiert werden (z.B.
„Independent Keyword“) und die Kategorie wird stattdessen als Filter eingesetzt. Bei Bekanntmachung eines Wortes als potenzielles Ereignis wird es vom Management mit der
Kategorie assoziiert. Die Idee zum dynamischen Vokabular ist in Anlehnung an [Die04]
entstanden, wonach der Besucher das System Schritt für Schritt erlernen soll, während er
die Ausstellung erkundet. Je mehr er an Exponaten und Arealen gesehen hat, desto größer wird das Vokabular. Der Besucher soll Informationen zu bereits besuchten Exponaten
jederzeit wieder durch Aussprache des entsprechenden Schlüsselwortes, also der Bezeichnung des Ausstellungsstücks, abrufen können. Wenn die Lokalisierungskomponente einen
neuen Standort meldet, werden relevante Schlüsselwörter, die Aktionen auslösen können,
aufgenommen. Ebenso sind nur solche graphischen Menüelemente per Sprache ansteuerbar, die auch gleichzeitig sichtbar sind. Das vermeidet zum einen, dass der Besucher sich
an Kommandos erinnern muss, zum anderen, dass die Schnittstelle auf nicht verwertbare
Ereignisse reagiert, die momentan nicht in den Kontext passen. Schlüsselwörter, die gerade nicht verwendbar sind, aber schon zuvor angezeigt und erlernt wurden, werden bei
Bedarf in einer Informationstafel thematisch sortiert angezeigt.
Benutzerführung
Ein sprecherabhängiges Spracherkennungssystem ist für die korrekte Entdeckung grammatikalisch korrekter Ausdrücke verantwortlich. Es liest den vom Mikrophon kommenden
Datenstrom und schlägt ein oder mehrere „Hypothesen“ vor. „Hypothesen“ sind mögliche
Bedeutungen eines erkannten Wortes, gewichtet mit einer Wahrscheinlichkeit. Die „Hypothese“ mit der höchsten Wahrscheinlichkeit wird als final erkanntes Wort genommen, wenn
die Wahrscheinlichkeit einen gewissen Schwellwert überschreitet, also eindeutig ist. Nun
muss einer Hypothese aber nicht notwendigerweise eine verifizierte Erkennung folgen.
Dann greift das Konzept der Schnittstelle, nämlich die höchstwahrscheinlichste Hypothese in den aktuellen Kontext einzuordnen. Wenn das Schlüsselwort passt, wird versucht,
die entsprechende Aktion auszulösen, allerdings erst nach Bestätigung des vermeintlichen
86
Kommandos durch den Benutzer. Am effizientesten arbeitet ein sprecherabhängiges System natürlich, wenn jeder Anwender sein eigenes Sprachprofil abgelegt hat.
Wie man sieht, sind die Konzepte von sehr unterschiedlicher Natur. Ebenso lässt sich daraus noch kein Prototyp mit zusammenhängenden Komponenten stricken, der alle Bedürfnisse des Szenarios abdeckt. In Kapitel 5 wird man sehen, dass die Arbeit ihren Schwerpunkt auf Realisierungskonzepte legt, die umgekehrt aber wieder aufgrund ihrer Generalisierbarkeit und Skalierbarkeit einen positiven Effekt auf kommende, erst einmal theoretische Konzepte haben.
4.5.3
Präsentationskonzepte
Zwar wurde gesagt, dass sich die Konzepte der Arbeit hauptsächlich mit der Interaktion
als mit der Präsentation beschäftigen, allerdings schließt die Definition einer multimodalen Schnittstelle die Reaktion in Form von Multimedia auf die Aktionen des Anwenders
unbedingt mit ein. Außerdem ist die Effizienz des Touristenführers nicht wirklich messbar, wenn der Besucher keine Medien geliefert bekommt. Die Absicht, GUI-Prinzipien
nicht vollständig abzulösen, birgt zudem automatisch die Idee der Einbettung von sichtbaren Steuerelementen in die Schnittstelle. Erfahrungen mit graphischen Schnittstellen in
der AR im Bereich Cultural Heritage und Tourismus wurden von Intracom in den Projekten Archeoguide und intCulture gesammelt. An die Entwicklung von ARGuide wurde in
dieser Arbeit angeknüpft und die Schnittstelle, die bis dato nur Demonstrationszwecken
diente, umstrukturiert. Erhalten bleiben Kontext-, Content- und Lokalisierungskomponenten sowie Konzepte zur Führung des Besuchers durch die Ausstellung.
Unterscheidung von Steuerelementen
Nach den Ideen von [HFT+ 99] sind die graphischen Steuerelemente grundsätzlich in
„screen-stabilized“ und „world-stabilized“ Objekte aufgeteilt. Erstere dienen der Darstellung von Statusinformationen, globale Instruktionen zur Führung des Besuchers sowie
Hilfestellungen. Sie können auf dem Bildschirm dynamisch durch Autor oder Benutzer
positioniert werden. Alle unmittelbar auf die getrackten Objekte ausgerichteten Elemente
4.5. KONZEPTE
87
beschreiben direkte Interaktionen in der AR, etwa die Animation von Overlays, Medienpräsentationen über das augmentierte Objekt, dreidimensionale Ansichten oder Kommentierung der Situation.
Abbildung 4.4: Relation der Steuerelemente (Mockup)
Sitenavigation
Eine Ausstellung hat, wie in Abschnitt 4.3 beschrieben, eine hierarchische Architektur.
Anfangs war die Idee, die Bezeichnungen für Areale und Exponate in einer baumartigen
Menüstruktur mit dem Ausstellungsnamen als Wurzel und Gebiete sowie Teilgebiete als
Zweige und Äste unterzubringen. Es hat sich aber herausgestellt, dass akkurate Navigation
durch die Struktur zu verstrickter, tiefer Erweiterung des Baumes und damit zu Sichtverdeckung führt. Außerdem wird der Benutzer vermutlich irritiert, wenn er nicht weiß, wie
er zu einem bestimmten Punkt zurückgelangen soll. Stattdessen wird dem Anwender die
Navigation durch ein umfangreiches Menü abgenommen. Der Guide zeigt ihm immer nur
die Bezeichnung des gerade besuchten oder navigierten Objekts (∼
= innerer Knoten des
∼
Baums) und dessen direkte Unterobjekte (= Kinder des innereren Knotens) in Form von
Schlüsselwort und Miniaturbild (Thumbnails) an (⇒ Beantwortung der Fragen „Wo bin
ich?“ und „Was kann ich hier sehen?“). Die Informationen werden bei Positionswechsel
sowie Selektion eines sichtbaren oder eines erinnerten Objekts aktualisiert. Durch ent-
88
sprechende Kommandos gelangt der Besucher immer wieder zur Ausgangsansicht zurück
(Informationen zur aktuellen Position). Die Fragen „Was ist in der Nähe?“ (umgebene
Areale und Exponate) und „Was ist mit dem Objekt verwandt?“ (themenverwandte Areale
und Exponate) werden durch diese Art der Sitenavigation auch beantwortet, wenn passende Befehle ausgesprochen werden und der Guide vom Sitemanagement (Verwaltung der
Struktur des Ausstellungsgeländes) relevante Informationen einholt.
Abbildung 4.5: Hierarchiemenü mit
horizontaler Baumstruktur (Konzept).
Abbildung 4.6: Alternatives Hierarchiemenü mit Baumstruktur (Konzept).
Abbildung 4.7: Menü mit Miniaturbildern und Bezeichnern (Konzept).
Feedback
Damit der Besucher auch weiß, welche Informationen er gerade erhalten und welche Aktionen er gerade durchgeführt hat, präsentiert der Guide kontinuierliches Text-, Audio-,
Farb- und Helligkeitsfeedback. Text wird nach Aktionen in einer horizontal aufblendenden Leiste angezeigt. Um dem Anwender nicht unnötig lange ein Teil seiner Sicht zu
nehmen, wird der Balken nach einer Weile wieder ausgeblendet. Es muss beachtet werden, dass nicht jede einzelne Aktion Textfeedback auslösen sollte, da die Einblendungen
4.5. KONZEPTE
89
dann zu oft wechseln und der Benutzer nicht folgen kann. Stattdessen sorgen Audiosignale
bei Hervorhebung und Auswahl von Steuerelementen für die notwendige Bestätigung der
Aktion. Dieselbe Funktion erfüllen unterschiedliche Farben und Helligkeiten. Grundsätzlich werden aktive und passive Steuerelemente unterschieden, allerdings ist dies nur für
die Verwendung von Maus und Remote Control notwendig, da mit Sprache alle Elemente
unmittelbar angesprochen werden können. Da in der Schnittstelle keine Pointing-Option
zur Verfügung steht, können Tools und Controls mit den ursprünglichen Zeigegeräten nur
sequentiell angesteuert werden. Wurde ein Tool navigiert, ist es in einem aktiven Zustand.
Dessen Controls werden nun ebenfalls sequentiell durchlaufen und selektiert. Wird eine
Control gerade durchlaufen, ist sie aktiv, alle übrigen sind passiv. Passiv sind auch alle verbliebenen, sichtbaren Tools und Controls. Aktive und passive Elemente unterscheiden sich
eindeutig im Kontrast. Um nun Sprachkommandos von normalen Textfragmenten trennen
zu können, werden auch hier kontrastreiche Farbhervorhebungen angewandt. Es ist darauf
zu achten, dass sich die vier Farbtöne nicht gegenseitig stören. Die Identifikation muss insbesondere beim Wechsel der Aktiv-Passiv-Rolle - immer eindeutig bleiben.
Statusmanipulation und Hilfsfunktionen
Neben der Navigation der Informationen kann der Anwender das System ständig mit Hilfe
einer Statusleiste kontrollieren. Es kann eine Kommandoleiste aufgerufen werden, die unter verschiedenen Themen an bereits erlernte Schlüsselwörter und Kommandos erinnert.
Die Themen können in Anlehnung an die in [Hsi02] geschilderten Benutzerbedürfnisse, an
die Bezeichnung der Tools oder an die dem Kommando folgenden Informationen („Architecture“, „Athletics“, „Political“, „Cultural“, etc.) spezifiziert sein. Nach Selektion eines
Themas wird eine Box mit entsprechend sortierten Einträgen temporär eingeblendet.
Wenn der Besucher wünscht, sich mit anderen Personen bei gleichzeitiger Benutzung des
Systems zu unterhalten, kann er das Mikrophon jederzeit stumm schalten. Die Spracherkennung reagiert folglich nur noch auf ein Reaktivierungskommando. Per Maus und RC
bleibt weiterhin alles ansteuerbar.
Nach den Hypothesen ist es gewünscht, dass der Anwender das Interface jederzeit ver-
90
Abbildung 4.8: Hotspots eines Exponats (Konzept)
stecken kann, wenn die graphischen Interaktionstools seine Sicht verdecken. Diese Option
ist ebenfalls in die Statusleiste integriert. Ein Hinweis erscheint, der den Anwender anleitet, wie er die Aktion umkehren kann.
Für Hilfefunktionen ist eine Option in die Statusleiste integriert, wird derzeit aber noch
kein Konzept vorgeschlagen, da intCulture entsprechende Lösungen vorsieht.
Augmentierung des Exponatmenüs
Reale Objekte werden im Videobild nicht nur von Bildern mit alternativen Ansichten des
Objektes überlagert, sondern es kann mit ihnen auch selbst wieder interagiert werden. Das
Exponatmenü hat dieselbe Funktionsweise wie alle übrigen Tools. Durch dieses lassen sich
Animationen steuern, ein dreidimensionaler Einblick in das Objekt geben, Informationen
zum Objekt abrufen und Erinnerungen an das Exponat aufzeichnen. Alternativ werden
bestimmte Bereiche eines Overlays - in Anlehnung an die aktuelle Exponatbezeichnung
im Sitenavigations-Tool - farblich mit transparenten Markern hervorgehoben (siehe Abb.
4.8), um den semantischen Bezug zwischen Thumbnail, Exponattitel und Position in der
Ausstellung herzustellen.
4.6. SYSTEMARCHITEKTUR
4.6
91
Systemarchitektur
Das Kapitel zur Systemarchitektur gilt der Realisierung der Konzepte unter Beachtung der
Hypothesen. Im Sinne von intGuide wird darüber hinaus an softwaretechnische Konzepte
zur Generalisierung und Skalierbarkeit der Plattform gedacht. Aber auch wenn man an die
Vielzahl der möglichen Wünsche und Bedürfnisse von Ausstellungsbesuchern denkt, ist
Erweiterbarkeit der Schnittstelle in jeder Hinsicht ein Muss.
4.6.1
Multimodale Systemarchitektur
Anhand von Konzepten und Anwenderszenarien lässt sich erkennen, dass die Schnittstelle
weder einseitig multimodal noch unimodal, sondern hybrid die Eingabedaten des Anwenders verarbeitet. Welcher Modus wann verwendet wird, um die Daten zu interpretieren, ist
abhängig von ihrer Komplexität. Das Ziel ist dennoch allen Modi gleich, nämlich Interaktion und Interpretation so einfach und effektiv wie möglich zu gestalten.
Streng nach Terminologie [Ovi02] betrachtet handelt es sich um ein sogenanntes „blended multimodal interface“, welches mindestens einen passiven und mindestens einen aktiven Eingabemodus erkennt und analysiert. Aktive Eingabedatenströme, die explizit vom
Anwender durch Kommandos ausgelöst werden, kommen von Sprach-, Maus- und Fernbedienungseingaben. Direkte passive Eingabedatenströme erreichen die Schnittstelle von
den Trägheitssensoren von Maus, Remote Control und (versuchsweise) Gamepad. Indirekte Interpretationen erfolgen durch Tastendruckfrequenz und Stimmlautstärke. Indirekt
bedeutet, dass sie nicht zum Zeitpunkt der Interaktion in Kombination mit anderen Daten,
sondern später analysiert werden. Für die Integration der Konzepte sind Kombinationen
aus aktiven und passiven Daten allerdings nicht notwendig. Stattdessen werden nur aktive Daten gemeinsam interpretiert. Da der Puffer eine sequentielle Dateneingabe erlaubt
und die Interpretation eines zeitlich versetzten, zweiten Eingabedatums damit von dem
zuerst erfolgten Kommando abhängig sein kann, handelt es sich zudem um ein sogenanntes „temporally cascaded multimodal interface“. Erst wenn der Puffer entleert wird, also
nach Erkennung jedes einzelnen Datums, wird ein Einzelereignis (unimodal) oder ein Tupel (multimodal) in eine systemverständliche Nachricht übersetzt. Dies bezeichnet man
92
als „late semantic-level fusion“, denn die Bedeutung eines Ereignisses ist schon auf Erkennungsebene bekannt. Bedeutung heißt in diesem Zusammenhang, dass eine komplette Dateneinheit erkannt wurde (z.B. „Play media“ oder „LeftMouseButtonPressed“. Das
Übersetzungsschema nutzt schließlich eine Methode, die als „frame-based integration“
bezeichnet werden kann. Ein Ereignistupel ((Device1 , Event1 ), . . . , (Devicen , Eventn ))
wird mit maximal k Schlüsseln der Form ((Device1 , Event1 ), . . . , (Devicem , Eventm ))
verglichen, bis eine Übereinstimmung gefunden wurde („Pattern-Matching“).
4.6.2
Komponentenkommunikation
Die Komponenten „Interaktion“ und „Präsentation“ bilden den Kern der multimodalen
Schnittstelle. Damit die vom Anwender ausgehenden Interaktionsdaten aber korrekt verarbeitet werden können, bis schließlich ein Ergebnis präsentiert wird, werden noch weitere
Komponenten benötigt. Der Aufbau orientiert sich teilweise an Vorschlägen aus [MRKB04].
Der Besucher interagiert folglich mit den Eingabegeräten der Interaktionskomponente,
die die Ereignisse abfängt, sie in für das System verständliche Informationen umwandelt (ergo interpretiert) und diese an die Applikationsverwaltung sendet. Diese hat zu
Anfang alle Manager initialisiert, welche wiederum für Subkomponenten verantwortlich
sind. Außerdem hostet sie den ARBrowser. Wenn die Benutzeranfrage Informationen aus
dem Repository benötigt, stellt die Applikation eine Anfrage an die Kontextkomponente, die den Zugriff ermöglicht. Sind alle Anfragen beantwortet, aktualisiert die Applikation den Zustand der Präsentation. Dem Anwender zeigt sich nun ein anderer Status
der Schnittstelle, mit welchem er abermals interagieren kann. Das Diagramm in Abb. 4.9
zeigt den (theoretischen) Kreislauf der Informationsverteilung. In der Praxis müssen die
Komponenten etwas verschoben werden. Das Tracking beinhaltet sowohl Positions- und
Orientierungsbestimmung als auch das Verfolgen und Rendern von Objekten und Overlays. GPS-Sensor und Kompass sind aber Bestandteile der Gruppe der Ortungsgeräte und
liefern der Applikation die Daten über die Interaktionskomponente. Der ARBrowser hin-
93
Abbildung 4.9: Komponentenkommunikation
gegen musste aus Designgründen, die in Kapitel 5.2.1 näher erläutert werden, in die Präsentation verschoben werden. Für Repository und Context werden im Prototyp nur Stubs
zur Verfügung stehen, da die Komponenten von intCulture bereits vorhanden sind, aber
noch nicht angebunden werden konnten.
94
4.6.3
Patterns und Komponenten
Nachdem nun festgelegt wurde, wie das System Daten austauscht, müssen die einzelnen
Komponenten weiter spezifiziert werden. Den Anforderungen der Anwendungsfälle und
des Anwenderszenarien folgend werden den Komponenten in Anlehnung an [MRKB04]
Patterns (grobe Funktionsspezifikation) zugeteilt. Die Vorschläge aus [MRKB04] sind für
die Erstellung von Klassendiagrammen aber noch zu ungenau definiert und werden daher
noch detaillierter beschrieben.
Die Interaktionskomponente wird in zwei Subsysteme aufgeteilt: ein Teilsystem verwaltet
alle Eingabe-, Ausgabe- und Lokalisierungsgeräte, ein anderes übernimmt die Verarbeitung der ankommenden Ereignisse der Geräte. Eingaben werden mittels „Keymapping“
(siehe Abschnitt 5.1.3) bei der Verarbeitung auf eine systemverständliche Ebene übersetzt.
Daten der Lokalisierungsgeräte werden durchgeschleust. Alle Einheiten der beiden Systeme sind konfigurierbar. Nach dem MVC-Modell (Model-View-Controller, [GHJV95])
ist die Interaktionskomponente der Controller zwischen Besucher und Applikation. Sie ist
aber nicht auf eine bestimmte View bezogen, sondern im Gegenteil vollständig unabhängig.
Die „gemappten“ Ereignisse werden an die Applikationskomponente weitergeleitet. Sie
werden auf Relevanz im aktuellen Kontext (Status der Interaktion und Schnittstelle) überprüft und an entsprechende Präsentationseinheiten, die initialisiert sein müssen, versendet.
An die Komponente werden ebenso alle Logging-Einträge gesendet, die feedbackrelevante Informationen beinhalten. Sie repräsentiert das Model des MVC-Konzepts, mit dem
Unterschied, dass keine Methoden für Zugriffe auf und Manipulationen von Daten bereitgestellt werden.
Jene Funktionalität wird von sogenannten „UIWidgets“ übernommen, die sowohl funktionale als auch darstellende Aufgaben (∼
= Tools und Controls) haben können und in die Präsentationskomponente integriert sind. Alle Widgets werden von einem Manager verwaltet.
Im Besonderen können Widgets (in späteren Prototypen) in VRML definierte Szenen und
95
Einzelobjekte in den ARBrowser importieren und rendern lassen. Ein Medienbetrachter ist
in der Lage, alle Arten von im Repository vorhandenen Medien abzuspielen. Zur Navigation innerhalb des Ausstellungsgeländes ist eine komplexere Subkomponente notwendig.
Alle von der Applikation gesammelten Feedbacknachrichten kommen dem Besucher an
dieser Stelle zu. Die Präsentationskomponente implementiert die View des MVC-Modells.
Context- und Content Management werden weitestgehend von intCulture übernommen
und verwalten die Site und ihre Ausstellungsstücke einschließlich ihrer zugehörigen Medien. Alle Informationen werden im Repository abgelegt. Profiling-Konzepte zur Feststellung von Benutzerpräferenzen sind ebenfalls eingeschlossen. Annotations-Funktionen
von intCulture werden mit Möglichkeiten erweitert, die sich aus Spracherkennung und
den Komponenten des ARBrowser ergeben. Neu konzipiert sind dagegen die Pattern zur
Konfiguration verschiedenster Module mittels in XML definierten Dateien, obwohl einige
Module schon im ARGuide mit XML konfigurierbar sind (Details zur Neugestaltung finden sich in Kapitel 5).
Weltmodell („World model“) und Trackingmodul sind nach Diagramm 4.10 unabhängige
Komponenten. Das Weltmodell gehört eigentlich zur Präsentation und ist nicht in einem
dreidimensionalen Koordinatensystem definiert. Objekte werden anhand von zweidimensionalen Positionsdaten und nach Abgleich mit Referenzbildern augmentiert. Daher kann
das Trackingmodul auch keiner einzigen Komponente zugeordnet werden. Daten kommen
von GPS und Kompass als Positionsgeräten und dem in die Präsentation eingebetteten ARBrowser durch die Kamera- bzw. Anwenderorientierung.
96
Abbildung 4.10: Patterns
Kapitel 5
Realisierung
In den folgenden Abschnitten wird die Umsetzung der in Kapitel 4.5 vorgestellten Konzepte anhand der in Kapitel 4.6 skizzierten Systemarchitektur nachvollzogen. Es ist darauf
zu achten, dass die Konzepte nicht alle Hypothesen einbezogen haben und auch Teile der
Ideen des Anwenderszenarios erst in der Implementation wirklich zur Geltung kommen.
5.1
5.1.1
Interaktion
Ereignisse der Eingabegeräte
Wenn ein Anwender mit dem System interagiert, so bedient er in erster Linie einmal die
Interaktionsgeräte Sprache und Maus oder Remote Control. Maus und Sprache sind als
gekapselte, selbstständige Objekte integriert. Es existiert eine abstrakte Definition von
Sprachklassen, so dass später alternative Spracherkennungssysteme angebunden werden
können. Ebenso gibt es ein Objekt zum Filtern von Keyboardereignissen, das jedoch nur
als Workaround verwendet wird und nicht als Interaktionsgerät. Die mitgelieferte Softwa97
98
KAPITEL 5. REALISIERUNG
re der Remote Control1 erlaubt eine beliebige Belegung der Knöpfe mit Aktionen, die das
Betriebssystem zur Verfügung stellt (Aufrufen von Applikation, Mausereignisse, Keyboardereignisse, Befehlskombinationen) und läuft als separate Anwendung im Hintergrund.
Sie wurde mit Maus- und Keyboardaktionen belegt, die von den Wrappern der anderen
Geräte entsprechend interpretiert werden. Die ankommenden Ereignisse werden abgefangen, eventuell gefiltert und schließlich in den Formaten <Device, Event> oder <Device,
Event, Info> an den Gerätemanager als einzigem Nachrichtenempfänger weitergeleitet.
Das spezielle Tupel ist notwendig, falls die Interaktion zusätzliche Information liefert, die
direkt am Gerät erkannt wird (z.B. der Lautstärkepegel des Mikrophons oder die Position des Mauszeigers bzw. die Daten der Trägheitssensoren in Maus und RC). Spracheingaben werden durch das dynamisch konstruierte Schlüsselwort- und Phrasenverzeichnis
und Maus-Eingaben durch die Angaben in einer Konfigurationsdatei gefiltert (siehe Listing 5.1). Die RC hat allerdings keine eigene Konfiguration, sondern imitiert Maus- und
Keyboard-Eingaben.
<?xml version= " 1 . 0 " ?>
<MouseSettings xmlns:xsd = " h t t p : / / www. w3 . org / 2 0 0 1 /XMLSchema" x m l n s : x s i = " h t t p : / / www. w3 . org
/ 2 0 0 1 / XMLSchema−instance " C o n f i g F i l e P a t h = " H: \ P r o j e c t s \ Sources \ MuMoUI \ b i n \ Release \
MouseSettings . xml " >
<Filters>
<event x s i : t y p e = " x s d : s t r i n g " >RightButtonRelease< / event >
<event x s i : t y p e = " x s d : s t r i n g " >RightButtonDouble< / event >
<event x s i : t y p e = " x s d : s t r i n g " >RightButtonPressed< / event >
<event x s i : t y p e = " x s d : s t r i n g " >LeftButtonPressed< / event >
<event x s i : t y p e = " x s d : s t r i n g " >LeftButtonRelease< / event >
<event x s i : t y p e = " x s d : s t r i n g " >LeftButtonDouble< / event >
<event x s i : t y p e = " x s d : s t r i n g " >MiddleButtonDouble< / event >
<event x s i : t y p e = " x s d : s t r i n g " >MiddleButtonRelease< / event >
<event x s i : t y p e = " x s d : s t r i n g " >MiddleButtonPressed< / event >
<event x s i : t y p e = " x s d : s t r i n g " >MouseMove< / event >
</ Filters>
< / MouseSettings>
Listing 5.1: Konfiguration der Mausereignisfilter
1
GyroTools, http://www.gyration.com/gyrotools.htm
5.1. INTERAKTION
5.1.2
99
Ereignisse der Lokalisierungsgeräte und Kontrolle der Ausgabegeräte
In den Anwendungsfällen ist zwar vorgesehen, dass der Anwender Kontrast und Helligkeit von Displays sowie Lautstärke des Headsets regeln kann, dennoch gehört die Anbindung von Ausgabegeräten über Softwaremodule nicht zum Bestandteil dieser Arbeit. Die
Profiling-Module von intCulture übernehmen diese Aufgaben. Werden diese später integriert, ist darüber nachzudenken, entsprechende Funktionen auszugliedern. Gleiches trifft
auf die Lokalisierungsgeräte GPS und elektronischer Kompass zu, die im weiteren nicht
verwendet werden können. Allerdings wurde ein Workaround geschrieben, um per Keyboardeingabe vorgegebene Positions-Tupel mit Arealbezeichner (SiteItemID), Längenund Breitengrad und Orientierung an der aktuellen Position aufrufen zu können und Reaktionen des Systems auszulösen.
5.1.3
Ereignismanagement
Der Ereignismanager empfängt nun ein Ereignistupel und sucht nach einem passenden
Schlüssel in seiner Keymap (Speicher mit Schlüssel-Wert-Paaren), die per XML konfiguriert wurde (siehe Listing 5.2). Ein Eintrag (MapEntry) besteht aus einem oder mehreren KeyPair(s) <Device, Event> und einem oder mehreren ValuePair(s) im Format <Widget,Common Layer Value*> (zur Idee von Widgets siehe 4.6.3). Wenn ein Eintrag gefunden wurde, werden die Common Layer Value(s) (CLV) über den Systemmanager an ihre
entsprechenden Widgets versendet. Ein CLV ist eine systemverständliche Nachricht, die
von einem Widget gelesen werden kann. Der Mappingprozess ist in den Abbildungen 5.1
und 5.2 dargestellt.
Man sieht, dass die Ereignisse sich in keinster Weise ähneln, die abgebildeten Paare aus
Zielwidget und CLV aber allen gemeinsam sind. Durch die Variable „Global“ lässt sich
zusätzlich festlegen, ob das Ereignis bei Initialisierung des Managers als globaler Befehl
mit in das Sprachvokabular aufgenommen wird.
100
Abbildung 5.1: Keymapping (algorithmisch)
Mediator
Da der Manager sowie andere Entitäten des Systems sich nicht kennen, unterstützt ein
global bekannter „Mediator“ (vgl. [GHJV95]) bei der Verbreitung der Sprachbefehle. Interessierte Nachrichtenempfänger registrieren sich über ein eigenes Interface und vorgegebene „Subjects“. Mögliche Subjects sind „SiteElementKeywords“ (Exponatbezeichner
wie „Temple“), „EventKeywordsSingle“ (Kurzkommandos wie „Play“), „EventKeywordsPhrase“ (Kommandos wie „Next tool“), „EventKeywordsPreCommands“ (Einleitende
Kommandowörter wie „Next“), „CommandBroadcast“ (Nachrichtenverteiler zur Auslösung eines Kommandos, ohne dass ein Gerät bedient wurde) und „EventFilters“ (Ereignisse und Nachrichten, die von einem Empfänger geblockt werden). Der Nachrichtenverteiler
hat besondere Bedeutung, weil hierdurch das System selbst Ereignisse auslösen kann, die
das Eventmanagement zu analysieren hat. Wie später ersichtlich wird, ist dies beispielsweise für die Kommunikation zwischen Widgets notwendig. Die Ereignisfilter sind für
multimodale Befehlsverarbeitung gedacht und werden einige Abschnitte später erklärt.
Das Interface kombiniert nun Empfängermethoden und Subjects. Wenn ein Sender Nachrichten global verbreiten will, übergibt er dem Mediator diese über relevante Aufrufe, je
101
5.1. INTERAKTION
Abbildung 5.2: Keymapping (schematisch)
nachdem welches Interesse der Sender hat, wie die Nachricht interpretiert werden soll.
Der Mediator verteilt die Nachricht an seine Beobachter. Das Sprachmodul nimmt dann
etwa als Schlüsselwörter oder Befehlsketten interpretierte Nachrichten in sein Vokabular
auf und bildet eine neue Grammatik.
Der Parameter „Verbose“ gibt an, ob das Ereignis einerseits geloggt wird und andererseits direkt als Feedback für den Anwender verwendet wird. In Beispiellisting 5.2 wird
die Aktion erst durch das BioFeedbackWidget verarbeitet und es entscheidet selbst, ob es
Feedback wiedergibt oder nicht.
102
...
<MapEntry>
<Keys>
<KeyPair Device= " MSSpeech " EventID= " Next t o o l " G l o b a l = " t r u e " / >
<KeyPair Device= " I ne r t i a l G a m e p a d " EventID= " 07 " G l o b a l = " f a l s e " / >
<KeyPair Device= " Mouse " EventID= " MiddleButtonPressed " G l o b a l = " f a l s e " / >
< / Keys>
<Values>
< V a l u e P a i r TargetWidget = "MuMoUI . P r e s e n t a t i o n . Widgets . W i d g e t C o n t r o l l e r " >
<CommonLayerValues>
<CLV>NextWidget< / CLV>
< / CommonLayerValues>
< / ValuePair>
< V a l u e P a i r TargetWidget = "MuMoUI . P r e s e n t a t i o n . Widgets . BioFeedbackWidget " Verbose
=" false ">
<CommonLayerValues>
<CLV>ObserveButtons< / CLV>
< / ValuePair>
< / Values>
< / MapEntry>
...
Listing 5.2: Beispieleintrag der Keymap
5.1.4
Ereignisse mit Zusatzinformationen
Ein Eintrag zur Verarbeitung eines Ereignisses mit Zusatzinfo unterscheidet sich nur in
dem Bezeichner des Events von dem herkömmlichen Format. Das Gerät signalisiert mit
dem besonderen Schlüsselwort „IndependentKeyword“, das es als Event in das Tupel
<Device, Event, Info> packt, dass als Information ein unabhängiges Schlüsselwort folgt.
Dieses Schlüsselwort ist demnach keine Befehlskette im Sinne von „Next tool“, sondern etwa der Bezeichner eines Ausstellungsstücks und gehört zu einer gesonderten Kategorie des Sprachvokabulars. Die auf Ereignisse wartenden Widgets interpretieren die
Schlüsselwörter dementsprechend für ihre Aufgaben. In Beispiel 5.3 nutzt die Sitenavigation (ThumbnailMenuWidget) das Schlüsselwort als Navigationspunkt, die Kommandohilfe (CommandBarWidget) sucht nach einer passenden Kategorie und das Exponatmenü
(AROverlayWidget) nach einem passenden Menüeintrag. Die Semantik ist also in jedem
5.1. INTERAKTION
103
Fall deutlich unterschiedlich.
...
<MapEntry>
<Keys>
<KeyPair Device= " MSSpeech " EventID= " IndependentKeyword " G l o b a l = " f a l s e " / >
< / Keys>
<Values>
< V a l u e P a i r TargetWidget = "MuMoUI . P r e s e n t a t i o n . Widgets . ThumbnailMenuWidget "
Verbose= " t r u e " >
<CommonLayerValues>
<CLV>Keyword< / CLV>
< / ValuePair>
< V a l u e P a i r TargetWidget = "MuMoUI . P r e s e n t a t i o n . Widgets . CommandBarWidget "
Verbose= " t r u e " >
<CommonLayerValues>
<CLV>Topic< / CLV>
< / ValuePair>
< V a l u e P a i r TargetWidget = "MuMoUI . P r e s e n t a t i o n . Widgets . AROverlayWidget " Verbose= "
true ">
<CommonLayerValues>
<CLV>MenuEntry< / CLV>
< / ValuePair>
< / Values>
< / MapEntry>
...
Listing 5.3: Beispieleintrag der Keymap für Events mit Zusatzinfo
5.1.5
Verarbeitung multimodaler Ereignisse
Die in den letzten beiden Listings abgebildeten Ausschnitte sind nun nur zu unimodaler
Verarbeitung gedacht. Multimodale Befehle erfordern eine komplexere Spezifikation und
Verarbeitung (vgl. Listing 5.4). Durch das Flag „Multimodal“ erkennt der Ereignismanager, dass die in dem Eintrag definierten KeyPairs zusammen erkannt werden müssen. Zusammen bedeutet nicht parallel, sondern innerhalb eines vorgegebenen Zeitfensters. Intern
werden die Paare in einem separaten Speicher abgelegt. Das erste vorkommende KeyPair
104
< M SSpeech, P lay > dient gleichzeitig als Schlüssel zum Starten des Timers bis zum
Ablauf des Zeitrahmens. Es wird zuerst in einem Puffer abgelegt und der Manager wartet
auf weitere Ereignisse. Werden die übrigen Ereignisse < M ouse, Lef tButtonP ressed >
vor Ablauf empfangen, löst der Manager die zu den Tupeln gehörigen Aktionen in den
Widgets aus, entleert den Puffer und setzt den Timer zurück. Andernfalls werden die im
Puffer gespeicherten Ereignisse sequentiell unimodal verarbeitet. Das Keymapping wird
mit der herkömmlichen Keymap ausgeführt. Ereignisse, die nicht in den Puffer abgelegt
werden sollen (etwa nach einem multimodalen Primärschlüssel), werden über eine durch
das Subject „EventFilters“ des Mediators aufgebaute Liste geblockt und direkt unimodal
verarbeitet (z.B. das kontinuierliche Senden des Lautstärkepegels). Das entsprechend zu
definierende Flag für ein KeyPair lautet „BlockBuffer“.
Die Erkennung eines multimodalen Befehls passiert nicht in Echtzeit. Der Manager wartet
immer das Zeitfenster ab und vergleicht dann die Objekte im Puffer. Die einzige zeitsparende Maßnahme ist der Vergleich mit den Primärschlüsseln der multimodalen Befehle,
bevor ein Ereignis im Puffer abgelegt wird. Stimmen Ereignis und Schlüssel nicht überein, wird unmittelbar unimodal verarbeitet. Daraus folgt, dass die Schlüssel sorgfältig ausgewählt sein müssen und keine Zweideutigkeiten zu unimodalen Befehlen zulassen (vgl.
„Put-That-There“ [Bol80] mit „Put“ als Schlüssel). Nichtsdestotrotz dient Beispieleintrag
5.4 nur zu Demonstrationszwecken und wird für die Bedienung der Schnittstelle momentan nicht benötigt.
5.1. INTERAKTION
105
...
<MapEntry M o d a l i t y = " M u l t i m o d a l " >
<Keys>
<KeyPair Device= " MSSpeech " EventID= " Play " G l o b a l = " t r u e " / >
<KeyPair Device= " Mouse " EventID= " L e f t B u t t o n P r e s s e d " G l o b a l = " f a l s e " / >
< / Keys>
<Values>
< V a l u e P a i r TargetWidget = "MuMoUI . P r e s e n t a t i o n . Widgets . MediaViewerWidget " Verbose
=" true ">
<CommonLayerValues>
<CLV>Play< / CLV>
< / ValuePair>
...
< / Values>
< / MapEntry>
...
Listing 5.4: Beispieleintrag der Keymap für multimodale Befehle
5.1.6
Zustandsautomaten
Ein interpretiertes Wertepaar <Widget, CLV*> wird schließlich an den Anwendungsmanager gesendet. Dieser entscheidet anhand der Widgetliste des (G)UIManagers und derer
Zustandsautomaten, ob das Ereignis in den aktuellen Kontext passt. Die Liste beinhaltet
alle in der Konfiguration des (G)UIManagers definierten und initialisierten Widgets. Jedem Widget liegt ein Zustandsautomat (Statemachine) (Finite Statemachine, FSM) mit
einer ereignisgesteuerten2 Zustandsübergangstabelle3 zugrunde. Die Struktur der FSMs
ist in Anlehnung an [YA] und [GHJV95] entstanden. Da die Patterns aus Paper und Buch
aber zu unflexibel und im Programmcode unterzubringen sind, wurde eine generalisierte Klasse geschaffen, deren Objekte, also Entitäten einer FSM, über eine externe XMLKonfiguration spezifiziert werden können. Eine FSM ist demnach wie folgt aufgebaut (in
EBNF):
2
3
Definition in Wikipedia unter http://en.wikipedia.org/wiki/Event_driven_finite_state_machine
Definition in Wikipedia unter http://en.wikipedia.org/wiki/State_transition_table
106
F SM ::= F SM ObjectT ype {F SM State}
F SM ObjectT ype ::= N amespace
N amespace ::= {N ame „ . „} N ame
N ame ::= Char {Char}
Char ::= „a„| . . . |„z„
F SM State ::= N ame StateBehaviour {OccuringEvent}
StateBehaviour ::= Enter|Exit|N one|Special
OccuringEvent ::= N ame N extState Action
N extState ::= N ame
Action ::= N ame
Der Anwendungsmanager vergleicht einen CLV mit den Namen der möglichen Ereignisse
in dem aktuellen Zustand des zum Tupel gehörenden Zielwidgets. Findet er eine Übereinstimmung, löst er die zum Ereignis zugehörige Aktion durch einen namensgleichen
Methodenaufruf im Widget aus. Der Datenfluss von Interaktion über Applikation zu Präsentation bleibt erhalten, da der Manager auf die initialisierten Widgets im Speicher des
(G)UIManagers zugreift. Nach dem Aufruf wechselt das angesprochene Widget in den für
das Ereignis definierten nächsten Zustand und die Ereigniskette wird abgeschlossen. Zustände können verschiedene Verhaltensweisen zeigen. Es existieren Eintritts-, Austrittsund Spezialzustände neben Zuständen ohne spezifisches Verhalten. Diese Option ist für
ein späteres Entwicklungsstadium vorgesehen, in welchem die FSM mehrerer Widgets
miteinander verknüpft werden könnten, um ein gemeinsames, voneinander abhängiges
Verhalten zu herzustellen (z.B. im Augenblick der Medienwiedergabe wäre die Interaktion mit Menüs nicht möglich).
Listing 5.5 zeigt eine FSM am Beispiel des Exponatmenüs. In einem Fall muss das Widget
in den nächsten Zustand seiner FSM ohne die Hilfe der Konfiguration wechseln, nämlich,
nachdem eine Animation präsentiert worden ist. Der Anwender kann diese jederzeit selbst
5.2. PRÄSENTATION
107
abbrechen. Das Widget aber kennt den Folgezustand nicht, wenn kein neues Ereignis im
aktuellen Zustand auftritt. Alternativ könnte das Widget auch ein dem möglichen auftretenden Ereignis „StopAnimation“ äquivalenten Command Broadcast auslösen. Dazu sind
aber Kenntnisse der Keymap des Ereignismanagers notwendig.
<?xml version= " 1 . 0 " encoding= "UTF−8" ?>
<StateMachine
FSMObjectType= "MuMoUI . P r e s e n t a t i o n . Widgets . AROverlayWidget " xmlns:x0 = " h t t p : / / www. w3 .
org / 2 0 0 1 /XMLSchema" >
<FSMState Name= " RenderOverlay " S t a t e B e h a v i o u r = " None " >
<OccuringEvent Name= " Next " N e x t S t a t e = " RenderOverlay " >
< A c t i o n Name= " NextOverlay " / >
< / OccuringEvent>
<OccuringEvent Name= " ShowAnimation " N e x t S t a t e = " Animating " >
< A c t i o n Name= " ShowAnimation " / >
< / OccuringEvent>
<OccuringEvent Name= "Go i n t o " N e x t S t a t e = " RenderOverlay " >
< A c t i o n Name= " GoInto " / >
< / OccuringEvent>
<OccuringEvent Name= " MenuEntry " N e x t S t a t e = " RenderOverlay " >
< A c t i o n Name= " S e l e c t O v e r l a y " / >
< / OccuringEvent>
< / FSMState>
<FSMState Name= " Animating " S t a t e B e h a v i o u r = " None " >
<OccuringEvent Name= " StopAnimation " N e x t S t a t e = " RenderOverlay " >
< A c t i o n Name= " StopAnimation " / >
< / OccuringEvent>
< / FSMState>
< / StateMachine>
Listing 5.5: FSM-Konfiguration am Beispiel des Exponatmenüs
5.2
5.2.1
Präsentation
Präsentationsmanagement
Bevor aber ein Aktionsname zu einem Widget gesendet wird, teilt - wie schon erwähnt der (G)UIManager dem Anwendungsmanager mit, ob dieses überhaupt initialisiert wurde.
108
Im Dialekt des .NET-Framework ist der Manager eine „Form“, die die Widgets als „Controls“ rendert. Er bettet zudem den ARBrowser als ActiveX-Control in die Umgebung ein,
startet das Tracking und aktualisiert die Overlays. Ursprünglich sollte der Anwendungsmanager die Komponente integrieren. Die ActiveX-Control muss aber zwingend eine Form
oder andere Control als Container besitzen. Dies erscheint auch logischer, da das Tracking
immer noch zum Anwendungsmanager gehört (GPS, Kompass, ARBrowser-Events) und
nur das Rendering des Videobilds in die Präsentation verlegt wird, das schließlich von
Controls überlagert wird. Der (G)UIManager wird durch eine externe XML-Datei konfiguriert. Die Konfiguration enthält neben einer Liste der zu importierenden Widgets Farbund Helligkeitswerte für aktive (focused) und passive (basic) Tools und derer Steuerelemente sowie für aktive (active) und passive (passive) Textelemente. Aktive Textelemente
sind alle Kommandos und Schlüsselwörter. Ebenfalls sind zwei Schriftarten zu Zwecken
der Textgliederung definiert, die sich hauptsächlich in ihrer Größe unterscheiden. Ein Auszug der Konfiguration findet sich in Listing 5.6.
5.2. PRÄSENTATION
109
...
<UIWidgets>
<Widget P r i m a r y C e l l = " B o t t o m L e f t " SecondaryCell = " B o t t o m L e f t " F i r s t D o c k S t y l e = "
Bottom " >
<Name>MuMoUI . Presentation . Widgets . StatusBarFeedbackWidget< / Name>
< / Widget>
...
<Widget>
<Name>MuMoUI . Presentation . Widgets . AROverlayWidget< / Name>
< / Widget>
...
<Widget>
<Name>MuMoUI . Presentation . Widgets . WidgetController< / Name>
< / Widget>
<Widget>
<Name>MuMoUI . Presentation . Widgets . BioFeedbackWidget< / Name>
< / Widget>
...
< / UIWidgets>
<focusedWidgetColor alpha = " 255 " red= " 204 " green= " 163 " b l u e = " 74 " / >
< b a s i c W i d g e t C o l o r alpha = " 255 " red= " 255 " green= " 244 " b l u e = " 216 " / >
< a c t i v e T e x t C o l o r alpha = " 255 " red= " 58 " green= " 99 " b l u e = " 128 " / >
< p a s s i v e T e x t C o l o r alpha = " 255 " red= " 0 " green= " 0 " b l u e = " 0 " / >
<mainLevelFont f o n t F a m i l y = " Tahoma " f o n t S i z e = " 14.25 " f o n t S t y l e = " Bold " g r a p h i c s U n i t = " P o i n t "
gdiChar= " 0 " / >
<subLevelFont f o n t F a m i l y = " Tahoma " f o n t S i z e = " 12.25 " f o n t S t y l e = " Bold " g r a p h i c s U n i t = " P o i n t "
gdiChar= " 0 " / >
...
Listing 5.6: Auszug aus der Konfiguration des UIManagers
Layout
Neben den Farbinformationen benötigt der Manager die bevorzugten Positionsangaben
der Widgets, da das entsprechende Attribut der .NET-Control den Wert relativ zu ihrem
Container (∼
= Managerform) in absoluten Koordinaten definiert, aber je nach Auflösung
des Bildschirms von Resizing- und Positionierungs-Funktionen abhängig ist. Während
der Entwicklung ist aber aufgefallen, dass diese Funktionalität nicht gewährleistet werden
kann. Da außerdem eine Pointing-Metapher fehlt, die die notwendige Interaktion bewerkstelligt, definiert der Manager stattdessen das Layout der Form durch ein eigens definiertes
Grid (Gitter). Das Grid besitzt eine Auflösung von (3 × 3)n mit 1 ≤ n ≤ 3 Zellen. Fei-
110
Abbildung 5.3: Positionierung im Grid
nere Auflösungen werden - wenn auch nicht benötigt - momentan noch nicht unterstützt.
Prinzipiell sind sie von der Vorgabe einer minimalen Zellengröße abhängig, bis zu welcher
maximal unterteilt wird. Die Idee zu gerade dieser Unterteilung in minimal 9 Zellen entstammt dem Gedanken, dass das Zentrum des Bildschirms für die Sicht auf die Umgebung
freigehalten werden sollte und alle Elemente um das Zentrum herum arrangiert sind.
Das Grid ist nun als Hierarchie von (3 × 3) Zellen aufgebaut, die jeweils wiederum ein
Grid gleicher Größe bis zur Tiefe n besitzen. Wie in Listing 5.6 zu sehen, kann jedes
Widget seine bevorzugte Position in diesem Grid durch die Angabe von maximal n Zellen festlegen. Jedes n steht für eine Hierarchiestufe. Zusätzlich kann es an verschiedenen
Kanten der Hierarchiezelle angedockt werden (Top, Bottom, Left, Right). Die Definition
von „DockStyles“ entstammt dem .NET-Framework. Rein funktionale Widgets benötigen keine Angaben. Ein Beispiel für die Positionierung eines Widgets in einem (3 × 3)2
großen Grid ist in Abb. 5.3 zu sehen. Die hellfarben markierte Zelle liegt in der ersten
(„PrimaryCell“) Hierarchieebene („BottomLeft“) und die dunkelfarben markierte Zelle in
der zweiten („SecondaryCell“) Hierarchieebene („BottomLeft“).
Eine Lösung für sich gegenseitig verdeckende Widgets, z.B. wenn sie dieselben Zellen
definiert haben, ist bisher nur auf Anwenderebene vorgesehen. Jedes Widget lässt sich per
Kommando auf eine der (3 × 3) Zellen der ersten Hierarchiestufe verschieben. Da Besuchern diese Aufgabe aber eigentlich abgenommen werden soll, sollten nur Autoren die
5.2. PRÄSENTATION
111
Funktion nutzen. In zukünftigen Versionen könnte man auch ein Layout per Kommando
definieren und als Konfiguration abspeichern.
5.2.2
Widgets
Im Detail sind Widgets in die Kategorien UIWidget, NCWidget und MDIWidget unterteilt.
Die Klasse der UIWidgets sind Erweiterungen benutzergenerierter Steuerelemente (UserControl), die mehrere andere Steuerelemente (Control) des .NET-Framework einbetten
und von einer Form als eine vollständige Control importiert werden können. Der Manager
kommuniziert dann nur noch mit dieser Control und nicht mit den einzelnen Elementen.
UIWidgets
Bevor ein UIWidget initialisiert und angesteuert werden kann, muss es eine Position vorschlagen (immer notwendig, auch wenn in Konfigurationsdatei spezifiziert), sein Zustandsautomat generieren und einen Startzustand in der FSM festlegen. Nach seiner Initialisierung durch den Manager ist es bereit, Nachrichten zu empfangen. Die Nachrichten sind aus
CLV des Event Management abgeleitete Aktionen im aktuellen Zustand der FSM (Auflösung der CLV nach Schema der FSM) und lösen damit den Aufruf von Routinen aus, die
den Zustand des Widgets und seiner FSM ändern. Trug das Ereignis eine Zusatzinformation mit sich, wird sie hier schließlich ausgewertet. Ist die Nachricht der Name einer Control und wurde über eine gesonderte Routine übergeben, hebt das Widget entsprechende
mittels einer der vorgegebenen Farbtöne hervor. Eine folgende Selektion geschieht durch
die Benachrichtigung des Ereignismanagers über ein Command Broadcast des Controlnamens, wenn unidirektionale Eingabegeräte bedient werden. Die abstrahierten Ereignisse
dieser Geräte (z.B. Tasten der Maus) werden zwar vom Ereignismanager verstanden, stehen aber so häufig in einem anderen Kontext, dass sich eine Integration im Programmcode
flexibler auswirkt als eine Festlegung des Ereignisses und vieler beobachtender Widgets
in der Konfigurationsdatei. Gleiches gilt für die Aktivierungs- und Deaktivierungsroutinen
der UIWidgets, die dem Anwender zunächst einmal helfen, aktive und passive Tools voneinander zu unterscheiden. In späteren Entwicklungsstadien ist etwa daran zu beachten,
dass sich Widgets je nach Status ihrer FSM gegenseitig stören können. Ein reales Ein- und
112
Ausschalten anstatt simpler Farbunterscheidung wäre also auch denkbar. Der Aufwand ist
höher, die Nachrichtenkette länger und es erfordert die Integration eines WidgetControllers (siehe kommende Abschnitte).
Aktualisierung des Kontext
Der Zustand eines Widgets kann sich auch durch ein Update des Kontext durch den Anwendungsmanager ändern. Zur Bekanntmachung dieser Information wird ein Objekt (Exponat) mit folgenden Attributen ausgetauscht (im Kontextmodul des ARGuide schon definiert und hier ergänzt):
• Position des Benutzers mit GPS- und Kompassdaten,
• Namenskennung des Ausstellungsstücks (∼
= SiteElementID),
• Schlüsselworte (∼
= Keywords),
• Dateipfade zu den Overlays des Ausstellungsstücks, zu den Referenzbildern des
Ausstellungsstücks, zu den Medienkonfigurationen des Ausstellungsstücks (∼
= SMIL)
und zu den Trackerkonfigurationen des Ausstellungsstücks,
• Speicherort für Schnappschüsse mit Präfix,
• Listen mit Schlüsselworten aller POI des Ausstellungsstücks, aller umgebenen AOI
und POI des Ausstellungsstücks und aller verwandten AOI und POI des Ausstellungsstücks.
Die Bezeichnung Ausstellungsstück bezieht sich dabei sowohl auf die gesamte Ausstellung selbst, als auch auf enthaltende AOI und POI. Das Objekt wird vom Anwendungsmanager unter Abfrage des Kontextbackends mit Inhalten gefüllt und an alle Beobachter
bei Positionswechsel oder spezifischer Abfrage des Content eines Elements gesendet. Die
Schnittstelle wird somit konstant auf aktuellem Stand gehalten und der Anwender hat immer einen Überblick über seinen derzeitigen Kontext.
5.2. PRÄSENTATION
113
NCWidgets
Ursprünglich zur Lösung von Transparenzproblemen entworfen (Diskussion in Kapitel
6.1), eignen sich NCWidgets (No-Control-Widgets) auch gut zur Einbettung von im Hintergrund arbeitenden Routinen, die keine visuelle Repräsentation benötigen. Im Gegensatz
zu den UserControls stellt der (G)UIManager die Steuerelemente des Widgets einzeln dar
und nicht zusammenhängend. Aufgrund von Resizing- und Positionierungsschwierigkeiten, insbesondere, wenn sich die Positionen einzelner Steuerelemente dynamisch ändern,
eignen sie sich aber nicht für eine große Zahl zu rendernder graphischer Steuerelemente.
Nichtsdestotrotz sind nur wenige Widgets mit dieser Technik realisiert. Auch UIWidgets
können nämlich bei erhöhter Flexibilität nur im Hintergrund laufen, wenn entsprechende
Attribute gesetzt werden.
UIMDIWidgets
Die Idee zu UIMDIWidgets entstand aufgrund der gleichen Probleme wie die der NCWidgets und versuchte, das Konzept der Multi-Document-Interfaces (MDI) des .NETFramework zu nutzen. Hintergrund war, dass eine Form Transparenzen zum Hintergrund
automatisch unterstützt. Da jedes Dokument der Applikation selbst wieder eine Form ist,
hätte man hier minimale Steuerelemente ohne gruppierende Elemente, die die Sicht eigentlich am meisten verdecken, unterbringen können. Bei der Umsetzung wurde aber bemerkt,
dass Transparenz nur von der Top-Level-Form zugelassen wird. Außerdem hätte dies eine
Umstellung der Kommunikation zwischen Manager und Widgets bedeutet.
Zum Abschluss der Realisierungsphase standen eine Reihe von Widgets zur Verfügung
(siehe Tabelle 5.1). Teilweise sind sie noch im Experimentierstadium. Voll funktionale
Widgets wurden schließlich mit in die Evaluation aufgenommen. Kurze Beschreibungen,
wie versucht wurde, die Konzepte umzusetzen, und welche spezifischen Eigenschaften die
Implementationen haben, folgen in der Tabelle.
114
Widget
Funktion
Typ
Stadium
sichtbar
AROverlayWidget
Navigation
und
Rendering
des
Exponatmenüs; Wechselndes Rendering von
Overlays; Animationen
UIWidget
Evaluierbar
Als Overlay, nicht als
.NET-Steuerelement
BioFeedbackWidget
Analyse passiver Eingabedatenströme; Analyse des Benutzerverhaltens anhand seiner
Interaktionen; Feedback
bei auffälligem Verhalten
UIWidget
Evaluierbar
Nein; Weiterleitung von
Feedback an FeedbackLogger
CommandBarWidget
Darstellung der Topics
der Kommandohilfe in
Form einer Statusleiste
NCWidget
Evaluierbar
Ja
CommandLabelWidget
Darstellung
der
Schlüsselwörter
und
Kommandophrasen für
die Kommandohilfe in
Form von aufblendenden „Notizzetteln“
UIWidget
Evaluierbar
Innerhalb
Zeitfensters
GuideStatusWidget
Anzeige
notwendiger
Ikonen und Hilfen bei
verstecktem Interface
NCWidget
Evaluierbar
Ja
HelpWidget
Anzeige von Hilfeseiten
UIWidget
Hilfeseiten sind simple
Erklärungen, aber evaluierbar
Ja
MediaViewerWidget
Präsentation verschiedender Medien mittels
SMIL-Format; verwendet den RealPlayer als
ActiveX-Control
UIWidget
Präsentationsfenster
kann
nicht
positioniert
werden,
aber
evaluierbar
Keine
Steuerelemente;
On-DemandPräsentationen
in
Aufblendfenster
SimpleTestWidget
Ausgabe des Sprachvokabulars
auf
der
Konsole;
Auslösen
von
Schnappschüssen und künstlichen
Positionswechseln
UIWidget
Nicht wirklich eigenständig; kombiniert Funktionen, die nicht in anderen Widgets untergebracht werden konnten;
evaluierbar
Nein
eines
115
5.2. PRÄSENTATION
Widget
Funktion
Typ
Stadium
sichtbar
StatusBarFeedbackWidget
Darstellung
der
Kommandos
für
Hilfefunktion,
Versteckfunktion
und
Kommandoleiste;
Ein- und Ausschalten
des
Mikrophons;
Darstellung
des
Lautstärkepegels des
Mikrophons
UIWidget
Evaluierbar
Ja
TextFeedbackWidget
Präsentation von Feedbacknachrichten in Textform
UIWidget
Evaluierbar
Innerhalb
Zeitfensters
ThumbnailMenuWidget
Sitenavigation mit Hilfe
von
Miniaturbildern
und Exponatschlüsselwörten;
seitenweises
Blättern durch Exponate
eines AOI oder POI
UIWidget
Evaluierbar
Ja
WidgetController
Schnittstelle zwischen
(G)UIManager
und
Widgets zur Ausführung
von navigativen Befehlen mit unidirektionalen
Eingabegeräten (Navigation durch Tools und
Controls; Selektionen;
Positionierung
von
Tools;
Verstecken
und Hervorholen der
visuellen Elemente)
UIWidget
Evaluierbar
Nein
eines
Tabelle 5.1: Realisierte Widgets und ihre Funktionen
WidgetController
Elementar für die Verkettung von (G)UIManager und Widgets ist der WidgetController. Normalerweise verwaltet der Manager alle Widgets und weiß, welches gerade aktiv und welche passiv sind, welche Steuerelemente hervorgehoben und selektiert worden sind. Über ihn können Tools und Controls gesteuert werden. Weil Interaktion und
116
Präsentation aber von Ereignismanager über Anwendungsmanager nur indirekt über den
(G)UIManager zu den Widgets kommunizieren, stopft der Controller das Kommunikationsloch. Denn Ereignisse sollen nach Design des Eventmanagement den Status eines
Widgets unmittelbar manipulieren und nicht den Manager. Der Controller fängt alle Ereignisse, die eigentlich für den Manager gedacht sind, ab und ruft dessen entsprechenden
Routinen auf. Die Informationskette bleibt wie vorgesehen bestehen.
Ansteuerung des ARBrowser
Die Technik des ARBrowser verlangt momentan die Einbettung von Augmentierungen als
statische Dateien in proprietären Formaten. Zwar lassen sich graphische Primitive wie in
XML definierte Pfeile und Kreise laden, aber zum einen müssen die Positionen der Objekte für jedes Referenzbild neu evaluiert werden und zum anderen entstanden Probleme
bei Löschung oder Überschreibung der Overlays. Die notwendige Verwendung statischer
Bilder erlaubt demnach keine direkte Interaktion mit Steuerelementen, sondern nur den
Austausch von Overlays mit unterschiedlichen semantischen Bedeutungen. Die semantische Relation muss also schon durch den Autor oder Graphiker hergestellt werden. Der
Algorithmus selbst muss Schlüsselwort und Name des Overlays im Dateisystem aufeinander abstimmen. Die Menüoverlays müssen als .NET-Controls definiert sein, damit der
Manager (bzw. der Anwender) mit ihnen interagieren kann. Z.B. sucht das Widget bei
Auswahl des Menüeintrags „Introduction“ nach dem Overlay mit gleichnamigem Wortbestandteil, während beim Durchlaufen des Menüs von der unsichtbaren Control auf ein
Overlay gleichen Namens bezogen wird. Die Wortbestandteile müssen also schon zur Designzeit bekannt sein. Sichtbar wird das Widget aber selbst nicht, da seine Größe auf (0,0)
gesetzt wurde.
Adaption an das Benutzerverhalten
Informationsinhalte sind abhängig vom Kontext, genauer gesagt von Position, Orientierung und Interesse des Besuchers an einem Standort auf der Ausstellung. Diese Schlüssel sind ohne Aufwand herauszufinden. Aufwendiger ist die automatische Adaption der
Schnittstelle an das Benutzerverhalten. So soll dem Anwender jederzeit bekannt sein, wel-
5.2. PRÄSENTATION
117
che Aktionen er im Augenblick mit welchen Geräten durchführen kann. Die Kommandohilfe müsste demnach ständig den Zustand der übrigen Widgets kennen. Zum Zeitpunkt
der Evaluation sind die Kommandos aber nur statisch in einer Konfigurationsdatei festgehalten, wie in Listing 5.7 zu sehen.
...
<Topics >
<Topic Name= " I n v e s t i g a t e " >
<Commands>
<Name> I n t r o d u c t i o n < / Name>
<Name>Annotation< / Name>
<Name>Go i n t o < / Name>
<Name>Timetravel < / Name>
< / Commands>
< / Topic >
...
<Topic Name= " Navigate menus " >
<Commands>
<Name>Previous< / Name>
<Name>Next< / Name>
<Name>Return< / Name>
<Name>Previous t o o l < / Name>
<Name>Next t o o l < / Name>
< / Commands>
< / Topic >
< / Topics >
...
Listing 5.7: Auszug aus der Konfiguration der Kommandoleiste
Signalisierung der Stimmlautstärke
Im Hinblick auf erkennungsbasierte, möglicherweise fehleranfällige Eingabedatenströme
sollte dem Anwender immer gezeigt werden, wenn das System ein Datum richtig erkannt
und es Probleme hat, den Datenstrom zu analysieren. Die Anzeige des Lautstärkepegels in
der Statusleiste reagiert auf die Lautstärke der Anwenderstimme und signalisiert (indirekt)
in einer Balkenanzeige die Qualität der Erkennung. Die Annahme ist, dass je stärker der
Pegel ausschlägt, desto besser kann die Stimme analysiert werden, unter der Voraussetzung, dass der Anwender artikuliert spricht und keine Nebengeräusche vorhanden sind.
118
Zur besseren Unterscheidung der „Qualitätsstufen“ symbolisieren rote Balken eine leise,
gelbe eine moderate und grüne eine gehobene Stimme. Dennoch wird durch das BioFeedbackWidget eine konstant laute oder leise Stimme als passive Benutzeraktion gewertet, die
es kommentieren wird.
5.2.3
Feedback Logging
Feedbacknachrichten werden an ein zentrales Logging-Modul (FeedbackLogger) der Applikationskomponente gesendet und an alle interessierten Beobachter verteilt, die sie darstellen können. Sender kann prinzipiell jede Systemkomponente sein, die dem Anwender das Feedback aber verständlich machen muss. In später Versionen könnte etwa das
Content-Modul von intCulture für jede Aktion nach einem Dialogprinzip (Frage-Antwort
/ Aktion-Reaktion) passendes Feedback liefern. Derzeit stehen Text und Audio als mögliche Wiedergabeformate zur Verfügung. Obwohl zu Beginn des Kapitels gesagt wurde,
dass Ausgabegeräte nicht angebunden werden, wurde zuletzt eine Klasse zur Ausgabe von
Audiodateien generiert, die diesen zugeordnet wurde. Die Regulierung der Lautstärke ist
aber weiterhin nicht möglich. Allerdings wird Audio nicht über den Gerätemanager angesteuert, sondern wird systemweit als bekannt vorausgesetzt. Es können nun eigene Audiodateien, die etwa die Kontextkomponente liefert, übergeben werden oder vordefinierte
Klänge (∼
= „Audio Cues“) abgespielt werden. Als Typen sind jeweils ein Warn-, Fehler-,
Selektions- oder Auswahlton möglich. Zur Wiedergabe wird DirectSound® der Microsoft
DirectX®-Komponente4 verwendet.
5.2.4
Sitenavigation
Die Sitenavigation in Form des ThumbnailMenuWidget ist die wichtigste Komponente,
um nach Informationen zu suchen. Es verhält sich wie ein „Bilderbuch“, durch welches
sich blättern lässt. Die Ausgabe von Kombinationen aus Miniaturbildern und Schlüsselwörtern beschränkt sich pro Seite auf drei bis vier, je nach Größe der Texteinheiten. Die
Miniaturbilder entsprechen den zu den Schlüsselwörtern zugehörigen Referenzbildern.
4
Informationen unter ( http://www.microsoft.com/windows/directx/default.aspx)
5.2. PRÄSENTATION
119
Wie im Konzept gewünscht, listet es alle enthaltenen POI eines AOI. Nachteilig zeigt
sich bisher, dass das Tool einen großen Teil des Bildschirms abdeckt. Es ist vertikal ausgerichtet, da Erfahrungen gezeigt haben, dass Anwender Informationen besser spaltenweise
als zeilenweise erfassen können (vgl. Zeitungslayout).
Wie man leicht feststellen kann, arbeiten die Widgets mit vielen anderen Komponenten zusammen. Teilweise reagieren sie nur und präsentieren dem Anwender eine andere „View“
(vgl. MVC-Pattern), teilweise manipulieren sie den Systemzustand. Widgets, deren Inhalte sich von Kontext zu Kontext ändern, müssen oft mit dem Content-Modul kommunizieren. Nach Design hat eigentlich nur die Applikationskomponente darauf Zugriff und alle
notwendigen Informationen sind in dem Exponatobjekt mit Bezeichner und Dateipfaden
enthalten. Bisher verfügt der Anwendungsmanager allerdings noch über kein Interface,
das die Widgets abfragen könnten. Stattdessen greifen sie direkt auf Media Management
und Site Management zu. Auch auf die meisten übrigen Komponenten wird ihnen derzeit
voller Zugriff gewährt, da die Routinen in einer korrekten Abfragesequenz schlichtweg zu
aufwendig wären.
120
Kapitel 6
Evaluation
Die Überprüfung der Bedeutung der Konzepte der Designphase erfolgt zum einen durch
die Implementation selbst, zum anderen durch die Bewertung durch potenzielle Benutzer.
Beide Varianten nehmen die vor dem Design aufgestellten Hypothesen (s. Kap. 4.1) als
Grundlage zur Verifizierung oder Falsifizierung.
Zuerst wird der Status des initialen Prototypen mit den Ideen aus der Designphase verglichen, insbesondere mit den Präsentationskonzepten aus Kapitel 5.2, und Stärken und
Schwächen der Umsetzung sowie etwaige verbesserte Konzepte und Ideen für kommende
Prototypen gezeigt. Zusätzlich bewerten zwei Testgruppen in Einzeltests die Funktionalität des Prototypen nach einem Testparcours anhand eines Fragebogens, der im Anschluss
ausgewertet wird.
6.1
Konzeptanalyse
Zur Konzeptanalyse werden ausgewählte Präsentationskonzepte mit ihren tatsächlichen
Umsetzungen im initialen Prototypen verglichen und Verbesserungen für zukünftige Entwicklungen vorgeschlagen.
121
122
6.1.1
KAPITEL 6. EVALUATION
Exponatmenü
Nach dem Konzept der „world-stabilized“ Elemente einer Benutzerschnittstelle wurden
Referenzbilder und Overlays eines Ausstellungsstückes mit transparenten, überlagerten
Menüs und Handlern versehen (siehe Abb. 6.3). Wie herkömmliche Overlays werden sie
getrackt. Sie sind in derselben Art und Weise ansprechbar wie alle übrigen Tools. Die
Handler erscheinen über dem getrackten Referenzbild, wenn ein Benutzer zum Exhibitmenü navigiert. Wird bereits ein anderes Overlay gerendert, lagern sie über diesem. Zwar
sind die Menüeinträge der Handler objektbezogen, verweisen aber noch nicht immer auf
spezifische Merkmale des Exhibit. Zum aktuellen Zeitpunkt ist lediglich ein Bezug vom
aktuellen Menüeintrag in der Sitenavigation und einem hervorgehobenen Hot Spot ohne
Beschriftung hergestellt, wie in Abb. 6.1 zu sehen (Hot Spots sind informationsrelevante Teile einer gegebenen Überlagerung, wie etwa die Metope eines Tempels, das Gesicht
einer Statue etc.). Signifikanterer semantischer Bezug wird erst durch den Zusatz von hervorgehobenen Hot Spots mit Beschriftung und direktionaler Information hergestellt. Die
Handler werden exakt dort positioniert, worauf die korrespondierende Aktion verweist.
Ein Mockup zu dieser Idee zeigt Abb. 6.2.
Abbildung 6.1: Hervorgehobene
Hotspots.
Abbildung 6.2: Hervorgehobene
Hotspots mit markanterem semantischem Bezug (Mockup).
6.1. KONZEPTANALYSE
123
Abbildung 6.3: Exhibitmenü in versteckter Ansicht.
6.1.2
Sitenavigation
Das Tool zur Sitenavigation erlaubt es einem Benutzer, die Hot Spots eines Areals oder eines spezifischen Exhibit aufzulisten und zu durchstöbern. Es wird automatisch aktualisiert,
abhängig von der aktuellen Position. Außerdem kann ein Benutzer jederzeit den Kontext
eines bereits besuchten Gebietes nochmals auflisten lassen. Zwar kann man die Position
des Tools jederzeit dynamisch ändern, durch seine vertikale Position kann es aber andere
Teile des Bildschirms verdecken. Ein Vorschlag wäre eine horizontale Positionierung im
oberen Bereich des Bildschirms (siehe Abb. 6.4). Dies könnte außerdem den Lesefluss in
Richtung unterem Bereich fördern.
6.1.3
„Schwebende“ Menüs
In Abb. 6.3 sieht man die Verknüpfung von Menühandlern und Overlay, die jedoch noch
keinen direkten semantischen Bezug zum Objekt haben. Als Alternative zeigt Abb. 6.5 die
Augmentierung sogenannter „schwebender“ Menüs („Flying menus“) in Form von „Notizzetteln“, die auf das korrespondierende Objekt deuten. Der Notizkopf bezeichnet das
relevante Objekt oder einen Hot Spot des Objektes. Darunter werden passende Sprachkommandos aufgelistet, zusammen mit Ikonen, die Kommandos für andere Geräte symbolisieren. Zusätzlich könnte eine Legende im Menü die Hintergrundfarben der Ikonen
124
Abbildung 6.4: Vertikale Sitenavigation (Mockup).
erklären, die sich jeweils auf ein anderes Gerät beziehen.
Abbildung 6.5: „Schwebendes“ Menü (Mockup).
6.1.4
Signalisierung der Stimmlautstärke
In Tests hat sich bei der Verwendung eines geräuschreduzierenden Mikrophons zur Spracheingabe herausgestellt, dass die Erkennung schon bei leisem bis halbwegs moderatem Sprechen korrekte Resultate liefert. Entgegen der Vermutung, dass der Anwender laut und klar
sprechen sollte, reicht eine präzise Artikulation zur korrekten Verarbeitung aus. Die Farbs-
6.1. KONZEPTANALYSE
125
kala sollte demnach - wie in den Lautstärkeskalen von HiFi-Verstärkern - bei leisem bis
angehend lauten Pegel grün und bei sehr lautem Pegel rot sein.
6.1.5
Transparenz
Im Designentwurf wurde ursprünglich vorgesehen, Steuerelemente der Schnittstelle transparent und ohne gruppierende Boxen oder Hintergründe darzustellen. Gruppierungen semantisch ähnlicher Elemente sollten sich durch Positionierung und Layout ergeben. Aufgrund des jungen, technisch noch unausgereiften .Net-Frameworks und der Eigenarten des
OpenGL-Rendering des ARBrowser, z.B. Double-Buffering) war eine zufriedenstellende
Umsetzung im Rahmen dieser Arbeit nicht möglich. So lassen sich zwar einzelne Steuerelemente wie Buttons oder Labels separat ohne Gruppierung auf dem Videobild rendern,
doch dazu müssen sie einzelne untergeordnete Controls des den ARBrowser einbettenden
Managers sein. Dies wiederum verstößt gegen das Konzept der Widgets, die als Sammlung
von einzelnen Elementen eine Gruppe bilden und innerhalb einer Box gerendert werden.
Jene Box kann nicht auf einfache Weise transparent dargestellt werden. Flimmern oder
„Cut-Outs“ des Videobilds sind die Folge, wenn die Elemente nicht einzeln „von Hand“
gezeichnet werden. „Von Hand“-Zeichnungen bedeuten, dass Controls als grundlegende
Elemente einer Windows-Anwendung als Zeichenobjekte und nicht mehr als Interaktionselemente gehandhabt werden. Dies hätte den Aufwand um ein vielfaches erhöht. Es wurden zwei Ansätze gefunden und implementiert, die versuchen, diese Problematik zu lösen.
Sogenannte No-Control-Widgets (NCWidget) sind nicht von der Basisklasse aller Controls abgeleitet und haben somit keine Gruppierung. Stattdessen rendert der Manager alle
in diesem Widget definierten Elemente einzeln. Probleme ergeben sich dann aber während der Interaktion, da der Manager jedes einzelne Element als Widget behandelt. Die
Ansteuerung über die CLV’s der Keymap ist damit nicht mehr gewährleistet. Weiterhin
waren Veränderungen in Position und Erscheinung eines NCWidget und seiner Kontrollen
nicht ohne größeren Aufwand zu rendern. Beispielsweise war als Alternative zur Sitenavigation mittels Thumbnails ein textuelles Hierarchiemenü vorgesehen, das alle Areale und
Ausstellungstücke vom äußeren Grenzbereich des Museums bis zur aktuellen Position anzeigt und sich infolgedessen kontinuierlich ändert. Als zweiter Ansatz sollte das Konzept
der Multi-Document-Interfaces (MDI) des .NET-Framework jedes Widget als separates
126
Fenster anzeigen lassen. Fenster sind die einbettende Instanz für alle Controls und können
ohne eigene Routinen auf Transparenz gesetzt werden. Doch dies gilt leider nur für das
„Wurzelfenster“ der Applikation.
Wie bereits festgestellt, sind Transparenzen innerhalb des .NET-Framework nur mit eigens
geschriebenen Zeichnungsroutinen zu erzeugen. Der Manager müsste die in einem Widget definierten Elemente einzeln rendern und sie während der Interaktion immer wieder
mit dem Widget identifizieren, um die korrekte Ereigniskette einzuhalten. Eine zusätzliche Routine im Manager wäre also nötig, um die einzelnen Elemente zu markieren und
sich stets ihren Status zu merken. Die Komplexität dieses Verfahrens scheint recht aufwendig. Eine andere Überlegung trennt sich vollständig vom GUI-Framework und sieht das
Rendern von Tools und Controls mittels in OpenGL geschriebenem Code vor. Der dem
ARBrowser zugrundeliegende AVALON-Renderer könnte diese Routinen interpretieren.
Eine Schleusung von eigenem Code in den Browser ist bisher aber noch nicht vorgesehen. Was für OpenGL gilt, könnte auch auf VRML zutreffen. Der VRML-Dialekt eröffnet
auch noch viele weitere Optionen, die Schnittstelle um Funktionalität zu erweitern. Dies
gilt insbesondere für dreidimensional gerenderte Augmentierungen.
6.1.6
3D-Rendering
Theoretisch wäre es möglich gewesen, vorgerenderte dreidimensionale Objekte als Overlays zu verwenden und korrekt zu augmentieren. Praktisch wäre der Aufwand allerdings
nicht im Zeitrahmen dieser Arbeit geblieben. Mindestens zwei Kameras sind notwendig,
um Position und Orientierung des Anwenders dreidimensional zu bestimmen und die Koordinaten für das Overlay mittels epipolargeometrischer Berechnungen im zweidimensionalen Videobild festzulegen. Das Konzept der Handlermenüs hätte sich mit dieser Methode ähnlich wie in Abb. 6.6 und Abb. 6.7 umsetzen lassen können.
Das Mockup der Innenansicht gibt nicht vollständig wieder, wie das Konzept zu verstehen
ist. Es handelt sich um ein dreidimensionales Objekt, dessen vorderen Flächen, die die
hinteren verdecken, verschwinden und dafür die Ansicht der Innenräume aufdecken. Der
Guide behandelt die aufgedeckten Objekte dann als eigenständige Ausstellungsstücke, mit
127
6.1. KONZEPTANALYSE
Abbildung
6.6:
Handlermenü
am
dreidimensionalen
Objekt
(Mockup).
Abbildung 6.7: Innenansicht eines
Objektes (Mockup).
denen wie mit der äußeren Pyramide interagiert werden kann. Die Sitenavigation springt
eine Ebene tiefer. Die Objekte sollten sich zoomen und rotieren lassen und die gleichen
Medien beherbergen wie alle anderen Exponate.
6.1.7
VRML
Einschleusung von in VRML formulierten dreidimensionalen Szenarien in den ARBrowser könnte die Verwendung des GUI-Toolkits des .NET-Frameworks vollständig ablösen.
Es ist darauf zu achten, dass getrackte und ungetrackte Objekte gerendert werden müssen,
zur Erhaltung des „world-stabilized“-“screen-stabilized“-Prinzips. Das Format bietet alle
Vorteile dreidimensionaler Interaktionen, wie etwa Animationen, Skalierungen, Rotationen, Löschen und Hinzufügen anderer Objekte. Dies mag die Absicht unterstützten, für
Ausstellungsbesucher einen höheren Lern- und Erlebniseffekt zu erzielen.
6.1.8
Nicht realisierte Konzepte
Einige vorgeschlagene Konzepte konnten innerhalb des vorgegebenen Zeitrahmens nicht
realisiert werden. Entgegen den im Anwenderszenario 4.4 erwähnten Vorschlägen blei-
128
ben Navigations- und Orientierungsinteraktionen auf ein einzelnes Exponat und dessen
Hot Spots beschränkt. Daher integriert der vorliegende Prototyp auch noch kein räumliches Audiofeedback, das von den Daten von GPS und Kompass abhängig ist. Desweiteren
fehlt es an Audiokommentaren, die aber Teil des Repository und somit Teil von intCulture
sind. Dreidimensionale Modelle, ob getrackt oder im Showcase, werden ebenso Aufgabe
zukünftiger Entwicklungen sein.
6.2
Benutzertests
Um die vor der Designphase aufgestellten Hypothesen überprüfen zu können, ist in erster
Linie die Erprobung und Bewertung durch potenzielle Benutzer notwendig, also geschichtsund kulturinteressierte Reisende, Gelegenheitsbesucher, Pauschaltouristen, Studienreisende, Kinder, Jugendliche, Erwachsene etc. Prinzipiell muss für ein aussagekräftiges Ergebnis ein breites Spektrum an Erfahrungen und Erwartungen an die Themen Tourismus,
Kulturgut und Mobile Equipment abgedeckt werden. Im Rahmen dieser Arbeit ist ein Test
an einer historischen Stätte oder in einem Museum mit vor Ort präsenten Testpersonen allerdings nicht möglich gewesen. Zum einen aus zeitlichen Gründen, zum anderen, weil die
inhalteliefernde Komponente von intCulture noch nicht integriert ist. Außerdem sind die
Ortungskomponenten noch nicht angeschlossen. Tests vor Ort wären dennoch möglich, allerdings wurde schon bei ersten Versuchsläufen vor der eigentlichen Befragung bemerkt,
dass selbst geringfügige Schwächen, die vielleicht nur eine Änderung in der Konfiguration bedeuten, die Wahrnehmung und Informationsaufnahme deutlich beeinträchtigen. Die
Erprobung verschiedener Konfigurationen in Testläufen ist also eigentlich notwendig. Daher beschränkt sich die erste Befragung auf zwei kleine Benutzergruppen von jeweils 7
Testpersonen, die allesamt aus der Berufsgruppe Ingenieur / Informatiker stammen. Vor
Beginn des Tests wurden die Kandidaten kurz über die prinzipielle Verwendung von Sprache und Maus / RC und die zu verwendenden Tools informiert. Ebenso wurden sie auf
bekannte Einschränkungen des Systems, wie partiell nicht vorhandener Content zu Kommandos und Controls sowie die fehleranfällige, sprecherabhängige Spracherkennung hingewiesen. Zur Minimierung derer Fehlerquote wurden vorab zwei Sprachprofile erstellt,
von einer griechisch männlichen und einer griechisch weiblichen Stimme. Personen mit
129
6.2. BENUTZERTESTS
akzentfreierem Englisch wurde ein deutsch männliches Profil zugeteilt. Die Sprache der
Schnittstelle selbst ist in Englisch gehalten.
Abbildung 6.8: Erklärung von Tools,
Controls und Verwendung der Eingabegeräte.
Abbildung 6.9: Erklärung des Exhibitmenü und der Versteckfunktion.
Abbildung 6.10: Erklärung der augmentierten Ansicht.
Nach Feststellung von Stärken und Schwächen des Designs bzw. Verifizierung der Hypothesen zeigen sich dann die Konsequenzen für kommende Weiterentwicklungen.
130
6.2.1
Testparcours
Nach Anpassung der Konfigurationen nach dem Testlauf mit einer Versuchsperson wurden die Kandidaten, die den Fragebogen zur endgültigen Analyse beantworten würden,
gebeten, den Test indoor und stationär vorzunehmen. Sie wurden mit unterschiedlichen
Gerätschaften ausgestattet. Ein mobiler Parcours hätte, so die Vermutung, mit dem aktuellen Prototypen keinen Vorteil oder mehr Realitätsnähe erbracht. In einem Halbkreis
wurden 3 verschiedene “Ausstellungsstücke„ positioniert. Die einzige Aufgabe bestand
darin, möglichst viele Informationen über die einzelnen Standorte und ihre Merkmale zu
sammeln und währenddessen eine Idee zur Funktionalität des Systems zu bekommen.
Das gesamte Testfeld wurde in zwei gleichgroße Gruppen aufgeteilt. Erstere wurde mit
Abbildung 6.11: Erprobung der Schnittstelle im Test.
Abbildung 6.12: Testkandidatin während der Evaluation.
einem Video-See-Through-HMD und einer standardmäßigen Desktop-Maus ausgestattet,
letztere mit einem Video-See-Through-Binocular und einer Fernbedienung mit eingebautem Bewegungssensor, sowie beide mit einem Single-Sided-Headset. Die RC war für die
erste Testgruppe noch nicht verfügbar. Wegen technischer Schwierigkeiten konnte die Gyration UltraGT Maus nicht eingesetzt werden. Vorab lässt sich bereits festhalten, dass
keine eindeutig „perfekte“ Konfiguration der Geräte gefunden werden konnte. Der HMD
wurde den Benutzern stets zu schwer und drückte so sehr, dass er von der eigentlichen
Information zu sehr ablenkte und zu den Binoculars gewechselt wurde. Die Binoculars
6.2. BENUTZERTESTS
131
wiederum erfordern die Betätigung des Ausgabegerätes anstatt sich auf die Eingabemodi
zu konzentrieren.
6.2.2
Konzept des Fragebogens
Zu jeder Hypothese wurden diverse zu verifizierende oder falsifizierende Fragen aufgestellt. Einige Thesen konnten mit gleichen Fragen überprüft, wiederum andere durch Design und Implementierung bestätigt werden. Die Testkandidaten konnten zu jeder Frage
eigene Kommentare und Verbesserungsvorschläge abgeben. Teilweise waren Inhaltsfragen zu beantworten. Auf Auffälligkeiten wird gesondert eingegangen.
6.2.3
Auswertung
Die Erfüllung der in 4.1 erwähnten Grundsätze und Kategorien werden zusammenfassend
bewertet. Die ausführlichen, statistischen Ergebnisse der Fragen zu einzelnen Hypothesen
sind in Anhang G zu finden. Einen Überblick über die wichtigsten Ergebnisse geben die
Diagramme 6.13 bis 6.19.
Die Auswertung wird anhand der Gesamtergebnisse beider Testgruppen durchgeführt, da
Vor- und Nachteile der gewechselten Ein- und Ausgabegeräte bekannt sind. Auf Untersuchungen, die sich speziell auf die Eingabegeräte beziehen, wird gesondert eingegangen.
Desweiteren waren einige Kandidaten unentschieden oder haben Teile der Schnittstelle
separat bewertet.
„Ein Dialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seine
Arbeitsaufgabe effektiv und effizient zu erledigen.“
Aufgabenangemessenheit bedeutet in erster Linie, dass die Elemente der Schnittstelle den
Benutzer nicht bei der Lösung seiner „Aufgabe“ behindern. Das Bedürfnis eines Besu-
132
Abbildung 6.13: Benutzerfreundlichkeit.
Abbildung 6.14: Erfüllte Erwartungshaltung.
chers besteht im Speziellen darin, möglichst viele Informationen über ein Ausstellungsstück zu erfahren, und zwar, ohne dass seine reale Sicht auf das Objekt eingeschränkt
wird. 9 von 14 Benutzern wurden durch die sichtbaren Elemente bzw. Tools nicht in ihrer Sicht auf das Geschehen am Objekt behindert. Die Positionierung der Sitenavigation
war der einzige Kritikpunkt für die übrigen. Eine Alternative wurde bereits in Abschnitt
6.1 vorgestellt. Die Option zum Verstecken der Elemente konnte von 12 Benutzern leicht
gefunden werden, wurde aber nicht immer und stetig angewendet. Transparente Menüs
oder ein interaktiveres, augmentiertes Menü scheinen eine Alternative, da sich der Fokus
dann auf eine Sicht konzentriert und nicht zwischen „Show“ und „Hide“ geschaltet werden müsste. Ein Kandidat schlug vor, die Elemente separat einund ausschalten zu können.
Hinsichtlich ihrer Verwendbarkeit hatten 12 Personen einen positiven Eindruck von den
visuellen Tools. Negativ wirkten sich lediglich mangelnde Mediainhalte und - wie schon
erwähnt - die Größe der Sitenavigation aus. Parallel aufgetretene Redundanz bei Menüeinträgen in der Sitenavigation und im augmentierten Ausstellungsstückmenü irritierte manche Benutzer. Die Selektionsoption war nicht eindeutig. Da sich jene beiden Menüarten
auch hinsichtlich der Darstellungsform (statisch fixiert - dynamisch getrackt) unterscheiden, war der Vorgang des Wechselns vom einen zum anderen Tool nicht immer offensicht-
6.2. BENUTZERTESTS
Abbildung 6.15: Bevorzugte Eingabegeräte.
133
Abbildung 6.16: Leichte Gewöhnung an
die Eingabegeräte.
lich. Manche Benutzer schlugen die Augmentierung der Sitenavigation sowie abwechselndes Hervorholen des aktiven und Verstecken der passiven Tools zur Orientierung vor.
An die Spracheingabe gewöhnte sich das gesamte Testfeld sehr schnell, lediglich ein Benutzer hat Sprache überhaupt nicht verwendet. Dagegen hatten mehrere Benutzer anfangs
Schwierigkeiten mit der Maus- bzw. RC-Eingabe. Die meisten mussten sich ergo an die
Bedienung der Geräte nach der kurzen Einführung erinnern. Grundsätzlich wurde eine
kurze Trainingsphase benötigt. Zum einen lag dies an mangelndem Kontrast im Blickfeld,
so dass nicht ersichtlich war, welches Tool und welche Controls gerade aktiviert waren,
zum anderen an der Belegung der Maustasten. Die RC wurde allerdings besser als die
Maus angenommen, obwohl das Binocular mit einer Hand festgehalten werden musste.
Der Großteil beider Gruppen war zufrieden mit den Reaktionen des Systems auf angeforderte Informationen. Wie schon zur Testeinführung geschildert, zählt zur Erwartungshaltung primär passender und variierender Content, aufgrund dessen manchem Benutzer
nicht ersichtlich war, wie eine adäquate Reaktion auszusehen hat. Einige HMD-Träger berichteten zudem von Konzentrationsschwierigkeiten auf die eigentlichen Inhalte durch das
Gewicht des Geräts. Demgegenüber hat das System kaum irrelevante oder unaufgeforderte
134
Abbildung 6.17: Immersionsgefühl.
Abbildung 6.18: Intuitive Interaktion.
Information geliefert. Lediglich die Hilfefunktion benötigt eine Verbesserung.
Aus den Ergebnissen kann man schließen, dass der Dialog der gestellten Aufgabe angemessen ist. Die Benutzer waren in der Lage, an erwünschte Informationen mit mindestens einem der Eingabegeräte zu gelangen. Nachbesserungsbedarf besteht hinsichtlich des
Kontrastes zwischen aktiven und passiven Elementen, der Belegung der Eingabetasten für
Maus und RC sowie in der Positionierung der Sitenavigation. Jede dieser Schwächen kann
mit Hilfe einer geänderten Konfiguration behoben werden. Dennoch ist eine Änderung des
Highlighting von Tools und Controls, beispielsweise eines Rahmens oder eines „Aktiv“Icons (siehe Abb. 6.20), in Erwägung zu ziehen. Ebenso kann über eine Alternative zu
Maus und RC nachgedacht werden, wie etwa die Integration der Knöpfe am Binocular.
Sehr positiv zeigt sich, dass niemand Probleme mit der direkten Anwendung von Sprache
hatte.
„Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt
durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem
Benutzer auf Anfrage erklärt wird.“
6.2. BENUTZERTESTS
135
Abbildung 6.19: Multimodales Interaktionsgefühl.
Abbildung 6.20: „Aktiv“-Icon (Konzept)
Die Repräsentation der Sprachkommandos in Form von farblich hervorgehobenem Text
erwies sich als sehr hilfreich. Der Bezug war im allgemeinen intuitiv. Dennoch wünschte
sich nahezu die Hälfte aller Tester nähere Erläuterungen zu ihren Bedeutungen, insbesondere für die Topics in der angedachten Hilfe zu den Sprachkommandos. Andere Formulierungen benötigen hingegen „Annotation“ und „Go into“. Die Kommandos waren
einprägsam, 4 Benutzer konnten sich sogar an mehr als 10 Kommandos nach dem Test
erinnern.
Dem Grundsatz der Selbstbeschreibungsfähigkeit ist nur eine konkrete Hypothese zugeordnet. Er wird unter anderem durch die folgenden Abschnitte über Fehlertoleranz und
Benutzerführung ergänzt.
136
Steuerbarkeit
„Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf
zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das
Ziel erreicht ist.“
Den Untersuchungsergebnissen folgend war der Dialog konsistent genug, um zu jeder vorhandenen Information zu gelangen. Eine Eingewöhnungsphase scheint jedoch immer erforderlich, insbesondere im Hinblick auf die Eingabegeräte, hier vor allem Maus und RC.
Die Kandidaten mussten weniger darüber nachdenken, welche Elemente sie selektieren
mussten als wie sie zu einem bestimmten finalen Punkt gelangen würden. Bemerkt wurde,
dass es sich sowohl bei Interaktion als auch bei Präsentation um neuartige Technologien
handle, mit denen man bisher noch nicht konfrontiert wurde, vor allem die Abstraktion
von Gerät über die augmentierte Ansicht zu Menüstrukturen.
Zur Positionierung der Tools und ihrer Controls gab es unterschiedliche Meinungen, insbesondere zur Anbringung der Sitenavigation vertikal auf der linken Seite des Bildschirms.
Die einen irritierte es nur am Anfang, die anderen gelegentlich, wenn sie z.B. eine freie
Sicht haben wollten. Ein Benutzer äußerte, dass die Kombination von Bild und Text als
Menüelement bereits zu viel an Information sei, die beschränkt werden könne, um mehr
Platz auf dem Schirm zu schaffen. Die Navigationselemente „Previous“ und „Next“ waren
in geringem Maße nicht erwartungskonform, denn erwartet wurde gelegentlich ein Wechsel des Overlays. Dagegen war den meisten offensichtlich, welches Tool welche Funktionalität besitzt. Mit der Suche nach einer Funktion verbanden die meisten auch die längere
Navigationszeit mit Maus oder RC im Vergleich zu Sprache.
Fast alle Benutzer waren in der Lage während des Tests mit anderen umgebenden und
nicht beteiligten Personen zu kommunizieren. Gelegentlich zeigte das System etwas unkontrolliertes Verhalten, was darauf zurückzuführen ist, dass vergessen wurde, das Mikrophon auszuschalten, wenngleich ausnahmslos alle die Funktion zum An- und Ausschalten
der Peripherie entdeckt hatten. Eine Testperson hatte vorgedacht und sich gefragt, wie das
Mikrophon wieder angeschaltet werden könne. Desweiteren ist aufgefallen, das wenige
6.2. BENUTZERTESTS
137
die Funktion konstant verwendet haben, vielmehr haben sie sie nur überprüft.
Das eingeschränkte Sprachvokabular erleichterte fast allen die Erinnerung an Kommandos. Auch hier gilt der Satz, je mehr Training, desto gefestigter die Erinnerung. Knapp ein
Drittel versuchte andere als die vorgegebenen Kommandos. Verursacht wurde dies zum
einen durch mangelnden Kontrast zwischen blauen und schwarzen Schriftzügen, zum anderen hat das System während eines kontinuierlichen Sprachflusses, z.B. bei der Diskussion mit anderen Personen, gespeicherte Kommandos erkannt.
Fast alle Testpersonen hielten Sprache und Maus / RC für angemessene Eingabegeräte,
allerdings mit der Einschränkung, dass Maus / RC das weniger bequeme und intuitive von
beiden sei. Funktionen an den Geräten selbst wurden nicht vermisst, lediglich eine Person fände die Interaktion mit einem Gamepad besser. In diesem Zusammenhang haben
sich einige zusätzliche Funktionen wie eine Navigationshilfe („Wo kann ich als nächstes hingehen ?“), kontextsensitive Hilfe zu allen UI-Elementen sowie mehr Mediainhalte
gewünscht. Zu überlegen ist, ob der Zugang zu diesen Funktionen ohne visuelle Repräsentation nicht direkt auf das Eingabegerät selbst ausgelagert werden kann, um immer
verfügbar zu sein.
Niemand hatte demnach ernsthafte Schwierigkeiten, Inhalte zu finden. Die Schnittstelle
war stets präsent. Probleme gab es hinsichtlich der Interaktion mit der Maus / RC und
gelegentlichen Verwirrungen bei der Aktivierung des nächsten Tools oder Control. Ein
paar Tester äußerten , dass eine intuitivere Analogie zwischen den Repräsentationen einer
Control in der UI und am Eingabegerät diese Schwächen korrigieren könnten.
„Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.B. den Kenntnissen aus dem Arbeitsgebiet, der
Ausbildung und der Erfahrung des Benutzers sowie den allgemein anerkannten Konventionen.“
138
Bedenkt man die unterschiedlichen Erfahrungswerte der potenziellen Zielgruppe - nicht
unbedingt die der nahezu homogenen Testgruppen -, so kann man, da kein detailliertes
Wissen über deren Erfahrungsschatz vorhanden ist, nur mutmaßen, ob der Dialog erwartungskonform ist. Daher wurden die Kandidaten lediglich gefragt, ob das Testsystem die
Erwartungen erfüllt hat, die jeder nach der kurzen Einführung mitgebracht hatte. Mehr als
dreiviertel waren zufriedengestellt. Problematisch waren - so auch in der Testeinführung
erwähnt - die fehlenden Inhalte. Es zeigt sich, dass die Benutzer den höchsten Anspruch
an die zu präsentierenden Siteinformationen haben. Mängel in der Interaktion wurden an
dieser Stelle nicht festgestellt.
Fehlertoleranz
„Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz
erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem
Korrekturaufwand durch den Benutzer erreicht werden kann.“
Eine Maxime für diese Arbeit lautete, dass ein Benutzer keine fehlerhaften Eingaben machen kann, da das System die Korrekturen automatisch vornimmt oder zumindest Lösungsvorschläge präsentiert. Eine positive Einschränkung auf Systemseite ist außerdem,
dass der Benutzer keine dynamischen Daten hinzufügen kann. Eher wird statisch auf Ereignisse reagiert, sprich jede fixe Eingabe hat eine fixe Ausgabe zur Folge. Daten müssen
nicht überprüft werden. Was also berichtigt werden müsste, ist das Verhalten des Systems
selbst, etwa, wenn es einen Befehl nicht versteht und nur eine vage Prognose geben kann.
Dies ist weniger Korrektur als die Bestätigung nach einer Eingabe durch den Benutzer.
Das benutzerführende Konzept der Validierung von Spracherkennungshypothesen etwa
(s. Abschnitt 4.5.2) konnte in diesem Prototypen noch nicht implementiert werden.
Um den Benutzer zu führen und ihn auf seinen Status und den des Systems hinzuweisen,
wurden diverse Formen von Feedback integriert, wie etwa Textnachrichten, Audiosignale
und farbliche Hervorhebungen. Als störend empfand diese automatische Funktion eigentlich niemand. Zwei Benutzer waren unentschlossen. Einige Benutzer haben die Textnachrichten zum Lernen des Systems benötigt, andere sahen in akkuratem Tracking eine Form
6.2. BENUTZERTESTS
139
von Feedback. Bis auf eine Person fanden alle Form und Inhalt des Feedbacks hilfreich,
mehr allerdings für die Kenntnis des eigenen Status als für Orientierung und Navigation.
Die Anzahl relevanter Informationen für Orientierung und Navigation beschränkte sich
eher auf simple Positionsangaben im Sinne von „You are in area...“ oder „You can see the
exhibit’s items“. Navigationsfunktionen für eine vollständige Orientierung auf einer komplexen Site werden mit der Anbindung von intCulture realisiert. Wie ein Benutzer festgestellt hat, ist das System momentan mehr reaktiv als proaktiv und schlug die Kombination
von Lokalisationspunkten und Beschreibungen auf einer Navigationskarte vor, womit auch
das Sitenavigationstool überflüssig wäre. Ein solcher Ansatz wurde schon einmal im Anwenderszenario in Kapitel 4.4 verfolgt, aufgrund bereits vorhandener intCulture-Konzepte
aber nicht integriert.
Das System toleriert „Fehler“ also bereits durch die Filterung von Eingaben. In diesem
Sinne liegen die Fehler also im System selbst, etwa wenn, wie schon erwähnt, passende
Inhalte fehlen.
„Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an
die Erfordernisse der Arbeitsaufgabe, individuelle Vorlieben des Benutzers
und Benutzerfähigkeiten zulässt.“
Beide bereitgestellten Interaktionsmodi wurden von den Testpersonen verwendet. Der
überwiegende Teil, nämlich 10 Kandidaten, tendierte zur Spracheingabe, während 2 die
Maus und 2 weitere die RC favorisierten. 11 von ihnen haben erwogen, beide Geräte zu
verwenden, 2 haben sich unmittelbar für Maus / RC und eine Person für Sprache entschieden. Mehr als die Hälfte benötigte beide Modi, meistens, wenn der jeweils andere nicht
ordentlich funktionierte. Es fiel auf, dass von einigen Benutzern entweder Sprache oder
Maus / RC absichtlich vermieden wurde. Es ist also tatsächlich so, dass eines der Geräte
immer als Alternative und zur Umgehung des anderen Schwächen verwendet wurde. Da
für den Test keine aktive multimodale Interaktion bereitgestellt wurde, konnte man aber
nur aktiv unimodal agieren.
140
Die wenigsten Benutzer waren an selbstständiger individueller Positionierung der Tools
interessiert. Stattdessen bevorzugten fast alle ein automatisches Layout, entweder anhand
von Vorschlägen durch das System oder nach Profilierung. Die Vermutung war folglich
korrekt, dass freie Individualisierbarkeit in diesem Anwendungsfall nicht relevant ist.
Eine überlegtere Verteilung der Tools würde auch dem Manko helfen, dass viele Benutzer
durch die Position der Sitenavigation so sehr abgelenkt wurden, dass sie es gerne separat
versteckt hätten. Dennoch waren sie mit dem Layout der Tools selbst zufrieden.
Individualisierung gehört nicht zu den notwendigen aktiven Bedürfnissen der Testpersonen. Personalisierung kann automatisch durch das System erfolgen, je nach Präferenzen
eines Benutzers. Vielmehr verlangten die Benutzer Interaktionsvielfalt und Unabhängigkeit in der Ansteuerung. Die Tendenz geht also in Richtung mehrerer Eingabemodi und
automatischer UI-Anpassung auch während der Benutzung unter Verwendung passiver
Modi.
Lernförderlichkeit
„Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet.“
Nach der Einführung waren die Testpersonen auf sich allein gestellt. Das Hilfesystem gehört nicht zu den vorgestellten Designkonzepten und präsentiert sich als Slideshow der
Einführungsfolien, die mittels „Help“ im Statustool abgerufen werden können. Es wurde
noch kurz vor dem Test implementiert. Das Feedback in Form von Kurztext, Audio und
Highlighting sollte demnach zur Anleitung ausreichen.
Die Hervorhebung von Sprachkommandos in blauem Schriftzug fanden alle Benutzer
sinnvoll, die Sprache verwendet haben. Die Kontrastschwäche erschwerte allerdings deren
Erkennung. Sie ist aber teilweise bedingt durch die kontrastarmen Displays. Die Mehrheit
der Benutzer musste sich nach Trainingsphase aber nicht mehr an dieses Feature erinnern,
6.2. BENUTZERTESTS
141
um zu erkennen, dass es sich um ein Sprachkommando handelte. Ein Benutzer ging davon
aus, dass jedes Textelement ein Kommando repräsentiert.
Das Highlighting von Tools und Controls wurde bereits zuvor diskutiert. Die Kontrastschwäche und die Auswahl der Farben ließ nicht immer eine eindeutige Unterscheidung
der aktiven und passiven Elemente zu.
Da intCulture noch nicht angebunden war, konnte zudem nicht überprüft werden, ob die
Benutzer sich an die präsentierten, objektbeschreibenden Informationen erinnern konnten.
Wiedergegebene Medien hatten stets denselben Inhalt.
Bisher ist der Dialog also nur begrenzt lernförderlich. Insbesondere die Kontrastschwäche
führte zu Irritationen. Wie schon vorgeschlagen, ist auch an Alternativen zur Farbhervorhebung zu denken.
Benutzerführung
Benutzerführung ist eigentlich ein separates Kapitel in der softwareergonomischen Analyse. Das Europäische Komitee für Normung hat hierzu eine eigene Richtlinie [fN98b]
herausgegeben. Im Rahmen dieser Arbeit werden deren Grundsätze aber nicht im einzelnen analysiert. Der Prototyp ist in einem noch zu jungen Entwicklungsstadium. Stattdessen
wurden beispielhafte Fragen zu diversen Konzepten gestellt.
Adäquate Benutzerführung sollte in erster Linie durch die drei Feedbackformen gewährleistet werden. Die „Audio Cue“s beschränkten sich im Test allerdings auf kurze Signaltöne anstatt gesprochenem Text.
Die Formen und Präsentationen des Feedback empfanden die meisten Benutzer als hilfreich und passend. Insbesondere Textfeedback hat vielen zum Verständnis ihrer Interaktion
weitergeholfen. Wie schon mehrmals erkannt, störte aber der mangelnde Kontrast im Display bei der Erkennung der aktiven und passiven Farbschemata. Das Audiofeedback haben
einige Benutzer nicht bemerkt oder „falsch“ interpretiert. Wiederum andere sagten, dass
142
es nach einer Weile nicht mehr benötigt werden würde. Daraus lässt sich schließen, dass
zum einen eine begrenzte Anzahl an Feedbackmodi ausreicht und zum anderen, dass der
Inhalt des Feedback präzise formuliert sein muss.
Die Wahl der Feedbackinhalte scheint insofern eine Aufgabe für zukünftige Prototypen.
Es ist darauf zu achten, dass mit fortgeschrittener Anzahl an Tools und Interaktionsmöglichkeiten auch die Quantität des Feedback steigen muss. Die meisten Benutzer fanden die
bisherigen Feedbackinhalte passend zu ihren Aktionen, einige andere störte aber das Audiofeedback oder vermissten Reaktionen des Systems. Jene Reaktionen müssen sich nicht
immer in der Form von aktivem Feedback äußern. Schon passive Reaktionen wie die Präsentation von passendem Content reichen als Bestätigung aus. Weiterhin ist zu überlegen,
wie das System auf nicht erkannte Eingaben reagieren soll, etwa wenn die Spracherkennung stockt.
Die Vermischung von Videobild, augmentierten und statischen UI-Elementen kann den
Benutzer beim Wechseln des Fokus irritieren. Die meisten Kandidaten mussten nur gelegentlich nach dem gerade aktiven Tool suchen. Einige andere wurden aber inbesondere durch die Redundanz von Einträgen im letzten Hierarchielevel der Sitenavigation und
des Ausstellungsstückmenüs abgelenkt. Ein Benutzer hat vorgeschlagen, den Bereich mit
Steuerelementen und den mit Videobild von vornherein voneinander abzugrenzen.
Die Aufteilung der Steuerelemente in „world-stabilized“ und „screen-stabilized“ hat der
Mehrheit dazu geholfen, die kontext- und objektbezogenen Informationen zu unterscheiden. Dennoch mussten 3 Probanden den Fokus wechseln und wurden dadurch beeinträchtigt. Wiederum die Sitenavigation hat zu dieser Irritation beigetragen.
Einige der aufgestellten Hypothesen können schon durch die Implementation überprüft
werden oder sind nicht durch subjektive Benutzerfragen zu beantworten. Sie werden anhand der Erfahrungen während Benutzer- und Implementationstests im Anschluss an die
Auswertung der Fragebögen bewertet.
6.2. BENUTZERTESTS
143
Es wurde davon ausgegangen, dass sich die Benutzer durch die multimodale Dateneingabe, insbesondere von Sprache, immersiver in der Umgebung fühlen. Lediglich 5 Personen
konnten dies bestätigen, 6 haben dies nicht empfunden und 3 waren unentschlossen. Die
Ursache lässt sich allerdings nur aus den bisherigen Ergebnissen erahnen. Zum einen waren die Displays sowohl des HMD als auch der Binoculars sehr kontrastarm, insbesondere
verglichen zu Versuchen auf einem herkömmlichen Laptopdisplay. Ebenso waren die Helligkeitsunterschiede zwischen aktivem und passivem Highlight nicht deutlich genug. Darüber hinaus muss von Maus und RC zur visuellen Interaktion mit der Schnittstelle noch
stark abstrahiert werden. Betrachteten die Benutzer die Umgebung durch das Fernglas,
konnte man beobachten, dass es ihnen schwer fiel, gleichzeitig die RC zu bedienen. Andererseits störte das Gewicht des HMD die Konzentration auf die Interaktion. Zwar wurden
vorher Versuche mit einem Gamepad unternommen, doch wurde dies für die Benutzertests ausgeschlossen, weil einhändige Bedienung schwierig und die Funktionsvielfalt zu
opulent ist. Beidhändig wäre es nur für den HMD in Frage gekommen, den viele Benutzer
wiederum nach einer Weile festgehalten haben, weil er auf die Nasenflügel drückte.
Wenn sich ein Kandidat immersiv fühlte, so lag der Grund meist in der Augmentierung
der Overlays, also der „screen-stabilized“ Elemente. Für andere war es dann aber eine
Schwierigkeit, das Overlay aufgrund von Verwacklungen beim Tracking zu fokussieren.
Ideen zur Verstärkung des Immersionsgefühls werden am Ende der Arbeit in Kapitel 8
vorgestellt.
Es hat sich bereits herausgestellt, dass für benutzerfreundliche Funktionalität Daten nicht
notwendigerweise multimodal eingegeben werden müssen, wenn sie geringfügig komplex
sind. Etwa sind derzeit weder temporäre noch räumliche Angaben zu machen. Demnach
besteht die Multimodalität darin, dem Benutzer die Wahl des Eingabegerätes zu überlassen, abhängig von seinen Präferenzen und unabhängig vom Status der Schnittstelle. Darüber hinaus erlaubt die Schnittstelle die Verknüpfung mit passiven Eingabedatenströmen,
woraus sich die Definition eines „blended multimodal user interface“ ergab. Derzeit wird
dieser Datenstrom aber auch nur separat für die Analyse des Benutzerverhaltens verwendet und nicht in Kombination mit dem aktiven Strom. Dennoch haben 10 Tester angege-
144
ben, multimodal interagiert zu haben, weil sie mehr als ein Gerät verwendeten. Insgesamt
8 meinten, dass sie das Eingabegerät häufig während des Test wechselten. Den Begriff
„simultane Verwendung“ hat man unterschiedlich aufgefasst. Einerseits impliziert es Parallelität während der Dateneingabe, andererseits Parallelität im Verlaufe des Tests, also
eher alternativ. 10 Personen sagten demnach, dass sie nicht simultan interagiert haben.
Insgesamt empfanden aber 11 Kandidaten die Interaktion mit mehr als einem Eingabegerät komfortabel. Die übrigen haben stets nur ein Gerät verwendet. Ein Benutzer erwähnte,
dass die Interaktion besonders im Zustand des Laufens schlicht gehalten werden sollte.
Daraus lässt sich z.B. ableiten, dass die etwas längeren Mauseingaben hier vermieden
werden sollten, wie etwa das Scrollen durch Tools und Controls.
Die meisten Benutzer haben nicht mitbekommen, dass ihre Stimmlautstärke gemessen
wurde, obwohl ebenso viele den Pegel des Mikrophons gesehen hatten, nicht aber, dass
der Guide mit Textfeedback reagiert, wenn der Pegel eine gewisse Schranke über- oder
unterschreitet. Die Frage war hier nicht präzise genug gestellt.
Für den Test wurde keine multimodale Verkettung von Befehlen verwendet, dennoch muss
in diesem Stadium schon auf Ambiguitäten geachtet werden. Fast alle Tester konnten hier
keine Doppeldeutigkeiten feststellen, die Auswahl der Kommandos war präzise und eindeutig. Ebenso wurden sie als konsistent und gut verständlich empfunden. Einzig die Bedeutung der Topicnamen für die Kommandohilfe war nicht ganz klar. Dies hat aber keinen
Einfluss auf die multimodale Verarbeitung.
Eine weitere Vermutung war, dass eine multimodale Schnittstelle die Benutzung freundlicher und intuitiver gestaltet als eine unimodale. Der Vergleich konnte im Test nicht direkt
hergestellt werden. Alle Benutzer äußerten also, dass die Schnittstelle in ihrem jetzigen
Status durchaus benutzerfreundlich sei, allerdings unter Beachtung der zur Einführung genannten Einschränkungen. Das Konzept im Allgemeinen sei durchdacht, die Umsetzung
bedürfe aber noch ein paar Verfeinerungen und Änderungen. Schwächen wurden bereits
einige Absätze zuvor herausgestellt. Darüber hinaus besteht eine größere Aufgabe darin, die Akzeptanz zur nahezu „neuen“ Interaktionsform herzustellen. Eine Vermutung ist,
dass diese Hürde durch die vermehrte Einbettung benutzerführender Aufgaben wie Na-
6.2. BENUTZERTESTS
145
vigation und Orientierung sowie visuell ergonomischerer Komponenten abgebaut werden
kann. Die Mehrheit war mit der jetzigen Fassung weitestgehend zufrieden. Eine Auflistung
erwünschter Verbesserungen folgt:
• Verbesserung der Analogie zwischen Maus/RC-Buttons und ihrer visuellen Repräsentation auf dem Bildschirm,
• Reduzierung der Hierarchiestufen in der Sitenavigation,
• Darstellung einer einzigen Ansicht für alle Elemente, Steuerungen und Informationen zur Vermeidung weiter Interaktionswege,
• Vermeidung von Sprachkommandos, die per Maus / RC nicht ansteuerbar sind oder
gänzlich unsichtbar sind und gemerkt werden müssen (z.B. „Commands“, „Previous
tool“, „Next tool“, „Return“, „All“, „Contained“, „Related“, etc.)(s. Abb. 6.21),
• transparente Tools und Steuerelemente,
• Repositionierung der Sitenavigation,
• individuellere Kontrollen wie z.B. separates Ein- und Ausschalten von Tools,
• Vergrößerung des natürlichen Blickfeldes und Reduzierung der Verdeckung durch
Tools,
• Verbesserung der Spracherkennung,
• Verbesserung von Kontrast, Highlighting und Feedbacknachrichten,
• interaktivere Kommandos innerhalb des Exhibitmenü,
• schrilleres und ausgefalleneres Design.
Jeder Kandidat hat ein bis zwei dieser Punkte erwähnt. Die Verbesserungsvorschläge waren also von Mal zu Mal sehr unterschiedlich und durch individuelle Vorlieben bestimmt.
Zur Festlegung einer Prioritätsliste wären größere Testgruppen nötig.
146
Abbildung 6.21: Kommandos und Labels
Viele der vorgeschlagenen Verbesserungen gelten für die Präsentationskomponente des
Systems. Hingegen wurde die Intention bestätigt, die Interaktion möglichst intuitiv zu gestalten. Lediglich jeweils ein Benutzer hat sich dagegen ausgesprochen oder war unentschlossen.
Analyse nicht abgefragter Hypothesen
Einige der Hypothesen konnten mittels Benutzertests nicht ausgewertet werden, da sie
entweder zu eng an die Technik gebunden sind, innerhalb des Zeitrahmens nicht implementierbar waren oder im Rahmen des Anwendungsgebietes bisher noch nicht notwendig
waren. So versteht der Guide etwa keinen temporalen Kontext. Es heißt, dass sich Sprache
gut zu dessen Beschreibung eignet. Bestätigt wurde stattdessen, dass sich Sprache gut zur
Kurzkommandoeingabe eignet.
Dass multimodale Kommandos vom Test ausgeschlossen wurden, liegt nicht zuletzt an
ihrem Potenzial. Derzeit beschränkt sich die Interaktion auf das Abrufen von Inhalten. Modifikation und Manipulation von Information und Objekten sind nicht integriert. Ebenso
ist die Menge, aus der ausgewählt werden kann, auf wenige Datensätze limitiert. Schlichte, kurze Kommandos mit Maus / RC und Sprache haben daher ausgereicht, um umgehend
ans Ziel zu gelangen.
6.2. BENUTZERTESTS
147
In Vorversuchen wurde die multimodale Funktionalität mit kombinierten Kommandos getestet. Durch die Speicherung von Kommandos im Puffer, konfigurierbare Zeitspanne und
Puffergröße können Kommandos sequentiell eingegeben werden. Wichtig ist indes die
Reihenfolge, in welcher das System die eingehenden Einzelkommandos erkennt. Es ist
aufgefallen, dass Sprache generell mehr Reaktionszeit als Maus oder RC verbraucht. Eine
gewisser zeitlicher Abstand zwischen den Einzelkommandos war ergo immer nötig, damit
eine korrekte Sequenz erkannt werden konnte.
Während der Implementation wurde auch festgestellt, dass durch das Konzept des Keymapping multimodale und unimodale Kommandos keineswegs redundant sind. Werden
multimodale Befehlsketten verwendet, so bleiben als Startsequenz erkannte Kommandos
erstmal im Puffer und werden nach Ablauf des Zeitfensters unimodal weitergeleitet. Einziger Nachteil, der sich hieraus ergibt, ist die zeitlich aufgeschobene Verarbeitung, wenn
eine Startsequenz gleichzeitig multimodal oder unimodal sein kann. Durch die konkrete
Formulierung akzeptierbarer Eingangsdaten wird auch deren Redundanz vermieden. Erstens werden beim Ereignismanagement jedem Key mehrere Values zugeordnet. Ein Key
taucht also nur einmal auf, wenn nach einer passenden Aktion für ein Event gesucht wird.
Zweitens enthält keine Komponente des Systems Algorithmen zur semantischen Zerlegung kontinuierlicher Eingabeströme, die einen Abgleich mit zur Verfügung stehendem
Content zur Folge hätte. Die Prozedur folgt also dem einfachen Prinzip von Aktion und
Reaktion. Dies erweist sich allerdings keineswegs als Nachteil, da die Keymap dynamisch
um beliebige Events und CLV erweitert werden kann.
Vermeidung von Redundanz bedeutet normalerweise auch, dass sich die erkannten Kommandos der Eingabeströme weder gegenseitig aufheben, noch gleichen. Sie sollten sich
komplettieren und somit komplexere Aktionen vereinfachen. Dies trifft in diesem System
nur dann zu, wenn multimodale Keytupel separat definiert werden. Andererseits kann das
Event des einen Geräts immer dem eines anderen gleichen, und entspricht somit der Intention, jederzeit alles mit jedem Modus ansteuerbar zu halten. Es muss schließlich immer
unterschieden werden, ob ein Benutzer unimodal oder multimodal interagiert.
148
Besonderere Ansprüche an eine multimodale Schnittstelle sind nach [Ovi02] Generalisierbarkeit, Robustheit und Skalierbarkeit. In der Interaktionskomponente sprechen dafür die
Unterteilung der Geräte nach Funktionalität wie Eingabe-, Ausgabe- und Lokalisierungsgeräte und die Kapselung spezifischer Geräte mit Hilfe der Steuerinterfaces der Gerätegruppen. Es können beliebige Modi jederzeit hinzugefügt werden. Ihre Verwendbarkeit
ergibt sich dann aus den Konfigurationen der verfügbaren Events und ihrer Integration in
das Event Management. Die Präsentationskomponente stellt mit dem Widgetkonzept die
Plattform für beliebige Reaktionen des Systems. Widgets können rein funktionale und/oder visuelle Aufgaben erfüllen. Ihre Steuerbarkeit wird durch proprietäre Interfaces und
ihre Zustandsautomaten gewährleistet.
Graphical User Interface (GUI) vs Multimodal User Interface (MUI)
Prinzipiell gibt es zwischen GUI und MUI eine klare Abgrenzung. Das Konzept wechselt
von Fenstern, Ikonen, Menüs und Zeigern zu der Verarbeitung paralleler, kontinuierlicher
Eingabedatenströme mit der Präsentation von Multimedia als Ausgabe. Statische Zugriffe auf Steuerelemente sollen durch dynamische Aktionen ersetzt werden. Die Intention
dieser Arbeit war es allerdings, GUI nicht durch MUI gänzlich abzulösen, sondern zu erweitern, insbesondere, weil dem Benutzer eine visuelle Repräsentation der verfügbaren
Steuerelemente zur Verfügung stehen sollte, die er nicht interpretieren muss und die nicht
von ihm verlangt, darüber nachzudenken, wie er interagieren muss. Dies soll aber nicht
implizieren, dass eine MUI diese Aufgabe nicht erfüllen kann. Vielmehr war die Absicht,
dem Benutzer eine „gewohnte“ Plattform zu bieten, wenngleich man nicht davon ausgehen
kann, dass jeder Tourist schon einmal einen Desktop-Computer bedient hat. Das ursprüngliche Interaktionsprinzip von WIMP ist daher auch weggefallen. Die Pointing-Metapher ist
im Dreidimensionalen unpraktisch, Ikonen erfordern Abstraktionsvermögen, herkömmliche Menüs - insbesondere, wenn sie eine tiefe Hierarchiestruktur besitzen - erscheinen
schwer navigierbar ohne Pointing und sich überlagernde Fenster mögen einzeln schwer
ansteuerbar sein. Stattdessen wurde das .NET zugrundeliegende GUI-Framework sozusagen zweckentfremdet, um eine neue Art von Oberfläche zu gestalten. Nichtsdestotrotz
haben die resultierenden visuellen Tools immer noch eine starke Ähnlichkeit zu DesktopApplikationen. Dafür haben sich Ansteuerung und Komplexität geändert.
6.2. BENUTZERTESTS
149
Die Ansteuerung von visuellen Elementen erfolgt demnach entweder indirekt und sequentiell durch das Scrollen oder Tabbing durch Tools und Controls oder unmittelbar durch
Sprachkommandos. Das Tabbing wird weiterhin - wie in GUI üblich - durch Farb- und
Helligkeitsfeedback signalisiert und die Auswahl der jeweiligen darunterliegenden Control muss zusätzlich bestätigt werden, wohingegen Sprachkommandos eine direkte Reaktion auslösen und somit dem MUI-Konzept näher sind. Performanter ist die Sprachkontrolle.
Wie Benutzer aber kommentierten, entspricht diese nicht immer dem unbedingt bevorzugten Modus.
Nicht nur bedingt durch das begrenzte Sichtfeld und bedingte Schärfe und Kontrast musste die Komplexität der Tools auf ein Minimum reduziert werden, bei gleichem Anspruch
an deren Funktionalität. Zwar scheint dies eine Maxime für jede Art von Applikation zu
sein, doch ist in vielen Desktop-Applikationen oft eine hohe Funktionsvielfalt mit vielen Ansteuerungselementen zu finden. Das Design der Schnittstelle hat daher vorgesehen,
die Reichweite der Funktionen eng auf den Anwendungsbereich und die Ansprüche eines Ausstellungsbesuchers zu begrenzen. Weiterhin präsentiert das System nur Elemente,
die in den aktuellen Kontext passen. Die einzigen verbleibenden hierarchischen Strukturen sind die Sitenavigation und die Kommandohilfe. Trotz nur zweier vorhandener Steuerelemente erschien einigen Benutzern die Navigation durch die Thumbnails aber noch
zu komplex. Entscheidend dafür waren unter anderem die Helligkeitsunterschiede aktiver und passiver Elemente und deren Anordnung. Vorschläge zur Umgehung dieser Problematik wurden bereits in Abschnitt 6.1 und in Kapitel 4 präsentiert. Das in Kapitel 4
vorgeschlagene Konzept der Navigationskarte wäre wohl auch für die Einbindung multimodaler Kommandos prädestiniert und könnte die Komplexität noch einmal verringern,
da mehr räumliche Informationen vorhanden sind.
Folglich kann das System nicht einem Konzept - GUI oder MUI - zugeordnet werden,
sondern ist hybrid aufgebaut. Ein Überblick über die konkreten, auf die beiden Konzepte
passenden Eigenschaften der Schnittstelle ist in Tabelle 6.1 gegeben.
150
GUI
MUI
Kriterium
Einzelner Ereignisdatenstrom
Kontinuierliche, simultane Eingabe von
parallel ankommenden Strömen
Eigenschaften
Unimodale Dateneingabe, optional per
Maus / RC oder Sprache
Multimodale Dateneingabe per Maus /
RC und Sprache
Kriterium
Atomare, eindeutige Ereignisse
Erkennungsbasierte Ereignisse
wahrscheinlichkeitstheoretischen
Methoden
der
Verarbeitung
wechselseitiger Begriffsklärung
mit
und
Eigenschaften
Keymapping einzelner Events
Keymapping mehrerer, unmittelbar aufeinanderfolgender Eventtupel; eindeutig;
Begriffsklärung anhand Keymap; Sprache wird vorab erkannt und anhand eines Vokabulars als atomares Event verarbeitet
Kriterium
Statische singuläre Implementierung
Vernetzte Erkennung und Interpretation
des Kontext
Eigenschaften
Event und Control (∼
=Widget) entkoppelt;
dynamische Erweiterung von und mit
Widgets ohne Anpassung der Events;
Regulierung von Eventströmen mittels
Zustandsautomaten
Statische Erkennung von Eventtupeln;
Interpretation durch Key-Value-Mapping
Kriterium
Farb- und Helligkeitsfeedback
Feedback in Form von Text-To-Speech,
Non-Speech Audio, Graphik und Animation (Multimedia)
Eigenschaften
Zur Signalisierung von Maus / RCAktionen; binäre Unterscheidung in aktive und passive Elemente; Textfeedback
und Audiosignalfeedback
Textfeedback, Audiosignalfeedback und
direkte Reaktion und Informationspräsentation bei Sprachaktionen
Tabelle 6.1: GUI vs. MUI (Kriterien nach Oviatt [Ovi02])
Kapitel 7
Fazit
Benutzerschnittstellen mobiler AR-Schnittstellen haben kein einheitliches Design. Sie sind
abhängig von dem Anwendungszweck des zugrundeliegenden Systems gestaltet. Außerdem orientieren sich die Konzepte oft an Erfahrungswerten und nicht an Styleguides oder
Richtlinien. In Kapitel 3 wurden Rückschlüsse auf die Benutzerfreundlichkeit der unterschiedlichen UI-Typen gezogen und in das Design der MUI des ARGuide einbezogen.
Die Konzepte orientierten sich weniger an den Funktionen, die der mobile Touristenführer
beherrschen soll, sondern mehr an den Ansprüchen eines Besuchers an den Wissensschatz
eines Museums oder einer Kulturstätte. Wenn sich Inhalte ändern, so ist ARGuide fähig,
dieselben Konzepte anzuwenden. Wenn ein Besucher sich mit spezifischen Eingabegeräten nicht wohlfühlt, ist die MUI in der Lage, ihm andere Modi anzubieten. Die Anwendungsfreundlichkeit menschlich-natürlicher Kommunikationsformen spiegelt sich in den
Testergebnissen wieder.
Allerdings konnten die Fähigkeiten und Kenntnisse der Testgruppen als weitgehend einheitlich und fortgeschritten eingestuft werden. Da keine heterogene, zufällig ausgewählte
Besuchergruppe einbezogen wurde, lag die Erwartungshaltung eher auf technisch funktionalen Features als auf Informationsgehalt, wohl beabsichtigt für einen initialen Prototypen. Die Benutzerschnittstelle wurde trotz Inhaltsdefizit als benutzerfreundlich gewertet.
Die Interaktionskonzepte sind intuitiv und natürlich. Funktionen waren einfach zu fin-
151
152
KAPITEL 7. FAZIT
den und auszuführen. Eine Stärke multimodaler Interaktion ist ihre Erweiterbarkeit, etwa
der Sprachwortschatz der Schnittstelle, so wie auch natürliche Kommunikationsmittel erweiterbar sind. Gleiches gilt für die Präsentationskonzepte, die sich als nützlich erwiesen
haben, allerdings noch einen Feinschliff in Layout und Platzierung benötigen. Sichtbehinderungen lenkten zu sehr ab und wirkten sich sehr nachteilig auf den Gesamteindruck der
Schnittstelle aus. Die Tools konnten den Anwender bei der Wahl seiner nächsten Aktionen anleiten. Eine Gewöhnungszeit war allerdings immer notwendig, auch wenn sie stets
kurz war und dies zeigt, dass die Metaphern nicht zu fremdartig waren. Die Abstraktion
von Sprache, Maus und Remote zur Aktion im System muss immer vollzogen werden.
Die Idee, dass sich die Geräte gegenseitig ersetzen und gleichzeitig multimodal eingesetzt
werden können, erhöhte den Freiheitsgrad der Interaktion und war wichtig, um die Akzeptanz unter den Anwendern herzustellen. Redundanz von Eingaben unterschiedlicher
Geräte war somit beabsichtigt. Zweideutigkeiten sind hingegen nicht aufgetaucht.
„Guiding“ bedeutet nicht nur die Unterstützung von Orientierung und Navigation auf dem
Ausstellungsgelände, sondern auch die ständige Beantwortung der Frage, welche Aktionen wie ausführbar sind. Das konstante Feedback war passend und half vor allem, den
Status des Anwenders zu signalisieren. Punktuelle Orientierungshilfen gaben Sitenavigationstool und die merkmalsbezogenen Hot Spots der Overlays. Das System war insofern
nur begrenzt mobil einsetzbar.
Nach Terminologie ist die Schnittstelle multimodal konzipiert und realisiert. Der Einsatz
multimodaler Befehlskombinationen ist momentan noch nicht notwendig. Die Möglichkeit unimodaler Interaktion lässt eine leichte Gewöhnung an die Eingabegeräte zu. Nach
den Eingewöhnungsphasen wurde bevorzugt mit nur einem einzigen Gerät interagiert. Dynamische Gerätewechsel ermöglichen die flexible Anpassung an die Bedürfnisse des Anwenders und die Anforderungen des Systems. Die Auswahl einer Alternative wurde als
angenehm empfunden. Effektiv konnten die passiven Datenströme eingesetzt werden. Die
Daten unterstützten das Feedback, ohne dass es dem Anwender offensichtlich war.
Sprache wurde als Eingabemodus bevorzugt. Dies war aber nicht die Regel, denn auch
Maus oder RC waren gelegentlich die erste Wahl. Durch das begrenzte, dynamisch wach-
153
sende Vokabular und die klare Repräsentation in der GUI war der Kommandowortschatz
einprägsam. Die Wortwahl und Steuerung durch Kommandos war intuitiv. Man merkte, dass Sprache aufgrund ihrer direkten Ausführbarkeit stets zu Informationspräsentationen oder Statusänderungen der UI führte. Mensch-Mensch- und Mensch-MaschineKommunikation sind parallel ausführbar.
Die Konzepte können einen Besucher mit Hilfe einer mobilen AR-Plattform über eine
Ausstellung führen. Es muss darauf geachtet werden, dass die Komponenten exakt aufeinander abgestimmt sind. Irritationen können das Immersionsgefühl reduzieren. So müssen
Interaktionen immer die gewünschten Reaktionen hervorrufen und das Erscheinungsbild
der Tools darf die freie Sicht nicht stören. Für einen intensiveren Einsatz multimodaler Eingaben bzw. menschlich-natürlicher Modi spricht der geringe Lernbedarf. Die Modi sind
quasi schon vorhanden und bekannt, es müssen nur neue Metaphern hinzugefügt werden.
Konzeptanalyse und Benutzertests haben gezeigt, dass die Konzepte die gestellten Ansprüche an die Schnittstelle weitestgehend erfüllen. Wie es für einen initialen Prototypen
üblich sein dürfte, konzentrierte sich die Implementation auf Umsetzung von Funktionalität. Die Stärken der Schnittstelle liegen in ihrer „Generalisierbarkeit“ (Unabhängigkeit von Geräten und Widgets vom Anwendungszweck), ihrer „Robustheit“ (Vokabular,
Zustandsautomaten) und ihrer „Skalierbarkeit“ (Anbindung multipler Geräte, skalierbarer Ereigniswortschatz ohne Ambiguitäten und Redundanzen) und bilden somit die erste
Voraussetzung für eine allgemeingültige UI mit beliebigen Interaktionsmetaphern.
154
KAPITEL 7. FAZIT
Kapitel 8
Ausblick
Der vorliegende Prototyp hat gezeigt, wie sich Tracking und Rendering des ARBrowser
und Content-, Site- und Medienmanagement von intCulture bzw. ARGuide nutzen lassen,
um einem Besucher detaillierte augmentierte Informationen zu einem Ausstellungsstück
zu geben und ihn in seiner Interaktion zu unterstützen. Die Entwicklung steht hier aber
noch am Anfang und kann in vielen Richtungen expandiert werden. Zum Teil sind weiterführende Ideen und Konzepte abhängig von den zukünftigen Entwicklungen des ARBrowser und intCulture.
8.1
Interaktion
Die multimodalen Fähigkeiten der Schnittstelle konnten bisher nicht ausgeschöpft werden.
Unimodale Interaktion hat den Anforderungen am besten entsprochen. Ob dieses Konzept
auch aufgeht, kann deshalb nur in zukünftigen Tests herausgefunden werden, wenn neue
Funktionen dies erfordern. In Zukunft sollten auch abstrakte Geräte wie Maus und Remote Control durch andere menschlich-natürliche Kommunikationsmodi abgelöst werden. Es
bleibt aber immer eine Frage der Notwendigkeit und der Akzeptanz unter den Besuchern.
Die Interaktionen des Besuchers beschränken sich momentan auf die Navigation durch
Tools, Steuerelemente und die Hot Spots eines Exponats sowie den Abruf weiterführen155
156
KAPITEL 8. AUSBLICK
der Informationen. Steigt die Komplexität der Information, wie etwa dreh- und skalierbare
dreidimensionale Abbilder eines Exponats in einem Showcase oder begehbare Modelle,
steigt auch der Anspruch an die Interaktion. Es werden mehr manipulative Funktionen
benötigt. Diese wiederum eignen sich ideal für multimodale Steuerung. Entsprechende
Metaphern hätten etwa die Form Scale < distance >, mit < distance > als mit zwei
Fingern gestengedeutetem Abstand. Für fortgeschrittenere interaktiv augmentierte Modelle lässt sich das Hot-Spot-Konzept erweitern. Auch die Navigation durch die Exponate
der Site kann konkreter und dynamischer gestaltet werden. Vorzustellen ist sich hier etwa
im Sinne von Bolt [Bol80] eine Metapher in der Form Show items < there >, wobei
die Richtung < there > durch eine Geste gedeutet werden kann. Der Befehl würde die
Exponate in der gewünschten Richtung auflisten.
Die Trägheitssensoren der Remote Control lassen sich zur Simulation zweidimensionaler Gesten verwenden. Die Abschaltautomatik erlaubt das gezielte Ziehen von Linienzügen im Sichtfeld. Die Gesten sollten auf dem Bildschirm zur Verfolgung und Verifikation
durch den Anwender nachgezeichnet werden.
Der Prototyp wurde auf Interaktionen für ein einziges Exponat beschränkt. Die Tests verliefen stationär. Bei Geh- und Laufbewegungen dürfte die Bedienung von Handgeräten
schwer fallen. Entweder sie müssen dann vorübergehend am Körper untergebracht werden,
was die Interaktion behindert, oder - wie schon erwähnt - sie werden durch natürliche ersetzt, oder Eingabemodalitäten werden am Ausgabegerät integriert. Als erster Schritt sollten die Knöpfe der Binoculars angebunden werden. Schwere Video-See-Through-HMD
sollten nicht in Frage kommen.
8.2
Präsentation
Ein äußerst auffälliges und teilweise störendes Manko des Prototypen ist das visuelle Erscheinungsbild. Die Tools verdecken die Sicht stets mit ihrer kompletten Größe. Eine wesentliche Verbesserung dürfte sich einstellen, wenn die gruppierenden Elemente transparent und die Steuerelemente halbtransparent werden. Ein starker Kontrast zum Videobild
8.3. APPLIKATION
157
muss allerdings erhalten bleiben, besonders in Außenbereichen mit starker Sonneneinstrahlung. Wenn Transparenz nicht durch Weiterführung der bisher versuchten Ansätze
hergestellt werden kann, könnte versucht werden, mit OpenGL geschriebenen Code in
den ARBrowser zu integrieren oder eigenständig über dem Videobild zu rendern.
Kontextsensitive Menüs werden bisher direkt per Bildbearbeitung in das Overlay integriert. Das System erkennt dessen Relevanz nur durch Verzeichnisstruktur und Dateiname.
Dynamischer wären in VRML definierte Modelle, deren Hot Spots manipulierbar sind und
mit den vorgeschlagenen „Flying Menus“ markiert werden (z.B. eine Tür, die sich öffnen
lässt). Die Integration bedingt aber eine Erweiterung des ARBrowser um Import, Tracking
und Rendering von VRML-Modellen. Ebenso müssen Ereignisse der Schnittstelle weitergeleitet werden können, um den Szenegraphen zu manipulieren.
Ebenso könnten die systemsteuernden Menüs durch den ARBrowser dargestellt werden.
Sie müssen zwar nicht getrackt werden, allerdings könnte der AVALON-Renderer sie an
Bildschirmkoordinaten fixiert rendern. Dies dürfte auch zur Lösung der Transparenzprobleme beitragen. Weiterhin könnte der Besucher durch am Boden augmentierte, getrackte
Navigationspfeile die Wege von Exponat zu Exponat erklärt bekommen.
Schließlich müssen die Komponenten von intCulture noch vollständig integriert werden.
Darüber hinaus werden für die mobile Nutzung noch die Orientierungs- und Navigationsfunktionen benötigt, die entsprechend an den ARGuide anzupassen sind.
8.3
Applikation
Die Feedback-Funktionen haben sich als sehr hilfreich erwiesen und sollten erweitert werden. Vor allem sollte es strukturiert sein und nicht direkt im Programmcode untergebracht
werden. Eine Ausgliederung in ein externes Format in der Art wie VoiceXML1 könnte
einen Dialog zwischen Mensch und Maschine definieren. Aktionen des Benutzers (bereits
interpretiert in Widgetkommandos) resultieren in Feedback mit Angabe von Format, Inhalt
1
Informationen zum Standard unter http://www.voicexml.org/ und http://www.w3.org/TR/voicexml20/
158
KAPITEL 8. AUSBLICK
und darstellendem Widget. Es folgt ein kurzes Mockup zu dieser Idee.
<FeedbackDialogue>
< D ia l o gu e It e m >
<Human A c t i o n = " Play media " / >
<Machine Response= " You see a media f i l e o f X . " >
< !−− X i s p a r s e d and r e p l a c e d w i t h a p p r o p r i a t e s i t e i t e m i d . −−>
< \ D ia l o gu e It e m >
< \ FeedbackDialogue>
Daneben sollte jedes Tool selbst immer Highlightfeedback liefern. Statt des Kontrasts zwischen aktivem und passiven Tools könnte ein Rahmen den Zustand symbolisieren.
Das auftretende Feedback könnte weiterhin analysiert werden, um die Schnittstelle dynamisch an die Bedürfnisse des Anwenders anzupassen. Selten genutzte Tools könnten automatisch versteckt werden. Das System könnte bei Registrierung von Interaktionsschwierigkeiten ein anderes Layout vorschlagen. Es ist auch an eine verbesserte Handhabung der
Tools zu denken wie dynamisches Verstecken und Hervorbringen einzelner Tools. Es ist
aber darauf zu achten, dass die bestätigten Hypothesen nicht verletzt werden.
Automatisiertes Feedback könnte sich auch in einem verbesserten, dynamischeren Hilfesystem widerspiegeln. Statt aktivem Aufruf statischer Hilfen sollten kontextsensitive Hilfen dynamisch und konstant präsent sein und bei Bedarf abgeschaltet werden können. Bei
Fokussierung von Steuerelementen zeigt ein aufblendendes Label etwa die dahintersteckende Funktion. Oder bei Fokussierung von Tools werden die dort zur Verfügung stehenden Sprachbefehle in einem Label angezeigt.
Alle natürlichen Eingabemodi, die in zukünftigen Prototypen angebunden werden, können passive Datenströme liefern, die für biometrisches Feedback ausgenutzt werden sollten (z.B. Körperbewegungen oder Lidschläge beim Eyetracking).
8.4. ALLGEMEIN
8.4
159
Allgemein
Die Einordnung von Designentscheidungen und Testergebnissen in softwareergonomische
Grundsätze sollte auf weitere Normen ausgedehnt werden. Auch wenn sie eigentlich nur
auf die Arbeit mit stationären Desktopsystemen ausgerichtet sind, so können sie doch
eine Idee benutzerfreundlichen Designs vermitteln und die Entwicklung natürlicher ARInteraktion unterstützen.
Ebenso ist der Testparcour in ein reales Ausstellungsgelände zu verlagern. Wenn heterogene Testgruppen mit unterschiedlichen Präferenzen, Vorkenntnissen und Erwartungshaltungen evaluiert werden, haben die Ergebnisse eine weitreichendere Bedeutung.
Es ist auch in Zukunft die Frage zu beantworten, ob Kleingeräte wie PDA und Mobiltelefone multimodale Funktionalitäten integrieren können und sollten. Denn eigentlich verfügen sie schon über typische und vor allem gewohnte Eingabemodi. Die Akzeptanz für
die Technik wird jedenfalls nur dann wachsen - so die Vermutung -, je komfortabler und
miniaturisierter die Hardware und je intuitiver und natürlicher die Bedienung werden.
160
KAPITEL 8. AUSBLICK
Anhang A
Zum Inhalt des Anhangs
Die Inhalte des Anhangs sind zum größten Teil in Englisch gehalten, da die Arbeit während der gesamten Zeit vom Team des Abteilung Content Delivery Systems in Intracom
unterstützt auf Englisch und die Ergebnisse in regelmäßigen Abständen diskutiert und präsentiert wurden. Ebenso dienen die Diagramme und Beschreibungen der einfachen Wartung und Erweiterung der Schnittstelle im Anschluss an diese Arbeit. Desweiteren sind
die Schnittstelle sowie die Inhalte selbst auch in Englisch gehalten.
161
162
ANHANG A. ZUM INHALT DES ANHANGS
Anhang B
Eingabegeräte
Device
Technical Description
Advantages
Disadvantages
Cloth
gloves
with
electrical
sensors
in
each
fingertip,
contact
between
any two or more
digits
completes
a
conductive
path,
sample source code
is available for either
SGI or PC platforms.
No
calibration,
low-cost
method
of
recognizing
natural
gestures,
tracking
available
(Polhemus and Ascension).
Gestures are limited to
the use of finger tips,
too
much
functionality for a tourist,
wearing
gloves
in
summer
might
be
uncomfortable,
bulky
receiver,
high
costs,
tracking not included.
Measures finger flexure (1 sensor per
finger) and the orientation (pitch and roll)
of the user’s hand,
USB adapter available.
Wireless version and
more sensors available,
mouse emulation mode.
Extra
model
for
each left and righthanded
people,
mouse emulation mode
only in wired version,
uncomfortable
as
the
pinch
gloves,
expensive,
tracking not included.
163
164
ANHANG B. EINGABEGERÄTE
Device
Advantages
Disadvantages
22 high-accuracy jointangle measurements,
18-sensor model features two bend sensors
on each finger, four
abduction
sensors,
plus sensors measuring thumb crossover,
palm arch, wrist flexion
and wrist abduction,
18-sensor CyberGlove
includes open fingertips, which allow the
user to type, write and
grasp objects while
wearing the glove.
Tracking available (Polhemus and Ascension),
feedback features like a
LED on the glove.
Tracking not included,
same
disadvantages
as the other gloves,
too
much
functionality for a tourist,
not affordable.
Mouse-mode
compatible,
6 degrees of tracking
(X, Y, Z, Yaw, Pitch
and Roll) to ensure
realistic
movement,
USB
port,
infrared control receptor
with scratch-resistant,
anti-reflective lens.
Low-cost-device,
SDK
available,
easy
handling
by
triggering and pointing to the screen,
wireless.
Infrared
sensor
needs line of sight,
is too big and receives signals from
the wrong direction,
would be a perfect
device if wired or
Bluetooth
version
would be available,
might be too uncomfortable because of plastic
elements (to be tested).
165
Device
Advantages
Disadvantages
11 programmable buttons, trackable with receivers.
Built-in tracking sensor, but no receivers,
familiar looking button
interface like remote controls have got,
programmable.
11 buttons might be
too much for tourists,
extra
tracking
devices
needed,
not
hands-free,
not wireless.
3
programmable, tactile buttons,
„Hula-Point“-Navigation
by Joystick button.
Light-weight,
less
buttons,
tracker mounts.
Not wireless, extra protocol must be written,
can be connected to
CAVELib and Trackd
compatible applications,
not hands-free.
Steering cross, 10 programmable
buttons,
analog
sticks,
software bundle.
Light-weight,
less
buttons,
tracker mounts.
Cordless,
force
feedback,
customizable through
standard drivers.
Optical/nonwearing
measuring
system,
8
illuminated
programmable
buttons,
durable
stainless
steel
construction,
stationary,
movements by sliding,
pulling, tilting the cap,
6 DOF.
Set
with
Logitech
mouse,
small,
easy
interface,
supports
turn-andclick
metaphor,
hands-free
if
attached to output device or
body.
Too
expensive
for
too
less
functions,
maybe
too
much
buttons,
not
a
lightweight,
not
very
natural,
not yet known if device has to be moved like a mouse or
just in turnarounds,
not known if there is an
API.
166
Device
Advantages
Disadvantages
Bluetooth,
switch to optical mouse,
two buttons, scrolling
design.
Hardware
ergonomic
because lying in hand,
most known metaphor,
customizable,
„wearable
mouse“,
tactile
feedback,
wireless,
direct
usability,
no
training
phase
needed.
Not
trackable,
too
expensive
for
too
less
functions,
no hands-free.
USB
interface,
gesture
detection
software,
pad
can
behave like a mouse,
standard mouse and
keyboard behaviours,
gesture editor.
Natural
interaction,
programmable,
light-weight,
gesture
detection
software.
Touchpad is too large
(0.31 x 7.1 x 5.5 inches),
gestures
might
be too difficult to
learn in short time,
cant be easily attached
to body.
Four
mechanical
buttons;
three
programmable functions,
No contact pressure
required;
sensitivity
adjustable with driver,
USB and PS/2.
Good
price,
small (4 in. long x 4.4 in.
wide x 0.375 in. deep),
behaves like a mouse,
tap
zones,
tapping on pad can
emulate left and right
clicks.
Gesture
recognition
difficult,
libraries available in
different languages but
untested (e.g. StrokeIt),
advanced
gestures
might be difficult for the
user to learn.
167
Device
Advantages
Disadvantages
USB dual RF receiver,
gyroscopic
motion sensor for use
off
the
desktop,
extra
long
30-foot
RF range, no lineof-sight
limitations,
ultra precise optical sensor for use on the desk,
no mouse pad required,
long-life
rechargeable
NiMH
battery with convenient,
desktop
charging
cradle,
GyroTools
PC
Media Control Software
for Windows, which
includes 60 General,
Internet, Media, Input
and Windows tools,
clickable scroll wheel.
Point-andClick-Metaphor,
device
is
tracked,
customizable software,
wireless,
recently priced.
To be evaluated.
Cheap,
totally
small,
2-Button functionality,
handy,
body-attachable.
Not
wireless,
for further interaction methods maybe not
suitable.
168
Device
Synaptics Touchpad attached on wrist
Advantages
Disadvantages
100-ft RF range with no
line-of-sight limitations,
solid-state
motion
sensor,
receiver connects to
computer via USB port,
advanced
techniques
using subtle movements.
Gestures,
Pointing,
customizable,
high
functionality,
wireless,
tactile feedback.
To be evaluated.
Using Synaptics technology.
Body-attached,
hands-free,
usability like a watch,
natural input method,
easy gestures like left
striping / right striping,
tap zones.
Advanced
gestures
not easy to learn,
gesture
recognition
library necessary, too
costly.
Anhang C
Anwendungsdiagramme
Blaue Anwendungsfälle sind aus den Anwendungsfalldiagrammen des Projekts Archeoguide [VIK+ 02] entnommen.
169
170
C.1
ANHANG C. ANWENDUNGSDIAGRAMME
Generelle Benutzerinteraktionen
Abbildung C.1: Benutzerbedürfnisse
C.1. GENERELLE BENUTZERINTERAKTIONEN
Abbildung C.2: Benutzerhandlungen
171
172
C.2
Unterteilung der Museumssite
Jede Museumsanlage ist hierarchisch aufgebaut und besteht aus verschiedenen „Area of
Interest“ (AOI), die sich nicht überlappen sollten. Jedes AOI besteht wiederum aus verschiedenen „Point of Interest“ (POI). Der POI kann entweder ein Hot Spot eines augmentierten Objektes, das augmentierte Objekt selbst oder ein beliebiger Interessenspunkt
innerhalb der Site sein. Ein AOI kann auch ein POI sein, ein POI aber niemals ein AOI.
Abbildung C.3: Area of Interest (AOI)
C.2. UNTERTEILUNG DER MUSEUMSSITE
Abbildung C.4: Point of Interest (POI)
173
174
C.3
Benutzerbedürfnisse im Detail
Abbildung C.5: Erkunden
C.3. BENUTZERBEDÜRFNISSE IM DETAIL
Abbildung C.6: Nachfragen nach Informationen
175
176
Abbildung C.7: Dokumentieren und Erinnern
Abbildung C.8: Empfehlen und Führen lassen
177
178
Abbildung C.9: Erklären lassen
Abbildung C.10: Nachforschen
179
180
Abbildung C.11: Kontrollieren
Anhang D
Anwendungsszenarios
D.1
Kind
A Greek family visits the ancient hill of Athens’ Acropolis. A museum’s assistant offers
the familiy’s child to explore the site by solving some playful quests together with other
children on the site. The child is equipped with a head-mounted display, a backpack with
laptop equipment, a headset and a minimized mouse with two buttons. After the HMD is
calibrated to its head and the system is initialized with the child’s profile an animated avatar icon appears and tells about the main story of this ancient place. Afterwards, it invites
the child to reveal the secrets the Greek tribe has left centuries ago. A background story is
told and an image of the secret is shown like it looked in ancient times. A first abstract hint
is given by the avatar to find the secret. Exploring the area the avatar informs the child how
close it is to the secret. The child’s position indicating point on the miniature map blinks
and pulses faster the closer it gets. Unfortunately, the Acropolis site is very huge, so it
lasts long to explore. Therefore, the child receives a second hint after a mouse click telling
more details about the secret. In the next hint a navigation arrow appears in the display
showing the direction the child has to go. Additionally, instructions and explanations are
played in audio cues and displayed in the status bar. The navigation help disappears as the
child reaches the bounding area of the point of interest with the secret. Finally, it founds
the secret which is signalized by an appearing treasure image and a surprising earcon. The
181
182
ANHANG D. ANWENDUNGSSZENARIOS
avatar tells the child that it has collected some points calculated by the needed time and
the number of hints. Now, some additional information about the secret can be accessed.
After the child finishes its quest its points are compared to the other childs which explored the area at the same time and it receives a printout of all found secrets that can be
shown to the other childs around.
D.2
Hörgeschädigter Erwachsener
Chris comes from Germany and would like to explore Delphi’s ancient amphitheatre. Unfortunately, he is deaf since his birth and not able to listen to the usual guides. Therefore,
a museum’s assistant offers him to be guided by an augmented reality system consisting
of a head-mounted display, an ear-enclosing headset, laptop equipment in a backpack and
a wireless mouse device with force feedback. After every device has been applied to his
body properly, he enters the site.
The system introduces him to the site by an automatic scrolling text description on the
bottom of the screen. Navigational information is not provided at the moment since Chris
should have a full view of the environment. In order to get an orientation on the site he
interrupts the guide’s explanation by a simple noise into the microphone. A small status
panel indicates the quality of the recognition resp. the loudness of Chris’ voice. The text
panel flashes, disappears and is exchanged by a status message. Shortly after, a menubar
with a few entries appears at the bottom indicated by a keyword and an icon. By pressing and holding a mouse button he cycles through these entries and releases as the entry
„Navigation“ is highlighted. After another mouse click a minimized map and a menu of
suggested points of interest in the near environment appear at the bottom.
After selecting a point of interest and guided to the area the navigation menu disappears
and a menu with selectable media like scrolling text, video with subtitles and animations
is displayed at the bottom. His choice of scrolling text opens the same text panel as for the
mentioned introduction.
D.3. UNTERSCHIEDE VON AOI UND POI AM BEISPIEL EINES ERWACHSENEN183
After Chris has finished reading he proceeds towards another area. As he reaches its zone
the mouse vibrates and the procedure is repeating.
D.3
Unterschiede von AOI und POI am Beispiel eines Erwachsenen
Kostas is equipped with the museum’s electronic guidance system and enters the area of
the Temple of Hera. A female voice introduces him to the main background story and
history of the area (Information need 1: Where am I?). After the voice cue has finished a
menu appears at the bottom containing the hint „You can see here“ followed by the area’s
name, a thumbnail list and their keyword descriptions (Information need 2: What can I see
here?). Choosing the item „Temple of Hera“ the female voice returns and tells Kostas the
details about the temple’s history. As he is standing in front of the temple itself after being
led by augmented navigation pointers and has got a fully immersive view on the exhibit
the image is augmented with an overlay of the ancient intact temple. At its corners the
image is applied with miniature icons which offer Kostas the temple view to be manipulated. An explanation of the icons is provided at the sidebar of the screen. The scroll wheel
of the mouse is now used to cycle through the icons (Note: for each cycle state a new
overlay is needed). A „Select“ on the icon standing for „Unhide“ resp. „Go into“ causes
the augmented image to animate and reveal an interior view of the temple with transparent
front and side walls (cut-away). Kostas cycles to the icon for the interaction „Timetravel“.
Selection causes a tracked animation of several appearances of the building during its era
(Information need 3: What can I do here?).
Notice that everytime icon handlers are shown explaining help sidebars are displayed unless they are hidden by one of Kostas commands. During the hiding only one icon is visible
in the bottom-right corner of the screen explaining the command needed to unhide the GUI
items.
184
ANHANG D. ANWENDUNGSSZENARIOS
Nevertheless, Kostas wants much more detailed information about the temple. Therefore, he asks for details by speaking the suggested keyword „Details“ into the microphone
on his headset. Additionally to the speech a textbox is displayed scrolling the text of the
speech and highlighting keywords. Meanwhile, an overlay animation is augmented on the
screen highlighting the positions of the exhibits appearing in the text. Next to the highlighted areas labels with keywords appear. At the end of the speech a final overlay is shown
containing all the highlights and their corresponding keywords. A status bar at the bottom
instructed Kostas with the possible interaction „Details on Area’s exhibits by choosing
keyword on list“ he picks the entry „Statue of Zeus“ by voice. Otherwise he could have
switched between textbox and labels by a mouse button and scrolled through by the mouse
wheel. The other button would have choosen the highlighted entry.
A menu appears with several interaction methods. After the selection of „Media“ a media
player pops up playing some suggested media files including animations of the statue. As
it finishes the menu is still there. Additionally, the entry „3D Model“ leds to another popup
which shows an manipulative 3D model of the statue to be rotated and scaled.
Anhang E
Mockups
Jedes Anwenderszenario wurde anhand von Mockups nachgestellt. Die folgenden Beispielabbildungen zeigen, wie die Ideen umgesetzt werden sollten. Es wurde dabei mehr
auf die konzeptuelle Bedeutung geachtet als auf visuelle Attraktivität geachtet.
Abbildung E.1: Fokussierter POI eines AOI
185
186
ANHANG E. MOCKUPS
Abbildung E.2: Selektierter POI eines AOI
Abbildung E.3: Showcase mit 3D Modell
Abbildung E.4: Kompass zur Navigation zu einem AOI oder POI
Anhang F
Sequenzdiagramme
Am Beispiel der nach den Erfahrungen in den Projekten intCulture und Archeoguide am
meisten gestellten Fragen von Besuchern auf einer Ausstellung zeigen die folgenden Sequenzdiagramme, wie die Systemkomponenten interagieren. Die unten aufgeführten Sequenzdiagramme sind partiell in dem hier beschriebenen System implementiert worden.
Abbildung F.1: Frage „Wo bin ich?“
187
188
ANHANG F. SEQUENZDIAGRAMME
Abbildung F.2: Frage „Was kann ich hier sehen?“
189
Abbildung F.3: Frage „Was ist in der Nähe?“
190
ANHANG F. SEQUENZDIAGRAMME
Anhang G
Fragebogen
Jeder Hypothese wurden versucht, Fragen für den Benutzertest zuzuordnen. Einige Thesen konnten allerdings schon durch die Implementation selbst oder die Konzeptanalyse
beantwortet werden. Wiederum andere konnten aufgrund fehlender Interaktionsmöglichkeiten oder Content nicht beantwortet werden. Diese Thesen und Fragen sind aufgeführt,
allerdings ohne statistische Ergebnisse. Kommentare der Benutzer sind in die Bewertung
bereits mit eingeflossen.
G.1
Hypotheses & Questions
Yes
No
Both
Did the visible elements occlude your view?
5
9
0
Have you been easily able to hide the visible elements ?
12
2
0
Transparenz oder Unsichtbarkeit von Steuerelementen
erleichtern die Sicht, wenn jene nicht in Gebrauch sind.
Das visuelle Design und die Anordnung der Elemente
des graphischen Teils der Schnittstelle behindern nicht die Sicht
auf die Ausstellungsstücke.
Nur für die aktuelle Benutzeraufgabe bestimmte Steuerelemente
sind sichtbar.
191
192
ANHANG G. FRAGEBOGEN
Yes
No
Both
Were the visible elements useful to interact with the system?
12
0
2
Were any elements unnnecessary in your opinion? If yes, which
ones?
4
8
2
Was it easy to get used to the speech input?
13
0
0
Was it easy to get used to the mouse input?
8
4
2
Did you need to remember how to use the input devices while
using the system?
9
3
2
Did you receive any information you were interested in?
10
3
1
Has the system presented information you have not been interested in?
1
11
2
In which information would you be interested using such a system?
-
-
-
Yes
No
Both
Multimodale Interaktion, insbesondere mit „natürlichen“ Eingabemethoden, benötigt wenig Gewöhnung an die Eingabegeräte
und der Benutzer kann sich auf seine Aufgabe konzentrieren.
Durch eingesetzte Kombination von Ein- und Ausgabegeräten konzentriert sich der Fokus des Benutzers
auf die Information anstatt auf deren Handhabung.
Die Kombination von natürlichen, erkennungsbasierten
Eingabemodi und nicht auf Mixed Reality spezialisierten Modi
verringert die Komplexität der Interaktion bei gleichzeitiger
Erhöhung der Freiheitsgrade.
Keine
det,
um
Eingabemethode
eine
andere
wird
zu
verwenaktivieren.
Weder wird der Zugang zu Informationen unnötig blockiert, noch wird zuviel an Information präsentiert.
Der Freiheitsgrad der Interaktionen ist zur Handhabung
der Schnittstelle ausreichend.
G.2
Kurze Kommandos und Kommandophrasen sind einprägsam.
193
G.3. STEUERBARKEIT
G.3
Yes
No
Both
Do you still remember the speech commands? Which ones?
13
0
0
Did you need to remember the functionality of the speech commands? (Negotiation: Have they been intuitive?)
1
12
0
Are the visible representations of commands sufficient for remembering?
13
0
1
Do you need more help on the commands?
6
7
1
Yes
No
Both
Did you need to think about how to receive information?
5
8
1
Did you need to think about which visible elements to access to
receive information?
2
12
0
Did you need to think about how to use the input devices to receive information?
6
8
0
Have you been confused by the arrangment of the visible elements?
7
6
1
Did you need to search for a visible tool to receive information?
4
10
0
Were you able to communicate with other persons while using
the system?
11
2
1
Did the system behave incorrectly when you were talking to
others?
4
8
0
Did you recognize that you can switch on and off the microphone?
13
0
1
4
10
0
Steuerbarkeit
Durch konsistente Navigation in der Benutzerschnittstelle gelangt
der Benutzer zu jeder vorhandenen Information.
Durch Positionierung aller „notwendigen Informationen für eine
gegebene Aufgabe in einer einzigen Ansicht“ kann der Benutzer
die Schnittstelle in einem einzigen Arbeitsschritt manipulieren.
Die Verwendung von Sprache als Eingabemodalität schadet nicht
der Kommunikation mit Unbeteiligten in der Umgebung.
Ein eingeschränktes Vokabular hilft, sich an notwendige Kommandos gut zu erinnern und sie schnell auszuführen.
Did you try commands not recognized by the system?
194
Yes
No
Both
Have there been too many commands to remember?
1
13
0
Durch die Kombination von Sprache und alternativem Eingabegerät lassen sich komplexe Interaktionsaufgaben durchführen.
-
-
-
Were the input devices appropriate for the interaction?
12
1
1
Did you miss a function on the device to interact with the system?
4
9
0
13
0
1
Yes
No
Both
11
2
1
Yes
No
Both
Has the system annoyed you by feedback messages?
0
12
2
Were the feedback messages helpful?
13
1
0
Were the messages helpful for your orientation?
8
5
0
Were the messages helpful for your navigation?
8
5
0
Were the messages helpful for knowing your status?
13
1
0
Nicht nur die Eingabegeräte, sondern auch die Interaktionsmetaphern der Benutzerschnittstelle bestimmen die Qualität ihrer
Funktionalität. Die Eingabegeräte entsprechen den Anforderungen der Schnittstelle.
Die Schnittstelle ist zu jeder Zeit verfügbar.
Was the interface available anytime you needed it?
G.4
Der Dialog ist konsistent und der Erwartungshaltung eines Besuchers einer bestimmten Stätte oder eines Museums entsprechend gestaltet.
Did the system satisfiy your expectations according to the introduction by the museum staff / researcher?
G.5
Fehlertoleranz
Vorschläge zur Lösung einer Aufgabe sind hilfreicher als die Korrektur von Eingaben.
195
G.6. INDIVIDUALISIERBARKEIT
G.6
Yes
No
Both
Could the system help you to find information?
10
2
2
Yes
No
Both
Which input device did you prefer?
2
Mouse
2
Remote
10
Voice
Have you considered to use both devices?
11
3
0
Did you need both devices?
8
6
0
Would you be interested in rearrangement of the visible elements
to your preferences?
9
5
0
Would you like the system to arrange the elements for you?
13
1
0
Were the visible elements properly arranged?
10
3
1
Were the visible elements disturbung you in any way?
8
5
1
Did you feel to put any visible element elsewhere to have a free
view?
9
5
0
Eine multimodale Schnittstelle fördert die Verwendung
von alternativen Ansteuerungen für ein und dieselbe Aktion.
Multimodale Interaktion bedeutet nicht notwendigerweise,
dass der Benutzer zwei oder mehrerere Eingabemodi gleichzeitig zur Ausführung einer Interaktion benutzen wird, obwohl
die Möglichkeit stets zur Verfügung steht. Vielmehr mag sich ein
Besucher nach einer Weile für einen Modus entscheiden, oder
zumindest neigt er zu der Verwendung eines bestimmten Eingabegerätes. Dennoch tendieren Benutzer eher zu multimodaler
als unimodaler Interaktion.
Freie Individualisierbarkeit ist für den Benutzer eines Touristenführers nicht relevant.
Die Positionierung der visuellen Elemente in einer einzigen Perspektive ist geeignet zur Ansteuerung der Schnittstelle. Frei positionierbare Elemente sind nicht notwendig.
196
G.7
Lernförderlichkeit
Yes
No
Both
Was the highlighting of speech commands useful?
13
1
0
Did you have to recognize the highlight later on to realize that it
is a speech command?
5
9
0
Nicht nur das Dialogsystem, sondern auch die bereitgestellten
Informationen lassen sich leicht erlernen.
-
-
-
Yes
No
Both
Were the different color schemes useful to separate the functinality of the visible elements?
9
2
3
Were the audio cues useful to signalize your interaction?
11
2
0
Was the text feedback useful to support you?
14
0
0
11
2
1
3
10
1
Die Verknüpfung von sichtbarem Steuerelement und Sprachkommando ist sinnvoll, um den Dialog zu erlernen.
G.8
Benutzerführung
Die Signalisierung von Interaktionen durch „Audio Cues“, Text
und farblich hervorgehobene Steuerelemente unterstützt die Erwartungshaltung an die Schnittstelle und die erfolgreiche Navigation zur gesuchten Information.
Kontinuierliches, unmittelbares und auf den Kontext zugeschnittenes Feedback ist nicht störend, sondern unterstützt die Handhabung der Benutzerschnittstelle auf dem Weg zur gesuchten Information.
Was the feedback appropriate to your actions or did it annoy you
by presenting unrequested information?
Das Verhältnis von „Fokus“ und „Kontext“ ist ausgeglichen. Die
Aufnahme momentan fokussierter Information wird nicht durch
die umgebene kontextuelle Information beeinträchtigt.
When interacting with a visible tool were you distracted by other
tools or the view on the environment?
197
G.9. MULTIMODALE INTERAKTION
Yes
No
Both
11
3
0
Yes
No
Both
Mittels kurzen Kommandos und Phrasen anstatt eines Dialogs
kann Sprache für mehrere Zwecke als für temporale oder nichträumliche Information angewandt werden.
-
-
-
5
6
3
Did you realize that your voice temperament was analyzed?
4
10
0
Did you realize that your hand movements have been analyzed?
-
-
-
Did you realize that the guide was reacting to this behaviour?
9
5
0
8
6
0
10
4
0
4
10
0
Durch die Aufteilung der sichtbaren Elemente der Schnittstelle in
„world-stabilized and screen-stabilized items“ lassen sich objektbezogene und kontextbezogene Informationen eindeutig unterscheiden.
Were the controls for an interaction at a proper position or did you
need to switch your focus for their related action result?
G.9
Die Multimodalität verstärkt das Immersionsgefühl.
Did you feel immersive? Or, did you feel somehow artifical with
the system?
„Blended multimodal interfaces“ unterstützen permanentes
Feedback durch den Guide.
Nicht unbedingt jedes Kommando wird weiterverarbeitet.
Did you expected used commands to be recognized which have
not been recognized?
Aufgrund des „blended multimodal interface“ werden Benutzer
nicht äußern, dass sie multimodal interagieren, auch wenn passive Eingabedaten nicht unmittelbar mit aktiven verarbeitet werden.
Do you think you interacted multimodal which means that you
took more than one device for interaction?
Die bereitgestellten aktiven Eingabemodi werden nicht simultan
verwendet. Darüber hinaus müssen sie nicht simultan betätigt
werden, um korrekt verarbeitet werden zu können.
Did you use the input devices simultaneously?
198
Yes
No
Both
Were the speech commands and mouse commands ambiguous?
1
13
0
Bei korrekter multimodaler Verarbeitung werden Benutzer weniger Sprachkommandos verwenden, dafür aber zusammen mit
dem zweiten aktiven Eingabemodus.
-
-
-
8
6
0
Which device did you prefer?
s.a.
s.a
s.a.
Die multimodale Verflechtung von Eingabedatenströmen ersetzt
keineswegs deren unimodale Verwendung. Die Inhalte sind nicht
redundant.
-
-
-
13
0
0
Do you think the interface can be considered as „user-friendly“?
12
0
2
Were you satisfied with the interface? If not, what are you missing?
10
3
1
Was the interaction intuitive?
12
1
1
Multimodale Befehle dienen am meisten der Manipulation, insbesondere der von augmentierten Objekten.
-
-
-
Die Maussteuerung kann die Sprachsteuerung ersetzen.
-
-
-
Kurze Eingabekommandos erhöhen die Performanz linguistischer Verarbeitung und verringern die kognitive Belastung des
Benutzers.
s.a.
s.a.
s.a.
Die Schnittstelle ist „generell, robust und skalierbar.“
-
-
-
Alle Eingabekommandos sind nicht zweideutig.
In einem multimodalen System interagieren die Benutzer nicht
immer multimodal, sondern auch unimodal mit gelegentlichem
und spontanen Wechsel des Eingabemodus.
Did you change the input device often during interaction?
Sprache ist nicht die primäre Eingabemethode.
Die multimodalen Befehle sind einheitlich und verständlich.
Were the (speech and mouse) commands consistent and articulate?
Der Vorteil einer multimodalen Schnittstelle besteht nicht in der
Performanz der Verarbeitung, sondern in der intuitiverern Handhabung und Benutzerfreundlichkeit.
199
G.9. MULTIMODALE INTERAKTION
Yes
No
Both
In which situations did you use more than one device for combinations of commands to interact?
-
-
-
Did you feel comfortable to use more than one device at once to
interact?
11
3
0
Did you like to use combinded commands?
-
-
-
Multimodale Steuerbefehle werden häufig während der Modifikation und Manipulation von Information verwendet sowie bei der
Auswahl aus einer großen Datenmenge.
200
Literaturverzeichnis
[Aeb85]
A EBLI , H ANS: Zwölf Grundformen des Lehrens. Eine allgemeine Didaktik
auf psychologischer Grundlage. Klett-Cotta, 2 Auflage, 1985.
[AGS04]
ACHENBACH , O LIVER, D R .-I NG . S TEFAN G ÖBEL und O LIVER S CHNEI DER : GEIST: A Narrative AR Learning Application. INIGRAPHICS computer graphik topics, 16(3):26–27, 2004. Fraunhofer IGD et alii, Darmstadt.
[BKLP04]
B OWMAN , D OUG A., E RNST K RUIJFF, J OSEPH J. J R . L AV IOLA und I VAN
P OUPYREV: 3D User Interfaces: Theory and Practice. Addison-Wesley,
2004.
[BM02]
B REWSTER , S TEPHEN A. und DAVID K. M C G OOKIN: DOLPHIN : The
design and initial evaluation of multimodal focus and context. In: Proceedings of the International Conference on Auditory Display, Kyoto, Japan, July 2002. Department of Computer Science, University of Glasgow, Glasgow,
Scotland.
[Bol80]
B OLT, R ICHARD: Put-That-There : Voice and Gesture at the Graphics Interface. In: Proceedings of SIGGRAPH, Seiten 262–270. ACM Press, 1980.
[CDMF00] C HEVEREST, K EITH, N IGEL DAVIES, K EITH M ITCHELL und A DRIAN
F RIDAY: Experiences of Developing and Deploying a Context-Aware Tourist Guide: The GUIDE project. In: MOBICOM, Boston MA USA, 2000.
[Die04]
D IENER , H OLGER: Game Based Interfaces. INIGRAPHICS computer graphik topics, 16(3):8–9, 2004. Fraunhofer IGD et alii, Darmstadt.
201
202
[DVI04]
LITERATURVERZEICHNIS
D EMIRIS , T HANOS, VASSILIS V LAHAKIS und N IKOS I OANNIDIS: intCulture: Location-based Multiplatform Publishing of Cultural Heritage Information. In: Proceedings of the ICHIM 2004, Seiten CD–ROM paper C2,
2004.
[DVM+ 05] D EMIRIS , ATHANASIOS M., VASSILIOS V LAHAKIS, A LEXANDRA M A KRI , M ANOS PAPAIOANNOU und N ICOLAOS I OANNIDIS : intGuide: a Platform for Context-aware Services featuring Augmented-reality, based on the
Outcome of European Research Projects. In: Signal Processing: Image Communication - Special Edition (ICJ SI), Band 26. Elsevier, INTRACOM S.A.,
Hellenic Telecommunications and Electronics Industry, Greece, 2005.
[EOea94]
E BERLEH , E DMUND, H ORST O BERQUELLE und R EINHARD O PPERMANN
ET ALII : Einführung in die Software-Ergonomie: Gestaltung graphischinteraktiver Systeme: Prinzipien, Werkzeuge, Lösungen, Band 1 der Reihe
Mensch Computer Kommunikation - Grundwissen. Walter de Gruyter, 2 Auflage, 1994.
[fN95]
N ORMUNG , E UROPÄISCHES KOMITEE FÜR: Ergonomische Anforderungen
für Bürotätigkeiten mit Bildschirmgeräten, Teil 10: Grundsätze der Dialoggestaltung (EN ISO 9241-10). Europäische Norm, Europäisches Komitee für
Normung, 1995.
[fN98a]
für Bürotätigkeiten mit Bildschirmgeräten Teil 12: lnformationsdarstellung
(ISO 9241-12). Europäische Norm, Europäisches Komitee für Normung,
1998.
[fN98b]
für Bürotätigkeiten mit Bildschirmgeräten Teil 13: Benutzerführung (ISO
9241-13). Europäische Norm, Europäisches Komitee für Normung, 1998.
[fN99]
für Bürotätigkeiten mit Bildschirmgeräten Teil 16: Dialogführung mittels di-
203
rekter Manipulation (ISO 9241-16). Europäische Norm, Europäisches Komitee für Normung, 1999.
[GHJV95]
G AMMA , E RICH, R ICHARD H ELM, R ALPH J OHNSON und J OHN V LIS SIDES: Design Patterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley Professional Computing Series. Addison-Wesley, Indianapolis, USA, 1995.
[HFT+ 99]
H ÖLLERER , T OBIAS, S TEVEN F EINER, TACHIO T ERAUCHI, G US R ASHID
und D REXEL H ALLAWAY: Exploring MARS: Developing Indoor and Outdoor User Interfaces to a Mobile Augmented Reality System. Computer &
Graphics, 23(6):779–785, 1999.
[Hsi02]
H SI , S HERRY: The Electronic Guidebook: A Study of User Experiences using
Mobile Web Content in a Museum Setting. In: Proceedings of the IEEE International Workshop on Wireless and Mobile Technologies in Education.
Metacourse, Inc., 2002.
[Kaa03]
K AASINEN , E IJA: User needs for loation-aware mobile services. In: Pers
Uniquit Comput, Band 7, Seiten 70–79. VTT Information Technology and
Springer Verlag Limited, Tampere, Finland and London, UK, 2003.
[KSH02]
K USUNOKI , F USAKO, M ASANORI S UGIMOTO und H IROMICHI H ASHIZU ME : Toward an Interactive Museum Guide System with Sensing and Wireless
Network Technologies. In: Proceedings of the IEEE International Workshop
on Wireless and Mobile Technologies in Education, 2002.
[Mic02]
M ICROSOFT: Microsoft Speech SDK (SAPI 5.1) Documentation.
Technischer Bericht, Microsoft Corporation, 2002.
http://download.microsoft.com/download/speechSDK/SDK/5.1/WXP/ENUS/sapi.chm.
[Mil56]
M ILLER , G EORGE A.: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological
Review, 63:81–97, 1956.
204
[MLB04]
M ÖHRING , M ATHIAS, C HRISTIAN L ESSIG und O LIVER B IMBER: Video
See-Through AR on Consumer Cell Phones. In: Third IEEE and ACM International Symposium on Mixed and Augmented Reality (ISMAR’04), Seiten
252–253, Bauhaus University, Weimar, Germany, November 2004.
[MRKB04] M AC W ILLIAMS , A SA, T HOMAS R EICHER, G UDRUN K LINKER und
B ERND B RUEGGE: Design Patterns for Augmented Reality Systems. In: D U BOIS , E MMANUEL , P HILIP G RAY , DANIELA T REVISAN und J EAN VAN DERDONCKT (Herausgeber): IUI-CADUI Workshop on Exploring the Design and Engineering of Mixed Reality Systems, Band 91. Lehrstuhl für Angewandte Softwaretechnik, Institut für Informatik, Technische Universität
München, 2004.
[MS95]
M ULLET, K EVIN und DARRELL S ANO: Designing Visual Interfaces: Communication Oriented Techniques. SunSoft Press, 2550 Gracia Avenue, Mountain View, California, USA, 1995.
[Ovi02]
OVIATT, S HARON: Multimodal Interfaces. In: JACKO , J ULIE A. und A N DREW S EARS (Herausgeber): The Human-Computer Interaction Handbook:
Fundamentals, Evolving Technologies and Emerging Applications, Kapitel 14, Seiten 286–304. Lawrence Erlbaum Associates, Inc., 2002.
[PBT02]
P OPESCU , G EORGE P., G RIGORE C. B URDEA und H ELMUTH T REFFTZ:
Multimodal Interaction Modelling. In: S TANNEY, K AY M. (Herausgeber):
Handbook of Virtual Environments: Design, Implementation, and Applications, Human Factors and Ergonomics, Kapitel 21, Seiten 435–454. Lawrence
Erlbaum Associates, Mahwah, New Jersey, 2002.
[PT03]
P IEKARSKI , WAYNE und B RUCE H. T HOMAS: Augmented Reality User Interfaces and Techniques for Outdoor Modelling. In: ACM SIGGRAPH Symposium on Interactive 3D Graphics (I3D2003), Seiten 225–226, Monterey,
California, April 2003. Wearable Computer Laboratory, School of Computer
and Information Science, University of South Australia, ACM Press.
205
[PTB+ 02]
P OUPYREV, I VAN, D ESNEY S. TAN, M ARK B ILLINGBURST, H IROKATZU
K ATO, , H OLGER R EGENBRECHT, und N OBUJI T ETSUTANI: Developing a
Generic Augmented-Reality Interface. IEEE Computer, 35(3):44–50, March
2002.
[SBG98]
S CHMIDT, A LBRECHT, M ICHAEL B EIGL und H ANS -W. G ELLERSEN: There is more to Context than Location: Environment Sensing Technologies for
Adaptive Mobile User Interfaces. In: Proceedings of Workshop on Interactive
Applications of Mobile Computing (IMC98), Rostock, Germany, Nov 1998.
Telecooperation Office (TecO), University of Karlsruhe, Germany.
[SGBT00]
S CHMIDT, A LBRECHT, H ANS -W. G ELLERSEN, M ICHAEL B EIGL und
O RTWIN T HATE: Developing User Interfaces for Wearable Computers:
Don’t Stop to Point and Click. In: International Workshop on Interactive
Applications of Mobile Computing (IMC2000). TecO, University of Karlsruhe, Germany, 2000.
[Shn00]
S HNEIDERMAN , B EN: The Limits of Speech Recognition. Communications
of the ACM, 43(9):63–65, September 2000.
[Str01]
S TRICKER , D IDIER: Tracking with Reference Images: A Real-Time and Markerless Tracking Solution for Out-Door Augmented Reality Applications. In:
Proceedings of Conference on Virtual Reality, Archeology, and Cultural Heritage, Seiten 77–82, Darmstadt, Germany, 2001. Fraunhofer IGD.
[SW03]
S TRICKER , D IDIER und J ENS W EIDENHAUSEN: What can be done with
Augmented-Reality? Two applications @ the Cebit 2003. INIGRAPHICS
computer graphik topics, 15(1):34–35, 2003. Fraunhofer IGD et alii, Darmstadt.
[VIK+ 02]
V LAHAKIS , VASSILIOS, N IKOLAOS I OANNIDIS, J OHN K ARIGIANNIS,
M ANOLIS T SOTROS, M ICHAEL G OUNARIS, D IDIER S TRICKER, T IM
G LEUE, PATRICK DAEHNE und L UIS A LMEIDA: Archeoguide: An Augmented Reality Guide for Archaeological Sites. IEEE Computer & Graphics,
22(5):52–60, 2002.
206
[YA]
YACOUB , S HERIF M. und H ANY H. A MMAR: Finite State Machine Patterns.
[YYDW99] YANG , J IE, W EIYI YANG, M ATTHIAS D ENECKE und A LEX WAIBEL:
Smart Sight: A Tourist Assistant System. In: 3rd International Symposium
on Wearable Computers (ISWC’99), Seiten 73–78, San Francisco, California,
October 1999. Interactive Systems Laboratories, Carnegie Mellon University,
Pittsburgh, IEEE Computer Society.
[ZSB02]
Z UDILOVA , E.V., P.M.A. S LOOT und R.G. B ELLEMAN: A Multi-Modal Interface for an Interactive Simulated Vascular Reconstruction System. In: Proceedings of the 4th IEEE International Conference on Multimodal Interfaces
(ICMI’02). Section of Computational Science, Faculty of Science, University
of Amsterdam, IEEE Computer Society, 2002.
Abbildungsverzeichnis
1.1
Interaktion in GUI und MUI . . . . . . . . . . . . . . . . . . . . . . . .
13
2.1
i-Glasses mit SVGA-Display (mit 800 x 600 betrieben). . . . . . . . . . .
17
2.2
n-Vision Binoculars mit Firewire-Kamera und Kompass (mit 800 x 600
betrieben). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3
PDA im „ragged case“. . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.4
Dell Sub-Notebook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5
Funktionsweise der Spracherkennung in SAPI . . . . . . . . . . . . . . .
20
3.1
Geste „Daumen rechts“ führt zum Wechsel des Overlay. . . . . . . . . . .
33
3.2
Geste „Daumen rechts“ zeigt nächstes Overlay. . . . . . . . . . . . . . .
33
3.3
Microsoft™Sidewinder Freestyle Pro Gamepad. . . . . . . . . . . . . . .
47
4.1
Multimodale Ereignisverarbeitung . . . . . . . . . . . . . . . . . . . . .
78
4.2
Räumliches Feedback außerhalb der AOI. . . . . . . . . . . . . . . . . .
82
4.3
Räumliches Feedback innerhalb eines AOI. . . . . . . . . . . . . . . . .
82
4.4
Relation der Steuerelemente (Mockup) . . . . . . . . . . . . . . . . . . .
87
4.5
Hierarchiemenü mit horizontaler Baumstruktur (Konzept). . . . . . . . .
88
4.6
Alternatives Hierarchiemenü mit Baumstruktur (Konzept). . . . . . . . .
88
207
208
ABBILDUNGSVERZEICHNIS
4.7
Menü mit Miniaturbildern und Bezeichnern (Konzept). . . . . . . . . . .
88
4.8
Hotspots eines Exponats (Konzept) . . . . . . . . . . . . . . . . . . . . .
90
4.9
Komponentenkommunikation . . . . . . . . . . . . . . . . . . . . . . .
93
4.10 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.1
Keymapping (algorithmisch) . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2
Keymapping (schematisch) . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3
Positionierung im Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.1
Hervorgehobene Hotspots. . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.2
Hervorgehobene Hotspots mit markanterem semantischem Bezug (Mockup).122
6.3
Exhibitmenü in versteckter Ansicht. . . . . . . . . . . . . . . . . . . . . 123
6.4
Vertikale Sitenavigation (Mockup). . . . . . . . . . . . . . . . . . . . . . 124
6.5
„Schwebendes“ Menü (Mockup). . . . . . . . . . . . . . . . . . . . . . . 124
6.6
Handlermenü am dreidimensionalen Objekt (Mockup). . . . . . . . . . . 127
6.7
Innenansicht eines Objektes (Mockup). . . . . . . . . . . . . . . . . . . 127
6.8
Erklärung von Tools, Controls und Verwendung der Eingabegeräte. . . . . 129
6.9
Erklärung des Exhibitmenü und der Versteckfunktion. . . . . . . . . . . . 129
6.10 Erklärung der augmentierten Ansicht. . . . . . . . . . . . . . . . . . . . 129
6.11 Erprobung der Schnittstelle im Test. . . . . . . . . . . . . . . . . . . . . 130
6.12 Testkandidatin während der Evaluation. . . . . . . . . . . . . . . . . . . 130
6.13 Benutzerfreundlichkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.14 Erfüllte Erwartungshaltung. . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.15 Bevorzugte Eingabegeräte. . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.16 Leichte Gewöhnung an die Eingabegeräte. . . . . . . . . . . . . . . . . . 133
6.17 Immersionsgefühl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
209
6.18 Intuitive Interaktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.19 Multimodales Interaktionsgefühl. . . . . . . . . . . . . . . . . . . . . . . 135
6.20 „Aktiv“-Icon (Konzept) . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.21 Kommandos und Labels . . . . . . . . . . . . . . . . . . . . . . . . . . 146
C.1 Benutzerbedürfnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
C.2 Benutzerhandlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
C.3 Area of Interest (AOI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
C.4 Point of Interest (POI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
C.5 Erkunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
C.6 Nachfragen nach Informationen . . . . . . . . . . . . . . . . . . . . . . 175
C.7 Dokumentieren und Erinnern . . . . . . . . . . . . . . . . . . . . . . . . 176
C.8 Empfehlen und Führen lassen . . . . . . . . . . . . . . . . . . . . . . . . 177
C.9 Erklären lassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
C.10 Nachforschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
C.11 Kontrollieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
E.1 Fokussierter POI eines AOI . . . . . . . . . . . . . . . . . . . . . . . . . 185
E.2 Selektierter POI eines AOI . . . . . . . . . . . . . . . . . . . . . . . . . 186
E.3 Showcase mit 3D Modell . . . . . . . . . . . . . . . . . . . . . . . . . . 186
E.4 Kompass zur Navigation zu einem AOI oder POI . . . . . . . . . . . . . 186
F.1
Frage „Wo bin ich?“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
F.2
Frage „Was kann ich hier sehen?“ . . . . . . . . . . . . . . . . . . . . . 188
F.3
Frage „Was ist in der Nähe?“ . . . . . . . . . . . . . . . . . . . . . . . . 189
210
Tabellenverzeichnis
5.1
Realisierte Widgets und ihre Funktionen . . . . . . . . . . . . . . . . . . 115
6.1
GUI vs. MUI (Kriterien nach Oviatt [Ovi02]) . . . . . . . . . . . . . . . 150
211
212
TABELLENVERZEICHNIS
Listings
5.1
Konfiguration der Mausereignisfilter . . . . . . . . . . . . . . . . . . . .
5.2
Beispieleintrag der Keymap . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3
Beispieleintrag der Keymap für Events mit Zusatzinfo . . . . . . . . . . . 103
5.4
Beispieleintrag der Keymap für multimodale Befehle . . . . . . . . . . . 105
5.5
FSM-Konfiguration am Beispiel des Exponatmenüs . . . . . . . . . . . . 107
5.6
Auszug aus der Konfiguration des UIManagers . . . . . . . . . . . . . . 109
5.7
Auszug aus der Konfiguration der Kommandoleiste . . . . . . . . . . . . 117
213
98

Extension of ARGuide – A Multimodal User

Transcription

Similar documents

Dokument_7.

07_09_28_ecue manual basic DIN A5 v3.8 DEU FINAL

Internetbasierte geleitete Selbsthilfeansätze bei Angststörungen und