Projektbericht - Universität Oldenburg

Transcription

AirWeb
Projektgruppe AirWeb
April 2000 - April 2001
Carl von Ossietzky Universität
Oldenburg
Projektbericht
Inhaltsverzeichnis
1
2
3
Einführung
5
1.1
Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2
Beteiligte Personen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
Verlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4
Online-Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Seminarphase
7
2.1
Verlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Referatsthemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Konzept und Prototyp
8
3.1
Ausblick auf dieses Kapitel . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2.1
Technik/Realisierungsumgebung . . . . . . . . . . . . . . . .
8
3.2.2
Programmiersprache und Entwicklungsumgebung . . . . . .
9
3.2.3
Integrierte Entwicklungsumgebung (IDE) . . . . . . . . . . . .
9
Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.3.1
Raumkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.3.2
Weitere Verfeinerung des Raumkonzeptes . . . . . . . . . . .
11
3.3.3
Navigationskonzepte . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3.4
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Realisierung/Implementation des Prototypen . . . . . . . . . . . . .
15
3.4.1
Verlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.4.2
Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.3
3.4
4
Erste Evaluationen
17
4.1
Ausblick auf dieses Kapitel . . . . . . . . . . . . . . . . . . . . . . . .
17
4.2
Evaluation der Töne . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.2.1
Lokalisierbarkeit und Angehnehmheit der Töne . . . . . . . .
17
4.2.2
Evaluation der Töne innerhalb des Prototypen . . . . . . . . .
19
Evaluation des Prototypen . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.3.1
20
4.3
Verbesserungen am Prototypen . . . . . . . . . . . . . . . . . .
INHALTSVERZEICHNIS
5
6
4.3.2
Planung und Durchführung der Evaluation . . . . . . . . . . .
21
4.3.3
Auswertung und Konsequenzen für die Projektgruppe . . . .
21
Produkt
24
5.1
Anforderungsdefinition und Entwurf . . . . . . . . . . . . . . . . . .
24
5.2
Überarbeitetes Konzept . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.3
Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.4
Anbindung des Internet Explorers . . . . . . . . . . . . . . . . . . . .
25
5.5
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.6
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Abschluss
27
6.1
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.1.1
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.1.2
Steuerbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
6.1.3
Erlernbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
6.1.4
Aufgabenangemessenheit . . . . . . . . . . . . . . . . . . . . .
29
Ergebnisse der Evaluation . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.2.1
Steuerbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.2.2
Erlernbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.2.3
Aufgabenangemessenheit . . . . . . . . . . . . . . . . . . . . .
31
6.2
A Erste Raumkonzepte
33
A.1 Gruppe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
A.2 Gruppe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
A.3 Gruppe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
A.4 Gruppe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
B Auswahl der IDE
41
B.1 IBM Visual Age 3 Entry Edition . . . . . . . . . . . . . . . . . . . . . .
41
B.2 Sun Forte 1.01 Community Edition . . . . . . . . . . . . . . . . . . . .
42
B.3 Microsoft Visual J++ 6.0 Enterprise Edition . . . . . . . . . . . . . . .
42
B.4 Borland Inprise JBuilder 3 Professional Edition . . . . . . . . . . . . .
43
C Evaluation der Töne
44
D Erster Test des Prototypen
46
D.1 Handlungsanweisungen für den ersten Schritt . . . . . . . . . . . . .
46
D.2 Ergebnisse der Evaluation . . . . . . . . . . . . . . . . . . . . . . . . .
47
E Evaluation des Prototypen
E.1 Versuchsablauf und Aufgaben . . . . . . . . . . . . . . . . . . . . . . .
48
48
3
INHALTSVERZEICHNIS
E.2 Beobachtungen und Ergebnisse . . . . . . . . . . . . . . . . . . . . . .
49
E.2.1
Anzahl erkannter Hearcons . . . . . . . . . . . . . . . . . . . .
49
E.2.2
Lokalisierung der Hearcons . . . . . . . . . . . . . . . . . . . .
49
E.2.3
Zeitbedarf für das Lokalisieren der Hearcons . . . . . . . . . .
50
E.2.4
Beobachtungen durch die Videoaufzeichnung . . . . . . . . .
51
F Technische Beschreibung des Produkts
53
F.1
Anbindung des Internet Explorers . . . . . . . . . . . . . . . . . . . .
53
F.2
Technische Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . .
54
F.2.1
Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . .
54
F.2.2
Kommandozeilenparameter . . . . . . . . . . . . . . . . . . . .
55
F.2.3
Verwendete Komponenten/Bibliotheken . . . . . . . . . . . .
55
4
Kapitel 1
Einführung
1.1 Zielsetzung
Ziel der Projektgruppe war die Schaffung einer Augmented Reality, indem klassische grafische Benutzungsoberflächen um einen auditiven Interaktionsraum erweitert werden. An einem Beispielszenario sollte ein Referenzmodell für die Abbildung von vorhandenen Interaktionsobjekten mit ihren topografischen und topologischen Merkmalen auf ihre entsprechenden akustischen Interaktionsobjekte
entwickelt werden. Daneben sollten Überlegungen angestellt werden, welche Interaktionsobjekte mit Hilfe der Kunstkopfstereophonie als Phantomgeräusche (Hearcons) nur im Hörraum der Augmented Reality neu zur Verfügung gestellt werden können. Für das Beispielszenario sollte im Rahmen der Projektgruppe eine
Benutzungsoberfläche der Augmented Reality realisiert werden, bei der softwareergonomische Aspekte der Gestaltung eine besondere Berücksichtigung fanden.
1.2 Beteiligte Personen
Teilnehmerinnen und Teilnehmer waren:
Baranowski, Ardadiusz [email protected]
Erdmann, Oliver
[email protected]
Noll, Ralph-Peter
[email protected]
Stumpe, Jörg
[email protected]
Weers, Michael
[email protected]
Wendt, Dagmar
[email protected]
Wesskallnies, Thorsten [email protected]
Witte, Marc
[email protected]
Die Betreuung erfolgte durch:
Donker, Hilko
Gorny, Peter
Klante, Palle
[email protected]
[email protected]
[email protected]
1.3 Verlauf
1.3 Verlauf
Der grobe zeitliche Verlauf der Projektgruppe stellt sich folgendermaßen dar:
April 2000
11.5.2000
22.6.2000
27.7.2000
4.8.2000
21.8.2000
26.9.2000
ab 5.10.200
9.11.2000
16.11.2000
ab 21.11.2000
4.12.2000
5.12.2000
7.12.2000
16.1.2001
21.2.2001
ab 22.3.2001
12.4.2001
2.-3.5.2001
10.5.2001
Erstes Treffen, Verteilung der Seminarthemen
Seminarphase (bis 15.6.2000)
Ganztagestreffen, erste Konzepte/Vorstellungen
Start der Erstellung des Prototypen
Anforderungsdefinition des Prototypen
Urlaub (bis 11.9.2000)
Urspünglich geplanter Fertigstellungstermin des Prototypen
(Wiederverwendbare) Teilmodule des Prototypen stabilisieren
1. Evaluation innerhalb der Projektgruppe
2. Evaluation innerhalb der Projektgruppe
Integration der Internet-Explorers
Evaluation von Tönen
Evaluationstauglicher Prototyp
Evaluation mit projektgruppenfremden Personen
Verabschiedung der Anforderungsdefinition für den AirBrowser
Endversion des Entwurfs für den AirBrowser
Erstellung des Projektberichts
Geplanter Fertigstellungstermin
Abschließende Evaluation des AirBrowser
Präsentation & Feierlicher Abschluß
1.4 Online-Version
Die Projektgruppe besitzt eine Website, bestehend im wesentlichen aus den Arbeitsdokumenten, die über die gesamte Zeit der Projektgruppe entstanden sind. Dort ist
auch eine HTML-Fassung dieses Projektberichts zu finden. Die Website ist zu finden
unter:
Projektgruppe AirWeb
http://www-cg-hci.informatik.uni-oldenburg.de/ãirweb/
6
Kapitel 2
Seminarphase
2.1 Verlauf
Anders als üblich wurden die Seminarthemen zum Anfang des Semesters verteilt
und nicht am Anfang der Semesterferien. Deshalb konnte erst am 11.05.00 mit den
Vorträgen begonnen werden. Jede/r TeilnehmerInnen erhielt ein Thema, zu dem
er/sie dann eine Ausarbeitung schreiben und ein ca. 45–minütiges Referat halten
mußte. Anschließend wurde noch ca. 45 Minuten diskutiert, um Fragen zum Thema
zu klären.
2.2 Referatsthemen
Folgende Themen wurden in der Seminarphase behandelt:
Einführung ZIB
Akustik im WWW - Soundunterstützung in webbasierten Sprachen
Web-Usability
Metaphern und mentale Modelle
Interaktion und auditive Interaktionsobjekte
Realität und Wahrnehmung in der Akustik
Multimodale Ein- und Ausgabetechniken
Entwicklungsmethoden Software-Engineering und Software-Ergonomie
Evaluation
Anwendungsszenarien von AIRen
Die Ausarbeitungen der Seminare sind in der Online-Fassung zu finden unter:
Seminarthemen — Projektgruppe AirWeb — 11.05.00 – 15.06.00
http://www-cg-hci.informatik.uni-oldenburg.de/
ãirweb/AirWeb-Seminarthemen.html
Kapitel 3
Konzept und Prototyp
3.1 Ausblick auf dieses Kapitel
Dieses Kapitel beschreibt die ersten Arbeiten, die zur Erstellung des Prototypen
notwendig waren.
Der folgende Abschnitt 3.2 stellt einige Rechercheergebnisse dar, die die technische
Umgebung des Produkts klären sollten. Dazu gehört zum einen die Produktplattform, d.h. das System, in dem das fertige Produkt laufen soll, sowie die Entwicklungsplattform, d.h. die Wahl der Entwicklungsumgebung, der Tools und der Programmiersprache.
Der darauffolgende Abschnitt 3.3, „Konzept“, befaßt sich mit der Diskussion um
die inhaltliche Gestaltung des Produkts. Die Aufgabenstellung der Projektgruppe
war bezüglich der Funktionalität weitestgehend nicht festgelegt, so daß hier viele
kreative, aber auch konträre Ideen zusammengebracht werden mußten.
Diese ersten konzeptionellen Überlegungen gipfelten dann zunächst in der Erstellung eines Prototypen, der im Abschnitt 3.4 beschrieben ist.
3.2 Recherche
3.2.1 Technik/Realisierungsumgebung
Für die Entwicklung des Prototypen wurden von der Abteilung drei Rechner mit
500 MHz Pentium III - Prozessor, 128 MB RAM und 19 Zoll-Monitor zur Verfügung gestellt. Diese Konfiguration ist auch Referenzplattform zur Demonstration
des Prototyps.
Neben den obligatorischen Mäusen und Tastaturen kommen als weitere Eingabegeräte drei Analogjoysticks mit je 2 Achsen zum Einsatz. Diese Joysticks erschienen
nach eingehender Analyse des Marktes für andere mögliche analoge Eingabegeräte
(z.B. SpaceBall) als einzig realistische Alternative, da die erhältichen Dokumentationen für die Programmierung nicht ausreichend genug war.
Eine wesentliche Rolle kommt in diesem Projekt der akustischen Ausgabe zu. Hierfür wurden Aureal Vortex2 AU8830 kompatible Soundkarten eingesetzt. Für diese
Wahl sprach erstens das in der Abteilung vorhandene Know-How inklusive vorhandener Java-Anbindung, zweitens die Fähigkeit zur Berechnung der akustischen
Umgebungsmodelle in Hardware und drittens die reichhaltige mitgelieferte Programmierschnittstelle A3D. Zur Kontrolle der Ausgabe sind Kopfhörer vorhanden.
3.2 Recherche
Als Betriebssystem läuft auf den Rechnern Windows 2000, Zeitweise wurde auf
Windows 98 umgestellt, um das Verhalten verschiedener Treiberversionen zu vergleichen.
Um eine parallele Arbeit an allen drei Arbeitsplätzen zu ermöglichen, sind alle
Rechner an das Ethernet-Netzwerk des Fachbereichs angeschlossen. Die anfallenden Daten des Projekts werden zentral auf dem Abteilungsserver gehalten und auf
den Rechnern als Netz-Laufwerk gemountet.
3.2.2 Programmiersprache und Entwicklungsumgebung
Parallel zur Anforderungsdefinition des Prototypen beschäftigte sich eine zweite Arbeitsgruppe mit technischen Details. Diese sogenannte Technikgruppe hatte
die Aufgabe zu klären, welche Entwicklungsumgebung verwendet werden sollte,
welche CVS-Konfiguration möglich und sinnvoll ist (lokal oder Server) und welche Schnittstelle zur Soundkarte und zum Eingabegerät (Joystick) zur Verfügung
steht bzw. verwendet werden soll. Aus Administrationsgründen wurde entschieden, dass ein CVS-Server nicht zum Einsatz komme. Für den Joystick wurde eine
Standard-DLL gefunden, für die eine Java-Wrapperklasse geschrieben werden musste. Für die A3D-Soundkarte existierte bereits eine Java-Schnittstelle, die von der
Abteilung CG/HCI bereitgestellt wurde.
3.2.3 Integrierte Entwicklungsumgebung (IDE)
Zur Auswahl und zum Test standen folgende integrierte Entwicklungsumgebungen für Java zur Verfügung:
Borland JBuilder 3 Professional Edition
IBM Visual Age 3 Entry Edition
Sun Forte 1.01 Community Edition
Microsoft Visual J++ 6.0 Professional Edition
Die IDEs wurden bzgl. der Systemanforderrungen, der benutzbaren JDKs, der JavaKonformität, der Dokumentation, der Fähigkeiten des GUI-Builders und der produkteigenen Besonderheiten hin untersucht.
Die Ergebnisse für die einzelnen IDEs sind im Anhang B auf Seite 41 zu finden.
Für die Arbeit der Projektgruppe wurde der JBuilder von Borland als bestes Werkzeug ausgewählt. Wichtig für den Einsatz in der Projektgruppe war vor allem die
Fähigkeit zwischen mehreren JDK-Konfigurationen zu wechseln und die Möglichkeit sehr einfach weitere Biblotheken einzubinden. Das Paket ist ausreichend gut
dokumentiert und es gibt diverse Quellen im Internet (z.B. News), was in Problemfällen immer von Vorteil ist. Die fehlende interne Versionsverwaltung wird durch
ein CVS-System ersetzt. Das Programm ist flexibel und wird bereits in anderen Projekten eingesetzt. Der hieraus resultierende Vorsprung an praktischer Erfahrung
und die sofortige Verfügbarkeit sprechen ebenfalls für den Einsatz dieser IDE.
9
3.3 Konzept
3.3 Konzept
Grundsätzlich gingen wir von der Möglichkeit aus, mit Hilfe der 3D-Möglichkeiten
der Soundkarte verschiedene Geräusche an verschiedenen Hörpositionen zu plazieren. Die Geräusche können also so klingen, als ob sie sich in weiterer oder näherer
Entfernung an einem beliebigen Ort befinden. So ergab sich bald die Idee mehrere Geräusche um den Hörer anzuordnen, einige davon näher, einige entfernter. Die
Idee war, daß sich dadurch ein Raum-Gefühl einstellt. Dabei ist Raum nicht im Sinne
von geschlossenem Raum zu verstehen, sondern in dem Sinne, das die Geräusche
darin so angeordnet sind wie die Gegenstände in einem Raum. Ganz im Sinne dieser Analogie sind daher unterschiedliche Geräusche an unterschiedlichen Plätzen
angeordnet und man kann sich auf diese Geräusche zubewegen.
Eine weitere Analogie zum Raum ergibt sich durch die Funktionalität. Aus der Idee
der Geräusche folgte, diese mit Bedeutungen und Funktionen zu belegen. Schon
früh war klar, das die Anzahl der gleichzeitig zu spielenden und zu erkennenden Töne begrenzt sein muß. Also muß es einen Austausch der Funktionen geben,
so daß eine andere Palette von Geräuschen andere Funktionen übernehmen kann.
Auch dies ist analog zur Raummetapher, da es auch in einem Haus unterschiedliche Räume mit unterschiedlichen Funktionen gibt — Der Wechsel der Geräusche
entspricht also einem Raumwechsel.
Dieses Konzept des Raums sollte in einer Art Internet-Browser zur Anwendung
kommen. Die genauen Details und Abwandlungen von einem herkömmlichen Browser waren zu Beginn natürlich noch nicht festgelegt. Die Hauptaspekte jedoch, daß
also in irgendeiner Form Inhalte präsentiert werden und daß man durch diese Texte
navigieren kann, sollten auf jeden Fall Grundlage werden.
3.3.1 Raumkonzepte
Zunächst mußten also Konzepte für diese Räume entwickelt werden. Zentrale Fragestellung war dabei zum einen die detaillierte Ausarbeitung des Raumkonzepts,
soweit dies schon Konsens war. Zum anderen sollten konkrete Vorschläge gemacht
werden, wie die noch nicht geklärten Punkte gelöst werden können. Dies waren die
folgenden Fragen:
Geplant war die Erstellung eines Prototypen. Daraus ergab sich die Frage, welche Anteile der Konzepte konkret prototypisch umsetzbar sind.
Einer der Räume sollte zur Bedienung des Programms benutzt werden, bzw. die
höchste Hierarchiebene dieser Kontrolle darstellen. Daraus erwuchs die Frage
nach der prototypischen Umsetzung dieses Kontrollraums.
Strittig war auch noch die Funktionalität des Browsers im einzelnen. Diese musste noch festgelegt werden.
Ungeklärt war auch noch die Frage der Präsentation. Dies bezieht sich zum
einen auf die Präsentation der Inhalte, zum anderen auch auf die Präsentation
der einzelnen Geräusche.
Um eine möglichst große Auswahl von Raumkonzepten zu haben, wurden vier
Gruppen aus je zwei Personen gebildet, die jeweils ein möglichst konkretes Raumkonzept entwerfen sollten.
Die entstandenen Raumkonzepte sind im Anhang A dokumentiert. Die Beschreibung jedes Konzepts besteht aus drei Teilen. Zunächst ist das Konzept beschrieben,
10
3.3 Konzept
wie es ursprünglich auch präsentiert wurde (Unter der Überschrift „Beschreibung“
im Anhang). Jedes Konzept wurde einer Kritik durch die übrigen Projektgruppenmitglieder unterzogen („Kritik“). Zum Abschluß wurden jeweils die innovativen
Aspekte der einzelnen Vorschläge herausgestellt („Innovative Aspekte“). Der Vollständigkeit halber sind hier alle genannten Punkte aufgeführt worden, was die teilweise widersprüchlichen Nennungen erklären sollte. Auch ist aufgefallen, daß einige Punkte sowohl negativ als auch positiv bewertet wurden.
Alle diese Punkte wurden festgehalten, um — in weiteren Schritten — aus diesen
Punkten unser zu entwerfendes Produkt festzulegen.
3.3.2 Weitere Verfeinerung des Raumkonzeptes
Nach der Diskussion der Raumkonzepte, wurde beschlossen, ein Produkt zu entwickeln, welches die Funktionalität des Vorschlages der Gruppe 2 besitzen, zusätzlich jedoch auch eine vereinfachte Version des Karten-Konzeptes der Gruppe 4 enthalten sollte.
In dem von der Gruppe 2 erstellten Vorschlag wurde eine grundlegende Unterscheidung der Raumtypen in einen Inhaltsraum und mehrere Kontrollräume vorgesehen. Im Inhaltsraum sollte die Darstellung des Inhaltes erfolgen. Vom HauptKontrollraum aus war ein Übergang in spezialisierte weitere Kontrollräume wie
Besuchte-Seiten-Raum, Favoriten-Raum, Vorwärtslisten-Raum, Suchergebnisse-Raum
und Hilfe-Raum möglich. Die rein akustische Präsentation sollte 2-dimensional um
den Hörer herum erfolgen, wobei die Hearcons an festen, vom Mittelpunkt gleichweit entfernten Positionen lagen.
Bei dem von Gruppe 4 entwickelten Kartenkonzept wurde eine Karte für den SurfVerlauf erzeugt, die sowohl die besuchten Seiten als auch die Übergänge zwischen
ihnen beinhaltete. Für jede betretene Seite wird die Vorwärtsliste aller ihrer Links
eingelesen. Werden Links dieser Seite verfolgt, so werden sie aus der allgemeinen
Vorwärtsliste dieser Seite in eine benutzte-Links-Liste der Seite übertragen. Für die
neue Seite wird nun ebenfalls eine Vorwärtsliste und zusätzlich auch eine Rückwärtsliste erstellt. Die Rückwärtsliste enthält alle Seiten, von denen aus die aktuelle
Seite betreten wurde. So entsteht ein Netz, das den Surf-Verlauf von einer Startseite ausgehend abbildet. Es ist möglich, innerhalb eines Programmablaufes mehrere solcher Netze zu erstellen, in dem unterschiedliche Seiten als Startseite eine
Surf-Verlaufes angegeben werden. Auf Wunsch können solche Surfverlaufe auch
abgespeichert werden, so daß ein Bookmarknetz bzw. mehrere Bookmarknetze entstehen.
Es wurden 2 Gruppen mit jeweils 4 Personen gebildet, die die Aufgabe hatten, diese
beiden Konzepte weiterzuentwickeln und miteinander zu verbinden. Dabei setzten
sich die beiden Gruppen unterschiedliche Schwerpunkte. Gruppe I beschäftigte sich
vor allem mit Auswahl und Funktionalität der Kontrollräume, während Gruppe II
sich darauf konzentrierte, eine akustische Repräsentation für das Kartenkonzept zu
finden.
Die beiden Konzepte sind unter:
Kontrollraum Konzept 2 — Gruppe I — Projektgruppe AirWeb — 23.07.2000
ãirweb/Konzept/Prototyp/Kontrollraum_ll_a.pdf
und unter:
11
3.3 Konzept
Kontrollraum Konzept 2 — Gruppe II — Projektgruppe AirWeb — 23.07.2000
ãirweb/Konzept/Prototyp/navconcept0724.pdf
zu finden.
Gruppe I entwarf eine grundsätzliche Unterteilung der Räume in eine Inhaltsebene
und eine Kontrollebene. In der Inhaltsebene wird der Seiteninhalt dargestellt und
eine Navigation durch die dargestellte Seite ermöglicht. Die Kontrollebene besteht
aus mehreren, ringförmig angeordneten Räumen. Von jedem dieser Räume ist ein
Wechsel in die Inhaltsebene möglich. Alle Räume werden zusätzlich zur akustischen Repräsentation auch graphisch dargestellt.
Für die Kontrollebene entwickelte Gruppe I zwei Konzepte. Im Kontrollebenenkonzept Ia besteht die Kontrollebene aus mehreren, gleichartig aufgebauten Kontrollräumen. Diese Kontrollräume sind runde Räume in denen an bestimmten Stellen
Hearcons angeordnet sind. Jedes Hearcon steht dabei für eine Funktion. Zur besseren Unterscheidbarkeit der Räume, wird jeder Raum mit einem spezifischen Hintergrundgeräusch ausgestattet. Ein Hearcon erklingt nur innerhalb eines bestimmten
Abstandes um seine Position.
Die Navigation zwischen Kontrollräumen erfolgt durch Raumwechsel-Hearcons,
die links und rechts im Hearconkranz liegen. Als Geräusch eines solchen Hearcons
wird das Hintergrundgeräusch des mit ihm zu erreichenden Raumes benutzt. Da
die Kontrolräume ringförmig aufgereiht sind, kann jeder Raum durch wiederholtes
Auslösen des rechten bzw. linken Hearcons erreicht werden.
Im Kontrollebenenkonzept Ib wurde die Auswahl der Kontrollräume anders gelöst.
Zwischen Inhalts- und Kontrollebene wurde eine zusätzliche Laufstiegsebene eingeführt. Kontrollräume können ausschließlich von dieser Laufstiegsebene aus betreten werden. Ein direkter Übergang von der Inhaltsebene zu einem Kontrollraum
oder umgekehrt ist nicht möglich.
Gruppe II gelang es nicht, eine Möglichkeit zu finden, die Karte insgesamt akustisch darzustellen. Sie fand allerdings eine Möglichkeit die Vor- und Rücklinks einer einzelnen Seite akustisch zu präsentieren. Es wurde ein kreisförmiger akustischer Raum angenommen, indem sich Wechsel-Hearcons zu anderen Kontrollräumen direkt links und rechts befinden. Im hinteren Bereich des Raumes befinden sich
Hearcons die vorherige Seiten bezeichnen (Rücklinks), im vorderen Bereich werden
die von dieser Seite ausgehenden Links angeordnet (Vorlinks). Die Links die schon
verfolgt wurden werden hierbei links vorne angezeigt.
In der anschließenden Diskussion entschied sich die Projektgruppe für das Kontrollraumkonzept der Gruppe I und hierbei für das Kontrollebenenkonzept Ia. Das
Konzept der Gruppe II zur akustischen Darstellung des Kartenraumkonzeptes wurde für zu komplex gehalten. Eine Umsetzung dieses Konzeptes im Rahmen der Projektgruppe wurde daher abgelehnt.
3.3.3 Navigationskonzepte
3.3.3.1
Navigation im Internet
Im derzeitigen Web werden als Navigationshilfen bei der Linkauswahl lediglich
das Linkziel und eine Linkbeschreibung angegeben (href-Attribut des A-Tags, bzw.
der zwischen A-Tag und A-Endtag geklammerte Text). Weitere Informationen, etwa
über die Art des Zieldokumentes, wären zwar bei der Linkauswahl sinnvoll und
12
3.3 Konzept
hilfreich, sind jedoch derzeit nicht verfügbar.
In dem von uns entwickelten Konzept können diese Zusatzinformationen mit Hilfe
eines eigenen XML-Derivates angegeben werden. Die Darstellung erfolgt innerhalb
des akustischen Browsers. Hierbei werden zu jedem Zeitpunkt ausschließlich die
Zusatzinformationen zu höchstens einem (ausgewählten) Link dargestellt.
Bei den möglichen Zusatzinformationen handelt es sich etwa um Angaben zur Größe der Zielseite, zum Ort der Zielseite (innerhalb derselben Site, anderswo im Internet) oder von zusätzlichen Kommentaren über die Zielseite.
3.3.3.2
Navigation innerhalb des AIRBrowsers
Die Navigation innerhalb des akustischen Browsers definiert sich durch folgende
Punkte:
1. Navigation innerhalb der akustischen Räume
Innerhalb des Browsers werden die vorhandenen Funktionen durch Hearcons
akustisch dargestellt, welche räumlich um den Benutzer herum gruppiert sind.
Innerhalb des akustischen Raumes bewegt sich der Anwender. Die akustische
Ausgabe wird hierbei an seine Position im Raum angepaßt, indem die Lautstärke der Hearcons aufgrund der Entfernung zum Benutzer angepasst wird.
Um eine Funktion auslösen zu können, muß sich der Benutzer auf das entsprechende Hearcon bewegen und dort eine Aktion über das Steuergerät auslösen.
Die akustische Darstellung hängt nicht nur von der Positionierung des Anwenders, sondern auch vom Zustand der Funktionen ab. Ein Hearcon erzeugt unterschiedliche Ausgaben, je nachdem ob die Funktion zur Zeit verfügbar ist, nicht
verfügbar ist oder ausgewählt wurde.
Um eine akustische Überfrachtung des Anwenders zu verhindern, werden die
Funktionen in Räumen aufgeteilt, welche maximal 8 Hearcons enthalten dürfen. Zwischen diesen Räumen kann mit Hilfe zweier spezieller RaumwechselHearcons navigiert werden. Räume können also höchsten 6 Funktions-Hearcons
enthalten.
2. Linkauswahl
Zusätzlich zur klassischen Linkauswahl mit Hilfe des Eingabegerätes ist eine
weitere Möglichkeit zur Linkauswahl vorgesehen. Alle Linkverweise der Inhaltsseite werden in einer Vorwärtsliste zusammengefaßt, innerhalb der ebenfalls Links ausgewählt werden können. Bei dieser Vorwärtsliste handelt es sich
um eine der Funktionen, die über ein Hearcon ausgewählt werden kann.
Ist ein Link ausgewählt werden seine Zusatzinformationen - falls vorhanden akustisch dargestellt.
3. Bookmarks
Als Bookmarks markierte Internetseiten werden in einer Bookmarkliste (einer
weiteren Funktion) zusammengefaßt. Diese Liste kann während der Programmbenutzung editiert werden. Die Bookmarkliste wird beim Programmende gespeichert.
13
3.3 Konzept
3.3.4 Anforderungen
Im nächsten Schritt wurden einige Konzepte in einem Prototypen umgesetzt. Dieser Prototyp sollte zum einen die technische Machbarkeit einiger Ideen prüfen. Zum
anderen sollte er dazu dienen, die widersprüchlichen Argumente für verschiedene
Konzepte, deren Gegensätze über die Diskussion nicht aufzulösen waren, am realisierten Beispiel zu überprüfen.
Geplant war von vorneherein eine Evaluation mit projektgruppenfremden Personen, um einige der Ideen zur Steuerung des Programms auf ihre Tauglichkeit zu
überprüfen.
Um in einem knappen Rahmen von ursprünglich angesetzten sechs Wochen einen
lauffähigen Prototypen zu realisieren, konnte natürlich aus dem bisherigen Gesamtkonzept nur einiges exemplarisch herausgegriffen werden. Die wesentlichen Punkte waren:
1. Anordnung von acht Hearcons in einem „Kranz“ um den Hörer.
2. Diese Hearcons behalten ihre Position im Raum, der Hörer kann sich auf sie
zubewegen, er verändert dabei seine Orientierung nicht.
3. „Raumwechsel“, d.h. mit Hilfe eines Hearcons kann auf eine andere Achtergruppe von Hearcons (mit anderen Geräuschen und anderer Funktionalität) umgeschaltet werden.
4. Wesentliches Hilfmittel der Selbstbeschreibungsfähigkeit ist das Vorlesen der
Funktionen.
Einsparungen ergaben sich insbesondere bei folgenden Punkte:
1. Im wesentlichen fehlt die Funktionalität hinter den Hearcons; die Hearcons können nur angesteuert werden, das „Auslösen“ hat jedoch im weiteren keine Auswirkungen.
2. Es gibt keinen relevanten Inhalt. Dargestellt wird nur eine (statische) Seite, damit überhaupt eine Darstellung vorhanden ist. Die Evaluation (s. Kap. 4.3 auf
Seite 20) wurde dann auch mit fehlender Sicht der Testpersonen auf den Bildschirm durchgeführt.
3. Von den vielen angedachten Eingabemöglichkeiten wurden nur die Maus und
der Joystick (in einer Steuerungsvariante) realisiert.
4. Reduzierung auf zwei Steuerelemente: Hearcons mit Trefferfläche und Pull-downMenüs mit diskret anzusteuernden Einträgen. Im Endeffekt wurde nur die erste
Variante bis zur Evaluationsfähigkeit weiterentwickelt.
Die detaillierten Anforderungen an den Prototypen sind in der Anforderungsdefinition festgehalten:
Anforderungsdefinition Prototyp —
Projektgruppe AirWeb — 04.08.2000
ãirweb/Prototyp/Anforderungsdefinition/
14
3.4 Realisierung/Implementation des Prototypen
3.4.1 Verlauf
Nachdem die technischen Details geklärt waren, wurde eine Arbeitsgruppe dazu
eingeteilt die Programmstruktur mittels eines Klassendiagramms zu entwerfen. Dabei wurde die Vorgabe, den Prototypen in vier möglichst unabhängige Module zu
unterteilen, von der gesamten Projektgruppe gemacht. Darüberhinaus sollten von
der gleichen Arbeitsgruppe die Schnittstellen der Module spezifiziert werden. Eine weitere Gruppe kümmerte sich um die grafischen Elemente, speziell Icons, des
Prototypen und eine dritte Gruppe wurde beauftragt, Geräusche bzw. Klänge zu
suchen und eventuell anzupassen.
Das Klassendiagramm für das gesamte Programm gibt es unter
Klassendiagramm Prototyp — Projektgruppe AirWeb
ãirweb/Prototyp/Documents/klassenkonzept.pdf
Für das Teilsystem für die Soundausgabe gibt es ein eigenes Klassenkonzept:
Soundteilsystem Klassendiagramm Prototyp — Projektgruppe AirWeb
ãirweb/Prototyp/Documents/SoundTeilsystem_V6.pdf
Hauptdatenklasse und Schnittstelle zwischen dem Sound-Teilsystem und dem übrigen Programm ist die SoundData-Klasse:
Klasse SoundData Prototyp — Projektgruppe AirWeb
ãirweb/Prototyp/Documents/SoundData_V4.pdf
Die Benutzung der Sound-Klassen verdeutlichen die Kommunikationsszenarien zum
Sound-Teilsystem:
Klasse SoundData Prototyp — Projektgruppe AirWeb
ãirweb/Prototyp/Documents/SoundAktionen_V2.pdf
Vor der Implementation wurde eine Namenskonvention, die ein Schema für die Namensgebung der Variablen, Konstanten und Methoden angibt, und eine Formatierungskonvention, die z.B. angibt wie weit und wann im Quelltext eingerückt werden soll, verabschiedet. Beide Konventionen sind in elektronischer Form im Projektgruppenverzeichnis festgehalten. Diese Konventionen sollen die Lesbarkeit und
Verständlichkeit der Quelltexte erleichtern. Die Einarbeitung in die Entwicklungsumgebung wurde von jedem Projektgruppenteilnehmer in eigener Regie übernommen. Die Implementation selbst wurde auf zwei gleich große Arbeitsgruppen aufgeteilt. Die erste Gruppe kümmerte sich um die GUI und den Sound, die zweite
Gruppe um alle Klang-Räume und den zugehörigen Raum-Kontrolleur. In der Praxis fand dann jeweils noch eine interne Aufteilung der Gruppen statt, so dass vier
Gruppen an den Teilen Sound, GUI, Räume + Kontrolleur und Event-Handler arbeiteten.
15
3.4.2 Komponenten
Der Prototyp musste auf zwei Geräte zurückgreifen, die im Java SDK nicht standardmäßig unterstützt werden. Zum einen war das der Joystick und zum anderen die A3D-Soundkarte. Die Joystick-Anbindung geschah über eine einfache, von
der Projektgruppe selbst geschriebene Wrapper-Klasse, die einfach die StandardJoystick-DLL, die von Windows mitgeliefert wird, „wrapped”. Die Dokumentation
zur DLL, stand auf den MSDN Webseiten zur Verfügung. Mit der Wrapper-Klasse
konnte man aber nur den Joystick direkt abfragen, es stand jedoch kein „EventHandling” zur Verfügung. Deshalb musste die Java-3D-Bibliothek bemüht werden,
die auch von Sun geliefert wird und das kontinuierliche „pollen” von beliebigen
Eingabegeräten übernimmt. Somit wurde auf der Basis von Java 3D ein „EventHandling” nachprogrammiert. Für das Ansprechen der A3D-Soundkarte wurde
eine Javaklasse namens „a3dtools” von der Abteilung CG/HCI bereitgestellt. Bei
dieser Klasse handelt es sich um einen „Wrapper” der die mit der Karte mitgelieferte A3D-Schnittstelle umhüllt. Da die A3D-API nur rudimäntere Funktionen bereitstellt, wurde entschieden einen sogenannten Soundmanager zu schreiben, der
auf der A3D-API aufsetzt und für den Prototyp spezifische Soundfunktionen bereitstellt wie „wechsele den Raum” oder „lese den Link vor”. Zunächst wurde eine
Person mit dieser Aufgabe betraut, was aber, wie sich herausstellte, unterbesetzt
war und dazu führte, dass zum Zeitpunkt der Präsentation der Prototyp instabil
war. Daraufhin wurden zwei weitere Programmierer dazuberufen, um eine stabile
Version des Moduls zu erstellen, da der Soundmanager der Unterbau auch für das
spätere, richtige Produkt sein sollte. Dies führte zur kompletten Umstrukturierung
des Soundmanagers. Die vielen Threads, die in der alten Version gestartet wurden,
wurden durch ein Erzeuger-Verbraucher Konzept ersetzt. Der Erzeuger war das
restliche Programm, und der Verbraucher war das Soundmodul. Das Programm
erzeugte sogenannte „Actions” die in eine Schlange gestellt wurden, und der Soundmanager verarbeitete diese in einem eigenen Thread. Jedoch gab es auch hier
Probleme, die aber durch eine neue Version des Soundtreibers behoben wurden.
16
Kapitel 4
Erste Evaluationen
4.1 Ausblick auf dieses Kapitel
Mit dem Ziel, die im Prototyp realisierte Benutzungsoberfläche zu testen, war eine
Evaluation des Prototypen mit externen Versuchspersonen geplant.
Im Vorfeld mussten allerdings noch geeignete Geräusche für die Hearcons gefunden werden. Dazu wurden zwei Projektgruppen-interne Evaluationen durchgeführt:
Zunächst wurden die bisher vorhandenen Geräusche mit dem Ziel getestet, die
brauchbarsten Töne für den Prototypen zu ermitteln (Abschnitt 4.2.1). Danach wurde der Prototyp mit den besten Geräuschen zuerst intern in der Projektgruppe evaluiert (Abschnitt 4.2.2).
Nach diesen Vorbereitungen konnte die Evaluation mit externen Versuchspersonen
stattfinden, die im Abschnitt 4.3 beschrieben ist.
4.2 Evaluation der Töne
4.2.1 Lokalisierbarkeit und Angehnehmheit der Töne
«««< EvaluationDerSounds.tex Die Evaluation der Sounds für den Prototypen des
AirBrowsers sollte grundsätzliche Fragen zur Auswahl von Sounds geklärt werden. Im günstigsten Fall sollten Schemata gefunden werden, mit denen es möglich
ist, jederzeit neue Sounds zu finden, ohne diese nochmals evaluieren zu müssen.
======= Die Evaluation der Sounds für den Prototypen des AirBrowsers sollte
grundsätzliche Fragen zur Auswahl von Sounds geklärt werden. Im günstigsten
Fall sollten Schemata gefunden werden, mit denen es möglich ist, jederzeit neue
Sounds zu finden ohne diese nochmals evaluieren zu müssen.
Es wurden 27 Sounds getestet. Jeder Sound wurde an drei zufällig gewählten Positionen im Raum angeordnet. Die erste Position lag immer auf den drei Grundachsen. Stellt man sich den Kopf des Probanten als Ursprung vor, lagen die Sounds
genau vorne, hinten, rechts oder links. Die zweite Soundposition lag immer auf
einer Diagonalen zu den Grundachsen, also praktisch gesehen in den Ecken. Die
letzte Position lag frei im Raum, also irgendwo zwischen den anderen zuvor getesteten Stellen. Mit dieser Anordnung sollte ermittelt werden, ob es Präferenzen für
die Position dieses Sounds gibt. Diese Information könnte in der späteren Wiederverwendung der Sounds wichtig sein. Der Versuchsleiter spielt dem Probanten den
Sound vor, dieser hat ihn zu erkennen und zu lokalisieren. Ausserdem soll er dem
Sound eine Note für seine Ertragbarkeit geben.
Das Ergebnis wurde protokolliert und ist im Anhang C dokumentiert.
Die Evaluation ergab, daß es nahezu unmöglich zu sein scheint, ein Geräusch zuverlässig im Raum zu orten. Die Gründe hierfür liegen sicherlich zum einen an
der technischen Machbarkeit der Sounddarstellung. Ein künstlich erzeugter Raumklang ist immer noch weit von der Realität räumlichen Hörens entfernt. Zum anderen müssten die Geräusche verbessert werden. Alle Geräusche wurden nicht unter
Studiobedingungen aufgenommen, bei vielen war noch ein zu starkes Hintergrundrauschen und ähnliche Störungen enthalten.
Die Auswahl der Geräusche für den Prototyp, bzw. des fertigen Programms wurde
dann intuitiv vorgenommen. Das Hauptkriterium war hierbei der subjektive Eindruck beim Hören des Geräusches. Es musste ausreichen, ein als angenehm empfundenes Geräusch zu verwenden, die Lokalisationsfähigkeit war nicht konkret genug zu testen. »»»> 1.6
«««< EvaluationDerSounds.tex
4.2.1.1
Versuchsablauf
Es werden 27 Sounds getestet. Jeder Sound wird an drei Positionen im Raum angeordnet. Die erste Position liegt immer auf den drei Grundachsen. Stellt man sich
den Kopf des Probanten als Ursprung vor, liegen die Sounds genau vorne, hinten,
rechts oder links. Die zweite Soundposition liegt immer auf einer Diagonalen zu
den Grundachsen, also praktisch gesehen in den Ecken. Die letzte Position liegt
frei im Raum, also irgendwo zwischen den anderen zuvor getesteten Stellen. Mit
dieser Anordnung soll ermittelt werden, ob es Präferenzen für die Position dieses
Sounds gibt. Diese Information könnte in der späteren Wiederverwendung der Sounds wichtig sein. Der Versuchsleiter spielt dem Probanten den Sound vor, dieser
hat ihn zu erkennen und zu lokalisieren. Ausserdem soll er dem Sound eine Note
für seine Ertragbarkeit geben. Das Ergebnis wird protokolliert.
4.2.1.2
Auswertung
Um die Ergebnisse des Versuchs besser quantifizieren zu können, werden die Antworten der Probanten drei Kategorien eingeteilt. Die erste Kategorie stellt genaue
Treffen dar, in die zweite Kategoerie fallen alle Antworten, die die Position nicht
ganz genau beschreiben, eine der Richtungen kann abweichen. Wenn der Probant
die Position des Sounds gar nicht erkannt hat, wird seine Aussage unter Kategorie
drei vermerkt. Sollte der Sound genau lokalisiert worden sein, erhält er in dieser
Kategorie eine Beurteilung den Index 0, wurde eine Koordinate falsch eingeschätzt
(z.B. vorne hinten verwechselt), erhält er eine 1. Wenn der Sound gar nicht oder
völlig falsch lokalisiert wurde, wird eine 3 im Protokoll vermerkt.
4.2.1.3
Versuchsprotokoll
Die Abbildung C.1 zeigt tabellarisch die Ergebnisse des Versuchs. Zur besseren
Übersicht wurden die Ergebnisse einer Kategorie farblich unterlegt. Die Tabelle
umfasst vier deutlich voneinander getrennte Spalten. In der ersten Spalte sind alle Ergebnisse verzeichnet, bei der eine Position getestet wurde, die sich auf den drei
Grundachsen befindet, Hauptspalte zwei zeigt die Ergebnisse des Tests einer Postion auf den Diagonalen und Spalte drei und vier zeigt die Aussagen der Probanten
zu einer Position im freien Raum (siehe Versuchsablauf). Innerhalb der Spaten sind
18
bellen
bowling
drucker
glocken
harfe
kraehe
morsen
telefon2
trommel
vogel
dblatack
kurzc5
fakedoo
100sloo3
x3hammd2
1cl_long
clearbel
120sloop6
rocks15
doochor2
120slo11
fills02
gitrh12
gitrh01
bassd07
bassf07
distf01
bassa02
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
1
1
1
0
1
0
0
0
1
0
0
0
0
0
0
0
1
0
0
0
0
1
0
1
0
1
0
1
1
1
1
0
1
1
1
1
1
1
0
0
0
1
1
1
1
0
1
0
1
2
0
1
1
1
1
1
2
1
1
0
2
1
1
1
1
1
0
0
1
1
1
1
1
0
1
1
1
2
1
1
1
1
1
1
2
1
1
1
2
1
2
1
1
2
0
1
1
1
1
1
2
1
1
1
2
2
1
1
1
1
1
2
2
2
2
1
2
2
2
2
2
2
2
1
2
1
2
1
2
1
2
2
2
2
2
1
2
1
2
1
0
1
1
0
2
0
1
1
1
1
0
0
0
1
0
1
0
1
1
1
1
0
1
1
0
0
0
1
1
2
1
1
2
1
1
1
1
1
0
0
1
1
0
2
1
1
1
1
1
1
1
1
1
1
1
1
1
2
1
1
2
1
1
1
1
1
1
1
1
1
1
2
1
2
1
1
2
1
1
1
1
1
1
2
1
2
2
1
2
1
1
1
1
1
1
1
1
1
1
2
1
2
1
1
2
1
2
1
1
1
1
2
1
2
2
1
2
1
2
2
1
1
1
1
1
2
2
2
2
2
1
2
2
2
2
1
1
1
2
2
1
2
2
2
2
1
2
2
1
2
1
2
1
2
2
2
2
2
1
2
2
2
2
2
1
1
2
1
0
0
0
0
1
1
0
0
1
0
0
0
1
1
1
0
0
0
1
1
0
1
0
0
0
0
0
1
1
1
0
0
1
1
1
1
1
0
0
1
1
1
1
0
0
0
1
2
0
1
1
0
0
0
0
1
1
1
0
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
2
1
1
1
0
0
1
1
2
1
1
1
1
2
1
2
2
1
1
1
1
1
1
2
1
1
1
1
2
1
1
1
1
1
1
1
2
1
2
1
1
2
1
2
2
2
1
1
2
1
2
2
1
2
2
1
2
1
2
1
2
1
1
1
2
2
2
1
2
2
2
2
2
2
1
1
2
1
2
2
2
2
2
1
2
2
2
2
2
1
1
1
2
0
0
1
1
0
1
0
1
0
0
0
0
0
1
0
1
1
0
1
0
0
0
0
0
1
0
0
2
1
1
2
1
1
1
0
1
0
0
1
2
0
1
0
1
1
1
1
0
0
0
0
1
1
1
1
2
1
1
2
1
1
2
1
1
1
0
1
2
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
2
1
2
2
1
1
2
1
1
1
1
1
2
1
1
1
1
1
1
1
1
1
1
1
1
2
2
1
2
1
2
2
1
2
2
1
1
2
1
1
2
1
1
1
2
2
1
1
1
1
1
1
1
2
2
1
2
1
2
2
2
2
2
1
1
2
1
1
2
2
2
2
2
2
2
1
2
2
2
1
1
2
2
2
Erläuterung:
0 - genau lokalisiert
1 - 1 Koordinate falsch
2 - 2 Koordinaten falsch
Wie aus der
Flächenverteilung
ersichtlich, scheint es
nahezu unmöglich ein
Geräusch genau zu
lokalisieren.
Schlußfolgerung:
Orientierung anhand der
Geräusche im Raum nicht
möglich, daher müssen die
Geräusche nach anderen
Kategorien ausgewählt
werden.
Abbildung 4.1: Ergebnisse der Evaluation der Töne
für jedes Geräusch die Aussagen der sechs Probanten nach Kategorien (siehe Auswertung) aufgezeichnet. Die gelben Flächen stehen für exakte Treffer, die hellgrünen für fast getroffen und die dunkelgrünen für nicht lokalisiert.
4.2.1.4
Schlussfolgerungen
Wie aus der Treffer-Verteilung ersichtlich wurde, scheint es nahezu unmöglich zu
sein ein Geräusch zuverlässig im Raum zu orten. Die Gründe hierfür liegen sicherlich zum einen an der technischen Machbarkeit der Sounddarstellung. Ein künstlich erzeugter Raumklang ist immer noch weit von der Realität räumlichen Hörens
entfernt. Zum anderen sind die Geräusche verbesserungsbedürftig. Alle Geräusche
wurden nicht unter Studiobedingungen aufgenommen, bei vielen sind noch ein zu
starkes Hintergrundrauschen und ähnliche Störungen enthalten.
Die Auswahl der Geräusche für den Prototyp, bzw. des fertigen Programms wurden von den Mitgliedern der Projektgruppe vorgenommen. Das Hauptkriterium
war hierbei der subjektive Eindruck beim hören des Geräusches. Es reicht aus, ein
als angenehm empfundenes Geräusch zu verwenden, die Lokalisationsfähigkeit ist
scheinbar nicht konkret genug zu testen.======= »»»> 1.6
4.2.2 Evaluation der Töne innerhalb des Prototypen
Im Anschluss an den Test der Einzeltöne wurde ein erster Test des Prototypen
durchgeführt, wie schon angesprochen, zunächst nur mit Mitgliedern der Projekt19
4.3 Evaluation des Prototypen
gruppe selbst.
Die Evaluation erfolgte zweischrittig: Zunächst benutzten die Probanden den Prototyp und lösten dabei Aufgaben bzw. folgten den Handlungsanweisungen. Das
Verhalten der Probanden wurde von den Versuchsleitern protokolliert. Im zweiten
Schritt füllten die Probanden einen Fragebogen aus. Sie hatten dabei die Möglichkeit, den Prototyp weiter zu benutzen, allerdings ohne gestellte Aufgaben.
Die Handlungsanweisungen, so wie sie für die Evaluation benutzt wurden, sind im
Anhang D.1 dokumentiert. Es wurden Aufgaben gestellt, um zu sehen, ob die hinter den Hearcons liegenden Funktionen erreicht werden können. Ausserdem wurde überprüft, ob die Idee des Raumwechels erkannt wird. Die Versuche wurden
jeweils mit unterschiedlichen Eingabegeräten und jeweils mit und ohne visueller
Unterstützung durchgeführt.
Leider standen für den Versuch nur wenige Testpersonen zur Verfügung. Die Ergebnisse im Detail können im Anhang D.2 nachgelesen werden. Zusammenfassend
kann man sagen, daß noch einige Schwierigkeiten beim Umgang mit dem Prototypen bestanden. So wurden die Hearcons nicht immer exakt erreicht und ihre Funktion wurde nicht gleich erkannt. Ingesammt bietet wohl auch die präsentierte Akustik zuwenig Anhaltspunkte, um nicht die Orientierung zu verlieren. Hinzu kamen
technische Schwierigkeiten des Joysticks, die teilweise zu nicht nachvollziehbaren
Reaktionen des Systems führten.
Aus den Ergebnissen ergab sich die weitere Arbeit der Projektgruppe. Zum einen
war die Notwendigkeit einer Evaluation durch Nichtprojektgruppenmitglieder klar,
da sicherlich nicht alle Mängel durch die Projektgruppenmitglieder erkannt wurden. Zum anderen mussten aber vor der Evaluation des Prototypen durch Nichtprojektgruppenmitglieder Änderungen der ärgsten Unzulänglichkeiten im Prototyp vorgenommen werden.
Am 07.12.2001 fand eine Evaluation des Airweb-Prototypen statt, in der Nichtprojektgruppenmitglieder Versuchspersonen waren.
Mit der Evaluation sollte die Gebrauchstauglichkeit des Bedienkonzeptes in der
Form untersucht werden, in der es zur Zeit der Evaluation durch die Projektgruppe entwickelt worden war. Gegenstand der Untersuchung war der Hearconkranz
mit seinen Slots – das bereits im Prototypen realisierte Bedienelement des zu entwickelnden Browsers.
Untersucht wurde, wieviele der vorhandenen Geräusche wahrgenommen werden
können, wo sie im Raum positioniert sind, welche Geräusche besser oder schlechter lokalisiert werden konnten und wieviel Zeit das in Anspruch nehmen würde.
Daneben sollte auch die Eignung der Eingabegeräte Maus und Joystick untersucht
werden.
4.3.1 Verbesserungen am Prototypen
Für die Evaluation wurden etliche Verbesserungen am Prototypen durchgeführt,
die auf Erkenntnissen der vorangegangenen internen Evaluation beruhen.
An der Software wurden hauptsächlich Details geändert: Das Hintergrundgeräusch
in jedem Raum wurde entfernt, Hearcons erhielten eine Art „Rollover-Effekt“ in
20
Form einer Tonhöhenänderung. Ebenfalls für die Situation, dass das Eingabegerät
auf ein Hearcon zeigt, ist die vorgesehene allseitige Hörbarkeit des Geräusches realisiert worden. Bei der Zusammenstellung der Räume mit ihren Geräuschen half die
vorangegangene Sound-Evaluation.
Für die Evaluation standen qualitativ hochwertige 2-Achsen-Joysticks zur Verfügung (Logitech Wingman Attack), die mit dem Problem des überaus stark zitternden, bisher verwendeten Joysticks aufräumten. Durch einen neuen SoundkartenTreiber konnte die Evaluation (und die weitere Entwicklungsarbeit) unter MS Windows 2000 durchgeführt werden.
4.3.2 Planung und Durchführung der Evaluation
Die Evaluation war für einen Tag vorgesehen. Die Durchläufe mit den einzelnen
Versuchspersonen fanden nacheinander statt, wofür jeweils eine Stunde Zeit eingeplant worden war.
Jedes Mitglied der Projektgruppe musste ein oder zwei Versuchspersonen mitbringen – insgesamt standen uns 8 Personen zur Verfügung. Jeder Durchlauf wurde von
einem Mitglied der Projektgruppe geleitet.
Die Versuchspersonen waren allesamt sehend. Die Versuche wurden daher blind
durchgeführt, also ohne dass die Versuchspersonen die visuelle Darstellung am
Monitor sehen konnten. In der Evaluation wurden Kopfhörer für die Tonausgabe
verwendet, wie es in den Konzepten der Projektgruppe vorgesehen war.
Die Versuchspersonen mussten einen „Testparcours“ aus sieben Räumen absolvieren. In jedem Raum waren Aufgaben zu lösen, dazu gehörten das Erkennen und
Lokalisieren der unterschiedlichen Geräusche sowie das „Anfahren“ der zugehörigen Hearcons mit dem Eingabegerät. Der Versuchsablauf mit samt den Aufgaben
ist im Anhang E genauer beschrieben.
Während der Versuche wurden die Ergebnisse von den Versuchsleitern notiert. Gleichzeitig wurde eine Videoaufzeichnung angefertigt, die die anschließende Versuchsauswertung unterstützte. Aufgenommen wurde das Monitorbild mit eigens vergrößerter Mauszeigerdarstellung. Die Versuchsperson wurde zu „lautem Denken“ aufgefordert, das auf der Audiospur aufgezeichnet wurde. Die Ergebnisse sind ebenfalls im Anhang E zu finden. Im nächsten Abschnitt folgt daher schon die Evaluationsauswertung.
4.3.3 Auswertung und Konsequenzen für die Projektgruppe
4.3.3.1
Planung und Durchführung von Evaluationen
Aus der Durchführung der Evaluation gewannen wir zunächst einmal Erfahrungen, wie Evaluationen besser geplant und durchgeführt werden können: Die Versuchsleiter müssen besser vorbereitet werden. Die Ziele der Evaluation und die Art
der Auswertung müssen vorher genau festgelegt sein, beispielsweise dass bei der
Video-Auswertung die Zeiten gestoppt werden sollen.
Für die Durchführung zukünftiger Evaluationen kann es sinnvoll sein, mit insgesamt weniger Evaluatoren zu arbeiten, die dann allerdings mehr Versuche leiten
müssten. Jeder Durchlauf der Evaluation kann am besten von zwei Versuchsleitern
betreut werden, die sich die Arbeit teilen können.
21
4.3.3.2
Der Prototyp
Aus den Beobachtungen und Ergebnissen der Evaluation wurden die folgenden
Schlüsse gezogen, die in die weitere Arbeit der Projektgruppe und insbesondere
den zu entwickelnden Software, den AIRBrowser, einfließen sollten. In Klammern
gesetzte Zahlen beziehen sich auf die im Anhang E dokumentierten Beobachtungen.
Ein Lerneffekt stellt sich ein (1, 2). Desorientierung trat hauptsächlich im ersten
Raum auf.
Die blinde Navigation mit der Maus ist schwierig. Es besteht die Gefahr, dass
der Benutzer nicht weiß, wo sich der Mauszeiger tatsächlich befindet (3). Der
Joystick ist als Eingabegerät besser geeignet als die Maus. Der Grund – in diesem
Zusammenhang – liegt offensichtlich daran, dass der Joystick automatisch in die
Mittelstellung zurückkehrt, wenn man ihn loslässt.
Für die Maus könnte eine spezielle Markierung Abhilfe schaffen, z. B. ein Geräusch, das die Raummitte oder den Rand kennzeichnet.
Bei der Lokalisierung kann nur die Links/Rechts-Achse eindeutig erkannt werden. Vorn/Hinten wird nicht deutlich erkannt. (4, 5). Eine Ausnahme war dabei
interessanterweise das Bowling-Geräusch.
Die Rückmeldung, dass ein Hearcon getroffen („angefahren“) wurde, muss deutlich wahrnehmbar sein („Akustische Haptik“).
Im Konzept des Prototypen war vorgesehen, dass das Hearcongeräusch um den
Benutzer herum (allseitig) erklingen sollte, wenn das Eingabegerät auf das Hearcon zeigt. Gleiches galt für das Vorlesen. Beides war nicht ausreichend realisiert
(6, 7) – die Balance stimmte nicht ganz, trotz der Verbesserungen im Prototypen
vor der Evaluation.
Ein Zittern des Joysticks muss berücksichtigt werden, so dass das Vorlesen nicht
mehrfach aktiviert wird (8).
Charakteristika der verwendeten Geräusche haben starken Einfluss auf die Lokalisierbarkeit: Kontinuierlich klingende Geräusche können im allgemeinen besser geortet werden als Geräusche mit kurzen Pausen (9).
Themenbildung bei der Auswahl und Zusammenstellung von Geräuschen kann
die Orientierung und die Wiedererkennung verbessern (10).
Für die Beobachtung, dass manche Hearcons direkt angefahren wurden, obwohl
sie vorher nicht richtig lokalisiert wurden, findet sich keine Erklärung (11).
Bei der Diskussion der Evaluationsergebnisse traf die Projektgruppe einige Festlegungen für die zukünftige Arbeit:
Das Navigationskonzept sollte beibehalten, aber noch verfeinert werden.
Die Geräusche waren benutzbar, mindestens gut erkennbar. Auch hier sollte
noch weiter geforscht werden.
Sowohl Joystick und Maus sollten weiterhin als Eingabegerät verwendet werden. Getestet werden sollte zusätzlich ein Grafiktablett.
22
Speziell für die Joysticksteuerung kam die Idee auf, die Orientierung des Hörers im
Raum durch Drehung veränderbar zu machen – wird der Joystick nach Links oder
Rechts gedrückt, dreht sich der Benutzer viruell im Raum (bzw. die Geräuschkulisse
dreht sich entgegengesetzt). Die Drehung würde die bisherigen Seitwärtsbewegung
ersetzen. Diese Idee wurde untersucht, allerdings später wieder verworfen.
Weitere Ideen betrafen den Hearconkranz, der als Kreis (anstatt als Rechteck) angeordnet und dessen Ebene im Raum gekippt werden könnte.
Der Evaluation folgte eine Konzeptionsphase für das Endprodukt, in die die Ergebnisse der Evaluation einflossen.
23
Kapitel 5
Produkt
Bei der Entwicklung des eigentlichen Ergebnisses der Projektarbeit, dem Produkt
’AirBrowser’, standen zwei Ziele im Mittelpunkt. Erstens sollten die Erfahrungen
mit dem Prototypen berücksichtigt werden, und zweitens sollten bewußte Vereinfachungen und verminderte Anforderungen beim Prototypen beim Produkt nicht
mehr gelten.
Diese Ziele flossen in die Anforderungsdefinition und den Entwurf ein. Die auffälligsten Veränderungen gab es dabei im neuen Bedienkonzept und bei technischen
Erweiterungen, die im folgenden erläutert werden. Als besondere Herausforderung
hat sich dabei die Integration des externen Webbrowsers erwiesen.
5.1 Anforderungsdefinition und Entwurf
Anforderungsdefinition und Entwurf liegen in seperaten Dokumenten vor.
Die Anforderungsdefinition ist
Anforderungsdefinition AirBrowser — Datum: 16.1.2001 — Korrigierte Fassung:
23.1.2001
ãirweb/AirBrowser/Documents/AnfDef/Anfdef_2001-01-23.pdf
und der Entwurf
Entwurfsdokument AirBrowser — Projektgruppe AirWeb — 21.02.2001
ãirweb/AirBrowser/Documents/Entwurf/Entwurfdok.pdf
5.2 Überarbeitetes Konzept
Das Navigationskonzept des Prototypen wurde für das Produkt übernommen und
durch die Evaluationsergebnisse verfeinert. Die Navigation innerhalb der Benutzungsoberfläche erfolgt jetzt nur noch auf akustischem Weg. Visuelle Hilfsmittel
zur Navigation sollten nur noch für Debug-Zwecke genutzt werden. Dies wurde
damit begründet, daß verstärkt ein Schwerpunkt auf die akustische Benutzungsoberfläche gelegt werden sollte. Der sehende Anwender würde sich ansonsten weiter
dominant auf die gewohnte visuelle Interaktion verlassen.
Das Navigationskonzept wurde durch drei verschiedene Räume realisiert. Es gibt
den Leseraum, den Programmraum und den neu hinzugekommenen Markerraum,
5.3 Inhalt
der für die verbesserte Navigation innnerhalb des Inhalttextes verantwortlich ist.
Mit dem Markerkonzept lassen sich verschiedene Seiten (z.B. gleicher Inhaltsart
oder auch themenorientiert) in eine Markerliste eintragen, der dann ein Geräusch
eindeutig zugewiesen wird. Die Verwaltung markierter Seiten erfolgt im Markerraum, wobei in einem Markerraum alle Seiten zusammengefaßt werden, die mit
dem gleichen Geräusch markiert sind. Der Markerraum ist der einzige Raumtyp,
der das Anlegen mehrerer Räume erlaubt.
Die mögliche Interaktion wurde durch Eingabegeräte und durch Programmoptionen erweitert. Neu bei der Eingabe ist die Tastatureingabe, eine Spracheingabe und
eine neue Form der Joysticksteuerung. Durch ein Optionsfenster wird dem Benutzer die Möglichkeit geboten, die akustische Repräsentation zu modifizieren, sowie
die Startseite und den Startraum festzulegen.
5.3 Inhalt
Der Inhaltstext liegt im (X)HTML-Format vor, der mit einigen Zusatztags für die
Zusatzinformationen angereichert wurde. Die im Text vorkommenden Links werden zur besseren Orientierung akustisch differenziert und gesammelt an expliziten
Orten im virtuellen akustischen Raum zur Abfrage angeboten.
Zu den unterschiedenen Typen von Links zählen Referenzen, Beispiele und StrukturLinks. Weiterhin wird unterschieden nach der Länge der referenzierten Seite und
zwischen externen und internen Links.
5.4 Anbindung des Internet Explorers
Die größte technische Neuerung gegenüber dem Protoypen ist die Einbindung des
Microsoft Internet Explorers (TM). Es wurden mehrere technische Lösungen verfolgt, diese sind im Anhang F.1 aufgeführt.
Die eigene native Anbindung des Internet Explorer an Java, die wohl die sauberste und stabilste Lösung gewesen wäre, wurde zum Teil implementiert, dann aber
aus Zeitgründen nicht mehr weiter verfolgt. Stattdessen wurde entschieden, den
frei verfügbaren Wrapper-Generator Bridge2Java, später dann den funktional identischen Wrapper-Generator JacoZoom als Schnittstelle zwischen Java und dem Internet Explorer einzusetzen. Trotz einiger anfänglicher Stabilitätsprobleme konnten
doch alle Probleme beseitigt werden.
5.5 Zusammenfassung
Gemäß Anforderungsdefinition und Entwurf wurde das Produkt im Grundsatz von
grundauf neu entwickelt. Lediglich bei der bereits recht ausgereiften SoundeffektVerwaltung wurden Anleihen beim Prototypen gemacht. Als neue Anforderungen
kamen neben des Anspruchs einer höheren Softwarequalität (Leistung, Stabilität
etc.) verschiedene technische Erweiterungen und Modifikationen des Bedienkonzeptes hinzu. Als besondere Leistung der Gruppe ist die Einbindung des MicrosoftBrowsers herauszustellen, die eine regelmäßige Weiterentwicklung entwurfsrelevanter Entscheidungen erforderte.
25
5.6 Implementation
5.6 Implementation
An den Entwurf schloß sich die Implementierung an. Dabei gab es verschiedene
technische Probleme zu lösen. Im Anhang F.2 ist im Detail dokumentiert, welche
Schritte zur Installation der erstellten Software und der benötigten Laufzeitumgebung auf neuen Rechnern notwendig sind. Weiterhin wird dort Funktionsweise der
eingesetzten, teils selbst entwickelten, teils als Biblioheken eingebundenen technischen Komponenten erläutert.
Wie dort ersichtlich ist, ist die Projektgruppe in mehreren Bereichen an die Grenzen der Programmiersprache Java gestoßen. Eigene Komponenten wurden für die
Eingabegeräte Joystick, Maus und Tastatur implementiert. Für die Verbindung der
Soundkarten-DLL mit dem Java-Programm stand ein Wrapper aus der Abteilung
zur Verfügung. Sprachfunktionen, Parser und die Steuerung des Webbrowsers stützen sich zum Teil auf Produkte von Drittherstellern.
Die Herstellung einer geeigneten Laufzeitumgebung, d.h. Konfiguration aller Komponenten, so daß diese gefunden werden und reibungslos funktionieren, war recht
aufwendig. Zum Einrichten der Software auf weiteren Rechnern sollten unbedingt
die obigen Ausführungen herangezogen werden.
26
Kapitel 6
Abschluss
Den Abschluss der Projektgruppe bildete eine Evaluation des Endprodukts. Dazu
wurden, wie schon bei der Evaluation des Prototypen (s. Kapitel 4.3 auf Seite 20),
Personen, die nicht an der Projektgruppe beteiligt waren, hinzugezogen, die als Tester des Programms fungierten.
Der folgende Abschnitt 6.1 beschreibt den Entwurf der Evaluation, die Planung der
Durchführung und die Fragestellungen, die die Evaluation beantworten sollte. Im
Abschnitt 6.2 findet sich dann die Zusammenfassung der Ergebnisse der Evaluation.
6.1 Evaluation
6.1.1 Allgemeines
Die Evaluation wurde von drei Personen durchgeführt, einem Evaluationsleiter, einem Protokollanten und einem Tester. Die ersten beiden Personen waren Teilnehmer der Projektgruppe und der Tester war eine beliebige Person, die mit dem Projekt nicht verbunden war.
Die Evaluierung dauerte ca. 45 Min., 15 Min. kamen als Pufferungszeit hinzu, so
dass sich eine Stunde als Gesamtzeit ergab.
Die Durchführung der Evaluierung sah folgendermaßen aus: Der Evaluationsleiter gab dem Tester Anweisungen bzw. Aufgaben, die dieser durchzuführen hatte.
Die Aufgaben konnten einfache Fragen bis hin zu komplexen Aufgabenstellungen
sein. Jedoch wurden nicht die konkreten Aufgaben festgelegt, sondern es wurden
nur sogenannte Kernfragen formuliert, die vom Evaluationsleiter zu beantworten
waren. Bei allen Aufgaben war die Position des Eingabegerätes auf dem Monitor
nicht sichtbar. Die Musteraufgaben (s. unten) durften für die Evaluation übernommen werden, es war jedoch ausdrücklich erlaubt, davon abzuweichen, wenn es
die Situation erforderte. Damit es trotz dieser Freiheit des Evaluationsleiters zu einem repräsentativen Ergebnis kam, sollte der Protokollant die konkreten Aufgaben
während einer Evaluation mitprotokollieren. Dabei war die Wortwahl des Evaluationsleiters u.U. von großer Bedeutung, so dass darauf zu achten war, dass diese
Stichwörter orginalgetreu protokolliert wurden. So ist es z.B. nicht unwesentlich,
ob „Marker”, „Bookmark” oder „Lesezeichen” gesagt wurde. Zusätzlich wurde das
Verhalten bzw. das Vorgehen des Testers auf Video aufgezeichnet.
Die Evalution wurde in drei Themenkomplexe unterteilt, von denen jeder ein Benutzungskriterium, das aus dem Bereich der Software-Ergonomie stammte, auf die
6.1 Evaluation
Erfüllung hin prüfen sollte.
Die folgenden Abschnitte unter den Überschriften „Steuerbarkeit”, „Erlernbarkeit”
und „Aufgabenangemessenheit” beschreiben diese Teile der Evalutaion.
6.1.2 Steuerbarkeit
Im ersten Teil der Evaluation sollte festgestellt werden, ob das Programm im weitesten Sinne bedienbar war. Dies war die Frage, ob der Benutzer in der Lage wäre, das
Steuerungskonzept zu erkennen und zu verstehen und ob er die akustische Ausgabe des Programms ausreichend genug erfassen konnte.
Die Kernfragen waren dabei:
1. ob die technische Umsetzung gelungen ist, und
2. ob die Raummetapher wahrgenommen wird.
Die Durchführung lief dann folgendermaßen ab: Der Tester durfte sich — wie oben
schon erwähnt: ohne optisches Feedback — mit dem Eingabegerät im akustischen
Raum frei bewegen. Es war ihm jedoch nicht gestattet Funktionen auszulösen, die
über die reine Bewegung im Raum hinausgingen. Für die Durchführung standen
folgende Musteraufgaben zur Verfügung:
1. Um die technischen Umsetzung zu beurteilen waren diese Fragen vorgesehen:
Wie viele Geräusche werden unterschieden?
Welche Geräusche werden erkannt?
Wie ist die Lautstärke der Geräusche zueinander?
2. Um die Raummetapher zu erkennen waren hingegen folgende Fragen vorgesehen:
Wird Bewegung der Geräusche erkannt?
Ändern sich die Geräuschpositionen zueinander?
Wie sind die Hearcons zueinander angeordnet? (Kreis, Rechteck, Gerade,etc.)
Kann man sich im Zentrum eines Geräusches befinden/Können Geräusche
betreten werden?
6.1.3 Erlernbarkeit
Der zweite Teil der Evaluation sollte herausfinden, ob ein einigermaßen erfahrener
Internetbenutzer — ausgestattet mit dem Wissen vom Steuerungskonzept des Programms — selbständig die aufgabenorientierte Bedienung erlernen kann, indem er
die Selbstbeschreibungsfähigkeit ausnutzt.
Als wesentliche Kernfragen wurden daher folgende gewählt:
1. Ist das Programm ausreichend selbstbeschreibungsfähig?
2. Beschreibt die Raummetapher das Steuerungskonzept ausreichend?
3. Ist die Raummetapher konsistent zum Steuerungskonzept?
28
6.1 Evaluation
Der Versuch wurde dann so durchgeführt, dass der Benutzer zunächst hinsichtlich
seiner Interneterfahrung eingestuft werden musste. Es wurde nur in den folgenden
drei Stufen unterschieden: „keine Erfahrung”, „Erfahrung”, „viel Erfahrung” Bevor
der Tester mit den Aufgaben begann, musste er über folgende Punkte unterrichtet
werden: Über
die unterschiedlichen Arten von Räumen,
die maximal acht Hearcons, in in jedem Raum im Kreis angeordnet sind,
die Hearcons, die Funktionen beinhalten, und
die Eingabemöglichkeiten des Eingabegerätes.
Mögliche Aufgaben, um die Kernfragen zu beantworten, waren:
Welche Raumarten gibt es?
Welche Funktionen besitzt jede Raumart?
6.1.4 Aufgabenangemessenheit
In letzen Teil sollte ermittelt werden, wie gut man mit dem Programm „browsen”
konnte. Insbesondere war von Interessse, inwiefern die Denkweise des Benutzers
mit der Bedienung des Programms korrelierten. Wenn man mit dem Programm eine
Aufgabe lösen mochte, dann musste diese vom Benutzer in mehrere Teilaufgaben
zerlegt werden. Interessant war dabei, inwieweit diese Teilaufgaben im Kopf des
Benutzers mit den Funktionsschritten des Programms übereinstimmten. Ein weiterer Aspekt war, ob das Programm Fehler seitens des Benutzers zuließ, er diese
bemerken und korrigieren konnte.
Die entschiedenen Fragen waren also,
1. wie gut kann man mit dem Programm „browsen” kann,
2. inwieweit die Denkweise des Benutzers und die Programmbedienung korrelieren, und
3. ob das Programm ausreichend fehlertolerant ist.
Der Tester musste zuerst über alle nötigen Programmfunktionen aufgeklärt werden.
Dazu musste er die Steuerung des Programms beherrschen, die Erklärung musste
eventuell nachgeholt werden, wenn er sich nicht genügend Verständnis aus den
vorhergehenden Teilen verschaffen konnte.
Danach wurden dem Benutzer Aufgaben gestellt. Vor der Durchführung der Aufgaben sollte er sein geplantes Vorgehen beschreiben. Der Evaluationsleiter korrigierte
ihn nicht, wenn jener sich ein falsches Vorgehen überlegt hatte. Anschließend sollte
der Tester sein Vorhaben in die Tat umsetzen. Bei falscher Vorgehensweise ließ der
Evaluationsleiter dem Tester eine gewisse Zeit seine Fehler zu bemerken und zu
korrigieren. Falls der Tester dies nicht ohne Hilfe schaffte, musste der Evaluationsleiter ihm das Vorgehen erläutern und ihn die Aufgabe aus der Startposition erneut
durchführen lassen.
Folgende Aufgaben sollten Helfen, die Kernfragen zu beantworten:
29
6.2 Ergebnisse der Evaluation
Finden einer Information auf der aktuellen Seite.
Finden einer Information auf einer weiterführenden Seite.
Finden einer Information auf einer gemerkten Seite.
Dieser Abschnitt beschreibt die Ergebnisse der Evaluation. Er ist entsprechend der
Durchführung der Evaluation wieder in die Teile „Steuerbarkeit”, „Erlernbarkeit”
und „Aufgabenangemessenheit” unterteilt. In diesen Teilen sind jeweils die Antworten aus den im vorherigen Kapitel formulierten Kernfragen aufgeführt..
6.2.1 Steuerbarkeit
Die erste Frage war die nach der Qualität der technischen Umsetzung.
Grundsätzlich wurden alle Geräusche richtig erkannt und auch deren Anzahl. Der
Joystick war jedoch mit seinen Eigenschaften beiden Eigenschaften, dass man die
Joystickposition fühlt und die automatische Wiederkehr in die Ausgangsposition,
eine große Hilfe bei dieser Aufgabe. Die rein akustische Umsetzung ist noch verbesserungswürdig. So beklagten sich viele Tester darüber, dass einige Geräusche
zu leise (so z.B. das Bellen und das Bowling-Geräusch) und andere wiederum zu
laut bzw. zu dominant (z.B. das Telefonklingeln) waren. Auch die Ortbarkeit der
Geräusche wäre ohne den Joystick wesentlich schwieriger gewesen. Als weiteres
wurde auch der Zusammenklang schlecht bewertet, da mehr als drei Geräusche
gleichzeitig als anstrengend empfunden wurden.
Die zweite Kernfrage sollte überprüfen, ob die Raummetapher wahrgenommen
wurde.
Dass die Geräusche eine feste Position hatten und im Kreis um den Tester angeordnet waren, wurde meistens erkannt. Aber auch hier half der Joystick ungemein. Interessanter war dagegen, dass die Bewegungen des Joysticks nicht immer als Eigenbewegung im akustischen Raum gedeutet wurde sondern auch als eine Art Mischpult, mit dem man die Geräusche neu „abmischen” bzw. „heranholen” konnte. Das
Betreten der Geräusche, also das Gefühl im Zentrum eines Geräusches zu stehen,
wurde abhängig vom Geräusch besser oder schlechter erkannt. Daraus wurde aber
dann geschlossen, dass man sich bei allen Geräuschen im Zentrum befinden kann,
auch wenn bei einigen rein akustisch dieser Eindruck nicht unmittelbar entstand.
Abschließend könnte man sagen, dass die Raummetapher eher nicht selbständig
erkannt wurde, was sicherlich auch mit daran lag, dass die Tester die Tests sehend
durchführten, so dass die visuellen Reize die Konzentration auf die Akustik beeinträchtigte.
6.2.2 Erlernbarkeit
Alle Tester hatten bereits Erfahrung mit herkömmlichen Browsern und konnten sich
im Internet bewegen. Etwa die Hälfte der getesteten Personen gab an, „viel Erfahrung” im Umgang mit dem Internet und den dazugehörigen Programmen zu besitzen.
Die erste Frage war: Ist das Programm ausreichend selbstbeschreibungsfähig?
30
Aus den Reaktionen der Tester war zu entnehmen, dass es nicht möglich war, mit
dem Programm zu arbeiten, ohne zuvor eine genaue Beschreibung zu erhalten. Die
Anordnung der Geräusche wurde meist nicht als Raum wahrgenommen, die Tester
wussten nicht, wo sie sich befanden. Erschwerend kam hinzu, dass die Geräusche
nicht zu den Funktionen passten, so war es zum Beispiel unverständlich, dass sich
hinter einem Telefonklingeln das Zurückblättern befand.
Die zweite Frage lautete: Beschreibt die Raummetapher das Steuerungskonzept
ausreichend?
Wohl auch aufgrund der kurzen Einarbeitungszeit wurde von den meisten Testern
nicht erkannt, dass sich in den unterschiedlichen Räumen kontextverwandte Funktionen befanden. Mit fortschreitender Arbeit mit dem Programm wurde allerdings
den meisten klar, wie die Steuerung abläuft.
Die dritte Frage sollte die Konsistenz der Raummetapher mit dem Steuerungskonzept klären.
Alle Tester haben verstanden, dass in unterschiedlichen Räumen auf festen Positionen Geräusche mit Funktionen angeordnet sind. Die Navigation per Joystick wurde als eingängig und einfach empfunden. Nachdem klar war, wie die Räume aufgebaut sind, gelang allen die Bewegung ohne Probleme. Die Belegung der beiden
Joystickknöpfe war allerdings nicht immer einsichtig. So verwunderte es die meisten Tester, dass man mit dem Button, der die Erklärungen ausgibt, auch die Links
durchlaufen kann.
6.2.3 Aufgabenangemessenheit
Die erste Frage in diesem Teil war, ob sich das Programm als Browser bewährt.
Die Evaluatiuon ergab, dass sich das Programm nur bedingt zum täglichen Gebrauch eignet. Es waren zwar die meisten Funktionen vorhanden, die auch in herkömmlichen Browsern enthalten und zum surfen notwendig sind. Der Funktionsumfang — gerade was die unzulänglich implementierte Bookmark/Marker-Funktionen betrifft — wäre jedoch unbedingt zu erweitern. Das Programm war insgesamt zu langsam. Der Benutzer musste sekundenlang warten, bis sich eine neue
Seite aufgebaut hat. Zusammen mit der Instabilität gegenüber Fehleingaben machte es ein flüssiges Vorankommen im Lesen der Inhalte schwierig.
Als nächstes sollte die Frage beantwortet werden, inwieweit die Denkweise des
Benutzers und die Programmbedienung korrelieren.
Alle Tester, die das Raumkonzept verstanden hatten, konnten einen beliebigen Inhalt der Site finden. Die Denkweise der getesteten Benutzer passte sich den Vorgaben des Programms an. Bis auf wenige Ausnahmen war es allen Testern möglich zu
einer gestellten Aufgabe den Weg durch die Funktionen in den Räumen zu beschreiben und diese umzusetzen. Denjenigen unter den Benutzern, die bereits Schwierigkeiten mit dem Raumkonzept an sich hatten, fiel es natürlicher Weise auch schwer,
ihre Aktionen zu planen. Meist wurden in diesem Fall systematisch alle Hearcons
in allen Räumen ausprobiert, bis eine Funktion gefunden wurde, die vermeintlich
zum Erfolg führte.
Zuletzt stellte sich noch die Frage nach der Fehlertoleranz des Programms.
Während des Tests kam es sehr oft zu Abstürzen. Hastige Bewegungen am Joystick, gerade während der Aufbereitungsphase einer neu geladenen Seite wurden
meist mit einem Einfrieren des Rechners quittiert, was wiederum einen Neustart
des Systems erforderte. Die langen Wartezeiten beim Aufbau der Seiten provozier31
ten diesen Fehler recht häufig.
32
Anhang A
Erste Raumkonzepte
Dieses Kapitel beschreibt die ersten Raumkonzepte, die in vier Teilgruppen erarbeitet wurden — s. dazu Kapitel 3.3.1 auf Seite 10.
A.1 Gruppe 1
Beschreibung
1. Fahrzeug fährt vorwärts und wirft dabei tönende Gegenstände ab (History)
2. Bewegung zwischen Räumen mittels virtuellem Aufzug (Bookmarks)
3. Baum-Metapher für Dokumentstruktur (Kapitel, Unterkapitel, Text..)
4. Zusammensetzen zu einem Interaktionsraum: Aus dem Text-Raum kommt
man nach oben in den Navigationsraum, hier sind Interaktionsobjekte an den
sechs Seiten eines Quaders (Aufzugskabine) angebracht:
links/rechts: Seite vor/zurück gemäß Dokumentinhalt
oben: Bookmark-Stapel
unten: Textraum
hinten: History; sich entfernende tönende Gegenstände
vorne: baumartige Dokumentstruktur
Kritik
Das sequentielle Suchen in großen Bookmarkdateien wird sehr schnell sehr
aufwändig
Die Listenstruktur ist prinzipiell schwer zu überblicken
Bookmarks sind nur sehr umständlich zu erreichen (Textraum / Aufzug /
Bookmark)
Auswahl eines best. Bookmarks, History-Seite
Bookmarks: Entropie bei zwei festen Geräuschen
zu langer Weg/Baumstruktur
akustisch überfrachtet
wie hört man History (überlagern, bzw. löschen sich die Töne sich nicht gegenseitig aus?)
Aufzug führt zu neuen Welten nicht zu neuer Seite
kein wirklich neues Navigationskonzept
A.2 Gruppe 2
Kombination verschiedener Metaphern: statisch, stark/wenig dynamisch
Dokumente sind meistens Graphen, nicht Bäume
Dokumentstruktur zu starr
Stichwortsuche fehlt
Stop/Suche/öffnen anderer Seiten fehlt
Baum = Informatiker-Metapher, umständlich für Laien
Unterscheidung Kontrollraum/Rest
kein Freiraum für spätere Erweiterungen
Innovative Aspekte
Berücksichtigung der Entfernung in der History
Steuerbarkeit
Hierarchie in der Tiefe dargestellt, Nacbarn links/rechts, nächste Stufe weiter
weg
überschaubar
Navigation ist struktur- / hierarchieorientiert Aufzug ist permanenter Ansatzpunkt
leicht zu begreifende Metaphern
A.2 Gruppe 2
Beschreibung
1. Funktionalität Browser
Mehrere Räume
Inhaltsraum
Kontrollraum
„Besuchte Seiten“-Raum
Favoriten-Raum
Vorwärtslisten-Raum
Suchergebnisse-Raum
Hilfe-Raum
2. Präsentation
Raum: 2D, um den Benutzer herum in der Horizontalen
Hearcons:
Sind im Raum positioniert, haben Geräusch und Sprachausgabe, ein deaktiviertes Hearcon ist stumm/dumpfer.
Geräusch: Klingt immer [außer im Inhaltsraum], wird etwas lauter, wenn
Zeiger über dem Hearcon positioniert wird.
Sprachausgabe: Wenn Zeiger auf dem Hearcon positioniert ist, und wenn
man einen Raum betritt, spricht das Hearcon seine Funktion.
3. Eingabe
Eingabemöglichkeiten (um Hearcons auszuwählen):
– Zeigegerät
34
A.2 Gruppe 2
Vor
Vorwärtsliste
Favoriten
Neue Favoriten
Suche in Site
Öffnen
Halt
Kontrollraum
Hilfe
Neu Laden
Besuchte
Seiten
Zurück
Vor
Suche in Seite
Inhaltsraum
Hilfe
Besuchte
Seiten
Zurück
Abbildung A.1: Skizze des Raumkonzepts Gruppe 2
– Spracheingabe
4. Offene Fragen
Vorwärtsliste nötig?
Welche Zustände können Hearcons haben (aktiv/nicht aktiv)?
5. Eine Skizze ist in Abb. A.1 zu sehen.
Kritik
Wechsel zwischen den Räumen nicht berücksichtigt
hinten und vorne akustisch schwer zu unterscheiden, besser links / rechts
keine visuelle Repräsentation
kein neues Navigationskonzept
nur 2D
35
A.3 Gruppe 3
2D-Zuordnung weil viele Ton-Funktionen
Dauerklang der Hearcons
akustisch überfrachteter Kontrollraum
zu viele Objekte gleichzeitig hörbar
Innovative Aspekte
Vorwärtslisten
akustische Tooltips
wichtigste Elemente aus Kontrollraum wiederholt
gleiche Orte: Funktionalitäten
Ausgrauen guter Hinweis
um den Benutzer stehen wichtige Dinge vorn, unwichtige hinten
Kontroll- und Inhaltsraum getrennt
Trennung in Kontrollraum -> Kontrolle !
Akustische Unterschiede zwischen den einzelnen Räumen
A.3 Gruppe 3
Beschreibung
Im Kontrollraum visuell max. acht (vier oben, vier unten) Felder verteilt auf
den ganzen Bildschirm.
Akustisch, sind diese max. acht Geräusche im Raum plaziert - oder in einer
Ebene, falls gleichzeitige graphische Ausgabe erfolgt.
Diese Geräusche (Wasserfall, Vogelgezwitscher, Gewitter, etc.) sind eindeutig
den Icons zugeordnet. Falls eigenständige Icons erzeugt werden (z.B. eigene
Navigationsräume), müssen diese eigene Geräusche bekommen
Icons:
1. Text, Preferences, URL-Eingabe, Back (vielleicht ein Menü)
2. Struktur, Linkliste, zwei weitere (frei)
Struktur-Icon = überschriften im Text
Linkliste-Icon = Verweise im Text
Alle Geräusche ertönen gleichzeitig, die Lautstärke ist jedoch abhängig von
der Entfernung. Wenn man einem Icon, auf dem Bildschirm, näherkommt,
wird auch das Geräusch lauter, etc.
Ab gewisser Nähe zu einem Icon (Bildschirmmäßig wenn man auf dem Icon
ist) wird nur noch dessen Geräusch dargestellt (alle anderen Töne sind ausgeblendet). Außerdem erfolgt eine Anpassung des Geräusches auf Grund zusätzlicher Information (eingeblendet innerhalb einer Sekunde): z.B Text-Icon
= Wasserfall, dann: Größe des Wasserfalls entspricht Größe des Texts. Dies
ist gedacht als Hinweis das dieses Icon nun aktiv ist, und man es per Maus
bedienen kann.
Klick = Erklärung des Icons durch Sprachausgabe
Doppelklick = Ausführen / Aufbau eines weiterführenden Menüs
Weiterführende Ideen:
36
A.4 Gruppe 4
– Unterscheidung der Räme durch raumspezifischen Hall der einzelnene Geräusche, z.B. Kontrollraum = metallischer Klang, Dokumentdarstellung =
papiernes Geraschel, ...
– Jede Änderung des Raumes (Bildschirmaufbaus), wird durch einen entsprechenden Ton als Bewegungsrückmeldung unterlegt, zum Beispiel das
„Ausschleusen“ bei Elite, oder falls man in den Kontrollraum wechselt, nähern sich die max. 8 Geräusche aus dem Nichts an einen heran...
– Gleiche Geräusche im Text (Also wenn im Dokument auf die Linkliste verwiesen wird ertönt auch dort dasselbe Geräusch wie in der Kontrollzentrale
— Erwartungskonformität).
Kritik
redundante Information
Sound überflüssig?
zu viele Geräusche
zu viele Nuancen bei den akustischen Earcons, Ton gibt zu viele Informationen
Geräusche in nur einer Ebene
tabellenförmige Anordnung der Icons
8 Punkte sind zu wenig an Funktionalität
Navigation und eigentliche Kontrollfunktion kaum getrennt
kein neues Navigationskonzept
Innovative Aspekte
leicht bedienbare Struktur
sehr übersichtlich
Hearcons kommen näher/entfernen sich
Einfach-/Zweifach-Klick
Einbeziehung des Bildschirms
frei wählbare Kontrollpunkte
A.4 Gruppe 4
Beschreibung
1. Grundlagen
Für die einzelnen Seiten müssen folgende Informationen verfügbar sein:
Information (kurze Inhaltsangabe, evtl. Schlagwörter)
Property-Informationen (Definitionsseiten, weiterführende Seiten, Hauptseiten, ...)
Link-Information: kurze Zusammenfassung des Inhalts
Grundlage des Navigationskonzeptes ist, daß eine Unterscheidung zwischen
Kontroll-, Navigations- und Inhaltsschicht besteht. Ob Kontroll- und Navigationsschicht noch unterschieden werden müssen, steht zur Diskussion. Die
einzelnen Schichten sind übereinander angeordnet: als Basis die Inhaltsschicht,
37
A.4 Gruppe 4
dann die Navigations- und zu oberst die Kontrollschicht. In der Inhaltsschicht
steht tatsächlich nur der Content der Seite zur Verfügung. Sie wird nur betreten, wenn der Screenreader aktiv ist oder was auch immer zur Darstellung
des eigentlichen Inhalts genutzt wird. Danach bewegt sich das Programm
automatisch wieder in die Navigationsschicht und erwartet weitere Anweisungen (Inhalt darstellen, Link verfolgen, zurück, ...). Der Übergang in den
Kontrollraum entspricht einer Bewegung nach oben.
Alle Befehle werden per Spracheingabe eingegeben.
2. Primitive Navigation
Die Navigation soll im wesentlichen auf einer Art Landkarte beruhen, die das
Programm selbständig führt und über die der Benutzer einerseits weiter navigieren kann, aber auch Zugriff auf bereits besuchte Inhalte/Seiten erhält.
Diese Maps stellen somit eine Art History dar. In der normalen Navigation
sind z.B. Bewegungen vor und zurück denkbar, ebenso müssen Links verfolgt werden können oder die Content-Info zu einer gelinkten Seite abrufbar
sein. Beim Betreten einer Seite sollte es ein Kurzinfo darüber geben, was diese
Seite enthält (Content-Info). Die Information könnte zum einen per Sprache
ausgegeben werden oder durch kurze akustische Signale. Beispiel: Nach Betreten einer Seite ertönen zwei PingSignale. Das erste gibt an, wie viel Content (Menge) auf dieser Seite zu erwarten ist (je höher der Ton, desto mehr
Content), der zweite Ping gibt an, wie viele weiterführende Links diese Seite
enthält (je höher desto mehr).
3. Die Landkarte (Map)
Die Landkarte stellt die Basis sowohl für die erweiterte Navigation in der
History (über den Kontrollraum) als auch für die Navigation in den Bookmarks bzw. Pfaden dar. Die Landkarte wird vom Programm selbständig geführt und ist im Kontrollraum darstellbar. Die Darstellung soll akustisch (näheres siehe im Abschnitt über den Kontrollraum) und bestenfalls auch visuell
vorliegen. Da die Landkarte mit fortlaufender Surfdauer sehr groß und damit
unübersichtlich wird, soll es möglich sein, bestimmte Teile der Karte bei Bedarf auszublenden. Um dies zu erreichen muß es für den Benutzer möglich
sein, bestimmte Bereiche der Karte (Teilkarten) zu markieren. Wird durch den
Benutzer ein Marker gesetzt, werden alle ab dahin besuchten Seiten mit eben
diesem Marker versehen. Im Kontrollraum kann dann nur noch der Kartenteil eingeblendet werden, der mit dem gewünschten Marker versehen ist.
In der Karte werden grundsätzlich die Content-Infos und Link-Infos und Property-Infos aller besuchten Seiten gehalten. In wie weit dies vom Umfang her
handlebar ist, bleibt zu klären. Da aber immer nur die Infos der Seiten, die um
den aktuellen Standpunkt herumliegen dem Benutzer zur Verfügung stehen
müssen, sollte die Informationsflut in Grenzen zu halten sein.
Akustisch werden dem Benutzer die Informationen geboten, die er auch erhalten könnte, wenn er auf einer bestimmten Seite steht, ohne sie tatsächlich
betreten zu müssen. Beispiel: Während einer Session wurde irgendwann im
Text ein bestimmtes Stichwort erwähnt, zu diesem Text möchte der Nutzer
nun gern zurück. Er bewegt sich in den Kontrollraum und erhält die Information, daß er sich auf der Seite zum Thema XXX befindet. Diese Seite hat
er bereits zwei mal erreicht. Einmal von YYY aus (entspricht im der Beispielmap Pfad 1) und einmal von ZZZ aus (Pfad 2). Er will genauere Informationen über den Pfad 2 und fordert genauere Informationen über die Seite aus
diesem Pfad, von der aus er an den aktuellen Standort gelangte. Hier erfährt
er wiederum, worum es auf dieser Seite geht und von wo aus er dorthin gelangte. Sollte er nun irgendwann die Seite aus der History gefunden haben,
38
A.4 Gruppe 4
Start (Suchmaschine)
Ergebnis 1
Ergebnis 2
Legende
Pfad 1
Pfad 2
verfolgte Links
unverfolgte Links
Abbildung A.2: Eine Beispielmap
zu der er wollte, kann er sich sofort dorthin bewegen oder kurz den Content
anschauen ohne die aktuelle Position zu wechseln.
4. Ein Beispiel für eine Map ist in Abb. A.2 zu sehen.
5. Der Kontrollraum
Der Kontrollraum könnte in Hinblick auf das gesamte Navigationskonzept
auch als Kartenraum bezeichnet werden. Da der Kontrollraum ein separater
Raum mit bestimmten Funktionen ist, die in anderen Schichten nicht verfügbar sind (z.B. auch das Laden und Speichern der Karten ...) sollte es einen
akustischen Marker geben, der anzeigt, das man sich im Kontrollraum befindet. Dies könnte z.B. ein unterschwelliges Brummen sein (wie in einem Maschinenraum eines Schiffes ...). Außerdem könnte man, um zu Verdeutlichen,
wo man auf der Karte gerade steht wiederum die Content-Info der aktuellen
Seite anbieten oder zusätzlich noch eine weitere akustische Information, die
Aufschluß über das direkte Umfeld gibt (nicht primär die Eigenschaften der
Seite, auf der ich mich befinde, sondern die der Seiten, die um diesen Punkt
herumliegen).
Um die Orientierung in der Map und das wiederfinden von Informationen
noch transparenter zu gestalten, ist ein erweitertes Bookmark-Konzept erforderlich. Es soll nicht nur möglich sein, wie bei herkömmlichen Browsern, einfache Lesezeichen zu setzen, die sequentiell gespeichert werden, sondern es
müssen verschiedene Arten von Bookmarks zur Verfügung gestellt werden,
so daß der Content unterschiedlich markiert werden kann. Die einfachste Variante dieser Idee wäre temporäre und permanente Bookmarks einzuführen.
Temporäre Bookmarks dienen lediglich dazu, bestimmte Wege (Pfade) in der
Map zu markieren, um möglichst effektiv wieder zum Ursprung bestimmter
Informationen zurückzufinden. Daneben sollte es nach wie vor die herkömm39
A.4 Gruppe 4
lichen Bookmarks geben, die einzelne Plätze markieren, die immer wieder
aufgesucht werden sollen.
Eine weitere wesentliche Funktion, die im Kontrollraum verfügbar ist, sollte
es ermöglichen, in den Content-Infos der gemapten Seiten nach bestimmten
Schlagwörtern zu suchen. Außerhalb der Bookmark-Funktion können so bereits gelesene Inhalte schnell wiedergefunden werden. Auch hier sollte die
Einschränkung des Suchweges auf bestimmte Pfade möglich sein.
Kritik
3 Pings zu komplex
sehr viel Sprachausgabe sofort
erhält Benutzer ausreichende Idee von räumlicher Karte ?
übersichtlichkeit des Kontrollraums bei vielen angebotenen Informationen
verlangt sehr disziplinierte Surfer - wissenschaftliches Arbeiten
Karte nicht die typische Steuerfunktionalität
nur für Lexikon
spezielle Anforderungen an Site-Autor, Inhaltsangabe
Immenser lokaler Speicherbedarf; Download- Aufwand für Karte
Innovative Aspekte
sehr detaillierte Ausgabe
Informationsdarstellung und Űverknüpfung
Karten- und Teilkartenkonzept
Nav-Karte
Marker im Navigationskonzept
Landkarte, eigene Pfadhistorie
Einbeziehung unterschiedlicher Link-Arten; Ping-Konzept
Entropie bei Linkgruppen
Gruppierung der Links
Infos über Umgebung der Seite Gruppen (?)
neue Art zur Info-Recherche, Nav-Karte wird veröffentlicht
Sprachausgabe
Inhaltsangabe = Vorschlag
Inhaltsangabe im Kontrollraum
40
Anhang B
Auswahl der IDE
Dieses Kapitel beschreibt die Ergebnisse der Untersuchung der verschiedenen IDEs.
B.1 IBM Visual Age 3 Entry Edition
Systemanforderungen:
Win 9x / NT4 SP4,
Pentium, 48 MB Ram
bis 300 MB Festplatte
IBMs IDE verwaltet grundsätzlich keine .java oder .class Dateien, sondern arbeitet
auf einer Datenbank, in der sowohl Quellcodes als auch die Binarys gehalten werden (Repository). Mittels eines recht komfortablen Browsers ist es so möglich, auch
auf Klassen oder Packages zuzugreifen, die nicht zum aktuellen Projekt gehören.
Ein weiterer Vorteil dieses Verfahrens sind die erweiterten Suchmöglichkeiten z.B.
nach bestimmten Methoden über mehrere Projekte hinweg. Auf Wunsch können
beliebige Pakete, Klassen oder Quellen im herkömmlichen Format auf die Platte
ausgelagert werden. Eine Einlagerung (auch nachdem z.B. Quellen extern modifiziert wurden) ist ebenfalls problemlos möglich.
Im GUI-Editor können nicht nur Oberflächen designt werden, sondern es werden
auch die (z.B. zu einem Button) gehörigen Verknüpfungen zu bestimmten Methoden im Quellcode visuell angezeigt und auf Wunsch zum editieren angeboten. Leider werden Änderungen in den Quellen nicht direkt im GUI-Editor berücksichtigt,
ein manuelles Reengineering ist nötig, funktioniert aber manchmal nicht korrekt
(z.B. wenn keine bekannten Standard-GUI-Elemente, sondern eigene, abgeleitete
Kreationen verwendet werden). Sollte das manuelle Übernehmen der Änderungen
einmal „vergessen“ und im GUI-Editor noch weitere Änderungen vorgenommen
werden, werden die manuell eingefügten Zeilen sogar aus dem Quellcode entfernt!
Hier ist sehr viel Aufmerksamkeit vom Benutzer gefordert.
Eine Benutzer-/Versionsverwaltung ist in dieser IDE schon enthalten. Es kann aber
auch eine externe Lösung (z.B. PVCS) verwendet werden.
Das zugrundeliegende JDK 1.2 kann nicht verändert werden. Ein Umstieg auf neuere/ältere JDK-Versionen ist also nicht möglich.
Die Dokumentation ist in Form eines Hilfe-Systems integriert, außerdem existieren
diverse Newsgroups.
B.2 Sun Forte 1.01 Community Edition
B.2 Sun Forte 1.01 Community Edition
Win 9x / NT4,
Pentium 300, 128 MB Ram
ab 30 MB Festplatte
Forte von Sun (einigen vielleicht auch unter dem OpenSource-Projekt Netbeans bekannt) basiert auf einem separat installiertem JDK (also auf einem beliebigen!). Unangenehm fallen sofort die immens hohen Systemanforderungen auf (mind. 128
MB Arbeitsspeicher, Prozessor jenseits der 300 mHz erwünscht). Tatsächlich bauen
sich einige Fenster recht langsam auf, Wizards brauchen ewig, bis sie zu sehen sind.
Besonders schwer wiegt dieser Nachteil, da Forte den Quelltext mit geschützten Codeblöcken versieht, in denen keine manuellen Änderungen vorgenommen werden
können. Den darin enthaltenen Eigenschaften ist nur über Property-Fenster, bzw.
Wizards beizukommen. Da kann es schon mal vorkommen, dass man für eine so
simple Eigenschaft, wie „visible=false“ 10 Sekunden auf den Wizard warten muss,
um dann auf Seite 3 (!) diese Einstellung zu ändern. Das extern geänderte Klassen
nicht wieder in das Projekt integrierbar sind, versteht sich in anbetracht dieser Umstände fast von selbst.
Eine Versionsverwaltung ist nicht vorgesehen, die Dokumentation beschreibt aber,
wie man Forte mit einem vorhandenen CVS-System nutzen kann — das Studium
dieses Kapitels wurde aufgrund der Umständlichkeit des Verfahrens abgebrochen.
Die Dokumentation der IDE beschränkt sich im wesentlichen auf einen User-Guide
und ein Quickstart-Dokument, beides im PDF-Format. Die Dokumentation der APIs
ist dann in dem verwendeten JDK enthalten und muss separat installiert werden.
Spezielle Newsgroups gibt es nicht.
B.3 Microsoft Visual J++ 6.0 Enterprise Edition
Win 9x / NT4,
Pentium, 48 MB Ram
bis 190 MB Festplatte
Ein ganz besonderer Fall von Java-IDE stellt Microsofts Visual J++ dar. Es basiert auf
MS eigenem JDK 1.1.4 (welches nichts mit irgendeinem Sun-JDK zu tun hat). Dies
erfordert unter anderem auch die Installation einer eigenen VM von MS. Mit anderen Worten: wer mit MS Visual J++ entwickelt, distanziert sich von der eigentlichen
Java-Welt, denn die entsprechenden Programme sind in keinem Fall mit der SunVM lauffähig, geschweige denn Plattform-unabhängig. Da die Sun und MS-JDKs
nicht annähernd kompatibel sind, ist es auch nicht möglich etwaige Zusatzpakete
(wie z.B. das von uns benötigte Java3D) in J++-Projekte zu integrieren.
Ansonsten macht VJ++ einen sehr guten Eindruck. Es ist alles vorhanden, was zum
effektiven Arbeiten nötig ist: eine eigene Versionsverwaltung (Microsoft Visual Sorce Safe), sehr guten Reengineering während der Eingabe, sehr guter Klassen-Browser
42
B.4 Borland Inprise JBuilder 3 Professional Edition
mit diversen Sprung-Möglichkeiten in den Quellcode usw.. Wer bereits mit anderen
Visual-Studio-Programmen (Visual Basic, Visual C++) bekannt ist, wird VJ++ sehr
gut und effektiv bedienen.
Die Dokumentation liegt in Form von mind. 2 CDs vor (Microsoft MSDN) oder ist
Online verfügbar. Es existieren diverse Newsgroups.
B.4 Borland Inprise JBuilder 3 Professional Edition
Win 9x / NT4,
Pentium 166, 96 MB Ram
ab 100 MB Festplatte
Die auf den ersten Blick eher recht simpel erscheinende IDE von Borland basiert
von Haus aus auf dem JDK 1.2. Es ist aber problemlos möglich, zwischen mehreren
JDK-Konfigurationen zu wechseln. Eine Integration von weiteren APIs ist ebenso
machbar. Das deutet schon die Variabilität an, die ein echter Vorteil dieses Programms ist! Änderungen im Quellcode werden während der Eingabe analysiert
und in den GUI-Builder übernommen, der auch mit selbst erstellten GUI-Klassen
zurechtkommt. Extern editierte Quellen können problemlos wieder in das Projekt
integriert werden. Der Debugger ist sehr umfangreich, er ermöglicht z.B. auch das
debuggen von Threads.
Eine Versionsverwaltung muss separat Installiert werden (PVCS).
Sehr gut und umfangreich ist auch die Dokumentation. Mehrere Bücher sind Online
verfügbar, diverse Beispiele, Tutorials, auch eine Doku der JBCL-API (Java Borland
Class Library) fehlt nicht. Es sind diverse Newsgroups verfügbar.
Bemerkung: Von Entwicklern, die bereits praktische Erfahrungen mit JBuilder haben, erhielten wir den Hinweis, dass JBuilder-Projekte, selbst wenn sie in pure Java
(also nur mit Sun-JDK-Klassen) geschrieben sind, nicht mehr extern kompilierbar
sind. Dieses Phänomen konnte aber (unter anderem mangels genügend großer Testprojekte) bei den eigenen Tests nicht nachvollzogen werden.
43
Anhang C
Evaluation der Töne
Um die Ergebnisse des Versuchs besser messbar zu gestalten, werden die Antworten der Probanten drei Kategorien eingeteilt. Sollte der Sound genau lokalisiert worden sein, erhält er in dieser Kategorie eine Beurteilung den Index 0, wurde eine Koordinate falsch eingeschätzt (z.B. vorne hinten verwechselt), erhält er eine 1. Wenn
der Sound gar nicht oder völlig falsch lokalisiert wurde, wird eine 3 im Protokoll
vermerkt.
Die Abbildung C.1 zeigt tabellarisch die Ergebnisse des Versuchs. Zur besseren
Übersicht wurden die Ergebnisse einer Kategorie farblich unterlegt.
bellen
bowling
drucker
glocken
harfe
kraehe
morsen
telefon2
trommel
vogel
dblatack
kurzc5
fakedoo
100sloo3
x3hammd2
1cl_long
clearbel
120sloop6
rocks15
doochor2
120slo11
fills02
gitrh12
gitrh01
bassd07
bassf07
distf01
bassa02
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
1
1
1
0
1
0
0
0
1
0
0
0
0
0
0
0
1
0
0
0
0
1
0
1
0
1
0
1
1
1
1
0
1
1
1
1
1
1
0
0
0
1
1
1
1
0
1
0
1
2
0
1
1
1
1
1
2
1
1
0
2
1
1
1
1
1
0
0
1
1
1
1
1
0
1
1
1
2
1
1
1
1
1
1
2
1
1
1
2
1
2
1
1
2
0
1
1
1
1
1
2
1
1
1
2
2
1
1
1
1
1
2
2
2
2
1
2
2
2
2
2
2
2
1
2
1
2
1
2
1
2
2
2
2
2
1
2
1
2
1
0
1
1
0
2
0
1
1
1
1
0
0
0
1
0
1
0
1
1
1
1
0
1
1
0
0
0
1
1
2
1
1
2
1
1
1
1
1
0
0
1
1
0
2
1
1
1
1
1
1
1
1
1
1
1
1
1
2
1
1
2
1
1
1
1
1
1
1
1
1
1
2
1
2
1
1
2
1
1
1
1
1
1
2
1
2
2
1
2
1
1
1
1
1
1
1
1
1
1
2
1
2
1
1
2
1
2
1
1
1
1
2
1
2
2
1
2
1
2
2
1
1
1
1
1
2
2
2
2
2
1
2
2
2
2
1
1
1
2
2
1
2
2
2
2
1
2
2
1
2
1
2
1
2
2
2
2
2
1
2
2
2
2
2
1
1
2
1
0
0
0
0
1
1
0
0
1
0
0
0
1
1
1
0
0
0
1
1
0
1
0
0
0
0
0
1
1
1
0
0
1
1
1
1
1
0
0
1
1
1
1
0
0
0
1
2
0
1
1
0
0
0
0
1
1
1
0
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
2
1
1
1
0
0
1
1
2
1
1
1
1
2
1
2
2
1
1
1
1
1
1
2
1
1
1
1
2
1
1
1
1
1
1
1
2
1
2
1
1
2
1
2
2
2
1
1
2
1
2
2
1
2
2
1
2
1
2
1
2
1
1
1
2
2
2
1
2
2
2
2
2
2
1
1
2
1
2
2
2
2
2
1
2
2
2
2
2
1
1
1
2
0
0
1
1
0
1
0
1
0
0
0
0
0
1
0
1
1
0
1
0
0
0
0
0
1
0
0
2
1
1
2
1
1
1
0
1
0
0
1
2
0
1
0
1
1
1
1
0
0
0
0
1
1
1
1
2
1
1
2
1
1
2
1
1
1
0
1
2
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
2
1
2
2
1
1
2
1
1
1
1
1
2
1
1
1
1
1
1
1
1
1
1
1
1
2
2
1
2
1
2
2
1
2
2
1
1
2
1
1
2
1
1
1
2
2
1
1
1
1
1
1
1
2
2
1
2
1
2
2
2
2
2
1
1
2
1
1
2
2
2
2
2
2
2
1
2
2
2
1
1
2
2
2
Erläuterung:
0 - genau lokalisiert
1 - 1 Koordinate falsch
2 - 2 Koordinaten falsch
Wie aus der
Flächenverteilung
ersichtlich, scheint es
nahezu unmöglich ein
Geräusch genau zu
lokalisieren.
Schlußfolgerung:
Orientierung anhand der
Geräusche im Raum nicht
möglich, daher müssen die
Geräusche nach anderen
Kategorien ausgewählt
werden.
Abbildung C.1: Ergebnisse der Evaluation der Töne
45
Anhang D
Erster Test des Prototypen
D.1 Handlungsanweisungen für den ersten Schritt
Für den ersten Schritt war folgendes Vorgehen vorgesehen:
1. Der Proband benutzt den Prototyp blind und mit Maus. Gestartet wird im generischen Raum (3 Hearcons). Finde alle Hearcons; lasse Dir die Erklärungen
vorlesen. Folgende Fragen und Handlungsanweisungen wurden dazu gestellt:
Wie heißt der Raum, in dem Du bist?
Wechsele in den Adressraum.
Löse die Funktion Neue Adresse eingeben aus.
Wechsele in den Textraum.
Öffne das Hilfe-Menü.
Verlasse das Menü durch Auswählen eines der Menüeinträge.
2. Der Proband benutzt jetzt den Prototyp sehend mit der Maus. Folgende Fragen
und Handlungsanweisungen wurden dazu gestellt:
Wechsele zum Adressraum.
Wechsele in den Stille–Modus.
Finde einen Link mit der Maus.
Wechsele in den generischen Raum.
Wechsele in den Air-Modus.
Öffne das Menü; wähle den obersten Menüeintrag aus.
Wechsele in den Textraum.
Finde die Funktion zum Vorwärtsscrollen im Text (nicht die Scrollbar!) und
löse sie aus.
3. Der Proband benutzt jetzt den Prototyp sehend mit Joystick. Der Versuchsleiter
erklärt, wie der Joystick aktiviert wird (falls nötig). Folgende Fragen und Handlungsanweisungen wurden dazu gestellt:
Finde die Funktion zum Zurückscrollen des Textes und löse sie aus.
Wechsele in den generischen Raum.
öffne das Menü; löse im Menü eine (beliebige) Funktion aus.
D.2 Ergebnisse der Evaluation
D.2 Ergebnisse der Evaluation
Lokalisierung/Treffen der Hearcons problematisch (akustische Haptik):
– Verzicht auf das Hintergrundgeräusch; oder Verzicht auf das Hintergrundgeräusch speziell über einem Hearcon.
– Bessere Sounds (gültige Metaphern).
– Das Hearcon könnte evtl. eine andere Tonlage annehmen wenn das Icon erreicht wird.
– Weitere Verbesserung der Trefferwahrscheinlichkeit durch Vorlesen der Bezeichnung bei Erreichen des Icons (Problem mit Synchronisation mit dem jeweils zweiten Kanal).
Beobachtete Desorientierung bei blinder Benutzung. Vorn/hinten nicht gehört:
– Bessere akustische Haptik (s. o.).
– Andersartige Anordnung der Hearcons des Hearconkranz (einfachere Anordnung; z. B als horizontale Leiste).
Joystick: zittert, ungenau; Cursor nicht überall sichtbar, kein Vorlesen:
– besseren verwenden.
– Diskrete Positionen für Joystick?
– Hearconkranz wie erwartet.
– Linkauswahl (?): Irgendwie in den Linkmodus gehen (Tastaturkürzel, eindeutige Joystickeingabe,...) dort Navigation von Link zu Link mit den Joystickbewegungen.
– Vorlesen auch für den Joystick implementieren.
– Joystickcursor überall am Bildschirm sichtbar (auch hinter Icon, Menüeintrag).
Fehlende Rückmeldungen des Systems:
– Rückmeldungen bei Aktionen (z. B. Raumwechsel).
– Menü: Vorlesen der Menüeinträge.
– Sprachengine? Wav-Dateien?
47
Anhang E
Evaluation des Prototypen
E.1 Versuchsablauf und Aufgaben
Die Evaluation war mit folgendem Ablauf und Aufgaben geplant:
Der Versuch bestand aus 7 Räumen R1 - R7. Die folgende Skizze verdeutlicht, an welchen Positionen die Räume mit Geräuschen bestückt waren (Draufsicht, oben ist vorn):
R1,R4:
--------|
o
|
|
|
|o
o|
|
|
|
o
|
---------
R2,R5,R7:
--------|o
o
o|
|
|
|o
o|
|
|
|o
o
o|
---------
R3,R6:
--------|o
o|
|
|
|o
o|
|
|
|o
o|
---------
Die Räume mit gleicher Hearconzahl verwenden auch die gleichen Geräusche an den
jeweiligen Positionen, sind also insofern identisch. Durch die Reihenfolge kommt die
Testperson mehrfach – allerdings mit Abstand – in sich gleich anhörende Räume.
Raum R7 unterscheidet sich von den übrigen Räumen darin, dass die Hörradien der
Geräusche geringer sind. Der Hörradius gibt an, in welcher Entfernung vom Hearcon
das Geräusch noch gerade hörbar ist. Der Hörradius war hier so eingestellt, dass in der
Mitte nichts zu hören war.
Die Räume wurden von den Testpersonen in der Reihenfolge ihrer Nummer durchlaufen. Der Raumwechsel wird vom Betreuer durchgeführt.
In den Räumen R1–R3 verwendete die Testperson die Maus als Eingabegerät. Pro Raum
mussten die folgenden Aufgaben gelöst werden.
– Zunächst ohne das Eingabegerät zu verwenden, mussten folgende Fragen beantwortet werden: Wieviele Geräusche sind vorhanden? Was für Geräusche sind es? Wo sind sie?
– Danach sollten die selben Fragen mit Verwendung des Eingabegerätes noch ein mal
beantwortet werden. Zunächst hörte man also die Geräusche nur, ohne die Möglichkeit zu haben, die Geräusche mit dem Eingabegerät „anzufahren“.
– Abschließend sollten zwei bestimmte Geräusche gefunden werden. Ein gefundenes
Hearcon sollte angeklickt werden, und die dabei zu hörende Bedeutung des Hearcons zur Kontrolle wiederholt werden. Es waren beliebig viele Maus-/Joystickklicks
gestattet.
Danach, in den Räumen R4–R6, werwendete die Testperson den Joystick als Eingabegerät. Die Aufgaben waren dieselben wie in den vorangegangenen Räumen.
Im letzten Raum, R7, verwendete die Testperson ein Eingabegerät ihrer Wahl. Mit dem
gewählten Eingabegerät sollten dann die selben Aufgaben wie zuvor gelöst werden, es
fiel nur der Teil der Aufgaben ohne Eingabegerät weg.
E.2 Beobachtungen und Ergebnisse
E.2.1 Anzahl erkannter Hearcons
In der ersten Tabelle geht es um die Anzahl der in den 4er-, 6er- bzw. 8er-Räumen
erkannten Hearcons (Geräusche). In jeder Zelle ist die Anzahl der erkannten Hearcons und die Gesamtzahl der vorhandenen Hearcons angegeben. Dabei sind jeweils
die Ergebnisse der einzelnen Testpersonen sind zusammengezählt, so dass sich etwa Gesamtzahlen von 32, 48 etc. ergeben. Diese Ergebnisse berücksichtigen nicht,
ob die Hearcons richtig geortet wurden.
Raum
ohne Eingabegerät, Maus
ohne Eingabegerät, Joystick
ohne Eingabegerät. gesamt
mit Eingabegerät, Maus
mit Eingabegerät, Joystick
gemischt
4-er
6-er
8-er
Jeweils Summe aus allen 8 Versuchen
27/32 42/48
52/64
31/32 45/48
55/64
58/64 87/96
107/128
32/32 47/48
60/64
32/32 46/48
63/64
64/64
E.2.2 Lokalisierung der Hearcons
Die folgenden Tabellen geben an, wie gut einzelne Geräusche lokalisiert werden
konnten, und zwar ohne Benutzung des Eingabegerätes. Jede Tabelle steht für einen
der Räume R1–R6. Die Zahlen jeweils rechts neben den Geräuschbezeichnungen
geben an, wie oft das Geräusch wie gut lokalisiert werden konnte. Die Lokalisierungsgüte ist in vier Stufen ausgedrückt (0–2, n.e.)
Legende:
0 Geräusch perfekt geortet
1 Geräusch halb falsch geortet
2 Geräusch falsch geortet
n.e. Geräusch nicht erkannt
* Geräusch dreimal nicht gespielt
+ Geräusch erkannt, aber nicht geortet
Fettschrift linke oder rechte Position
4er Raum, Maus
0 1 2 n. e.
Gitarre 3 3 2
0
Bass
1 4 2
1
Drums 5 1 0
2
Synthi 5 0 0
2
6er Raum, Maus
0 1
Fahrradkette
1 1
Autotür
1 5
Schreibmaschine 8 0
Autohupe
0 8
Filzstift *
5 0
Telefon
1 6
2
1
1
0
0
0
0
n. e.
5
1
0
0
0
1
4er Raum, Joystick
0 1 2 n. e.
Gitarre 2 5 1
0
Bass
2 4 2
0
Drums 8 0 0
0
Synthi 7 0 0
1
6er Raum, Joystick
0 1
Fahrradkette
2 5
Autotür
2 5
Schreibmaschine * 4 1
Autohupe
1 7
Filzstift
5 2
Telefon
1 7
2
0
0
0
0
0
0
n. e.
1
1
0
0
1
0
49
8er Raum, Maus
0 1 2 n. e.
Bellen
1 5 1
1
Vogel +
0 3 1
3
Krähe
0 5 0
3
Telefon
7 0 0
1
Glocken
2 4 0
2
Drucker
6 2 0
0
Morsen
0 6 0
2
Bowling + 4 3 0
0
8er Raum, Joystick
0 1 2 n. e.
Bellen
0 6 0
2
Vogel
1 3 2
2
Krähe
0 7 0
1
Telefon 6 2 0
0
Glocken 0 6 0
2
Drucker 6 1 0
1
Morsen 0 7 0
1
Bowling 3 3 2
0
E.2.3 Zeitbedarf für das Lokalisieren der Hearcons
Gemessen wurde auch der Zeitbedarf für das Lokalisieren von Geräuschen unter
Verwendung des Eingabegerätes.
Für jede Versuchsperson (anonymisiert durch Angabe des Versuchsleiters) sind die
Zeiten in den einzelnen Räumen angegeben. Zeitangaben (in Sekunden) gibt es für
das Auffinden aller Hearcons („alle“), und zum Lösen der jeweils zwei Einzelaufgaben („G 1“ und „G 2“). „Alle“ und „G 1“ unterscheiden sich insofern, als dass
bei „G 1“ die Hearcons nur als einzelne erkannt, nicht aber lokalisiert (gefunden)
werden mussten. Die Zeiten wurden anhand der Videoaufzeichnung ermittelt.
Für den Raum 7 ist zusätzlich das von der Versuchsperson gewählte Eingabegerät
(M = Maus, J = Joystick) angegeben, und ob dieser Raum auf Grund der nicht in der
Mitte klingenden Hearcons leichter zu bedienen ist (+: besser, : schlechter)
Leider konnten in mehreren Fällen die Zeiten nicht aufgenommen werden (leere
Zellen). Gründe waren nicht erfassbare Zeiten, nicht erfolgreich gelöste Aufgaben
oder nicht relevante Versuchsabläufe.
50
VL/VP
3.1
VL/VP
1.1
2.1
2.2
Raum
1
2
3
4
5
6
7 (J)
1
2
3
4
5
6
7 (J) (+)
1
2
3
4
5
6
7 (J) (+)
alle
30
105
145
22
20
50
110
45
G1
25
20
5
1
5
1
35
G2
43
10
50
5
3
4
2
5
7
1
1
6
1
1
4
7
3
7
10
1
1
5
1
2
10
5
2
2
4.1
5.1
6.1
6.2
Raum
1
2
3
4
5
6
7 (M) (+)
1
2
3
4
5
6
7 (J) (-)
1
2
3
4
5
6
7 (M) (-)
1- 6
7 (J)
1-6
7 (J) (-)
alle
G1
372
180
85
170
278
305
45
65
126
33
78
82
10
2
1
2
26
3
G2
48
30
3
5
12
6
10
20
25
10
2
3
12
3
3
1
10
2
11
3
8
4
E.2.4 Beobachtungen durch die Videoaufzeichnung
Neben der harten Zeitmessung haben wir auch Wert gelegt auf die zu machenden
Beobachtungen während der Versuchsdurchführung, soweit sie auf dem Video aufgezeichnet wurden. Im Endeffekt waren diese Beobachtungen für Designentscheidungen des Produkts am fruchtbarsten.
1. Die meisten Versuchspersonen sind im ersten Raum mit dem Eingabegerät eher
„wild herumgefahren“, im weiteren zeigte sich dieses Verhalten nicht so stark.
2. Die Testpersonen haben sich im allgemeinen die Geräusche gut gemerkt und
wieder erkannt, wenn sie ein zweites Mal in einem gleich klingenden Raum
gelangten.
3. Zwei Testpersonen haben bei Benutzung der Maus mindestens einmal jede Orientierung verloren.
4. Lokalisierung ohne Verwendung des Eingabegerätes resultierte häufig nur in
einer Links/Rechts-Einteilung.
5. Als Richtungen wurden auch oben/unten genannt (obwohl die Akustik in einer
waagerechten Ebene angelegt war).
6. Hearcongeräusche klingen nicht allseitig, wenn das Eingabegerät genau auf das
Hearcon zeigt.
51
7. Das Vorlesen der Hearconbedeutung erfolgte ebenfalls nicht allseitig.
8. Beim Klicken mit dem Joystick auf ein Hearcon passierte es, dass das Vorlesen
mehrfach einsetzte. (Durch Zitterbewegung des Joysticks schien das Hearcon
mehrmals angeklickt worden zu sein.)
9. Nicht kontinuierliche Geräusche konnten schlechter lokalisiert werden als kontinuierliche.
10. Einige Testpersonen dachten an thematische Räume. Geräusche im selben Raum,
die nicht zu einem solchen Thema gehören, wurden falsch beschrieben. Raum 3
wurde häufig aufgrund von Telefon und Schreibmaschine als Büroszene angesehen und die anderen Geräusche entsprechend „uminterpretiert“:
Autotür Stempel; Fahrradkette Projektor.
11. Manche Hearcons wurden bei einer gezielten Suche (Aufgabe) direkt angefahren, auch wenn sie vorher nicht genau lokalisiert werden konnten. Diese Hearcons befanden sich rechts vorn.
12. Mehrfach traten Kaltstarts des Rechners während der Benutzung des Programms
auf.
52
Anhang F
Technische Beschreibung des
Produkts
F.1 Anbindung des Internet Explorers
Mögliche Lösungen sind:
1. Eigene Anbindung des IE an Java
Beschreibung: Anbindung selbst entwickeln (Wrapper).
Anforderungen: IE als Java-GUI-Komponente.
Von Java aus steuerbar.
Zugriff auf DOM.
Machbarkeit: ja
Vorteile: GUI (Prototyp) kann weiter verwendet werden (AWT/Swing).
Wiederverwendbare Komponente entsteht.
Nachteile: Aufwand für Entwicklung der Anbindung (sehr hoch), Einarbeitund
in JNI, MFC, COM.
native Win32–Programmierung nötig.
2. MS-Java-SDK
Beschreibung: Java-SDK von Microsoft bietet einen Zugriff auf das COM von
Java aus an. Ist allerdings MS-spezifisch und setzt das SDK von MS voraus.
Machbarkeit: ja
Vorteile: Klassen sind vorhanden (Browser, DOM).
Nachteile: GUI neu entwickeln.
Anschaffung von Visual J++ nötig(?).
Umstellung auf Visual J++ (?).
reine (MS-)Java-Lösung, kein natives Win32
3. JWindows
Beschreibung: JWindows ist eine Anbindung der MFC an Java.
Umfaßt allerdings nicht den InternetExplorer.
JWindows verwenden und für uns erweitern.
Machbarkeit: Noch unklar, vermutlich ja
F.2 Technische Beschreibung
Vorteile: Open Source
Nachteile: Windows muß erweitert werden, da IE nicht vorhanden ist.
Für die Erweiterung wäre (wahrscheinlich) auch native Programmierung nötig (?).
Offene Fragen Würde JWindows mit AWT/Swing auf Java-Seite harmonieren?
(Sonst müste JWindows für die gesamte GUI verwendet werden).
Ressourcen http://www.rolemaker.dk/JWindows
4. Bridge2Java
Beschreibung: Native-Komponenten über Wrapper in Java programmieren
Machbarkeit: ja
Vorteile: Keine Native-Programmierung nötig.
GUI hätte weiter verwendet können (tun wir aber nicht).
Nachteile: nicht fertiges Produkt
Stabilitätsprobleme. Probleme, die volle Funktionaltiät von COM in B2J umsetzen.
Einarbeitung in B2J, unzureichende Dokumentation
Lange Einarbeitungsphase nötig
Ressourcen www.alphaworks.ibm.com
Im folgenden ist
AIRBrowser das Startverzeichnis des Produkts, so wie es im CVS hinterlegt ist,
AirWebData das aktuelle Homeverzeichnis, und
Java3D die Installation von Java3D
F.2.1 Laufzeitumgebung
Die Laufzeitumgebung ist der JBuilder-Projektdatei „AirBrowser.jpr“ entnommen.
Zur Laufzeit benötigt das Programm Zugriff auf einige Laufzeitbibliotheken und
auf die Konfigurationsdateien und die Sound- und Icon-Dateien.
Die benötigten Laufzeitbibliotheken, eingebunden mit Hilfe der
-Djava.library.path-Angabe sind
die Bibliotheken im CVS, also AIRBrowser\lib,
die Java3D-Bibliothek, also Java3D\java3d_version12\sdk\jre\bin
und die Anbindung des Browsers, je nach gewähltem Wrappergenerator, wie
in Kap. F.2.3.3 und Kap. F.2.3.4 beschrieben.
Die Pfade zu den Konfigurationsdateien und zu den Sound- und Icon-Dateien werden mit Hilfe von Kommandozeilenparametern festgelegt.
Die Klasse mit der main()-Methode zum Starten des Programms ist
awp.AirBrowser.
54
F.2.2 Kommandozeilenparameter
Folgende Kommandozeilenparameter sind möglich:
-i Datei Pfad/Dateiname der Ini-Datei, Default-Wert ist AW_ini.xml
-m Datei Pfad/Dateiname der Markerlisten-Datei, Default-Wert ist AW_mark.xml
-o Datei Pfad/Dateiname der Optionen-Datei, Default-Wert ist AW_opt.xml
-p Pfad Pfadangabe, die den Angaben bei -i, -m, -o vorangestellt wird
-s Pfad Pfadangabe, die den Angaben bei Sounddateien in der Ini-Datei vorangestellt wird
-k Pfad Pfadangabe, die den Angaben bei Icondateien in der Ini-Datei vorangestellt wird
F.2.3 Verwendete Komponenten/Bibliotheken
F.2.3.1
Java JDK 1.3
Das Java-Basissystem. Die 1.3-Version wird für einige spezielle Funktionen in der
Browserschnittstelle und der Mausanbindung benötigt.
F.2.3.2
Java3D
Java3D wird bei der Ansteuerung der Eingabegeräte benutzt.
F.2.3.3
Bridge2Java
Eine Java-Schnittstelle zum Internet Explorer ist Bridge2Java (Zur Entscheidung für
diese Variante s. Kap. 5.4 auf Seite 25). Die Verwendung von Bridge2Java ist dokumentiert in:
http://www-cg-hci.Informatik.Uni-Oldenburg.DE/
airweb/AirBrowser/Documents/Browser_IE/Probleme Info
Bridge2Java.pdf
Die Javaresourcen finden sich unter
AirWebData\3rdParty\bridge2java\b2j\MSIE.jar
AirWebData\3rdParty\bridge2java\b2j\MSHTML.jar
AirWebData\3rdParty\bridge2java\Bridge2Java\
Als Bibliothekspfad wird benötigt:
AirWebData\3rdParty\bridge2java\
Bridge2Java\runtime\bridge2java\Release\
F.2.3.4
JacoZoom
Eine stabilere, aber langsamere Variante zur Anbindung des Internet Explorer ist
„jacoZoom“ von „www.infozoom.de“.
Die Javaresourcen sind unter
55
AirWebData\3rdParty\jaco\Runtime
zu finden
Als Bibliothekspfad wird benötigt:
AirWebData\3rdParty\jaco\Runtime
Die Bibliothek „IzmJniComAx.dll“ muss zuvor mit Hilfe des Programms „REGSVR32.EXE“ am System angemeldet werden.
Diese Variante kollidiert mit anderen nativen Komponenten, die auch eine COMSchnittstelle benutzten. Die anderen Komponenten müssen daher in einem anderen
Java-Thread laufen. In dieser Form ist dies auch im AirBrowser realisiert.
F.2.3.5
Anbindung Joystick
Der Joystick wird über das Java Native Interface angebunden. Dazu wurde eine
Windows-DLL erstellt, die die entsprechenden Aufrufe auf das Windows-API abbildet. Auf Java-Seite pollt das Programm die Joystick-Koordinaten und Tastendrücke
in ausreichend kleinen Zeitabständen. Dies geschieht asynchron in einem eigenen
Prozeß, wie er bereits Teil der Java3D-Grafikbibliothek ist. Die erhaltenen Werte
werden dann auf Bildschirmkoordinaten umgerechnet, wodurch der Joystick sich
als normales Eingabegerät in das Programm einfügt.
Die benötigte Bibliothek, „Joystick.dll“ , ist zu finden unter
AIRBrowser/lib/Joystick.dll
F.2.3.6
Native Mausanbindung
Die Mausposition und Mausclicks werden ebenso wie der Joystickstatus in einer
Native-Bibliothek abgefragt. Auf diese Weise ist es möglich, sich entgegen der JavaFensterphilosophie auch Mausevents außerhalb des Applikationsfensters liefern zu
lassen und die Weiterleitung der Mausattribute an andere Windows-Programme zu
unterbinden. Dies hat zwei wesentliche Anwendungen: Der eingebundene Internet
Explorer kann passiv gesetzt werden und eventuell vorhandene Topmost-Fenster
(Taskleiste etc.) können die Anwenderinteraktion nicht beeinträchtigen. Ermöglicht
wird dies durch die Windows-Hook Schnittstelle. Hier lassen sich C-Prozeduren
aus selbstgeschriebenen DLLs anmelden. Windows blendet die DLLs in den Adreßraum eines jeden laufenden Programms ein und ruft die Funktionen jedes Mal auf,
bevor Ereignisse an die jeweiligen Programme weitergeleitet werden. Einige Fenster sind von dieser Regel ausgenommen, so lassen sich etwa die Events, die an
Kommandozeilen-Fenster gehen, nicht abfangen.
Die benötigte Bibliothek, „NativeMouse.dll“, ist zu finden unter
AIRBrowser/lib/NativeMouse.dll
F.2.3.7
Evapro
Die Anbindung an die A3D-Soundkarte wird mit Hilfe der Schnittstelle von Evapro
realisiert. die benötigten Klassen sind
56
AirWebData/3rdParty/evapro/evapro/a3dtools.java
sowie die dazugehörige Bibliothek
a3dtools.dll
die die native Anbindung realisiert.
F.2.3.8
Sprachein- und ausgabe
Bei den Sprachfunktionen haben wir uns für den Einsatz des Produktes „Via Voice“
der Firma IBM entschieden, da dieses eine ausreichende Funktionalität besitzt, eine
nur unwesentlich eingeschränkte Evaluationsversion frei verfügbar ist und ein SDK
mit Unterstützung der Java-Speech API erhältlich ist.
Die sogenannte Speech-Engine von Via Voice wird über das standardisierte Java
Speech-API angesprochen. Hier muß unterschieden werden zwischen den Ein- und
Ausgabefunktionen.
Für die Ausgabe ist unter anderem die Schnittstelle javax.speech.Synthesizer zuständig. Hier können Text-Strings übergeben werden, die die künstliche Stimme
anschließend vorliest. Parameter der Stimme, wie
Alter
Lautstärke
Tonhöhe
Betonung
Geschwindigkeit
lassen sich, abweichend von der API, über in den Text eingebaute Kontrollbefehle
steuern.
Für die Ausgabe können prinzipiell beliebige Sätze vorgesehen werden. Bei der
Auswahl wurde besonders auf die Wahl kurzer, prägnanter und verständlicher Begriffe geachtet.
Für die Spracheingabe ist zunächst eine Ascii-Datei zu erstellen, die die möglichen Befehle in Form einer Grammatik beschreibt. Diese Liste ist dem Interface javax.speech.Recognizer zu übergeben, das daraus eine interne Repräsentation der zu
erkennenden Muster erstellt. Über verstandene Worte und die gegenwärtige Lautstärke informiert die Engine, indem entsprechende Callback-Methoden einer zu Instanz entsprechender Listener-Interfaces aufgerufen werden.
Bei der Spracherkennung ist neben der technischen auch die funktionale Anbindung interessant. Um die Navigation durch Geräusche nicht obsolet werden zu lassen, sind Funktionen nicht durch Sprechen ihres Namens auszulösen. Stattdessen
werden Sprachbefehle wie ’links unten’ auf die entsprechenden Koordinaten abgebildet und die dort befindlichen Hearcon-Aktionen ausgelöst.
Benötigte Komponenten sind:
1. IBM ViaVoice, auf dem System installiert,
57
2. IBM Speech for Java: installiert unter AirBrowser/lib
Die durch die mitgelieferte Batch-Datei install.bat (im falschen Verzeichnis)
installierte Datei speech.properties mit dem Inhalt:
com.ibm.speech.recognition.EngineCentral=
com.ibm.speech.recognition.IBMEngineCentral
com.ibm.speech.synthesis.EngineCentral=
com.ibm.speech.synthesis.IBMEngineCentral
muß sich im benutzten Java-SDK-Pfad in /bin, /lib, /lib/ext befinden.
Achtung: Andere im Systempfad installierte javax.speech-Implementationen verhindern die Benutzung (von ibmjs.jar).
Achtung: Im Systempfad „PATH“ muss sich ein Eintrag mit dem „BIN“-Verzeichnis
des installierten ViaVoice befinden.
F.2.3.9
Tastatur
Als weiterer Eingabeweg wird die Tastatur unterstützt. Sie ist besonders für übergeordnete Funktionen (Ende, Eingabegerät umschalten) und für Testzwecke hilfreich.
Hier werden die normalen Funktionen des Java-API verwendet.
Analog zur Mausanbindung enthält die Bibliothek mit den Hook-Funktionen auch
eine solche für Tastaturevents, das heißt, dass auch diese nativ abgefragt und abgefangen werden können. Dies kann verwendet werden, um Meldungen von WindowsSondertasten zu erhalten, die Explorerkomponente weiter einzuschränken oder Tastaturevents zu bekommen, während die Applikation nicht den Eingabefokus hält.
F.2.3.10
Xerces
Xerces wird als XML-Parser benutzt. Xerces stammt vom Apache-Projekt, zu finden
unter http://xml.apache.org. Die benötigten Java-Archive liegen unter
AirWebData/3rdParty\XML\xerces.jar
AirWebData/3rdParty\XML\xercesSamples.jar
vor.
F.2.3.11
JavaCC HTML
Der HTML-Parser wird für die Analyse der selbstdefinierten Attribute im A- und
BODY-Tag benutzt. Die Quelle ist unter
http://www.quiotix.com/downloads/html-parser/
zu finden.
Das benötigte Java-Archiv befindet sich unter
AirWebData/3rdParty/javaCC-HTML/html-parser.jar
58
F.2.3.12
GNU getopt
GNU Getopt wird zum Einlesen der Kommandozeilenparameter benutzt. Erhältlich unter der GPL-Lizenz vom GNU-Projekt unter http://www.gnu.org. Das JavaArchiv liegt unter unter
AirWebData/3rdParty/GNUgetopt/java-getopt-1.0.8.jar
vor.
59

Projektbericht - Universität Oldenburg

Transcription

Documents pareils

Lena Schell-Majoor - For women in science

Misophonie - Psychosoziale Gesundheit

Das Modelabel „BRACHMANN Menswear“

Didaktischer Kommentar

Haben Sie Fragen? Zögern Sie nicht mich anzurufen!

Haben Sie Fragen? Zögern Sie nicht mich anzurufen!

Aufgabenbeispiele zu den Teilen I und II der

Erläuterungen zur Feuerwehr-Dienstvorschrift 7 „Atemschutz“

„HUMAN FACTOR – endless prototyping“ im

Prototyping in industriellen Software- Projekten - Erfahrungen

HESSISCHES KULTUSMINISTERIUM 784

Design Thinking – Kreativität als Methode

DMX-Controller - JB