Unterstützung der Bedienung von Touch

Fakultät für Informatik undMathematikLehrstuhl für Informatik mit SchwerpunktEingebetteteSystemeProf. Dr. Matthias Kranz

Unterstützung der Bedienung von Touch-screens in Fahrzeugen durch Verwendung eineszweiten Displays im Fahrersichtfeld

Supporting Touchscreen Usability in the Car by Employ-ing a Second Display in the Driver’s Field of View

Daniel Riedl

Bachelor-Arbeit

Verfasser: Daniel RiedlAnschrift:

Matrikelnummer:Prüfer: Prof. Dr. Matthias KranzBetreuer: M.Sc. Patrick Lindemann

Beginn: 01.01.2015Abgabe: 30.03.2015

Fakultät für Informatik undMathematik

Lehrstuhl für Informatik mit Schwerpunkt

EingebetteteSysteme

Prof. Dr. Matthias Kranz

ErklärungHiermit erkläre ich an Eides statt, dass ich diese Bachelor-Arbeit zum Thema

Unterstützung der Bedienung von Touch- screens in Fahrzeugen durch Verwendung eineszweiten Displays im FahrersichtfeldSupporting Touchscreen Usability in the Car by Employing a Second Display in theDriver’s Field of View

selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendethabe.

Passau, den 30.03.2015Daniel Riedl

Daniel Riedl

Kurzfassung

Touchscreen Geräte finden immer mehr Verwendung in PKWs an der Stelle von festen Tasten undSchalter im Zuge der populärer werdenden Computerisierung von Fahrzeugen. Diese bieten einemNutzer nämlich eine Vielzahl von Funktionen und viele sind deren Bedienung mit Smartphonesunter anderem bereits gewohnt. Jedoch ist eine solche Bedienung während einer Fahrt sicher-heitstechnisch bedenklich, da diese keinen haptischen Feedback bieten und ein Fahrer seinen Blickimmer senken müsste. In dieser Arbeit wird untersucht ob ein Headup Display (HUD) die Fahr-sicherheit bei gleichbleibenden Bedienkomfort verbessern könnte, indem die Informationen vomTouchscreen direkt darin angezeigt werden. Dafür wurde eine Studie durchgeführt, für die eineMusikspieler Applikation entwickelt wurde. Musikverwaltung ist eine populäre tertiäre Tätigkeitunter Fahrern, zudem bot es sich hierbei an, verschiedene Funktionen eines Touchscreens zu tes-ten. In der Studie haben Teilnehmer immer verschiedene Aufgaben auf einem Touchscreen Gerätwährend einer simulierten Fahrt durchgeführt. Diese Aufgaben haben sie einmal mit Hilfe einesHUD und einmal ohne bearbeitet. Es wurden für alle Varianten die Fahrabweichung, Reaktions-zeit, Aufgabendauer und Fehleingaben ermittelt. Aufgrund der geringen Anzahl von 7 Teilnehmernkonnte kein signifikantes Ergebnis festgehalten werden, jedoch hatten in den meisten Fällen dieHUD Varianten etwas schlechtere Werte als die ohne. Insbesondere brauchten die Aufgaben mitHUD fast immer länger um fertig bearbeitet zu werden als die ohne. Jedoch bevorzugten die Teil-nehmer in den meisten Fällen die Varianten mit HUD, daher müsste man bei einer Weiterführungdieses Experiments auch noch die Anzahl und Dauer der Blickabweichungen mit berücksichtigen.

iii

Abstract

Touchscreens devices are becoming more common in cars in place of physical buttons and switchesdue to the popular increase of computerization of cars. They offer a lot of functions and manyusers are already accustomed to handling devices like smartphones. However their use whiledriving is considered dangerous, since they don’t provide haptic feedback and a driver would needto lower his gaze away from the road. This Thesis analyses if a HUD would improve the user safety,by directly display the contents of a Touchscreen device, while maintaing the handling comfort.Therefore a study was conducted , for which a musicplayer application was created. Managingmusic is a popular tertiary activity of drivers and has the possibilty of testing many differentfunctions on a touchscreen device. In the user study participants conducted different tasks on atouchscreen device while driving with a simulator. Every task was repeated with the help of aHUD and without one. For every variation, the car deviation, reaction time, task duration anderror count was determined. Due to the small number of 7 participants no signifikant result couldbe achieved, however in most cases the variants with HUD had worse values as those without.Specifally the tasks with HUD needed almost always longer to be completed. Still in most casesthe variants with HUD was preferred by the participants, for this reason the count and durationof gaze deviation should be considered in future studies.

iv

Inhaltsverzeichnis

Inhaltsverzeichnis v

1 Einleitung 1

2 Relevante Arbeiten 32.1 Touchscreens im Auto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Headup Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Touchscreen und HUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Alternative Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 Blick-basierte Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.2 Zeigeauswahl mit 3d Feedback . . . . . . . . . . . . . . . . . . . . . . . 8

3 Implementierung 93.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.3 Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.4 Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Hauptbildschirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Listensuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 Texteingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.6 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6.1 Serialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6.2 Parcelable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6.3 Kommunikationsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Studie 194.1 Simulationsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Lane Chane Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 Zeitunterschied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v

INHALTSVERZEICHNIS vi

4.2 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.2 Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Zusammenfassung und Ausblick 285.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2 Fazit & Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A Daten 31A.1 Aufgaben Datentabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

B Fragebogen 43

Abbildungsverzeichnis 51

Tabellenverzeichnis 52

Abkürzungsverzeichnis 53

Literaturverzeichnis 54

Kapitel 1

Einleitung

Seit der Erfindung des Autos im 17. Jahrhundert 1 wurde von den Entwicklern verschiedenster Au-tomobilbranchen pausenlos an Verbesserungen gearbeitet, um seine Kunden sicher und zuverlässigan ihr Ziel zu bringen. Jedoch lag der Fokus nicht nur auf der Verbesserung der Fahrsicherheit undder Gewährleistung des Automobils als finanzierbares Massenprodukt für die Allgemeinheit. Zu-nehmend wurde nun auch darauf geachtet einen hohen Grad an Komfort zu gewährleisten. Nebstausgeklügelten Systemen wie beispielsweise des elektrischen Fensterhebers oder der Klimaanlage,welche inzwischen selbstverständlich serienmäßig in Autos vorhanden sind sollte das moderne Autonun auch computertechnisch auf dem neusten Stand sein. Durch das Einsetzen von Borddisplayskann das Auto mit dem Handy oder anderen externen Geräten verbunden werden und dadurchz.B. Musik durch Bedienung des im Auto integrierten Gerätes abspielen.

Da viele Menschen in Deutschland die Nutzung eines Touchscreen Gerätes wie Smartphones bereitsgewohnt sind, werden diese auch immer öfter von Herstellern wie BMW2 in PKWs an der Stellevon Tasten eingesetzt. Und das obwohl die Bedienung eines Touchscreens mehr Aufmerksamkeitfordert als das Drücken von Knöpfen, da der Fahrer seinen Blick unweigerlich für wenige Sekundenvon der Fahrbahn abwenden muss um das Display zu bedienen, weil die Tasten nun nicht mehrerfühlt werden können.

Um dieses Problem zu lösen wird in dieser Arbeit untersucht ob mit Hilfe eines HUD im Fah-rersichtfeld die Bedienung eines Touchscreens während der Fahrt unterstützt wird. Das Konzeptvon HUDs existiert bereits seit 1960 und wurde hauptsächlich für Kampfflugzeuge[1] entwickelt.Mittlerweile werden diese auch in Fahrzeugen verwendet, ein Fahrer sieht dabei die Projektionender Informationen seines Borddisplays direkt an der Windschutzscheibe seines PKWs und kanndiese somit präzise erfassen ohne seinen Blick senken zu müssen.

1Geschichte des Automobils, http://themen.autoscout24.de/die-geschichte-des-automobils, letzter Auf-ruf 25. März 2015

2BMW iDrive, http://www.bimmertoday.de/2015/01/06/ces-2015-bmw-idrive-mit-touchscreen-gestensteuerung/, letzter Aufruf 25. März 2015

1

http://themen.autoscout24.de/die-geschichte-des-automobils

http://www.bimmertoday.de/2015/01/06/ces-2015-bmw-idrive-mit-touchscreen-gestensteuerung/


Kapitel 1 Einleitung 2

Eine Kombination beider Technologien hätte somit das Potenzial, dass ein Fahrer während derBedienung seines Touchscreens, seine Aktionen im Fahrersichtfeld angezeigt bekommt und erso seinen Blick nicht von der Straße abweichen müsste. Somit blieben theoretisch der Komfortund die Funktionalität von Touchscreens erhalten ohne dass die Fahrsicherheit bei der Bedienungleiden müsste. Um diese Theorie auf die Probe zu stellen, wurde in dieser Arbeit eine Studiedurchgeführt in der die Teilnehmer ein Touchscreen bei gleichzeitiger Fahrt und Verwendungeines HUD zu bedienen hatten. Als Applikation für dieses Experiments wurde ein Musikspielerimplementiert, da das Abspielen von Musik eine beliebte tertiäre Tätigkeit während der Fahrt ist.Zudem bietet es sich hierbei an unterschiedliche Methoden der Interaktion zu untersuchen, wieTasten, Streifen oder Texteingaben.

Kapitel 2

Relevante Arbeiten

Diese Untersuchung bezieht sich hier auf vorherige Studien welche die Nutzbarkeit und Sicherheitvon Interaktionsgeräten durch tertiäre Tätigkeiten während einer Autofahrt erforschten. In diesemKapitel werden einige dieser Arbeiten mit ihren Erkenntnissen vorgestellt, insbesondere derer diebereits die Verwendungen von HUDs und Touchscreens in diesem Kontext erforscht haben.

2.1 Touchscreens im Auto

Da Touchscreens viele Funktionen zu bieten haben, ist es interessant, deren Vor- und Nachteileim Auto zu bestimmen. Ein Vorteil ist unter anderem, dass es eine direkte Eingabe auf einemBildschirm erlaubt und es eine direkte Beziehung zwischen dem was die Augen sehen und wasdie Hände machen gibt, was es für Nutzer einfach macht, sich an die Bedienung zu gewöhnen.Nachteile sind jedoch, dass der Fahrer seinen Blick senken muss um ein Touchscreen zu bedienenund dass man kein physisches Feedback über eigene Tätigkeiten erhält.

Harvey et. al verglichen die Interaktion von Touchscreens und Drehencoder während des Fahrensgegeneinander [2]. Die Drehencoder Experimente bestanden aus einem Display im Fahrersichtfeldund einem Drehencoder in der Mittelkonsole. Der Drehencoder ist eine indirekte Eingabemethodewelche vor allem geeignet für repetitive Aufgaben ist und für solche bei denen eine hohe Genauigkeitgefordert wird. Es hat außerdem den Vorteil eines besser positionierten Displays, sowie physischesFeedback. Jedoch dauert es durch die indirekte Eingabe länger eine Aufgabe zu erledigen undist für Novizen schwer zu erlernen. Den Testern wurden 20 verschiedene Aufgaben gestellt inden Kategorien Infotainment, Komfort, Kommunikation und Navigation. Sie benutzten dabei denFahrsimulator der Universität von Southampton, mit eingespielten Verkehr, bei dem ein schlechtesFahrverhalten zu einem Crash führen kann. Beide Interaktionen führten zu wesentlich schlechterenFahrperformanzen jedoch waren laut der Studie die Touchscreens den Drehencodern in fast allenAspekten wie Blickverhalten, Fahrkontrolle und Nutzer Zufriedenheit überlegen.

1BMW-iDrive, http://www.bimmertoday.de/2015/01/06/ces-2015-bmw-idrive-mit-touchscreen-gestensteuerung/, letzter Aufruf 20. März 2015

3



Kapitel 2 Relevante Arbeiten 4

Abbildung 2.1: BMW-iDrive 1

Eine der Arbeiten auf die sich meine Arbeit stützt, erforscht die Nutzbarkeit von TouchscreenGeräten im Auto. Insbesondere wird dabei auch die Bedienung eines Musikspieler untersucht [3].In der Arbeit hat man einen Musikspieler bei dem man in einer Liste zwischen mehreren Titelnscrollen kann. Insbesondere werden verschiedene Gesten Techniken verglichen, sowie die optimaleAnzahl der Gegenstände um die Ablenkung für den Nutzer möglichst gering zu halten.

Je weniger Gegenstände auf dem Bildschirm angezeigt werden, desto weniger wird ein Nutzervon den Informationen abgelenkt, denn es fällt ihm leichter die einzelnen Titel zu lesen und zuverarbeiten während nur ein kurzer Blick auf das Display ausreicht. Bei einer größeren Liste vonTitel und wenigen Gegenständen pro Seite hat man dann aber das Problem, dass es länger dauernkann einen gewünschten Titel zu finden wodurch der Blick des Nutzers ebenfalls länger abgelenktwird. In der Arbeit wird dieses Verhalten mit jeweils 3, 5 und 7 Gegenständen pro Seite getestet.Dabei waren laut der Studie 7 Gegenstände am wenigsten geeignet, wobei 5 keinen signifikantenVorteil über 3 Gegenstände hatten.

Das zweite Problem das getestet wurde, war welche Methode sich am besten eignete um dieListe zu navigieren [3, 4]. Es wurden die Bedienung mittels Tasten, Swipe und Kinetic Swipemiteinander verglichen. Kinetic Swipe hatte die größte visuelle Belastung und führte daher auchzu den meisten Fehlern. Swipe stellte sich dabei als die am wenigsten ablenkende Methode heraus.

Bachfischer et al. erforschten die Nutzerfreundlichkeit eines anpassungsfähigen Touchscreens,bei dem die Buttons im Display sich bei Näherung vergrößerten [5]. Sie untersuchten, welchenEinfluss adaptive Buttons im Fahrzeug auf das Visuelle Verhalten und das Bewegungsverhalteneines Fahrers hat.


Abbildung 2.2: Garmin HUD2

Dabei lag in ihrer Studie bei einem nicht-anpassungsfähigen Touchscreen die Fehlerrate bei 7%,wohingegen die Fehlerrate bei einem anpassungsfähigen Touchscreen bei 0% lag und die Blickdauerebenfalls in dieser Variante ebenfalls kürzer war.. Jedoch war die Bewegungsdauer in der Variantefür die Aufgaben nicht signifikant geringer als beim nicht anpassungsfähigen Touchscreen.

Touchscreen Interaktion verlangen häufige Blickabwendung von der Straße, insbesondere längerenTexteingaben sowie kinetic scrolling [6]. Diese bieten nämlich nur visuelles Feedback, daher wärenmögliche Verbesserungen von Touchscreens im Auto zum Beispiel das Hinzufügen von Audio oderhaptischer Wahrnehmung möglich[7].

2.2 Headup Display

Eine Möglichkeit die visuelle Belastung zu minimieren und den Blick eines Fahrers auf die Straße zukonzentrieren, wäre die Verwendung eines Headup Displays. Bei einem HUD werden Informationendirekt in der Windschutzscheibe angezeigt, wodurch es die Notwendigkeit den Blick von der Straßeabzuwenden für den Fahrer sinken sollte.

Studien zeigen, dass HUDs eine Verbesserung effizienter Informationsanzeige im Auto leistenkönnen, unter anderem im Vergleich mit Headdown Display (HDD) [8]. Außerdem ist die Anpas-sungszeit die ein Fahrer braucht um sich an ein HUD zu gewöhnen kürzer, da er seinen Blick nichtverändern muss, um sich auf die Informationen zu konzentrieren. Laut den Studien sind HUDauch bei den Nutzern die bevorzugte Variante.

2Garmin HUD, http://www.techradar.com/reviews/car-tech/tom-tom-gps-and-sat-nav/garmin-hud-1204503/review, letzter Aufruf 20. März 2015

http://www.techradar.com/reviews/car-tech/tom-tom-gps-and-sat-nav/garmin-hud-1204503/review

http://www.techradar.com/reviews/car-tech/tom-tom-gps-and-sat-nav/garmin-hud-1204503/review


Es gibt jedoch auch Probleme die bei HUDs auftreten können wie zum Beispiel, dass die Aufmerk-samkeit des Fahrers auf die Anzeige des HUDs fokusiert ist [1]. Oder dass die Wahrnehmung desFahrers eingeschränkt auf den Blickbereich des HUDs ist und er Aktivitäten die am Rand gesche-hen schlechter erkennt Außerdem ist die Sichtbarkeit des HUD von Lichtkonditionen abhängig.

Weinberg et al. evaluierten die Nutzbarkeit eines HUDs für das Auswählen aus einer Liste inFahrzeugen [9]. Dabei wurden drei Methoden getestet um aus einer Liste auszuwählen, nämlichmittels HDD, HUD und Audioansage(kein Display). Zur Navigation und Auswahl aus der Listewurde ein Jog-Dial verwendet und bei der HDD und HUD wurden maximal 7 Gegenstände proSeite angezeigt mit 2 Seiten insgesamt. HUD und Audio waren dabei am wenigsten ablenkend,allerdings brauchte man bei den Audioansagen wesentlich länger einen Gegenstand auszuwählen.

2.3 Touchscreen und HUD

Eine zu diesem Project ähnliche Arbeit von Lauber et al. untersuchte ebenfalls, ob ein HUDdie Bedienung von Touchscreens im Fahrzeug unterstützt[10]. In ihrer Studie verwendeten sieaußerdem eine Kinect Kamera um die Position eines kurz über dem Touchscreen schwebendenFingers zu erkennen. Zudem gab es ebenfalls einen Knopf am Steuerrad als Alternative zumKlicken auf dem Touchscreen. Man musste in ihren Studien einen Ortsnamen mittels einer Tastaturam Touchscreen eingeben, dabei wurden 6 verschiedene Methoden dafür auf Effizienz verglichen.Die Methoden wurden in folgende Kategorien gegliedert, nämlich Schwebe (Hover) gegen Kontakt(durch Sliding) basierte Aktivierung und Suche, Klick (am Steuerrad) gegen Touch als Selektionund ob das Zoomen der Gegenstände bei den Hover Varianten sinnvoll ist. Die erste Studie wurdenoch ohne HUD geführt.

Für das Markieren von Gegenständen konnte kein signifikanter Unterschied zwischen Kontakt undHover basierter Suche festgestellt werden, aber bei der Auswahl waren in fast allen Tests dieKlickkonzepte besser als die Touchkonzepte. Die bevorzugten Varianten waren Hover-Klick undSlide-Klick. Methoden mit Zoom hingegen stellten sich dabei als schlechter heraus als die ohneZoom.

In einer zweiten Studie wurden nur noch die Hover Konzepte verwendet, es wurde dann jeweilsmit Mittelkonsole und mit HUD untersucht wann welche Auswahlvariante die effizienteste war.Dabei war Touch die bevorzugte Variante bei der Mittelkonsole und Klick die bessere beim HUD.


Eine Vermutung warum die Nutzer bei den Touch Konzepten mit HUD schlechter waren istdie, dass beim Touch eine höhere Hand-Augen Koordination erforderlich war. Gerade auch beider rein Kontakt-basierten Variante Slide-Lift, bei der eine Taste durch Berühren markiert wirdund durch Hochheben des Fingers ausgewählt wird. Slide-Lift fühlte sich selbst bei erfahrerenTouchscreen Nutzern komplex und ungewohnt an. Da in dieser Arbeit jedoch keine Kinect-Kameraoder ähnliches verwendet wurde, war dies die Methode die für die Studie bei der Texteingabeeingesetzt wurde.

2.4 Alternative Konzepte

2.4.1 Blick-basierte Auswahl

Es gibt außerdem auch andere Konzepte, wie die Blick-basierte Auswahl auf mehreren Bildschirmenim Auto [11] von Poitschke et al. Dabei wird ein Blickerkennungssystem mit mehreren Monitoren,unter anderem einem HUD und 3 HDD verwendet. Ein Nutzer kann auf einem der Bildschir-me einen Gegenstand mittels Blickkontakt aus dem System auswählen. Dieser wird am Monitordann auch farblich markiert. Dadurch kann sehr schnell ein Gegenstand ausgewählt werden. Diesist selbst für Anfänger leicht zu erlernen und und lässt es zu, dass der Fahrer seine Hände aufdem Lenkrad behält. Allerdings wird Blickkontakt nicht benutzt um ausgewählte Gegenständezu bestätigen, da unter anderem eine Eingabeaktion unterbrechbar sein soll, zum Beispiel für be-stimmte Verkehrssituationen. Stattdessen werden am Lenkrad Multi-Funktions-Tasten verwendetum durch Drücken einen Gegenstand auszuwählen und mittels Drehen zum Beispiel eine Liste raufund runter zu scrollen. Da dies eine Methode ist bei der haptische Wahrnehmung verwendet wird,ist ein Fahrer weniger visuell vom Fahren abgelenkt wie bei der Verwendung eines Touchscreen.Sie verwenden dennoch ein Touchscreen Gerät kombiniert in ihrem Experiment, um mittels Dragand Drop Widgets von einem Display zum anderen zu verschieben. Jedes der Widgets konnte auchrein mit Touchscreen bedient werden, um dann in ihrer Studie mit dem blick-basierten Konzeptverglichen zu werden. In ihrer Studie haben sie 15 Teilnehmer mit beiden Konzepten verschiede-ne Eingaben testen lassen, während sie mit dem Lane Change Test (LCT) Program eine Fahrtsimulierten. Zwei von ihnen bereits vertraut in Blick-basierte Eingaben. Die durchschnittlichenErgebnisse gaben an, dass das Blick basierte Konzept zu größeren Fahrabweichungen und Reak-tionszeiten führte auf Grund der hohen mentalen Belastung. Die Blick-trainierten Fahrer jedochhatten grundsätzlich bessere Werte in dieser Variante.


2.4.2 Zeigeauswahl mit 3d Feedback

Fujimura et. al. entwickelten ein System bei dem ein Fahrer auf Ziele die sich außerhalb derWindschutzscheibe befinden mittels Fingergesten zeigen kann, über welche er dann Informationenerhalten kann. Diese Eingabemethode ist gepaart mit einem 3d-HUD, welches visuelles Feed-back in einem passenden Tiefenbereich außerhalb des Fahrzeugs liefern kann. Mittels Zeigenkönnen physische Gegenständen wie Geschäfte oder Straßenschilder ausgewählt werden und fallsdie Applikation die Identität dieses Gegenstands erkennt werden Informationen dazu im 3d-HUDdargestellt. Das 3d-HUD generiert dabei Bilder auf verschiedenen Focus Ebenen, welche dadurchdie Distanz zu Zielen anpassen können, auch während sich das Fahrzeug bewegt. Jedoch muss sichder Kopf des Nutzers innerhalb eines bestimmten Bereiches vor der Windschutzscheibe befinden,da ansonsten das generierte Bild nicht mehr sichtbar ist. Die Eingabemethode mit dem Zeigenhat zudem den sicherheitstechnischen Vorteil, dass die Hand des Fahrers auf dem Lenkrad bleibenkann. In ihrer Studie nahmen Fujimura et. al. Szenen von verschiedenen Fahrrouten auf undprojizierten diese auf einen gekrümmten Bildschirm. Während der simulierten Fahrt wurden dieseSzenen abgespielt und die Teilnehmer wurden darauf hingewiesen auf bestimmte gelbe Markierun-gen auf Gebäuden zu zeigen, um das abwechselnde Auswählen verschiedener Ziele zu simulieren.Ihre Ergebnisse dabei deuteten darauf hin, dass die Finger Tracking Verfolgung schnell genug istum bei moderaten Geschwindigkeiten verwendet zu werden. Es hat zudem das Potenzial dass esfür Nutzer intuitiv zu lernen ist und sie dabei jedoch vom Fahren nicht zu sehr abgelenkt werden.

Kapitel 3

Implementierung

Im diesem Kapitel wird die Implementierung der Musikspieler Applikation für die Studie vorgestellt.Dieser ist in Java mit Eclipse als Entwicklungsumgebung für zwei Androidgeräte programmiertworden. Eines der Geräte ist für das Touchscreen, dass andere für das HUD. Das TouchscreenGerät enthält den eigentlichen Musikspieler und alle Nutzereingaben werden auf diesem ausgeführt.Mittels Transmission Control Protocoll (TCP) sendet der Touchscreen stets Nachrichten an dasHUD damit dieses seine Graphic User Interface (GUI) anpassen kann. Es gibt bei beiden Gerätdrei verschiedene GUI Anzeigen für den Hauptbildschirm, der Listenannzeige und der Anzeige vonTexteingaben. Es folgt nun eine Erläuterung über die Android Umgebung, sowie ein Überblicküber die Funktionsweise der Implementierung.

3.1 Android

Android ist mit einem Linux Kernel als Betriebssystem und einer erweiterten und optimiertenvirtuellen Maschine für Java Anwendungen ausgestattet[12]. Java ist eine Programmiersprachedie von einer stetig wachsenden Anzahl von Entwicklern genutzt wird, während der Linux KernelAndroid die Flexibilität gibt um auf verschiedenen Hardwareplattformen verwendet zu werden. DieKomponenten von Android sind als Stack gestaltet, mit den Applikationen als oberste und demLinux Kernel als unterste Schicht.

Eine Android Applikation besteht aus unterschiedlichen Komponenten die lose miteinander ge-koppelt sind. Die Architektur der Applikation erlaubt das Wiederverwenden bereits vorhandenerKomponenten

Android enthält außerdem eine Reihe von Kern Komponenten, wie einen Email-Client, einemSMS-Program, etc.

9

Kapitel 3 Implementierung 10

3.1.1 Activities

Bei Activities[13] werden die GUI Elemente mit dem Programmcode verbunden. Der Nutzer kanndiese sehen und mit ihnen agieren. Eine Applikation kann aus mehreren Activities bestehen und auseiner Activity kann man in eine andere wechseln. Der Android Kern kontrolliert den Lebenszykluseiner Activity, wie in Abb. 4.1 dargestellt. Wenn von einer Activity aus eine andere gestartet wird,wird die ursprüngliche gestoppt und die neue fängt an. Dabei wird die ursprüngliche Activity aufeinem Back-Stack wie in Abb. 3.2 Abb. 3.2. Das Back-Stack funktioniert nach dem "last out,first in"Prinzip somit wird beim Ende einer momentanen Activity, die Activity welche zuletzt inden Back-Stack kam gestartet. Verwendete Activities sind hier jeweils für den Hauptbildschirm,die Listenanzeige und die Anzeige der Texteingabe verantworlich.

Abbildung 3.1: Android-Activity-Lifecycle


Abbildung 3.2: Back-Stack

3.1.2 Services

Services [13] sind Komponenten die im Hintergrund laufen sollen, um wiederholende, zeitintensiveAktionen zu übernehmen, welche keine GUI benötigen. Sie können manuell oder über eine Bin-dung an eine Komponente, welche auch aus verschiedenen Applikationen erfolgen kann, gestartetwerden. Ein Service hat außerdem eine höhere Priorität als inaktive oder unsichtbare Activitiesund es ist daher weniger wahrscheinlich, dass diese vom Android System beendet werden. Eswerden für diese Applikation zwei Service Klassen, eine für den Touchscreen (ServerService) undeine für den HUD (ClientService) verwendet, um die Verbindung der beiden zu steuern.

3.1.3 Intents

Intents [13] sind Vorhaben mit denen eine bestimmte Aktion durchgeführt werden kann. Wenneine andere Activity aus einer Activity gestartet werden soll verwendet sie ein Intent, welchesmit Informationen darüber angereichert wird. Das Intent wird vom Android-Kern empfangen undstartet die entsprechende Activity. Zudem kann man mit Intents Daten von der ursprünglichenActivity zu der neuen übermitteln. Zum Beispiel wird dies hier verwendet, um eine Liste vonTitelnamen von einer Activity zu einer anderen zu übermitteln.


3.1.4 Permissions

Jede Applikation läuft in einer Sandbox und hat von Anfang an weder die Berechtigung auf dasInternet zuzugreifen, noch SMS zu empfangen, etc. Damit das System weiß welche Berechtigungeneine Applikation hat, muss man dieser erst Permissions1 geben. Diese werden in der AndroidManifest Datei definiert, um zum Beispiel in diesem Fall den Netzwerkzugriff zu erlauben.

3.2 Hauptbildschirm

Der Hauptbildschirm auf dem Tablet wird von der Activity MusicPlayer dargestellt, welcher dieStandardansicht des Musikspielers während einer Fahrt anzeigt. MusicPlayer ist außerdem für dieVerwaltung und Kontrolle der abgespielten Lieder verantwortlich. Jede Instanz eines Liedes wird imMusicPlayer alsMusic Objekt geladen, mit dem die verschiedenen Zustände der Instanz kontrolliertwerden können. Vom Hauptbildschirm aus kann man in die Listenanzeige oder in die Ansicht derTexteingabe wechseln. Beide Ansichten führen nur wieder zurück zum Hauptbildschirm. DieLieder werden auch dann weiter wiedergegeben wenn man sich nicht mehr im Hauptbildschirmbefindet. In dieser Ansicht hat ein Nutzer folgende Eingabemöglichkeiten:

1. Play/Pause: Die Musik kann gestartet oder pausiert werden. Das Bild des Buttons ändertsich dementsprechend.

2. Stop: Stoppt die Wiedergabe der Musik und setzt es auf ihre Startzeit zurück.

3. Shuffle: Wird am Tablet rot markiert wenn es eingeschaltet ist und erscheint fest am HUD.Die Wiedergabe der Lieder erfolgt dann zufällig

4. Looping: Wird rot markiert wenn es eingeschaltet ist und erscheint fest am HUD. Wennder momentane Titel von selbst zu Ende ist, wird er wiederholt.

5. Start: Rot wenn inaktiv. Wenn es gedrückt wird beginnt es für die nächste Aufgabe desExperiments zu loggen und wird grün. Wechselt wieder auf rot wenn die Aufgabe geschafftwurde oder eine Minute vergangen ist.

6. Suchleiste: Die Suchleiste zeigt den momentanen zeitlichen Fortschritt des aktuellen Titelsan. Mittels klicken oder gleiten kann der Balken verschoben werden und so zu einer anderenStelle des Liedes gewechselt werden.

1System Permissions, http://developer.android.com/guide/topics/security/permissions.html, letzterAufruf 14. März 2015

http://developer.android.com/guide/topics/security/permissions.html


Abbildung 3.3: HUD HauptbildschirmAbbildung 3.4: Touchscreen Hauptbildschirm

7. Streifen:

a) von Links nach Rechts: Wechselt zum vorherigen Titel

b) von Rechts nach Links: Wechselt zum nächsten Titel

c) von Oben nach Unten: Wechselt zur Listenanzeige

d) von Unten nach Oben: Wechselt zur Tastaturanzeige

8. Back,Recent,Home Diese 3 Eingaben sind nicht für die Benutzung der Teilnehmer vor-gesehen, da diese aber zum Android Standard dazugehören, wurde sie umgeändert um dieStudie möglichst wenig zu stören falls ein Teilnehmer versehentlich darauf klickt. Die BackTaste funktioniert nur wenn man sie längere Zeit gedrückt hält und wird nur vom Studien-leiter verwendet um wieder aus der Applikation rauszugehen. Die Recent und Home Tastekann man nicht ohne weiteres abschalten. Deswegen werden folgende Methoden verwendetum zu weniger Problemen zu führen. Sobald der Recent Key gedrückt wird und die letz-ten Applikationen angezeigt werden, werden diese sofort wieder geschlossen und der Nutzerkann ohne Probleme weitere Eingaben machen. Die MusicPlayer Applikation wurde alsHeim Anzeige im Manifest eingestellt. Daher gelangt man durch Drücken der Home Tasteimmer zurück zum Hauptbildschirm der Applikation. Dies gilt auch für die anderen Activi-ties des Touchscreens. Probleme gab es trotzdem immer noch beim Streifen von der HomeTaste aus. Bei der Studie wurden Teilnehmer auch daraufhin hingewiesen diese Tasten wennmöglich nicht zu berühren.

Durch das gedrückt halten eines Buttons wird dessen Hintergrundfarbe rot markiert und erscheintals Symbol auch am HUD in der oberen Mitte des Bildschirms wie hier in Abb. 3.3 das PlaySymbol. Wenn man einen Button drückt wird dieser erst durch das Hochheben des Fingers an derStelle aktiviert. Wenn zum Beispiel auf den PlayButton gedrückt wird, der Touchscreen gedrücktbleibt, aber der Finger zum Stop Button gleitet und dann losgelassen wird, dann wird die StopTaste aktiviert und nicht die Play Taste. Dieses Prinzip basiert auf dem Slide-and-Lift von Lauberet. al [10]. Die Activity HeadupDisplay stellt die Anzeige des Hauptbildschirm auf dem HUD dar.


Abbildung 3.5: Listen Anzeige für HUD undTouchscreen

Abbildung 3.6: Texteingaben Anzeige für HUDund Touchscreen

Anders als bei den anderen beiden Ansichten ist die Anzeige vom HeadupDisplay nicht identischmit der des MusicPlayer. Das Design soll minimalistisch alles was sich am Touchscreen abspieltanzeigen doch gleichzeitig bei einer Fahrt ohne Bedienung des Musikspieler die Sicht wenig stören.Die Buttons am Touchscreen hingegen sind ziemlich groß und befinden sich jeweils an den Eckender Applikation, um es dem Nutzer möglichst einfach zu machen diese auch ohne hinzusehen zutreffen.

3.3 Listensuche

Die Listenanzeige wird auf dem Touchscreen durch die Activity MusicList und auf dem HUDdurch HeadupList dargestellt wie in Abb. 3.5. Man kommt in den Listenmodus indem manauf dem Touchscreen im Hauptbildschirm von oben nach unten streift. Die Anzeige ist aufbeiden Geräten identisch. Es werden immer 5 Titel dargestellt, durch das Streifen von untennach oben kommt man zu den nächsten 5 und durch das Streifen von oben nach unten zu denvorherigen 5. Auch wenn mehr als 5 Titel anzuzeigen am HUD weniger problematisch wäre, würdedies auf dem Touchscreen dazu führen, dass man seinen Blick länger abwenden müsste um dieTitel zu lesen [3, 9]. Der Bildlauf ist dabei nicht kinetisch, da dies zu Problemen während einerAutofahrt führen könnte [4]. Das Anklicken und gedrückt halten der Titel funktioniert genauso wiebeim Hauptbildschirm. Wenn ein Lied ausgewählt wurde, wird man zurück zum Hauptbildschirmgebracht und der ausgewählte Titel wird abgespielt. Durch das Streifen von links nach rechtswährend des Listenmodus wird der Nutzer ebenfalls zurück zum Hauptbildschirm geleitet ohnedass ein Titel gewechselt wird.


3.4 Texteingabe

Die Texteingaben Anzeige ist genau wie bei der Liste auf beiden Geräten identisch und wird durchdie Klassen MusicKeyboard auf dem Touchscreen und HeadUpKeyboard auf dem HUD erstelltund verwaltet wie in Abb. 3.6. Man kommt in diese Ansicht durch das Streifen von unten nachoben auf dem Touchscreen vom Hauptbildschirm aus. In diesem Modus kann man einen Titelauswählen indem auf der Tastatur der Name des Liedes eingegeben wird. Die Tastaturbelegungsollte möglichst vertraut wirken und ähnelt deshalb der deutschen QWERTZ Belegung welcherauf den meisten Geräten wie Computer und anderem verwendet wird. Es kommen alle deutschenBuchstaben von A bis Z vor, ausgeschlossen sind hier die Umlaute Ä,Ö,Ü sowie ß. Die letztenzwei Tasten sind „Delete“um den letzten eingegebenen Buchstaben zu löschen und „Enter“umden eingegebenen Titel zu starten. Die Tastatur sollte außerdem möglichst viel Platz für dieTasten bieten, damit diese leicht zu treffen sind. Daher wurde auch nicht die Standard Tastaturvon Android hergenommen um möglichst viel Platz zu haben ohne dass nicht verwendete Tastendiesen wegnehmen. Das Drücken der Tasten funktioniert ebenfalls so wie beim Hauptbildschirmund der Liste. Genau wie bei der Listenanzeige kommt man zurück zum Hauptbildschirm durchdas Streifen von links nach rechts. Als Hilfe wird rechts neben der Texteingabe angezeigt, ob daseingegebene Wort in der Liste der Titel vorhanden ist. Bei einen grünen Haken ist es vorhanden,bei einem roten Kreuz nicht. Solange kein korrekter Titelname eingegeben wurde funktioniert auchdie „Enter“Taste nicht. Aufgrund der Platzbeschränkung auf dem Nexus 4 wurde die Wortlängebei der Eingabe auf 6 Buchstaben begrenzt.


3.5 Logging

Um Daten über die Eingaben von Teilnehmern in der Studie zu erfassen, werdem einem Teilnehmerverschiedene Aufgaben gestellt, die er lösen muss. Während einer Aufgabe werden Daten bezüglichseiner Eingaben erfasst. Dafür ist die Klasse UserLogger zuständig, die verwaltet, welche Aufgabegerade erledigt werden soll und alle Eingaben des Nutzers während einer Aufgabe loggt. Es werdendie Identifizierungsnummer des Teilnehmers (ID),die aktuelle Aufgabe (Task), die momentane Zeit(Current Time), die momentane Dauer (Duration), die minimal nötigen Aktionen für die Aufgabe(Min Actions), die momentane Anzahl an Aktionen (Used Actions), die falschen Aktionen (Errors),sowie die momentane Aktion geloggt (CurrentAction). Diese Daten werden dann in .csv Dateiengespeichert. In Tabelle 3.1 wird der Inhalt einer Zeile einer Log Datei dargestellt. Beim Startder Touchscreen Applikation kommt man zuerst in die Launcher Activity (siehe Abb. 3.7) wo derStudienleiter folgende Daten eingeben kann. Die Identifizierungsnummer des Teilnehmers, einenZeitunterschied der beim Logging stets dazu addiert wird, die Variante (mit oder ohne HUD)sowie die Aufgaben die geloggt werden und ihre Reihenfolge.

Tabelle 3.1: Eine Zeile einer beispielhaften csv-Logdatei der Touchscreen-AnwendungID Task CurrentTime Duration1hud42 KEYBOARD SEARCH 2015-03-10 10:42:06.988 8001msMin. Actions Used Actions Errors CurrentAction8 4 1 (KEYBOARD: CLICK_KEY + v)

Abbildung 3.7: Launcher Activity


3.6 Kommunikation

3.6.1 Serialisierung

Serialisierung 2 wird hier für die Übertragung von Objekten über das Netzwerk verwendet. Dabeiwird der komplette Zustand des Objektes, inklusive aller referenzierten Objekte, in einen Daten-strom umgewandelt. Der Datenstrom kann über das Netzwerk geschickt werden und dann amZiel deserialisiert werden. Mit Deserialisierung kann aus dem Datenstrom das Objekt wieder neuerzeugt werden.

3.6.2 Parcelable

Um primitive Daten zwischen zwei Android Activities zu senden reicht es aus, wenn man dafürIntents benutzt. Für das Versenden von Java Objekten gibt es jedoch zwei Möglichkeiten Seria-lizable oder Parcelable 3. Für das Versenden von Objekten in Android ist die Parcelable Variantejedoch deutlich schneller und erzeugt weniger Müll Objekte. Für diese Verwendung wird deshalbin der Applikation Parcelable verwendet.

3.6.3 Kommunikationsablauf

In der Applikation werden spezielle Objekte, welche die Klasse HUDMessage implementieren, vomTouchscreen aus zum HUD gesendet mittels TCP, damit das HUD seine GUI entsprechend an denvom Touchscreen anpassen kann. Sowohl der Touchscreen als auch das HUD regeln die Kommu-nikation über Services die in ihren eigenen Threads laufen, so dass eine Verbindung nicht abbrichtwenn es einen Wechsel von Activities gibt. Neben HUDMessage implementieren die zu sendendenObjekte ebenfalls Parcelable, sowie Serializable. Zuerst wird jedes Objekt einer Touchscreen Ac-tivity mittels Parcelable an ServerService geschickt. Von dort aus wird es über das Netzwerk zuClientService gesendet, wo es zu der momentan sichtbaren Activity vom HUD geschickt wird. InAbb. 3.8 wird der Kommunikationsablauf in einem Beispiel mittels eines Sequenzdiagramm spezifi-scher dargestellt. In diesem Beispiel führt ein Nutzer drei Aktionen auf dem Touchscreen aus. Erstwechselt er vom Hauptbildschirm zur Anzeige der Texteingabe, dann gibt er einen Buchstaben einund wechselt wieder zurück.

2Java - Serialization, http://www.tutorialspoint.com/java/java_serialization.htm, letzter Aufruf 14.März 2015

3Parcelable vs. Java Serialization in Android App Development, Ravindra Kumar Prajapati, http://www.tutorialspoint.com/java/java_serialization.htm, letzter Aufruf 14. März 2015

http://www.tutorialspoint.com/java/java_serialization.htm




Abbildung 3.8: Kommunikations Beispiel

Kapitel 4

Studie

Um die Annahme, dass ein HUD die Bedienung von Touchscreens im Auto erleichtern, sowie dieFahrsicherheit erhöhen kann zu prüfen, wurde eine Nutzerstudie durchgeführt. Dabei nahmen7 Nutzer teil welche bei simulierten Fahrten gleichzeitig ein Touchscreen bedienen mussten. Eswurden dabei zwei Varianten unterschieden und gegeneinander verglichen, einmal mit HUD undeinmal ohne HUD.

4.1 Simulationsaufbau

Um möglichst genaue Daten über den Einfluss der Bedienung von Touchscreengeräten mit der Hilfevon HUD auf Fahrer zu messen, wurde folgender Simulationsaufbau wie in Abb. ?? angewendet.Ein Teilnehmer benutzte auf einem PC das LCT Programm um die Fahrszenarien mit einemLenkrad nachzustellen [14]. Als Lenkrad wurde in der Simulation ein Logitech G27 verwendet.Rechts, auf Höhe der Mittelkonsole, wurde ein Nexus 10 Android Tablet positioniert. Vor demBildschirm wurde ein Nexus 4 Smartphone aufgestellt, welches das HUD simulieren sollte. Abb. ??zeigt einen der Teilnehmer beim Experiment.

4.1.1 Lane Chane Test

Das LCT Programm ist eine einfache Methode, mit dem Ziel, die Belastung der Bedienung vontertiären Aufgaben für einen Fahrer zu ermitteln. Teilnehmer mussten ein simuliertes Fahrzeugauf einer dreispurigen Fahrbahn kontrollieren, auf der kein Verkehr herrschte. Mittels Zeichen aufSchildern, die sich auf beiden Seiten der Straße befanden, wurden die Teilnehmer angewiesen dieFahrbahnen zu wechseln. Die Nutzer hatten dabei das Gaspedal ständig durchgedrückt um diemaximal eingestellte Geschwindigkeit von 60 km/h zu halten. Ein bekannter Nachteil ergibt sichjedoch, da es bei mehrmaligen Benutzen des LCT zu Lerneffekten kommen kann [15].

19

Kapitel 4 Studie 20

Um dem entgegen zu wirken, fuhren alle Teilnehmer bei jeder einzelnen Fahrt eine andere Streckedes Simulators. Mit dem Programm wurden nach jedem Experiment die Fahrabweichungen sowiedie Reaktionszeiten der Teilnehmer bei den einzelnen Aufgaben analysiert wie in Abb. 4.2.

Abbildung 4.1: Simulationsaufbau

Abbildung 4.2: LCT Analyser

Kapitel 4 Studie 21

4.1.2 Zeitunterschied

Während der Simulation wurden für alle Aufgaben die Interaktionszeiten des Nutzers am Tabletgeloggt und nach den Experimenten mit den Fahrdaten vom LCT am PC verglichen. Die Uhrender beiden Geräte waren nicht synchronisiert, daher konnte es zu Zeitunterschieden kommen, dieeinen Vergleich der Ergebnisse der beiden Messungen verfälschen würden. Um diesem Problemvorzubeugen wurde die Software Tools Wireshark und PingTools Network Utilities verwendet.PingTools schickte vom Tablet aus mehrere Pings an den PC. Man erhielt dann in der Applikationdie Zeiten t1 wann die Pakete losgeschickt wurden als auch deren Umlaufzeiten.

Gleichzeitig konnte man auf Wireshark an den eingefangenen Paketen ihre Ankunftszeit t2 ablesen.Daraus ließ sich der Zeitunterschied d mit

d = t2 − t1 − R

2

ermitteln, der immer zu den Messungen vom Tablet addiert wurde. Für die Studienzwecke war esausreichend, dass der Zeitunterschied nur einmal vor jeden Experiment festgestellt wurde.

4.2 Ablauf

4.2.1 Einführung

Vor Beginn der Studie wurden die Teilnehmer an die Bedienung der Musikspieler Applikationauf dem Tablet eingewöhnt. Es wurden alle Funktionen der Applikation erklärt, sowie auch dieBedeutungen der Anzeigen auf dem HUD. Nach einer gewissen Eingewöhnungszeit konnten siedie Aufgaben des Experiments jeweils einmal ausführen, um zu vermeiden dass es bei dem Test zueinem Unterschied wegen Lerneffekten kommt. Die Klick und Swipe Aufgaben waren identisch wieim Experiment, damit die Teilnehmer den Ablauf nicht verwechseln würden. Bei der Listensucheund der Texteingabe wurde jedoch ein anderes Wort vorgegeben. (Mehr Details zu den Aufgabenim Ablauf)

Der Musikspieler enthielt 46 identische Titel die sich nur namentlich unterschieden. Die Melodiewar immer gleich, um zu verhindern dass es bei der Bedienung der Suchleiste zu Unterschiedenwegen der Dauer kommen konnte. Die Namen der Titel bezogen sich dabei nicht auf die eigentlichabgespielte Musik, sondern waren allgemein bekannte Wörter die so ausgewählt wurden, damitderen Eingabe ungefähr gleich schwierig ist. Jeder Titel hatte dabei die gleiche Länge, es kamenmaximal zwei gleiche Buchstaben im selben Wort vor und keine gleichen Buchstaben hintereinan-der. Es wurden alle Buchstaben des deutschen Alphabets als Anfangsbuchstaben verwendet außer„ä,ö,ü,q,y,x“.

Kapitel 4 Studie 22

Abbildung 4.3: Ausschnitt vom Studienplan

Jeder der 23 Buchstaben kommt doppelt als Anfangsbuchstabe der 46 Titel vor. Als Wortlängewaren 6 Buchstaben festgesetzt um eine leicht moderate Schwierigkeit bei der Texteingabe zuhaben.

Nachdem die Nutzer sich mit dem Musikspieler zurecht fanden, machten Sie sich mit dem Fahr-simulator vertraut. Dabei fuhren sie die Strecke 5 des LCT ohne dabei eine tertiäre Aufgabeerledigen zu müssen. Jede Fahrt mit dem LCT dauerte dabei 3 Minuten.

4.2.2 Experiment

Nun folgte das eigentliche Experiment, wobei die Nutzer die Fahrszenarien möglichst sicher zufahren hatten bei gleichzeitiger Bedienung der Anwendung, zweimal mit HUD und zweimal ohne.Um bei der Auswertung Lerneffekte auszuschließen, fing abwechselnd immer ein Teilnehmer denersten Versuchslauf ohne HUD und den anderen mit HUD an. Damit bei der Bedienung derApplikation außerdem vergleichbare Ergebnisse erreicht werden konnten, wurden jedes Mal fürbeide Varianten dieselben 4 Aufgaben gestellt.

Um zu verhindern dass der Nutzer bei den letzten beiden Fahrten die Aufgaben sofort erratenkonnte bevor sie gestellt wurden, was das Ergebnis verfälschen würde, war ebenfalls die Reihen-folge der Aufgaben bei den letzten beiden Fahrten anders als bei den ersten. Außerdem war dieReihenfolge der Aufgaben für alle Teilnehmer ebenfalls anders verteilt. Um die Aufgaben mög-lichst gut während der Simulation zu verteilen, waren während einer Fahrt jeweils zwei Aufgabenvorgesehen. Die Teilnehmer mussten beim LCT die Bahnen 1,3, 8 und 9 jeweils einmal fahren, umzu vermeiden dass Sie sich an eine Bahn gewöhnen konnten. Alle Teilnehmer fuhren die Bahnen ineiner anderen Reihenfolge, einmal abwechselnd beginnend mit einer Links- oder Rechtskurve undeinmal abwechselnd beginnend mit einer langen und einer kurzen Anfahrstrecke. Es gab somitimmer 4 Kombinationen der Bahnen 1,3,8 und 9. In Abb. 4.3 sieht man einen Ausschnitt desgemachten Studienplans bei der die Reihenfolgen der Strecken, Aufgaben und Varianten für biszu 24 Teilnehmer spezifiert wurde.

Kapitel 4 Studie 23

Die erste Aufgabe wurde immer 20 Sekunden nach dem Start angesagt und die zweite nach1 Minute und 40 Sekunden. Für jede Aufgabe war maximal 1 Minute vorgesehen. Vor jederEingabe musste der Nutzer auf dem Touchscreen einen bestimmten Button zum Start drücken.Ab diesem Moment wurde die Dauer der Bedienung gemessen. Der Button wechselte dabei dieFarbe von rot zu grün. Wenn die Aufgabe bewältigt wurde oder wenn nach der Eingabe 1 Minutevergangen war, landete der Nutzer wieder auf dem Hauptbildschirm und der Button wechselte dieFarbe wieder zu rot. Folgende Aufgaben wurden dabei gestellt:

Aufgabe 1 (Listensuche): Hier musste nach Ansage in der Wiedergabeliste ein bestimmter Titelgesucht und ausgewählt werden. Von 46 Titeln werden immer nur 5 angezeigt. Der gesuchte Titelwar in diesem Fall der 39. Titel an der 4. Stelle in einer Listendarstellung, weit genug hinten in derListe um der Testperson die Suche zu erschweren. Als Scroll Methode wurde Swipe verwendet,da diese die wenigste visuelle Belastung verursacht [3].

Aufgabe 2 (Textsuche): Auf dem Touchscreen musste in der Anzeige der Texteingabe einangesagtes Wort eingegeben werden, in diesem Fall „Vampir“. Die Eingabe von Texten während derFahrt wäre nicht unbedingt nur für Musikspieler interessant, sondern auch für Navigationseingabenoder Nachrichten. Jedoch ist es gleichzeitig eines der schwierigsten tertiären Tätigkeiten die manim Auto machen kann [6].

Aufgabe 3 (Klick): Bei der Klick Aufgabe musste jeweils einmal an den 4 Ecken des Tabletsund in der Mitte gedrückt werden. Es wurden in der folgenden Reihenfolge jeweils einmal auf denButton Shuffle, den Button Looping, den Button Stop, der Mitte der Suchleiste und den ButtonPlay gedrückt. Bei der Suchleiste musste der Fortschrittsbalken zwischen 40% und 60% getroffenwerden, es durfte daher nicht hin geglitten werden.

Aufgabe 4 (Swipe): In dieser Aufgabe musste dreimal von rechts nach links gestreift werden,um jeweils den nächsten Titel abzuspielen. Als nächstes wurde zweimal von links nach rechtsgestreift, wobei der vorherigen Titel abgespielt wird. Abschließend wurde mittels der Suchleistezur Hälfte des Titels vorgespult, indem vom Anfang zur Hälfte geglitten wurde. Beim Startenjedes Gleitens lag der Spielraum zwischen 0% und 15% vom Lied und beim Ende zwischen 40%und 60%. Diese Aufgabe sollte Aufschluss darüber geben wie gut ein Nutzer mit den Streif- undGleitbewegungen während der Fahrt zurecht kommt.

Als Letzter Teil mussten die Teilnehmer einen Fragebogen ausfüllen um sowohl qualitative Datenüber ihr Subjektives Empfinden, als auch quantitative Daten über ihre bisherigen Erfahrungen undEigenschaften bezüglich des Themas zu erhalten.

Kapitel 4 Studie 24

4.3 Ergebnisse

Das Durchschnittsalter der Teilnehmer war ca. 47 Jahre mit einer Standardabweichung von ca.18 Jahren. Die jüngste Person war 21 und die älteste 70 Jahre alt. Jede Testperson besaßseit mindestens 7 Jahren einen Führerschein und fuhr im Monat mehrmals mit dem eigenenAuto. Von den 7 Teilnehmern besaßen zwei außerdem keine Touchscreengeräte und keiner einInfotainmentbildschirm mit Toucheingabe in ihrem Fahrzeug. Die Haupttätigkeiten derjenigenmit Touchscreengeräten waren Nachrichten schreiben, gefolgt vom Surfen im Internet. Nur zweibenutzten diese selten um Musik zu hören. Zwei gaben zudem zu während einer Fahrt hin undwieder mit ihrem Smartphone in der Hand Textnachrichten zu lesen und auch zu schreiben. Viervon den Teilnehmern bedienten außerdem nie ihren Musikspieler während einer Fahrt.

Für die Auswertung wurden für jede Aufgabe die Zeiten aus den Logdateien im LCT eingetragenum dann für den jeweiligen Abschnitt, den Durchschnitt und die Standardabweichung der Fahrab-weichung sowie der Reaktionszeit zu messen. In den Logdateien befanden sich außerdem für dieAufgaben die gebrauchte Dauer und die Fehleranzahl. Die Daten wurden dann in den einzelnenAufgaben eingeteilt. Hier zeigt die Tabelle 4.1 als Beispiel den Vergleich der durchschnittlichenFahrabweichung bei der Variante mit HUD und bei der ohne, während den Swipe Aufgaben fürdie einzelnen Teilnehmer. Mit dem Shapiro-Wilk Test[16] wurden die Daten dann auf Normalver-teilung überprüft, welche Voraussetzung für einen t-Test1 ist. Der Shapiro-Wilk ist besonders beisehr kleinen Datensätzen unter 50 Teilnehmern empfehlenswert um die Normalverteilung zu prü-fen. Der t-Test ist ein Hypothesentest mit dem überprüft werden kann, ob sich zwei Stichprobensignifikant unterscheiden, vorausgesetzt sie sind normal verteilt. In diesem Fall ist es ein gepaartert-Test da immer dieselben Teilnehmer einmal mit und einmal ohne HUD getestet wurden. Wennbei dem Shapiro-Wilk Test einer Stichprobe ein Wert größer als 0.05 entsteht so ist diese normalverteilt. Beim t-Test muss hingegen ein Wert kleiner als 0.05 rauskommen um eine signifikanteAussage über den Unterschied der beiden Stichproben zu erhalten.

Aufgrund der geringen Teilnehmerzahl konnten leider keine signifikanten Aussagen erzeugt werdenum die These, dass ein HUD die Bedienung von Touchscreens während einer Fahrt unterstützenwürde zu beantworten. Außerdem mussten die Werte vom Teilnehmer 4 für die Studie außeracht gelassen werden, da dieser nicht mit der Applikation zurecht kam. Dies lag aber vermutlichweniger an der Applikation, da dieser sich bereits in einem Alter von 70 Jahren befand, keineComputerkenntnisse besaß und auch angab während einer Fahrt nie einer tertiären Tätigkeit, wieder Bedienung eines Musikspieler zu bedienen, nachzugehen.

1t-Test, http://matheguru.com/stochastik/267-t-test.html, letzter Aufruf 17. März 2015

http://matheguru.com/stochastik/267-t-test.html

Kapitel 4 Studie 25

Tabelle 4.1: Swipe: Fahrabweichung DurchschnittID Swipe

Fahrabweichung (Durchschnitt in Meter)Touch HUD

1 1.3045 2.72352 3.659 2.78473 4.2864 3.15435 1.3929 2.126 2.1576 2.87657 1.5002 2.5375

Summe 14.3006 16.1965Durchschnitt 2.3834333333 2.6994166667SD 1.282552743 0.3487323582Shapiro-Wilk 0.1109741684 0.8144313441t-Test 0.496721695Signifikant Nein

Durch den Ausfall von Teilnehmer 4 bei der Auswertung, kam es auch dazu dass vier der ausgewer-teten Teilnehmer zuerst die Aufgaben ohne HUD und dann die Aufgaben mit HUD durchführten,bei den anderen beiden war es anders herum. Daher sollten die Aufgaben mit HUD einen leichtenVorteil haben, aufgrund des Eingewöhnungseffekts.

Jedoch waren bei den Aufgaben meistens die Ergebnisse ohne HUD etwas besser als die mitHUD, insbesondere jedoch haben grundsätzlich alle Aufgaben durchschnittlich länger mit derHUD Variante gebraucht. Vor allem bei der Aufgabe mit Texteingabe waren die Zeiten in derVariante wesentlich schlechter und es haben 5 von 6 Teilnehmern einen Timeout gehabt wie manin Tabelle 4.2 sehen kann. Dass heißt unter normalen Bedingungen hätten sie vermutlich nochlänger gebraucht. Durch die hohe Zahl an Timeouts, ist diese Stichprobe nicht normalverteilt undes konnte kein t-Test zur Signifikanzprüfung dazu gemacht werden. Außerdem war die Texteingabedie Variante , welche mit Abstand die meisten Fehleingaben hatte, ganz besonders die mit HUDwie man in der Tabelle 4.2 sehen kann. Die Daten für Fehleingaben eignen sich jedoch allgemeinnicht für eine Signifikanzprüfung und wurden deshalb von den Tests ausgelassen.

Trotz dieser schlechteren Ergebnisse in Aufgabendauer und Anzahl der Fehleingaben empfandendie meisten abgesehen von Teilnehmer 4 die Variante als hilfreicher wie man an den Umfrageergeb-nissen von Abb. 4.4 sehen kann. Sie konnten sich außerdem deutlich eher vorstellen diese Varianteprivat zu nutzen. Dies könnte eventuell auch durch die etwas besseren Werte für Fahrabweichungund Reaktionszeiten erklärt werden.

Kapitel 4 Studie 26

Allgemein fiel auf dass laut Fragebogen die Teilnehmer in der Regel die HUD Varianten jeder Auf-gabe zu bevorzugen schienen, abgesehen von der Swipe Aufgabe, ohne Suchleistenbedienung. Ausden Ergebnis Daten lässt sich auch ermitteln, dass die Swipe Aufgaben mit HUD neben Texteinga-be ohne HUD die größten Fahrabweichungen und Reaktionszeiten aufzeigen. Swipe enthielt auchnach der Texteingabe die meisten Fehleingaben. Gleichzeitig war diese Aufgabe jedoch diejenige,welche am schnellsten von den anderen bearbeitet wurde. Die Teilnehmer empfanden außerdemdass, trotz der schlechteren Ergebnisse in Fahrabweichung und Reaktionszeit, beide Swipe Varian-ten ihnen während der Fahrt, im Vergleich zu den anderen Aufgaben, am wenigsten Konzentrationabverlangte. Texteingabe ohne HUD viel ihnen am schwersten und am ehesten würden sie privatTastenbedienung mit HUD nutzen.

Die anderen Aufgaben zeigten keine sonderlich großen Unterschiede zwischen den beiden Variantenan, abgesehen davon dass durchschnittlich grundsätzlich die Aufgaben mit HUD länger brauchtenum bearbeitet zu werden. Die geringsten Fahrabweichungen und Reaktionszeiten gab es bei denListen- Suchaufgaben und die geringsten Fehleingaben bei den Klick Aufgaben. Weiter Daten derStudie sind im Anhang zu finden.

Aufgefallen ist, dass Teilnehmer ohne oder mit nur sehr wenig Erfahrung mit Touchscreengerätenteilweise große Schwierigkeiten hatten die Buttons so zu berühren, um zu einer Klickaktion zugelangen. Unter anderem brauchte Teilnehmer 6 bei der Klick Aufgabe mit HUD alleine 29.356Sekunden um nach dem Shuffle Button den Looping Button zu betätigen. Bei Teilnehmer 4war dies sehr extrem, da dieser bereits nachdem die gegebene Eingabezeit vergangen war denStartbutton nicht betätigen konnte, was auch ein Grund für die Verwerfung seiner Daten in derAuswertung war.

Tabelle 4.2: Texteingabe: Aufgabendauer und FehleingabenID Texteingabe

Aufgabendauer (in Millisekunden) Fehleingaben AnzahlTouch HUD Touch HUD

1 13083 60002 0 102 50257 60001 6 73 38872 60001 7 75 33203 60001 0 26 39674 60004 1 47 9360 33923 0 2

Summe 184449 213930 14 32Durchschnitt 30741.5 53482.5 2.3333333333 4.5

SD 16135.6714982674 13039.6667263137 3.2659863237 3.7859388972Shapiro-Wilk 0.398641653 0.0069620402 / /

t-Test nicht anwendbar /Signifikant Nein /

Kapitel 4 Studie 27

Abbildung 4.4: Statistik zum Fragebogen

Kapitel 5

Zusammenfassung und Ausblick

5.1 Zusammenfassung

Im Rahmen dieser Arbeit sollte untersucht werden, ob ein HUD im Fahrersichtfeld die Bedienungvon tertiären Aktivitäten mittels eines Touchscreens, während einer Fahrt unterstützt. Dabeiwurden zuerst andere verwandte Arbeiten recherchiert um basierend auf ihren Erkenntnissen dieRahmenbindungen für eine Studie zu erstellen mit der diese Untersuchung durchgeführt wer-den kann. Insbesondere wurden die Ergebnisse von Designuntersuchungen von Touchscreen undHUD Geräten in der Implementierung der Applikation für diese Studie berücksichtigt, wie dieListennavigation[3, 4] und Slide and Lift[10]. Als Anwendung bot es sich an einen Musikspieler zuentwickeln, da mit dieser eine Vielzahl von Funktionen erstellt wurden, die in einer Studie unter-sucht werden konnten. Dabei handelt es sich um eine Kombination aus dem Drücken von Buttons,Texteingaben mittels Slide and Lift, Swipe Aktionen in vier Richtungen, sowie dem Klicken oderZiehen des Fortschrittsbalkens. Diese Eingabemethoden wurden dann in einem Experiment von7 Teilnehmern in einer Fahrsimulation bei bestimmten Aufgaben ausgeführt um die grundlegendeThese dieser Arbeit beantworten zu können. Dabei erledigten die Nutzer alle Aufgaben zweimalauf dem Touchscreen, einmal mit HUD und einmal ohne. Für jeden Teilnehmer wurde dann dieFahrabweichung, Reaktionszeiten, Aufgabendauer und Fehleingaben ermittelt, jedoch konnte zukeinem dieser Daten ein signifikantes Ergebnis mittels einem t-Test erzielt werden, da die Teil-nehmeranzahl zu gering war und ein Teilnehmer ausfiel. Jedoch ließ sich insbesondere bei derAufgabendauer beobachten, dass die Werte für die HUD Varianten in der Regel etwas schlechterabschnitten als für die ohne.

28

Kapitel 5 Zusammenfassung und Ausblick 29

5.2 Fazit & Ausblick

Die Auswertung ist zwar noch nicht aussagekräftig genug und es müsste eine größere Studie mitmehr Teilnehmern gemacht werden. Jedoch legen die bisher gesammelten Ergebnisse nahe, dassein zusätzliches Display im Fahrersichtfeld, zumindest in dieser Anwendung die Bedienung einesTouchscreens nicht unterstützt. Im Gegenteil insbesondere bei der Dauer der Bearbeitung einerAufgabe schnitten die Aufgaben mit HUD oftmals schlechter ab als ohne, trotz des Vorteils durchden Ausfall von Teilnehmer 4. Die längere Bedienungsdauer ist jedoch nicht so verwunderlich, daes eine hohe Präzision erfordert bestimmte Bereiche des Touchscreens zu berühren, selbst wenndurch das gedrückt Halten der Bereich im Fahrersichtfeld angezeigt wird. Dies trifft besonders aufdas Eingeben auf der Tastatur zu, wobei man stets ein kleines Ziel zu treffen hatte. Überraschendwar jedoch, dass abgesehen von einem Ausreißer-Teilnehmer der mit dem Aufgabenablauf durch-einander kam, die Swipe Aufgabe in der HUD Variante grundsätzlich schlechtere Werte hatte. Inder Aufgabe sollte eigentlich, abgesehen von der Bedienung der Suchleiste, wenig Präzision undBlickkontakt notwendig sein.

In der Studie wurden allerdings weder die Dauer noch die Anzahl der Blickabweichungen gemessen,bei einem Ausbau dieser Studie wären dies noch interessante Daten die man berücksichtigen sollteum eventuell ein anderes Licht auf die bisher gesammelten Erkenntnisse werfen zu können. Denntrotz der eher schlechteren gemessenen Daten für HUD empfanden die Teilnehmer größtenteilsdie Varianten mit HUD als die Sicherere. Im Nachhinein sollte auch für Aufgabe der Texteingabeentweder die Wortlänge auf vier bis fünf Buchstaben verkürzt werden, oder die Eingabezeit ver-längert werden, da für die Variante mit HUD einer Minute in der Regel zu knapp scheint um siezu bearbeiten. Außerdem muss man mit weiteren Teilnehmern bei dem Studienplan den Ausfallvom Teilnehmer 4 mitberechnen. Um weitere solche Ausfälle zu vermeiden, kann man als Vor-aussetzung für die Studie Kenntnisse mit Touchscreen Geräten fordern oder untersuchen, ob dieSensitivität an der Applikation verbessern werden kann.

Eine persönliche Vermutung ist, dass selbst bei Verwendung von HUDs als Hilfe dies eventu-ell nicht ausreicht, um die Gefahr die bei der Bedienung von Touchscreens während der Fahrtentsteht angemessen zu verringern. Denn durch die glatte Oberfläche des Touchscreens ist diehaptische Wahrnehmung sehr stark eingeschränkt [7] und man muss sich hauptsächlich auf seinevisuellen Reize verlassen. Insbesondere ist es bei kleinen Zielen schwieriger und aufwendiger, beiBerührung eines Ziels die Position und Distanz eines anderen zu ermitteln, wenn man keine ertas-tete Wahrnehmung bei der Berührung hat und sich auf die visuellen Reize einer anderen Anzeigemit eventuell anderen Maßstäben verlassen muss. Außerdem kann jede Eingabe mit dem Fingererst mit dem Auge verifiziert werden, nachdem der Finger den Touchscreen berührt hat . Danachmuss die Position eventuell wieder angepasst werden, was Zeit in Anspruch nimmt. Daher würdeneventuell einige ihren Blick zum Touchscreen abwenden um sich die Zeit zu sparen. Das HUD

Kapitel 5 Zusammenfassung und Ausblick 30

an sich hat vermutlich sehr viel Potenzial um Informationen bequem und sicher für einen Fahreranzuzeigen, jedoch wäre eine Form der haptischen Eingabe während einer Fahrt vermutlich bessergeeignet, damit sich Seh- und Tastsinn die Belastung bei der Verwaltung von Informationen teilenkönnen.

Eine theoretische Möglichkeit eine Verbesserung in der Zukunft wäre es die HUD Anzeigen dieserApplikation mit dem Finger Erkennungssystem von Fujimura et. al.[17], sowie mit Tasten amLenkrad zu erweitern. Zum Beispiel könnte man anstatt des Touchscreen mit dem Finger auf dieButtons am HUD zeigen um diese zu markieren, diese werden mit einer Taste am Lenkrad dannmit der anderen Hand ausgewählt. Um die Sicht nicht dauerhaft zu stören, könnte man eine zweiteTaste am Lenkrad anbringen um die Ansicht zu minimieren/maximieren. Gleiten auf der Suchleistekönnte auch durch markieren und gedrückt halten der Taste bewerkstelligt werden und die SwipeAktionen wären durch schnelle Fingerbewegungen nach rechts, links, etc. ausgelöst. LängereTexteingaben sind als Eingabemethode vermutlich immer noch bedenklich, eventuell würde sichhier die Verwendung eines Spracherkennungssystems als sinnvoll erweisen. Falls es mehrere Treffergibt, könnten diese in einer Liste angezeigt werden, um so wieder mit Fingergesten in der Liste zunavigieren. Theoretisch hätte dieses System die Vorteile, dass die Hand stets am Lenkrad bleibt,dass man bei der Auswahl ein haptisches Feedback hat und es keinen Grund gibt um seinen Blicksenken zu müssen.

Die Kombination aus Infotainment, Nutzerkomfort und Fahrsicherheit wird vermutlich auch nochin der Zukunft ein populäres Thema für wissenschaftliche Forschungen sein und mit der Wei-terentwickelung von neuen Technologien wird es vermutlich keinen Mangel an neuen Ideen undKonzepten geben.

Anhang A

Daten

A.1 Aufgaben Datentabellen

Tabelle A.1: Liste: Durchschnitt FahrabweichungID Liste


1 1.2229 1.32122 2.1294 1.82263 2.7571 2.39075 2.7982 2.12586 3.0285 3.34977 1.4394 2.3566

Summe 13.3755 13.3666Durchschnitt 2.22925 2.2277666667

SD 0.7599610062 0.6779823085Shapiro-Wilk 0.327608424 0.7664527871

t-Test 0.99517544Signifikant Nein

31

Anhang A Daten 32

Tabelle A.2: Liste: SD FahrabweichungID Liste

Fahrabweichung (Standardabweichung in Meter)Touch HUD

1 1.0651 1.31052 2.1943 1.49553 2.0426 1.83445 2.2503 1.72976 2.2159 2.58477 1.3437 2.7546


SD 0.5142264576 0.5878156979Shapiro-Wilk 0.0494006743 0.2690501027

t-Test nicht anwendbarSignifikant Nein

Tabelle A.3: Liste: Durchschnitt ReaktionszeitID Liste

Reaktionszeit (Durchschnitt in Sekunden)Touch HUD

1 1.2232 1.32142 2.1314 1.82843 2.7582 2.39315 2.8002 2.12726 3.0394 3.34797 1.4396 2.3626


SD 0.762538917 0.6769474248Shapiro-Wilk 0.3355810303 0.7711639473


Anhang A Daten 33

Tabelle A.4: Liste: SD ReaktionszeitID Liste

Reaktionszeit (Standardabweichung in Sekunden)Touch HUD

1 1.0651 1.31022 2.195 1.49923 2.0424 1.83595 2.2501 1.73046 2.2278 2.58517 1.3429 2.7536


SD 0.5161363286 0.5870090391Shapiro-Wilk 0.049117474 0.3750163125


Tabelle A.5: Liste: AufgabendauerID Liste

Aufgabendauer (in Millisekunden)Touch HUD

1 20185 192172 28053 600013 18212 511855 33984 268576 26068 302997 20576 10093

Summe 147078 197652Durchschnitt 24513 32942

SD 5976.3470448092 19075.9619940909Shapiro-Wilk 0.4794786244 0.6138628197


Anhang A Daten 34

Tabelle A.6: Liste: FehleingabenID Liste

Fehleingaben AnzahlTouch HUD

1 2 22 0 63 0 35 0 06 1 07 8 0

Summe 11 11Durchschnitt 1.8333333333 1.8333333333

SD 3.1251666622 2.4013884872

Tabelle A.7: Texteingabe: Durchschnitt FahrabweichungID Texteingabe


1 2.7932 2.3432 2.2662 2.85573 2.9633 2.93455 2.8015 2.04896 2.6764 2.51787 2.5621 2.2988


SD 0.2420451645 0.3418335701Shapiro-Wilk 0.6391820694 0.6097161963


Anhang A Daten 35

Tabelle A.8: Texteingabe: Standardabweichung FahrabweichungID Texteingabe


1 2.9738 2.33632 2.1121 2.44763 2.602 2.01695 2.4443 1.9246 2.1701 1.96057 2.5581 1.9958


SD 0.3154111391 0.220801607Shapiro-Wilk 0.6450636838 0.0771763125


Tabelle A.9: Texteingabe: Durchschnitt ReaktionszeitID Texteingabe


1 2.7964 2.34452 2.2674 2.86563 2.9657 2.93475 2.8031 2.04956 2.6855 2.51947 2.5648 2.3002


SD 0.2424317258 0.3435177283Shapiro-Wilk 0.6119830887 0.5771981782


Anhang A Daten 36

Tabelle A.10: Texteingabe: Standardabweichung ReaktionszeitID Texteingabe


1 2.9727 2.33582 2.1117 2.4533 2.5999 2.01685 2.443 1.92376 2.1782 1.96127 2.5561 1.9953


SD 0.3133564148 0.2223578917Shapiro-Wilk 0.6708490063 0.0782937091


Tabelle A.11: Klick: Durchschnitt FahrabweichungID Klick


1 2.8587 4.1892 1.5908 2.78833 3.0418 2.38875 2.9079 2.52966 3.5085 1.71217 1.919 1.8313


SD 0.7288302612 0.8927404632Shapiro-Wilk 0.4228286006 0.3177091409


Anhang A Daten 37

Tabelle A.12: Klick: Standardabweichung FahrabweichungID Klick


1 2.8554 2.9042 1.2863 2.15273 1.5563 2.26145 2.0086 2.24816 2.9774 1.1897 1.4096 1.3359


SD 0.7403300966 0.6430837377Shapiro-Wilk 0.2235181367 0.4280625811


Tabelle A.13: Klick: Durchschnitt ReaktionszeitID Klick


1 2.8574 4.18952 1.5915 2.79023 2.3885 3.04185 2.9071 2.53076 3.5204 1.71317 1.9188 1.831


SD 0.7077647898 0.9054917281Shapiro-Wilk 0.86629881 0.86629881


Anhang A Daten 38

Tabelle A.14: Klick: Standardabweichung ReaktionszeitID Klick


1 2.8545 2.90292 1.2863 2.15363 1.5563 2.26135 2.0081 2.24766 2.9869 1.18997 1.4088 1.3356


SD 0.7427335307 0.6426067312Shapiro-Wilk 0.2282088329 0.4262983368


Tabelle A.15: Klick: AufgabendauerID Klick


1 5697 122102 18505 542093 47432 392685 24869 397466 44318 486407 5517 8233


SD 18267.676323678 19088.0367630269Shapiro-Wilk 0.3187701256 0.2770878347


Anhang A Daten 39

Tabelle A.16: Klick: FehleingabenID Klick


1 0 02 1 13 3 45 1 26 4 07 0 0


SD 1.6431676725 1.6020819788

Tabelle A.17: Swipe: Standardabweichung SwipeID Swipe


1 1.3691 2.84782 2.567 2.01613 3.1775 2.22015 1.4143 1.9066 1.2917 2.07017 1.3355 2.4378


SD 0.8091165167 0.3461029254Shapiro-Wilk 0.0216723597 0.4211681391


Anhang A Daten 40

Tabelle A.18: Swipe: DurchschnittReaktionszeitID Swipe


1 1.3048 2.72542 3.6594 2.7843 4.2848 3.15435 1.3934 2.12136 2.1583 2.87917 1.4995 2.5404


SD 1.2821018004 0.3482898032Shapiro-Wilk 0.1104472972 0.8106529959


Anhang A Daten 41

Tabelle A.19: Swipe: Standardabweichung ReaktionszeitID Swipe


1 1.3688 2.84622 2.5669 2.01643 3.179 2.22015 1.4142 1.90616 1.2914 2.07087 1.3346 2.4367


SD 0.8097938596 0.3452975147Shapiro-Wilk 0.0217306907 0.4228101153


Tabelle A.20: Swipe: AufgabendauerID Swipe


1 10700 124132 14428 249703 60002 259105 14489 435606 14454 350377 8515 11590

Summe 122588 153480Durchschnitt 20431.3333333333 25580

SD 19542.8521937476 12508.2871569212Shapiro-Wilk 0.008578605 0.5346284836

t-TestSignifikant Nein

Anhang A Daten 42

Tabelle A.21: Swipe: FehleingabenID Swipe


1 2 12 0 73 13 35 0 76 0 07 0 1


SD 5.2057660339 3.1251666622

Anhang B

Fragebogen

43

Anhang B Fragebogen 44







Abbildungsverzeichnis

2.1 BMW-iDrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Garmin HUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Android-Activity-Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Back-Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 HUD Hauptbildschirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Touchscreen Hauptbildschirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Listen Anzeige für HUD und Touchscreen . . . . . . . . . . . . . . . . . . . . . 143.6 Texteingaben Anzeige für HUD und Touchscreen . . . . . . . . . . . . . . . . . 143.7 Launcher Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.8 Kommunikations Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Simulationsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 LCT Analyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Ausschnitt vom Studienplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4 Statistik zum Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

51

Tabellenverzeichnis

3.1 Eine Zeile einer beispielhaften csv-Logdatei der Touchscreen-Anwendung . . . . . 16

4.1 Swipe: Fahrabweichung Durchschnitt . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Texteingabe: Aufgabendauer und Fehleingaben . . . . . . . . . . . . . . . . . . 26

A.1 Liste: Durchschnitt Fahrabweichung . . . . . . . . . . . . . . . . . . . . . . . . 31A.2 Liste: SD Fahrabweichung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.3 Liste: Durchschnitt Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.4 Liste: SD Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.5 Liste: Aufgabendauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.6 Liste: Fehleingaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.7 Texteingabe: Durchschnitt Fahrabweichung . . . . . . . . . . . . . . . . . . . . 34A.8 Texteingabe: Standardabweichung Fahrabweichung . . . . . . . . . . . . . . . . 35A.9 Texteingabe: Durchschnitt Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . 35A.10 Texteingabe: Standardabweichung Reaktionszeit . . . . . . . . . . . . . . . . . . 36A.11 Klick: Durchschnitt Fahrabweichung . . . . . . . . . . . . . . . . . . . . . . . . 36A.12 Klick: Standardabweichung Fahrabweichung . . . . . . . . . . . . . . . . . . . . 37A.13 Klick: Durchschnitt Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . 37A.14 Klick: Standardabweichung Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . 38A.15 Klick: Aufgabendauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.16 Klick: Fehleingaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.17 Swipe: Standardabweichung Swipe . . . . . . . . . . . . . . . . . . . . . . . . . 39A.18 Swipe: DurchschnittReaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . 40A.19 Swipe: Standardabweichung Reaktionszeit . . . . . . . . . . . . . . . . . . . . . 41A.20 Swipe: Aufgabendauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.21 Swipe: Fehleingaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

52

Abkürzungsverzeichnis

HUD Headup Display

LCT Lane Change Test

TCP Transmission Control Protocoll

GUI Graphic User Interface

HDD Headdown Display

53

Literaturverzeichnis

[1] L. Prinzel und M. Risser, “Head-up displays and attention capture,” NASA/TM-2004-213000,2004.

[2] C. Harvey, N. A. Stanton, C. A. Pickering, M. McDonald, und P. Zheng, “To twist orpoke? a method for identifying usability issues with the rotary controller and touch screenfor control of in-vehicle information systems,” Ergonomics, Band 54, Nr. 7, Seiten 609–625,2011. PMID: 21770749.

[3] A. Lasch und T. Kujala, “Designing browsing for in-car music player: Effects of touch screenscrolling techniques, items per page and screen orientation on driver distraction,” in Pro-ceedings of the 4th International Conference on Automotive User Interfaces and InteractiveVehicular Applications, AutomotiveUI ’12, (New York, NY, USA), Seiten 41–48, ACM, 2012.

[4] T. Kujala, “Browsing the information highway while driving: Three in-vehicle touch screenscrolling methods and driver distraction,” Personal Ubiquitous Comput., Band 17, Seiten 815–823, Juni 2013.

[5] K. Bachfischer, C. Waeller, S. Troesterer, A. Tatzel, und F. Leon, “Eye gaze and movementbehaviour in the operation of adaptive in-car touchscreens,” in Intelligent Vehicles Symposi-um, 2008 IEEE, Seiten 1027–1032, June 2008.

[6] W. A. Rogers, A. D. Fisk, A. C. McLaughlin, und R. Pak, “Touch a screen or turn a knob:Choosing the best device for the job,” Human Factors: The Journal of the Human Factorsand Ergonomics Society, Band 47, Nr. 2, Seiten 271–288, 2005.

[7] M. J. Pitts, M. A. Williams, T. Wellings, und A. Attridge, “Assessing subjective response tohaptic feedback in automotive touchscreens,” in Proceedings of the 1st International Con-ference on Automotive User Interfaces and Interactive Vehicular Applications, AutomotiveUI’09, (New York, NY, USA), Seiten 11–18, ACM, 2009.

[8] M. Ablassmeier, T. Poitschke, F. Wallhoff, K. Bengler, und G. Rigoll, “Eye gaze studiescomparing head-up and head-down displays in vehicles,” in Multimedia and Expo, 2007 IEEEInternational Conference on, Seiten 2250–2252, July 2007.

[9] G. Weinberg, B. Harsham, und Z. Medenica, “Evaluating the usability of a head-up displayfor selection from choice lists in cars,” in Proceedings of the 3rd International Conference

54

LITERATURVERZEICHNIS 55

on Automotive User Interfaces and Interactive Vehicular Applications, Seiten 39–46, ACM,2011.

[10] F. Lauber, A. Follmann, und A. Butz, “What you see is what you touch: Visualizing touchscreen interaction in the head-up display,” in Proceedings of the 2014 Conference on Desi-gning Interactive Systems, DIS ’14, (New York, NY, USA), Seiten 171–180, ACM, 2014.

[11] T. Poitschke, F. Laquai, S. Stamboliev, und G. Rigoll, “Gaze-based interaction on multipledisplays in an automotive environment,” in Systems, Man, and Cybernetics (SMC), 2011IEEE International Conference on, Seiten 543–548, IEEE, 2011.

[12] A. K. Saha, “What is android,” 2011.

[13] L. Vogel, “Android tutorials.” http://www.vogella.com/tutorials/android.html. Ac-cessed: 2015-03-16.

[14] S. Mattes, “The lane-change-task as a tool for driver distraction evaluation,” Quality of Workand Products in Enterprises of the Future, Seiten 57–60, 2003.

[15] T. Petzoldt, N. Bär, C. Ihle, und J. F. Krems, “Learning effects in the lane change task(lct)—evidence from two experimental studies,” Transportation research part F: traffic psy-chology and behaviour, Band 14, Nr. 1, Seiten 1–12, 2011.

[16] C. Zaiontz, “Shapiro-wilk original test.” http://www.real-statistics.com/tests-

normality-and-symmetry/statistical-tests-normality-symmetry/shapiro-

wilk-test/. Accessed: 2015-03-17.

[17] K. Fujimura, L. Xu, C. Tran, R. Bhandari, und V. Ng-Thow-Hing, “Driver queries usingwheel-constrained finger pointing and 3-d head-up display visual feedback,” in Proceedingsof the 5th International Conference on Automotive User Interfaces and Interactive VehicularApplications, AutomotiveUI ’13, (New York, NY, USA), Seiten 56–62, ACM, 2013.

http://www.vogella.com/tutorials/android.html

http://www.real-statistics.com/tests-normality-and-symmetry/statistical-tests-normality-symmetry/shapiro-wilk-test/



Documents

Unterstützung der Bedienung von Touch