Implementierung Und Evaluation Einer Hand-Exoskelett-Steuerung Für Mobile Geräte

Masterarbeit

im Studiengang Computer Science and Media Implementierung und Evaluation einer Hand-Exoskelett-Steuerung für mobile Geräte

vorgelegt von Sebastian Koch

an der Hochschule der Medien Stuttgart

am 14.08.2020

zur Erlangung des akademischen Grades eines

Master of Science

Erst-Prüfer: Prof. Dr. Gottfried Zimmermann

Zweit-Prüfer: Tobias Ableitner, M. Sc. Das verwendete LATEX Template basiert auf der Arbeit von Karl Voit, die unter der CC BY-SA 3.0 Lizenz verwendet wurde.

Der Text dieser Masterarbeit ist unter CC BY-SA 4.0 lizenziert. Ehrenwörtliche Erklärung

Hiermit versichere ich, Sebastian Koch, ehrenwörtlich, dass ich die vorliegende Bache- lorarbeit (bzw. Masterarbeit) mit dem Titel: „Implementierung und Evaluation einer Hand-Exoskelett-Steuerung für mobile Geräte“ selbstständig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen der Arbeit, die dem Wortlaut oder dem Sinn nach anderen Werken entnommen wurden, sind in jedem Fall unter Angabe der Quelle kenntlich gemacht. Die Arbeit ist noch nicht veröffentlicht oder in anderer Form als Prüfungsleistung vorgelegt worden.

Ich habe die Bedeutung der ehrenwörtlichen Versicherung und die prüfungsrecht- lichen Folgen (§ 26 Abs. 2 Bachelor-SPO (6 Semester), § 24 Abs. 2 Bachelor-SPO (7 Semester), § 23 Abs. 2 Master-SPO (3 Semester) bzw. § 19 Abs. 2 Master-SPO (4 Semester und berufsbegleitend) der HdM) einer unrichtigen oder unvollständigen ehrenwörtlichen Versicherung zur Kenntnis genommen.

Unterschrift

iii Kurzfassung

Jeder Mensch könnte einen Schlaganfall erleiden, der eine der Hauptursachen für Be- hinderungen im erwachsenen Alter ist. Die Überlebenden haben oft Lähmungen und Spastiken und benötigen daher ständige Hilfe, da selbst die Ausführung der einfachs- ten alltäglichen Aufgaben eine unüberwindbare Herausforderung darstellen kann. Um den Betroffenen zu helfen, wurde im Rahmen des Forschungsprojekts KONSENS unter der Leitung des Universitätsklinikums Tübingen ein Hand-Exoskelett entwickelt, das auch Schlaganfallpatienten nutzen können.

Ziel dieser Arbeit ist die Implementierung einer Steuerung für dieses Hand-Exoskelett auf der Google Glass, sowie Android Smartphones und Smartwatches. Der entstandene Prototyp wurde mit Studenten der Hochschule der Medien Stuttgart und Bekann- ten des Autors evaluiert. Diese Arbeit bildet den Zwischenstand der Evaluation nach zwanzig Probanden ab. Der Schwerpunkt liegt dabei auf dem Vergleich der Nutzer- akzeptanz und Eignung verschiedener Ein- und Ausgabemethoden wie Touch-Input, Sprachsteuerung oder Eyetracking.

Darüber hinaus fasst diese Arbeit auch aktuelle Richtlinien zur barrierefreien Imple- mentierung von Augmented-Reality-Anwendungen zusammen und vergleicht jene mit einem daraus abgeleiteten gemeinsamen Kriterienkatalog.

iv Abstract

Anyone could suffer a stroke, which is one of the major causes of disability inthe adult population. Survivors often experience problems due to paralysis and spastic- ity and thus require constant help, as even the simplest everyday tasks can pose an insurmountable challenge. To help those affected, the KONSENS research project led by the University Hospital in Tübingen developed a hand exoskeleton that can also be used by stroke patients.

The goal of this work is to implement a control for this exoskeleton on Google Glass, as well as Android smartphones and smartwatches. The resulting prototype was evalu- ated with students of Stuttgart Media University and acquaintance of the author. This work presents the interim status of the evaluation after twenty test persons. The fo- cus is on comparing the user acceptance and suitability of different input and output methods such as voice control, eye tracking or touch input.

Furthermore, this work also summarizes current guidelines for the accessible imple- mentation of augmented reality applications and compares them to a common catalog of criteria derived from them.

v Inhaltsverzeichnis

1 Einleitung ...... 1 1.1 Aufbau der Masterarbeit ...... 2

2 Grundlagen ...... 4 2.1 Exoskelett-Systeme ...... 4 2.1.1 Kategorisierung...... 5 2.1.2 Anwendungen ...... 6 2.1.3 Steuerung von Exoskelett-Systemen ...... 9 2.1.4 Verwendetes Hand-Exoskelett ...... 10 2.2 Augmented Reality ...... 12 2.2.1 Reality-Virtuality Continuum ...... 12 2.2.2 Gestaltung von Anwendungen auf Google Glass...... 14 2.3 Technische Grundlagen ...... 15 2.3.1 In-Memory Data Grids (IMDG) ...... 16 2.3.2 Hybride Apps ...... 17

3 Methodik ...... 19 3.1 Technische Methodik...... 20 3.2 Theoretische Methodik ...... 21

4 AR- und VR-Richtlinien ...... 22 4.1 XR Accessibility User Requirements (W3C) ...... 23

vi Inhaltsverzeichnis

4.2 ETSI EN 301 549 ...... 27 4.3 Apple Human Interface Guidelines ...... 31 4.4 Google Augmented Reality Design Guidelines ...... 37 4.5 Abgeleiteter Kriterienkatalog ...... 42 4.6 Vergleich der Richtlinien ...... 50

5 Implementierung ...... 55 5.1 Verwendete Hardware ...... 55 5.2 Ein- und Ausgabe ...... 58 5.2.1 Eingabeverfahren ...... 58 5.3 Benutzeroberfläche ...... 66 5.3.1 Konfiguration der Anwendung ...... 68

6 Evaluation ...... 69 6.1 Studiendesign ...... 69 6.1.1 Input-Output-Combinations (IOCs) ...... 70 6.1.2 Icon-Position-Combinations (IPCs) ...... 72 6.1.3 Experimenteller Aufbau ...... 74 6.1.4 Fragebogen ...... 76 6.1.5 Schutzmaßnahmen und Sicherheit der Teilnehmer ...... 76 6.2 Teilnehmer ...... 78 6.3 Datenverarbeitung ...... 78 6.4 Ergebnisse ...... 80 6.4.1 Vergleich der IPCs ...... 81 6.4.2 Vergleich der IOCs ...... 82 6.4.3 Subjektive Bewertung durch die Probanden ...... 84

7 Zusammenfassung und Ausblick ...... 87

Anhang ...... I

vii Inhaltsverzeichnis

Dateiverzeichnis ...... II Abbildungsverzeichnis ...... III Tabellenverzeichnis ...... VI Listingverzeichnis ...... VIII Abkürzungsverzeichnis ...... IX Literaturverzeichnis ...... XI

viii 1 Einleitung

Nach Hirn- oder Rückenmarksverletzungen können Beeinträchtigungen der Hand, wie ein Verlust der Muskelkraft, Apraxien oder Ataxien, Spastik oder Lähmungen auf- treten (Sanborn et al., 2013). Die hierdurch erlebten Einschränkungen im beruflichen und privaten Leben bedeuten eine große Einbuße an Autonomie und Lebensquali- tät für die betroffenen Menschen (Bakula et al., 2011). Durch die Anwendung eines Hand-Exoskeletts können Mediziner zumindest einen Teil der Handfunktion wiederherstellen (Schabowsky et al., 2010).

Die Steuerung eines Hand-Exoskeletts kommt jedoch mit neuen Herausforderungen für die betroffenen Menschen einher: So kann beispielsweise ein – aufgrund seines1 Alters seheingeschränkter – Nutzer nicht von dem Hand-Exoskelett profitieren, wenn er die Steuerungseinheit nicht lesen und daher das System nicht steuern kann.

Im Rahmen dieser Arbeit soll daher die Frage beantwortet werden, welche Ein- und Ausgabeverfahren sich zur Steuerung eines Hand-Exoskeletts eignen. Hierzu wurde die Eingabe via Sprache und Touch, sowie Augen- und Kopfbewegungen, auf drei mobilen Geräten – der Google Glass, sowie einem Android Smartphone und einer

1Im Rahmen dieser Masterarbeit wird durchgängig das generische Maskulinum verwendet – außer an Stellen, an denen eine spezifische Person gemeint ist. Dies dient ausschließlich der Lesbarkeit und schließt neben männlichen ausdrücklich auch weibliche und diverse Personen ein.

1 1 Einleitung

Smartwatch – als native Anwendung unter Verwendung des Android Software Deve- lopment Kits (SDKs) implementiert. Die Nutzerakzeptanz und Eignung der verschiedenen Ein- und Ausgabeverfahren wurde mit Studenten der Hochschule der Medien und Bekannten des Autors in einer Studie evaluiert. Diese Arbeit stellt den Zwischen- stand nach zwanzig Testpersonen dar – da eine weitergehende Evaluation aufgrund der anhaltenden SARS-CoV-2 Pandemie schwer bis unmöglich ist.

Neben einer Einführung wichtiger Konzepte der Augmented Reality und von Exo- skelett-Systemen, fasst diese Arbeit aktuelle Richtlinien zu der barrierefreien Imple- mentierung von AR-Anwendungen zusammen und leitet aus jenen einen gemeinsamen Kriterienkatalog ab. Weiterhin beschreibt diese Masterarbeit auch die technischen Grundlagen der verwendeten Technologien. Danach wird das entstandene Konzept und die resultierende prototypische Implementierung sowie der Aufbau der durchgeführten Studie beschrieben und ausgewertet. Abschließend wird ein kurzer Ausblick auf zukünftige Entwicklungen und notwendige Folgestudien gegeben.

1.1 Aufbau der Masterarbeit

Kapitel 2 (Grundlagen) beschreibt die Grundlagen von Exoskelett-Systemen anschlie- ßend grenzt es verschiedene Formen dieser voneinander ab. Danach wird ihre Anwen- dung im industriellen, medizinischen und militärischen Bereich sowie deren mögli- che Anwendung in der Rehabilitation am Beispiel von Schlaganfallpatienten, durch das im Rahmen des Forschungsprojekts KONSENS2 unter der Leitung des Universi-

2Am KONSENS Projekt Beteiligte sind das Universitätsklinikum Tübingen, die Universitäten Tü- bingen und Stuttgart, die Hochschule Reutlingen sowie das Fraunhofer IPA (Siewe-Reinke & Müller, n. d.).

2 1 Einleitung tätsklinikums Tübingen entwickelte Hand-Exoskelett dargestellt. Des Weiteren werden die Grundlagen der AR beschrieben und dargestellt, wie jene von ähnlichen Kon- zepten wie beispielsweise der Virtual Reality (VR) zu differenzieren ist. Abschließend werden die Grundlagen der Gestaltung von AR-Anwendungen sowie die technischen Grundlagen der verwendeten Technologien eingeführt.

Kapitel 3 (Methodik) beschreibt die Methodik, welche während dieser Arbeit verwendet wurde, um die Forschungsfrage zu beantworten.

Kapitel 4 (AR- und VR-Richtlinien) fasst verschiedene Richtlinien zur barrierefreien Implementierung von AR-Anwendungen zusammen und leitet daraus einen gemeinsamen Kriterienkatalog ab, mit welchem die betrachteteten Richtlinien verglich- ten werden. Die Richtlinien sind: XR Accessibility User Requirements, ETSI EN 301 549, Apple Human Interface Guidelines und Google Augmented Reality Design Gui- delines.

Kapitel 5 (Implementierung) beschreibt das Konzept der entstandenen Anwendung und des experimentellen Prototyps sowie deren Implementierung für die evaluierten Geräte.

Kapitel 6 (Evaluation) beschreibt den Versuchsaufbau, der benutzt wurde, um das entstandene Konzept zu evaluieren. Daneben gibt es einen Überblick über die beteiligten Probanden und wertet anschließend die entstandenen Daten aus.

Kapitel 7 (Zusammenfassung und Ausblick) fasst die Ergebnisse dieser Arbeit zusammen und gibt einen kurzen Ausblick auf die zukünftige Entwicklung des Feldes.

3 2 Grundlagen

Der erste Abschnitt dieses Kapitels führt die theoretischen Grundlagen von Exoske- lett-Systemen ein und beschreibt welche Einsatzzwecke solche Systeme haben. An- schließend wird das in dieser Arbeit verwendete Hand-Exoskelett des KONSENS For- schungsprojekts beschrieben. Der zweite Abschnitt führt die theoretischen Grundla- gen der Augmented Reality ein und grenzt jene von verwandten Konzepten wie Virtu- al Reality ab. Schließlich beschreibt der dritte Abschnitt wichtige technische Konzepte zum Verständnis dieser Arbeit und der erfolgten Implementierung.

2.1 Exoskelett-Systeme

Exoskelett-systeme sind am Körper getragene Systeme, die Körperhaltung und Kör- perkräfte unterstützen (de Looze et al., 2016). Das technische Design und die Funk- tionsweise von Exoskelett-Systemen selbst sind nicht Teil dieser Arbeit und werden entsprechend nur umrissen. Die folgenden Abschnitte führen verschiedene Katego- risierungen von Exoskelett-Systemen ein und beschreiben deren Nutzung in Militär, Medizin und Industrie sowie schließlich das verwendete System des KONSENS For- schungsprojekts.

4 2 Grundlagen

2.1.1 Kategorisierung

Exoskelett-Systeme werden in aktive und passive Systeme aufgeteilt. Aktive Systeme werden beispielsweise von Elektromotoren oder Pneumatik angetrieben und können so zusätzliche Kräfte aufwenden. Passive Systeme können beispielsweise das Gewicht schwerer Werkzeuge über Federn und Seilzugmechanismen im Exoskelett-System in den Boden ableiten und entlasten so den Nutzer. (de Looze et al., 2016)

Entsprechend ihrer Positionierung am Körper können Exoskelett-Systeme auch in die drei folgenden Kategorien aufgeteilt werden (de Looze et al., 2016).

Lower Body Exoskeletons unterstützen an den unteren Extremitäten, beispielsweise einem Bein. Upper Body Exoskeletons unterstützen an den oberen Extremitäten, beispielsweise einem Arm. Full Body Exoskeletons unterstützen sowohl an den oberen als auch an den unteren Extremitäten.

Es kann darüberhinaus auch eine Unterscheidung danach getroffen werden, wie an- thropomorph das System ist – also, in wie weit das Exoskelett-System die biologi- schen Gelenke des menschlichen Körpers abbildet (de Looze et al., 2016). Daneben existieren noch sogenannte Single-Joint Exoskeletons, welche einzelne Gelenke, wie beispielsweise das des Knies, unterstützen (de Looze et al., 2016). Relevant für diese Masterarbeit sind Hand-Exoskelette, die vom Nutzer an der Hand getragen werden.

5 2 Grundlagen

2.1.2 Anwendungen

Exoskelett-Systeme haben eine Vielzahl an Anwendungsmöglichkeiten im militäri- schen, industriellen und medizinischen Bereich, welche im Folgenden beschrieben werden.

Militär

Mindestens seit den 1960er-Jahren (Fick & Makinson, 1971) forscht das US-Militär an Exoskelett-Systeme, um die Kraft und Ausdauer von Soldaten im Einsatz zu erhö- hen. Zum Beispiel sollten jene beim Be- und Entladen von Gütern und deren Trans- port zum Einsatz kommen (Fick & Makinson, 1971). Auch heute wird die Technologie durch das Militär und Industriepartner wie Lockheed Martin oder Sarcos weiterver- folgt, findet jedoch noch keine breite Anwendung (Lockheed Martin, 2017; Sarcos, 2019).

Industrie

Krankheiten des Muskel-Skelett-Systems und des Bindegewebes waren im Jahr 2018 für 21,9 % aller Arbeitsunfähigkeitstage in Deutschland verantwortlich, wodurch ein Produktionsausfall von 18,5 Mrd. € verursacht wurde (BMAS/BAuA, 2020, S. 45). Solche Erkrankungen entstehen insbesondere durch Fehlbelastungen bei der Arbeit (BMAS/BAuA, 2017, S. 116–118). 32 % der Arbeitnehmer in der Europäischen Union (EU) tragen oder bewegen schwere Lasten während mindestens einem Viertel ihrer Arbeitszeit; 61 % führen repetitive Hand- oder Armbewegungen durch (Publications

6 2 Grundlagen

Oﬀice of the European Union, 2017, S. 43).

Exoskelett-Systeme finden in der Praxis bereits erste Anwendung – vor allen inOst- asien, Europa und den USA – um derartige Belastungen zu verringern (Bogue, 2018) – wobei hier jedoch zumeist passive Systeme zum Einsatz kommen (BMAS/BAuA, 2017, S. 69).

Medizin

In der Medizin werden Exoskelett-Systeme bereits für eine Vielzahl an Anwendungen benutzt.

So können Exoskelett-Systeme zur Unterstützung der Durchführung medizinischer Eingriffe verwendet werden, bei denen ein hoher Grad an Präzision durch den aus- führenden Chirurgen erfordert wird (Su, 2009). Ebenso ermöglichen jene Operatio- nen durch kleinere Einschnitte als bei klassischen Verfahren (Hessinger et al., 2015) sowie die Durchführung telemedizinischer Eingriffe (Meng et al., 2004), bei denen Spezialisten Operationen aus der Ferne an Patienten durchführen, wenn kein qua- lifizierter Arzt in der Nähe ist – beispielsweise in ländlichen Krankenhäusern oder Notfallsituationen.

Daneben spielen Exoskelett-Systeme eine immer größere Rolle in der Rehabilitation, beispielsweise von Schlaganfallpatienten (Heo et al., 2012; Lo & Xie, 2012). Ein Schlag- anfall führt in vielen Fällen zum vollständigen oder teilweisen Verlust der motorischen Fähigkeiten einer oder beider Hände (Kwakkel et al., 2003) und ist eine Hauptursache von Behinderung im Erwachsenenalter (Robert Koch-Institut, 2015, S. 43). Das Robert Koch-Institut prognostiziert, dass die Anzahl der Schlaganfallpatienten in Deutsch-

7 2 Grundlagen land von derzeit ca. 270 000 Personen pro Jahr aufgrund des demografischen Wan- dels zukünftig weiter steigen wird (Robert Koch-Institut, 2015, S. 44). 35,6 % der Be- troffenen werden in Folge eines Schlaganfalls pflegebedürftig (Robert Koch-Institut, 2015, S. 44). Durch das Durchführen von Greif- und Schlagübungen sowie anderen Rehabilitationsmaßnahmen, kann die Prognose dieser Patienten – sowohl bezüglich der Sterblichkeit als auch der Pflegebedürftigkeit – verbessert werden (Robert Koch- Institut, 2015, S. 48). Abbildung 2.1 zeigt die exponentiell zunehmende Anzahl der in den drei genutzten Datenbanken (Dimensions, PubMed und Google Scholar) gefun- denen Publikationen zu dem Suchbegriff „exoskeleton“ bzw. „robotic exoskeleton“ im Fall von Google Scholar; die Ergebnisse in Dimensions wurden auf technische und medizinische Journals beschränkt, um Publikationen beispielsweise zu tierischen Exo- skeletten zu filtern.

1 Dimensions PubMed Scholar

0.8

0.6

0.4

0.2

2000 2005 2010 2015 2020

Abbildung 2.1: Jährliche Publikationen zu robotischen Exoskelett-Systemen seit 2000 im prozentualem Verhältnis zu den Veröffentlichungen im Jahr 2019. In Dimensions, PubMed und Google Scholar waren 2019 4839, 439 und 3640 Ergebnisse zu finden.

8 2 Grundlagen

2.1.3 Steuerung von Exoskelett-Systemen

Die ersten Exoskelett-Systeme können in zwei Generationen eingeteilt werden (Ro- sen & Perry, 2007). Systeme der ersten Generation wurden direkt durch den Opera- tor gesteuert, indem dieser Bewegungen ausführt, welche durch das System verstärkt werden (Rosen & Perry, 2007). Dieser Ansatz wurde gewählt, da andere Formen von Daten noch nicht leicht maschinell verfügbar waren (Fick & Makinson, 1971). Jedoch zeigte sich bei Tests derartiger Systeme, dass diese zu komplex und nicht praktikabel waren (Kazerooni et al., 2006). Systeme der zweiten Generation erkannten die Bewe- gungen des Operators durch Kraftsensoren (Rosen & Perry, 2007). Parallel zu solchen Systemen wurden an der Universität Belgrad Systeme erforscht, welche in der La- ge waren vordefinierte Bewegungen durchzuführen, um behinderten Menschen das Laufen wieder zu ermöglichen (Baldovino & Jamisola, 2017).

Systeme der ersten und zweiten Generation fühlten sich für den Operator an, als wür- de das Exoskelett-System seinen Bewegungen nur folgen, nicht diese parallel ausfüh- ren. Durch die hierdurch reduzierte Bandbreite der Steuerung, war es nicht möglich schnelle und unvorhergesehene Bewegungen, wie das Fangen eines fallenden Ob- jekts, durchzuführen. Durch das Nutzen neurologischer Signale, statt der tatsächlich durchgeführten Bewegungen, kann die wahrgenomenne Verzögerung verringert werden. Die Systeme dieser Art werden als dritte Generation bezeichnet. (Rosen & Perry, 2007)

9 2 Grundlagen

2.1.4 Verwendetes Hand-Exoskelett

Im Rahmen dieser Arbeit wurde ein nichtinvasives Hand-Exoskelett des KONSENS Forschungsprojekts verwendet, welches eingesetzt werden soll, um die motorischen Fähigkeiten einer gelähmten Hand wiederherzustellen. In einem vorhergehenden For- schungsprojekt wurde mit dem Vorgänger-Modell des Hand-Exoskelett gezeigt, dass beispielsweise selbstständiges Essen und Trinken wieder ermöglicht werden kann (Soekadar et al., 2016).

Das System kann durch das Messen zwei verschiedener biologischer Signale gesteuert werden, welche ein Computer in Echtzeit auswertet (Soekadar et al., 2016). Einer- seits über das Messen elektrischer Ströme des Gehirns (als Elektroenzephalografie (EEG) bezeichnet) und andererseits über das Messen elektrischer Ströme des Auges (als Elektrookulografie (EOG) bezeichnet). Durch eine Kontrolleinheit werden Mo- toren und Aktoren gesteuert, welche das Hand-Exoskelett bewegen (Soekadar et al., 2016). Die Abbildung 2.2 gibt einen Überblick über das verwendete System.

(a) Steuerung (b) Komponenten

Abbildung 2.2: Übersicht des Hand-Exoskeletts des KONSENS Forschungsprojekts (Soekadar et al., 2016, bearbeitet durch den Autor)

Das Hand-Exoskelett ist in der Lage zwei verschiedene Grifftypen durchzuführen,

10 2 Grundlagen welche im Folgenden beschrieben werden. Abbildung 2.3 gibt einen Überblick über die beiden Grifftypen.

Palmar Grasp Bei diesem Grifftyp werden Objekte, wie Dosen oder Spielblöcke, aufgenommen, indem jene durch vier Finger und dem Daumen gegriffen werden. Dabei ruht das aufgenommene Objekt in der Handfläche. Lateral Pinch Bei diesem Grifftyp werden flache Objekte, wie Stifte oder Schlüssel, aufgenommen, indem jene zwischen dem Daumen und dem Zeigefinger gegriffen werden. Dabei ruhen die Finger in der Handfläche. Die Hand nähert sich hier von der Seite – nicht von oben.

(a) Palmar Grasp (b) Lateral Pinch

Abbildung 2.3: Darstellung der beiden verwendeten Grifftypen (Feix et al., 2016, bearbeitet durch den Autor)

Insbesondere für junge, technikaﬀine Menschen ist es wichtig, dass die Bedienung des Hand-Exoskeletts unauffällig stattfinden kann, um nicht durch Beobachter aus- gegrenzt zu werden (Ableitner et al., 2019). Hierzu können beispielsweise Sprach- steuerung, AR-Brillen oder Eyetracker zum Einsatz kommen (Ableitner et al., 2019),

11 2 Grundlagen welche neben anderen im Rahmen dieser Arbeit implementiert und evaluiert wurden.

2.2 Augmented Reality

Augmented Reality (AR) beschreibt eine interaktive Erfahrung, bei der Objekte der realen Welt durch computergenerierte Elemente erweitert werden; im Gegensatz zur VR, bei welcher der Nutzer vollständig in einer simulierten Welt agiert (Milgram et al., 1994). Die folgenden Abschnitte führen das Reality-Virtuality Continuum (RVC) ein und ordnen die AR darin ein. Anschließend wird ein kurzer Überblick über einige der aktuell relevanten kommerziell verfügbaren AR-Systeme gegeben. Die im Rahmen dieser Masterarbeit verwendete Google Glass AR-Brille wird in Abschnitt 5.1 (Ver- wendete Hardware) beschrieben.

2.2.1 Reality-Virtuality Continuum

Das Reality-Virtuality Continuum (RVC) (siehe Abbildung 2.4) beschreibt einen Ver- lauf zwischen dem vollständig Realem (der Realität oder „Reality“) und dem voll- ständig Virtuellem (der Virtualität oder „Virtuality“) (Milgram et al., 1994). Alle Va- rianten zwischen Realität und Virtualität werden als Mixed Reality (MR) bezeichnet und spezifischer in Augmented Reality (AR) und Augmented Virtuality (AV) eingeteilt (Milgram et al., 1994).

12 2 Grundlagen

Abbildung 2.4: Repräsentation des Reality-Virtuality Continuums (Milgram et al., 1994, bearbeitet durch den Autor)

Augmented Reality

Augmented Reality beschreibt Erfahrungen, bei denen die Realität den Hauptanteil ausmacht.

Beispielsweise werden dem Besucher eines Museums zusätzliche Informationen oder Videos zu den ausgestellten Stücken durch ein Head-up-Display (HUD) präsentiert. In vielen Fällen haften die dargestellten Informationen den jeweiligen Objekten an, als befänden sich jene in der realen Welt, wenn der Nutzer sich im Raum bewegt.

Kommerziell existieren eine Vielzahl an dedizierten AR-Systemen, wie den Smart- glasses Epson Moverio oder Google Glass. Daneben unterstützen sowohl Android als auch iOS native AR-Anwendungen, die das Display eines Smartphones oder Ta- blets nutzen, das der Nutzer in der Hand hält. Weitere Systeme wie der Nintendo 3DS erlauben Entwicklern die zwei rückwärtsgewandten 3-D-Kameras der Konsole zu nutzen, um AR-Spiele zu entwickeln.

13 2 Grundlagen

Augmented Virtuality

Virtual Reality beschreibt Erfahrungen, bei denen die Virtualität den Hauptanteil ausmacht.

Beispielsweise wird dem Spieler in einem Videospiel ein Schwert, welches er in der realen Welt hält und kontrolliert, eingeblendet, während jener vollständig in einer virtuellen Welt gegen Drachen kämpft.

Ebenso wie bei AR existieren verschiedene dedizierte VR-Systeme, wie die Oculus Go oder PlayStation VR, welche sich auch als AV-Systeme nutzen lassen. Daneben lassen sich Android und iOS Smartphones oder die Nintendo Switch Konsole als VR- Headsets tragen und mit verschiedenen VR-Apps verwenden.

In der Praxis sind jedoch kaum AV-Anwendungen außerhalb des prototypischen Kon- texts zu finden. Lediglich virtuelle Fernsehstudios, bei welchen der Moderator in einer komplett virtuellen Umgebung mit echten und simulierten Objekten interagiert, finden Anwendung.

2.2.2 Gestaltung von Anwendungen auf Google Glass

Laut Tanuma et al. (2011) hat die Positionierung eines Benutzeroberflächen-Elements keine Auswirkung auf die Lesbarkeit von Benutzeroberflächen-Elementen auf Gerä- ten wie der Google Glass, wenngleich Elemente auf der Nasenseite für die Studienteil- nehmer komfortabler zu lesen waren. Darüberhinaus waren Elemente an der Stirn- seite weniger komfortabel als Elemente auf der unteren Seite (Tanuma et al., 2011).

14 2 Grundlagen

Daneben empfehlen Tanuma et al. (2011) die Verwendung eines komplett schwar- zen Hintergrunds und von Farben mit hoher Helligkeit und Leuchtdichte, da diese den höchsten Komfort bieten. Abbildung 2.5 zeigt das Komfortlevel an verschiedenen Stellen auf dem Display.

66,7 88,9 50,0 % % %

88,9 94,4 66,7 % % %

88,9 97,2 66,7 % % %

Abbildung 2.5: Komfortlevel an verschiedenen Stellen auf dem Display. Hierbei befand sich das Dis- play auf der Seite des nichtdominanten Auges. Darstellung durch den Autor auf Basis der Daten von Tanuma et al. (2011).

2.3 Technische Grundlagen

Die entwickelte Anwendung wurde als native Anwendung für Android und die An- droid basierenden Betriebssysteme Glass OS und Wear OS implementiert. Daneben wurde ein hybrider Ansatz in Betracht gezogen, mit welchem ein webbasiertes User Interface (UI) durch native Sensorwerte gesteuert wird; die Kommunikation mit Ha- zelcast wurde über die Representational State Transfer (REST) Schnittstelle Hazel- casts implementiert. Schlussendlich wurde der hybride Ansatz aus Performancegrün- den zugunsten der nativen Anwendung verworfen. Die folgenden Abschnitte geben

15 2 Grundlagen einen Überblick über die verwendeten Frameworks und die technischen Grundlagen hybrider Anwendungen.

2.3.1 In-Memory Data Grids (IMDG)

Für die Funktion der Anwendung ist eine Kommunikation mit der Hardware des Hand-Exoskeletts notwendig, um beispielsweise den Status des Hand-Exoskeletts ab- zufragen oder Anweisungen an dieses zu senden, welche die Open-Source-Software Hazelcast IMDG1 verwendet. Hazelcast implementiert ein In-Memory Data Grid, mit welchem Daten verteilt gespeichert sowie von unterschiedlichen Geräten benutzt und modifiziert werden können (Di Sanzo et al., 2013). Im Fall von Hazelcast werden sämt- liche Daten im Arbeitsspeicher (also „in memory“) der Systeme gehalten.

Obwohl Hazelcast für eine Vielzahl an Programmiersprachen verfügbar ist – unter anderem auch Java – konnte der oﬀizielle Client nicht für das Projekt verwendet werden, da darin Funktionen von Java verwendet werden, welche nicht alle auf der Laufzeit- umgebung von Android (Dalvik bzw. ART) verfügbar sind (Allen, 2015, S. 358).

Aus diesem Grund wurden die notwendigen Funktionen des oﬀiziellen Java Clients durch den Autor auf Android portiert oder durch Open-Source Backports und Imple- mentierungen ersetzt. Nicht benutzte Features wie LDAP und Logging mit Log4J oder SL4J wurden entfernt, sofern hierdurch eine Anpassung für Android erforderlich ge- wesen wäre. Die angepasste Library findet sich in den Anlagen dieses Dokuments.

1vgl. https://hazelcast.org/

16 2 Grundlagen

2.3.2 Hybride Apps

Anwendungen für mobile Geräte können auf unterschiedliche Weisen geschrieben werden: als native, hybride oder webbasierte App. Alle drei Paradigmen haben unterschiedliche Einsatzzwecke und jeweils Vor- und Nachteile (Que et al., 2016).

Native Apps werden für die jeweilige Plattform spezifisch geschrieben, beispielsweise in Kotlin für Android oder in Swift für iOS. Hierdurch ist direkter Zugriff auf die zugrunde liegende Hardware und Optimierung für die spezifische Plattform mög- lich (Que et al., 2016). Allerdings steigt der Entwicklungsaufwand mit jeder weiteren Plattform deutlich an, da im Wesentlichen kein Code zwischen den Varianten wieder- verwendet werden kann (Que et al., 2016).

Webbasierte Apps laufen in einer Browserumgebung und werden mit Webtechnolo- gien wie HTML, CSS oder JavaScript geschrieben (Que et al., 2016), wodurch eine App nur einmal geschrieben werden muss aber prinzipiell auf allen Geräten läuft, die einen kompatiblen Webbrowser installiert haben. Im Gegensatz zu nativen Apps ist die Anpassung an das spezifische Gerät nicht möglich, weswegen webbasierte An- wendungen oft nicht die Erwartungen der Nutzer an die UI-Normen ihrer Plattform erfüllen und daneben nicht dieselbe Performance erreichen können (Que et al., 2016). Weiterhin ist ein Zugriff auf Hardware – wie Sensoren – nicht oder nur unter Verwen- dung von Web Application Programming Interfaces (APIs) möglich, die nicht immer alle Features der nativen APIs abdecken (Que et al., 2016).

Hybride Apps sind eine Lösung zwischen nativer und webbasierter App. Hierbei kommen ebenfalls Webtechnologien bei der Entwicklung zum Einsatz, die mithilfe

17 2 Grundlagen einer Middleware – wie Apache Cordova2 – mit nativen APIs direkter interagieren können (Que et al., 2016). Verbreitet verfügt die Middleware auch über UI Kompo- nenten, welche für die verschiedenen Plattformen passend gerendert werden (Que et al., 2016).

Intel Crosswalk

Intel Crosswalk ist eine Open-Source-Laufzeit, um Cross-Plattform-Webanwendung- en zu schreiben. Crosswalk ermöglicht eine auf dem Chromium Browser und der Blink Browserengine basierende Umgebung zu nutzen, welche auf iOS, Android, Ti- zen sowie Windows und Linux Desktops, gleich ist – unabhängig davon, welche Brow- serversion auf den jeweiligen Geräten installiert ist. Besonderer Fokus wurde darauf- gelegt, die aktuellsten Browserfeatures, auch solche die experimentell sind, zu un- terstützen. Intel Crosswalk wird seit 2017 nicht mehr weiterentwickelt und basiert in der letzten veröffentlichten Version auf Chromium 53 (Intel Corporation, 2017), deckt aber alle im Rahmen dieser Arbeit benötigten Features ab.

Da auf Wear OS kein Webbrowser verfügbar ist, kann Crosswalk benutzt werden, um auf allen unterstützten Geräten über dieselbe Browserumgebung zu verfügen.

2vgl. https://cordova.apache.org/

18 3 Methodik

Dieses Kapitel beschreibt die verwendete Methodik dieser Arbeit. Abbildung 3.1 zeigt ein Flussdiagramm des methodischen Vorgehens.

Ableitung eines Zusammenfassung Vergleich der gemeinsamen der Kriterien Richtlinien Kriterienkatalogs

Literaturrecherche zu AR und Gestaltung von AR-Anwendungen

Technischer Initiale Erster Prototyp Zweiter Expertenreview Durchstich Studienidee (hybrid) Prototyp (nativ) (nativ)

Technischer Durchstich (hybrid) Verbesserter Pilotstudie Prototyp (nativ) Prototyp (nativ)

Auswertung Studie

Abbildung 3.1: Übersicht der Methodik dieser Arbeit.

19 3 Methodik

3.1 Technische Methodik

Um die Forschungsfrage dieser Arbeit zu untersuchen, war ein Prototyp einer Steue- rung für ein Handexoskelett zu implementieren. Hierzu wurde zunächst ein hybrider Ansatz verfolgt, um den Entwicklungsaufwand für die drei genutzten Geräte zu limi- tieren. Daneben wurde während des technischen Durchstichs festgestellt, dass Hazel- cast nicht auf Android ausführbar ist, weswegen eine JavaScript-basierte Implemen- tierung verwendet werden sollte.

Um den Lernaufwand für Nutzer gering zu halten und diesen einen flexiblen Wechsel zwischen den Ausgabegeräten zu ermöglichen, sollte eine Benutzeroberfläche gestaltet werden, welche auf allen drei getesteten Geräten verwendbar ist. Hierbei wurde die Implementierung für die Google Glass priorisiert, da eine Anwendung für dieses Gerät spezifische Anforderungen hat gegenüber der Smartwatch und dem Smartpho- ne.

Das resultierende Steuerungskonzept wurde im Rahmen eines Expertenreviews anhand eines vertikalen Prototyps evaluiert. Hierbei wurde das allgemeine Konzept po- sitiv aufgenommen, jedoch einzelne Aspekte zur Verbesserung festgestelt, welche verbessert wurden. In Folge des Reviews verwendet beipielsweise das Hervorheben des ausgewählten Icons nun neben Farben auch eine Invertierung.

Aufgrund der SARS-CoV-2-Pandemie konnten die Benutzerstudien nicht zum geplan- ten Zeitpunkt Anfang 2020 stattfinden und mussten auf Mitte 2020 verschoben werden. Die gewonnene Zeit konnte genutzt werden, einen zweiten technischen Durch- stich durchzuführen, bei welchem Hazelcast auf Android ausgeführt werden konnte. Hierdurch war nun eine native Implementierung möglich, welche umgesetzt wurde,

20 3 Methodik um eine bessere Performance und Wartbarkeit zu erreichen.

Diese native Implementierung wurde mit drei Studienteilnehmern im Rahmen einer Pilotstudie ausprobiert, währenddessen verschiedene Schwierigkeiten bei der Einga- be und der Durchführung des Versuchs festgestellt wurden. Beispielsweise wurden die Kalibrierung der Eyetracker-Steuerung und verschiedene Timings angepasst.

Etwa einen Monat nach dieser Pilotstudie wurde schließlich eine Evaluierung mit zwanzig Teilnehmern durchgeführt, während der keine Änderungen mehr an der getesteten Anwendung durchgeführt wurden, jedoch aufgefallene Probleme im Wuell- code behoben wurden. Beispielsweise wurde ein Absturz der Eyetrackersteuerung nach einem fertigen Durchlauf behoben.

3.2 Theoretische Methodik

Parallel zu dem ersten Prototyp wurde eine Literaturrecherche durchgeführt, um De- signaspekte für die Gestaltung von Augmented Reality herauszuarbeiten, welche in die Implementierung eingeflossen sind. Daneben wurden mehrere Richtlinien zur barrierefreien Gestaltung von Augmented Reality Anwendungen recherchiert und zusammengefasst. Die hierbei gewonnenen Erkenntnisse wurden genutzt, um einen gemeinsamen Kriterienkatalog abzuleiten und die betrachteten Richtlinien mit diesen zu vergleichen.

21 4 AR- und VR-Richtlinien

Im Folgenden werden verschiedene Richtlinien zur Nutzung von AR und Anforde- rungen an die barrierefreie Nutzbarkeit von Informations- und Kommunikationstech- nik (ICT) beschrieben und anschließend zu einem gemeinsamen Kriterienkatalog zusammengefasst. Hierbei wurde durch den Autor jeweils eine Einteilung, in eine von vier Kategorien, vorgenommen, die in den Ursprungsdokumenten nicht vorkommt, welche an die Kategorien der Web Content Accessibility Guidelines (WCAG) ange- lehnt ist – wobei die Kategorie Robust durch Verschiedenes ersetzt wurde, um Kriterien aufzunehmen, welche im Kontext der WCAG nicht abgedeckt sind.

1. Wahrnehmbar Informationen müssen für verschiedene Nutzer wahrnehmbar sein. 2. Bedienbar Interaktionen müssen durch verschiedene Nutzer durchführbar sein. 3. Verständlich Informationen und Interaktionen müssen von verschiedenen Nut- zern verstehbar sein. 4. Verschiedenes Kriterien dieser Kategorie decken weitere Anforderungen ab, welche nicht in die drei anderen Kategorien passen. Hierbei handelt es sind in vielen Fällen um Aspekte, die spezifisch AR-Anwendungen betreffen.

22 4 AR- und VR-Richtlinien

4.1 XR Accessibility User Requirements (W3C)

Das World Wide Web Consortium (W3C) ist eine internationale Standardisierungsor- ganisation, welche Protokolle und Standards („Recommendations“) für das Web ver- öffentlicht (W3C, 2020). W3C-Standards selbst haben keinen international anerkann- ten Charakter, bilden jedoch die Basis mancher internationalen Standards – beispielsweise wurde die WCAG 2.0 durch die International Organization for Standardizati- on (ISO) und International Electrotechnical Commission (IEC) als ISO/IEC-Standard übernommen (Jacobs & Frost, 2012). Auch die maßgebliche Verordnung zur Barrie- refreiheit in Deutschland – die Barrierefreie-Informationstechnik-Verordnung (BITV) bezieht sich explizit auf die Kriterien der WCAG des W3Cs1 (Bundesministerium des Innern, 2002, Anlage Teil 1).

Innerhalb des W3Cs arbeiten unterschiedliche Arbeitsgruppen an spezifischen The- men und Technologien (World Wide Web Consortium (W3C), n. d.). Die Accessible Platform Architectures Working Group (APA WG) ist eine Arbeitsgruppe, welche sich mit der Barrierefreiheit von Spezifikationen des W3Cs beschäftigt und zum Ziel hat, diese sicherzustellen (Accessible Platform Architectures Working Group, 2018). Die XAUR ist eine Spezifikation zur Barrierefreiheit von Cross Reality (XR) Anwen- dungen – also VR, MR, AR und verwandte Technologien (Accessible Platform Archi- tectures Working Group, 2020b). Zum Zeitpunkt der Abgabe dieser Masterarbeit ist die Spezifikation als Arbeitsentwurf klassifiziert (Accessible Platform Architectures Working Group, 2020b), die erste öffentliche Phase für einen Entwurf, der nach mehreren erfolgreichen Reviews und Revisionen zu einer Recommendation erhoben werden kann (World Wide Web Consortium (W3C), 2019, § 6.1.1).

1Hier beispielhaft BITV 1.0 und WCAG 1.0.

23 4 AR- und VR-Richtlinien

Die XAUR definiert 18 Nutzerbedürfnisse („user needs“), welchen jeweils durch das Erfüllen einer oder mehrerer Anforderungen gerecht werden kann (Accessible Plat- form Architectures Working Group, 2020b, § 4). In Tabelle 4.1 werden diese in der Version vom 17.02.2020 zusammengefasst dargestellt.

§ Beschreibung

1. Wahrnehmbar

6a Die Farben und Kontraste von Elementen müssen durch den Nutzer anpassbar sein.

9a Gestenbasierte Interfaces müssen eine Sprachausgabe unterstützen, welche dem Nutzer weitere Informationen zum jeweiligen Element gibt.

17a Auditive Informationen müssen binaural ausgegeben werden können.

18a Untertitel und andere Texte müssen anpassbar und vergrößerbar sein, ohne deren Inhalt oder Funktion zu verlieren.

2. Bedienbar

1b Eingabemechanismen müssen rekonfigurierbar sein beispielsweise bezüg- lich der Belegung und der Sensitivität.

2a Eingabemechanismen, welche physische Bewegungen im Raum erfordern, müssen eine nicht-physische Alternative anbieten.

2b Alle Eingaben müssen mit ein und demselben Eingabegerät durchführbar sein.

2c Mehrere verschiedene Eingabemechanismen müssen gleichzeitig benutzt werden können.

Auf nächster Seite fortgesetzt

24 4 AR- und VR-Richtlinien

§ Beschreibung

4a Feinmotorische Fähigkeiten dürfen nicht vorausgesetzt werden, um eine Eingabe durchzuführen.

4b Interaktive Elemente müssen groß genug und mit ausreichendem Ab- stand platziert werden, damit diese leicht wählbar sind.

4c Mehrere gleichzeitige Eingaben dürfen nicht vorausgesetzt werden, um eine Eingabe durchzuführen.

5a Alle Eingaben müssen ausschließlich durch Sprachsteuerung durchge- führt werden können.

7a Beim Nutzen einer Bildschirmlupe muss der aktuelle Fokus und Kontext erkennbar sowie zurücksetzbar sein.

13a Das Zurücksetzen und Kalibrieren des Bildschirmausschnitts muss mög- lich sein.

14a Textuelle und auditive Inhalte müssen über Geräte – wie Braillezeilen – ausgegeben werden können.

15b Timings für Interaktionen müssen anpassbar sein.

16a Interaktionen, welche bekannt sind physische Reaktionen, wie Epilepsie, zu verursachen, sind zu vermeiden bzw. müssen deaktivierbar sein.

16b Die Frequenz des Flimmerns von Elementen muss auf höchstens 3 Hz limitiert bzw. deaktivierbar sein.

3. Verständlich

3a Ikonografische Zusatzinformationen müssen optional über Elemente der virtuellen Umgebung platziert werden.

Auf nächster Seite fortgesetzt

25 4 AR- und VR-Richtlinien

§ Beschreibung

8a Kritische Informationen müssen dem Nutzer mitgeteilt werden, ohne den Fokus zu bewegen.

10a Textuelle Informationen müssen durch einen Gebärdensprach-Avatar prä- sentiert werden können.

13b Das Sichtfeld muss konfigurierbar sein.

15c Für Nutzer mit kognitiven Einschränkungen muss ein virtueller Hilfsava- tar verfügbar sein, welcher Hinweise zur Nutzung geben kann.

15d Es müssen klare Start- und Stopmechanismen vorhanden sein.

4. Verschiedenes

1a Elemente der virtuellen Umgebung müssen für assistive Technologien semantisch beschrieben sein.

3b Nicht-kritische Inhalte wie Animationen müssen deaktivierbar sein.

11a Für Nutzer mit kognitiven Einschränkungen muss ein immer erreichbarer sicherer Ort („safe place“) verfügbar sein, welcher die immersive Erfah- rung pausiert.

12a Der Nutzer muss in der Lage sein, sich selbst ein Zeitlimit zu setzen, nach welchem die immersive Erfahrung gestoppt wird.

15a Die Geschwindigkeit der immersiven Erfahrung und der Bewegungen darin muss anpassbar sein.

Tabelle 4.1: Tabellarische Zusammenfassung der Anforderungen der XR Accessibility User Require- ments (XAUR)

26 4 AR- und VR-Richtlinien

4.2 ETSI EN 301 549

Das European Telecommunications Standards Institute (ETSI) ist eine Normungsor- ganisation mit Sitz in Frankreich und mit über 850 Mitgliedern weltweit (European Standards Organization, 2020). Sie ist eine von drei Normungsorganisationen, welche europäische Normen verabschieden können (Amt für Veröffentlichungen der Eu- ropäischen Union, 2012, S. 12). Eine der Normtypen, die das ETSI verabschieden kann, ist die Europäische Norm (EN), welche nach der Ratifizierung durch alle nationalen Normungsorganisationen der Mitgliedstaaten – wie dem Deutschen Institut für Nor- mung (DIN) – als nationale Norm umgesetzt werden muss, wobei auch eventuell be- stehende widersprechende nationale Normen zurückgezogen werden müssen (CEN CENELEC, 2020).

Die ETSI EN 301 549 Norm beschreibt funktionale Anforderungen an die Barriere- freiheit von ICT Produkten und Services sowie Testverfahren zur Evaluierung der Umsetzung technischer Maßnahmen (European Telecommunications Standards In- stitute, 2018, S. 10).

Kapitel 4 der Norm beschreibt Anforderungen an ICT Produkte, die Nutzern ermögli- chen Funktionen zu finden, zu identifizieren und zu benutzen sowie die bereitgestell- ten Informationen, gleich ihrer körperlichen, kognitiven oder sensorischen Fähigkei- ten zu nutzen (European Telecommunications Standards Institute, 2018, S. 10). Neben den Kriterien als solchen, sind jeweils Umsetzungsnotizen („NOTES“) angegeben, welche umgesetzt werden können, um das Kriterium zu erfüllen.

In Kapitel 5.1 werden Besonderheiten geschlossener Systeme – also Systeme, die der Nutzer nicht mit Hard- oder Software modifizieren kann, wie zum Beispiel einen Fahr-

27 4 AR- und VR-Richtlinien kartenautomaten – beschrieben (European Telecommunications Standards Institute, 2018, S. 20). Die Kriterien 5.2 - 5.13 müssen hier dennoch soweit anwendbar erfüllt werden – ohne eine Anpassung durch den Nutzer zu erfordern2 (European Telecom- munications Standards Institute, 2018, § 5.1.2.1).

Kapitel 11 wendet die Anforderungen der WCAG Stufe AA auf allgemeine Software- produkte an. Einzelne Anforderungen finden keine Anwendung.

In Tabelle 4.2 werden auf AR allgemein anwendbare Kriterien der ETSI EN 301 549 Norm zusammengefasst dargestellt, wobei Umsetzungsnotizen und Anforderungen nicht unterschieden wurden.

§ Beschreibung

1. Wahrnehmbar

4.2.1 Für blinde Nutzer müssen Alternativen für visuelle Inhalte bereitgestellt werden. Die semantische Beschreibung virtueller Elemente kann hier un- terstützend sein, ebenso wie beispielsweise ein auditives Interface.

4.2.2 Farben, Kontraste, Helligkeit und das Sichtfeld sollten anpassbar sowie eine Vergrößerung verfügbar sein. Daneben sollte eine Anwendung nicht die Erkennung von Tiefe voraussetzen.

4.2.3 Für Inhalte, die das Erkennen und Unterscheiden von Farben voraussetzen, müssen Alternativen bereitgestellt werden.

4.2.4 Für auditive Inhalte muss eine Alternative bereitgestellt werden.

Auf nächster Seite fortgesetzt

2Persönliche Kopfhörer und Induktionsschleifen gelten nicht als solche Anpassung (European Te- lecommunications Standards Institute, 2018, § 5.1.2.2)

28 4 AR- und VR-Richtlinien

§ Beschreibung

4.2.5 Hintergrundgeräusche sowie der Dynamikumfang von auditiven Inhal- ten müssen anpassbar sein.

7.1.1 Für Videos mit Audioinhalt müssen Untertitel vorhanden sein. Beim Nut- zen geschlossener Untertitel ist eine Eingabe zu schaffen, diese zu aktivieren.

7.1.2 Vorhandene Untertitel müssen mit dem zugehörigen Audioinhalt synchronisiert sein.

7.2.1 Für Videos mit Audioinhalt sind Audiodeskriptionen bereitzustellen.

7.2.2 Vorhandene Audiodeskriptionen müssen mit dem zugehörigen Audioin- halt synchronisiert werden.

2. Bedienbar

4.2.6 Für Sprach- und Lauteingaben muss eine Alternative bereitgestellt werden.

4.2.7 Feinmotorische Fähigkeiten dürfen nicht vorausgesetzt werden, um eine Eingabe durchzuführen.

4.2.7 Gleichzeitige Eingaben sollen nicht erforderlich sein, ebenso wie eine bestimmte Stärke der Eingaben.

4.2.8 Alle Eingaben müssen für Nutzer mit eingeschränkter Mobilität – wie beispielsweise Rollstuhlfahrer – möglich sein.

4.2.9 Interaktionen, welche bekannt sind physische Reaktionen, wie Epilepsie, zu verursachen, müssen vermieden werden.

4.2.10 Timings für Interaktionen müssen anpassbar sein.

Auf nächster Seite fortgesetzt

29 4 AR- und VR-Richtlinien

§ Beschreibung

4.2.10 Der Fokus muss einer logischen Ordnung folgen.

5.2 Das Aktivieren von assistiven Funktionen muss seinerseits barrierefrei möglich sein.

5.3 Das Vorhandensein einer spezifischen biometrischen Eigenschaft, wie eines Fingerabdrucks, darf nicht als alleiniger Eingabemechanismus vorausgesetzt werden.

5.5.1 Eingaben, die ein Greifen oder Kneifen der Hand sowie ein Drehen des Handgelenks erfordern, müssen eine Alternative bereitstellen.

5.7 Die Tastaturverzögerung muss auf mindestens 2 s nach oben und die Wie- char derholrate auf mindestens 0,5 s nach unten einstellbar sein, sollte eine Tastenwiederholung aktiviert sein.

5.8 Die Verzögerung zwischen zwei gleichen Eingaben muss auf mindestens 0,5 s nach oben einstellbar sein.

5.9 Mehrere gleichzeitige Eingaben dürfen nicht vorausgesetzt werden, um eine Eingabe durchzuführen.

7.3 Das Aktivieren von Audiodeskription oder Untertiteln muss auf eine ver- gleichbare Weise möglich sein, wie andere Steuerungsfunktionen – beispielsweise der Wiedergabe oder Pausierung.

3. Verständlich

4.2.10 Fehlermeldungen und Hinweise zu deren Behebung müssen angezeigt werden.

Auf nächster Seite fortgesetzt

30 4 AR- und VR-Richtlinien

§ Beschreibung

5.5.2 Die Funktion von Eingaben muss durch den Nutzer nicht-visuell bestimmbar sein – ohne diese durchführen zu müssen.

5.6.1 Die Stellung von 2- und 3-Wege-Schaltern muss durch den Nutzer nicht- visuell bestimmbar sein – ohne diese aktivieren zu müssen.

5.6.2 Ebenfalls muss die Stellung von 2- und 3-Wege-Schaltern durch den Nut- zer visuell bestimmbar sein – ohne diese aktivieren zu müssen.

4. Verschiedenes

4.2.11 Anpassungen zur Barrierefreiheit dürfen nicht die Privatsphäre des Nut- zers einschränken. Beispielsweise sollte eine Sprachausgabe maskierte Textfelder nicht laut vorlesen.

Tabelle 4.2: Tabellarische Zusammenfassung der Anforderungen durch die EN 301 549

4.3 Apple Human Interface Guidelines

Die AHIG beschreiben, wie Anwendungen auf den verschiedenen Plattformen Apples gestaltet werden sollen, um eine gute User Experience zu bieten (Apple Inc., n. d.). Für die Plattform iOS definiert Apple Anforderungen an Apps, die die AR-Bibliothek iOS’ (Apple ARKit) nutzen – ein VR-Produkt hat Apple derzeit nicht auf dem Markt. Der Fokus liegt auf der Erstellung immersiver und fesselnder Erfahrungen, die virtuelle Objekte mit der realen Welt mischen (Apple Inc., n. d.).

In Tabelle 4.3 werden diese zusammengefasst dargestellt. Die Abschnittsangaben wur-

31 4 AR- und VR-Richtlinien den durch den Autor hinzugefügt und beziehen sich auf die digital beigefügte PDF- Version des Dokuments. Anforderungen, welche spezifischen Bezug auf Eigenschaf- ten von ARKit nehmen, sind weggelassen3.

§ Beschreibung

1. Wahrnehmbar

1.4 Auditive und taktile Effekte sind zu benutzen, um erfolgreiche Interaktio- nen hervorzuheben.

1.7 Steuerungsfunktionen sollten transluzent gestaltet werden, um die darun- terliegende Szene nicht zu verbergen.

7.3 Wichtige Textausgaben sollten deutlich im Screenspace hervorgehoben gestaltet werden.

2. Bedienbar

1.6 Zusätzlich notwendige Steuerungsfunktionen und Hinweise sind im Screenspace zu platzieren – also nicht in dem 3-D-Koordinatensystem der realen oder virtuellen Umgebung, sondern dem 2-D-Koordinatensystem des Geräts.

1.7 Soweit möglich, sollten indirekte Steuerungsfunktionen für persistente Eingaben benutzt werden.

1.7 Persistente Steuerungsfunktionen sollten so positioniert werden, dass das Gerät nicht umgegriffen werden muss, um diese zu nutzen.

1.8 Die Anwendung muss Orte verschiedener Größe unterstützen und den Nutzer über den erwarteten Platzbedarf informieren.

Auf nächster Seite fortgesetzt

3Dies sind vor allem 10. und 11., welche die Verwendung des Apple ARKit Logos beschreiben.

32 4 AR- und VR-Richtlinien

§ Beschreibung

4.1 Soweit möglich, sollten direkte Steuerungsfunktionen für nicht- persistente Eingaben benutzt werden, außer in Fällen, in denen sich Nut- zer viel bewegen.

4.2 Soweit möglich, sollte die Anwendung bekannte Gesten wie Pinch-To- Zoom verwenden.

4.3 Soweit möglich, sind vereinfachte 2-D-Gesten zu verwenden, um Objekte in der 3-D-Umgegung der realen Welt zu manipulieren.

4.4 Die Anwendung sollte auch auf Interaktionen reagieren, die nicht direkt auf, sondern knapp neben ein Objekt zielen.

4.6 Die Anwendung sollte ähnliche Gesten vermeiden oder sicherstellen, diese ausreichend zu testen.

3. Verständlich

1.2 Sollte die Anwendung realistische Elemente in der virtuellen Welt platzieren, müssen sich diese glaubhaft und verständlich verhalten, um den Nutzer nicht abzulenken. Beispielsweise können hierzu realistische Schat- ten und Reflexionen benutzt werden4.

1.5 Textuelle Inhalte sind auf das Minimum zu reduzieren, das notwendig ist, die Anwendung zu nutzen.

Auf nächster Seite fortgesetzt

41.3 beschreibt technische Limitierungen ARKits zu Reflexionen.

33 4 AR- und VR-Richtlinien

§ Beschreibung

2.1 Die Anwendung sollte ein Tutorial anbieten, welches wichtige Bedien- konzepte einführt und den Nutzer durch eventuell notwendige Setupauf- gaben führt. Dieses kann auch nach Unterbrechungen – wie z. B. nach einem Telefonanruf – eingesetzt werden (vgl. 8.1)5. Die Anwendung sollte das Tutorial ohne Ablenkungen anzeigen: Andere UI-Elemente sind beispielsweise auszublenden.

3.1 Die Anwendung sollte dem Nutzer anzeigen, wenn eine Oberfläche zu lokalisieren, oder ein Objekt zu platzieren ist.

3.2 Platzierte Objekte sollen frühzeitig angezeigt werden, selbst wenn noch verfeinerte Positionsinformationen verfügbar sein werden.

3.3 Die Anwendung sollte den Nutzer über Objekte außerhalb des Sichtfeldes informieren.

3.5 Die Anwendung sollte dem Nutzer anzeigen, welche Klassifikation die vorhandenen Ebenen (z. B. Boden oder Wand) haben, sodass dieser weiß, ob ein spezifisches Objekt darauf platziert werden kann.

4.7 Ebenso sollten Elemente sich realistisch bewegen und nicht, beispielsweise während einer Bewegung, verschwinden.

5.1 Wenn die Anwendung mehrere Nutzer unterstützt, sollte Okklusion implementiert werden, um ein nachvollziehbares, realistisches Verhalten abzubilden.

Auf nächster Seite fortgesetzt

52.3 beschreibt spezifische Implementierungsdetails zu Tutorials (Coaching View genannt in ARKit).

34 4 AR- und VR-Richtlinien

§ Beschreibung

5.2 Wenn die Anwendung mehrere Nutzer unterstützt, sollte es möglich sein, weitere Nutzer im Programmverlauf in dieselbe virtuelle Umgebung aufzunehmen.

7.1 Sollte die Ausgabe von Textinhalten notwendig sein, ist eine einfache, nicht-technische Sprache zu verwenden.

7.2 Für 3-D-Interaktionen sind 3-D-Indikatoren zu bevorzugen. Beispielswei- se sollen bei der Rotation eines Würfels Rotationsindikatoren um das Ob- jekt herum – also im Raum und nicht im Screenspace – angezeigt werden.

7.4 Sollten weitere Informationen zum Verständnis eines Objekts notwendig sein, ist ein einheitlicher Indikator zu verwenden, durch welchen der Nut- zer an allen Objekten weitere Informationen erhalten kann.

8.5 Sollte die Anwendung die Frontkamera des Geräts verwenden, ist dem Nutzer anzuzeigen, wenn diese für mehr als 500 ms keine Erkennung mehr durchführen konnte.

9.2 Die Anwendung sollte dem Nutzer Vorschläge zum Lösen und Verhin- dern von Problemen anzeigen, sodass er diese ausführen kann.

4. Verschiedenes

0.1 Anwendungen, die ausschließlich AR-Funktionen anbieten, sollten nur für AR-kompatible Geräte installierbar sein.

0.1 Anwendungen, die AR-Funktionen und Nicht-AR-Funktionen anbieten, sollten AR-Funktionen nur auf AR-kompatiblen Geräten anbieten.

Auf nächster Seite fortgesetzt

35 4 AR- und VR-Richtlinien

§ Beschreibung

1.1 UI-Elemente, welche von der immersiven Erfahrung ablenken können, sollen, soweit möglich, vermieden werden.

1.9 Objekte der virtuellen Umgebung sollen nicht zu weit weg im Raum positioniert werden, um Müdigkeit des Nutzers zu vermeiden.

1.9 Die Anwendung – insbesondere Spiele – soll an regelmäßige Pausen erinnern oder ruhigere Abschnitte vorsehen.

1.10 Wenn die Anwendung Bewegungen im Raum erfordert, sind diese all- mählich einzuführen, um den Nutzer nicht zu überfordern.

1.11 Die Anwendung sollte keine schnellen oder weiten Bewegungen erfordern, um den Nutzer nicht zu gefährden.

4.5 Objekte der virtuellen Welt sollten durch den Nutzer skalierbar sein, au- ßer sie bilden die reale Welt ab (beispielsweise eine Anwendung eines Möbelhauses, mit der der Nutzer Möbel in seiner Wohnung platzieren kann, sollte nicht skalieren).

4.8 Die Anwendung soll mit verschiedenen Interaktionsmethoden im Hin- terkopf gestaltet werden. So könnte beispielsweise Nähe zu einem Objekt, anstatt einer Geste, zur Interaktion verwendet werden.

6.1 Wenn die Anwendung auf bestimmte Objekte in der realen Umgebung, wie ein Filmplakat, reagieren kann, sollten die zusätzlich eingeblendeten Informationen eine kurze Zeit verbleiben, nachdem das Objekt aus dem Sichtfeld gekommen ist6.

Auf nächster Seite fortgesetzt

66.2f beschreiben technische Limitierungen ARKits zur Erkennung von Referenzbildern in der realen Umgebung.

36 4 AR- und VR-Richtlinien

§ Beschreibung

8.2 Während einer Neujustierung sollten virtuelle Objekte verborgen werden, um ein Flimmern zu verhindern.

8.3 Soweit diese vermeidbar sind, sind Wechsel zwischen AR und nicht-AR Teilen der App zu vermeiden.

8.4 Sollte eine Neujustierung nicht erfolgreich sein, ist dem Nutzer anzubie- ten, die Simulation zurückzusetzen.

9.1 Die Anwendung soll dem Nutzer erlauben, die Simulation zurückzuset- zen.

Tabelle 4.3: Tabellarische Zusammenfassung der Anforderungen der Apple Human Interface Guide- lines

4.4 Google Augmented Reality Design Guidelines

Die GARDG beschreiben, wie AR-Anwendungen für Android Geräte geschrieben werden sollten (Google Inc., 2020). Die Kriteriennummerierung wurde durch den Autor hinzugefügt und bezieht sich auf die digital beigefügte PDF-Version des Dokuments. Kriterium 6.3 ist dabei als sequenziell drittes Kriterium auf Seite 6 zu lesen.

§ Beschreibung

1. Wahrnehmbar

6.2 Wichtige Textausgaben sollten deutlich, von allen Richtungen sichtbar, angezeigt werden.

Auf nächster Seite fortgesetzt

37 4 AR- und VR-Richtlinien

§ Beschreibung

2. Bedienbar

4.1 Die Anwendung sollte Orte verschiedener Größe unterstützen und den Nutzer über den Platzbedarf informieren.

4.2 Sollte die Anwendung auf einem Tisch benutzt werden können, müssen verschiedene Tischgrößen unterstützt werden.

6.1 Es muss nicht notwendig sein, physische Bewegungen im Raum durchzu- führen, um Interaktionen auszulösen.

6.3 Die Anwendung sollte erlauben, virtuelle Objekte näherzubringen – ohne eine Bewegung im Raum zu erfordern.

18.1 Objekte, welche nicht skaliert werden müssen, sollten durch einen Tap platzierbar sein.

23.1 Die Anwendung sollte sowohl 1- als auch 2-Finger-Gesten zur Rotation unterstützen. Die 2-Finger-Geste sollte nur aktiviert werden, wenn der Nutzer die Finger in entgegengesetzte Richtungen bewegt; die 1-Finger- Geste nur, wenn der Swipe außerhalb des Objekts beginnt.

23.3 Die Anwendung sollte das Skalieren von Objekten, beispielsweise durch die Pinch-To-Zoom Geste, unterstützen.

24.2 Die Anwendung sollte ähnliche Gesten vermeiden oder sicherstellen, diese ausreichend zu testen.

24.3 Die Anwendung sollte auch auf Interaktionen reagieren, die nicht direkt auf, sondern knapp neben ein Objekt zielen.

Auf nächster Seite fortgesetzt

38 4 AR- und VR-Richtlinien

§ Beschreibung

31.4 Die Anwendung sollte sowohl Landscape als auch Portrait Ausrichtungen unterstützen.

3. Verständlich

5.1 Die Anwendung sollte Objekte gezielt am Bildschirmrand platzieren, um zu verdeutlichen, dass Nutzer sich im Raum bewegen können, wodurch insbesondere für neue Nutzer unterstützt werden.

5.2 Wenn die Anwendung Bewegungen im Raum erfordert, sind diese all- mählich einzuführen, um den Nutzer nicht zu überfordern.

8.1 Sollte die Anwendung realistische Elemente in der virtuellen Welt platzieren, müssen sich diese glaubhaft und verständlich verhalten, um den Nutzer nicht abzulenken. Beispielsweise können hierzu realistische Schat- ten und Reflexionen benutzt werden.

14.1 Die Anwendung sollte es dem Nutzer anzeigen, wenn eine Oberfläche zu lokalisieren, oder ein Objekt zu platzieren ist und über die erfolgreiche bzw. fehlerhafte Erkennung informieren.

15.1 Die Anwendung sollte bereits erkannte Oberflächen in der Sichtrichtung des Nutzers hervorheben.

15.2 Fehlermeldungen und schrittweise Hinweise zu deren Behebung müssen angezeigt werden.

17.1 Dem Nutzer ist anzuzeigen in welchem Bereich Objekte platziert werden können.

Auf nächster Seite fortgesetzt

39 4 AR- und VR-Richtlinien

§ Beschreibung

17.3 Dem Nutzer ist durch einen visuellen Indikator anzuzeigen, wo ein Ele- ment platziert werden würde.

19.1 Sollte die Anwendung Drag-Gesten verwenden, sind diese dem Nutzer schrittweise zu erklären. Insbesondere ist dem Nutzer vor dem Beginn des Drags zu erklären, wie das Objekt platziert werden kann.

21.1 Die Anwendung sollte interaktive Objekte visuell hervorheben, beispielsweise durch Farben oder Outlines.

22.1 Elemente sollten sich realistisch bewegen – also beispielsweise nicht wäh- rend einer Bewegung verschwinden.

24.1 Dem Nutzer ist anzuzeigen, wie stark Objekte skaliert werden können.

26.1 Wechsel zwischen AR und nicht-AR Teilen der App sind dem Nutzer vorher deutlich anzuzeigen und sollten durch den Nutzer selbst ausgelöst werden.

31.1 Die Anwendung sollte ein Tutorial anbieten, welches wichtige Bedien- konzepte einführt und den Nutzer durch eventuell notwendige Setupauf- gaben führt. Dieses Tutorial sollte in den Fluss der virtuellen Erfahrung eingebunden sein.

31.2 Visuelle Ausgaben sind textuellen Informationen vorzuziehen.

31.3 Soweit möglich, sollte die Anwendung bekannte Gesten wie Pinch-To- Zoom verwenden.

32.1 Die Anwendung sollte dem Nutzer klar verständlich anzeigen, warum welche Permissions notwendig sind, um die App zu verwenden.

Auf nächster Seite fortgesetzt

40 4 AR- und VR-Richtlinien

§ Beschreibung

4. Verschiedenes

5.3 Die Anwendung sollte eine Einführung der verfügbaren Nutzungsweisen – wie sitzend oder stehend – geben sowie einen komfortablen Wechsel zwischen diesen ermöglichen.

5.4 Die Anwendung sollte keine schnellen oder weiten Bewegungen erfordern, um den Nutzer nicht zu gefährden.

7.1 Die Anwendung soll den Nutzer nicht auffordern gefährliche Bewegun- gen – wie Rückwärtslaufen – durchzuführen.

7.2 Die Anwendung muss es erlauben unterbrochen und gestoppt zu werden, um dem Nutzer Pausen zu ermöglichen.

7.3 Die Anwendung sollte verschiedene Positionen des Geräts unterstützen und den Nutzer dazu ermutigen, zwischen diesen zu wechseln, um eine Ermüdung seiner Hände zu verhindern.

7.4 Die Anwendung muss nach einer Pause – auch nach einem Wechsel des physischen Ortes – wieder an derselben Stelle gestartet werden können.

17.2 Die Anwendung sollte verhindern, dass der Nutzer Objekte zu nah bzw. zu fern platziert.

23.2 Automatisch erfolgende Rotationen sind zu vermeiden.

27.1 Die Anwendung sollte den Nutzer durch das Verwenden von Soundeffek- ten dazu ermutigen, die virtuelle Welt zu erkunden.

Auf nächster Seite fortgesetzt

41 4 AR- und VR-Richtlinien

§ Beschreibung

27.2 Die Anwendung sollte auf haptisches Feedback verzichten.7

28.1 Die Anwendung sollte verhindern, dass der Nutzer sich innerhalb von Objekten bewegt und dies, beispielsweise durch Blur-Effekte, verdeutlichen.

29.1 Die Anwendung soll dem Nutzer erlauben die Simulation zurückzuset- zen.

29.2 Soweit möglich, sollte die Anwendung die Präsenz mehrerer Nutzer in einer gemeinsamen Umgebung unterstützen und den Nutzern schrittweise helfen, diese einzurichten.

30.1 UI-Elemente, welche von der immersiven Erfahrung ablenken können, sollen, soweit möglich, vermieden werden.

Tabelle 4.4: Tabellarische Zusammenfassung der Anforderungen der Google Augmented Reality De- sign Guidelines

4.5 Abgeleiteter Kriterienkatalog

Im Folgenden wird ein gemeinsamer Kriterienkatalog aus den betrachteten Richtli- nien abgeleitet und diese damit verglichen. Zusätzlich zu Kriterien, welche aus den Richtlinien abgeleitet sind, werden durch den Autor weitere hinzugefügt, um dem aktuellen Verständnis von Behinderung gerecht zu werden: Behinderung wird nicht

7Dies wird dadurch begründet, dass Vibratoren die Kalibrierung des Geräts durcheinander bringen können. Als Alternative können tieffrequente Sounds abgespielt werden.

42 4 AR- und VR-Richtlinien als intrinsische Eigenschaft einer Person – sondern als Resultat der Wechselwirkung zwischen Menschen und ihrer Umwelt – verstanden (Bundestag, 2008, Präambel e).

§ Kriterium Beschreibung

1. Wahrnehmbar

1.1 Visuelle Wahrnehmbarkeit

1.1.1 Kontraste zu- Verwendete Vor- und Hintergrundfarben müssen einen einander Kontrast von mindestens 4.5:18 aufweisen.

1.1.2 Kontraste zum Ein ausreichender Kontrast zwischen alleinstehenden Hintergrund Elementen – also solchen ohne eigenen Hintergrund – und der realen Welt muss – beispielsweise durch Text- rahmen – sichergestellt werden.

1.1.3 Bedeutung von Die Bedeutung von Elementen darf nicht nur durch Farben Farbunterschiede signalisiert werden.

1.1.4 Schriftgröße Schriften müssen mindestens 16 px im Screenspace groß sein, auch wenn diese im virtuellem Raum platziert sind.

1.1.5 Anpassbarkeit Die Anwendung muss es erlauben, Farben und Kon- traste, Schriften bis zu 200 % Vergrößerung9 sowie das Sichtfeld anzupassen.

1.2 Auditive Wahrnehmbarkeit

Auf nächster Seite fortgesetzt

8vgl. 1.4.3 (W3C, 2008) 9vgl. 1.4.4 (W3C, 2008)

43 4 AR- und VR-Richtlinien

§ Kriterium Beschreibung

1.2.1 Absolute Laut- Die Anwendung muss es erlauben, die absolute Laut- stärke stärke – also das Master Volume – allgemein und für spezifische Geräte wie Kopfhörer – anzupassen.

1.2.2 Relative Laut- Die Anwendung muss erlauben die relative Lautstärke stärke zwischen verschiedenen Quellen – wie Vorder- und Hintergrundgeräuschen – anzupassen.

1.2.3 Dynamikum- Der Dynamikumfang jeder Soundquelle muss einstell- fang bar sein.

1.2.4 Monaurale Die Ausgabe aller Sounds auf einem einzigen Ausgabe- Ausgabe gerät – also in Mono – muss möglich sein.

1.2.5 Ortung Der Ursprung der ausgegebenen Geräusche muss – beispielsweise auch visuell oder taktil – erkennbar sein.

1.2.6 Gebärdenspra- Die Anwendung muss die Ausgabe von Gebärdenspra- che che für voraufgezeichnete auditive und textuelle Inhal- te unterstützen.

1.2.7 Sprachausgabe Die Anwendung muss die Sprachausgabe von UI- Elementen und Texten unterstützen, damit seheinge- schränkte Nutzer diese verwenden können.

1.2.8 Untertitel Die Anwendung muss die Ausgabe von voraufgezeich- neten auditiven Inhalten durch Untertitel erlauben und diese durch den Nutzer anpassbar machen.

1.3 Fokussierbarkeit

Auf nächster Seite fortgesetzt

44 4 AR- und VR-Richtlinien

§ Kriterium Beschreibung

1.3.1 Fokus auf not- Nicht-kritische Elemente, wie Animationen oder Hin- wendiges tergrundgeräusche, müssen deaktivierbar sein, damit Nutzer sich auf das Wichtigste konzentrieren können.

2. Bedienbar

2.1 Eingabe

2.1.1 Mehrere Einga- Die Anwendung muss die Verwendung mehrerer Ein- begeräte gabegeräte gleichzeitig unterstützen.

2.1.2 Einzelnes Ein- Die Anwendung muss die Verwendung eines einzelnen gabegerät Eingabegeräts unterstützen.

2.1.3 Umbelegung Die Anwendung muss erlauben, die Belegung von Ein- gaben und deren Sensitivität zu konfigurieren.

2.1.4 Mobilitäts- Um Interaktionen auszulösen, soll es nicht notwendig unabhängige sein, physische Bewegungen im Raum durchzuführen. Eingaben

2.1.5 Ortsunabhän- Sollte die Anwendung nicht für einen spezifischen Ort gige Nutzung – wie ein bestimmtes Museum – konzipiert sein, muss sie Orte verschiedener Größe unterstützen und den Nutzer über den Platzbedarf informieren.

2.1.6 Feinmotorische Die Anwendung darf keine besonderen feinmotori- Eingaben schen Fähigkeiten, wie die gleichzeitige Eingabe mehrerer Gesten, erfordern. Dazu gehört es auch, ausreichend große Interaktionsziele zu definieren.

Auf nächster Seite fortgesetzt

45 4 AR- und VR-Richtlinien

§ Kriterium Beschreibung

2.1.7 Timing Sollten bestimmte Timings zur Eingabe notwendig sein, muss die Anwendung erlauben diese zu verlängern oder zu deaktivieren.

2.1.8 Spracheingabe Die Anwendung muss per Sprache steuerbar sein, damit seheingeschränkte Nutzer diese verwenden kön- nen.

2.1.9 Umgreifen Persistente Steuerungsfunktionen müssen so positioniert werden, dass das Gerät nicht umgegriffen werden muss, um diese zu nutzen.

2.2 Bildschirmlupen

2.2.1 Bildschirmlu- Die Anwendung muss Bildschirmlupen unterstützen. pen

2.2.2 Fokus zurück- Zur Nutzung von Bildschirmlupen muss ein Reset des setzen Fokus möglich sein.

2.2.3 Kritische Aus- Kritische Ausgaben müssen dem Nutzer mitgeteilt wer- gaben den, ohne den Fokus zu verlieren.

2.3 Reize

2.3.1 Vermeidung Die Anwendung soll Reize vermeiden oder deaktivierbar machen, welche dafür bekannt sind, negative physische Reaktionen – wie epileptische Anfälle oder Be- wegungskrankheit – auszulösen.

Auf nächster Seite fortgesetzt

46 4 AR- und VR-Richtlinien

§ Kriterium Beschreibung

2.3.2 Warnung Sollte es nicht möglich sein, die Reize aus 2.3.1 gänzlich zu vermeiden, ist der Nutzer zu Beginn der Anwen- dung darauf hinzuweisen.

2.4 Barrierefreiheit

2.4.1 Dokumentati- Die von der Anwendung unterstützten Barrierefrei- on heitsoptionen müssen dokumentiert sein.

2.4.2 Selbstständige Die De-/Aktivierung und Konfiguration der unter- Einstellung stützten Barrierefreiheitsoptionen muss selbst barrierefrei gestaltet sein, um Nutzern zu erlauben, diese selbst – also ohne fremde Hilfe – vorzunehmen.

3. Verständlich

3.1 Verständnis der Ausgaben

3.1.1 Sprache Die Anwendung sollte eine klare, nicht technische Sprache verwenden, um mit dem Nutzer zu kommu- nizieren.

3.1.2 Problemlö- Die Anwendung sollte dem Nutzer Vorschläge zum sung und - Lösen und Verhindern von Problemen anzeigen, sodass vermeidung er diese ausführen kann.

3.1.3 Vermeiden von Sollte die Anwendung realistische Elemente in der vir- Ablenkungen tuellen Welt platzieren, müssen sich diese glaubhaft und verständlich verhalten, um den Nutzer nicht abzulenken. Beispielsweise können hierzu realistische Schatten und Reflexionen benutzt werden.

Auf nächster Seite fortgesetzt

47 4 AR- und VR-Richtlinien

§ Kriterium Beschreibung

3.2 Verständnis der Eingaben

3.2.1 Gesten Soweit möglich, sollte die Anwendung bekannte Ges- ten, wie Pinch-To-Zoom, verwenden. Daneben ist eine direkte Manipulation einer indirekten vorzuziehen.

3.2.2 Tutorial Die Anwendung sollte ein Tutorial anbieten, welches wichtige Bedienkonzepte einführt und den Nutzer durch eventuell notwendige Setupaufgaben führt.

3.3 Verständnis des Modus

3.3.1 Mehrere Modi Sollte die Anwendung den Wechsel zwischen AR und nicht-AR erlauben, ist dies dem Nutzer vorher deutlich anzuzeigen.

3.3.2 Wechsel des Im Falle von 3.3.1 soll der Wechsel durch den Nutzer Modus selbst ausgelöst werden und nicht automatisch gesche- hen.

4. Verschiedenes

4.1 Sicherheit

4.1.1 Privatsphäre Anpassungen zur Barrierefreiheit dürfen nicht die Pri- vatsphäre des Nutzers einschränken. Beispielsweise sollte eine Sprachausgabe maskierte Textfelder nicht laut vorlesen.

Auf nächster Seite fortgesetzt

48 4 AR- und VR-Richtlinien

§ Kriterium Beschreibung

4.1.2 Bewegungen Die Anwendung soll den Nutzer nicht auffordern ge- fährliche Bewegungen – wie Rückwärtslaufen – durch- zuführen.

4.2 Komfort

4.2.1 Mehrnutzer- Soweit möglich, sollte die Anwendung die Präsenz umgebungen mehrerer Nutzer in einer gemeinsamen Umgebung un- terstützen, was beispielsweise Kindern mit Autismus- Spektrum-Störung erlaubt, die Umgebung zusammen mit ihren Eltern in einer komfortablen Weise zu erkunden.

4.2.2 Pausen Die Anwendung muss erlauben jederzeit unterbrochen und gestoppt zu werden. Hierzu ist eine Eingabe zu schaffen, welche stets einen sicheren Modus öffnet.

4.2.3 Intensität Die Anwendung soll an regelmäßige Pausen erinnern oder ruhigere Abschnitte vorsehen.

4.3 Emotionale Reize

4.3.1 Vermeidung Inhalte, welche auf bestimmte Nutzer verstörend wir- ken können – wie Drogenkonsum oder Nacktheit – sind zu vermeiden oder sollten deaktivierbar sein10.

Auf nächster Seite fortgesetzt

10Ein aktuelles Beispiel für solche Accessibility Settings ist der Arachnophobia Safe Mode in Groun- ded, in welchem die im Spiel auftauchenden Spinnen in mehreren Stufen weniger spinnenartig eingestellt werden können (Obsidian Entertainment Inc., 2020).

49 4 AR- und VR-Richtlinien

§ Kriterium Beschreibung

4.3.2 Warnung Sollte es nicht möglich sein, die Reize aus 4.3.1 gänzlich zu vermeiden, ist der Nutzer zu Beginn der Anwen- dung darauf hinzuweisen.

4.4 Assistive Technologien

4.4.1 Semantische Elemente der virtuellen Umgebung müssen für assisti- Informationen ve Technologien semantisch beschrieben sein.

Tabelle 4.5: Abgeleiteter Kriterienkatalog zur Barrierefreiheit von AR-Anwendungen

4.6 Vergleich der Richtlinien

Im Allgemeinen lassen sich die in diesem Kapitel betrachteten Richtlinien anhand deren Fokussierung in zwei Kategorien aufteilen.

Accessibility Die XAUR und ETSI EN 301 549 Norm haben den Fokus auf Aspekten der Barrierefreiheit für Nutzer mit „klassischen“ Behinderungen, wie einer Ein- schränkung der Sehfähigkeit. Usability Die AHIG und GARDG haben den Fokus auf allgemeinen Aspekten der Be- nutzbarkeit für alle Nutzer. Als Teil davon werden natürlich auch Aspekte der Barrierefreiheit thematisiert, darüber hinaus werden aber spezifische Nutzbar- keitsgesichtspunkte der AR aufgenommen.

Tabelle 4.6 stellt den abgeleiteten Kriterienkatalog den vier betrachteten Richtlinien gegenüber. Dabei wird für jedes Kriterium die nächste Entsprechung – sofern vor-

50 4 AR- und VR-Richtlinien handen – der jeweiligen Richtlinie angegeben. Nur wenige Kriterien haben Entspre- chungen in drei der Richtlinien; keine in allen vieren.

Kriterium XAUR ETSI EN AHIG GARDG

1.1.1 Kontraste zueinander (6a)11 Via – – WCAG12

1.1.2 Kontraste zum Hinter- – Via – – grund WCAG

1.1.3 Bedeutung von Farben – 4.2.3 – –

1.1.4 Schriftgröße – Via – – WCAG

1.1.5 Anpassbarkeit 6a/13b 4.2.2 – –

1.2.1 Absolute Lautstärke – – – –

1.2.2 Relative Lautstärke – 4.2.5 – –

1.2.3 Dynamikumfang – 4.2.5 – –

1.2.4 Monaurale Ausgabe –13 – – –

1.2.5 Ortung (14a)14 – – –

1.2.6 Gebärdensprache 10a – – –

Auf nächster Seite fortgesetzt

116a fordert nur die Anpassbarkeit von Farben und Kontrasten mit Verweis auf farbenblinde Nutzer – keine expliziten Kontraste. 12Kriterien die durch Referenz auf die WCAG abgedeckt werden. 13Dieses Kriterium soll der Richtlinie hinzugefügt werden (Accessible Platform Architectures Working Group, 2020a). 1414a fordert Umgebungsgeräusche auf andere Geräte ausgeben zu können, wodurch dieses Krite- rium teilweise abgedeckt werden kann.

51 4 AR- und VR-Richtlinien

Kriterium XAUR ETSI EN AHIG GARDG

1.2.7 Sprachausgabe 9a (4.2.1)15 – –

1.2.8 Untertitel 18 Via – – WCAG

1.3.1 Fokus auf notwendiges 3b – – –

2.1.1 Mehrere Eingabegeräte 2c – – –

2.1.2 Einzelnes Eingabegerät 2b – – –

2.1.3 Umbelegung 1b – – –

2.1.4 Mobilitätsunabhängige 2a – – 6.1 Eingaben

2.1.5 Ortsunabhängige Nut- – – 1.8 4.1 zung

2.1.6 Feinmotorische Eingaben 4a, 4b, 4c 4.2.7, 5.5.1 – 24.3

2.1.7 Timing 15b 4.2.10 – –

2.1.8 Spracheingabe 5a – – –

2.1.9 Umgreifen – – 1.7 –

2.2.1 Bildschirmlupen 7a 4.2.2 – –

2.2.2 Fokus zurücksetzen 13a, 7a – – –

2.2.3 Kritische Ausgaben 8a – – –

2.3.1 Vermeidung 16a, 16b 4.2.9 – –

Auf nächster Seite fortgesetzt

154.2.1 fordert einen nicht visuellen Interaktionsmodus – nicht jedoch spezifisch eine Sprachausgabe.

52 4 AR- und VR-Richtlinien

Kriterium XAUR ETSI EN AHIG GARDG

2.3.2 Warnung – – – –

2.4.1 Dokumentation – 12.1.1 – –

2.4.2 Selbstständige Einstel- – 5.2 – – lung

3.1.1 Sprache – – 7.1 –

3.1.2 Problemlösung und - – 4.2.10 9.2 15.2 vermeidung

3.1.3 Vermeiden von Ablen- – – 1.2, 4.7 8.1 kungen

3.2.1 Gesten – – 1.7, 4.2 32.1

3.2.2 Tutorial – – 2.1 31.1

3.3.1 Mehrere Modi – – (11.3)16 26.1

3.3.2 Wechsel des Modus – – – 26.1

4.1.1 Privatsphäre – 4.2.11 – –

4.1.2 Bewegungen – – 1.11 5.4, 7.1

4.2.1 Mehrnutzerumgebungen – – 5.1, 5.2 29.2

4.2.2 Pausen 15d, 11a, – 1.9 7.2 12a

4.2.3 Intensität 15a – 1.10 5.2

Auf nächster Seite fortgesetzt

16Apple schreibt hier die Verwendung spezieller Systemglyphen vor – allerdings nur, wenn die An- wendung Apples ARKit benutzt.

53 4 AR- und VR-Richtlinien

Kriterium XAUR ETSI EN AHIG GARDG

4.3.1 Vermeidung – – – –

4.3.2 Warnung – – – –

4.4.1 Semantische Informatio- 1a 4.2.1 – – nen

Tabelle 4.6: Vergleich abgeleiteter Kriterienkatalog mit betrachteten Richtlinien

54 5 Implementierung

Der erste Abschnitt dieses Kapitels beschreibt die verwendete Hardware, um die entwickelte Anwendung – die den Namen Sukeruton (von jap. スケルトン, wiederum von engl. skeleton) trägt – auszuführen. Der zweite Abschnitt beschreibt die implementierten Ein- und Ausgabeverfahren, wie beispielsweise die Eingabe per Touch. Der dritte Abschnitt beschreibt die entwickelte Benutzeroberfläche und, wie der Nutzer mit dieser interagiert.

5.1 Verwendete Hardware

Zur Evaluierung der entwickelten Anwendung wurde diese mit Probanden auf drei verschiedenen Endgeräten mit unterschiedlichen Ein- und Ausgabegeräten getestet. Als Smartglass kommt die Google Glass (EE1), als Smartwatch die Asus ZenWatch 2 sowie als Smartphone das Google Pixel 4 zum Einsatz.

Die Google Glass ist eine Android-basierte Smartglass. Das erste Modell (Developer Edition) erschien im Frühjahr 2013 und fand geringen Anklang auf dem Markt. Ins- besondere Privatsphäre und ethische Bedenken aufgrund der Möglichkeit, Menschen in der Öffentlichkeit – ohne deren Wissen – aufzunehmen und ein unklares Wert-

55 5 Implementierung versprechen sind Gründe hierfür (Hong, 2013). Nach einer Revision der Developer Edition erschien 2017 ein zweites Modell (Enterprise Edition), welches speziell für die Verwendung in Unternehmen konzipiert und vermarktet wird. Auch diese Editi- on erhielt eine Revision der verwendeten Hardware. Die verwendete ZenWatch 2 ist eine Android-basierte Smartwatch, welche 2015 erschien; das Google Pixel 4 ist ein Android Smartphone, welches 2019 erschien.

Tabelle 5.1 gibt einen Überblick über die Spezifikation der verwendeten Hardware (AsusTeK Computer Inc., n. d.; Google Inc, n. d. a, n. d. b).

Google Glass EE1 Asus ZenWatch 2 Google Pixel 4

Betriebssystem Glass OS1 Wear OS2 Android 10 („Q“)

Prozessor Intel Tangier Qualcomm Qualcomm Snap- 2,1 GHz Dual Snapdragon 400 dragon 855, Core (32 bit) 1,2 GHz Quadcore 1,78 GHz bis 2,84 GHz Octacore

Arbeitsspeicher 2 GB 512 MB 6 GB

Hauptspeicher 16 GB Flash 4 GB eMMC Flash 64 GB UFS Flash

Display LCoS 640×3603 AMOLED OLED 1440×2160 320×320 (1,63 ″) (5,7 ″)

Netzwerk 802.1x Wi-Fi 802.11b/g/n Wi-Fi 802.11a/b/g/n/ac Wi-Fi

Bluetooth 4.0 4.1 5.0

Auf nächster Seite fortgesetzt

1Android 4.4 („KitKat“) basierend 2Android 7 („Nougat“) basierend 3äquivalente Auflösung

56 5 Implementierung

Google Glass EE1 Asus ZenWatch 2 Google Pixel 4

Navigation GPS/GLONASS keine GPS/GLONASS/ BDS/Galileo

Akku 780 mA h 380 mA h 2,8 A h

Kamera 5MP/720p keine 8MP/1080p (Vorderseite) 16MP/4K (Rück- seite)

Gyroskop 3-Achsen 6-Achsen ja

Akzelerometer 3-Achsen 6-Achsen ja

Magnetometer 3-Achsen keines ja

Weitere Sensoren Umgebungslicht, keine Barometer, Barometer4 Umgebungslicht- und Näherungs- sensor, Radar (Motion Sense)

Tabelle 5.1: Tabellarische Übersicht der Spezifikation der verwendeten Hardware

4Weitere Sensoren, die sich nicht über die API ansteuern lassen, sind ein Blinzel- und Zwinkersen- sor sowie Sensoren die erkennen, dass das Gerät aufgeklappt und auf dem Kopf getragen wird.

57 5 Implementierung

5.2 Ein- und Ausgabe

Es stehen verschiedene Ein- und Ausgabeverfahren zur Verfügung, welche im Folgen- den beschrieben werden. Nicht jedes Ein- und Ausgabeverfahren steht auf allen Platt- formen zur Verfügung. Beispielsweise kann nur die Google Glass per Kopfbewegung gesteuert werden. Tabelle 5.2 gibt einen Überblick über die verfügbaren Kombinatio- nen von Ein- und Ausgabeverfahren.

Google Glass Smartwatch Smartphone

Sprachsteuerung via Smartphone Ja Ja

Touch Wischen Wischen Tap

Kopfbewegungen zwei Varianten Nein Nein

Eyetracker zwei Varianten Nein Nein

Tabelle 5.2: Tabellarische Übersicht der verfügbaren Ein- und Ausgabeverfahren

5.2.1 Eingabeverfahren

Als Eingabeverfahren wurden Sprachsteuerung, Touch (je nach verwendetem Gerät direkt per Tap oder indirekt per Wischgesten), Kopfbewegungen (in zwei Varianten) und Eyetrackersteuerung (ebenfalls in zwei Varianten) implementiert. Abbildung 5.1 zeigt, wie welche Komponenten der Anwendung miteinander interagieren.

58 5 Implementierung

Bewegt Sprechen Ist Glass? Touch Kopfbewegung Augen/Blinzelt JA

NEIN

Wort Icon Ignoriert Laut NEIN JA NEIN Ignoriert Klick erkannt? gewählt? r

e JA z t u N

Konvertiert in Konvertiert in Konvertiert in Befehl für Befehl für Befehl für Client Exoskelett Client g n t u n d e n i l e C w n A Führt aus g n r u e d v n r e e w S

n Wort

A Ignoriert Laut NEIN JA erkannt? t t e l e k

s JA o Eingabe

x Ignoriert NEIN E Interaktion erkannt? g n r u e d p n l e e w H Abbildung 5.1: Vereinfachte Darstellung der Interaktion der verschiedenen Komponenten der Anwen- n A

dung. r e k n i c g a r u t l e P y

E Sprachsteuerung

Aus Datenschutzgründen sowie zum Schutz der Privatsphäre wurde eine Offline- Spracherkennung zur Erkennung der Befehle verwendet. Die beiden infrage kommen- den Libraries, die dieses Kriterium erfüllen und unter Android prinzipiell lauffähig sind, sind PocketSphinx und Kaldi. Beide wurden sowohl auf den verwendeten Ge- räten als auch am Desktop durch den Autor evaluiert – wobei die Entscheidung, aufgrund der leichteren Konfigurierbarkeit und besseren Erkennung in Umgebungen mit Hintergrundgeräuschen, auf Kaldi fiel. Aus technischen Gründen wird für die Sprach- steuerung auf der Google Glass eine Helper App verwendet, welche auf einem Smart- phone läuft und die Spracherkennung durchführt. Erkannte Befehle werden dabei per

59 5 Implementierung

Hazelcast an den Client gesendet.

Anstatt eine Grammatik zu definieren, die der Nutzer erst erlernen muss, um die An- wendung zu verwenden, wurde ein einfacheres, auswahlbasiertes System gestaltet, wodurch der Nutzer stets nur zwischen bis zu vier Optionen – in Form der Zahlen Eins bis Vier5 – entscheiden muss und sich dadurch auf seine Ziele fokussieren kann. Ebenfalls erlaubt dies, dasselbe Interface für die Sprachsteuerung zu verwenden, wie es die anderen Eingabemethoden benutzen, indem die Darstellung der Icons durch ein Label mit der entsprechenden Zahl ergänzt wird. Hierdurch wird dem Nutzer ein einfacher Wechsel zwischen den Ein- und Ausgabevarianten ermöglicht. Abbil- dung 5.2 zeigt ein Sequenzdiagramm des Programmablaufs bei diesem Eingabever- fahren.

Helper Anwendung Mobile Anwendung Server (JVM) (Android) (Android)

Nutzer

Loop

[true] Alternative

[If isGlass] <> Eingabe Spricht [Else]

<> Logging

Abbildung 5.2: Sequenzdiagramm des Programmablaufs bei Verwendung von Sprachsteuerung. Im Falle der Google Glass wird eine Helper App verwendet.

5Die Zahl Zwei wird auch in der umgangssprachlichen Variante Zwo erkannt.

60 5 Implementierung

Kopfbewegungen

Die Kopfbewegungssteuerung wird nur auf der Google Glass unterstützt und wurde in zwei Varianten implementiert. Bei beiden Varianten bewegt der Nutzer den Kopf auf bzw. ab (Nickachse, engl. „Pitch“), um Eingaben auf der vertikalen Achse durchzuführen. Zur Auswahl der horizontalen Eingaben kann der Nutzer entweder den Kopf seitlich bewegen (Gierachse, engl. „Yaw“), oder zu seinen Schultern neigen (Rollachse, engl. „Roll“). Abbildung 5.4 zeigt ein Sequenzdiagramm des Programm- ablaufs bei diesem Eingabeverfahren.

Abbildung 5.3: Darstellung der Achsenrotationen (Deldjoo & Atani, 2016, bearbeitet durch den Autor)

Das Gyroskop richtet sich in allen Fällen regelmäßig durch die Nutzung von Magnet- sensor- und Akzelerometerdaten neu aus und verhindert kurz aufeinanderfolgende Eingaben, wodurch Fehleingaben des Nutzers minimiert werden. Listing 5.1 zeigt den implementierten Algorithmus vereinfacht als Pseudocode.

1 algorithm detectDirection is

2 input: Gyroscope values V (angular velocity),

3 secondary axis A # 1=roll, 2=yaw,

4 minimal angular velocity threshold minV,

61 5 Implementierung

5 minimal time between events minT

6 output: Direction? d # Up, Down, Left, Right

7 state: Timestamp of last event t

9 if now() - t < minT return None else t F= now() fi

11 V F= align(V) # realign w.r.t. magnet and accelerometer

12 idx F= index( max( abs( V ) ) )

14 if idx = 0 # pitch axis

15 if V[idx] < -minV

16 return Down

17 elif V[idx] > minV

18 return Up

19 fi

20 elif idx = A # roll or yaw axis

21 if V[idx] < -minV

22 return Right

23 elif V[idx] > minV

24 return Left

25 fi

26 else

27 return None

28 fi

Listing 5.1: Pseudocode des implementierten Gyroskopalgorithmus

62 5 Implementierung

Mobile Anwendung Server (JVM) (Android)

Nutzer

Loop

[true] Bewegt Kopf

<> Logging

Abbildung 5.4: Sequenzdiagramm des Programmablaufs bei Verwendung von Kopfbewegungen.

Eyetrackersteuerung

Die Eyetrackersteuerung verwendet die Open-Source-Eyetrackinglösung Pupil Core von Pupil Labs (Kassner et al., 2014), welche eine MessagePack-basierte6 API zur Ver- fügung stellt, für die auf Basis der Open-Source-Software ZeroMQ7 ein Client implementiert wurde. Es wurden zwei Varianten der Steuerung mit dem Eyetracker implementiert: scanningbasiert und blickbasiert. Abbildung 5.5 zeigt ein Sequenzdiagramm des Programmablaufs bei diesem Eingabeverfahren.

Bei der Steuerung per Scanning wird nacheinander jedes Element der Benutzerober- fläche hervorgehoben und kann durch den Nutzer durch Betätigen eines Schalters (engl. „Switch“) gewählt werden (Colven & Judge, 2006, S. 13). Als Switch dient hierbei ein Blinzeln des Nutzers. Die Erkennung des Blinzeln wird durch die Pupil Core

6vgl. https://msgpack.org/index.html 7vgl. https://github.com/zeromq/jeromq

63 5 Implementierung

Mobile Anwendung Eyetracker (Python) Server (JVM) (Android)

Nutzer

Loop Bewegt Augen [true] <> <> Eingabe Blinzelt <> <> Eingabe

<> Logging

Abbildung 5.5: Sequenzdiagramm des Programmablaufs bei Verwendung von Eyetracking.

Software übernommen, welche dieses durch ein plötzliches Abfallen der Konfidenz der Erkennung erkennt8.

Bei der blickbasierten Steuerung schaut der Nutzer auf das Icon, welches er wählen möchte. Dieses wird dann hervorgehoben und kann durch ein Blinzeln ausgewählt werden. Um das Abbilden der Sensordaten auf die Benutzeroberfläche zu ermögli- chen, wurde ein Plugin für den Eyetracker geschrieben, welches eine Kalibrierung und Verwendung des Eyetrackers ermöglicht. Die Kalibrierung erfolgt, indem der Nutzer nacheinander alle Icons für einen Moment anschaut und währenddessen die erhal- tenen Sensorwerte gemittelt werden. Zusätzlich wird eine mittige Position zwischen allen Icons ermittelt. Neue Sensorwerte werden im Anschluss durch einen Algorith- mus, der in Listing 5.2 vereinfacht dargestellt ist, abgebildet.

1 algorithm detectDirection is

2 input: Eyesensor values V,

3 minimal thresholds T

4 output: Direction? d # Up, Down, Left, Right

8vgl. https://github.com/pupil-labs/pupil/blob/master/pupil_src/shared_modules/blink_ detection.py

64 5 Implementierung

5 state: Calibrated positions P

7 d F= []

8 for p in P

9 # squared Euclidean distance

10 d[p] F= [p, (p[0] - V[0])F*2 + (p[1] - V[1])F*2]

11 rof

13 if min(d)[0] = Center # ignoring center

14 return None

15 elif min(d)[1] F= T[min(d)[0]] # ignoring looking outside of viewport

16 return None

17 else

18 return min(d)[0]

19 fi

Listing 5.2: Pseudocode des implementierten Eyetrackingalgorithmus

Touchsteuerung

Zusätzlich steht auf allen Geräten eine Steuerung per Toucheingabe zur Verfügung, welche in zwei Varianten implementiert wurde. Bei der direkten Variante wählt der Nutzer ein Element durch Tap auf dieses. Da eine direkte Toucheingabe auf der Goog- le Glass nicht möglich und das Display der Smartwatch hierfür zu klein ist, wurde auf diesen Geräten eine indirekte Variante implementiert. Bei dieser wischt der Nutzer in Richtung des zu wählenden Elements auf dem Display der Smartwatch

65 5 Implementierung bzw. dem Touchfeld der Google Glass. Abbildung 5.6 zeigt ein Sequenzdiagramm des Programmablaufs bei diesem Eingabeverfahren.

Mobile Anwendung Server (JVM) (Android)

Nutzer

Loop

[true] Touch/Swipe

<> Logging

Abbildung 5.6: Sequenzdiagramm des Programmablaufs bei Verwendung von Toucheingabe.

Auf dem Smartphone und der Smartglass wird die Toucherkennung des Android SDKs bzw. GDKs benutzt. Auf der Smartwatch wird die zur Erkennung von Swipes optimierte OpenSource-Library swipe9 von Piotr Wittchen in der imperativen Varian- te verwendet – die RxJava-basierte Variante wird also nicht verwendet.

5.3 Benutzeroberfläche

Im Folgenden wird die im Rahmen dieser Arbeit entwickelte Benutzeroberfläche beschrieben und, wie diese durch den Nutzer angepasst werden kann.

9vgl. https://github.com/pwittchen/swipe

66 5 Implementierung

Es wird angenommen, dass der Nutzer die Anwendung anfangs zum Erlernen der Hand-Exoskelett-Verwendung nutzt, später nur noch als passive Unterstützung. Da- her wurde die Benutzeroberfläche bewusst einfach gehalten und die Hauptbedienele- mente als Icons dargestellt. Zusätzlich kann dem Nutzer am unteren Bildschirmrand ein kurzer textueller Hinweis zum aktuellen Status des Systems angezeigt werden. Die zu einem Zeitpunkt sichtbaren UI-Elemente werden als Screen bezeichnet und im Folgenden beschrieben.

Nachdem der Nutzer die Anwendung öffnet, wird ihm eine Ladeanimation angezeigt, während das Hand-Exoskelett gesucht und die Anwendung selbst initialisiert wird. Anschließend wird der Nutzer über das Ergebnis des Ladevorgangs informiert – entweder durch einen grünen Haken oder ein rotes Kreuz mit weiteren textuellen Infor- mationen, was das Problem verursachte.

Konnte die Anwendung erfolgreich laden, wird der Nutzer durch ein Handicon aufgefordert sich dem gewünschten Objekt zu nähern. Die ungefähre Distanz zum Objekt wird durch ein zunächst ausgegrautes, später durch ein farbiges Objekt, signalisiert.

Im Anschluss wird der Nutzer aufgefordert, den zu greifenden Objekttyp zu wählen. Hierbei hat er die Auswahl aus dünnen Objekten (wie einer Kreditkarte) und runden (wie einer Kaffeetasse). Nach der erfolgten Auswahl wird dem Nutzer ein Screen zur Bestätigung angezeigt – dieser kann durch erfahrenere Nutzer deaktiviert werden, um ein schnelleres Arbeiten zu ermöglichen.

Nun kann das Hand-Exoskelett schließen, was dem Nutzer durch eine Animation einer schließenden Hand angezeigt wird. Sollte es beim Schließen des Hand-Exoskeletts zu einem Fehler kommen, wird auch dies dem Nutzer angezeigt. In beiden Fällen kann der Nutzer entscheiden, ob er noch ein weiteres Objekt greifen möchte, wodurch die

67 5 Implementierung

Hand geöffnet und die Anwendung zurückgesetzt wird – oder, ob er die Anwendung schließen möchte.

5.3.1 Konfiguration der Anwendung

Die entwickelte Anwendung kann über eine JSON-basierte Konfigurationsdatei eingestellt werden, für welche ein JSON-Schema definiert wurde. Dabei sind alle verwendeten Farben (aus technischen Gründen begrenzt auf eine Menge an definierten Far- ben), Timings und die Grenzwerte (in Listing 5.2 als ‘minV‘ bezeichnet) einstellbar. Daneben kann die verwendete Hazelcast Instanz eingestellt werden. Um eine einfache Erweiterbarkeit zu ermöglichen, können auch die angefragten Android Permissions eingestellt werden. Listing 5.3 zeigt einen Auszug der Konfigurationsdatei.

1 {

2 "timings": {

3 "delayBetweenScreens": 500,

4 "gestureDelay": 500,

5 "scanningDelay": 1000

6 },

7 "head": {

8 "stateTimeout": 1500000000,

9 "minMoveAngularVelocity": 1.0

10 }

11 }

Listing 5.3: Auszug der Konfigurationsdatei

68 6 Evaluation

Im Rahmen einer Benutzerstudie mit Studenten der Hochschule der Medien und Be- kannten des Autors wurde evaluiert, welche Eingabeverfahren auf welchen Ausga- begeräten am effektivsten zu benutzen sind. Im Folgenden wird zunächst die hierfür durchgeführte Studie beschrieben und dann deren Ergebnisse ausgewertet.

6.1 Studiendesign

Jeder Test wurde in zwei Teilen durchgeführt: Im ersten Teil wurden die Interaktio- nen der Probanden mit der Anwendung gemessen. Anschließend wurde eine durch Erhebung der Nutzer durchgeführt, in welcher die getesteten Kombinationen in eine subjektive Rangfolge gebracht werden sollten. Daneben wurden demografische Daten der Teilnehmer, wie Geburtsjahr und Geschlecht sowie Informationen zu eventuell vorhandenen Einschränkungen, wie beispielsweise dem Tragen einer Brille, erhoben. Abbildung 6.1 stellt den zeitlichen Verlauf eines einzelnen Experiments dar.

69 6 Evaluation

Händewaschen und Begrüßung

Aufklärung über Testdurchlauf: Testdurchlauf: Erhebung demografischer Daten des Ende des Experiments Ziele des Ex- Erste IOC Letzte IOC Probanden periments Verabschiedung des Probanden Messung: Erste Messung: Subjektive Ordnung der getesteten IOC Einholen von IOC Letzte IOC Einverständnis

Ankunft I1O1 ... I2O3 Survey Ende

Abbildung 6.1: Schematische Darstellung des experimentellen Verlaufs je Proband

6.1.1 Input-Output-Combinations (IOCs)

Mit jedem Studienteilnehmer wurden zehn verschiedene Kombinationen aus Einga- beverfahren und Ausgabegeräten evaluiert. Eine solche Kombination wird in diesem Kapitel als Input-Output-Combination (IOC) bezeichnet. Die getesteten IOCs sind: Touch und Sprachsteuerung (jeweils mit Smartphone, Smartwatch und Google Glass) sowie zwei Arten der Kopfbewegungen und des Eyetrackers mit der Google Glass, welche in Abschnitt 5.2 (Ein- und Ausgabe) näher beschrieben sind. Tabelle 6.1 gibt einen Überblick über die getesteten IOCs und deren Bezeichnung in diesem Kapitel.

Google Glass Smartwatch Smartphone

Touch Direkt n/a n/a I2O2

Indirekt I6O5 I2O1 n/a

Sprachsteuerung Deutsch I7O5 I7O1 I7O2

Kopfbewegungen Gierachse I8AO5 n/a n/a

Rollachse I8BO5 n/a n/a

Eyetracking Mapped I9AO5 n/a n/a

Auf nächster Seite fortgesetzt

70 6 Evaluation

Google Glass Smartwatch Smartphone

Scanning I9CO5 n/a n/a

Tabelle 6.1: Tabellarische Übersicht der IOCs

Die Probanden verwendeten alle IOCs in unterschiedlichen und durch ein lateinisches Quadrat definierten Reihenfolgen, welche in Tabelle 6.2 dargestellt werden.

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10

#1 I9AO5 I2O1 I7O2 I8BO5 I9CO5 I8AO5 I7O1 I6O5 I7O5 I2O2

#2 I7O1 I9AO5 I2O1 I7O5 I7O2 I9CO5 I6O5 I8BO5 I2O2 I8AO5

#3 I2O1 I7O2 I9CO5 I6O5 I8AO5 I2O2 I9AO5 I7O1 I8BO5 I7O5

#4 I7O2 I9CO5 I8AO5 I7O1 I2O2 I7O5 I2O1 I9AO5 I6O5 I8BO5

#5 I2O2 I7O5 I8BO5 I7O2 I6O5 I7O1 I8AO5 I9CO5 I2O1 I9AO5

#6 I7O5 I8BO5 I6O5 I9CO5 I7O1 I9AO5 I2O2 I8AO5 I7O2 I2O1

#7 I8BO5 I6O5 I7O1 I8AO5 I9AO5 I2O1 I7O5 I2O2 I9CO5 I7O2

#8 I9CO5 I8AO5 I2O2 I9AO5 I7O5 I8BO5 I7O2 I2O1 I7O1 I6O5

#9 I6O5 I7O1 I9AO5 I2O2 I2O1 I7O2 I8BO5 I7O5 I8AO5 I9CO5

#10 I8AO5 I2O2 I7O5 I2O1 I8BO5 I6O5 I9CO5 I7O2 I9AO5 I7O1

Tabelle 6.2: Tabellarische Übersicht der IOC Reihenfolgen

71 6 Evaluation

6.1.2 Icon-Position-Combinations (IPCs)

Jede IOC wurde jeweils mit fünf verschiedenen Icon Positionen getestet, welche in diesem Kapitel als Icon-Position-Combination (IPC) bezeichnet werden. Es wurden Kombinationen mit zwei, drei und vier Icons in verschiedenen Anordnungen getestet, welche im Folgenden dargestellt werden. Es war stets genau ein Icon als korrekt durch ein Smileysymbol, die restlichen Icons als falsch durch ein Kreuzsymbol markiert.

In jedem Durchlauf wurden dem Nutzer zwölf Screens jeder IPC angezeigt, auf denen das korrekte Icon gleichverteilt zufällig positioniert ist. Um zu verhindern, dass der Nutzer die Position der letzten Icons erraten konnte, wurden zwei weitere an zufälliger Stelle hinzugefügt, welche nicht gemessen wurden. Jeder Proband testete jede IPC zweimal nacheinander, wobei der erste Durchlauf zum Erlernen der Steuerung diente und nicht gemessen wurde. Tabelle 6.3 zeigt eine Übersicht der getesteten IPCs.

Variante Bezeichnung

Horizontal IPC2a 2 Icons Vertikal IPC2b

Dreieck IPC3a 3 Icons Umgedrehtes Dreieck IPC3b

4 Icons Rhombus IPC4

Tabelle 6.3: Tabellarische Übersicht der IPCs

72 6 Evaluation

Übersicht der IPCs

Es wurden zwei IPCs mit je zwei Icons getestet. Abbildung 6.2a zeigt das horizontale Layout, bei welchem die Icons links bzw. rechts positioniert wurden. Abbildung 6.2b zeigt das vertikale Layout, bei welchem die Icons oben bzw. unten positioniert wurden.

(a) Horizontal (IPC2a) (b) Vertikal (IPC2b)

Abbildung 6.2: Übersicht der getesteten Zweier-IPCs

Es wurden zwei IPCs mit je drei Icons getestet. Abbildung 6.3a zeigt das Dreieckslay- out, bei welchem die Icons in einem Dreieck mit Hypotenuse unten positioniert wurden. Abbildung 6.3b zeigt das umgedrehte Dreieckslayout, bei welchem die Icons in einem Dreieck mit Hypotenuse oben positioniert wurden.

(a) Dreieck (IPC3a) (b) Umgedrehtes Dreieck (IPC3b)

Abbildung 6.3: Übersicht der getesteten Dreier-IPCs

Es wurde eine IPC mit vier Icons getestet. Abbildung 6.4 zeigt das Viereckslayout, bei

73 6 Evaluation welchem die Icons in einem Rhombus positioniert wurden.

Abbildung 6.4: Übersicht der getesteten Vierer-IPC (IPC4)

Die Probanden wurden in zwei Gruppen eingeteilt, welche sich dadurch unterschieden, welche der Zweier- bzw. Dreier-IPCs zuerst angezeigt wurden. Probanden der ersten Gruppe wurde zuerst die horizontale bzw. normale; Probanden der zweiten zuerst die vertikale bzw. umgedrehte IPC angezeigt. Tabelle 6.4 zeigt eine Übersicht der beiden Reihenfolgen.

IPC 1 IPC 2 IPC 3 IPC 4 IPC 5

Proband A IPC2a IPC2b IPC3a IPC3b IPC4

Proband B IPC2b IPC2a IPC3b IPC3a IPC4

Tabelle 6.4: Tabellarische Übersicht der IPC Reihenfolgen

6.1.3 Experimenteller Aufbau

Der experimentelle Aufbau bestand aus mehreren Komponenten, welche im Folgen- den beschrieben werden.

Kern des Aufbaus sind die mobilen Anwendungen, welche eine Benutzeroberfläche

74 6 Evaluation auf den drei getesteten Ausgabegeräten anzeigen. Entsprechend der jeweiligen IOC verarbeiten diese die Daten des Gyroskops, Beschleunigungs- und Magnetfeldsen- sors; des Touchscreens oder des Mikrofons, welche zu Eingabebefehlen übersetzt und an Hazelcast gesendet werden, wo diese zum Update der Benutzeroberfläche verwendet werden. Des Weiteren senden die mobilen Anwendungen Trackingdaten, in Form von Timestamps, für jedes experimentell relevante Ereignis.

Daten des Eyetrackers werden durch ein von dem Autor für die Pupil Software ge- schriebenes Plugin verarbeitet und aus Performancegründen durch eine Desktopan- wendung zu Eingabebefehlen übersetzt, welche über Hazelcast an die mobile Anwen- dung gesendet werden. Daneben loggt diese Anwendung die anfallenden Tracking- daten und stellt eine Konfigurationsschnittstelle für den Experimentator bereit, mit welcher jener beispielsweise die verwendete IOC konfigurieren kann.

Die Hazelcast Schnittstelle zum eigentlichen Hand-Exoskelett wurde im Rahmen dieser Studie nicht verwendet. Abbildung 6.5 zeigt den experimentellen Aufbau.

Exoskeleton

«device» Control Server Sends inputs/configs «component» Hazelcast Member Updates tracking/commands/inputs Updates inputs/configs

Sends tracking data

«device» Configures Application Server

«component» «component» «device» GUI Hazelcast Experimentor Client Mobile Application

«device» Moves head (Glass) «component» «component» Eyetracker «component» «component» Gyroscope GUI Receiver Logger «component» Sends eyetracker data IPC Backbone «component» Hazelcast Client Blinks

«component» Experimentee Touches device «component» PupilPlugin «device» Touch Voice Helper Moves eyes Speaks (Glass) «component» «component» Voice Speaks (other devices) Voice

Experimentee

Abbildung 6.5: Schematische Darstellung des experimentellen Aufbaus

75 6 Evaluation

6.1.4 Fragebogen

Im Anschluss an die durchgeführten Tests wurde von jedem Teilnehmer ein Fragebo- gen ausgefüllt. Dabei wurden die folgenden Fragen in der gleichen Reihenfolge gestellt.

Alter Angabe des Geburtsjahres. Geschlecht Angabe des Geschlechts. Einschränkungen Angabe von relevanten körperlichen Einschränkungen des Teilneh- mers, wie das Tragen einer Brille. Probandencode Aus persönlichen Daten pseudonym generiert, um die Ergebnisse in einer eventuellen Folgestudie den Probanden wieder zuordnen zu können. Präferenz Sortierung der getesteten IOC in eine subjektive Reihenfolge.

6.1.5 Schutzmaßnahmen und Sicherheit der Teilnehmer

Im Folgenden werden die potenziellen Gefährdungen der Teilnehmer beschrieben und welche Vorkehrungen getroffenen wurden, diese zu mitigieren. Ein besonderes Augenmerk lag auf Vorkehrungen zum Infektionsschutz begründet durch die SARS- CoV-2 Pandemie.

SARS-CoV-2 Maßnahmen

Zum Schutz aller Teilnehmer, des Autors und der Gesellschaft wurden verschiedene Maßnahmen ergriffen, um eine Verbreitung des SARS-CoV-2 Virus zu verhindern

76 6 Evaluation sowie gegebenenfalls nachvollziehen zu können. Diese Vorkehrungen wurden im Ein- klang mit dem Hygienekonzept der Hochschule der Medien getroffen (Hochschule der Medien, 2020) und durch den betreuenden Professor genehmigt.

Mund-Nasen-Bedeckung Alle Teilnehmer und der Autor trugen während des gesam- ten Aufenthalts im Labor eine Mund-Nasen-Bedeckung. Abstand Soweit möglich wird ein Mindestabstand von 1,5 m zwischen den Personen im Labor eingehalten. Desinfektion Alle verwendeten Geräte und Oberflächen wurden vor und nach allen Teilnehmern gründlich desinfiziert. Weiterhin desinfizierten sich die Teilnehmer vor dem Test die Hände. Durchlüftung Für einen ständigen Durchzug frischer Luft wurde durch ständige Öff- nung der Fenster gesorgt. Ausschluss Teilnehmer, welche angaben, Krankheitssymptome zu zeigen oder mit einer an SARS-CoV-2 infizierten Person innerhalb der letzten beiden Wochen Kon- takt gehabt zu haben, wurden von der Teilnahme ausgeschlossen. Nachverfolgung Um ein eventuelles Infektionsgeschehen nachvollziehen zu können, wurde eine Teilnehmerliste geführt. Des Weiteren verpflichteten sich alle Teil- nehmer eine Infektion innerhalb von zwei Wochen nach dem Test sofort mitzu- teilen.

Sonstige Risikobewertung

Im Allgemeinen waren die Beteiligten keiner besonderen physischen Gefahr ausgesetzt, da lediglich alltägliche Smartdevices gesteuert werden sollten. Allen Teilneh- mern wurde zu jeder Zeit ermöglicht die Untersuchung – beispielsweise aufgrund einer psychischen Belastung – ohne Angabe von Gründen zu pausieren oder abzu-

77 6 Evaluation brechen.

Ein verantwortungsvoller Umgang mit den persönlichen Daten der Teilnehmer wurde praktiziert. Die erhobenen Daten (Demografische Daten, subjektive Bewertungen und gesundheitliche Angaben) werden gesichert aufbewahrt und nur für die Zwecke der Studie verwendet. Aufgezeichnetes Bild- und Tonmaterial, das für die Benutzung der Sprach- und Eyetrackersteuerung erzeugt wurde, wurde bereits während jedes Tests vernichtet.

6.2 Teilnehmer

Teilnehmer der Studie waren zwanzig Personen: Studenten der Hochschule der Me- dien, welche in den Studiengängen Medieninformatik (B.Sc. und M.Sc.), Mobile Me- dien (B.Sc.) sowie Audiovisuelle Medien (B.Sc.) eingeschrieben sind und Bekannte des Autors. Von den Teilnehmern (Alter M = 31,1; SD = 13,31) waren zehn männlich, zehn weiblich und keine divers.

6.3 Datenverarbeitung

Die Verarbeitung der gemessenen Daten erfolgte in drei Schritten, welche im Folgen- den beschrieben werden. Der erste Schritt wurde manuell durchgeführt und bestand daraus, die entstandene Logdatei jedes Probanden in die zehn getesteten IOCs zu tren- nen. Dabei wurden auch die ersten Messungen jedes Probanden je IOC entfernt, da diese für die Auswertung nicht betrachtet werden. Listing 6.1 zeigt ausschnittsweise

78 6 Evaluation

den Zustand der Rohdaten nach diesem Schritt.

1 FF# Start experiment FF#

2 Time: 1595500787570

3 Data: {"device" : "Phone", "input" : "Touch", "screens" : [FF. ], "subject" : "Subject A"}

4 sukerutonF:trackingF:show,1595500789638: Showing screen 0/14 ignored

5 sukerutonF:trackingF:correctClick,1595500790930: No description given.

6 sukerutonF:trackingF:hide,1595500791578: No description given.

7 sukerutonF:trackingF:show,1595500791688: Showing screen 1/14

8 sukerutonF:trackingF:wrongClick,1595500792772: No description given.

9 FF.

10 sukerutonF:trackingF:newLayout,1595500901171: Showing layout 5/5.

11 sukerutonF:trackingF:done,1595500901178: Experiment was finished.

Listing 6.1: Auschnitt der Rohdaten einer einzelnen IOC. In diesem Fall wurde I2O2 von einem Probanden der ersten Gruppe getestet. Die IPCs werden in einem Array gespeichert und sind hier nicht dargestellt. Gemessene Daten werden als Key-Value-Paare mit darauffolgendem Kommentar gespeichert.

Im nächsten Schritt wurden die entstandenen Logs geparst und als eine einzelne CSV- Datei pro Proband gespeichert. Hierbei wurden auch als ignoriert markierte IPC Mes- sungen verworfen. Jede CSV-Datei enthält somit 600 Einträge: zwölf je getesteter IPC für alle zehn IOCs. Darüberhinaus wurden die Zeitstempel der Nutzerinteraktionen relativ zum Zeitpunkt des Zeigens der jeweiligen Messung gespeichert. Listing 6.2

79 6 Evaluation

zeigt ausschnittsweise den Zustand der Daten nach diesem Schritt.

1 proband, device, input, layout, screen_number, clicks

2 BAHAIG30, Glass, Scanning, DoubleHorizontal, 0, 1738

3 BAHAIG30, Glass, Scanning, DoubleHorizontal, 1, 736

4 BAHAIG30, Glass, Scanning, DoubleHorizontal, 2, 468

5 BAHAIG30, Glass, Scanning, DoubleHorizontal, 3, 538

6 BAHAIG30, Glass, Scanning, DoubleHorizontal, 4, 599;2078

7 FF.

Listing 6.2: Auschnitt der verarbeiteten Daten eines einzelnen Probanden. Hier sind fünf Messungen der IPC2a mit I9CO5 zu sehen. Die fünfte Messung zeigt einen Eingabefehler des Nutzers, welcher durch die zwei erfolgten Klicks ersichtlich ist.

Im letzten Schritt der Verarbeitung wurden weitere Informationen aus den erhalte- nen Daten abgeleitet, welche in Abschnitt 6.4 (Ergebnisse) dargestellt werden. Dazu gehörte unter anderem die Bestimmung der Bandbreite für jede IOC und IPC.

6.4 Ergebnisse

Alle Werte wurden für die Darstellung in diesem Dokument auf zwei Nachkomma- stellen gerundet.

80 6 Evaluation

6.4.1 Vergleich der IPCs

Insgesamt konnte kein signifikanter Unterschied zwischen den IPC-Varianten mit jeweils gleicher Anzahl an Icons festgestellt werden. Tabelle 6.5 zeigt eine Übersicht der gemessenen Daten für die getesteten IPCs.

Fehleingaben Benötigte Zeit Bandbreite M SD M SD M SD

IPC2a 54,95 257,7 1,60 0,90 1,61 0,80

IPC2b 61,54 312,5 1,65 0,93 1,55 0,74

IPC3a 73,37 290,5 1,60 0,81 2,40 1,09

IPC3b 52,06 237,9 1,61 0,85 2,36 1,13

IPC4 83,26 333,5 1,63 0,89 3,15 1,49

Tabelle 6.5: Tabellarische Übersicht der Fehleingaben [‰], benötigten Zeit zur Eingabe [s] und der Bandbreite [bit/s] für die getesteten IOCs.

Abbildung 6.6 zeigt die gemachten Fehleingaben [‰] mit den unterschiedlichen IPCs. Hierbei konnte zwischen IPC2a und IPC2b kein signifikanter Unterschied festgestellt werden (t = 0,54; p = 0,59); ebenso konnte zwischen IPC3a und IPC3b kein signifikanter Unterschied festgestellt werden (t = 1,89; p = 0,06).

Abbildung 6.7 zeigt die benötigte Zeit zur Eingabe [s] mit den unterschiedlichen IPCs. Hierbei konnte zwischen IPC2a und IPC2b kein signifikanter Unterschied festgestellt werden (t = 1,38; p = 0,17); ebenso konnte zwischen IPC3a und IPC3b kein signifikanter Unterschied festgestellt werden (t = 1,49; p = 0,14).

81 6 Evaluation

IPC2a

IPC2b

IPC3a

IPC3b

IPC4

0 0.5 1 1.5 2 2.5 3

Abbildung 6.6: Anzahl der gemachten Fehleingaben im Vergleich der getesteten IPCs.

Abbildung 6.8 zeigt die erreichte Bandbreite [bit/s] mit den unterschiedlichen IPCs. Hierbei konnte zwischen IPC2a und IPC2b kein signifikanter Unterschied festgestellt werden (t = 1,91; p = 0,06); ebenso konnte zwischen IPC3a und IPC3b kein signifikanter Unterschied festgestellt werden (t = 0,78; p = 0,44).

6.4.2 Vergleich der IOCs

Insgesamt konnte ein signifikanter Unterschied zwischen den IOC-Varianten festgestellt werden. Tabelle 6.6 zeigt eine Übersicht der gemessenen Daten für die getesteten IOCs.

82 6 Evaluation

IPC2a

IPC2b

IPC3a

IPC3b

IPC4

1000 2000 3000 4000 5000 6000

Abbildung 6.7: Benötigte Zeit zur Eingabe [ms] im Vergleich der getesteten IPCs.

Fehleingaben Benötigte Zeit Bandbreite M SD M SD M SD

I2O2 4,18 64,55 0,74 1,84 3,94 1,37

I6O5 26,32 170,83 1,29 0,73 2,54 1,04

I2O1 3,38 58,07 1,16 0,65 2,86 1,22

I7O5 36,33 187,29 2,04 0,72 1,54 0,80

I7O1 23,38 151,25 1,99 0,71 1,57 0,68

I702 32,91 188,53 1,91 0,59 1,60 0,70

I8AO5 98,59 367,26 1,58 0,92 2,19 1,00

I8BO5 46,18 234,10 1,41 0,74 2,30 0,95

Auf nächster Seite fortgesetzt

83 6 Evaluation

Fehleingaben Benötigte Zeit Bandbreite M SD M SD M SD

I9AO5 216,17 528,10 1,93 1,10 1,89 1,04

I9CO5 152,06 419,24 2,00 0,98 1,85 1,26

Tabelle 6.6: Tabellarische Übersicht der Fehleingaben [‰], benötigten Zeit zur Eingabe [s] und der Bandbreite [bit/s] für die getesteten IOCs.

Die höchsten Bandbreiten konnten durch die Verwendung von Touch auf dem Smart- phone erreicht werden, gefolgt von Touch auf der Smartwatch und Glass. Die Band- breite bei der Verwendung von Kopfbewegungen ist die nächsthöchste. Hierbei konnte zwischen I8AO5 und I8BO5 ein signifikanter Unterschied festgestellt werden (t = -2,03; p = 0,04). Die Eyetrackereingabe mit Mapped lag etwas vor Scanning. Die ge- ringsten Bandbreiten erreichten die Sprachsteuerungen auf Smartphone, Smartwatch und Smartglass. Abbildung 6.9 zeigt eine Übersicht der gemessenen Daten für die getesteten IPCs.

6.4.3 Subjektive Bewertung durch die Probanden

Im Anschluss an die gemessenen Versuche brachten die Probanden die getesteten IOCs in eine subjektive Rangfolge von 1 (beste Bewertung) bis 10 (schlechteste Be- wertung).

Subjektiv bevorzugten die Probanden die Eingabe per Touch auf dem Smartphone, gefolgt von Touch auf der Smartwatch und Glass. Diese Beurteilung stimmt mit den

84 6 Evaluation

IPC2a

IPC2b

IPC3a

IPC3b

IPC4

0 2 4 6 8

Abbildung 6.8: Erreichte Bandbreite [bit/s] im Vergleich der getesteten IPCs. jeweils erreichten Bandbreiten überein. Im Gegensatz zu der gemessenen Bandbreite wurden die Sprachsteuerungen als zweitbestes bewertet, gefolgt von Kopfbewegun- gen und Eyetracking. Abbildung 6.10 zeigt die subjektive Beurteilung der unterschiedlichen IOCs.

85 6 Evaluation

Gierachse Head Rollachse

Mapped Eyes Scanning

Glass

Voice Watch

Phone

Glass

Touch Watch

Phone

0 2 4 6 8

Abbildung 6.9: Erreichte Bandbreite [bit/s] im Vergleich der getesteten IOCs.

Gierachse Head Rollachse

Mapped Eyes Scanning

Glass

Voice Watch

Phone

Glass

Touch Watch

Phone

2 4 6 8 10

Abbildung 6.10: Subjektive Beurteilung im Vergleich der getesteten IOCs. In dieser Darstellung ist ein höherer Wert besser.

86 7 Zusammenfassung und Ausblick

Die Erkenntnisse dieser Arbeit teilen sich in zwei Bereiche auf. Zum einen wurde ein gemeinsamer Kriterienkatalog aus aktuellen Richtlinien zur barrierefreien Implemen- tierung von Augmented-Reality-Anwendungen abgeleitet, zum anderen eine Steue- rung für ein rehabilitatives Hand-Exoskelett entwickelt und evaluiert.

Der Vergleich der Richtlinien zur barrierefreien Implementierung von AR-Anwen- dungen zeigte, dass es insgesamt noch wenige umfassende Richtlinien in diesem Be- reich gibt. Zwar veröffentlichen die Hersteller beider kommerziell-relevanter mobiler Betriebssysteme (iOS/Android) Richtlinien zur Implementierung von AR-Anwen- dungen (Apple Human Interface Guidelines/Google Augmented Reality Design Gui- delines), allerdings haben jene keinen Fokus auf Barrierefreiheit. Die Richtlinien der ETSI nehmen keinen Bezug auf AR im Speziellen, wenngleich sie im Allgemeinen auch auf die AR anwendbar sind. Die letzte betrachtete Richtlinie, die XR Accessibili- ty User Requirements, nimmt explizit Bezug auf AR und Barrierefreiheit, deckt aber mehrere sinnvolle Gesichtspunkte der anderen Richtlinien nicht ab.

Es ist bereits absehbar, dass die XAUR in naher Zukunft um einige der fehlenden Kriterien erweitert wird (Accessible Platform Architectures Working Group, 2020a). Infolgedessen sollte die XAUR zu diesem Zeitpunkt erneut betrachtet werden.

87 7 Zusammenfassung und Ausblick

Daneben wurde im Rahmen dieser Arbeit eine Steuerung für ein Hand-Exoskelett konzipiert und für mobile Geräte als native Anwendung implementiert. Mit Hilfe eines Hand-Exoskeletts können Mediziner zumindest einen Teil der Handfunktion von beispielsweise Schlaganfallpatienten wiederherstellen (Schabowsky et al., 2010). Die betroffenen Menschen können hierdurch eine gewisse Autonomie und Lebensqualität zurückgewinnen (Bakula et al., 2011).

Wie diese Arbeit in einer vorläufigen Studie zeigen konnte, eignet sich für die Steue- rung eines Hand-Exoskeletts vor allem die Eingabe via Touch, wobei hier ein Smart- phone und eine Smartwatch gegenüber einer Smartglass etwas bevorzugt wurden. Daneben konnte gezeigt werden, dass die Spracheingabe auf einem Smartphone eher akzeptiert wurde als auf Smartwatch und Smartglass – wobei hier technische Limitie- rungen gegenwärtiger mobiler Geräte womöglich das Ergebnis beeinflusst haben. Die Eingabe per Kopfbewegungen wurde von den getesteten Probanden abgelehnt – wobei hier die Nutzung der Rollachse etwas beliebter war als die Gierachse. Kein klares Ergebnis konnte für die Eingabe per Eyetracking gefunden werden, welche etwa wie die Eingabe per Kopfbewegung bewertet wurde.

Im nächsten Schritt sollten diese Versuche daher zunächst mit weiteren Testpersonen wiederholt werden, um die vorläufigen Erkenntnisse festigen zu können. Insbesonde- re ist es wichtig zu untersuchen, ob und für welche Personengruppen die Steuerung per Eyetracking in Frage kommt. Ebenfalls sollte die Anwendung danach zusammen mit dem Hand-Exoskelett in einem realitätsnäheren Kontext mit tatsächlich betroffenen Personen getestet werden, um die entwickelte Steuerung einordnen zu können. Es könnte sich beispielsweise herausstellen, dass betroffene Personen die Eingabe per Touch weniger gut befinden, da durch die solche beide Hände blockiert würden – die eine durch das Hand-Exoskelett, die andere durch die Eingabe. Es ist zumindest denkbar, dass sich in dieser Gruppe die Eingabe per Sprachsteuerung gegenüber der

88 7 Zusammenfassung und Ausblick

Touchsteuerung bewährt.

89 Acknowledgements

Ich möchte Herrn Prof. Dr. Gottfried Zimmermann und Herrn Tobias Ableitner, M. Sc. für die Betreuung und ihr wertvolles Feedback während meiner Master Thesis danken.

Meiner Hochschule und meinen Betreuern gilt besonderer Dank für ihren verantwor- tungsvollen Umgang mit der SARS-CoV-2 Pandemie und dem Ermöglichen einer Ver- schiebung meiner Studie im Interesse der Gesellschaft.

Daneben möchte ich allen Teilnehmern der Studie für ihre Unterstützung danken.

Weiterer Dank gilt Herrn Dipl.-Ing. Patrick Münster für die Erstellung der Eyetracker- Halterung für die Google Glass. Anhang

I Anhang

Dateiverzeichnis

Auf der beigefügten digitalen Abgabe finden sich die folgenden Dateien:

/ Code: Implementierung Dist: Binaries

Source: Quellcode

Data: Roh-Daten der Studie

Latex: LATEX Projekt Dist: PDF Versionen

References: Annotierte Versionen zweier Richtlinien

Source: Quellcodes

Misc: Sonstige Dateien Affinity: Projektdateien der Abbildungen und Icons

Docker: Dockerfile für LATEXund Plots

GitLab CI: CI-Konfiguration für GitLab

Versuche: Dateien zur Durchführung der Versuche

II Anhang

Abbildungsverzeichnis

2.1 Jährliche Publikationen zu robotischen Exoskelett-Systemen seit 2000 im prozentualem Verhältnis zu den Veröffentlichungen im Jahr 2019. In Dimensions, PubMed und Google Scholar waren 2019 4839, 439 und 3640 Ergebnisse zu finden...... 8

2.2 Übersicht des Hand-Exoskeletts des KONSENS Forschungsprojekts (Soe- kadar et al., 2016, bearbeitet durch den Autor) ...... 10

2.3 Darstellung der beiden verwendeten Grifftypen (Feix et al., 2016, bearbeitet durch den Autor) ...... 11

2.4 Repräsentation des Reality-Virtuality Continuums (Milgram et al., 1994, bearbeitet durch den Autor) ...... 13

2.5 Komfortlevel an verschiedenen Stellen auf dem Display. Hierbei befand sich das Display auf der Seite des nichtdominanten Auges. Darstellung durch den Autor auf Basis der Daten von Tanuma et al. (2011). . . . . 15

3.1 Übersicht der Methodik dieser Arbeit...... 19

5.1 Vereinfachte Darstellung der Interaktion der verschiedenen Kompo- nenten der Anwendung...... 59

III Anhang

5.2 Sequenzdiagramm des Programmablaufs bei Verwendung von Sprach- steuerung. Im Falle der Google Glass wird eine Helper App verwendet. 60

5.3 Darstellung der Achsenrotationen (Deldjoo & Atani, 2016, bearbeitet durch den Autor) ...... 61

5.4 Sequenzdiagramm des Programmablaufs bei Verwendung von Kopf- bewegungen...... 63

5.5 Sequenzdiagramm des Programmablaufs bei Verwendung von Eyetracking. 64

5.6 Sequenzdiagramm des Programmablaufs bei Verwendung von Touch- eingabe...... 66

6.1 Schematische Darstellung des experimentellen Verlaufs je Proband . . 70

6.2 Übersicht der getesteten Zweier-IPCs ...... 73

6.3 Übersicht der getesteten Dreier-IPCs ...... 73

6.4 Übersicht der getesteten Vierer-IPC (IPC4) ...... 74

6.5 Schematische Darstellung des experimentellen Aufbaus ...... 75

6.6 Anzahl der gemachten Fehleingaben im Vergleich der getesteten IPCs. 82

6.7 Benötigte Zeit zur Eingabe [ms] im Vergleich der getesteten IPCs. . . . 83

IV Anhang

6.8 Erreichte Bandbreite [bit/s] im Vergleich der getesteten IPCs...... 85

6.9 Erreichte Bandbreite [bit/s] im Vergleich der getesteten IOCs...... 86

6.10 Subjektive Beurteilung im Vergleich der getesteten IOCs. In dieser Dar- stellung ist ein höherer Wert besser...... 86

V Anhang

Tabellenverzeichnis

4.1 Tabellarische Zusammenfassung der Anforderungen der XR Accessibi- lity User Requirements (XAUR) ...... 26

4.2 Tabellarische Zusammenfassung der Anforderungen durch die EN 301 549 ...... 31

4.3 Tabellarische Zusammenfassung der Anforderungen der Apple Hu- man Interface Guidelines ...... 37

4.4 Tabellarische Zusammenfassung der Anforderungen der Google Aug- mented Reality Design Guidelines ...... 42

4.5 Abgeleiteter Kriterienkatalog zur Barrierefreiheit von AR-Anwendungen 50

4.6 Vergleich abgeleiteter Kriterienkatalog mit betrachteten Richtlinien . . 54

5.1 Tabellarische Übersicht der Spezifikation der verwendeten Hardware . 57

5.2 Tabellarische Übersicht der verfügbaren Ein- und Ausgabeverfahren . 58

6.1 Tabellarische Übersicht der IOCs ...... 71

6.2 Tabellarische Übersicht der IOC Reihenfolgen ...... 71

VI Anhang

6.3 Tabellarische Übersicht der IPCs ...... 72

6.4 Tabellarische Übersicht der IPC Reihenfolgen ...... 74

6.5 Tabellarische Übersicht der Fehleingaben [‰], benötigten Zeit zur Ein- gabe [s] und der Bandbreite [bit/s] für die getesteten IOCs...... 81

6.6 Tabellarische Übersicht der Fehleingaben [‰], benötigten Zeit zur Ein- gabe [s] und der Bandbreite [bit/s] für die getesteten IOCs...... 84

VII Anhang

Listingverzeichnis

5.1 Pseudocode des implementierten Gyroskopalgorithmus ...... 61

5.2 Pseudocode des implementierten Eyetrackingalgorithmus ...... 64

5.3 Auszug der Konfigurationsdatei ...... 68

6.1 Auschnitt der Rohdaten einer einzelnen IOC. In diesem Fall wurde I2O2 von einem Probanden der ersten Gruppe getestet. Die IPCs werden in einem Array gespeichert und sind hier nicht dargestellt. Gemessene Da- ten werden als Key-Value-Paare mit darauffolgendem Kommentar gespeichert...... 79

6.2 Auschnitt der verarbeiteten Daten eines einzelnen Probanden. Hier sind fünf Messungen der IPC2a mit I9CO5 zu sehen. Die fünfte Messung zeigt einen Eingabefehler des Nutzers, welcher durch die zwei erfolgten Klicks ersichtlich ist...... 80

VIII Anhang

Abkürzungsverzeichnis

AHIG Apple Human Interface Guidelines APA WG Accessible Platform Architectures Working Group API Application Programming Interface AR Augmented Reality AV Augmented Virtuality BITV Barrierefreie-Informationstechnik-Verordnung DIN Deutsches Institut für Normung EEG Elektroenzephalografie EN Europäische Norm EOG Elektrookulografie ETSI European Telecommunications Standards Institute EU Europäische Union GARDG Google Augmented Reality Design Guidelines HUD Head-up-Display ICT Informations- und Kommunikationstechnik IEC International Electrotechnical Commission IOC Input-Output-Combination IPC Icon-Position-Combination ISO International Organization for Standardization MR Mixed Reality REST Representational State Transfer RVC Reality-Virtuality Continuum SDK Software Development Kit UI User Interface VR Virtual Reality

IX Anhang

W3C World Wide Web Consortium WCAG Web Content Accessibility Guidelines XAUR XR Accessibility User Requirements XR Cross Reality

X Anhang

Literaturverzeichnis

Ableitner, T., Soekadar, S., Schilling, A., Strobbe, C. & Zimmermann, G. (2019). User Acceptance of Augmented Reality Glasses in Comparison to Other Interaction Methods for Controlling a Hand Exoskeleton: A Study among Technology- Oriented Young Persons. Mensch und Computer 2019 - Workshopband, (MuC’19), 178–184. https://doi.org/10.18420/muc2019-ws-616 (siehe S. 11) Accessible Platform Architectures Working Group. (2018). Accessible Platform Archi- tectures Working Group Charter. Verfügbar 6. März 2020 unter https://www. w3.org/2018/08/apa-charter. (Siehe S. 23) Accessible Platform Architectures Working Group. (2020a). ACTION-2254: Draft text around the need for mono. Verfügbar 27. Juni 2020 unter https://www.w3. org/WAI/APA/track/actions/2254. (Siehe S. 51, 87) Accessible Platform Architectures Working Group. (2020b). XR Accessibility User Re- quirements. Verfügbar 6. März 2020 unter https://www.w3.org/TR/2020/ WD-xaur-20200213/. (Siehe S. 23, 24) Allen, G. (2015). Beginning Android: Get started building apps for the Android platform (J. Westfall, Hrsg.; 5. Aufl.). Springer Science+Business Media. https://doi.org/ 10.1007/978-1-4302-4687-9. (Siehe S. 16) Amt für Veröffentlichungen der Europäischen Union. (2012). Verordnung (EU) Nr. 1025/2012 des Europäischen Parlaments und des Rates zur europäischen Nor- mung, zur Änderung der Richtlinien 89/686/EWG und 93/15/EWG des Ra- tes sowie der Richtlinien 94/9/EG, 94/25/EG, 95/16/EG, 97/23/EG, 98/34/EG, 2004/22/EG, 2007/23/EG. (Siehe S. 27). Apple Inc. (n. d.). Human Interface Guidelines. Verfügbar 2. März 2020 unter https: //developer.apple.com/design/human-interface-guidelines/. (Siehe S. 31)

XI Anhang

AsusTeK Computer Inc. (n. d.). ASUS ZenWatch 2 (WI501Q): Spezifikation. Verfüg- bar 21. Juni 2020 unter https://www.asus.com/de/ZenWatch/ASUS%7B% 5C_%7DZenWatch%7B%5C_%7D2%7B%5C_%7DWI501Q/specifications/. (Siehe S. 56) Bakula, M., Kovačević, D., Sarilar, M., Palijan, T. & Kovač, M. (2011). Quality of Life in People with Physical Disabilities. Collegium antropologicum, 35(Suppl. 2), 247– 53. https://doi.org/10.1007/springerreference_188311 (siehe S. 1, 88) Baldovino, R. G. & Jamisola, R. S. (2017). A Survey in the Different Designs and Con- trol Systems of Powered Exoskeleton for Lower Extremities. Journal of Mecha- nical Engineering and Biomechanics, 1(4), 103–115. https://doi.org/10.24243/ jmeb/1.4.192 (siehe S. 9) BMAS/BAuA. (2017). Sicherheit und Gesundheit bei der Arbeit 2017 (Techn. Ber.). www. baua.de/suga. (Siehe S. 6, 7) BMAS/BAuA. (2020). Sicherheit und Gesundheit bei der Arbeit - Berichtsjahr 2018: Unfall- verhütungsbericht Arbeit (2. Aufl., Techn. Ber.). https://doi.org/10.21934/baua: bericht20191115. (Siehe S. 6) Bogue, R. (2018). Exoskeletons –a review of industrial applications. Industrial Robot, 45(5), 585–590. https://doi.org/10.1108/IR-05-2018-0109 (siehe S. 7) Bundesministerium des Innern. (2002). Verordnung zur Schaffung barrierefreier In- formationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie Informationstechnik-Verordnung –BITV). (Siehe S. 23). Bundestag. (2008). Gesetz zu dem Übereinkommen der Vereinten Nationen vom 13. Dezember 2006 über die Rechte von Menschen mit Behinderungen sowie zu dem Fakultativprotokoll vom 13. Dezember 2006 zum Übereinkommen der Vereinten Nationen über die Rechte von Menschen mit Behind. (Siehe S. 43). CEN CENELEC. (2020). What is a European Standard (EN)? Verfügbar 29. Februar 2020 unter https://www.cencenelec.eu/standards/DefEN/Pages/default. aspx. (Siehe S. 27)

XII Anhang

Colven, D. & Judge, S. (2006). Switch access to technology: A comprehensive guide (1. Aufl.). The ACE Centre. (Siehe S. 63). Deldjoo, Y. & Atani, R. E. (2016). A low-cost infrared-optical head tracking solution for virtual 3D audio environment using the Nintendo Wii-remote. Entertainment Computing, 12, 9–27. https://doi.org/10.1016/j.entcom.2015.10.005 (siehe S. 61) de Looze, M. P., Bosch, T., Krause, F., Stadler, K. S. & O’Sullivan, L. W. (2016). Exo- skeletons for industrial application and their potential effects on physical work load. Ergonomics, 59(5), 671–681. https://doi.org/10.1080/00140139.2015. 1081988 (siehe S. 4, 5) Di Sanzo, P., Antonacci, F., Ciciani, B., Palmieri, R., Pellegrini, A., Peluso, S., Quaglia, F., Rughetti, D. & Vitali, R. (2013). A Framework for High Performance Simula- tion of Transactional Data Grid Platforms. SimuTools. https://doi.org/10.4108/ simutools.2013.251737 (siehe S. 16) European Standards Organization. (2020). About Us. Verfügbar 29. Februar 2020 unter https://www.etsi.org/about. (Siehe S. 27) European Telecommunications Standards Institute. (2018). EN 301 549 V2.12 (2018- 08) - Accessibility requirements for ICT products and services. Harmonised Eu- ropean Standard. https://www.etsi.org/deliver/etsi%7B%5C_%7Den/301500% 7B % 5C _ %7D301599 / 301549 / 02 . 01 . 02 % 7B % 5C _ %7D60 / en % 7B % 5C _ %7D301549v020102p.pdf (siehe S. 27, 28) Feix, T., Romero, J., Schmiedmayer, H. B., Dollar, A. M. & Kragic, D. (2016). The GRASP Taxonomy of Human Grasp Types. IEEE Transactions on Human-Machine Systems, 46(1), 66–77. https://doi.org/10.1109/THMS.2015.2470657 (siehe S. 11) Fick, B. R. & Makinson, J. B. (1971). Final Report on Hardiman I Prototype for Machine Augmentation of Human Strength and Endurance. http://cyberneticzoo.com/ wp-content/uploads/2010/04/hardiman-final.pdf (siehe S. 6, 9)

XIII Anhang

Google Inc. (n. d. a). Tech Specs. Verfügbar 2. März 2020 unter https://sites.google. com/a/google.com/glass-partner-dev-program/tech-specs. (Siehe S. 56) Google Inc. (n. d. b). Technische Daten von Pixel 4 und Pixel 4 XL im Vergleich. Ver- fügbar 11. Juli 2020 unter https://store.google.com/product/pixel%7B%5C_ %7D4%7B%5C_%7Dspecs. (Siehe S. 56) Google Inc. (2020). Augmented Reality Design Guidelines. Verfügbar 1. März 2020 unter https://designguidelines.withgoogle.com/ar-design/augmented-reality- design-guidelines/introduction.html. (Siehe S. 37) Heo, P., Gu, G. M., jin Lee, S., Rhee, K. & Kim, J. (2012). Current hand exoskeleton technologies for rehabilitation and assistive engineering. International Journal of Precision Engineering and Manufacturing, 13(5), 807–824. https://doi.org/10. 1007/s12541-012-0107-2 (siehe S. 7) Hessinger, M., Müller, R., Werthschützky, R. & Pott, P. P. (2015). Tool position control of an upper limb exoskeleton for robot-assisted surgery. IFAC-PapersOnLine, 28(20), 195–200. https://doi.org/10.1016/j.ifacol.2015.10.138 (siehe S. 7) Hochschule der Medien. (2020). Corona-Hygieneschutzmaßnahmen für die Hoch- schule der Medien. https://www.hdm- stuttgart.de/intranet/iformulare/ formular20200529140140 / Hygienekonzept % 7B % 5C _ %7DHdM % 7B % 5C _ %7Dv.1.3.pdf. (Siehe S. 77) Hong, J. (2013). Considering privacy issues in the context of google glass. Communi- cations of the ACM, 56(11), 10–11. https://doi.org/10.1145/2524713.2524717 (siehe S. 56) Intel Corporation. (2017). Transitioning your Mobile App away from Crosswalk. Ver- fügbar 12. März 2020 unter https://software.intel.com/en-us/xdk/docs/lp- crosswalk. (Siehe S. 18) Jacobs, I. & Frost, R. (2012). W3C Web Content Accessibility Guidelines 2.0 Approved as ISO/IEC International Standard. http://www.w3.org/2012/07/wcag2pas- pr.html. (Siehe S. 23)

XIV Anhang

Kassner, M., Patera, W. & Bulling, A. (2014). Pupil: An Open Source Platform for Per- vasive Eye Tracking and Mobile Gaze-based Interaction. Adjunct Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Compu- ting, 1151–1160. https://doi.org/10.1145/2638728.2641695 (siehe S. 63) Kazerooni, H., Steger, R. & Huang, L. (2006). Hybrid control of the Berkeley Lower Extremity Exoskeleton (BLEEX). International Journal of Robotics Research, 25(5- 6), 561–573. https://doi.org/10.1177/0278364906065505 (siehe S. 9) Kwakkel, G., Kollen, B. J., Van der Grond, J. V. & Prevo, A. J. (2003). Probability of regaining dexterity in the flaccid upper limb: Impact of severity of paresis and time since onset in acute stroke. Stroke, 34(9), 2181–2186. https://doi.org/10. 1161/01.STR.0000087172.16305.CD (siehe S. 7) Lo, H. S. & Xie, S. Q. (2012). Exoskeleton robots for upper-limb rehabilitation: State of the art and future prospects. Medical Engineering and Physics, 34(3), 261–268. https://doi.org/10.1016/j.medengphy.2011.10.004 (siehe S. 7) Lockheed Martin. (2017). New Lockheed Martin Exoskeleton Helps Soldiers Carry Heavy Gear. Verfügbar 11. November 2019 unter https://news.lockheedmartin. com / 2017 - 05 - 16 - New - Lockheed - Martin - Exoskeleton - Helps - Soldiers - Carry-Heavy-Gear?%7B%5C_%7Dga=2.257684616.2035891536.1564607389- 431268198.1564607389. (Siehe S. 6) Meng, C., Wang, T., Chou, W., Luan, S., Zhang, Y. & Tian, Z. (2004). Remote surgery case: Robot-assisted teleneurosurgery. Proceedings - IEEE International Con- ference on Robotics and Automation, 2004(1), 819–823. https://doi.org/10.1109/ robot.2004.1307250 (siehe S. 7) Milgram, P., Takemura, H., Utsumi, A. & Kishino, F. (1994). Augmented reality: a class of displays on the reality–virtuality continuum. Proceedings the SPIE, 2351(Telemanipulator and Telepresence Technologies), 282–292. https://doi.org/10.1.1.83.6861 (siehe S. 12, 13)

XV Anhang

Obsidian Entertainment Inc. (2020). Accessibility features. Verfügbar 31. Juli 2020 unter https://grounded.obsidian.net/news/grounded/accessibility- features. (Siehe S. 49) Publications Oﬀice of the European Union. (2017). Eurofound (2017), Sixth European Working Conditions Survey: Overview report (2017 update) (Techn. Ber.). Luxem- bourg. https : / / www . eurofound . europa . eu / publications / report / 2016 / working-conditions/sixth-european-working-conditions-survey-overview- report. (Siehe S. 6) Que, P., Guo, X. & Zhu, M. (2016). A Comprehensive Comparison between Hybrid and Native App Paradigms. Proceedings - 2016 8th International Conference on Computational Intelligence and Communication Networks, CICN 2016, 611–614. https: //doi.org/10.1109/CICN.2016.125 (siehe S. 17, 18) Robert Koch-Institut. (2015). Gesundheit in Deutschland (Techn. Ber.). https://doi.org/ 10.17886/rkipubl-2015-003. (Siehe S. 7, 8) Rosen, J. & Perry, J. C. (2007). Upper limb powered exoskeleton. International Journal of Humanoid Robotics, 4(3), 529–548. https://doi.org/10.1142/S021984360700114X (siehe S. 9) Sanborn, M., Smith, L. J. & Malhotra, N. R. (2013). The Trauma Manual: Trauma and Acu- te Care Surgery (4. Aufl.). LIPPINCOTT WILLIAMS & WILKINS, a WOLTERS KLUWER business. https://doi.org/10.1016/B978-0-12-374245-2.00015-2. (Siehe S. 1) Sarcos. (2019). U.S. Navy Partners with Sarcos Robotics for Powered Full-Body Exo- skeletons and Inspection Robots to Optimize Shipyard. Verfügbar 11. Novem- ber 2019 unter https://www.sarcos.com/company/news/press-releases/u-s- navy-partners-with-sarcos-robotics/. (Siehe S. 6) Schabowsky, C. N., Godfrey, S. B., Holley, R. J. & Lum, P. S. (2010). Development and pilot testing of HEXORR: Hand EXOskeleton Rehabilitation Robot. Journal of

XVI Anhang

NeuroEngineering and Rehabilitation, 7(1), 36. https://doi.org/10.1186/1743- 0003-7-36 (siehe S. 1, 88) Siewe-Reinke, A. & Müller, J. (n. d.). KONSENS-NHE BW-NEUROROBOTIK. Ver- fügbar 8. August 2020 unter https : / / www . inf . reutlingen - university . de / forschung/forschungsgruppen-projekte/konsens-nhe/. (Siehe S. 2) Soekadar, S. R., Witkowski, M., Gómez, C., Opisso, E., Medina, J., Cortese, M., Cempi- ni, M., Carrozza, M. C., Cohen, L. G., Birbaumer, N. & Vitiello, N. (2016). Hy- brid EEG/EOG-based brain/neural hand exoskeleton restores fully indepen- dent daily living activities after quadriplegia. Science Robotics, 1(1), 1–8. https: //doi.org/10.1126/scirobotics.aag3296 (siehe S. 10) Su, L. M. (2009). Role of robotics in modern urologic practice. Current Opinion in Uro- logy, 19(1), 63–64. https://doi.org/10.1097/MOU.0b013e32831aeecc (siehe S. 7) Tanuma, K., Sato, T., Nomura, M. & Nakanishi, M. (2011). Comfortable design of task-related information displayed using optical see-through head-mounted display. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 6772 LNCS(PART 2), 419–429. https://doi.org/10.1007/978-3-642-21669-5_50 (siehe S. 14, 15) W3C. (2008). Web Content Accessibility Guidelines (WCAG) 2.0. Verfügbar 24. Januar 2017 unter https://www.w3.org/TR/WCAG20/. (Siehe S. 43) W3C. (2020). Facts About W3C People of W3C. Verfügbar 6. März 2020 unter https: //www.w3.org/Consortium/facts. (Siehe S. 23) World Wide Web Consortium (W3C). (n. d.). Working Groups. Verfügbar 9. März 2020 unter https://www.w3.org/Consortium/activities. (Siehe S. 23) World Wide Web Consortium (W3C). (2019). World Wide Web Consortium Process Document. Verfügbar 6. März 2020 unter https://www.w3.org/2019/Process- 20190301/. (Siehe S. 23)

XVII