Medienprojekt ” - TU Ilmenau

Medienprojekt
” BARRIEREFREIER CAMPUS: MOBILE
ENDSYSTEME. BENUTZERSCHNITTSTELLE ZUR
NAVIGATION FÜR MOBILE ENDGERÄ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 für Kommunikations- und Messtechnik
Technische Universitä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
3.5 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
4 Systementwurf und Vorgehensweise 18
4.1 Nutzungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Zielnutzergruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Gesamtentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Technische Berührungspunkte mit anderen Teilprojekten . . . . . . . . . 19
4.5 Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1

5 Programmentwicklung 23
5.1 Wahl der Programmiersprache . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.2 .NET Compact Framework . . . . . . . . . . . . . . . . . . . . . 24
5.2 Design der Nutzerschnittstellen . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1 Nutzerschnittstelle für Sehende . . . . . . . . . . . . . . . . . . 24
5.2.2 Nutzerschnittstelle für Blinde . . . . . . . . . . . . . . . . . . . 25
5.2.3 Allgemeine und geräteabhängige Teile der Nutzerschnittstelle . . 26
5.3 Programmstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1 Funktionsblöcke . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.2 Zeitliche Abläufe . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4 Klassen und Komponenten des Programms auf dem Endgerä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
5.5 Probleme bei der Implementation . . . . . . . . . . . . . . . . . . . . . . 30
5.5.1 Sprachsynthese . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5.2 Hardware-Tasten und Sound-Ausgabe . . . . . . . . . . . . . . . 30
6 Demonstrationsprogramme 32
6.1 WgsToXY – Ansatz für den Spaziermodus . . . . . . . . . . . . . . . . . 32
6.2 User Interface fü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
7 Ausblick 35
Literaturverzeichnis 37
Abbildungsverzeichnis 40
Tabellenverzeichnis 41
Abkürzungsverzeichnis 42
A Liste der recherchierten Endgeräte 44
2

Kapitel 1
Einleitung
” Nichts über uns und nichts ohne uns“ – mit diesem Motto hat der Rat der Europäischen
Union das Jahr 2003 zum Jahr der Menschen mit Behinderung ausgerufen. Ziel ist ein
Loslösen von Diskriminierung und Bevormundung hin zu Teilhabe und Selbstbestimmung
von Menschen mit Behinderungen. Die Lebensbedingungen mit und fü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 Geräten im Alltag nicht einfach. Oft
stehen technische Funktionen und nicht der Fokus auf künftige Nutzer bei der Entwicklung
im Vordergrund, selten werden Menschen mit Behinderungen als Nutzer bedacht. So
bestehen für sie besondere hohe Nutzungsbarrieren bezüglich Nutzerschnittstellen und
Technik. Menschen mit Behinderung sind oft sogar von der Nutzung bestimmter Systeme
ganz ausgeschlossen. So können beispielsweise Geldautomaten von einem Großteil der
Bevölkerung ohne Probleme genutzt werden, für Rollstuhlfahrer oder blinde Menschen
sind sie jedoch an vielen Orten nicht erreichbar beziehungsweise nicht bedienbar.
Der gezielte Einsatz von Technik kann für Menschen mit Behinderungen jedoch auch positive
Effekte bewirken. Die Nutzung von Technik kann dazu dienen, Einschränkungen
durch eine Behinderung zu mildern oder im Idealfall ganz zu kompensieren. Eine
technische Hilfe kann dann als Prothese bezeichnet werden, die Einschränkungen aufhebt
[Edw95, S. 22]. Viele Geräte erleichtern so das Leben von Menschen mit Behinderungen
in großem Maße, und ermöglichen ein Stück Freiheit: So gibt es zum Beispiel
Sprach-Computer, die über Symbole bedient werden,die auf einem Tastenfeld angeordnet
sind. Solche Sprach-Computer erzeugen zuvor aufgenommene oder synthetisierte Sprache.
Für einen Menschen mit einer tonischen Spastik, der zwar seine Mitmenschen versteht,
sich aber nicht artikulieren kann, ermöglicht diese Technik die Kommunikation mit
seiner Umwelt. Der pedalfreie PKW hebt während des Autofahrens die Einschränkungen
einer Beinlähmung auf. Weitere Beispiele fü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
können. Sie sind speziell auf die verschiedenen, individuellen Bedürfnisse der Nutzer
zugeschnitten.
Solche positiven Effekte durch Technikeinsatz sind gerade auch im Urlaubs- oder im
Freizeitbereich wünschenswert. Die Freizeitgestaltung hat besonders auch für behin-
3

derte Menschen einen hohen Stellenwert. Sie dient der Selbstfindung, der kreativen
Persönlichkeitsentfaltung und der sozialen Integration [Akt03]. Freizeit und Freiheit
gehören eng zusammen. Freizeit als Freiheit von Alltagszwängen und Leistungsdruck
sollte deshalb selbstbestimmt erlebt werden können. Gerade im Freizeitbereich ist es deshalb
wichtig, dass Zugangsbarrieren für Menschen mit Behinderungen abgebaut werden.
Das gilt zum Beispiel für Besichtigung von Sehenswürdigkeiten, für das selbständige Erkunden
einer neuen Umgebung ohne Begleitung oder das Erreichen von Wegzielen ohne
Umwege. In einer individualistischen Gesellschaft wie der unseren ist Mobilität für alle
Menschen ein hohes Gut.
Diese Mobilität wird unterstützt durch kleine elektronische Helfer, die unseren Alltag erobern.
Fü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 Leistungsfähigkeit dieser Geräte
beginnen neue Anwendungen und Dienste wie lokationsabhängige Dienste zu entstehen.
Sie bieten dem Nutzer gezielt Informationen und Dienste an, die abhängig vom Aufenthaltsort
des Nutzers sind.
Für Menschen mit Behinderungen können solche Systeme der Schlüssel sein, ihre Freizeit
selbständig und selbstbestimmt zu erleben. Dazu ist es notwendig, dass diese lokationsabhängigen
Dienste auf die Bedürfnisse der Nutzer individuell abgestimmte Inhalte
anbieten und dass die Nutzerschnittstellen barrierefrei gestaltet werden. Barrierefreiheit
verlangt dabei die Erfüllung zweier zunächst gegensätzlich erscheinender Anforderungen:
Erstens eine Lösung ” für alle“ und zweitens gleichzeitig individuelle Lösungen ” für jeden
einzelnen“. Technische Systeme dieser Art sollen also so konzipiert sein, dass Menschen
mit den unterschiedlichsten Voraussetzungen potentielle Nutzer sein können. Diese Konzepte
integrieren individuelle Bedürfnisse behinderter Menschen in Alltagstechnik, das
heisst barrierefreie Systeme stehen für Integration.
Das Medienprojekt Barrierefreier Campus ist der Versuch einen Schritt in die aufgezeigte
Richtung zu gehen. Der Campus der Technischen Universität Ilmenau bietet das Versuchsfeld
fü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 für Besucher des Campus der Technischen Universität
Ilmenau. Basierend auf einer Client-Server-Architektur bietet es dem Nutzer lokationsabhängige
Dienste, wie Wegsuche und Informationsdienste zu Details von Wegstrecke
und Gebäuden, auf einem mobilen Endgerät an. Teilprojekt 7 beschäftigt sich dabei mit
der Implementierung der Nutzerschnittstelle. Besonderes Augenmerk bei der Konzeption
gilt der Barrierefreiheit, also der möglichst vollständigen Vermeidung von Zugangsbarrieren
für Menschen mit Behinderungen, sowie der Wiederverwendbarkeit des Systems
in einem erweiterten Kontext als touristisches Assistenzsystem für die gesamte Region
Thü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 über die Nutzerprofile und Wegdatenerstellung bis zur Anpassung für
die Endgeräte und schließlich der Präsentation der Daten auf einem mobilen Endgerät ab.
Letzteres ist Aufgabe des Teilprojekts 7, Programm auf dem Endgerät, dessen Hauptbestandteil
die Konzeption und Implementation der Nutzerschnittstelle für das Gesamtprojekt
ist. Abbildung 2.1 zeigt eine Übersicht aller Teilprojekte sowie deren Themengebiete.
2.2 Aufgabenstellung Teilprojekt 7
Im Teilprojekt 7 soll eine Nutzerschnittstelle für mobile Endgerä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 Endgeräten,
• Konzipierung einer modularen Nutzerschnittstelle:
5

– zum Abfragen einer Navigationshilfe gemäß festgelegter Optionen unter Zuhilfenahme
verschiedener Möglichkeiten zur Lokalisierung,
– zur Darstellung der von der Datenbank / dem Anpassungsmodul kommenden
Navigationsinformationen,
• Aufteilung der Nutzerschnittstelle in einen allgemeinen und einen
geräteabhängigen Teil,
• Implementierung des Konzepts auf einem beliebigen tragbaren Endgerät.
Theoretische Grundlagen zu Nutzerschnittstellen werden in Kapitel 3 behandelt. Die Evaluierung
und Klassifizierung möglicher Endgeräte wird zusammen mit Systementwurf
und Nutzungsszenarien sowie der Konzipierung der modularen Nutzerschnittstelle und
deren Aufteilung in allgemeine und geräteabhängige Teile in Kaptitel 4 behandelt. Eine
Tabelle der evaluierten Endgeräte ist in Anhang A angefertigt. Kapitel 5 beschreibt
die Implementierung der Nutzerschnittstelle und das Programm auf dem Endgerä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: Übersicht ü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 näher beleuchtet werden. Eine genaue Auseinandersetzung mit
den Nutzergruppen, die nähere Betrachtung der Technologie sowie des Kontexts der Interaktion
geben Anhaltspunkte für das Design des Programms auf dem Endgerät. Die
untenstehende Abbildung 3.1 zeigt das grundlegende Modell einer Mensch-Maschine-
Kommunikation. Ein Mensch hat über die Nutzerschnittstelle Zugriff auf eine bestimmte
Technik. Oder anders gesagt: Diese Technik bietet dem Nutzer Dienste über das User
Interface an. Stö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 möglichst genaue Kenntnis der Nutzergruppen,
der zur Verfügung stehenden Technik sowie der Situation oder der Umwelt, in der
die Techniknutzung stattfindet, voraus. In Abschnitt 3.1 soll daher die Frage geklärt werden,
in wie weit die Nutzergruppe aus Designersicht definiert werden kann und welche
Fähigkeiten sowie Einschränkungen auf Nutzerseite zu beachten sind. Welche besonderen
Voraussetzungen sich vor allem bei mobilem Technikeinsatz sowie der gleichzeitigen
7

Ausführung mehrerer Aufgaben ergeben, soll Abschnitt 3.2 beleuchten. Abschnitt 3.3
beschäftigt sich mit der Nutzerschnittstelle selbst vor allem unter der Voraussetzung einer
sehr heterogene Nutzergruppe. Ein- und Ausgabetechniken für mobile Endgeräte sowie
Nutzerschnittstellenkonzepte werden kurz im Abschnitt 3.4 vorgestellt. Schließlich sollen
im Abschnitt 3.5 bestehende Systeme vorgestellt werden, die zum einen lokationsabhängige
Dienste für den Tourismus und zum anderen Navigationshilfen für behinderte
Personen anbieten.
3.1 Nutzergruppe
Bei der Softwareentwicklung wird meist von einer sehr homogenen Nutzergruppe ausgegangen.
Der Nutzer“ ist für viele Programmierer eine gewöhnliche Person mit durch-
”
schnittlichen Fähigkeiten. Diese realitätsferne Annahme lässt sich sehr gut mit dem fiktiven
Schuhgeschäft ’Software-Schuh’ veranschaulichen. Hier gibt es zwar Schuhe in
vielen Modellen und Farben zu kaufen, allerdings sind sie ausnahmslos auf den durchschnittlichen
Fuß, Größ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
Bedürfnisse der Nutzer. Ergebnis eines solchen Designs ist nicht selten eine Software,
von der man den Eindruck hat, dass sie für den 25-jährigen männlichen Computerexperten
geschrieben wurde. Eine willkürliche, ungenaue Unterteilung in Anfänger“- und
”
” Experten“-Modi hilft dem Nutzer in einem solchen Fall meist auch nicht weiter.
Im Gegensatz dazu kö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 Bedürfnisse ihrer Zielgruppe fokussiert sein,
dass Designgrundsätze oder grundlegende Ästhetik missachtet werden und die Zielgruppe
dadurch weiter stigmatisiert wird. So gibt es etwa genügend speziell für behinderte
Menschen entwickelte Haushaltsgeräte, die so hä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 auffällige Platzierung
von technischem Gerät aus der Gruppe der Besucher des Campus herausstechen.
Um Denkanstöße fü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 gewöhnliche Fähigkeiten und außergewöhnliche
Fähigkeiten ( ” everyone has ordinary and extra-ordinary abilities“)
Ein grundlegendes Missverständnis bei der Diskussion über Nutzergruppen ist die
rein binäre Aufteilung in die Gruppen Behinderte und Nichtbehinderte. Plakative
Darstellungen unterstü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 für eine Bewegungseinschränkung verwenden. Dennoch sind
die Unterschiede innerhalb dieser Gruppe groß. Die Fähigkeit, auf einem schmalen
Weg umzukehren, wird schon von der Bauform des Rollstuhls vorgegeben, da
diese den Wendekreis bestimmt. Während die einen selbst hohe Stufen meistern
8

können, bleibt für andere eine abgesenkte Bordsteinkante eine unüberwindbare Barriere.
Zudem hat die Gruppe der Rollstuhlfahrer eine ebenso große Bandbreite an
physikalischen, sensorischen und kognitiven Fähigkeiten wie andere Gruppen auch.
Wenn man also genau hinschaut, hat jeder Mensch eine Reihe von Fähigkeiten, die
als ” normal“ gelten und andere, die offensichtlich von der Norm abweichen. So haben
große Teile der Gesellschaft eine Sehschwäche, viele, vor allem alte Menschen,
sind schwerhörig und einige sind physisch schwächer als andere. Jeder einzelne
Mensch hat unterschiedliche kognitive Fähigkeiten sowie verschiedene kulturelle,
politische und religiöse Ansichten.
2. Außergewöhnliche Bedürfnisse sind nur verstärkte gewöhnliche Bedürfnisse
( ” Extra-ordinary needs are only exaggerated ordinary needs“)
In den meisten Fällen unterscheiden sich von der Norm abweichende Bedürfnisse
und Fähigkeiten nicht in ihrer Qualität, sondern vielmehr in der Quantität. So bedeutet
ein Tremor nicht, dass der Mensch überhaupt keine motorische Kontrolle
über seine Gliedmaßen hat, sondern eben weniger. Menschen, die eine Lernbehinderung
haben, können sich eventuell schlecht Daten, Namen und Dinge merken –
Symptome, die gleichwohl auch bei durchschnittlich befähigten Personen in einer
abgeschwächten Form unter Stress auftreten können.
3. Personen werden durch ihre Umwelt eingeschränkt ( ” People are handicapped
by their environments“)
Die Fähigkeiten des Menschen sind nicht statischer Natur. Sie verändern sich über
die Zeit und hängen stark von den Einflüssen unserer Umgebung ab. So ist Behinderung
nicht als Abwesenheit von Fähigkeiten zu sehen, sondern kann als Umwelteinfluss
auf den Menschen interpretiert werden. Umgebungslärm kann zum
Beispiel wie Schwerhörigkeit wirken und temporä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 Sicherheitsanzügen
mit Handschuhen führen zu taktiler und motorischer Unsicherheit; Stress
oder Übermüdung können zur Verringerung der kognitiven Fähigkeiten führen. Ein
extremes Beispiel fü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 Lärm der Geschütze betäubt, steckt bis zu
den Knien im Schlamm und ist vor Todesangst fast gelähmt.
4. Begrenzte Bandbreite ( ” Bandwidth Limitations“)
Der effiziente Umgang mit beispielsweise einem Textverarbeitungsprogramm setzt
eine gewisse Anschlagsgeschwindigkeit für die Texteingabe voraus. Diese kann,
bedingt durch eine Einschränkung des Nutzers, sehr langsam sein. Die Bandbreite,
in diesem Kontext die Menge an Information, die der Nutzers über die Tastatur
übermitteln kann, reicht fü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 mü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 Flugmanöver, sä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 genügend Hände’ .In solchen ” high workload environments“
können zusä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 fü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
größere Auswirkungen auf die Qualität der Interaktion. Wenn man einen Bildschirmarbeitsplatz
betrachtet, ist der störende Einfluss der Umwelt gering. Der Nutzer sitzt in optimaler
Position vor Tastatur und Monitor, hat es meist warm und ist durch ein Gebäude
vor Wettereinflüssen geschü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 Gerät vor, kann man sich leicht Faktoren denken, die die Mensch-
Maschine-Interaktion stören. Helles Sonnenlicht macht das Display schwer ablesbar, Umgebungslärm
übertönt eine Sprachausgabe, oder der Nutzer wird angerempelt und die Dateneingabe
über einen Touch Screen misslingt. In einem solchen mobilen Umfeld kann
10

einem technischen Gerät immer nur ein Teil der Aufmerksamkeit zukommen, da der Nutzer
zwei Aufgaben simultan erledigen muss, beispielsweise die Bedienung des Gerä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 Fähigkeiten
ergänzen und nicht mit ihnen interferieren. Die Tätigkeit des Menschen sollte von dem
mobilen Gerät unterstü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 mühsamen Computeroperationen herumschlagen müssen, wenn ein
” real world task“ ausgeführt wird. Letztendlich sollte der Aufwand, ein zusätzliches Gerät
zu bedienen, so gering sein, dass der zusätzliche Nutzen durch dieses klar überwiegt.
Ein Beispiel für das gleichzeitige Ausfü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 ermöglichen
dies: Zum einen ist Autofahren eine höchst visuelle Angelegenheit, die zwar gleichzeitig
auditive Kommunikation zulässt, nicht aber weitere visuelle Tätigkeiten, wie zum Beispiel
gleichzeitiges Fernsehen. Zum anderen hat der Fahrer die nötigen Handgriffe zur
Steuerung des Autos schon so oft ausgeführt, dass sie automatisiert sind und keiner besonderen
Aufmerksamkeit mehr bedürfen. Das Problem der geteilten Aufmerksamkeit
fü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 können mit etwas Übung Texte eingeben,
ohne über einzelne Strichfolgen oder Tastenanschläge nachzudenken.
Beim Barrierefreien Campus handelt es sich um ein Assistenzsystem für den Tourismus.
Die Nutzer wollen ihr Reiseziel kennen lernen und die Umgebung erkunden. Das Gerät
sollte daher ein leicht erlernbares Interface haben, das unerfahrene Nutzer und Nutzer mit
Einschränkungen nicht überfordert. Im Idealfall steht es unterstützend zur Seite, wenn
dies gewünscht ist.
3.3 Mensch-Maschine-Schnittstelle
Nutzerschnittstellen bieten den Menschen die Mö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 unnütz
wird, wenn das User Interface schlecht ist. Allerdings bieten Nutzerschnittstellen häufig
nur proprietäre Ein- und Ausgabemöglichkeiten und sind nicht sehr flexibel oder an spezielle
Bedürfnisse anpassbar. Den meisten Mensch-Maschine-Schnittstellen ist zu Eigen,
dass für ihre effiziente Benutzung zunächst ein Lernprozess durchschritten werden muss.
Um diesen Prozess abzukürzen sind viele Nutzerschnittstellen an Metaphern angelehnt,
die als dem Nutzer bekannt angenommen werden. Verdeutlichen lässt sich das ganze
an folgendem Beispiel: Um Microsoft Windows zu beenden, muss man paradoxerweise
zunächst den ” Start“-Knopf drü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 Bedürfnisse, Quelle:
nach [Edw95, S. 22–25].
12

weil dessen Designer annehmen kö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 für Menschen, die eine Behinderung haben, sehr schwierig oder gar wegen
nicht überwindbarer Barrieren unmöglich sein. So brachte die Einführung von grafischen
Nutzeroberflächen bei Personal Computern Anfang der 90er Jahre vielen Nutzern
Vorteile, für blinde Menschen hingegen verschlechterte und erschwerte sich der Zugang
zu moderner Computertechnologie. Ähnliche Tendenzen sind derzeit im World Wide Web
zu beobachten. Immer häufiger ” verstecken“ sich wichtige Navigationselemente in unkommentierten
Grafiken, verschachtelten Frames oder Flash-Animationen und sind so
für viele Menschen nicht benutzbar. Durch Standardisierung und Einfü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 Einschränkungen einer Behinderung zu mildern und gewöhnliche
Schnittstellen für den Nutzer ” anzupassen“. Diesen Sachverhalt verdeutlichen die Grafiken
in Abbildung 3.3.
Ist eine adäquate Anpassung der Nutzerschnittstelle an den Nutzer durch ein technisches
Hilfsmittel erst einmal erreicht, sollte diese Anpassung dann für eine ganze Reihe
von Computeranwendungen wiederverwendet werden, um unnötige Duplikation bei
der Programmierung zu vermeiden. Allerdings sind solche technischen Nutzerinterface-
Anpassungen in der mobilen Anwendung oft nicht verwendbar, da sie schwer und unhandlich
sind. Bei Softwareanpassungen ist die Rechenleistung eines mobilen Endgeräts
eventuell zu gering oder der Ressourcenverbrauch steigt. In diesem Bereich muss deshalb
bei der Entwicklung eines möglichst barrierefreien Interfaces besonders behutsam
vorgegangen werden. Der Designer sollte sich fragen: Welche Fähigkeiten hat der Nutzer?
Welche Einschränkungen gilt es zu beachten? Wie ist die Situation beschaffen, in der
die Interaktion stattfindet? Welche Umweltfaktoren beeinflussen die Mensch-Maschine-
Kommunikation? Und: Welche Maßgaben macht die Technologie? Welche Schnittstellen
hat das Endgerät?
3.4 Technologien
In diesem Abschnitt über Technologien soll primär mobile Technik behandelt werden. Unter
der Überschrift Technologien könnte man viele Teilthemen, wie Netzwerke, Miniaturisierung
von mobilen Endgeräten oder Sensoren, die mobilen Anwendungen Kontextinformationen
zu ihrer Umwelt liefern, diskutieren. Hier sollen jedoch die fü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/Display-
Metapher lösen. Viele mobile Systeme arbeiten folglich mit verkleinerten Zeigeinstru-
13

menten und Mini-Tastaturen, anstatt natürlichere Formen der Kommunikation wie Sprache
oder Gestik zu verwenden. Einige solcher alternativen Ein- und Ausgabemethoden
sollen im Folgenden vorgestellt werden.
Haptik
Mit der Einführung eines Wireless Personal Area Network (WPAN), das verschiedene
Komponenten ü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 könnte man
einem solchen WPAN ein Phicon in der Form eines geschlossenen Vorhängeschlosses
hinzufügen und damit eine verschlüsselte Datenübertragung veranlassen.
Gestik
Der Zeichenvorrat an Gesten ist ein sehr natürliches, häufiges verwendetes Vokabular
zwischenmenschlicher Kommunikation. Für die Entwicklung von natürlichen Mensch-
Maschine-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 für eine Anwendung
ist ein elektrischer Rollstuhl, der die Richtungsinformation aus der Kopfbewegung
des Nutzers zieht [Kun99].
Neben kamerabasierten Systemen wird Gestik auch bei Geräten mit Touch Screen verwendet.
Hier werden mit dem Stift kreierte Gesten [Lon99] zur Steuereung des Gerä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 Geräts in einem mobilen Umfeld besteht das Problem,
dass der Nutzer, um mit dem Gerä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 Trägers befindet. Der Bildschirminhalt
erscheint fü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 gewährt und den visuellen Kanal des Nutzers
nicht beeinflusst. Findet man bereits heutzutage viele Beispiele für Sprachschnittstellen
in Telefonie-Anwendungen und bei Workstations, ermöglichen bessere Algorithmen für
die Sprachsynthese und Spracherkennung in Verbindung mit steigender Rechenleistung
in Zukunft dialogbasierte Benutzerschnittstellen auf mobilen Geräten [Ovi01, S. 422].
14

Nach Pitt [PE03] profitieren Sprachinterfaces von der zusätzlichen Verwendung von
Tönen und Geräuschen, den sogenannten ” Auditory Icons“ oder ” Earcons“. Diese sind
Geräuschen der Wirklichkeit nachempfunden oder bestehen aus Tonfolgen, die der Nutzer
als Meldung fü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 Kontextmenü. Dieses Prinzip wird auf Objektpaare
ausgeweitet. Der Nutzer bekommt bei der Auswahl zweier Objekte die Schnittmenge
an möglichen Operationen, die mit den beiden Elementen durchgeführt werden können.
Die Anwendung von ” Direct Combination“ in einem mobilen Kontext beschreibt Holland
[Hol03] zudem in mehreren Szenarien, in denen zum Beispiel Personen und Räume
eines fiktiven Bü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 lernfähig. Er kommuniziert mit dem Anwender und mit
anderen Agenten. Für den Nutzer ergeben sich daraus Vorteile, da er Aufgaben delegieren
kann, und sich damit nicht mehr um sie kümmern muss. Besonders im mobilen Einsatz
könnte ein Agent die persönlichen Vorlieben des Nutzers sowie zusätzliche Kontext-
Sensoren verknüpfen und so auf die Situation und Örtlichkeit angepasste Informationen
anbieten. Agenten können vollständig, vom Nutzer kaum bemerkt, im Hintergrund arbeiten,
oder direkt mit ihm interagieren.
3.5 Bestehende Systeme
Im Folgenden möchte ich beispielhaft bereits bestehende Navigationssysteme und Forschungsprojekte
im Bereich Navigationhilfen für behinderte Personen und Assistenzsysteme
für Touristen vorstellen. Diese Zusammenstellung, die bei weitem nicht als umfassend
angesehen werden kann, soll den Theorieteil ergänzen.
3.5.1 Kommerzielle Navigationssysteme am Markt
Neben professionellen Navigationssystemen, die ihren Einsatz in Luftverkehr, Schifffahrt
oder Logistik finden, sind die wohl populä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 Gerät
15

statt; das dafür erforderliche Kartenmaterial befindet sich im internen Speicher. Zur Positionsbestimmung
wird das satellitengestützte Global Positioning System (GPS) verwendet.
Eine ganze Reihe von weiteren Sensoren für Geschwindigkeit, Fahrtrichtung und Lenkbewegung
machen die Navigation erstens sehr genau und zweitens auch in Abschattungsbereichen
möglich. Derlei Systeme haben meist eine grafische Oberfläche und nutzen zudem
während der Fahrt eine Sprachausgabe für Fahranweisungen.
Als Konkurrenz zu den fest eingebauten Navigationssystemen bildet sich in letzter Zeit
zunehmend die Riege der PDA basierten Navigationssysteme heraus [Chr03]. Ä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-Lösungen mit Off-Board-Navigation arbeitet, ist T-
D1 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
übermittelt, die dann den Weg berechnet und Wegdaten zurückschickt.
Eine recht neue Entwicklung ist das Bemühen vieler Mobilfunknetzbetreiber, ihren Kunden
lokationsabhängige Dienste anzubieten [Epl03, Vod03]. Meist arbeiten diese mit
einer Positionsbestimmung über die Mobilfunknetze selbst. Eine erste Ausnahme bildet
das TD1 NaviGate Blue Kit, ein smartphone-basiertes System, welches einen GPS-
Empfänger mittels des Kurzstreckenfunks Bluetooth an ein Symbian OS Mobiltelefon
anbindet, und somit auch genauere Positionsbestimmung ermöglicht.
3.5.2 Local Location Assistant (Lol@)
Der Local Location Assistant [Pop02] ist der Prototyp eines elektronischen Touristen-
Guides für die Stadt Wien. Basierend auf clientseitigen Java Applets realisiert er geführte
Stadtrundgänge und bietet Informationen zu Sehenswü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 mö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 ständige Netzwerkverfügbarkeit voraussetzt. Interessant ist das hybride
Routing-Konzept. So wird bei der Positionsbestimmung bedingt durch die mangelnde Genauigkeit
von GPS eine Nutzerposition geschä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 reprä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 Europäischen
Union und richtet sich speziell an Personen mit visuellen Einschrä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 stationären PC-System mit synthetischer
Sprachausgabe oder Braillezeile die Strecke planen und die Umgebung kennen lernen
können. Dazu wurden öffentliches Kartenmaterial, Daten, Adressen und persönliche
Präferenzen sowie wichtige Informationen für blinde Personen bezüglich Wegzustand
und Position von Hindernissen zur Verfügung gestellt. Die Routenberechnung beachtete
zudem Nutzervorgaben, wie zum Beispiel schnellste Route, keine Stufen oder Benutzung
von öffentlichen Verkehrsmitteln. Auf dem Weg sollte das MoODS, ausgestattet
mit einem DGPS-Empfänger zur Positionsbestimmung, den Nutzer leiten und relevante
Informationen anbieten. Nutzerinteraktionen erfolgten über eine kleine Tastatur für Eingaben
und verbale Antworten, die über einen offenen Kopfhörer ausgegeben wurden, der
Geräusche der Umwelt nicht abschottet. Für erste Usability Tests wurde ein Walkman mit
zuvor aufgenommenen Weginformationen verwendet. Ein Begleiter war für die Positionsbestimmung
verantwortlich [Pet97]. Zusätzlich benutzten die Testpersonen ihre gewohnten
Hilfsmittel wie zum Beispiel Blindenhund oder Blindenstock.
3.5.4 Personal Guidance System
Als zweites Navigationssystem für Blinde basiert das Personal Guidance System auf einem
virtuellen akustischen Display. Räumliche Audiosignale werden dem Nutzer über
Kopfhö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-Empfängers. Wichtig fü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 räumliches Audio der rein verbalen
Beschreibung der Umgebung leicht ü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] beschäftigt sich mit der Entwicklung eines elektronischen
Fremdenführers für Lancaster. Ein erster Prototyp basierte auf einem Webpad
mit Stifteingabe. Positionsdaten sowie weitere Informationen zu Geschichte, Wetter oder
Öffnungszeiten von Sehenswürdigkeiten bezog das System aus einem Netz von WLAN
Hotspots, das ü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
Bornträger. Fü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 zulässt [Bor03, S. 27]. Zur Positionsbestimmung
benutzt der Prototyp ein GPS-Modul, das im Erweiterungsschacht eines
PDA arbeitet. Eine Netzanbindung zum Beispiel über WLAN ist nicht notwendig, da alle
Inhalte im Endgerä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 für einen Weg zu einem zuvor
ausgewähltem Ziel auf einem mobilen Endgerät bereitstellen sollte. Diese Informationen
sollten als Richtungsanweisungen in Echtzeit grafisch und akustisch ausgegeben werden.
Erst spä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 Einführung in die Bedienung gegeben.
Das Endgerät wird ausgehändigt und der Nutzer meldet sich am System an.
2. Der Nutzer gibt ein Wegziel ein oder er wählt aus einer Vorschlagliste aus.
3. Ausgehend von der aktuellen Position erhält der Nutzer Richtungsanweisungen und
Zusatzinformationen, die nach dem gewä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 nähere Umgebung werden auf dem Endgerät dargestellt
und in Echtzeit aktualisiert, auf etwaige Hindernisse wie zum Beispiel Stufen
oder Steigungen wird hingewiesen.
3. Zu interessanten Gebäuden, Sehenswürdigkeiten und sonstigen Einrichtungen bietet
das System Zusatzinformationen an.
18

4.2 Zielnutzergruppen
Die Zielgruppe für das Medienprojekt Barrierefreier Campus ist im Hinblick auf
Fähigkeiten und Einschränkungen sehr vielschichtig. Von den vielfältigen Auswirkungen
der Bewegungseinschränkungen bis zu starken Sehbehinderungen finden spezielle
Bedürfnisse Beachtung. Das Teilprojekt 4, das sich mit den Nutzerprofilen beschäftigt,
trägt dieser Tatsache Rechnung. Für die Nutzerschnittstelle wäre wünschenswert, gerade
mit dem Gedanken der Barrierefreiheit im Hinterkopf, allen Nutzern ein gemeinsames
Userinterface zur Verfügung zu stellen, das über die Nutzerprofile angepasst wird. Für
viele Nutzer wird man dabei zunächst an eine visuelle Schnittstelle denken, die mit einer
Sprachausgabe ergänzt wird. Vorteil hiervon ist, dass der Mensch grafische Informationen
quasi parallel aufnehmen kann. Er kann sehr schnell Bildteile fokussieren und so
selbstä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 für blinde Nutzer anpassen. Für diese Nutzergruppe haben wir
uns deshalb fü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 Endgerät. Um die Wiederverwendbarkeit
des Systems in Verbindung mit einer ganzen Reihe von Endgeräten und verschiedenen
Kommunikationsinfrastrukturen zu gewährleisten, wird ein möglichst großer Teil der Programmlogik
auf einem Server implementiert. Dies erspart unnötigen Mehraufwand bei
der Programmierung von unterschiedlichen Endgeräten. Außerdem kommt es der Notwendigkeit
entgegen, auf einem batteriebetriebenen Endgerät möglichst energiesparend
zu arbeiten und rechenintensive Programmteile wie Wegberechnung oder Datenbanken
auszulagern.
Für die Serveranbindung des Endgeräts bietet sich auf dem Campus der TU Ilmenau die
schon vorhandene WLAN-Infrastruktur an, da auch das Teilprojekt 2 – Lokalisation in
Gebäuden – mit WLAN arbeitet. Allerdings bestehen Abdeckungslücken; eine Serveranbindung
ist nicht ständig vorhanden. Deswegen ist die Struktur so gewählt, dass Wegberechnung
und Content-Aufbereitung sowie Nutzerprofilverwaltung zentral auf dem Server
geschieht, während Lokalisierung und Nutzerschnittstelle auf dem Endgerät situieren. Um
Lücken in der WLAN-Abdeckung zu überbrücken, kann das Endgerät – ist es erst einmal
initialisiert und hat es aktuelle Wegdaten – selbständig zum Ziel finden.
4.4 Technische Berührungspunkte mit anderen Teilprojekten
In der Projektgruppe war lange nicht genau definiert, wo die Berü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 zunächst semantisch definiert, da die genaue technische Realisierung zum
Zeitpunkt der Definition noch nicht bekannt war. Diese Definitionen legen verbindliche
Variablennamen und Datentypen für den Datenaustausch vor allem zwischen den Teilprojekten
Lokalisierungsinformation, Endgeräteanpassung und Programm auf dem Endgerät
fest. Die Realisierung, zum Beispiel die Modellierung mit einer XML-Struktur oder die
direkte Übertragung von Datenobjekten, war damit noch festzulegen.
Für das Programm auf dem Endgerät beziehungsweise für den mobilen Client wurde in
diesem Prozess ein Web Service als zentrale Schnittstelle für alle Systemteile und Teilprojekte
auf dem Server festgelegt. Aus Endgerä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 Rü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 Endgerät selbst erfolgt. Mit den Teammitgliedern,
die für Lokalisation im freien Feld und in Gebäuden zuständig sind, wurde
deshalb die Integration ihrer Programmteile als Klassen im Programm auf dem Endgerät
abgesprochen.
4.5 Endgeräte
Durch den offenen Charakter des Systems Barrierefreier Campus soll letztendlich eine
ganze Reihe von Endgeräten unterstützt werden. Vom ausgewachsenen Notebook bis
zum kleinsten Mobiltelefon ist zunächst alles denkbar. Allerdings zielt die Anwendung
als ” Assistenzsystem“ klar auf mobile beziehungsweise wearable Systeme. Kalawsky bezieht
den Ausdruck ” mobil“ in diesem Zusammenhang auf Mobilität und Bewegungsfreiheit
im freien Feld und nicht darauf, dass ein Laptop außerhalb des Büros benutzt werden
kann [Kal02, S. 8]. Wearable heißt in diesem Sinne, dass das Gerät in irgendeiner Weise
am Kö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 Endgerät für einen Fußgänger wohl eher eine suboptimale
Wahl darstellen würde. Für einen Rollstuhlfahrer ist ein Notebook dagegen eventuell
ein geeignetes Endgerät. Die Wahl des Endgeräts ist damit letztendlich ein Kompromiss,
den jeder Anwender selbst eingehen muss. Ein sehr kleines, handliches Gerät hat Einschränkungen
bei Rechenleistung und Displaygröße, ein Gerät mit hoher Rechenleistung
hingegen nur eine kurze Betriebsdauer, da der Akku schnell leer ist.
Für die Entwicklung des Prototyps wurde ein Endgerät gesucht, das ein möglichst breites
Spektrum an Nutzerbedürfnissen abdeckt. Dazu wurden Endgeräte recherchiert, die
einen kleineren Formfaktor haben und sich als ” mobiles“ Endgerät im beschriebenen Sinne
eigenen. Der Formfaktor ist allerdings nicht die einzige Anforderung an das Endgerät.
Weitere Kriterien, die sich gegenseitig zum Teil ausschließen, sind die folgenden:
• Akku-Laufzeit,
• Rechenleistung,
20

• Display, Auflösung, Farbtiefe,
• Erweiterungsschacht für WLAN- und GPS-Modul, beziehungsweise alternative
Möglichkeiten für WLAN und GPS,
• Speicherkapazität,
• Audio-Eigenschaften, Wiedergabe von Sprache,
• Hardware-Buttons - für Nutzer mit eingeschränkten Sehfähigkeiten von großer Bedeutung,
• Verfügbarkeit eines VPN-Client zur Verbindung mit dem Campusnetz.
Lässt man Exoten wie beispielsweise tragbare Industriesysteme beiseite, kann man
mögliche Endgeräte in vier verschiedene Geräteklassen einteilen: Mobiltelefone, Handheld
Computer und Personal Digital Assistants (PDA), Webpads, zu denen ich auch Tablet
PC zählen möchte, sowie Notebooks. Tabelle 4.1 zeigt Kriterien, die von einer denkbaren
Entwicklungsplattform für den Prototypen des Medienprojekts Barrierefreier Campus
zwingend erfüllt werden mussten, um keine Nutzergruppe von vorn herein auszuschließen
und die Vorgaben aus anderen Teilprojekten zu erfüllen.
Mobiltelefon PDA Webpad Notebook
GPS-Funktionalität – + + +
WLAN-Funktionalität – + + +
für Fußgänger geeignet + 0 0 –
Hardware-Buttons + + – +
Sprachausgabe 0 + + +
Tabelle 4.1: Anforderungen an Endgeräte Quelle: eigene Tabelle
Mobiltelefone konnten zum Zeitpunkt der Recherche noch nicht mit GPS-Funktionalität
ausgerüstet werden, die von Teilprojekt 2 für die Lokalisierung im freien Feld verwendet
wird. WLAN, das von Teilprojekt 1 zur Positionsbestimmung in Gebäuden verwendet
wird, ist für Mobiltelefone nicht vorgesehen. Ein Notebook ist für einen Fußgänger
in Bewegung nicht bedienbar. Blinde Menschen brauchen zur Interaktion mit dem Endgerät
nichtvisuelle Ein- und Ausgabemöglichkeiten. Für sie sind Sprachausgabe sowie
Hardware-Buttons, die viele Webpads und Tablet PC nicht haben, unverzichtbar. Von den
vier Geräteklassen wurden deshalb Vertreter der zweiten Gruppe als Plattform für den
Prototypen näher betrachtet. Ein PDA vereint die wichtigsten benötigten Eigenschaften in
einem Gerät, so dass er eine gute Kompromisslösung darstellt.
Der Markt für PDAs teilt sich momentan in zwei große Lager, Palm OS PDAs und PDAs
mit Windows CE. Von den Palm-Gerä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 für das Projekt benötigten Multimediafunktionen
bietet und Multitasking unterstützt. Der Tungsten T war allerdings noch recht neu und das
Angebot an Peripherie und Programmen demzufolge gering. Den Anforderungskatalog
recht gut erfüllten hingegen die Pocket PC-Geräte. Sie ähneln sich durch die Vorgaben
von Microsoft sehr stark.
21

Die Wahl fiel auf einen IPAQ 36xx, der am Fachgebiet Kommunikationsnetze verfü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 für die Soundwiedergabe. Außerdem kann er mit einem optionalen
Jacket mit Slots für die Aufnahme von bis zu zwei PCMCIA-Karten ausgerüstet werden,
die für WLAN und GPS gebraucht werden. Rechenleistung und Akku-Laufzeit sind akzeptabel.
Damit stellt der IPAQ 36xx einen guten Kompromiss zwischen Portabilität und
Funktionalität dar. Die recherchierten Webpads haben eine sehr ä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 Endgeräte sind in Anhang A zu finden.
22

Kapitel 5
Programmentwicklung
Für die praktische Umsetzung der Nutzerschnittstellen war es notwendig, zunächst eine
Programmiersprache zu wählen. Danach galt es, die Nutzerschnittstellen in ihrer Funktionalitä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 über die Implementation des Programms
auf dem Endgerät werden mit einer Beschreibung von Problemen abgerundet, die
während der Entwicklung auftauchten.
5.1 Wahl der Programmiersprache
Als Endgerät für den Prototypen wurde wie in Kapitel 4.5 beschrieben ein IPAQ 36xx ausgewä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-Source-
Projekten 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. Fü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 Verhä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 für das Programmieren mit Java braucht man zunächst eine Virtual Machine
auf der Zielplattform. Für Windows CE gibt es das kommerzielle Jeode Java Runtime
Environment (JRE) von Esmertec [Esm03] oder als freie Alternative zum Beispiel
SuperWaba [Sup03]. SuperWaba unterstützt allerdings nicht den gesamten Sprachumfang
von Java und wird von seinen Entwicklern lediglich als ” javaähnlich“ bezeichnet. Vorteil
bei einer Entwicklung unter Java ist die Verfügbarkeit von Java-VMs auf einer großen
23

Anzahl von möglichen Endgeräten bis hin zu Mobiltelefonen. Damit ist eine zumindest
eingeschränkte Wiederverwendbarkeit des Programmcodes möglich. Nachteilig sind bei
der Verwendung von Java oft Performancedefizite sowie die fehlende Unterstü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 GPS-
Modul und WLAN-Karte unsicher ist.
5.1.2 .NET Compact Framework
Die Entscheidung fiel, auch aufgrund der positiven Erfahrungen von Christian Bornträger,
die er bei der Entwicklung seines Audio-Prototyps gemacht hatte, zugunsten von C# aus.
Mit Erscheinen des Microsoft Visual Studio 2003 lag für diese Lösung auch eine integrierte
Entwicklungsumgebung vor. Vorteil von C# ist die gute Unterstützung für die Programmierung
von Pocket PC-Geräten, so können zum Beispiel die windowsspezifischen
Nutzeroberflächenelemente verwendet werden und dem Programmierer steht eine große
Anzahl an Programmbibliotheken zur Verfügung. Um ein C#-Programm auszuführen,
muss zunächst das circa 1,5 MB große .NET Compact Framework auf der Zielplattform
installiert werden, für die Installation des eigentlichen Programms genügt ein einfacher
” xcopy“-Befehl. Durch das Verwenden des .NET Frameworks ist einmal erstellter Quellcode
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.
Ergänzt wurde dieser Ansatz durch Diagramme zur Nutzerinteraktion, die zeitliche
Abläufe im Programm auf dem Endgerät definierten. Die Benutzerschnittstellen wurden
in Zusammenarbeit mit den Teilprojekten vier und fü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 Entwürfe sind nun im Folgenden beschrieben. Sie beziehen sich
auf das Gewählte Endgerät. Ein kurzer Abschnitt zu allgemeinen und geräteabhängigen
Teilen der Benutzerschnittstelle steht unter 5.2.3.
5.2.1 Nutzerschnittstelle für Sehende
Das User-Interface für Sehende folgt mehreren Metaphern. Bestimmend in den Diskussionen
bezügliche der Funktionalität des Gesamtsystems war die Kartenmetapher. Karten
sind ein sehr gebräuchliches Mittel um Routen zu planen und ein neues Terrain zu erkunden.
Außerdem werden Karten bei der Routenberechnung benötigt. Diese kann man
dann gleichwohl dem Nutzer zur Orientierung präsentieren. Desweiteren macht sich das
User-Interface die Windows-Metapher zunutze. Es werden Standard Windows Forms-
Komponenten, wie das virtuelle Keyboard oder Registerkarten, verwendet. Diese verlangen
Nutzern, die einen Pocket PC im Alltag verwenden, keine Umgewöhnung ab. So passt
sich die Nutzerschnittstelle gut in die Pocket PC-Umgebung ein.
24

Ähnlich wie der Audio-Prototyp von Christian Bornträger bietet die Nutzerschnittstelle
für das Projekt Barrierefreier Campus vier gleichzeitig aktive Interfaces, die der Nutzer
über Kartenreiter auswählen kann. Menü (Einstellungen), Zielsuche, Kartendarstellung
und Zusatzinformation sind neben Nutzerauswahl der Registerkarten zusätzlich verlinkt.
So kann der Nutzer zum Beispiel über Icons auf der Karte direkt zu den zugehörigen Zusatzinformationen
springen. Abbildung 5.1 zeigt einen Screenshot der Nutzerschnittstelle
für Sehende.
Abbildung 5.1: Screenshot der Benutzeroberfläche. Quelle: eigene Abbildung
5.2.2 Nutzerschnittstelle für Blinde
Wie bereits angedeutet, verfolgt die Nutzerschnittstelle für Blinde einen fundamental
anderen Ansatz als das Interface für Sehende. Es ist rein dialogbasiert und verzichtet
gänzlich auf eine graphische Nutzeroberfläche. Als bestimmende Metapher wäre hier die
Browsermetapher anzuführen. Vorbild für die Belegung der Hardwaretasten war der Textbrowser
Lynx [Lyn03], der überwiegend über die Richtungspfeiltasten bedient wird. Dieses
Konzept wurde auf das Richtungskreuz des IPAQ übertragen. So kann man sich mit
den Up- und Down-Tasten durch die Einträge eines Menüs bewegen. Ein Link wird mit
der Rechtstaste ausgewählt. Als universelle Zurück-Taste kommt die Linkstaste zum Einsatz.
Beim User Interface für Blinde mussten Einschränkungen in der Funktionalität in Kauf
genommen werden. Es gibt für das gewählte Endgerät keinen Mechanismus für die Texteingabe,
den eine blinde Person nutzen könnte. Ideal hierfür wären speziell für Blinde
entwickelte Geräte wie der PACMate [Wir02]. Er ist mit einem Screen Reader sowie
einer Braille-Tastatur ausgerüstet. Um blinden Nutzern trotz aller Einschränkungen die
Texteingabe mit dem Endgerät für den Barrierefreien Campus zu ermöglichen, wurde von
uns eine QWERTZ-Braille-Tastatur entwickelt. Sie besteht aus einer Folie, die ein ertastbares
Tastatur-Layout enthä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 für Blinde lediglich als Demonstration
eines dialogbasierten Sprach-Interfaces zu sehen ist. Für diese Zielgruppe kann das
entstehende Programm lediglich Ausgangspunkt für intensive Weiterentwicklungen sein.
5.2.3 Allgemeine und geräteabhängige Teile der Nutzerschnittstelle
Das oben beschriebene Design der Nutzerschnittstelle bezieht sich auf den IPAQ-PDA,
der als Endgerät für den Prototypen des Barrierefreien Campus gewä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 größeren Anpassung
bedarf allerdings die Präsentation (siehe Abbildung 5.2), da sich Ein- und Ausgabe
auf verschiedenen Endgeräten beträchtlich unterscheiden.
Gänzlich plattformunabhängig ist die von Teilprojekt 8 definierte Schnittstelle des Web
Service. Die Web-Service-Methoden können von beliebigen Clients genutzt werden, die
SOAP unterstützen. Als plattformunabhängige Nutzerschnittstelle könnte man sich zum
Beispiel ein Web Frontend für den Barrierefreien Campus vorstellen. Dieser könnte genutzt
werden um Besichtigungstouren und Ausflüge von zuhause aus vorzubereiten.
5.3 Programmstruktur
Über den prinzipiellen Ablauf der der Nutzerinteraktion haben schon die Nutzerszenarien
in Abschnitt 4.1 Auskunft gegeben. In diesem Abschnitt sollen nun die internen Abläufe
des Programms auf dem Endgerät gezeigt werden.
5.3.1 Funktionsblöcke
Abbildung 5.2 zeigt die Funktionsblöcke des Programms auf dem Endgerät. Die Kommunikation
mit dem Web Service erledigt eine Proxy-Klasse, die sämtliche SOAP-Aufrufe
selbst generiert. Weg und Spaziergang werden bei Bedarf mit den Rückgabewerten der
Web-Service-Methoden initialisiert und ” steuern“ die Anzeige. Der Block Audio ist noch
nicht vollständig implementiert.
5.3.2 Zeitliche Abläufe
Die meisten Prozesse und Abläufe stößt der Nutzer durch Eingabe von Daten oder
Betätigen von Buttons an. Damit gibt es keine zeitlich starre Abfolge der Code-
Ausführung. Zeitlich feste Abläufe während einer Nutzungs-Session gibt es während der
Initialisierung und an Stellen, an denen das Programm in einen anderen Modus wechselt.
Diese zeitlichen Abläufe werden im Folgenden beschrieben.
26

Abbildung 5.2: Struktur des Programms auf dem Endgerät. Quelle: eigene Abbildung
Initialisierung
Beim Programmstart wird zunächst vorausgesetzt, dass der Nutzer ein Nutzerprofil angelegt
hat. Eine User ID und ein Passwort ist dann für ihn gespeichert. Für das Abändern
des Nutzerprofils sowie die Generierung der Kennwörter wird eine Setup-Anwendung
(siehe Abschnitt 5.4.1) bereitgestellt. Wenn das Programm keine User ID auf dem Endgerä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 GPS-
Readers, das Starten des Spaziermodus.
Umschalten zwischen Spazier- und Wegmodus
Defaultmäßig befindet sich der Nutzer im Spaziermodus. Die Einstellungen für den Spaziermodus
bleiben deshalb während der gesamten Nutzungs-Session erhalten. Über die
Bildschirmansicht ” Ziel“ kann der Nutzer ein Ziel wä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, fällt das System
zurück in den Spaziermodus. So soll gewährleistet werden, dass sich das Programm
auf dem Endgerät immer in einem der beiden Zustände befindet.
27

5.4 Klassen und Komponenten des Programms auf dem
Endgerät
Bei der Entwicklung des Programms auf dem Endgerät gab es zunächst eine große Anzahl
von ungelösten Problemen. Vorgegangen wurde wie folgt: Zunächst war die Lösung von
Teilproblemen durch kleine Programmteile vorrangig. Erst gegen Ende des Entwicklungszeitraumes
wurden diese zu einem vollständigen Programm zusammengesetzt. Natü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 fü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 Endgerät gespeichert. Alle anderen Einstellungen können über ein Web Interface,
das aus der Setup-Anwendung heraus aufgerufen wird, verändert werden.
5.4.2 Die Klasse Spaziergang
Das Nutzerszenario Spaziergang setzt die Initialisierung des Programms auf dem Endgerät
mit Daten zu interessanten Gebä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 Endgerät übertragen. Eine neue Instanz der Klasse Spaziergang wird mit dem
übermittelten Datensatz angelegt. Sie stellt Zugriffsmethoden für die Daten zur Verfügung
und übernimmt die Extraktion der Daten aus den Tabellen. So können Referenzpunkte
und Daten zu Points of Interest (POI) durch einfache ” get“-Methoden direkt aufgerufen
werden.
5.4.3 Die Klasse Weg
Ähnlich wie die Klasse Spaziergang stellt die Klasse Weg Zugriffsmethoden für den vom
Web Service übermittelten Wegdatensatz zur Verfügung. Darüber hinaus hat sie ein Interface
für die aktuellen GPS-Daten, um den Kurs des Nutzers überprüfen zu können und
Anweisungen zu triggern.
Der Weg, der von Teilprojekt 3 – Lokalisierungsinformation – berechnet wird, ist approximiert
durch gerade Teilstücke, die so genannten Kanten. Jede Kante ist definiert durch
ein GPS-Datum für jeweils Anfang und Ende. Eine Beschreibung von Hindernissen, die
Länge der Kante sowie Richtungsinformationen fü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 über die nä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 Kantenlänge und ihre
Mittelpunkte liegen im Abstand von einem Meter. Die Methode ” IsOnTrack“ ermittelt
nun für jedes GPS-Datum das Quadrat, in dem sich der Nutzer gerade befindet, und kann
so Aussagen über den Fortschritt des Nutzers auf der Kante geben. Diese Vorgehensweise
gewährleistet, dass Richtungsinformationen rechtzeitig ausgegeben werden können.
Sobald ein Nutzer vom Weg abkommt geschehen drei Dinge:
1. Das Programm wartet kurze Zeit.
2. Die aktuelle und die nä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 für das Projekt Barrierefreier Campus.
Abgeleitet von Windows.Forms.Control bietet sie nützliche Funktionen für die Nutzeroberfläche
eines Navigationssystems für Pocket PC.
Die Klasse Scrollkarte kann Kartengrafiken in den meisten Standardgrafikformaten anzeigen.
Per Stift können die Karten an die richtige Position ” gezogen“ werden, um auf
einem kleinen Bildschirm eine große Karte betrachten zu kö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 nachgefü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 für Lokalisierungsinformationen
aus den Teilprojekten 1 und 2 – Lokalisierung im freien Feld und in Gebäuden. Der
Parser bietet ein Interface für Referenzpunkte, die fü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 Gebäuden, die Integration beider
Lokalisierungsmethoden in einem einheitlichen Interface.
5.5 Probleme bei der Implementation
5.5.1 Sprachsynthese
Für das Interface für Blinde wird eine Sprachausgabe benötigt. Hier bietet es sich an,
Sprachsynthese zu verwenden, da der Aufwand fü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 Gebäude entstehen. Eine freie TTS
Engine (text to speech engine), die für das Projekt verwendet wurde, ist Festival Light
(Flite) [Fli03]. Flite ist eine kleine, schnelle Sprachsynthese-Software, die vornehmlich
für embedded Geräte entwickelt wurde. Anfänglich entwickelt für Linux, gibt es mittlerweile
Versionen für Windows CE und eine Portierung für Java. Problem ist allerdings,
dass in der Version für Windows CE nur eine englische Stimme enthalten ist, die für den
hiesigen Sprachraum nicht geeignet ist und sich die Integration einer deutschen Stimme
als für das Projektteam unlösbare Aufgabe herausstellte. So bleibt Sprachsynthese
für das Projekt Barrierefreier Campus eine offene, noch zu klä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 stößt. Generell ist das
Problem, dass nicht alle Funktionen des .NET Frameworks implementiert sind. Grund
dafür ist die Beschränkung auf einen mö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 grün markiert. Neben dem Fehlen dieser gesamte
Blöcke sind für viele Klassen auch nur bestimmte Methoden implementiert.
Ein Beispiel für eine fehlende Funktionionalitä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 Möglichkeit Key Events doch an zentraler Stelle zu verarbeiten, ist das
30

Abbildung 5.4: Das Compact Framework unterstützt nur die Klassen, die blau unterlegt
sind. Quelle: nach [Tia03]
Benutzen von WinAPI-Funktionen und damit ” unmanaged Code“, oder man muss sicherstellen,
dass zu keiner Zeit ein anderes Control als die Form selbst den Eingabefokus hat.
Schwierigkeiten bekommt man dann aber, wenn man den Eingabefokus tatsächlich einmal
auf einem bestimmten Control braucht, zum Beispiel wenn der Nutzer einen Text in
eine Textbox eingeben will.
Ein zweites Beispiel für eine fehlende Funktion, das mich eine ganze Weile beschäftigt
hat, ist die Ausgabe von Sounds. Auch hierfür gibt es keine Funktionen im .NET Compact
Framework. Bei Versuchen, die Sound-Ausgabe durch P/Invoke einer nativen Funktion
zu ermö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 Möglichkeiten vorhanden waren, die Sound-Ausgabe zu
stoppen oder zu pausieren. Die Lösung schien mit der Verwendung einer Open Source-
Klassenbibliothek [Ope03] fü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 zurückzuführen ist.
31

Kapitel 6
Demonstrationsprogramme
6.1 WgsToXY – Ansatz fü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-Empfänger auf eine selbstgewählte Karte mappt. Hierzu können die
Referenzpunkte in Echtzeit gewählt werden, um beliebiges Kartenmaterial verwenden zu
können. Für die Kartendarstellung kommt die Scrollkarten-Klasse zum Einsatz. Die Position
wird mit einem Fadenkreuz-Sprite angezeigt. Bei einigen Rundgängen auf dem
Campus konnten mit diesem Tool schon Erfahrungen zu der tatsächlichen Genauigkeit
der Lokalisierung im freien Feld gemacht und letztendlich die Grundlage für den Spaziermodus
demonstriert werden.
6.2 User Interface für Blinde – Demonstrationsprogramm
Das User Interface für Blinde ist noch nicht im Programm auf dem Endgerät implementiert.
Das hat mehrere Gründe: Zum einen ist die Lokalisierung noch nicht genau genug.
Tests mit dem GPS-Empfänger und dem Endgerät ergaben eine Positionsunsicherheit
von bis zu zwanzig Metern, die für punktgenaue Richtungsanweisungen ungenügend
sind. Zum anderen verzögerten Probleme mit Sprachsynthese und Soundausgabe allgemein
die Implementation der Nutzerschnittstelle. Das vorliegende Programm demonstriert
demzufolge den Eingabemechanismus für das Interface, der in eine einfache auditive
Menüstruktur eingebettet ist. So können mit dem Steuerkreuz Menüpunkte ausgewählt
sowie ein Ziel bei der Zielsuche eingegeben werden.
6.3 BaFreiCa – eine Demonstrationsversion
Um eine Demonstrationsversion vom Programm auf dem Endgerät zu erstellen, die unabhängig
von den anderen Komponenten des Barrierefreien Campus lauffähig ist, mussten
einige Kompromisse eingegangen werden. So sind sämtliche Programmressourcen, wie
32

Bilder und Kartenmaterial, die eigentlich vom Web Service ü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 unvollständige Lokalisierungsinformationen
enthalten, jedoch dem definierten Format entsprechen.
6.3.1 Simulation der fehlenden Komponenten
Die beiden wichtigsten technischen Schnittstellen für das Programm auf dem Endgerät
sind zum einen der Web Service, der die Kommunikation zu Lokalisierungsinformation
und Benutzerprofilen übernimmt und zum anderen die Lokalisierungsdaten auf dem Endgerä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 übernimmt. Fü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 Funktionalität lediglich aus der
Erstellung eines Datensatzes, der aus einer auf Universitäts-Webspace abgelegten XML-
Datei generiert wird. Die Methode Zielsuche simuliert das Generieren genauerer Suchoptionen
aus den vom Nutzer gewählten Zielen.
Die Simulation der Lokalisierung ü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 Endgerät mit den Rückgabewerten der Web-Service-
Methode ’Authentifizierung’, befindet sich der Nutzer im Spaziermodus. Er kann die
Karte des Campus betrachten und Zusatzinformationen zu Gebäuden abfragen, die auf
der Registerkarte ’Info’ angezeigt werden. Seine Position wird auf der Karte durch ein
Fadenkreuz angezeigt. Der Button ” Ziel“ führt den Nutzer zur Registerkarte ’Zielsuche’.
Durch eine wiederholte Auswahl von Optionen, die in einem Drop-Down-Menü 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 Weglä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 nä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’
präsentiert. Auch das Erreichen des Zielpunktes wird in Verbindung mit der Anzeige der
zugeörigen Zusatzinformationen angezeigt.
33

6.3.3 Ergebnisse
Die stark eingeschränkte Demonstrationsversion des Programms auf dem Endgerät lässt
nur bedingt Rückschlüsse auf die Benutzung des Programms in einem realitätsnahen Umfeld
zu. Neben wichtigen Aspekten, die in die Zuständigkeit anderer Teilprojekte fallen –
wie zum Beispiel der Positionsgenauigkeit, Qualitä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
Größe der Quadrate, die die Kante approximieren, muss noch der Positionsgenauigkeit
angepasst werden. Ebenso ist die Distanz beziehungsweise der Zeitpunkt des Hinweises
auf die nächste Kante noch zu bestimmen.
Allerdings können schon einige Ergebnisse für diesen Prototypen festgehalten werden.
Das Programm auf dem Endgerät selbst bietet relativ wenige Einstellungsmöglichkeiten,
es passt sich vielmehr selbständig nach dem gewählten Nutzerprofil an die Bedürfnisse
des Nutzers an. Da die Nutzerprofile bei Programmstart erst vom Server geladen werden
mü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 Überladung dieser
Bildschirmansicht geführt hat. Deshalb wurden die Richtungsanweisungen auf die Registrierkarte
” Info“ verlagert um Übersichtlichkeit zu gewinnen. Zusätzliche werden die Informationen
für die aktuellen Kanten an selber Stelle laufend aktualisiert. Durch die Buttons
am unteren Bildschirmrand, die auch mit den Fingern bedient werden können, sind
diese Informationen schnell abrufbar, auch wenn sie nicht direkt mit der Karte dargestellt
werden. Die Anzeige der Position durch ein Fadenkreuz ist für reale Lokalisierungsinformationen
wahrscheinlich schon fast zu genau, für die Eingabe der Position mit dem Steuerkreuz
ist es gut geeignet. Die Registrierkarte ” Menü“ enthält für den Prototypen und zu
Testzwecken wichtige Anzeigen, wie GPS-Koordinaten, Einstellmöglichkeiten und Darstellungsoptionen.
Tests mit realen Nutzungsszenarien müssen zeigen, welche Optionen
hier wirklich wichtig sind, und welche durch Programmlogik ersetzt werden können.
34

Kapitel 7
Ausblick
Die Ergebnisse des Medienprojekts sind Momentaufnahmen einer Entwicklung, in der
ein erster Ansatz für ein Assistenzsystem verwirklicht wurde. Im Teilprojekt 7 entstand
die prototypische Implementation einer Nutzerschnittstelle für das Medienprojekt Barrierefreier
Campus. Eine Demonstration verdeutlicht, wie eine Nutzerschnittstelle für blinde
Menschen fü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 für weitere Forschung und Anwendungsentwicklungen.
Lange Verzö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 überprüft werden müssen. Auch das Endgerät muss sich in der Praxis
bewähren. So ist bisher nicht geklärt, wie sich Wettereinflüsse wie Regen oder Kälte auf
Gerät und Bedienung auswirken oder wie gut die Interaktion mit dem Prototypen funktioniert,
während sich der Nutzer im Gelände bewegt.
Weitere Forschung und Entwicklung ist im Bereich der Nutzerschnittstelle für Blinde
notwendig. Hier kann die Integration einer Sprachsynthese die mühsame Aufgabe der
Sprachaufnahme ersetzen. Die im Team entwickelte QWERTZ-Brailletastatur für den
IPAQ kann nur eine suboptimale Lösung für die Dateneingabe für blinde Personen sein.
Mit steigender Rechenleistung der Endgeräte sowie Fortschritten bei der Spracherkennung
ist eine rein auditive Nutzerschnittstelle denkbar. Eine sorgfältige Betrachtung der
Positionsbestimmung sowie der Verarbeitung der Positionsdaten im Programm auf dem
Endgerät könnte ein weiterer Schwerpunkt für Verbesserungen am Prototypen sein. Durch
Annahmen wie ” Ein Nutzer geht meist auf Wegen“ oder ” Ein Nutzer bewegt sich nicht auf
Dächern“ usw. kö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 zukünftigen Versionen des Programms
könnten Kontextinformationen über weitere Sensoren erfasst werden. So könnten Daten
über die Bewegungsrichtung und Geschwindigkeit des Nutzers Dead Reckoning in Bereichen
ermöglichen, in denen Abschattungen der GPS-Satelliten mit Abdeckungslücken
des WLAN zusammen fallen. Sensoren am Körper des Nutzers könnten den Gesundheitszustand
des Nutzers überwachen und im Notfall einen Hilferuf mit der genauen Position
absetzen. Um das Leistungsangebot des Assistenzsystem zu vervollständigen könnte
35

man auch über Interaktions- und Kommunikationsmöglichkeiten zwischen mehreren Nutzern
nachdenken. Message Boards könnten den Erfahrungsaustausch fördern, ein Chat-
Programm oder eine Sprachverbindung zu anderen angemeldeten Nutzern könnten eine
entstehende Gemeinschaft unterstützen.
Durch dieses Medienprojekt haben sich die Zugangsbarrieren für Menschen mit Behinderungen
zum Campus der TU Ilmenau nicht in Luft aufgelöst. Einige Probleme mit dem
Programm auf dem Endgerät bestehen weiterhin. In der Projektarbeit sind jedoch Konzepte
und Lösungen entstanden, die, prototypisch implementiert, erahnen lassen, welches
Potential eine barrierefreies Assistenzsystem in sich birgt.
36

Literaturverzeichnis
[Akt03] Freizeit und Sport, gleichberechtigte Teilnahme am öffentlichen Leben.
http://www.familienratgeber.de/ratgeber/seite_6975.
html; 30.12.2003.
[Bab98] BABER, CHRIS ET AL.: Preliminary Investigations into the Use of Wearable
Computers. In: JOHNSON, HILARY ET AL. (Eds.): People and Computers
XIII, Proceedings of HCI ’98. Springer, London, 1998, 313–325.
[Bor03] BORNTRÄGER, CHRISTIAN: Contextual Influence on the Usability of Different
Media Types. Diplomarbeit, TU Ilmenau, 2003.
[Che03] CHEVERST, KEITH 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] CHRISTE, JAN UND PETER-MICHAEL ZIEGLER,: Richtungsweisend.
Satelliten-Navigation mit dem PDA. In: c’t 1/2003, 142–149.
[Edw95] EDWARDS, ALISTAIR D. N.: Computers and people with disabilities. In:
EDWARDS, ALISTAIR 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] FISHKIN, KENNETH 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] HOLLAND, SIMON 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] HOLLAND, SIMON AND DANIEL OPPENHEIM: Direct Combination. In:
WILLIAMS, MARIAN 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] KUNO, YOSHINORI ET AL.: Combining Observations of Intentional and
Unintentional Behaviors for Human-Computer Interaction. In: WILLIAMS,
MARIAN 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] KALAWSKY, R. S.: Interface Issues for Wearable and Mobile Computer
Users. In: EARNSHAW, RAE AND JOHN VINCE (Eds.): Intelligent Agents
for Mobile and Virtual Media. Springer, London, 2002, 8–27.
[LG01] LOOMIS, JACK M. AND REGINALD G. GOLLEDGE: GPS-Based Navigation
Systems for the Visually Impaired. In: BARFIELD, WOODROW AND THO-
MAS CAUDELL (Eds.): Fundamentals of wearable computers and augmented
reality. Lawrence Erlbaum Associates, Mahwah, 2001, 429–446.
[Lie97] LIEBERMANN, HENRY: Autonomous Interface Agents. In: PEMBERTON,
STEVEN (Ed.): Human factors in computing systems. Looking to the future.
CHI 97. Addison–Wesley, Reading, 1997, 67–74.
[Lon99] LONG, ALLAN C. ET AL.: Implications For a Gesture Design Tool In: WIL-
LIAMS, MARIAN 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Ü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] NEWELL, ALAN F.: Extra-ordinary human-computer interaction. In: ED-
WARDS, ALISTAIR D. N. (Ed.): Extra-ordinary human-computer interaction:
interfaces for users with disabilities. Cambridge University Press, New
York, 1995, 3–18.
[Ovi01] OVIATT, SHARON ET AL.: Designing the User Interface for Multimodal
Speech and Pen-Based Gesture Applications: State-of-the-Art-Systems
and Future Research Directions. In: CARROLL, JOHN M. (Ed.): Human-
Computer 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] PETRIE, HELEN ET AL.: User-centred design in the development of a navigational
aid for blind travellers. In: HOWARD, STEVE ET AL. (Eds.): Human-
Computer Interaction: INTERACT ’97. Chapman & Hall, London, 1997,
220–227.
38

[Pop02] POPSCHIL, GÜNTHER ET AL.: Designing LoL@, a mobile Tourist Guide
for UMTS. In: PATERNÒ, FABIO (Ed.): Human Computer Interaction with
Mobile Devices. 4th International Symposium, Pisa, Italy. Springer, Berlin,
2002, 140–154.
[PE03] PITT, IAN AND ALISTAIR EDWARDS: Design of speech-based devices: a
practical guide. Springer, London, 2003.
[Rek01] REKIMOTO, JUN: NaviCam: A Palmtop Device Approach to Augmented Reality.
In: BARFIELD, WOODROW AND THOMAS CAUDELL (Eds.): Fundamentals
of wearable computers and augmented reality. Lawrence Erlbaum
Associates, Mahwah, 2001, 354.
[Sta02] STARNER, THAD 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] TIAN, MIN: Abgespeckt; .Net Compact Framework für mobile Gerä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 Initiative (WAI). http://www.w3c.org/WAI;
26.11.2003.
[Wir02] WIRTGEN, JÖRG: Pocket PC für Blinde. In: c’t 26/2002, 22
[WoB03] Aktionsbündnis für barrierefreie Informationstechnik – AbI. http://www.
wob11.de/index.html; 30.11.2003.
39

Abbildungsverzeichnis
2.1 Übersicht ü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
3.3 Anpassung von Nutzerschnittstellen an spezielle Bedürfnisse, Quelle:
nach [Edw95, S. 22–25]. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Screenshot der Benutzeroberfläche. Quelle: eigene Abbildung . . . . . . 25
5.2 Struktur des Programms auf dem Endgerät. Quelle: eigene Abbildung . . 27
5.3 Approximation der Wegkanten. Quelle: eigene Abbildung . . . . . . . . 29
5.4 Das Compact Framework unterstützt nur die Klassen, die blau unterlegt
sind. Quelle: nach [Tia03] . . . . . . . . . . . . . . . . . . . . . . . . . 31
40

Tabellenverzeichnis
4.1 Anforderungen an Endgerä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 Endgeräte Quellen: http://www.skeye.com; http://
www.siemens.de . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
41

Abkü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 Endgeräte
Diese Zusammenstellung von Endgeräten kann keine Marktübersicht leisten. Vielmehr
sollen aus den Endgeräteklassen typische Vertreter mit ihren speziellen Eigenschaften vorgestellt
werden. In Tabelle A.1 werden Mobiltelefone aufgefü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 angeführt.
MOBILTELEFONE
Nokia 9210i Sony Ericsson P800
System Symbian OS Symbian OS
Speicher 8 MB RAM, 16 MB RAM
16 MB Flash-ROM 16 MB Flash-ROM
CPU ARM9-basiert ARM9-basiert
Erweiterungsslots MMC Memory Stick Duo
Kopfhörer-Anschluss ja ja
Mikrofon ja ja
IrDA ja ja
Bluetooth – ja
WLAN – –
Display 640 x 200 Pixel, 640 x 480 Pixel,
12 Bit Farbtiefe 12 Bit Farbtiefe
Display-Beleuchtung ja ja
Maße (BxHxT) [mm 3 ] 59 x 158 x 28 59 x 117 x 27
Gewicht [g] 244 159
Laufzeit 5,6 h (PDA-Dauerbetrieb) 5,2 h (PDA-Dauerbetrieb)
Dateneingabe QWERTZ-Tastatur Software-Tastatur,
JotPro
Alarmsignale akustisch Vibration, akustisch
Tabelle A.1: Mobiltelefone Quelle: c’t special Handhelds [Lue03]
44

PALM OS PDAS
Palm m130 Palm m515 Palm Tungsten T Sony Clié PEG-SJ33 Sony Clié PEG-NZ90
System Palm OS 4.1 Palm OS 4.1 Palm OS 5 Palm OS 4.1 Palm OS 5
Speicher 8 MB RAM, 16 MB RAM, 16 MB RAM, 16 MB RAM, 16 MB RAM,
2 MB ROM 4 MB ROM 8 MB Flash-ROM 4 MB Flash-ROM 16 MB Flash-ROM
CPU Motorola Dragonball, Motorola Dragonball, TI OMAP 144MHz Motorola Dragonball, Intel PXA250 XScale,
33MHz 33MHz 66 MHz 200MHz
Erweiterungsslots SD, MMC SD, MMC SD, MMC Memory Stick Memory Stick
Kopfhörer-Anschluss – – ja ja ja
Mikrofon – – ja – ja
IrDA ja ja ja ja ja
Bluetooth – – ja – ja
WLAN – – – – –
Display DSTN-Display, Reflektiv-Display, Reflektiv-Display, Transflexiv-Display, Transflexiv-Display,
160 x 160 Pixel, 160 x 160 Pixel, 320 x 320 Pixel, 320 x 320 Pixel, 320 x 480 Pixel,
12 Bit Farbtiefe 16Bit Farbtiefe 16Bit Farbtiefe 16 Bit Farbtiefe 16 Bit Farbtiefe
Display-Beleuchtung ja ja ja ja ja
Maße (BxHxT) [mm3 ] 122 x 78 x19 114 x 81 x 13 100 x 73 x 15 103 x 71 x 15 140 x 76 x 30
Gewicht [g] 184 146 157 133 296
Laufzeit mit/ohne Licht 4,5 h/– 3,5 h/20 h 3,4 h/6,5 h 5,5 h/13 h 3,2 h/8,5 h
Dateneingabe Software-Tastatur, Software-Tastatur, Software-Tastatur, Software-Tastatur, Hardware-Tastatur,
Graffiti Graffiti Graffiti, Graffiti Software-Tastatur,
Voice Recording Graffiti virtuell
Navigation Up-/Down-Taste, Up-/Down-Taste, Navigationskreuz, Jog-Dial, Jog Dial,
4 Applikationstasten 4 Applikationstasten 4 Applikationstasten, 4 Applikationstasten, 4 Applikationstasten,
Aufnahmetaste Rücktaste Rück- und Haltetaste
Alarmsignale Vibration, LED, Vibration, LED, LED, LED,
akustisch akustisch akustisch Tonauswahl Tonauswahl
45
Tabelle A.2: Palm OS PDAs. Quelle: c’t special Handhelds [Lue03]

WINDOWS CE PDAS
Compaq iPAQ 36xx HP iPAQ H5450 Siemens Pocket Loox 600 Toshiba e740 WIFI Toshiba e330
System Pocket PC 2000 Pocket PC 2002 Pocket PC 2002 Pocket PC 2002 Pocket PC 2002
Speicher 32 MB RAM 64 MB RAM, 64 MB RAM, 64 MB RAM, 64 MB RAM,
16 MB Flash-ROM 48 MB Flash-ROM 32 MB Flash-ROM 32 MB Flash-ROM 32 MB Flash-ROM
CPU Intel StrongARM Intel PXA250 XScale, Intel PXA250 XScale, Intel PXA250 XScale, Intel PXA250 XScale,
206 MHz 400 MHz 400 MHz 400 MHz 300 MHz
Erweiterungsslots – SD, MMC SD, MMC, CF-Typ II SD, MMC, CF-Typ II SD, MMC
Kopfhörer-Anschluss ja ja ja ja ja
Mikrofon ja ja ja ja ja
IrDA ja ja ja ja ja
Bluetooth – ja ja – –
WLAN – ja – ja –
Display Transflexiv-Display, Transflexiv-Display, Reflektiv-Display, Reflektiv-Display, Reflektiv-Display,
240 x 320 Pixel, 240 x 320 Pixel, 240 x 320 Pixel, 320 x 320 Pixel, 240 x 320 Pixel,
16 Bit Farbtiefe 16 Bit Farbtiefe 16 Bit Farbtiefe 16 Bit Farbtiefe 16 Bit Farbtife
Display-Beleuchtung ja ja ja ja ja
Maße (BxHxT) [mm3 ] 130 x 83,5 x 15,9 131 x 82 x 16 132 x 82 x 17 125 x 80 x 16 125 x 79 x 15
Gewicht [g] 170 201 171 171 134
Laufzeit mit/ohne Licht k.A. 4,5 h/12,4 h 3,5 h/7,9 h 2,2 h/7,1 h 5 h/13 h
Dateneingabe Handschrift, Handschrift, Handschrift, Handschrift, Handschrift,
Software-Tastatur, Software-Tastatur, Software-Tastatur, Software-Tastatur, Software-Tastatur,
Voice Recorder Voice Recorder Voice Recorder Voice Recorder Voice Recorder
Navigation Steuerkreuz, Steuerkreuz, Steuerkreuz, Steuerkreuz, Steuerkreuz,
4 Applikationstasten, 4 Applikationstasten, 4 Applikationstasten, 4 Applikationstasten, 4 Applikationstasten,
Aufnahmetaste Aufnahmetaste Scrollrad Aufnahmetaste, Aufnahmetaste,
Scrollrad Scrollrad
Alarmsignale LED, Tonauswahl LED, Tonauswahl LED, Tonauswahl LED, Tonauswahl LED, Tonauswahl
46
Tabelle A.3: Windows CE PDAs. Quellen:c’t special Handhelds [Lue03]; http://www.hewlett-packard.de

WEBPADS TABLET PC NOTEBOOK
Skeye Webpad Siemens SIMpad SL4 Fujitsu-Siemens ST4120 Fujitsu-Siemens Lifebook S Series
System Windows CE.NET WinCE 3.0 (HPC 2000) WindowsXP Tablet PC ed. Windows XP
Speicher 32 MB RAM, 64 MB RAM, 256 MB–76 8MB RAM, 256–1024 MB RAM,
32 MB Flash-ROM 32 MB Flash-ROM Festplatte Festplatte
CPU Intel StrongARM, Intel StrongARM, Intel PII ULV, Intel Pentium M,
206MHz 206MHz 933MHz 1,6 GHz
Erweiterungsslots PCMCIA-Typ II, CF-Typ II PCMCIA-Typ II PCMCIA-Typ I oder Typ II PCMCIA Typ I/II
Kopfhörer-Anschluss ja ja ja ja
Mikrofon ja k.A. ja ja
IrDA ja ja – ja
Bluetooth – – – ja
WLAN – – ja ja
Display 8,2“ DSTN, 8,4“ TFT, 10,4“ TFT, 13,3“ TFT,
800 x 600 Pixel, 800 x 600 Pixel, 1024 x 768 Pixel, 1024 x 768 Pixel,
16 Bit Farbtiefe 16 Bit Farbtiefe 24 Bit Farbtiefe 24 Bit Farbtiefe
Display-Beleuchtung ja ja ja ja
Maße (BxHxT) [mm3 ] 240 x 160 x 30 263 x 180 x 28 301 x 220 x 21 293 x 236 x 34
Gewicht [g] 900 1000 ca. 1450 1700
Laufzeit 6–8 h k.A. k.A. 3,7 h
Dateneingabe Handschrift, Handschrift, Handschrift, Tastatur,
Software-Tastatur Software-Tastatur Software-Tastatur Touch Pad
Navigation – Steuerkreuz, Navigationstasten, Tastatur
Auswahltaste Anwendungstasten
Alarmsignale Tonauswahl LED, Tonauswahl LED, Tonauswahl LED, Tonauswahl
47
Tabelle A.4: Sonstige Endgeräte Quellen: http://www.skeye.com; http://www.siemens.de