ucanvas: Interaktive Anzeigeflächen auf heterogenen Oberflächen

Transkript

1 ucanvas: Interaktive Anzeigeflächen auf heterogenen Oberflächen Yves Grau, Tobias Bagg Abbildung 1: Screenshots der Anwendungen: links Mind-Mapper, rechts Food Ninja Abstract Digitale Anzeigen haben in den letzten Jahren enorm an Bedeutung gewonnen. Die Präsenz dieser Bildschirme in Form von Mobiltelefonen, Tablet-PCs, projizierten Flächen oder Public Displays ist allgegenwärtig. Jeder Bildschirm benötigt eine individuelle Art der Interaktion, zum Beispiel durch ein spezielles Eingabegerät oder berührungssensitive Interaktion. Teilweise werden keinerlei Interaktionsmöglichkeiten angeboten, wodurch lediglich ein informativer Dienst zu Verfügung steht. Heutzutage trägt nahezu jeder Mensch ein Smartphone mit sich und besitzt damit schon ein High-End Interaktionsgerät, welches sich mit jeder, mit dem Internet verbundenen, digitalen Anzeigefläche verbinden könnte. Aus diesem Grund haben wir ucanvas entwickelt, ein System, das einen schnellen und einfachen Zugriff zu diesen Anzeigeflächen herstellt und damit Interaktionsmöglichkeiten bereitstellt. Im Gegensatz zu bisherigen Ansätzen ist keine zusätzliche Hardware nötig, lediglich ein Mobiltelefon, welches mit einem Beschleunigungs- und Magnetfeldsensor ausgestattet ist. Diese Sensoren werden benutzt um sein Mobiltelefon mit der Anzeige zu kalibrieren und die Bewegungen der Benutzer auf den Mauszeiger zu übertragen. Um die Einfachheit und Benutzbarkeit unseres Systems zu evaluieren haben wir zwei Beispielanwendungen erstellt. In einer durchgeführten Benutzerstudie zeigte sich die intuitive Benutzung des Systems und die einfache Ersteinrichtung für den Endbenutzer. Index Terms Mobile interaction, public display, ubiquitous computing, magnetometer, pointing, smart environments 1 EINLEITUNG Mark Weiser s Vision, Computer nahtlos in unsere alltägliche Umwelt zu integrieren[7], wurde in Form der Public Displays in die Realität umgesetzt. Bildschirme haben sich in unterschiedlichsten Formen, Größen, Funktionalitäten (informativ oder interaktiv), Orten und Kontexten (zu Hause, Arbeit, Öffentlichkeit) fest in unserem täglichen Leben etabliert. Insbesondere Public Displays wurden in den letzten Jahren verhäuft an Flughäfen, Bahnhöfen, Einkaufszentren und an anderen öffentlichen Orten installiert. Doch die Hauptaufgabe dieser Bildschirme liegt noch immer darin als Informationsquelle zu fungieren und erlauben nur stark begrenzte Interaktionsmöglichkeiten für die Benutzer. Diese Einschränkungen sind zum einen durch den Schutz der Bildschirme gegen Vandalismus bedingt und zum anderen durch die häufig große Distanz zu den Bildschirmen ( Distant Displays ), da zum Beispiel am Bahnhof Gleise zwischen dem Benutzer und dem Bildschirm liegen. Eine berührungsbasierte Interaktion ist somit in diesen Fällen nicht oder nur begrenzt möglich. Dagegen gibt es auch im privaten Umfeld bei Geräten wie Projektoren oder TV erhebliche Einschränkungen für anspruchsvolle Eingaben, die über die übliche TV-Fernbedienung hinausgehen. Mittlerweile tragen nahezu alle Menschen ein Mobiltelefon mit sich. Daher haben sich schon einige Arbeiten damit befasst, das Mobiltelefon als Eingabegerät für große Bildschirme zu verwenden[1, 3, 6]. Keine dieser Techniken wurde im Allge- Yves Grau Tobias Bagg inf82040@stud.uni-stuttgart.de inf79170@stud.uni-stuttgart.de meinen angenommen, da die Installation häufig zu aufwendig ist oder zusätzliche Hardware benötigt wird. Wir haben ucanvas entwickelt um eine einfache, schnelle und intuitiv zu bedienende Möglichkeit zu geben, mit der man jegliche Anzeige in eine interaktive Oberfläche verwandeln kann. Jede Person mit einem Mobiltelefon ist in der Lage das System zu nutzen. Das System besteht aus drei Komponenten. Irgendeine Art von Bildschirm welche mit dem Internet verbunden ist, das Mobiltelefon des Anwenders mit installierter ucanvas Applikation, sowie dem ucanvas Server. Außerdem muss das Mobiltelefon über einen integrierten Beschleunigungs- und Magnetfeldsensor verfügen. Um die Interaktion mit dem Bildschirm zu starten muss der Anwender nur drei Schritte befolgen. Als erstes muss der Nutzer die ucanvas Applikation auf seinem Mobiltelefon installieren. Der zweite Schritt beinhaltet die Kalibrierung der Anzeige. Hierzu muss der Anwender, mit seinem Mobiltelefon, auf die linke obere Ecke des Bildschirms deuten und auf Start Calibration drücken, daraufhin deutet man auf die rechte untere Ecke und drückt auf Stop Calibration. Im dritten Schritt startet man den Interaktionsmodus, indem man auf Canvas drückt. Die Interaktion besteht lediglich darin, innerhalb der zuvor kalibrierten Ecken auf den Bildschirm zu deuten. Wir benutzen den Beschleunigungs- und den Magnetfeldsensor um den Punkt des Benutzers, auf welchen er innerhalb des Bildschirms zeigt und seine Bewegungen direkt auf die Position des Mauszeigers abzubilden. Das System unterstützt die Interaktion mit mehreren Nutzern auf einer Anzeigefläche oder simultan auf mehreren unterschiedlichen Anzeigen. 1

2 Mit diesem System kann jegliche Art von Bildschirm interaktiv gemacht werden. Von projizierten Flächen, Public Displays, TVs, Smartboards bis zu ganzen Medienfassaden. Prinzipiell kann jede Anzeige, welche eine Webseite anzeigen kann und mit dem Internet verbunden ist, in eine interaktive Fläche umgewandelt werden. Um die Realisierbarkeit unseres Ansatzes zu überprüfen, haben wir zwei Beispielanwendungen implementiert und getestet. Damit soll gezeigt werden, dass es möglich ist mit minimalem Aufwand einen Bildschirm in eine interaktive Anzeige zu verwandeln. 2 RELATED WORK Bereits 1980 gab es erste Versuche von Bolt[2] graphische Flächen mit Hilfe von Sprache und Gesten zu handhaben. Hierfür wurde ein gesamter Raum mit Spracherkennung sowie einem komplexen System aus Würfeln mit magnetischen Sensoren ausgestattet, um Gesten erkennen zu können. Heutzutage wird viel im Bereich der Interaktion mit Public- und Distant Displays geforscht. Beispielsweise nutzen Ballagas et al.[1] die Kamera eines Smartphones, um den Mauszeiger auf einem Distant Display (z.b interaktive öffentliche Displays) zu bewegen. Dies wird durch optical flow image processing erreicht, wobei die Bewegung einzelner Pixel einer Bildersequenz berechnet wird. Die Studienergebnisse wiesen allerdings große Zeitwerte auf, die Teilnehmer benötigten um Aufgaben zu lösen, als auch niedrige Werte bei der Bewertung durch Studienteilnehmer. Boring et al.[3] nutzten die Kamera, Tasten sowie den Beschleunigungssensor von Smartphones um einen Mauszeiger auf einem Display zu bewegen. Ein aktueller Ansatz um Geräte zu kontrollieren stammt von Derthick et al.[5]. Hierbei wird ein WiFi access point benutzt, um die Web-Benutzerschnittstelle des Geräts darzustellen, sobald sich ein mobiles Gerät versucht zu verbinden. Wie man erkennen kann, gibt es viele Ansätze um Interaktion mit Displays zu gestalten. Bisher gab es allerdings noch keine Technologie, welche von einer breiten Masse angenommen wurde. Wir denken, dass dies an kostspieligen Implementierungen, umständlicher Installation und nicht gut skalierenden Ansätzen liegt. Unser Ansatz stellt eine skalierbare Client-Server Lösung vor, was dadurch erreicht wird, dass sich eine Vielzahl von Geräten mit mehreren unterschiedlichen Canvas zur gleichen Zeit verbinden können. ucanvas kann auf jedem Bildschirm betrieben werden, welcher mit dem Internet verbunden ist sowie mit Hilfe eines Android Smartphone. Da das Deuten mit der Hand eine natürliche Geste ist, benutzen wir diesen Ansatz, um Bewegungen des Handgelenks eines Benutzers in Bewegungen eines Mauszeigers auf einem Bildschirm darzustellen. Im Vergleich zu bisherigen Ansätzen ist unser Ansatz auf eine schnelle Installation optimiert und es wird keine zusätzliche Hardware benötigt. 3 UCANVAS ARCHITEKTUR ucanvas ist ein Multi-User Client-Server System (Abbildung 2). Wir unterscheiden zwei Typen von Clients: Erstens Mobiltelefone (Benutzer Clients), welche Sensordaten sowie Informationen über die auszuführenden Aktionen an den Server senden. Zweitens verbinden sich Bildschirme (welche den Canvas darstellen) mit Hilfe von Webbrowsern mit dem Server. Der Server vermittelt, die von den Smartphones verschickten Aktionen, an den gewählten Bildschirm, welcher mit Hilfe einer Javascript Bibliothek diese Daten im Webbrowser verarbeitet und darstellt. Zusätzlich speichert der Server den Zustand jedes Canvas, sodass sich ein Bildschirm jederzeit mit dem Server verbinden kann um den aktuellen Zustand abzurufen. Diese Eigenschaft macht es möglich mit einem Canvas auf mehreren Bildschirmen an unterschiedlichen Orten zu interagieren. 3.1 Benutzer Client - Smartphones Der Benutzer Client ist eine native Android Applikation, welche keine permanente Verbindung zum Server aufbaut, sondern lediglich per UDP Pakete verschickt. Die Auswahl und anschließendes Interagieren mit einem Bildschirm läuft in drei Schritten ab: (1) Registrierung mit Hilfe der Eingabe der Canvas-ID oder durch das Scannen eines QR-Codes. (2) Die Kalibrierung des Canvas. Der Benutzer legt die Größe des Canvas fest, indem er auf die linke obere Ecke des Bildschirms deutet und per Klicken eines Buttons diese Position speichert. Für die rechte untere Ecke wird auf die gleiche Art verfahren. Dadurch wird ein Rechteck mit Hilfe des Beschleunigungs- sowie Magnetfeldsensor festgelegt, welches die Grenzen des Bildschirms festlegt. (3) Durch die abgeschlossene Kalibrierung kann der Benutzer mit der eigentlichen Interaktion beginnen, indem er innerhalb der Grenzen mit seinem Smartphone deutet und Aktionen ausführt. Auf Grund der Benutzung des Magnetfeldsensors sind die Gesten auf Bewegungen aus dem Handgelenk beschränkt, da sich ansonsten die Winkel zwischen dem Smartphone und Canvas verschieben Glättung der Sensorwerte p r i v a t e f i n a l f l o a t SMOOTHING = f ; / T i e f p a s s F i l t e r / p r i v a t e f l o a t [ ] lowpass ( f l o a t [ ] i n p u t, f l o a t [ ] o u t p u t ) { i f ( o u t p u t == n u l l ) return i n p u t ; f o r ( i n t i =0; i<i n p u t. l e n g t h ; i ++ ) { o u t p u t [ i ] = o u t p u t [ i ] + SMOOTHING ( i n p u t [ i ] o u t p u t [ i ] ) ; return o u t p u t ; Listing 1: Tiefpassfilter Abbildung 2: ucanvas Architektur Da die Sensorwerte von Smartphones ungenau sind und schon leichte Bewegungen der Hand zu starkem Zittern des Mauszeigers führen, müssen die Sensordaten gefiltert beziehungsweise geglättet werden. Innerhalb des Fachbereichs Elektrotechnik werden schon seit langer Zeit erfolgreich Tiefpassfilter eingesetzt um Frequenzen, welche sich oberhalb einer bestimmten Grenzfrequenz befinden, abzuschwächen und Werte die unterhalb dieser Grenze liegen passieren zu lassen. Solch ein Tiefpassfilter (Listing 1), welcher die Sensordaten bereits auf dem Smartphone aufbereitet, hat sich als sehr nützlich erwiesen. Mit Hilfe der Konstanten SMOOTHING, lässt sich der Filter einstellen. Je kleiner dieser Wert gewählt wird, desto weniger zittert ein Mauszeiger, wenn man versucht ihn an einer Stelle zu halten. Gleichzeitig bewegt sich der Mauszeiger dadurch bei schnelleren Bewegungen nur sehr träge. Wählt man diesen Wert größer verhält sich dieser Umstand genau umgekehrt. Der hier gewählte Wert führt zu einem guten Kompromiss zwischen diesen beiden Problemfällen. 2

3 Abbildung 3: Paketformate: links Food Ninja, rechts Mind-Mapper 3.2 UDP-Pakete Damit eine gute Benutzbarkeit des Systems erreicht wird, sollten Interaktionen möglichst ohne Verzögerung auf dem Bildschirm dargestellt werden (z.b die Bewegung eines Mauszeigers). Um die Verzögerung klein zu halten, sollten die ausgetauschten Datenpakete möglichst klein sein. Deshalb verwenden wir ein komprimiertes Byte Array, da der Overhead klein gehalten wird. Die übermittelten Daten sind abhängig von der jeweiligen Applikation (siehe Abbildung 3). c l i e n t I D = S e t t i n g s. S e c u r e. g e t S t r i n g ( g e t C o n t e n t R e s o l v e r ( ), S e t t i n g s. S e c u r e. ANDROID ID ) ; Listing 2: Abrufen der Client-ID Beide Applikationen benötigen in den ersten 32 Byte eine eindeutige Client-ID (Listing 2) für jeden Benutzer Client, um ein Multi-User System anbieten zu können. Der Server verwendet diese ID um ankommende Pakete einem mobilen Gerät zuordnen zu können. Ebenfalls benutzen beide Anwendungen eine 4 Byte lange Canvas-ID, damit der Server bestimmen kann mit welchem Bildschirm ein Benutzer Client interagieren möchte. Die folgenden Byte sind abhängig von der jeweiligen Anwendung. Food Ninja benötigt lediglich weitere 8 Byte um eine X- und Y-Koordinate (jeweils 4 Byte) zu übertragen, sodass ein Mauszeiger damit gesteuert werden kann. Die Mind-Mapper Anwendung benötigt bis zu vier solcher Koordinaten, sodass insgesamt 16 Byte dafür vorgesehen sind (x1, x2, y1, y2). Zudem werden weitere 4 Byte benötigt, da unterschiedliche Aktionen kodiert werden müssen, zum Beispiel das Erzeugen von Blasen oder das Erstellen von Verbindungen. Da der Mind-Mapper in der Lage ist Blasen mit Text zu erzeugen, welcher vom Benutzer eingegeben wird, können die Pakete unterschiedliche Länge besitzen. Deshalb sind alle Bytes die hinter dem 57 Byte bis zur Länge des Paket folgen für eingegebenen Text reserviert. 3.3 Server Da der Server unter Umständen eine Vielzahl von Benutzer Clients mit eventuell unterschiedlichen Canvas verbindet und deren Zustand zusätzlich speichern muss, war eines der Kriterien eine Technologie einzusetzen, welche auch für viele Clients gut skaliert. Deshalb wurde der Server vollständig in node.js[4] entwickelt, was uns zusätzlich durch die starke Abstrahierung ermöglichte mit relativ wenig Codezeilen eine durchaus komplexe Anwendung zu entwickeln. Angebotene Dienste Der Server stellt drei unterschiedliche Dienste bereit: (1) Ein UDP-Server, welcher auf einem Port auf ankommende UDP-Pakete der Smartphones lauscht. (2) Ein HTTP-Server, der eine Webseite (HTML/Javascript) an verbundene Browser ausliefert. (3) Ein Websocket, der einen vollduplexen Kanal bereitstellt um permanent Daten an die Webbrowser auszuliefern, ohne dabei die Webseite erneut laden zu müssen. Je nach Anwendung kann es auch nötig sein, Daten über diese Verbindung vom Browser zurück zum Server zu übertragen. Empfang und Verarbeitung von UDP-Paketen Node.js setzt auf das Paradigma der Ereignis-basierten Programmierung, was am Beispiel des UDP-Server in Listing 3 dargestellt wird. Dabei wird eine Funktion auf ein bestimmtes Ereignis registriert, welche var u d p S e r v e r = dgram. c r e a t e S o c k e t ( udp4 ) ; u d p S e r v e r. on ( message, f u n c t i o n ( msg, i n f o ) { / e n t p a c k e n und v e r a r b e i t e n des UDP Paket / msg. copy ( c l i e n t I D B u f f e r, 0, 0, 32) ;... Listing 3: Der Server lauscht auf unterschiedlichen Ports, als Beispiel der UDP-Port aufgerufen wird, sobald dieses Ereignis eintritt. Der Server zerlegt ankommende UDP-Pakete mit der, bereits in Abschnitt 3.2, beschriebenen Struktur. / A l l e verbunden B i l d s c h i r m e, werden u n t e r der j e w e i l i g e n Canvas ID g e s p e i c h e r t und koennen im O b j e k t SetCanvas a l s A t t r i b u t a b g e r u f e n werden z. B SetCanvas [ 1 ] b e i n h a l t e t a l l e B i l d s c h i r m e, welche s i c h f u e r CanvasID=1 r e g i s t r i e r t haben / var SetCanvas = {; / I t e r a t i o n ueber a l l e B i l d s c h i r m e f u e r e i n e n Canvas. Uebertragen wird e i n e b e s t i m m t e A k t i o n a l s auch e i n e x1 und y1 K o o r d i n a t e / f o r ( var i =0; i < SetCanvas [ CanvasID ]. l e n g t h ; i ++){ s o c k e t i o. s o c k e t s. s o c k e t ( SetCanvas [ CanvasID ] [ i ] ). e mit ( a c t i o n, {x1 : x1, y1 : y1 ) ; Listing 4: Speicherstruktur von Bildschirmen, welche sich für einen Canvas registriert haben Durch die darin enthaltene Canvas-ID weiß der Server, an welches Ziel oder Ziele die restlich enthaltenen Daten weitergeleitet werden sollen, wie z.b in Listing 4 angedeutet wird. Je nachdem wieviele Webbrowser sich einen Canvas teilen, werden die Daten per Websocket an einen oder mehrere Webbrowser weitergeleitet. Speichern des Zustands Um zu ermöglichen, dass sich Bildschirme zu unterschiedlichen Zeitpunkten für den selben Canvas registrieren und gleichzeitig immer den selben Zustand haben, ist es nötig, dass dies der ucanvas Server speichert. Verbindet sich ein Client (Bildschirm) erst zu einem Zeitpunkt, an welchem schon viele Aktionen durch andere Clients durchgeführt wurden, so muss der Server diesen Zustand dem neuen Client übermitteln. Die Art, wie der Zustand gespeichert wird, ist abhängig von der Applikation und soll hier am Beispiel des Mind-Mappers gezeigt werden. Um den aktuellen Zustand bei einem neuen Client herzustellen ist es nötig zu wissen, welche Blasen sowie Verbindungen zwischen Blasen bisher erzeugt wurden. In Listing 5 wird die benötigte Speicherstruktur gezeigt und zweitens wie der aktuelle Zustand an den Client übermittelt wird. Im Beispiel wird dies nur anhand der Blasen gezeigt, für Verbindungen läuft der Vorgang analog ab. Über die erste Dimension des Objekts statecanvas greift man entweder auf Blasen oder Verbindungen zu. Mit Hilfe der zweiten Dimension werden die Blasen durch verschiedene CanvasIDs getrennt, z.b statecanvas[ bubbles ][canvasid]. Hier können nun alle vorhanden Blasen abgerufen werden. 3.4 Ausblick Aktuell ist es für einen Benutzer umständlich einem ucanvas Server Pakete zu schicken, um mit einem Canvas zu interagieren, da der Benutzer erstens die App für sein Smartphone benötigt und zweitens 3

4 var s t a t e C a n v a s = {; s t a t e C a n v a s [ b u b b l e s ] = {; s t a t e C a n v a s [ c o n n e c t i o n s ] = {; / Beim Verbinden e i n e s C l i e n t / f o r ( node i n s t a t e C a n v a s [ b u b b l e s ] [ canvasid ] ) { var x1 = s t a t e C a n v a s [ b u b b l e s ] [ canvasid ] [ node ]. x ; var y1 = s t a t e C a n v a s [ b u b b l e s ] [ canvasid ] [ node ]. y ; var msg = s t a t e C a n v a s [ b u b b l e s ] [ canvasid ] [ node ]. msg ; var ID = s t a t e C a n v a s [ b u b b l e s ] [ canvasid ] [ node ]. nodeid ; s o c k e t i o. s o c k e t s. s o c k e t ( s o c k e t. i d ). e mit (PLACE BUBBLE, {x1 : x1, y1 : y1, msg : msg, nodeid : ID ) ; Listing 5: speichern Speicherstruktur um den Zustand eines Canvas zu überhaupt ein Android-Phone besitzen muss (Benutzer von iphones werden zum Beispiel bisher ausgeschlossen, da keine App vorhanden ist). Deshalb soll eine Version entstehen, welche komplett auf eine App verzichtet. Hier wird lediglich eine HTML5-Webseite besucht, welche die Aufgaben der App übernimmt. Dies macht die Applikation plattformunabhängig und zwingt den Benutzer nicht dazu sich erst eine Anwendung herunterladen zu müssen. 4 APPLIKATIONEN Auf Basis des im letzten Kapitel beschriebenen Grundsystems wurden zwei Beispielanwendungen implementiert. Zum einen wurde eine Mind-Mapper Applikation entwickelt, bei der mehrere Nutzer simultan eine Mind-Map erstellen oder modifizieren können. Die Mind-Map, in Abbildung 1 links, wurde mit dieser Applikation erstellt. Zum anderen wurde das Spiel Food Ninja erstellt, in Abbildung 1 dargestellt. In diesem geht es darum die umherfliegenden Früchte zu zerschneiden und dadurch Punkte zu sammeln. Auch bei dieser Applikation können mehrere Nutzer gleichzeitig interagieren und gegeneinander antreten. Auf diese zwei Beispielanwendungen wird nun im Detail eingegangen. 4.1 Food Ninja In dem Spiel Food Ninja geht es darum die zufällig hereinfliegenden Früchte mit dem Mauszeiger zu zerschneiden und damit Punkte zu sammeln. Mit ansteigendem Level erhöht sich die Anzahl der Früchte, sowie die Punkte, die man pro zerschnittener Frucht erhält. Außerdem fliegen auch hin und wieder Bomben durch die Anzeige, denen man ausweichen sollte. Ein Spiel ist zu Ende, sobald ein Spieler eine Bombe berührt und damit GameOver eintritt. Früchte und Bomben fliegen zufällig von links, rechts oder von unten ein. Nicht zerschnittene Früchte haben keine negativen Auswirkungen auf den Spieler. In Abbildung 1 rechts, sieht man Food Ninja im Spielmodus. Die rote Raute stellt den Mauszeiger dar, mit dem man die Früchte zerschneiden muss. Zudem sieht man eine herannahende Bombe, einige Früchte und eine vor kurzem in zwei Teile geschnittene Frucht. Außerdem sieht man in der rechten oberen Ecke die aktuell erreichten Punkte von 219. Abbildung 4 zeigt jede einzelne Activity der mobilen Anwendung von Food Ninja. Mit dem linken Screenshot startet die Anwendung. Hier muss man die CanvasID angeben, damit der Server die Information erhält, mit welcher Anzeige der Benutzer interagieren möchte. Durch drücken des SaveID Buttons kommt man auf Abbildung 4: Screenshots der mobilen Anwendung von Food Ninja die Activity der Kalibrierung, in Abbildung 4 der mittlere Screenshot. Ähnlich zum Basissystems werden bei Azimuth und Pitch die aktuellen Sensordaten angezeigt. Die Kalibrierung funktioniert genau wie im schon vorgestellten Grundsystem. Bei dem Abschnitt Top Left Corner werden die Winkel für die kalibrierte linke obere Ecke angezeigt, dementsprechend wird bei Bottom Right Corner die Winkel der rechten unteren Ecke dargestellt. Beim Drücken des Info Buttons, welcher an den definierten Canvas erinnern soll, wird eine Nachricht angezeigt, in der die Kalibrierung nochmals erklärt wird. Nach der Kalibrierung wird mit dem Canvas Button der Interaktionsmodus gestartet. Ab diesem Zeitpunkt ist die mobile Anwendung für den Nutzer eher unwichtig. Es wird lediglich noch angezeigt, ob der Benutzer inerhalb oder außerhalb der definierten Fläche interagiert, zu sehen in Abbildung 4 rechts. Mit dem Button Back kann man zur vorherigen Activity zurückkehren und die Kalibrierung erneut vornehmen. Sobald man sich im Interaktionsmodus befindet werden die Pakete zum Server gesendet und auf dem Canvas erscheint der steuerbare Mauszeiger. Abbildung 5: Startmenü der Food Ninja Applikation auf dem Canvas Das Startmenü von Food Ninja ist in Abbildung 5 dargestellt. Zum Starten des Spiels muss der Benutzer mit dem Mauszeiger den Neues Spiel Button berühren. Daraufhin startet der Spielmodus und innerhalb weniger Sekunden fliegen die ersten Früchte und Bomben ein. Diese kommen pro Level in jeweils fünf Intervallen und pro Intervall fliegen im ersten Level zwei Früchte ein. Die Anzahl der Früchte steigt mit zunehmendem Level ebenfalls an. Sobald der Spieler eine Bombe berührt ist das Spiel vorbei, dem Spieler wird seine erreichte Punktzahl angezeigt und er kann erneut ein Spiel beginnen. Zu jeder Zeit, ob im Menü oder im Spielmodus, können theoretisch beliebig viele Spieler hinzukommen und spielen bis einer 4

5 der Spieler eine Bombe berührt hat (Multi-User). Am Ende wird von jedem Spieler die erreichte Punktzahl angezeigt und der jeweilige Spieler markiert, welcher die Bombe berührt hat. 4.2 Mind-Mapper Die Applikation (Screenshot siehe Abbildung 1 links) entstand mit dem Grundgedanke Mind-Map, welche normalerweise mit Hilfe von Stift und Papier von einer Person angefertigt werden um einen komplexeren Sachverhalt abstrakt zu modellieren, nun digital auf einer großen Bildfläche erzeugen zu können. Gleichzeitig sollte die Möglichkeit bestehen, solche Graphen in Kooperation mit anderen Personen zu erzeugen (Multi-User). werden kann. Unterläuft hierbei ein Fehler, so kann mit Blase entfernen die Blase wieder entfernt werden. Eventuelle Verbindungen zu anderen Blasen werden ebenfalls entfernt. Wurde eine Blase an einem ungünstigen Platz gesetzt, so kann diese mit Hilfe von Blase verschieben an einen anderen Platz gesetzt werden. Abbildung 8: Screenshots der App: links Optionen des Menüs Bubble Actions, rechts Optionen des Menüs Connection Actions Abbildung 6: Screenshots der App: rechts die Activity zum Kalibrieren der App, links das Hauptmenü In Abbildung 6 erkennt man rechts die Activity, welche beim Starten der App aufgerufen wird um den Canvas zu kalibrieren, wie es bereits in vorrangehenden Abschnitten erklärt wurde. Klickt man den Button Canvas!, so wird die Activity aus Abbildung 6 links geladen. Nun befindet man sich im Hauptmenü der App und kann die gewünschten Aktionen von hier aus steuern. Abbildung 7: Darstellung einer Blase und deren Verbindungen, Ausschnitt aus einer Mind-Map Bubble Actions Im Untermenü Bubble Actions (siehe Abbildung 8 links) sind folgende Aktionen zu finden, welche direkt mit der Interaktion der Blasen zu tun haben. Eine Blase ist in Abbildung 7 dargestellt. Blase erzeugen Blase entfernen Blase verschieben Möchte der Benutzer eine Blase erzeugen, so öffnet sich automatisch ein Texteingabefeld mit welchem ein Text in die Blase eingefügt Connection Actions Im Untermenü Connection Actions (siehe Abbildung 8 rechts) sind folgende Aktionen zu finden. Verbindung erzeugen Verbindung entfernen Mit Hilfe von Verbindung erzeugen kann eine Verbindung zwischen zwei Blasen erzeugt werden. Dafür wird der Mauszeiger zuerst auf eine der beiden Blasen bewegt und auf den Button Set Connection gedrückt, danach dasselbe für die zweite Blase. Möchte der Benutzer diesen Schritt rückgängig machen, so wendet er das gleiche Prinzip mit Remove Connection an. 5 PROJEKTABLAUF Vorbesprechung Das Projekt begann mit der Besprechung des Funktionsumfangs sowie des Grundsystems, auf dem die von uns getrennt entwickelten Anwendungen basieren sollen. Ein Benutzer soll mit Hilfe eines Smartphones eine mit einem Beamer bestrahlte Fläche (oder ein großes Display) interaktiv nutzen können. Auf dieser Grundlage können dann weitere Applikationen entwickelt werden. Dabei sollte es möglich sein, sich frei vor dem Canvas bewegen zu können und durch das Deuten auf den Canvas mit diesem zu interagieren. Das Grundsystem wurde in mehreren Phasen entwickelt. Prototyp des minimalen Grundsystems Nachdem wir uns genauer mit dem Android Framework, dem Verarbeiten von Sensordaten sowie node.js zum Entwerfen des Server beschäftigt hatten, implementierten wir in Phase 1 die Kalibrierung des Canvas sowie das Verpacken der Sensordaten in UDP Pakete, welche an den Server verschickt werden. Der Server war zu diesem Zeitpunkt lediglich in der Lage, die Pakete von Smartphones an Webbrowser weiterzuleiten, welche per Websocket mit diesem verbunden sind. Eine kleine Javascript Bibliothek, welche jeder der Webbrowser beim Verbinden läd, zeichnet den Pfad der Bewegung, die der Benutzer mit dem Smartphone in Form einer Geste durchführte, nach. 5

6 Filtern der Sensordaten Da die Sensoren ungenaue Daten liefern, die insbesondere bei schnellen Bewegungen zu starken Ausreißern sorgen, versuchten wir in Phase 2 die Daten zu filtern, um bei Bewegungen glattere Kurven erzeugen zu können. Zuerst versuchten wir durch das Mitteln von n Datenpunkten starke Schwankungen zu filtern. Hierzu testeten wir unterschiedliche Werte für n, welche allerdings alle keine befriedigenden Ergebnisse erzeugten. Deshalb implementierten wir in einem weiteren Schritt einen Tiefpassfilter (siehe Abschnitt 3.1.1), welcher wesentlich bessere Daten generierte. Diese Methode wurde damit auch fester Bestandteil des Grundsystems. Freies Bewegen vor dem Canvas In der nächsten Phase sollte nun Code implementiert werden, welcher bei Bewegungen des Benutzers im Raum automatisch die Winkel zwischen Benutzer und Canvas anpasst. Nach ausführlicher Recherche entschieden wir uns diese Möglichkeit außen vor zulassen, sodass der Benutzer eine feste Position im Raum einnehmen muss, aus folgendem Grund: Um diese Funktion umzusetzen, wäre es nötig mit Hilfe der Sensoren festzustellen ob und wie weit sich der Benutzer von seiner Ausgangsposition bewegt hat. Leider sind die Sensorwerte hierfür zu ungenau, sodass sich diese Ungenauigkeit sehr schnell verstärkt. Möchte der Benutzer die Position verändern, ist deshalb eine Rekalibrierung nötig. Entwicklung unabhängiger Applikationen Nachdem die soeben beschriebenen Phasen beendet waren, war es möglich, dass zwei Applikationen auf Basis dieses Systems entwickelt werden konnten. Wir entschieden uns hierbei für ein Spiel Food Ninja als auch für eine Mind-Mapper Anwendung. Hierfür waren unterschiedliche Erweiterungen des Basissystems nötig. Erstens mussten je nach Applikation die Menge der in UDP-Paketen übertragenen Informationen erweitert werden (z.b weitere Aktionen). Ebenfalls mussten dadurch der Server als auch die vom Webbrowser geladene Javascript Bibliothek erweitert werden. Nutzerstudie Abschließend sollte das grundlegende Konzept der Interaktion mit einem Canvas, als auch beide von uns implementierte Applikationen mit einer Nutzerstudie evaluiert werden (siehe Abschnitt 6). Die Studie brachte uns Erkenntnisse über die Benutzbarkeit sowie vorhandene Schwachstellen. Ebenfalls erlangten wir durch die Diskussionen mit den Studienteilnehmern gute Vorschläge für Verbesserungen und Einsatzmöglichkeiten. 6 BENUTZERSTUDIE Wir implementierten zwei Beispielanwendungen um die Realisierbarkeit und die Benutzbarkeit unseres Systems zu bewerten. Ein Spiel Food Ninja und eine Applikation (Mind-Mapper). Wir führten die Benutzerstudie mit zehn männlichen Probanden, mit durchschnittlichem Alter von 25 Jahren (SD=3.37) durch, die hauptsächlich aus dem akademischen Bereich kamen. Die Benutzerstudie lief wie folgt ab: Die Probanden sollten nach einer kurzen Einweisung das Mobiltelefon mit der projizierten Anzeige kalibrieren und sich anschließend wenige Minuten mit der Bedienung des Systems vertraut machen. Danach starteten wir zufällig mit einer der Beispielanwendungen und baten die Probanden folgende Aufgaben zu erledigen. 6.1 Mind-Mapper Applikation Bei der Mind-Mapper Applikation mussten die Probanden zwei unterschiedliche Aufgaben absolvieren. Mit welcher der Proband anfing wurde ebenfalls zufällig gewählt. Eine Aufgabe bestand darin, dass dem Probanden eine erstellte Mind-Map gezeigt wurde und er diese modifizieren musste, indem er Knoten und Verbindungen löscht oder erstellt. Diese Modifikationen wurden von uns vorgegeben und waren bei jedem Probanden gleich. Die zweite Aufgabe bestand darin, dass der Proband innerhalb von vier Minuten zu unserem vorgegebenem Thema Urlaubsplanung eine Mind-Map erstellen musste. 6.2 Food Ninja Applikation In diesem Spiel geht es darum, dass der Spieler Punkte erhält, indem er die über den Bildschirm fliegenden Früchte zerschneidet und versucht den gelegentlich erscheinenden Bomben auszuweichen. Die Probanden wurden gebeten drei Runden zu spielen. Eine Runde ist vorbei, sobald der Proband eine Bombe zerschneidet. 6.3 Ergebnisse Um eine allgemeine Meinung über das System zu bekommen, haben wir einen Questionnaire for User Interaction Satisfaction (QUIS) Fragebogen verwendet. Darüber hinaus haben wir den standardisierten System Usability Score (SUS) Fragebogen benutzt um die Benutzbarkeit unseres Systems zu bewerten. Abschließend wurde die Benutzerstudie für jeden Probanden jeweils noch mit einem semistrukturierten Interview beendet. Abbildung 9: Durchschnittswerte des QUIS-Fragebogen für das generelle System (1=negativ bis 5=positiv) Abbildung 9 zeigt die durchschnittlichen Bewertungen der Probanden für das generelle System, die wir mit Hilfe des QUIS- Fragebogen erhalten haben. Der Durchschnitt für das Grundsystem liegt bei einer Bewertung von 3,20, wobei die Skalierung von 1=negativ bis 5=positiv angesetzt wurde. Besonders auffällig ist der höchste Wert von 3,90 bei der Bewertung für die Spannung und der niedrigste Wert bei Zufriedenstellend von 2,70. Diese Werte spiegeln auch genau unsere Meinung wieder, dass der Ansatz des Systems auf einem guten Weg ist und viele neue Interaktionsmöglichkeiten bietet, doch die Qualität der Sensordaten, die von den Mobiltelefonen geliefert werden, noch nicht ausreichend zufriedenstellend sind. Abbildung 10 zeigt die durchschnittlichen Bewertungen der Probanden speziell für die Mind-Mapper Applikation und die Food Abbildung 10: Durchschnittswerte des QUIS-Fragebogen für die Mind-Mapper und die Food Ninja Applikation (1=negativ bis 5=positiv) 6

7 Ninja Applikation, beide mittels QUIS-Fragebogen. Die Mind- Mapper Anwendung erhielt einen Durchschnittswert von 3,36 und die Food Ninja Applikation von 3,65. Hier gab es keine großen Ausschläge, ausgenommen die Bewertung der Spannung bei der Food Ninja Applikation von 4,40, welche deutlich über den anderen Werten liegt. Abbildung 11: Probanden mit ihren entsprechenden SUS-Werten Nach dem QUIS-Fragebogen baten wir die Probanden noch den SUS-Fragebogen auszufüllen. Der SUS-Wert jedes Probanden ist in Abbildung 11 dargestellt. Unser System hat einen durchschnittlichen SUS-Wert von 75,75 erreicht und liegt damit nur knapp unter der Grenze von 80 Prozent, ab der man von einem System mit guter bis exzellenter Benutzbarkeit spricht. Das semistrukturierte Interview unterstreicht nochmals die durch die Fragebögen erhaltenen Bewertungen. Auf die Frage, was den Probanden besonders an unserem System gefallen hat, betonten die meisten Studienteilnehmer die sehr intuitive Bedienung des Systems. Beispielsweise hat Proband 9 (P9) unser System mit der Wii verglichen und betonte damit die einfache Benutzung. Des Weiteren gefiel P2 die Anzeige eines Mauszeigers auf dem Bildschirm, wodurch die Interaktion nahezu selbsterklärend wird. P3 gefiel die direkte Übertragung der Gesten auf den Mauszeiger, genau wie P7. Alle Probanden, ausgenommen P8 und P10, kritisierten die ruckartigen Mauszeigerbewegungen. P1 und P3 schlugen für dieses Problem vor die Mauszeigerbewegung stärker zu glätten, indem man zum Beispiel nur die durchschnittliche Mauszeigerposition, innerhalb eines bestimmten Zeitfensters, auf den Bildschirm überträgt (P1). Weitere Hauptkritikpunkte waren die Verzögerung in der Mauszeigerbewegung (P2, P5, P8, P10) und die unbequeme Gestik, weil man nur das Handgelenk und nicht den kompletten Arm zur Interaktion bewegen darf (P1, P6, P7). Alle Probanden könnten sich vorstellen das System in Verbindung mit einem Public Display zu verwenden. P1, P2 und P9 sind der Meinung, dass das System besonders gut für Spiele geeignet ist, was auch durch den sehr hohen Wert des QUIS-Fragebogen bei der Spannung von 4,40 zusätzlich unterstrichen wird. Bis auf zwei Probanden können sich alle vorstellen das System auch zu Hause einzusetzen, besonders in Verbindung mit großen Bildschirmen, wie zum Beispiel projizierte Beamerflächen oder bei gleichzeitiger Interaktion mit mehreren Nutzern(P1). Auf die Frage, ob die Probanden sich weitere Arten von Anwendungen für das System vorstellen könnten, bekamen wir viel Resonanz. Beispiele dafür sind hauptsächlich Spiele (P1, P3, P6, P7, P9), Modellierungen von Diagrammen (P1, P3, P8) oder bei Pr sentationen (P1, P10). Außerdem wurde vorgeschlagen das System zu nutzen, sobald die Interaktion mit Bildschirmen eingeschränkt ist, da diese zu weit entfernt sind um eine berührungsbasierte Interaktion zu erlauben (P4, P9). Ein Beispiel dafür wäre die Möglichkeit zur interaktiven Essenszusammenstellung in einem Drive-In Schalter (P9). P6 und P9 betonten, dass das System besonders für Situationen, bei denen ein schneller Zugriff erforderlich ist, geeignet ist. 6.4 Diskussion Trotz der gelegentlichen Verzögerungen und Ruckeln des Mauszeigers bei schnellen Gesten, lobten die Studienteilnehmer überwiegend das System auf Grund der intuitiven Interaktionsmöglichkeiten und der sehr schnellen und einfachen Einrichtung. Obwohl in unserem System durch die Sensoren und die notwendige Internetverbindung zwei eher unzuverlässige Komponenten enthalten sind, überwiegt die komfortable und einfache Registrierung des eigenen Mobiltelefons mit jeder, mit dem Internet verbundenen, digitalen Anzeige. Da das System bisher nur mit dem Beschleunigungs- und Magnetfeldsensor arbeitet, muss der Benutzer nach der Kalibrierung auf einer fixen Position stehen und die Gesten für die Interaktionen dürfen nur aus dem Handgelenk erfolgen, da es sonst schon nach kurzer Zeit zu starken Ungenauigkeiten kommt. 7 FAZIT UND FUTURE WORK Wir entwickelten ucanvas um jeden Bildschirm mit Internetverbindung interaktiv nutzen zu können. Interaktionen beinhalten das Deuten auf die Bildschirmfläche um einen Mauszeiger bewegen zu können, selektieren, Menüauswahl als auch das Erzeugen von Texteinträgen. Aufgrund der Allgegenwart von Smartphones, entschieden wir uns für den Einsatz des Magnetfeldsensor, sowie des Beschleunigungssensor, um eine natürliche Interaktion möglich zu machen, ohne dazu zusätzlich Hardware zu benötigen. Nachdem wir zwei Applikationen implementiert hatten, führten wir abschließend eine Studie mit zehn Teilnehmern durch, um die Einfachheit und Benutzbarkeit bewerten zu können. Zukünftige Erweiterungen des Systems werden eine automatische Canvas Kalibrierung durch genaue GPS Lokalisierung beinhalten, wodurch der Benutzer sich nicht mehr um die Registrierung und Kalibrierung kümmern müsste. Ebenfalls wäre es denkbar, den Benutzer nicht mehr an eine statische Position zu binden, hierfür müssten allerdings zukünftige Smartphones akkuratere Sensorwerte berechnen. Des Weiteren ist in Zusammenarbeit mit unserem Betreuer ein Paper entstanden, welches als Note bei der Konferenz CHI2014 (chi2014.acm.org) eingereicht wurde. In diesem Paper wird die native Applikation durch eine mobile Web-Applikation ersetzt, wodurch keine umständliche Installation einer App mehr nötig ist, sondern nur noch eine HTML5-Webseite besucht werden muss. Hierfür wurde ebenfalls ein Einführungsvideo erstellt, welches die Grundkonzepte des Systems vorstellt. REFERENCES [1] R. Ballagas, M. Rohs, and J. G. Sheridan. Sweep and point and shoot: phonecam-based interactions for large public displays. In CHI 05 extended abstracts on Human factors in computing systems, pages ACM, [2] R. A. Bolt. Put-that-there: Voice and gesture at the graphics interface. In Proceedings of the 7th annual conference on Computer graphics and interactive techniques, SIGGRAPH 80, pages , New York, NY, USA, ACM. [3] S. Boring, M. Jurmu, and A. Butz. Scroll, tilt or move it: using mobile phones to continuously control pointers on large public displays. In Proceedings of the 21st Annual Conference of the Australian Computer- Human Interaction Special Interest Group: Design: Open 24/7, pages ACM, [4] R. L. Dahl. node.js [Online; accessed 17-Oktober-2013]. [5] K. Derthick, J. Scott, N. Villar, and C. Winkler. Exploring smartphonebased web user interfaces for appliances. In Proceedings of the 15th international conference on Human-computer interaction with mobile devices and services, pages ACM, [6] R. Hardy and E. Rukzio. Touch & interact: touch-based interaction of mobile phones with displays. In Proceedings of the 10th international conference on Human computer interaction with mobile devices and services, pages ACM, [7] M. Weiser. The computer for the 21st century. Scientific american, 265(3):94 104,