Fakult¨
at f¨ur
Ingenieurwissenschaften
und Informatik
Institut f¨
ur Datenbanken und
Informationssysteme
2014
Multi-Touch Gestures for Process
Modeling
Masterarbeit an der Universit¨
at Ulm
Vorgelegt von:
Adam Just
Gutachter:
Prof. Dr. Manfred Reichert
Prof. Dr. Peter Dadam
Betreuer:
Dipl.-Inf. Jens Kolb
Fassung 25. Februar 2014
c
2014 Adam Just
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike
2.0 License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-sa/2.0/de/ or send a letter to Creative
Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
Satz: PDF-L
A
T
EX 2ε
Abstract
Mithilfe sogenannter Prozesssichten, kann die Komplexit¨
at von Prozessmodellen
reduziert werden. Die Erstellung sowie Bearbeitung von Prozesssichten wird durch
das proView-Framework unterst¨
utzt. Dieses Framework kann aufgrund seiner web-
basierten Bedienoberfl¨
ache auch auf mobilen Ger¨
aten, wie Smartphones oder
Tablets, eingesetzt werden. Da mobile Ger¨
ate jedoch heutzutage ausschließlich
mittels Fingern bedient werden, ist eine Anpassung des Desktop-orientierten Be-
dienkonzepts von proView notwendig. In dieser Arbeit werden hierzu Multi-Touch-
Gesten ermittelt, implementiert und mit den entsprechenden Modellierungsfunk-
tionen von proView verkn¨
upft, um eine Gesten-basierte Prozessmodellierung auf
Basis von Prozesssichten zu erm¨
oglichen. Die Validierung der Implementierung
wird mithilfe eines abschließenden Experiments durchgef¨
uhrt.
iii
iv
Inhaltsverzeichnis
1 Einleitung 1
2 Grundlagen 3
2.1 Varianten von Bedienkonzepten . . . . . . . . . . . . . . . . . . . . . 3
2.2 Prozessmodell .............................. 4
2.2.1 BPMN-Prozesselemente . . . . . . . . . . . . . . . . . . . . 5
2.3 proView-Framework ........................... 8
2.4 Vaadin-Framework............................ 10
3 Analyse der Problemstellung 13
3.1 Ermittlung von Multi-Touch-Gesten . . . . . . . . . . . . . . . . . . . 13
3.1.1 Benutzerdefiniertes Gesten-Set . . . . . . . . . . . . . . . . . 13
3.1.2 Symbolische Gesten interaktiver Systeme . . . . . . . . . . . 15
3.1.3 Multi-Touch-Gesten f¨
ur die Prozessmodellierung . . . . . . . 15
3.2 Abbildung von Multi-Touch-Gesten auf Prozessmodellierungsfunk-
tionen ................................... 17
4 Analyse von Multi-Touch-Implementierungen 29
4.1 VaadinTouchKit ............................. 29
4.2 Multi-Touch-Bibliotheken f¨
ur JavaScript . . . . . . . . . . . . . . . . . 30
4.3 Fazit.................................... 32
5 Entwicklung eines Multi-Touch-Add-ons 33
5.1 Aufbau des TouchPanel-Add-ons . . . . . . . . . . . . . . . . . . . . 33
5.2 Clientseitiges TouchPanel-Widget . . . . . . . . . . . . . . . . . . . . 35
5.2.1 Behandlung von TouchMove-Events . . . . . . . . . . . . . . 36
5.2.2 Symbolische Gesten . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.3 Tap-Geste............................. 38
5.2.4 Double-Tap-Geste . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.5 Pan-Geste ............................ 39
5.2.6 Pinch-Geste ........................... 41
5.2.7 Hold-Geste............................ 42
5.3 Serverseitige TouchPanel-Komponente . . . . . . . . . . . . . . . . 42
v
Inhaltsverzeichnis
5.3.1 $1 Gesture Recognizer . . . . . . . . . . . . . . . . . . . . . 42
5.3.2 Gesten-Listener und -Events . . . . . . . . . . . . . . . . . . 47
5.4 Emulation von Touch-Events . . . . . . . . . . . . . . . . . . . . . . 49
6 Erweiterung des proView-Frameworks 51
6.1 Integration des TouchPanel-Add-ons . . . . . . . . . . . . . . . . . . 51
6.2 SymbolischeGesten........................... 53
6.2.1 L¨
oschen-Symbol......................... 54
6.2.2 Rechteck-Symbol . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Rechteck-Symbol mit Diagonale . . . . . . . . . . . . . . . . 55
6.2.4 Strich-Symbol .......................... 56
6.2.5 Pfeil-Symbol ........................... 57
6.2.6 Halbes Rechteck-Symbol . . . . . . . . . . . . . . . . . . . . 58
6.2.7 Zickzack-Symbol . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.8 Fragezeichen-Symbol . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Tap-Geste................................. 59
6.4 Double-Tap-Geste ............................ 60
6.5 Pinch-Geste................................ 60
6.6 Hold-Geste ................................ 61
7 Evaluation der Implementierung 63
7.1 Vorbereitung und Durchf¨
uhrung der experimentellen Untersuchung . 64
7.1.1 Teil 1: Eigene Gesten ausdenken . . . . . . . . . . . . . . . . 66
7.1.2 Teil2:Tutorial........................... 67
7.1.3 Teil 3: Implementierte Gesten anwenden . . . . . . . . . . . 67
7.2 Auswertung der experimentellen Untersuchung . . . . . . . . . . . . 69
7.2.1 Detaillierte Auswertung der einzelnen Aufgaben . . . . . . . 71
7.3 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . 93
8 Zusammenfassung und Ausblick 97
A Anhang 99
A.1 Benutzerdefiniertes Gesten-Set . . . . . . . . . . . . . . . . . . . . . 99
A.2 Prozessmodell ..............................100
A.3 Ergebnisse der experimentellen Untersuchung . . . . . . . . . . . . 101
A.4 $1 Gesture Recognizer . . . . . . . . . . . . . . . . . . . . . . . . . 109
Literaturverzeichnis 113
vi
1 Einleitung
Die Komplexit¨
at von Prozessmodellen kann durch sogenannte Prozesssichten re-
duziert werden. Benutzer bekommen mithilfe einer Prozesssicht nur den Teil eines
Prozesses zu sehen, der f¨
ur sie relevant ist. Gleichzeitig k¨
onnen Ver¨
anderungen
an einer Prozesssicht vorgenommen werden, die im komplexen Prozessmodell
¨
ubernommen werden. Diese Technologie ist wesentlicher Bestandteil des proView-
Frameworks1, das an der Universit¨
at Ulm entwickelt wird. Es handelt sich hierbei
um eine webbasierte Anwendung, die in Browsern unterschiedlicher Ger¨
ate aus-
gef¨
uhrt werden kann. Dies gilt auch f¨
ur mobile, internetf¨
ahige Ger¨
ate, wie Smart-
phones oder Tablets, die sich derzeit einer steigenden Beliebtheit erfreuen. Das
derzeitige Problem von proView ist jedoch, dass es f¨
ur den Einsatz auf Desktop-
Computern optimiert ist und daher eine Men¨
u-basierte Interaktion mittels Maus
und Tastatur erzwingt [12]. Da mobile Ger¨
ate heutzutage ausschließlich mit den
Fingern bedient werden und eine ¨
uberm¨
aßige Verwendung von Men¨
us f¨
ur kleine
Bildschirme ungeeignet ist, muss das proView-Framework an mobile Ger¨
ate ange-
passt werden.
Ziel dieser Arbeit ist es das proView-Framework um eine Gesten-basierte Pro-
zessmodellierung zu erweitern, sowie die Verwendung von Men¨
us zu reduzieren
und eine intuitive Bedienung von proView mittels Finger auf mobilen Ger¨
aten zu
f¨
ordern. Hierzu sollen zun¨
achst verschiedene Multi-Touch-Gesten ermittelt wer-
den, die zu den von proView angebotenen Modellierungsfunktionen passen. Nach
einer sorgf¨
altigen Analyse der Umsetzungsm¨
oglichkeiten sollen die Gesten im-
plementiert und in das proView-Framework integriert bzw. mit den bestehenden
Modellierungsfunktionen verkn¨
upft werden. Abschließend soll eine experimentelle
Untersuchung durchgef¨
uhrt werden, um die implementierten Gesten zu validieren.
Kapitel 2 gibt einen kurzen Einblick in die Grundlagen, die f¨
ur das Verst¨
andnis
dieser Arbeit erforderlich sind. Eine ausf¨
uhrliche Analyse der Problemstellung the-
matisiert Kapitel 3, das unter anderem eine Ermittlung von Multi-Touch-Gesten
enth¨
alt. Das darauffolgende Kapitel 4 besch¨
aftigt sich mit unterschiedlichen Multi-
Touch-Implementierungen f¨
ur die ermittelten Gesten. Kapitel 5 beschreibt das in
dieser Arbeit entwickelte Vaadin-Add-on TouchPanel. Dieses Add-on ist f¨
ur die
1http://www.dbis.info/proView
1
1 Einleitung
in Kapitel 6 beschriebene Erweiterung des proView-Frameworks notwendig. Eine
Evaluation in Form einer experimentellen Untersuchung der finalen Implementie-
rung ist Gegenstand von Kapitel 7. Das abschließende Kapitel 8 beinhaltet eine
Zusammenfassung dieser Arbeit sowie einen kurzen Ausblick auf zuk¨
unftige Ar-
beiten.
2
2 Grundlagen
Dieses Kapitel beschreibt grundlegende Aspekte, die f¨
ur ein besseres Verst¨
and-
nis dieser Arbeit wichtig sind. Abschnitt 2.1 stellt verschiedene Bedienkonzepte
vor, die auf Multi-Touch-Ger¨
aten eingesetzt werden k¨
onnen. Der anschließende
Abschnitt 2.2 beinhaltet eine kurze Einf¨
uhrung in die Prozessmodellierung, indem
die f¨
ur diese Arbeit wichtigsten Prozesselemente vorgestellt werden. Das proView-
Framework [13, 14] und das f¨
ur dessen Implementierung eingesetzte Framework
Vaadin [7] werden in Abschnitt 2.3 und 2.4 n¨
aher erl¨
autert.
2.1 Varianten von Bedienkonzepten
Die Bedienung eines Multi-Touch-Ger¨
ates kann je nach Benutzeroberfl¨
ache der
Anwendung, die darauf ausgef¨
uhrt wird, unterschiedlich aussehen. Bietet die An-
wendung eine gew¨
ohnliche Men¨
uleiste im oberen Bereich des Bildschirms an,
kann durch eine einfache Tippgeste ein Men¨
upunkt ausgew¨
ahlt werden, worauf-
hin sich dieser aufgeklappt und dem Nutzer hierarchisch weitere Auswahlm¨
oglich-
keiten pr¨
asentiert. Beispielsweise ist bei vielen Anwendungen das Dateimen¨
u vor-
handen, das bei einem Antippen oder Anklicken dem Nutzer unter anderem die
M¨
oglichkeit bietet, die Anwendung zu beenden oder den aktuellen Programmzu-
stand abzuspeichern. Bei diesem Verfahren handelt es sich um eine sogenann-
te Men¨
u-basierte Interaktion mit dem System, die den meisten Computernutzern
durchaus bekannt ist. Zu beachten ist, dass die Eintr¨
age eines Men¨
us eine Kan-
tenl¨
ange von mindesten 11,52 mm betragen sollten, um bei Eingaben per Finger
eine Trefferwahrscheinlichkeit von 95% zu erzielen [31].
Auch ein Kontextmen¨
u z¨
ahlt zum Bereich Men¨
u-basierte Interaktion. Bei diesem
Verfahren klickt der Nutzer mit der rechten Maustaste typischerweise auf ein Be-
dienelement auf der Benutzeroberfl¨
ache und es ¨
offnet sich das Kontextmen¨
u mit
verschiedenen Interaktionsfunktionen. Bei der Bedienung einer solchen Anwen-
dung mit Fingern kann je nach Programmierung der Anwendung das Kontext-
men¨
u beispielsweise durch Antippen an einer bestimmten Stelle der Bedienober-
fl¨
ache ge¨
offnet werden. Abgesehen davon, dass Men¨
u-basierte Interaktionen sehr
3
2 Grundlagen
bekannt sind, haben sie den Vorteil, dass viele Funktionen der Anwendung sofort
ersichtlich sind. Dies ist n¨
amlich bei einer rein Gesten-basierten Interaktion nicht
der Fall [11].
Bei der Gesten-basierten Interaktion weiß der Nutzer meistens erst nach einer
Studie der Bedienungsanleitung oder einem Tutorial, mit welcher Geste er welche
Funktion ausl¨
osen kann. Je mehr Funktionen eine Anwendung besitzt, desto mehr
Gesten muss sich ein Nutzer merken, um mit der Anwendung problemlos interagie-
ren zu k¨
onnen. Bei dieser Interaktionsart unterscheidet man weiter zwischen phy-
sikalischen und symbolischen Gesten [31]. Bei der physikalischen Geste werden
Bedienelemente direkt manipuliert. Beispielsweise kann ein Element ausgew¨
ahlt
werden, und w¨
ahrend sich der Finger noch darauf befindet, an eine andere Positi-
on verschoben werden. Diese Art der Ber¨
uhrung gibt einem Nutzer ein Gef¨
uhl der
direkten Manipulation von Bildschirmelementen; im Gegensatz zu einer Maus oder
Tastatur [23]. Bei symbolischen Gesten zeichnet der Nutzer verschiedene Symbole
bzw. Metaphern auf den Bildschirm, die die Anwendung erkennt und daraus eine
Funktion ableitet. Zeichnet der Nutzer beispielsweise ein Fragezeichen auf dem
Bildschirm, so k¨
onnte die Hilfefunktion aufgerufen werden. An diesem Beispiel er-
kennt man sofort, dass es in manchen F¨
allen schwierig sein kann, ein geeignetes
Symbol zu definieren, das sich ein Nutzer zudem auch merken kann.
Bei der Gesten-basierten Interaktion haben sich vor allem durch den Einsatz von
mobilen Ger¨
aten, verschiedene Gesten f¨
ur bestimmte Funktionen etabliert und
sind mittlerweile bei den meisten Nutzern zur Gewohnheit geworden. Ein Beispiel
hierf¨
ur ist die Zoom-Funktion, die mittels einer sogenannten Pinch-Geste ausgel¨
ost
wird. Der Nutzer ber¨
uhrt bei dieser Geste den Bildschirm mit zwei Fingern, die
sich entweder aufeinander zubewegen (d.h. vergr¨
oßern) oder voneinander weg-
bewegen (d.h. verkleinern). Nach Ausf¨
uhrung dieser bekannten Geste k¨
onnte sich
ein Kontextmen¨
u¨
offnen, das weitere Funktionen zur Auswahl anbietet. In einem
solchen Fall w¨
urde es sich um eine hybride Interaktion handeln, das heißt eine
Kombination aus Men¨
u- und Gesten-basierter Interaktion.
2.2 Prozessmodell
Die Prozessabl¨
aufe eines Unternehmens k¨
onnen mithilfe von Prozessmodellen
textuell [15], grafisch [6] oder formal [1] dargestellt werden. Diese Prozessmodelle
unterst¨
utzen unter anderem die Analyse von Gesch¨
aftsprozessen sowie die Kom-
munikation ¨
uber Gesch¨
aftsprozesse. Des Weiteren k¨
onnen sie aufgrund von Op-
timierungsmaßnahmen zu einer Steigerung der Produktivit¨
at und des Umsatzes
4
2.2 Prozessmodell
eines Unternehmens beitragen.
Es existiert eine Vielzahl von Standards, die f¨
ur Notationen von Prozessmodellen
verwendet werden k¨
onnen. Eines davon ist die Business Process Model and No-
tation (BPMN)-Notation [19] mit der sich Prozessmodelle grafisch darstellen, mo-
dellieren und dokumentieren lassen. Die BPMN-Notation ist wichtiger Bestandteil
von proView und daher werden die wichtigsten Elemente dieser Prozessnotation
in Abschnitt 2.2.1 ausf¨
uhrlicher beschrieben.
Der gesamte Gesch¨
aftsprozess wird durch ein Central Process Model (CPM) re-
pr¨
asentiert. Allerdings ist nicht immer f¨
ur jeden Benutzer das gesamte Prozessmo-
dell von Bedeutung. F¨
ur einen Manager sind zum Beispiel bestimmte Aktivit¨
aten
wichtiger als f¨
ur einen ”gew¨
ohnlichen“ Bearbeiter. Daher besteht die M¨
oglichkeit
aus einem komplexen Prozessmodell sogenannte Prozesssichten (engl. Process
Views) zu abstrahieren, die den einzelnen Benutzern zugeordnet werden. Pro-
zesssichten beinhalten dabei nur die wichtigsten Prozesselemente, die f¨
ur einen
Benutzer relevant sind. Alle anderen Prozesselemente sind nicht sichtbar. Dies
verbessert zus¨
atzlich die Pflege sowie Erweiterbarkeit eines Prozessmodells. Die
von den Benutzern durchgef¨
uhrten ¨
Anderungen an den Prozesssichten werden
an das CPM weitergeleitet und auch in anderen Prozesssichten ¨
ubernommen, die
dieselben Prozesselemente beinhalten.
2.2.1 BPMN-Prozesselemente
Die BPMN-Notation [19] ist sehr umfangreich, aus diesem Grund sind im Folgen-
den nur die f¨
ur diese Arbeit wichtigsten Prozesselemente beschrieben, die auch
von proView unterst¨
utzt werden.
Start- und End-Ereignis Start- und End-Ereignis (engl. Start/End Event) werden
in einem Prozessmodell als Kreis mit unterschiedlicher Linienst¨
arke repr¨
asen-
tiert. Sie signalisieren den Anfang bzw. das Ende eines Prozesses und wer-
den entsprechend im Prozessmodell positioniert (siehe Abb. 2.1).
End-EreignisStart-Ereignis
Abbildung 2.1: Start- und End-Ereignis.
Aktivit¨
at Eine Aktivit¨
at (engl. Activity) wird als Rechteck mit abgerundeten Ecken
repr¨
asentiert. Sie symbolisiert eine atomare Aufgabe (engl. Task) oder ein
5
2 Grundlagen
Subprozess (engl. Subprocess) und verweist auf ein weiteres Prozessmo-
dell, das das Verhalten der Subprozess-Aktivit¨
at n¨
aher beschreibt. Im kol-
labierten Zustand wird ein Subprozess mit einem Plus-Symbol am unteren
Rand des Elements kenntlich gemacht. Im expandierten Zustand durch ein
Minus-Symbol (siehe Abb. 2.2).
A E
C
B
D
XOR-Split XOR-Join
Abbildung 2.2: Aktivit¨
aten (A, C, D) und Subprozesse (B, E).
Verzweigungsblock Ein Verzweigungsblock (engl. Branching Block) wird durch
zwei Raute-¨
ahnliche Symbole repr¨
asentiert. Innerhalb der Symbole kann sich
ein weiteres X- oder Plus-Symbol befinden (siehe Abb. 2.3). In diesen bei-
den F¨
allen w¨
urde es sich um ein XOR- bzw. AND-Verzweigungsblock han-
deln, die von proView unterst¨
utzt werden. Der XOR-Verzweigungsblock wird
verwendet, um in einem Prozess alternative Prozessfl¨
usse zu schaffen, von
denen aufgrund einer bestimmten Bedingung nur einer ausgef¨
uhrt wird. Die
Parameter f¨
ur diese Bedingung werden aus einem Datenelement ausgele-
sen. Bei einem AND-Verzweigungsblock werden zwei oder mehrere Pro-
zessfl¨
usse parallel ausgef¨
uhrt. Ein AND-Split-Verzweigungsknoten sorgt am
Anfang des Verzweigungsblocks f¨
ur die Aufsplittung des Prozessflusses und
ein AND-Join-Verzweigungsknoten am Ende des Verzweigungsblocks f¨
ur die
Zusammenf¨
uhrung. Bei einem XOR-Verzweigungsblock handelt es sich da-
bei immer um die Verzweigungsknoten XOR-Split und XOR-Join.
Die Prozessmodelle in proView besitzen generell eine Blockstruktur, wodurch
die verschiedenen Bl¨
ocke geschachtelt und disjunkt auftreten. ¨
Uberlappun-
gen sind allerdings nicht m¨
oglich.
Schleife Einzelne Prozessschritte bzw. Aktivit¨
aten k¨
onnen wiederholt werden, in-
dem der Prozessfluss mit den XOR-Verzweigungsknoten als Schleife (engl.
Loop) zur¨
uckgeleitet wird (siehe Abb. 2.4). Der XOR-Split-Verzweigungskno-
ten besitzt hierbei eine Abbruchbedingung, die bei Nichterf¨
ullung eine Weiter-
leitung zum XOR-Join-Verzweigungsknoten einleitet. Innerhalb des Schlei-
6
2.2 Prozessmodell
A
B
C
AND-Split AND-Join D
E
XOR-Split XOR-Join
x > 0 ?
[{x > 0}]
[{x 0}]
Abbildung 2.3: AND- und XOR-Verzweigungsblock.
fenblocks wird der Wert eines Datenelements modifiziert, das zur Pr¨
ufung der
Abbruchbedingung vom XOR-Split-Verzweigungsknoten ausgelesen wird.
A B
XOR-Join
Loop Start
x
INTEGER
i
Loop End
XOR-Split
Abbildung 2.4: Eine Schleife.
Datenelement Ein Datenelement (engl. Data Element) wird durch eine Seite mit
abgeknickter, oberer Ecke repr¨
asentiert (siehe Abb. 2.5). Es hat keinen di-
rekten Einfluss auf den Kontrollfluss, sondern repr¨
asentiert bestimmte Da-
ten bzw. Variablen, die w¨
ahrend eines Prozesses relevant sind. Aktivit¨
aten
k¨
onnen Datenelemente auslesen oder beschreiben. Ein Datenelement hat
einen definierten Datentyp, wie zum Beispiel String, Integer, Float oder Boo-
lean.
repeat
BOOLEAN
b
x
INTEGER
i
Name
STRING
s
y
FLOAT
f
date
DATE
d
uri
URI
u
Abbildung 2.5: Datenelemente und deren Typen.
Sequenzflusskante Eine Sequenzflusskante (engl. Sequence Flow Edge) wird
durch einen gew¨
ohnlichen, durchgehenden Pfeil repr¨
asentiert (siehe Abb.
2.6). Sie verbindet Ereignisse, Aktivit¨
aten und Verzweigungsbl¨
ocke miteinan-
der und bestimmt deren Ausf¨
uhrungsreihenfolge.
Synchronisationskante Eine Synchronisationskante (engl. Synchronization Ed-
7
2 Grundlagen
C
D
EB
Synchronisationskante
Sequenzflusskante
LesekanteSchreibkante
A
x
INTEGER
i
Abbildung 2.6: Sequenzfluss-, Synchronisations-, Lese- und Schreibkanten.
ge) wird durch einen gestrichelten Pfeil repr¨
asentiert und dient dazu, Abh¨
an-
gigkeiten zwischen Aktivit¨
aten innerhalb von AND-Verzweigungsbl¨
ocken zu
definieren (siehe Abb. 2.6). Eine Aktivit¨
at D wird beispielsweise erst nach
Beendigung von Aktivit¨
at C, die auf einem anderen Zweig liegt, ausgef¨
uhrt.
Lese- und Schreibkanten Lese- und Schreibkanten (engl. Read/Write Edge) wer-
den wie Synchronisationskanten durch einen gestrichelten Pfeil repr¨
asentiert
(siehe Abb. 2.6). Ihre Aufgabe ist es allerdings Lese- und Schreiboperatio-
nen zwischen Datenelementen und Aktivit¨
aten bzw. Verzweigungsknoten zu
symbolisieren. Wird beispielsweise ein Datenelement von einer Aktivit¨
at aus-
gelesen, kennzeichnet eine Lesekante vom Datenelement zur Aktivit¨
at diese
Leseoperation. Schreiboperationen werden durch eine Schreibkante von Ak-
tivit¨
at bzw. Verzweigungsknoten zu Datenelement symbolisiert.
2.3 proView-Framework
Das proView-Framework1ist ein Projekt des Instituts f¨
ur Datenbanken und Infor-
mationssysteme an der Universit¨
at Ulm. Es bietet im Wesentlichen die M¨
oglichkeit,
aus komplexen Prozessmodellen personalisierte Prozesssichten zu abstrahieren,
die von bestimmten Benutzern bzw. Rollen bearbeitet werden k¨
onnen [12, 13].
Als Web-Anwendung nutzt proView eine Client-Server-Architektur (siehe Abb. 2.7)
[12]. Der proView-Server ist hierbei f¨
ur die gesamte Programmlogik, sowie Ver-
waltung der einzelnen Prozessmodelle und -sichten verantwortlich. Der proView-
Client ¨
ubernimmt die Visualisierung von Prozessmodellen, die entweder als For-
mular, Text [15] oder in den beiden Notationen BPMN und ADEPT [3] dargestellt
werden k¨
onnen. Die webbasierte Benutzeroberfl¨
ache von proView ist mithilfe des
1http://www.dbis.info/proView
8
2.3 proView-Framework
Vaadin-Frameworks entwickelt worden [2], das in Abschnitt 2.4 genauer beschrie-
ben ist. Dies hat den Vorteil, dass proView mit den meisten aktuellen Browsern
kompatibel ist. In dieser Arbeit wird die Benutzeroberfl¨
ache erweitert, damit Multi-
Touch-Ereignisse, die f¨
ur eine Gesten-basierte Prozessmodellierung notwendig
sind, entgegen genommen werden k¨
onnen.
proView-Server proView-Client GUI
Multi-Touch
Erweiterung
REST
visualisieren
ändern
berühren
Abbildung 2.7: proView-Framework mit Multi-Touch-Erweiterung.
In Abbildung 2.8 ist die Benutzeroberfl¨
ache von proView mit den wesentlichen Be-
standteilen zu sehen.
Men¨uleiste (1) Die Men¨
uleiste bietet zus¨
atzliche Einstellm¨
oglichkeiten an. Zum
Beispiel ist ein Wechsel zwischen den unterschiedlichen Notationen, wie
BPMN oder ADEPT, durchf¨
uhrbar. Es stehen zwei unterschiedliche Layout-
varianten (Normal und Simulated) zur Verf¨
ugung, um zwischen einem Block-
oder CPM-orientierten Layout zu wechseln [2].
TemplateTree (2) Der TemplateTree stellt alle zur Verf¨
ugung stehenden Prozess-
modelle (d.h. CPM oder Prozesssichten) in einer baumartigen Struktur dar.
¨
Uber den TemplateTree k¨
onnen auch neue Prozesssichten erstellt oder vor-
handene gel¨
oscht werden.
Bearbeitungsbereich (3) Das im TemplateTree ausgew¨
ahlte Prozessmodell wird
in einem Bearbeitungs- und Visualisierungsbereich angezeigt.
Kontextmen¨u (4) Die Modellierungsfunktionen von proView k¨
onnen mithilfe eines
Kontextmen¨
us ausgef¨
uhrt werden.
Properties-Panel (5) Wird im Bearbeitungsbereich ein Prozesselement ausge-
w¨
ahlt, werden weitere Informationen zu diesem Element, wie beispielsweise
die ID, im Properties-Panel angezeigt.
Create Operations-Panel (6) Mit dem Create Operations-Panel werden alle Ope-
rationen aufgelistet, die in Bezug auf das angezeigte Prozessmodell aus-
9
2 Grundlagen
gef¨
uhrt worden sind.
Abbildung 2.8: Webbasierte Benutzeroberfl¨
ache von proView.
2.4 Vaadin-Framework
Vaadin ist ein Framework, das der Entwicklung von umfangreichen Benutzerschnitt-
stellen f¨
ur Web-Anwendungen dient [7]. Eine gew¨
ohnliche Web-Anwendung be-
steht bekanntlich aus einer Client- und einer Serverseite f¨
ur deren Entwicklung
Kenntnisse in unterschiedlichen Web-Technologien wie HTML oder JavaScript not-
wendig sind. Beide Seiten werden in Vaadin haupts¨
achlich mit der Programmier-
sprache Java entwickelt, sodass sich der Entwickler auf die wichtigere Programm-
logik einer Web-Anwendung konzentrieren kann. Zus¨
atzlich wird eine Vielzahl an
vordefinierten UI-Komponenten angeboten, die auch in Java programmiert sind.
Eine UI-Komponente, wie beispielsweise ein Button, besteht hierbei aus einer ser-
verseitigen und einer clientseitigen Komponente, auch Widget genannt.
Das clientseitige Framework von Vaadin basiert auf dem Google Web Toolkit (GWT)
und nutzt eine erweiterte Version des GWT-Compilers, um den Java-Code ei-
nes Widgets vor der Ausf¨
uhrung in JavaScript umzuwandeln. Die serverseitige
Komponente wird als Java-Servlet in einem Anwendungsserver wie Apache Tom-
cat ausgef¨
uhrt. Die Nutzung von GWT hat zus¨
atzlich den Vorteil, dass die Web-
Anwendung dadurch mit den meisten aktuellen Browsern kompatibel ist.
10
2.4 Vaadin-Framework
Clientseitige Widgets sind insbesondere f¨
ur die Visualisierung der Benutzerschnitt-
stelle zust¨
andig, sowie f¨
ur die Weiterleitung von Benutzereingaben an den Server.
Die Durchf¨
uhrung dieser Kommunikation zwischen Client und Server wird eben-
falls vom Vaadin-Framework ¨
ubernommen, das hierf¨
ur die Web-Technologie AJAX
verwendet.
Das Erscheinungsbild der Benutzerschnittstelle bzw. der einzelnen UI-Komponen-
ten kann durch sogenannte CSS-basierte Themes beeinflusst werden. Der Ent-
wickler hat hier die M¨
oglichkeit eigene Themes zu definieren oder Standard The-
mes von Vaadin zu verwenden.
Die Auswahl an vorgefertigten UI-Komponenten kann durch weitere Komponenten,
die als Add-ons auf der Vaadin-Webseite zu finden sind, erg¨
anzt werden. Dar¨
uber
hinaus ist es ebenfalls m¨
oglich, eigene Add-ons zu entwickeln und in eine Web-
Anwendung zu integrieren.
11
2 Grundlagen
12
3 Analyse der Problemstellung
Bevor mit der eigentlichen Implementierung einer Multi-Touch-Erweiterung f¨
ur das
proView-Framework begonnen werden kann, wird in diesem Kapitel analysiert,
welche Gesten sich am besten f¨
ur diese Erweiterung eignen. Abschnitt 3.1 ermit-
telt zun¨
achst einige Gesten, die eventuell zum Einsatz kommen k¨
onnten. Abschnitt
3.2 besch¨
aftigt sich anschließend mit der Zuordnung der Gesten zu passenden
Modellierungsfunktionen in proView.
3.1 Ermittlung von Multi-Touch-Gesten
Die folgenden Abschnitte stellen drei Arbeiten vor, die als Ergebnis jeweils ein
Gesten-Set f¨
ur den Einsatz in Multi-Touch-Anwendungen pr¨
asentieren. Abschnitt
3.1.1 und 3.1.3 beinhalten Gesten-Sets, die zum Zwecke einer besseren Multi-
Touch-Bedienung experimentell ermittelt worden sind. Im zweiten Fall handelt es
sich um ein Experiment, das im direkten Zusammenhang mit Prozessmodellierung
steht. Welche Gesten sich bereits in bestehenden, interaktiven Systemen etabliert
haben, ist Thema der Arbeit von Abschnitt 3.1.2.
3.1.1 Benutzerdefiniertes Gesten-Set
F¨
ur gew¨
ohnlich entscheiden Softwaredesigner, welche Funktionen einer Anwen-
dung mit welchen Gesten ausgel¨
ost werden. Dies hat allerdings den Nachteil,
dass Nutzer mit sehr wenig Technikkenntnissen Probleme bei der Bedienung ha-
ben, da sie eventuell eine andere Geste bevorzugen w¨
urden. Welche Geste f¨
ur
welche Funktion von den Nutzern bevorzugt wird, ermittelt ein Experiment in [31],
um darauf aufbauend ein benutzerdefiniertes Gesten-Set zu pr¨
asentieren. Dieses
Gesten-Set bietet Softwaredesignern die M¨
oglichkeit, bessere Gesten f¨
ur ihre ei-
genen Implementierungen zu entwickeln.
Den einzelnen Testpersonen dieses Experiments werden auf einem Touch-Table
von Microsoft verschiedene Grundobjekte gezeigt. Die Software des Touch-Tables
13
3 Analyse der Problemstellung
f¨
uhrt automatisierte Aktionen aus, die die gezeigten Grundobjekte f¨
ur die Testper-
sonen sichtbar ver¨
andern. Zum Beispiel zeigt die Software zun¨
achst ein Rechteck
an und f¨
uhrt anschließend die Aktion zum Vergr¨
oßern des Rechtecks aus. Jede
Testperson muss sich diese Aktionen anschauen und daraufhin versuchen diesel-
be Aktion durch eigene Gesten herbeizuf¨
uhren (siehe Abb. 3.1). Wie viele Finger
bzw. H¨
ande sie daf¨
ur benutzt, entscheidet die Testperson selbst. Gleiches gilt f¨
ur
die Verwendung einer symbolischen oder einer physikalischen Geste.
User-Defined Gestures for Surface Computing
Jacob O. Wobbrock
The Information School
DUB Group
University of Washington
Seattle, WA 98195 USA
Meredith Ringel Morris, Andrew D. Wilson
Microsoft Research
One Microsoft Way
Redmond, WA 98052 USA
{merrie, awilson}@microsoft.com
ABSTRACT
Many surface computing prototypes have employed
gestures created by system designers. Although such
gestures are appropriate for early investigations, they are
not necessarily reflective of user behavior. We present an
approach to designing tabletop gestures that relies on
eliciting gestures from non-technical users by first
portraying the effect of a gesture, and then asking users to
perform its cause. In all, 1080 gestures from 20 participants
were logged, analyzed, and paired with think-aloud data for
27 commands performed with 1 and 2 hands. Our findings
indicate that users rarely care about the number of fingers
they employ, that one hand is preferred to two, that desktop
idioms strongly influence users’ mental models, and that
some commands elicit little gestural agreement, suggesting
the need for on-screen widgets. We also present a complete
user-defined gesture set, quantitative agreement scores,
implications for surface technology, and a taxonomy of
surface gestures. Our results will help designers create
better gesture sets informed by user behavior.
Author Keywords: Surface, tabletop, gestures, gesture
recognition, guessability, signs, referents, think-aloud.
ACM Classification Keywords: H.5.2. Information
interfaces and presentation: User Interfaces – Interaction
styles, evaluation/methodology, user-centered design.
INTRODUCTION
Recently, researchers in human-computer interaction have
been exploring interactive tabletops for use by individuals
[29] and groups [17], as part of multi-display environments
[7], and for fun and entertainment [31]. A key challenge of
surface computing is that traditional input using the
keyboard, mouse, and mouse-based widgets is no longer
preferable; instead, interactive surfaces are typically
controlled via multi-touch freehand gestures. Whereas input
devices inherently constrain human motion for meaningful
human-computer dialogue [6], surface gestures are versatile
and highly varied—almost anything one can do with one’s
Figure 1. A user performing a gesture to pan a field of objects after
being prompted by an animation demonstrating the panning effect.
hands could be a potential gesture. To date, most surface
gestures have been defined by system designers, who
personally employ them or teach them to user-testers
[14,17,21,27,34,35]. Despite skillful design, this results in
somewhat arbitrary gesture sets whose members may be
chosen out of concern for reliable recognition [19].
Although this criterion is important for early prototypes, it
is not useful for determining which gestures match those
that would be chosen by users. It is therefore timely to
consider the types of surface gestures people make without
regard for recognition or technical concerns.
What kinds of gestures do non-technical users make? In
users’ minds, what are the important characteristics of such
gestures? Does number of fingers matter like it does in
many designer-defined gesture sets? How consistently are
gestures employed by different users for the same
commands? Although designers may organize their gestures
in a principled, logical fashion, user behavior is rarely so
systematic. As McNeill [15] writes in his laborious study of
human discursive gesture, “Indeed, the important thing
about gestures is that they are not fixed. They are free and
reveal the idiosyncratic imagery of thought” (p. 1).
To investigate these idiosyncrasies, we employ a
guessability study methodology [33] that presents the
effects of gestures to participants and elicits the causes
meant to invoke them. By using a think-aloud protocol and
video analysis, we obtain rich qualitative data that
illuminates users’ mental models. By using custom software
with detailed logging on a Microsoft Surface prototype, we
obtain quantitative measures regarding gesture timing,
activity, and preferences. The result is a detailed picture of
user-defined gestures and the mental models and
performance that accompany them.Although some prior
Permission to make digital or hard copies of all or part of this work fo
r
p
ersonal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
b
ear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prio
r
specific permission and/or a fee.
CHI 2009, April 4–9, 2009, Boston, Massachusetts, USA.
Copyright 2009 ACM 978-1-60558-246-7/09/04…$5.00
CHI 2009 ~ Tabletop Gestures
April 7th, 2009 ~ Boston, MA, USA
1083
Abbildung 3.1: Teilnehmer des Experiments f¨
uhrt eine Pan-Geste aus [31].
Nach einer sorgf¨
altigen Analyse der ermittelten Daten hat sich gezeigt, dass 43,9%
aller verwendeten Gesten, physikalische Gesten sind und damit h¨
aufiger verwen-
det werden als symbolische Gesten mit 28,9%. Bei den verbleibenden 27,2% han-
delt es sich um abstrakte Gesten, wie beispielsweise das Ausf¨
uhren einer L¨
osch-
Geste durch dreimaliges Antippen eines Bedienelements. Des Weiteren ist die
Komplexit¨
at einer jeden Geste ermittelt worden. Die Geste zum R¨
uckg¨
angig ma-
chen von Eingaben stellt sich dabei als komplizierteste Geste heraus, denn hier
m¨
ussen die Testpersonen am l¨
angsten ¨
uberlegen, welche Bewegung sich am be-
sten f¨
ur diese Funktion eignet. Im Gegensatz dazu ist die Verschieben-Geste die
einfachste Geste. Hier m¨
ussen die Testpersonen im Durchschnitt nur acht Sekun-
den vor Gestenausf¨
uhrung nachdenken. Bei den komplizierten Gesten sind es im
Durchschnitt 15 Sekunden. F¨
ur die 27 Aktionen wird f¨
ur 25 Aktionen nur eine Hand
verwendet. Die zweite Hand kommt lediglich bei den Aktionen ”Einf¨
ugen“ und ”Ma-
ximieren“ zum Einsatz. 72,0% aller Gesten werden ¨
ahnlich wie mit einer Maus
ausgef¨
uhrt. Das heißt, die Testpersonen w¨
ahlen die Bedienelemente zun¨
achst mit
einem Antippen aus und f¨
uhren anschließend eine Ver¨
anderung aus. Die Anzahl
der verwendeten Finger ist in den meisten F¨
allen unbedeutend. Mehrere Finger
sind beispielsweise bei gr¨
oßeren Bedienelementen von Bedeutung, da diese Be-
dienelemente den Anschein erwecken, dass man hier zur Manipulation mehr ”Kraft“
aufwenden muss. Bei Vergr¨
oßerung von Elementen werden ebenfalls mehrere Fin-
ger verwendet, sowie f¨
ur Aktionen bei denen man sicherstellen will, dass auch
wirklich gedr¨
uckt wird. In einigen F¨
allen verwenden Testpersonen f¨
ur verschiede-
ne Aktionen dieselben Gesten. Zum Beispiel ist die Pinch-Geste einmal f¨
ur die
14
3.1 Ermittlung von Multi-Touch-Gesten
Vergr¨
oßerung eines Bedienelementes n¨
utzlich und ein anderes Mal zum Zoomen,
indem die Geste auf dem Hintergrund angewendet wird.
Als Ergebnis des Experiments ist ein benutzerdefiniertes Gesten-Set ermittelt wor-
den, das sich im Anhang A.1 dieser Arbeit befindet.
3.1.2 Symbolische Gesten interaktiver Systeme
Vor der Einf¨
uhrung von Smartphones und Tablets mit Multi-Touch-Funktionalit¨
at
existierten bereits Ger¨
ate, wie Tablet-PCs und Pocket-PCs, die mit einem Stift be-
dient werden k¨
onnen. F¨
ur diese Ger¨
ate sind bereits interaktive Systeme inklusi-
ve Gestenerkennern und Bibliotheken entwickelt worden, die eine Vielzahl an un-
terschiedlichen symbolischen Gesten unterst¨
utzen [9, 16, 17, 25]. Einige dieser
Gesten haben sich bew¨
ahrt und k¨
onnen deshalb auch auf aktuelle Multi-Touch-
Entwicklungen angewendet werden. Eine Zusammenstellung der 16 n¨
utzlichsten
symbolischen Gesten, die im Kontext der Entwicklung des $1 Gesture Recognizers
[30] (siehe Kapitel 5.3.1) erstellt worden ist, ist in Abbildung 3.2 zu sehen.
Abbildung 3.2: 16 verschiedene, symbolische Gesten [30].
3.1.3 Multi-Touch-Gesten f¨ur die Prozessmodellierung
In [23] ist ein Experiment zum Thema Gesten-basierte Prozessmodellierung be-
schrieben. Bei diesem Experiment sind zun¨
achst acht elementare Modellierungs-
15
3 Analyse der Problemstellung
funktionen festgelegt worden (siehe Tabelle 3.1), zu denen sich Testpersonen ge-
eignete Multi-Touch-Gesten ¨
uberlegen m¨
ussen. Dabei beachtet das Experiment
unterschiedliche Benutzertypen (erfahrene und unerfahrene Benutzer) und Be-
dienkonzepte, sowie spezifische Problemstellungen wie das Verdecken der Be-
dienoberfl¨
ache durch H¨
ande und Finger, Pr¨
azision beim Tippen, Erm¨
udung von
Gliedmaßen, Anzahl verwendeter Finger, beidh¨
andige Bedienung und gemeinsa-
mes Arbeiten.
Es sind zun¨
achst drei unterschiedliche Gesten-Sets definiert worden, bestehend
aus einem Set f¨
ur rein Gesten-basierte Modellierung, f¨
ur Men¨
u-basierte Modellie-
rung mittels Men¨
uleisten und schließlich eine hybride L¨
osung der ersten beiden
Ans¨
atze, die ein gutes Verh¨
altnis zwischen einfach zu erlernenden und schnell
auszuf¨
uhrenden Gesten beinhaltet. Das Experiment evaluiert diese Hybridl¨
osung
und liefert als Resultat ein finales Gesten-Set.
Insgesamt l¨
osen 26 Testpersonen auf einem Apple iPad acht aufeinander aufbau-
ende Aufgaben, um einen bestehenden Prozess eines Bestellvorgangs zu model-
lieren. Jede Aufgabe beinhaltet die Anwendung eines der Modellierungsfunktionen
(siehe Tabelle 3.1). Die Reihenfolge der Aufgaben ist dabei bei jeder Testperson
gleich. Die Testpersonen k¨
onnen jedoch frei entscheiden, welche Geste sie f¨
ur
welche Modellierungsfunktion anwenden.
Elementare Modellierungsfunktionen
MF1 Aktivit¨
at einf¨
ugen MF5 Datenelement einf¨
ugen
MF2 Element benennen MF6 Lese- und Schreibkanten setzen
MF3 Verzweigungsblock einf¨
ugen MF7 Subprozess bilden und aufl¨
osen
MF4 Verzweigung einf¨
ugen MF8 Element l¨
oschen
Tabelle 3.1: Elementare Modellierungsfunktionen.
Dieses Experiment beinhaltet eine Unterscheidung zwischen symbolischen, phy-
sikalischen und Men¨
u-basierten Gesten. Zum Beispiel ist eine gestrichelte Linie
mit einem Pfeil, die auf diese Weise eine Lese- oder Schreibkante repr¨
asentiert,
eine symbolische Geste. Physikalische Gesten sind zum Beispiel Drag & Drop-
Bewegungen beim Erstellen einer gew¨
ohnlichen Kante. Men¨
u-basierte Gesten be-
inhalten die Verwendung von Men¨
uleisten und Kontextmen¨
us, die von den Testper-
sonen zeichnerisch dargestellt werden. Im Gegensatz zu Men¨
u-basierten Gesten
bereitet die Zuordnung anderer ausgef¨
uhrter Gesten zu einer bestimmten Katego-
rie allerdings Schwierigkeiten, da dies nicht immer ersichtlich ist.
Die Aufgaben werden den Testpersonen in Form von statischen Bildern pr¨
asen-
tiert, die aus dem zu bearbeitenden Prozess und einem Aufgabentext bestehen.
16
3.2 Abbildung von Multi-Touch-Gesten auf Prozessmodellierungsfunktionen
Die Testpersonen zeichnen ihre L¨
osungen in diese Bilder ein, die anschließend als
Testergebnis abgespeichert werden.
Die abschließende Analyse des Experiments ergibt, dass die insgesamt 208 er-
mittelten Gesten aus 57 symbolischen Gesten, 93 physikalischen Gesten und
58 Men¨
u-basierten Gesten bestehen. Abbildung 3.3 stellt den prozentualen An-
teil eines Gestentyps pro Modellierungsfunktion dar. Es hat sich herausgestellt,
dass Testpersonen, die Erfahrung mit Multi-Touch-Ger¨
aten haben, physikalische
sowie Men¨
u-basierte Gesten bevorzugen, wohingegen unerfahrene Testpersonen
zu symbolischen L¨
osungen tendieren. Die Verwendung von beiden H¨
anden oder
mehreren Fingern lehnen die Testpersonen gr¨
oßtenteils ab. Diese M¨
oglichkeiten
kommen lediglich bei der Pinch-Geste sowie beim Zoomen zum Einsatz.
Abbildung 3.3: Anteil der unterschiedlichen Gesten in Bezug auf die einzelnen
Modellierungsfunktionen.
3.2 Abbildung von Multi-Touch-Gesten auf
Prozessmodellierungsfunktionen
Die Gesten aus den vorherigen Abschnitten sind genauer betrachtet worden, um
passende Gesten f¨
ur die in proView implementierten Modellierungsfunktionen zu
definieren. Im Folgenden stellen wir die einzelnen Modellierungsfunktionen vor.
Gleichzeitig findet die Zuweisung einer entsprechenden Geste zu einer Modellie-
rungsfunktion statt.
17
3 Analyse der Problemstellung
F1 (Element ausw¨
ahlen) Die einzelnen Aktivit¨
aten, Verzweigungsbl¨
ocke und Da-
tenelemente eines Prozessmodells k¨
onnen selektiert werden. Diese Model-
lierungsfunktion nutzt ein Benutzer w¨
ahrend der Bearbeitung eines Prozess-
modells sehr h¨
aufig und sollte daher auf sehr einfache und schnelle Weise
ausgel¨
ost werden. Deshalb wird zum Ausw¨
ahlen eines einzelnen Prozess-
elements die Tap-Geste verwendet. Die Benutzer tippen dabei mit einem Fin-
ger auf ein Prozesselement und l¨
osen damit die Auswahlfunktion aus (siehe
Abb. 3.4). Ausgew¨
ahlte Prozesselemente werden in proView farblich hervor-
gehoben.
a) b)
Abbildung 3.4: Aktivit¨
at selektieren a) und farblich hervorheben b).
Um mehrere Prozesselemente gleichzeitig auszuw¨
ahlen, wird eine symboli-
sche Geste in Form eines Rechtecks verwendet (siehe Abb. 3.5). Das Sym-
bol ”S“ kennzeichnet den Startpunkt der Geste. Der Benutzer kann anschlie-
ßend selbst entscheiden, in welche Richtung er die Geste weiter zeichnet.
S
Abbildung 3.5: Mehrere Prozesselemente gleichzeitig ausw¨
ahlen.
Die Verwendung einer Tap-Geste und des Rechteck-Symbols ist auch ein
Vorschlag in [23]. Eine Untersuchung der Auswahlfunktion ist in diesem Kon-
text nicht durchgef¨
uhrt worden. Die Tap-Geste ist jedoch Bestandteil des re-
sultierenden Gesten-Sets von [31] (siehe Abschnitt 3.1.1).
F2 (Aktivit¨
at einf¨ugen) In ein bestehendes Prozessmodell k¨
onnen weitere Akti-
vit¨
aten eingef¨
ugt werden. Diese Modellierungsfunktion sollte ebenfalls schnell
und einfach ausl¨
osbar sein, da diese bei der Modellierung h¨
aufig verwendet
wird.
18
3.2 Abbildung von Multi-Touch-Gesten auf Prozessmodellierungsfunktionen
Eine intuitive L¨
osung ist das Zeichnen eines Rechtecks oder eines Kreises
beispielsweise auf der Sequenzflusskante zwischen zwei bestehenden Akti-
vit¨
aten. Dieser Ansatz ben¨
otigt jedoch viel Ausf¨
uhrungszeit und Platz im Pro-
zessmodell. [23] stellt eine physikalische Geste vor, die die Ausf¨
uhrungszeit,
sowie den ben¨
otigten Platz reduziert. Es handelt sich hierbei um eine ver-
tikale Drag & Drop-Bewegung, die der Benutzer auf der Sequenzflusskante
zwischen zwei Aktivit¨
aten ausf¨
uhrt (siehe Abb. 3.6). Zeichnerisch ¨
ahnelt die
Geste einem vertikalen Strich und wird daher auch Strich-Geste genannt.
Abbildung 3.6: Aktivit¨
at einf¨
ugen.
Eine alternative L¨
osung ist die Verwendung einer Tap-Geste, die ein Kontext-
men¨
u einblendet. Mit diesem Men¨
u kann anschließend eine neue Aktivit¨
at
eingesetzt werden. Angetippt wird die Sequenzflusskante zwischen zwei Ak-
tivit¨
aten. Bei dieser L¨
osung ist jedoch aufgrund des Kontextmen¨
us ein Schritt
mehr notwendig als f¨
ur die Strich-Geste. Dar¨
uber hinaus ist ein pr¨
azises An-
tippen der Sequenzflusskante Voraussetzung, da eventuell benachbarte Pro-
zesselemente ungewollt ausgew¨
ahlt werden.
Der Name der neuen Aktivit¨
at wird mithilfe eines Dialogfensters und einer
virtuellen Tastatur eingegeben.
F3 (Element umbenennen) In einigen F¨
allen ist es notwendig, den Namen be-
stehender Prozesselemente zu ¨
andern. [23] schl¨
agt hierzu eine Tap-Geste
oder eine Double-Tap-Geste vor, die der Benutzer auf die entsprechende Ak-
tivit¨
at anwendet. Mit der Tap-Geste werden in dieser Arbeit bereits Prozess-
elemente ausgew¨
ahlt, daher wird f¨
ur die Umbenennen-Funktion die Double-
Tap-Geste eingesetzt (siehe Abb. 3.7).
Abbildung 3.7: Element umbenennen.
19
3 Analyse der Problemstellung
Nach Ausl¨
osen dieser Funktion ¨
offnet sich ein neues Dialogfenster mit ei-
nem Eingabefeld, in dem der neue Name des Prozesselements mithilfe einer
virtuellen Tastatur eingegeben werden kann.
F4 (Element l¨
oschen) Einzelne Prozesselemente, wie Verzweigungsknoten oder
Aktivit¨
aten, k¨
onnen aus einem Prozessmodell entfernt werden. Eine intuiti-
ve Geste f¨
ur diese Funktion ist das Durchstreichen des zu l¨
oschenden Ele-
ments. Dabei werden verschiedene Symbole wie ein diagonaler Strich, X-
oder ein Zickzack-Symbol verwendet.
Bei der Wahl der Geste muss darauf geachtet werden, dass sie nicht zu
einfach, aber auch nicht zu kompliziert ist. Bei einer einfachen Geste, wie
zum Beispiel dem diagonalen Strich, kann es schnell passieren, dass ein
Benutzer Prozesselemente ungewollt l¨
oscht. An dieser Stelle ist deshalb der
Einsatz einer Sicherheitsabfrage notwendig. Komplexe Gesten, wie zum Bei-
spiel ein Zickzack-Symbol, ben¨
otigen mehr Ausf¨
uhrungszeit, schließen den
Einsatz einer Sicherheitsabfrage allerdings aus, da ungewollte L¨
oschvorg¨
an-
ge nicht so schnell auftreten k¨
onnen.
Die L¨
oschfunktion wird ebenfalls in [23] untersucht. Das finale Gesten-Set
des Experiments beinhaltet hierf¨
ur eine Hold-Geste, die ein Kontextmen¨
u auf-
ruft. Der Benutzer verweilt mit seinem Finger f¨
ur eine gewisse Zeit auf dem zu
l¨
oschenden Prozesselement, bis sich das Kontextmen¨
u¨
offnet. Anschließend
kann er mit diesem Kontextmen¨
u die L¨
oschfunktion ausl¨
osen.
Einige Testpersonen bevorzugen bei diesem Experiment allerdings auch eine
zeichnerische L¨
osung in Form eines X- oder Zickzack-Symbols. Eine Vielzahl
an interaktiven Systemen auf Tablet-PCs verwenden ebenfalls ein solches
Symbol, wie das Gesten-Set in Abschnitt 3.1.2 beweist. Ein Vorteil symboli-
scher Gesten ist, dass nur ein Schritt zum L¨
oschen notwendig ist und nicht
zwei Schritte, wie es bei dem Kontextmen¨
u der Fall ist.
Aufgrund dieser Ergebnisse wird f¨
ur die L¨
oschfunktion eine Geste in Form
eines X-Symbols bevorzugt (siehe Abb 3.8). Dabei ist zu beachten, dass der
Finger w¨
ahrend der Gestenausf¨
uhrung nicht abgesetzt werden darf.
Abbildung 3.8: Element l¨
oschen.
20
3.2 Abbildung von Multi-Touch-Gesten auf Prozessmodellierungsfunktionen
F5 (Elemente aggregieren) Mit dieser Modellierungsfunktion ist es m¨
oglich ein
oder mehrere Prozesselemente zu einem Subprozess zusammenzufassen,
wodurch eine Steigerung der ¨
Ubersichtlichkeit erreicht wird.
Eine intuitive L¨
osung ist das Zeichnen eines Kreises oder eines Rechtecks
um die zu aggregierenden Prozesselemente (siehe Abb. 3.9). Da das Recht-
eck-Symbol nicht nur f¨
ur diese Modellierungsfunktion, sondern auch f¨
ur die
Funktionen F7 (Verzweigungsblock einf¨
ugen) und F14 (Prozesssicht erstel-
len) verwendet wird, ist der zus¨
atzliche Einsatz eines Kontextmen¨
us notwen-
dig, um die Modellierungsfunktion auszul¨
osen.
S
Aggregate Nodes
View From Selection
Insert Conditional
Insert Parallel
a)
b)
Abbildung 3.9: Prozesselemente ausw¨
ahlen a) und entsprechende Modellierungs-
funktion per Kontextmen¨
u ausf¨
uhren b).
F6 (Element reduzieren) Prozesselemente k¨
onnen aus einer Prozesssicht ent-
fernt werden, sind aber im CPM noch vorhanden, d.h. sie werden nicht voll-
st¨
andig gel¨
oscht. Auf diese Weise ist es m¨
oglich, die ¨
Ubersichtlichkeit eines
Prozessmodells zu verbessern.
Da diese Funktion ¨
ahnlich zur Funktion F4 (Element l¨
oschen) ist, stellt das
Durchstreichen der Prozesselemente mittels Kreuz oder Zickzack-Symbol
auch hier die intuitive L¨
osung dar. Diese Gesten eignen sich allerdings nicht
besonders gut, um mehrere Prozesselemente gleichzeitig zu reduzieren. [23]
stellt zum L¨
oschen von Prozesselementen noch eine weitere Geste vor, die
von der Form her einem Verbotsschild ¨
ahnelt. Eine ¨
ahnliche Geste wird auch
an dieser Stelle f¨
ur das Reduzieren von Prozesselementen verwendet (sie-
he Abb. 3.10). Diese Geste ist aber nicht wie in [23] kreisf¨
ormig, sondern
rechteckig.
Der Benutzer zeichnet wie beim Aggregieren ein Rechteck um die zu redu-
zierenden Prozesselemente. Das Symbol ”S“ kennzeichnet hierbei den Start-
punkt der Geste. Zus¨
atzlich zeichnet er einen diagonalen Strich von der obe-
21
3 Analyse der Problemstellung
S
Abbildung 3.10: Element reduzieren.
ren, linken Ecke zur unteren, rechten Ecke des Rechtecks ein. Diese symbo-
lische Geste wird ohne Absetzen des Fingers ausgef¨
uhrt. In welche Richtung
der Benutzer seinen Finger bei Gestenausf¨
uhrung vom Startpunkt aus weiter
bewegt, kann er selbst entscheiden.
Der Vorteil dieser Geste ist, dass kein zus¨
atzliches Kontextmen¨
u, wie zum
Beispiel beim Aggregieren von Prozesselementen, notwendig ist.
F7 (Verzweigungsblock einf¨ugen) Mit dieser Modellierungsfunktion wird ein neu-
er Verzweigungsblock in das Prozessmodell eingef¨
ugt. Dabei hat der Benut-
zer die Wahl zwischen einem AND- oder einem XOR-Verzweigungsblock.
Fast ein Drittel der Testpersonen in [23] entscheiden sich f¨
ur eine symbo-
lische Geste, indem sie zum Beispiel den Start- sowie den Endpunkt des
Verzweigungsblocks mit einem rautenf¨
ormigen Symbol kennzeichnen. Inner-
halb des Rauten-Symbols zeichnen sie ein Plus- oder ein X-Symbol ein, um
zwischen einem AND- und XOR-Verzweigungsblock zu unterscheiden. Das
Experiment ergibt allerdings im Wesentlichen ein recht ausgeglichenes Er-
gebnis, da genauso viele Testpersonen Men¨
u-basierte L¨
osungen als auch
physikalische Gesten bevorzugen.
Das finale Gesten-Set in [23] beinhaltet eine Men¨
u-basierte L¨
osung f¨
ur diese
Modellierungsfunktion. Der Benutzer f¨
uhrt zun¨
achst eine Strich-Geste aus.
Der Startpunkt der Geste markiert den ¨
offnenden Verzweigungsknoten und
der Endpunkt entsprechend den schließenden Verzweigungsknoten. Alle Pro-
zesselemente, die sich innerhalb der beiden Gestenpunkte befinden, sind
Bestandteil des neuen Verzweigungsblocks. Nach Gestenausf¨
uhrung ¨
offnet
sich ein Kontextmen¨
u, mit dem ein Verzweigungstyp ausgew¨
ahlt werden kann.
Einige Testpersonen in [23] haben sich aber auch f¨
ur ein Rechteck-Symbol
entschieden, um die entsprechenden Prozesselemente zu selektieren. Da
die Funktion F1 (Element ausw¨
ahlen) ebenfalls dieses Symbol nutzt, ist es
naheliegend, dieses Symbol f¨
ur das Einf¨
ugen neuer Verzweigungsbl¨
ocke
anstelle der Strich-Geste zu verwenden. In einem Kontextmen¨
u, das nach
22
3.2 Abbildung von Multi-Touch-Gesten auf Prozessmodellierungsfunktionen
dem Ausf¨
uhren der symbolischen Geste erscheint, kann der Benutzer den
gew¨
unschten Verzweigungstyp ausw¨
ahlen (siehe Abb. 3.9).
F8 (Verzweigung einf¨ugen) In einen Verzweigungsblock k¨
onnen weitere Verzwei-
gungen eingef¨
ugt werden. Intuitiv wird von den meisten Benutzern eine Strich-
Geste zwischen den beiden Verzweigungsknoten eines Blocks gezeichnet
[23]. Das Problem dieser Geste ist jedoch, dass beide Verzweigungsknoten
auf dem Bildschirm sichtbar sein m¨
ussen, was sich bei einem sehr großen
Prozessmodell als schwierig erweist. Beim Verkleinern eines Prozessmo-
dells besteht wiederum das Problem, dass die Verzweigungsknoten zu klein
sind, um sie pr¨
azise auszuw¨
ahlen. F¨
ur diese Modellierungsfunktion wird da-
her eine Geste gew¨
ahlt, die nur den ¨
offnenden Knoten eines Verzweigungs-
blocks ben¨
otigt. Es handelt sich hierbei um eine symbolische Geste in Form
eines nach oben gerichteten Pfeils (siehe Abb. 3.11). Der Startpunkt ”S“
dieses Pfeils liegt auf dem ¨
offnenden Knoten des Verzweigungsblocks. Der
schließende Verzweigungsknoten wird nach Gestenausf¨
uhrung automatisch
von der Anwendung ermittelt.
S
Abbildung 3.11: Verzweigung einf¨
ugen.
F9 (Schleife einf¨ugen) Mit dieser Modellierungsfunktion kann in das Prozessmo-
dell eine neue Schleife eingef¨
ugt werden, um bestimmte Prozesselemente
wiederholt auszuf¨
uhren. [23] besitzt keine experimentelle Untersuchung zu
dieser Modellierungsfunktion, dennoch wird eine Geste vorgeschlagen. Es
handelt sich dabei um ein wellenf¨
ormiges Symbol, das an drei Stellen den
Sequenzfluss schneidet. Der erste und der letzte Schnittpunkt definieren den
Start- bzw. Endpunkt der Schleife. Zwischen diesen beiden Punkten befin-
den sich die Prozesselemente, die wiederholt werden sollen. Da diese vorge-
schlagene Geste nicht intuitiv genug ist, wird f¨
ur diese Modellierungsfunktion
eine andere Geste bevorzugt.
Der Benutzer zeichnet die Schleife direkt in das Prozessmodell ein (siehe
Abb. 3.12). Die rautenf¨
ormigen Symbole f¨
ur die Verzweigungsknoten wer-
den jedoch weggelassen. Die Geste ¨
ahnelt auf diese Weise einem halben
23
3 Analyse der Problemstellung
Rechteck. Die Endpunkte dieser Geste starten und enden direkt auf den Pro-
zesselementen, die noch in die Schleife miteinbezogen werden sollen. Nach
Gestenausf¨
uhrung befinden sich die entsprechenden Prozesselemente in-
nerhalb des Schleifenblocks.
S
Abbildung 3.12: Schleife einf¨
ugen.
F10 (Synchronisationskante einf¨ugen) Um die Abh¨
angigkeit zwischen zwei Ak-
tivit¨
aten innerhalb eines AND-Verzweigungsblocks zu bestimmen, kann eine
Synchronisationskante zwischen diesen Prozesselementen eingef¨
ugt wer-
den. F¨
ur diese Modellierungsfunktion existiert keine experimentelle Unter-
suchung. Sie ¨
ahnelt jedoch der Modellierungsfunktion zum Einf¨
ugen einer
Lese- oder Schreibkante. In [23] hat sich herausgestellt, dass 57,69% der
Testpersonen mithilfe einer Strich-Geste eine Linie zwischen Datenelement
und Aktivit¨
at ziehen. Die Richtung der Linie bestimmt, ob es eine Lese- oder
Schreibkante ist. Diese Geste l¨
asst sich ebenfalls f¨
ur die Synchronisations-
kante verwenden (siehe Abb. 3.13).
Abbildung 3.13: Synchronisationskante einf¨
ugen.
F11 (Subprozess anzeigen) Ein Subprozess in kollabierter Version kann in pro-
View wieder vollst¨
andig angezeigt werden. Zu dieser Modellierungsfunktion
fand bisher keine experimentelle Untersuchung statt. Die ¨
Uberlegungen zu
dieser Modelllierungsfunktion beinhalteten die Implementierung einer Swipe-
oder einer Pinch-Geste, die auf dem Subprozess ausgef¨
uhrt wird. Schlus-
sendlich wird eine Hold-Geste verwendet, da der kollabierte Subprozess mit
24
3.2 Abbildung von Multi-Touch-Gesten auf Prozessmodellierungsfunktionen
dieser Geste pr¨
aziser ausgew¨
ahlt werden kann. Der Subprozess wird hier-
bei f¨
ur eine bestimmte Zeitdauer ber¨
uhrt, um die Modellierungsfunktion aus-
zul¨
osen und den Subprozess aufzuklappen (siehe Abb. 3.14a).
a) b)
Abbildung 3.14: Subprozess anzeigen a) und verbergen b).
F12 (Subprozess verbergen) Diese Modellierungsfunktion erm¨
oglicht die ¨
Uber-
f¨
uhrung eines expandierten Subprozesses in seine kollabierte Version. Wie
schon bei F11 (Subprozess anzeigen), wird auch an dieser Stelle wieder die
Hold-Geste verwendet (siehe Abb. 3.14b).
F13 (Subprozess aufl ¨
osen) Ein bestehender Subprozess kann in seiner expan-
dierten Version mit dieser Modellierungsfunktion aufgel¨
ost werden, sodass
die enthaltenen Prozesselemente wieder fester Bestandteil des gesamten
Prozessmodells sind.
[23] untersucht nur das Bilden eines Subprozesses, d.h. das Aggregieren von
Prozesselementen. Im finalen Gesten-Set ist jedoch ein Gestenvorschlag f¨
ur
die Aufl¨
osen-Funktion enthalten. Der Benutzer zeichnet hierbei um den ex-
pandierten Subprozess ein Rechteck, um ihn auszuw¨
ahlen. Im sich anschlie-
ßend ¨
offnenden Kontextmen¨
u kann die entsprechende Modellierungsfunkti-
on zum Aufl¨
osen des Subprozesses ausgew¨
ahlt werden.
Eine weitere Alternative ist in [31] enthalten. Die Mehrheit der Testpersonen
des Experiments zeichnen beim R¨
uckg¨
angig machen bestimmter Aktionen
ein Zickzack-Symbol auf den Bildschirm (siehe Abb. A.1m). Da diese Geste
experimentell ermittelt ist, wird sie f¨
ur die Implementierung bevorzugt (siehe
Abb. 3.15).
Zu beachten ist, dass sich der Startpunkt der Geste innerhalb des Subpro-
zesses befinden muss, da das Zickzack-Symbol f¨
ur weitere Modellierungs-
funktionen eingesetzt werden k¨
onnte. Der restliche Teil der Geste kann sich
auch außerhalb des Subprozesses befinden. Ein Vorteil dieser symbolischen
Geste ist, dass die entsprechende Modellierungsfunktion sofort nach Ge-
stenausf¨
uhrung ausgel¨
ost wird und kein weiterer Schritt ¨
uber ein Kontext-
25
3 Analyse der Problemstellung
men¨
u notwendig ist.
S
Abbildung 3.15: Subprozess aufl¨
osen.
F14 (Prozesssicht erstellen) Aus einem Prozessmodell k¨
onnen weitere Prozess-
sichten extrahiert werden, indem die entsprechenden Prozesselemente aus-
gew¨
ahlt werden. Diese Modellierungsfunktion ist beinahe identisch zur Mo-
dellierungsfunktion F5 (Elemente aggregieren). Daher wird f¨
ur das Erstellen
von neuen Prozesssichten dieselbe Geste verwendet.
Der Benutzer w¨
ahlt mit einem Rechteck die Prozesselemente aus, die in der
neuen Prozesssicht enthalten sein sollen. In einem sich ¨
offnenden Kontext-
men¨
u kann die Modellierungsfunktion zum Erstellen der Prozesssicht aus-
gew¨
ahlt werden (siehe Abb. 3.9).
F15 (Datenelement einf¨ugen) In ein Prozessmodell k¨
onnen nicht nur neue Ak-
tivit¨
aten, sondern auch neue Datenelemente eingef¨
ugt werden. [23] unter-
sucht diese Modellierungsfunktion und liefert ein ausgeglichenes Ergebnis
zwischen symbolischen und physikalischen Gesten. 38,46% der Testperso-
nen entscheiden sich bei dem Experiment f¨
ur das Zeichnen eines Rechtecks
oder Kreises auf eine freie Fl¨
ache des Hintergrunds. 46,15% der Testper-
sonen, bei denen es sich gr¨
oßtenteils um erfahrene Testpersonen handelt,
favorisieren Men¨
u-basierte L¨
osungen, d.h. sie setzen mittels Tap-Geste und
Kontextmen¨
u ein neues Datenelement ein.
Das finale Gesten-Set des Experiments schl¨
agt das Zeichnen eines Recht-
ecks abseits des Prozessmodells, d.h. auf freiem Hintergrund, vor. Dieser
Vorschlag wird ¨
ubernommen (siehe Abb. 3.16). Die Geste erzeugt sofort
nach ihrer Ausf¨
uhrung ein neues Datenelement, das der Benutzer unter Ein-
satz einer virtuellen Tastatur benennen kann.
F16 (Hilfe aufrufen) Ist eine Geste dem Benutzer nicht bekannt, kann er in einem
Hilfe-Dialog nach dieser Geste suchen. F¨
ur den Aufruf dieses Hilfe-Dialogs
ist ebenfalls eine Geste notwendig.
Benutzer verbinden mit einer Hilfe in der Regel das Fragezeichen-Symbol.
26
3.2 Abbildung von Multi-Touch-Gesten auf Prozessmodellierungsfunktionen
S
Abbildung 3.16: Datenelement einf¨
ugen.
Daher ist die naheliegende L¨
osung, eine symbolische Geste zum Aufrufen
des Hilfe-Dialogs zu verwenden. Dies wird auch von [31] best¨
atigt, in dem
die meisten Testpersonen ein Fragezeichen ohne unteren Punkt zeichnen
(siehe Abb. A.1i). Das Fragezeichen-Symbol ist ebenfalls fester Bestandteil
vieler interaktiver Systeme auf Tablet-PCs, wie Abb. 3.2g zeigt.
Verwendet wird somit f¨
ur diese Funktion ebenfalls eine symbolische Geste
in Form eines Fragezeichens ohne den unteren Punkt, da der Benutzer sei-
nen Finger nicht absetzen darf (siehe Abb. 3.17). Die Geste kann an einer
beliebigen Stelle im Bearbeitungsbereich ausgef¨
uhrt werden.
S
Abbildung 3.17: Hilfe aufrufen.
F17 (R¨uckg¨
angig machen) Ausgef¨
uhrte Bearbeitungsschritte k¨
onnen, wie in vie-
len anderen Anwendungen auch, wieder r¨
uckg¨
angig gemacht werden. Eine
experimentelle Untersuchung dieser Modellierungsfunktion ist in [31] enthal-
ten. Die Mehrheit der Testpersonen dieses Experiments entscheidet sich die
Modellierungsfunktion mit einem Zickzack-Symbol auszul¨
osen (siehe Abb.
A.1m). An dieser Stelle wird eine symbolische Geste in Form eines Zickzack-
Symbols gew¨
ahlt. Zu beachten ist, dass die Geste abseits des Prozessmo-
dells auf freiem Hintergrund ausgef¨
uhrt werden muss (siehe Abb. 3.18), da
F13 (Subprozess aufl¨
osen) diese Geste bereits nutzt.
F18 (Lese- und Schreibkante einf¨ugen) Zwischen einer Aktivit¨
at und einem Da-
tenelement kann eine Lese- oder Schreibkante eingef¨
ugt werden, damit die
27
3 Analyse der Problemstellung
S
Abbildung 3.18: R¨
uckg¨
angig machen.
Aktivit¨
at lesenden bzw. schreibenden Zugriff auf das Datenelement hat.
Mit 57,69% und somit mehr als die H¨
alfte der Testpersonen in [23] ent-
scheiden sich eine Strich-Geste zwischen Aktivit¨
at und Datenelement aus-
zuf¨
uhren. Die Richtung der Bewegung bestimmt dabei den Kantentyp. F¨
ur
Lesekanten zum Beispiel f¨
uhren die Testpersonen eine Bewegung vom Da-
tenelement zur Aktivit¨
at aus. Aufgrund dieses Ergebnisses wird diese Geste
¨
ubernommen (siehe Abb. 3.19).
Zu beachten ist, dass sich die Endpunkte des Strichs genau auf den entspre-
chenden Prozesselementen befinden, da die Modellierungsfunktion sonst
nicht ausgel¨
ost werden kann.
Abbildung 3.19: Lese- und Schreibkante einf¨
ugen.
28
4 Analyse von
Multi-Touch-Implementierungen
Die zur Verf¨
ugung gestellten UI-Komponenten in Vaadin reagieren standardm¨
aßig
auf keine Touch-Events. Es k¨
onnen allerdings clientseitige Widgets erzeugt wer-
den, die aufgrund der Verwendung von GWT auf Touch-Events reagieren k¨
onnen.
Vaadin bietet auf der eigenen Webseite Add-ons an, von denen einige Touch-
Events unterst¨
utzen. Diese Add-ons sind TouchScroll [26], TouchMenu [5], JSlider
[20] und das Vaadin TouchKit [7].
Die ersten drei Add-ons bieten jeweils eine einzelne UI-Komponente an, die aus-
schließlich auf Scroll-Gesten reagiert. Eine von der Komponente losgel¨
oste Nut-
zung der Geste ist nicht m¨
oglich. Dar¨
uber hinaus reicht die einzelne Scroll-Geste
nicht f¨
ur eine Erweiterung des proView-Frameworks aus. Einzelheiten zum Touch-
Kit-Add-on von Vaadin werden in Abschnitt 4.1 diskutiert.
Vaadin unterst¨
utzt auch den Einsatz von JavaScript-Bibliotheken mit denen Multi-
Touch-Funktionalit¨
at realisiert werden kann. Abschnitt 4.2 stellt diese Bibliotheken
vor. Schließlich beinhaltet Abschnitt 4.3 ein Fazit zu den vorgestellten Multi-Touch-
Implementierungen.
4.1 Vaadin TouchKit
Das Vaadin TouchKit-Add-on ist von Vaadin Ltd. entwickelt worden und dient der
Erstellung von Web-Anwendungen mit dem Look and Feel nativer Anwendungen
auf mobilen Ger¨
aten [7]. So beinhaltet es beispielsweise spezielle UI-Komponenten
wie Buttons oder Navigationsleisten, die eine optische ¨
Ahnlichkeit mit Komponen-
ten einer nativen iPhone-Anwendung haben. Zudem unterst¨
utzt die SwipeView-
Komponente des TouchKits die Swipe-Geste. Mit dieser Geste kann zwischen ver-
schiedenen Seiten einer Web-Anwendung gewechselt werden, indem diese nach
links oder rechts ”gewischt“ werden. Dies ist allerdings die einzige Geste, die das
TouchKit-Add-on unterst¨
utzt.
29
4 Analyse von Multi-Touch-Implementierungen
Es werden verschiedene Browser-Eigenschaften unterst¨
utzt, wie Geolocation, Ho-
me Screen Launching, Splash Screen und Web App Mode. Zus¨
atzlich bietet das
Add-on einen Offline-Modus f¨
ur Web-Anwendungen an, bei dem es sich um eine
spezielle Vaadin-Benutzerschnittstelle handelt, die im Cache eines Browsers ab-
gelegt wird und bei einer fehlenden Netzwerkverbindung zur Laufzeit oder beim
Start der Web-Anwendung aktiv wird.
Ein wesentlicher Nachteil dieses Add-ons ist, dass es nur mit Browsern kompati-
bel ist, die f¨
ur das Rendering von HTML und JavaScript die freie Browser-Engine
WebKit verwenden. Dies ist beispielsweise bei den Standardbrowsern von iPhone
und Android der Fall. Andere Browser, wie zum Beispiel Mozilla Firefox, der die
Browser-Engine Gecko verwendet, werden vom TouchKit-Add-on nicht unterst¨
utzt.
4.2 Multi-Touch-Bibliotheken f¨ur JavaScript
Das W3C beschreibt eine Touch-Events Spezifikation [24], die das Ausl¨
osen von
Low-Level-Ereignissen beim Ber¨
uhren von ber¨
uhrungsempfindlichen Bildschirmen
beinhaltet. Zu beachten ist, dass es sich bei dieser Spezifikation momentan nur
um einen W3C-Empfehlungsvorschlag (engl. Proposed Recommendation) han-
delt, der im Kontext der HTML5-Entwicklung entstanden ist. Touch-Events sind
demzufolge noch keine endg¨
ultige W3C-Empfehlung (d.h. W3C-Standard), sind
aber wie HTML5 bereits in den meisten Browsern implementiert. Die Ereignisse,
die von der Touch-Events Spezifikation definiert werden sind:
TouchStart Dieses Ereignis wird ausgel¨
ost, wenn der Multi-Touch-Bildschirm bzw.
ein ber¨
uhrungsempfindliches DOM-Element mit einem Finger ber¨
uhrt wird.
Beim Einsatz mehrerer Finger l¨
ost jedes dieser Finger ein separates Touch-
Start-Event aus.
TouchEnd Verl¨
asst ein Finger den Multi-Touch-Bildschirm bzw. das DOM-Element,
so wird ein TouchEnd-Event ausgel¨
ost. Dies schließt auch den Fall ein, wenn
ein Finger ¨
uber den Rand eines Multi-Touch-Bildschirms gezogen wird.
TouchMove Ber¨
uhrt ein Finger den Bildschirm und wird w¨
ahrenddessen an ei-
ne andere Position auf dem Bildschirm bzw. DOM-Element verschoben, l¨
ost
dies w¨
ahrend der Verschiebung mehrere TouchMove-Events aus. Die Anzahl
dieser Ereignisse h¨
angt dabei von der Implementierung der Touch-Events
Spezifikation ab, sowie von der Hardware des Multi-Touch-Ger¨
ates.
TouchCancel Das TouchCancel-Event wird ausgel¨
ost, wenn der Finger w¨
ahrend
eines Touch-Events die HTML-Seite verl¨
asst oder ein Touch-Event aus be-
30
4.2 Multi-Touch-Bibliotheken f¨
ur JavaScript
stimmten Gr¨
unden vom Browser unterbrochen wird. Es wird ebenfalls ein
TouchCancel-Event ausgel¨
ost, wenn die vorkonfigurierte Maximalanzahl an
Ber¨
uhrungspunkten ¨
uberschritten bzw. hardwareseitig nicht bew¨
altigt werden
kann.
Listing 4.1 demonstriert die Verwendung des TouchStart-Events innerhalb eines
HTML5-Dokuments. Dem DIV-Container mit der ID panel in Zeile 1 wird ein Touch-
Start-Listener hinzugef¨
ugt (Zeile 3). Dieses DOM-Element ist nun ber¨
uhrungsemp-
findlich und l¨
ost bei Ber¨
uhrung die Handler-Methode handleStart aus (Zeile 5), die
anschließend die Position des Ber¨
uhrungspunktes in der Browser-internen Konso-
le ausgibt (Zeile 7).
Listing 4.1: Code-Beispiel des TouchStart-Events
1<div id=" panel " >touch </div >
2<script type =" text / javascript " >
3panel . addEventListener (" touchstart ", handleStart , false );
4
5function handleStart ( evt) {
6var touch = evt . touches [0];
7console . log ( touch . pageX + " " + touch . pageY );
8}
9</ script >
Es existieren bereits eine Vielzahl an JavaScript-Bibliotheken die diese Touch-
Events nutzen, um damit verschiedene Gesten-Implementierungen anzubieten.
Diese Bibliotheken sind zum Beispiel QuoJS [29], HammerJS [27], Touchy [4]
und jGestures [8]. In einigen F¨
allen ist eine zus¨
atzliche Einbindung der jQuery-
Bibliothek [10] in das HTML-Dokument notwendig.
Abh¨
angig von der verwendeten JavaScript-Bibliothek werden unter anderem die
Gesten Single-Tap, Double-Tap, Hold, 2x Fingers Tap, 2x Double-Tap, Swipe, Drag,
Rotate und Pinch unterst¨
utzt. Symbolische Gesten werden allerdings von keinen
genannten Bibliotheken unterst¨
utzt.
Das Vaadin-Framework bietet standardm¨
aßig die M¨
oglichkeit, ein clientseitiges
Widget in JavaScript zu implementieren. Dies wiederum erm¨
oglicht die Verwen-
dung eines der zuvor vorgestellten JavaScript-Bibliotheken, um die dort bereits
implementierten Gesten f¨
ur die Erweiterung von proView zu nutzen. Eine Imple-
mentierung mit JavaScript hat zudem den Vorteil, dass w¨
ahrend der Entwicklung
ein kompilieren bzw. umwandeln von Java nach JavaScript entf¨
allt. Die Nachtei-
le sind allerdings, dass zus¨
atzliche Kenntnisse in JavaScript notwendig sind, eine
31
4 Analyse von Multi-Touch-Implementierungen
bew¨
ahrte Entwicklungsumgebung f¨
ur JavaScript fehlt und die GWT-Bibliothek mit
eventuell n¨
utzlichen Klassen und Widgets nicht zur Verf¨
ugung steht.
4.3 Fazit
Um das proView-Framework zu erweitern und Gesten-basierte Prozessmodellie-
rung zu erm¨
oglichen, werden zun¨
achst Gesten-Implementierungen ben¨
otigt. Es
existieren einige Add-ons f¨
ur das Vaadin-Framework, die Gesten-Implementierun-
gen anbieten. Die Anzahl der Gesten ist hier allerdings haupts¨
achlich auf nur eine
Geste beschr¨
ankt. Diese einzelne Geste ist jedoch eng mit einer UI-Komponente
verkn¨
upft, sodass eine Nutzung der Geste ohne die UI-Komponente nicht m¨
oglich
ist. Eine Alternative zu Vaadin-Add-ons sind JavaScript-Bibliotheken, die oft eine
große Anzahl an Gesten-Implementierungen besitzen. Allerdings fehlt, wie bei den
Vaadin-Add-ons, eine Implementierung von symbolischen Gesten und clientseiti-
ge Widgets m¨
ussen in JavaScript implementiert werden, das einige Entwicklungs-
schritte erschweren k¨
onnte.
Aufgrund dieser Kritikpunkte ist es sinnvoll ein eigenes Vaadin-Add-on zu ent-
wickeln, das auf Touch-Events reagiert und alle ben¨
otigten Gesten inklusive sym-
bolischer Gesten anbietet. Dieses Add-on kann sp¨
ater sowohl f¨
ur das proView-
Framework als auch f¨
ur andere Vaadin-Projekte verwendet werden. Im n¨
achsten
Kapitel 5 wird das in dieser Arbeit entwickelte Vaadin-Add-on TouchPanel ausf¨
uhr-
licher beschrieben.
32
5 Entwicklung eines Multi-Touch-Add-ons
In diesem Kapitel werden die Entwicklung und der Aufbau des TouchPanel-Add-
ons beschrieben. Hierbei handelt es sich um ein erweitertes Vaadin-Panel, das
auf Gesten-basierte Interaktionen reagiert. Wie jede andere Vaadin-Komponente
auch, besteht das TouchPanel-Add-on aus einem clientseitigen Widget (siehe Ab-
schnitt 5.2) und einer serverseitigen Komponente (siehe Abschnitt 5.3). Das Zu-
sammenspiel zwischen Client- und Serverseite ist Thema von Abschnitt 5.1. Ab-
schnitt 5.4 beinhaltet die Emulation von Touch-Events, damit ein Testen des Add-
ons auch auf Ger¨
aten ohne Multi-Touch-Funktion m¨
oglich ist.
5.1 Aufbau des TouchPanel-Add-ons
Das clientseitige Widget ist eine Instanz der Klasse TouchPanelWidget und erwei-
tert das Vaadin-Widget VPanel (siehe Abb. 5.1). Die Klasse TouchPanel erweitert
dagegen die Vaadin-Komponente Panel und repr¨
asentiert auf diese Weise die ser-
verseitige Komponente des TouchPanel-Add-ons (siehe Abschnitt 5.3). Zu beach-
ten ist, dass sich laut Vaadin-Spezifikation alle f¨
ur das Widget relevanten Klassen
in einem separaten Paket mit dem Namen client befinden m¨
ussen. Im Gegensatz
dazu d¨
urfen die serverseitigen Klassen ¨
uberall abgelegt sein. Statische Ressour-
cen wie Bilder und Stylesheets werden in einem Paket-unabh¨
angigen, ¨
offentlichen
Ordner abgelegt.
Die Kommunikation zwischen TouchPanelWidget und TouchPanel wird durch die
Klasse TouchPanelConnector geregelt. Dieser Connector befindet sich im client-
Paket und wird mittels Annotation @Connect mit dem serverseitigen TouchPanel
verbunden. Auf diese Weise ist es m¨
oglich, den Zustand des Widgets sowie Ereig-
nisse vom und zum Server zu synchronisieren.
Im client-Paket befindet sich zus¨
atzlich ein sogenanntes shared state-Objekt,
das dazu dient, Zustands¨
anderungen der serverseitigen Komponente automatisch
an das Widget weiterzuleiten. Dieses Objekt ist eine Instanz der TouchPanelState-
Klasse und unterst¨
utzt ausschließlich primitive Datentypen wie String,Array, so-
wie die Datenstrukturen List,Map und Set.
33
5 Entwicklung eines Multi-Touch-Add-ons
TouchPanelWidget
VPanel
Widget
Client Server
Shared
TouchPanel
Panel
AbstractComponent
TouchPanel-
Connector
PanelConnector
AbstractComponent-
Connector
TouchPanelState PanelState AbstractComponent-
State
<<interface>>
TouchPanelServerRpc
<<interface>>
TouchPanelClientRpc
Application-
Connection ClientConnector
Communication-
Manager
RPC
Abbildung 5.1: Klassendiagramm zum TouchPanel-Add-on.
Das shared state-Objekt wird ausschließlich vom Server an den Client gesendet.
Das Senden von Zustands¨
anderungen vom Client an den Server ist mithilfe von
RPC-Aufrufen m¨
oglich. Hierzu nutzt der TouchPanelConnector die Schnittstelle
TouchPanelServerRpc, die sich mit der Methode registerRpc beim TouchPanel-
Connector registriert. Diese Methode erbt der TouchPanelConnector vom Ab-
stractComponentConnector. Implementiert wird diese Schnittstelle vom Touch-
Panel.
RPC-Aufrufe vom Server an den Client sind mit der Schnittstelle TouchPanel-
ClientRpc m¨
oglich. Eine Implementierung dieser Schnittstelle ist in der Klasse
TouchPanelConnector enthalten. Die Schnittstelle wird mit der getRpcProxy-Me-
thode beim serverseitigen TouchPanel registriert, das die Methode vom Client-
Connector erbt. Den Rest ¨
ubernimmt der serverseitige CommunicationManager,
den Vaadin zur Verf¨
ugung stellt.
Ebenfalls im TouchPanel-Add-on enthalten ist ein Module Descriptor mit dem Na-
men TouchPanelWidgetSet.gwt.xml. Dieser Descriptor beschreibt das vom Add-
on verwendete Widget-Set, das bei einer Kompilierung von Java nach JavaScript
34
5.2 Clientseitiges TouchPanel-Widget
ber¨
ucksichtigt werden soll. Andere Vaadin-Projekte, die das TouchPanel-Add-on
verwenden, m¨
ussen eine Referenz zu diesem Module Descriptor in ihrem eigenen
Module Descriptor angeben. Bereits vorkompilierte Widget-Sets befinden sich im
Ordner WebContent/VAADIN/widgetsets des TouchPanel-Add-ons.
Das client-Paket enth¨
alt noch weitere Unterpakete, beispielsweise das gestures-
Paket, das verschiedene Gesten-Implementierungen enth¨
alt.
5.2 Clientseitiges TouchPanel-Widget
Im Folgenden wird die Implementierung des TouchPanel-Widgets n¨
aher erl¨
autert,
das auf Clientseite zur Ausf¨
uhrung kommt. Im Mittelpunkt dieses Widgets steht die
Klasse TouchPanelWidget, die Touch-Events mit der Methode onBrowserEvent
entgegennimmt und an initialisierte Klassen zur Weiterverarbeitung delegiert. Bei
diesen Klassen handelt es sich um Gesten-Implementierungen, die in den n¨
achsten
Abschnitten genauer beschrieben werden (siehe Abb. 5.2).
<<interface>>
IGesture
<<interface>>
IGestureListener
DoubleTapGesture
Flinging
HoldGesture
PanGesture
PinchGesture
SymbolicGesture
TapGesture
+ start(screenX : int, screenY : int, x : int, y : int) : void
+ move(screenX : int, screenY : int, x : int, y : int) : void
+ end() : boolean
+ setGestureListener(gestureListener : IGestureListener) : void
+ onDoubleTapGesture(point : TouchPoint) : void
+ onGesture(points : List<TouchPoint>) : void
+ onHoldGesture(point : TouchPoint) : void
+ onPanGesture(dx : int, dy : int) : void
+ onPinchGesture(scalefactor : float, isPinchEnd : boolean) : void
+ onTapGesture(point : TouchPoint) : void
TouchPanelConnector
TouchPanelWidget
TouchPoint
Abbildung 5.2: Klassendiagramm mit Gesten-Implementierungen.
Jede dieser Klassen (d.h. DoubleTapGesture, Flinging, HoldGesture, PanGesture,
PinchGesture, SymbolicGesture und TapGesture) implementiert die Schnittstelle
35
5 Entwicklung eines Multi-Touch-Add-ons
IGesture, um auf diese Weise sicherzustellen, dass in jeder Klasse die Metho-
den start,move,end und setGestureListener vorhanden sind. Die Methoden
start und end werden aufgerufen, sobald ein Finger den Bildschirm ber¨
uhrt bzw.
diesen wieder verl¨
asst. Bewegt sich der Finger w¨
ahrend einer Ber¨
uhrung, so wird
die Methode move aufgerufen. Die Position eines Fingers auf dem Bildschirm so-
wie auf dem Element, das dem TouchPanel untergeordnet ist, wird den Methoden
start und end als Parameter ¨
ubergeben. Mithilfe des GestureListeners, der mit
der Methode setGestureListener initialisiert wird, k¨
onnen Ergebnisse der imple-
mentierten Methoden an den TouchPanelConnector weitergegeben werden, der
f¨
ur RPC-Aufrufe zwischen Client und Server zust¨
andig ist.
Zu beachten ist, dass TouchMove-Events pro Sekunde sehr oft auftreten k¨
onnen
und sie daher anders behandelt werden m¨
ussen als TouchStart- oder TouchEnd-
Events, um das Multi-Touch-Ger¨
at bzw. den Browser nicht zu ¨
uberlasten. Der
n¨
achste Abschnitt 5.2.1 beinhaltet n¨
ahere Informationen hierzu.
5.2.1 Behandlung von TouchMove-Events
TouchMove-Events werden zum Beispiel bei einer Verschiebung eines Prozessmo-
dells verwendet. Aufgrund einer ¨
Uberlastung des Rechners, kann es passieren,
dass einzelne Ereignisse verworfen werden, was zu einer ruckeligen Verschiebung
f¨
uhrt. Auch spielen TouchMove-Events bei der Gestenerkennung eine wichtige Rol-
le, da bei einer erh¨
ohten Ausl¨
oserate der Ereignisse mehr Ber¨
uhrungspunkte er-
zeugt werden, die f¨
ur eine genaue Formung einer Geste wichtig sind. Es ist des-
halb notwendig ein spezielles Verarbeitungsintervall zu nutzen, um die ¨
Uberlastung
eines Rechners zu reduzieren.
Jeder Browser f¨
uhrt in einem speziellen Intervall eine Repaint-Funktion aus. Die-
ses Zeichnungsintervall ist an die Bildwiederholfrequenz des eingesetzten Bild-
schirms angepasst. Unter Verwendung von RequestAnimationFrame (RAF) [21] ist
es m¨
oglich TouchMove-Events an das Zeichnungsintervall zu koppeln, damit die-
se Browser-gesteuert mit einer angepassten Rate verarbeitet werden. Dies w¨
urde
die ¨
Uberlastung des Rechners reduzieren und beispielsweise zu einer weicheren
Bewegung beim Verschieben f¨
uhren. In Abbildung 5.3 ist zu erkennen, dass auf
unterschiedlichen Ger¨
aten durch den Einsatz von RequestAnimationFrame sogar
mehr TouchMove-Events verarbeitet werden.
Unterst¨
utzt wird die RequestAnimationFrame-Funktion durch den AnimationSche-
duler von GWT. Das TouchPanelWidget implementiert hierzu die Schnittstelle
AnimationCallback und die damit verbundene Methode execute, die aufgerufen
36
5.2 Clientseitiges TouchPanel-Widget
Abbildung 5.3: RequestAnimationFrame (RAF) im Einsatz.
wird, sobald der Browser durch einen Callback die Ausf¨
uhrung des n¨
achsten Ereig-
nisses freigibt. Die Anfrage nach der Freigabe des n¨
achsten Ereignisses geschieht
mit der Methode requestAnimationFrame des AnimationSchedulers. Innerhalb
der Methode execute wird ein TouchMove-Event verarbeitet.
Der AnimationScheduler bzw. RequestAnimationFrame hat im Gegensatz zu ei-
ner gew¨
ohnlichen Timer-Implementierung den Vorteil, dass nebenl¨
aufige Ereignis-
se durch den Browser optimiert werden und dass die Verarbeitungsschleife ange-
halten wird, sobald der Browser-Tab mit der Web-Anwendung nicht sichtbar ist.
Dies resultiert in einer reduzierten Nutzung von CPU, GPU und Speicher. Gleich-
zeitig wird auf diese Weise der Akku von mobilen Ger¨
aten geschont.
5.2.2 Symbolische Gesten
Symbolische Gesten werden mithilfe der Klasse SymbolicGesture realisiert. Die
Methode start erzeugt bei einem TouchStart-Event ein neues TouchPoint-Objekt
(siehe Abb. 5.4). Weitere TouchPoint-Objekte erzeugt die Methode move, sobald
der Benutzer TouchMove-Events ausl¨
ost. Alle TouchPoint-Objekte zusammen er-
geben eine symbolische Geste. Ein ausgel¨
ostes TouchEnd-Event f¨
uhrt dazu, dass
die TouchPoint-Objekte unter Verwendung der Methode onGesture des IGesture-
Listeners als Parameter an die Klasse TouchPanelConnector ¨
ubergeben werden.
Der TouchPanelConnector leitet die TouchPoint-Objekte anschließend per RPC-
Methode gestureExecuted an den Server zur Gestenerkennung weiter.
Erzeugt wird eine symbolische Geste erst dann, wenn sich der Finger weiterbewegt
und eine bestimmte Distanz zum Startpunkt besitzt. Dies verhindert, dass symbo-
lische Gesten bereits bei Ausf¨
uhrung einer Tap- oder Double-Tap-Geste erzeugt
werden. Wird der Finger ¨
uber den Rand des Multi-Touch-Bildschirms gezogen,
37
5 Entwicklung eines Multi-Touch-Add-ons
:SymbolicGesture
:TouchPanelWidget :TouchPanelConnector :Server
onGesture(TouchPoints)
onBrowserEvent(onTouchStart)
start(touchPos)
move(touchPos)
end()
onBrowserEvent(onTouchMove)
onBrowserEvent(onTouchEnd)
gestureExecu-
ted(TouchPoints)
confirm()
addElementToSVG(Circle)
addElementToSVG(Circle)
Abbildung 5.4: ¨
Ubertragen einer symbolischen Geste an den Server.
l¨
ost dies ein TouchCancel-Event aus, das die symbolische Geste abbricht.
Die TouchPoint-Objekte einer symbolischen Geste werden auf einem dem Touch-
Panel untergeordneten Canvas als cyanfarbige SVG-Kreise visualisiert. Dies hat
den Vorteil, dass ein Nutzer Feedback ¨
uber die korrekte Darstellung einer symbo-
lischen Geste erh¨
alt und auf m¨
ogliche Fehleingaben besser reagieren kann. Die
Klasse SymbolicGesture f¨
ugt dem Canvas die SVG-Kreise mithilfe der Methode
addElementToSVG hinzu.
5.2.3 Tap-Geste
Die Tap-Geste ist ein einfaches Antippen des Multi-Touch-Bildschirms mit einem
Finger. Durch das Antippen wird die Methode onTapGesture des IGestureLis-
teners aufgerufen, der als Parameter ein TouchPoint-Objekt mit den Koordina-
ten des Ber¨
uhrungspunktes ¨
ubergeben bekommt. Der TouchPanelConnector, der
die Methode onTapGesture implementiert, leitet den Ber¨
uhrungspunkt per RPC-
Methode tapGestureExecuted an den Server weiter. Zu beachten ist, dass die
Ber¨
uhrung des Bildschirms nicht l¨
anger als eine Sekunde dauern darf, da anstelle
einer Tap-Geste sonst eine Hold-Geste ausgef¨
uhrt wird (siehe Abschnitt 5.2.7).
5.2.4 Double-Tap-Geste
Wird der Bildschirm an einer bestimmten Stelle zweimal hintereinander mit ei-
nem Finger angetippt, handelt es sich um eine Double-Tap-Geste. Das zweima-
38
5.2 Clientseitiges TouchPanel-Widget
lige Antippen muss innerhalb einer Sekunde erfolgen, damit es zu einer erfolg-
reichen Ausf¨
uhrung kommt. Anschließend wird die Methode onDoubleTapGesture
des IGestureListeners ausgef¨
uhrt, die den Ber¨
uhrungspunkt als TouchPoint-
Objekt an den TouchPanelConnector weiterleitet. Dieser sendet die Informationen
per RPC-Methode doubleTapGestureExecuted an den Server weiter. Zu beachten
ist, dass bei einer Double-Tap-Geste ebenfalls eine Tap-Geste ausgef¨
uhrt wird.
5.2.5 Pan-Geste
Mit der Pan-Geste ist es m¨
oglich den Bearbeitungsbereich in proView zu verschie-
ben. Der Benutzer verschiebt hierzu lediglich seinen Finger auf dem Bildschirm.
Anders als beim Scrolling wird der Bearbeitungsbereich beim Panning gleichzei-
tig in x- und y-Richtung verschoben. Der Einsatz mehrerer Finger beim Panning
ist ebenfalls m¨
oglich. In diesem Fall wird ein Mittelwert zwischen den Ber¨
uhrungs-
punkten berechnet.
Die Klasse PanGesture ruft w¨
ahrend der Gestenausf¨
uhrung die Methode onPan-
Gesture des IGestureListeners auf. Als Parameter werden die zur¨
uckgelegten
Distanzen (dx, dy)des Fingers in Pixel ¨
ubergeben, die zwischen den einzelnen,
ausgel¨
osten TouchMove-Events ermittelt wurden. Der Connector leitet die Distan-
zen an den Server weiter. Gleichzeitig werden die Distanzen clientseitig direkt an
die horizontale sowie vertikale Scrollleiste des Bearbeitungsbereichs ¨
ubergeben,
damit eine sofortige Verschiebung des Bearbeitungsbereichs stattfindet.
5.2.5.1 Flinging
Unter Flinging versteht man das Verschieben eines Elements mit abnehmender
Geschwindigkeit, nachdem der Finger den Bildschirm nach Ausf¨
uhren einer Pan-
Geste bereits verlassen hat. So ist es m¨
oglich mit nur einem kurzen Wisch ¨
uber
den Bildschirm ein Prozessmodell bzw. den Bearbeitungsbereich von proView um
eine gr¨
oßere Distanz zu verschieben. Je schneller der Benutzer die Pan-Geste
ausf¨
uhrt, desto gr¨
oßer die Distanz beim Flinging, die innerhalb der vier Sekunden
nach dem Start des Flinging zur¨
uckgelegt wird. Aus diesem Grund wird zun¨
achst
die Pan-Geschwindigkeit in Pixel pro Sekunde berechnet (siehe Algorithmus 1, Zei-
le 2 und 3). Hierzu werden die einzelnen vertikalen sowie horizontalen Abst¨
ande,
die sich innerhalb zweier TouchMove-Events ergeben, ermittelt. Der durchschnitt-
liche Wert dieser Abst¨
ande wird durch die durchschnittliche Ausf¨
uhrungszeit der
Pan-Geste dividiert.
39
5 Entwicklung eines Multi-Touch-Add-ons
Algorithm 1 Flinging Algorithmus
1: function START
2: velocityX ←(avgDx ∗1000)/avgT
3: velocityY ←(avgDy ∗1000)/avgT
4: end function
5: function FLING
6: distX ←DISTANCE T IME F ACTOR ∗velocityX
7: distY ←DISTANCE T IME F ACTOR ∗velocityY
8: SCROLLBY(elem, distX, distY, duration)
9: end function
10: function SCROLLBY(elem, distX, distY, duration)
11: now ←curTime
12: curMs ←MIN(duration, now −startTime)
13: x←EASEOUT(curMs, 0, distX, duration)
14: y←EASEOUT(curMs, 0, distY, duration)
15: PANBY(elem, −(x−lastX),−(y−lastY ))
16: lastX ←x
17: lastY ←y
18: if curMs < duration then
19: isFling ←1
20: else
21: isFling ←0
22: end if
23: end function
24: function EASEOUT(t, start, end, duration)
25: t←t
duration −1
26: return end ∗(t3+ 1) + start
27: end function
Die Geschwindigkeit der Pan-Geste wird anschließend mit dem Faktor DISTANCE -
TIME FACTOR multipliziert (Zeile 6 und 7), um gr¨
oßere Distanzen beim Flinging zu
erreichen.
Eine Verlangsamung der Verschiebung beim Flinging kann mittels verschiedener
¨
Ubergangsfunktionen (engl. Easing Functions) realisiert werden, die durch die
Schnittstelle Easing im Paket easing zur Verf¨
ugung gestellt werden. Das Flinging
verwendet eine kubische EaseOut-Funktion, die von der Klasse Cubic implemen-
tiert wird. Diese Funktion wird innerhalb der Methode scrollBy aufgerufen (Zeile
13, 14 und 24), die ¨
ahnlich zu den Touch-Events vom AnimationScheduler aus-
gef¨
uhrt wird. Als ersten Parameter erh¨
alt die EaseOut-Funktion einen Differenzwert
aus dem Startzeitpunkt des Flingings und dem aktuellen Zeitpunkt in Millisekun-
den. Sobald dieser Differenzwert gr¨
oßer als die eigentliche Dauer der Ease Out-
Funktion ist, so ist das Flinging beendet. Das bedeutet, die Variable isFling (Zeile
40
5.2 Clientseitiges TouchPanel-Widget
19 und 21) erh¨
alt nach vier Sekunden den Wert 0, um das Flinging als beendet zu
kennzeichnen. Der zweite und dritte Parameter der Ease Out-Funktion beinhaltet
den Startpunkt und die Distanz der Verschiebung. Der letzte Parameter enth¨
alt die
Dauer des Flinging. Als Ergebnis der Ease Out-Funktion werden die neuen Posi-
tionswerte ausgegeben, die anschließend an die Scrollleiste des Bearbeitungsbe-
reichs ¨
ubergeben werden.
5.2.6 Pinch-Geste
Der Benutzer f¨
uhrt eine Pinch-Geste aus, wenn er zwei Finger auf dem Multi-
Touch-Bildschirm gleichzeitig aufeinander zubewegt oder voneinander weg be-
wegt. Diese Geste findet oft Anwendung in Bildbetrachtungsprogrammen auf mobi-
len Ger¨
aten, um Bilder zu vergr¨
oßern bzw. zu verkleinern. In der proView-Erweite-
rung wird sie daher auf gleiche Weise zur Vergr¨
oßerung und Verkleinerung von
Prozessmodellen verwendet.
Befinden sich genau zwei Finger auf dem Multi-Touch-Bildschirm, l¨
ost dies die
start-Methode der Klasse PinchGesture aus, die mittels dem Satz von Pytha-
goras die Distanz zwischen den beiden Fingern ermittelt. Diese Start-Distanz ist
w¨
ahrend eines TouchMove-Events f¨
ur die Berechnung eines Skalierungsfaktors
notwendig (siehe Listing 5.1), mit dessen Hilfe eine Unterscheidung zwischen Ver-
gr¨
oßerung und Verkleinerung stattfinden kann.
Listing 5.1: Berechnung des Skalierungsfaktors
1newScalefactor = distance / startDistance ;
Besitzt der Skalierungsfaktor einen Wert kleiner als 1, so handelt es sich hierbei
um eine Verkleinerung. Im Gegensatz dazu signalisieren Werte gr¨
oßer als 1 eine
Vergr¨
oßerung. Der Wert 1 ist ein neutraler Wert, d.h. es findet keine Skalierung
statt.
Die Methode onPinchGesture des IGestureListeners erh¨
alt den Skalisierungs-
faktor als Parameter zugewiesen. Des Weiteren erh¨
alt sie als Parameter einen
boolschen Wert isPinchEnd, der bei Ausl¨
osung eines TouchEnd-Events das En-
de einer Pinch-Geste kennzeichnet. Dies ist sp¨
ater bei der Erweiterung von pro-
View relevant (siehe Abschnitt 6.5). Die onPinchGesture-Methode kommt erst zur
Ausf¨
uhrung, wenn w¨
ahrend eines TouchMove-Events die Differenz zwischen altem
und neuem Skalierungsfaktor gr¨
oßer als 0,1 ist. Dies reduziert die Anzahl an RPC-
Aufrufen, die durch die onPinchGesture-Methode und dem TouchPanelConnector
angestoßen werden.
41
5 Entwicklung eines Multi-Touch-Add-ons
5.2.7 Hold-Geste
Ber¨
uhrt der Benutzer l¨
anger als eine Sekunde den Multi-Touch-Bildschirm an ei-
ner Stelle, so handelt es sich hierbei um eine Hold-Geste. Eine Implementierung
dieser Geste befindet sich in der Klasse HoldGesture. Der Finger darf sich da-
bei nicht weiter als 15 Pixel vom Startpunkt entfernen, da dies sonst zum Ab-
bruch der Geste f¨
uhrt. Der Einsatz eines weiteren Fingers f¨
uhrt ebenfalls zum
Abbruch. Bei einer erfolgreichen Ausf¨
uhrung der Hold-Geste wird die Methode
onHoldGesture des IGestureListeners aufgerufen. Diese Methode erh¨
alt als Pa-
rameter den Ber¨
uhrungspunkt als TouchPoint-Objekt, der somit an die Klasse
TouchPanelConnector ¨
ubergeben wird.
5.3 Serverseitige TouchPanel-Komponente
Die serverseitige TouchPanel-Komponente nimmt vom Client gesendete, Gesten-
basierte Daten entgegen und verarbeitet sie entsprechend ihrer Logik weiter. Hier-
zu wird ein Gestenerkenner (siehe Abschnitt 5.3.1) verwendet, der die Daten aus-
wertet und ausgef¨
uhrte Symbol- sowie Strich-Gesten identifiziert. Eine Implemen-
tierung des Gestenerkenners auf Clientseite ist ebenfalls m¨
oglich, ist allerdings f¨
ur
mobile Client-Ger¨
ate mit niedriger Rechenleistung ungeeignet. Deshalb muss der
Gestenerkenner auf einem leistungsst¨
arkeren Server ausgef¨
uhrt werden. Nach ei-
ner erfolgreichen Erkennung der Geste wird ein entsprechendes Gesten-Event er-
zeugt und an die Klassen weitergereicht, die den in Abschnitt 5.3.2 vorgestellten
Gesten-Listener implementiert haben.
5.3.1 $1 Gesture Recognizer
Bei dem $1 Gesture Recognizer handelt es sich um einen Algorithmus, der ver-
schiedene symbolische Gesten erkennen kann [30]. In einem Experiment, das von
den Entwicklern durchgef¨
uhrt worden ist, hat sich herausgestellt, dass der $1 Ge-
sture Recognizer eine nahezu identische Erkennungsgenauigkeit liefert, wie die
beiden wesentlich komplexeren Gestenerkenner Dynamic Time Warping (DTW)
[18] und Rubine [22], die h¨
aufig in Schrifterkennungssoftware eingesetzt werden.
F¨
ur diese Gestenerkenner sind zur Implementierung spezielle Kenntnisse in den
Bereichen K¨
unstliche Intelligenz und Mustererkennung notwendig. Des Weiteren
hat der $1 Gesture Recognizer im Vergleich zu vorhandenen Bibliotheken und Tool-
kits den Vorteil, dass er unabh¨
angig von der verwendeten Programmiersprache, in
jedes Programm integriert werden kann.
42
5.3 Serverseitige TouchPanel-Komponente
Eine symbolische Geste wird zun¨
achst resampelt, rotiert, skaliert, verschoben und
anschließend mit bereits vordefinierten Referenzmustern verglichen. Gleichzeitig
werden die Wahrscheinlichkeiten ermittelt, mit denen die Referenzmuster mit der
symbolischen Geste ¨
ubereinstimmen. Als Ergebnis wird das Referenzmuster mit
der h¨
ochsten Wahrscheinlichkeit zur¨
uckgeliefert. Die einzelnen Schritte sind in den
folgenden Abschnitten genauer erl¨
autert. Der entsprechende Pseudocode befindet
sich im Anhang A.4.
5.3.1.1 Resampling einer Geste
Je nach Multi-Touch-Ger¨
at werden pro Sekunde unterschiedlich viele Touch-Events
ausgel¨
ost, wenn ein Nutzer den Bildschirm mit seinen Fingern ber¨
uhrt. Besonders
kleinere Ger¨
ate wie Smartphones l¨
osen aufgrund ihrer schw¨
acheren Hardware
pro Sekunde weniger Touch-Events aus als leistungsst¨
arkere Desktop-PCs (sie-
he Abb. 5.3). Die Anzahl an ausgel¨
osten Touch-Events pro Sekunde, im Folgen-
den Abtastpunkte genannt, ist f¨
ur die Erkennungswahrscheinlichkeit einer sym-
bolischen Geste besonders kritisch, denn zu wenige Abtastpunkte k¨
onnen dazu
f¨
uhren, dass die symbolische Geste eventuell nicht erkannt wird. Dies ist beson-
ders bei einer schnellen Ausf¨
uhrungsgeschwindigkeit einer Geste der Fall (siehe
Abb. 5.5).
Abbildung 5.5: Ausf¨
uhrung eines Rechteck- und Fragezeichen-Symbols mit unter-
schiedlichen Ausf¨
uhrungsgeschwindigkeiten auf einem Tablet.
Erzeugt eine Geste zu viele Abtastpunkte, wird mehr Rechenleistung ben¨
otigt, um
43
5 Entwicklung eines Multi-Touch-Add-ons
die Geste mit den vordefinierten Referenzmustern zu vergleichen. Bei einer gleich-
zeitig langsamen Ausf¨
uhrungsgeschwindigkeit kann es sogar zu ungeraden Linien
kommen, die eine Erkennung ebenfalls erschweren. Die optimale Anzahl an Ab-
tastpunkten liegt daher bei N= 64 verbunden mit einer mittleren Ausf¨
uhrungs-
geschwindigkeit, um eine Geste mit hoher Wahrscheinlichkeit und mit wenig Re-
chenleistung zu erkennen [30]. Beim Resampling wird die Anzahl der Abtastpunk-
te angepasst, indem Punkte entfernt oder mittels linearer Interpolation hinzugef¨
ugt
werden (siehe Abb. 5.6). Der gleichbleibende Abstand zwischen den einzelnen 64
Abtastpunkten ergibt sich aus der Gesamtl¨
ange des originalen Gesten-Pfades, der
durch (N−1) dividiert wird.
N = 32 N = 64 N = 128
Abbildung 5.6: Zickzack-Symbol bestehend aus N=32, 64 und 128 Abtastpunkten.
5.3.1.2 Rotation
Im zweiten Schritt findet eine Rotation der symbolischen Geste statt. Hierzu wird
der indikative Winkel der Geste bestimmt, der sich aus dem Startpunkt und dem
Mittelpunkt der Geste ergibt. Die Rotation endet, sobald die Geste einen Winkel
von 0◦besitzt (siehe Abb. 5.7).
rotieren
0°
Abbildung 5.7: Rechteck-Symbol wird rotiert, sodass sein indikativer Winkel bei 0◦
liegt.
44
5.3 Serverseitige TouchPanel-Komponente
5.3.1.3 Skalierung und Verschiebung
Die symbolische Geste wird im dritten Schritt auf eine vordefinierte Gr¨
oße skaliert.
Dabei handelt es sich um eine nicht uniforme Skalierung. Die Bounding Box der
Geste besitzt nach abschließender Skalierung eine quadratische Form, mit einer
Kantenl¨
ange von 200 Pixeln. Zu beachten ist, dass eine gezeichnete Gerade nicht
konform skaliert werden kann. Die Erkennung einer gezeichneten Gerade erfolgt
daher ohne Anwendung des $1 Gesture Recognizers nur mithilfe der Bounding
Box der Geste. Hierzu werden die Kantenl¨
angen der Bounding Box miteinander
verglichen, bevor es zur Ausf¨
uhrung des Gestenerkenners kommt. Auch gibt es
Unterscheidungsprobleme zwischen einem Quadrat und Rechteck, sowie einem
Kreis und einer Ellipse, da diese Symbole nach der Skalierung identisch ausse-
hen. Deshalb wird in dieser Arbeit darauf geachtet, dass nur symbolische Gesten
verwendet werden, die sich eindeutig voneinander unterscheiden lassen.
Nachdem eine symbolische Geste skaliert ist, wird anschließend ihr Mittelpunkt
verschoben, sodass dieser sich an der Position (0,0) des Bearbeitungsbereichs in
proView befindet.
5.3.1.4 Gestenerkennung mittels Referenzmuster
Die bisher vorgestellten Verarbeitungsschritte werden ebenfalls auf die davor ab-
gelegten Referenzmuster angewandt. Diese Referenzmuster sind f¨
ur die optimale
Erkennung einer symbolischen Geste wichtig und m¨
ussen daher dieselbe Anzahl
an Abtastpunkten, denselben Winkel und dieselbe Gr¨
oße sowie Position aufwei-
sen, wie die symbolische Geste selbst.
Referenzmuster sind in der XML-Datei templates.xml im Ordner WEB-INF des
TouchPanel-Add-ons abgelegt. Listing 5.2 zeigt einen beispielhaften Aufbau die-
ser XML-Datei.
Listing 5.2: Referenzmuster in templates.xml
1<? xml version =" 1.0 " encoding ="utf -8" standalone =" yes "?>
2<templates >
3<template name =" RECTANGLE " ><pt x="59" y=" 158 " / >... </ template >
4<template name =" DELETE " ><pt x=" 11 " y="58" / >... </ template >
5</templates >
In Zeile 3 und 4 sind zwei unterschiedliche Referenzmuster aufgef¨
uhrt, die jeweils
durch ein template-Tag repr¨
asentiert sind. Innerhalb dieses Tags befinden sich
45
5 Entwicklung eines Multi-Touch-Add-ons
die zu den Referenzmustern geh¨
orenden x- und y-Koordinaten der einzelnen Ab-
tastpunkte. Pro Abtastpunkt wird ein pt-Tag verwendet, dessen Attribute die Koor-
dinaten enthalten.
Die Klasse TemplateList im recognizer-Paket liest die XML-Datei mithilfe des
SAX-Parsers aus und legt einzelne Referenzmuster als Instanz der Klasse Temp-
late in einer LinkedList ab. Da außer einem Lesevorgang keine weiteren Ope-
rationen an der XML-Datei durchgef¨
uhrt werden, ist der SAX-Parser ausreichend.
Die TemplateList nutzt das Singleton-Pattern, um eine wiederholte und rechen-
aufwendige Initialisierung der Liste zur Laufzeit zu vermeiden.
Ein neues Referenzmuster wird zun¨
achst wie eine symbolische Geste gezeich-
net und mit der Methode printTouchPointsToConsole, die sich in der Klasse
GestureRecognizer im recognizer-Paket befindet, auf der Konsole ausgegeben.
Der Entwickler kann die Ausgabe anschließend direkt in die XML-Datei temp-
lates.xml kopieren und das Referenzmuster benennen. Client-Nutzer von pro-
View haben somit keine M¨
oglichkeit eigene Referenzmuster zu erzeugen, die even-
tuell zu einer falsch-positiven Gestenerkennung innerhalb der Web-Anwendung
f¨
uhren k¨
onnten.
Pro symbolischer Geste k¨
onnen im System mehrere Referenzmuster vordefiniert
sein, um die Trefferwahrscheinlichkeit bei der Erkennung zu erh¨
ohen. Bereits bei
einem geladenen Referenzmuster erh¨
alt man eine Trefferwahrscheinlichkeit von
97% (siehe Abb. 5.8). Ab drei geladenen Referenzmustern zu einer Geste erh¨
oht
sich die Trefferwahrscheinlichkeit auf bis zu 99,5% [30]. Auch bei den anderen
Gestenerkennern Rubine und DTW h¨
angt die Erkennungsrate von der Anzahl an
vordefinierten Referenzmustern ab. Je mehr Referenzmuster definiert sind, desto
mehr Rechenleistung ist allerdings f¨
ur die Erkennung notwendig, da die symboli-
sche Geste mit jedem Referenzmuster verglichen werden muss.
W¨
ahrend des Vergleichs wird zun¨
achst eine durchschnittliche Distanz dizwischen
den Abtastpunkten einer Geste Cund den Punkten des Referenzmusters Tiermit-
telt (siehe Gleichung 5.1).
di=
N
P
k=1
p(C[k]x−Ti[k]x)2+ (C[k]y−Ti[k]y)2
N(5.1)
Das Referenzmuster mit der kleinsten Distanz zur Geste ist das Ergebnis der Ge-
stenerkennung. Zur Ermittlung der kleinsten Distanz muss die Geste trotz eines
indikativen Winkels von 0◦weiter rotiert werden, sodass die Geste im optimalen
Winkel zum Referenzmuster steht. Daher wird sie unter Verwendung des Berg-
steigeralgorithmus (engl. hill climbing) iterativ um ±1Grad weiter rotiert, bis die
46
5.3 Serverseitige TouchPanel-Komponente
Abbildung 5.8: Erkennungsfehler sind abh¨
angig von der Anzahl der Referenzmu-
stern pro Geste.
optimale, kleinste Distanz erreicht ist, d.h. sich die Distanz bereits im n¨
achsten
Schritt wieder verschlechtert.
Die ermittelte Distanz wird anschließend in einen Ergebniswert score umgewan-
delt, dessen Wertebereich zwischen 0 und 1 liegt (siehe Gleichung 5.2).
score = 1 −di
1
2√size2+size2(5.2)
¨
Uberschreitet der score den Grenzwert 0,85 gilt die symbolische Geste als er-
kannt. Mehrere Gestenausf¨
uhrungen haben gezeigt, dass bei einer mittleren bis
langsamen Ausf¨
uhrungsgeschwindigkeit, score-Werte ¨
uber 0,9 erreichbar sind,
daher ist im Kontext dieser Arbeit ein Grenzwert von 0,85 gew¨
ahlt worden. Bei Wer-
ten, die unterhalb dieses Grenzwerts liegen, wird die eingegebene Geste ignoriert
bzw. muss vom Benutzer erneut ausgef¨
uhrt werden.
Die Variable size in der Gleichung entspricht der Kantenl¨
ange einer Geste nach
ihrer Skalierung.
5.3.2 Gesten-Listener und -Events
Das TouchPanel gibt Informationen ¨
uber physikalische sowie symbolische Ge-
sten mittels Ereignissen an andere Klassen weiter. Diese Klassen m¨
ussen die
Schnittstelle ITouchPanelGestureListener implementiert haben, um auf Gesten-
Ereignisse zu reagieren. In diesem Fall ist es die proView-Klasse BPMN Appearance,
die eine Implementierung der Schnittstelle enth¨
alt. Im Folgenden werden die ein-
zelnen Ereignisse, die ausgel¨
ost werden k¨
onnen, genauer beschrieben.
47
5 Entwicklung eines Multi-Touch-Add-ons
TouchPanelDoubleTapGestureEvent Dieses Ereignis wird ausgel¨
ost, sobald der
Nutzer eine Double-Tap-Geste auf dem Multi-Touch-Bildschirm ausf¨
uhrt. Die
Methode des ITouchPanelGestureListeners, die hierf¨
ur implementiert wer-
den muss, heißt doubleTapGestureExecuted. Das TouchPanelDoubleTap-
GestureEvent enth¨
alt die Quelle des Ereignisses und den Ber¨
uhrungspunkt
der ausgef¨
uhrten Double-Tap-Geste.
TouchPanelGestureEvent Symbolische Gesten l¨
osen ein TouchPanelGesture-
Event aus. Dieses Ereignis enth¨
alt die Ausf¨
uhrungsquelle, Abtastpunkte, Mit-
telpunkt und Bounding Box der Geste. Ebenfalls enthalten ist das Ergebnis
des Gestenerkenners, das aus dem Gestentyp und Score besteht. ¨
Uber-
geben werden diese Informationen an die Implementierung der Methode
gestureExecuted des ITouchPanelGestureListeners.
TouchPanelHoldGestureEvent Verweilt der Finger des Nutzers f¨
ur mehr als ei-
ne Sekunde an einer Stelle auf dem Multi-Touch-Bildschirm, wird ein Touch-
PanelHoldGestureEvent ausgel¨
ost. Die Informationen, die dieses Ereignis
enth¨
alt, sind die Quelle des Ereignisses und der Ber¨
uhrungspunkt. Das Er-
eignis wird an die Methode holdGestureExecuted ¨
ubergeben.
TouchPanelPanGestureEvent Das TouchPanelPanGestureEvent wird ausgel¨
ost,
wenn der Benutzer seinen Finger auf dem Multi-Touch-Bildschirm verschiebt.
Die Abst¨
ande (dx, dy)zwischen den einzelnen Abtastpunkten w¨
ahrend der
Gestenausf¨
uhrung, sind in diesem Ereignis enthalten. Ebenfalls enthalten ist
die Quelle des Ereignisses. Zur Weiterverarbeitung wird die Geste an die
Methode panGestureExecuted des ITouchPanelGestureListeners ¨
uberge-
ben. F¨
ur die serverseitige proView-Erweiterung ist dieses Ereignis nicht von
großer Relevanz, da Pan-Gesten bereits clientseitig verarbeitet werden und
direkt an den Bearbeitungsbereich mit den Prozessmodellen ¨
ubergeben wer-
den. Das TouchPanelPanGestureEvent wird hier lediglich f¨
ur zuk¨
unftige Ar-
beiten zur Verf¨
ugung gestellt.
TouchPanelPinchGestureEvent Eine Pinch-Geste f¨
uhrt die Vergr¨
oßerung sowie
Verkleinerung des Prozessmodells herbei. Hierzu wird das TouchPanelPin-
chGestureEvent ausgel¨
ost, das einen Skalierungsfaktor und einen boolschen
Wert isPinchEnd enth¨
alt. Der Skalierungsfaktor ist zur Unterscheidung zwi-
schen Vergr¨
oßerung und Verkleinerung wichtig. Gleichzeitig gibt er an, wie
stark skaliert werden soll. Der boolsche Wert isPinchEnd signalisiert ledig-
lich das Ende einer Pinch-Geste. Das Ereignis wird an die Methode pinch-
GestureExecuted des ITouchPanelGestureListeners zur Weiterverarbei-
tung ¨
ubergeben.
48
5.4 Emulation von Touch-Events
TouchPanelTapGestureEvent Ein kurzes Antippen des Bildschirms f¨
uhrt eben-
falls zu einem Ereignis. Dieses TouchPanelTapGestureEvent enth¨
alt Informa-
tionen zur Quelle des Ereignisses sowie Positionsangaben des Ber¨
uhrungs-
punktes, die an die Methode tapGestureExecuted weitergegeben werden.
5.4 Emulation von Touch-Events
Da das Testen des TouchPanel-Add-ons auf einem Multi-Touch-f¨
ahigen Ger¨
at sehr
zeitaufwendig sein kann, bietet es sich an einen Emulator zu verwenden, der
Touch-Events auf dem Desktop-PC simulieren kann.
Es gibt Emulatoren f¨
ur Betriebssysteme sowie f¨
ur bestimmte Browser. Diese ha-
ben allerdings diverse Nachteile. F¨
ur den Firefox-Browser gibt es zum Beispiel
ein Multi-Touch-Emulator-Add-on. Dieses ist allerdings seit 2010 nicht mehr wei-
terentwickelt worden und mit neueren Firefox-Versionen nicht mehr kompatibel.
Der Chrome-Browser besitzt einen integrierten Touch-Event-Emulator, der ¨
uber die
Web-Entwickler Eigenschaften aktiviert werden kann. Dieser Emulator unterst¨
utzt
jedoch keine Multi-Touch-Eingaben (außer auf Apple MacBook oder MagicPad),
die beispielsweise zur Ausf¨
uhrung von Pinch-Gesten notwendig sind. F¨
ur das Be-
triebssystem Windows 7 sind keine Emulatoren vorhanden, sondern nur ein Emu-
lator f¨
ur die Vorg¨
angerversion Windows Vista, den der Benutzer wie einen gew¨
ohn-
lichen Treiber installiert.
Aufgrund dieser Umst¨
ande besitzt das TouchPanel einen integrierten Emulator, mit
dem es m¨
oglich ist, einzelne Touch-Events sowie Multi-Touch-Events auszul¨
osen.
Die einzelnen Touch-Events werden mittels gew¨
ohnlicher Mouse-Events simuliert.
F¨
ur die Simulation von Multi-Touch-Events wird jedoch mindestens ein weiterer
Ber¨
uhrungspunkt ben¨
otigt. Durch einen Doppelklick wird ein weiterer fester Punkt
im Bearbeitungsbereich platziert, der den Einsatz eines zweiten Fingers simu-
liert. Bei gedr¨
uckter, linker Maustaste und einer Bewegung des Mauszeigers Rich-
tung zweiten Ber¨
uhrungspunkt bzw. in entgegengesetzte Richtung, wird ein Pinch-
Ereignis ausgel¨
ost.
Diese Emulation von Touch-Events l¨
asst sich in proView jederzeit ¨
uber die obere
Men¨
uleiste der Anwendung aktivieren bzw. deaktivieren. Im Programm wird hierf¨
ur
die Methode setMouseMode(true) bzw. setMouseMode(false) des TouchPanels
verwendet.
49
5 Entwicklung eines Multi-Touch-Add-ons
50
6 Erweiterung des proView-Frameworks
Dieses Kapitel diskutiert die Erweiterung des bestehenden proView-Frameworks,
um Gesten-basierte Prozessmodellierung zu erm¨
oglichen. An dieser Stelle kommt
das TouchPanel-Add-on zum Einsatz, das in Kapitel 5 bereits ausf¨
uhrlich beschrie-
ben ist. Das TouchPanel wird in das proView-Projekt integriert (siehe Abschnitt 6.1)
und die vom TouchPanel ausgel¨
osten Gesten-Ereignisse mit den entsprechenden
proView-Funktionen verkn¨
upft. Abschnitt 6.2 behandelt hierbei die symbolischen
Gesten und die Abschnitte 6.3 bis 6.6 beziehen sich auf physikalische Gesten.
6.1 Integration des TouchPanel-Add-ons
In Form einer JAR-Bibliothek wird das TouchPanel-Add-on in den WEB-INF/lib-
Ordner des proView-Projekts kopiert. Dieses Projekt enth¨
alt die Klasse BPMN -
Appearance, die im Wesentlichen f¨
ur die Visualisierung von BPMN-Prozessmodel-
len zust¨
andig ist. Sie besteht aus mehreren ineinander verschachtelten Vaadin-
Layouts und -Panels. Eines davon ist das Panel processVisPanel, das durch das
TouchPanel ersetzt wird (siehe Abb. 6.1).
BPMN_Appearance
TouchPanel
SVG-Canvas
Abbildung 6.1: Integration des TouchPanels in die Klasse BPMN Appearance.
Als Unterobjekt ist diesem Panel ein Canvas zugeordnet, das Prozessmodelle als
SVG-Grafik darstellt. Dieses Canvas bekommt eine eindeutige ID mit der Bezeich-
nung ”canvas“ zugewiesen. Dieselbe ID wird auch dem TouchPanel-Objekt als
51
6 Erweiterung des proView-Frameworks
Parameter im Konstruktor ¨
ubergeben, um eine eindeutige Verkn¨
upfung zwischen
TouchPanel und Canvas zu erhalten. Zum Beispiel ist es wichtig, dass Pan-Gesten
clientseitig direkt vom TouchPanel-Widget an das Canvas ¨
ubergeben werden, um
das im Canvas enthaltene Prozessmodell mit der Geste zu verschieben. Ein ”Um-
weg“ ¨
uber den Server f¨
uhrt zu einer zu hohen Latenzzeit bzw. einer ruckelnden
Verschiebung.
Damit vom TouchPanel ausgel¨
oste Ereignisse bei der Klasse BPMN Appearance
ankommen, implementiert diese das ITouchPanelGestureListener-Interface. Mit
der Methode addGestureListener registriert sich die Klasse als Listener beim
TouchPanel.
Um die bereits in Abschnitt 5.4 beschriebene Emulation von Touch-Events mittels
Mauszeiger zu erm¨
oglichen, wird die Men¨
uleiste von proView modifiziert. Durch
einen zus¨
atzlichen Eintrag im Men¨
u von proView kann der Benutzer zwischen
Maus- und Touch-Modus wechseln (siehe Abb. 6.2a). Der entsprechende Men¨
u-
eintrag hierzu lautet ”Enable Touch Mode“. Die Aktivierung des Maus-Modus ruft
die Methode setMouseMode(true) des TouchPanel-Objekts auf. Dem gegen¨
uber
ist mit derselben Methode und einem negativen Parameterwert wieder ein Wech-
sel zum Touch-Modus m¨
oglich. Standardm¨
aßig ist der Maus-Modus jedoch deak-
tiviert.
Abbildung 6.2: Den Touch-Modus aktivieren a) und zwischen Ansichts- und Bear-
beitungsmodus wechseln b).
Das TouchPanel unterst¨
utzt außer der Emulation von Maus- und Touch-Events
noch zwei weitere Modi: Den Ansichts- und Bearbeitungsmodus. Der Ansichts-
modus dient dazu, dass der Benutzer ein Prozessmodell problemlos verschieben
sowie vergr¨
oßern kann, ohne dass es zu einer (unerw¨
unschten) Manipulation von
Prozesselementen kommt. Eine Manipulation des Prozessmodells ist nur im Be-
arbeitungsmodus m¨
oglich. Diese Trennung hat zudem den Vorteil, dass manche
52
6.2 Symbolische Gesten
Gesten, wie zum Beispiel die Pinch-Geste, zweimal mit einer Funktion belegt wer-
den k¨
onnen.
Der Wechsel zwischen den beiden Modi wird durch einen Switch-Button realisiert,
der sich auf dem Canvas in der oberen, linken Ecke befindet (siehe Abb. 6.2b). Das
Antippen oder Anklicken dieses Switch-Buttons f¨
uhrt zu einer Ausf¨
uhrung der Me-
thode setMode des TouchPanel-Objekts. Diese Methode erh¨
alt, je nachdem wel-
cher Modus aktiviert wird, einen boolschen Wert, damit das TouchPanel die rich-
tigen Ereignisse ausl¨
ost. Gleichzeitig ¨
andert sich das Symbol des Switch-Buttons,
um den aktivierten Modus zu kennzeichnen.
Die Gr¨
oße des TouchPanels muss sich initial an die Gr¨
oße des ¨
ubergeordne-
ten Layout-Objektes processContent anpassen, daher ist es notwendig zu Be-
ginn der Ausf¨
uhrung die Methoden setHeight und setWidth des TouchPanel-
Objektes aufzurufen. Diese Methoden erhalten als Parameter die entsprechen-
den Gr¨
oßen zugewiesen. Wenn sich das Browserfenster vergr¨
oßert oder verklei-
nert, l¨
ost dies ein Ereignis aus, auf das die Methode resize innerhalb der Klasse
BPMN Appearance reagiert. Diese Methode enth¨
alt ebenfalls eine Anweisung zur
Anpassung der TouchPanel-Gr¨
oße.
Aufgrund der Nutzung der ITouchPanelGestureListener-Schnittstelle seitens der
BPMN Appearance-Klasse sind weitere Methoden-Implementierungen notwendig,
die auf die in Abschnitt 5.3.2 beschriebenen TouchPanel-Ereignisse reagieren.
Diese Methoden sowie deren Implementierung werden im Folgenden erl¨
autert.
6.2 Symbolische Gesten
Mithilfe der Methode gestureExecuted ist die Klasse BPMN Appearance in der Lage
im Bearbeitungsmodus auf symbolische Gesten zu reagieren. Die Methode besitzt
als Parameter das TouchPanelGesture-Event, das alle notwendigen Informationen
zur Geste enth¨
alt. Dies ist unter anderem ein Score-Wert sowie der Typ der Geste.
Zun¨
achst findet eine ¨
Uberpr¨
ufung des Score-Wertes statt, der einen Wert gr¨
oßer
als 0,85 enthalten muss. Ist dies nicht der Fall, wird die Geste ignoriert. Ein passen-
der Score-Wert leitet die anschließende Untersuchung des Gestentyps ein, damit
die Geste entsprechend verarbeitet werden kann. Der Winkel einer Geste spielt
¨
ubrigens f¨
ur eine korrekte Erkennung keine Rolle und hat auch keinen großen
Einfluss auf den Score-Wert. So k¨
onnen Benutzer Gesten beispielsweise auch in
einem 90 Grad Winkel auf dem Multi-Touch-Bildschirm zeichnen.
Da das TouchPanel sehr viele unterschiedliche Symbol-Typen unterst¨
utzt, behan-
53
6 Erweiterung des proView-Frameworks
delt die Methode gestureExecuted auch entsprechend viele F¨
alle, die in den Ab-
schnitten 6.2.1 bis 6.2.8 n¨
aher beschrieben sind.
6.2.1 L¨
oschen-Symbol
Erkennt der Gestenerkenner des TouchPanels das L¨
oschen-Symbol (siehe Abb.
3.8), ermittelt dieser daraufhin das zu l¨
oschende Prozesselement. Hierzu wird
der Mittelpunkt der Geste aus dem TouchPanelGesture-Event ausgelesen und an
die Methode getElementFromPoint ¨
ubergeben. Diese Methode ermittelt anschlie-
ßend das involvierte Prozesselement. Dabei durchl¨
auft sie in einer Schleife alle
Aktivit¨
aten sowie Verzweigungsknoten des Prozessmodells und vergleicht gleich-
zeitig deren Position und Gr¨
oße mit dem ¨
ubergebenen Mittelpunkt. Ist eine Aktivit¨
at
gefunden, deren Position mit der Position des Gesten-Mittelpunkts ¨
ubereinstimmt,
ist diese Aktivit¨
at das Resultat der Methode getElementFromPoint. Stimmen die
Positionen allerdings nicht ¨
uberein, so wird ein Null-Objekt zur¨
uckgeliefert und die
symbolische Geste l¨
ost somit keine Reaktion aus.
Ein erfolgreich ermitteltes Prozesselement gelangt anschließend als Parameter zu
der bereits in proView implementierten Methode deleteNode. Diese Methode ist
Bestandteil der ModellingService-Schnittstelle in proView, die auch f¨
ur weitere
Modellierungsfunktionen verantwortlich ist. Die Methode deleteNode entfernt das
Prozesselement endg¨
ultig aus dem Prozessmodell.
6.2.2 Rechteck-Symbol
Das Rechteck-Symbol ist f¨
ur unterschiedliche Modellierungsfunktionen in proView
relevant. Mit diesem Symbol lassen sich mehrere Prozesselemente zusammenfas-
sen bzw. aggregieren und es dient unter anderem dazu, eine neue Prozesssicht
oder einen neuen Verzweigungsblock zu erstellen. Diese Modellierungsfunktionen
werden allerdings nicht direkt ausgef¨
uhrt, sondern in einem sich ¨
offnenden Kon-
textmen¨
u angeboten. Der Benutzer kann mithilfe dieses Men¨
us die gew¨
unschte
Modellierungsfunktion ausf¨
uhren.
Die Methode getElementsFromRectangle ermittelt zun¨
achst die vom Rechteck
umschlossenen Prozesselemente. Sie erh¨
alt als Parameter die Bounding Box der
ausgef¨
uhrten Geste. Eine Schleife durchl¨
auft alle Aktivit¨
aten sowie Verzweigungs-
knoten des Prozessmodells und pr¨
uft, ob sich ein komplettes Prozesselement in-
nerhalb der Bounding Box befindet. Ragt beispielsweise eine Aktivit¨
at aufgrund
ihrer Gr¨
oße ¨
uber den Rand der Bounding Box hinaus, so wird sie nicht mitgez¨
ahlt.
54
6.2 Symbolische Gesten
Alle anderen Aktivit¨
aten gelangen in einem ArrayList-Objekt als Resultat an die
Methode showTouchMenu. Gleichzeitig erh¨
alt diese Methode als Parameter die Po-
sition des letzten Ber¨
uhrungspunktes, da an dieser Stelle das Kontextmen¨
u er-
scheint.
Die showTouchMenu-Methode ermittelt die Anzahl der ausgew¨
ahlten Prozessele-
mente und erzeugt anschließend das Kontextmen¨
u. Abh¨
angig von der Anzahl an
Prozesselementen, variieren die Eintr¨
age im Kontextmen¨
u. Die beiden Modellie-
rungsfunktionen zur Erzeugung eines XOR- oder AND-Verzweigungsblocks zum
Beispiel, setzen eine Anzahl von genau zwei Prozesselementen voraus. Ist diese
Anzahl nicht gegeben, sind diese Modellierungsfunktionen im Kontextmen¨
u auch
nicht vorhanden.
Das Antippen eines Men¨
u-Eintrags l¨
ost ein ContextMenuItemClick-Event aus,
auf das die Methode contextMenuItemClicked reagiert. Diese Methode ermittelt
den angetippten Men¨
ueintrag und f¨
uhrt mit der ModellingService-Schnittstelle die
passenden Modellierungsfunktionen aus. So f¨
uhrt sie zum Beispiel die Methode
createViewFromSubprocessAndNodes aus, wenn aus den ausgew¨
ahlten Prozess-
elementen eine neue Prozesssicht erstellt werden soll. Die Methode aggregate-
NodeIds des Modelling-Services ist zust¨
andig, Prozesselemente zu aggregieren
und die Methoden insertConditional sowie insertParallel sind f¨
ur die Erstel-
lung neuer Verzweigungsbl¨
ocke verantwortlich.
6.2.3 Rechteck-Symbol mit Diagonale
Prozesselemente lassen sich mit einem Rechteck-Symbol, das zus¨
atzlich einen
diagonalen Strich von der oberen, linken Ecke zur unteren, rechten Ecke besitzt,
reduzieren. Die Ermittlung der Prozesselemente, die von der Geste betroffen sind,
geschieht wie in Abschnitt 6.2.2 mit der Methode getElementsFromRectangle.
Auch in diesem Fall erh¨
alt diese Methode die Bounding Box der symbolischen
Geste als Parameter.
Im Gegensatz zum vorherigen Rechteck-Symbol erscheint hier nach Gestenaus-
f¨
uhrung kein Kontextmen¨
u, sondern die entsprechenden Prozesselemente werden
sofort reduziert. Zu diesem Zweck gibt es die Methode reduceNodeIds der Model-
lingService-Schnittstelle, die als Parameter ein Set-Objekt mit allen ausgew¨
ahl-
ten Prozesselementen erh¨
alt.
55
6 Erweiterung des proView-Frameworks
6.2.4 Strich-Symbol
Strich-Symbole sind sowohl f¨
ur Synchronisations-, Lese- und Schreibkanten, als
auch zum Einf¨
ugen neuer Aktivit¨
aten relevant. Als erstes ermittelt die Methode
distance nach Gestenausf¨
uhrung die Strichl¨
ange. Diese Methode erh¨
alt als Pa-
rameter den Start- sowie den Endpunkt des Strichs. Strich-Symbole, die kleiner
als 40 Pixel sind, werden ignoriert. Der Grund hierf¨
ur ist, dass es sich bei einer
ausgef¨
uhrten Tap-Geste ebenfalls um ein Strich-Symbol handeln k¨
onnte.
Es wird ebenfalls gepr¨
uft, ob die Endpunkte des Strich-Symbols auf ein und dem-
selben Prozesselement liegen. Die Methode getElementFromPoint bekommt die
Endpunkte zugewiesen und ermittelt die Prozesselemente auf denen sie liegen.
Bei ein und demselben Prozesselement sind keine weiteren Aktionen definiert.
Liegt der Startpunkt des Strich-Symbols auf einem Datenelement und der End-
punkt auf einer Aktivit¨
at, so handelt es sich hierbei um eine Lesekante und im
umgekehrten Fall um eine Schreibkante. Bei diesen Kanten finden keine weiteren
Aktionen statt, da die Funktionen zum Einf¨
ugen einer neuen Lese- sowie Schreib-
kante noch nicht Bestandteil des proView-Frameworks sind.
Liegen beide Endpunkte auf zwei unterschiedlichen Aktivit¨
aten innerhalb eines
AND-Verzweigungsblocks, wird eine neue Synchronisationskante zwischen diesen
beiden Aktivit¨
aten eingesetzt. Dies geschieht mithilfe der Methode insertSyncEdge
der ModellingService-Schnittstelle. Sie erh¨
alt die beiden ermittelten Aktivit¨
aten
als Parameter. Die Richtung der Synchronisationskante h¨
angt von den Positionen
der Endpunkte des Strich-Symbols ab, die auf den Aktivit¨
aten liegen.
Ermittelt die Methode getElementFromPoint f¨
ur beide Endpunkte keine Prozess-
elemente, geht die Anwendung davon aus, dass sie eine neue Aktivit¨
at einf¨
ugen
soll. Deshalb kommt es zum Aufruf der Methode insertActivity, die pr¨
uft, ob es
sich um ein vertikales oder horizontales Strich-Symbol handelt. Je nachdem wird
anschließend die Methode insertActivityWithVerticalStroke oder insertAc-
tivityWithHorizontalStroke ausgef¨
uhrt. Bei beiden Methoden findet zun¨
achst
eine Erweiterung der Bounding Box der Geste statt. Ein vertikaler Strich f¨
uhrt da-
zu, dass sich die H¨
ohe der Bounding Box um 20 Pixel und die Breite um 80 Pixel
vergr¨
oßert (siehe Abb. 6.3a). Bei horizontalen Strichen vergr¨
oßert sich die Brei-
te um 20 Pixel und die H¨
ohe um 80 Pixel. Diese Erweiterung der Bounding Box
dient dazu, Prozesselemente in der N¨
ahe der Geste zu ermitteln. Daher muss der
Benutzer beim Zeichnen des Strich-Symbols die Entfernung zu anderen Prozess-
elementen beachten.
Alle Prozesselemente werden in einer Schleife durchlaufen, um ¨
Uberschneidungen
56
6.2 Symbolische Gesten
a)
c)b)
Abbildung 6.3: Erweiterung der Bounding Box.
der Prozesselemente mit der erweiterten Bounding Box des Strich-Symbols zu fin-
den. Handelt es sich bei einem der entdeckten Prozesselemente um ein XOR- oder
AND-Split und besitzt dieser Verzweigungsknoten drei Zweige, f¨
ugt die Methode
insertActivityWithVerticalStroke auf dem mittleren Zweig eine neue Aktivit¨
at
ein (siehe Abb. 6.3b). Die Methode insertActivityWithHorizontalStroke pr¨
uft
dahingegen noch zus¨
atzlich, ob der Verzweigungsknoten oberhalb oder unterhalb
des Strich-Symbols liegt. Abh¨
angig davon wird eine neue Aktivit¨
at auf dem ersten
oder auf dem zweiten bzw. dritten Zweig eingef¨
ugt, wenn der Verzweigungsblock
aus drei Zweigen besteht (siehe Abb. 6.3c).
Ermittelt die Methode insertActivityWithVerticalStroke zwei Aktivit¨
aten bzw.
ein Start- oder End-Ereignis, pr¨
uft sie anschließend, ob diese mittels einer Se-
quenzflusskante miteinander verbunden sind. Erst dann setzt sie zwischen diesen
Prozesselementen eine neue Aktivit¨
at ein. Bei nur einem gefundenen Prozessele-
ment pr¨
uft die Methode ebenfalls, ob dieses mit einem anderen per Sequenzflus-
skante verbunden ist. Auf diese Weise ist es m¨
oglich Datenelemente oder sonstige
unerw¨
unschte Prozesselemente auszuschließen.
Neue Aktivit¨
aten werden mit der Methode insertSerial eingef¨
ugt, die Bestandteil
der ModellingService-Schnittstelle ist.
6.2.5 Pfeil-Symbol
Das Pfeil-Symbol ist zum Einf¨
ugen eines neuen Zweiges innerhalb eines Verzwei-
gungsblocks notwendig. Der Startpunkt der Geste muss sich auf einem XOR- oder
AND-Split befinden. Zur Ermittlung des darunterliegenden Prozesselements ist die
Methode getElementFromPoint zust¨
andig. Die Pfeilspitze muss sich dahingegen
57
6 Erweiterung des proView-Frameworks
auf keinem speziellen Prozesselement befinden. Es muss jedoch darauf geachtet
werden, dass der Pfeil nach oben ausgerichtet ist.
Neue Verzweigungen setzt die Methode insertBranch der ModellingService-
Schnittstelle in das Prozessmodell ein. Diese Methode ben¨
otigt allerdings zu ei-
nem Split-Gateway auch das dazugeh¨
orige Join-Gateway. Beide Gateways, so-
wie andere Prozesselemente auch, besitzen in proView eine eindeutige ID. Wenn
die ID eines Split-Gateways nist, dann ist die ID eines Join-Gateways immer
n+1, da das System beide Prozesselemente beinahe zeitgleich in ein Prozessmo-
dell eingef¨
ugt. Aus diesem Grund wird das zu einem Split-Gateway zugeh¨
orige
Join-Gateway ¨
uber dessen ID, sowie mithilfe der Methode getNode der Klasse
BPMN ProcessVisualisationComponent ermittelt und an die insertBranch-Me-
thode ¨
ubergeben.
6.2.6 Halbes Rechteck-Symbol
Halbe Rechtecke dienen dazu, Schleifen in das Prozessmodell einzuzeichnen. Die
beiden Endpunkte der Geste erh¨
alt die Methode getElementFromPoint als Pa-
rameter, um die Prozesselemente zu ermitteln, auf denen die Endpunkte liegen.
Handelt es sich bei den ermittelten Prozesselementen um Aktivit¨
aten oder Ver-
zweigungsknoten, kann die Schleife eingef¨
ugt werden. Die Schnittstelle Model-
lingService stellt die Methode insertLoop zur Verf¨
ugung, die als Parameter ein
ArrayList-Objekt mit den beiden Prozesselementen zugewiesen bekommt. Bei ei-
ner erfolgreichen Ausf¨
uhrung der Methode, wird die Schleife in das Prozessmodell
eingef¨
ugt, ansonsten l¨
ost der proView-Server eine Exception aus.
6.2.7 Zickzack-Symbol
Das Zickzack-Symbol dient dazu, einen bestehenden Subprozess aufzul¨
osen oder
eine zuletzt ausgef¨
uhrte Aktion wieder r¨
uckg¨
angig zu machen. Die Aufl¨
osung ei-
nes expandierten Subprozesses findet nur dann statt, wenn sich der Startpunkt
der Geste innerhalb des Subprozesses befindet. Um diese Bedingung zu ¨
uber-
pr¨
ufen, kommt an dieser Stelle die Methode subprocessOperations zum Einsatz.
Sie ¨
uberpr¨
uft mit der Methode getElementFromPoint, ob der Startpunkt auf ei-
nem Subprozess liegt oder nicht. Der Startpunkt, den die Methode als Parame-
ter erh¨
alt, ist im TouchPanelGesture-Event enthalten. Dieses Ereignis besitzt alle
Ber¨
uhrungspunkte der ausgef¨
uhrten Geste.
Befindet sich der Startpunkt auf einem Subprozess, der sich im expandierten Zu-
58
6.3 Tap-Geste
stand befindet, l¨
ost dies die Methode undoOperations der Schnittstelle Modelling-
Service aus. Diese Methode erh¨
alt als Parameter den Subprozess, der aufgel¨
ost
werden soll. F¨
uhrt der Benutzer dieselbe Geste auf einer freien Fl¨
ache des Hin-
tergrunds aus, l¨
ost dies eine Funktion zum R¨
uckg¨
angig machen der letzten Aktion
aus. Diese Funktion ist allerdings noch nicht Bestandteil des proView-Frameworks.
6.2.8 Fragezeichen-Symbol
Mithilfe des Fragezeichen-Symbols kann der Benutzer ein Hilfe-Dialog ¨
offnen, der
alle Gesten samt zugeh¨
origer Modellierungsfunktionen beschreibt (siehe Abb. 6.4).
Die Gestenausf¨
uhrung l¨
ost die Methode openGesturesWindow aus. In dieser Me-
thode wird ein neues GesturesWindow-Objekt initialisiert, das f¨
ur die Erzeugung
des Dialog-Layouts zust¨
andig ist.
Abbildung 6.4: Hilfe-Dialog.
6.3 Tap-Geste
Unter Verwendung der Tap-Geste im Ansichts- oder Bearbeitungsmodus, kann der
Benutzer ein einzelnes Prozesselement selektieren, das sich in proView anschlie-
ßend farblich von den anderen Prozesselementen hervorhebt. Das Properties-
59
6 Erweiterung des proView-Frameworks
Panel zeigt weitere Informationen zu diesem selektierten Prozesselement an, wie
zum Beispiel dessen ID.
Tap-Ereignisse nimmt die Methode tapGestureExecuted der Klasse BPMN Appea-
rance entgegen, die die Position des Ber¨
uhrungspunktes aus dem TouchPanel-
TapGesture-Event ausliest und an die Methode setSelectedElement des Objekts
BPMN ProcessVisualisationComponent ¨
ubergibt.
6.4 Double-Tap-Geste
Die Double-Tap-Geste ist im Bearbeitungsmodus zum Umbenennen von Prozess-
elementen relevant. Durch doppeltes Antippen einer Aktivit¨
at, ¨
offnet sich zum Bei-
spiel ein neues Dialog-Fenster, in das der Benutzer den neuen Name f¨
ur die Akti-
vit¨
at eingeben kann.
Eine Double-Tap-Geste l¨
ost ein TouchPanelDoubleTapGesture-Event aus, das die
Methode doubleTapGestureExecuted der Klasse BPMN Appearance abf¨
angt. Die-
ses Ereignis beinhaltet die genaue Position des Ber¨
uhrungspunktes, die notwen-
dig ist, um das ausgew¨
ahlte Prozesselement zu ermitteln. F¨
ur diese Aufgabe ist
die Methode getElementFromPoint zust¨
andig, die als Ergebnis entweder ein Pro-
zesselement oder ein Null-Objekt zur¨
uckliefert. Bei einem erfolgreich ermittelten
Prozesselement wird dieses an die Methode renameNode ¨
ubergeben, die Bestand-
teil der ModellingService-Schnittstelle ist.
6.5 Pinch-Geste
Die Pinch-Geste ist im Ansichtsmodus zum Vergr¨
oßern oder Verkleinern des Pro-
zessmodells relevant. Eine Implementierung der Methode pinchGestureExecuted
in der Klasse BPMN Appearance erm¨
oglicht das Abfangen des TouchPanelPinch-
Gesture-Events, das weitere Informationen, wie beispielsweise den Skalierungs-
faktor, enth¨
alt.
Der Skalierungsfaktor wird nicht direkt an eine Methode zur Visualisierung des Pro-
zessmodells ¨
ubergeben, sondern an eine vorhandene Slider-Komponente. Diese
Slider-Komponente gibt dann die Skalierungsdaten an die Visualisierungskompo-
nente weiter.
Damit die Skalierung nach der Gestenausf¨
uhrung bestehen bleibt, ist die im Touch-
PanelPinchGesture-Event enthaltene boolsche Variable isPinchEnd notwendig.
60
6.6 Hold-Geste
Diese signalisiert das Ausf¨
uhrungsende der Geste, sodass die Skalierung erhal-
ten bleibt.
6.6 Hold-Geste
Der Benutzer kann Subprozesse mit der Hold-Geste entweder aufklappen oder zu-
klappen. Das TouchPanelHoldGesture-Event wird mit der Methode holdGesture-
Executed abgefangen. Dieses Ereignis enth¨
alt die Startkoordinaten des Ber¨
uh-
rungspunktes, die die Methode subprocessOperations weiter verarbeitet. Sie er-
mittelt, ob der Benutzer die Hold-Geste auf einem Subprozess angewendet hat. Ist
dies der Fall, pr¨
uft die Methode anschließend, ob sich der Subprozess im expan-
dierten oder im kollabierten Zustand befindet.
Ein expandierter Subprozess l¨
ost die Methode hideSubprocess aus, die den Sub-
prozess zuklappt. Hierzu ist die Methode removeExpandedSubProcess notwendig,
die von der Klasse BPMN ProcessVisualisationComponent bereitgestellt wird.
Zum Aufklappen eines Subprozesses ist die Methode showSubprocess zust¨
andig,
die auf die Methode addExpandedSubProcess zugreift, um einen Subprozess in
den expandierten Zustand zu ¨
uberf¨
uhren.
61
6 Erweiterung des proView-Frameworks
62
7 Evaluation der Implementierung
Im Rahmen dieser Arbeit ist eine experimentelle Untersuchung der proView-Er-
weiterung durchgef¨
uhrt worden. An diesem Experiment nehmen mehrere unter-
schiedliche Testpersonen teil, die mithilfe der implementierten Multi-Touch-Gesten
ein bestehendes Prozessmodell bearbeiten m¨
ussen. Zuvor m¨
ussen sie sich aller-
dings in einem ersten Teil eigene Gesten f¨
ur die in dieser Arbeit eingesetzten Mo-
dellierungsfunktionen einfallen lassen, ohne die bereits implementierten Gesten
f¨
ur diese Modellierungsfunktionen zu kennen.
Das Ziel ist eine Validierung der implementierten Gesten, sowie eine Evaluation, ob
die richtigen Gesten f¨
ur die Implementierung verwendet werden, sodass zuk¨
unftige
Benutzer von proView in der Lage sind Prozesse mit den bereits implementierten
Gesten intuitiv zu modellieren bzw. zu bearbeiten.
Ein solches Experiment bietet zudem den Vorteil, die Weisheit von Vielen bei der
Implementierung von Benutzeroberfl¨
achen zu nutzen und sich nicht nur nach ge-
wissen Gestaltungsrichtlinien und Erfahrungen des Usability-Designers zu richten.
Das bedeutet, je mehr Testpersonen an einem solchen Experiment teilnehmen,
desto aussagekr¨
aftiger ist das Resultat dieses Experiments und desto besser und
robuster ist das Bedienkonzept.
Im weiteren Verlauf dieses Kapitels werden in Abschnitt 7.1 zun¨
achst die Vorberei-
tungen beschrieben, die zur Durchf¨
uhrung eines solchen Experiments notwendig
sind. Die Beschreibung der Experimentdurchf¨
uhrung ist ebenfalls in dem Abschnitt
enthalten. In Abschnitt 7.2 des Kapitels werden die ermittelten Daten der einzelnen
Testpersonen ausgewertet und genau analysiert. Dabei wird jede ausgef¨
uhrte Mo-
dellierungsfunktion separat betrachtet. Abschnitt 7.3 beinhaltet eine Zusammen-
fassung zu den Ergebnissen des Experiments.
63
7 Evaluation der Implementierung
7.1 Vorbereitung und Durchf¨uhrung der
experimentellen Untersuchung
Das Experiment besteht aus 18 unterschiedlichen Aufgaben, die alle relevanten
Modellierungsfunktionen der proView-Erweiterung abdecken. Die einzelnen Test-
personen bearbeiten diese Aufgaben jeweils in drei Teilen. Dabei sind die Rei-
henfolgen der 18 Aufgaben in jedem Teil unterschiedlich (siehe Tabelle 7.1). Die
Aufgabenreihenfolge eines Teils ist allerdings f¨
ur jede Testperson gleich.
Teil 1: Eigene Gesten ausdenken
F16, F1, F2, F3, F4, F8, F9, F10, F7, F5, F11, F12, F13, F6, F14, F15, F17, F18
Teil 2: Tutorial
F2, F4, F1, F16, F3, F5, F8, F7, F10, F9, F11, F12, F13, F17, F15, F6, F18, F14
Teil 3: Implementierte Gesten anwenden
F11, F12, F13, F10, F5, F8, F9, F7, F16, F2, F3, F4, F1, F6, F17, F15, F18, F14
Tabelle 7.1: Reihenfolge der Aufgaben von Teil 1, 2 und 3 des Experiments.
In jedem Teil kommt eine spezielle Anwendung zum Einsatz, deren Bedienober-
fl¨
ache den Testpersonen vor Beginn eines Teils vom Versuchsleiter erl¨
autert wird.
Die Anwendungen sind in den Abschnitten 7.1.1 bis 7.1.3 beschrieben. In Teil 1
und Teil 3 des Experiments besteht die M¨
oglichkeit zwischen dem Ansichts- und
Bearbeitungsmodus zu wechseln. Eine experimentelle Untersuchung der Gesten
f¨
ur den Ansichtsmodus findet allerdings nicht statt, da es sich hierbei um Gesten
handelt, die bereits fester Bestandteil vieler ber¨
uhrungsempfindlicher Bedienober-
fl¨
achen sind.
Der von den Testpersonen zu bearbeitende Prozess in Teil 1 und Teil 3, beinhaltet
die Pr¨
ufung der Kreditw¨
urdigkeit eines Kreditnehmers. Jeder dieser beiden Teile
beginnt mit dem initialen Zustand des Prozesses, wie er in Abbildung A.2 zu sehen
ist.
Vor Beginn des Experiments findet eine Aufkl¨
arung der Testperson statt. Dies dient
dazu, der Testperson das Thema dieser Arbeit, sowie den Ablauf und das Ziel des
Experiments n¨
aher zu bringen. Daneben werden wichtige demografische Daten
zur Person erfasst (d.h. Geschlecht, Alter, T¨
atigkeit, Erfahrungen mit Multi-Touch-
Ger¨
aten sowie Prozess-Management). Testpersonen, die keine oder nur wenig
Erfahrung mit Prozess-Management haben, bekommen eine kurze Einf¨
uhrung in
dieses Thema, indem ihnen einige Prozesselemente vorgestellt werden. Die Test-
personen haben zudem die M¨
oglichkeit selbst Fragen zum Experiment, sowie zur
64
7.1 Vorbereitung und Durchf¨
uhrung der experimentellen Untersuchung
Prozessmodellierung zu stellen. Schließlich gibt es eine kurze Erl¨
auterung zu den
Unterschieden zwischen symbolischen und physikalischen Gesten sowie zu Men¨
u-
basierten L¨
osungen. Die Testpersonen haben durch diese Erl¨
auterungen somit
einen besseren ¨
Uberblick ¨
uber ihre Interaktionsm¨
oglichkeiten.
Um St¨
orungen bzw. Beeinflussungen der Testpersonen auszuschließen, findet das
Experiment in einem freien Seminarraum der Universit¨
at Ulm statt. Zur Anwendung
kommt ein Google Nexus 7 Tablet mit dem Betriebssystem Android, auf dem die
Testpersonen die Aufgaben bearbeiten m¨
ussen. Eingegebene Resultate ¨
ubertra-
gen die eingesetzten Anwendungen per WLAN an ein Notebook f¨
ur sp¨
atere Analy-
sezwecke (siehe Abb. 7.1). Das Notebook stellt den proView-Server f¨
ur das Experi-
ment bereit, der f¨
ur die Ausf¨
uhrung von proView notwendig ist. Den Testpersonen
ist es nicht m¨
oglich den Bildschirm des Notebooks zu sehen und k¨
onnen somit
nicht abgelenkt werden. Eine Kamera, die sich schr¨
ag oberhalb der Testpersonen
befindet, zeichnet die Eingaben der Testpersonen auf. Gleichzeitig macht sich der
Versuchsleiter, der rechts neben den Testpersonen sitzt, Notizen zu den Eingaben
und Kommentaren der Testpersonen.
Testperson
Versuchsleiter
Tablet
Notebook
Kamera
Abbildung 7.1: Aufbau des Experiments.
Es finden drei Probel¨
aufe des Experiments statt, um die Machbarkeit des Expe-
riments sicherzustellen [32]. Nach jedem Probelauf finden Optimierungen an den
Aufgaben des Experiments statt.
65
7 Evaluation der Implementierung
7.1.1 Teil 1: Eigene Gesten ausdenken
In Teil 1 haben die Testpersonen die Aufgabe, sich zu ¨
uberlegen, welche Geste sie
f¨
ur welche Modellierungsfunktion verwenden w¨
urden, ohne die bereits implemen-
tierten Gesten zu kennen. Hierf¨
ur ist eine spezielle Anwendung mit dem Namen
ProViewTouch entwickelt worden, die den Testpersonen nacheinander die 18 Auf-
gaben auf dem Bildschirm des Tablets einblendet (siehe Abb. 7.2).
Abbildung 7.2: Benutzeroberfl¨
ache von ProViewTouch.
Mit einem Start-Button, der sich in der rechten, oberen Ecke des Bildschirms be-
findet, k¨
onnen die Testpersonen den Versuch starten und sich die erste Aufgabe
anzeigen lassen. Ein Switch-Button in der linken, oberen Ecke des Bildschirms,
erm¨
oglicht den Wechsel zwischen Ansichts- und Bearbeitungsmodus. Die Anwen-
dung ¨
ubertr¨
agt eingegebene Gesten zusammen mit dem Startzeitpunkt einer Auf-
gabe an den proView-Server, der die Daten zur sp¨
ateren Auswertung in einer XML-
Datei ablegt. Zur n¨
achsten Aufgabe gelangen die Testpersonen ebenfalls ¨
uber den
Button in der rechten, oberen Ecke des Bildschirms.
Benutzereingaben f¨
uhren zu keinen Ver¨
anderungen des Prozessmodells, da die
eingesetzte Anwendung einerseits keine Prozess¨
anderungen unterst¨
utzt und die
eingegebenen Gesten andererseits keine Ver¨
anderungen herbeif¨
uhren k¨
onnen,
wenn sie nicht zuf¨
allig implementiert sind.
Der Versuchsleiter fordert die Testpersonen vor diesem Teil zu lautem Denken auf,
damit Notizen und Skizzen zu ihren Ideen gemacht werden k¨
onnen [28]. Zudem
haben Testpersonen die M¨
oglichkeit, w¨
ahrend des Experiments Fragen an den
Versuchsleiter zu stellen, falls einige der Aufgaben f¨
ur sie unklar sind.
66
7.1 Vorbereitung und Durchf¨
uhrung der experimentellen Untersuchung
7.1.2 Teil 2: Tutorial
Im zweiten Teil des Experiments m¨
ussen die Testpersonen ein Tutorial bearbei-
ten, um die implementierten Gesten der proView-Erweiterung zu erlernen. Dies ist
f¨
ur die Durchf¨
uhrung des dritten Teils notwendig. Mit diesem Tutorial k¨
onnen sich
die Testpersonen nicht nur an die Gesten gew¨
ohnen, sondern auch an die richtige
Ausf¨
uhrungsgeschwindigkeit einer Geste, die f¨
ur eine erfolgreiche Gestenerken-
nung im dritten Teil wichtig ist.
Wie in Teil 1 ist auch f¨
ur dieses Tutorial eine spezielle Anwendung mit dem Namen
ProViewTutorial unter Verwendung des Vaadin-Frameworks und des TouchPanel-
Add-ons entwickelt worden (siehe Abb. 7.3). Im oberen Bereich der Benutzer-
schnittstelle blendet die Anwendung den Testpersonen die 18 unterschiedlichen
Aufgaben textuell ein. Die Reihenfolge der Aufgaben ist allerdings im Vergleich
zum vorherigen Teil anders (siehe Tabelle 7.1). Mithilfe eines Start-Buttons in der
rechten, oberen Ecke des Bildschirms k¨
onnen die Testpersonen das Tutorial star-
ten, sowie zur n¨
achsten Aufgabe gelangen.
Abbildung 7.3: Benutzeroberfl¨
ache von ProViewTutorial.
Pro Aufgabe blendet die Anwendung im linken Bereich der Benutzerschnittstel-
le die implementierten Gesten inklusive Prozesselemente in bildhafter Form ein.
Rechts neben dieser Darstellung erscheint eine Abbildung derselben Prozessele-
mente ohne eingezeichneter Geste. Die Testpersonen haben auf diese Weise die
M¨
oglichkeit, die Geste nachzuzeichnen und sie zu erlernen. Sowohl bei erfolgrei-
cher als auch bei nicht erfolgreicher Eingabe erscheint auf dem Bildschirm eine
entsprechende Meldung.
7.1.3 Teil 3: Implementierte Gesten anwenden
Nachdem die Testpersonen mithilfe des Tutorials die Gesten erlernt haben, m¨
ussen
sie in Teil 3 des Experiments ein erneutes Mal alle 18 Modellierungsfunktionen
67
7 Evaluation der Implementierung
bzw. Aufgaben in unterschiedlicher Reihenfolge ausf¨
uhren, diesmal allerdings un-
ter Verwendung der implementierten Gesten der proView-Erweiterung. Auf diese
Weise kann untersucht werden, ob die verwendeten Gesten einfach zu erlernen
sind.
F¨
ur diesen Teil des Experiments kommt die proView-Anwendung zum Einsatz,
die nach erfolgreicher Gestenausf¨
uhrung das Prozessmodell nun auch visuell ver-
¨
andert (siehe Abb. 7.4). Mit dem Start-Button im rechten, oberen Bereich der Be-
nutzerschnittstelle, k¨
onnen die Testpersonen den Versuch starten und zur n¨
achsten
Aufgabe gelangen. Die Anwendung blendet jede einzelne Aufgabenstellung textu-
ell ein und blendet sie wieder aus, sobald die Testperson die Aufgabe nach dem
Lesen antippt.
Abbildung 7.4: Benutzeroberfl¨
ache von proView.
Startzeitpunkt einer Aufgabe, sowie ausgef¨
uhrte Gesten sendet die Anwendung
per WLAN an den proView-Server, der die Daten in einer XML-Datei f¨
ur die sp¨
atere
Auswertung speichert. Die Testpersonen haben bei unklaren Aufgaben die M¨
oglich-
keit Fragen an den Versuchsleiter zu stellen.
Implementierte Gesten, an die sich eine Testperson nicht mehr erinnern kann, wer-
den ebenfalls vom Versuchsleiter f¨
ur die sp¨
atere Auswertung notiert. Anschließend
werden die Testpersonen auf die richtige L¨
osung hingewiesen.
Am Ende des Experiments werden die Testpersonen aufgefordert, ein Feedback
zu den implementierten Gesten abzugeben. Hier sind insbesondere die Gesten
wichtig, an die sich eine Testperson im Laufe des dritten Teils nicht mehr erinnert.
Feedback und Verbesserungsvorschl¨
age werden schriftlich festgehalten.
68
7.2 Auswertung der experimentellen Untersuchung
7.2 Auswertung der experimentellen Untersuchung
An dem Experiment nehmen insgesamt elf Testpersonen teil, von denen eine Test-
person weiblich ist. Neun Testpersonen sind Studenten, eine Testperson ist Mitar-
beiter des Instituts f¨
ur Datenbanken und Informationssysteme der Universit¨
at Ulm
und eine weitere Testperson ist Mitarbeiter des Kommunikations- und Informations-
zentrums (KIZ) der Universit¨
at Ulm. Das Durchschnittsalter aller Testpersonen liegt
bei 26,27 Jahren (siehe Abb. 7.5). An diesem Experiment nimmt ein Linksh¨
ander
teil. Alle restlichen Testpersonen sind Rechtsh¨
ander.
Abbildung 7.5: Demografische Daten der Testpersonen.
Alle Testpersonen haben bereits Erfahrungen mit Multi-Touch-Ger¨
aten gesammelt.
Neun Testpersonen besitzen ein Smartphone und sechs Testpersonen ein Tablet.
Als Betriebssystem kommt auf diesen Ger¨
aten ¨
uberwiegend Android zum Einsatz.
Abbildung 7.6 zeigt eine Verteilung der eingesetzten Multi-Touch-Ger¨
ate und Be-
triebssysteme.
Neun Testpersonen kennen sich bereits mit Prozess-Management und Prozessmo-
dellierung aus. Davon halten sich f¨
unf Testpersonen f¨
ur Experten in diesem Be-
reich. Im Durchschnitt haben die Testpersonen 3,11 Jahre Erfahrung mit Prozess-
Management. In den letzten zw¨
olf Monaten vor dem Experiment sind von den
Testpersonen im Durchschnitt 18,33 Prozessmodelle analysiert und gelesen wor-
den. In derselben Zeit bearbeiteten und erstellten die Testpersonen durchschnitt-
lich 15,56 Prozessmodelle. Diese Prozessmodelle besitzen eine durchschnittliche
Anzahl von acht Aktivit¨
aten.
Insgesamt f¨
uhren die Testpersonen w¨
ahrend der drei Teile 11 ∗3∗18 = 594 Ge-
69
7 Evaluation der Implementierung
Abbildung 7.6: Verwendete Multi-Touch-Ger¨
ate a) und Betriebssysteme b).
sten aus. Ung¨
ultige Eingaben werden nicht mitgez¨
ahlt. Der erste Teil, bei dem
sich die Testpersonen eigene Gesten haben einfallen lassen, beinhaltet insgesamt
11 ∗18 = 198 Gesten, von denen 54 (d.h. 27,27%) symbolische Gesten sind, 100
(d.h. 50,51%) sind physikalische Gesten und bei 44 (d.h. 22,22%) handelt es sich
um Men¨
u-basierte L¨
osungen. Tabelle 7.2 zeigt eine Verteilung der verwendeten
Gesten bezogen auf die acht Modellierungsfunktionen, die auch in [23] Bestand-
teil sind. In einem direkten Vergleich der Ergebnisse beider Experimente und unter
Beachtung der entsprechenden Modellierungsfunktionen, ist deutlich zu erkennen,
dass die Verteilung der Gesten nahezu identisch ist.
Ermittelte Werte [23]
Symbolische Gesten 23,87% 27,40%
Physikalische Gesten 45,45% 44,72%
Men¨u-basierte L¨
osungen 30,68% 27,88%
Tabelle 7.2: Gesten-Verteilung im Vergleich.
F¨
ur die Bearbeitung von Teil 1 ben¨
otigen die Testpersonen im Durchschnitt 10,16
Minuten. Im dritten Teil sind es 9,98 Minuten im Durchschnitt. Im Anhang A.3 sind
weitere Tabellen und Diagramme zu den Ergebnissen dieses Experiments zu fin-
den.
70
7.2 Auswertung der experimentellen Untersuchung
7.2.1 Detaillierte Auswertung der einzelnen Aufgaben
Im Folgenden findet eine detaillierte Auswertung jeder einzelnen Aufgabe statt. Es
handelt sich hierbei um die Aufgaben bzw. Modellierungsfunktionen F1 bis F18,
die in den drei Teilen des Experiments in unterschiedlichen Reihenfolgen gestellt
werden (siehe Tabelle 7.1). Teil 2 des Experiments, das ausschließlich das Tutorial
beinhaltet, wird aus der Analyse ausgeschlossen, da sich hier keine besonders
aussagekr¨
aftigen Daten ermitteln lassen.
Pro ausgewerteter Aufgabe stellt eine Tabelle die Verteilung der Bedienkonzepte
dar, die in Teil 1 des Experiments ermittelt worden sind. Weitere relevante Tabellen
befinden sich im Anhang dieser Arbeit, wie die Bearbeitungsdauern von Teil 1 und
Teil 2 des Experiments (siehe Tabelle A.6 und A.7) oder eine tabellarische Darstel-
lung, wie h¨
aufig eine bestimmte Aufgabe in Teil 3 gel¨
ost worden ist (siehe Tabelle
A.5). Auf diese Tabellen wird des ¨
Ofteren w¨
ahrend der detaillierten Auswertung
verwiesen.
7.2.1.1 F1 (Element ausw¨
ahlen)
Bei dieser Aufgabe m¨
ussen die einzelnen Testpersonen die Aktivit¨
at ”Load Custo-
mer Data“ des Prozessmodells ausw¨
ahlen. Es gibt so gut wie keine Verst¨
andnis-
probleme dieser Aufgabe, daher ben¨
otigen alle elf Testpersonen durchschnittlich
16,64 Sekunden, um diese Aufgabe im ersten Teil zu bearbeiten (siehe Abb. 7.7).
In dieser Zeit ist das Lesen und Verstehen der Aufgabe, sowie das Ausf¨
uhren der
Geste enthalten. Im Vergleich zu den anderen Aufgaben m¨
ussen die Testpersonen
nicht lange ¨
uberlegen, um sich eine Geste einfallen zu lassen. Dies wird nochmals
mit Tabelle A.6 verdeutlicht.
10 20 30 40
Teil 1
Teil 3
Abbildung 7.7: Bearbeitungszeiten (in Sek.) von Aufgabe F1 (Element ausw¨
ahlen).
Alle elf Testpersonen bevorzugen bei dieser Aufgabe in Teil 1 des Experiments, die
Verwendung einer physikalischen Geste (siehe Tabelle 7.3). Dabei handelt es sich
in allen elf F¨
allen um die Tap-Geste, die auch in der Implementierung eingesetzt
wird.
71
7 Evaluation der Implementierung
Ermittelte Werte
Symbolische Gesten 0%
Physikalische Gesten 100%
Men¨u-basierte L¨
osungen 0%
Tabelle 7.3: Gesten-Verteilung beim Ausw¨
ahlen von Prozesselementen.
Aufgrund dieses Resultats k¨
onnen sich in Teil 3 des Experiments 10 Testperso-
nen an die implementierte Tap-Geste erinnern. Sie l¨
osen die Aufgabe in durch-
schnittlich 18,27 Sekunden (siehe Tabelle A.7). Die Geste hat sich somit f¨
ur das
Ausw¨
ahlen von Elementen bew¨
ahrt.
7.2.1.2 F2 (Aktivit¨
at einf¨ugen)
Die Testpersonen werden bei dieser Aufgabe aufgefordert, den gegebenen Pro-
zess um eine weitere Aktivit¨
at zu erg¨
anzen. Diese Aktivit¨
at muss zwischen dem
Subprozess ”1. Review“ und der Aktivit¨
at ”2. Review“ eingef¨
ugt werden. Der Name
f¨
ur die neue Aktivit¨
at ist ”A“.
Bei dieser Aufgabe gibt es keine Verst¨
andnisprobleme. Die durchschnittliche Be-
arbeitungszeit betr¨
agt 29,64 Sekunden in Teil 1, was sehr nahe am durchschnittli-
chen Wert von 33,87 Sekunden aller Aufgaben liegt (siehe Abb. 7.8).
20 40 60 80
Teil 1
Teil 3
Abbildung 7.8: Bearbeitungszeiten (in Sek.) von Aufgabe F2 (Aktivit¨
at einf¨
ugen).
Zwei Testpersonen setzen die neue Aktivit¨
at mithilfe einer symbolischen Geste um.
Sie zeichnen entweder ein X- oder ein Kreuz-Symbol auf die Sequenzflusskante
zwischen Subprozess und Aktivit¨
at.
Vier Testpersonen bevorzugen bei dieser Aufgabe eine Men¨
u-basierte L¨
osung.
Hierzu tippen sie zun¨
achst die Sequenzflusskante zwischen dem Subprozess und
der Aktivit¨
at an, um ein Kontextmen¨
u zu ¨
offnen. Anschließend setzen sie die neue
Aktivit¨
at mithilfe des Kontextmen¨
us ein.
Die Mehrheit, bestehend aus f¨
unf Testpersonen, entscheidet sich f¨
ur eine physika-
lische Geste. Diese besteht zum einen aus einer Hold-Geste, die auf der Sequenz-
72
7.2 Auswertung der experimentellen Untersuchung
flusskante ausgef¨
uhrt wird. Zum anderen aus einer einfachen Strich-Geste, die die
Testpersonen mit einer Bewegung von oben nach unten zwischen den zwei beste-
henden Prozesselementen ausf¨
uhren. Diese L¨
osung ist mit der implementierten
Geste identisch.
In [23] ist ebenfalls eine experimentelle Untersuchung dieser Modellierungsfunk-
tion enthalten. Hier entscheidet sich die Mehrheit der Testpersonen allerdings f¨
ur
eine Men¨
u-basierte L¨
osung und die wenigsten Testpersonen bevorzugen physika-
lische Gesten, wie Tabelle 7.4 zeigt. Auch symbolische Gesten ¨
uberwiegen, wie
das Einzeichnen eines Rechtecks auf oder ¨
uber die Sequenzflusskante.
Ermittelte Werte [23]
Symbolische Gesten 18,18% 34,62%
Physikalische Gesten 45,46% 23,08%
Men¨u-basierte L¨
osungen 36,36% 42,31%
Tabelle 7.4: Gesten-Verteilung beim Einf¨
ugen einer neuen Aktivit¨
at.
Alle Testpersonen erkennen die implementierte Strich-Geste dennoch als sinnvoll
an und k¨
onnen sich daher problemlos an diese Geste im dritten Teil des Experi-
ments erinnern. Zum L¨
osen der Aufgabe ben¨
otigen die Testpersonen bei diesem
Teil im Durchschnitt 35,64 Sekunden und somit ¨
uberdurchschnittlich viel Zeit. Im
Wesentlichen ist eine lange ¨
Uberlegungsdauer bei dieser Aufgabe f¨
ur die lange
Bearbeitungsdauer der Aufgabe verantwortlich.
Trotz der Unterschiede zwischen den beiden Experiment-Teilen, akzeptieren die
Testpersonen die implementierte Geste. Intuitiv bevorzugen sie allerdings eine an-
dere Geste.
7.2.1.3 F3 (Element umbenennen)
Im ersten Teil des Experiments haben die Testpersonen an dieser Stelle die Auf-
gabe, die Aktivit¨
at ”2. Review“ umzubenennen. Teil 3 beinhaltet die Umbenennung
der in Aufgabe F2 erstellten Aktivit¨
at.
Die Testpersonen ben¨
otigen im ersten Teil im Durchschnitt 25,45 Sekunden f¨
ur
diese Aufgabe (siehe Abb. 7.9). Zwei Testpersonen bevorzugen bei dieser Aufgabe
den Einsatz eines Kontextmen¨
us. Sie tippen dabei die bestehende Aktivit¨
at einmal
an und erwarten daraufhin ein Men¨
u. Die restlichen neun Testpersonen entschei-
den sich f¨
ur eine physikalische Geste. Dabei l¨
osen sie die Umbenennen-Funktion
entweder mit einer einfachen Tap-Geste oder mit einer horizontalen Strich-Geste
73
7 Evaluation der Implementierung
auf der Aktivit¨
at aus. Sechs der neun Testpersonen w¨
ahlen die Double-Tap-Geste,
die auch f¨
ur die proView-Erweiterung genutzt wird.
10 20 30 40 50
Teil 1
Teil 3
Abbildung 7.9: Bearbeitungszeiten (in Sek.) von Aufgabe F3 (Element
umbenennen).
Der Vergleich mit [23] zeigt, dass sich die Testpersonen in diesem Experiment
ebenfalls zum gr¨
oßten Teil f¨
ur eine physikalische Geste entscheiden, die unter
anderem eine Tap-, sowie eine Double-Tap-Geste beinhaltet (siehe Tabelle 7.5).
Ermittelte Werte [23]
Symbolische Gesten 0% 30,77%
Physikalische Gesten 81,82% 61,54%
Men¨u-basierte L¨
osungen 18,18% 7,69%
Tabelle 7.5: Gesten-Verteilung beim Umbenennen einer Aktivit¨
at.
Im dritten Teil des Experiments k¨
onnen sich vier von elf Testpersonen nicht an die
implementierte Double-Tap-Geste erinnern. Drei dieser Testpersonen bevorzugen
aber bereits im ersten Teil eine andere Geste. Das Feedback der Testpersonen,
die sich an die implementierte Geste nicht erinnern k¨
onnen, f¨
allt dennoch positiv
aus.
Viel Zeit wird zum L¨
osen der Aufgabe in Teil 3 ebenfalls nicht ben¨
otigt. Wie in Tabel-
le A.7 zu sehen ist, brauchen die Testpersonen im Durchschnitt 30,82 Sekunden
und daher weniger Zeit als f¨
ur die meisten anderen Aufgaben.
Die Wahl der Double-Tap-Geste f¨
ur das Umbenennen einer Aktivit¨
at hat sich mit
diesem Experiment best¨
atigt.
7.2.1.4 F4 (Element l¨
oschen)
Nachdem in den vorherigen Aufgaben eine neue Aktivit¨
at erstellt und umbenannt
worden ist, muss sie in Teil 3 des Experiments mit dieser Aufgabe wieder gel¨
oscht
74
7.2 Auswertung der experimentellen Untersuchung
werden. Im ersten Teil des Experiments m¨
ussen die Testpersonen die Aktivit¨
at ”2.
Review“ l¨
oschen.
Zum L¨
osen dieser Aufgaben brauchen die Testpersonen 28,73 Sekunden im Durch-
schnitt (siehe Abb. 7.10).
0 20 40 60 80 100
Teil 1
Teil 3
Abbildung 7.10: Bearbeitungszeiten (in Sek.) von Aufgabe F4 (Element l¨
oschen).
Eine Testperson entscheidet sich ein Double-Tap auf die Aktivit¨
at anzuwenden,
woraufhin sich ein Kontextmen¨
u¨
offnet, mit dem die Aktivit¨
at gel¨
oscht werden kann.
Sechs Testpersonen und damit die Mehrheit bevorzugen es, die Aktivit¨
at aus dem
Bearbeitungsbereich zu ziehen. Sie platzieren dabei ihren Finger auf die Aktivit¨
at
und f¨
uhren eine Drag & Drop-Bewegung Richtung oberen oder unteren Bildschirm-
rand aus.
Die restlichen vier Testpersonen entscheiden sich f¨
ur eine symbolische Geste in
Form eines X-Symbols und somit f¨
ur die implementierte Geste. Die Testpersonen
setzen allerdings alle beim Zeichnen ihren Finger ab, was der einzige Unterschied
zur implementierten Geste ist.
In [23] entscheidet sich die Mehrheit ebenfalls f¨
ur eine physikalische Geste (sie-
he Tabelle 7.6). Auch bei diesem Experiment kommt die Drag & Drop-Bewegung
Richtung Bildschirmrand zum Einsatz. Zu diesen physikalischen Gesten z¨
ahlen
aber auch diagonale Drag & Drop-Bewegungen, die das Durchstreichen einer Ak-
tivit¨
at symbolisieren sollen. Das X-Symbol kommt ebenfalls in einigen F¨
allen vor,
unter anderem auch in Kombination mit einem Kontextmen¨
u.
Ermittelte Werte [23]
Symbolische Gesten 36,36% 7,69%
Physikalische Gesten 54,55% 50,00%
Men¨u-basierte L¨
osungen 9,09% 42,31%
Tabelle 7.6: Gesten-Verteilung beim L¨
oschen einer Aktivit¨
at.
Die Testpersonen tun sich mit der implementierten Geste schwer. Nur acht Test-
personen k¨
onnen sich im dritten Teil an die Geste erinnern, was sie mit der et-
75
7 Evaluation der Implementierung
was gew¨
ohnungsbed¨
urftigen, durchgehenden Form des X-Symbols begr¨
unden.
Es wird deshalb auch im Vergleich zu den anderen Aufgaben mit Durchschnitt-
lich 33,27 Sekunden mehr Zeit ben¨
otigt, um die Aufgabe im dritten Teil zu l¨
osen.
Dennoch ¨
außern viele der Testpersonen auch positive Kritik zu der eingesetzten
Geste.
Eine Implementierung der bevorzugten Drag & Drop-Bewegung Richtung unteren
Bildschirmrand ist in proView m¨
oglich. Allerdings muss darauf geachtet werden,
dass man beispielsweise beim schlechten Einf¨
ugen einer Synchronisationskante,
unbeabsichtigt eine Aktivit¨
at l¨
oschen k¨
onnte, da die Gesten ¨
ahnlich zueinander
sind. Dann ist der Einsatz einer vorherigen Sicherheitsabfrage von Vorteil.
7.2.1.5 F5 (Elemente aggregieren)
Die Aufgabe im ersten Teil des Experiments ist es, die Aktivit¨
at ”Fill Out Credit
Request“ und den ersten XOR-Verzweigungsblock, der aus der Aktivit¨
at ”Load Cu-
stomer Data“ und ”Create Customer Data“ besteht, zu einem Subprozess zusam-
menzufassen. Im dritten Teil muss der einzige AND-Verzweigungsblock aggregiert
werden.
Es gibt keine Verst¨
andnisprobleme mit dieser Aufgabe, dennoch haben viele Test-
personen im ersten Teil Probleme diese Aufgabe zu l¨
osen, da ihnen nicht sofort
eine Geste einf¨
allt. Aus diesem Grund betr¨
agt die durchschnittlich ben¨
otigte Zeit
39,00 Sekunden und liegt damit ¨
uber der durchschnittlichen Zeit aller Aufgaben
(siehe Abb. 7.11).
20 30 40 50 60 70 80
Teil 1
Teil 3
Abbildung 7.11: Bearbeitungszeiten (in Sek.) von Aufgabe F5 (Elemente
aggregieren).
F¨
ur die Aggregation der entsprechenden Prozesselemente verwendet eine Test-
person eine obere Men¨
uleiste, um die Modellierungsfunktion zun¨
achst zu aktivie-
ren. Anschließend w¨
ahlt sie mittels Tap-Geste die Prozesselemente aus, die ag-
gregiert werden sollen.
Vier Testpersonen verwenden eine physikalische Geste. In drei F¨
allen wird die
76
7.2 Auswertung der experimentellen Untersuchung
Pinch-Geste verwendet, indem die Testpersonen zwei Finger auf den zu aggre-
gierenden Prozesselementen zusammenziehen. Bei dieser Ausf¨
uhrung fehlt aller-
dings eine gewisse Genauigkeit bei der Auswahl der entsprechenden Prozessele-
mente.
Die Mehrheit, bestehend aus sechs Testpersonen, f¨
uhrt eine symbolische Geste
aus. Dabei zeichnen zwei Testpersonen einen Kreis und vier Testpersonen einen
Rechteck um die zu aggregierenden Prozesselemente.
In [23] werden ebenfalls mit 73,08% haupts¨
achlich Kreise und Rechtecke zum Ag-
gregieren verwendet (siehe Tabelle 7.7). Zu beachten ist, dass [23] diese Symbole
zu einer physikalischen Geste z¨
ahlt, wohingegen es sich in diesem Experiment um
symbolische Gesten handelt. Wenn dies ber¨
ucksichtigt wird, sind die Ergebnisse
nahezu identisch.
Ermittelte Werte [23]
Symbolische Gesten 54,55% 11,54%
Physikalische Gesten 36,36% 73,08%
Men¨u-basierte L¨
osungen 9,09% 15,38%
Tabelle 7.7: Gesten-Verteilung beim Aggregieren von Elementen.
Die Testpersonen ben¨
otigen in Teil 3 des Experiments im Durchschnitt 46,73 Se-
kunden, um die Aufgabe zu l¨
osen. Dies ist ein schlechter Wert (siehe Tabelle A.7).
Erinnern k¨
onnen sich allerdings alle Testpersonen an die implementierte Geste.
Der Grund f¨
ur die schlechte Zeit liegt darin, dass einige Testpersonen ¨
uber den
mehrmaligen Einsatz des Rechteck-Symbols f¨
ur die Modellierungsfunktionen ver-
wundert sind und bei dieser Aufgabe zun¨
achst an eine andere Geste denken.
7.2.1.6 F6 (Element reduzieren)
Diese Aufgabe beinhaltet das Reduzieren von Prozesselementen. Dabei muss in
Teil 1 der expandierte Subprozess ”Calculate and Check“ und in Teil 3 die Aktivit¨
at
”Fill Out Credit Request“ reduziert werden.
F¨
ur Teil 1 ben¨
otigen die Testpersonen im Durchschnitt 40,91 Sekunden (siehe Abb.
7.12). Das liegt unter anderem daran, dass vielen Testpersonen trotz Erfahrung mit
Prozess-Management zu dem Zeitpunkt der Begriff ”Reduzieren“ nicht gel¨
aufig ist.
Drei Testpersonen bevorzugen den Einsatz eines Kontextmen¨
us. Sie w¨
ahlen die
entsprechenden Prozesselemente aus und rufen die Funktion zum Reduzieren in
einem Kontextmen¨
u auf.
77
7 Evaluation der Implementierung
20 30 40 50 60 70
Teil 1
Teil 3
Abbildung 7.12: Bearbeitungszeiten (in Sek.) von Aufgabe F6 (Element
reduzieren).
Symbolische L¨
osungen kommen ¨
uberhaupt nicht zum Einsatz, sondern im We-
sentlichen physikalische Gesten. Die am meisten ausgef¨
uhrte Geste ist dabei die
Pinch-Geste. Die Testpersonen ziehen auf dem zu reduzierenden Prozesselement
ihre Finger zusammen, um auf diese Weise die Reduktions-Funktion auszul¨
osen.
Hierbei beachten sie allerdings nicht, wie die Geste auf mehrere Prozesselemente
gleichzeitig angewendet werden k¨
onnte. In so einem Fall gibt es mit der Pinch-
Geste Probleme, da eine gewisse Auswahlgenauigkeit fehlt. Eine Verteilung der
Gesten f¨
ur diese Funktion ist in Tabelle 7.8 zu sehen.
Ermittelte Werte
Symbolische Gesten 0%
Physikalische Gesten 72,73%
Men¨u-basierte L¨
osungen 27,27%
Tabelle 7.8: Gesten-Verteilung bei der Reduktion.
In Teil 3 des Experiments ben¨
otigen die Testpersonen 51,73 Sekunden. Auch hier
gibt es erhebliche Schwierigkeiten sich an die Geste zu erinnern. Viele k¨
onnen
sich teilweise an das Rechteck erinnern, vergessen aber des ¨
Ofteren die zus¨
atzli-
che Diagonale. Nur eine Testperson kann sich an die implementierte, symbolische
Geste erinnern.
Die Testpersonen geben ¨
uberwiegend an, dass die Geste schlecht zu merken und
nicht intuitiv ist. Andere kritisieren die lange Ausf¨
uhrungsdauer der Geste. Um eine
Verbesserung zu erreichen, kann auf die zus¨
atzliche Diagonale verzichtet werden,
sodass nur noch ein Rechteck um die zu reduzierenden Prozesselemente gezeich-
net werden muss. Dies bedeutet allerdings auch, dass sich in dem anschließend
¨
offnenden Kontextmen¨
u ein weiterer Eintrag f¨
ur die Reduktions-Funktion befinden
muss.
78
7.2 Auswertung der experimentellen Untersuchung
7.2.1.7 F7 (Verzweigungsblock einf¨ugen)
Die Testpersonen haben die Aufgabe einen neuen XOR-Verzweigungsblock zu er-
stellen. In Teil 1 des Experiments soll die Aktivit¨
at ”Fill Out Credit Request“ Be-
standteil des Verzweigungsblocks sein, d.h. sich auf einem XOR-Zweig befinden.
In Teil 3 soll sich der Subprozess ”1. Review“ und die Aktivit¨
at ”2. Review“ im Ver-
zweigungsblock befinden.
F¨
ur diese Aufgabe wird am meisten Zeit ben¨
otigt. Im Durchschnitt vergehen 60,91
Sekunden, bis die Testpersonen die Aufgabe l¨
osen (siehe Abb. 7.13). Dabei haben
sie keine Probleme die Aufgabe zu verstehen, sondern sich eine passende Geste
f¨
ur diese Modellierungsfunktion zu ¨
uberlegen.
20 40 60 80 100
Teil 1
Teil 3
Abbildung 7.13: Bearbeitungszeiten (in Sek.) von Aufgabe F7 (Verzweigungsblock
einf¨
ugen).
Vier Testpersonen zeichnen den ¨
offnenden und den schließenden XOR-Verzwei-
gungsknoten auf die Sequenzflusskante. Die verwendeten Symbole sind Kreise,
X-Symbole sowie ein horizontales, halbes Rechteck.
Zwei Testpersonen setzen die Verzweigungsknoten mithilfe einer Hold-Geste ein,
indem sie die entsprechenden Sequenzflusskanten f¨
ur eine gewisse Dauer ber¨
uh-
ren.
Die Mehrheit der Testpersonen entscheidet sich f¨
ur eine Men¨
u-basierte L¨
osung.
Dabei tippen sie die Sequenzflusskanten an, um ein Kontextmen¨
u zu ¨
offnen, mit
dem sie die Verzweigungsknoten einsetzen k¨
onnen.
Das Ergebnis in [23] ist f¨
ur diese Modellierungsfunktion ziemlich ausgeglichen (sie-
he Tabelle 7.9). Es entscheiden sich genauso viele Testpersonen f¨
ur eine symboli-
sche wie auch f¨
ur eine Men¨
u-basierte L¨
osung. Die L¨
osungen enthalten eine große
Vielzahl an unterschiedlichen Symbolen und Gesten, sodass sich keine eindeutige
L¨
osung herauskristallisiert. Lediglich die physikalischen Gesten werden in beiden
Experimenten etwas weniger eingesetzt.
Wie in Teil 1 des Experiments, ben¨
otigen die Testpersonen auch in Teil 3 mit im
Durchschnitt 57,64 Sekunden viel Zeit, um die Aufgabe zu l¨
osen. In f¨
unf F¨
allen
79
7 Evaluation der Implementierung
Ermittelte Werte [23]
Symbolische Gesten 36,36% 34,62%
Physikalische Gesten 18,19% 30,76%
Men¨u-basierte L¨
osungen 45,45% 34,62%
Tabelle 7.9: Gesten-Verteilung beim Einf¨
ugen eines Verzweigungsblocks.
scheitern die Testpersonen hierbei. Als Grund geben sie an, dass sie das Rechteck-
Symbol zum Ausw¨
ahlen der entsprechenden Prozesselemente zwar vermuten, es
jedoch nicht anwenden, da es ebenfalls f¨
ur andere Modellierungsfunktionen zum
Einsatz kommt. Verbesserungsvorschl¨
age gibt es jedoch keine. Schlussendlich
wird das Rechteck-Symbol zum ¨
Offnen eines Kontextmen¨
us, das die entsprechen-
de Modellierungsfunktion enth¨
alt, von den Testpersonen akzeptiert und als sinnvoll
befunden.
7.2.1.8 F8 (Verzweigung einf¨ugen)
In den ersten XOR-Verzweigungsblock, der aus zwei XOR-Zweigen und den Ak-
tivit¨
aten ”Load Customer Data“ und ”Create Customer Data“ besteht, sollen die
Testpersonen einen neuen XOR-Zweig einsetzen. Hierf¨
ur ben¨
otigen sie im Durch-
schnitt 32,64 Sekunden (siehe Abb. 7.14).
10 20 30 40 50 60 70
Teil 1
Teil 3
Abbildung 7.14: Bearbeitungszeiten (in Sek.) von Aufgabe F8 (Verzweigung
einf¨
ugen).
Eine Testperson f¨
uhrt eine symbolische Geste aus, indem sie einen Bogen vom
¨
offnenden Verzweigungsknoten zum schließenden Verzweigungsknoten oberhalb
des XOR-Verzweigungsblocks zeichnet.
Die Mehrheit bevorzugt den Einsatz eines Kontextmen¨
us, das nach dem Antippen
des ¨
offnenden Verzweigungsknotens erscheint und die Modellierungsfunktion zum
Einf¨
ugen eines neuen Zweigs anbietet.
Vier Testpersonen entscheiden sich eine Strich-Geste von links nach rechts aus-
zuf¨
uhren, deren Startposition der ¨
offnende Verzweigungsknoten ist und in zwei
80
7.2 Auswertung der experimentellen Untersuchung
F¨
allen der schließende Verzweigungsknoten als Endposition dient. Die anderen
zwei Testpersonen machen sich Gedanken dar¨
uber, dass in manchen Prozessmo-
dellen der schließende Verzweigungsknoten aufgrund eines kleinen Bildschirms
eventuell nicht sichtbar ist und beenden die Strich-Geste deshalb nur wenige Zen-
timeter nach dem ¨
offnenden Knoten, um auf diese Weise einen Zweig anzudeuten.
Diese L¨
osung ist ¨
ahnlich zu der implementierten Geste, die die Form eines nach
oben gerichteten Pfeils besitzt.
Werden die hier ermittelten Werte mit denen in [23] verglichen, ist deutlich ein Un-
terschied erkennbar (siehe Tabelle 7.10). In [23] entscheiden sich 46,15% f¨
ur eine
physikalische Geste, die im Wesentlichen aus dieser bereits erl¨
auterten Strich-
Geste besteht.
Ermittelte Werte [23]
Symbolische Gesten 9,09% 30,77%
Physikalische Gesten 36,36% 46,15%
Men¨u-basierte L¨
osungen 54,55% 23,08%
Tabelle 7.10: Gesten-Verteilung beim Einf¨
ugen einer neuen Verzweigung.
Trotz der ungew¨
ohnlichen Form k¨
onnen sich dennoch neun Testpersonen an das
implementierte Pfeil-Symbol erinnern. Zeitlich wird die Aufgabe in Teil 3 des Expe-
riments in 31,36 Sekunden gel¨
ost, wie Tabelle A.7 beweist.
Besonders negative Kritik gibt es in Bezug auf die Pfeilspitze. Fast alle Testperso-
nen empfehlen die Pfeilspitze wegzulassen, da sie schwierig zu zeichnen ist, ohne
den Finger abzusetzen. Ohne Pfeilspitze verbleibt eine einfache Strich-Geste, die
wie bereits erw¨
ahnt, vier Testpersonen in Teil 1 des Experiments verwenden.
7.2.1.9 F9 (Schleife einf¨ugen)
Die Testpersonen haben die Aufgabe in den Prozess eine neue Schleife einzu-
setzen. Diese Schleife soll nach der Aktivit¨
at ”2. Review“ beginnen und vor dem
XOR-Split des ersten XOR-Verzweigungsblocks im Prozessmodell enden.
Im Durchschnitt ben¨
otigen die Testpersonen 42,36 Sekunden f¨
ur diese Aufgabe
(siehe Abb. 7.15). Einige Sekunden sind notwendig, um die richtigen Stellen, an
denen die Schleife eingesetzt werden soll, zu finden. Die restliche Zeit ben¨
otigen
die Testpersonen f¨
ur das Ausdenken einer passenden Geste.
Zwei Testpersonen entscheiden sich, die Schleife ¨
uber eine Men¨
u-basierte L¨
osung
zu realisieren. Dabei verwenden sie ein Kontextmen¨
u, das sie ¨
uber ein einfaches
81
7 Evaluation der Implementierung
20 30 40 50 60 70 80
Teil 1
Teil 3
Abbildung 7.15: Bearbeitungszeiten (in Sek.) von Aufgabe F9 (Schleife einf¨
ugen).
Antippen oder langes Ber¨
uhren der entsprechenden Sequenzflusskanten ¨
offnen.
Dieses Kontextmen¨
u enth¨
alt eine Modellierungsfunktion zum Einsetzen des Start-
knotens der Schleife, sowie eine Modellierungsfunktion zum Einsetzen des End-
knotens der Schleife.
Physikalische Gesten kommen nicht zum Einsatz, sondern im Wesentlichen sym-
bolische Gesten (siehe Tabelle 7.11). Die restlichen Testpersonen zeichnen hierbei
die Schleife in das Prozessmodell ein. Diese L¨
osung ist mit der implementierten
Geste identisch. Allerdings gibt es bei der Gestendurchf¨
uhrung zwei unterschiedli-
che Ans¨
atze. F¨
unf der neun Testpersonen bevorzugen es, dass die Endpunkte der
zu zeichnenden Schleife auf der Aktivit¨
at ”2. Review“ und dem XOR-Split liegen,
wohingegen die anderen Testpersonen nach der Aktivit¨
at beginnen zu zeichnen
bzw. vor dem XOR-Split mit dem Zeichnen aufh¨
oren. Dennoch k¨
onnen sich alle
Testpersonen in Teil 3 des Experiments an die Geste erinnern und w¨
ahlen den
richtigen Ansatz zum Zeichnen, d.h. platzieren Start- und Endpunkt der Schleife
auf den entsprechenden Prozesselementen. Die hierf¨
ur ben¨
otigte Durchschnitts-
zeit liegt bei 37,91 Sekunden und ist aufgrund der sehr guten Erinnerungsrate ein
akzeptabler Wert.
Ermittelte Werte
Symbolische Gesten 81,82%
Physikalische Gesten 0%
Men¨u-basierte L¨
osungen 18,18%
Tabelle 7.11: Gesten-Verteilung beim Einf¨
ugen einer Schleife.
Das Ergebnis dieser Aufgabe zeigt, dass die implementierte Geste zur Modellie-
rungsfunktion passt.
82
7.2 Auswertung der experimentellen Untersuchung
7.2.1.10 F10 (Synchronisationskante einf¨ugen)
Die Testpersonen m¨
ussen bei dieser Aufgabe in den AND-Verzweigungsblock des
Prozessmodells eine neue Synchronisationskante zwischen der Aktivit¨
at ”Calcula-
te Risk“ und ”Check Credit Protection Agency“ einsetzen. Die Richtung der Kante
spielt dabei keine Rolle. Die Aufgabe l¨
osen die Testpersonen in durchschnittlich
37,45 Sekunden (siehe Abb. 7.16).
10 20 30 40 50 60 70
Teil 1
Teil 3
Abbildung 7.16: Bearbeitungszeiten (in Sek.) von Aufgabe F10 (Synchronisations-
kante einf¨
ugen).
Eine Testperson bevorzugt bei dieser Aufgabe eine Men¨
u-basierte L¨
osung (siehe
Tabelle 7.12). Sie tippt dabei zun¨
achst auf die obere Aktivit¨
at, um ein Kontext-
men¨
u aufzurufen, w¨
ahlt die Synchronisationskante aus und zieht sie per Drag &
Drop auf die untere Aktivit¨
at.
Ermittelte Werte
Symbolische Gesten 27,27%
Physikalische Gesten 63,64%
Men¨u-basierte L¨
osungen 9,09%
Tabelle 7.12: Gesten-Verteilung beim Einf¨
ugen einer Synchronisationskante.
Drei Testpersonen bevorzugen eine symbolische Geste, indem sie eine gestrichel-
te Synchronisationskante einzeichnen. In einem Fall wird die Kante durch eine
Pfeilspitze erg¨
anzt.
Die restlichen sieben Testpersonen entscheiden sich bei dieser Aufgabe f¨
ur ei-
ne physikalische Geste. Sie f¨
uhren eine Strich-Geste von der oberen zur unteren
Aktivit¨
at aus, um die Synchronisationskante auf diese Weise einzusetzen. Diese
Geste wird auch in der proView-Erweiterung eingesetzt. Daher l¨
osen alle Test-
personen dieselbe Aufgabe in Teil 3 des Experiments problemlos. Sie ben¨
otigen
hierf¨
ur durchschnittlich 23,00 Sekunden.
83
7 Evaluation der Implementierung
7.2.1.11 F11 (Subprozess anzeigen)
Das Prozessmodell enth¨
alt einen Subprozess ”1. Review“, der sich im kollabier-
ten bzw. zugeklappten Zustand befindet. Bei dieser Aufgabe gilt es nun, diesen
Subprozess mittels einer Geste in den expandierten Zustand zu ¨
uberf¨
uhren.
Die Testpersonen l¨
osen diese Aufgabe in Teil 1 des Experiments mit durchschnitt-
lich 14,36 Sekunden (siehe Abb. 7.17). Eine Testperson f¨
uhrt dabei zum Aufklap-
pen des Subprozesses eine symbolische Geste in Form eines H¨
akchens aus. Die
restlichen zehn Testpersonen entscheiden sich, eine physikalische Geste zu ver-
wenden (siehe Tabelle 7.13). Es handelt sich hierbei um eine Pinch-, Double-Tap
und eine Hold-Geste. Die Mehrheit f¨
uhrt allerdings eine gew¨
ohnliche Tap-Geste
auf dem Plus-Symbol des Subprozesses aus, um diesen aufzuklappen.
10 20 30 40 50
Teil 1
Teil 3
Abbildung 7.17: Bearbeitungszeiten (in Sek.) von Aufgabe F11 (Subprozess
anzeigen).
Ermittelte Werte
Symbolische Gesten 9,09%
Physikalische Gesten 90,91%
Men¨u-basierte L¨
osungen 0%
Tabelle 7.13: Gesten-Verteilung beim Anzeigen eines Subprozesses.
In Teil 3 des Experiments ben¨
otigen die Testpersonen f¨
ur dieselbe Aufgabe Durch-
schnittlich 32,91 Sekunden. Neun von insgesamt elf Testpersonen f¨
uhren die im-
plementierte Geste richtig aus.
Beinahe alle Testpersonen sind mit der Wahl der implementierten Geste zufrieden.
Es gibt eine Kritik zur langen Ausf¨
uhrungsdauer der Geste, die bei einer h¨
aufigeren
Anwendung st¨
orend sein kann.
84
7.2 Auswertung der experimentellen Untersuchung
7.2.1.12 F12 (Subprozess verbergen)
In Teil 1 des Experiments m¨
ussen die Testpersonen bei dieser Aufgabe den Sub-
prozess ”Calculate and Check“ zuklappen, d.h. in den kollabierten Zustand brin-
gen. In Teil 3 handelt es sich um den Subprozess ”1. Review“.
Wie bei der Aufgabe ”Subprozess anzeigen“ k¨
onnen die Testpersonen auch diese
Aufgabe mit durchschnittlich 20,09 Sekunden schnell l¨
osen (siehe Abb. 7.18). Alle
Testpersonen w¨
ahlen hierbei eine physikalische Geste aus.
10 20 30 40
Teil 1
Teil 3
Abbildung 7.18: Bearbeitungszeiten (in Sek.) von Aufgabe F12 (Subprozess
verbergen).
Vier Testpersonen klappen den Subprozess mit einer Pinch-Geste zu, d.h. sie
ber¨
uhren den Bildschirm mit zwei Fingern, die sie anschließend auf dem Sub-
prozess zusammenziehen.
Sechs Testpersonen tippen mit ihrem Finger auf das Minus-Symbol des Subpro-
zesses, das sich zentriert am unteren Rand des Prozesselements befindet.
Eine Verteilung der verwendeten Bedienkonzepte ist in Tabelle 7.14 zu sehen.
Ermittelte Werte
Symbolische Gesten 0%
Physikalische Gesten 100%
Men¨u-basierte L¨
osungen 0%
Tabelle 7.14: Gesten-Verteilung beim Verbergen eines Subprozesses.
In Teil 3 des Experiments, wo es darum geht sich an die implementierte Hold-Geste
zu erinnern, haben die Testpersonen keine großen Schwierigkeiten. Diese Aufga-
be l¨
osen alle Testpersonen mit einer durchschnittlichen Zeit von 15,09 Sekunden.
Eine negative Kritik zu dieser Geste gibt es nicht.
85
7 Evaluation der Implementierung
7.2.1.13 F13 (Subprozess aufl ¨
osen)
Der bestehende Subprozess ”Calculate and Check“ muss von den Testpersonen
bei dieser Aufgabe aufgel¨
ost werden, sodass die im Subprozess enthaltenen Pro-
zesselemente wieder fester Bestandteil des gesamten Prozessmodells sind.
Es gibt keine Verst¨
andnisprobleme bei dieser Aufgabe. Eine passende Geste zu
finden, gestaltet sich f¨
ur manche Testpersonen dennoch als schwierig. Im Durch-
schnitt ben¨
otigen alle Testpersonen 37,36 Sekunden f¨
ur diese Aufgabe (siehe Abb.
7.19).
20 40 60 80
Teil 1
Teil 3
Abbildung 7.19: Bearbeitungszeiten (in Sek.) von Aufgabe F13 (Subprozess
aufl¨
osen).
Drei Testpersonen f¨
uhren eine symbolische Geste aus (siehe Tabelle 7.15). In
einem Fall wird der Subprozess mit einem Kreuz durchgestrichen. Die anderen
beiden Ans¨
atze sind sich sehr ¨
ahnlich. Die Testpersonen zeichnen dabei die Um-
randung des Subprozesses mit einer durchgehenden bzw. einer zickzackf¨
ormigen
Linie nach, um diese praktisch aufzul¨
osen.
Ermittelte Werte
Symbolische Gesten 27,27%
Physikalische Gesten 45,46%
Men¨u-basierte L¨
osungen 27,27%
Tabelle 7.15: Gesten-Verteilung beim Aufl¨
osen eines Subprozesses.
Weitere drei Testpersonen bevorzugen den Einsatz eines Men¨
us. Auch hier gibt
es drei unterschiedliche Ans¨
atze. Zum ¨
Offnen eines Kontextmen¨
us tippt einer der
Testpersonen den Namen ”Calculate and Check“ oberhalb des Subprozesses an.
Ein anderer tippt den Subprozess direkt an. Im dritten Ansatz aktiviert die Testper-
son in einer Men¨
uleiste die Modellierungsfunktion zum Aufl¨
osen des Subprozesses
und w¨
ahlt anschließend den entsprechenden Subprozess aus.
Die Mehrheit, bestehend aus f¨
unf Testpersonen, f¨
uhrt eine physikalische Geste
aus. Hier ergibt sich allerdings ebenfalls keine eindeutige L¨
osung. Drei Testperso-
86
7.2 Auswertung der experimentellen Untersuchung
nen l¨
osen den Subprozess mit einer Hold- bzw. einer Pinch-Geste auf. Die rest-
lichen beiden Testpersonen f¨
uhren eine Drag & Drop-Bewegung aus. Der Start-
punkt der Bewegung ist in einem Fall die obere, rechte Ecke des Subprozesses.
Die anschließende Bewegung ist sehr kurz. Im zweiten Fall wird die Drag & Drop-
Bewegung quer auf dem Subprozess ausgef¨
uhrt.
Nur sieben Testpersonen k¨
onnen sich in Teil 3 an die implementierte Zickzack-
Geste erinnern. Die durchschnittliche Bearbeitungszeit der Aufgabe liegt daher bei
52,27 Sekunden.
Einige Testpersonen finden die Geste zu kompliziert und nicht intuitiv genug. Au-
ßerdem ist die Ausf¨
uhrungsdauer f¨
ur viele Testpersonen zu lang. Die Testperso-
nen bevorzugen gr¨
oßtenteils ihre ausgedachten Gesten, die allerdings sehr un-
terschiedlich ausgefallen sind, sodass es nicht m¨
oglich ist, eine eindeutige Ge-
ste f¨
ur diese Modellierungsfunktion zu finden. Die implementierte Geste k¨
onnte
zur Verbesserung auf einen zu zeichnenden Zacken reduziert werden, um die
Ausf¨
uhrungsdauer und die Komplexit¨
at etwas zu reduzieren.
7.2.1.14 F14 (Prozesssicht erstellen)
Bei dieser Aufgabe m¨
ussen die Testpersonen aus dem ersten XOR-Verzweigungs-
block, der aus den zwei Aktivit¨
aten ”Load Customer Data“ und ”Create Customer
Data“ besteht, eine neue Prozesssicht erstellen. Eine Benennung der neuen Pro-
zesssicht wird nicht verlangt.
Zum L¨
osen dieser Aufgabe ben¨
otigen die Testpersonen in Teil 1 durchschnittlich
56,73 Sekunden (siehe Abb. 7.20). Dies liegt vor allem daran, dass die Testper-
sonen versuchen unbedingt eine Geste zu finden, die sie in den letzten Aufgaben
noch nicht verwendet haben.
20 40 60 80 100
Teil 1
Teil 3
Abbildung 7.20: Bearbeitungszeiten (in Sek.) von Aufgabe F14 (Prozesssicht
erstellen).
Eine Testperson erstellt eine neue Prozesssicht, indem sie eine Strich-Geste von
links nach rechts auf dem Verzweigungsblock ausf¨
uhrt.
87
7 Evaluation der Implementierung
Men¨
u-basierte L¨
osungen werden von drei Testpersonen bevorzugt (siehe Tabelle
7.16). Sie w¨
ahlen zun¨
achst die entsprechenden Prozesselemente mit einer Tap-
Geste aus und l¨
osen die Modellierungsfunktion zum Erstellen einer neuen Pro-
zesssicht ¨
uber ein Kontextmen¨
u aus.
Ermittelte Werte
Symbolische Gesten 63,64%
Physikalische Gesten 9,09%
Men¨u-basierte L¨
osungen 27,27%
Tabelle 7.16: Gesten-Verteilung beim Erstellen einer Prozesssicht.
Sieben Testpersonen zeichnen einen Rechteck um den XOR-Verzweigungsblock,
aus dem eine neue Prozesssicht erstellt werden soll.
Im Gegensatz zu Teil 1 l¨
osen die Testpersonen dieselbe Aufgabe in Teil 3 schneller.
Im Durchschnitt ben¨
otigen sie 28,73 Sekunden, um sich an die implementierte
Geste zu erinnern und diese anschließend anzuwenden. Die Aufgabe wird von
allen Testpersonen gel¨
ost. Eine negative Kritik zu der implementierten L¨
osung gibt
es nicht. Daher sind keine ¨
Anderungen der implementierten Geste notwendig.
7.2.1.15 F15 (Datenelement einf¨ugen)
Diese Aufgabe beinhaltet das Einf¨
ugen eines neuen Datenelements in das beste-
hende Prozessmodell. Die Position des neuen Datenelements wird nicht vorge-
geben. Die Testpersonen ben¨
otigen nicht viel Zeit, um f¨
ur diese Modellierungs-
funktion eine Geste zu finden. Die durchschnittliche Zeit liegt in Teil 1 bei 28,09
Sekunden (siehe Abb. 7.21).
10 20 30 40 50 60
Teil 1
Teil 3
Abbildung 7.21: Bearbeitungszeiten (in Sek.) von Aufgabe F15 (Datenelement
einf¨
ugen).
Zwei Testpersonen entscheiden sich bei dieser Aufgabe f¨
ur eine symbolische Ge-
ste. Sie zeichnen dabei eine horizontale S-Kurve oder ein Plus-Symbol auf den
freien Hintergrund.
88
7.2 Auswertung der experimentellen Untersuchung
Zwei weitere Testpersonen platzieren das neue Datenelement mit einer Hold-Geste
auf den freien Hintergrund.
Die Mehrheit entscheidet sich ein Men¨
u einzusetzen. Hier kommen ebenfalls sehr
unterschiedliche Ans¨
atze zum Einsatz. Unter Verwendung einer Tap-, Hold oder
einer symbolischen Geste in Form eines X-Symbols, rufen die Testpersonen ein
Kontextmen¨
u auf, mit dem sich das neue Datenelement einsetzen l¨
asst. Die restli-
chen vier Testpersonen bevorzugen die Verwendung einer oberen bzw. seitlichen
Men¨
uleiste, die ein neues Datenelement zur Verf¨
ugung stellt. Per Drag & Drop
kann so das neue Datenelement eingef¨
ugt werden.
In [23] entscheidet sich die Mehrheit ebenfalls f¨
ur eine Men¨
u-basierte L¨
osung, um
das Datenelement einzusetzen (siehe Tabelle 7.17). Es handelt sich hierbei um
dieselben Ans¨
atze, wie oben beschrieben. Symbolische Gesten, wie Kreise, Drei-
ecke und Rechtecke kommen ebenfalls sehr h¨
aufig vor.
Ermittelte Werte [23]
Symbolische Gesten 18,18% 38,46%
Physikalische Gesten 18,18% 15,38%
Men¨u-basierte L¨
osungen 63,64% 46,16%
Tabelle 7.17: Gesten-Verteilung beim Einf¨
ugen eines neuen Datenelements.
In Teil 3 k¨
onnen sich nur wenige Testpersonen an die implementierte Geste erin-
nern. Es sind insgesamt f¨
unf Testpersonen, die die Geste korrekt ausf¨
uhren. Die
Testpersonen geben an, dass die symbolische Geste nicht intuitiv und zu kompli-
ziert ist. Favorisiert werden physikalische Gesten, wie die Hold- oder Double-Tap-
Geste. Aufgrund dieses Ergebnisses ist es sinnvoll f¨
ur das Einsetzen eines Daten-
elements die Double-Tap-Geste zu verwenden, die auf dem freien Hintergrund aus-
gef¨
uhrt wird. Aktivit¨
aten d¨
urfen w¨
ahrend dieser Gestendurchf¨
uhrung nicht ber¨
uhrt
werden, da dies sonst die Umbenennen-Funktion ausl¨
ost.
7.2.1.16 F16 (Hilfe aufrufen)
Die Testpersonen haben die Aufgabe einen Hilfe-Dialog aufzurufen, der alle imple-
mentierten Gesten inklusive Beschreibung auff¨
uhrt.
Es werden bei dieser Aufgabe in Teil 1 sehr viele unterschiedliche L¨
osungen in
durchschnittlich 48,64 Sekunden ausgef¨
uhrt (siehe Abb. 7.22). Es handelt sich
hierbei um die erste Aufgabe des Experiments, bei der sich die Testpersonen
zun¨
achst auf das Experiment einstellen m¨
ussen.
89
7 Evaluation der Implementierung
20 40 60 80 100
Teil 1
Teil 3
Abbildung 7.22: Bearbeitungszeiten (in Sek.) von Aufgabe F16 (Hilfe aufrufen).
Drei Testpersonen rufen den Hilfe-Dialog mithilfe einer oberen Men¨
uleiste auf. Da-
bei tippen sie auf einen Button, der ein Fragezeichen-Symbol besitzt.
Physikalische Gesten werden von drei Testpersonen bevorzugt (siehe Tabelle 7.18).
Sie f¨
uhren eine Swipe-Geste aus, um den Hilfe-Dialog von oben nach unten oder
von links nach rechts auf die Bearbeitungsfl¨
ache zu ziehen. In einem Fall werden
f¨
ur die Swipe-Geste drei Finger gleichzeitig benutzt.
Ermittelte Werte
Symbolische Gesten 45,46%
Physikalische Gesten 27,27%
Men¨u-basierte L¨
osungen 27,27%
Tabelle 7.18: Gesten-Verteilung beim Aufrufen der Hilfe.
Die Mehrheit der Testpersonen entscheidet sich eine symbolische Geste zu ver-
wenden. Eine Testperson zeichnet ein H-Symbol und die restlichen Testpersonen
ein Fragezeichen-Symbol in den Bearbeitungsbereich. Das Fragezeichen-Symbol
wird ebenfalls in der Implementierung eingesetzt. Die Wahl des Symbols f¨
ur die
Implementierung hat sich mit Teil 3 des Experiments best¨
atigt, da sich alle Test-
personen in diesem Teil an die Geste erinnern k¨
onnen und die Aufgabe in durch-
schnittlich 17,45 Sekunden l¨
osen.
Einige Testpersonen machen nach dem Experiment den Vorschlag eine kontext-
sensitive Hilfe-Funktion zu implementieren. Wird beispielsweise das Fragezeichen
auf einer Aktivit¨
at gezeichnet, zeigt der sich ¨
offnende Hilfe-Dialog nur Modellie-
rungsfunktionen an, die sich auf die entsprechende Aktivit¨
at anwenden lassen.
7.2.1.17 F17 (R¨uckg¨
angig machen)
Bereits ausgef¨
uhrte Aktionen k¨
onnen wieder r¨
uckg¨
angig gemacht werden. Die
Testpersonen m¨
ussen sich f¨
ur diese Funktion in Teil 1 eine Geste ¨
uberlegen. Auf-
grund ihrer Erfahrung mit Multi-Touch-Ger¨
aten f¨
allt den meisten Testpersonen die-
90
7.2 Auswertung der experimentellen Untersuchung
se Aufgabe nicht besonders schwer, weshalb sie im Durchschnitt nur 22,09 Sekun-
den ben¨
otigen (siehe Abb. 7.23). Dabei kommen allerdings sehr viele unterschied-
liche Gesten zum Einsatz.
10 20 30 40 50
Teil 1
Teil 3
Abbildung 7.23: Bearbeitungszeiten (in Sek.) von Aufgabe F17 (R¨
uckg¨
angig
machen).
Zwei Testpersonen bevorzugen einen einfachen Button in einer oberen Men¨
uleiste,
sowie es von aktuellen Browsern her bekannt ist.
Vier Testpersonen entscheiden sich f¨
ur eine physikalische Geste (siehe Tabelle
7.19). Dabei handelt es sich in drei F¨
allen um eine Swipe-Geste, die entweder von
links nach rechts oder umgekehrt ausgef¨
uhrt wird. Eine Double-Tap-Geste kommt
ebenfalls zum Einsatz.
Ermittelte Werte
Symbolische Gesten 45,46%
Physikalische Gesten 36,36%
Men¨u-basierte L¨
osungen 18,18%
Tabelle 7.19: Gesten-Verteilung f¨
ur R¨
uckg¨
angig machen.
F¨
unf symbolische Gesten werden bei dieser Aufgabe verwendet. In zwei F¨
allen
handelt es sich um einen Kreis, den die Testpersonen gegen den Uhrzeigersinn
in den Bearbeitungsbereich zeichnen. Zwei Testpersonen zeichnen ein nach links
ausgerichteten Pfeil. Bei einem Pfeil ist allerdings nur die obere H¨
alfte der Pfeilspit-
ze sichtbar. Eine Testperson zeichnet eine Spirale, um die R¨
uckg¨
angig-Funktion
auszul¨
osen.
Nachdem die Testpersonen das Tutorial in Teil 2 des Experiments absolvieren,
m¨
ussen sie sich in Teil 3 an die implementierte Geste f¨
ur die Funktion erinnern.
Dies gelingt nur acht Testpersonen des Experiments. Die durchschnittliche Zeit
zum L¨
osen der Aufgabe betr¨
agt 31,36 Sekunden, was im Vergleich zu den anderen
Aufgaben ein akzeptabler Wert ist.
Mit der implementierten Geste sind viele Testpersonen unzufrieden. Kritisiert wird
91
7 Evaluation der Implementierung
vor allem die zu lange Ausf¨
uhrungsdauer der Geste, sowie die zu hohe Komple-
xit¨
at. Es gibt Vorschl¨
age die Geste durch eine Swipe-Geste nach links oder eine
symbolische Geste in Form eines Kreises zu ersetzen. Dies sollte bei einer erneu-
ten Gesten-Implementierung beachtet werden.
7.2.1.18 F18 (Lese- und Schreibkante einf¨ugen)
Die Testpersonen m¨
ussen bei dieser Aufgabe eine Lesekante zwischen dem Da-
tenelement ”CustomerPhone“ und der Aktivit¨
at ”Load Customer Data“ einf¨
ugen.
In Teil 1 des Experiments ben¨
otigen sie hierf¨
ur durchschnittlich 28,64 Sekunden
(siehe Abb. 7.24).
10 20 30 40
Teil 1
Teil 3
Abbildung 7.24: Bearbeitungszeiten (in Sek.) von Aufgabe F18 (Lese- und Schreib-
kante einf¨
ugen).
Es gibt eine Testperson, die f¨
ur diese Aufgabe ein Kontextmen¨
u verwendet. Zuvor
tippt sie die Aktivit¨
at an, um die Lesekante im Kontextmen¨
u auszuw¨
ahlen. An-
schließend tippt sie auf das Datenelement, um dieses mit der Aktivit¨
at zu verbin-
den.
Zwei Testpersonen zeichnen die Lesekante unter Verwendung eines Pfeil-Symbols
ein. Die restlichen acht Testpersonen verwenden eine physikalische Geste. Sie
f¨
uhren eine Strich-Geste aus, die beim Datenelement startet und bei der Aktivit¨
at
endet.
Der Vergleich mit [23] in Tabelle 7.20 zeigt, dass die Mehrheiten bei beiden Expe-
rimenten ¨
ubereinstimmen.
Ermittelte Werte [23]
Symbolische Gesten 18,18% 30,77%
Physikalische Gesten 72,73% 57,69%
Men¨u-basierte L¨
osungen 9,09% 11,54%
Tabelle 7.20: Gesten-Verteilung beim Einf¨
ugen einer Lesekante.
92
7.3 Abschließende Bemerkungen
F¨
ur dieselbe Aufgabe in Teil 3 ben¨
otigen die Testpersonen durchschnittlich 23,00
Sekunden. Alle Testpersonen k¨
onnen sich ohne Weiteres an die implementierte
Geste erinnern, da die Mehrheit sich ebenfalls in Teil 1 f¨
ur die Geste entschieden
hat. Die Strich-Geste hat sich somit f¨
ur das Erstellen von Lese- sowie Schreibkan-
ten etabliert.
7.3 Abschließende Bemerkungen
Die H¨
alfte aller Aufgaben werden im dritten Teil des Experiments von allen Test-
personen problemlos gel¨
ost. Im Durchschnitt k¨
onnen sich die Testpersonen an
3,64 Gesten nicht mehr erinnern, finden die Wahl einiger Gesten dennoch als
sinnvoll (siehe Abb. 7.25). Eine ¨
Anderung dieser Gesten ist deshalb nicht not-
wendig. Dies sieht bei den Gesten f¨
ur die Modellierungsfunktionen F6 (Element
reduzieren), F13 (Subprozess aufl¨
osen), F15 (Datenelement einf¨
ugen) und F17
(R¨
uckg¨
angig machen) allerdings anders aus. Aufgrund ihrer Komplexit¨
at und lan-
gen Durchf¨
uhrungsdauer sollten sie in zuk¨
unftigen Verbesserungsarbeiten ersetzt
werden, sofern Kollisionen mit anderen Gesten ausgeschlossen werden k¨
onnen.
Alternative Gesten-Implementierungen sind in den Abschnitten 7.2.1.6, 7.2.1.13,
7.2.1.15 und 7.2.1.17 beschrieben.
1 2 3 4 5 6
Anzahl Gesten
Abbildung 7.25: Anzahl Gesten, an die sich die Testpersonen in Teil 3 nicht erin-
nern k¨
onnen.
In zwei von acht Vergleichen mit [23] stimmen die Mehrheiten der beiden Experi-
mente nicht ¨
uberein. Die Unterschiede sind hier allerdings sehr gering und w¨
urden
sich wom¨
oglich durch eine Erh¨
ohung der Teilnehmerzahl angleichen. In einigen
F¨
allen ist es auch nicht immer eindeutig, die ausgef¨
uhrten Gesten einem Bedien-
konzept zuzuordnen, weshalb dies ebenfalls zu einigen Abweichungen f¨
uhrt.
Wird zwischen Testpersonen mit und ohne Erfahrung mit Prozess-Management
unterschieden, ergibt sich folgende Verteilung (siehe Abb. 7.26 und Abb. 7.28): An
dem Experiment nehmen zwei Testpersonen ohne und neun Testpersonen mit Er-
fahrung mit Prozess-Management teil. Die Testpersonen ohne Erfahrung brauchen
pro Aufgabe im ersten Teil des Experiments durchschnittlich 27,58 Sekunden. F¨
ur
die Bearbeitung aller Aufgaben des ersten Teils ben¨
otigen sie im Durchschnitt 8,28
93
7 Evaluation der Implementierung
Minuten. Im Gegensatz dazu ben¨
otigen die Testpersonen mit Erfahrung mehr Zeit,
obwohl hier ein besserer Wert zu erwarten w¨
are. Pro Aufgabe ben¨
otigen die Test-
personen mit Erfahrung durchschnittlich 35,27 Sekunden und f¨
ur die L¨
osung aller
Aufgaben im ersten Teil insgesamt 10,58 Minuten.
Abbildung 7.26: Durchschnittliche Bearbeitungszeiten (in Sek.) pro Aufgabe von
Testpersonen mit und ohne Erfahrung mit Prozess-Management.
In Teil 3 des Experiments ist das Ergebnis umgekehrt. Bei diesem Teil ben¨
otigen
die Testpersonen mit Erfahrung weniger Zeit. Sie l¨
osen eine Aufgabe in durch-
schnittlich 31,83 Sekunden und brauchen f¨
ur alle Aufgaben im dritten Teil 9,55 Mi-
nuten im Durchschnitt. Dem gegen¨
uber ben¨
otigen Testpersonen ohne Erfahrung
durchschnittlich 39,72 Sekunden pro Aufgabe und f¨
ur das L¨
osen aller Aufgaben im
Durchschnitt 11,92 Minuten. In diesem Teil sind es 4,5 Aufgaben, die von den Test-
personen ohne Erfahrung nicht gel¨
ost werden. Testpersonen mit Erfahrung k¨
onnen
sich nur an 3,44 Aufgaben nicht erinnern.
Tabelle 7.21 stellt die Verteilung der Gesten dar, die von Testpersonen mit und
ohne Erfahrung bez¨
uglich Prozess-Management bevorzugt werden. Die Mehrheit
der Testpersonen auf beiden Seiten entscheidet sich hierbei haupts¨
achlich f¨
ur phy-
sikalische Gesten. Der Unterschied ist, dass sich Testpersonen ohne Erfahrung
¨
ofters f¨
ur Men¨
u-basierte L¨
osungen entscheiden als Testpersonen mit Erfahrung
bez¨
uglich Prozess-Management.
94
7.3 Abschließende Bemerkungen
Abbildung 7.27: Gesamtbearbeitungszeiten (in Min.) von Testpersonen mit und oh-
ne Erfahrung mit Prozess-Management.
123456
mit Erf.
ohne Erf.
Abbildung 7.28: Anzahl Gesten, an die sich Testpersonen mit und ohne Erfahrung
mit Prozess-Management nicht erinnern k¨
onnen.
Erfahrung Ohne Erfahrung
Symbolische Gesten 30,86% 11,11%
Physikalische Gesten 50,00% 52,78%
Men¨u-basierte L¨
osungen 19,14% 36,11%
Tabelle 7.21: Bevorzugte Gesten von Testpersonen mit und ohne Erfahrung
bez¨
uglich Prozess-Management.
95
7 Evaluation der Implementierung
96
8 Zusammenfassung und Ausblick
Das proView-Framework unterst¨
utzt die Erstellung und Modifikation von Prozess-
sichten. Hierf¨
ur wird eine Vielzahl an Modellierungsfunktionen angeboten, die in
einer webbasierten Umgebung ausgef¨
uhrt werden. Diese Arbeit beinhaltet die Im-
plementierung einer Erweiterung von proView, mit der die zur Verf¨
ugung stehen-
den Modellierungsfunktionen per Multi-Touch-Gesten ausgel¨
ost werden k¨
onnen.
Dies soll den Einsatz von proView auf Multi-Touch-Ger¨
aten, wie Smartphones oder
Tablets, verbessern. Nach einer ausf¨
uhrlichen Beschreibung des proView-Projekts
und unterschiedlicher Bedienkonzepte wird die Problemstellung dieser Arbeit ana-
lysiert. Es werden verschiedene Experimente, die sich mit dem Thema Multi-Touch
besch¨
aftigen, durchleuchtet, um passende Multi-Touch-Gesten f¨
ur die Modellie-
rungsfunktionen zu finden. Da die Visualisierungskomponente von proView mit
dem Vaadin-Framework entwickelt worden ist und f¨
ur dieses Framework keine ge-
eigneten Multi-Touch-Add-ons existieren, ist die Implementierung eines eigenen
Add-ons notwendig, das alle f¨
ur diese Arbeit relevanten Multi-Touch-Gesten un-
terst¨
utzt. Dieses TouchPanel-Add-on wird in proView integriert und mit den beste-
henden Modellierungsfunktionen verkn¨
upft.
Der abschließende Teil der Arbeit beinhaltet eine experimentelle Untersuchung
der Implementierung. In einem aus drei Teilen bestehenden Experiment hatten die
Testpersonen die Aufgabe, sich eigene Gesten einfallen zu lassen, sowie die im-
plementierten Gesten nach einem Tutorial anzuwenden bzw. zu testen. Ein Groß-
teil der f¨
ur die proView-Funktionen gew¨
ahlten Multi-Touch-Gesten ist von den Test-
personen akzeptiert worden.
In zuk¨
unftigen Verbesserungsarbeiten k¨
onnen die von den Testpersonen des Ex-
periments als negativ bewerteten Gesten durch bessere L¨
osungen ersetzt wer-
den. Zudem ist der Einsatz von Responsive Webdesign f¨
ur die webbasierte Vi-
sualisierungskomponente des proView-Frameworks sinnvoll, da einige Bedienele-
mente der Benutzeroberfl¨
ache f¨
ur mobile Ger¨
ate mit kleinen Bildschirmen, die
per Fingereingaben bedient werden, ungeeignet sind. Je nach Gr¨
oße des Ger¨
ats,
Aufl¨
osung, Orientierung sowie Eingabem¨
oglichkeiten, sollten die Bedienelemente
automatisch ihre Gr¨
oße anpassen.
97
8 Zusammenfassung und Ausblick
98
A Anhang
A.1 Benutzerdefiniertes Gesten-Set
Abbildung A.1: Benutzerdefiniertes Gesten-Set.
99
A Anhang
A.2 Prozessmodell
Abbildung A.2: Das im Experiment verwendete Prozessmodell.
100
A.3 Ergebnisse der experimentellen Untersuchung
A.3 Ergebnisse der experimentellen Untersuchung
Legende
F1: Element ausw¨
ahlen
F2: Aktivit¨
at einf¨
ugen
F3: Element umbenennen
F4: Element l¨
oschen
F5: Elemente aggregieren
F6: Element reduzieren
F7: Verzweigungsblock einf¨
ugen
F8: Verzweigung einf¨
ugen
F9: Schleife einf¨
ugen
F10: Synchronisationskante einf¨
ugen
F11: Subprozess anzeigen
F12: Subprozess verbergen
F13: Subprozess aufl¨
osen
F14: Prozesssicht erstellen
F15: Datenelement einf¨
ugen
F16: Hilfe aufrufen
F17: R¨
uckg¨
angig machen
F18: Lese- und Schreibkante einf¨
ugen
S: Symbolische Geste
G: Physikalische Geste
M: Men¨
u-basierte L¨
osung
101
A Anhang
TNr Testperson-Nummer
FNr Funktions-Nummer
Geschl.: Geschlecht
m: m¨
annlich
w: weiblich
L/R: Links- / Rechtsh¨
ander
T¨
atigk.: T¨
atigkeit
ST: Student
MA: Mitarbeiter des Instituts f¨
ur Datenbanken und
Informationssysteme der Universit¨
at Ulm
SO: Sonstige
Erfahr. MT: Erfahrung im Umgang mit Multi-Touch-Ger¨
aten
Erfahr. PM: Erfahrung mit Prozess-Management
TNr Geschl. Alter L/R T¨
atigk. Erfahr. MT Erfahr. PM PM Experte
1 m 24 R ST ja ja ja
2 m 27 R ST ja ja ja
3 m 25 R ST ja ja ja
4 m 32 R SO ja nein nein
5 m 29 R MA ja ja nein
6 m 26 R ST ja ja ja
7 m 27 L ST ja ja nein
8 m 25 R ST ja ja nein
9 m 25 R ST ja nein nein
10 w 24 R ST ja ja ja
11 m 25 R ST ja ja nein
Tabelle A.1: Demografische Daten der Testpersonen des Experiments.
102
A.3 Ergebnisse der experimentellen Untersuchung
TNr Smartphone Tablet Android iOS Windows
1 ja nein ja nein nein
2 ja ja ja nein ja
3 nein ja nein nein ja
4 ja ja nein ja nein
5 ja nein ja nein nein
6 ja ja ja ja nein
7 ja nein ja nein nein
8 ja nein ja ja nein
9 ja ja ja ja nein
10 nein ja nein ja nein
11 ja nein ja nein nein
Tabelle A.2: Von den Testpersonen verwendete Multi-Touch-Ger¨
ate und
Betriebssysteme.
TNr Erfahr. PM
(in Jahren)
analysiert / gele-
sen (Letzten 12
Monate)
erstellt / bearbei-
tet (Letzten 12
Monate)
øAnzahl
Aktivit¨
aten
1 2 40 20 7
2 3 50 50 25
3 5 10 5 10
5 5 0 0 0
6 3 50 50 20
7 3 0 0 0
8 2 0 0 0
10 3 15 15 10
11 2 0 0 0
ø 3,11 18,33 15,56 8
Tabelle A.3: Erfahrungen der Testpersonen mit Prozess-Management.
103
A Anhang
FNr 1 2 3 4 5 6 7 8 9 10 11
F1: G G G G G G G G G G G
F2: M S G M G M G G G S M
F3: G G G M G M G G G G G
F4: M G S G S S G G G S G
F5: S S G S G G S S M S G
F6: G G G M G G M G G G M
F7: M M S M S S S G G M M
F8: M G G M M G M M G S M
F9: M S S S S S S S S S M
F10: M S S G G G G G G S G
F11: G G G G S G G G G G G
F12: G G G G G G G G G G G
F13: G S G M G G S G M S M
F14: S M S M S S S S M S G
F15: M M S M S G M M M M G
F16: M S S G S M S G S M G
F17: M S S M S G S G G S G
F18: M S G G S G G G G G G
Tabelle A.4: Von den Testpersonen gew¨
ahlte Bedienkonzepte.
Abbildung A.3: Gew¨
ahlte Bedienkonzepte im ¨
Uberblick.
104
A Anhang
FNr Aufgabe H¨
aufigkeit (gel ¨
ost)
F2 Aktivit¨
at einf¨
ugen 11
F5 Elemente aggregieren 11
F9 Schleife einf¨
ugen 11
F10 Synchronisationskante einf¨
ugen 11
F12 Subprozess verbergen 11
F14 Prozesssicht erstellen 11
F16 Hilfe aufrufen 11
F18 Lese- und Schreibkante einf¨
ugen 11
F1 Element ausw¨
ahlen 10
F8 Verzweigung einf¨
ugen 9
F11 Subprozess anzeigen 9
F4 Element l¨
oschen 8
F17 R¨
uckg¨
angig machen 8
F3 Element umbenennen 7
F13 Subprozess aufl¨
osen 7
F7 Verzweigungsblock einf¨
ugen 6
F15 Datenelement einf¨
ugen 5
F6 Element reduzieren 1
Tabelle A.5: Anzahl gel¨
oster Aufgaben des dritten Teils des Experiments in abstei-
gender Reihenfolge.
106
A.3 Ergebnisse der experimentellen Untersuchung
FNr Aufgabe øBearbeitungsdauer (in Sek.)
F11 Subprozess anzeigen 14,36
F1 Element ausw¨
ahlen 16,64
F12 Subprozess verbergen 20,09
F17 R¨
uckg¨
angig machen 22,09
F3 Element umbenennen 25,45
F15 Datenelement einf¨
ugen 28,09
F18 Lese- und Schreibkante einf¨
ugen 28,64
F4 Element l¨
oschen 28,73
F2 Aktivit¨
at einf¨
ugen 29,64
F8 Verzweigung einf¨
ugen 32,64
F13 Subprozess aufl¨
osen 37,36
F10 Synchronisationskante einf¨
ugen 37,45
F5 Elemente aggregieren 39,00
F6 Element reduzieren 40,91
F9 Schleife einf¨
ugen 42,36
F16 Hilfe aufrufen 48,64
F14 Prozesssicht erstellen 56,73
F7 Verzweigungsblock einf¨
ugen 60,91
ø 33,87
Tabelle A.6: Durchschnittliche Bearbeitungszeit der einzelnen Aufgaben im ersten
Teil des Experiments in aufsteigender Reihenfolge.
107
A Anhang
FNr Aufgabe øBearbeitungsdauer (in Sek.)
F12 Subprozess verbergen 15,09
F16 Hilfe aufrufen 17,45
F1 Element ausw¨
ahlen 18,27
F10 Synchronisationskante einf¨
ugen 23,00
F18 Lese- und Schreibkante einf¨
ugen 23,00
F14 Prozesssicht erstellen 28,73
F3 Element umbenennen 30,82
F8 Verzweigung einf¨
ugen 31,36
F17 R¨
uckg¨
angig machen 31,36
F15 Datenelement einf¨
ugen 31,55
F11 Subprozess anzeigen 32,91
F4 Element l¨
oschen 33,27
F2 Aktivit¨
at einf¨
ugen 35,64
F9 Schleife einf¨
ugen 37,91
F5 Elemente aggregieren 46,73
F6 Element reduzieren 51,73
F13 Subprozess aufl¨
osen 52,27
F7 Verzweigungsblock einf¨
ugen 57,64
ø 33,26
Tabelle A.7: Durchschnittliche Bearbeitungszeit der einzelnen Aufgaben im dritten
Teil des Experiments in aufsteigender Reihenfolge.
108
A.4 $1 Gesture Recognizer
A.4 $1 Gesture Recognizer
Algorithm 2 Schritt 1. Resample den points Pfad, sodass nPunkte mit gleichm¨
aßi-
gen Abstand zueinander bestehen bleiben.
1: function RESAMPLE(points, n)
2: I←PATH-LENGTH(points)/(n–1)
3: D←0
4: newPoints ←points0
5: for all point pifor i≥1in points do
6: d←DISTANCE(pi−1, pi)
7: if (D+d)≥Ithen
8: qx←pi−1x+ ((I–D)/d)∗(pix–pi−1x)
9: qy←pi−1y+ ((I–D)/d)∗(piy–pi−1y)
10: APPEND(newPoints, q)
11: INSERT(points, i, q). q ist das n¨
achste pi
12: D←0
13: else
14: D←D+d
15: end if
16: end for
17: return newPoints
18: end function
19: function PATH-LENGTH(A)
20: d←0
21: for ifrom 1to |A|step 1do
22: d←d+DISTANCE(Ai−1, Ai)
23: end for
24: return d
25: end function
109
A Anhang
Algorithm 3 Schritt 2. Rotiere points, sodass ihr indikativer Winkel bei 0◦liegt.
1: function ROTATE-TO-ZERO(points)
2: c←CENTROID(points).berechnet (x, y)
3: θ←ATAN(cy–points0y, cx–points0x).f¨
ur −π≤θ≤π
4: newPoints ←ROTATE-BY(points, −θ)
5: return newPoints
6: end function
7: function ROTATE-BY(points, θ)
8: c←CENTROID(points)
9: for all point pin points do
10: qx←(px–cx)COS(θ)–(py–cy)SIN(θ)+cx
11: qy←(px–cx)SIN(θ)–(py–cy)COS(θ)+cy
12: APPEND(newPoints, q)
13: end for
14: return newPoints
15: end function
Algorithm 4 Schritt 3. Skaliere points, sodass die Bounding Box eine Gr¨
oße von
size2besitzt. Verschiebe points anschließend zum Ursprung. BOUNDING-BOX
liefert ein Rechteck mit den Werten (minx, miny),(maxx, maxy)zur¨
uck. F¨
ur Ge-
sten, die als Referenzmuster abgelegt werden sollen, sollten die Schritte 1-3 auf
die eingegebenen Punkte angewandt werden. F¨
ur ausgef¨
uhrte Gesten, sollten die
Schritte 1-4 verwendet werden.
1: function SCALE-TO-SQUARE(points, size)
2: B←BOUNDING-BOX(points)
3: for all point pin points do
4: qx←px∗(size/Bwidth)
5: qy←py∗(size/Bheight)
6: APPEND(newPoints, q)
7: end for
8: return newPoints
9: end function
10: function TRANSLATE-TO-ORIGIN(points)
11: c←CENTROID(points)
12: for all point pin points do
13: qx←px–cx
14: qy←py–cy
15: APPEND(newPoints, q)
16: end for
17: return newPoints
18: end function
110
A.4 $1 Gesture Recognizer
Algorithm 5 Schritt 4. Vergleiche points mit den abgelegten Referenzmustern.
Die size Variable von RECOGNIZE bezieht sich auf die Variable size von SCALE-
TOSQUARE in Schritt 3. Das Symbol ϕgleicht dem Ausdruck 1
2(−1 + √5). Es
wird θ=±45◦und θ∆= 2◦von RECOGNIZE verwendet. Aufgrund der Funkti-
on RESAMPLE, kann angenommen werden, dass Aund Bdieselbe Anzahl an
Punkten besitzen, d.h. |A|=|B|.
1: function RECOGNIZE(points, templates)
2: b←+∞
3: for all template Tin templates do
4: d←DISTANCE-AT-BEST-ANGLE(points, T, −θ, θ, θ∆)
5: if d<bthen
6: b←d
7: T0←T
8: end if
9: end for
10: score ←1–b/0.5p(size2+size2)
11: return hT0, scorei
12: end function
13: function DISTANCE-AT-BEST-ANGLE(points, T, θa, θb, θ∆)
14: x1←ϕθa+ (1–ϕ)θb
15: f1←DISTANCE-AT-ANGLE(points, T, x1)
16: x2←(1–ϕ)θa+ϕθb
17: f2←DISTANCE-AT-ANGLE(points, T, x2)
18: while |θb–θa|> θ∆do
19: if f1< f2then
20: θb←x2
21: x2←x1
22: f2←f1
23: x1←ϕθa+ (1–ϕ)θb
24: f1←DISTANCE-AT-ANGLE(points, T, x1)
25: else
26: θa←x1
27: x1←x2
28: f1←f2
29: x2←(1–ϕ)θa+ϕθb
30: f2←DISTANCE-AT-ANGLE(points, T, x2)
31: end if
32: end while
33: return MIN(f1, f2)
34: end function
35: function DISTANCE-AT-ANGLE(points, T, θ)
36: newPoints ←ROTATE-BY(points, θ)
37: d←PATH-DISTANCE(newPoints, Tpoints)
38: return d
39: end function
40: function PATH-DISTANCE(A, B)
41: d←0
42: for ifrom 0to |A|step 1do
43: d←d+DISTANCE(Ai, Bi)
44: end for
45: return d/|A|
46: end function
111
Literaturverzeichnis
[1] BAUMGARTEN, Bernd (1996): Petri-Netze - Grundlagen und Anwendungen.
Spektrum-Akademischer Verlag.
[2] B ¨
URINGER, Stefan (2012): Development of a Business Process Abstraction
Component based on Process Views. Bachelorarbeit, Fakult¨
at f¨
ur Ingenieur-
wissenschaften und Informatik, Universit¨
at Ulm.
[3] DADAM, Peter; REICHERT, Manfred (2009): The ADEPT Project: A Decade of
Research and Development for Robust and Flexible Process Support. Tech-
nical Report, Fakult¨
at f¨
ur Ingenieurwissenschaften und Informatik, Universit¨
at
Ulm.
[4] FISHER, Bill (2013): Touchy.https://github.com/HotStudio/touchy (be-
sucht am 6. Aug. 2013).
[5] GRANKVIST, Michael (2011): TouchMenu.http://vaadin.com/addon/
touchmenu (besucht am 3. Aug. 2013).
[6] GROSSKOPF, Alexander; DECKER, Gero; WESKE, Mathias (2009): The Pro-
cess: Business Process Modeling Using BPMN. Meghan-Kiffer Press.
[7] GR¨
ONROOS, Marko (2013): Book of Vaadin: Vaadin 7. 2. Auflage. Vaadin Ltd.
[8] JGESTURES (n.d.): jGestures: A jQuery Plugin for Gesture Events.http://
jgestures.codeplex.com/ (besucht am 6. Aug. 2013).
[9] HONG, Jason I.; LANDAY, James A. (2010): SATIN: A Toolkit for Informal Ink-
based Applications. In: Proc. UIST ’00. New York: ACM Press, 63-72.
[10] JQUERY FOUNDATION (2013): jQuery.http://jquery.com/ (besucht am 6.
Aug. 2013).
[11] KOLB, Jens; RUDNER, Benjamin; REICHERT, Manfred (2012): Towards
Gesture-based Process Modeling on Multi-Touch Devices. In: 1st Int’l Work-
shop on Human-Centric Process-Aware Information Systems (HC-PAIS’12),
Gdansk, Poland.
[12] KOLB, Jens; REICHERT, Manfred (2013): Supporting Business and IT through
Updatable Process Views: The proView Demonstrator. In: ICSOC’12, Demo
113
Literaturverzeichnis
Track of the 10th Int’l Conference on Service Oriented Computing, November
12-15, 2012, Shanghai, China.
[13] KOLB, Jens; REICHERT, Manfred (2013): Data Flow Abstractions and Adapta-
tions through Updatable Process Views. In: 28th Symposium on Applied Com-
puting (SAC’13), 10th Enterprise Engineering Track (EE’13), Coimbra, Portu-
gal, March 2013, ACM Press, pp. 1447-1453.
[14] KOLB, Jens; REICHERT, Manfred (2013): A Flexible Approach for Abstracting
and Personalizing Large Business Process Models. In: Applied Computing
Review, 13(1): 6-17, ACM SIGAPP.
[15] KOLB, Jens; LEOPOLD, Henrik; MENDLING, Jan; REICHERT, Manfred (2013):
Creating and Updating Personalized and Verbalized Business Process Des-
criptions. In: 6th IFIP WG 8.1 Working Conference on the Practice of Enterprise
Modeling (PoEM’13), Riga, Latvia, November 6-7, 2013, LNBIB, Springer.
[16] LANDAY, James A.; MYERS, Brad A. (1993): Extending an Existing User Inter-
face Toolkit to Support Gesture Recognition. In: Proc. CHI ’93. New York: ACM
Press, 91-92.
[17] LIN, James; NEWMAN, Mark W.; HONG, Jason I.; LANDAY, James A. (2000):
DENIM: Finding a Tighter Fit Between Tools and Practice for Website Design.
In: Proc. CHI ’00. New York: ACM Press, 510-517.
[18] MYERS, Cory S.; RABINER, Lawrence R. (1981): A Comparative Study of
Several Dynamic Time-Warping Algorithms for Connected Word Recognition.
In: The Bell System Technical J. 60 (7), 1389-1409.
[19] OMG (2011): Business Process Model and Notation (BPMN).http://www.
omg.org/spec/BPMN/2.0/PDF (besucht am 2. Jan. 2014).
[20] PETERS, Andre (2013): JSlider.http://vaadin.com/addon/
jslider-add-on (besucht am 3. Aug. 2013).
[21] ROBINSON, James; MCCORMACK, Cameron (2013): Timing control for script-
based animations: W3C Candidate Recommendation 31 October 2013.http:
//www.w3.org/TR/animation-timing/ (besucht am 12. Sep. 2013).
[22] RUBINE, Dean (1991): Specifying Gestures by Example. In: Proc. SIGGRAPH
’91. New York: ACM Press, 329-337.
[23] RUDNER, Benjamin (2011): Fortgeschrittene Konzepte der Prozessmodellie-
rung durch den Einsatz von Multi-Touch-Gesten. Bachelorarbeit, Fakult¨
at f¨
ur
Ingenieurwissenschaften und Informatik, Universit¨
at Ulm.
114
Literaturverzeichnis
[24] SCHEPERS, Doug; SANGWHAN, Moon; BRUBECK, Matt; et al. (2013): Touch
Events version 1: W3C Proposed Recommendation 09 May 2013.http:
//www.w3.org/TR/2013/PR-touch-events-20130509/ (besucht am 12. Sep.
2013).
[25] SWIGART, Scott (2005): Easily Write Custom Gesture Recognizers for
Your Tablet PC Applications.http://msdn.microsoft.com/en-us/library/
aa480673.aspx (besucht am 21. Sep. 2013).
[26] TAHVONEN, Matti (2011): TouchScroll.http://vaadin.com/addon/
touchscroll (besucht am 3. Aug. 2013).
[27] TANGELDER, Jorik (n.d.): Hammer.js - A JavaScript Library for Multi-Touch
Gestures.http://eightmedia.github.io/hammer.js/ (besucht am 6. Aug.
2013).
[28] VAN SOMEREN, Maarten W.; BARNARD, Yvonne F.; SANDBERG, Jacobijn A.C.
(1994): The Think Aloud Method: A Practical Guide to Modelling Cognitive
Processes. Academic Press, London.
[29] VILLAR Javi J. (n.d.): QuoJS - Micro JavaScript Library.http://quojs.
tapquo.com (besucht am 3. Aug. 2013).
[30] WOBBROCK, Jacob O.; WILSON, Andrew D.; LI, Yang (2007): Gestures without
Libraries, Toolkits or Training: A $1 Recognizer for User Interface Prototypes.
In: Proc. of the 20th Annual ACM Symposium on User Interface Software and
Technology, New York, USA, S. 159-168.
[31] WOBBROCK, Jacob O.; MORRIS, Meredith R.; WILSON, Andrew D. (2009):
User-defined Gestures for Surface Computing. In: Proc. 27th Int’l Conf on Hu-
man Factors in Computing Systems (CHI ’09), New York, USA, S. 1083-1092.
[32] WOHLIN, Claes; RUNESON, Per; HST, Martin; OHLSSON, Magnus C. (2012):
Experimentation in Software Engineering. Springer Publishing Company, In-
corporated.
115
Name: Adam Just Matrikelnummer: 673424
Erkl¨
arung
Ich erkl¨
are, dass ich die Arbeit selbst¨
andig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel verwendet habe.
Ulm,den ........................................................................
Adam Just
