Multi-Touch im Browser eines Tabletop-PCs - Projects

Transcrição

Multi-Touch im Browser
eines Tabletop-PCs
Frameworks, Einsatzmöglichkeiten und Einschränkungen
Diplomarbeit
Ausgeführt zum Zweck der Erlangung des akademischen Grades
Dipl.-Ing. für technisch-wissenschaftliche Berufe
am Masterstudiengang Digitale Medientechnologien an der
Fachhochschule St. Pölten, Vertiefungsrichtung Angewandte Medieninformatik.
Martin Christoph Grubinger, BSc
dm101513
Erstbegutachter und Betreuer: FH-Prof. Dipl.-Ing. Markus Seidl
Zweitbegutachter: Dipl.-Ing. Dr. Peter Judmaier
St. Pölten, 08.08.2012
Ehrenwörtliche Erklärung
Ich versichere, dass
- ich diese Diplomarbeit selbständig verfasst, andere als die angegebenen Quellen und
Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfe bedient habe.
- ich dieses Diplomarbeitsthema bisher weder im Inland noch im Ausland einem
Begutachter/einer Begutachterin zur Beurteilung oder in irgendeiner Form als
Prüfungsarbeit vorgelegt habe.
Diese Arbeit stimmt mit der vom Begutachter bzw. der Begutachterin beurteilten Arbeit überein.
.........................................
.........................................
Ort, Datum
Unterschrift
I
Kurzfassung
Die Verwendung von Multi-Touch als Eingabemethode hat in den letzten Jahren stark zugenommen. Neben Mobiltelefonen verwenden auch Tabletop-PCs Multi-Touch und Gesten für
die Interaktion der Benutzer/innen mit dem System. Die Entwicklung von Software für Tabletop-PCs wird derzeit vorwiegend mit traditionellen Softwareentwicklungswerkzeugen realisiert, woraus eine hohe Plattform- und Geräteabhängigkeit resultiert.
Die Technologien im Umkreis von HTML5 und CSS3 ermöglichen die Ausführung umfangreicher Webanwendungen und Spiele im Webbrowser ohne zusätzliche Plug-ins. Zudem unterstützen immer mehr Browser Zugriff auf Touchinformationen des Systems. Aufgrund dieser
Entwicklungen wird in dieser Arbeit untersucht, ob der Browser des Tabletop-PCs eine Plattform für ansprechende, gestenbasierte Multi-Touch-Applikationen darstellt und als Alternative zu Multi-Touch-fähiger Desktopsoftware betrachtet werden kann.
Um diese Frage zu beantworten, wurden die Fähigkeiten moderner Webbrowser zur Verarbeitung von Multi-Touch-Events untersucht und unterschiedliche Frameworks evaluiert, die bei
der Entwicklung derartiger Anwendungen und webbasierten Animationen unterstützen. Unter
Verwendung des Frameworks jQMultiTouch, das browserspezifische Touchevent-APIs vereinheitlicht und Gestenerkennung durchführt, wurde ein Prototyp eines einfachen MultiTouch-Spiels entwickelt. Anhand eines Benutzertests dieses Prototyps wurde die Verwendbarkeit von gestenbasierten Multi-Touch-Applikationen auf Basis von Webtechnologien evaluiert.
Im Test dieses Prototyps konnte die generelle Verwendbarkeit gezeigt werden, jedoch wurden
Einschränkungen hinsichtlich der Performance sowie der Anzahl der unterstützten Berührungspunkte festgestellt. Aufgrund dieser Einschränkungen sind Browser derzeit nur für die
Ausführung von einfachen gestenbasierten Multi-Touch-Anwendungen auf TabletopSystemen geeignet. Für Multi-User-Anwendungen mit hohen Grafikanforderungen und komplexen Gesten sind Webbrowser (noch) nicht geeignet.
II
Abstract
Usage of multi-touch input has seen a considerable increase in recent years. Besides mobile
phones, also tabletop PCs employ multi-touch and gestures for the interaction between users
and the system. Currently software for tabletop PCs is mainly developed using traditional software development tools resulting in high platform and device dependency.
The technologies commonly refered to as HTML5 and CSS3 allow rich Web applications and
games to run in Web browsers without using plug-ins. Additionally, more and more browsers
support access to touch information sent by the system. As a result of these developments, this
thesis seeks to answer the question, whether the browser of tabletop systems represents a platform for engaging gesture-based multi-touch applications and can be considered an alternative
to multi-touch-enabled desktop software.
In order to answer this question, the capabilities of modern Web browsers for handling multitouch events were analyzed and different frameworks for developing such applications and
Web-based animations were evaluated. Using the jQMultiTouch framework, which provides
unification of browser-specific Touch Event-APIs and gesture-recognition, a prototype for a
simple multi-touch game was developed. Based on this prototype a user test was conducted to
evaluate the applicability of gesture-based multi-touch applications built with Web technologies.
By testing this prototype, we showed the general applicability, but constraints regarding the
performance and the number of supported touch points were identified. As a result of these
limitations, currently browsers are only suitable for relatively simple gesture-based multi-touch
applications on tabletop systems. Web browsers are not (yet) suitable for graphics-intensive
multi-user applications with complex gestures.
III
Inhaltsverzeichnis
Ehrenwörtliche Erklärung .......................................................................................................... I
Kurzfassung ................................................................................................................................II
Abstract ..................................................................................................................................... III
1 Einleitung................................................................................................................................1
2 Grundlagen von Multi-Touch und Gestural Interfaces ......................................................4
2.1 Multi-Touch ............................................................................................................................... 4
2.2 Gestural Interfaces..................................................................................................................... 5
2.3 Hardware .................................................................................................................................... 9
2.3.1
Microsoft PixelSense (vormals Surface 2) ................................................................................................................... 9
2.3.2
PQLabs Overlays ........................................................................................................................................................... 10
2.3.3
Ideum Platform ............................................................................................................................................................. 11
2.3.4
Eigenbau Möglichkeiten (DIY)................................................................................................................................... 12
2.4 Protokolle und Multi-Touch-Integration in Desktop-Betriebssystemen ....................... 17
2.4.1
TUIO Protokoll ............................................................................................................................................................. 17
2.4.2
Microsoft Windows 7 Touch Events.......................................................................................................................... 18
2.4.3
Mac OS X Multi-Touch ............................................................................................................................................... 19
2.4.4
Ubuntu uTouch ............................................................................................................................................................. 19
2.5 Frameworks für die Entwicklung von nativen Multi-Touch-Applikationen ................. 20
2.5.1
MT4j (Java) .................................................................................................................................................................... 22
2.5.2
Surface 2.0 SDK (.NET) ............................................................................................................................................... 22
2.5.3
GestureWorks und OpenExhibits SDK (Flash) ....................................................................................................... 23
2.5.4
Weitere Frameworks .................................................................................................................................................... 24
3 Multi-Touch im Browser .....................................................................................................25
3.1 Relevante clientseitige Webtechnologien ............................................................................. 27
3.1.1
HTML(5) ........................................................................................................................................................................ 27
3.1.2
Audio und Video Unterstützung................................................................................................................................ 31
3.1.3
Canvas und WebGL...................................................................................................................................................... 31
3.1.4
Fullscreen API ............................................................................................................................................................... 34
3.1.5
JavaScript, jQuery und JSON ...................................................................................................................................... 34
3.1.6
CSS(3) ............................................................................................................................................................................. 37
3.2 Touchevents und deren Unterstützung in aktuellen Browserversionen......................... 42
3.2.1
Mobile Endgeräte .......................................................................................................................................................... 43
3.2.2
W3C Touch Events ....................................................................................................................................................... 44
3.2.3
Mozilla Touch Events ................................................................................................................................................... 46
3.2.4
Microsoft Pointer Events (IE10) ................................................................................................................................. 47
3.2.5
Touchevents in Google Chrome ................................................................................................................................. 49
3.3 Frameworks und Tools für die Entwicklung von webbasierten Multi-TouchApplikationen ................................................................................................................................... 50
3.3.1
Grundsätzliche Anforderungen an ein webbasiertes Multi-Touch-Framework................................................. 50
3.3.2
Hammer.js ...................................................................................................................................................................... 51
3.3.3
Hummer.js ..................................................................................................................................................................... 53
IV
3.3.4
jQMultiTouch................................................................................................................................................................ 54
3.3.5
Weitere Optionen für die Verwendung von Multi-Touch-Daten im Browser .................................................. 57
3.3.6
Simulatoren für Multi-Touch-Eingabe...................................................................................................................... 59
3.3.7
Tools und Frameworks zur Erstellung von webbasierten Animationen .............................................................. 61
4 Umsetzung eines Prototyps .................................................................................................65
4.1 Ausgangssituation ................................................................................................................... 66
4.1.1
Valcamonica .................................................................................................................................................................. 66
4.1.2
Playing Valcamonica .................................................................................................................................................... 67
4.1.3
Module............................................................................................................................................................................ 69
4.1.4
Technische Umsetzung und Zielplattform ............................................................................................................... 70
4.2 Spielbeschreibung.................................................................................................................... 70
4.3 Vorgehensweise ....................................................................................................................... 72
4.4 Umsetzung mit jQMultiTouch .............................................................................................. 74
4.4.1
Struktur und Inhalt mit HTML5 ................................................................................................................................ 74
4.4.2
Visuelle Erscheinung mit CSS ..................................................................................................................................... 76
4.4.3
Funktionalität mit JavaScript ...................................................................................................................................... 77
4.4.4
Endanimation mit JavaScript und GSAP .................................................................................................................. 82
4.5 Test des Prototyps ................................................................................................................... 83
4.5.1
Testsetup ........................................................................................................................................................................ 83
4.5.2
Testablauf ....................................................................................................................................................................... 84
5 Ergebnisse .............................................................................................................................85
5.1 Ergebnisse der allgemeinen Kriterien ................................................................................... 85
5.1.1
Fähigkeiten aktueller Browser zur Verarbeitung von Touchevents ...................................................................... 85
5.1.2
Performance aktueller Browser bei Multi-Touch- und Gesteninteraktionen .................................................... 85
5.1.3
Verfügbarkeit von Frameworks für Multi-Touch-Gestensteuerungen ................................................................ 86
5.1.4
Verfügbarkeit von Werkzeugen zur Erstellung von webbasierten Animationen .............................................. 87
5.1.5
Verfügbarkeit von unterstützenden Werkzeugen.................................................................................................... 88
5.2 Ergebnisse des Tests des Prototyps ....................................................................................... 90
5.2.1 Wie verhält sich die Webapplikation bei der Bedienung von einer Person im Vergleich mit der FlashApplikation? ................................................................................................................................................................................ 90
5.2.2 Wie verhält sich die Webapplikation bei der gleichzeitigen Bedienung von vier Personen (Multi User) im
Vergleich mit der Flash-Applikation? ..................................................................................................................................... 91
5.2.3
Ab welcher Belastung sind Performanceprobleme deutlich erkennbar?............................................................. 91
5.2.4
Tritt Fehlverhalten bei der Verwendung von Gesten auf?...................................................................................... 91
5.2.5 Welchen subjektiven Eindruck erhalten Benutzer/innen hinsichtlich der Qualität der Interaktion und der
visuellen Darstellung des Spiels? .............................................................................................................................................. 92
5.3 Use Cases .................................................................................................................................. 93
6 Conclusio ..............................................................................................................................95
7 Anhang ..................................................................................................................................97
Anhang A: Quellenverzeichnis ....................................................................................................... 97
Anhang B: Abbildungsverzeichnis ............................................................................................... 102
Anhang C: Tabellenverzeichnis .................................................................................................... 103
Anhang D: Listingverzeichnis ....................................................................................................... 103
V
1
Einleitung
Tap, Swipe, Drag. Durch die zunehmende Verbreitung von Multi-Touch-fähigen Geräten und
die Steuerung vieler Anwendungen über Gesten haben diese Begriffe in den letzten Jahren unseren Wortschatz erweitert. Im Zusammenhang mit der Interaktion eines Benutzers mit einem
Multi-Touch-System reichen die herkömmlichen Begriffe für die Beschreibung von Interaktionsmechanismen nicht mehr aus. Die Steuerung unserer Mobiltelefone und Tablet- oder Notebook-Computer mittels Gesten ist in den letzten Jahren beinahe zur Selbstverständlichkeit
geworden 1. Mit Produkten wie Microsoft’s PixelSense 2 wird diese Art der Interaktion auch für
großflächige, in Tischen integrierte Bildschirme verwendet. Eine locker durchgeführte Geste
genügt, um Inhalte zu vergrößern, das nächste Foto anzusehen oder durch lange Listen zu
scrollen.
Gleichzeitig werden immer komplexere Anwendungen für die Ausführung im Browser entwickelt. Spiele, die vor einigen Jahren die Grenzen der Leistungsfähigkeit von Computerhardware
ausreizten, werden heute direkt im Browser dargestellt. Auch Officeanwendungen oder interaktive Musikvideos werden auf Basis von Webtechnologien direkt für die Verwendung und
Darstellung im Browser entwickelt. Die Technologien hinter diesem Trend sowie die Webbrowser sind ständig im Wandel begriffen und werden mit sehr kurzen Releaseabständen weiterentwickelt. Im Umfeld der Schlagworte HTML5 und CSS3 entstehen Technologien, die es
ermöglichen, Applikationen für das Web zu entwickeln, die noch vor wenigen Jahren ohne die
Verwendung zusätzlicher Plug-ins undenkbar gewesen wären. Ein Hinweis auf diese Entwicklung ist die breite Auswahl an Applikationen, die im Chrome Web Store 3 zur Ausführung im
Browser zur Verfügung stehen.
Diese beiden Entwicklungen, die bereits jetzt die Arbeitsweise der Benutzer/innen stark beeinflusst haben, legen den Schluss nahe, dass auch immer komplexere Multi-TouchApplikationen direkt im Browser ohne zusätzliche Plug-ins oder Runtimes möglich sind. Derzeit werden Multi-Touch-Anwendungen mit Gestenunterstützung meist als Desktopapplikationen auf Basis von traditionellen Softwareentwicklungswerkzeugen und Programmiersprachen
wie C++, C# oder ActionScript umgesetzt und sind daher als eigenständige Anwendung auszuführen. Desktopapplikationen für mehrere Plattformen zu entwickeln ist mit hohem Aufwand
und hohen Abhängigkeiten zu anderen Softwarebibliotheken verbunden.
1
Laut einer Studie von Canalys waren bereits im letzten Quartal 2009 weltweit erstmals mehr als die Hälfte
der verkauften Smartphones mit einem Touch-Screen ausgestattet, wobei Apple-Produkte etwa ein Drittel
dieser Smartphones darstellen. (Canalys, 2010) Eine weitere Studie der Gartner Group zeigt, dass 2011
57,9% der verkauften Smartphones auf den auf (Multi-)Touch-Interaktionen basierenden Betriebssytemen
Apple iOS und Google Android basieren. (Pettey, 2011)
2
http://www.pixelsense.com, siehe Kapitel 2.3.1
3
https://chrome.google.com/webstore
1
Einleitung
Vor allem auf Smartphones und Tablet-PCs werden Touchinformationen bereits zur Interaktion mit dem Browser und der dargestellten Websites verwendet. Meist beschränken sich dabei
die verwendeten Gesten auf einen Finger und simulieren nur die Funktionalität der Maus
(Klick, Doppelklick, Ziehen, ...). Auch Softwarebibliotheken, die ausdrücklich für die Erstellung von webbasierten touch-optimierten Benutzerschnittstellen konzipiert sind, sind stark auf
die Bedienung mit nur einem Finger fokussiert und verwenden damit Interaktionsmechanismen, die mehr die Metaphern der klassischen PC-Maus anstatt fortgeschrittene Gestensteuerung verwenden.
Multi-Touch-Anwendungen mit Webtechnologien zu realisieren bietet einige Vorteile gegenüber Desktopanwendungen. Webapplikationen besitzen durch die zugrunde liegenden Technologien eine hohe Geräte- und Plattformunabhängigkeit sowie einfache Verbreitungsmöglichkeiten. Eine äußerst aktive, globale Entwickler/innencommunity ist an der Weiterentwicklung von Webtechnologien und moderner Browser interessiert. Browserhersteller integrieren in kurzen Releaseabständen neue Technologien im Umfeld von HTML5 und verbessern
die Leistungsfähigkeit für die Darstellung von aufwändigen Grafiken und Animationen. Eine
Reihe von Werkzeugen vereinfacht zudem die Erstellung von Ani-mationen auf Basis von
Webtechnologien.
Die vorliegende Diplomarbeit untersucht die aktuellen Möglichkeiten zur Erstellung von gestenbasierenden Multi-Touch-Applikationen auf Basis von Webtechnologien. Die Zielplattform
für diese Applikationen sind primär Multi-Touch Tabletop-PCs: interaktive, Multi-Touchfähige Oberflächen in tischähnlicher Bauweise.
Ziel dieser Arbeit ist es, festzustellen, ob und in welchem Ausmaß mit dem derzeitigen Stand
der Technik Multi-Touch-Applikationen mit Gestensteuerung unter Verwendung von clientseitigen Webtechnologien realisierbar sind.
Die leitende Forschungsfrage ist: Kann der Browser eines Tabletop-PCs eine Plattform für ansprechende, gestenbasierte Multi-Touch-Applikationen darstellen und als Alternative zu Multi-Touch-fähiger Desktopsoftware betrachtet werden?
Kriterien, die zur Beantwortung der Frage beitragen, sind:
•
die Fähigkeiten aktueller Browser zur Verarbeitung von Touchevents
•
die Verfügbarkeit von Frameworks für Multi-Touch-Gestensteuerungen
•
die Performance aktueller Browser bei Multi-Touch- und Gesteninteraktionen
•
die Verfügbarkeit von Werkzeugen zur Erstellung von webbasierten Animationen
•
die Verfügbarkeit von unterstützenden Werkzeugen
Zur Beantwortung der Forschungsfrage trägt ein praktisches Experiment bei. Ein Modul einer
bereits entwickelten Multi-Touch-fähigen Desktop-Applikation wurde im Zuge dieser Arbeit
mit clientseitigen Webtechnologien umgesetzt. Die Applikation wurde ursprünglich für eine
2
Einleitung
Museumsausstellung auf Basis der Adobe Flash/AIR Plattform programmiert und wird im
Flash Player auf einem Tabletop-PC ausgeführt. Anhand dieses praxisnahen Versuchs werden
die Möglichkeiten zur Entwicklung von Multi-Touch-Applikationen für den Browser beleuchtet und auftretende Schwierigkeiten oder Einschränkungen dargestellt. Folgende Fragen werden in einem Test der Webapplikation mit mehreren Benutzern beantwortet:
•
Wie verhält sich die Webapplikation bei der Bedienung von nur einer Person (Single
User) im Vergleich mit der Flash-Applikation?
•
Wie verhält sich die Webapplikation bei der gleichzeitigen Bedienung von vier Personen (Multi User) im Vergleich mit der Flash-Applikation?
•
Ab welcher Belastung sind Performanceprobleme deutlich erkennbar?
•
Tritt Fehlverhalten bei der Verwendung von Gesten auf?
•
Wie ist der subjektive Eindruck hinsichtlich der Qualität der Interaktion und der visuellen Darstellung des Spiels?
In Kapitel 2 werden Grundlagen von Multi-Touch und Gestural Interfaces behandelt und
Hardware, Protokolle und Frameworks zur Entwicklung von Multi-Touch-Applikationen beschrieben. Relevante clientseitige Webtechnologien, die Verfügbarkeit von Touchinformationen im Browser sowie Frameworks für web- und gestenbasierte Multi-Touch-Anwendungen
und Animationen werden in Kapitel 3 diskutiert. In Kapitel 4 werden der Prototyp sowie dessen Umsetzung und die Vorgehensweise bei der Entwicklung dargestellt. Zudem wird das Setup des Tests des Prototyps beschrieben. Kapitel 5 beinhaltet die Ergebnisse der theoretischen
Auseinandersetzung und des Tests anhand der beschriebenen Kriterien und Fragen.
3
2
Grundlagen von Multi-Touch und
Gestural Interfaces
Um einen Überblick über das Themengebiet zu verschaffen, werden in diesem Kapitel grundlegende Begriffe und Technologien sowie Interaktionskonzepte erläutert. Multi-Touch wird
aus technischer Sicht behandelt, um ein Verständnis für die aus der jeweiligen Hard- und
Software resultierenden Eigenschaften zu schaffen. Aufgrund der technologischen Möglichkeiten von Multi-Touch-Interfaces gelten auch für das Interaktionsdesign andere Paradigmen und
Überlegungen, um einfach und effizient zu bedienende Gestural Interfaces zu schaffen.
2.1 Multi-Touch
Multi-Touch (engl. mehrfach berühren) ist ein Sammelbegriff für Geräte, die die Berührung
von mehreren Fingern auf einer berührungsempfindlichen Oberfläche erkennen. Diese Technologien verarbeiten die Positionsdaten der einzelnen Berührungspunkte und ermöglichen so
die Interaktion eines Benutzers mit einem System unter Verwendung von mehr als einem Finger (Han, 2005).
Diese Form der Eingabemöglichkeit wurde mit der Einführung des Apple iPhones im Jahr
2007 erstmals in einem massentauglichen Produkt verwendet4. Auch wenn im öffentlichen
Diskurs die Interaktionsmöglichkeiten des iPhones als innovativ galten, fanden bereits 1982 die
ersten Forschungen und Experimente zum Thema Multi-Touch an der University of Toronto,
Kanada, und den Bell Laboratories statt. Auch mit der weit verbreiteten Geste Pinch (engl.
kneifen; siehe Kapitel 2.2) wurde bereits 1983 experimentiert (Buxton Bill, 2009, S. 4).
Große Aufmerksamkeit erfährt der Technologie auch im Jahr 2005, als Jefferson Han die Interaktion mit einem Multi-Touch-Screen in der Größe von etwa 40x30cm vorstellt. Han beschreibt den Aufbau seines Systems genau und ermöglicht Entwickler/innen mit relativ wenig
Kapitalaufwand große Multi-Touch-fähige Oberflächen zu bauen (Han, 2005).
Seit der erwähnten Markteinführung des iPhones stieg die Zahl der mit Multi-Touch-Screens
ausgestatteten Mobiltelefone rasant an und ist heute der de-facto Standard für sogenannte
Smartphones. Laut einer Studie von Gartner, Inc. beträgt der weltweite Anteil an verkauften
Mobiltelefonen mit den auf (Multi-)Touch basierenden Betriebsystemen iOS und Android im
Jahr 2011 57,9% (Pettey, 2011).
4
Apple patentierte die Technologie, mit mehreren Fingern den Inhalt eines Seitenausschnittes zu bewegen
und ließ den Begriff Multi-Touch als Marke eintragen (Tolmasky, 2011).
4
Grundlagen von Multi-Touch und Gestural Interfaces
Nicht nur am Mobiltelefonmarkt nimmt die Verwendung von Multi-Touch-Technologien zu.
Nach sechs Jahren Forschung zum Thema Multi-Touch veröffentlichte Microsoft im Jahr 2007
den Multi-Touch-Tisch Surface (Buxton Bill, 2009; Whorley, 2011). Surface ist ein interaktiver
Tisch mit einem 30-Zoll Multi-Touch-fähigen Display, das nicht nur mehrere Finger sondern
auch mit speziellen Markern versehene Objekte erkennt. Anfang 2012 startete Microsoft mit
dem Vertrieb der zweiten Generation des Surface. Surface 2.0 wurde gemeinsam mit Samsung
entwickelt. Der Tisch mit dem Produktnamen SUR40 besitzt ein 40-Zoll Display und kann wie
die erste Generation auch Objekte erkennen, ist aber mit etwa 10 cm Tiefe ungefähr so flach
wie ein Fernseher (siehe Kapitel 2.3.1) (Microsoft (Hg.), o. J.-a).
2.2 Gestural Interfaces
Mit Multi-Touch als neue Eingabemöglichkeit ergeben sich neue Herausforderungen für das
Interaktionsdesign einer Software. Klassische Muster der Interaktion zwischen Mensch und
Computer wie Point-and-Click funktionieren in einer Multi-Touch-Umgebung nur bedingt.
Viele Interaktionsmechanismen im Zusammenhang mit Multi-Touch-Interfaces werden im
Fachjargon als Gesten bezeichnet.
„A gesture […] is any physical movement that a digital system can sense and respond to without
the aid of a traditional pointing device such as a mouse or stylus.” (Saffer, 2009)
Benutzerschnittstellen, die primär Gesten als Eingabemöglichkeit verwenden, werden Gestural
Interfaces genannt. Seit einigen Jahren nehmen Geräte mit Gestural Interfaces einen immer
größeren Platz im Arbeitsalltag und in Freizeitaktivitäten ein. Die meisten Smartphones und
immer mehr Desktop-Betriebssysteme sind – wie in Kapitel 2.1 beschrieben – Multi-Touchfähig und werden in unterschiedlichem Ausmaß über Gesten gesteuert. Auch in der Unterhaltungsindustrie erzielte Nintendo mit der Spielekonsole Wii, die über bewegungsempfindliche
Controller gesteuert wird, einen großen Erfolg.
Microsoft geht noch einen Schritt weiter und veröffentlichte im Herbst 2010 mit Microsoft
Kinect einen Sensor für die Spielekonsole XBOX 360, der die Bewegungen des gesamten Körpers des/der Spielers/Spielerin misst und in Gesten übersetzt. Microsoft bewirbt die Kinect mit
dem Slogan „Du bist der Controller“, der Körper des Spielers wird somit zum Interface
(Microsoft (Hg.), o. J.-b).
Gestural Interfaces, die auf Touch bzw. Multi-Touch basieren, werden als Touch User Interfaces (TUIs) bezeichnet (Saffer, 2009, S. 4). Dieser Begriff kann allerdings zu Missverständnissen führen, da TUI auch als Abbreviatur für Tangible User Interfaces (greifbare
Benutzerschnittstellen) verwendet wird.
5
Eine weitere Bezeichnung im Zusammenhang mit Gestural Interfaces ist Natural User Interface. Dieser Begriff stellt einen Hinweis auf eine vom Benutzer als sehr natürlich und authentisch empfundene User Experience 5 dar. In der Fachliteratur wird dieser Terminus allerdings
auch kritisiert, da Gesten häufig nicht intuitiv erlernbar sind und nur für wenig komplexe Aufgaben verwendet werden können. (Norman, 2010; Wigdor & Wixon, 2011, S. 14)
Verbreitete Gesten für Multi-Touch-Interfaces
Gesten für Multi-Touch-Applikationen bestehen aus bestimmten Bewegungsabläufen eines
oder mehrerer Finger auf der Oberfläche des Geräts. Diese Bewegungsabläufe weisen eine
mehr oder weniger stark ausgeprägte Komplexität auf, da einige Parameter (je nach Fähigkeiten des Hardwaresystems) kombiniert werden können um eine Geste zu definieren:
•
Anzahl der Finger auf der Oberfläche
•
Abstand der Finger zueinander
•
Winkel der Finger zueinander
•
Bewegungsmuster einzelner Finger
•
Anpress-Druck der Finger
•
unveränderte Positionen einzelner Finger
•
Dauer der Berührung
Aufgrund der vielfältigen Kombinationsmöglichkeiten, die sich aus diesen Parametern ergeben, ist es essentiell für eine gute User Experience, die richtige Geste für eine Aktion auszuwählen oder zu definieren. Bill Buxton (2009) beschreibt die Notwendigkeit, beim Design eines
Gestural Interfaces über die Bedürfnisse der Benutzer genau zu kennen ein. In nicht allen Fällen sind demnach Multi-Touch Gesten die sinnvollste Art der Interaktion.
Für den Einsatz auf Multi-Touch Screens hat sich in den letzten Jahren ein relativ kleines Repertoire (im Hinblick auf die Möglichkeiten) an intuitiv verwendbaren Gesten etabliert. Das
Ausmaß der Intuitivität der nachfolgenden Gesten ist sehr unterschiedlich. Während manche
Gesten eine logische Konsequenz bekannter Metaphern (z.B. der Bedienung einer Maus) darstellen, haben andere Gesten über eine weite Verbreitung in Consumer-Produkten unser Verständnis von Interaktion geprägt und werden deshalb als „intuitiv“ wahrgenommen. Die
weiteren Auswirkungen dieser Problematik für das Interaktionsdesign eines Systems werden in
dieser Arbeit nicht weiter behandelt.
5
Als User Experience (UX) wird das Nutzungserlebnis bei der Interaktion mit einem System bezeichnet. Eine
gute UX geht dabei über das erfolgreiche Erfüllen von Aufgaben (Usability) hinaus und betrachtet die gesamte Interaktion, die Gedanken, Gefühle und Wahrnehmungen eines Benutzers mit dem System. (Tullis &
Albert, 2008, S. 4)
6
Folgende Gesten und die entsprechende Reaktion des Systems können als Gebrauchsmuster
für das Interaction Design einer Multi-Touch-Applikation verwendet werden:
Tap to open/activate/select
Eine Berührung auf ein bestimmtes Objekt/eine bestimmte Region
der Oberfläche löst eine der folgenden Aktionen aus: Öffnen, Aktivieren, Auswählen. Dies ist die einfachste Geste und der direkte
Ersatz für einen Mausklick. Erweiterungen dieser Geste sind Double
Tap (ein doppeltes Berühren eines Objektes in kurzem Zeitabstand)
und Tap and Hold (eine lang andauernde Berührung eines Objektes
ohne den Finger zu bewegen).
Drag to move object
Ein am Bildschirm dargestelltes Objekt wird mit einem Finger berührt und an eine neue Position verschoben.
Slide to scroll
Mit der Bewegung eines Fingers wird eine Liste oder dgl. am Bildschirm bewegt um weitere Einträge anzuzeigen.
Spin to scroll
Durch das kreisförmige Bewegen eines Fingers werden weitere
Elemente einer Liste angezeigt.
Slide and hold for continuous scroll
Bei dieser Geste wird der Bildschirminhalt nach einer Drag-Geste
so lange weiter bewegt, bis der Finger von der Oberfläche entfernt
wird.
7
Flick to nudge
Durch eine kurze, ruckartige Bewegung eines Fingers wird der Bildschirminhalt oder ein Objekt am Bildschirm in die Richtung der
Bewegung verschoben.
Tap to stop
Ein in Bewegung befindliches Objekt wird durch eine einfache Berührung (Tap) gestoppt.
Two Fingers to Scroll
Werden zwei Finger nebeneinander in die gleiche Richtung bewegt,
so wird der Inhalt einer Liste oder ein Objekt am Bildschirm verschoben, um weiteren Inhalt anzuzeigen.
Pinch to shrink / spread to enlarge
Durch die Bewegung zweier Finger zueinander oder voneinander
weg wird das Objekt oder der unter den Fingern befindliche Bereich proportional skaliert. Wird die Distanz zwischen den Fingern
erhöht, so wird das Objekt vergrößert; wird die Distanz verringert,
verkleinert sich auch das Objekt.
Rotate
Durch eine gleichzeitige, kreisartige Bewegung zweier Finger auf
einem Objekt wird das Objekt in die Richtung rotiert, in die sich die
Finger bewegen. Diese Geste wird häufig mit Pinch to shrink /
spread to enlarge kombiniert, so dass ein Objekt gleichzeitig gedreht und verkleinert bzw. vergrößert werden kann.
Tabelle 1: Gebrauchsmuster für die Verwendung von Multi-Touch-Gesten
(Hinrichs & Carpendale, 2011; Saffer, 2009, S. 46–68). llustrationen von (GestureWorks (Hg.),
o. J.))
Wie Wu und seine Mitautoren (2006) darstellen, bestehen Gesten aus drei Phasen: Gesture
Registration, Gesture Continuation und Gesture Termination. In der ersten Phase (Registrati-
8
on) berühren die Finger die Oberfläche und verlassen damit den Out of Range-Bereich des
Gerätes. Während der zweiten Phase (Continuation) erfolgt ein Bewegungsablauf in der dritten
Phase (Termination) endet die Berühung der Oberfläche (vgl. Abbildung 1; (Wigdor & Wixon,
2011, S. 127; Wu u. a., 2006).
Abbildung 1: Drei Phasen einer Geste: Registration, Continuation, Termination
2.3 Hardware
Aufgrund der hohen Kosten war die Hardware für Multi-Touch Tabletop-Systeme über viele
Jahre hinweg Mitarbeitern von Forschungslaboren und Universitäten vorbehalten. Seit der
Veröffentlichung von Jeff Han‘s Bauanleitung für eine kostengünstige Multi-Touch-Oberfläche
(Han, 2005) und der enormen Popularität des reacTables (Jordà, Geiger, Alonso, & Kaltenbrunner, 2007) im Jahr 2007 finden sich im World Wide Web zahlreiche Anleitungen mit
denen engagierte Bastler mit nur relativ geringen Kosten ein Multi-Touch-Tisch bauen können. Die höhere Rechenleistung von handelsüblichen PCs ermöglicht eine schnellere Verarbeitung von Videodaten, damit wird Multi-Touch-Erkennung mit herkömmlicher PC-Hardware
möglich. Die Open Source-Community stellt zusätzlich zahlreiche Trackinganwendungen und
Demoapplikationen in verschiedensten Programmierumgebungen und Anleitungen zur Verfügung.
Auch Unternehmen entdecken zunehmend das Potential von großflächigen Multi-Touch Interfaces für eine Vielzahl an Anwendungen, etwa für Point-of-Sale Settings, Events oder kollaboratives Arbeiten. Für ein besseres Verständnis wird in diesem Kapitel eine Auswahl von
kommerziellen Produkten und die wichtigsten DIY-Methoden (Do-It-Yourself) behandelt.
Aufgrund der Vielzahl an Möglichkeiten und ständigen Weiterentwicklungen wird allerdings
kein Anspruch auf Vollständigkeit erhoben.
2.3.1 Microsoft PixelSense (vormals Surface 2)
Microsoft stellte 2007 den Surface, ein 30 Zoll großes, tischähnliches Multi-Touch-Display vor.
Während diese erste Version des Surface – aufgrund des hohen Platzbedarfs der Hardware –
noch eine geschlossene Bauweise aufweist, benötigt der 2012 veröffentliche Surface 2 kaum
mehr räumliche Tiefe als ein Fernseher und kann somit auch vertikal verwendet werden.
Schon Version 1 des Surface konnte neben Fingerberührungen auch Objekte erkennen. Mit
9
Surface 2 jedoch verwendet Microsoft eine neuartige Technologie, die es der gesamten Oberfläche durch integrierte Kamerapixel ermöglicht zu „sehen“, was sich auf der Oberfläche befindet.
Diese Technologie wurde in Kooperation mit Samsung entwickelt, trägt den Namen PixelSense
und ermöglicht (im Unterschied zu vielen anderen Technologien) das Erkennen von Objekten
trotz sehr schlanker Bauweise. Durch diese geringe physische Tiefe kann Surface 2 auch vertikal als Interaktive Wand, zum Beispiel für Präsentationssituationen, verwendet werden (siehe
Abbildung 2).
Abbildung 2: Microsoft PixelSense (vormals Surface 2) (Samsung (Hg.), o. J.)
Die 42 Zoll große, interaktive Oberfläche des Surface 2 kann mindestens 50 simultane Fingerberührungen erkennen. Im Gehäuse des Surface 2 ist außerdem ein vollwertiger PC mit dem
Betriebssystem Window 7 integriert. (Microsoft (Hg.), o. J.-c)
Microsoft stellt das Surface 2.0 SDK 6 zur Entwicklung von Multi-Touch-Applikationen für die
Surface Plattform zur Verfügung (siehe Kapitel 2.5.2). Als im Juni 2012 Microsoft neue TabletPCs mit dem Namen Surface 7 vorstellt, wird der Tabletop-PC kurzerhand auf den Namen der
verwendeten Technologie – PixelSense – umbenannt. Das SDK trägt aber weiterhin den Namen Surface 2.0 SDK, ist jedoch ins PixelSense Design and Development Center 8 integriert.
2.3.2 PQLabs Overlays
PQLabs entwickelt Rahmen (Overlays) für handelsübliche Computermonitore oder Fernseher
um diese um Multi-Touch-Fähigkeiten zu erweitern. Diese Rahmen werden direkt über dem
Display installiert und per USB an einen PC angeschlossen. PQLabs stellt Treiber für Windows
6
SDK: Software Development Kit. Ein SDK ist eine Sammlung an Werkzeugen für die Entwicklung von
Software für einen spezifischen Aufgabenbereich.
7
http://www.microsoft.com/surface
8
http://msdn.microsoft.com/en-US/windows/desktop/hh241326.aspx
10
XP/Vista/7, Mac OS X und Ubuntu/Fedora sowie ein SDK zur Entwicklung von Multi-TouchAnwendungen zur Verfügung 9.
Die Overlays von PQLabs sind in vielen Größen von 32 bis 103 Zoll und in verschiedenen Varianten zur Erkennung von zwei bis 32 simultanen Touchpunkten (Produkt G4 Dual Touch bis
G4 Plus) erhältlich.
Abbildung 3: PQLabs G4 Multi-Touch Overlay (Quelle: multi-touch-screen.com)
Diese Geräte zeichnen sich durch schnelle Reaktionszeiten (5 bis 10ms) und gehärtetes Glas
aus und können durch die dünne Bauweise sowohl horizontal als Tabletop als auch vertikal als
Interaktive Wand verwendet werden (siehe Abbildung 3). Alternativ zur Platzierung über einem LCD-Bildschirm können diese Rahmen auch mit einer Folie für Rückprojektion ausgestattet und mit einem Projektor bespielt werden. Das erlaubt auch vertikale Setups, bei denen
Zuschauer von allen Seiten die Interaktionen auf der Oberfläche verfolgen können. Ein Anwendungsszenario ist die Performance eines Disk- oder Visual Jockeys (PQ Labs (Hg.), o. J.).
2.3.3 Ideum Platform
Der Ideum Platform ist ein Tabletopsystem mit einem Multi-Touch-Display, das bis zu 40 simultane Berührungspunkte erkennen kann. Das System weist mit 55 Zoll Bildschirmdiagonale
gegenüber Microsoft PixelSense (40 Zoll) eine deutlich größere interaktive Fläche auf. Dies
wirkt sich positiv auf Multi-User-Situationen aus, da mehrere Personen ohne Platzeinschränkungen um den Tisch stehen können.
Das System weist eine flache und stabile Konstruktion auf, in der auch ein PC mit i7-Prozessor
integriert ist. Der Platform ist durch den schmalen Standfuß auch für Rollstuhlfahrer geeignet
und ist somit für barrierefreie Ausstellungen einsetzbar (Ideum (Hg.), 2012).
9
Das SDK von PQLabs ist nur spärlich dokumentiert und wird aus diesem Grunde in Kapitel 2.5 nicht behandelt.
11
Abbildung 4: Ideum Platform Multi-Touch-Tisch (Quelle: ideum.com)
Ideum stellt mit dem kommerziellen Framework GestureWorks auch eine Werkzeugpalette
zur Entwicklung von Multi-Touch-Applikationen für die Adobe Flash Plattform zur Verfügung (siehe Kapitel 2.5.3).
2.3.4 Eigenbau Möglichkeiten (DIY)
Seit der Veröffentlichung von Jefferson Han’s populären YouTube-Video des halbtransparenten Multi-Touch-Screens und einer detaillierten Bauanleitung, folgten engagierte Hobbybastler/innen, Studierende, Interaktionsdesigner/innen und Experimentierfreudige der Anleitung
und bauten eigene Multi-Touch-Tische aus handelsüblichen Komponenten.
Im Internet bildete sich eine Community, die Erfahrungen und Probleme hinsichtlich Konstruktion, Hardware und Software bei Do-it-Yourself (DIY) Multi-Touch Hardware-Projekten
mit anderen Interessierten teilt und diskutiert. Die zentrale Plattform dieser Community ist
aktuell das Forum der NUI Group 10 (Natural User Interface Group).
In diesem Kapitel werden vier weit verbreitete Methoden für den Bau einer Multi-TouchOberfläche behandelt: Frustrated Total Internal Reflection, Diffused Surface Illumination, Rear
Diffused Illumination und Laser Light Plane.
Diese Methoden basieren auf einem optischen System bei dem die Berührungen der Oberfläche von einer Kamera aufgezeichnet und von einer Trackingsoftware ausgewertet werden. Wie
in Abbildung 5 ersichtlich, wird das Bild auf der Oberfläche von einem Projektor dargestellt.
Aufgrund des hohen Mindestabstandes von Kamera und Projektor zur Oberfläche ist die Bauweise in einem tischähnlichen Kasten sehr verbreitet.
10
http://nuigroup.com/forums
12
Abbildung 5: Grundsätzlicher Aufbau eines DIY-Multi-Touch-Tisches bei Diffused Surface Illumination mit
Projektor, Kamera und beleuchteter Oberfläche.
Frustrated Total Internal Reflection (FTIR)
Das von Han (2005) für seine Multi-Touch-Oberfläche aufgegriffene Prinzip der Frustrated
Total Internal Reflection (FTIR) basiert auf dem Phänomen der Total Internal Reflection.
Elektromagnetische Wellen, die sich innerhalb eines Materials ausbreiten, werden an der äußeren Grenze des Materials vollständig reflektiert, wenn dieses Material einen höheren Brechungsindex als das umgebende Material besitzt und der Brechungswinkel klein genug ist.
FTIR-Setups bestehen üblicherweise aus einer durchsichtigen Acrylglasplatte, die mit einer
dünnen Siliconschicht überzogen und an den Enden mit Infrarot-LEDs 11 bestückt ist. Diese
LEDs fluten die Platte mit Infrarotlicht. Das Licht kann erst aus dem Acrylglas entweichen,
wenn ein Benutzer die Silikonschicht der Platte mit seinem Finger berührt. Dadurch ändert
sich der Brechungsindex des umgebenden Materials. Dieses ausströmende Licht kann mit einer
Infrarotkamera erkannt und durch anschließende Filterung des Videos als Finger identifiziert
werden. Um auf der Oberfläche ein Bild darzustellen, wird üblicherweise das Acrylglas mit
einer Projektionsfolie überzogen. Auf diese Oberfläche kann ein auf der Rückseite des Glases
befindlicher Projektor das Bild darstellen (siehe Abbildung 6). (Han, 2005; Schöning u. a.,
2008)
11
LED: Light Emitting Diode. LEDs sind elektronische Bauteile, die elektromagnetische Wellen in unterschiedlicher Wellenlänge aussenden. LEDs werden häufig als visuelle Indikatoren oder für eine InfrarotÜbertragungsstrecke (Fernbedienung) in Elektrogeräte verbaut.
13
Abbildung 6: FTIR-Setup schematisch dargestellt.
Diffused Surface Illumination (DSI)
Diffused Surface Illumination ist eine im Aufbau der FTIR-Variante sehr ähnliche Methode.
Wie bei FTIR werden Infrarot LEDs verwendet, um Infrarotlicht in das Material der Oberfläche zu bringen; DSI basiert jedoch nicht auf Totaler Interner Reflektion. Für ein DSI-Setup
wird ein spezielles Acrylglas verwendet, das winzige Partikel beinhaltet (Endlighten Acrylglas).
Diese Partikel fungieren als kleine Spiegel, die das Infrarotlicht verteilen, dadurch ergibt sich
eine gleichmäßige Verteilung des Lichts (siehe Abbildung 7). (Roth, 2008; Schöning u. a., 2008)
Tim Roth (2008) erläutert die Vor- und Nachteile dieses Systems in seinem Blog:
Vorteile:
•
Keine Probleme bei der gleichmäßigen Verteilung des Lichts, einfaches Setup
•
FTIR Setup kann einfach zu einem DI [DSI, Anm.] konvertiert werden
•
Es muss keine Kiste für das Setup gebaut werden (im Unterschied zu anderen DI Setups)
•
Fiducials können erkannt werden
Nachteile:
•
Geringerer Kontrast im Vergleich zu einem normalen DI Setup, weil das Plexiglas das
Licht auch in Richtung der Kamera ablenkt
•
Potentiell mehr Probleme mit Umgebungslicht aufgrund von geringerem Kontrast
•
Möglicherweise Einschränkungen hinsichtlich der Größe aufgrund der Weichheit des
Plexiglases
14
Abbildung 7: DSI-Setup schematisch dargestellt.
Rear Diffused Illumination (RDI)
Ein Diffused Illumination Setup besteht aus einer beliebigen glasähnlichen Oberfläche mit einer Projektionsfolie (alternativ kann auch Weißglas, ein auf einer Seite gleichmäßig aufgerauhtes Glas, verwendet werden) und einer Reihe von Infrarot Scheinwerfern. Die Scheinwerfer
beleuchten die Oberfläche gleichmäßig von unten (siehe Abbildung 8). Ein Körper in geringer
Distanz zur Oberfläche wird von dem Licht reflektiert und wird bei einer Berührung aufgrund
der scharfen Kanten des hellen Bereichs über das Kamerabild als Objekt oder Finger erkannt.
DI ermöglicht durch diese Art der Beleuchtung auch die Verwendung von mit Fiducials versehenen Objekten. Bei dieser Methode ist eine gleichmäßige Ausleuchtung der Oberfläche entscheidend für eine stabile Erkennung. (Schöning u. a., 2008)
Abbildung 8: RDI-Setup schematisch dargestellt.
15
Laser Light Plane (LLP)
Bei einem Laser Light Plane Setup erfolgt die Beleuchtung der Oberfläche durch einen oder
mehrere Laser mit Wellenlängen im Infrarotbereich. Durch Liniengeneratorlinsen, die vor den
Lasern platziert werden, werden die Laserstrahlen in etwa 1mm dicke Laserebenen (Laser Light
Plane) transformiert. Wie in Abbildung 9 dargestellt, werden die Laser so positioniert, dass sich
diese Ebenen in möglichst geringer Distanz über der Oberfläche befinden. Durchbricht ein
Finger diese Ebene, wird das darauf eintreffende Licht reflektiert. Diese hellen Bereiche kann
eine Infrarotkamera erkennen und entsprechende Software verarbeiten.
Abbildung 9: LLP-Setup schematisch dargestellt.
Trackingsoftware
Unabhängig vom verwendeten Setups muss eine Applikation den Videostream der Kamera
verarbeiten, um Informationen über die Position der einzelnen Finger (oder Objekte) zu erhalten. Eine von der NUI Group Community für diesen Zweck entwickelte Softwarelösung ist
Community Core Vision (CCV) 12. CCV ist open-source und cross-platform und ermöglicht
umfangreiche Einstellungsmöglichkeiten und performante Erkennung von Berührungen sowie
mit Marker versehenen Objekten. Eine integrierte Kalibrationsroutine erleichtert die Konfiguration des Setups. Die erfassten Daten werden über das in Kapitel 2.4.1 beschriebene TUIOProtokoll für Multi-Touch-Applikationen bereitgestellt.
Eine weitere quelloffene Trackingsoftware ist reacTIVision (siehe Kapitel 2.4.1). reacTIVision
wurde ursprünglich für den reacTable entwickelt und bietet wie CCV Finger- und Objekterkennung sowie Unterstützung für das TUIO-Protokoll (Kaltenbrunner, 2009).
12
http://ccv.nuigroup.com/
16
2.4 Protokolle und Multi-Touch-Integration in
Desktop-Betriebssystemen
Durch die stetig steigende Anzahl von Multi-Touch-fähigen Eingabegeräten wird auch die
Integration dieser Eingabe- und Interaktionsmöglichkeiten in Desktop-Betriebssystemen stärker forciert. In diesem Kapitel wird das TUIO-Protokoll und die Unterstützung für MultiTouch und Gesten in den drei am weitesten verbreiteten Desktop-Betriebssystemfamilien
(Microsoft Windows, Apple Mac OS X und Ubuntu Linux) beschrieben (Net Applications
(Hg.), 2012).
2.4.1 TUIO Protokoll
Eines der erfolgreichsten Projekte für Multi-Touch und Tangible User Interfaces ist der von
Sergi Jordà und seinem Team entwickelte reacTable. Der reactTable ist ein kollaboratives Musikinstrument basierend auf einem Multi-Touch-Tisch. Die Oberfläche des Tisches erkennt
allerdings nicht nur Finger-Berührungen (pointers oder cursors) sondern auch mit Markern
(Fiducials 13) versehene Objekte (objects). (Jordà u. a., 2007; Jordà, Julià, & Gallardo, 2010; Kaltenbrunner, 2009)
Abbildung 10: Marker (Fiducial) für die Erkennung von physischen Objekten aus dem „amoeba“-Set von reacTIVision ((Jordà u. a., 2007). Bildquelle: http://reactivision.sourceforge.net)
Im Zuge der Entwicklung des reacTables wurde auch reacTIVision, eine Applikation zur Erfassung von Multi-Touch-Interaktionen und phyischen Objekten durch Verarbeitung von Videodaten, entwickelt. Zudem entwickelten Kaltenbrunner und sein Team TUIO, ein Protokoll zur
Beschreibung und Übermittlung von Multi-Touch- und Objektdaten.
TUIO basiert auf OpenSound Control, ein Netzwerkprotokoll zur Übermittlung von Steuerungsdaten zur Kommunikation und Synchronisation von Computern, Musikinstrumenten
und anderen Geräten (Kaltenbrunner, 2009; Wright, Freed, & Momeni, 2003).
13
Fiducials sind visuell eindeutig unterscheidbare Codes, die auf Objekten platziert werden können, um diese
bspw. auf einer Multi-Touch-Oberfläche erkennen zu können. Dadurch kann Funktionalität mit Objekten
aufgrund deren Position, Drehung und Größe verknüpft werden. (Constanza & Robinson, 2003)
17
Durch eine sehr flexible, aber konsistente Struktur hat sich TUIO in den letzten Jahren zum
de-facto Standard für Multi-Touch-Anwendungen auf Tabletopsystemen entwickelt. Viele
Trackingframeworks 14 und kommerzielle Multi-Touch-Hardware stellen die gefilterten Ergebnisse als TUIO-Daten über eine Netzwerkschnittstelle bereit. Durch die Verwendung von OSC
können diese Daten mit einem Großteil der modernen Programmiersprachen ausgelesen und
verarbeitet werden. Viele Creative Coding-Frameworks wie Processing, vvvv, openFrameworks
oder Max/MSP15 bieten außerdem eigene Klassen oder Module zur Verwendung von TUIODaten.
Ein TUIO-Message Bundle besteht aus drei Teilen: Die alive Message gibt eine Liste der aktuellen Tokens (Finger oder Objekte) anhand einzigartiger Session-IDs aus. Der zweite Teil, die set
Message, kommuniziert den Status eines Tokens mit den Parametern Position, Änderung,
Ausrichtung, Beschleunigung und der Session-ID des Tokens. Im dritten Teil, der fseq Message, wird das aktuelle Bundle mit einer einzigartigen, sequentiell vergebenen ID belegt, so dass
er eindeutig identifizierbar ist.
Eine TUIO set Message für eine Statusänderung eines Cursors (Finger) ist folgendermaßen
aufgebaut 16:
/tuio/2Dcur set sid xpos ypos xvel yvel maccel
Die Parameter haben folgende Bedeutung: sid gibt die Session ID wieder, xpos und ypos die
aktuellen Koordinaten des Punktes; xvel und yvel geben die Geschwindigkeit der Änderung
als Vektor an und maccel steht für die Beschleunigung der Bewegung (Acceleration).
Bei der Verwendung von physischen Objekten beginnt eine set Message mit /tuio/2Dobj
und erhält zusätzliche Parameter wie den Winkel des Objektes und die Rotationsbeschleunigung (Kaltenbrunner, 2009).
2.4.2 Microsoft Windows 7 Touch Events
Im Betriebssystem Windows 7 von Microsoft ist die Bedienung mittels Multi-Touch-fähigen
Eingabegeräten im System verankert. Windows 7 unterstützt die Bedienung mit einem oder
mehreren Fingern. Ähnlich wie bei Mac OS X (siehe Kapitel 2.4.3) können etwa Fensterinhalte
mit zwei Fingern gescrollt oder mit mehreren Fingern zwischen Programmen gewechselt werden. Mit Windows 7 wurde auch der Einstellungsdialog „Stift- und Fingereingabe“ eingeführt,
der umfassende Einstellungsmöglichkeiten für die Verwendung von Multi-Touch-Gesten zulässt. Entwickler/innen gibt Microsoft die Möglichkeit, Unterstützung für Multi-Touch und
14
Ein Tracking-Framework analysiert Live-Videodaten einer Kamera, um zu erkennen, wo sich Berührungspunkte von Fingern auf der Oberfläche befinden (siehe auch Kapitel 2.3.4).
15
http://processing.org/, http://vvvv.org, http://www.openframeworks.cc/,
http://cycling74.com/products/max/
16
TUIO-Daten werden nicht als Klartext, sondern komprimiert im Binärcode übertragen.
18
Gestensteuerung in Applikationen zu integrieren. Die mit Windows 7 eingeführten Windows
Messages WM_TOUCH für die Rohdaten der Berührungspunkte und WM_GESTURE für die
Erkennung der durchgeführen Geste erleichtern die Entwicklung derartiger Applikationen.
(Kiriaty, 2009)
Microsoft setzt mit Windows 8 17 und der Metro-Oberfläche 18 noch stärker als bisher auf MultiTouch, da das Betriebssystem sowohl für Tablet-PCs als auch für Desktop-PCs optimiert sein
soll. Dabei sind zwei Entwicklungen besonders bemerkenswert: Microsoft setzt für die Entwicklung von Metro-Applikationen sehr stark auf den Einsatz von Webtechnologien wie
HTML, CSS und JavaScript (siehe Kapitel 3.1) und bietet erstmals eine Schnittstelle für die
Verarbeitung von Multi-Touch-Events im Browser Microsoft Internet Explorer 10 (Rossi,
2011); siehe Kapitel 3.2.4).
2.4.3 Mac OS X Multi-Touch
Apple führte 2008 mit dem MacBook Air ein Multi-Touch-fähiges Trackpad 19 ein. Über dieses
Trackpad können Benutzer durch die Verwendung von einfachen Gesten mit mehreren Fingern mit dem System interagieren. Diese Funktionalität wurde mit Mac OS X 10.7 (Lion) um
einige Gesten erweitert und ermöglicht Scrollen und Zoomen von Fensterinhalten, Suchen von
Dateien und Aufgaben des Fenstermanagements durch die Bewegung von mehreren Fingern
auf dem Trackpad (Apple (Hg.), 2011). Seit dem ersten Mac Book Air sind alle neuen Apple
MacBook Modelle mit Multi-Touch-fähigen Trackpads ausgestattet.
Zusätzlich wurden von Apple externe Hardwareprodukte mit Multi-Touch-Unterstützung für
Mac Desktopcomputer und Notebooks entwickelt. Dazu zählt die Magic Mouse, laut Hersteller
„die erste Multi-Touch-Maus der Welt“ sowie das Magic Trackpad als Trackpad für Desktopcomputer. (Apple (Hg.), o. J.-a, o. J.-b)
Die Interaktion mit dem System mittels Gesten ist mit diesen Produkten und durch die tiefe
Integration in das Betriebssystem ein fester Bestandteil der täglichen Arbeit mit OS X.
2.4.4 Ubuntu uTouch
Die von Canonical entwickelte Linux-Distribution Ubuntu unterstützt in der Version 10.10
(Codename Maverick Meerkat, aktuelle Version: 12.04 Precise Penguin) erstmals Multi-Touch
und Gestenerkennung. In dieser Version wurde der uTouch-Stack eingeführt. uTouch ist ein in
17
Microsoft hat bereits eine Vorschau-Version von Windows 8 (Release Preview) veröffentlicht. Ein genaues
Datum der Veröffentlichung der finalen Version ist noch nicht bekannt. Es wird jedoch von einem Verkaufsstart noch im Jahr 2012 ausgegangen.
18
Metro ist die Bezeichnung für eine auf Tiles (engl. Kacheln) basierende Design-Sprache die für Windows
Phone 7 entwickelt wurde und für Windows 8 weiterentwickelt wird.
19
Als Trackpad oder Touchpad wird ein meist in Notebooks vorhandenes Gerät bezeichnet, das u.a. die Bedienung des Maus-Cursors durch den Benutzer ermöglicht.
19
das X Window System 20 von Ubuntu integriertes Framework, das Multi-Touch-Daten verarbeitet und durchgeführte Gesten erkennt. Die ausgewerteten Informationen stehen Softwareentwickler/innen über ein API 21 zur Verfügung, um Applikationen mit Gestenunterstützung
zu entwickeln. (Carr, 2010)
In der nächsten Hauptversion 11.04 („Natty Narwhal“) von Ubuntu wurde die Unterstützung
von Multi-Touch noch ausgeweitet. So wurde beispielsweise ein stabiles Multi-Touch-API für
das Qt-Framework 22 geschaffen.
Ubuntu bietet mit dem Dienst Ginn ein konfigurierbares Werkzeug für die Verwendung von
Multi-Touch-Gesten für bestimmte Aktionen, auch wenn eine Applikation keine Gestenunterstützung bietet. Mit Hilfe einer einfachen XML-Syntax 23 können sogenannte Wishes (Wünsche) definiert werden, indem einer Geste bespielsweise eine Tastaturaktion zugewiesen wird.
(McGreggor, 2011)
2.5 Frameworks für die Entwicklung von nativen
Multi-Touch-Applikationen
Durch die rasante Verbreitung von Multi-Touch-Hardware ergiebt sich ein Bedürfnis nach
Softwareframeworks zur Entwicklung von Multi-Touch-Applikationen. In den letzten Jahren
wurde eine Vielzahl an Frameworks mit jeweils unterschiedlicher Protokollunterstützung, unterschiedlicher Funktionalität und Architektur in verschiedenen Programmiersprachen entwickelt. Kammer et al. beschreiben eine Liste von Kriterien anhand derer Multi-TouchFrameworks unterschieden werden können. Diese Liste ist in die drei aufbauenden Ebenen
Architecture, Scope (Umfang) und Features (Funktionalität) geteilt (siehe Abbildung 11).
20
X Window System ist das Protokoll und Toolkit für die Darstellung von grafischen Benutzerschnittstellen
in vielen Linux-Distributionen, u.a. auch Ubuntu.
21
API: Application Programming Interface. Als API bezeichnet man eine Programmierschnittstelle in der
Softwareentwicklung.
22
Qt ist ein plattformübergreifendes, open-source Applikations- und Benutzerschnittstellen-Framework auf
C++ Basis (Douglas, 2011).
23
XML: Extensible Markup Language. XML ist eine Auszeichnungssprache (Markup Language) zur strukturierten Darstellung von Daten.
20
Abbildung 11: Schichtenmodell mit Kriterien zur Klassifikation von Multi-Touch-Frameworks (Kammer, Keck,
Freitag, & Wacker, 2010).
Die unterste Ebene Architecture bildet die Basis für das Framework und beschreibt die Abhängigkeiten von einer Plattform oder Hardware sowie das verwendete Eventsystem. Die nächste
Ebene Scope klassifiziert Frameworks anhand des implementieren Umfangs. Einige Frameworks unterstützen sowohl die Verwendung von physischen Objekten (Tangible Objects) als
auch Berührungspunkten (Touches). Die Mehrheit der Frameworks ist jedoch für eine der
beiden Anwendungsfälle konzipiert. In dieser Schicht wird zudem anhand der Parametrisierbarkeit der Gesten unterschieden. In der obersten Ebene Features wird die Unterstützung von
Standardgesten, deren Erweiterbarkeit sowie die Grafikunterstützung, je nach Kontext in 2D
oder 3D, bewertet. (Kammer, Keck, u. a., 2010)
Eine wichtige Unterscheidung bei der Verarbeitung von Gesten ist bezüglich des Zeitpunktes
der Gestenerkennung zu treffen. Offline-Gesten werden erst nach der Durchführung der Geste
verarbeitet und erkannt. Diese Art von Gesten kann in manchen Anwendungsszenarien sinnvoll sein – als Beispiel sei der Aufruf eines Menüs durch eine kreisförmige Geste genannt. In
den meisten Fällen ist diese Art von Interaktion wenig zufriedenstellend, da das Feedback für
den User erst nach Abschluss der Geste erfolgt. Im Gegensatz dazu werden Online-Gesten
schon während der Durchführung verarbeitet und erkannt. Diese Art von Verarbeitung ist
unter anderem bei den in Kapitel 2.2 angeführten Gesten Drag, Rotate, Scale und Scroll notwendig, da das Ergebnis abhängig von dem Ausmaß der Veränderung der Fingerpositionen
während der Durchführung ist. Alle in diesem Kapitel behandelten Frameworks unterstützen
diese Art von Gestenverarbeitung.
Da diese Arbeit auf die Plattform Tabletop-PC fokussiert ist, werden Frameworks für die Entwicklung von nativen Applikationen für mobile Endgeräte – etwa auf Basis der mobilen Betriebssysteme Android oder iOS – nicht gesondert behandelt.
21
2.5.1 MT4j (Java)
Das open-source Framework MT4j 24 (Multi-Touch for Java) ist ein umfangreiches Framework
zur Erstellung von Multi-Touch-Applikationen. Aus der Verwendung der Programmiersprache Java resultiert eine hohe Plattformunabhängigkeit – die mit MT4j entwickelten Programme laufen in der Java Virtual Machine (VM) und sind somit auf Windows, Mac OS X und
Linux lauffähig.
MT4j kann mit einem breiten Spektrum an Multi-Touch-Hardware und den dazugehörigen
Protokollen verwendet werden. Folgende Geräte/Protokolle werden unterstützt: Windows 7
Touch Messsages, Mac OS X Trackpad und Magic Mouse, Ubuntu Linux, TUIO sowie
Android-Geräte (experimentelle Unterstützung).
Das Framework wurde auf Basis des populären Java-Frameworks Processing entwickelt. Dies
ermöglicht es, viele Funktionen und Bibliotheken für Processing auch mit MT4j zu verwenden
und resultiert in einer kürzeren Lernphase für Entwickler/innen mit Erfahrung in Processing.
Durch die Verwendung von Processing, ist es in MT4j auf einfache Art und Weise möglich,
sowohl 2D- als auch 3D-Objekte zu verwenden.
MT4j stellt eine Reihe an UI-Komponenten wie Buttons, Listen, Slider und ein Multi-Touchfähiges, virtuelles Keyboard sowie viele Grafikprimitive wie Rechtecke, Kreise, Polygone aus
der Processing-Umgebung zur Verfügung. Weiters ermöglicht MT4j die Verwendung der gängigsten Multi-Touch-Gesten (Drag, Rotate, Scale, Scroll) sowie eigene, komplexere Gesten –
etwa für die Manipulation von 3D-Objekten – zu definieren. (Laufs, Ruff, & Zibuschka, 2010)
2.5.2 Surface 2.0 SDK (.NET)
Kurz vor dem Verkaufsstart des Microsoft PixelSense (vormals: Surface 2) stellte Microsoft am
12. Juli 2011 das Surface 2 SDK für Entwickler/innen zum Download bereit. Das Surface 2 SDK
wurde hauptsächlich für die Entwicklung von PixelSense-Applikationen konzipiert. Durch die
starke Touchunterstützung in Windows 7 ist es allerdings auch für die Entwicklung von Windows 7 Applikationen, die stark auf Toucheingabe basieren, verwendbar (Cabrera, 2011).
Das Surface 2.0 SDK basiert auf der Plattform .NET 4.0 und Windows Presentation Foundation 4.0 (WPF). Aufgrund dessen ist das SDK für viele Entwickler/innen mit Erfahrung in der
Programmierung von Windows Applikationen einfach zu verwenden. Als Entwicklungsumgebung wird Visual Studio 2010 oder Visual C# 2010 Express empfohlen, wenngleich auch quelloffene Entwicklungsumgebungen (z.B. MonoDevelop oder SharpDevelop) für C#-Entwicklung
verfügbar sind. (Microsoft (Hg.), o. J.-d)
Auf der Website des PixelSense Design and Development Center 25 bietet Microsoft zusätzlich
Tutorials und eine umfangreiche Anleitung für die Konzeption von Multi-Touch-
24
http://www.mt4j.org
25
http://msdn.microsoft.com/de-de/windows/desktop/hh241326.aspx
22
Anwendungen für PixelSense. Diese Anleitung beinhaltet Hinweise zur Verwendung von Gesten, visuelle Richtlinien, typografische Empfehlungen und Interaktionsmechanismen bei der
Verwendung von physischen Objekten als Teil der Applikation. Mit dieser Anleitung soll gewährleistet werden, dass PixelSense-Anwendungen eine einheitliche User Experience schaffen.
Das Surface 2.0 SDK fügt sich hinsichtlich des visuellen Stils in die aktuelle Designrichtlinie
von Windows 8 mit der Metro-Oberfläche ein.
Das SDK beinhaltet zudem einen Touch Input Simulator, der es ermöglicht, Multi-TouchApplikationen auch ohne die Verwendung eines Touch-fähigen Gerätes zu entwickeln. Die
Touchpunkte sowie Objekte werden durch Mausklicks simuliert. Um eine Applikation auch im
vertikalen Modus testen zu können (etwa bei der Verwendung als Interaktive Wand), kann in
diesem Simulator auch die Neigung des Gerätes konfiguriert werden (Cabrera, 2011). Kapitel
3.3.6 beinhaltet eine detailliertere Beschreibung der Funktionalität dieses Simulators.
2.5.3 GestureWorks und OpenExhibits SDK (Flash)
Die Adobe Flash Plattform erhält mit der Version 10.1 native Unterstützung für Multi-Touch
und Gestenevents. Diese Funktionalität ist jedoch nur eingeschränkt für hochqualitative MultiTouch-Applikationen verwendbar, da die Gestenunterstützung auf eine gleichzeitige Geste
limitiert ist. Das hat zur Folge, dass es beispielsweise nicht möglich ist, ein Objekt am Bildschirm mit zwei Fingern zu rotieren und gleichzeitig zu verschieben (Cantrell, 2009).
Für die Flash Plattform gibt es daher einige Multi-Touch und Gestenframeworks, die diese
Probleme lösen. Ein umfangreiches Frameworks ist das von Ideum (siehe Kapitel 2.3.3) entwickelte GestureWorks.
GestureWorks 26 bietet die Erkennung einer breiten Palette an Ein- und Mehrfingergesten. Dabei wird zwischen Multitouch Gestures und Stroke Gestures unterschieden. Stroke Gestures sind
definierte Pfade – etwa ein Kreis oder der Buchstabe M – bei deren Durchführung mit einem
Finger das Framework ein entsprechendes Event auslöst. Mit Hilfe der mit Version 3 eingeführten Gesture Markup Language (GestureML) lassen sich zusätzlich eigene Gesten definieren, um so das verwendete Gestenspektrum individuell zu erweitern. GestureWorks ermöglicht
es, durch GestureML und die große Anzahl an vordefinierten Gesten mit wenig Entwicklungsaufwand gestenbasierte Prototypen zu entwickeln.
GestureWorks unterstützt TUIO-Messages (siehe Kapitel 2.4.1) und Windows 7 Touch Messages (siehe Kapitel 2.4.2), dadurch ist das Framework auf den meisten Multi-Touch-Geräten, auf
denen die Flash Runtime oder Adobe AIR unterstützt wird, einsetzbar (Ideum (Hg.), o. J.).
GestureWorks ist nur unter einer kommerziellen Lizenz verfügbar. OpenExhibits 27 SDK, das
u.a. die Kernfunktionalität von GestureWorks beinhaltet, ist jedoch für Universitäten, Studen-
26
http://gestureworks.com
27
http://openexhibits.org/
23
ten und Museen frei verfügbar. Die ebenfalls von Ideum gegründete Stiftung OpenExhibits, hat
es sich zur Aufgabe gemacht, durch neuartige, physischere Ausstellungskonzepte Besucher
einzuladen, mehr miteinander zu interagieren und so eine Ausstellung gemeinsam zu erleben.
Das OpenExhibits SDK beinhaltet die Gestenerkennung von GestureWorks. Zusätzlich bietet
OpenExhibits einige frei verfügbare Module für häufig benötigte Anwendungsszenarien wie
eine Bildergalerie, ein Modul für die Anzeige von hochauflösenden Bildern (Gigapixel Viewer)
sowie Player für Musik und Videos. All diese Module sind beliebig kombinierbar und werden
mittels Multi-Touch-Gesten gesteuert. (Open Exhibits (Hg.), o. J.)
2.5.4 Weitere Frameworks
Neben den drei behandelten Frameworks MT4j, Surface 2 SDK und GestureWorks existiert
eine Vielzahl weiterer Frameworks für diverse Programmiersprachen mit unterschiedlichem
Funktionsumfang. Je nach Zielplattform, gewünschter Funktionalität und Ansprüche hinsichtlich Performance und Grafik haben die Frameworks unterschiedliche Stärken und Schwächen.
In diesem Kapitel wurden nur Frameworks mit Unterstützung für Multi-Touch-Gesten behandelt. Applikationen, die diese Funktionalität nicht benötigen, können mit einer Vielzahl
von Programmierumgebungen entwickelt werden. Die populären Creative Coding Toolkits
openFrameworks und Cinder 28 sind aufgrund der Unterstützung von Grafikbibliotheken mit
Hardwarebeschleunigung für Anwendungen mit komplexer Grafik geeignet. Für diese Frameworks existieren bis dato noch keine Multi-Touch-Frameworks im Umfang der oben genannten Lösungen MT4j, Surface 2 SDK und GestureWorks.
Für Multi-Touch-Applikationen, die hohe Anforderungen an Grafik und Performance stellen,
kann das derzeit noch in Entwicklung befindliche Framework MINT eine brauchbare Alternative zu den oben genannten Frameworks darstellen. MINT wird von dem österreichischen Design Studio Strukt in Kooperation mit der Technischen Universität Wien entwickelt. Das
Framework ist in der Programmiersprache C++ entwickelt und kann daher für die Entwicklung von Multi-Touch-Applikationen zusammen mit den Toolkits openFrameworks oder Cinder verwendet werden. Zusätzlich wird das Framework als Plug-in für die visuelle
Programmiersprache vvvv verfügbar sein. Laut einer Ankündigung im vvvv Forum 29 wird
MINT allerdings erst auf dem Festival NODE13 30 im Februar 2013 in Frankfurt veröffentlicht.
(Hitthaler, 2012; Strukt (Hg.), 2012)
28
http://libcinder.org/
29
http://vvvv.org/forums
30
http://node.vvvv.org/
24
3
Das World Wide Web ist seit seiner Schaffung in den frühen 1990er Jahren ständig in Veränderung und Weiterentwicklung. Ursprünglich als System zum Austausch von wissenschaftlichen Informationen konzipiert, wurde schnell deutlich, dass das von Tim Berners-Lee am
CERN entwickelte World Wide Web mit der Strukturierungssprache HTML, dem Transferprotokoll HTTP und dem System für Adressen im Web (URI) für sehr unterschiedliche Anwendungszwecke gebraucht werden kann. (Berners-Lee, 2012)
Der Webbrowser, ein Programm zur Darstellung von Inhalten des World Wide Webs, ist inzwischen zu einer der wichtigsten Applikationen auf jedem Desktop-Computer oder mobilem
Endgerät geworden. Durch schnellere Datenverbindungen und neue technologische Entwicklungen werden neben klassischen Websites immer mehr umfangreiche Applikationen für die
Verwendung im Browser entwickelt. Als Beispiele seien hier E-Mail-Applikationen oder Fotobearbeitungssoftware erwähnt. Mit der Entwicklung der Technologien, die gemeinhin unter
dem Begriff HTML5 zusammengefasst werden, werden Möglichkeiten für Programmierer geschaffen, unterschiedliche Medien ohne zusätzliche Plug-ins in Websites einzubinden, Inhalte
editierbar zu machen und anprechende Interaktionen des Benutzers mit dem System zu gestalten.
Im Kapitel 2.5 wurden Frameworks behandelt die es ermöglichen, Multi-Touch-Anwendungen
als eigenständige Applikationen mit klassischen Programmiersprachen zu entwickeln. Diese
Frameworks haben ihre Berechtigung und spezifischen Vorteile. Durch die Möglichkeiten, die
die aktuellen Entwicklungen der Webtechnologien mit sich bringen, wird jedoch der Webbrowser als Plattform für interaktive Applikationen mit fortgeschrittener Eingabe wie MultiTouch immer attraktiver.
Ein Vorteil, der für die Verwendung von Webtechnologien für interaktive Applikationen
spricht, ist eine große, globale Entwickler/innencommunity, die mit den relevanten Technologien vertraut ist und sich intensiv mit deren Fortschritt beschäftigt. Webentwickler/innen versuchen die Möglichkeiten der Browser auszureizen und dadurch immer bessere
Nutzungserlebnisse für die Benutzer/innen einer Applikation zu schaffen. Browserhersteller
wie Mozilla, Google, Apple und Microsoft sowie die für die Entwicklung des Webs verantwortlichen Konsortien, wie das World Wide Web Consortium (W3C), reagieren auf die Vorschläge
und Kritik der Entwickler/innengemeinde, um ihre Browser zu verbessern bzw. neue Standards
zu definieren.
Wie bereits erwähnt, ist ein deutlicher Trend in der Art des Konsums von Inhalten und Verwendung von Applikationen weg von traditionellen Desktop-Anwendungen zu web-basierten
Applikationen zu erkennen. Anwendungen mit reichhaltigen Interaktionsmöglichkeiten („rich
interaction“) oder animiertem Inhalt konnten früher nur mit zusätzlich zu installierenden
Plug-ins wie Adobe Flash Player oder Silverlight realisiert werden. Die neuen Technologien um
HTML5 machen einen Großteil der Hauptaufgaben von Flash obsolet, denn dieselbe Funktio25
nalität kann häufig mit standardisierten Technologien ohne Verwendung von Plug-ins realisiert werden. Einen Hinweis auf diese Entwicklung liefert beispielsweise der Chrome Web Store 31, in dem umfangreiche Applikationen für die Ausführung in Google‘s Webbrowser
Chrome 32 zur Verwendung bereitstehen. Das breite Sortiment umfasst unter anderem Büroanwendungen, Spiele, Bildbearbeitungstools sowie Audioeditoren. All diese Programme basieren auf standardisierten Webtechnologien und zeigen das breite Spektrum an Möglichkeiten
für die Entwicklung von webbasierten Anwendungen. Dieser Trend zeichnet sich auch durch
Google’s Betriebssystem Chrome OS 33, das ausschließlich auf Webtechnologien basiert, sowie
durch die mit Microsoft Windows 8 eingeführte Möglichkeit, Desktopapplikationen mit Webtechnologien zu entwickeln, ab.
Ein weiterer Vorteil bei der Verwendung von Webtechnologien für Multi-TouchApplikationen ergibt sich für die Distribution der Software. Da Webanwendungen üblicherweise auf einem Webserver im Internet bereitgestellt sowie teilweise auch ausgeführt werden,
ist eine Webapplikation sehr einfach von verschiedenen Orten zugänglich zu machen. Soll eine
Multi-Touch-Applikation an mehreren Orten gleichzeitig verwendet werden – etwa in mehreren Filialen einer Kaufhauskette – so können Änderungen in der Software schnell und kostengünstig ausgerollt werden. Über erneutes Abrufen der Website, die die Applikation beinhaltet,
wird die aktuelle Version der Applikation ausgeführt. Ein Nachteil bei dieser Art der Distribution ergibt sich jedoch für Zugriffsbeschränkungen oder kostenpflichtige Applikationen. Für
derartige Applikationen muss zusätzlich ein Authorisierungs- oder Bezahlungssytem implementiert werden.
In diesem Kapitel werden die aktuellen Möglichkeiten untersucht, Multi-Touch-Informationen
und Gesten im Webbrowser zu verwenden. Für ein Verständnis der wichtigsten Technologien
werden aktuelle Entwicklungen im Umfeld von HTML5 und CSS3 und ihre Relevanz für Multi-Touch-Anwendungen behandelt. Um Multi-Touch-fähige Applikationen zu entwickeln, ist
zudem die derzeitige Implementierung von Touchevents in unterschiedlichen Browser ein
zentraler Punkt.
Die Unterstützung von Touchevents auf mobilen Endgeräten wie Smartphones, die standardmäßig mit einem Multi-Touch-fähigen Bildschirm ausgestattet sind, wird kurz beschrieben. Da
sich diese Arbeit aber auf den Einsatz auf Tabletop-PCs fokussiert, wird nur ein Überblick über
die aktuellen Möglichkeiten mit Smartphones gegeben. Die Unterstützung von Touchevents in
Desktop-Browser wird im Detail beleuchtet.
Frameworks, die Touchevents verwenden, um eine einheitliche Programmierung von Gesten
für mehrere Browser zu ermöglichen, werden in Kapitel 3.3 behandelt.
31
https://chrome.google.com/webstore
32
http://chrome.google.com
33
http://www.chromium.org/chromium-os/
26
3.1 Relevante clientseitige Webtechnologien
3.1.1 HTML(5)
Im Jahr 1989 schlug Tim Berners-Lee, ein Physiker an der Europäischen Organisation für
Kernforschung (CERN) ein globales System zur Verteilung von wissenschaftlichen Publikationen vor. 1990 begann Berners-Lee, die drei wesentlichen Bestandteile seines Systems zu spezifizieren und zu implementieren:
•
Hypertext Transfer Protokoll (HTTP): Spezifikation für die Kommunikation zwischen
Webservern und Webclients
•
Universal Resource Identifier (URI): Spezifikation für die Adressierung von Dateien
und Datenquellen im Internet
•
Hypertext Markup Language (HTML): Spezifikation einer Auszeichnungssprache zur
Strukturierung von Webdokumenten
(Berners-Lee, 2012; Selfhtml (Hg.), 2005)
Seit diesen frühen Tagen des Webs bildet HTML die Grundlage von Webseiten. HTML ist aber
keineswegs eine statische Spezifikation, sondern wurde und wird ständig weiterentwickelt. Eine
zentrale Funktion in diesem Prozess nimmt das Word Wide Web Consortium (W3C), das
1994 von Tim Berners-Lee ins Leben gerufen wurde. Im W3C ist die Arbeit in sogenannte Activities aufgeteilt, welche wiederum von den Arbeitsgruppen (Working Groups) und den Interessensgruppen (Interest Groups) bearbeitet werden. In diesen beiden Gruppen sind viele
Unternehmen vertreten, die so aktiv an der Weiterentwicklung des Webs mitwirken. (Selfhtml
(Hg.), 2005)
Im Dezember 1997 wurde die HTML-Version 4 und zwei Jahre später Version 4.01 vom W3C
veröffentlicht. (Raggett, Le Hors, & Jacobs, 1997, 1999) Nachdem das W3C in einem Workshop zu dem Schluss kam, dass eine Weiterentwicklung von HTML 4.01 nur schwierig zu realisieren sei, wurde nur kurze Zeit später die Arbeit der HTML Working Group eingestellt und
die Arbeit in Richtung einer neuen Spezifikation, die auf wohlgeformtes XML aufbaut, aufgenommen. Die Ergebnisse dieser Bemühungen führten zu XHTML, ein Standard der sich allerdings nie richtig durchsetzen konnte. Die XHTML Working Group wurde mit Ende 2009
aufgelöst. (Le Hegaret & Jacobs, 2009; Smith & Sivonen, 2011)
Da zu dieser Zeit das W3C HTML nicht weiterentwickelte, wurde aus Sorge um die Zukunft
von HTML im Jahr 2004 die WHAT Working Group 34, ein unabhängiger und offener Zusammenschluss aus Browserherstellern 35 und an der Weiterentwicklung von HTML interes-
34
WHAT WG: Web Hypertext Applications Technology Working Group
35
Die zentralen Gründungsmitglieder der WHAT WG waren Mitarbeitern von Apple, der Mozilla Foundation und Opera Software (WHATWG (Hg.), 2012).
27
sierten Parteien, gegründet. Die WHAT Working Group beschäftigte sich mit Aspekten wie
Abwärtskompatibilität von HTML und Funktionalitäten für Webformulare. Über zwei Jahre
hinweg ignorierten sich das W3C und die WHAT Working Group größtenteils, bis 2006 Tim
Berners-Lee verkündete, dass man beim W3C stärker mit der WHAT Working Group zusammenarbeiten werde, um die Anstrengungen der beiden Gruppen zusammenzuführen. Eine der
ersten Entscheidungen der neu entstandenen W3C HTML Working Group war es, die Spezifikation der WHAT WG mit dem Namen Web Applikations 1.0 in HTML5 umzubenennen.
(Berners-Lee, 2006; Pilgrim, 2010, S. 2)
HTML5 ist derzeit noch im Working Draft Stadium, somit ist im Grunde noch HTML 4.01 die
aktuelle Version von HTML. (Raggett u. a., 1999) Viele der neuen HTML5-Technologien und
Funktionen können jedoch bereits verwendet werden. Allerdings muss für ältere Browser, die
diese Funktionen nicht unterstützen, vor allem bei kritischen Elementen einer Webseite oder
Webapplikation eine alternative Lösung bereitgestellt werden.
Durch die vielfältigen neuen Features ist HTML5 mehr als ein Überbegriff für ein Set an fortgeschrittenen, clientseitigen Webtechnologien anstatt einer einzelnen, abgeschlossenen Spezifikation zu betrachten. Welche Neuerungen HTML5 im Allgemeinen bringt und welche davon
für die Entwicklung von Multi-Touch-Applikationen besonders relevant sind, wird nach einer
kurzen Einleitung in die Struktur von HTML-Dokumenten behandelt.
Struktur von HTML-Dokumenten
Ein einfaches HTML-Dokument könnte beispielsweise so aussehen:
<!DOCTYPE html>
<html>
<head>
<title>Beispielseite</title>
</head>
<body>
<h1>Beispielseite</h1>
<p>Das ist ein Textabsatz mit einem <a ref="beispiel2.html">
Link</a> und einem Bild.</p>
<img src="bild.png" />
</body>
</html>
Listing 1: Quellcode eines einfachen HTML-Dokuments
Ein HTML-Dokument besteht aus Elementen und Text, die in einer Baumstruktur organisiert
sind. Elemente werden durch Start- und Endtags gekennzeichnet und können weitere Elemente oder Text beinhalten. Ein Starttag (z.B. <body>) ist durch einen in Kleiner- und Größerzeichen umschlossenen Tagnamen gekennzeichnet und kann mehrere Attribute (z.B.
src="bild.png") beinhalten. Die meisten Elemente müssen durch einen Endtag (z.B.
</body>) wieder geschlossen werden, außer sogenannte Void Tags. Void Tags (z.B. img)
28
dürfen weder weitere Elemente noch Text beinhalten, daher ist kein Endtag nötig. Der Starttag
kann optional aber mit einem Schrägstrich und Größerzeichen (/>) geschlossen werden.
(Hickson, 2012a; Pilgrim, 2010)
Jedes HTML-Dokument beginnt mit einer Doctype-Definition (<!DOCTYPE html> für
HTML5-Dokumente) und besteht aus einer Anzahl von verschachtelten und benachbarten
Elementen. Durch diese Verschachtelung ergibt sich eine Baumstruktur. Das <html> Element
bildet das Root Element (die Wurzel). Benachbarte Elemente werden Siblings (Geschwister)
genannt. Ein inneres Element ist als Child (Kind) zu seinem Parent (Elternteil) zu bezeichnen.
(Pilgrim, 2010, S. 33)
Das in Listing 1 dargestellte HTML-Dokument kann als Baum folgendermaßen dargestellt
werden:
html
|
+--head
| |
| +--text node "Beispielseite"
|
+--body
|
+--h1
| |
| +--text node "Beispielseite"
|
+--p
| |
| +--text node "Das ist ein Text-Absatz mit einem "
| |
| +--a
| | |
| | +--text node "Link"
| |
| +--text node " und einem Bild."
|
+--img
Listing 2: Baum-Darstellung des HTML-Dokuments aus Listing 1
HTML5
HTML 4.01 bietet ein begrenztes Set an verfügbaren Tags, aus welchen sich jede Website zusammensetzt. Um den vielseitigen Anwendungsszenarien von HTML-Dokumenten gerecht zu
werden, führt HTML5 über 30 neue Tags ein, um Inhalt besser zu strukturieren und dem Markup mehr semantischen Sinn zu geben. Beispiele hierfür sind <nav> für die Hauptnavigation
einer Seite, <section> für einen Bereich der Seite mit thematisch zusammengehörigem Inhalt
29
oder <header> und <footer> für Kopf- oder Fußzeilen einer <section> oder der gesamten Seite. (Clark, 2011; Pilgrim, 2010, S. 41)
Neben semantischen Elementen beinhaltet HTML5 Elemente für die Darstellung von Medien
und für clientseitig generierte Grafiken, ein API für die Abfrage von Geopositionsdaten, Möglichkeiten zur clientseitigen Formularvalidierung sowie Unterstützung für die Speicherung von
Daten auf dem Computer des Benutzers. HTML5 beinhaltet als Sammelbegriff eine Vielzahl an
Technologien, die nur teilweise mit HTML-Code programmiert werden. Die Mehrheit dieser
Funktionalität wird über JavaScript-APIs programmiert (siehe Kapitel 3.1.5).
Derzeit unterstützt kein Browser alle HTML5-Features, deshalb ist es nötig bei der Verwendung dieser Funktionen auf Abwärtskompatibilität zu achten. Während semantische Elemente
mit wenigen Zeilen JavaScript-Code auch für ältere Browser verfügbar werden, muss für fortgeschrittene HTML5-Technologien je nach unterstützter Funktionalität des Zielbrowsers eine
Fallbacklösung implementiert werden. Die JavaScript-Library Modernizr 36 kann für die Erkennung, ob eine Funktion verfügbar ist (Feature Detection), hilfreich sein (Pilgrim, 2010, S. 16).
Um HTML5 stärker zu fördern und schneller zu etablieren, hat
das W3-Konsortium ein eigenes Logo für HTML5 entwickelt und
bietet Entwickler/innen an, dieses Logo auf ihren Websites zu
verwenden, wenn HTML5-Features genutzt werden (siehe Abbildung 12).
Abbildung 12: HTML5 Logo
HTML5 Boilerplate
Vor allem für umfangreichere Webapplikationen, die auf HTML5-Funktionalität aufbauen,
empfiehlt sich die Verwendung eines Toolkits, das häufige Aspekte bei der Entwicklung von
HTML5-Websites oder Applikationen gezielt behandelt. Eines dieser Projekte ist HTML5 Boilerplate 37, das unter anderem von Paul Irish und Divya Manian entwickelt wird.
HTML5 Boilerplate stellt eine Sammlung an Einstellungen, Frameworks und Best-Practices dar
und beschleunigt damit die Entwicklung einer HTML5-Applikation. Das Toolkit umfasst unter
anderem:
•
Unterstützung älterer Browser inkl. Internet Explorer 6
•
Unterstützung von HTML5-Tags in älteren Browser
•
Maßnahmen zur Steigerung der Performance
36
http://modernizr.com/
37
http://html5boilerplate.com/
30
•
Optimierung für mobile Websites
•
Modernizr 38 für Erkennung von unterstützten Fähigkeiten des Browsers
•
jQuery
•
Eigene CSS-Klassen für Internet Explorer
(Gallagher, Manian, Reinl, Chuan, & Bynens, o. J.)
Das Projekt wird aktiv weiterentwickelt und ständig verbessert. Die aktuelle Version von
HTML5 Boilerplate ist Version 3.0.
3.1.2 Audio und Video Unterstützung
Das Video-Element (<video>) ermöglicht es, Videos direkt im Browser wiederzugeben ohne
von zusätzlichen Plug-ins wie Adobe Flash oder Apple QuickTime abhängig zu sein. Derzeit
unterstützen die wichtigsten Browser jeweils unterschiedliche Videoformate, daher ist es nötig,
mehrere Videodateien in unterschiedlichen Formaten bereitzustellen. Das von Google entwickelte Videoformat WebM versucht, durch ein offenes Lizenzmodell eine Lösung für dieses
Problem zu bieten. Die Browser Mozilla Firefox 39, Google Chrome und Opera 40 unterstützen
dieses Format bereits (Pilgrim, 2010, S. 89).
Analog zum Video-Element erlaubt das Audio-Element (<audio>) die Wiedergabe und Steuerung von Audiodateien. Auch für dieses Element müssen derzeit mehrere Dateien in unterschiedlichen Formaten angegeben werden, um eine möglichst hohe Browserunterstützung zu
erreichen (Boas, 2012). Auf das umfangreiche Themengebiet der Video- und Audiokodierung
für HTML5 wird in dieser Arbeit nicht weiter eingegangen.
Für die Entwicklung von Multi-Touch-Applikationen für die Ausführung im Browser stellt die
Unterstützung von Mediendateien eine wesentliche Erleichterung und Verbesserung dar. Wird
in einer Multi-Touch-Anwendung eine Video- oder Audiodatei eingebunden, so kann die
Wiedergabe dieser Elemente mit HTML5 nativ im Browser ausgeführt und damit Ressourcen
gespart werden.
3.1.3 Canvas und WebGL
Ein weiteres neues, mit HTML5 eingeführtes Element von großer Bedeutung ist Canvas
(<canvas>). (Hickson, 2012c) beschreibt in der HTML5 Spezifikation der WHAT Working
Group das Canvas-Element folgendermaßen:
„The canvas element provides scripts with a resolution-dependent bitmap canvas, which can be
used for rendering graphs, game graphics, or other visual images on the fly.”
38
http://modernizr.com/
39
http://www.mozilla.org/de/firefox/
40
http://de.opera.com/
31
Das Canvas-Element stellt eine grundlegende Neuerung dar. Bis einschließlich HTML 4 konnten Animationen nur über animierte GIF-Dateien oder zusätzliche Plug-ins wie Adobe Flash
oder Apple QuickTime realisiert werden. Canvas bietet eine umfangreiche JavaScript 41Programmierschnittstelle, um interaktive 2D-Grafiken clientseitig zu generieren. Elemente wie
Text, Grafikprimitive (Kreise, Linien, Rechecke, Polygone) oder Pfade werden unter Verwendung von verschiedenen Füll- und Linienfarben in einem zweidimensionalen Koordinatensystem positioniert. Die Koordinaten (0,0) beschreiben die linke obere Ecke der Zeichenfläche.
Der x-Wert wird nach rechts erhöht, der y-Wert nach unten (Hickson, 2012c; Pilgrim, 2010, S.
57); siehe Abbildung 13).
Abbildung 13: Koordinatensystem für die Positionierung von Elementen auf einem Canvas zwei Punkten (0,0)
und (4,2)
Wie bereits erwähnt, kann Canvas nicht nur statische Grafiken ausgeben. Über Maus- oder
Touchevents kann auf Benutzeraktionen reagiert werden, um komplexe, interaktive Animationen zu erstellen (Pilgrim, 2010, S. 77). Zahlreiche Bibliotheken abstrahieren die nativen Zeichenfunktionalitäten des Canvas-Elements, um die Entwicklung von interaktiven Grafiken
oder Spielen zu vereinfachen. Beispiele hierfür sind Paper.js 42 und Processing.js 43.
Paper.js basiert auf Scriptgrapher, der Scriptingsprache des vektororientierten Programms
Adobe Illustrator und bietet somit ein API um interaktive Grafiken über Vektormanipulation
für das Canvas-Element zu entwickeln (Paper.js (Hg.), o. J.).
Processing.js versucht die Syntax des Java-Frameworks Processing für Canvas zu übernehmen,
um so erfahrenen Processing-Entwickler/innen den Umstieg auf HTML5 zu erleichtern. Bereits vorhandener Processing-Code kann sehr einfach auf Processing.js übersetzt werden. Processing.js bietet (wie Processing selbst) auch die Möglichkeit, dreidimensionale Grafiken und
41
JavaScript wird im Kapitel 3.1.5 behandelt.
42
http://paperjs.org/
43
http://processingjs.org/
32
Animationen zu programmieren. Für 3D-Grafiken verwendet Processing.js nicht den 2DKontext des Canvas-Elements, sondern übersetzt den Code auf WebGL. (Processing.js (Hg.), o.
J.)
Die WebGL (Web Graphics Library) Spezifikation führt einen weiteren Grafikkontext für das
HTML5 Canvas-Element ein, der eine der OpenGL 44 ES 2.0 API weitgehend entsprechenden
Programmierschnittstelle zur Verfügung stellt. WebGL Programmcode wird direkt auf der
Grafikkarte des Computers ausgeführt und erzielt somit selbst bei komplexen Grafikoperationen eine hohe Leistung. (Marrin, 2012)
Neben Bibliotheken, die sowohl die Programmierung von 2D als auch 3D-Grafiken und Animationen ermöglichen wie Processing.js, richten andere Frameworks den Fokus auf den 3DKontext und WebGL-Rendering. Eines dieser Frameworks, dem derzeit viel Beachtung geschenkt wird, ist Three.js 45. Three.js ist eine JavaScript 3D-Engine zur Erstellung von komplexen dreidimensionalen, interaktiven Szenen. Die Bibliothek bietet unter anderem:
•
Hinzufügen und Entfernen von Objekten zur Laufzeit
•
Unterschiedliche Kameratypen (perspektivisch und orthografisch)
•
Unterstützung für Animationen über Schlüsselbilder und Morphing
•
Eine Vielzahl an Lichttypen, Materialien und geometrischen Figuren
•
Werkzeuge für die Umwandlung von verbreiteten 3D-Dateiformaten für die Verwendung in das von Three.js verwendete JSON-Format 46
(Cabello, 2012)
Durch die Möglichkeit, mit Three.js eine 3D-Szene zur Laufzeit über JavaScript-Befehle – und
somit auch mit Multi-Touch-Interaktionen – zu verändern, ergeben sich vielfältige Anwendungsfälle für grafisch anspruchsvolle, interaktive Applikationen oder Spiele, die im Browser
ausgeführt werden. Ein Beispiel hierfür ist das mit Three.js umgesetzte Spiel TriggerRally (siehe
Abbildung 14).
44
OpenGL ES ist ein freies, plattformübergreifendes API für 2D und 3D-Grafiken für Eingebettete Systeme.
OpenGL ES stellt ein Subset des OpenGL API dar und ermöglicht es, Hardware-beschleunigte Grafikoperationen auszuführen. (Khronos Group (Hg.), o. J.)
45
http://mrdoob.github.com/three.js/
46
JSON wird im Kapitel 3.1.5 behandelt.
33
Abbildung 14: Screenshot der Onlineversion des mit Three.js umgesetzten Spiels TriggerRally.
3.1.4 Fullscreen API
Eine weitere, für die Entwicklung von Webapplikationen hilfreiche Funktion ist das Fullscreen
API. Über dieses API kann mittels einer Aktion des Benutzers (z.B. ein Mausklick oder TapEvent) der gesamte Bildschirm für die Darstellung eines Elements oder einer gesamten Website
zur Verfügung gestellt werden.
Dieses Feature befindet sich derzeit noch in experimentellem Stadium und stellt daher noch
keine abgeschlossene Spezifikation dar. Das Fullscreen API wurde von Mozilla vorgeschlagen
und ist bereits seit Mozilla Firefox 10 und Google Chrome 15 verfügbar. Auch das W3C beschäftigt sich mit dem neuen API und hat eine Living Specification für das Fullscreen API veröffentlicht 47. (Kesteren & Çelik, 2012)
Um den Fullscreenmodus für ein Element zu aktivieren, wird in der von Mozilla vorgeschlagenen Syntax der Befehl element.requestFullScreen() verwendet. Die Syntaxen der Spezifikationen von Mozilla und dem W3C unterscheiden sich – wie auch die
Browserimplementierungen – geringfügig, daher sind die Methoden des API derzeit noch mit
browserspezifischen Präfixe (moz für Firefox und webkit für Chrome) zu versehen. (Doherty,
2012; Kesteren & Çelik, 2012; Schechter, 2012)
3.1.5 JavaScript, jQuery und JSON
JavaScript ist eine Programmiersprache, die entwickelt wurde, um die beschränkten Möglichkeiten von HTML-Dokumenten zu erweitern und Webseiten mit Funktionalität, die clientseitig im Browser des Benutzers ausgeführt wird, auszustatten. JavaScript ist kein Teil von HTML,
sondern eine Web Scripting Language und wird mit dem Standard ECMAScript Programming
Language definiert48. (Ecma International, 2011; Flanagan, 2006, S. 1)
47
In der Spezifikation wird betont, dass das Fullscreen API kein W3C Standard ist und sich auch nicht auf
dem Weg dorthin befindet.
48
http://ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
34
JavaScript ist eine interpretierte, schwach typisierte, objektorientierte, aber klassenlose Sprache
mit einer Syntax, die Elemente der Programmiersprachen C, C++ und Java verwendet. Die
Vererbung von Objekten geschieht in JavaScript über das sogenannte Prototypal Inheritance,
was für Programmierer/innen mit Erfahrung in anderen objektorientierten Programmiersprachen eine Umstellung darstellt. (Crockford, 2008, S. 7; Flanagan, 2006, S. 122)
Wenn von JavaScript gesprochen wird, so bezieht man sich in den meisten Fällen auf clientseitiges JavaScript, da dies die am weitesten verbreitete Verwendung ist. Die Popularität von Frameworks wie Node.js 49 zeigen aber auch Einsatzmöglichkeiten von JavaScript für serverseitig
ausgeführte Anwendungen.
Clientseitiger JavaScript-Code wird von einem in den Browser eingebetteten JavaScriptInterpreter ausgeführt. JavaScript erlaubt es, Entwickler/innen beispielsweise auf Benutzereingaben via Tastatur oder Maus zu reagieren, Daten asynchron nachzuladen oder Elemente einer
HTML-Seite zu verändern. Dafür verwendet JavaScript das Document Object Model (DOM),
ein vom W3C definierter Standard, der den Zugriff auf alle Elemente einer Seite und deren
Eigenschaften erlaubt. (Flanagan, 2006, S. 361)
Wie Douglas Crockford (2008, S. 8) beschreibt, beinhaltet JavaScript Designfehler und fehlerhafte Funktionalität sowie Konzepte, die bei vielen Programmierer/innen für Verwirrung sorgen. Diese Schwachstellen können und müssen aber umgangen werden, um die mächtige und
vielseitige Programmiersprache JavaScript sinnvoll einsetzen zu können.
Zu diesen Designfehlern zählt beispielsweise der Umstand, dass Variablen globalen Geltungsbereich besitzen. Dies kann schon bei Applikationen mit geringem Umfang zu Problemen führen und ist daher gezielt zu adressieren, um Konflikte zu vermeiden. (Crockford, 2008, S. 3)
Bei der Verwendung von JavaScript muss zudem darauf geachtet werden, dass die Browser
Unterschiede in der Implementierung des JavaScript Interpreters aufweisen. Dadurch ergeben
sich Kompatibilitätsprobleme, die hohe Kosten in der Entwicklung verursachen können. Eine
Anzahl von JavaScript-Frameworks versuchen diese Problematik durch Abstraktion von JavaScript-Funktionalität zu verringern. Ein sehr bekannter Vertreter dieser Frameworks ist
jQuery.
jQuery
Die JavaScript-Bibliothek jQuery 50 vereinfacht und vereinheitlicht den Zugriff auf HTMLDokumente, Eventhandling, Animationen und Ajax-Funktionalität. Mit der Verwendung von
jQuery entfallen viele Probleme, die durch unterschiedliche JavaScript-Implementierungen
seitens der Browserhersteller entstehen. (jQuery Foundation (Hg.), o. J.)
49
http://nodejs.org/
50
http://jquery.com/
35
jQuery ist ein sehr populäres Framework und besitzt daher eine große Entwickler/innencommunity, die den Kern und eine große Anzahl von Plug-ins entwickelt. Die Plug-in
Architektur stellt eines der wesentlichen Konzepte von jQuery dar und ist mit ein Grund für
die weite Verbreitung. Für sehr viele Probleme, denen Programmierer/innen bei der Entwicklung von JavaScript für Webseiten und -applikationen begegnen, existieren bereits Plug-ins für
jQuery. Diese Modularität erlaubt es, Quellcode einfach anderen Benutzer/innen zur Verfügung zu stellen und im Umkehrschluss, ein definiertes Set an Plug-ins für jQuery zu verwenden, ohne die Funktionalität der einzelnen Plug-ins selbst implementieren zu müssen.
Ein weiteres Konzept von jQuery ist das Chaining. Über Punktnotation können mehrere Operationen eines Element durch Aneinanderhängen (Chaining) ausgeführt werden. Dieses Konzept sorgt nicht nur für wesentlich weniger Quellcode, sondern erleichtert auch die
Manipulation von Elementen und ist ressourcensparend, da die Auswahl von DOM-Elementen
rechenintensive Operationen mit sich führen kann. (jQuery Community Experts, 2010)
$("div.name").hide().text("Grubinger").addClass("lastname").show();
Listing 3: Beispiel für Chaining in jQuery.
In dem in Listing 3 dargestellten Beispiel, werden in einer Zeile JavaScript/jQuery-Code folgende Schritte durchgeführt:
•
Alle DIV-Elemente (<div>) mit der Klasse name werden ausgewählt,
•
unsichtbar gemacht,
•
der Inhalt der selektierten Elemente mit dem Text „Grubinger“ ersetzt,
•
eine weitere Klasse lastname hinzugefügt und
•
wieder angezeigt.
JSON
JSON ist ein kompaktes Format zum Datenaustausch zwischen verschiedenen Arten von Programmen und basiert auf der Object Literal Notation 51 von JavaScript. JSON wird als Text
gespeichert und ist damit sowohl von Computern als auch Menschen lesbar. Ein JSON-Objekt
besteht aus einer ungeordneten Liste an paarweise auftretenden Name/Wert-Kombinationen.
Der Name muss ein String sein, der Wert kann sechs unterschiedliche Typen beinhalten: Objekte, Arrays, Strings, Zahlen, Boolsche Werte und den Wert null. (Crockford, 2008, S. 136)
In dem in Listing 4 ersichtlichen Beispiel werden zwei Elemente mit unterschiedlichen Wertetypen dargestellt. Der Ausdruck tea_json[1].origin liefert in diesem Beispiel den Wert
„any region with temperate climate“ als Textkette.
51
Ein Objektliteral ist eine Möglichkeit in JavaScript Objekte zu erzeugen. Sie bestehen aus einem Paar an
geschwungenen Klammern, das null oder mehr Paare aus Name und Wert umschließt. (Crockford, 2008, S.
20)
36
JSON-Objekte können ohne Einschränkungen ineinander verschachtelt werden, allerdings
empfiehlt es sich für bessere Lesbarkeit, die Struktur möglichst flach zu halten.
Eine Vielzahl an Programmiersprachen bieten Parser für JSON-Objekte, dadurch bietet sich
JSON als Format zum Austausch von Daten über verschiedene Systeme hinweg an. Viele moderne APIs von Webservices bieten daher neben dem XML-Format die Daten auch im JSON
Format an.
var tea_json = [
{
"name": "Darjeeling",
"origin": "India",
"stimulative": true,
"cups_consumed_today": 1
},
{
"name": "Peppermint",
"origin": "any region with
"stimulative": false,
"cups_consumed_today": 3
} ]
//
//
//
//
String
String
Boolean
Number
temperate climate",
Listing 4: Ein einfaches JSON-Objekt eines Arrays mit zwei Objekten mit jeweils vier Name/Wert-Paaren.
3.1.6 CSS(3)
Cascading Style Sheets (CSS) ermöglichen, das visuelle Erscheinungsbild eines Dokuments
oder einer Reihe von Dokumenten zu gestalten. Ein Dokument kann beispielsweise eine
HTML-Seite sein. CSS wird aber auch von Mozilla für die Gestaltung der Benutzerschnittstelle
von Firefox verwendet. Mittels CSS werden die in HTML strukturierten Daten und Informationen einer Website in das gewünschte Layout gebracht, Farben angepasst, Schriftarten definiert und viele weitere visuelle Aspekte konfiguriert. (Laborenz, 2011, S. 19; Meyer, 2007, S. 1)
In den Anfangszeiten des Webs (1990-1993) beschränkten sich Webseiten auf HTML-Markup,
das Informationen übersichtlich darstellte. Webseiten bestanden im Wesentlichen aus Überschriften, Absätzen, Listen und Hyperlinks zu anderen Dokumenten. Erst mit der Einführung
des ersten – im Sinne der heute aktuellen Browser – Webbrowsers Mosaic im Jahr 1993, etablierte sich das World Wide Web auch außerhalb des akademischen Kontexts. Entwickler/innen
von Webseiten begannen, HTML-Elemente mit Attributen zu versehen, die die Darstellung im
Browser beeinflussen. Das führte zu unübersichtlichen und aufwändig zu wartenden HTMLDokumenten. Bei einer Änderung beispielsweise der Farbe aller Überschriften auf einer umfangreichen Website mussten alle Links einzeln bearbeitet werden. (Laborenz, 2011; Meyer,
2007; Vetter, 1994)
Diese Entwicklung veranlasste das W3C, 1995 ein Konzept mit den Arbeitstitel CSS zu veröffentlichen und diesen Problemen entgegenzuwirken. 1996 erlangte CSS den Empfehlungsstatus
37
des W3C. Während erst 2001 die aktuelle Version von CSS (Level 2.1) im Juni 2011 vollen
Empfehlungsstatus erhielt, arbeitet die W3C CSS Working Group schon seit dem Jahr 2000 an
Level 3 von CSS. Dieses Level wird – in der Nomenklatur konsistent mit HTML5 – einfach
CSS3 genannt. (Bos, Çelik, Hickson, & Lie, 2011; Meyer, 2000, 2007, S. 4)
Die wesentliche Aufgabe von CSS ist die Trennung von Inhalt und Aussehen einer Webseite.
Während der Inhalt und die logische und semantische Beschreibung einer Webseite mit
HTML realisiert wird, ist CSS für die Zuweisung von Stilanweisungen für die Formatierung
und das Aussehen einer Website zu verwenden. (Laborenz, 2011, S. 22)
Für die Formatierung eines HTML-Dokuments mit CSS wird meist eine externe CSS-Datei
angelegt und im HTML-Quellcode referenziert. Mehrere HTML-Seiten einer Website können
so auf die gleiche CSS-Datei zugreifen, Änderungen am Style Sheet (CSS-Datei) wirken sich auf
alle referenzierenden Dokumente aus. Das erleichtert die Wartung und Weiterentwicklung von
Websites enorm. (Meyer, 2007, S. 7)
Ein weiteres Schlüsselkonzept von CSS ist die bereits im Namen enthaltene Kaskadierung. Mittels Kaskadierung können Stile, die für mehrere Elemente Geltung besitzen, auf einer Untermenge dieser Elemente erweitert oder überschrieben werden. Kaskadierung ist ein einfacher,
aber effektiver Mechanismus, um trotz Stilregeln, die für eine Vielzahl von Elementen gelten,
flexibel bei der Gestaltung von einzelnen Elementen zu bleiben. Welcher Stil für ein bestimmtes Element, dessen Stilattribut mehrfach definiert wurde, verwendet wird, folgt genau definierten Regeln und wird von mehreren Faktoren wie Nähe zum Element und Hierarchie bestimmt.
(Meyer, 2007, S. 8)
CSS3
Das noch in Entwicklung befindliche CSS Level 3 führt eine Reihe neuer Funktionen ein, die
von CSS-Autoren verwendet werden können, um HTML-Elemente zu positionieren, formatieren oder animieren. CSS3 basiert auf dem überarbeiteten Kern von CSS 2.1 und einer Reihe
von Modulen, die von eigenständigen Arbeitsgruppen entwickelt werden. Auch wenn die neuen Module noch nicht vom W3C verabschiedet wurden, implementieren moderne Browser
diese bereits teilweise. Um Kompatibilitätsproblemen bei einer in der Zukunft stattfindenden
Standardisierung mit geänderter Syntax entgegenzuwirken, sind viele der mit CSS3 verfügbaren Funktionen mit Browser-Präfixen zu versehen. Dadurch entstehten weniger übersichtliche
und aufwändiger zu wartende CSS-Anweisungen (siehe Listing 6).
Eine einfache CSS-Regel wird in Listing 5 dargestellt. Diese Regel färbt alle Überschriften der
ersten Ordnung (<h1>) eines Dokuments rot und zeigt eine graue Randlinie mit einem Pixel
Strichstärke um das gesamte Element an. Zusätzlich wird der Hintergrund mit einem vertikalen Verlauf von Gelb nach Blau eingefärbt.
38
h1 {
color: red;
border: 1px solid #ccc;
linear-gradient(yellow, blue);
/* Rote Schrift */
/* Durchgängiger Rand mit 1px
und #ccc Farbe */
/* Linearer Verlauf von Gelb
nach Blau */
}
Listing 5: Einfache CSS-Regel mit drei Attributen
Die Eigenschaft linear-gradient wurde erst mit CSS3 eingeführt. Obwohl diese Eigenschaft bereits den Candidate Recommendation des W3C besitzt, muss ein Verlauf derzeit zusätzlich noch mit den erwähnten Präfixen für die verschiedenen Browser definiert werden
(Deveria, o. J.) siehe Listing 6).
h1 {
[...]
-moz-linear-gradient(yellow, blue);
-webkit-linear-gradient(yellow, blue);
-o-linear-gradient(yellow, blue);
linear-gradient(yellow, blue);
}
/*
/*
/*
/*
/*
Zusaetzl. Attribute
Mozilla Browser
Webkit Browser
Opera
W3C Syntax
*/
*/
*/
*/
*/
Listing 6: CSS-Regel mit Browser-Präfixe für CSS3-Attribute
Eine aktuelle Auskunft über den Implementierungsstatus von CSS3 Eigenschaften in den vergangenen, derzeitigen und zukünftigen Versionen der meistgenutzten Browser gibt die Website When Can I Use? 52. Auf der Detailansicht der einzelnen Eigenschaften können sich
Entwickler/innen auch über die Notwendigkeit der Verwendung von Präfixen informieren
sowie externe Links zu den jeweiligen Spezifikationen des W3C finden.
CSS3 Transforms
Eine mit CSS3 neu eingeführte Eigenschaft ist für die Entwicklung von gestenbasierten MultiTouch-Applikationen von besonders großem Nutzen: transform. Mittels transform kann
ein HTML-Element im 2D oder 3D Kontext über eine Transformationsmatrix transformiert
werden. Über die Parameter der Eigenschaft kann ein DOM-Element verschoben (translate), skaliert (scale) oder rotiert (rotate) werden. Werden diese Transformationen im 3DKontext mit den Achsen x, y, z verwendet, so kann zusätzlich noch die Perspektive (perspective), der sogenannte Betrachtungsabstand verändert werden. Standardmäßig werden die
Transformationen ausgehend vom Zentrum des Elements (X-Achse: 50%, Y-Achse: 50%) berechnet, diese Position kann jedoch über die transform-origin Eigenschaft modifiziert
werden. (Fraser u. a., 2012)
52
http://caniuse.com
39
CSS Transforms sind ein eigenständiges CSS3-Modul und befinden sich noch im Stadium des
Editor’s Draft, daher können noch Änderungen von Seiten des W3C vorgenommen werden
(Fraser u. a., 2012). Aktuelle Browserversionen unterstützen jedoch bereits Transformationen
mit CSS 53, allerdings müssen auch bei dieser Eigenschaft aufgrund der noch nicht abgeschlossenen Spezifikation die erwähnten Browser-Präfixe -moz, -webkit, -o und zusätzlich -ms für
Internet Explorer vorangestellt werden.
Abbildung 15 zeigt ein Bild mit den in Listing 7 definierten CSS Transformationen.
img.transformed {
-moz-transform: translate(100px) rotate(20deg);
-moz-transform-origin: 60% 100%;
-webkit-transform: translate(100px) rotate(20deg);
-webkit-transform-origin: 60% 100%;
-o-transform:translate(100px) rotate(20deg);
-o-transform-origin: 60% 100%;
-ms-transform: translate(100px) rotate(20deg);
-ms-transform-origin: 60% 100%;
transform: translate(100px) rotate(20deg);
transform-origin: 60% 100%;
}
Listing 7: CSS-Regel für die Verschiebung um 100px an der X-Achse sowie Drehung um 20 Grad für Bilder der
Klasse transformed. Der Mittelpunkt der Transformation befindet sich bei X=60% und Y=100%. (Patonnier,
2012)
53
CSS Transforms sind ab Internet Explorer 9, Mozilla Firefox 3.5, Google Chrome 4, Apple Safari 3.1 und
iOS Safari 3.2, Opera 10.5 und Android Browser 2.1 unter Verwendung von Browser-Präfixen verfügbar.
(Deveria, o. J.)
40
Abbildung 15: Resultat der in Listing 7 definierten Transformationen. Das halbtransparente Bild zeigt die Ausgangsposition, der rote Punkt markiert den Ursprungspunkt (transform-origin).
CSS3 Transitions und Animations
Selbst einfache Übergänge und Animationen von DOM-Elementen konnten vor CSS3 nur
über JavaScript-Anweisungen realisiert werden. Das führt einerseits dazu, dass Benutzer die
JavaScript in ihrem Browser deaktiviert haben, diese Übergänge und Animationen nicht sehen
können und benötigt andererseits – im Vergleich zu CSS3 Funktionen – viel Prozessorleistung,
was sich negativ auf die Darstellbarkeit auf mobilen Endgeräten auswirkt.
Mit CSS Transitions können für einzelne CSS-Attribute Übergangsanimationen definiert werden. So kann beispielsweise ein gradueller Übergang zwischen der normalen Hintergrundfarbe
und einer anderen Hintergrundfarbe bei einem Maushover realisiert werden (Laborenz, 2011,
S. 365).
Komplexere Animationen können über das Attribut animation realisiert werden. Über vorher definierte Schlüsselbilder (Keyframes) kann das zu animierende Element verschiedene Zustände mitsamt Easingfunktionen 54 während einer einzelnen Animation annehmen (Laborenz,
2011, S. 366–369).
54
Easingfunktionen beschreiben den zeitlichen Ablauf einer Animation/Transformation. Sie ermöglichen
nicht-lineare Animationsabläufe und sorgen so für als natürlicher wahrgenommene Animationen. (Flanagan, 2006, S. 556; Laborenz, 2011, S. 365)
41
h1 {
animation-duration: 3s;
animation-name: moveright;
}
@keyframes moveright {
from {
margin-left: 100px;
}
to {
margin-left: 0px;
}
}
Listing 8: Beispiel-Code einer CSS-Animation mit zwei Schlüsselbilder (from, to). Ein H1-Element bewegt sich
dabei innerhalb von drei Sekunden um 100 Pixel von rechts nach links. Aus Gründen der Lesbarkeit wurde auf
Browser-Präfixe verzichtet. (Perrier, 2012)
Listing 8 zeigt ein Beispiel für die Verwendung von CSS Animationen. Die Syntax sieht zwei
getrennte Teile vor: einerseits die Deklaration der Animation mittels Schlüsselbilder und Identifikation mit einem Namen (moveright) mit der @keyframes Syntax und andererseits die
Zuweisung einer definierten Animation an ein Element über die CSS-Eigenschaft animation-name. Diese Syntax trennt die eigentliche Beschreibung der Animation vom verwendenden
Element. Dadurch ergeben sich zwei wesentliche Vorteile: Die CSS-Stile der einzelnen Elemente bleiben besser lesbar und die Animationen sind für andere Elemente wiederverwertbar.
3.2 Touchevents und deren Unterstützung in
aktuellen Browserversionen
Die wichtigste Voraussetzung für Multi-Touch-Applikationen auf Basis von HTML und
JavaScript ist die Möglichkeit, auf Touchinformationen im Browser zugreifen zu können.
Clientseitiges JavaScript verwendet ein Programmierkonzept, das auf asynchrone Eventverarbeitung baut. In diesem Konzept erzeugt der Webbrowser ein Event, wenn ein Ereignis im
Zusammenhang mit dem Browser oder dem aktuellen Dokument aufgetreten ist. Eine derartige Aktion kann etwa der Abschluss des Ladevorgangs des Dokuments, ein Tastenanschlag des
Benutzers/der Benutzerin, ein Klick mit der Maus auf ein bestimmtes Element oder auch eine
Berührung des Touchscreens sein. Zusätzlich zu den genannten Ereignissen existieren eine
Vielzahl weiterer Events; vor allem im Zusammenhang mit neuen HTML5-Features wie Video
oder Audio wurden einige neue Events eingeführt. (Flanagan, 2006, S. 447–449)
Wird eines dieser Ereignisse vom Browser registriert, so sendet dieser ein entsprechendes
Event. Bei einem Mausklick auf ein Element wird beispielsweise das Event mousedown bei
Betätigung der Maustaste und mouseup beim Loslassen gesendet. Wenn der Benutzer die
42
Maus zwischen diesen beiden Events bewegt, so werden dazwischen zusätzlich mousemove
Events gesendet, die die Bewegung der Maus repräsentieren. (Flanagan, 2006, S. 451)
Um in einer Applikation auf Events zu reagieren, muss für jedes Event ein Eventhandler (auch:
Eventlistener) definiert werden. Der Eventhandler verknüpft ein Event mit einer Funktion, die
beim Auftreten des Events ausgeführt wird. Zusätzlich zur Information, welches Event gesendet wurde, sind Events mit Attributen mit weiteren Informationen (beispielsweise welches
Element das Event ausgelöst hat, Koordinaten des Mausklicks, welche Keyboardtaste gedrückt
wurde etc.) versehen. (Flanagan, 2006, S. 446)
3.2.1 Mobile Endgeräte
Mit der hohen Verbreitung von mobilen Endgeräten mit Multi-Touch-fähigen Bildschirmen
reichen die vorhandenen Events für Interaktionen des Benutzers mit dem System nicht mehr
aus. In einigen Fällen können zwar Touchinteraktionen auf Mausinteraktionen wie Klick und
Scroll übertragen werden, aber um Benutzerschnittstellen zu realisieren, die von der Erkennung von mehreren Berührungspunkte profitieren, sind entsprechende Events notwendig.
(Flanagan, 2006, S. 456)
Aus diesem Grund entwickelte Apple für seinen auf den mobilen Geräten iPhone, iPod und
iPad verwendeten Browser Safari ein Eventsystem zur Beschreibung von Multi-Touch- und
Gestenevents (Flanagan, 2006, S. 456).
Über lange Zeit war Safari auf mobilen Endgeräten von Apple der einzige Browser, der diese
Events vollständig unterstützte. Der auf Android-Geräten standardmäßig verwendete Browser 55 sendet zwar Multi-Touch-Events bei einer Berührung des Displays an den Browser, allerdings nur für den jeweils ersten Finger einer Berührungssequenz und ist somit nicht MultiTouch-fähig. Der inzwischen für Android erhältliche Browser Chrome 56 unterstützt MultiTouch-Events auch für mehrere Finger und ist damit für Multi-Touch-Applikationen geeignet.
Zusätzlich zu Multi-Touch-Events, sendet Safari auch Gesture-Events, wenn das System eine
Rotate oder Scale Geste (siehe Kapitel 2.2) erkennt. Damit nimmt der Browser die Erkennung
von Gesten den Entwickler/innen ab und lässt gleichzeitig mittels niederschwelligen MultiTouch-Events die Erkennung von anderen Gesten zu. Derzeit ist Safari der einzige Browser,
der Gesture-Events unterstützt. (Apple (Hg.), 2010; Flanagan, 2006, S. 456)
55
Der Android-Browser basiert wie Apple Safari und Google Chrome auf der WebKit Engine.
56
https://www.google.com/intl/en/chrome/browser/mobile/android.html
43
3.2.2 W3C Touch Events
Das W3C erkannte die Notwendigkeit, diese Multi-Touch-Events zu standardisieren und veröffentlichte im Dezember 2011 eine Spezifikation für Touchevents 57 mit Candidate Recommendation Status (Brubeck, Moon, & Schepers, 2011; Flanagan, 2006, S. 456).
Diese Spezifikation ist stark an das von Apple eingeführte System angelehnt. Folgende Events
vom Objekttyp TouchEvent sind verfügbar: Das Event touchstart wird gesendet, wenn ein
Finger den Bildschirm berührt, touchmove wenn der Finger bewegt wird und touchend
wenn der Finger die Oberfläche verlässt. Zusätzlich ist das Event touchcancel vorgesehen,
welches ausgelöst wird, wenn das System die Verfolgung einer Berührung abbricht. Ein Beispiel für dieses Event ist, wenn ein Finger aus dem Multi-Touch-fähigen Bereich ohne Unterbrechung in die grafische Benutzerschnittstelle des Browsers bewegt wird. (Brubeck u. a., 2011;
Flanagan, 2006, S. 456)
Abbildung 16: Die Beziehung zwischen Berührung und den Objekttypen TouchEvent, TouchList und Touch.
Ein TouchEvent besitzt in der W3C-Spezifikation einige Attribute, die detaillierte Informationen über das Event beinhalten. Die Attribute altKey, metaKey, ctrlKey und shiftKey
geben Informationen, ob eine bestimmte Taste auf der Tastatur gedrückt wurde während das
TouchEvent ausgelöst wurde. Für die Entwicklung von Multi-Touch-Applikationen sind die
Attribute touches, targetTouches und changedTouches vom Objekttyp TouchList
von großer Relevanz (siehe Tabelle 2). (Brubeck u. a., 2011)
Attribut
Typ
touches
TouchList
targetTouches
TouchList
57
Zweck
Beinhaltet alle derzeit auf der Oberfläche befindlichen
Touches.
Beinhaltet alle derzeit auf der Oberfläche befindlichen
Touches, die auf dem Event-generierenden Objekt (target) begonnen hatten.
Anmerkung: Der Autor unterscheidet hier zwischen zwei Schreibweisen: Touchevents in der deutschen
Schreibweise und Touch Event in Eigennamen wie W3C Touch Events.
44
changedTouches
TouchList
Beinhaltet alle Touches, die zur Auslösung des Event
beigetragen haben.
Tabelle 2: TouchList-Attribute eines TouchEvent-Objekts (Brubeck u. a., 2011).
Wie in Abbildung 16 ersichtlich, beinhalten die TouchList-Attribute jeweils eine Liste von
Objekten vom Typ Touch. Ein Touch-Objekt entspricht dabei einem einzelnen Berührungspunkt auf der Oberfläche und beinhaltet einige Attribute, die den Punkt beschreiben (siehe
Tabelle 3).
Attribut
Typ
identifier
long
target
EventTarget
screenX
long
screenY
long
clientX
long
clientY
long
pageX
long
pageY
long
Zweck
Eine Identifikationsnummer, die unter allen aktiven
Berührungspunkten einzigartig ist. Alle Events, die sich
auf diesen Punkt beziehen, müssen die selbe Nummer
verwenden.
Das Element auf dem die Berührung begonnen hat,
auch wenn der Punkt sich aktuell außerhalb des Elements befindet.
Die horizontale Koordinate des Punktes relativ zum
Bildschirm.
Die vertikale Koordinate des Punktes relativ zum Bildschirm.
Viewport 58 des Browsers ohne Scrollversatz.
Die vertikale Koordinate des Punktes relativ zum
Viewport des Browsers ohne Scrollversatz.
Viewport des Browsers inklusive Scrollversatz.
Viewport des Browsers inklusive Scrollversatz.
Tabelle 3: Attribute eines Objekts vom Typ Touch (Brubeck et al., 2011).
Bei genauerer Betrachtung dieser Attribute fällt auf, dass keine Eigenschaft die Koordinaten
des Berühungspunkts relativ zu dem das Event auslösende Element (target) beinhaltet. Wird
dieser Punkt (beispielsweise für eine Drag-Aktion) benötigt, muss er über die Positionsattribute des Elements und den Attributen pageX und pageY des Punktes ermittelt werden.
58
Der Begriff Viewport bezieht sich im Zusammenhang mit Webbrowser auf die Größe des aktuellen Darstellungsbereichs ohne eventuell sichtbare Elemente der Benutzerschnittstelle des Browsers selbst.
45
Derzeit arbeitet die W3C Web Events Working Group an Version 2 der Touch Events Spezifikation. Zum Zeitpunkt der Erstellung dieser Arbeit befindet sich Version 2 im Status Editor’s
Draft und stellt somit eher eine Sammlung an Ideen als eine fertige Spezifikation dar. Aufgrund
der Veränderlichkeit, die dieser Status impliziert, werden die folgenden Erweiterungen noch in
keinem Browser unterstützt.
Version 2 der Touch Events erweitert Version 1 um die Events touchenter und touchleave, welche beim Eintreten bzw. Verlassen der Fläche eines DOM-Elements gesendet werden.
Die Spezifikation sieht derzeit zusätzlich für Objekte vom Typ Touch die in Tabelle 4 ersichtlichen Attribute vor. (Schepers, Moon, & Brubeck, 2011)
Attribut
Typ
radiusX
long
radiusY
long
rotationAngle
float
force
float
Zweck
Der Radius an der X-Achse einer Ellipse, die die
Kontur des Berührungspunktes am genauesten beschreibt.
Der Radius an der Y-Achse einer Ellipse, die die
Kontur des Berührungspunktes am genauesten beschreibt.
Die Rotation der mit radiusX und radiusY beschriebenen Ellipse um deren Zentrum (0 bis 90 Grad).
Der relative Anpressdruck von 0 bis 1, wobei 0 keinen Druck und 1 den maximalen vom Gerät messbaren Druck darstellt.
Tabelle 4: Zusätzliche in Version 2 der Touch Event Spezifikation (Editor’s Draft) vorgesehene Attribute eines
Objekts vom Typ Touch (Schepers u. a., 2011).
3.2.3 Mozilla Touch Events
Mozilla führte im März 2011 mit der Version 4 seines Browsers Firefox ein API für die Verwendung von Touchevents unter Windows 7 ein.(Mozilla Foundation (Hg.), 2011) Zu diesem
Zeitpunkt war die Spezifikation des W3C (Kapitel 3.2.2) noch nicht finalisiert. Aus diesem
Grund entwickelte Mozilla ein eigenes, proprietäres API zur Verwendung von (Multi-)TouchInformationen in Webdokumenten.
Das Mozilla Touch Event-API ist ähnlich konzipiert wie das vom W3C empfohlene. Es unterscheidet sich jedoch in drei wesentlichen Punkten:
•
Die von Mozilla verwendeten Events verwenden andere Namen und den Präfix Moz
anstelle der vom W3C spezifizierten Namen (siehe Tabelle 5). Für das Event touchcancel der W3C Spezifikation existiert in dem Mozilla Touch Event-API kein Pendant.
46
Mozilla
W3C-Pendant
MozTouchDown
touchstart
MozTouchMove
touchmove
MozTouchUp
touchend
Tabelle 5: Unterschiedliche Bezeichnungen der Touchevents in Mozilla Firefox und W3C Spezifikation.
•
Die in Kapitel 3.2.2 beschriebenen Attribute touches, targetTouches und changedTouches sind in den Mozilla Touch Events nicht verfügbar. Wird eine Liste der
aktuellen Berührungspunkte benötigt, muss diese zusätzlich implementiert werden.
•
Mozilla verwendet die Bezeichnung streamId für das Attribut, das die eindeutige
Identifikationsnummer des Berührungspunktes beinhaltet. Das W3C verwendet die
Bezeichnung identifier.
Mozilla hat die Arbeit an diesem API mit Firefox 6 eingestellt und den Status auf überholt
(deprecated) gesetzt. In der Android-Version von Firefox werden ab dieser Version die vom
W3C spezifizierten Touchevents unterstützt (Brubeck, 2012). Die zum Zeitpunkt der Erstellung dieser Arbeit aktuelle Firefox Version 13.0.1 sowie der aktuelle Nightly Build 59 16.0a1 für
Windows 7 unterstützen diese Events jedoch noch nicht.
3.2.4 Microsoft Pointer Events (IE10)
Microsoft setzt mit der neuen Version seines Browsers Internet Explorer 10 verstärkt auf Multi-Touch und Gestenunterstützung 60. Dafür hat Microsoft ein proprietäres API entwickelt, das
Interaktionen des Benutzers über ein Eingabegerät abstrahiert und zu sogenannten Pointer
zusammenfasst. Je nach verwendetem Eingabegerät entspricht ein Pointer entweder einer Fingerberührung, einem Eingabestift oder einfach einem Mauszeiger. (Rossi, 2011)
Abbildung 17: Pointer vereint Touch, Stift und Mauseingaben (Rossi, 2011).
59
Nightly Builds sind Entwicklungs-Versionen von Firefox, die die aktuellsten Änderungen beinhalten. Der
Begriff Nightly leitet sich von dem Umstand ab, dass diese Builds traditionell meist nachts kompiliert wurden, wenn kein/e Entwickler/in am Quellcode arbeitet. Nightly Builds sind Testversionen, die möglicherweise Instabilitäten aufweisen und sollten daher nicht in einer Produktivumgebung eingesetzt werden.
(Yeow, 2005, S. 273)
60
Derzeit ist Internet Explorer 10 nur in einer Preview-Version mit Windows 8 Release Preview erhältlich.
47
Pointer können die folgenden Events auslösen:
Event
Aktion
MSPointerDown
Beim ersten Kontakt des Pointers
MSPointerMove
Bei einer Bewegung eines aktiven Pointers
MSPointerUp
Bei Beendigung des Kontakts
MSPointerOver
Bei Eintritt eines Pointers in die Fläche eines DOM-Elements
MSPointerOut
Beim Austritt eines Pointers aus der Fläche eines DOM-Elements
MSPointerCancel
Bsp: Wenn mehr Finger als vom Gerät unterstützt auf der Oberfläche platziert werden
Tabelle 6: MSPointer Events
Wird eines dieser Events ausgelöst, so kann über das event-Objekt auf Attribute des Pointers
wie Position, ID etc. zugegriffen werden. Zusätzlich zu den herkömmlichen Attributen können
alle aktuell auf dem Bildschirm vorhandenen Kontaktpunkte (Pointer) über die Methode
event.getPointerList() abgerufen werden (Microsoft (Hg.), o. J.-e). Diese Liste ist in der
bereitgestellten Funktionalität dem Attribut touches der W3C Touch Events sehr ähnlich.
Zusätzlich zu dieser Abstraktion von Eingabemöglichkeiten führt Microsoft Unterstützung für
statische und dynamische Gesten ein. Statische Gesten sind über die Events MSGestureTap,
MSGestureDoubleTap, die den Gestenmustern Tap und Double Tap entsprechen (siehe Kapitel 2.2), sowie MSGestureHold, eine länger andauernde Berührung ohne Bewegung, verfügbar. (Microsoft (Hg.), o. J.-e; Rossi, 2011)
Bei dynamischen Gesten werden die Events MSGestureStart bei Beginn, MSGestureChange bei jeder Änderung und MSGestureEnd bei Beendigung der Geste gesendet. Diese Events
liefern die Attribute translation (Verschiebung), rotation (Drehung), scale (Skalierung) sowie velocityX und velocityY (Geschwindigkeit) um auf Veränderungen während
der Durchführung der Geste reagieren zu können. (Microsoft (Hg.), o. J.-e)
Mit diesem API soll es einfacher werden, Benutzerschnittstellen mit fortgeschrittenen Eingabemöglichkeiten wie Touch und Gesten bei gleichzeitiger Geräteunabhängigkeit zu entwickeln.
Dieser Ansatz ist grundsätzlich zu begrüßen, allerdings ist an den Reaktionen der Entwickler/innen auf den das Pointer-Konzept vorstellenden Blogeintrag zu erkennen, dass Unmut
über die Tatsache herrscht, dass Microsoft seine Touchunterstützung nicht nach den W3C
Spezifikationen ausrichtet, sondern eigene Wege beschreitet (Rossi, 2011).
48
3.2.5 Touchevents in Google Chrome
Zum Zeitpunkt der Erstellung dieser Arbeit unterstützt Google’s Browser Chrome in der aktuellsten Version 20 standardmäßig keine Touchevents vollständig. Bei gleichzeitigem Kontakt
von zwei Berührungspunkten auf dem Bildschirm wird ein touchstart Event gesendet, jedoch kein touchmove oder touchend Event. Die Unterstützung ist unvollständig und somit
unbrauchbar.
In Chrome 20 kann allerdings experimentelle Unterstützung für Touchscreens auf der internen
Konfigurationsseite für experimentelle Funktionen 61 aktiviert werden. Wird diese Funktionalität aktiviert, unterstützt Chrome die W3C Touch Events Version 1. Dieser Umstand und die
Unterstützung für Touchevents in der mobilen Version des Browsers legen die Vermutung
nahe, dass Chrome in zukünftigen Versionen Touchevents standardmäßig unterstützen wird.
Auffällig ist, dass Chrome durch Aktivierung der Touch Unterstützung neben der Verfügbarkeit der Touchevents auch die Darstellung von Elementen der Benutzerschnittstelle von
Chrome verändert. So weisen beispielsweise Einträge in einer Dropdown-Box mehr als die
doppelte Höhe (~220%) bei aktiver Touch Unterstützung auf (siehe Abbildung 18). Es kann
davon ausgegangen werden, dass diese Maßnahme die Wahrscheinlichkeit einer irrtümlichen
Auswahl bei der Bedienung per Toucheingabe zu verringern versucht.
Abbildung 18: Dropdown-Stil bei aktiver (links) und inaktiver (rechts) Touchunterstützung in Google Chrome
20. (Suchformular: smashingmagazine.com)
Google Chrome besitzt eine der performantesten JavaScript-Engines und ist daher für MultiTouch-Applikationen mit nur geringer Latenz62 sehr geeignet. (Kinglsey-Hughes, 2012)
61
Verfügbar unter Aufruf der Seite chrome://flags/ in Chrome 20.
62
Als Latenz wird die Verzögerung zwischen dem Zeitpunkt bezeichnet, an dem eine Aktion durchgeführt
wird und dem Zeitpunkt, an dem die Aktion feststellbar ist. Latenz wird üblicherweise in Millisekunden
(ms) gemessen und sollte bei Multi-Touch-Anwendungen so gering wie möglich sein um eine ansprechende User Experience zu erreichen. (Saffer, 2009, S. 127)
49
3.3 Frameworks und Tools für die Entwicklung von
webbasierten Multi-Touch-Applikationen
Die zunehmende Verbreitung von Multi-Touch-fähigen Geräten sowie die unterschiedliche
Unterstützung in verschiedenen Browser und Plattformen resultieren in hohem Entwicklungsaufwand von Multi-Touch-Applikationen (Nebeling & Norrie, 2012). Um mehrere Zielplattformen zu unterstützen, müssen Entwickler/innen die Unterschiede zwischen den einzelnen
Implementierungen im Detail kennen. Sieht ein Interaktionskonzept neben der Möglichkeit
mehrere individuelle Berührungspunkte verarbeiten zu können auch Gesten als Form der Interaktion vor, so stehen Entwickler/innen vor der Herausforderung, Muster in der Bewegung
und Position mehrerer Berührungspunkte programmatisch zuverlässlich zu erkennen. Die
Erkennung von Gesten wie Rotate und Scale (siehe Kapitel 2.2) aufgrund mehrerer Punkte
basiert auf mathematischen Operationen, die vor allem bei der Verarbeitung von mehr als zwei
Punkten und in Hinblick auf die in Kapitel 2.2 beschriebenen Faktoren eine nicht zu vernachlässigende Komplexität aufweisen können 63.
In diesem Kapitel werden Anforderungen an ein webbasiertes Multi-Touch-Framework diskutiert und bereits existierende Lösungen mitsamt deren spezifischen Eigenschaften evaluiert.
Nicht behandelt werden Frameworks wie jQTouch 64 und Sencha Touch65, die für die Erstellung von Webinterfaces auf Multi-Touch-fähigen Geräten konzipiert sind, aber nur einen Berührungspunkt unterstützen und somit die vielfältigen Möglichkeiten von Multi-Touch
vernachlässigen.
3.3.1 Grundsätzliche Anforderungen an ein webbasiertes Multi-TouchFramework
Nebeling und Norrie (2012) sehen aufgrund der großen Vielfalt an Geräten drei bedeutende
technische und gestalterische Herausforderungen für Multi-Touch-Frameworks:
Technische Unterschiede zwischen Multi-Touch-fähigen Geräten. Diese Unterschiede inkludieren die Anzahl der gleichzeitig erkennbaren Berührungspunkte, die Geschwindigkeit der
Erkennung und die Unterstützung für weitere Sensorik wie Beschleunigungssensoren oder
physische Objekte.
Unterschiedliche Softwarearchitektur und Implementierungsmethoden. Um für die Vielfalt
an Smartphones, Tablet- und Tabletop-PCs zu entwickeln, benötigen Entwickler/innen Detailwissen über die Softwareentwicklung für unterschiedliche Plattformen. Derzeitige Frame-
63
Kammer et al. (2010) entwickelten aus diesem Grund ein semantisches Modell zur formalen Beschreibung
von Multi-Touch-Gesten. In diesem Modell wird die Erkennung von Gesten anhand textuell beschriebener
Gesten durchgeführt und von der eigentlichen Applikationslogik über eine Schnittstelle getrennt.
64
http://www.jqtouch.com/
65
http://www.sencha.com/products/touch/
50
works wie MT4j versuchen in Kombination mit Protokollen wie TUIO Plattformunabhängigkeit zu erreichen, benötigen aber eine zusätzliche Abstraktionsschicht sowie plattformspezifische Treiber für die Implementierung des Protokolls.
Limitierte Erweiterbarkeit. Viele der in Kapitel 2.5 behandelten Frameworks sind nur für eine
bestimmte Art von Applikationen konzipiert. Üblicherweise unterstützen diese Frameworks
nur ein definiertes, schwierig zu erweiterndes Set an Gesten.
Ein webbasiertes Framework für Multi-Touch-Applikationen sollte diese drei Herausforderungen adressieren. Unterschiedliche Implementierungen von Touchevents müssen vereinheitlicht
werden, um eine konsistente Verwendung von diesen Events in unterschiedlichen Browser zu
gewährleisten. Nichteinhaltung von definierten Standards oder Empfehlungen sowie Entwicklungen, wie die in Kapitel 3.2.4 behandelten Pointer von Microsoft, erschweren diese Aufgabe
beträchtlich.
Die Problematik der Plattformunabhängigkeit wird von einem webbasierten Framework für
Multi-Touch-Anwendungen schon allein aufgrund der Eigenschaften von Webapplikationen
gelöst. Teilweise werden Webapplikationen in unterschiedlichen Browser und deren Versionen
nicht identisch ausgeführt oder dargestellt, grundsätzlich sind Webdokumente aber auf jeder
Plattform in ähnlicher Form zu erreichen. Diese Abhängigkeit von Fähigkeiten des Browsers
stellt allerdings ein Problem dar, dessen Lösung von Entwickler/innen nicht direkt beeinflusst
werden kann.
Die Adressierung der von Nebeling und Norrie (2012) diskutierten Herausforderung der Erweiterbarkeit obligt den Entwickler/innen des Frameworks. Eine Implementierung, die großen
Wert auf Erweiterbarkeit und Flexibilität legt, ermöglicht es Entwickler/innen von MultiTouch-Applikationen ein Framework mit geringen Modifikationen oder Erweiterungen für
verschiedenste Projekte zu verwenden.
3.3.2 Hammer.js
Hammer.js 66 ist eine kürzlich veröffentliche Bibliothek zur Entwicklung von Applikationen mit
Multi-Touch- und Gestenunterstützung in JavaScript. Hammer.js wird von der niederländischen Kreativagentur Eight Media 67 entwickelt und wurde als open-source Software freigegeben.
Auf der offiziellen Website wird Hammer.js mit folgenden Eigenschaften beschrieben:
•
Einfache Implementierung von Touchevents
•
Kleine Dateigröße
•
Einfach zu erlernen
66
http://eightmedia.github.com/hammer.js/
67
http://www.eight.nl/
51
•
Fokussiert auf Multi-Touch-Gesten
•
Eigenständige Bibliothek, auch als Plug-in für jQuery verfügbar
Hammer.js unterstützt die folgenden Gesten:
•
Tap und Double Tap
•
Swipe
•
Hold
•
Transform
•
Drag
(Eight Media (Hg.), o. J.)
Eine Erweiterbarkeit dieser Gesten ist von Hammer.js nicht explizit vorgesehen. Aufgrund von
leicht verständlichem sowie gut dokumentiertem Quellcode der Bibliothek können aber mit
entsprechenden Programmier- und Mathematikkenntnissen zusätzliche Gesten hinzugefügt
werden.
Listing 9 zeigt ein Beispiel der Verwendung von Hammer.js als jQuery-Plug-in mit Methoden
für die Gesten Drag und Transform (Rotate und Scale) sowie einer Ausgabe aller Gesten in der
Konsole des Browsers.
$(".dragable")
.hammer( {
// Initialisieren und Optionen festlegen
prevent_default: true,
drag_min_distance: 5,
rotation_treshold: 1,
scale_treshold: 0.05 })
.bind("dragstart", function(ev) {
// Beginn einer Drag-Geste
})
.bind("drag", function(ev) {
// Während einer Drag-Geste
})
.bind("transform", function(ev) {
// Während einer Transform-Geste (Rotate/Scale)
})
.bind("doubletap", function(ev) {
// Double Tap
})
.bind("hold tap doubletap transformstart transform transformend
dragstart drag dragend release", function(ev) {
console.log("event type: " + ev.type); // Ausgabe über Konsole
});
Listing 9: Beispielcode bei Verwendung von Hammer.js
52
An diesem Beispiel wird deutlich, wie Hammer.js es ermöglicht, unterschiedliche Aktionen bei
Beginn, während der Durchführung und bei Beendigung einer Geste auszuführen (zB.
dragstart). Dies erlaubt es, flexibel bei der Umsetzung einer Applikation bei Verwendung
dieser Gesten zu sein, da in vielen Fällen nicht nur während der Durchführung einer Geste eine
visuelle Veränderung von statten gehen muss, sondern auch programmatische Aktionen zu
Beginn und Ende einer Geste durchgeführt werden müssen.
Hammer.js verwendet die vom W3C spezifizierten Touchevents. In Ermangelung eines Browsers, der diese Events unterstützt, konnte die Bibliothek vor der Veröffentlichung von Chrome
20 und dessen experimenteller Touch Unterstützung in Desktopumgebungen nicht verwendet
werden. Zu Testzwecken wurde im Rahmen dieser Diplomarbeit Hammer.js um die Mozilla
Touch Events erweitert und in Hummer.js umbenannt.
3.3.3 Hummer.js
Hummer.js 68 erweitert die Library Hammer.js um die Mozilla Touch Events. Dadurch ermöglicht Hummer.js die Entwicklung von gestenbasierenden Applikationen nicht nur für mobile
Browser, sondern auch für Mozilla Firefox (ab Version 3.6) in Desktopumgebungen.
Diese Erweiterung bedingte einige wesentliche Schritte. Um auf die Mozilla Events reagieren
zu können, wurden Listener für die Events MozTouchDown, MozTouchMove und MozTouchUp registriert. Da die Attribute dieser Events sich stark von den vom W3C spezifizierten
unterscheiden, wurden in den Eventlistener für die Mozilla Events die W3C-Events konstruiert
und gesendet. Dadurch wird eine Unabhängigkeit von der Weiterverarbeitung der Touchdaten zu einzelnen Gesten erreicht und bewahrt die Gestenimplementierungen vor vielen
eventspezifischen Verzweigungen.
Wie in Kapitel 3.2.3 erwähnt, sehen die Mozilla
Touch Events kein Event für das Verlassen eines aktiven Berührungspunktes einer durch ein DOMElement definierten Fläche vor. Ferner stellen die
Mozilla Events kein Attribut zur Verfügung, das alle
soeben veränderten Punkte repräsentiert. Dadurch
entstehen Probleme, wenn eine Geste auf einem Abbildung 19: Hummer.js Logo
Element beginnt, jedoch ein Berührungspunkt die
Fläche während der Durchführung verlässt, da es keine Möglichkeit gibt, die Beendigung dieser Berührung programmatisch zu erkennen. Diese Problematik kann teilweise durch Leeren
der internen Liste bei jedem ersten Berührungspunkt einer Geste umgangen werden. Bei bestimmten Mustern in der Gestendurchführung kann es aber zu Fehlverhalten kommen.
68
https://bitbucket.org/mgrubinger/hummer
53
Diese Unzulänglichkeiten in der Implementierung der Mozilla Touch Events sind aber durch
die Entscheidung von Mozilla, dieses proprietäre API nicht mehr weiterzuentwickeln, vernachlässigbar.
Neben der Unterstützung für Mozilla Touch Events wurde Hummer.js noch mit einer Möglichkeit ausgestattet, bei Transform-Events (Rotate oder Scale) den vorherigen Zustand über
die Attribute event.previousRotate und event.previousScale auszulesen. Diese
Werte vereinfachen das mehrmalige Transformieren eines Objekts, da die Attribute
event.rotate und event.scale nur die aktuellen Änderungen wiedergeben. Die gesamten
Transformationswerte können bei Verwendung von Hummer.js durch Addition der zu Beginn
der Geste bestehenden (previousRotation bzw. previousScale) und der aktuellen Werte
(rotate bzw. scale) errechnet werden.
3.3.4 jQMultiTouch
Ein weiteres Framework zur Entwicklung von Multi-Touch-Applikationen auf Basis von Webtechnologien ist jQMultiTouch 69. Das am Institute of Information Systems der ETH Zürich
von Michael Nebeling und seinem Team entwickelte Framework trägt den Untertitel „Lightweight Toolkit and Development Framework for Multi-touch/Multi-device Web Interfaces“ –
das Framework ist also per Definition für möglichst hohe Geräteunabhängigkeit konzipiert.
(Nebeling & Norrie, 2012)
Das Design von jQMultiTouch ist inspiriert von der einfachen Erfüllung von JavaScriptAufgaben, der Verarbeitung von Events mit Callbacks und der Abstraktion von tieferliegenden
Details einer Implementierung, die jQuery (siehe Kapitel 3.1.5) bereitstellt. Um die Vorteile
von jQuery zu nutzen, ist das Framework als Plug-in für jQuery entwickelt. Nebeling und Norrie (2012) beschreiben die drei wichtigsten technischen Beträge von jQMultiTouch wie folgt:
•
Eine Methodik zur geräteunabhängigen Verarbeitung von Multi-Touch-Events in
Web-Benutzerschnittstellen.
•
Ein neuartiges, vor allem bei komplexeren Multi-Touch- und Gesteninteraktionen hilfreiches Konzept einer Touch History für die zentrale Verarbeitung von Events.
•
Ein Toolkit und Multi-Touch-Framework, das ausschließlich auf nativen Webtechnologien basiert.
jQMultiTouch stellt eine Abstraktionsschicht für tieferliegende Multi-Touch-Events und deren
je nach Browser variierenden Details zur Verfügung (Nebeling & Norrie, 2012). In Anbetracht
der in Kapitel 3.2 beschriebenen Unterschiede, vor allem zwischen den Touchevents des W3C
und Mozilla, stellt diese Abstraktion eine wesentliche Erleichterung bei der Entwicklung von
Multi-Touch-Applikationen dar. Ferner unterstützt jQMultiTouch ein Set an Standardgesten
69
http://dev.globis.ethz.ch/jqmultitouch/
54
(Default Multi-Touch Event Handlers) sowie eine einfache Möglichkeit, eigene, komplexe Gesten zu definieren (Custom Gesture Handlers).
Die Syntax für das aktivieren des Plug-ins für bestimmte DOM-Elemente ist, wie bei jQuery
üblich, sehr kompakt. In Listing 10 werden alle Bilder einer Website mit jQMultiTouch über
Multi-Touch-Gesten dreh-, skalier- und verschiebbar.
$('img').touchable({draggable:true, scalable:true, rotatable:true});
Listing 10: Verwendung von jQMultiTouch um alle Bilder einer Website über Gesten dreh-, skalier- und verschiebbar zu machen.
Nach Anwendung des Befehls touchable wird den per jQuery selektierten Elementen (im
Beispiel in Listing 10 alle <img>-Elemente) die CSS-Klasse ui-state-touchable hinzugefügt. Dies erlaubt es Entwickler/innen, den per Multi-Touch-Gesten transformierbaren Elementen per CSS ein einheitliches Erscheinungsbild zu verleihen. (Nebeling & Norrie, 2012)
Abbildung 20: Architektur mit vier Schichten einer Webapplikation basierend auf jQMultiTouch (Nebeling &
Norrie, 2012)
Eine der zentralen Eigenschaften von jQMultiTouch ist die Touch History. Die Touch History
stellt einen zentralen Speicherort für Informationen zu allen aktuell auf der Oberfläche befindlichen Berührungspunkten sowie deren Vergangenheit bereit. Diese Informationen beinhalten
neben Koordinaten und der jeweiligen Identifikationsnummer des Punktes auch einen Zeitstempel. Über die Informationen in dieser zentralen Touch History können mittels Evaluationsmethoden eigene Gesten definiert werden. (Nebeling & Norrie, 2012)
55
Um beispielweise eine Swipe-Geste (schnelle Fingerbewegung in eine Richtung, siehe Kapitel
2.2) nach rechts zu registrieren, muss überprüft werden, ob ein Finger in den letzten x Millisekunden y Pixel in eine Richtung zurückgelegt hat. Die beiden Werte x und y haben wesentlichen Einfluss auf die Durchführbarkeit der Geste und der damit verbundenen User Experience
– sie sollten daher mit Bedacht gewählt werden. Als Beispielwerte werden in Listing 11 130
Millisekunden und 100 Pixel verwendet.
function gestureHandler(e, history) {
if(history.match({
finger: 0,
deltaX: '<100',
time: '1..130' })) {
// Swipe-right wurde ausgefuehrt
}
}
Listing 11: Beispielcode für einen Eventhandler für eine Swipe-Right-Geste mit jQMultiTouch
Wie Listing 11 zeigt, können Gesten innerhalb des Eventhandlers über die Methode match des
Touch History-Objekts mit einer Reihe von Parametern definiert werden. Diese Parameter
spezifizieren die Überprüfung beispielsweise anhand des verwendeten Fingers (finger), der
zurückgelegten Distanz (deltaX/Y) in einem Zeitraum (time) bzw. über den gesamten Verlauf der Interaktion (netX/Y) oder eines definierten Bereichs der Oberfläche (clientX/Y).
Im Detail stellt die match-Methode eine Kurzversion für die kombinierte Verwendung der
Methode filter (für die Filterung der Touch History etwa nach Finger-ID, Zeit, Typ und
auslösendes Element des Events) und match für die Detektion von Bewegungen (z.B. deltaX/Y, netX/Y, clientX/Y, angle). (Nebeling & Norrie, 2012)
Die Syntax für die Beschreibung von Wertebereichen für zeitliche oder räumliche Parameter
(z.B. 1..130 für 1 bis 130) ist an die Animationssyntax von jQuery angelehnt.
Ein weiteres Konzept von jQMultiTouch wird mit Attachable Behaviours (anfügbare Verhaltensweisen, siehe Abbildung 20) bezeichnet und bietet Möglichkeiten, die standardmäßig enthaltenen Gesten (Drag, Rotate, Scale) zu parametrisieren. Über diese Parameter können etwa
Minimal- und Maximalwerte für eine Vergrößerung/Verkleinerung eines Elements (min, max)
oder Schrittweiten bei der Rotation (step) angegeben werden. Zusätzlich kann über verschiedene Callback-Funktionen, die vor, während oder nach einer Geste ausgeführt werden, in die
Gestenfunktionalität eingegriffen oder die definierten Gesten komplett überschrieben werden.
(Nebeling & Norrie, 2012)
56
Zum Zeitpunkt der Erstellung dieser Arbeit liegt jQMultiTouch in Version 0.4 70 vor. Diese
Version beinhaltet noch Fehlverhalten bei Verwendung der Drag-Geste auf bereits transformierte Elemente. Dieses Fehlverhalten verursacht eine Neupositionierung des Elements mit
einem deutlichen Versatz zum vorherigen Zustand bei Beginn der Geste. Durch eine andere
Berechnung der Translation lässt sich dieses Problem allerdings beheben (siehe Kapitel 4.2).
3.3.5 Weitere Optionen für die Verwendung von Multi-Touch-Daten
im Browser
Die beiden in den vorangegangen Kapiteln diskutierten Frameworks Hammer.js/Hummer.js
und jQMultiTouch verwenden vom Betriebssystem bereitgestellte native Events (z.B.
WM_TOUCH unter Windows 7). Diese Vorgehensweise orientiert sich an Webstandards und
nutzt vorhandene Funktionalität des Browsers.
Während diese Konzepte die logische Konsequenz aus der rapiden Verbesserung von Unterstützung von Touchevents seitens der Browserhersteller darstellt, sind alternative Möglichkeiten des Zugriffs auf Touchdaten verfügbar und in manchen Szenarien sinnvoll. Die zugrunde
liegenden Ansätze zweier alternativer Möglichkeiten werden in diesem Kapitel behandelt.
npTuioClient
npTuioClient 71 ist ein Plug-in für Browser, das TUIO-Daten (siehe Kapitel 2.4.1) in JavaScript
zur Verfügung stellt. Das Plug-in ist für Firefox und Chrome auf den Plattformen Windows,
Mac OS X und Linux verfügbar. (Rusadi, o. J.)
Nach Installation des Plug-ins können die TUIO-Daten über die Funktion tuio_callback()
verwendet werden. Der Parameter type dieser Funktion beschreibt, welches TUIO-Event ausgelöst wurde und ermöglicht es, auf die unterschiedlichen Aktionen zu reagieren (siehe Listing
12).
function tuio_callback(type, sid, fid, x, y, a) {
// type == 0: TUIO Object Add
// type == 1: TUIO Object Update
// type == 2: TUIO Object Remove
// type == 3: TUIO Cursor Add
// type == 4: TUIO Cursor Update
// type == 5: TUIO Cursor Remove
}
Listing 12: Eventhandler bei der Verwendung des Plug-in npTuioClient.
70
jQMultiTouch wurde seitens der ETH Zürich noch mit keiner Lizenz versehen. Der Hauptentwickler Michael Nebeling gestattete dem Verfasser dieser Arbeit jedoch die Verwendung des Frameworks und stellte
eine Veröffentlichung unter einer open-source-Lizenz in absehbarer Zeit in Aussicht.
71
https://github.com/fajran/npTuioClient
57
Ein Nachteil dieses Konzepts ist die Notwendigkeit, ein Plug-in zu installieren. Darüber hinaus
beschreibt die Dokumentation des Projekts Probleme in der Implementierung, etwa bei der
Verwendung in Firefox auf Mac OS X.
Als deutlichen Vorteil kann die – durch die Verwendung von TUIO-Messages bedingte –
Möglichkeit, auch physische Objekte zu verwenden, gesehen werden.
Die von Boris Smus entwickelte Library MagicTouch.js 72 verwendet die von npTuioClient bereitgestellten Daten und wandelt sie in W3C-Touch Events um. Mit dieser Kombination kann
standardkonformer Code für Multi-Touch-Events mit TUIO-fähiger Hardware verwendet
werden. (Smus, 2011)
WebSockets
WebSockets sind eine in Arbeit befindliche Spezifikation, die persistente Datenverbindungen
zwischen dem Server und Clients erlaubt. Bisher wurde asynchroner Datenaustausch in Webapplikationen über AJAX 73 realisiert. Jede Anfrage eines Clients an den Server basiert bei AJAX
auf einem HTTP-Request, damit verbunden ist eine hohe Latenz. Benötigt eine Applikation
(annähernd) Echtzeitinformationen, so sind periodische Abrufaktionen notwendig, die den
Server zusätzlich belasten. (Hickson, 2012d; Ubl & Kitamura, 2012)
Mit WebSockets kann eine persistente Verbindung zwischen Client und Server hergestellt werden, über die beide Parteien zu jeder Zeit Daten senden können. Dadurch werden Echtzeitapplikationen mit mehreren Benutzern möglich, deren Daten über den Server per WebSockets
synchronisiert werden. (Ubl & Kitamura, 2012)
Eine Serverapplikation für WebSockets kann in einer Vielzahl von Programmiersprachen –
darunter serverseitiges JavaScript, Java, Ruby, Python und C++ – entwickelt werden. Ein WebSocket-Server kann auf TUIO-Daten zugreifen und diese an eine Client-Applikation im Browser senden. Auf diese Weise werden Plug-ins wie npTuioClient obsolet.
Im Mai 2012 wurde das Projekt TUIO.js 74 auf Github76 veröffentlicht. TUIO.js ist eine für die
JavaScript-Serverumgebung Node.js 75 implementierte Serverapplikation, der TUIO-Daten per
WebSockets bereitstellt. In der Clientapplikation können die TUIO-Events mittels Eventlistener verwendet werden. (Raab, o. J.)
72
https://github.com/borismus/MagicTouch
73
AJAX: Asynchronous JavaScript and XML
74
https://github.com/fe9lix/Tuio.js
75
http://nodejs.org/
58
3.3.6 Simulatoren für Multi-Touch-Eingabe
Unabhängig von der verwendeten Zielplattform und vom eingesetzten Framework stellt sich
bei der Entwicklung von Multi-Touch-Applikationen ein Problem beim Testen der Software.
Die Entwicklung direkt am Endgerät – etwa auf einem Tabletop-PC – ist sehr mühsam und
nicht empfehlenswert. Zudem hat nicht jeder/jede Entwickler/in ständig Zugang zur Zielplattform.
Aus diesen Umständen resultiert die Notwendigkeit, Simulatoren für Multi-TouchInteraktionen während der Entwicklung zu verwenden. Zwei dieser Simulatoren werden in
diesem Kapitel behandelt.
Multi-Touch Vista
Auf der Codeplex 76-Seite von Multi-Touch Vista 77 wird das Projekt wie folgt beschrieben:
„Multi-Touch Vista is a user input management layer that handles input from various devices
(touchlib, multiple mice, TUIO etc.) and normalises it against the scale and rotation of the target
window. Now with multitouch driver for Windows 7.“ (Danilin, 2011)
Wie in dieser Beschreibung angedeutet, inkludiert Multi-Touch Vista ein Service, das als Abstraktionsschicht für verschiedene Quellen von Multi-Touch-Daten fungiert. Dieses Service
konvertiert beispielsweise TUIO-Daten in native Windows 7 Touch Events (WM_TOUCH).
Alternativ zu TUIO können über eine Einstellung in einer einfachen Konfigurationsoberfläche
(siehe Abbildung 21) mehrere an den PC angeschlossene Mäuse verwendet werden. Jede Maus
wird dabei durch einen roten Punkt auf dem Bildschirm dargestellt. Die Betätigung der linken
Maustaste entsprichten einem aktiven Berührungspunkt.
Abbildung 21: Konfigurationsoberfläche von Multi-Touch Vista
76
Github und Codeplex sind Hosting-Plattformen für open-source Software.
77
http://multitouchvista.codeplex.com/
59
Die Verwendung dieses Simulators bringt auch Einschränkungen für den/die Entwickler/in
mit sich:
•
Multi-Touch Vista unterstützt nur einen Bildschirm. Vor dem Start des Services darf
nur der Hauptmonitor aktiv sein, da sonst die Abbildung der Mauskoordination auf
Touchkoordinaten fehlerhaft ist.
•
Um mehrere Mäuse zur Simulation der Touchdaten verwenden zu können, muss die in
der Konfigurationsoberfläche unter Configure device die Option Block native windows
mouse input ausgewählt werden. Dadurch wird die native Mausinteraktion deaktiviert
und in der Folge auch der Bildlauf mittels Scrollrad.
Microsoft Surface Input Simulator
Wie in Kapitel 2.5.2 erwähnt, stellt Microsoft mit dem Surface 2.0 SDK auch einen Simulator
zur Verfügung. Im Unterschied zu Multi-Touch Vista wird dieser Simulator mit einer Maus
bedient. Über eine grafische Oberfläche kann zwischen vier Eingabemodi gewechselt werden:
Finger, Blob, Tag oder Maus. In den ersten drei Modi kann mit klicken und ziehen der rechten
Maustaste ein Pointer dieser Kategorien simuliert werden. Wird während der Simulation eines
aktiven Inputs die linke Maustaste betätigt, so wird der Punkt fixiert. Auf diese Art können
mehrere Finger, Blobs und Tags platziert werden. Das Selection-Tool erlaubt die Auswahl dieser platzierten Pointer sowie die Änderung der Attribute wie Drehung, Position oder Größe
des ausgewählten Pointers. Werden mehrere Pointer ausgewählt, so können diese mit dem
Selection-Tool gleichzeitig rotiert, vergrößert oder verschoben werden (siehe Abbildung 23).
(Cabrera, 2011; Microsoft (Hg.), o. J.-f)
Abbildung 23: Vergrößerung/Verkleinerung der
Abstände zwischen fünf Finger-Objekten mit Surface Input Simulator
Abbildung 22: Microsoft Surface Simulator
60
Da Microsoft Surface auch Neigungen der Oberfläche erkennt, kann auch diese Funktion simuliert werden (Cabrera, 2011); siehe Abbildung 22).
Der Surface Input Simulator funktioniert wie Multi-Touch Vista nur auf dem Hauptmonitor.
Im Vergleich zu Multi-Touch Vista ist die Arbeit mit dem Surface Input Simulator etwas weniger effizient. Das Werkzeug bietet aber vor allem für Interaktionen mit mehr als zwei Berührungspunkten sehr zweckdienliche Möglichkeiten zu deren simultaner Manipulation.
3.3.7 Tools und Frameworks zur Erstellung von webbasierten Animationen
Animationen stellen einen zentralen Bestandteil vieler moderner Websites und Webapplikationen dar. Vor allem für Spiele und Applikationen, die Benutzer eine ansprechende Interaktion
mit einem System erlauben, sind Animationen essentiell.
Neue Webtechnologien wie Canvas und WebGL (siehe Kapitel 3.1.3) bieten Möglichkeiten für
die Erstellung von Animationen auf einer Art Zeichenfläche. Als Alternative dazu können auch
HTML-Elemente (etwa ein Image- oder ein Div-Element) mit CSS3 und JavaScript animiert
werden (siehe Kapitel 3.1.6). Diese Art der Animation ist die zu bevorzugende Variante, wenn
Elemente der Animation bereits in dem HTML-Dokument bestehen. Allerdings ergeben sich
dabei zwei Nachteile:
1. Die Möglichkeiten hinsichtlich erweiterten Parametern der Animation (etwa Easing oder
andere Effekte) sind mit diesen Mitteln eingeschränkt.
2. Die Erstellung von komplexeren Animationen mittels CSS3 und JavaScript ist zeitaufwendig
und umständlich, da keine einheitliche Struktur dafür vorhanden ist.
Um diesen beiden Problemen entgegenzuwirken, stehen Entwickler/innen einige Werkzeuge
zur Erstellung komplexer und interaktiver Animationen zur Verfügung. Die folgenden zwei
Werkzeuge, Adobe Edge und GreenSock GSAP, stellen eine Auswahl der verfügbaren Bibliotheken und Tools dar. Diese beiden Werkzeuge werden in dieser Arbeit behandelt, da für den
in Kapitel 4 beschriebenen Prototyp eine Animation mit beiden Lösungen entwickelt wurde.
Weitere Frameworks mit ähnlicher Zielsetzung sind Tween.js78 und JSTween 79.
78
http://www.createjs.com/#!/TweenJS
79
http://www.jstween.org/
61
Adobe Edge
Adobe Edge 80 ist ein Werkzeug zur Erstellung von Animationen und interaktiven Webapplikationen auf Basis der Technologien HTML5, CSS3 und JavaScript. Edge erlaubt es – ähnlich wie
Adobe Flash – Animationen von Elementen anhand von Schlüsselbildern in einer Zeitleiste zu
erstellen. Die einzelnen Elemente einer Animation sind jedoch als HTML-Elemente in die
Animation eingebettet und werden mit JavaScript animiert (Adobe Systems (Hg.), 2012).
Abbildung 24: Adobe Edge mit Eigenschaftenfenster (links), Bibliothek (rechts) und Zeitleiste (unten).
Adobe Edge verwendet intern die JavaScript-Bibliothek jQuery (siehe Kapitel 3.1.5) und ermöglicht es Entwickler/innen, JavaScript/jQuery-Code an Schlüsselbildern und Objekten hinzuzufügen. Auf diese Art können auch interaktive Animationen erstellt werden, indem auf
Aktionen von Benutzern reagiert wird (Adobe Systems (Hg.), 2012).
Beim Export der Animation erstellt Edge den Ordner publish im Projektverzeichnis. Dieser
Ordner beinhaltet folgende Dateien und Ordner:
80
http://labs.adobe.com/technologies/edge/
62
Datei- oder Ordnername
Anmerkung
edge_includes
Beinhaltet alle JavaScript-Bibliotheken, die zur Ausführung von Edge-Animationen notwendig sind.
edge.0.1.6.min.js
Edge-Bibliothek
jquery.easing.1.3.js
jQuery Plug-in für erweiterte Easing-Effekte
jquery.1.7.1.min.js
jQuery
json2_min.js
Bei Bedarf verwendetes Skript um JSON-Unterstützung in
Browser, die JSON nicht nativ unterstützen zu aktivieren
images
Beinhaltet alle verwendeten Grafiken der Animation.
[projektname].html
HTML-Dokument, das die Animation beinhaltet.
[projektname]_edge.js
Beinhaltet die Beschreibung aller im Projekt vorhandenen
Elemente und deren Animationen.
[projektname]_edgeActions.js
Beinhaltet alle JavaScript-Anweisungen, die bei der Ausführung der Animation durchgeführt werden.
[projektname]_edgePreload.js
Preloader-Skript
Tabelle 7: Die von Adobe Edge erstellte Ordner- und Dateistruktur für exportierte Projekte. Kursive Namen
stellen Dateien dar.
Adobe Edge befindet sich noch im Entwicklungsstadium und steht derzeit als Vorschauversion
6.1 zum Download auf der Webseite der Adobe Labs zur Verfügung.
GreenSock Animation Platform (GSAP) 12
Die von Jack Doyle entwickelte GreenSock Tweening Platform 81 ist eine umfangreiche und
häufig verwendete Bibliothek zur programmatischen Erstellung von Animationen in ActionScript. Ab Version 12 wurde die Bibliothek in GreenSock Animation Platform (GSAP) umbenannt. GSAP unterstützt erstmals auch die Programmierung von Animationen in JavaScript
mit gleicher Syntax wie in ActionScript. Dieser Umstand erleichtert Entwickler/innen mit Erfahrung in ActionScript die Programmierung von JavaScript-Animationen deutlich (Doyle,
2012a).
Mit GSAP können sowohl einzelne Animationen als auch komplexe Sequenzen mit umfangreichen Timing-Möglichkeiten programmiert werden. Diese Funktionalität ist in zwei Module
mit jeweils zwei Varianten aufgeteilt:
81
http://www.greensock.com/v12/
63
TweenLite und TweenMax: Diese beiden Werkzeuge stellen die Basis der GSAP dar und ermöglichen die Programmierung von einzelnen Animationen. TweenMax erweitert dabei
TweenLite um einige Funktionen für die Programmierung fortgeschrittener Animationen
(Doyle, 2012b).
TimelineLite und TimelineMax: Über Timelines können Sequenzen aus mehreren Tweens und
Timelines erstellt und gesteuert werden. TimelineMax erweitert TimelineLite um Funktionen
zur detaillierteren Steuerung von Timelines (Doyle, 2012b).
GSAP erlaubt die Animation von allen numerischen Werten eines Elements sowie CSSWerten, sofern das Plug-in CSSPlugin verwendet wird. In Listing 13 ersichtlich ist eine Animation (ein Tween) der Höhe eines im HTML-Dokument vorhandenen Bildes (photo).
var photo = $("#photo");
TweenLite.to(photo, 1.5, {height: 200, ease: Elastic.easeOut});
Listing 13: Animation eines HTML-Elements mit der GreenSock Animation Platform in JavaScript. Das zu
animierende Element mit der ID "photo" wird per jQuery ausgewählt und die Höhe auf 200px animiert. Die
Animation dauert 1,5 Sekunden und verwendet die Easingfunktion Elastic.easeOut.
64
4
Umsetzung eines Prototyps
Im vierten Kapitel werden die in den vorangegangenen Kapiteln theoretisch behandelten Möglichkeiten zur Programmierung von Multi-Touch-Anwendungen für den Browser in einem
praktischen Beispiel angewendet. Ausgehend von einer an der Fachhochschule St. Pölten umgesetzten Flash-Applikation, wird ein Teil ebendieser unter Verwendung der in Kapitel 3 beschriebenen Technologien für Webtechnologien adaptiert. Der Prototyp stellt ein einfaches
Puzzlespiel dar, das von bis zu vier Personen gleichzeitig mit Multi-Touch-Gesten bedient
werden kann. Ist das Puzzle gelöst, wird eine kurze Animation dargestellt, um die Spieler/innen
über das erreichte Spielende zu informieren.
In Kapitel 4.1 wird die bereits entwickelte Flash-Applikation mit ihren Modulen und der verwendeten Hardware dargestellt. In den darauf folgenden Kapiteln 4.2 und 0 wird das umzusetzende Puzzlespiel sowie die Vorgehensweise bei der Umsetzung auf Basis von
Webtechnologien beschrieben. In Kapitel 4.4 wird erläutert, wie die Webtechnologien HTML,
CSS, JavaScript und Animationswerkzeuge eingesetzt wurden, um dieses Spiel für die Ausführung im Browser zu entwickeln.
Die Entwicklung dieses Prototyps unterstützt die Beantwortung der Forschungsfrage, ob der
Browser für die Ausführung von Multi-Touch-Applikationen geeignet ist, anhand der folgenden, eingangs bereits erwähnten Kriterien:
•
die Fähigkeiten aktueller Browserversionen, Touchevents zu verarbeiten
•
die Verfügbarkeit von Frameworks für Multi-Touch-Gestensteuerungen
•
Performance aktueller Browser bei Multi-Touch- und Gesteninteraktionen
•
die Verfügbarkeit von Werkzeugen zur Erstellung von webbasierten Animationen
•
die Verfügbarkeit von unterstützenden Werkzeugen
Zur Evaluierung der Verwendbarkeit des Prototyps trägt zudem ein Test der Applikation mit
vier Teilnehmer/innen bei. Im letzten Teil dieses Kapitels werden das Setup und der Ablauf
dieses Tests beschrieben. Anhand der Ergebnisse des Tests werden folgende Fragen untersucht:
•
Wie verhält sich die Webapplikation bei der Bedienung von nur einer Person (Single
User) im Vergleich mit der Flash-Applikation?
•
Wie verhält sich die Webapplikation bei der gleichzeitigen Bedienung von vier Personen (Multi User) im Vergleich mit der Flash-Applikation?
•
Ab welcher Belastung sind Performanceprobleme deutlich erkennbar?
•
Tritt Fehlverhalten bei der Verwendung von Gesten auf?
•
Wie ist der subjektive Eindruck hinsichtlich der Qualität der Interaktion und der visuellen Darstellung des Spiels?
Die Ergebnisse der Kriterien und die Antworten auf diese Fragen werden in Kapitel 5 dargestellt.
65
4.1 Ausgangssituation
Um ein besseres Verständnis für den Kontext des entwickelten Prototyps zu schaffen, werden
in der Folge der Hintergrund der bereits erstellten Applikation sowie deren technische Umsetzung näher beschrieben.
4.1.1 Valcamonica
In einem Tal in den Lombardischen Alpen im Norden Italiens lebte in der Eisenzeit ein Volk,
das heute den Namen Camuni trägt. Dieses Tal, das nach seinen antiken Bewohner/innen benannte Valcamonica, beherbergt eine der umfangreichsten Sammlungen von Felsbildkunst in
Europa. Auf beiden Seiten dieses Tals finden sich auf etwa 2400 Felsen eine Vielzahl an in den
Fels gemeißelte Bilder (Petroglyphen). Schätzungen gehen von circa 140.000 derartiger Bilder
aus, die in den letzten 8000 Jahren, vorwiegend aber ab etwa 3000 v. Chr., mit primitiven
Werkzeugen in die Felsen des Tals Valcamonica gemeißelt wurden. Viele Felsen lagen unter
einer über die Jahrtausende gewachsene Erdschicht und wurden von Wissenschaftlern sorgfältig freigelegt, eine unbekannte Zahl ist aber immer noch unentdeckt. Die Felsbildkunst von
Valcamonica trägt seit 1979 den Status des UNESCO Weltkulturerbe. (Nash & Chippindale,
2002; „Rock Drawings in Valcamonica - UNESCO World Heritage Centre“, o. J.)
Die Beschaffenheit des Sandsteins, der von den Gletscherbewegungen glattgeschliffen wurde,
eignet sich hervorragend als „Zeichenfläche“ und kann mit einfachen Mitteln bearbeitet werden. Die Petroglyphen umfassen eine Vielzahl an Darstellungen von Menschen, Landwirtschaft, Krieg, Magie, Werkzeuge, Tiere, geometrische Formen und Symbole. Eine Vielzahl an
Darstellungen von Menschen, sogenannte Pitotis 82, sowie Gruppen von Figuren, die miteinander in Interaktion stehen, sind in die Felsen eingraviert.
Diese Zeichnungen sind eine einzigartige Dokumentation des Lebens eines prähistorischen
Volkes in dieser Region. Die systematische Erforschung der Felsbildkunst in Valcamonica hat
einen erheblichen Beitrag zum wissenschaftlichen Diskurs der Themen prähistorische Archäologie, Soziologie und Ethnologie geleistet. („Rock Drawings in Valcamonica - UNESCO World
Heritage Centre“, o. J.)
82
Pitoti ist ein lokales Dialekt-Wort und bedeutet Püppchen. (Nash & Chippindale, 2002)
66
Abbildung 25: Detailaufnahme einer Pitoti-Figur
Abbildung 26: Detailaufnahme einer Rosa Camuna, eines der am häufigsten verwendeten Symbole.
4.1.2 Playing Valcamonica
In Zusammenarbeit mit Dr. Frederik Baker (Fachhochschule St. Pölten und Universität Cambridge) und Dr. Christopher Chippindale (Universität Cambridge) wurde ein Spielkonzept für
einen Multi-Touch-Tabletop-PC entwickelt und umgesetzt. Diese Installation ist Teil einer
Museumsausstellung zum Thema Felsbildkunst in Valcamonica und trägt den Namen Playing
Valcamonica.
Das Ziel dieses Projekts ist es, ein kollaboratives Lernspiel für Kinder und Erwachsene im Museumskontext zu entwickeln. Drei Faktoren sind für die Entwicklung dieses Spiel wichtig:
•
Es ermöglicht, die Felsbildkunst dem interessierten Publikum zugänglich zu machen,
obwohl die Felsen selbst nicht transportiert werden können.
•
Es ermöglicht eine Interaktion zwischen Besucher/innen und den Figuren. Die Figuren
sind nicht immer zugänglich und befinden sich teilweise auf steilen Hängen, die aus
Gründen der Erhaltung und des Schutzes nicht betreten werden dürfen.
•
Das Spiel erlaubt es Besucher/innen, durch Spielen mehrerer Spiele die Interaktion
zwischen den Figuren zu entdecken.
(Seidl u. a., 2011)
Ausgangspunkt von Playing Valcamonica ist ein hochauflösendes Gesamtbild eines etwa 12x15
Meter großen Felsen, der mit einer Neigung von bis zu 45° in unwegsamen Gelände liegt83. Um
dieses Bild zu erstellen, wurde der Felsen mit 214 Einzelfotos aus gleichbleibender Distanz abfotografiert und im Anschluss zu einem einzelnen Abbild des Felsens zusammengefügt. Das
Gesamtbild hat eine Auflösung von etwa 3,5 Gigapixel (3,5 Milliarden Pixel) und kann in Play-
83
Die Bezeichnung dieses Felsens, der sich in der Nähe des Ortes Capo di Ponte befindet, lautet Seradina 12.
67
ing Valcamonica von Besucher/innen über die Gesten Scale und Drag erforscht werden. Dadurch wird einerseits eine Ansicht des gesamten Felsens aus der Vogelperspektive (siehe
bildung 27) sowie ein detailreiches Erkunden dieses Felsens und der Figuren beinahe in
Originalgröße ermöglicht. Beide Ansichten sind auch vor Ort – aufgrund der Unwegsamkeit
des Geländes und der erwähnten Schutzmaßnahmen – so nicht möglich.
Abbildung 27: Gesamter Felsen (Seradina 12) mit Interfaceelementen: Spielstationen (weiße Rosa Camuna auf
Felsen), Navigator und Maßstab (links oben bzw. rechts unten), Hilfe-Button und Hintergrundinfo-Button
(rechts oben bzw. links unten).
Auf diesem Abbild des Felsens sind auf einer
eigenen, skalierungsunabhänigen Ebene stilisierte Rosa Camuna-Symbole (siehe Abbildung 28) platziert, über die eines von fünf
Minispielen gestartet werden kann. Diese
Spielstationen befinden sich jeweils in der
Nähe einer Figurengruppe, die im Spiel behandelt wird und sind über unterschiedliche
Anzahl der Punkte des Symbols subtil nummeriert.
Abbildung 28: Rosa Camuna-Symbole dienen
als Einstiegspunkt für die Minispiele.
68
Für eine Installation im öffentlichen Raum ist es entscheidend, dass Spieler/innen ohne Vorerfahrung schnell und möglichst ohne Hilfestellung die Funktionsweise begreifen. Um die Eintrittsschwelle für Besucher/innen des Museums so niedrig wie möglich zu halten, wird nur ein
kleines Set an einfachen Gesten wie Tap, Drag, Rotate und Scale verwendet (siehe Kapitel 2.2).
Die Minispiele sind für eine Bedienung von allen vier Seiten des Tisches und für ein bis vier
Spieler konzipiert, daher sind Interfaceelemente an beiden Längsseiten der Oberfläche platziert
(siehe Abbildung 27). Die Spielkonzepte besitzen einen Aufforderungscharakter und sollen
zusehende Personen einladen, jederzeit bei der Lösung eines Spiels aktiv mitzuhelfen. So wird
die Auseinandersetzung mit den Inhalten der Ausstellung zu einem kooperativen Erlebnis.
(Cao, Massimi, & Balakrishnan, 2008; Seidl u. a., 2011)
4.1.3 Module
Folgende Minispiele wurden in Playing Valcamonica als Module implementiert:
Puzzle Hunter, Deer und Warrier
Diese drei Spiele sind als Puzzlespiele zu begreifen, in denen Teile von Figuren wieder zusammengesetzt werden müssen. Die drei verwendeten Figuren sind ein Jäger mit Speer (Hunter),
ein Reh (Deer) und ein Krieger (Warrier).
Die Spieler müssen die zufällig platzierten, halbtransparent mit Weiß eingefärbten Teile an die
richtige Position bewegen sowie in die richtige Drehung und Größe bringen. Sind diese Attribute (Position, Drehung, Größe) nahe genug an den richtigen Werten, so rastet das Puzzleteil
ein und bekommt wieder die Originalfarbe des Steins.
Catch the oxes
Die vier Ochsen zweier Bauern sind entlaufen und müssen von den Spielern in ein durch weiße
Kreise markiertes Zielgebiet (zu den Bauern) gebracht werden. Mit der Hilfe von vier Hunden,
können die Ochsen in Richtung Zielgebiet gedrängt werden. Um die Hunde zu steuern, können die Spieler einen Pfad für jeden Hund zeichnen, dem dieser Hund folgt.
Hunting
Durch Schießen mit vier Jagdbögen müssen die Spieler gemeinsam versuchen, die auf verschiedenen Pfaden durch das Spielfeld laufende Rehe zu erlegen. Um gemeinsames Spielen zu
fördern, werden nicht die Treffer eines einzelnen Spielers sondern aller Spieler zusammen gezählt.
Da die Hauptzielgruppe von Playing Valcamonica Kinder sind, ist der visuelle Effekt bei einem
Treffer kindergerecht gestaltet: Das getroffene Reh stoppt und dreht sich um 180 Grad auf den
Rücken.
69
4.1.4 Technische Umsetzung und Zielplattform
Playing Valcamonica wurde in ActionScript 3 für die Adobe Flash/AIR-Runtime entwickelt.
Als Entwicklungswerkzeug kamen einerseits die Adobe Flash IDE 84 zur Erstellung von Animationen und die quelloffene IDE FlashDevelop 85 zum Einsatz. Die Applikation baut auf dem
OpenExhibit SDK (siehe Kapitel 2.5.3) als Basis-Framework für die Abstraktion von TouchDaten und Multi-Touch-Gesten auf.
Der zentrale Bestandteil von Playing Valcamonica, das hochauflösende Bild eines Felsens,
wurde mit OpenZoom 86 realisiert. OpenZoom ist ein Framework zur Darstellung von und Interaktion mit hochauflösenden Bildern und liegt auch als Modul für OpenExhibts vor. Für die
Programmierung von Animationen wurde die Animationsbibliothek TweenMax von GreenSock 87 verwendet (siehe Kapitel 3.3.7).
Um eine einfache und umkomplizierte Anpassung von Einstellungen, die die Schwierigkeit der
Spiele regeln sowie Änderungen der multilingualen Textinhalte zu gewährleisten, greift Playing
Valcamonica auf eine mySQL-Datenbank zu. Zusätzlich werden Fehlerberichte und – sofern
aktiviert – Messdaten für User Experience Tests in dieser Datenbank gespeichert 88.
Die Hardware besteht aus einem von der Wiener Firma cyWorx Interactive Systems 89 konstruiertem Tisch mit einem 46 Zoll Full-HD LCD-Monitor von Samsung sowie einem MultiTouch-Overlay G3 von PQLabs (siehe 2.3.2). Ausgeführt wird die Software in Flash Player
11.01 unter Windows 7 Enterprise. Der in den Tisch integrierte PC hat folgende Merkmale:
Intel i5-Prozessor mit 3.3 GHz, 8 GB Hauptspeicher und einer ATI Radeon HD6570 Grafikkarte sowie einer Solid-State-Drive (SSD).
4.2 Spielbeschreibung
Im Zuge dieser Diplomarbeit wurde eines der in Kapitel 4.1.3 beschriebenen Minispiele von
Playing Valcamonica, das Puzzle Warrier, auf Basis von Webtechnologien umgesetzt. Das Spiel
Puzzle Warrier ist für eine versuchsweise Umsetzung geeignet, da die Multi-Touch-Gesten
Drag, Rotate und Scale zur Interaktion der Benutzer mit den Puzzleteilen verwendet werden.
Zudem wird bei Spielende eine kurze Animation der Figur angezeigt, welche ebenfalls mit
Webtechnologien umgesetzt wurde. In der weiteren Folge wird das Spiel mit Puzzle bezeichnet.
84
IDE: Integrated Development Environment (Integrierte Entwicklungsumgebung)
85
http://flashdevelop.org/
86
http://www.openzoom.org/
87
http://www.greensock.com/tweenmax/
88
Details zu gemessenen UX-Daten werden von (Seidl u. a., 2011)) beschrieben.
89
http://www.cyworx.at/
70
Der Ablauf und die Spielmechanik des Spiels Puzzle kann so beschrieben werden:
•
Im Hintergrund befindet sich eine Fotografie, die den zusammenzusetzenden Pitoto
darstellt. Die Figur ist schwarz eingefärbt.
•
Auf beiden Seiten neben der Figur werden die zehn Puzzleteile mit zufälliger Position,
Größe und Drehung platziert. Diese Zufallswerte liegen innerhalb definierter Wertebereiche. Die Puzzleteile sind mit Weiß überlagert, um eine Differenzierung zu bereits
richtig platzierten Teilen zu gewährleisten.
•
Spieler können die Puzzleteile mit einem Finger (Geste: Drag) verschieben und mit
zwei Finger drehen und in der Größe verändern (Gesten: Rotate und Scale).
•
Wird ein Puzzleteil an der richtigen Position und in richtiger Größe und Drehung über
der Figur platziert (innerhalb eines definierten Bereichs), so verschwindet die in beschriebene weiße Farbüberlagerung und das Element bewegt sich exakt an die richtige
Position.
•
Sind alle zehn Puzzleteile an der richtigen Position, ist das Ende des Spiels erreicht. Eine kurze Animation, in der die Figur die Arme auf und ab bewegt, vermittelt den BenutzerInnen, dass das Spielende erreicht wurde.
Abbildung 29: Startansicht des Puzzle Warrier
71
4.3 Vorgehensweise
Die Vorgehensweise bei der Umsetzung dieses Spiels mit Webtechnologien erfolgte in sechs
aufeinander folgenden Schritten:
1. Vorbereitende Versuche
Erste Tests der Verfügbarkeit von Multi-Touch-Daten wurden in Mozilla Firefox durchgeführt, da Google Chrome diese Funktionalität zu diesem Zeitpunkt noch nicht bereitstellte.
Eine einfache Applikation zeichnete die Positionen einzelner Finger bei Berührung als Kreis
auf einem Canvas-Element eines HTML-Dokuments.
Aus diesem Test ging die Applikation Kunstenaar 90 hervor, die im Rahmen einer Jubiläumsfeier der Fachhochschule St. Pölten als digitales Gästebuch verwendet wurde. Besucher/innen
konnten gemeinsam auf einem Tabletop-PC per Berührung ihre Grüße in zeichnerischer Form
hinterlassen. Die neuesten dieser Nachrichten wurden in der Folge auf einer Projektionsfläche
dargestellt.
Abbildung 30: Multi-Touch Webapplikation Kunstenaar mit einer von Besucher/innen hinterlassenen Nachricht.
Bei der Entwicklung dieser Applikation konnten bereits die Möglichkeiten im Hinblick auf die
Verwendbarkeit der Mozilla Touch Events (siehe Kapitel 3.2.3) getestet werden. Jedoch verwendet diese Applikation keine Multi-Touch-Gesten. Zudem mussten aber bereits auch die
Einschränkungen, die mit der Verwendung dieser Events einhergehen und in Kapitel 3.2.3
behandelt wurden, festgestellt werden.
90
http://mgrubinger.at/projects/kunstenaar
72
2. Beginn der Entwicklung eines Multi-Touch-Frameworks
Zu diesem Zeitpunkt war noch kein Framework zur Erstellung von Gesten-basierenden MultiTouch-Applikationen verfügbar. Aus diesem Grund wurde seitens des Verfassers dieser Arbeit
mit der Entwicklung eines Frameworks zur Erkennung von einfachen Multi-Touch-Gesten
begonnen. Bereits in einem sehr frühen Stadium wurde jedoch die Bibliothek Hammer.js (siehe
Kapitel 3.3.2) veröffentlicht. Hammer.js realisiert die Ziele des zu entwickelnden Frameworks
weitgehend, daher wurde die Entwicklung eines weiteren Frameworks als obsolet betrachtet.
3. Erster Prototyp mit Hammer.js und Weiterentwicklung zu Hummer.js
Zu Evaluierungszwecken wurde ein Prototyp einer Applikation, die mit den Gesten Drag, Rotate und Scale bedient mit der Bibliothek Hammer.js umgesetzt. Da Hammer.js die Mozilla
Touch Events nicht unterstützt und damit die Verwendung in einer Tabletop-Umgebung nicht
möglich ist, musste Hammer.js um die Mozilla Touch Events sowie weiterer, in Kapitel 3.3.3
beschriebenen Änderungen erweitert werden. Im Zuge dieser Erweiterung wurde Hammer.js
in Hummer.js umbenannt.
Aufgrund der ebenfalls in Kapitel 3.3.3 beschriebenen Probleme konnten mit Hummer.js noch
keine befriedigenden Ergebnisse erzielt werden.
4. Prototyp mit jQMultiTouch sowie Erweiterung dessen
Kurz nach der Entwicklung des Prototyps mit Hummer.js wurde die Bibliothek jQMultiTouch
(siehe Kapitel 3.3.4) veröffentlicht. jQMultiTouch adressiert einige bei der Verwendung von
Hammer.js bzw. Hummer.js aufgetretenen Probleme mit Mozilla Touch Events gezielt. Um
diese Bibliothek zu testen, wurde ebenfalls ein Prototyp des beschriebenen Puzzlespiels entwickelt. Dabei aufgetretene Fehler oder Unzulänglichkeiten von jQMultiTouch wurden im Zuge
dessen behoben (siehe Kapitel 4.4.3).
5. Angeleiteter Test des Prototyps
Um die Funktionalität des Prototyps in einem möglichst realistischen Szenario zu evaluieren,
wurde ein Test mit vier Testpersonen durchgeführt, die das Spiel gemeinsam spielen. Die Teilnehmer/innen des Tests konnten zuerst die Flash-Applikation spielen. Danach wurde die
Webapplikation in zwei verschiedenen Browsern getestet. Eine detaillierte Beschreibung des
Testsetups und die Ergebnisse werden in Kapitel 4.5 dargestellt.
6. Erstellung der Endanimation mit Adobe Edge und Einbindung in das Spiel
In diesem Schritt wurde die Endanimation des Spiels mit dem in Kapitel 3.3.7 beschriebenen
Werkzeug Adobe Edge erstellt. Edge stellte sich trotz seines Vorschaustatus als komfortabel
und einfach zu bedienendes Programm heraus. Innerhalb kurzer Zeit konnte eine Animation
erstellt werden, die der in Flash erstellten bereits sehr ähnlich war.
73
Aus den in Kapitel 5.1.4 dargestellten Gründen wurde die Animation aus dem Spiel entfernt
und durch eine mit der GreenSock Animation Platform programmierte Animation ersetzt.
7. Erstellung der Animation mit GSAP und Einbindung in das Spiel
Die Verwendung der in Kapitel 3.3.7 beschriebenen GreenSock Animation Platform hat für
diesen Anwendungsfall einige Vorteile. Die bereits im HTML-Dokument vorhandenen Puzzleteile können für die Animation verwendet werden, ohne dass weitere Bilder geladen werden
müssen. Mit GSAP hat der/die Entwickler/in umfangreiche Möglichkeiten, in die Ausführung
der Animation einzugreifen und ist vor allem beim Timing der Animation sehr flexibel. Als
Nachteil ist zu erwähnen, dass die Erstellung von Animationen mit GSAP im Vergleich mit
Adobe Edge mehr Zeit in Anspruch nimmt.
4.4 Umsetzung mit jQMultiTouch
Als webbasiertes Multi-Touch-Framework wurde für die Umsetzung dieses Prototyps das in
Kapitel 3.3.4 beschriebene jQMultiTouch verwendet, da es – im Vergleich mit Hammer.js bzw.
Hummer.js – umfangreichere Funktionalität hinsichtlich Multi-Touch-Gesten und bessere
Unterstützung für Mozilla Touch Events bietet (siehe Kapitel 3.3.3 und 3.3.4).
Im Folgenden werden die vier Hauptkomponenten der technischen Umsetzung des Spiels –
die Struktur/der Inhalt, das visuelle Erscheinungsbild, die Funktionalität und die Animation –
unter Verwendung der Webtechnologien HTML, CSS und JavaScript erläutert.
4.4.1 Struktur und Inhalt mit HTML5
Wie in Kapitel 3.1.1 beschrieben, bildet HTML die Struktur und den Inhalt einer Website oder
Webapplikation. Die HTML-Datei von Puzzle orientiert sich an HTML5 Boilerplate. Es wurden allerdings die Funktionen für Unterstützung älterer Browser – vor allem Internet Explorer
– entfernt, da diese Browser ohnedies keine Touchevents unterstützen.
Der Kopfbereich der HTML-Datei index.html verweist auf folgende Dateien:
•
Stylesheet puzzle.css
•
jQuery Version 1.7.1 (komprimiert)
•
jQMultiTouch
•
JavaScript-Dateien für die GreenSock-Animationsbibliothek GSAP
•
JavaScript-Datei mit Applikationslogik: application.js
Im Body der HTML-Datei werden alle Puzzleteile als Figure-Tags (<figure>) definiert. Figure ist ein mit HTML5 eingeführter semantischer Tag, der als Container für eine Grafik mitsamt
zusätzlichen, mit der Grafik in Verbindung stehenden Elementen verwendet werden kann
(Hickson, 2012b) .
74
Innerhalb der Figure-Elemente befindet sich jeweils ein Image-Element (<img>). Diese Kombination zweier Elemente wurde gewählt, da sowohl ein Originalbild als auch ein weiß überlagertes benötigt werden. Das Figure-Element zeigt im Hintergrund (CSS) das Originalbild. Das
Image-Element stellt das weiß überlagerte Bild genau über dem Originalbild (des FigureElements) dar. Auf diese Art muss nur das äußere Element (Figure) bewegt, rotiert und skaliert
werden um auch das innere (Image) zu verändern. Ein weiterer Vorteil entsteht bei Erreichen
der richtigen Position. Um das Originalbild darzustellen, muss nur das darüber befindliche
Image-Element ausgeblendet werden.
Die Figure-Elemente erfüllen in dieser Applikation einen weiteren Zweck. Über Data-Attribute
werden den Elementen die Werte der finalen Position, Rotation und Größe angefügt. DataAttribute sind eine weitere Neuerung in HTML5 und erlauben es, Daten einem HTMLElement zuzuweisen. Data-Attribute müssen mit data- beginnen und können beliebige Werte
beinhalten. Diese Werte können per JavaScript für die weitere Verwendung gelesen und verändert werden. Listing 14 zeigt das HTML-Markup eines Puzzleteils mitsamt Data-Attributen für
die Werte finalX, finalY, finalRotation und finalScale.
<figure class="helm" data-finalX="803" data-finalY="115" datafinalRotation="0" data-finalScale="1">
<img src="img/helm_weiss.png">
</figure>
Listing 14: HTML-Markup für ein Puzzleteil mit Data-Attributen.
Abbildung 31: Puzzleteil "Helm" in den zwei Varianten Weiß und Original (verwendet in den Elementen
<img> und <figure> in Listing 14).
Die Bilder der Puzzleteile wurden in doppelter Größe eingebettet, um visuelle Artefakte bei
Skalierung der Bilder bis Faktor 2 zu vermeiden. Daraus resultiert eine wesentlich (um Faktor
4) größere Dateigröße der Bilder.
Zusätzlich beinhaltet die HTML-Datei ein Div-Element (<div>), das als Teil der Animation
bei Beendigung des Spiels im Hintergrund angezeigt wird. Die Implementierung der Animation wird in 4.4.3 beschrieben.
75
4.4.2 Visuelle Erscheinung mit CSS
Folgende Aspekte von Puzzle wurden mit CSS umgesetzt:
•
Darstellung des Hintergrunds91
•
Darstellung und Positionierung der Puzzleteile 91
•
Erscheinungsbild des Dialogs bei erfolgreichem Beenden des Spiels91
•
Größe und Drehung der Puzzleteile
•
Übergänge (Transition) bei Einrasten eines Puzzleteils
Veränderungen der Größe und Drehung der einzelnen Puzzleteile werden über die in Kapitel
3.1.6 beschriebene CSS Eigenschaft transform mit den Werten scale und rotate realisiert. Bei
Initialisierung der Applikation wird diese CSS-Eigenschaft per JavaScript mit zufälligen Werten gesetzt. Bei Interaktion eines Benutzers mit einem Puzzleteil werden sowohl diese CSSWerte als auch die Positionierung vom jQuery Plug-in jQMultiTouch verändert (siehe Kapitel
4.4.3).
Befindet sich ein Puzzleteil nahe genug an den korrekten Werten der finalen Position, Drehung
und Größe, so wird dem Figure-Element per JavaScript die Klasse final hinzugefügt. Die in
Listing 15 dargestellten CSS-Regeln bewirken durch die Verwendung der Eigenschaft transition 92, dass das Image-Element über eine Dauer von 750 Millisekunden ausgeblendet wird,
sobald einem übergeordneten Figure-Element die CSS-Klasse final zugeordnet wird.
Eine weitere in Listing 15 ersichtliche CSS-Eigenschaft ist background-color mit dem Wert
transparent. Dies stellt einen Lösungsansatz für einen Bug in der aktuellen Implementierung von CSS-Transitions in Firefox dar. Ohne diese Eigenschaft weist das Element während
des Übergangs einen deutlichen Versatz in der Positionierung auf. 93
91
Diese Aspekte stellen relativ simple CSS-Aufgaben dar und werden daher nicht im Detail behandelt. Für
Informationen zu diesen Punkten kann der Quelltext der auf CD beigefügten Datei puzzle.css untersucht
werden.
92
Die CSS-Eigenschaft transition ist wie in Kapitel 3.1.6 dargestellt derzeit noch mit Browser-Präfixe
(-moz, -webkit, -o, -ms) zu versehen. Aus Gründen der Übersichtlichkeit wurde an dieser Stelle darauf verzichtet.
93
Dieses Problem wird unter anderem in einem Forum der Webseite Graphicriver diskutiert:
http://graphicriver.net/forums/thread/latest-firefox-bug-with-css-scale-transform-opacity-transition/61070
76
figure.final img {
opacity: 0;
}
figure img {
position: relative;
width: 100%;
height: 100%;
transition: opacity 750ms;
background-color: transparent; /* fix img jump bug */
}
Listing 15: CSS-Regeln für das Image-Element und die Klasse final des Figure-Elements.
Um die Darstellung möglichst in allen Browser anzugleichen, verwendet Puzzle das CSSReset 94 von HTML5 Boilerplate (siehe Kapitel 3.1.1) als Basis. Dabei wurden Teile dieses Resets, die für Puzzle irrelevant sind, entfernt.
Da sich, wie bereits erwähnt, Multi-Touch-Interaktion deutlich von der Interaktion mit Maus
unterscheidet, ist es empfehlenswert, den Mauscursor mit der CSS-Eigenschaft cursor auszublenden.
4.4.3 Funktionalität mit JavaScript
JavaScript bildet den zentralen Bestandteil von Puzzle und realisiert die Funktionalität des
Spiels Puzzle:
•
Zufällige Positionierung der Puzzleteile
•
Handling der Multi-Touch-Daten und Erkennung von Gesten
•
Implementierung der Spielmechanik
•
Speicherung der Einstellungen für die Spielmechanik in stukturierter Form
•
Implementierung der Animation bei Spielende
Im Folgenden werden der Aufbau der JavaScript-Komponenten von Puzzle sowie Programmcode, der für die Entwicklung von Multi-Touch-Applikationen relevante Informationen beinhaltet, diskutiert.
Die JavaScript-Funktionalität ist auf drei Dateien aufgeteilt:
•
94
jquery-1.7.1-min.js: Aktuelle und komprimierte Version der Bibliothek jQuery (siehe
Kapitel 3.1.5).
CSS-Resets versuchen, Unterschiede in den Implementierungen von CSS in verschiedenen Browser auszugleichen. Zu diesen Unterschieden zählen standardmäßig definierte Abstände und Größen und nicht
standardkonforme Positionierung von Elementen.
77
•
jquery.multitouch.js: jQMultiTouch Plug-in für jQuery mit Modifikationen seitens des
Autors dieser Arbeit.
•
application.js: das „Herzstück“ der Anwendung. Beinhaltet die Spielmechanik, die Einstellungen des Spiels und initialisiert jQMultiTouch.
application.js
Die Datei application.js beinhaltet drei wesentliche Elemente: ein JSON-Objekt app_data, welches alle Einstellungen für das Spiel wie Schwellwerte und Grenzwerte für die Größe eines
Puzzleteils beinhaltet; das Objekt puzzle, welches die Funktionalität des Spiels beinhaltet und
die Initialisierung des Puzzlespiels sobald die Applikation fertig geladen wurde.
Im JSON-Objekt app_data werden folgende Einstellungswerte festgelegt:
•
Breite und Höhe der Benutzeroberfläche in Pixel
•
Die Bereiche zur Positionierung der Puzzleteile in Pixel
•
Beschränkungswerte für Skalierung eines Elements
•
Schwellwerte für Rotation, Skalierung und Positionierung für die Einrastung eines
Elements
Die Implementierung von Playing Valcamonica in ActionScript verwendet zur Speicherung
dieser Werte eine Datenbank und greift beim Start der Applikation darauf zu. Zur Verwaltung
großer Datenmengen sind Datenbanken sehr geeignet, bei dieser geringen Anzahl von Einstellungsmöglichkeiten ist jedoch die Verwendung eines JSON-Objekts (vor allem im Hinblick auf
die einfache Verwendbarkeit in JavaScript) vorteilhaft.
Die für die Verwendung von Multi-Touch-Gesten relevante Funktionalität ist im Objekt
puzzle implementiert. Dieses Objekt nach dem Pattern Closure 95 strukturiert und besitzt nur
eine öffentliche Methode init(), welche die Initialisierung des Spiels anhand der als Parameter übergebenen Einstellungen (im JSON-Format) vornimmt.
Das Initialisierungsskript (init()) ruft die Methode placeElements() auf, welche die
Puzzleteile innerhalb der im JSON-Objekt angegebenen Grenzen zufällig links und rechts der
Figur in zufälliger Drehung und Größe platziert. Diese Transformationswerte werden, wie in
Listing 16 dargestellt, zur leichteren Verwendung an späterer Stelle als Data-Attribute den
HTML-Elementen hinzugefügt.
95
Es wird empfohlen, Objekte in JavaScript als Closures zu implementieren. Closures werden nicht mit einem
Objektliteral initialisiert, sondern als Funktionsaufruf der ein Objektliteral zurückliefert. Durch die Verwendung von Closures können viele Probleme, die im Zusammenhang mit dem Gültigkeitsbereich von Variablen in JavaScript entstehen, vermieden werden. (Pilgrim, 2010, S. 37)
78
$(element).attr("data-rotation", rotation).attr("data-scale", scale);
Listing 16: jQuery Befehl für die Zuweisung von Data-Attributen, die die Werte der Rotation und Größe beinhalten.
In der durch das Initialisierungsskript aufgerufenen Methode addEventListeners() wird
jQMultiTouch initialisiert. Damit wird die Unterstützung für Multi-Touch-Gesten auf alle
selektierten HTML-Elemente (alle Figure-Elemente) angewendet. Der in Listing 17 dargestellte
Aufruf der von jQMultiTouch implementierten Methode touchable() mit einer Reihe an
Parametern ist die zentrale JavaScript-Anweisung für dieses Multi-Touch-Spiel.
$(elements).touchable({
draggable: true,
scalable: {min: 0.8, max: 1.2},
rotatable: true,
dragBefore: bringToFront,
dragAfter: checkPosition });
Listing 17: Aufruf der Methode touchable von jQMultiTouch für alle Puzzleteile ($(elements)) mit Parameter
zur Aktivierung der Gesten Drag, Scale und Rotate. Über die Callback-Funktionen dragBefore und dragAfter
werden Funktionen der Spiellogik zu Beginn bzw. Ende einer Drag-Geste aufgerufen.
Die Parameter draggable, scalable und rotatable aktivieren die Gesten Drag, Scale und
Rotate in jQMultiTouch. Bei Erkennen einer Geste aktualisiert jQMultiTouch standardmäßig
die veränderten Werte für Position, Größe und Drehung. Damit können Puzzleteile bereits mit
einem Finger verschoben und mit zwei Fingern vergrößert/verkleinert und rotiert werden. Die
mathematischen Berechnungen für diese Gesten werden von jQMultiTouch durchgeführt,
ohne dass der/die Entwickler/in in den Prozess der Gestenerkennung oder der darauf folgenden Aktion eingreifen muss.
Wie in Listing 17 ersichtlich, kann aber über verschiedene Callback-Funktionen wie dragBefore und dragAfter in die Ausführung der Geste eingegriffen werden ohne das Plug-in zu
modifizieren. In dem Spiel Puzzle wird zu Beginn einer Drag-Geste (dragBefore) über Aufruf der Funktion bringToFront das aktuelle Element mit der CSS-Eigenschaft z-index in
den Vordergrund gebracht. Unmittelbar nach der Beendigung einer Drag-Geste (dragAfter)
wird die Funktion checkPosition aufgerufen. CheckPosition vergleicht die aktuelle Position des Elements mit der Zielposition und ruft bei Erreichen dieser Zielposition die Funktion
snapin auf. Snapin rastet das Puzzleteil an der festgelegten Position ein und entfernt das
weiß überlagerte Bild. Im Anschluss wird überprüft, ob alle Puzzleteile eingerastet sind. Ist dies
der Fall, so ist das Ende des Spiels erreicht. Über Tap auf den Button „Play Again“ beginnt das
Spiel von neuem. Dieser Ablauf wird in Abbildung 32 visuell dargestellt.
79
Abbildung 32: Ablaufdiagramm des Spiels Puzzle
jquery.multitouch.js (jQMultiTouch)
Das Plug-in jQMultiTouch ist, wie erwähnt, einfach zu verwenden und vielseitig erweiterbar.
Im Laufe der Entwicklung von Puzzle wurde jedoch deutlich, dass die aktuelle Version des
Plug-ins (Version 0.4) noch Fehlverhalten und leichte Mängel in der Funktionalität aufweist.
Diese Probleme sind dem Hauptentwickler Michael Nebeling bekannt und werden in der
nächsten Version bereits behoben sein.
Für die Entwicklung von Puzzle mussten diese Probleme dennoch adressiert werden. Die wichtigsten Änderungen an dem Plug-in werden hier kurz zusammengefasst.
1. Fehlerhafte Positionierung bei Drag-Geste nach Rotate oder Scale
Die Positionierung eines Elements bei Verwendung der Geste Drag liefert die erwarteten Resultate: Das Element wird um die bewegte Distanz verschoben. Wird das Element mit einer
Rotate oder Scale-Geste transformiert, treten bei anschließender Drag-Geste Fehler auf. Das
Element wird dann zu Beginn der Geste an eine andere – von der aktuellen Drehung und Größe abhängige – Position verschoben.
In der Originalversion des Plug-ins wird die aktuelle Position des Elements anhand der Koordinaten des Touchpunkts (ausgehend vom Viewport) und der Koordinaten des Elements ermittelt. Diese Berechnungen liefern fehlerhafte Resultate, da durch die Transformation die
Koordinaten des Elements verschoben werden.
Um dieses Problem zu lösen, wurde die zurückgelegte Distanz der Drag-Geste auf den Achsen
x und y berechnet und die ermittelten Werte zu den Positionswerten des Elements bei Beginn
der Geste addiert.
[…]
left: touchData.dragging.startPos.left + dragDistanceX + "px",
top: touchData.dragging.startPos.top + dragDistanceY + "px"
[…]
Listing 18: Berechnung der neuen Werte für left und top (x und y) eines Elements bei einer Drag-Geste
80
2. Bestehende Transformationen werden bei Initialisierung des Plug-ins ignoriert.
Dieses Problem wurde bei der Entwicklung von Puzzle deutlich, da die Puzzleteile vor der Initialisierung von jQMultiTouch zufällig positioniert, gedreht und skaliert werden. Die Transformationswerte (Rotate und Scale) werden dabei über die CSS3 Eigenschaft transform für
jedes Element individuell festgelegt. In der Initialisierung erkennt jQMultiTouch vorhandene
CSS-Transforms nicht und produziert bei Durchführung der Gesten Rotate und Drag fehlerhafte Ergebnisse. Das kann wie folgt erklärt werden: Um das erwartete Verhalten bei diesen
Gesten zu erreichen, muss beispielsweise ein bereits um 20° gedrehtes Element bei einer weiteren Drehung um 15° eine Rotation von 35° aufweisen. Die Kalkulation dieses neuen Werts
(35°) ist nur möglich, wenn der Anfangswert (20°) bekannt ist.
Als Lösungsvorschlag wurde im Zuge der Entwicklung von Puzzle jQMultiTouch um eine interne Hilfsfunktion getTransformValues(). Diese Funktion erwartet als Parameter ein
DOM-Element und liefert die Transformationswerte als Objekt mit den Werten scale und
rotation zurück 96.
Werden bereits existierende Transformationswerte bei der Initialisierung mithilfe der
getTransformValues()-Funktion erkannt, so werden diese Werte als Startwerte verwendet.
Andernfalls wird der Standardwert 0 für die aktuelle Rotierung und Skalierung definiert.
touchData.rotate = getTransformValues(this).rotation || 0;
Listing 19: Zuweisung der aktuellen CSS-Rotation des Elements oder des Werts 0, wenn kein Rotationswert
vorhanden ist.
Zur einfacheren Verarbeitung dieser Werte wurde dem Plug-in eine Anweisung hinzugefügt,
die die aktuellen Rotations- und Skalierungswerte als Data-Attribute der HTML-Elemente
speichert (siehe Listing 16). Die Verwendung von Data-Attributen stellt eine Erleichterung bei
der Entwicklung des Spiels dar, allerdings ist diese Funktionalität nicht zwingend notwendig.
3. Limitierung der Maximal- und Minimalwerte für Scale-Geste
In jQMultiTouch kann eine Limitierung der Maximal- und Minimalwerte für die Verwendung
der Geste Scale definiert werden. Dadurch wird verhindert, dass Benutzer skalierbare Elemente
zu klein oder zu groß skalieren.
jQMultiTouch sieht zwar Optionen für diese beiden Werte vor, allerdings wurden sie in der
derzeit verfügbaren Version 0.4 noch nicht implementiert. Daher musste diese Funktionalität
zu jQMultiTouch hinzugefügt werden. Eine einfache Überprüfung des aktuellen Skalierungs-
96
Diese Werte rotate und scale der CSS-Eigenschaft transform können nicht wie herkömmliche
CSS-Eigenschaften ausgelesen werden. CSS-Transformationen werden in einer Transformationsmatrix
dargestellt, daher sind mehrere Berechnungsschritte nötig um die isolierten Werte zu erhalten. (Patonnier,
2012)
81
wertes anhand der Maximal- und Minimalwerte, wie in Listing 20 verkürzt dargestellt, löst
dieses Problem.
if(scale > max_scale) scale = max_scale;
if(scale < min_scale) scale = min_scale;
Listing 20: Limitierung der Scale-Werte auf Maximal- und Minimalwerte.
4.4.4 Endanimation mit JavaScript und GSAP
Die Animation bei erfolgreicher Beendigung des Spiels wurde mit der GreenSock Animation
Platform (siehe Kapitel 3.3.7) in JavaScript programmiert. Für die Endanimation von Puzzle
genügte die Funktionalität der Lite-Varianten von GSAP zusammen mit dem Plug-in zur
Animation von CSS-Werten. Die folgenden Dateien wurden daher als komprimierte Varianten
in den Header der HTML-Datei eingebunden:
•
TweenLite.min.js: Zentraler Bestandteil der GreenSock Animation Platform.
•
TimelineLite.min.js: Beinhaltet die Zeitleistenfunktionalität von GSAP.
•
CSSPlugin.min.js: Ermöglicht die Animation von CSS-Attributen mit GSAP.
Die Endanimation von Puzzle besteht aus sechs aufeinander folgenden Schritten:
•
Einblenden des Hintergrunds für die Animation
•
Bewegung der Arme und Werkzeuge (Schild und Axt) nach oben
•
Bewegung der Arme und Werkzeuge nach unten
•
Bewegung der Arme und Werkzeuge nach oben
•
Bewegung der Arme und Werkzeuge in die Ausgangsposition
•
Ausblenden des Hintergrunds der Animation
Um diese Animationssequenz präzise steuern zu können, empfiehlt es sich, die einzelnen Animationen einem Zeitleistenobjekt (Timeline) hinzuzufügen, das als Container für die gesamte
Animation dient.
Da diese Animation Rotationen der Arme der Figur beinhaltet, wurde der Mittelpunkt der
Transformationen in etwa an den Schultern positioniert. Dies erleichtert die Programmierung
der Rotationsbewegung.
Als Easingfunktion wurde Power1.EaseInOut verwendet, da diese Funktion ähnlich einer
natürlichen Bewegung der Arme wirkt. In Listing 21 wird ein Teil der Animation (Rotation der
rechten Hand) im Zusammenhang mit dem Zeitleistenobjekt (Timeline) dargestellt:
82
var t_hr_2 = TweenLite.to(
hand_r,
0.5, {
ease: Power1.easeInOut,
css: { rotation: 18 } });
tl.append(t_hr_2); // Tween zu Timeline hinzufügen
Listing 21: Animation des Werts rotation der rechten Hand. Die Animation dauert 0.5 Sekunden und verwendet eine Easingfunktion. Im Anschluss wird die Animation der Zeitleiste (tl) hinzugefügt.
4.5 Test des Prototyps
Um die Verwendbarkeit der prototypisch umgesetzten Lösung zu evaluieren, wurde ein Test
des Systems durchgeführt. Da das Spiel Puzzle für bis zu vier Personen konzipiert ist, spielten
das Spiel während des Tests vier Personen gleichzeitig. Bei diesem Test konnte die Funktionalität des Prototyps unter hoher Last durch viele simultane Interaktionen und Manipulationen
von Elementen getestet werden.
Abbildung 33: Test des Prototyps mit vier Personen.
4.5.1 Testsetup
Die Teilnehmer/innen sind im Alter zwischen 24 und 28 Jahren. Drei Personen sind weiblich
und eine Person ist männlich. Der Test wurde in den Räumlichkeiten der Fachhochschule St.
Pölten auf der in Kapitel 4.1.4 Hardware durchgeführt. Das Puzzlespiel wurde von einem Webserver außerhalb der Fachhochschule abgerufen.
Folgende Browser wurden getestet:
•
Mozilla Firefox, Version 13
•
Google Chrome, Version 20 mit aktivierter Unterstützung für Touchevents (experimentiell)
83
4.5.2 Testablauf
Der Test bestand aus drei Phasen:
1.
Kurze Einleitung in den Hintergrund des Tests und Playing Valcamonica.
2.
Test des Puzzlespiels in drei Varianten:
1. ActionScript-Implementierung
2. JavaScript-Implementierung, ausgeführt in Mozilla Firefox 13
3. JavaScript-Implementierung, ausgeführt in Google Chrome 20
3.
Befragung der Teilnehmer/innen
Für jede der drei getesteten Varianten des Spiels wurden folgende Schritte durchgeführt:
•
„Normales“ Spielen mit Beteiligung aller Teilnehmer/innen
•
Simultanes Bewegen (Drag) von zwei Elementen je Teilnehmer/in
•
Starke Auslastung durch simultanes Transformieren von zwei Puzzleteilen je
Teilnehmer/in
Folgende Fragen wurden den Teilnehmer/innen am Ende des Tests gestellt:
•
„Welche Variante hat deiner Meinung nach am besten funktioniert und warum?“
•
„Gab es Probleme bei der Bedienung?“
•
„Sind dir optische Unterschiede zwischen den Varianten aufgefallen?“
84
5
Ergebnisse
In diesem Kapitel werden die Ergebnisse dieser Arbeit dargestellt. Die Erkenntnisse wurden
einerseits aus der in Kapitel 2 und 3 beschriebenen theoretischen Auseinandersetzung sowie
aus der in Kapitel 4 beschriebenen Entwicklung und dem Test des Prototyps gewonnen. Die
Forschungsfrage, ob der Webbrowser als Plattform für Multi-Touch-Applikationen eine Alternative zu Desktopanwendungen darstellt, wird aufbauend auf diese Erkenntnisse und unter
Betrachtung von Use Cases (Anwendungsfälle) beantwortet.
5.1 Ergebnisse der allgemeinen Kriterien
5.1.1 Fähigkeiten aktueller Browser zur Verarbeitung von Touchevents
Die Unterstützung von Touchevents sowie das verwendete API in Desktopbrowser variert
stark, jedoch sind Events zur Verarbeitung von Touchdaten in Webapplikationen in Mozilla
Firefox, Google Chrome und Internet Explorer 10 (siehe Tabelle 8) verfügbar. Unter den auf
mobilen Endgeräten verfügbaren Browser unterstützen Apple Safari, Mozilla Firefox und der
kürzlich veröffentlichte Google Chrome Multi-Touch-Events.
Browser
Version
API
Anmerkung
Mozilla Firefox
ab 3.6
Mozilla Touch API
(proprietär)
Ab Version 6 wird dieses API nicht
mehr weiterentwickelt.
Google Chrome
ab 20
W3C Touch API
Derzeit nur als experimentielle
Funktion aktivierbar und auf sieben simultane Touches beschränkt.
Microsoft Internet
Explorer
ab 10
MS Pointer API
(proprietär)
Tabelle 8: Desktop-Browser mit Unterstützung für Touchevents
5.1.2 Performance aktueller Browser bei Multi-Touch- und
Gesteninteraktionen
Eine hohe Performance ist eine der wichtigsten Voraussetzungen für ein ansprechendes MultiTouch-Interface. Sinkt die Bildwechselfrequenz (FPS) während der Gestendurchführung auf
weniger als 15 Bilder pro Sekunde kann das Gehirn einzelne Schritte wahrnehmen und die
Interaktion wird nicht mehr als „flüssig“ empfunden (Read, Meyer, & Gamma Group, 2000).
Generell ist festzustellen, dass Gestenaktionen in Google Chrome mit einer höheren Frequenz
als Mozilla Firefox ausgeführt werden. Der Unterschied wird vor allem bei der simultanen
85
Ergebnisse
Transformation von mehreren Elementen deutlich. Dies ist auf die in Kapitel 0 erwähnte höhere Performance der JavaScript-Engine von Chrome zurückzuführen.
Bei der Transformation von Bildern mit der CSS3-Eigenschaft transform mittels MultiTouch-Gesten können Performanceprobleme auftreten. Bei kleinen Bildern ist die Performance für eine als flüssig wahrgenommene Interaktion ausreichend, jedoch sinkt die Bildwechselrate enorm, je größer ein Bild skaliert wird. Transformationen eines Bildes mit 1000 Pixel
Kantenlänge werden nur noch sehr langsam (unter 5 FPS) durchgeführt, was zu einer mangelhaften User Experience führt. Um dies zu verhindern ist es notwendig, einen Maximalwert für
Scale-Transformationen festzulegen. Aufgrund der relativ kurzen Verfügbarkeit dieser Transformationen ist allerdings davon auszugehen, dass die Implementierungen der CSSTranformationen in zukünftigen Browserversionen optimiert werden.
In aktuellen mobilen Browser wird ein Performanceproblem bei der Verwendung größerer
Bilder (>150 kB) als Gesteninteraktionselemente ausgelöst. Auch ohne die Verwendung von
CSS-Transformationen ist die Leistung dieser Geräte und Browser zu gering, um eine einfache
Drag-Aktion eines Elements ruckelfrei darzustellen. Werden jedoch HTML-Elemente ohne
Bilder verwendet, ist eine höhere Performance festzustellen.
5.1.3 Verfügbarkeit von Frameworks für Multi-Touch-Gestensteuerungen
Derzeit stehen Entwickler/innen zwei Frameworks zur Verfügung, um Multi-TouchWebanwendungen mit Gestenunterstützung für Tabletop-Systeme zu entwickeln: Hammer/Hummer.js und jQMultiTouch.
Hammer/Hummer.js
Hammer.js eignet sich zur Programmierung von Multi-Touch-Anwendungen und unterstützt
die am häufigsten verwendeten Gesten: Tap, Doubletap, Drag, Rotate und Scale. Die Bibliothek
weist allerdings folgende Einschränkungen auf:
•
Keine Möglichkeit zur Erweiterung des Sets an verfügbaren Gesten
•
Keine Unterstützung von Mozilla Touch Events
•
Verwendendung der Gesten Rotate und Scale aufwendig
Durch die Erweiterung Hummer.js werden die beiden letztgenannten Einschränkungen von
Hammer.js grundsätzlich behoben, wenn auch die Verwendung von Mozilla Touch Events
aufgrund des grundsätzlichen Aufbaus von Hammer.js noch Probleme aufweisen kann (siehe
Kapitel 3.3.3). Ein weiterer Nachteil dieser Erweiterung ist, dass Hummer.js nicht weiterentwickelt wird und somit auch Änderungen der Originalversion (Hammer.js) nicht übernommen
werden.
Hammer.js/Hummer.js realisiert nur die Erkennung der oben erwähnten Gesten, die entsprechende Reaktion des Systems auf diese Gesten muss der/die Programmierer/in implementie-
86
Ergebnisse
ren. Dieser Ansatz entkoppelt zwar die Gestenerkennung von der Applikationslogik, jedoch
resultiert daraus ein höherer Entwicklungsaufwand.
jQMultiTouch
Die Bibliothek jQMultiTouch stellte sich bei der Entwicklung des Prototyps als sehr flexibel
und einfach zu verwenden dar. jQMultiTouch befindet sich noch in der Entwicklung und ist
daher stellenweise noch nicht ausgereift. Die Konzepte im Kern der Bibliothek (etwa die Touch
History, siehe Kapitel 3.3.4) bieten jedoch vielseitige Möglichkeiten zur Entwicklung von Benutzerschnittstellen mit komplexer Gestensteuerung.
jQMultiTouch implementiert vordefinierte Gesten wie Drag, Rotate und Scale mitsamt der
erwarteten Aktion des Elements. Ein Element, das mit jQMultiTouch als rotierbar gekennzeichnet wurde, kann ohne weiteren Code bereits per Multi-Touch gedreht werden. Im Vergleich zu Hammer.js/Hummer.js stellt dies eine Zeitersparnis dar.
Die Möglichkeit, in die Ausführung der vordefinierten Gesten (Drag, Rotate, Scale) über Callback-Funktionen einzugreifen, sorgt für Flexibilität bei der Verwendung der Bibliothek trotz
standardmäßig implementierter Reaktionen auf die Gesten (beispielsweise das Drehen eines
Elements bei der Geste Rotate).
Merkmal
Hummer.js
jQMultiTouch
W3C-Touch Events
✓
✓
Mozilla Touch Events
✓
✓
Standard-Gesten (Drag,
Rotate, Scale)
✓
✓
Individuelle Gesten
×
✓
Transform-Verhalten
implementiert
×
✓
Verlauf der Touchpoints
×
✓ (Touch History)
Individuelle Reaktionen auf
Gesten durch
Events
Callbacks
Tabelle 9: Vergleich der Merkmale von Hummer.js und jQMultiTouch
5.1.4 Verfügbarkeit von Werkzeugen zur Erstellung von
webbasierten Animationen
Mit der Einführung des HTML5-Elements Canvas und dessen zunehmender Unterstützung
wird die Entwicklung sowohl von linear zeitbasierten als auch interaktiven Animationen ohne
Browser-Plug-ins möglich. Sehr rechenintensive Animationen mit einer Vielzahl an Objekten
werden durch WebGL, das in einem Canvas-Element gerendert wird, möglich.
87
Ergebnisse
Abseits von Animationen, die auf Canvas basieren, werden auch Animationen von HTMLElementen wie Images oder Text unter Verwendung von CSS(3)-Attributen mit höherer Performance möglich. Auf diese Entwicklung aufbauend, stellt Adobe mit Edge ein Werkzeug zur
Verfügung, das die Animation von HTML-Elementen anhand einer Zeitleiste mit Schlüsselbildern sehr einfach und effizient ermöglicht. Da Edge auf Standard-Webtechnologien aufbaut,
können auch interaktive Elemente über JavaScript-Code eingebettet werden.
Im Zusammenhang mit der Entwicklung der Endanimation des Prototyps wurde allerdings
festgestellt, dass mit Edge erstellte Animationen noch Einschränkungen haben:
•
Edge ist dafür konzipiert, dass die erstellten Animationen sofort nach abgeschlossenem
Ladevorgang gestartet werden. Soll die Animation erst zu einem späteren Zeitpunkt gestartet werden, so muss der generierte Code verändert werden. Dies führt dazu, dass
nach jedem Export der Animation dieser Schritt wiederholt werden muss.
•
Mit Edge erstellte Animationen und deren verwendeten Ressourcen werden automatisch geladen. So ist bespielsweise keine Möglichkeit vorgesehen, das von Edge verwendete jQuery nicht zu inkludieren. Das kann zu Kompatibilitätsproblemen führen.
Abhilfe schafft die Veränderung des generierten Codes, was jedoch zu dem in Punkt 1
erwähnten Problem führt.
•
Bereits in einem HTML-Dokument vorhandene Elemente können nicht in einem
Edge-Projekt verwendet werden. In Konzepten, die die Animation von vorhandenen
Elementen vorsehen, folgt daraus ein doppelt so hoher Ladebedarf, da jedes Element
zwei Mal vom Server geladen werden muss.
Aus diesen Gründen wurde die Endanimation des Prototyps mit der GreenSock Animation
Platform (GSAP) umgesetzt. Die Verwendung dieser Bibliothek ist – nicht zuletzt aufgrund der
umfangreichen Dokumentation – einfach und schnell zu erlernen. Im Vergleich mit Adobe
Edge ist die Erstellung von Animationen mit GSAP aufgrund des nicht vorhandenen visuellen
Editors zeitaufwändiger. Vorteilhaft ist jedoch, dass vorhandene HTML-Elemente verwendet
und die Animationen präzise per Code gesteuert werden können. Zudem ist GSAP auf hohe
Performance optimiert, um auch komplexere Animationen ruckelfrei darstellen zu können.
5.1.5 Verfügbarkeit von unterstützenden Werkzeugen
Eine Reihe von Werkzeugen wurden bei der Entwicklung des in Kapitel 4 beschriebenen Prototyps verwendet, um die Entwicklung effizienter und angenehmer zu gestalten. Der zentrale
Aspekt der Webentwicklung, die Programmierung, wird in einem Texteditor durchgeführt.
Die Auswahl an Texteditoren mit unterschiedlichen Merkmalen für verschiedene Programmiersprachen ist groß. Die persönlichen Präferenzen der Entwicklerin/des Entwicklers spielen
bei der Auswahl des Texteditors eine große Rolle. Nachfolgend werden die Werkzeuge, die bei
der Entwicklung des Puzzle-Prototyps verwendet wurden, beschrieben.
88
Ergebnisse
Texteditoren: Netbeans IDE 7.1 und Notepad++
Die Integrierte Entwicklungsumgebung (IDE) Netbeans wurde für die Erstellung der HTMLund CSS-Dateien sowie die Programmierung der JavaScript-Funktionalität verwendet. Netbeans bietet in der Version 7.1 umfangreiche Funktionen, die bei Programmieraufgaben unterstützend wirken. Für die Entwicklung von Puzzle stellten sich vor allem folgende Merkmale als
nützlich dar:
•
Syntax-Highlighting erhöht die Übersichtlichkeit von Quellcode enorm.
•
Autocompletion erspart vor allem bei der HTML- und CSS-Entwicklung Tastenanschläge und bietet in der Folge auch Zeitersparnis.
•
Übersichtliche Darstellung der Dateien im Projektexplorer.
•
Syntax-Check bei JavaScript-Entwicklung kontrolliert unter anderem nicht verwendete
Variablen oder fehlerhaft verwendete Zeichen.
•
Integration und Darstellung von Versionierungssystemen wie Git oder Subversion.
Netbeans ist eine umfangreiche Entwicklungsumgebung und benötigt daher einige Zeit für den
Startvorgang. Für einfache Aufgaben und kurzfristige Änderungen wurde daher Notepad++
verwendet. Notepad++ ist ein Texteditor, der ebenfalls Funktionen wie Syntax-Highlighting
bietet, jedoch nicht dem Umfang von Netbeans entspricht.
Versionierungssystem: Git
Als Versionierungssystem wurde Git verwendet. Versionierung ist eine gängige Praxis in der
Softwareentwicklung und ermöglicht die Arbeit von mehreren Entwickler/innen an der gleichen Codebasis sowie problemloses zurückkehren auf frühere Versionen.
Git ist ein verteiltes Versionierungssystem, im Unterschied zu zentralen Systemen wie Subversion hat dies den Vorteil, dass auch ohne bestehende Verbindung zum Internet neuer oder
veränderter Quellcode in das System commited (engl. etwa übergeben) werden kann. Besteht
zu einem späteren Zeitpunkt eine Verbindung zum zentralen Speicherort, können die Änderungen hochgeladen werden um sie für andere Entwickler/innen zur Verfügung zu Stellen.
Als Hostingprovider für das Git Repository von Puzzle wurde Bitbucket verwendet. Bitbucket
bietet kostenlosen Speicherplatz für Sourcecode von nicht kommerziellen Projekten mit Unterstützung für Versionierungssyteme wie Git und Subversion an.
Entwicklertools im Browser: Google Chrome Entwicklertools und Firebug für Mozilla Firefox
Die Entwicklung von Webapplikationen wird durch Entwicklertools der Browser deutlich
schneller, einfacher und komfortabler gestaltet. Entwicklertools erlauben die Inspektion und
Änderung der aktuell im HTML-Dokument vorhandenen Elemente mit ihren CSSEigenschaften ohne den zugrunde liegenden Quellcode bearbeiten zu müssen. Pixelgenaue
Positionierung von Elementen oder subtile Änderungen, etwa von Schlagschatten, können mit
89
Ergebnisse
diesen Werkzeugen direkt im Browser durchgeführt werden. Fehler in JavaScriptAnweisungen werden in diesen Werkzeugen ebenso dargestellt wie die vom Server geladenen
Dateien und Ressourcen.
Für die Entwicklung in Google Chrome stellt der Hersteller die standardmäßig inkludierten
Chrome Entwicklertools bereit. Diese Komponente von Chrome bietet grundsätzlich ähnliche
Funktionalität wie das Plug-in Firebug für Mozilla Firefox. Beide Werkzeuge unterstützen die
Entwicklung von webbasierten Multi-Touch-Applikationen in hohem Ausmaß.
Multi-Touch Vista
Bei der Entwicklung des Puzzlespiels wurde das in Kapitel 3.3.6 beschriebene Produkt MultiTouch Vista zur Simulation der Toucheingabe verwendet. Dabei wurde die Funktion „Multiple
Mice“ aktiviert, um den Prototyp mit zwei an den Entwicklungsrechner angeschlossenen Mäusen zu testen. Dieser Simulator ermöglicht Tests während der Entwicklung des Prototyps, allerdings empfiehlt es sich, Multi-Touch-Applikationen in regelmäßigen Abständen auch auf
Multi-Touch-fähiger Hardware zu testen. Durch die Bedienung des Systems mit zwei Mäusen
kann zwar die grundsätzliche Funktionalität getestet werden, sofern nicht mehr als zwei
Touchpunkte gleichzeitig benötigt werden. Es ist allerdings festzustellen, dass Probleme, die
erst bei mehreren simultanen Berührungspunkten auftreten, mit Simulatoren kaum simuliert
werden können.
5.2 Ergebnisse des Tests des Prototyps
Der in Kapitel 4.5 beschriebene Test des Prototyps wirkte unterstützend bei der Evaluierung
des Prototyps hinsichtlich der Funktionalität und Einsetzbarkeit. Wie beschrieben, wurden die
Flash-Applikation und die Webapplikation getestet, wobei zweitere sowohl in Mozilla Firefox
als auch in Google Chrome ausgeführt wurde. Die Flash-Variante wird dabei als Referenzimplementierung betrachtet anhand derer die Funktionalität der Webapplikation bewertet wird.
5.2.1 Wie verhält sich die Webapplikation bei der Bedienung von einer
Person im Vergleich mit der Flash-Applikation?
Die Webapplikation stellte sich bei der Bedienung des Systems von nur einer Person (Single
User) als zufriedenstellend performant und fehlerfrei dar. Die Performance ist mit jener der
Flash-Implementierung zu vergleichen; signifikante Unterschiede zwischen den Browser Mozilla Firefox und Google Chrome konnten im Test mit einer Testperson nicht festgestellt werden.
90
Ergebnisse
5.2.2 Wie verhält sich die Webapplikation bei der gleichzeitigen Bedienung von vier Personen (Multi User) im Vergleich mit der FlashApplikation?
Im Test der Webapplikation mit vier Personen, die das System gleichzeitig von vier Seiten bedienen, konnten starke Einschränkungen hinsichtlich der Leistungsfähigkeit der Browser bei
Multi-Touch-Interaktionen festgestellt werden (siehe Kapitel 5.2.3). Aus diesen Performanceproblemen resultieren Schwierigkeiten bei der Bedienung der Applikation, da einzelne Puzzleteile nur noch ruckartig bewegt und transformiert werden können. Dies führt zu einer
mangelhaften User Experience.
Zusätzlich konnte in dem Test festgestellt werden, dass die getestete Version Google Chrome
20 mit aktivierter Unterstützung von Touchevents (siehe Kapitel 0) lediglich sieben simultane
Berührungen verarbeiten kann. Diese Einschränkung ist bei mehreren Personen, die vier
gleichzeitige Gesten mit jeweils zwei Fingern durchführen bereits problematisch. Da weitere
Berührungspunkte ignoriert werden und somit Gesten nicht ausgeführt oder falsch interpretiert werden, tritt für die Benutzer/innen unerwartetes Verhalten auf.
5.2.3 Ab welcher Belastung sind Performanceprobleme
deutlich erkennbar?
Wie in Kapitel 5.2.2 bereits erwähnt, treten bei der simultanen Bedienung der Applikation von
vier Personen Probleme hinsichtlich der Performance auf.
Während mehrere Elemente gleichzeitig per Drag-Geste verschoben werden können, ohne
dass die Bedienbarkeit merklich beeinträchtigt wird, ist bei Mehrfinger-Gesten wie Rotate und
Scale eine deutliche Beeinträchtigung feststellbar. Dabei ergeben sich Unterschiede in der Performance der Browser:
In Mozilla Firefox sinkt die Bildwechselfrequenz auf der getesteten Hardware bereits ab zwei
simultanen Rotate- oder Scale-Gesten deutlich ab, so dass die Puzzleteile nur noch ruckartig
transformiert werden.
Google Chrome kann aufgrund der performanteren JavaScript-Engine auch drei gleichzeitig
durchgeführte Transform-Gesten in einer höheren Bildwechselfrequenz als Mozilla Firefox
darstellen. Doch auch in Google Chrome werden die Transformationen leicht ruckartig dargestellt. Zudem sind mehr als drei Zweifinger-Gesten durch die bereits beschriebene Einschränkung des Browsers auf sieben gleichzeitige Berührungspunkte nicht möglich.
5.2.4 Tritt Fehlverhalten bei der Verwendung von Gesten auf?
Die Erkennung der Gesten mit jQMultiTouch funktioniert auch bei mehreren gleichzeitigen
Interaktionen zuverlässig. Die Teilnehmer/innen des Tests konnten das Spiel ohne Probleme
hinsichtlich der Gestenerkennung bedienen.
91
Ergebnisse
Geringfügige Probleme traten jedoch auf, wenn eine Person ein Puzzleteil gleichzeitig transformierte und bewegte. Diese Kombination aus zwei Gesten kann jQMultiTouch zwar ausführen, jedoch wird als Urspungspunkt der Drag-Geste der erste Berührungspunkt verwendet.
Aus diesem Grund tritt bei einer deutlichen Transformation eines Elements unerwartetes Verhalten beim Verschieben auf.
Um dieses Problem zu lösen, müsste die Berechnung der Koordinaten einer Drag-Aktion bei
mehreren gleichzeitigen Punkten den Mittelpunkt aller Punkte ermitteln um das Element anhand diesen Werts zu verschieben.
5.2.5 Welchen subjektiven Eindruck erhalten Benutzer/innen hinsichtlich
der Qualität der Interaktion und der visuellen Darstellung des Spiels?
Die Einschätzung der Qualität der Interaktion und der visuellen Darstellung des Spiels wurde –
zusätzlich zur Beobachtung der Reaktionen der Testteilnehmer/innen – anhand einer mündlichen Befragung zu Ende des Tests evaluiert. Die Antworten stellen daher subjektive Eindrücke
der Testteilnehmer/innen dar, wenngleich die wesentlichen Kommentare auf technische Gegebenheiten zurückzuführen sind.
„Zittrige“ Puzzleteile
Das Transformieren oder Verschieben eines Puzzleteils wirkt auf die Testpersonen „zittrig“.
Alle Teilnehmer/innen des Tests stellten diese ungleichmäßige Darstellung der Bewegung oder
Veränderung fest.
Diese Unregelmäßigkeit ist auf die ungenaue Erkennung von Bewegungen der Fingerpositionen durch die Hardware zurückzuführen. Das Problem kann jedoch softwareseitig gelöst werden, indem Werte, die deutlich von den vorherigen Werten abweichen, angepasst werden.
Derartige Operationen werden als Glättung bezeichnet, da die Funktion, die die Wertveränderung beschreibt, danach eine geringere Fluktuation aufweist.
Schlagschatten von Puzzleteilen
Eine Testperson merkte an, dass die Webapplikation im Vergleich zur Flash-Variante visuell
„flacher“ wirke. Dies ist auf den fehlenden Schlagschatten der einzelnen Puzzleteile zurückzuführen.
In ActionScript/Flash wurde Schlagschatten programmatisch auf einzelne Elemente angewendet, um noch nicht richtig platzierte Elemente subtil in den Vordergrund zu bringen. Besitzen
Puzzleteile eine unregelmäßige Form (wie die Puzzleteilen von Playing Valcamonica) mit
Transparenzen, wird der in ActionScript definierte Schatten dieser Form angepasst (siehe Abbildung 34). Im Vergleich dazu wird bei Verwendung der CSS3-Eigenschaft box-shadow der
Schatten auf das umgebende Rechteck angewendet (siehe Abbildung 35). Um dieses Problem
zu umgehen, muss der Schlagschatten mit einem Bildbearbeitungswerkzeug hinzugefügt wer-
92
Ergebnisse
den. Diese Bearbeitung des Bildes macht jedoch eine spätere programmatische Änderung des
Schattens unmöglich.
Abbildung 34: Schlagschatten in ActionScript passt
Abbildung 35: CSS3-Schlagschatten wird auf das
sich der Form eines Elements mit Transparenzen an.
gesamte Element angewendet.
5.3 Use Cases
Die Forschungsfrage, ob der Browser eines Tabletop-PCs eine Plattform für ansprechende
Multi-Touch-Applikationen darstellt, kann aufgrund der Vielseitigkeit der dargestellten Erkenntnisse nicht eindeutig mit Ja oder Nein beantwortet werden. Daher werden drei Use Cases
(engl. Anwendungsfälle) definiert, anhand derer die Verwendbarkeit von Multi-Touch und
Gestensteuerungen in Webapplikationen diskutiert wird.
Use Case 1: Eine Multi-User-Applikation, die nur mit Gesten geringer Komplexität wie Drag
oder Tap bedient wird oder eine Single-User-Applikation, die auch Rotate- und Scale-Gesten
verwendet.
Für eine derartige Applikation stellt der Browser eine alternative Plattform zu Desktopanwendungen dar. Die beschriebenen Einschränkungen hinsichtlich Performance und Verarbeitung
der Touchevents sind in diesem Anwendungsfall zu vernachlässigen, da einfache Drag und
Tap-Aktionen ausreichend performant durchgeführt werden können und nicht mehr als sieben simultane Berührungspunkte benötigt werden.
Use Case 2: Eine Applikation, die Gesten wie Rotate und Scale verwendet, hochauflösende Grafiken als Interaktionselemente einsetzt und für ein bis drei Personen konzipiert ist (Multi
User).
Eine Applikation mit diesen Eigenschaften ist nur bedingt für die Ausführung im Webbrowser
geeignet, da aufgrund der Grafikanforderungen deutliche Performanceprobleme auftreten
können. Zusätzlich ist bei Ausführung in Google Chrome, der eine höhere Performance als
Mozilla Firefox aufweist, in Multi User Applikationen auf die derzeitige Limitierung sieben
simultaner Berührungspunkte zu achten.
93
Ergebnisse
Use Case 3: Eine Applikation, die sowohl Mehrfingergesten wie Drag und Rotate als auch
hochauflösende Grafiken als Interaktionselemente verwendet und von mehr als drei Spielern
zur selben Zeit bedient werden soll (Multi User).
Aufgrund der derzeitigen Einschränkungen der Multi-Touch-fähigen Browser ist eine Applikation mit diesen Merkmalen für die Ausführung im Browser nicht geeignet. Die Performance
bei Transformationen von hochauflösenden Grafiken mit CSS3 reicht aktuell noch nicht für
eine Bildwechselfrequenz, die eine Applikation für eine ansprechende User Experience benötigt. Zudem treten Probleme durch die Einschränkung auf sieben Touchpoints in Google
Chrome bei der gleichzeitigen Bedienung von mehr als drei Personen auf.
94
6
Conclusio
In dieser Arbeit wurden Möglichkeiten untersucht, Multi-Touch-Applikationen für die Ausführung im Browser eines Tabletop-PCs zu entwickeln. Der Webbrowser als Plattform für
Multi-Touch-Anwendungen bietet Vorteile gegenüber Desktopsoftware, da Webapplikationen
eine hohe Geräte- und Plattformunabhängigkeit aufweisen, einfache Distribution ermöglicht
und die Fähigkeiten der Webbrowser rapide verbessert werden.
Um die zentrale Forschungsfrage, ob der Browser eines Tabletop-PCs eine Plattform für ansprechende Multi-Touch- und gestenbasierte Anwendungen darstellt zu beantworten, wurden
mehrere Aspekte betrachtet. Die Fähigkeiten moderner Browser zur Verarbeitung von MultiTouch-Informationen, die Möglichkeiten, die neue Webstandards wie HTML5 und CSS3 bieten sowie deren Einschränkungen hinsichtlich Performance und Implementierung und Möglichkeiten zur Erstellung webbasierter Animationen wurden diskutiert.
Ein zentraler Aspekt von Multi-Touch ist die Interaktion mittels Gesten, daher wurden Frameworks, die einerseits die unterschiedlichen Touch-APIs vereinheitlichen und andererseits
die Erkennung von Multi-Touch-Gesten realisieren, evaluiert. In einem praktischen Experiment wurden die gewonnen Erkenntnisse in Form eines Prototyps umgesetzt und auf die Verwendbarkeit getestet.
Die Unterstützung von Touchevents in Desktopbrowser ist derzeit noch nicht sehr weit fortgeschritten. Während Mozilla Firefox bereits mit Version 3.6 (aktuell: 14) ein propretäres API für
die Verwendung von Touchevents einführte, bietet Google Chrome erst seit der aktuellen Version 20 experimentielle Unterstützung von Touchevents über ein vom W3C standardisiertes
API. Microsoft kündigte für den in Windows 8 enthaltenen Internet Explorer 10 wiederum ein
eigenes API zur Verwendung von Toucheingabe an.
Aufgrund dieser Unterschiede in Browser unterschiedlicher Hersteller ist die Verwendung von
Frameworks, die die Verwendung dieser APIs vereinheitlichen, sinnvoll. Die beiden Frameworks Hummer.js und jQMultiTouch bieten neben dieser Abstraktion auch die Erkennung
von Gesten. Das Hummer.js zugrunde liegende Framework Hammer.js unterstützt nur das
W3C Touch Event-API, daher wurde dieses Framework im Zuge dieser Arbeit um die Mozilla
Touch Events und einige Funktionen zur einfacheren Verwendbarkeit erweitert und in Hummer.js umbenannt. Das Framework jQMultiTouch unterstützt standardmäßig sowohl W3Cals auch Mozilla Touch Events und ermöglicht die Erkennung von vordefinierten sowie individuellen Gesten. Zudem bietet jQMultiTouch Möglichkeiten zur Anpassung der Funktionalität
und ist damit vielseitig einsetzbar.
In einem Test des mit jQMultiTouch entwickelten Prototyps eines Puzzlespiels wurde die Verwendbarkeit und Praxistauglichkeit einer derartigen Anwendung auf einem Multi-Touch
Tabletop-PC getestet. Vier Personen lösten in diesem Test miteinander und gleichzeitig das
Puzzle einerseits in der in Adobe Flash entwickelten Referenzimplementierung und anderer95
Conclusio
seits die Webapplikation in Mozilla Firefox und Google Chrome. In diesem Test wurde festgestellt, dass Chrome bei der Interaktion mittels Gesten im Vergleich zu Firefox eine höhere Performance aufweist, jedoch ist die Anzahl der simultanen Berührungspunkte derzeit auf sieben
beschränkt. Durch diese Einschränkung ist Chrome nur bedingt für Multi User Applikationen
geeignet. In Mozilla Firefox konnte keine derartige Einschränkung festgestellt werden. Performanceprobleme treten in beiden Browser vor allem bei der Transformation von großen Grafiken mit Multi-Touch-Gesten auf. Im Vergleich mit der Implementierung in Flash wurde von
den Testpersonen neben Performanceproblemen vor allem „zittriges“ Verhalten beim Verschieben oder Transformieren der Puzzleelemente kritisiert. Dieses Problem kann jedoch softwareseitig gelöst werden.
Aufgrund dieser Einschränkungen kann die Forschungsfrage nur bedingt positiv beantwortet
werden. Für Applikationen, die einfache Gesten wie Drag und Tap verwenden und nicht mehr
als sieben simultane Berührungspunkte benötigen, kann der Browser als alternative Plattform
für Multi-Touch-Applikationen betrachtet werden. Vor allem die derzeitige Performance der
Browser bei der Transformation von Grafiken ist als Hindernis für komplexere gestenbasierte
Multi-Touch-Applikationen zu betrachten. Für die Entwicklung von Multi-Touch-Prototypen
sind Webtechnologien aufgrund der relativ einfachen und schnellen Programmierung dennoch
geeignet.
Durch die schnelle Verbesserung der Fähigkeiten moderner Browser im Zusammenhang mit
den Technologien HTML5 und CSS3 ist zukünftig eine höhere Performance bei Transformationen zu erwarten. Derzeitige Bestrebungen seitens des W3C, die Verwendung von Touchevents zu vereinheitlichen, erleichtern zudem die Entwicklung von Multi-Touch-Applikationen.
Im Zusammenhang mit der generellen Tendenz, immer umfangreichere Anwendungen mit
Webtechnologien zu realisieren, sind diese Entwicklungen für die zukünftige Verwendbarkeit
von Multi-Touch im Browser von großer Bedeutung.
Diese Arbeit zeigt, dass der Browser für einfache, gestenbasierte und animationsunterstützte
Applikationen bereits jetzt eine Alternative zu Desktopanwendungen darstellt. Als größte Hindernisse für die Erstellung komplexerer Anwendungen konnte derzeit die Leistungsfähigkeit
der Browser und die daraus resultierende mangelhafte User Experience identifiziert werden.
Aber auch diese Einschränkung wird durch zukünftige Verbesserungen der Browser von geringerer Bedeutung sein.
96
7
Anhang
Anhang A: Quellenverzeichnis
Adobe Systems (Hg.). (2012, Juli 26). HTML5 tools, Animation tools - Adobe Edge Preview. Adobe
Labs. Abgerufen August 5, 2012, von http://labs.adobe.com/technologies/edge/
Apple (Hg.). (2010, Dezember 16). TouchEvent Class Reference. Abgerufen Juni 29, 2012, von
http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchEv
entClassReference/TouchEvent/TouchEvent.html#//apple_ref/doc/uid/TP40009358
Apple (Hg.). (2011, Juli 28). Mac OS X Lion: Informationen zu Multi-Touch-Gesten. Abgerufen Juni 1,
2012, von http://support.apple.com/kb/HT4721?viewlocale=de_DE#
Apple (Hg.). (o. J.-a). Apple - Magic Mouse - Die erste Multi-Touch-Maus der Welt. Abgerufen Juni 1,
2012, von http://www.apple.com/at/magicmouse/
Apple (Hg.). (o. J.-b). Apple - Magic Trackpad - Das Multi-Touch Trackpad für deinen Desktopcomputer. Abgerufen Juni 1, 2012, von http://www.apple.com/at/magictrackpad/
Berners-Lee, T. (2006, Oktober 27). Reinventing HTML | Decentralized Information Group (DIG)
Breadcrumbs. Abgerufen Juni 25, 2012, von http://dig.csail.mit.edu/breadcrumbs/node/166
Berners-Lee, T. (2012, April 11). Longer Bio for Tim Berners-Lee. Abgerufen Juni 22, 2012, von
http://www.w3.org/People/Berners-Lee/Longer.html
Boas, M. (2012, Mai 8). HTML5 Audio — The State of Play | HTML5 Doctor. Abgerufen Juni 25, 2012,
von http://html5doctor.com/html5-audio-the-state-of-play/
Bos, B., Çelik, T., Hickson, I., & Lie, H. W. (2011, Juni 7). Cascading Style Sheets Level 2 Revision 1
(CSS 2.1) Specification. Abgerufen Juni 28, 2012, von http://www.w3.org/TR/2011/REC-CSS220110607/
Brubeck, M. (2012, März 6). Touch events (Mozilla experimental) - MDN. Abgerufen Juli 2, 2012, von
https://developer.mozilla.org/en/DOM/Touch_events_(Mozilla_experimental)
Brubeck, M., Moon, S., & Schepers, D. (2011, Dezember 15). Touch Events version 1. Abgerufen Juni 29,
2012, von http://www.w3.org/TR/touch-events/
Buxton Bill. (2009, Dezember 2). Multi-Touch Systems that I Have Known and Loved.
Cabello, R. (2012, Juni 6). three.js. GitHub. Abgerufen Juni 26, 2012, von
https://github.com/mrdoob/three.js
Cabrera, L. (2011, Juli 7). Next week: The Microsoft Surface SDK and other Tools and Resources will be
available to you! Microsoft Surface Blog. Abgerufen Juni 15, 2012, von
http://blogs.msdn.com/b/surface/archive/2011/07/07/new-tools-and-resources-for-surfacepartners-for-the-samsung-sur40-for-microsoft-surface.aspx
Canalys. (2010, Februar 8). Majority of smart phones now have touch screens. Canalys. Abgerufen Juli
13, 2012, von http://www.canalys.com/newsroom/majority-smart-phones-now-have-touchscreens
Cantrell, C. (2009, November 17). Multitouch and gesture support on the Flash Platform | Adobe Developer
Connection.
Abgerufen
Juni
19,
2012,
von
http://www.adobe.com/devnet/flash/articles/multitouch_gestures.html
Cao, X., Massimi, M., & Balakrishnan, R. (2008). Flashlight jigsaw (S. 77). ACM Press.
doi:10.1145/1460563.1460577
Carr, G. (2010, August 16). Multi-touch Support Lands in Maverick « Canonical Blog. Abgerufen von
http://blog.canonical.com/2010/08/16/multi-touch-support-lands-in-maverick/
Clark, R. (2011, Juli 26). Avoiding common HTML5 mistakes | HTML5 Doctor. Abgerufen Juni 25,
2012, von http://html5doctor.com/avoiding-common-html5-mistakes/
97
Anhang
Constanza, E., & Robinson, J. (2003). A Region Adjacency Tree Approach to the Detection and Design
of Fiducials. Gehalten auf der Vision, Video and Graphics (VVG).
Crockford, D. (2008). Java Script: the good parts. Sebastopol, CA [etc.]: O’Reilly.
Danilin, D. (2011, März 27). Multi-Touch Vista. Abgerufen Juli 7, 2012, von
http://multitouchvista.codeplex.com/
Deveria, A. (o. J.). When can I use... Support Tables for HTML5, CSS3, etc. When can I use... Abgerufen
Juni 29, 2012, von http://caniuse.com/
Doherty, R. (2012, Juni 6). Using HTML5′s Fullscreen API for Fun and Profit. SmugMug Sorcery. Abgerufen Juni 26, 2012, von http://sorcery.smugmug.com/2012/06/06/using-html5s-fullscreen-apifor-fun-and-profit/
Douglas, C. (2011, März 15). Multitouch in Ubuntu 11.04 « Code Crunching. Abgerufen Juni 1, 2012,
von http://voices.canonical.com/chase.douglas/2011/03/15/multitouch-in-ubuntu-11-04/
Doyle, J. (2012a, Mai 15). Announcing GreenSock Animation Platform (GSAP) v12, now with tangy
JavaScript flavor! GreenSock. Abgerufen August 5, 2012, von http://www.greensock.com/v12/
Doyle, J. (2012b, Juli 15). com.greensock package - GreenSock JavaScript Documentation. Abgerufen
August 5, 2012, von http://api.greensock.com/js/
Ecma International. (2011, Juni). ECMAScript Language Specification. Abgerufen von http://ecmainternational.org/publications/files/ECMA-ST/Ecma-262.pdf
Eight Media (Hg.). (o. J.). Hammer.js — A javascript library for multi touch gestures. Abgerufen Juli 5,
2012, von http://eightmedia.github.com/hammer.js/
Flanagan, D. (2006). JavaScript : the definitive guide. Sebastopol, CA: O’Reilly.
Fraser, S., Jackson, D., Hyatt, D., Marrin, C., O’Conner, E., Schulze, D., & Gregor, A. (2012, Juni 16).
CSS Transforms. Abgerufen Juni 29, 2012, von http://dev.w3.org/csswg/css3-transforms/
Gallagher, N., Manian, D., Reinl, H. C., Chuan, S., & Bynens, M. (o. J.). HTML5 Boilerplate - A rocksolid default template for HTML5 awesome. Abgerufen Juli 12, 2012, von
http://html5boilerplate.com/
GestureWorks (Hg.). (o. J.). Open Source Multitouch Gesture Library and Illustrations. GestureWorks.
Abgerufen Juli 13, 2012, von http://gestureworks.com/features/open-source-gestures/
Han, J. Y. (2005). Low-Cost Multi-Touch Sensing through Frustrated Total Internal Refl ection. Gehalten auf der UIST’05, Seattle, WA, USA: ACM.
Hickson, I. (2012a, März 29). HTML5. Abgerufen Juni 25, 2012, von http://www.w3.org/TR/2012/WDhtml5-20120329/
Hickson, I. (2012b, März 29). 4.5.11 The figure element — HTML5. Abgerufen Juli 12, 2012, von
http://www.w3.org/TR/html5/the-figure-element.html#the-figure-element
Hickson, I. (2012c, Juni 23). 4.8.11 The canvas element — HTML Standard. Abgerufen Juni 26, 2012,
von http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
Hickson, I. (2012d, Juni 26). The WebSocket API. Abgerufen Juli 7, 2012, von
http://dev.w3.org/html5/websockets/
Hinrichs, U., & Carpendale, S. (2011). Gestures in the wild. Proceedings of the 2011 annual conference on
Human factors in computing systems (S. 3023). ACM Press. doi:10.1145/1978942.1979391
Hitthaler, T. (2012, April 25). MINT Framework for muti-touch gestures | vvvv. Abgerufen Juni 15,
2012, von http://vvvv.org/blog/mint-framework-for-muti-touch-gestures
Ideum (Hg.). (2012, Juni 12). Platform Technical Specifications. Ideum - Exhibit Design + Multitouch
Software
and
Hardware.
Abgerufen
Juli
9,
2012,
von
http://ideum.com/products/multitouch/platform/specifications/
Ideum (Hg.). (o. J.). GestureWorks - Multitouch Framework - Features. GestureWorks: build gesturedriven apps. Abgerufen Juni 15, 2012, von http://gestureworks.com/features/
Jordà, S., Geiger, G., Alonso, M., & Kaltenbrunner, M. (2007). The reacTable (S. 139–146). New York,
NY: ACM Press. doi:10.1145/1226969.1226998
98
Anhang
Jordà, S., Julià, C. F., & Gallardo, D. (2010). Interactive Surfaces and Tangibles. XRDS: Crossroads, The
ACM Magazine for Students - The Future of Interaction, (Volume 16 Issue 4, Summer 2010),
21–28.
jQuery Community Experts. (2010). jQuery cookbook. Beijing; Cambridge: O’Reilly.
jQuery Foundation (Hg.). (o. J.). jQuery: The Write Less, Do More, JavaScript Library. Abgerufen Juni
27, 2012, von http://jquery.com/
Kaltenbrunner, M. (2009). reacTIVision and TUIO (S. 9–16). New York, NY: ACM Press.
doi:10.1145/1731903.1731906
Kammer, D., Keck, M., Freitag, G., & Wacker, M. (2010). Taxonomy and Overview of Multi-touch
Frameworks: Architecture, Scope and Features.
Kammer, D., Wojdziak, J., Keck, M., Groh, R., & Taranko, S. (2010). Towards a formalization of multitouch gestures (S. 49). ACM Press. doi:10.1145/1936652.1936662
Kesteren, A. van, & Çelik, T. (2012, Juni 25). Fullscreen. Abgerufen Juni 26, 2012, von
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Khronos Group (Hg.). (o. J.). OpenGL ES - The Standard for Embedded Accelerated 3D Graphics. Abgerufen Juni 26, 2012, von http://www.khronos.org/opengles/
Kinglsey-Hughes, A. (2012, März 30). The BIG browser benchmark: Chrome 18 vs Opera 11 vs Firefox
11
vs
IE9
vs
Safari
5.
ZDNet.
Abgerufen
Juli
3,
2012,
von
http://www.zdnet.com/blog/hardware/the-big-browser-benchmark-chrome-18-vs-opera-11-vsfirefox-11-vs-ie9-vs-safari-5/19418
Kiriaty, Y. (2009, August). Multitouch-Funktionen in Windows 7. Abgerufen Juni 1, 2012, von
http://msdn.microsoft.com/de-de/magazine/ee336016.aspx
Laborenz, K. (2011). CSS : das umfassende Handbuch. Bonn: Galileo Press.
Laufs, U., Ruff, C., & Zibuschka, J. (2010). MT4j – A Cross-platform Multi-touch Development Framework. Gehalten auf der EICS, Workshop on Engineering Patterns for Multi-Touch Interfaces.
Le Hegaret, P., & Jacobs, I. (2009, Juli 2). Frequently Asked Questions (FAQ) about the future of
XHTML. Abgerufen Juni 25, 2012, von http://www.w3.org/2009/06/xhtml-faq.html
Marrin, C. (2012, Juni 18). WebGL Specification. Abgerufen Juni 26, 2012, von
https://www.khronos.org/registry/webgl/specs/1.0/
McGreggor, D. (2011, März 21). Multitouch/Ginn - Ubuntu Wiki. Abgerufen Juni 1, 2012, von
https://wiki.ubuntu.com/Multitouch/Ginn
Meyer, E. A. (2000, April 14). CSS3 introduction. Abgerufen Juni 28, 2012, von
http://www.w3.org/TR/2000/WD-css3-roadmap-20000414
Meyer, E. A. (2007). CSS: das umfassende Handbuch : [behandelt CSS2 und CSS2.1]. Beijing [u.a.]:
O’Reilly.
Microsoft (Hg.). (o. J.-a). What’s New? Microsoft Surface. Abgerufen Juni 1, 2012, von
http://www.microsoft.com/surface/en/us/whatsnew.aspx
Microsoft (Hg.). (o. J.-b). Kinect für Xbox 360. Xbox.com. Abgerufen Juni 3, 2012, von
http://www.xbox.com/de-DE/Kinect?xr=shellnav
Microsoft (Hg.). (o. J.-c). Experience Things in a Whole New Way. Abgerufen Juni 13, 2012, von
http://www.microsoft.com/surface/en/us/whatissurface.aspx
Microsoft (Hg.). (o. J.-d). Download: Microsoft® Surface® 2.0 SDK and Runtime. Microsoft Download
Center.
Abgerufen
Juni
15,
2012,
von
http://www.microsoft.com/enus/download/details.aspx?id=26716
Microsoft (Hg.). (o. J.-e). Zeiger- und Gestikereignisse. Abgerufen Juli 3, 2012, von
http://msdn.microsoft.com/de-de/library/ie/hh673557(v=vs.85).aspx
Microsoft (Hg.). (o. J.-f). Using Input Simulator. msdn. Abgerufen Juli 7, 2012, von
http://msdn.microsoft.com/en-us/library/ff727911.aspx
Mozilla Foundation (Hg.). (2011, März 22). Mozilla Firefox 4 Release Notes. Abgerufen Juli 3, 2012, von
http://www.mozilla.org/en-US/firefox/4.0/releasenotes/
Nash, G., & Chippindale, C. (2002). European landscapes of rock-art. London; New York: Routledge.
99
Anhang
Nebeling, M., & Norrie, M. C. (2012). jQMultiTouch: Lightweight Toolkit and Development Framework for Multi-touch/Multi-device Web Interfaces. Gehalten auf der ACM EICS’12, Copenhagen, Denmark.
Net Applications (Hg.). (2012, Juni 1). Operating system market share. netmarketshare. Abgerufen Juni
1,
2012,
von
http://www.netmarketshare.com/operating-system-marketshare.aspx?qprid=10&qpcustomd=0&qptimeframe=M&qpsp=160
Norman, D. A. (2010). The way I see it: Natural user interfaces are not natural. interactions, 17(3), 6.
doi:10.1145/1744161.1744163
Open Exhibits (Hg.). (o. J.). What is Open Exhibits? Learn About the Multitouch Software Initiative.
Open Exhibits. Abgerufen Juni 15, 2012, von http://openexhibits.org/about/
Paper.js (Hg.). (o. J.). Paper.js — About. Abgerufen Juni 26, 2012, von http://paperjs.org/about/
Patonnier, J. (2012, Juli 4). transform - MDN. Abgerufen Juli 7, 2012, von
https://developer.mozilla.org/en/CSS/transform
Perrier, J.-Y. (2012, März 27). CSS animations - MDN. Abgerufen Juli 7, 2012, von
https://developer.mozilla.org/en/CSS/CSS_animations
Pettey, C. (2011, April 7). Gartner Says Android to Command Nearly Half of Worldwide Smartphone
Operating System Market by Year-End 2012. Gartner Newsroom. Abgerufen Mai 31, 2012, von
http://www.gartner.com/it/page.jsp?id=1622614
Pilgrim, M. (2010). HTML5 : up and running. Sebastopol, CA: O’Reilly.
PQ Labs (Hg.). (o. J.). Multi-Touch Screen for LCD large screen, plasma TV display. Abgerufen Juni 13,
2012, von http://multi-touch-screen.com/product_plus.html
Processing.js (Hg.). (o. J.). Understanding Rendering Modes in Processing.js. Abgerufen Juni 26, 2012,
von http://processingjs.org/articles/RenderingModes.html
Raab, F. (o. J.). Tuio.js. Abgerufen Juli 7, 2012, von http://fe9lix.github.com/Tuio.js/
Raggett, D., Le Hors, A., & Jacobs, I. (1997, Dezember 18). HTML 4.0 Specification. Abgerufen Juni 25,
2012, von http://www.w3.org/TR/REC-html40-971218/
Raggett, D., Le Hors, A., & Jacobs, I. (1999, Dezember 24). HTML 4.01 Specification. Abgerufen Juni 25,
2012, von http://www.w3.org/TR/1999/REC-html401-19991224/
Read, P., Meyer, M.-P., & Gamma Group. (2000). Restoration of motion picture film. Oxford; Boston:
Butterworth-Heinemann.
Rock Drawings in Valcamonica - UNESCO World Heritage Centre. (o. J.). Abgerufen Juli 10, 2012, von
http://whc.unesco.org/en/list/94
Rossi, J. (2011, September 20). Touch Input for IE10 and Metro style Apps. IEBlog - MSDN Blogs. Abgerufen Juni 4, 2012, von http://blogs.msdn.com/b/ie/archive/2011/09/20/touch-input-for-ie10and-metro-style-apps.aspx
Roth, T. (2008, Juni 9). DSI - Diffused Surface Illumination. Multitouch Dev Blog. Abgerufen von
http://iad.projects.zhdk.ch/multitouch/?p=90
Rusadi, F. I. (o. J.). npTuioClient. GitHub. Abgerufen Juli 7, 2012, von
https://github.com/fajran/npTuioClient
Saffer, D. (2009). Designing gestural interfaces : touchscreens and interactive devices. Sebastopol, CA
[etc.]: O’Reilly.
Samsung (Hg.). (o. J.). Samsung SUR40 with Microsoft® PixelSenseTM. Abgerufen Juli 13, 2012, von
http://m.samsung.com/us/business/commercial-display-solutions/LH40SFWTGC/ZA
Schechter, G. (2012, April 24). Using full-screen mode - MDN. Abgerufen Juni 26, 2012, von
https://developer.mozilla.org/en/DOM/Using_full-screen_mode
Schepers, D., Moon, S., & Brubeck, M. (2011, November 14). Touch Events version 2. Abgerufen Juli 2,
2012, von http://dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html#touch-interface
Schöning, J., Brandl, P., Daiber, F., Echtler, F., Hilliges, O., Hook, J., Löchtefeld, M., u. a. (2008). MultiTouch Surfaces: A Technical Guide.
Seidl, M., Judmaier, P., Baker, F., Chippindale, C., Egger, U., Jax, N., Weis, C., u. a. (2011). Multi-touch
Rocks: Playing with Tangible Virtual Heritage in the Museum - First User Tests. Gehalten auf
100
Anhang
der VAST11: The 12th International Symposium on Virtual Reality, Archaeology and Intelligent Cultural Heritage, Prato, Italien.
Selfhtml (Hg.). (2005, August 22). SELFHTML: Einführung / Internet und WWW / Entstehung des
World Wide Web. Abgerufen Juni 25, 2012, von http://de.selfhtml.org/intro/internet/www.htm
Smith, M., & Sivonen, H. (2011, Juni 23). History - HTML WG Wiki. Abgerufen Juni 25, 2012, von
http://www.w3.org/html/wg/wiki/History
Smus, B. (2011, Mai 2). Multi-Touch for your Desktop Browser. Boris Smus. Abgerufen Juli 7, 2012, von
http://smus.com/multi-touch-browser-patch/
Strukt (Hg.). (2012, April). MINT - Multi-touch Interaction Framework. Abgerufen Juni 15, 2012, von
http://mint.strukt.com/
Tolmasky. (2011, Juni 21). United States Patent: 7966578. Abgerufen Mai 31, 2012, von
http://patft.uspto.gov/netacgi/nphParser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm
&r=1&f=G&l=50&s1=7,966,578.PN.&OS=PN/7,966,578&RS=PN/7,966,578
Tullis, T., & Albert, B. (2008). Measuring the user experience : collecting, analyzing, and presenting usability metrics. Amsterdam [u.a.]: Elsevier/Morgan Kaufmann.
Ubl, M., & Kitamura, E. (2012, März 13). Einführung zu WebSocket: Sockets im Web. HTML5 Rocks.
Abgerufen Juli 7, 2012, von http://www.html5rocks.com/de/tutorials/websockets/basics/
Vetter, R. J. (1994, Oktober). Mosaic and the World-Wide Web. North Dakota State University.
WHATWG (Hg.). (2012, Juni 1). FAQ - WHATWG Wiki. Abgerufen Juli 15, 2012, von
http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F
Whorley, V. (2011). The History of Microsoft Surface. Abgerufen von www.microsoft.com/enus/news/events/ces/docs/2011/SurfaceHistoryFS.xps
Wigdor, D., & Wixon, D. (2011). Brave NUI world : designing natural user interfaces for touch and gesture. Amsterdam: Elsevier : Morgan Kaufmann.
Wright, M., Freed, A., & Momeni, A. (2003). OpenSound Control: State of the Art 2003. Proceedings (S.
153–160). Gehalten auf der Conference on New Interfaces for Musical Expression, Montreal,
Canada.
Wu, M., Chia Shen, Ryall, K., Forlines, C., & Balakrishnan, R. (2006). Gesture Registration, Relaxation,
and
Reuse
for
Multi-Point
Direct-Touch
Surfaces
(S.
185–192).
IEEE.
doi:10.1109/TABLETOP.2006.19
Yeow, C. C. (2005). Firefox secrets. SitePoint Pty. Ltd.
101
Anhang
Anhang B: Abbildungsverzeichnis
Abbildung 1: Drei Phasen einer Geste: Registration, Continuation, Termination......................................... 9
Abbildung 2: Microsoft PixelSense (vormals Surface 2) (Samsung (Hg.), o.J.) ............................................10
Abbildung 3: PQLabs G4 Multi-Touch Overlay (Quelle: multi-touch-screen.com)....................................11
Abbildung 4: Ideum Platform Multi-Touch-Tisch (Quelle: ideum.com)......................................................12
Abbildung 5: Grundsätzlicher Aufbau eines DIY-Multi-Touch-Tisches bei Diffused Surface
Illumination mit Projektor, Kamera und beleuchteter Oberfläche. ...............................................................13
Abbildung 6: FTIR-Setup schematisch dargestellt. ...........................................................................................14
Abbildung 7: DSI-Setup schematisch dargestellt...............................................................................................15
Abbildung 8: RDI-Setup schematisch dargestellt. .............................................................................................15
Abbildung 9: LLP-Setup schematisch dargestellt. .............................................................................................16
Abbildung 10: Marker (Fiducial) für die Erkennung von physischen Objekten aus dem „amoeba“-Set
von reacTIVision (Jordà et al., 2007. Bildquelle: http://reactivision.sourceforge.net) .................................17
Abbildung 11: Schichtenmodell mit Kriterien zur Klassifikation von Multi-Touch-Frameworks
(Kammer, Keck, Freitag, & Wacker, 2010). .......................................................................................................21
Abbildung 12: HTML5 Logo ................................................................................................................................30
Abbildung 13: Koordinatensystem für die Positionierung von Elementen auf einem Canvas zwei
Punkten (0,0) und (4,2) .........................................................................................................................................32
Abbildung 14: Screenshot der Onlineversion des mit Three.js umgesetzten Spiels TriggerRally. .............34
Abbildung 15: Resultat der in Listing 7 definierten Transformationen. Das halbtransparente Bild zeigt
die Ausgangsposition, der rote Punkt markiert den Ursprungspunkt (transform-origin). ........................41
Abbildung 16: Die Beziehung zwischen Berührung und den Objekttypen TouchEvent, TouchList und
Touch. ......................................................................................................................................................................44
Abbildung 17: Pointer vereint Touch, Stift und Mauseingaben (Rossi, 2011). .............................................47
Abbildung 18: Dropdown-Stil bei aktiver (links) und inaktiver (rechts) Touchunterstützung in Google
Chrome 20. (Suchformular: smashingmagazine.com) .....................................................................................49
Abbildung 19: Hummer.js Logo ..........................................................................................................................53
Abbildung 20: Architektur mit vier Schichten einer Webapplikation basierend auf jQMultiTouch
(Nebeling & Norrie, 2012) ....................................................................................................................................55
Abbildung 21: Konfigurationsoberfläche von Multi-Touch Vista..................................................................59
Abbildung 22: Microsoft Surface Simulator.......................................................................................................60
Abbildung 23: Vergrößerung/Verkleinerung der Abstände zwischen fünf Finger-Objekten mit Surface
Input Simulator ......................................................................................................................................................60
Abbildung 24: Adobe Edge mit Eigenschaftenfenster (links), Bibliothek (rechts) und Zeitleiste (unten).
..................................................................................................................................................................................62
Abbildung 25: Detailaufnahme einer Pitoti-Figur ............................................................................................67
Abbildung 26: Detailaufnahme einer Rosa Camuna, eines der am häufigsten verwendeten Symbole. ....67
Abbildung 27: Gesamter Felsen (Seradina 12) mit Interfaceelementen: Spielstationen (weiße Rosa
Camuna auf Felsen), Navigator und Maßstab (links oben bzw. rechts unten), Hilfe-Button und
Hintergrundinfo-Button (rechts oben bzw. links unten). ................................................................................68
Abbildung 28: Rosa Camuna-Symbole dienen als Einstiegspunkt für die Minispiele. ................................68
102
Anhang
Abbildung 29: Startansicht des Puzzle Warrier .................................................................................................71
Abbildung 30: Multi-Touch Webapplikation Kunstenaar mit einer von Besucher/innen hinterlassenen
Nachricht.................................................................................................................................................................72
Abbildung 31: Puzzleteil "Helm" in den zwei Varianten Weiß und Original (verwendet in den
Elementen <img> und <figure> in Listing 14). .................................................................................................75
Abbildung 32: Ablaufdiagramm des Spiels Puzzle ............................................................................................80
Abbildung 33: Test des Prototyps mit vier Personen........................................................................................83
Abbildung 34: Schlagschatten in ActionScript passt sich der Form eines Elements mit Transparenzen an.
..................................................................................................................................................................................93
Abbildung 35: CSS3-Schlagschatten wird auf das gesamte Element angewendet. .......................................93
Anhang C: Tabellenverzeichnis
Tabelle 1: Gebrauchsmuster für die Verwendung von Multi-Touch-Gesten ................................................. 8
Tabelle 2: TouchList-Attribute eines TouchEvent-Objekts (Brubeck et al., 2011). ......................................45
Tabelle 3: Attribute eines Objekts vom Typ Touch (Brubeck et al., 2011). ...................................................45
Tabelle 4: Zusätzliche in Version 2 der Touch Event Spezifikation (Editor’s Draft) vorgesehene Attribute
eines Objekts vom Typ Touch (Schepers et al., 2011). .....................................................................................46
Tabelle 5: Unterschiedliche Bezeichnungen der Touchevents in Mozilla Firefox und W3C Spezifikation.
..................................................................................................................................................................................47
Tabelle 6: MSPointer Events.................................................................................................................................48
Tabelle 7: Die von Adobe Edge erstellte Ordner- und Dateistruktur für exportierte Projekte. Kursive
Namen stellen Dateien dar. ..................................................................................................................................63
Tabelle 8: Desktop-Browser mit Unterstützung für Touchevents ..................................................................85
Tabelle 9: Vergleich der Merkmale von Hummer.js und jQMultiTouch ......................................................87
Anhang D: Listingverzeichnis
Listing 1: Quellcode eines einfachen HTML-Dokuments................................................................................28
Listing 2: Baum-Darstellung des HTML-Dokuments aus Listing 1 ...............................................................29
Listing 3: Beispiel für Chaining in jQuery. .........................................................................................................36
Listing 4: Ein einfaches JSON-Objekt eines Arrays mit zwei Objekten mit jeweils vier Name/WertPaaren. .....................................................................................................................................................................37
Listing 5: Einfache CSS-Regel mit drei Attributen ............................................................................................39
Listing 6: CSS-Regel mit Browser-Präfixe für CSS3-Attribute ........................................................................39
Listing 7: CSS-Regel für die Verschiebung um 100px an der X-Achse sowie Drehung um 20 Grad für
Bilder der Klasse transformed. Der Mittelpunkt der Transformation befindet sich bei X=60% und
Y=100%. (Patonnier, 2012) ..................................................................................................................................40
Listing 8: Beispiel-Code einer CSS-Animation mit zwei Schlüsselbilder (from, to). Ein H1-Element
bewegt sich dabei innerhalb von drei Sekunden um 100 Pixel von rechts nach links. Aus Gründen der
Lesbarkeit wurde auf Browser-Präfixe verzichtet. (Beispielcode nach Perrier, 2012) ..................................42
103
Anhang
Listing 9: Beispielcode bei Verwendung von Hammer.js .................................................................................52
Listing 10: Verwendung von jQMultiTouch um alle Bilder einer Website über Gesten dreh-, skalier- und
verschiebbar zu machen. .......................................................................................................................................55
Listing 11: Beispielcode für einen Eventhandler für eine Swipe-Right-Geste mit jQMultiTouch .............56
Listing 12: Eventhandler bei der Verwendung des Plug-in npTuioClient.....................................................57
Listing 13: Animation eines HTML-Elements mit der GreenSock Animation Platform in JavaScript. Das
zu animierende Element mit der ID "photo" wird per jQuery ausgewählt und die Höhe auf 200px
animiert. Die Animation dauert 1,5 Sekunden und verwendet die Easingfunktion Elastic.easeOut.........64
Listing 14: HTML-Markup für ein Puzzleteil mit Data-Attributen...............................................................75
Listing 15: CSS-Regeln für das Image-Element und die Klasse final des Figure-Elements. ........................77
Listing 16: jQuery Befehl für die Zuweisung von Data-Attributen, die die Werte der Rotation und Größe
beinhalten................................................................................................................................................................79
Listing 17: Aufruf der Methode touchable von jQMultiTouch für alle Puzzleteile ($(elements)) mit
Parameter zur Aktivierung der Gesten Drag, Scale und Rotate. Über die Callback-Funktionen
dragBefore und dragAfter werden Funktionen der Spiellogik zu Beginn bzw. Ende einer Drag-Geste
aufgerufen. ..............................................................................................................................................................79
Listing 18: Berechnung der neuen Werte für left und top (x und y) eines Elements bei einer Drag-Geste
..................................................................................................................................................................................80
Listing 19: Zuweisung der aktuellen CSS-Rotation des Elements oder des Werts 0, wenn kein
Rotationswert vorhanden ist. ...............................................................................................................................81
Listing 20: Limitierung der Scale-Werte auf Maximal- und Minimalwerte. .................................................82
Listing 21: Animation des Werts rotation der rechten Hand. Die Animation dauert 0.5 Sekunden und
verwendet eine Easingfunktion. Im Anschluss wird die Animation der Zeitleiste (tl) hinzugefügt. .........83
104

Multi-Touch im Browser eines Tabletop-PCs - Projects

Transcrição

Documentos relacionados

ILIAS - E-Learning-Lernumgebung der FH Köln F01 Fakultät für

Installierte Software an den öffentlich zugänglichen Rechnern in der

Vorgehensweise bei Zugangsproblemen zu PhytoPRE

Embedded Control bequem via Ethernet realisiert

Impuls 1: Hip-Hop

Übersicht Online-Verfahren - Bank für Kirche und Diakonie

Pandoras Box Widget Designer 3.5

madmoo

mobiles web - WAN-IFRA

pdf_klein