Medienprojekt - Homepage Fachgebiet Kommunikationsnetze

Transcription

Medienprojekt
BARRIEREFREIER C AMPUS : M OBILE
”
E NDSYSTEME . B ENUTZERSCHNITTSTELLE ZUR
NAVIGATION F ÜR MOBILE E NDGER ÄTE“
Josa Eberle
Ausgabe des Themas: 03. Januar 2003
Abgabe der Arbeit: 02. Januar 2004
Verantwortlicher Hochschullehrer:
Prof. Dr. Jochen Seitz
Hochschulbetreuer:
Dipl.-Ing. Michael Heubach
Fachgebiet Kommunikationsnetze
Institut für Kommunikations- und Messtechnik
Technische Universität Ilmenau
2. Januar 2004
Inhaltsverzeichnis
1
Einleitung
3
2
Problemstellung
5
2.1
Einordnung in das Teamprojekt Barrierefreier Campus . . . . . . . . . .
5
2.2
Aufgabenstellung Teilprojekt 7 . . . . . . . . . . . . . . . . . . . . . . .
5
3
Theoretische Grundlagen
7
3.1
Nutzergruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Einfluss von Situation und Umwelt . . . . . . . . . . . . . . . . . . . . .
10
3.3
Mensch-Maschine-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . .
11
3.4
Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.4.1
Ein- und Ausgabemethoden . . . . . . . . . . . . . . . . . . . .
13
3.4.2
User-Interface-Konzepte . . . . . . . . . . . . . . . . . . . . . .
15
Bestehende Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.5.1
Kommerzielle Navigationssysteme am Markt . . . . . . . . . . .
15
3.5.2
Local Location Assistant (Lol@) . . . . . . . . . . . . . . . . . .
16
3.5.3
Mobility of Blind and elderly People Interacting with Computers
(MoBIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.5.4
Personal Guidance System . . . . . . . . . . . . . . . . . . . . .
17
3.5.5
Lancaster GUIDE . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.5
4
Systementwurf und Vorgehensweise
18
4.1
Nutzungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.2
Zielnutzergruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.3
Gesamtentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.4
Technische Berührungspunkte mit anderen Teilprojekten . . . . . . . . .
19
4.5
Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1
5
Programmentwicklung
23
5.1
Wahl der Programmiersprache . . . . . . . . . . . . . . . . . . . . . . .
23
5.1.1
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.1.2
.NET Compact Framework . . . . . . . . . . . . . . . . . . . . .
24
Design der Nutzerschnittstellen . . . . . . . . . . . . . . . . . . . . . . .
24
5.2.1
Nutzerschnittstelle für Sehende . . . . . . . . . . . . . . . . . .
24
5.2.2
Nutzerschnittstelle für Blinde . . . . . . . . . . . . . . . . . . .
25
5.2.3
Allgemeine und geräteabhängige Teile der Nutzerschnittstelle . .
26
Programmstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.3.1
Funktionsblöcke . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.3.2
Zeitliche Abläufe . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Klassen und Komponenten des Programms auf dem Endgerät . . . . . . .
28
5.4.1
Die Setup-Anwendung . . . . . . . . . . . . . . . . . . . . . . .
28
5.4.2
Die Klasse Spaziergang . . . . . . . . . . . . . . . . . . . . . .
28
5.4.3
Die Klasse Weg . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.4.4
Die Klasse Scrollkarte . . . . . . . . . . . . . . . . . . . . . . .
29
5.4.5
Die Klasse Parser . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Probleme bei der Implementation . . . . . . . . . . . . . . . . . . . . . .
30
5.5.1
Sprachsynthese . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.5.2
Hardware-Tasten und Sound-Ausgabe . . . . . . . . . . . . . . .
30
5.2
5.3
5.4
5.5
6
7
Demonstrationsprogramme
32
6.1
WgsToXY – Ansatz für den Spaziermodus . . . . . . . . . . . . . . . . .
32
6.2
User Interface für Blinde – Demonstrationsprogramm . . . . . . . . . . .
32
6.3
BaFreiCa – eine Demonstrationsversion . . . . . . . . . . . . . . . . . .
32
6.3.1
Simulation der fehlenden Komponenten . . . . . . . . . . . . . .
33
6.3.2
Testszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.3.3
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Ausblick
35
Literaturverzeichnis
37
Abbildungsverzeichnis
40
Tabellenverzeichnis
41
Abkürzungsverzeichnis
42
A Liste der recherchierten Endgeräte
44
2
Kapitel 1
Einleitung
Nichts über uns und nichts ohne uns“ – mit diesem Motto hat der Rat der Europäischen
”
Union das Jahr 2003 zum Jahr der Menschen mit Behinderung ausgerufen. Ziel ist ein
Loslösen von Diskriminierung und Bevormundung hin zu Teilhabe und Selbstbestimmung von Menschen mit Behinderungen. Die Lebensbedingungen mit und für behinderte
Menschen anders zu gestalten, ist eine große gesellschaftliche Herausforderung. Dies betrifft alle Lebensbereiche wie Arbeit, Wohnen, Bildung oder Freizeit. Ausgrenzung und
Diskriminierung hinsichtlich der Techniknutzung bilden dabei einen eigenen Bereich.
Das hohe Maß an Technisierung in unserer Industriegesellschaft bereitet vielen Menschen Probleme. So ist die Bedienung von vielen Geräten im Alltag nicht einfach. Oft
stehen technische Funktionen und nicht der Fokus auf künftige Nutzer bei der Entwicklung im Vordergrund, selten werden Menschen mit Behinderungen als Nutzer bedacht. So
bestehen für sie besondere hohe Nutzungsbarrieren bezüglich Nutzerschnittstellen und
Technik. Menschen mit Behinderung sind oft sogar von der Nutzung bestimmter Systeme
ganz ausgeschlossen. So können beispielsweise Geldautomaten von einem Großteil der
Bevölkerung ohne Probleme genutzt werden, für Rollstuhlfahrer oder blinde Menschen
sind sie jedoch an vielen Orten nicht erreichbar beziehungsweise nicht bedienbar.
Der gezielte Einsatz von Technik kann für Menschen mit Behinderungen jedoch auch positive Effekte bewirken. Die Nutzung von Technik kann dazu dienen, Einschränkungen
durch eine Behinderung zu mildern oder im Idealfall ganz zu kompensieren. Eine
technische Hilfe kann dann als Prothese bezeichnet werden, die Einschränkungen aufhebt [Edw95, S. 22]. Viele Geräte erleichtern so das Leben von Menschen mit Behinderungen in großem Maße, und ermöglichen ein Stück Freiheit: So gibt es zum Beispiel
Sprach-Computer, die über Symbole bedient werden,die auf einem Tastenfeld angeordnet
sind. Solche Sprach-Computer erzeugen zuvor aufgenommene oder synthetisierte Sprache. Für einen Menschen mit einer tonischen Spastik, der zwar seine Mitmenschen versteht, sich aber nicht artikulieren kann, ermöglicht diese Technik die Kommunikation mit
seiner Umwelt. Der pedalfreie PKW hebt während des Autofahrens die Einschränkungen
einer Beinlähmung auf. Weitere Beispiele für technische Hilfen sind Anpassungen an
Standard-Nutzerschnittstellen wie Screen-Reader, die Bildschirminhalte vorlesen, oder
spezielle Joysticks, die als Mausersatz zum Beispiel mit der Zunge gesteuert werden
können. Sie sind speziell auf die verschiedenen, individuellen Bedürfnisse der Nutzer
zugeschnitten.
Solche positiven Effekte durch Technikeinsatz sind gerade auch im Urlaubs- oder im
Freizeitbereich wünschenswert. Die Freizeitgestaltung hat besonders auch für behin-
3
derte Menschen einen hohen Stellenwert. Sie dient der Selbstfindung, der kreativen
Persönlichkeitsentfaltung und der sozialen Integration [Akt03]. Freizeit und Freiheit
gehören eng zusammen. Freizeit als Freiheit von Alltagszwängen und Leistungsdruck
sollte deshalb selbstbestimmt erlebt werden können. Gerade im Freizeitbereich ist es deshalb wichtig, dass Zugangsbarrieren für Menschen mit Behinderungen abgebaut werden.
Das gilt zum Beispiel für Besichtigung von Sehenswürdigkeiten, für das selbständige Erkunden einer neuen Umgebung ohne Begleitung oder das Erreichen von Wegzielen ohne
Umwege. In einer individualistischen Gesellschaft wie der unseren ist Mobilität für alle
Menschen ein hohes Gut.
Diese Mobilität wird unterstützt durch kleine elektronische Helfer, die unseren Alltag erobern. Für viele Menschen ist das Mobiltelefon ein steter Begleiter geworden. Viele vertrauen ihre Termine und Aufgaben elektronischen Organizern oder Personal Digital Assistants an. Mit zunehmender Vernetzung und steigender Leistungsfähigkeit dieser Geräte
beginnen neue Anwendungen und Dienste wie lokationsabhängige Dienste zu entstehen.
Sie bieten dem Nutzer gezielt Informationen und Dienste an, die abhängig vom Aufenthaltsort des Nutzers sind.
Für Menschen mit Behinderungen können solche Systeme der Schlüssel sein, ihre Freizeit selbständig und selbstbestimmt zu erleben. Dazu ist es notwendig, dass diese lokationsabhängigen Dienste auf die Bedürfnisse der Nutzer individuell abgestimmte Inhalte
anbieten und dass die Nutzerschnittstellen barrierefrei gestaltet werden. Barrierefreiheit
verlangt dabei die Erfüllung zweier zunächst gegensätzlich erscheinender Anforderungen:
Erstens eine Lösung für alle“ und zweitens gleichzeitig individuelle Lösungen für jeden
”
”
einzelnen“. Technische Systeme dieser Art sollen also so konzipiert sein, dass Menschen
mit den unterschiedlichsten Voraussetzungen potentielle Nutzer sein können. Diese Konzepte integrieren individuelle Bedürfnisse behinderter Menschen in Alltagstechnik, das
heisst barrierefreie Systeme stehen für Integration.
Das Medienprojekt Barrierefreier Campus ist der Versuch einen Schritt in die aufgezeigte
Richtung zu gehen. Der Campus der Technischen Universität Ilmenau bietet das Versuchsfeld für ein elektronisches Assistenzsystem, das Menschen das Zurechtfinden in einer unbekannten Umgebung erleichtern soll.
4
Kapitel 2
Problemstellung
Ziel des Teamprojekts Barrierefreier Campus ist die prototypische Konzeption und Implementierung eines Assistenzsystems für Besucher des Campus der Technischen Universität
Ilmenau. Basierend auf einer Client-Server-Architektur bietet es dem Nutzer lokationsabhängige Dienste, wie Wegsuche und Informationsdienste zu Details von Wegstrecke
und Gebäuden, auf einem mobilen Endgerät an. Teilprojekt 7 beschäftigt sich dabei mit
der Implementierung der Nutzerschnittstelle. Besonderes Augenmerk bei der Konzeption
gilt der Barrierefreiheit, also der möglichst vollständigen Vermeidung von Zugangsbarrieren für Menschen mit Behinderungen, sowie der Wiederverwendbarkeit des Systems
in einem erweiterten Kontext als touristisches Assistenzsystem für die gesamte Region
Thüringer Wald.
2.1
Einordnung in das Teamprojekt Barrierefreier Campus
Das Teamprojekt Barrierefreier Campus gliedert sich in acht Teilprojekte, die jeweils einem Bearbeiter zugeordnet sind. Diese Teilprojekte decken die gesamte Infrastruktur von
der Lokalisierung über die Nutzerprofile und Wegdatenerstellung bis zur Anpassung für
die Endgeräte und schließlich der Präsentation der Daten auf einem mobilen Endgerät ab.
Letzteres ist Aufgabe des Teilprojekts 7, Programm auf dem Endgerät, dessen Hauptbestandteil die Konzeption und Implementation der Nutzerschnittstelle für das Gesamtprojekt ist. Abbildung 2.1 zeigt eine Übersicht aller Teilprojekte sowie deren Themengebiete.
2.2
Aufgabenstellung Teilprojekt 7
Im Teilprojekt 7 soll eine Nutzerschnittstelle für mobile Endgeräte spezifiziert und prototypisch implementiert werden, die es erlaubt, auf angepasste Navigationsinformationen
zuzugreifen. Im Detail umfasst das Teilprojekt 7 folgende Arbeitspunkte:
• Evaluierung und Klassifizierung von Endgeräten,
• Konzipierung einer modularen Nutzerschnittstelle:
5
– zum Abfragen einer Navigationshilfe gemäß festgelegter Optionen unter Zuhilfenahme verschiedener Möglichkeiten zur Lokalisierung,
– zur Darstellung der von der Datenbank / dem Anpassungsmodul kommenden
Navigationsinformationen,
• Aufteilung der Nutzerschnittstelle
geräteabhängigen Teil,
in
einen
allgemeinen
und
einen
• Implementierung des Konzepts auf einem beliebigen tragbaren Endgerät.
Theoretische Grundlagen zu Nutzerschnittstellen werden in Kapitel 3 behandelt. Die Evaluierung und Klassifizierung möglicher Endgeräte wird zusammen mit Systementwurf
und Nutzungsszenarien sowie der Konzipierung der modularen Nutzerschnittstelle und
deren Aufteilung in allgemeine und geräteabhängige Teile in Kaptitel 4 behandelt. Eine Tabelle der evaluierten Endgeräte ist in Anhang A angefertigt. Kapitel 5 beschreibt
die Implementierung der Nutzerschnittstelle und das Programm auf dem Endgerät sowie
dessen Leistungsmerkmale. In Kapitel 6 werden die Ergebnisse der Programmierarbeit
vorgestellt. Quelltext, compilierte Versionen des Programms sowie weitere Materialien
finden sich auf der beigelegten CD-ROM.
Abbildung 2.1: Übersicht über die einzelnen Themen des Teamprojekts Barrierefreier
Campus. Quelle: eigene Abbildung
6
Kapitel 3
Theoretische Grundlagen
Hauptaufgabe des Teilprojekts ist die Konzeption einer Nutzerschnittstelle zum Assistenzsystem Barrierefreier Campus. In diesem Kapitel soll nun die Interaktion zwischen
Mensch und Technologie näher beleuchtet werden. Eine genaue Auseinandersetzung mit
den Nutzergruppen, die nähere Betrachtung der Technologie sowie des Kontexts der Interaktion geben Anhaltspunkte für das Design des Programms auf dem Endgerät. Die
untenstehende Abbildung 3.1 zeigt das grundlegende Modell einer Mensch-MaschineKommunikation. Ein Mensch hat über die Nutzerschnittstelle Zugriff auf eine bestimmte
Technik. Oder anders gesagt: Diese Technik bietet dem Nutzer Dienste über das User
Interface an. Störender Faktor in dem Modell ist der Einfluss der Umwelt oder der Umgebung, in der die Interaktion zwischen Mensch und Maschine stattfindet.
Abbildung 3.1: Modell einer Mensch-Maschine-Schnittstelle. Quelle: eigene Abbildung
Gutes Nutzerschnittstellen-Design setzt eine möglichst genaue Kenntnis der Nutzergruppen, der zur Verfügung stehenden Technik sowie der Situation oder der Umwelt, in der
die Techniknutzung stattfindet, voraus. In Abschnitt 3.1 soll daher die Frage geklärt werden, in wie weit die Nutzergruppe aus Designersicht definiert werden kann und welche
Fähigkeiten sowie Einschränkungen auf Nutzerseite zu beachten sind. Welche besonderen Voraussetzungen sich vor allem bei mobilem Technikeinsatz sowie der gleichzeitigen
7
Ausführung mehrerer Aufgaben ergeben, soll Abschnitt 3.2 beleuchten. Abschnitt 3.3
beschäftigt sich mit der Nutzerschnittstelle selbst vor allem unter der Voraussetzung einer
sehr heterogene Nutzergruppe. Ein- und Ausgabetechniken für mobile Endgeräte sowie
Nutzerschnittstellenkonzepte werden kurz im Abschnitt 3.4 vorgestellt. Schließlich sollen im Abschnitt 3.5 bestehende Systeme vorgestellt werden, die zum einen lokationsabhängige Dienste für den Tourismus und zum anderen Navigationshilfen für behinderte
Personen anbieten.
3.1
Nutzergruppe
Bei der Softwareentwicklung wird meist von einer sehr homogenen Nutzergruppe ausgegangen. Der Nutzer“ ist für viele Programmierer eine gewöhnliche Person mit durch”
schnittlichen Fähigkeiten. Diese realitätsferne Annahme lässt sich sehr gut mit dem fiktiven Schuhgeschäft ’Software-Schuh’ veranschaulichen. Hier gibt es zwar Schuhe in
vielen Modellen und Farben zu kaufen, allerdings sind sie ausnahmslos auf den durchschnittlichen Fuß, Größe 42, zugeschnitten. Viele Entwickler von Nutzerschnittstellen
haben zudem sich selbst als den idealtypischen Nutzer im Kopf. Ihr Wissen und ihre eigene Kompetenz im Umgang mit Software verstellen ihnen den Blick auf die eigentlichen
Bedürfnisse der Nutzer. Ergebnis eines solchen Designs ist nicht selten eine Software,
von der man den Eindruck hat, dass sie für den 25-jährigen männlichen Computerexperten geschrieben wurde. Eine willkürliche, ungenaue Unterteilung in Anfänger“- und
”
Experten“-Modi hilft dem Nutzer in einem solchen Fall meist auch nicht weiter.
”
Im Gegensatz dazu können Entwickler eines Systems, welches sich, wie auch das Medienprojekt Barrierefreier Campus, explizit an Personen mit Behinderungen richtet, so
stark auf die besonderen Eigenschaften und Bedürfnisse ihrer Zielgruppe fokussiert sein,
dass Designgrundsätze oder grundlegende Ästhetik missachtet werden und die Zielgruppe dadurch weiter stigmatisiert wird. So gibt es etwa genügend speziell für behinderte
Menschen entwickelte Haushaltsgeräte, die so hässlich sind, dass man sie eigentlich nicht
in einer Wohnumgebung platzieren will [New95, S. 7]. Nutzer des Barrierefreien Campus
sollten deshalb weder durch die Bedienung des User Interfaces noch durch auffällige Platzierung von technischem Gerät aus der Gruppe der Besucher des Campus herausstechen.
Um Denkanstöße für die Auseinandersetzung mit dem Thema Behinderung zu geben, will
ich im Folgenden vier Thesen nach Alan F. Newell vorstellen [New95, S. 7–10]:
1. Jeder Mensch hat gewöhnliche Fähigkeiten und außergewöhnliche
Fähigkeiten ( everyone has ordinary and extra-ordinary abilities“)
”
Ein grundlegendes Missverständnis bei der Diskussion über Nutzergruppen ist die
rein binäre Aufteilung in die Gruppen Behinderte und Nichtbehinderte. Plakative
Darstellungen unterstützen dies, wie zum Beispiel das Piktogramm, das einen Rollstuhlfahrer zeigt, und allgemein Menschen mit Behinderung meint. Dieser Denkfehler wird einem sofort klar, wenn man eine vermeintlich gut zu definierende Gruppe genauer betrachtet. Die Gemeinsamkeit aller Rollstuhlfahrer ist, dass sie den
Rollstuhl als Prothese für eine Bewegungseinschränkung verwenden. Dennoch sind
die Unterschiede innerhalb dieser Gruppe groß. Die Fähigkeit, auf einem schmalen Weg umzukehren, wird schon von der Bauform des Rollstuhls vorgegeben, da
diese den Wendekreis bestimmt. Während die einen selbst hohe Stufen meistern
8
können, bleibt für andere eine abgesenkte Bordsteinkante eine unüberwindbare Barriere. Zudem hat die Gruppe der Rollstuhlfahrer eine ebenso große Bandbreite an
physikalischen, sensorischen und kognitiven Fähigkeiten wie andere Gruppen auch.
Wenn man also genau hinschaut, hat jeder Mensch eine Reihe von Fähigkeiten, die
als normal“ gelten und andere, die offensichtlich von der Norm abweichen. So ha”
ben große Teile der Gesellschaft eine Sehschwäche, viele, vor allem alte Menschen,
sind schwerhörig und einige sind physisch schwächer als andere. Jeder einzelne
Mensch hat unterschiedliche kognitive Fähigkeiten sowie verschiedene kulturelle,
politische und religiöse Ansichten.
2. Außergewöhnliche Bedürfnisse sind nur verstärkte gewöhnliche Bedürfnisse
( Extra-ordinary needs are only exaggerated ordinary needs“)
”
In den meisten Fällen unterscheiden sich von der Norm abweichende Bedürfnisse
und Fähigkeiten nicht in ihrer Qualität, sondern vielmehr in der Quantität. So bedeutet ein Tremor nicht, dass der Mensch überhaupt keine motorische Kontrolle
über seine Gliedmaßen hat, sondern eben weniger. Menschen, die eine Lernbehinderung haben, können sich eventuell schlecht Daten, Namen und Dinge merken –
Symptome, die gleichwohl auch bei durchschnittlich befähigten Personen in einer
abgeschwächten Form unter Stress auftreten können.
3. Personen werden durch ihre Umwelt eingeschränkt ( People are handicapped
”
by their environments“)
Die Fähigkeiten des Menschen sind nicht statischer Natur. Sie verändern sich über
die Zeit und hängen stark von den Einflüssen unserer Umgebung ab. So ist Behinderung nicht als Abwesenheit von Fähigkeiten zu sehen, sondern kann als Umwelteinfluss auf den Menschen interpretiert werden. Umgebungslärm kann zum
Beispiel wie Schwerhörigkeit wirken und temporäre Taubheit nach sich ziehen.
Schlechte Sicht, verursacht durch Nebel oder Staub, kann als Sehbehinderung interpretiert werden. Unbefestigter Untergrund wird im wahrsten Sinne des Wortes
zur Gehbehinderung. Extreme Temperaturen oder die Verwendung von Sicherheitsanzügen mit Handschuhen führen zu taktiler und motorischer Unsicherheit; Stress
oder Übermüdung können zur Verringerung der kognitiven Fähigkeiten führen. Ein
extremes Beispiel für Behinderungen bedingt durch die Situation und Umwelt ist
ein Soldat auf dem Schlachtfeld (Abbildung 3.2). Er sieht kaum etwas, weil ihm der
Rauch in den Augen brennt, er ist vom Lärm der Geschütze betäubt, steckt bis zu
den Knien im Schlamm und ist vor Todesangst fast gelähmt.
4. Begrenzte Bandbreite ( Bandwidth Limitations“)
”
Der effiziente Umgang mit beispielsweise einem Textverarbeitungsprogramm setzt
eine gewisse Anschlagsgeschwindigkeit für die Texteingabe voraus. Diese kann,
bedingt durch eine Einschränkung des Nutzers, sehr langsam sein. Die Bandbreite, in diesem Kontext die Menge an Information, die der Nutzers über die Tastatur übermitteln kann, reicht für eine sinnvolle Bedienung des Textverarbeitungsprogramms nicht aus. Kommt eventuell noch eine Sehbehinderung hinzu, so dass
die Zeichen auf dem Monitor sehr groß dargestellt werden müssen, verringert sich
zudem die Bandbreite der Zeichenausgabe. Auch hier kann zur Verdeutlichung
als Beispiel eine Extremsituation gefunden werden. Die visuelle Bandbreite eines
Kampfjet-Piloten mag im Luftkampf nicht ausreichen, sich gleichzeitig auf alle Instrumente, das Flugmanöver, sämtliche gegnerische Flugzeuge und eventuell noch
9
Abbildung 3.2: Behinderung durch die Umwelt. Ein Soldat in der Schlacht. Quelle:
[New95, S. 9]
ankommende Raketen zu konzentrieren. Um auf alle Ereignisse zu reagieren hat er
wahrscheinlich zudem ’nicht genügend Hände’ .In solchen high workload envi”
ronments“ können zusätzliche taktile und auditive Interfaces die Last des visuellen
Kanal zu verringern.
Diese Betrachtungen geben Einblicke in den Umgang mit dem sensiblen Thema Behinderung und bieten Ansatzpunkte für das Nutzerschnittstellen-Design. Die behindertengerechte Gestaltung von User Interfaces ist nicht als Konzentration auf einzelne spezielle
Nutzergruppen zu sehen; das Augenmerk liegt vielmehr auf dem Abbau von technischen
Barrieren, wovon nicht nur der einzelne, sondern alle Nutzer profitieren.
3.2
Einfluss von Situation und Umwelt
Mensch-Maschine-Kommunikation findet immer in einem bestimmten Kontext statt. Dieser ist durch unterschiedlichste soziale und kulturelle Faktoren, aber auch durch die aktuelle Situation und den Umwelteinfluss, bestimmt. Diese Faktoren haben kleinere und
größere Auswirkungen auf die Qualität der Interaktion. Wenn man einen Bildschirmarbeitsplatz betrachtet, ist der störende Einfluss der Umwelt gering. Der Nutzer sitzt in optimaler Position vor Tastatur und Monitor, hat es meist warm und ist durch ein Gebäude
vor Wettereinflüssen geschützt. Die bekannte Umgebung vermittelt Sicherheit. Der Nutzer
kann so dem User Interface seine ungeteilte Aufmerksamkeit widmen.
Verlagert man diese Situation nach draußen und stellt sich anstatt eines Desktoparbeitsplatzes ein mobiles Gerät vor, kann man sich leicht Faktoren denken, die die MenschMaschine-Interaktion stören. Helles Sonnenlicht macht das Display schwer ablesbar, Umgebungslärm übertönt eine Sprachausgabe, oder der Nutzer wird angerempelt und die Dateneingabe über einen Touch Screen misslingt. In einem solchen mobilen Umfeld kann
10
einem technischen Gerät immer nur ein Teil der Aufmerksamkeit zukommen, da der Nutzer zwei Aufgaben simultan erledigen muss, beispielsweise die Bedienung des Geräts
einerseits und das Gehen auf einem Weg andererseits. Das stellt einen Menschen, der
von vorn herein eine geringe Bandbreite bei der Interaktion mit seiner Umwelt hat, vor
große Probleme. E. Starner [Sta02, S. 88] bemerkt dazu, dass mobile Nutzerschnittstellen
deshalb so entwickelt werden sollten, dass sie die normalen menschlichen Fähigkeiten
ergänzen und nicht mit ihnen interferieren. Die Tätigkeit des Menschen sollte von dem
mobilen Gerät unterstützt werden. Nach Rekimoto [Rek01, S. 354] ist der Fokus des Nutzers nicht die Mensch-Computer-Interaktion, sondern die Interaktion mit der realen Welt.
Er will sich nicht mit mühsamen Computeroperationen herumschlagen müssen, wenn ein
real world task“ ausgeführt wird. Letztendlich sollte der Aufwand, ein zusätzliches Gerät
”
zu bedienen, so gering sein, dass der zusätzliche Nutzen durch dieses klar überwiegt.
Ein Beispiel für das gleichzeitige Ausführen von verschiedenen Aufgaben ist das Autofahren [PE03]. Man kann beobachten, dass die Fahrer sich ohne Probleme mit ihren
Beifahrern unterhalten oder sich auf das Radio konzentrieren. Zwei Effekte ermöglichen
dies: Zum einen ist Autofahren eine höchst visuelle Angelegenheit, die zwar gleichzeitig
auditive Kommunikation zulässt, nicht aber weitere visuelle Tätigkeiten, wie zum Beispiel gleichzeitiges Fernsehen. Zum anderen hat der Fahrer die nötigen Handgriffe zur
Steuerung des Autos schon so oft ausgeführt, dass sie automatisiert sind und keiner besonderen Aufmerksamkeit mehr bedürfen. Das Problem der geteilten Aufmerksamkeit
für eine Nutzerschnittstelle kann also erstens durch die Beanspruchung unterschiedlicher
Sinne und zweitens durch das Erlernen der Schnittstelle gemildert werden. Nach [Sta02,
S. 89] kann man diesen Lernprozess auch bei der Benutzung der QWERTZ-Tastatur oder
der Graffiti-Zeichenerkennung bei Palm PDAs beobachten. Die Nutzer nehmen den Aufwand zum Erlernen des Interfaces in Kauf und können mit etwas Übung Texte eingeben,
ohne über einzelne Strichfolgen oder Tastenanschläge nachzudenken.
Beim Barrierefreien Campus handelt es sich um ein Assistenzsystem für den Tourismus.
Die Nutzer wollen ihr Reiseziel kennen lernen und die Umgebung erkunden. Das Gerät
sollte daher ein leicht erlernbares Interface haben, das unerfahrene Nutzer und Nutzer mit
Einschränkungen nicht überfordert. Im Idealfall steht es unterstützend zur Seite, wenn
dies gewünscht ist.
3.3
Mensch-Maschine-Schnittstelle
Nutzerschnittstellen bieten den Menschen die Möglichkeit, mit technischen Systemen in
Interaktion zu treten. Sie sind das Gesicht“ der Technik nach außen und tragen in großem
”
Maße zur Nutzerzufriedenheit bei. Ihre Bedeutung wird offensichtlich, wenn man sich
vorstellt, dass die beste Technik schwieriger beherrschbar oder gar vollkommen unnütz
wird, wenn das User Interface schlecht ist. Allerdings bieten Nutzerschnittstellen häufig
nur proprietäre Ein- und Ausgabemöglichkeiten und sind nicht sehr flexibel oder an spezielle Bedürfnisse anpassbar. Den meisten Mensch-Maschine-Schnittstellen ist zu Eigen,
dass für ihre effiziente Benutzung zunächst ein Lernprozess durchschritten werden muss.
Um diesen Prozess abzukürzen sind viele Nutzerschnittstellen an Metaphern angelehnt,
die als dem Nutzer bekannt angenommen werden. Verdeutlichen lässt sich das ganze
an folgendem Beispiel: Um Microsoft Windows zu beenden, muss man paradoxerweise zunächst den Start“-Knopf drücken. Betrachtet man hingegen den in der Linux-Welt
”
beliebten Fenstermanager KDE, so findet man den gleichen, unlogischen Mechanismus,
11
Abbildung 3.3: Anpassung von Nutzerschnittstellen an spezielle Bedürfnisse, Quelle:
nach [Edw95, S. 22–25].
12
weil dessen Designer annehmen können, dass die meisten Nutzer diese Vorgehensweise
gelernt haben. KDE folgt also einer Windows-Metapher.
Ist das Erlernen einer neuen Mensch-Maschine-Schnittstelle im Allgemeinen schon nicht
einfach, kann es für Menschen, die eine Behinderung haben, sehr schwierig oder gar wegen nicht überwindbarer Barrieren unmöglich sein. So brachte die Einführung von grafischen Nutzeroberflächen bei Personal Computern Anfang der 90er Jahre vielen Nutzern
Vorteile, für blinde Menschen hingegen verschlechterte und erschwerte sich der Zugang
zu moderner Computertechnologie. Ähnliche Tendenzen sind derzeit im World Wide Web
zu beobachten. Immer häufiger verstecken“ sich wichtige Navigationselemente in un”
kommentierten Grafiken, verschachtelten Frames oder Flash-Animationen und sind so
für viele Menschen nicht benutzbar. Durch Standardisierung und Einfügen von Metadaten kann hier Abhilfe geschaffen werden. Hinweise und Richtlinien zur barrierefreien
Gestaltung von Webseiten kann man beispielsweise unter [WAI03] oder [WoB03] finden.
Von einer Standardisierung der Nutzerschnittstellen profitieren vor allem Menschen, die
technische Hilfen benutzen. Screen Reader oder Braillezeilen und Bildschirmtastaturen
sind Prothesen, um die Einschränkungen einer Behinderung zu mildern und gewöhnliche
Schnittstellen für den Nutzer anzupassen“. Diesen Sachverhalt verdeutlichen die Grafi”
ken in Abbildung 3.3.
Ist eine adäquate Anpassung der Nutzerschnittstelle an den Nutzer durch ein technisches Hilfsmittel erst einmal erreicht, sollte diese Anpassung dann für eine ganze Reihe von Computeranwendungen wiederverwendet werden, um unnötige Duplikation bei
der Programmierung zu vermeiden. Allerdings sind solche technischen NutzerinterfaceAnpassungen in der mobilen Anwendung oft nicht verwendbar, da sie schwer und unhandlich sind. Bei Softwareanpassungen ist die Rechenleistung eines mobilen Endgeräts
eventuell zu gering oder der Ressourcenverbrauch steigt. In diesem Bereich muss deshalb bei der Entwicklung eines möglichst barrierefreien Interfaces besonders behutsam
vorgegangen werden. Der Designer sollte sich fragen: Welche Fähigkeiten hat der Nutzer? Welche Einschränkungen gilt es zu beachten? Wie ist die Situation beschaffen, in der
die Interaktion stattfindet? Welche Umweltfaktoren beeinflussen die Mensch-MaschineKommunikation? Und: Welche Maßgaben macht die Technologie? Welche Schnittstellen
hat das Endgerät?
3.4
Technologien
In diesem Abschnitt über Technologien soll primär mobile Technik behandelt werden. Unter der Überschrift Technologien könnte man viele Teilthemen, wie Netzwerke, Miniaturisierung von mobilen Endgeräten oder Sensoren, die mobilen Anwendungen Kontextinformationen zu ihrer Umwelt liefern, diskutieren. Hier sollen jedoch die für die Konzeption
von Benutzerschnittstellen wichtigen hard- und softwareseitigen Interface-Technologien
im Mittelpunkt stehen.
3.4.1
Ein- und Ausgabemethoden
Nur schwer kann man sich gedanklich von der bekannten Tastatur/Maus/DisplayMetapher lösen. Viele mobile Systeme arbeiten folglich mit verkleinerten Zeigeinstru-
13
menten und Mini-Tastaturen, anstatt natürlichere Formen der Kommunikation wie Sprache oder Gestik zu verwenden. Einige solcher alternativen Ein- und Ausgabemethoden
sollen im Folgenden vorgestellt werden.
Haptik
Mit der Einführung eines Wireless Personal Area Network (WPAN), das verschiedene
Komponenten über ein drahtloses Ad hoc-Netzwerk zusammenschließt, kann die Bedeutung von Elementen des Systems durch ihre Form kommuniziert werden. Fishkin [Fis02,
S. 52] bezeichnet diese Elemente als Phicons“ (physical icons). Als Beispiel könnte man
”
einem solchen WPAN ein Phicon in der Form eines geschlossenen Vorhängeschlosses
hinzufügen und damit eine verschlüsselte Datenübertragung veranlassen.
Gestik
Der Zeichenvorrat an Gesten ist ein sehr natürliches, häufiges verwendetes Vokabular
zwischenmenschlicher Kommunikation. Für die Entwicklung von natürlichen MenschMaschine-Schnittstellen, wie zum Beispiel humanoider Roboter, wird deshalb an guten
Algorithmen zur Gestenerkennung gearbeitet. Ausgestattet mit Kamerasystemen extrahieren sie Befehle und Kontext aus der Bildinformation. Ein Beispiel für eine Anwendung ist ein elektrischer Rollstuhl, der die Richtungsinformation aus der Kopfbewegung
des Nutzers zieht [Kun99].
Neben kamerabasierten Systemen wird Gestik auch bei Geräten mit Touch Screen verwendet. Hier werden mit dem Stift kreierte Gesten [Lon99] zur Steuereung des Geräts.
Im Vergleich zur Handschrifterkennung eines ganzen Wortes sind Gesten schneller, da sie
aus einem Zeichen bestehen. Der Nutzer kann sie sich leicht merken.
Head Mounted Display
Bei der Nutzung eines mobilen Geräts in einem mobilen Umfeld besteht das Problem,
dass der Nutzer, um mit dem Gerät in Interaktion zu treten, oft das Display fokussieren
muss. Bei einem Head Mounted Display wird, wie der Name schon sagt, das Display am
Kopf befestigt, so dass es sich immer im Blickfeld des Trägers befindet. Der Bildschirminhalt erscheint für den Nutzer so als eine Projektion in gewissem Abstand zum Auge. Oft
ist diese Art der Anzeige zudem halbtransparent, sodass die Umgebung immer noch wahrgenommen werden kann. Allerdings haben Tests gezeigt, dass das Tragen eines solchen
Displays zum Teil als unangenehm empfunden wird [Bab98, S. 320].
Sprache
Die Verwendung von Sprache als Interaktionsmedium bei der mobilen Computernutzung ist vorteilhaft, da sie Handfreiheit gewährt und den visuellen Kanal des Nutzers
nicht beeinflusst. Findet man bereits heutzutage viele Beispiele für Sprachschnittstellen
in Telefonie-Anwendungen und bei Workstations, ermöglichen bessere Algorithmen für
die Sprachsynthese und Spracherkennung in Verbindung mit steigender Rechenleistung
in Zukunft dialogbasierte Benutzerschnittstellen auf mobilen Geräten [Ovi01, S. 422].
14
Nach Pitt [PE03] profitieren Sprachinterfaces von der zusätzlichen Verwendung von
Tönen und Geräuschen, den sogenannten Auditory Icons“ oder Earcons“. Diese sind
”
”
Geräuschen der Wirklichkeit nachempfunden oder bestehen aus Tonfolgen, die der Nutzer als Meldung für ein Ereignis oder einen Zustand erkennt.
3.4.2
User-Interface-Konzepte
Direct Combination“ Interfaces
”
Wie von Holland [HO99] beschrieben, ist das Prinzip der direkten Kombination von Objekten eine Erweiterung der direkten Manipulation. Der bekannte Mechanismus zur Manipulation von Objekten auf dem Bildschirm ist ein Klick mit der rechten Maustaste und
nachfolgender Auswahl aus einem Kontextmenü. Dieses Prinzip wird auf Objektpaare
ausgeweitet. Der Nutzer bekommt bei der Auswahl zweier Objekte die Schnittmenge
an möglichen Operationen, die mit den beiden Elementen durchgeführt werden können.
Die Anwendung von Direct Combination“ in einem mobilen Kontext beschreibt Hol”
land [Hol03] zudem in mehreren Szenarien, in denen zum Beispiel Personen und Räume
eines fiktiven Büros in die Interaktion eingeschlossen werden.
Agenten
Nach Lieberman [Lie97] ist ein Agent ein Programm, das vom Nutzer als Assistent oder
Helfer angesehen werden kann. So ist ein Agent nicht einfach ein Werkzeug, sondern
handelt autonom, ist adaptiv und lernfähig. Er kommuniziert mit dem Anwender und mit
anderen Agenten. Für den Nutzer ergeben sich daraus Vorteile, da er Aufgaben delegieren kann, und sich damit nicht mehr um sie kümmern muss. Besonders im mobilen Einsatz könnte ein Agent die persönlichen Vorlieben des Nutzers sowie zusätzliche KontextSensoren verknüpfen und so auf die Situation und Örtlichkeit angepasste Informationen
anbieten. Agenten können vollständig, vom Nutzer kaum bemerkt, im Hintergrund arbeiten, oder direkt mit ihm interagieren.
3.5
Bestehende Systeme
Im Folgenden möchte ich beispielhaft bereits bestehende Navigationssysteme und Forschungsprojekte im Bereich Navigationhilfen für behinderte Personen und Assistenzsysteme für Touristen vorstellen. Diese Zusammenstellung, die bei weitem nicht als umfassend angesehen werden kann, soll den Theorieteil ergänzen.
3.5.1
Kommerzielle Navigationssysteme am Markt
Neben professionellen Navigationssystemen, die ihren Einsatz in Luftverkehr, Schifffahrt
oder Logistik finden, sind die wohl populärsten und bekanntesten Navigationssysteme im
Automobilbereich anzutreffen. Sie sind mittlerweile bei fast allen Herstellern als Festeinbauten zumindest in der Sonderausstattung enthalten und haben sich im allgemeinem Gebrauch etabliert. Technikseitig kommen Navigationssysteme im KFZ-Bereich meist ohne Netzanbindung aus, die Routenberechnung findet ’on board’ auf dem mobilen Gerät
15
statt; das dafür erforderliche Kartenmaterial befindet sich im internen Speicher. Zur Positionsbestimmung wird das satellitengestützte Global Positioning System (GPS) verwendet.
Eine ganze Reihe von weiteren Sensoren für Geschwindigkeit, Fahrtrichtung und Lenkbewegung machen die Navigation erstens sehr genau und zweitens auch in Abschattungsbereichen möglich. Derlei Systeme haben meist eine grafische Oberfläche und nutzen zudem
während der Fahrt eine Sprachausgabe für Fahranweisungen.
Als Konkurrenz zu den fest eingebauten Navigationssystemen bildet sich in letzter Zeit
zunehmend die Riege der PDA basierten Navigationssysteme heraus [Chr03]. Ähnlich
aufgebaut wie reine KFZ-Systeme verzichten sie jedoch auf Sensordaten aus der Fahrzeugelektronik und sind daher auch außerhalb des Fahrzeugs einsetzbar. Ein System, das
im Gegenteil zu allen anderen PDA-Lösungen mit Off-Board-Navigation arbeitet, ist TD1 NaviGate [Nav03]. Basierend auf Mobile Digital Assistants (MDA), das heißt Pocket
PC Systemen mit Telefonieerweiterungen, wird mittels General Packet Radio Service
(GPRS) die mit GPS ermittelte aktuelle Position sowie die Zieladresse an eine Telematikzentrale übermittelt, die dann den Weg berechnet und Wegdaten zurückschickt.
Eine recht neue Entwicklung ist das Bemühen vieler Mobilfunknetzbetreiber, ihren Kunden lokationsabhängige Dienste anzubieten [Epl03, Vod03]. Meist arbeiten diese mit
einer Positionsbestimmung über die Mobilfunknetze selbst. Eine erste Ausnahme bildet das TD1 NaviGate Blue Kit, ein smartphone-basiertes System, welches einen GPSEmpfänger mittels des Kurzstreckenfunks Bluetooth an ein Symbian OS Mobiltelefon
anbindet, und somit auch genauere Positionsbestimmung ermöglicht.
3.5.2
Local Location Assistant (Lol@)
Der Local Location Assistant [Pop02] ist der Prototyp eines elektronischen TouristenGuides für die Stadt Wien. Basierend auf clientseitigen Java Applets realisiert er geführte
Stadtrundgänge und bietet Informationen zu Sehenswürdigkeiten sowie eine Kartenanzeige der Umgebung an. Als Interaktionsmechanismen sind grafikbasierte Kommunikation
sowie Sprachsteuerung vorgesehen. Routenplanung und History-Funktionen sind mit erweiterter Informationsbasis vor und nach einer Besichtigungstour möglich. Abgesehen
vom User Interface und der Positionsbestimmung mittels GPS ist die gesamte Programmlogik, wie Routing, Spracherkennung oder Aufbereitung des Contents, serverseitig untergebracht, was eine ständige Netzwerkverfügbarkeit voraussetzt. Interessant ist das hybride
Routing-Konzept. So wird bei der Positionsbestimmung bedingt durch die mangelnde Genauigkeit von GPS eine Nutzerposition geschätzt sowie ein Fehlerwert beziehungsweise
eine Positionsabweichung errechnet. Der Nutzer bekommt daraufhin eine Liste von Straßennamen und muss seine genaue Position selbst bestimmen. Bei der grafischen Anzeige
wird deshalb kein Positionskreuz auf der Karte angezeigt, sondern ein Kreis, der die aktuelle Positionsgenauigkeit repräsentiert.
3.5.3
Mobility of Blind and elderly People Interacting with Computers (MoBIC)
Das MoBIC Projekt [MoB03] ist Teil des TIDE Frameworks [Tid03] der Europäischen
Union und richtet sich speziell an Personen mit visuellen Einschränkungen. Basierend
auf einer Nutzerbefragung entstand ein Wizard of Oz“-Prototyp, der MoTA (Mobile
”
16
Travel Aid) genannt wurde. Er besteht aus zwei Teilen – dem MoBIC Pre-Journey System (MoPS) und dem MoBIC Outdoor System (MoODS).
Vor der Reise sollten die Nutzer an einem stationären PC-System mit synthetischer
Sprachausgabe oder Braillezeile die Strecke planen und die Umgebung kennen lernen
können. Dazu wurden öffentliches Kartenmaterial, Daten, Adressen und persönliche
Präferenzen sowie wichtige Informationen für blinde Personen bezüglich Wegzustand
und Position von Hindernissen zur Verfügung gestellt. Die Routenberechnung beachtete zudem Nutzervorgaben, wie zum Beispiel schnellste Route, keine Stufen oder Benutzung von öffentlichen Verkehrsmitteln. Auf dem Weg sollte das MoODS, ausgestattet
mit einem DGPS-Empfänger zur Positionsbestimmung, den Nutzer leiten und relevante
Informationen anbieten. Nutzerinteraktionen erfolgten über eine kleine Tastatur für Eingaben und verbale Antworten, die über einen offenen Kopfhörer ausgegeben wurden, der
Geräusche der Umwelt nicht abschottet. Für erste Usability Tests wurde ein Walkman mit
zuvor aufgenommenen Weginformationen verwendet. Ein Begleiter war für die Positionsbestimmung verantwortlich [Pet97]. Zusätzlich benutzten die Testpersonen ihre gewohnten Hilfsmittel wie zum Beispiel Blindenhund oder Blindenstock.
3.5.4
Personal Guidance System
Als zweites Navigationssystem für Blinde basiert das Personal Guidance System auf einem virtuellen akustischen Display. Räumliche Audiosignale werden dem Nutzer über
Kopfhörer zugespielt und erklingen aus der Richtung, in der sich auch das beschriebene
Objekt befindet. Informationen zur Umgebung bezieht das System zum einen aus einem
geografischen Informationssystem (GIS), zum anderen aus einer Positionsbestimmung
mittels eines DGPS-Empfängers. Wichtig für das richtige Zuspielen des spatialen Audio
ist die Orientierung des Kopfes. Diese wird durch einen am Kopf befestigten Kompass
ermittelt. Testresultate von Jack Loomis zeigten, dass räumliches Audio der rein verbalen
Beschreibung der Umgebung leicht überlegen ist [LG01, S 441]. Allerdings war der Prototyp relativ groß und schwer, so dass er von der Testperson in einem Rucksack getragen
werden musste.
3.5.5
Lancaster GUIDE
Das Lancaster GUIDE Projekt [Che03] beschäftigt sich mit der Entwicklung eines elektronischen Fremdenführers für Lancaster. Ein erster Prototyp basierte auf einem Webpad
mit Stifteingabe. Positionsdaten sowie weitere Informationen zu Geschichte, Wetter oder
Öffnungszeiten von Sehenswürdigkeiten bezog das System aus einem Netz von WLAN
Hotspots, das über die Stadt gezogen wurde. Das Nutzerschnittstellen-Design folgte der
Browsermetapher, das Content in Hypertext und Bildern vorsah.
Ein relativ neuer Spross des GUIDE-Projekts ist der Audio-Prototyp“ von Christian
”
Bornträger. Für seiner Arbeit zum kontextuellen Einfluss auf die Nutzung verschiedener
Medien entstand eine Nutzerschnittstelle, die die gleichzeitige Nutzung von Text, Bild
und Audio sowie einer Kartendarstellung der Umgebung zulässt [Bor03, S. 27]. Zur Positionsbestimmung benutzt der Prototyp ein GPS-Modul, das im Erweiterungsschacht eines
PDA arbeitet. Eine Netzanbindung zum Beispiel über WLAN ist nicht notwendig, da alle
Inhalte im Endgerät gespeichert sind.
17
Kapitel 4
Systementwurf und Vorgehensweise
4.1
Nutzungsszenarien
Als Ausgangspunkt der Projektarbeit schwebte ein Nutzungsszenario im Raum, welches
einem Besucher der TU Ilmenau Navigationsinformationen für einen Weg zu einem zuvor
ausgewähltem Ziel auf einem mobilen Endgerät bereitstellen sollte. Diese Informationen
sollten als Richtungsanweisungen in Echtzeit grafisch und akustisch ausgegeben werden.
Erst später kam ein zweites Szenario hinzu. Darin sollte nun der Nutzer den Campus auf
eigene Faust erkunden und Zusatzinformationen je nach Nutzerprofil erhalten. Im Detail
sehen die beiden Szenarien wie folgt aus:
Wegsuche
1. Ein Besucher kommt am Campus an. Bei erstmaliger Benutzung wird das Nutzerprofil von einem Begleiter eingestellt und eine Einführung in die Bedienung gegeben. Das Endgerät wird ausgehändigt und der Nutzer meldet sich am System an.
2. Der Nutzer gibt ein Wegziel ein oder er wählt aus einer Vorschlagliste aus.
3. Ausgehend von der aktuellen Position erhält der Nutzer Richtungsanweisungen und
Zusatzinformationen, die nach dem gewählten Nutzerprofil erstellt wurden.
4. Bei Erreichen des Ziels werden weitere Zusatzinformationen zum Ziel dargestellt
und es kann ein neues Ziel eingegeben werden.
Spaziergang
1. Der Nutzer meldet sich am System an.
2. Die aktuelle Position sowie die nähere Umgebung werden auf dem Endgerät dargestellt und in Echtzeit aktualisiert, auf etwaige Hindernisse wie zum Beispiel Stufen
oder Steigungen wird hingewiesen.
3. Zu interessanten Gebäuden, Sehenswürdigkeiten und sonstigen Einrichtungen bietet das System Zusatzinformationen an.
18
4.2
Zielnutzergruppen
Die Zielgruppe für das Medienprojekt Barrierefreier Campus ist im Hinblick auf
Fähigkeiten und Einschränkungen sehr vielschichtig. Von den vielfältigen Auswirkungen der Bewegungseinschränkungen bis zu starken Sehbehinderungen finden spezielle
Bedürfnisse Beachtung. Das Teilprojekt 4, das sich mit den Nutzerprofilen beschäftigt,
trägt dieser Tatsache Rechnung. Für die Nutzerschnittstelle wäre wünschenswert, gerade
mit dem Gedanken der Barrierefreiheit im Hinterkopf, allen Nutzern ein gemeinsames
Userinterface zur Verfügung zu stellen, das über die Nutzerprofile angepasst wird. Für
viele Nutzer wird man dabei zunächst an eine visuelle Schnittstelle denken, die mit einer
Sprachausgabe ergänzt wird. Vorteil hiervon ist, dass der Mensch grafische Informationen quasi parallel aufnehmen kann. Er kann sehr schnell Bildteile fokussieren und so
selbständig wichtige Informationen herauspicken“. Im Gegenteil dazu ist Sprache ein
”
eher serielles Medium. Aus diesem Grund kann man ein visuelles Interface nicht einfach
durch eine Sprachausgabe für blinde Nutzer anpassen. Für diese Nutzergruppe haben wir
uns deshalb für die Entwicklung einer zweiten, rein akustischen, dialogbasierten Nutzerschnittstelle entschieden.
4.3
Gesamtentwurf
Der Entwurf des Gesamtsystems Barrierefreier Campus ist eine Aufgabe, die vor allem
vom Teilprojekt 8 – Kommunikation in Zusammenarbeit mit den Einzelmodulen – geleistet wurde. Dieser Gesamtentwurf hat Auswirkungen auf die praktische Gestaltung der
Nutzerschnittstelle und des Programms auf dem Endgerät. Um die Wiederverwendbarkeit
des Systems in Verbindung mit einer ganzen Reihe von Endgeräten und verschiedenen
Kommunikationsinfrastrukturen zu gewährleisten, wird ein möglichst großer Teil der Programmlogik auf einem Server implementiert. Dies erspart unnötigen Mehraufwand bei
der Programmierung von unterschiedlichen Endgeräten. Außerdem kommt es der Notwendigkeit entgegen, auf einem batteriebetriebenen Endgerät möglichst energiesparend
zu arbeiten und rechenintensive Programmteile wie Wegberechnung oder Datenbanken
auszulagern.
Für die Serveranbindung des Endgeräts bietet sich auf dem Campus der TU Ilmenau die
schon vorhandene WLAN-Infrastruktur an, da auch das Teilprojekt 2 – Lokalisation in
Gebäuden – mit WLAN arbeitet. Allerdings bestehen Abdeckungslücken; eine Serveranbindung ist nicht ständig vorhanden. Deswegen ist die Struktur so gewählt, dass Wegberechnung und Content-Aufbereitung sowie Nutzerprofilverwaltung zentral auf dem Server
geschieht, während Lokalisierung und Nutzerschnittstelle auf dem Endgerät situieren. Um
Lücken in der WLAN-Abdeckung zu überbrücken, kann das Endgerät – ist es erst einmal
initialisiert und hat es aktuelle Wegdaten – selbständig zum Ziel finden.
4.4
Technische Berührungspunkte mit anderen Teilprojekten
In der Projektgruppe war lange nicht genau definiert, wo die Berührungspunkte der einzelnen Projekte liegen und wie die Teile des Systems Barrierefreier Campus letztendlich
19
zusammenarbeiten sollen. Die Schnittstellen zwischen den einzeilen Teilprojekten wurden schließlich zunächst semantisch definiert, da die genaue technische Realisierung zum
Zeitpunkt der Definition noch nicht bekannt war. Diese Definitionen legen verbindliche
Variablennamen und Datentypen für den Datenaustausch vor allem zwischen den Teilprojekten Lokalisierungsinformation, Endgeräteanpassung und Programm auf dem Endgerät
fest. Die Realisierung, zum Beispiel die Modellierung mit einer XML-Struktur oder die
direkte Übertragung von Datenobjekten, war damit noch festzulegen.
Für das Programm auf dem Endgerät beziehungsweise für den mobilen Client wurde in
diesem Prozess ein Web Service als zentrale Schnittstelle für alle Systemteile und Teilprojekte auf dem Server festgelegt. Aus Endgerätesicht ist der Server damit eine Blackbox,
die nach außen hin nur die einzelnen Methoden des Web Service zeigt und Wegberechnung, Nutzerprofile und Anpassung kapselt. Diese wurden mit Methodennamen sowie
Aufrufparametern und Rückgabewerten definiert. Somit ist das Teilprojekt 8 – Kommunikation die technische Schnittstelle zu den Funktionsmodulen auf dem Server.
Die Lokalisierung des Nutzers erfolgt beim Barrierefreien Campus durch Selbstortung,
das heißt, dass die Positionsbestimmung auf dem Endgerät selbst erfolgt. Mit den Teammitgliedern, die für Lokalisation im freien Feld und in Gebäuden zuständig sind, wurde
deshalb die Integration ihrer Programmteile als Klassen im Programm auf dem Endgerät
abgesprochen.
4.5
Endgeräte
Durch den offenen Charakter des Systems Barrierefreier Campus soll letztendlich eine
ganze Reihe von Endgeräten unterstützt werden. Vom ausgewachsenen Notebook bis
zum kleinsten Mobiltelefon ist zunächst alles denkbar. Allerdings zielt die Anwendung
als Assistenzsystem“ klar auf mobile beziehungsweise wearable Systeme. Kalawsky be”
zieht den Ausdruck mobil“ in diesem Zusammenhang auf Mobilität und Bewegungsfrei”
heit im freien Feld und nicht darauf, dass ein Laptop außerhalb des Büros benutzt werden
kann [Kal02, S. 8]. Wearable heißt in diesem Sinne, dass das Gerät in irgendeiner Weise
am Körper getragen wird. Mensch und Technik sollten im Idealfall zu einer Funktionseinheit verschmelzen. Letzteres ist wohl eher Zukunftsmusik, dennoch kann man sagen, dass
ein schweres, großes Notebook als Endgerät für einen Fußgänger wohl eher eine suboptimale Wahl darstellen würde. Für einen Rollstuhlfahrer ist ein Notebook dagegen eventuell
ein geeignetes Endgerät. Die Wahl des Endgeräts ist damit letztendlich ein Kompromiss,
den jeder Anwender selbst eingehen muss. Ein sehr kleines, handliches Gerät hat Einschränkungen bei Rechenleistung und Displaygröße, ein Gerät mit hoher Rechenleistung
hingegen nur eine kurze Betriebsdauer, da der Akku schnell leer ist.
Für die Entwicklung des Prototyps wurde ein Endgerät gesucht, das ein möglichst breites Spektrum an Nutzerbedürfnissen abdeckt. Dazu wurden Endgeräte recherchiert, die
einen kleineren Formfaktor haben und sich als mobiles“ Endgerät im beschriebenen Sin”
ne eigenen. Der Formfaktor ist allerdings nicht die einzige Anforderung an das Endgerät.
Weitere Kriterien, die sich gegenseitig zum Teil ausschließen, sind die folgenden:
• Akku-Laufzeit,
• Rechenleistung,
20
• Display, Auflösung, Farbtiefe,
• Erweiterungsschacht für WLAN- und GPS-Modul, beziehungsweise alternative
Möglichkeiten für WLAN und GPS,
• Speicherkapazität,
• Audio-Eigenschaften, Wiedergabe von Sprache,
• Hardware-Buttons - für Nutzer mit eingeschränkten Sehfähigkeiten von großer Bedeutung,
• Verfügbarkeit eines VPN-Client zur Verbindung mit dem Campusnetz.
Lässt man Exoten wie beispielsweise tragbare Industriesysteme beiseite, kann man
mögliche Endgeräte in vier verschiedene Geräteklassen einteilen: Mobiltelefone, Handheld Computer und Personal Digital Assistants (PDA), Webpads, zu denen ich auch Tablet
PC zählen möchte, sowie Notebooks. Tabelle 4.1 zeigt Kriterien, die von einer denkbaren Entwicklungsplattform für den Prototypen des Medienprojekts Barrierefreier Campus
zwingend erfüllt werden mussten, um keine Nutzergruppe von vorn herein auszuschließen
und die Vorgaben aus anderen Teilprojekten zu erfüllen.
Mobiltelefon PDA
GPS-Funktionalität
–
+
WLAN-Funktionalität
–
+
für Fußgänger geeignet
+
0
Hardware-Buttons
+
+
Sprachausgabe
0
+
Webpad
+
+
0
–
+
Notebook
+
+
–
+
+
Tabelle 4.1: Anforderungen an Endgeräte Quelle: eigene Tabelle
Mobiltelefone konnten zum Zeitpunkt der Recherche noch nicht mit GPS-Funktionalität
ausgerüstet werden, die von Teilprojekt 2 für die Lokalisierung im freien Feld verwendet wird. WLAN, das von Teilprojekt 1 zur Positionsbestimmung in Gebäuden verwendet wird, ist für Mobiltelefone nicht vorgesehen. Ein Notebook ist für einen Fußgänger
in Bewegung nicht bedienbar. Blinde Menschen brauchen zur Interaktion mit dem Endgerät nichtvisuelle Ein- und Ausgabemöglichkeiten. Für sie sind Sprachausgabe sowie
Hardware-Buttons, die viele Webpads und Tablet PC nicht haben, unverzichtbar. Von den
vier Geräteklassen wurden deshalb Vertreter der zweiten Gruppe als Plattform für den
Prototypen näher betrachtet. Ein PDA vereint die wichtigsten benötigten Eigenschaften in
einem Gerät, so dass er eine gute Kompromisslösung darstellt.
Der Markt für PDAs teilt sich momentan in zwei große Lager, Palm OS PDAs und PDAs
mit Windows CE. Von den Palm-Geräten kam eigentlich nur der Tungsten T in Frage, der
als erster Palm-PDA mit dem Betriebssystem Palm OS 5 ausgeliefert wurde. Palm OS 5
ist das erste Betriebssystem, das die für das Projekt benötigten Multimediafunktionen
bietet und Multitasking unterstützt. Der Tungsten T war allerdings noch recht neu und das
Angebot an Peripherie und Programmen demzufolge gering. Den Anforderungskatalog
recht gut erfüllten hingegen die Pocket PC-Geräte. Sie ähneln sich durch die Vorgaben
von Microsoft sehr stark.
21
Die Wahl fiel auf einen IPAQ 36xx, der am Fachgebiet Kommunikationsnetze verfügbar
war und schon von Anfang des Projekts an zu Testzwecken ausgeliehen werden konnte.
Der IPAQ 36xx ist ausgestattet mit einem Strong ARM Prozessor 206 MHz, 32 MB Flash
ROM, einem 6cm x 8cm (240x320 Pixel) großen Touch Screen, Hardware Buttons sowie
einem Lautsprecher für die Soundwiedergabe. Außerdem kann er mit einem optionalen
Jacket mit Slots für die Aufnahme von bis zu zwei PCMCIA-Karten ausgerüstet werden,
die für WLAN und GPS gebraucht werden. Rechenleistung und Akku-Laufzeit sind akzeptabel. Damit stellt der IPAQ 36xx einen guten Kompromiss zwischen Portabilität und
Funktionalität dar. Die recherchierten Webpads haben eine sehr ähnliche Hardware- und
Schnittstellenausstattung, weshalb das Programm mit wenigen Anpassungen auch auf dieser Plattform zum Laufen gebracht werden kann. Zudem kommt das große Display der
Webpads Menschen mit Sehbehinderungen zugute. Tabellen der technischen Daten der
recherchierten Endgeräte sind in Anhang A zu finden.
22
Kapitel 5
Programmentwicklung
Für die praktische Umsetzung der Nutzerschnittstellen war es notwendig, zunächst eine
Programmiersprache zu wählen. Danach galt es, die Nutzerschnittstellen in ihrer Funktionalität zu beschreiben und zu implementieren. Im Folgenden sind diese Arbeitsschritte
dokumentiert. Die im Detail vorgestellte Programmstruktur wird durch die Beschreibung
der Klassen und Komponenten vertieft. Die Abschnitte über die Implementation des Programms auf dem Endgerät werden mit einer Beschreibung von Problemen abgerundet, die
während der Entwicklung auftauchten.
5.1
Wahl der Programmiersprache
Als Endgerät für den Prototypen wurde wie in Kapitel 4.5 beschrieben ein IPAQ 36xx ausgewählt. Das voreingestellte Betriebssystem ist Windows CE 3.0 beziehungsweise Pocket
PC 2000. Obwohl es auch in Verbindung mit ARM-Linux eine Reihe von Open-SourceProjekten zu Lokalisierung und Navigation gibt, wurde eine Verwendung von Linux als
Betriebssystem von vorn herein ausgeschlossen, da die meisten Pocket PC-Nutzer Windows CE kennen und verwenden. Für die Programmierung unter Windows CE blieben als
Alternativen die Verwendung einer Java Virtual Machine (VM) und Programmierung mit
Java sowie das gerade der Beta-Phase entwachsene Microsoft .NET Compact Framework
in Verbindung mit C# oder die native Entwicklung mit C++. Der Mehrnutzen einer nativen
Programmierung steht allerdings nicht im Verhältnis zu dem entstehenden Mehraufwand,
zumal sowohl C# als auch Java die Softwareentwicklung durch Garbage Collection und
Bounds Checking vereinfachen. Deshalb wurde die Entscheidung zwischen Java und C#
getroffen.
5.1.1
Java
Als Voraussetzung für das Programmieren mit Java braucht man zunächst eine Virtual Machine auf der Zielplattform. Für Windows CE gibt es das kommerzielle Jeode Java Runtime Environment (JRE) von Esmertec [Esm03] oder als freie Alternative zum Beispiel
SuperWaba [Sup03]. SuperWaba unterstützt allerdings nicht den gesamten Sprachumfang
von Java und wird von seinen Entwicklern lediglich als javaähnlich“ bezeichnet. Vorteil
”
bei einer Entwicklung unter Java ist die Verfügbarkeit von Java-VMs auf einer großen
23
Anzahl von möglichen Endgeräten bis hin zu Mobiltelefonen. Damit ist eine zumindest
eingeschränkte Wiederverwendbarkeit des Programmcodes möglich. Nachteilig sind bei
der Verwendung von Java oft Performancedefizite sowie die fehlende Unterstützung plattformeigener Kontrollelemente wie zum Beispiel das Soft-Keyboard bei den Pocket PC.
Hinzu kommt, dass die VMs schlecht dokumentiert sind und der direkte Zugriff auf GPSModul und WLAN-Karte unsicher ist.
5.1.2
.NET Compact Framework
Die Entscheidung fiel, auch aufgrund der positiven Erfahrungen von Christian Bornträger,
die er bei der Entwicklung seines Audio-Prototyps gemacht hatte, zugunsten von C# aus.
Mit Erscheinen des Microsoft Visual Studio 2003 lag für diese Lösung auch eine integrierte Entwicklungsumgebung vor. Vorteil von C# ist die gute Unterstützung für die Programmierung von Pocket PC-Geräten, so können zum Beispiel die windowsspezifischen
Nutzeroberflächenelemente verwendet werden und dem Programmierer steht eine große
Anzahl an Programmbibliotheken zur Verfügung. Um ein C#-Programm auszuführen,
muss zunächst das circa 1,5 MB große .NET Compact Framework auf der Zielplattform
installiert werden, für die Installation des eigentlichen Programms genügt ein einfacher
xcopy“-Befehl. Durch das Verwenden des .NET Frameworks ist einmal erstellter Quell”
code innerhalb der Windows-Welt“ relativ einfach wiederzuverwenden.
”
5.2
Design der Nutzerschnittstellen
Ausgangspunkt zum User-Interface Design war eine Mind Map, die wahllos Funktionen
und Darstellungsmodi auf gedachte Bildschirme, die miteinander verlinkt wurden, verteilte. Ergänzt wurde dieser Ansatz durch Diagramme zur Nutzerinteraktion, die zeitliche
Abläufe im Programm auf dem Endgerät definierten. Die Benutzerschnittstellen wurden
in Zusammenarbeit mit den Teilprojekten vier und fünf abgesprochen und in zwei Dokumenten festgehalten, die sich auf der beigelegten CD-ROM befinden. Funktionen und
Programmstruktur wurden dabei definiert. Die Implementierung verblieb als Aufgabe im
Teilprojekt 7. Die beiden Entwürfe sind nun im Folgenden beschrieben. Sie beziehen sich
auf das Gewählte Endgerät. Ein kurzer Abschnitt zu allgemeinen und geräteabhängigen
Teilen der Benutzerschnittstelle steht unter 5.2.3.
5.2.1
Nutzerschnittstelle für Sehende
Das User-Interface für Sehende folgt mehreren Metaphern. Bestimmend in den Diskussionen bezügliche der Funktionalität des Gesamtsystems war die Kartenmetapher. Karten
sind ein sehr gebräuchliches Mittel um Routen zu planen und ein neues Terrain zu erkunden. Außerdem werden Karten bei der Routenberechnung benötigt. Diese kann man
dann gleichwohl dem Nutzer zur Orientierung präsentieren. Desweiteren macht sich das
User-Interface die Windows-Metapher zunutze. Es werden Standard Windows FormsKomponenten, wie das virtuelle Keyboard oder Registerkarten, verwendet. Diese verlangen Nutzern, die einen Pocket PC im Alltag verwenden, keine Umgewöhnung ab. So passt
sich die Nutzerschnittstelle gut in die Pocket PC-Umgebung ein.
24
Ähnlich wie der Audio-Prototyp von Christian Bornträger bietet die Nutzerschnittstelle
für das Projekt Barrierefreier Campus vier gleichzeitig aktive Interfaces, die der Nutzer
über Kartenreiter auswählen kann. Menü (Einstellungen), Zielsuche, Kartendarstellung
und Zusatzinformation sind neben Nutzerauswahl der Registerkarten zusätzlich verlinkt.
So kann der Nutzer zum Beispiel über Icons auf der Karte direkt zu den zugehörigen Zusatzinformationen springen. Abbildung 5.1 zeigt einen Screenshot der Nutzerschnittstelle
für Sehende.
Abbildung 5.1: Screenshot der Benutzeroberfläche. Quelle: eigene Abbildung
5.2.2
Nutzerschnittstelle für Blinde
Wie bereits angedeutet, verfolgt die Nutzerschnittstelle für Blinde einen fundamental
anderen Ansatz als das Interface für Sehende. Es ist rein dialogbasiert und verzichtet
gänzlich auf eine graphische Nutzeroberfläche. Als bestimmende Metapher wäre hier die
Browsermetapher anzuführen. Vorbild für die Belegung der Hardwaretasten war der Textbrowser Lynx [Lyn03], der überwiegend über die Richtungspfeiltasten bedient wird. Dieses Konzept wurde auf das Richtungskreuz des IPAQ übertragen. So kann man sich mit
den Up- und Down-Tasten durch die Einträge eines Menüs bewegen. Ein Link wird mit
der Rechtstaste ausgewählt. Als universelle Zurück-Taste kommt die Linkstaste zum Einsatz.
Beim User Interface für Blinde mussten Einschränkungen in der Funktionalität in Kauf
genommen werden. Es gibt für das gewählte Endgerät keinen Mechanismus für die Texteingabe, den eine blinde Person nutzen könnte. Ideal hierfür wären speziell für Blinde
entwickelte Geräte wie der PACMate [Wir02]. Er ist mit einem Screen Reader sowie
einer Braille-Tastatur ausgerüstet. Um blinden Nutzern trotz aller Einschränkungen die
Texteingabe mit dem Endgerät für den Barrierefreien Campus zu ermöglichen, wurde von
uns eine QWERTZ-Braille-Tastatur entwickelt. Sie besteht aus einer Folie, die ein ertastbares Tastatur-Layout enthält. Diese wird auf den Touch Screen des IPAQ gelegt, der
25
ein entsprechendes Tasten-Layout anzeigt. Ein erfolgreicher Tastendruck wird mit einem
akustischen Signal angezeigt. Das Projektteam konnte keine rein akustische Beschreibung
der Umgebung leisten, weshalb die Nutzerschnittstelle für Blinde lediglich als Demonstration eines dialogbasierten Sprach-Interfaces zu sehen ist. Für diese Zielgruppe kann das
entstehende Programm lediglich Ausgangspunkt für intensive Weiterentwicklungen sein.
5.2.3
Allgemeine und geräteabhängige Teile der Nutzerschnittstelle
Das oben beschriebene Design der Nutzerschnittstelle bezieht sich auf den IPAQ-PDA,
der als Endgerät für den Prototypen des Barrierefreien Campus gewählt wurde. Durch
die Verwendung des .NET Compact Frameworks ist der entstehende Programmcode jedoch innerhalb der Windows-Welt“ recht gut auch in Verbindung mit anderen Windows”
Betriebssystemen und anderen Prozessoren wieder verwendbar. Einer größeren Anpassung bedarf allerdings die Präsentation (siehe Abbildung 5.2), da sich Ein- und Ausgabe
auf verschiedenen Endgeräten beträchtlich unterscheiden.
Gänzlich plattformunabhängig ist die von Teilprojekt 8 definierte Schnittstelle des Web
Service. Die Web-Service-Methoden können von beliebigen Clients genutzt werden, die
SOAP unterstützen. Als plattformunabhängige Nutzerschnittstelle könnte man sich zum
Beispiel ein Web Frontend für den Barrierefreien Campus vorstellen. Dieser könnte genutzt werden um Besichtigungstouren und Ausflüge von zuhause aus vorzubereiten.
5.3
Programmstruktur
Über den prinzipiellen Ablauf der der Nutzerinteraktion haben schon die Nutzerszenarien
in Abschnitt 4.1 Auskunft gegeben. In diesem Abschnitt sollen nun die internen Abläufe
des Programms auf dem Endgerät gezeigt werden.
5.3.1
Funktionsblöcke
Abbildung 5.2 zeigt die Funktionsblöcke des Programms auf dem Endgerät. Die Kommunikation mit dem Web Service erledigt eine Proxy-Klasse, die sämtliche SOAP-Aufrufe
selbst generiert. Weg und Spaziergang werden bei Bedarf mit den Rückgabewerten der
Web-Service-Methoden initialisiert und steuern“ die Anzeige. Der Block Audio ist noch
”
nicht vollständig implementiert.
5.3.2
Zeitliche Abläufe
Die meisten Prozesse und Abläufe stößt der Nutzer durch Eingabe von Daten oder
Betätigen von Buttons an. Damit gibt es keine zeitlich starre Abfolge der CodeAusführung. Zeitlich feste Abläufe während einer Nutzungs-Session gibt es während der
Initialisierung und an Stellen, an denen das Programm in einen anderen Modus wechselt.
Diese zeitlichen Abläufe werden im Folgenden beschrieben.
26
Abbildung 5.2: Struktur des Programms auf dem Endgerät. Quelle: eigene Abbildung
Initialisierung
Beim Programmstart wird zunächst vorausgesetzt, dass der Nutzer ein Nutzerprofil angelegt hat. Eine User ID und ein Passwort ist dann für ihn gespeichert. Für das Abändern
des Nutzerprofils sowie die Generierung der Kennwörter wird eine Setup-Anwendung
(siehe Abschnitt 5.4.1) bereitgestellt. Wenn das Programm keine User ID auf dem Endgerät findet, wird der Nutzer darauf hingewiesen, dass er als Gast“ angemeldet wird. Ist
”
eine Anbindung an den Server vorhanden, wird als entfernter Methodenaufruf die Authentifizierungsprozedur gestartet. Falls der Web Service nicht erreichbar ist, verwendet
das Programm ein lokales Profil, das noch von der letzten Session gespeichert ist. Es folgt
die Anpassung des Nutzerinterfaces und schließlich, nach der Initialisierung des GPSReaders, das Starten des Spaziermodus.
Umschalten zwischen Spazier- und Wegmodus
Defaultmäßig befindet sich der Nutzer im Spaziermodus. Die Einstellungen für den Spaziermodus bleiben deshalb während der gesamten Nutzungs-Session erhalten. Über die
Bildschirmansicht Ziel“ kann der Nutzer ein Ziel wählen und den Wegmodus starten.
”
Bei Beenden des Zielmodus, wenn das Ziel erreicht ist oder wenn der Nutzer vom Weg
abgekommen ist und keine Verbindung zum Server hergestellt werden kann, fällt das System zurück in den Spaziermodus. So soll gewährleistet werden, dass sich das Programm
auf dem Endgerät immer in einem der beiden Zustände befindet.
27
5.4
Klassen und Komponenten des Programms auf dem
Endgerät
Bei der Entwicklung des Programms auf dem Endgerät gab es zunächst eine große Anzahl
von ungelösten Problemen. Vorgegangen wurde wie folgt: Zunächst war die Lösung von
Teilproblemen durch kleine Programmteile vorrangig. Erst gegen Ende des Entwicklungszeitraumes wurden diese zu einem vollständigen Programm zusammengesetzt. Natürlich
sind neben den eigenen Klassen vorgefertigte Klassenbibliotheken zur Programmentwicklung eingesetzt worden. Im Folgenden sollen die selbst geschriebenen Komponenten vorgestellt werden.
5.4.1
Die Setup-Anwendung
Die Nutzerschnittstelle des Medienprojekts Barrierefreier Campus wird durch die verschiedenen Benutzerprofile, die zentral in einer Datenbank abgelegt sind, individuell an
den Nutzer angepasst. So ergibt sich das Problem, dass beim Programmstart schon ein
Nutzerprofil vorhanden sein muss, damit das Programm die richtigen Einstellungen laden
kann und damit für den jeweiligen Nutzer bedienbar ist. Das Benutzerprofil wird deswegen im Voraus eventuell auch durch einen Betreuer eingerichtet. Lediglich User ID und
Passwort werden, nachdem sie in der Setup-Anwendung definiert worden sind, lokal auf
dem Endgerät gespeichert. Alle anderen Einstellungen können über ein Web Interface,
das aus der Setup-Anwendung heraus aufgerufen wird, verändert werden.
5.4.2
Die Klasse Spaziergang
Das Nutzerszenario Spaziergang setzt die Initialisierung des Programms auf dem Endgerät mit Daten zu interessanten Gebäuden und Einrichtungen der zu Fuß oder mit
dem Rollstuhl erreichbaren Umgebung voraus. Hierzu wird durch entfernten Methodenaufruf ein Datensatz mit den relevanten Informationen und einer referenzierten Karte
auf das Endgerät übertragen. Eine neue Instanz der Klasse Spaziergang wird mit dem
übermittelten Datensatz angelegt. Sie stellt Zugriffsmethoden für die Daten zur Verfügung
und übernimmt die Extraktion der Daten aus den Tabellen. So können Referenzpunkte
und Daten zu Points of Interest (POI) durch einfache get“-Methoden direkt aufgerufen
”
werden.
5.4.3
Die Klasse Weg
Ähnlich wie die Klasse Spaziergang stellt die Klasse Weg Zugriffsmethoden für den vom
Web Service übermittelten Wegdatensatz zur Verfügung. Darüber hinaus hat sie ein Interface für die aktuellen GPS-Daten, um den Kurs des Nutzers überprüfen zu können und
Anweisungen zu triggern.
Der Weg, der von Teilprojekt 3 – Lokalisierungsinformation – berechnet wird, ist approximiert durch gerade Teilstücke, die so genannten Kanten. Jede Kante ist definiert durch
ein GPS-Datum für jeweils Anfang und Ende. Eine Beschreibung von Hindernissen, die
Länge der Kante sowie Richtungsinformationen für die Transition zwischen den Kanten
28
sind im Datensatz enthalten. Aus diesen Informationen leitet nun die Klasse Weg Anweisungen und Feedback an den Nutzer ab. So wird der Nutzer zum Beispiel vor dem
Erreichen des Kantenendes über die nächste Kante, die er einschlagen muss, informiert.
Hierzu wird die gerade aktive Kante der Einfachheit halber durch kleine Quadrate approximiert, da zum einen die Positionsbestimmung fehlerbehaftet ist und zum anderen
der Nutzer nicht immer die ideal gerade Linie verfolgt. Abbildung 5.3 zeigt diese Approximation. Zur Zeit haben die Quadrate jeweils circa zwei Meter Kantenlänge und ihre
Mittelpunkte liegen im Abstand von einem Meter. Die Methode IsOnTrack“ ermittelt
”
nun für jedes GPS-Datum das Quadrat, in dem sich der Nutzer gerade befindet, und kann
so Aussagen über den Fortschritt des Nutzers auf der Kante geben. Diese Vorgehensweise
gewährleistet, dass Richtungsinformationen rechtzeitig ausgegeben werden können.
Sobald ein Nutzer vom Weg abkommt geschehen drei Dinge:
1. Das Programm wartet kurze Zeit.
2. Die aktuelle und die nächste Kante werden durchsucht.
3. Der Nutzer wird darauf hingewiesen, dass er vom Weg abgekommen ist und es wird,
wenn WLAN vorhanden ist, ein neuer Weg mit gleichem Ziel angefordert.
Abbildung 5.3: Approximation der Wegkanten. Quelle: eigene Abbildung
5.4.4
Die Klasse Scrollkarte
Die Klasse Scrollkarte realisiert die Kartenanzeige für das Projekt Barrierefreier Campus.
Abgeleitet von Windows.Forms.Control bietet sie nützliche Funktionen für die Nutzeroberfläche eines Navigationssystems für Pocket PC.
Die Klasse Scrollkarte kann Kartengrafiken in den meisten Standardgrafikformaten anzeigen. Per Stift können die Karten an die richtige Position gezogen“ werden, um auf
”
einem kleinen Bildschirm eine große Karte betrachten zu können. Double Buffering, das
heißt das Zeichnen der Karte im Hintergrund und Darstellung auf dem Bildschirm in einem zweiten Schritt, verhindert Flackern und erzeugt ein weiches“ Scrollen. Auf der
”
Karte kann ein Fadenkreuz oder ein anderes Sprite dargestellt werden. Seine Position
29
kann in Relation zu den Kartenkoordinaten angegeben werden. Schließlich bietet das
Scrollkarten-Control einen Modus, bei dem die Karte der Position des Sprites auf dem
Bildschirm nachgeführt wird, so dass die Position des Nutzers nicht weglaufen“ kann.
”
5.4.5
Die Klasse Parser
Die Klasse Parser ist aus Programmsicht die Schnittstelle für Lokalisierungsinformationen aus den Teilprojekten 1 und 2 – Lokalisierung im freien Feld und in Gebäuden. Der
Parser bietet ein Interface für Referenzpunkte, die für das Mapping auf Kartenkoordinaten gebraucht werden. Zur Zeit besteht die Berechnung der Koordinaten aus einer einfachen linearen Transformation der Daten, die vom GPS-Reader kommen. Geplant ist, nach
Fertigstellung der Komponenten zur Lokalisierung in Gebäuden, die Integration beider
Lokalisierungsmethoden in einem einheitlichen Interface.
5.5
5.5.1
Probleme bei der Implementation
Sprachsynthese
Für das Interface für Blinde wird eine Sprachausgabe benötigt. Hier bietet es sich an,
Sprachsynthese zu verwenden, da der Aufwand für das Aufnehmen einer Stimme hoch
ist. Zudem entsteht bei der Verwendung von aufgenommenem Audio ein Problem, wenn
das System erweitert wird oder neue Orte, Straßen und Gebäude entstehen. Eine freie TTS
Engine (text to speech engine), die für das Projekt verwendet wurde, ist Festival Light
(Flite) [Fli03]. Flite ist eine kleine, schnelle Sprachsynthese-Software, die vornehmlich
für embedded Geräte entwickelt wurde. Anfänglich entwickelt für Linux, gibt es mittlerweile Versionen für Windows CE und eine Portierung für Java. Problem ist allerdings,
dass in der Version für Windows CE nur eine englische Stimme enthalten ist, die für den
hiesigen Sprachraum nicht geeignet ist und sich die Integration einer deutschen Stimme als für das Projektteam unlösbare Aufgabe herausstellte. So bleibt Sprachsynthese
für das Projekt Barrierefreier Campus eine offene, noch zu klärende Frage, da geeignete
Open Source-Programme fehlen.
5.5.2
Hardware-Tasten und Sound-Ausgabe
Bringt die Entwicklung mit dem .NET Compact Framework viele Vorteile, gibt es doch
einige Stellen, an denen man bei der Programmierung an Grenzen stößt. Generell ist das
Problem, dass nicht alle Funktionen des .NET Frameworks implementiert sind. Grund
dafür ist die Beschränkung auf einen möglichst kleinen Footprint im mobilen und embedded Bereich. In Abbildung 5.4 kann man sehen, welche Klassen nicht im Compact
Framework enthalten sind. Diese sind grün markiert. Neben dem Fehlen dieser gesamte
Blöcke sind für viele Klassen auch nur bestimmte Methoden implementiert.
Ein Beispiel für eine fehlende Funktionionalität ist das Abfangen der Key Events auf
Form-Ebene. Sobald ein anderes Control als die Form selbst, zum Beispiel eine Textbox
oder ein Button, den Eingabefokus hat, kann nur noch dieses auf den Key Event reagieren. Die einzige Möglichkeit Key Events doch an zentraler Stelle zu verarbeiten, ist das
30
Abbildung 5.4: Das Compact Framework unterstützt nur die Klassen, die blau unterlegt
sind. Quelle: nach [Tia03]
Benutzen von WinAPI-Funktionen und damit unmanaged Code“, oder man muss sicher”
stellen, dass zu keiner Zeit ein anderes Control als die Form selbst den Eingabefokus hat.
Schwierigkeiten bekommt man dann aber, wenn man den Eingabefokus tatsächlich einmal auf einem bestimmten Control braucht, zum Beispiel wenn der Nutzer einen Text in
eine Textbox eingeben will.
Ein zweites Beispiel für eine fehlende Funktion, das mich eine ganze Weile beschäftigt
hat, ist die Ausgabe von Sounds. Auch hierfür gibt es keine Funktionen im .NET Compact Framework. Bei Versuchen, die Sound-Ausgabe durch P/Invoke einer nativen Funktion zu ermöglichen, fror das Display ein. Ein zweiter Thread musste Abhilfe schaffen.
Allerdings ließ diese Funktion eigentlich nur das Abspielen von kurzen Sounds (Systemsounds usw.) zu, da keine Möglichkeiten vorhanden waren, die Sound-Ausgabe zu
stoppen oder zu pausieren. Die Lösung schien mit der Verwendung einer Open SourceKlassenbibliothek [Ope03] für das .NET Compact Framework gefunden. Sie bietet eine
Soundplayer-Infrastruktur. Allerdings trat bei meinen Versuchen mit der Bibliothek beim
Abspielen von Audiodateien immer wieder ein lautes Rauschen auf, das vermutlich auf
ein Problem beim Lesen der Sounddatei zurückzuführen ist.
31
Kapitel 6
Demonstrationsprogramme
6.1
WgsToXY – Ansatz für den Spaziermodus
In Zusammenarbeit mit dem Teilprojekt 2 – Lokalisierung im freien Feld – entstand das
Programm WgsToXY, das, wie der Name schon sagt, mit der Parser-Klasse WGS84 Koordinaten vom GPS-Empfänger auf eine selbstgewählte Karte mappt. Hierzu können die
Referenzpunkte in Echtzeit gewählt werden, um beliebiges Kartenmaterial verwenden zu
können. Für die Kartendarstellung kommt die Scrollkarten-Klasse zum Einsatz. Die Position wird mit einem Fadenkreuz-Sprite angezeigt. Bei einigen Rundgängen auf dem
Campus konnten mit diesem Tool schon Erfahrungen zu der tatsächlichen Genauigkeit
der Lokalisierung im freien Feld gemacht und letztendlich die Grundlage für den Spaziermodus demonstriert werden.
6.2
User Interface für Blinde – Demonstrationsprogramm
Das User Interface für Blinde ist noch nicht im Programm auf dem Endgerät implementiert. Das hat mehrere Gründe: Zum einen ist die Lokalisierung noch nicht genau genug. Tests mit dem GPS-Empfänger und dem Endgerät ergaben eine Positionsunsicherheit von bis zu zwanzig Metern, die für punktgenaue Richtungsanweisungen ungenügend
sind. Zum anderen verzögerten Probleme mit Sprachsynthese und Soundausgabe allgemein die Implementation der Nutzerschnittstelle. Das vorliegende Programm demonstriert demzufolge den Eingabemechanismus für das Interface, der in eine einfache auditive Menüstruktur eingebettet ist. So können mit dem Steuerkreuz Menüpunkte ausgewählt
sowie ein Ziel bei der Zielsuche eingegeben werden.
6.3
BaFreiCa – eine Demonstrationsversion
Um eine Demonstrationsversion vom Programm auf dem Endgerät zu erstellen, die unabhängig von den anderen Komponenten des Barrierefreien Campus lauffähig ist, mussten
einige Kompromisse eingegangen werden. So sind sämtliche Programmressourcen, wie
32
Bilder und Kartenmaterial, die eigentlich vom Web Service übertragen werden sollen,
schon vor Programmstart im Programmverzeichnis abgelegt. Die Schnittstellendefinitionen zu den anderen Teilprojekten werden jedoch eingehalten. So werden zum Beispiel
XML-Dokumente verwendet, die zwar noch unvollständige Lokalisierungsinformationen
enthalten, jedoch dem definierten Format entsprechen.
6.3.1
Simulation der fehlenden Komponenten
Die beiden wichtigsten technischen Schnittstellen für das Programm auf dem Endgerät
sind zum einen der Web Service, der die Kommunikation zu Lokalisierungsinformation
und Benutzerprofilen übernimmt und zum anderen die Lokalisierungsdaten auf dem Endgerät selbst. Beide Komponenten werden durch Stellvertreterklassen simuliert.
Auch ein richtiger“ Web Service wird in C# durch eine Proxy-Klasse angesprochen, die
”
die Kommunikation mit dem Service übernimmt. Für das Programm sind lediglich die
Methoden des Web Service sichtbar, die sich wie ganz normale lokale Methoden aufrufen
lassen. Ein Web-Service-Dummy realisiert die vier geplanten Methoden des Web Service
– namentlich Authentifizierung, InitWalkMode, Zielanfrage und Zielsuche – mit minimalen Funktionsumfang. Bis auf Zielsuche“ besteht die Funktionalität lediglich aus der
”
Erstellung eines Datensatzes, der aus einer auf Universitäts-Webspace abgelegten XMLDatei generiert wird. Die Methode Zielsuche simuliert das Generieren genauerer Suchoptionen aus den vom Nutzer gewählten Zielen.
Die Simulation der Lokalisierung übernimmt eine Klasse, die statt der GPS-Koordinaten
direkt karthesische Punktkoordinaten ausgibt. Die Karte wird mit sich selbst referenziert,
damit die Parse-Klasse wieder die gleichen Werte errechnen“ und weitergeben kann.
”
Eingegeben werden die Koordinaten durch das Steuerkreuz des IPAQ. So kann die Fortbewegung des Nutzers interaktiv gesteuert werden.
6.3.2
Testszenario
Das Testszenario umfasst Initialisierung, Spaziermodus und Wegmodus. Nach der Initialisierung des Programms auf dem Endgerät mit den Rückgabewerten der Web-ServiceMethode ’Authentifizierung’, befindet sich der Nutzer im Spaziermodus. Er kann die
Karte des Campus betrachten und Zusatzinformationen zu Gebäuden abfragen, die auf
der Registerkarte ’Info’ angezeigt werden. Seine Position wird auf der Karte durch ein
Fadenkreuz angezeigt. Der Button Ziel“ führt den Nutzer zur Registerkarte ’Zielsuche’.
”
Durch eine wiederholte Auswahl von Optionen, die in einem Drop-Down-Menü angezeigt
werden, wird das Ziel immer genauer bestimmt. Ein Klick auf den Button ’Los’ startet die
Zielsuche; als Information wird unter ’aktives Ziel’ Start und Ziel sowie die Weglänge angezeigt. Im Testszenario ist das immer der gleiche Weg. Das Fadenkreuz springt“ zum
”
Ausganspunkt des Wegs. Jetzt kann die Position des Nutzers durch das Steuerkreuz des
IPAQ bestimmt werden. Jeweils drei Meter vor der nächsten Abzweigung bekommt der
Nutzer Anweisungen, die aus einer textuellen Beschreibung der Folgekante der Angabe der Richtung sowie einem Pfeilpiktogramm bestehen, auf der Registrierkarte ’Info’
präsentiert. Auch das Erreichen des Zielpunktes wird in Verbindung mit der Anzeige der
zugeörigen Zusatzinformationen angezeigt.
33
6.3.3
Ergebnisse
Die stark eingeschränkte Demonstrationsversion des Programms auf dem Endgerät lässt
nur bedingt Rückschlüsse auf die Benutzung des Programms in einem realitätsnahen Umfeld zu. Neben wichtigen Aspekten, die in die Zuständigkeit anderer Teilprojekte fallen –
wie zum Beispiel der Positionsgenauigkeit, Qualität der Wegbeschreibung und Richtungsanweisungen bis zur Genauigkeit der Karte – sind auch einige Aspekte der Nutzerschnittstelle, wie die Bedienbarkeit in der Bewegung noch nicht bewertbar. Auch die Wahl der
Größe der Quadrate, die die Kante approximieren, muss noch der Positionsgenauigkeit
angepasst werden. Ebenso ist die Distanz beziehungsweise der Zeitpunkt des Hinweises
auf die nächste Kante noch zu bestimmen.
Allerdings können schon einige Ergebnisse für diesen Prototypen festgehalten werden.
Das Programm auf dem Endgerät selbst bietet relativ wenige Einstellungsmöglichkeiten,
es passt sich vielmehr selbständig nach dem gewählten Nutzerprofil an die Bedürfnisse
des Nutzers an. Da die Nutzerprofile bei Programmstart erst vom Server geladen werden
müssen, dauert die Initialisierung recht lange. Recht viel Zeit braucht dabei das Exception
Handling. Erste Versuche mit dem Prototypen haben gezeigt, dass die Anzeige der Richtungsinformationen auf der Registrierkarte Karte“ zu einer starken Überladung dieser
”
Bildschirmansicht geführt hat. Deshalb wurden die Richtungsanweisungen auf die Registrierkarte Info“ verlagert um Übersichtlichkeit zu gewinnen. Zusätzliche werden die In”
formationen für die aktuellen Kanten an selber Stelle laufend aktualisiert. Durch die Buttons am unteren Bildschirmrand, die auch mit den Fingern bedient werden können, sind
diese Informationen schnell abrufbar, auch wenn sie nicht direkt mit der Karte dargestellt
werden. Die Anzeige der Position durch ein Fadenkreuz ist für reale Lokalisierungsinformationen wahrscheinlich schon fast zu genau, für die Eingabe der Position mit dem Steuerkreuz ist es gut geeignet. Die Registrierkarte Menü“ enthält für den Prototypen und zu
”
Testzwecken wichtige Anzeigen, wie GPS-Koordinaten, Einstellmöglichkeiten und Darstellungsoptionen. Tests mit realen Nutzungsszenarien müssen zeigen, welche Optionen
hier wirklich wichtig sind, und welche durch Programmlogik ersetzt werden können.
34
Kapitel 7
Ausblick
Die Ergebnisse des Medienprojekts sind Momentaufnahmen einer Entwicklung, in der
ein erster Ansatz für ein Assistenzsystem verwirklicht wurde. Im Teilprojekt 7 entstand
die prototypische Implementation einer Nutzerschnittstelle für das Medienprojekt Barrierefreier Campus. Eine Demonstration verdeutlicht, wie eine Nutzerschnittstelle für blinde
Menschen für den Prototypen realisiert werden kann. Neben dem Prototypen selbst sind
bei der Entwicklung des Programms eine ganze Reihe von Klassen und Komponenten
entstanden. Sie bilden die Basis für weitere Forschung und Anwendungsentwicklungen.
Lange Verzögerungen bei der Entwicklung anderer Komponenten des Teamprojekts, auf
die die Benutzerschnittstelle aufbaut, ließen bisher leider noch keine Tests der Software in einer realen Einsatzsituation und mit potentiellen Nutzern zu. Dieser sehr wichtige
Schritt ist zur weiteren Anpassung und Verbesserung der Nutzerschnittstelle sowie des
Gesamtsystems jedoch unverzichtbar. Im Laufe der Entwicklung wurden viele Annahmen getroffen, die überprüft werden müssen. Auch das Endgerät muss sich in der Praxis
bewähren. So ist bisher nicht geklärt, wie sich Wettereinflüsse wie Regen oder Kälte auf
Gerät und Bedienung auswirken oder wie gut die Interaktion mit dem Prototypen funktioniert, während sich der Nutzer im Gelände bewegt.
Weitere Forschung und Entwicklung ist im Bereich der Nutzerschnittstelle für Blinde
notwendig. Hier kann die Integration einer Sprachsynthese die mühsame Aufgabe der
Sprachaufnahme ersetzen. Die im Team entwickelte QWERTZ-Brailletastatur für den
IPAQ kann nur eine suboptimale Lösung für die Dateneingabe für blinde Personen sein.
Mit steigender Rechenleistung der Endgeräte sowie Fortschritten bei der Spracherkennung ist eine rein auditive Nutzerschnittstelle denkbar. Eine sorgfältige Betrachtung der
Positionsbestimmung sowie der Verarbeitung der Positionsdaten im Programm auf dem
Endgerät könnte ein weiterer Schwerpunkt für Verbesserungen am Prototypen sein. Durch
Annahmen wie Ein Nutzer geht meist auf Wegen“ oder Ein Nutzer bewegt sich nicht auf
”
”
Dächern“ usw. können durch ein Bewegungsmodell des Nutzers Fehler der Lokalisierung
erkannt und eventuell Verbesserungen erreicht werden. Bisher wird als einziger Kontextsensor die Position des Nutzers ausgewertet. In zukünftigen Versionen des Programms
könnten Kontextinformationen über weitere Sensoren erfasst werden. So könnten Daten
über die Bewegungsrichtung und Geschwindigkeit des Nutzers Dead Reckoning in Bereichen ermöglichen, in denen Abschattungen der GPS-Satelliten mit Abdeckungslücken
des WLAN zusammen fallen. Sensoren am Körper des Nutzers könnten den Gesundheitszustand des Nutzers überwachen und im Notfall einen Hilferuf mit der genauen Position absetzen. Um das Leistungsangebot des Assistenzsystem zu vervollständigen könnte
35
man auch über Interaktions- und Kommunikationsmöglichkeiten zwischen mehreren Nutzern nachdenken. Message Boards könnten den Erfahrungsaustausch fördern, ein ChatProgramm oder eine Sprachverbindung zu anderen angemeldeten Nutzern könnten eine
entstehende Gemeinschaft unterstützen.
Durch dieses Medienprojekt haben sich die Zugangsbarrieren für Menschen mit Behinderungen zum Campus der TU Ilmenau nicht in Luft aufgelöst. Einige Probleme mit dem
Programm auf dem Endgerät bestehen weiterhin. In der Projektarbeit sind jedoch Konzepte und Lösungen entstanden, die, prototypisch implementiert, erahnen lassen, welches
Potential eine barrierefreies Assistenzsystem in sich birgt.
36
Literaturverzeichnis
[Akt03]
Freizeit und Sport, gleichberechtigte Teilnahme am öffentlichen Leben.
http://www.familienratgeber.de/ratgeber/seite_6975.
html; 30.12.2003.
[Bab98]
BABER , C HRIS ET AL .: Preliminary Investigations into the Use of Wearable
Computers. In: J OHNSON , H ILARY ET AL . (Eds.): People and Computers
XIII, Proceedings of HCI ’98. Springer, London, 1998, 313–325.
[Bor03]
B ORNTR ÄGER , C HRISTIAN: Contextual Influence on the Usability of Different Media Types. Diplomarbeit, TU Ilmenau, 2003.
[Che03]
C HEVERST, K EITH ET AL .: Developing a Context-aware Electronic Tourist
Guide: Some Issues and Experiences. http://www.guide.lancs.ac.
uk/CHIpaper.pdf; 26.11.2003.
[Chr03]
C HRISTE , JAN UND P ETER -M ICHAEL Z IEGLER ,: Richtungsweisend.
Satelliten-Navigation mit dem PDA. In: c’t 1/2003, 142–149.
[Edw95]
E DWARDS , A LISTAIR D. N.: Computers and people with disabilities. In:
E DWARDS , A LISTAIR D. N. (Ed.): Extra-ordinary human-computer interaction: interfaces for users with disabilities. Cambridge University Press, New
York, 1995, 19–43.
[Epl03]
Location Based Services per i-Mode. http://www2.eplus-imode.
de/1/de/html/pub/marketing/start_fs.html; 26.11.2003.
[Esm03]
Mass Market Java Solutions for Mobile and Embedded Devices. http://
www.esmertec.com/; 30.11.2003.
[Fis02]
F ISHKIN , K ENNETH P. ET AL . Wireless User Interface Components for Personal Area Networks. In: Pervasive Computing 4/2002, 49–55.
[Fli03]
Flite: a small, fast run time synthesis engine. http://www.speech.cs.
cmu.edu/flite/; 30.11.2003.
[Hol03]
H OLLAND , S IMON ET AL . The application of Direct Combination to Mobile
and Ubiquitous Human Computer Interaction. http://mcs.open.ac.
uk/sh2/Ambient%20Combination%20TR.pdf; 13.12.2003.
[HO99]
H OLLAND , S IMON AND DANIEL O PPENHEIM: Direct Combination. In:
W ILLIAMS , M ARIAN G. ET AL . (Eds.): The CHI is the limit. Human factors in computing systems; CHI 99 conference proceedings. ACM Press, New
York, 1999, 262–269.
37
[Kun99]
K UNO , YOSHINORI ET AL .: Combining Observations of Intentional and
Unintentional Behaviors for Human-Computer Interaction. In: W ILLIAMS ,
M ARIAN G. ET AL . (Eds.): The CHI is the limit. Human factors in computing systems; CHI 99 conference proceedings. ACM Press, New York, 1999,
238–245.
[Kal02]
K ALAWSKY, R. S.: Interface Issues for Wearable and Mobile Computer
Users. In: E ARNSHAW, R AE AND J OHN V INCE (Eds.): Intelligent Agents
for Mobile and Virtual Media. Springer, London, 2002, 8–27.
[LG01]
L OOMIS , JACK M. AND R EGINALD G. G OLLEDGE: GPS-Based Navigation Systems for the Visually Impaired. In: BARFIELD , W OODROW AND T HO MAS C AUDELL (Eds.): Fundamentals of wearable computers and augmented
reality. Lawrence Erlbaum Associates, Mahwah, 2001, 429–446.
[Lie97]
L IEBERMANN , H ENRY: Autonomous Interface Agents. In: P EMBERTON ,
S TEVEN (Ed.): Human factors in computing systems. Looking to the future.
CHI 97. Addison–Wesley, Reading, 1997, 67–74.
[Lon99]
L ONG , A LLAN C. ET AL .: Implications For a Gesture Design Tool In: W IL LIAMS , M ARIAN G. ET AL . (Eds.): The CHI is the limit: Human factors in
computing systems. CHI 99 conference proceedings. ACM Press, New York,
1999, 40–47.
[Lue03]
L ÜDERS , DANIEL: Gut entwickelt. Aktuelle PDAs im Vergleich. In: c’t special Handhelds, 2003, 6–19.
[Lyn03]
Textbrowser for the World Wide Web. http://lynx.browser.org/;
30.11.2003.
[MoB03]
MoBIC Homepage. http://isgwww.cs.uni-magdeburg.de/
projects/mobic/mobicde.html; 26.11.2003.
[Nav03]
NaviGate, Telematikdienst von T-Mobile. http://www.t-mobile.de/
navigate/; 26.11.2003.
[New95]
N EWELL , A LAN F.: Extra-ordinary human-computer interaction. In: E D A LISTAIR D. N. (Ed.): Extra-ordinary human-computer interaction: interfaces for users with disabilities. Cambridge University Press, New
York, 1995, 3–18.
WARDS ,
[Ovi01]
OVIATT, S HARON ET AL .: Designing the User Interface for Multimodal Speech and Pen-Based Gesture Applications: State-of-the-Art-Systems
and Future Research Directions. In: C ARROLL , J OHN M. (Ed.): HumanComputer Interaction in the New Millennium. ACM Press, New York, 2002,
421–456.
[Ope03]
OpenNETCF.org Multimedia Library Open-Source Project. http://www.
opennetcf.org/multimedia.asp; 13.12.2003.
[Pet97]
P ETRIE , H ELEN ET AL .: User-centred design in the development of a navigational aid for blind travellers. In: H OWARD , S TEVE ET AL . (Eds.): HumanComputer Interaction: INTERACT ’97. Chapman & Hall, London, 1997,
220–227.
38
[Pop02]
P OPSCHIL , G ÜNTHER ET AL .: Designing LoL@, a mobile Tourist Guide
for UMTS. In: PATERN Ò , FABIO (Ed.): Human Computer Interaction with
Mobile Devices. 4th International Symposium, Pisa, Italy. Springer, Berlin,
2002, 140–154.
[PE03]
P ITT, I AN AND A LISTAIR E DWARDS: Design of speech-based devices: a
practical guide. Springer, London, 2003.
[Rek01]
R EKIMOTO , J UN: NaviCam: A Palmtop Device Approach to Augmented Reality. In: BARFIELD , W OODROW AND T HOMAS C AUDELL (Eds.): Fundamentals of wearable computers and augmented reality. Lawrence Erlbaum
Associates, Mahwah, 2001, 354.
[Sta02]
S TARNER , T HAD E.: Attention, Memory, and Wearable Interfaces. In: Pervasive Computing 4/2002, 88–91.
[Sup03]
SuperWaba – Java Virtual Machine. http://www.superwaba.com.
br/; 26.11.2003.
[Tia03]
T IAN , M IN: Abgespeckt; .Net Compact Framework für mobile Geräte. In: iX
10/2003, 86.
[Tid03]
European Union: An evaluation of the Bridge phase of TIDE (Technology for Disabled and Elderly People). http://europa.eu.
int/information_society/programmes/evaluation/pdf/
reporttide_en.pdf; 30.11.2003.
[Vod03]
Vodafone
Street
Guide.
http://www.vodafone.de/
kundenbetreuung_services/unterwegs/31534.html;
26.11.2003.
[WAI03]
Web Accessibility
26.11.2003.
[Wir02]
W IRTGEN , J ÖRG: Pocket PC für Blinde. In: c’t 26/2002, 22
[WoB03]
Aktionsbündnis für barrierefreie Informationstechnik – AbI. http://www.
wob11.de/index.html; 30.11.2003.
Initiative
39
(WAI).
http://www.w3c.org/WAI;
Abbildungsverzeichnis
2.1
Übersicht über die einzelnen Themen des Teamprojekts Barrierefreier
Campus. Quelle: eigene Abbildung . . . . . . . . . . . . . . . . . . . . .
6
3.1
Modell einer Mensch-Maschine-Schnittstelle. Quelle: eigene Abbildung .
7
3.2
Behinderung durch die Umwelt. Ein Soldat in der Schlacht. Quelle:
[New95, S. 9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Anpassung von Nutzerschnittstellen an spezielle Bedürfnisse, Quelle:
nach [Edw95, S. 22–25]. . . . . . . . . . . . . . . . . . . . . . . . . . .
12
5.1
Screenshot der Benutzeroberfläche. Quelle: eigene Abbildung . . . . . .
25
5.2
Struktur des Programms auf dem Endgerät. Quelle: eigene Abbildung . .
27
5.3
Approximation der Wegkanten. Quelle: eigene Abbildung . . . . . . . .
29
5.4
Das Compact Framework unterstützt nur die Klassen, die blau unterlegt
sind. Quelle: nach [Tia03] . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3
40
Tabellenverzeichnis
4.1
Anforderungen an Endgeräte Quelle: eigene Tabelle . . . . . . . . . . . .
21
A.1 Mobiltelefone Quelle: c’t special Handhelds [Lue03] . . . . . . . . . . .
44
A.2 Palm OS PDAs. Quelle: c’t special Handhelds [Lue03] . . . . . . . . . .
45
A.3 Windows CE PDAs. Quellen:c’t special Handhelds [Lue03]; http://
www.hewlett-packard.de . . . . . . . . . . . . . . . . . . . . . .
46
A.4 Sonstige Endgeräte Quellen: http://www.skeye.com; http://
www.siemens.de . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
41
Abkürzungsverzeichnis
BaFreiCa
Barrierefreier Campus
CF
Compact Flash
CPU
Central Prozessing Unit
DGPS
Differential Global Positioning System
DSTN
Double Super Twisted Nematic
Flite
Festival Light
GIS
Geographic Information System
GPRS
General Packet Radio Service
GPS
Global Positioning System
IrDA
Infra-red Data Association
JRE
Java Runtime Environment
LED
Light Emitting Diode
MDA
Mobile Digital Assistant
MMC
Multi Media Card
PCMCIA
Personal Computer Memory Card International Association
PDA
Personal Digital Assistant
POI
Point of Interest
RAM
Random Access Memory
ROM
Read Only Memory
SD
Secure Digital Card
SOAP
Simple Object Access Protocol
TFT
Thin Film Transistor
TTS
Text To Speech
42
ULV
Ultra Low Voltage
VM
Virtual Machine
WGS84
World Geodetic System 1984
WinAPI
Windows Application Program Interface
WLAN
Wireless Local Area Network
WPAN
Wireless Personal Area Network
XML
Extensible Markup Language
43
Anhang A
Liste der recherchierten Endgeräte
Diese Zusammenstellung von Endgeräten kann keine Marktübersicht leisten. Vielmehr
sollen aus den Endgeräteklassen typische Vertreter mit ihren speziellen Eigenschaften vorgestellt werden. In Tabelle A.1 werden Mobiltelefone aufgeführt. Tabellen A.2 und A.3
zeigen verschiedene PDAs. In Tabelle A.4 sind neben den Webpads zum Vergleich die
technischen Daten eines Notebooks und eines Tablet PC der Marke Fujitsu-Siemens angeführt.
Display-Beleuchtung
Maße (BxHxT) [mm3 ]
Gewicht [g]
Laufzeit
Dateneingabe
M OBILTELEFONE
Nokia 9210i
Symbian OS
8 MB RAM,
16 MB Flash-ROM
ARM9-basiert
MMC
ja
ja
ja
–
–
640 x 200 Pixel,
12 Bit Farbtiefe
ja
59 x 158 x 28
244
5,6 h (PDA-Dauerbetrieb)
QWERTZ-Tastatur
Alarmsignale
akustisch
System
Speicher
CPU
Erweiterungsslots
Kopfhörer-Anschluss
Mikrofon
IrDA
Bluetooth
WLAN
Display
Sony Ericsson P800
Symbian OS
16 MB RAM
16 MB Flash-ROM
ARM9-basiert
Memory Stick Duo
ja
ja
ja
ja
–
640 x 480 Pixel,
12 Bit Farbtiefe
ja
59 x 117 x 27
159
5,2 h (PDA-Dauerbetrieb)
Software-Tastatur,
JotPro
Vibration, akustisch
Tabelle A.1: Mobiltelefone Quelle: c’t special Handhelds [Lue03]
44
45
Alarmsignale
Navigation
Display-Beleuchtung
Gewicht [g]
Laufzeit mit/ohne Licht
Dateneingabe
Erweiterungsslots
Mikrofon
IrDA
Bluetooth
WLAN
Display
CPU
System
Speicher
akustisch
Jog-Dial,
4 Applikationstasten,
Rücktaste
LED,
Tonauswahl
Sony Clié PEG-SJ33
Palm OS 4.1
16 MB RAM,
4 MB Flash-ROM
Motorola Dragonball,
66 MHz
Memory Stick
ja
–
ja
–
–
Transflexiv-Display,
320 x 320 Pixel,
16 Bit Farbtiefe
ja
103 x 71 x 15
133
5,5 h/13 h
Software-Tastatur,
Graffiti
Tabelle A.2: Palm OS PDAs. Quelle: c’t special Handhelds [Lue03]
Up-/Down-Taste,
4 Applikationstasten
Palm m130
Palm OS 4.1
8 MB RAM,
2 MB ROM
Motorola Dragonball,
33MHz
SD, MMC
–
–
ja
–
–
DSTN-Display,
160 x 160 Pixel,
12 Bit Farbtiefe
ja
122 x 78 x19
184
4,5 h/–
Software-Tastatur,
Graffiti
PALM OS PDA S
Palm m515
Palm Tungsten T
Palm OS 4.1
Palm OS 5
16 MB RAM,
16 MB RAM,
4 MB ROM
8 MB Flash-ROM
Motorola Dragonball, TI OMAP 144MHz
33MHz
SD, MMC
SD, MMC
–
ja
–
ja
ja
ja
–
ja
–
–
Reflektiv-Display,
Reflektiv-Display,
160 x 160 Pixel,
320 x 320 Pixel,
16Bit Farbtiefe
16Bit Farbtiefe
ja
ja
114 x 81 x 13
100 x 73 x 15
146
157
3,5 h/20 h
3,4 h/6,5 h
Software-Tastatur,
Software-Tastatur,
Graffiti
Graffiti,
Voice Recording
Up-/Down-Taste,
Navigationskreuz,
4 Applikationstasten 4 Applikationstasten,
Aufnahmetaste
Vibration, LED,
Vibration, LED,
akustisch
akustisch
Sony Clié PEG-NZ90
Palm OS 5
16 MB RAM,
16 MB Flash-ROM
Intel PXA250 XScale,
200MHz
Memory Stick
ja
ja
ja
ja
–
320 x 480 Pixel,
16 Bit Farbtiefe
ja
140 x 76 x 30
296
3,2 h/8,5 h
Hardware-Tastatur,
Software-Tastatur,
Graffiti virtuell
Jog Dial,
Rück- und Haltetaste
LED,
Tonauswahl
46
LED, Tonauswahl
LED, Tonauswahl
LED, Tonauswahl
Toshiba e740 WIFI
Pocket PC 2002
64 MB RAM,
32 MB Flash-ROM
400 MHz
SD, MMC, CF-Typ II
ja
ja
ja
–
ja
Reflektiv-Display,
320 x 320 Pixel,
16 Bit Farbtiefe
ja
125 x 80 x 16
171
2,2 h/7,1 h
Handschrift,
Software-Tastatur,
Voice Recorder
Steuerkreuz,
Aufnahmetaste,
Scrollrad
LED, Tonauswahl
Toshiba e330
Pocket PC 2002
64 MB RAM,
32 MB Flash-ROM
300 MHz
SD, MMC
ja
ja
ja
–
–
Reflektiv-Display,
240 x 320 Pixel,
16 Bit Farbtife
ja
125 x 79 x 15
134
5 h/13 h
Handschrift,
Software-Tastatur,
Voice Recorder
Steuerkreuz,
Aufnahmetaste,
Scrollrad
LED, Tonauswahl
Tabelle A.3: Windows CE PDAs. Quellen:c’t special Handhelds [Lue03]; http://www.hewlett-packard.de
Alarmsignale
Navigation
Display-Beleuchtung
Gewicht [g]
Laufzeit mit/ohne Licht
Dateneingabe
Erweiterungsslots
Mikrofon
IrDA
Bluetooth
WLAN
Display
CPU
System
Speicher
Compaq iPAQ 36xx
Pocket PC 2000
32 MB RAM
16 MB Flash-ROM
Intel StrongARM
206 MHz
–
ja
ja
ja
–
–
240 x 320 Pixel,
16 Bit Farbtiefe
ja
130 x 83,5 x 15,9
170
k.A.
Handschrift,
Software-Tastatur,
Voice Recorder
Steuerkreuz,
Aufnahmetaste
W INDOWS CE PDA S
HP iPAQ H5450
Siemens Pocket Loox 600
Pocket PC 2002
Pocket PC 2002
64 MB RAM,
64 MB RAM,
48 MB Flash-ROM
32 MB Flash-ROM
Intel PXA250 XScale, Intel PXA250 XScale,
400 MHz
400 MHz
SD, MMC
SD, MMC, CF-Typ II
ja
ja
ja
ja
ja
ja
ja
ja
ja
–
Reflektiv-Display,
240 x 320 Pixel,
240 x 320 Pixel,
16 Bit Farbtiefe
16 Bit Farbtiefe
ja
ja
131 x 82 x 16
132 x 82 x 17
201
171
4,5 h/12,4 h
3,5 h/7,9 h
Handschrift,
Handschrift,
Software-Tastatur,
Software-Tastatur,
Voice Recorder
Voice Recorder
Steuerkreuz,
Steuerkreuz,
4 Applikationstasten, 4 Applikationstasten,
Aufnahmetaste
Scrollrad
47
Alarmsignale
Navigation
TABLET PC
Fujitsu-Siemens ST4120
WindowsXP Tablet PC ed.
256 MB–76 8MB RAM,
Festplatte
Intel PII ULV,
933MHz
PCMCIA-Typ I oder Typ II
ja
ja
–
–
ja
10,4“ TFT,
1024 x 768 Pixel,
24 Bit Farbtiefe
ja
301 x 220 x 21
ca. 1450
k.A.
Handschrift,
Software-Tastatur
Navigationstasten,
Anwendungstasten
LED, Tonauswahl
LED, Tonauswahl
N OTEBOOK
Fujitsu-Siemens Lifebook S Series
Windows XP
256–1024 MB RAM,
Festplatte
Intel Pentium M,
1,6 GHz
PCMCIA Typ I/II
ja
ja
ja
ja
ja
13,3“ TFT,
1024 x 768 Pixel,
24 Bit Farbtiefe
ja
293 x 236 x 34
1700
3,7 h
Tastatur,
Touch Pad
Tastatur
Tabelle A.4: Sonstige Endgeräte Quellen: http://www.skeye.com; http://www.siemens.de
Display-Beleuchtung
Gewicht [g]
Laufzeit
Dateneingabe
Erweiterungsslots
Mikrofon
IrDA
Bluetooth
WLAN
Display
CPU
System
Speicher
W EB PADS
Skeye Webpad
Siemens SIMpad SL4
Windows CE.NET
WinCE 3.0 (HPC 2000)
32 MB RAM,
64 MB RAM,
32 MB Flash-ROM
32 MB Flash-ROM
Intel StrongARM,
Intel StrongARM,
206MHz
206MHz
PCMCIA-Typ II, CF-Typ II PCMCIA-Typ II
ja
ja
ja
k.A.
ja
ja
–
–
–
–
8,2“ DSTN,
8,4“ TFT,
800 x 600 Pixel,
800 x 600 Pixel,
16 Bit Farbtiefe
16 Bit Farbtiefe
ja
ja
240 x 160 x 30
263 x 180 x 28
900
1000
6–8 h
k.A.
Handschrift,
Handschrift,
Software-Tastatur
Software-Tastatur
–
Steuerkreuz,
Auswahltaste
Tonauswahl
LED, Tonauswahl

Medienprojekt - Homepage Fachgebiet Kommunikationsnetze

Transcription

Similar documents

Fun, Secure, Embedded

Entwicklung eines künstlichen Horizonts für kleine unbemannte

Leseprobe - GABAL Verlag

„Ziel speichern unter …“, um ein PDF

P4S800-MX

Anschlüsse und Bedienelemente