Universität Ulm | 89069 Ulm | Germany
Fakultät für
Ingenieurwissenschaften
und Informatik
Institut für Datenbanken und
Informationssysteme
MASTERARBEIT
COLLABORATIVE MODELING OF
BUSINESS PROCESSES ON CO-LOCATED
TABLETOP SYSTEMS
VORGELEGT VON
Sebastian Ronis
GUTACHTER
Prof. Dr. Manfred Reichert
Prof. Dr. Peter Dadam
BETREUER
Jens Kolb
2014
II
Fassung 25. September 2014
© 2014 Sebastian Ronis
III
KURZZUSAMMENFASSUNG
Most current Business Process Management Systems (BPMS) refer to single users,
working at a desktop PC individually. But especially, during the creation of pro-
cess models, domain and modeling experts work together. Therefore, a collabora-
tive BPMS offers possibilities to work in a team environment. The advantages of
collaborative process modelling are improved quality and accuracy of process
models. Thus, the user’s workload is reduced and the users learn from each other.
This thesis presents Process-Touch, which is a collaborative BPMS, using a tab-
letop and additional tablets or smartphones to create process models collabora-
tively. Process-Touch offers an easy to use Natural User Interface (NUI), sketch-
based input and the possibility to work with tablets or smartphones as a private
interaction device. Users can create and edit parts of the process model on their
tablets and smartphones and merge them on the tabletop using a tap gesture to
transfer the process model from the mobile device to the tabletop.
This thesis contributes a system for collaborative BPMS, general concepts and
requirements and a prototypical implementation. Moreover, the concept is evalu-
ated by experimental research, using the prototypical implementation. Hence,
improvements of the gesture-set, interaction design and implementation are
identified and discussed.
IV
DANKSAGUNG
Besonders bedanken möchte ich mich bei meinem Betreuer Jens Kolb, mit dem
ich während des Studiums interessante Projekte bearbeiten konnte, der mich im-
mer gefördert hat und mich durch die Masterarbeit geleitet hat.
Bei Herrn Prof. Dr. Manfred Reichert bedanke ich mich herzlich dafür, dass ich die
Arbeit im Institut anfertigen konnte, für die gute Ausstattung im Institut und die
Begutachtung der Arbeit.
Aus tiefsten Herzen möchte ich mich bei meinen Eltern bedanken, die mir die
Möglichkeit gegeben haben einen langen und guten Ausbildungsweg zu be-
schreiten. Ohne deren Unterstützung wäre es für mich nicht möglich gewesen das
Studium zu absolvieren.
V
INHALT
1 Einleitung ..................................................................................................................................... 1
1.1 Motivation .......................................................................................................................... 1
1.2 Problemstellung ............................................................................................................... 1
1.3 Beitrag der Arbeit ............................................................................................................ 2
1.4 Aufbau der Arbeit ............................................................................................................ 2
2 Related Work .............................................................................................................................. 3
3 Grundlagen ................................................................................................................................. 7
3.1 Business Process Model and Notation .................................................................... 7
3.2 Hardware ......................................................................................................................... 11
3.2.1 Near Field Communication .............................................................................. 11
3.2.2 Microsoft Pixel Sense ......................................................................................... 12
3.3 Touch-Eingabe mit mobilen Geräten.................................................................... 13
3.3.1 Erkennung einer Touch-Aktion auf mobilen Geräten ........................... 13
3.3.2 Präparierte Oberflächen.................................................................................... 14
3.3.3 Tabletop-System ................................................................................................. 15
3.4 Skizzenbasierte Eingabe ............................................................................................ 15
3.5 Gestaltgesetze ............................................................................................................... 17
4 Konzept Process-Touch ....................................................................................................... 21
4.1 Anforderungen an das Konzept .............................................................................. 21
4.2 Gesamtkonzept ............................................................................................................. 30
4.2.1 Alternativer Aufbau ............................................................................................. 32
4.2.2 Erstellung von Prozessmodellen .................................................................... 33
4.2.3 Bearbeitung von Prozessmodellen ............................................................... 34
4.2.4 Interaktion mit gedruckten Prozessmodellen .......................................... 34
4.3 Zusammenfassung ....................................................................................................... 36
5 Interaction-Design ................................................................................................................ 39
5.1 Allgemeine Interaktion ............................................................................................... 39
5.2 Gesten-Set für Benutzereingaben .......................................................................... 42
5.3 Benutzereingabe mit mobilen Geräten ................................................................ 47
5.4 Prüfung der korrekten BPMN Syntax .................................................................... 48
5.5 Layouting von Prozesselementen .......................................................................... 49
VI
5.6 Zusammenfassung ....................................................................................................... 52
6 Visual Design ........................................................................................................................... 53
6.1 Farben in Process Touch ............................................................................................ 53
6.2 Icons ud Typographie ................................................................................................. 55
6.3 Formen der Interaktionselemente.......................................................................... 57
6.4 Interaktionselemente .................................................................................................. 58
6.5 Rückmeldungen ............................................................................................................ 62
6.5.1 Syntaxprüfung ...................................................................................................... 63
6.5.2 Tablet-Touch-Aktionen ..................................................................................... 63
6.6 Zusammenfassung ....................................................................................................... 65
7 Proof-of-Concept-Implementierung .............................................................................. 67
7.1 Softwarearchitektur ..................................................................................................... 68
7.1.1 Das Design-Pattern Model-View-ViewModel .......................................... 69
7.1.2 Portable Class Library ........................................................................................ 70
7.2 Umsetzung des Prototypen ...................................................................................... 71
7.2.1 Model-Klassen ...................................................................................................... 71
7.2.2 ViewModel-Klassen ............................................................................................ 72
7.2.3 View des Tabletop-Systems ............................................................................ 73
7.2.4 View der Windows-Store-App ....................................................................... 77
7.3 Kommunikation und Datenaustausch .................................................................. 77
7.4 Skizzenbasierte Benutzereingabe ........................................................................... 82
7.4.1 Vereinfachung eines Polygons ....................................................................... 83
7.4.2 Symbolerkennung ............................................................................................... 85
7.4.3 Multiselektion von Prozesselementen......................................................... 89
7.5 Layouting der Prozesselemente .............................................................................. 90
7.6 Zusammenfassung ....................................................................................................... 91
8 Experimentelle Validation ................................................................................................... 93
8.1 Forschungsfrage und Experimentdefinition ....................................................... 93
8.1.1 Kontextauswahl und Zieldefinition ............................................................... 94
8.1.2 Hypothesendefintion ......................................................................................... 94
8.1.3 Aufbau des Experiments ................................................................................... 96
8.1.4 Gestaltung des Experiments.......................................................................... 102
8.1.5 Validität des Experiments ............................................................................... 103
VII
8.2 Ablauf des Experiments ........................................................................................... 105
8.2.1 Vorbereitung ....................................................................................................... 105
8.2.2 Durchführung ..................................................................................................... 105
8.2.3 Validation der Daten ........................................................................................ 107
8.3 Datenanalyse und Interpretation.......................................................................... 107
8.3.1 Datenanalyse und Beschreibende Statistik .............................................. 107
8.3.2 Hypothesentest .................................................................................................. 110
8.4 Qualitative Auswertung ............................................................................................ 110
8.4.1 Tabletop-System ............................................................................................... 111
8.4.2 Gesten .................................................................................................................... 112
8.4.3 Layouting von Prozessmodellen .................................................................. 113
8.4.4 Menüs .................................................................................................................... 114
8.4.5 Vollständigkeit von BPMN ............................................................................. 115
8.4.6 Implementierungsfehler ................................................................................. 115
8.5 Zusammenfassung ..................................................................................................... 116
9 Zusammenfassung und Ausblick ................................................................................... 119
A. ISO-Norm 9241/10 .................................................................................................................. ix
B. User Experience Questionnaire ....................................................................................... xvii
C. Allgemeine Fragen ................................................................................................................ xix
D. Leitfaden für den Experimentleiter ................................................................................. xxi
E. Einverständniserklärung .................................................................................................... xxiii
F. Anwendungsszenarien ....................................................................................................... xxiv
G. Prozessmodelle der Probanden .................................................................................... xxvii
H. Daten des Experiments .................................................................................................. xxxvii
VIII
1
1 EINLEITUNG
Die Vorteile von Business Process Management, oder auch Geschäftsprozess-
Management genannt, liegen klar auf der Hand: Transparenz, Effizienz und Agili-
tät der Organisation wird maßgeblich erhöht und folglich die Kosten gesenkt [1].
Ausgereifte Technologien erlauben einen breiten Einsatz verschiedenster Prozes-
se auf unterschiedlichen Prozessplattformen. Jedoch ist die Erstellung eines Pro-
zessmodells aufwändig und oft auch zeitintensiv. So werden 40% der Arbeitszeit
in Unternehmen dazu verwendet, Prozessmodelle zu erstellen [2]. Der Aufwand
rechtfertigt sich aus der Tatsache, dass die Geschäftsprozessmodellierung eine
der strategisch wichtigsten Aufgaben von Unternehmen ist, um dem Grundsatz
der Arbeitsteilung und Spezialisierung nachzukommen [2]. So ist das primäre Ziel
die Verbesserung von betrieblichen Arbeitsabläufen.
Aktuell sind zwei Arten der Kollaboration bei Software-Systemen weit verbreitet.
Benutzer sitzen getrennt an ihren jeweiligen Computern oder Notebooks und
erledigen kollaborative Aufgaben gemeinsam. Bei eng gekoppelten Arbeiten be-
darf dies einer detaillierten Absprache und Trennung der jeweiligen Aufgaben
und geht mit einem enormen Mehraufwand einher. Damit Benutzer Lösungen
gemeinsam erarbeiten und diskutieren können, kann auch gemeinsam ein Com-
puter verwendet werden. Jedoch ist diese Art der Kollaboration ineffizient, da
immer nur ein Benutzer das System bedienen kann und zeitgleiche Eingaben
nicht möglich sind. Bei eng gekoppelten Aufgaben, wie die Zusammenarbeit bei
komplexen Problemen, ist die kollaborative Arbeit mit Blickkontakt (face-to-face)
die beste Art der Zusammenarbeit [3] und kann durch Tabletop-Systemen reali-
siert werden.
Tabletop-Systeme ermöglichen durch Multi-Touch mehreren Benutzern die zeit-
gleiche Interaktion mit dem System. Traditionelle BPMS sind jedoch nicht für Mul-
ti-Touch-Systeme entworfen und nutzen folglich nicht das volle Potential der Ge-
räte [4].
1 EINLEITUNG
2
Daher stellt sich als einleitende Frage, wie auf Tabletop-Systemen kollaborative
Modellierung verbessert werden kann, um eng gekoppelte Aufgaben effizient zu
erledigen, gemeinsam Lösungen zu finden und diese gemeinsam diskutieren zu
können.
Der Beitrag dieser Arbeit ist die Identifikation und Kombination geeigneter Kon-
zepte aus dem Bereich der Human-Computer-Interaction (HCI), für die kollabora-
tive Geschäftsprozessmodellierung auf Tabletop-Systemen zu einem konsistenten
Gesamtsystem. Aus einem Teil des Gesamtsystems wird ein Software-System
entworfen und prototypisch implementiert. Anschließend wird mithilfe des Proto-
typs der das System in einem Experiment validiert und Verbesserungen werden
aufgezeigt. Der Fokus liegt dabei auf der Implementierung und Validation.
Kapitel 3 gibt einen Überblick über Geschäftsprozessmodellierung sowie techni-
sche Grundlagen, welche für die Arbeit relevant sind. Spezielle Hardware, wie das
SUR40 Tabletop-System von Samsung, wird vorgestellt und die dadurch mögli-
chen Interaktionsformen werden erklärt. Anschließend wird ein kurzer Abriss in
die Wahrnehmungspsychologie geben, um die Grundlagen der Arbeit zu definie-
ren (siehe Kapitel 3).
In Kapitel 4 wird anhand aktueller Literatur ein Gesamtkonzept für die kollaborati-
ve Geschäftsprozessmodellierung entworfen.
Um das Gesamtkonzept in ein Software-System zu überführen, beschäftigt sich
Kapitel 5 mit Detaillösungen und widmet sich speziell dem Interaction-Design.
Das feingranulare Konzept der Software wird anschließend (siehe Kapitel 6) gra-
phisch aufbereitet um ästhetischen, als auch hardwarebedingten Anforderungen
gerecht zu werden. Die technische Umsetzung wird in Kapitel 7 beschrieben. Um
das Konzept des lauffähigen Software-Systems zu validieren, wird in Kapitel 8 ein
Experiment definiert, durchgeführt und ausgewertet. Abschließend wird die Arbeit
zusammengefasst und ein Ausblick wird gegeben (siehe Kapitel 9).
3
2 RELATED WORK
[5] untersucht, ob Tabletop-Systeme für die Prozessmodellierung geeignet sind
und kommt zu dem Schluss, dass es besser ist als ein Desktop-PC zu verwenden,
wenn Domänen- und Modellierungs-Experten zusammenarbeiten. Der Aufbau
der Oberfläche schränkt jedoch die Kollaboration stark ein. So ist nur eine einzige
virtuelle Tastatur auf dem Tabletop-System vorhanden und durch die Verwen-
dung der Hardware (d.h. Micrsoft Surface 1) ist es nicht möglich eine bequeme
Sitzposition einzunehmen. Die Eingabe ist menübasiert und erinnert stark an Sys-
teme, welche mit Maus und Tastatur bedient werden. Das Menü ist auch nur von
einer Seite zugänglich. Diese Schwachstellen werden in der vorliegenden Arbeit
verbessert.
Das System Augemented Surfaces zeigt, wie Notebooks mit einem gemeinsamen
Display für kollaboratives Arbeiten verbunden werden können [6]. Das Display
kann zum einen auf den Tisch projiziert werden, zum anderen aber auch an die
Wand. Die Interaktion basiert auf Eingaben mit Maus und Tastatur. Der Fokus des
Systems wurde auf das einfache und intuitive Teilen von Dokumenten gelegt. So
kann mittels Drag&Drop ein Dokument geteilt oder zu eigen gemacht werden.
Dokumente können ausgedruckt werden, indem sie mittels Drag&Drop auf den
Drucker gezogen werden, der sich innerhalb des projizierten Displays befinden
muss. Der Einsatz des Systems ist Aufgrund des komplexen Aufbaus (Kameras
und Projektoren) nur in speziell hierfür ausgestatteten Räumen möglich.
[7] weist mittels Studien die Vorteile von kollaborativer Geschäftsprozessmodel-
lierung (Collaborative Business Process Modeling; CBPM) nach. So zeigen sie auf,
dass die Kommunikation erleichtert wird, Ideen besser ausgetauscht werden kön-
nen und Aufgaben einfacher zu lösen sind. Weiter konnten die Probanden von
ihren Teamkollegen lernen. Im Versuchsaufbau verwendeten sie Tablets welche
mit Touch-Eingaben bedient wurden.
[8] weist in einer vergleichenden Studie nach, dass bei CBPM sich Softwareunter-
stützung positiv auf die Qualität der Modelle auswirkt. Die Probanden arbeiten
bei dem Versuchsaufbau jeweils an einem Computer mit Maus und Tastatur.
2 RELATED WORK
4
Tabletop Concept Mapping beschreibt ein Werkzeug, mit diesem Benutzer indivi-
duelle Gedanken und Ideen auf einem Tabletop-System modellieren und teilen
können [9]. Die Verwendete Syntax der Modelle ist hierbei den Benutzern über-
lassen. Für die Modellierung werden physischen Objekten verwendet, welche die
Benutzer auf den Tabletop legen und mithilfe der angebotenen Funktionen ver-
binden können. Beschriftet werden können diese Objekte mit Post-Its oder digital
mittels einer externen Tastatur. Bei der digitalen Beschriftung wird der Name un-
terhalb des Elements auf dem Tabletop-System angezeigt.
[10] zeigt zwei verschiedene Ansätze um verteilte Prozessmodelle auf Tabletop-
Systemen miteinander zu verbinden. Dabei bedient er sich zum einen der Meta-
pher der Knopf-basierten Interaktion, zum anderen der Ablage-basierten. Bei der
Knopf-basierte Interaktion können Benutzer durch drehen eines physischen Inter-
aktionselements auf dem Tabletop-System Werte auswählen. Die Ablage-basierte
Interaktion überträgt gewohnte Menüs aus Graphical User Interfaces (GUI) auf
Tabletop-Systeme. Dabei können Benutzer ein Interaktionselement, welches auf
einem anderen Tabletop-System erstellt wurde, aus einer Liste auswählen und per
Drag&Drop auf das Tabletop-System übertragen. Die Interaktionselemente der
Liste müssen zuerst vom entfernten Tabletop-System angeboten werden und
dienen als Verbindungselement der beiden Prozessmodelle.
In [11] werden neue Ansätze der Prozessmodellierung erforscht. Basierend auf
der Tatsache, dass Domänen-Experten ihr Wissen meist nicht selbstbewusst in
Modellierungssitzungen ausdrücken können, verwenden sie papiergestützte Mo-
dellierungsverfahren. Dadurch soll es den Domänen-Experten, die sich mit Pro-
zessmodellierung wenig auskennen, erleichtert werden, ihr Wissen mitzuteilen.
Dieses Verfahren ist bei benutzerzentrierten Anwendungen und im Produktdesign
gängig.
[12] beschreibt die Interaktionstechnik Touch&Interact, um mit Smartphones
Touch-Aktionen an jeder Stelle eines präparierten Monitors durchzuführen. In
einem experimentellen Aufbau, in welcher diese Technik mittels eines Computer-
programms für Touristen validiert wurde, haben sie gezeigt, dass die Performanz
dieser Interaktionstechnik, mit der eines Touchscreen vergleichbar ist. Die Zufrie-
2 RELATED WORK
5
denheit der Probanden variiert, ist jedoch immer im positiven Bereich und das
Konzept stößt nicht auf Ablehnung seitens der Benutzer. In einer zweiten Studie,
in der Fotos zwischen einem Smartphone und einem Computer ausgetauscht
wurden, war die Zufriedenheit bei Touch&Interact sogar höher, als bei der Ver-
wendung eines normalen Touchscreens. Dies zeigt, dass abhängig des Systems
und der Software die Verwendung von Smartphones als Touch-Eingabegerät
nicht störend, sondern als fördernd angesehen werden kann.
[13] zeigt die Möglichkeit auf, kollaborativ auf Tabletop-Systemen Prozessmodel-
le zu erstellen. Benutzer können mehrere virtuelle Tastaturen verwenden, um
gleichzeitig Text einzugeben. Zusätzlich werden individuelle Ansichten angebo-
ten, um Kopien eines Bereichs des Interfaces zu erstellen. Um Konflikte zu lösen,
wenn mehrere Benutzer ein geteiltes Interaktionselement bearbeiten, wird ein
Änderungsverfahren angeboten. Weiter zeigt [13] auf, dass auch Benutzer mit
wenig Kompetenz in der Prozessmodellierung sich durch das verwendete System
gut in die gemeinschaftliche Gruppenarbeit einbringen können. Dabei sind sie mit
dem Modellierungsergebnis zufrieden und verstehen das Prozessmodell.
In [14] wird ein System für die kollaborative Prozessmodellierung auf Tabletop-
Systemen beschrieben. Die Hauptansicht des Systems ist dabei in vier Bereiche
für jeweils einen Benutzer untergliedert. Die Erstellung von Prozessmodellen ba-
siert auf Menüs und es ist nur eine virtuelle Tastatur vorhanden. Dabei werden
Texteingaben durch einen modalen Dialog dargestellt, welcher die gleichzeitige
Interaktion mehrerer Benutzer unterbindet.
2 RELATED WORK
6
7
3 GRUNDLAGEN
Dieses Kapitel erläutert die Grundlagen für die Konzeption eines kollaborativen
Prozessmodellierungssystems. Dabei gibt Kapitel 3.1 einen Überblick über BPMN,
um den Kontext und das Domänenwissen dieser Arbeit zu erläutern. In Kapitel 0
zeigt auf, wie mit Tablets und Smartphones Touch-Aktionen durchgeführt werden
können. Kapitel 3.4 beschreibt Ansätze aus dem Bereich der Human-Computer-
Interaction (HCI), um mit skizzenbasierter Eingabe die Prozessmodellierung zu
unterstützen. Grundlegende Gestaltgesetze werden in Kapitel 3.5 aufgezeigt.
Die Business Process Model and Notation (BPMN) ist eine graphische Spezifikati-
onssprache, um Prozessmodelle zu modellieren. Ein Prozessmodell ist dabei ein
gerichteter Graph, welcher aus Kanten und Knoten besteht. Die unterschiedliche
Darstellung und Semantik der Kanten und Knoten wird von der BPMN definiert.
Die BPMN Version 2.0 ist von der Object Management Group entwickelt worden
und findet in dieser Arbeit ihren Einsatz.
Die BPMN 2.0 gliedert sich in drei Modellarten, dem Choreography Diagram, dem
Conversation Diagram und dem Collaboration Diagram [15].
Prozesselemente der BPMN lassen sich, wie in Abbildung 3-1 gezeigt, in die fünf
Hauptkategorien Flussobjekte, Daten, Verbindende Objekte, Verantwortlichkeitsbe-
reich und Artefakte unterteilen.
Abbildung 3-1: BPMN-Kategorien
3 GRUNDLAGEN
8
Nachfolgend werden jene Prozesselemente vorgestellt, welche für diese Arbeit
relevant sind [15].
Ereignis
Ein Ereignis (engl.: Event) ist etwas, das
während dem Ablauf eines Prozesses pas-
siert (siehe Abbildung 3-2). Solch ein Er-
eignis beeinträchtigt den Ablauf des Pro-
zessmodels. Es gibt drei verschiedenen
Arten von Ereignissen, je nachdem an
welcher Stelle sich diese im Prozessmo-
dell befinden. Ein Start-Ereignis hat keine
eingehenden Kanten und steht den Start-
punkt des Prozesses dar. Ein Zwischen-
Ereignis hat eingehende wie auch ausge-
hende Kanten, wobei ein Ende-Ereignis
nur eingehende Kanten besitzt.
Start-
Ereignis
Zwischen-
Ereignis
Ende-
Ereignis
Abbildung 3-2: Ereignisse in BPMN
Sequenzfluss
Ein Sequenzfluss (engl.: Sequence Flow)
wird verwendet, um die Reihenfolge der
Prozessausführung aufzuzeigen (siehe
Abbildung 3-3).
Abbildung 3-3: Sequenzfluss in BPMN
Nachrichtenfluss
Ein Nachrichtenfluss (engl.: Message Flow)
wird verwendet um den Fluss von Nach-
richten zwischen zwei Teilnehmern zu
visualisieren (siehe Abbildung 3-4). Ver-
schiedene Pools repräsentieren dabei ver-
schiedene Teilnehmer.
Abbildung 3-4: Nachrichtenfluss in BPMN
3.1 BUSINESS PROCESS MODEL AND NOTATION
9
Assoziation
Eine Assoziation (engl.: Association) ver-
bindet Artefakte (z.B. Datenobjekte, tex-
tuelle Anmerkungen) mit Prozesselemen-
ten (siehe Abbildung 3-5). Die Pfeilspitze
gibt die Richtung der Assoziation an.
Abbildung 3-5: Assoziation in BPMN
Aktivität
Eine Aktivität (engl.: Activity) ist ein gene-
rischer Ausdruck für Arbeit, welche das
Unternehmen in dem Prozess verrichtet.
Eine Aktivität kann dabei atomar oder
nicht-atomar sein. Ein Subprozess stellt
selbst wieder ein Prozessmodell dar und
dient somit als atomare Aktivität. Ein
Tasks stellt eine einzelne Aufgabe inner-
halb eines komplexen Prozesses dar (sie-
he Abbildung 3-6).
Subprozess-
Aktivität
Task
Abbildung 3-6: Aktivitäten in BPMN
Portal
Ein Portal (engl.: Gateway) wird verwen-
det, um den Sequenzfluss in Prozessmo-
dellen zu steuern. Ein Gateway kann so-
wohl einen Sequenzfluss aufspalten oder
zusammenführen. AND-Gateways symbo-
lisieren eine parallele Aufspaltung, bzw.
eine Zusammenführung paralleler Se-
quenzflüsse. XOR-Gateways repräsentie-
ren eine exklusive Aufspaltung, bzw. Zu-
sammenführung verschiedener Sequenz-
flüsse (siehe Abbildung 3-7).
AND-Gateway
XOR-Gateway
Abbildung 3-7: Portale in BPMN
3 GRUNDLAGEN
10
Datenobjekt
Ein Datenobjekt (engl.: Data Object) stellt
Informationen für andere Prozesselemen-
te bereit oder nimmt Informationen von
diesen entgegen (siehe Abbildung 3-8).
Datenobjekte können sowohl eine einzel-
ne Variable, als auch eine Vielzahl von
Variablen repräsentieren.
Abbildung 3-8: Datenobjekt in BPMN
Pool
Ein Pool ist eine graphische Repräsentati-
on eines Teilnehmers innerhalb des Pro-
zessmodells und dient als Container für
andere Prozesselemente (z.B. Aktivitäten
und Gateways) (siehe Abbildung 3-9).
Abbildung 3-9: Pool in BPMN
Bahn
Eine Bahn (engl.: Lane) ist ein Teilab-
schnitt eines Prozessmodells oder Pools.
Sie erweitert einen Prozessmodell und
werden verwendet, um Aktivitäten zu or-
ganisieren und kategorisieren (siehe Ab-
bildung 3-10).
Abbildung 3-10: Lane in BPMN
Textuelle Anmerkung
Textuelle Anmerkungen (engl.: Text-
Annotation) bieten Modellierern die Mög-
lichkeit, Erklärungen und Informationen
einzugeben und werden über Assoziatio-
nen mit einem Prozesselement verbunden
(siehe Abbildung 3-11).
Abbildung 3-11: Anmerkung in BPMN
3.2 HARDWARE
11
Ein Beispiel eines Prozessmodells ist in Abbildung 3-12 zu sehen. Das Start-
Ereignis gibt den Startpunkt des Prozessmodells an. Anschließend wird durch das
AND-Gateway der Sequenzfluss aufgespalten. Folglich werden die beiden Aktivi-
täten Task A und Task B gleichzeitig ausgeführt und durch das nächste AND-
Gateway wieder zusammengeführt. Der Sequenzfluss wird erst fortgesetzt, wenn
beide Aktivitäten abgearbeitet sind. Der nächste Block, welcher aus dem zusam-
menführenden XOR-Gateway, Task C und dem verzweigenden XOR-Gateway be-
steht, stellt eine Schleife dar. Im ersten Durchgang hat das zusammenführende
XOR-Gateway keine Funktion und Task C wird ausgeführt. Das verzweigende
XOR-Gateway prüft die Bedingungen, welche neben den Sequenzflüssen angege-
ben werden und entscheidet, abhängig des Wertes von i, über die weitere Aus-
führung. Solange die Bedingung i<3 zutrifft, wird Task C ausgeführt. Sonst wird
der Sequenzfluss fortgeführt und das Ende-Ereignis zeigt das Ende des Prozesses
an.
Abbildung 3-12: Prozessmodell
3.2.1 NEAR FIELD COMMUNICATION
Near Field Communication (NFC) wird verwendet um zwischen zwei Geräten eine
drahtlose Verbindung aufzubauen und Informationen zu übermitteln. Basierend
auf der RFID-Technologie bietet NFC eine Kommunikation, welche räumlich auf
nur wenige Zentimeter beschränkt ist. Die Kommunikation kann zwischen einem
passiven NFC-Gerät (NFC-Tag) und einem aktiven NFC-Gerät lesend wie auch
schreibend, nur lesend, sowie zwischen zwei aktiven NFC-Geräten bidirektional
statt-finden [16].
3 GRUNDLAGEN
12
Ein NFC-Tag bezeichnet ein passives, elektronisches Gerät, welches selbst an kei-
ne Stromquelle angeschlossen ist. Kommt ein aktives NFC-Gerät, welches an eine
Stromquelle angeschlossen ist, in die Nähe des Tags, so wird dieser drahtlos via
Induktion mit Strom versorgt. Dadurch können Informationen vom NFC-Tag aus-
gelesen werden, um z.B. Webseiten zu öffnen, andere Verbindungen (z.B. WLan
oder Bluetooth) zu initiieren oder spezifische Daten auszulesen. Alternativ können
auch Informationen auf den NFC-Tag geschrieben werden, sofern dieser den
schreibenden Zugriff unterstützt.
Die limitierte Reichweite stellt hingegen der augenscheinlichen Schwäche die
größte Stärke dieser Technologie dar. So kann das Vorhandensein einer Verbin-
dung als Zustimmung einer Aktion angesehen werden. Anders ausgedrückt: So-
bald ein anderes NFC-Gerät in Reichweite ist, kann davon ausgegangen werden,
dass dies vom Benutzer beabsichtigt ist. Die Information kann ohne weitere Zu-
stimmung des Benutzers ausgelesen werden und Aktionen können gestartet wer-
den [16].
3.2.2 MICROSOFT PIXEL SENSE
Der Sur40 von Samsung, welcher Microsofts Pixel Sense Technologie unterstützt,
ist ein 40 Zoll großer, berührungsempfindlicher LCD-Bildschirm (Touchscreen),
welcher horizontal aufgestellt und als Tabletop-System verwendet, oder vertikal
an die Wand gehängt werden kann [17]. Die Detektion der Benutzereingaben
erfolgt bei dem, 2007 von Samsung vorgestellten Tisch, optisch. Bei konventio-
nellen Touchscreens werden Eingaben über Ladungsunterschiede erkannt. Der
Pixel Sense hingegen filmt von unten alles was über dem Display geschieht und
erkennt verschiedene physische Objekte. Der Vorteil der optischen Detektion be-
steht darin, dass sich ein Finger, ein Objekt oder ein getaggtes Objekt unterschei-
den lassen. Wird ein Objekt auf das Tabletop-System gelegt, erscheinen, je nach
Software, Interaktionselemente, um mit diesem zu interagieren. Durch die Auflö-
sung des Displays von 1920×1080 wird von ca. zwei Millionen Bildpunkten aus-
gegangen. Da jeder achte Pixel als Kamera fungiert, werden folglich ca. 26.000
Touchpunkte erkannt [17].
3.3 TOUCH-EINGABE MIT MOBILEN GERÄTEN
13
Dieser Abschnitt zeigt Interaktionskonzepte auf, wie Benutzer ihre eigenen mobi-
len Geräte (z.B. Smartphone oder Tablet) verwenden können, um mit einem Soft-
ware-System zu interagieren.
Der Benutzer verwendet dabei mobile Geräte, um mit diesen eine Oberfläche zu
Berühren und dadurch Aktionen auszulösen. Wird eine Berührung nicht nur von
der Oberfläche, sondern zusätzlich von dem mobilen Gerät erkannt, lässt sich
daraus schließen, welcher Benutzer eine bestimmte Aktion ausführt. Dazu wird auf
beiden Geräten der exakte Zeitpunkt der erkannten Touch-Aktion gespeichert
und über ein drahtloses Netzwerk miteinander geteilt. Anschließend werden die
Zeitpunkte miteinander verglichen. Korreliert der Zeitpunkt der Touch-Aktionen
beider Geräte wird ein TabletTouch erkannt.
Die folgenden Abschnitte zeigen auf, wie eine Berührung auf den mobilen Gerä-
ten und auf unterschiedlichen Oberflächen erkannt werden kann.
3.3.1 ERKENNUNG EINER TOUCH-AKTION AUF MOBILEN GERÄTEN
Als universelles Verfahren können die Beschleunigungssensoren der Geräte aus-
gelesen werden, welche bei einer Berührung kurz und stark ausschlagen [18]. Bei
normalem Gebrauch der mobilen Geräte in der Hand, sind die Beschleunigungs-
werte deutlich geringer und lassen sich somit eindeutig von einer Berührung un-
terscheiden. Durch diese Eigenschaft lässt sich auf einfache Art eine Berührungs-
detektion umsetzen.
Als weiteres Verfahren kann zusätzlich zu den Beschleunigungswerten das Mikro-
fon des mobilen Geräts, mit dem Interagiert werden soll, verwendet werden [18].
Da jede Berührung an einem Gegenstand mit einem spezifischen Geräusch ein-
hergeht, kann dieses vom Mikrofon erfasst werden. Die Methode lässt sich jedoch
nicht in Räumen mit hohen Umgebungsgeräuschen verwenden. Aber es kann
zusätzlich zu den Beschleunigungswerten als Indiz angesehen werden.
Der Nachteil der indirekten Bestimmung einer Berührung ist, dass beide Verfah-
ren nur mit harten Oberflächen, wie z.B. einer Tischplatte funktionieren. So kann
mit den beiden Verfahren nicht erkannt werden, ob ein Smartphone oder Tablet
3 GRUNDLAGEN
14
z.B. ein weiches Kissen berührt, da es weder eine starke und kurze Abbremsung,
noch ein spezifisches Geräusch gibt.
An welcher Stelle die Berührung stattgefunden hat, kann mittels der Beschleuni-
gungssensoren oder dem Mikrofon nicht erkannt werden. Hierfür lässt sich das
System auf verschiedene Arten erweitern, welche nachstehend erklärt werden.
3.3.2 PRÄPARIERTE OBERFLÄCHEN
Gedruckte Poster, Monitore oder Projektionsflächen können mit einer NFC-Tag-
Matrix versehen werden, um zusätzliche Funktionalität anzubieten [19]. Diese
können unter anderem dazu verwendet werden, die Position der mobilen Geräte
zu bestimmen. Die Berührung der Oberfläche wird wiederrum durch die mobilen
Geräte erkannt. Jeder NFC-Tag speichert seine Koordinaten, die dann bei einer
Berührung (vgl Kapitel 3.3.1) ausgelesen werden. Mittels einer zuvor initiierten
Verbindung (z.B. Bluetooth oder WLAN) können die Koordinaten an den Compu-
ter übertragen werden, wie in Abbildung 3-13 zu sehen ist. Zusätzlich kann jedes
Smartphone oder Tablet anhand der MAC-Adresse identifiziert und folglich un-
terschiedliche Benutzer erkannt und unterschieden werden.
Abbildung 3-13: Prinzip von Touch&Interact [12]
Durch die Verwendung einer NFC-Tag-Matrix ist die Auflösung stark begrenzt
und eine feine Granularität der Touchpunkte ist nicht möglich, da ein normaler
NFC-Tag ca. 3,5cm x 2cm groß ist.
Das Beispiel in Abbildung 3-13 zeigt eine NFC-Tag-Matrix mit 25 NFC-Tags. So-
mit sind nur 25 Touchpunkte unterscheidbar. Die Möglichkeit durch unterschied-
liche Signalstärken der einzelnen Tags eine Interpolation (d.h. Triangulation) und
3.4 SKIZZENBASIERTE EINGABE
15
somit eine genauere Positionsbestimmung durchzuführen, wurde noch nicht un-
tersucht.
3.3.3 TABLETOP-SYSTEM
Werden auf dem Tabletop-System Benutzereingaben optisch detektiert, kann das
vom Tabletop-System aufgenommene Bild dazu verwendet werden, Berührungen
mit mobilen Geräten zu erkennen. Dabei unterscheidet sich die Größe der Fläche
der Touch-Eingabe von Fingern und mobilen Geräten. Bei mobilen Geräten ist die
erkannte Fläche kleiner als bei Eingaben mit dem Finger. Der Aufbau ist in Abbil-
dung 3-14 skizziert.
Abbildung 3-14: Aufbau von PhoneTouch [18]
Die Idee skizzenbasierter Eingabe ist, dass Prozessmodelle per Hand gezeichnet
werden und anschließend vom Computer analysiert und korrekt interpretiert wer-
den, um sie anschließend automatisch in das System zu überführen. Da das Sys-
3 GRUNDLAGEN
16
tem die gemalten Formen, Linien und Pfeile korrekt interpretieren muss, ist der
Benutzer dazu gezwungen, genormte Zeichen und Symbole zu verwenden. Die
Erstellung von Prozessmodellen mittels Skizzen kann mit einem Stift auf Papier
oder mit dem Finger auf einem Touchscreen erfolgen.
Die erste Möglichkeit, Prozessmodelle zu skizzieren, besteht darin, die Prozess-
modelle mittels Stift auf Papier zu skizzieren und anschließend die Skizze einzu-
scannen oder zu fotografieren (siehe Abbildung 3-15). Das Bild wird vom System
analysiert und anschließend das Prozessmodell anhand der Skizze erstellt [20].
Die Erkennung von Handschrift ist prinzipiell möglich, ist aber meist fehleranfällig.
Eine Lösung ist, dass bei nicht erkannten Wörtern das Bild der Handschrift ange-
zeigt wird und der Benutzer nachträglich den Text eingeben kann. Das erkannte,
im System vorhandene Prozessmodell kann anschließend auf Validität und Voll-
ständigkeit überprüft werden, als Teilstück in ein größeres Prozessmodell einge-
fügt, oder zur späteren Weiterverarbeitung gespeichert werden.
Abbildung 3-15: Automatische Extraktion von Modellen aus einem Bild
Die zweite Möglichkeit der Skizzenbasierten Erstellung von Prozessmodellen be-
steht darin, dass die Eingabe mittels des Fingers, auf einem Tablet-PC oder
Smartphone erfolgt. Diese Interaktion ist auch als elektronisches Whiteboard be-
kannt [21]. Skizzierte Prozesselemente werden unmittelbar vom System analysiert
und das Ergebnis wird angezeigt (siehe Abbildung 3-16). Wird eine Eingabe nicht
erkannt, kann sofort eine Rückmeldung gegeben werden und entsprechende
Schritte, seitens des Benutzers, können eingeleitet werden. So kann z.B. aus einer
Vorschlagsliste ausgewählt werden, welches Objekt der Benutzer skizziert hat,
oder der Benutzer wiederholt seine Eingabe [22, 21].
3.5 GESTALTGESETZE
17
Abbildung 3-16: Skizzenbasierte Eingabe
Dieser Abschnitt beschäftigt sich mit den Grundlagen der menschlichen Wahr-
nehmung in Bezug auf die Gestaltung einer Benutzerschnittstelle. Es wird gezeigt,
wie sich Elemente anordnen und darstellen lassen, um diese zu Gruppieren und
dem Benutzer eine schnelle Touch-Interaktion mit dem System zu ermöglichen.
Zusätzlich wird auf die Orientierung von Interaktionselementen eingegangen.
Durch die relative Anordnung von Elementen zueinander, lassen sich diese op-
tisch zu Gruppen zusammenfassen. In Abbildung 3-17 wird das Gesetz der Nähe
verwendet. Dieses besagt, dass auf dem Bild drei Spalten mit jeweils fünf Quadra-
ten erkannt werden und nicht fünf Zeilen mit drei Quadraten. Allgemein ausge-
drückt wird Zusammengehörigkeit durch Nähe betont und Unterschiede durch
Distanz getrennt [23].
Abbildung 3-17: Gesetz der Nähe
Auf dem Gesetz der Nähe aufbauend besagt das Gesetz der Ähnlichkeit, dass Ele-
mente mit gleichem Abstand zueinander, durch Farbe und Form in Gruppen ein-
geteilt werden können (siehe Abbildung 3-18). So sind in Abbildung 3-18-a die
Zeilen, und in Abbildung 3-18-b die Spalten gruppiert. Neben Form und Farbe,
3 GRUNDLAGEN
18
kann auch die Helligkeit, Größe oder Orientierung für die Gruppenbildung ver-
wendet werden [23].
a)
b)
Abbildung 3-18: Gesetz der Ähnlichkeit
Das Gesetz der Schließung besagt, dass in unserer Wahrnehmung Konturen mög-
lichst vervollständigt werden. Abbildung 3-19 zeigt ein Rechteck, welches von
einem Kreis teils verdeckt wird. Die Hellgraue Figur wird von unserer Wahrneh-
mung zu einem Rechteck vervollständigt, auch wenn der genaue Verlauf der Kon-
tur unbekannt ist. Der abgeschnittene Kreis wird auch als Kreis wahrgenommen.
Abbildung 3-19: Gesetz der Schließung
Zusammenfassend lässt sich sagen, dass bei einer Kombination der unterschiedli-
chen Gestaltgesetze keine genaue Aussage darüber getroffen werden kann, wel-
ches Gesetz stärker oder schwächer auf unsere Wahrnehmung wirkt. Es gilt je-
doch das Gesetz der guten Gestaltung. Damit wird generell beschrieben, dass die
Wahrnehmung nach möglichst einfachen, regelmäßigen, symmetrischen und ge-
schlossen Figuren sucht [23].
Elemente können auch so angeordnet werden, dass Benutzer schneller mit dem
System interagieren können. Die Art der Anordnung wird durch Fitts Gesetz be-
schrieben. Die Zeit, welche ein Benutzer braucht um ein Objekt mit dem Finger zu
treffen wird dabei als Funktion der Distanz und Größe des Zielobjekts [24] darge-
3.5 GESTALTGESETZE
19
stellt. Je näher das Zielobjekt an der aktuellen Position des Fingers ist, bzw. je
größer das Zielobjekt ist, desto schneller kann der Benutzer dieses erreichen.
Die Orientierung von Elementen nimmt bei Tabletop-Systemen eine Schlüsselrol-
le ein [25, 26, 27, 28] und soll daher besonders herausgestellt werden. So sollen
Tabletop-Systeme bei textlastigen Aufgaben nicht verwenden werden [25]. Da
Prozessmodelle hauptsächlich aus beschrifteten Elementen und deren Verbin-
dungen bestehen, scheint es adäquat, Tabletop-Systeme für die Prozessmodellie-
rung zu verwenden. Der Aspekt der Orientierung soll jedoch nicht vernachlässigt
werden.
Eine rein manuelle Ausrichtung der Interaktionselemente, d.h. Benutzer rotieren
ohne Unterstützung des Tabletop-System Elemente in die gewünschte Richtung,
hat den Vorteil, volle Flexibilität in der Interaktion zu bieten. Jedoch sinkt die Le-
segeschwindigkeit der Beschriftungen der Interaktionselemente bei schlechter
Ausrichtung.
Eng gekoppelte Aufgaben, bei denen eine starke Zusammenarbeit notwendig ist,
werden mit rein manueller Ausrichtung von Interaktionselementen schneller erle-
digt als mit automatischer Ausrichtung [29]. Der Grund besteht darin, dass Benut-
zer die Orientierung nicht nur verwenden um selbst besser lesen zu können, son-
dern auch um Elemente zu teilen und um Informationen zu kommunizieren. Für
lose gekoppelte Aufgaben ist kein signifikanter Unterschied zwischen automati-
scher oder manueller Ausrichtung vorhanden. Folglich wird für dieses System kei-
ne automatische Ausrichtung verwendet.
Untersuchungen mit halbautomatischer Ausrichtung [28, 27] anhand des Personal
Space der jeweiligen Benutzer wurden nur an dokumentenorientierten Systemen
untersucht und lassen sich folglich nicht auf diese Arbeit übertragen. Das Display
soll nicht in Segmente aufgeteilt werden, um beliebig viele Benutzer zu unterstüt-
zen [30]. Somit wird auf eine halbautomatische Ausrichtung verzichtet.
Um Elemente in eine bestimmte Richtung zu orientieren, kann ein Magnet ver-
wendet werden [31]. Dabei werden alle Elemente, welche sich innerhalb des Wir-
kungsbereichs des Magneten befinden, in die Richtung des Magneten ausgerich-
3 GRUNDLAGEN
20
tet. Ein solcher Magnet kann zum einen ein spezielles physikalisches Objekt sein,
welches auf dem Tabletop-System platziert wird, oder ein virtuelles Element, wel-
ches auf dem Display angezeigt wird.
21
4 KONZEPT PROCESS-TOUCH
Dieses Kapitel zeigt auf, wie ein multi-modales Multi-User-System konzipiert wer-
den kann, welches sich auf aktuelle Erkenntnisse der HCI und BPM stützt, um den
Benutzern ein System für kollaborative Zusammenarbeit zu bieten, welches leicht
zu bedienen ist. Der Name Process-Touch beschreibt dabei den Grundsatz, dass
das zu erstellende Prozessmodellierungssystem nur mit Touch-Aktionen bedient
wird.
Ausgangspunkt der Arbeit bildet die Forderung nach einem multi-modalen Multi-
User-System. Benutzerzentriertes Design ist die Grundlage einer guten HCI [32].
Deshalb wird in dieser Arbeit und vor allem für das Interaction-Design, großer
Wert auf einen benutzerzentrierten Ansatz gelegt. Interaction-Design definiert
das Wechselspiel zwischen Software und Benutzerverhalten, Rückmeldungen und
Touch-Interaktionen [30].
Kapitel 4.1 identifiziert allgemeine Forderungen aus der Literatur, welche definie-
ren, wie ein solches System aufgebaut sein soll. Darauf aufbauend wird ein kon-
kretes Systemkonzept entworfen (Kapitel 4.2).
Da sich BPMN sich quasi als Standard für die Modellierung von Prozessmodellen
durchgesetzt hat [11], wird in dieser Arbeit BPMN als Modellierungssprache ver-
wendet (siehe Anforderung 1).
Anforderung 1 (BPMN als Modellierungssprache):
Als Modellierungssprache soll BPMN verwendet werden.
BPMN definiert neben der Semantik der einzelnen Prozesselemente auch die Syn-
tax der Prozessmodelle. Um vor allem Benutzer zu unterstützen, welche mit der
Syntax nicht vertraut sind, können Syntaxprüfungen von dem System angeboten
werden. Versucht ein Benutzer z.B. zwei Prozesselemente miteinander zu verbin-
den, überprüft das System ob eine Verbindung dieser Elemente syntaktisch Kor-
4 KONZEPT PROCESS-TOUCH
22
rekt ist und zeigt dies dem Benutzer an. Dadurch wird die syntaktische Qualität
der Prozessmodelle verbessert.
Anforderung 2 (Syntaxprüfung von Prozessmodellen):
Um die syntaktische Qualität der Prozessmodelle zu steigern, werden Benut-
zer bei der Prozessmodellierung durch Syntaxprüfungen unterstützt. Prozes-
selemente können nur verbunden werden, wenn dabei die korrekte Syntax
eingehalten wird.
In dieser Arbeit wird ein Konzept für ein einfach zu bedienendes System erstellt,
welches eine „natürliche“ Bedienung erlaubt und durch ein Natural User Interface
(NUI) angeboten werden soll. Da der Begriff NUI überladen und verwirrend ist
[33], wird in dieser Arbeit darunter ein Interface verstanden, welches sich an Me-
taphern der realen Welt bedient. Dies impliziert sowohl die Touch-Interaktion, als
auch, dass jedes Interaktionselement anfassbar, verschiebbar und rotierbar ist
(siehe Anforderung 3).
Anforderung 3 (Natural User Interface):
Die Interaktion muss sich Vorbildern aus der Realität bedienen.
Zentraler Bestandteil des Systems ist ein großes, interaktives Display, welches
Touch-Interaktionen erlaubt. Der große Interaktionsraum unterstützt hierbei kol-
laboratives Arbeiten, da mehrere Benutzer gleichzeitig mit dem Display interagie-
ren können [30]. Ein vertikal installiertes Display, welches kollaborativ verwendet
wird, wird oft als unangenehm empfunden [34]. Wird das Display horizontal auf-
gebaut und als Tabletop-System verwendet, unterstützt dies die Benutzer, mehr
Ideen zu erforschen. Zusätzlich können sie besser nachvollziehen was andere Be-
nutzer machen [34]. Daraus ergibt sich Anforderung 4.
4.1 ANFORDERUNGEN AN DAS KONZEPT
23
Anforderung 4 (Tabletop-System):
Das interaktive Display, welches für kollaborative Arbeiten verwendet wird,
wird horizontal installiert und als Tabletop-System verwendet.
Während der Interaktion mit Tabletop-Systemen, können Objekte auf diesem
abgelegt werden. Diese können aufgabenbezogen oder nicht aufgabenbezogen
sein. Aufgabenbezogenen Objekte können mobile Geräte oder auch spezielle Ob-
jekte sein, um mit dem Tabletop-System zu interagieren und Aktionen auszulösen
[9, 30]. Nicht aufgabenbezogene Objekte müssen von aufgabenbezogenen Objek-
ten unterschieden werden, damit Benutzer das Tabletop-System auch als Tisch
verwenden können, um z.B. eine Tasse abzustellen (siehe Anforderung 5).
Anforderung 5 (Verwendung von physikalischen Objekten):
Aufgabenbezogene Objekte müssen von nicht aufgabenbezogene Objekten
unterschieden werden.
Die meisten Aufgaben, welche auf kollaborativ genutzten Tabletop-Systemen
bearbeitet werden, sind nur ein Teil der gesamten gemeinschaftlichen Arbeit. Das
Tabletop-System muss daher den Benutzern einen Übergang hin zu individueller
Arbeit bieten, welche abseits des Tabletop-Systems stattfinden [25]. Dieser Über-
gang soll den Benutzern so einfach wie möglich gemacht werden (siehe Anforde-
rung 6).
Anforderung 6 (Übergang von kollaborativer, zu individueller Arbeit):
Ein produktiv genutztes System besteht nicht nur aus kollaborativer Arbeit
am Tabletop-System. Ein einfacher Übergang vom Tabletop-System zur indi-
viduellen Arbeit muss angeboten werden.
Tabletop-Systeme sollen Möglichkeiten für direkte Manipulationen von visuellem
Inhalt anbieten (siehe Anforderung 7) [31, 30]. Somit soll auf Hard- und Software-
Buttons verzichtet wird, um z.B. ein Interaktionselement zu drehen oder zu ver-
größern.
4 KONZEPT PROCESS-TOUCH
24
Anforderung 7 (Direktes Interface):
Der Inhalt ist das Interface. Buttons, Menüs oder Slider, um z.B. Objekte zu
rotieren, skalieren oder zu verschieben, sollen nicht angeboten werden.
Tabletop-Systeme müssen und können neue Eingabemöglichkeiten anbieten, um
die Nichtverwendung von Maus und Tastatur zu kompensieren (siehe Anforde-
rung 8) [31].
Anforderung 8 (Neuartige Eingabemöglichkeiten):
Neue Eingabemöglichkeiten, welche die Nichtverwendung von Maus und
Tastatur kompensieren, müssen angeboten werden.
Ein einheitliches Eingabegerät für sämtliche Benutzer-Aktionen auf dem Table-
top-System hilft, die Interaktion zu vereinfachen, da keine Geräte gewechselt
werden müssen [25]. Auf der anderen Seite, kann ein spezialisiertes Eingabegerät
die Bewältigung einer bestimmten Aufgabe stark vereinfachen (z.B. Tastatur statt
On-Screen-Tastatur). Um Anforderung 6 nachzukommen und den Übergang von
kollaborativer, zu individueller Arbeit einfach und intuitiv zu gestalten, werden
Tablets als private Displays verwendet (siehe Anforderung 8) und der Datentrans-
fer mittels Tablet-Touch-Aktionen (siehe Kapitel 3.3.3) angeboten. Dies wird in
Anforderung 9 zusammengefasst.
Anforderung 9 (Tablets als private Displays):
Neben dem Tabletop-System für kollaborative Arbeit sollen Tablets für indi-
viduelle Arbeit angeboten werden.
Die fundamentalste Art der Zusammenarbeit ist, dass Benutzer Daten und Objekte
miteinander teilen. Auch wird das Teilen als Start einer Kommunikation zwischen
Benutzern verwendet [29]. Bei Systemen, welche zusätzlich zu dem Tabletop-
System ein separates Gerät mit privatem Display anbieten, kann die Kommunika-
tion zwischen den Benutzern erschwert werden. Dies begründet sich darin, dass
4.1 ANFORDERUNGEN AN DAS KONZEPT
25
die Blickrichtung und Zeigegesten der Benutzer von anderen Benutzern nicht
interpretiert werden können, wenn sich dieser auf das private Display bezieht [6,
35]. Somit muss das Teilen von Daten auch zwischen den privaten Geräten und
dem zentralen Tabletop-System unterstützt werden (siehe Anforderung 10).
Anforderung 10 (Unterstützung der Kommunikation):
Um die Kommunikation der Benutzer zu unterstützen, müssen Daten und
Objekte zwischen allen Geräten ausgetauscht werden können.
Eine der natürlichsten Arten der Kommunikation zwischen Benutzern ist, auf Ob-
jekte zu zeigen oder auf diese zu schauen. Die Blickrichtung eines Benutzers wird
von anderen intuitiv wahrgenommen. Diese Geste kann jedoch nur verwendet
werden, wenn Objekte als Unikat dargestellt werden. Hat jeder Benutzer seine
eigene Kopie des gleichen Objekts, fällt ein wichtiger Bestandteil der Kommunika-
tion weg [36] (siehe Anforderung 11).
Anforderung 11 (Keine Duplikate):
Um die Kommunikation der Benutzer zu vereinfachen, sollen keine Duplikate
erzeugt werden. Dadurch beziehen sich Benutzer immer auf dasselbe Objekt.
Der Übergang der Benutzung von einem persönlichen Gerät zum Tabletop-
System muss dem Benutzer möglichst einfach gemacht werden. Dies kann unter-
stützt werden, indem Geräten ein ähnliches Nutzungsmodell haben [35]. Das be-
deutet auch, dass ein einheitliches Look & Feel gegeben sein muss, um den men-
talen Kontextwechsel der Benutzer gering zu halten. Dabei können, je nach Platt-
form auf welcher die einzelnen Programme ausgeführt werden, die Design- und
Interaction-Design -Guidelines der einzelnen Plattformen in Konflikt zueinander
stehen. Anforderung 12 beschreibt das einheitliche Konzept des Gesamtsystems.
4 KONZEPT PROCESS-TOUCH
26
Anforderung 12 (Übergänge von persönlicher zur Gruppenarbeit):
Der mentale Kontextwechsel der Benutzer muss gering gehalten werden. Un-
terschiedliche Geräte müssen ein einheitliches Erscheinungsbild und Bedien-
konzept anbieten.
Die Art der Aufgabe hat Einfluss auf die bevorzugte Anordnung der Benutzer an
dem Tabletop-System. Z.B. stehen bei eng gekoppelten Aufgaben Benutzer näher
zusammen [30]. Bei Aufgaben mit hoher Kommunikation stehen sie sich lieber
gegenüber. Folglich müssen unterschiedliche Anordnungen der Benutzer unter-
stützt werden.
Anforderung 13 (Anordnung von Benutzern):
Abhängig der Aufgabe, der Anzahl an Benutzern und der individuellen Eigen-
schaften der Benutzer, variiert die Anordnung der Benutzer an einem Table-
top-System. Das System muss flexibel darauf reagieren und darf eine freie
Anordnung der Benutzer nicht einschränken.
Desktop-Systeme unterstützen keine Multi-User-Eingaben. Hingegen interagieren
Benutzer von Tabletop-Systemen oft gleichzeitig mit dem System. So müssen
simultane Benutzeraktionen von der Hard- und Software unterstützt werden (sie-
he Anforderung 14) [30].
Anforderung 14 (Simultane Benutzeraktionen):
Das System muss ständig die Möglichkeit bieten, dass mehrere Benutzer
gleichzeitig an dem System arbeiten können.
Die zeitgleiche Benutzung des Systems auf einem Gerät bringt, im Vergleich zu
einem Single-User-System,neue Probleme mit sich. So ist es nicht möglich, eine
Rückgängig-Funktion anzubieten. Den Grund hierfür zeigt folgendes Beispiel auf:
4.1 ANFORDERUNGEN AN DAS KONZEPT
27
Zwei Benutzer arbeiten kollaborativ an einem System. Benutzer A führt
eine destruktive Aktion (z.B. Lösch-Aktion) aus. Er überlegt kurz, bis er
zu dem Schluss kommt, die Aktion rückgängig machen zu wollen. In
der Zwischenzeit hat Benutzer B einige konstruktive Aktionen getätigt
(z.B. neues Element erstellen). Würde Benutzer A die Rückgängig-
Funktion verwenden, würde er die Arbeit von Benutzer B zurücksetzen.
Da einzelne Aktionen nicht einem bestimmten Benutzer zugeordnet werden kön-
nen, darf keine Rückgängig-Funktion angeboten werden. Ein weiteres Problem
ergibt sich bei der Verwendung eines Multi-User-Systems, wenn die oben ge-
nannten Benutzer zusammenarbeiten und Benutzer A eine Zoom-Aktion ausführt,
um z.B. seinen Arbeitsbereich zu vergrößern. Wenn Benutzer B an einer anderen
Stelle arbeitet, kann es vorkommen, dass sein Bereich durch die Vergrößerung
nicht mehr sichtbar ist.
Somit kann zusammengefasst werden, dass globale Aktionen nicht unterstützt
werden können (siehe Anforderung 15) [30].
Anforderung 15 (Keine globalen Aktionen):
Aktionen eines Benutzers dürfen andere Benutzer in ihrer Arbeit nicht ein-
schränken. Folglich werden globale Aktionen nicht unterstützt.
Wird zum Beispiel ein Modus für Skizzeneingabe und ein Modus für die Ausrich-
tung der Interaktionselemente angeboten, würde das einer globalen Aktion
gleichkommen. Dies ist ein Widerspruch zu Anforderung 15. Daraus folgt, dass
auf Modi verzichtet werden soll. Dadurch ergibt sich auch ein flüssiges Interakti-
onskonzept (siehe Anforderung 16).
Anforderung 16 (Flüssige Übergänge und keine Modi):
Um unnötige Kontextwechsel zu vermeiden, sollen alle Funktionen auf allen
Geräten (Tabletop-System und mobile Geräte) angeboten werden. Verschie-
denen Eingabemodi sollen vermieden werden.
4 KONZEPT PROCESS-TOUCH
28
Anforderung 3 und Anforderung 7 fordern ein natürliches und direktes User-
Interface. Um diesen Anforderungen nachzukommen, soll eine skizzenbasierte
Benutzereingabe angeboten werden (siehe Kapitel 3.4). Jedoch müssen hierfür
folgende Kriterien erfüllt werden [21]:
K1: Direkte und flüssige Touch-Interaktion
K2: Unterstützung für kollaborative Arbeit
K3: Erstellen von formalen und informellen Elementen
K4: Unterstützung für große Modelle
K5: Integration in bereits existierende Systeme
Kriterium K1 wird bereits durch Anforderung 7 repräsentiert, Kriterium K2 von
Anforderung 14 und Kriterium K5 wird durch Anforderung 12 wiedergegeben.
Durch die in Kapitel 3.1 vorgestellten Prozesselemente der BPMN werden formale
und informelle Elemente bereitgestellt (Kriterium K3). Das Kriterium K4 wird durch
Anforderung 17 repräsentiert.
Anforderung 17 (Unterstützung für große Modelle):
Ein großer Interaktionsbereich muss angeboten werden, um folglich auch
große Modelle zu unterstützen. Zusätzlich soll die Möglichkeit gegeben wer-
den, einzelne Prozellelemente in der Größe zu ändern.
Die Ausrichtung der Interaktionselemente nimmt bei Tabletop-Systemen eine
Schlüsselrolle ein (siehe Kapitel 3.5). Eine halbautomatische Ausrichtung steht im
Widerspruch zu Anforderung 13, da das Tabletop-System flexible Benutzeranord-
nungen unterstützen soll. Die Verwendung der Magnet-Metapher kommt einer
globalen Aktion gleich und ist aufgrund von Anforderung 15 somit unzulässig.
Daher wird eine manuelle Ausrichtung der Interaktionselemente verwendet (siehe
Anforderung 18).
4.1 ANFORDERUNGEN AN DAS KONZEPT
29
Anforderung 18 (manuelle Ausrichtung):
Die Ausrichtung der Interaktionselemente soll durch das Tabletop-System
nicht beeinflusst werden. Interaktionselemente werden somit von den Benut-
zern manuell ausgerichtet.
Berührt ein Benutzer das Display des Tabletop-Systems, sollen immer Rückmel-
dungen auf eine Touch-Eingabe gegeben werden, auch wenn keine Aktion aus-
geführt wird [30]. Dadurch wird dem Benutzer signalisiert, dass die Touch-
Eingabe erkannt wurde. Das visuelle Feedback soll dabei so gestaltet sein, dass
Benutzer beim Erlernen des Systems unterstützt werden (siehe Anforderung 19).
Anforderung 19 (Immer auf Benutzereingaben reagieren):
Das System muss immer auf Touch-Eingaben reagieren um dem Benutzer
Feedback zu geben und den aktuellen Systemstatus anzuzeigen.
In einem real anmutenden System kann ein Interaktionselement z.B. nicht plötz-
lich verschwinden, wenn es gelöscht wird. Der Übergang muss dabei fließend
sein, um dem Benutzer zu zeigen, was gerade passiert [30] (siehe Anforderung
20).
Anforderung 20 (Animierte Zustandsübergänge):
Jeder Zustandsübergang muss animiert sein, um den Benutzer diesen zu ver-
deutlichen.
Die aufgeführten Anforderungen bilden die Basis für ein kollaborativen Prozess-
modellierungssystem auf einem Tabletop. Diese werden im nächsten Kapitel ver-
wendet um Interaktionskonzepte zu definieren und ein Gesamtkonzept für die
kollaborive Prozessmodellierung auf Tabletop-Systemen zu erstellen.
4 KONZEPT PROCESS-TOUCH
30
Um die kollaborative Prozessmodellierung zu verbessern, wird ein Tabletop-
System verwendet, damit Benutzer gemeinschaftlich auf einem Gerät arbeiten
können. Tabletop-Systeme weißen spezifische Stärken (z.B. Kollaboration) und
Schwächen (z.B. Orientierung der Elemente) auf. Um die Schwächen des Table-
top-Systems zu kompensieren und Benutzern die Möglichkeit zu geben, individu-
elle zu arbeiten, wird verstärkt auf die zusätzliche Verwendung von mobilen Gerä-
ten, wie Smartphones und Tablets, gesetzt.
So kann jedes Gerät als Spezialist für einzelne Teilbereiche der kollaborativen Ge-
schäftsmodellierung angesehen werden. Durch eine sinnvolle Kombination unter-
schiedlicher Geräte zu einem Gesamtsystem, sollen die Vorteile gestärkt und die
Nachteile kompensiert werden, d.h. die Handhabung von Prozessmodellen ge-
schieht auf dem Tabletop oder auch auf dem Smartphone oder Tablet (siehe An-
forderung 9).
Die in Kapitel 4.1 bestimmten Anforderungen werden nachstehend zusammenge-
fasst, um das System Process-Touch aufzubauen.
Mobile Geräte werden beim Erstellen, Bearbeiten und Betrachten der Prozessmo-
delle miteinbezogen. Dabei können sie jeweils ihre Stärke als individuelles Gerät
mit Touchscreen ausspielen. Schnittstellen, an denen eine Kommunikation zwi-
schen den Geräten und dem Tabletop nötig ist, müssen intuitiv gestaltet werden
(siehe Anforderung 6).
Teile eines Prozessmodells können auf unterschiedlichen Geräten erstellt werden,
um sie anschließend auf dem zentralen Tabletop-System zu verbinden (siehe An-
forderung 10, Anforderung 4 und Abbildung 4-1). Dabei sollen Prozesselemente
zum einen vom mobilen Gerät hin zum Tabletop-System übertragen werden, als
auch vom Tabletop-System zum mobilen Gerät.
4.2 GESAMTKONZEPT
31
Abbildung 4-1: Tabletop als zentrale Instanz
In Abbildung 4-1 ist der Aufbau dargestellt. Der Tabletop dient als Server, der das
Prozessmodell enthält und mit den unterschiedlichen Geräten kommuniziert. Der
NFC-Tag dient dazu, die Verbindung zwischen Smartphone und Tabletop-Server
benutzerfreundlich zu initiieren. Hierbei muss der Benutzer den NFC-Tag mit dem
mobilen Gerät berühren (siehe Anforderung 5). Weiter wird in Abbildung 4-1 ge-
zeigt, dass sich Teile des gesamten Prozessmodells, welche auf den mobilen Ge-
räten erstellt wurden, mit einem einfachen Tap auf die Oberfläche des Tabletops
an diese Stelle einfügen lassen (siehe Kapitel 3.3.3, Anforderung 5 und Anforde-
rung 7). Durch die Positionierung der eingefügten Prozesselemente um die Posi-
tion des mobilen Geräts herum, sind diese auf dem Tabletop-System sofort auf-
findbar und der mentale Kontextwechsel wird erleichtert (siehe Anforderung 12).
Wird ein Prozessmodell auf das Tabletop-System übertragen, erfolgt die Verbin-
dung der einzelnen Teile des Prozessmodells anschließend mittels Touchbedie-
nung auf dem Tabletop-System.
Um Teilsysteme auf den mobilen Geräten zu bearbeiten, können die Prozessele-
mente mit diesem eingekreist und anschließend darauf übertragen werden. Dies
funktioniert auch mit mehreren Personen gleichzeitig, da eine Touch-Aktion (wie
in Abschnitt 3.3.3 gezeigt) einem Benutzer eindeutig zugeordnet werden kann
(siehe Anforderung 14). Zudem ist es auch möglich, ganze Prozessmodelle nur
mithilfe des Tabletop-Systems zu erstellen. Die Erstellung von Prozesselementen
und deren Verbindung ist sowohl auf dem Tabletop-System, als auch auf mobilen
Geräten möglich. Dabei unterscheidet sich die Art und Weise der Interaktion nicht
(siehe Anforderung 12 und Anforderung 16).
4 KONZEPT PROCESS-TOUCH
32
Um mobilen Geräten ohne NFC ebenfalls eine komfortable Verbindung zum Ser-
ver zu ermöglichen, wird zusätzlich zu dem NFC-Tag ein QR-Code angeboten.
Das Konzept von Process Touch kann auch ohne Tabletop-System umgesetzt
werden. Dazu zeigt Kapitel 4.2.1 einen alternativen Aufbau auf. In Kapitel 4.2.2
werden die unterschiedlichen Möglichkeiten der Erstellung und in Kapitel 4.2.3
die unterschiedlichen Möglichkeiten der Bearbeitung von Prozessmodellen auf-
gezeigt. Kapitel 4.2.4 erläutert, wie mit bereits gedruckten Prozessmodellen inter-
agiert werden kann.
4.2.1
ALTERNATIVER AUFBAU
Durch die geringe Verbreitung von Tabletop-Systemen, zeigt dieses Kapitel einen
alternativen Systemaufbau. Der alternative Systemaufbau kann jedoch auch als
Erweiterung des bereits bestehenden Systemaufbaus verwendet werden.
Das Konzept ist auch ohne Tabletop-System möglich und wird in Abbildung 4-2
gezeigt [37]. So dient ein Desktop-PC mit einem präparierten Monitor als zentrale
Instanz des Systems und ersetzt somit das Tabeltop-System. Mithilfe des präpa-
rierten Monitors wird die Kommunikation zwischen mobilen Geräten und dem
Desktop-PC stark vereinfacht. Wird z.B. ein Smartphone an den Rand des Moni-
tors gehalten, erscheint das Prozessmodell, welches auf dem mobilen Gerät er-
stellt wurde, an dieser Stelle. Anschließend lässt sich das Prozessmodell mit einer
Drag&Drop-Aktion verschieben und mittels Mausinteraktionen mit dem Gesamt-
system verbinden.
Abbildung 4-2: Alternativer Systemaufbau
4.2 GESAMTKONZEPT
33
Ebenso lässt sich ein zuvor selektierter Teil des Prozessmodells des Desktop-Pcs
auf die eingeblendete Fläche ziehen, um sie dem mobilen Gerät zur weiteren Be-
arbeitung zur Verfügung zu stellen. Die eingeblendete Fläche (siehe Abbildung
4-2, weiße Fläche) kann als gemeinsamer Bereich betrachtet werden. Der Daten-
austausch zwischen Server und dem mobilen Gerät wird hiermit ermöglicht. Wer-
den zwei Geräte gleichzeitig an den Monitor gehalten, erscheint für jedes ein ei-
gener Bereich. Damit lassen sich auch Daten zwischen zwei mobilen Geräten aus-
tauschen (siehe Anforderung 10). Im Hintergrund findet der Datentransfer über
WLAN oder Bluetooth statt. So kann, wie in Kapitel 3.3.2 beschrieben, auch ein
präparierter Monitor als zentrale Instanz dienen (siehe Anforderung 8). Der Nach-
teil des alternativen Aufbaus besteht darin, dass durch die unterschiedliche Be-
dienung (Touch-Interaktion vs. Maus- und Tastatur-Interaktion) kein flüssiger
Übergang realisierbar ist (siehe Anforderung 16). Der Vorteil liegt jedoch darin,
dass durch den einfachen Austausch ein Übergang zur individuellen Arbeit gege-
ben ist (siehe Anforderung 6) und durch die Verwendung eines Desktop-PCs,
dessen Vorzüge ausgespielt werden können. Wird an einem Prozessmodell länger
gearbeitet, kann eine bequeme Sitzposition eingenommen, Text kann schneller
eingegeben und durch die Verwendung der Maus kann präziser interagiert wer-
den.
4.2.2 ERSTELLUNG VON PROZESSMODELLEN
Auf mobilen Geräten, als auch auf dem Tabletop-System, können Prozesselemen-
te mittels Menüs oder Skizzeneingabe erstellt werden. Die Skizzeneingabe wird
dabei auf unterschiedliche Arten angeboten (siehe Abbildung 4-3).
Prozesselemente können erstellt werden, indem Benutzer den Umriss des ge-
wünschten Prozesselements mit dem Finger skizzieren (siehe Anforderung 8 und
Abbildung 4-3-b). Nachdem der Finger von der Oberfläche gelöst wird, interpre-
tiert das System die Skizzeneingabe. Durch die sofortige Interpretation der Skiz-
zeneingabe registriert der Benutzer falsche Interpretationen seitens des Systems
sofort.
Die zweite Möglichkeit der Skizzeneingabe basiert darauf, Prozessmodelle auf
einem Whiteboard oder Papier zu. Wird das skizzierte Prozessmodell vom Benut-
4 KONZEPT PROCESS-TOUCH
34
zer fotografiert und anschließend vom System automatisch in ein Prozessmodell
übersetzt (siehe Anforderung 8), kann er dieses anschließend in das Gesamtsys-
tem einbinden (siehe Abbildung 4-3-a).
a) Prozessmodell automatisch
anhand eines Bildes erstellen.
b) Skizzieren des Prozesselements
Abbildung 4-3: Skizzenbasierte Eingabe
4.2.3 BEARBEITUNG VON PROZESSMODELLEN
Prozessmodelle können auf dem Tabletop-System sowie auf mobilen Geräten
bearbeitet werden. Um Teile des Prozessmodells auf mobilen Geräten zu bearbei-
ten, müssen Prozesselemente zuerst vom Benutzer ausgewählt werden. Hierfür
selektiert der Benutzer die gewünschten Prozesselemente mittels einer Lasso-
Geste, welche mit dem mobilen Gerät ausgeführt wird (siehe Abbildung 4-4). An-
schließend werden diese auf das mobile Gerät übertragen (siehe Anforderung 6).
Abbildung 4-4: Auswahl der Prozesselemente
4.2.4 INTERAKTION MIT GEDRUCKTEN PROZESSMODELLEN
Werden Prozessmodelle ausgedruckt, können diese normalerweise nur betrachtet
werden. Dieses Kapitel zeigt die Möglichkeit auf, wie mit gedruckten Modellen
4.2 GESAMTKONZEPT
35
interagiert werden kann um z.B. Prozesselemente umzubenennen oder zu löschen
(siehe Anforderung 5). Somit können mobile Geräte auch gedruckte Prozessmo-
delle verändern (siehe Anforderung 8).
Den Startpunkt stellt das gedruckte Prozessmodell dar. Dieses leidet meist unter
dem Problem, dass nicht alle Informationen, Attribute und Beziehungen mitge-
druckt werden können, um die Komplexität zu reduzieren und die Verständlich-
keit zu maximieren (siehe Anforderung 17). Weiter können z.B. Änderungen der
Beschriftung von Prozesselementen nicht erfasst werden, wenn das Prozessmo-
dell bereits gedruckt ist.
Um gedruckte Prozessmodelle zu verändern und geänderte Werte eines bereits
gedruckten Prozessmodells anzeigen zu können, lassen sich verschiedene Prinzi-
pien anwenden. Diese werden in den folgenden Kapiteln aufgezeigt.
4.2.4.1 Präparierte Prozessmodelle
Ausgedruckte Prozessmodelle können mit NFC-Tags präpariert werden [38].
Dadurch wird jedes Prozesselement mit einem eigenen NFC-Tag eindeutig mar-
kiert. Bei einer Berührung des NFC-Tags mit dem mobilen Gerät, wird die vom
NFC-Tag gespeicherte ID drahtlos zum Server übermittelt. Anschließend stellt der
Server die zusätzlichen Informationen dem Benutzer über das mobile Gerät zur
Verfügung (siehe Abbildung 4-5).
Abbildung 4-5: Gedrucktes und mit NFC-Tags präpariertes Prozessmodell
4.2.4.2 Mobile Augmented Reality
Um zusätzliche Informationen zu gedruckten Prozessmodellen zu erhalten, kann
das Augmented Reality Pattern [39, 40] verwendet werden. Hierbei verwendet der
Benutzer ein Smartphone und richtet die Kamera auf das Prozessmodell. Das Bild
des Prozessmodells ist auf dem Display ist mit zusätzlichen Interaktionselementen
4 KONZEPT PROCESS-TOUCH
36
zu sehen. So können für jedes Prozesselement zusätzliche Informationen oder ein
Interaktionselement dargestellt werden (siehe Abbildung 4-6).
Abbildung 4-6: Mobile Augmented Reality
4.2.4.3 Projizierte Information
Smartphones wie z.B. das Samsung Galaxy Beam besitzen einen integrierten Pro-
jektor [41]. Damit ist es möglich zusätzliche Informationen direkt auf das gedruck-
te Prozessmodell projizieren (siehe Abbildung 4-7).
Abbildung 4-7: Projizierte Information
Der Vorteil besteht darin, dass kein Kontextwechsel zwischen dem gedruckten
Prozessmodell und dem Smartphone-Display nötig ist. Die projizierten Informati-
onen sind für alle Benutzer sichtbar, was je nach Anwendungsfall ein Vor- aber
auch ein Nachteil sein kann.
Dieses Kapitel zeigt auf, welche Möglichkeiten bestehen, mithilfe mobiler Geräte,
Prozessmodelle zu erstellen, zu bearbeiten und die Betrachtung von Prozessmo-
dellen mittels mobiler Geräte zu erweitern. Das Gesamtkonzept von Process-
Touch wird beschrieben, welches mobile Geräte als individuelle Eingabemedien
verwendet.
4.3 ZUSAMMENFASSUNG
37
Das hier vorgestellte Konzept unterstützt den Benutzer, Prozessmodelle zu erstel-
len, zu betrachten und zu erweitern. Aufgrund der hohen Komplexität, ist es im
Rahmen dieser Arbeit nicht möglich, das Konzept vollständig umzusetzen. So
wird in der weiteren Arbeit nur die Erstellung von Prozessmodellen, mithilfe eines
Tabletop-Systems und mobilen Geräten, betrachtet und ausgearbeitet.
4 KONZEPT PROCESS-TOUCH
38
39
5 INTERACTION-DESIGN
In diesem Kapitel wird ein Teil des in Kapitel 4 erstellten Konzepts, wird in diesem
Kapitel ausgearbeitet und verfeinert. Dabei wird der Fokus auf das zentrale Table-
top-System und die Interaktion mit mobilen Geräten gelegt. Im Detail wird auf
die allgemeine und menübasierte Interaktion (siehe Kapitel 5.1), ein Gestenset für
die skizzenbasierte Interaktion erstellt (siehe Kapitel 5.2) und die Interaktion mit
mobilen Geräten aufgezeigt (siehe Kapitel 5.3). Die Regeln der Syntaxprüfung
werden erläutert (siehe Kapitel 5.4) und ein Layouting-Verfahren für Prozessmo-
delle erarbeitet (siehe Kapitel 5.5)
Dieser Abschnitt zeigt den generellen Aufbau des Systems Process-Touch mittels
Touch-Eingaben. Touch-Eingaben können sowohl auf dem Tabletop-System, als
auch auf mobilen Geräten getätigt werden. Die Entscheidung wird dabei dem
Benutzer überlassen. Um Anfängern und auch fortgeschrittenen Benutzern eine
adäquate Bedienung anzubieten, greift diese Arbeit den Ansatz eins Interaction-
Rich-Systems [33] auf, welcher eine Vielzahl an verschiedenen Touch-Eingaben
und Gesten vorsieht. Eine Geste beschreibt dabei eine Touch-Eingabe, welche aus
einer Kombination aus Berührung und Bewegung eines oder mehrerer Finger be-
steht.
In einem Interaction-Rich-System kann eine Aktion von verschiedenen Gesten
ausgelöst werden, jedoch kann auch eine Geste in unterschiedlichen Kontexten,
unterschiedliche Aktionen auslösen. Eine Pinch-Geste, wobei zwei Finger einer
Hand zueinander, bzw. voneinander weg bewegt werden, kann beispielsweise
zum Zoomen oder auch zum Öffnen einer Gruppe von verwendet werden [32]
(siehe Kapitel 5.2).
Neben Gesten, sollen Benutzern zusätzlich Menüs angeboten werden, um Prozes-
selemente zu erstellen und mit diesen zu interagieren. So gibt es zwei verschie-
dene Menüs. Mithilfe des Hauptmenüs können neue Prozesselemente erstellt
werden und bietet somit einen Einstiegspunkt für die Erstellung von Prozessmo-
dellen. Das Menü wird mittels einer Pinch-Geste auf dem Hintergrund geöffnet
5 INTERACTION-DESIGN
40
(siehe Abbildung 5-1). Da das Tabletop-System von Benutzern auch als Ablage-
fläche verwendet wird und Benutzer sich darauf aufstützen, muss eine Geste als
Einstiegspunkt verwendet werden, welche eine versehentliche Öffnung des Me-
nüs vermeidet [30] (siehe Anforderung 5).
Abbildung 5-1: Hauptmenü öffnen
Prozesselemente können durch Kanten miteinander verbunden werden. Benutzer
versuchen häufig mit diesen Kanten zu interagieren [4]. Um den Ansatz des Inter-
action-Rich-Systems fortzuführen, soll das System eine Interaktion mit diesen er-
möglichen. Kanten werden folglich mit einem Kreis versehen (siehe Abbildung
5-2-a), der zum einen als Einstiegspunkt für die menübasierte Erstellung von Pro-
zesselementen dient (siehe Abbildung 5-2-b), zum anderen als Indikator, um an
diese Stelle Prozesselemente mittels Drag&Drop einzufügen (siehe Abbildung
5-2-c). So können auch unerfahrene Benutzer einfach mit dem System arbeiten,
ohne die Gesten für die Erstellung von Prozesselemente zu kennen.
a) Einstiegspunkt
b) menübasierte Erstellung
c) Elemente einfügen
Abbildung 5-2: Arbeiten mit Verbindungspfeilen
Neben dem Hauptmenü soll für Prozesselemente ein Kontextmenü angeboten
werden. Dieses bietet Benutzern die Möglichkeit, Eigenschaften zu ändern und
Aktionen auf dem Prozesselement auszuführen. Die Aktionen, welche vom Kon-
textmenü angeboten werden, sind in Tabelle 5-1 aufgeführt.
5.1 ALLGEMEINE INTERAKTION
41
Aktion
Beschreibung
Subprozess
entpacken
Die Aktion Subprozess entpacken ist nur bei Subprozessen verfügbar
und entpackt (engl.: Unwrap) alle Prozesselemente, welche sich in-
nerhalb des Subprozesses befinden.
Subprozess
erstellen
Die Aktion Subprozess erstellen ist nur bei Aktivitäten verfügbar und
erstellt aus einer Aktivität einen leeren Subprozess.
Prozesselement
duplizieren
Das Prozesselement, welches das Kontextmenü öffnet, wird dupli-
ziert.
Prozesselement
löschen
Das Prozesselement, welches das Kontextmenü öffnet, wird ge-
löscht.
Beschriftung
ändern
Eine virtuelle Tastatur erscheint neben dem Prozesselement, wel-
ches das Kontextmenü öffnet, um die Beschriftung zu ändern.
Tabelle 5-1: Aktionen des Kontextmenüs
Die Beschriftung des Prozesselements soll zusätzlich über eine Doppel-Tap-Geste
geändert werden können, um für eine häufig verwendete Aufgabe eine Abkür-
zung anzubieten. Da es zu Problemen kommen kann, wenn nur eine einzige Tas-
tatur angezeigt werden kann [5], muss für jede Texteingabe eine separate Tasta-
tur bereitstehen. Dadurch können mehreren Benutzern gleichzeitig Texteingaben
machen (siehe Anforderung 14). Tastaturen werden in unmittelbarer Nähe zum
Prozesselement positioniert (vgl. Gesetz der Nähe) Abbildung 5-3 zeigt die Tasta-
tur, welche an einem Prozesselement ausgerichtet ist.
Abbildung 5-3: Virtuelle Tastatur
5 INTERACTION-DESIGN
42
Jedes Menü und Prozesselement kann von Benutzern vergrößert, verkleinert, ver-
schoben und rotiert werden. Wird eine Tastatur angezeigt, ist diese mit dem kor-
respondierenden Prozesselement verbunden. Das bedeutet, dass eine Verschie-
bung oder Rotation der Tastatur eine entsprechende Aktion des Prozesselements
auslöst, um die relative Ausrichtung der beiden Elemente zueinander konstant zu
halten (siehe Anforderung 7). Dadurch wird das Prozesselement mit der Tastatur
in einer Einheit zusammengefasst um unnötige Kontextwechsel zu vermeiden
(siehe Anforderung 16).
Neben der menübasierten Eingabe, sollen dem Benutzer auch Gesten angeboten
werden, um mit dem Inhalt zu interagieren. Im Detail sind die möglichen Gesten
die elementaren Bausteine des Interaction-Designs. Somit ist die Erstellung und
Auswahl einzelner Gesten und die Zusammenstellung eines kompletten Gesten-
sets fundamental für das Interaction-Design.
In der Literatur sind zahlreiche Gestensets für unterschiedliche Kontexte (u.A.
auch BPM) zu finden [42, 21, 43, 4, 32, 30]. Einige Gesten können durch die ver-
wendete Hardware oder in einem Multi-User-System nicht umgesetzt werden.
Durch die teils geringe Probandenzahl der Studien, mit denen die Gesten-Sets
erstellt und validiert werden, werden diese als Indiz verstanden und es wird für
dieser Arbeit eine Kombination der vorgeschlagenen Gestensets verwendet. Ge-
nerell achten Benutzer kaum auf die Anzahl der verwendeten Finger für eine Ges-
te [32]. Hingegen bevorzugen sie Einhandgesten im Vergleich zu Zweihandgesten.
Viele Gesten-Sets sind von den Systemerstellern vorgegeben und die Gesten
nach verschiedenen Prinzipien logisch zusammengestellt [32, 43]. Das Benutzer-
verhalten ist jedoch selten systematisch.
Die Kombination von menübasierter und skizzenbasierter Eingabe erscheint als
wichtig, wenn beide Ansätze möglich sind. Dies gilt speziell für die Erstellung und
Löschung von Elementen. Die Verwendung von Gesten ändert sich jedoch nach
ca. einer Woche, wenn das System anhaltend verwendet wird [33]. Benutzer be-
vorzugen nach der Eingewöhnungsphase öfter Zweihandgesten. Daraus folgt,
5.2 GESTEN-SET FÜR BENUTZEREINGABEN
43
dass verschiedene Gesten im Sinne des Interaction-Rich-Systems, angeboten wer-
den müssen.
Es kann auch Vorteile haben, eine Kombination aus Stift und Fingereingabe zu
verwenden [42, 44]. Dabei werden mit der nichtdominanten Hand (NDH) Touch-
Aktionen und mit der dominanten Hand (DH) Stiftaktionen ausgeführt. Der Vorteil
liegt darin, dass Stiftaktionen präziser als Touch-Aktionen sind. So bezeichnen
Benutzer die Interaktion mit zwei Händen, wobei die DH einen Stift verwendet, als
Einfach, Schnell und Natürlich [44]. Entscheidend ist hierbei, dass die DH präzise
und komplexe Aufgaben bearbeitet, und die NDH dabei den Kontext erschließt
[45, 44].
Beispielsweise können Zweihandgesten auf dem Tabletop-System nicht verwen-
det werden, da die beiden Hände eines Benutzers nicht als zusammengehörig
erkannt werden können, wenn mehrere Benutzer gleichzeitig am Tisch arbeiten.
Das erstelle Gesten-Set beinhaltet auch die skizzenbasierte Erstellung (siehe Kapi-
tel 3.4) von Prozesselementen und ist im Folgenden aufgeführt.
Erstellen einer Aktivität
Aktivitäten können mit dem Hauptmenü
(Abbildung 5-4-a), der Skizzeneingabe (sie-
he Abbildung 5-4-b) oder mittels einer Ko-
pie einer vorhandenen Aktivität (siehe Ab-
bildung 5-4-c) erstellt werden.
a) Menü-
basiert
b) Skizzen-
basiert
c) Kopie
Abbildung 5-4: Aktivität erstellen
Erstellen eines Gateways
Gateways können mit dem Hauptmenü
(siehe Abbildung 5-5-a), der Skizzeneingabe
(siehe Abbildung 5-5-b) oder einer Kopie
eines vorhandenen Gateways (siehe Abbil-
dung 5-5-c) erstellt werden.
a) Menü-
basiert
b) Skizzen-
basiert
c) Kopie
Abbildung 5-5: Gateway erstellen
5 INTERACTION-DESIGN
44
Erstellen eines Ereignisses
Ereignisse können mit dem Hauptmenü
(siehe Abbildung 5-6-a), der Skizzeneingabe
(siehe Abbildung 5-6-b) oder einer Kopie
eines vorhandenen Ereignisses (siehe Abbil-
dung 5-6-c) erstellt werden.
a) Menü-
basiert
b) Skizzen-
basiert
c) Kopie
Abbildung 5-6: Ereignis erstellen
Prozesselemente verschieben
Elemente können mit einem Finger
verschoben werden (siehe Abbildung 5-7).
Abbildung 5-7: Prozesselemente verschie-
ben
Kante erstellen
Wird ein Prozesselement mit einem Finger
berührt (A) und auf ein anderes
Prozesselement (B) geschoben, wird eine
neue Kante (Sequenzfluss) erstellt. Prozess-
element A nimmt daraufhin die
ursprüngliche Position auf dem Display
wieder ein (siehe Abbildung 5-8).
Abbildung 5-8: Elemente verbinden
Selektieren von Prozesselementen
Wird ein Prozesselement mit einem Finger
kurz berührt und wieder losgelassen (siehe
Abbildung 5-9-a) oder mit einem Finger
eingekreist (siehe Abbildung 5-9-b), wird
dieses selektiert. Werden mehrere
Prozesselemente mit einem Finger
eingekreist (siehe Abbildung 5-9-c), werden
sie als Gruppe selektiert.
a) Einzelner Tap
b) Lasso-Geste
c) Lasso-Geste
Abbildung 5-9: Selektierung von Prozes-
selementen
5.2 GESTEN-SET FÜR BENUTZEREINGABEN
45
Deselektion von Prozesselementen
Wird in der Nähe der selektierten
Prozesselemente eine Tap-Geste
ausgeführt, wird die komplette Gruppe von
Prozesselementen deselektiert (siehe Abbil-
dung 5-10).
Abbildung 5-10: Tap auf Hintergrund
Prozesselemente zoomen
Prozesselemente können vergrößert
werden, indem zwei Finger ein
Prozesselement berühren und sich dann
voneinander entfernen. Berühren beide
Finger ein Prozesselement und nähern sich
einander an, wird das Prozesselement
verkleinert (siehe Abbildung 5-11).
Abbildung 5-11: Zoomen
Löschen von Prozesselementen und Kanten
Wird der Hintergrund mit einem Finger
berührt und ein Strich durch bestehende
Prozesselemente (siehe Abbildung 5-12-a)
oder durch bestehende Kanten (siehe Ab-
bildung 5-12-b) gezogen, werden diese
gelöscht.
a) Prozesselemente
löschen
b) Kante
löschen
Abbildung 5-12: Löschgeste
Subprozess erstellen
Durch die abstrakte Art der Aktion
Subprozess erstellen wurde auf eine Geste
verzichtet. So erscheint nach der Selektion
der Prozesselemente ein Button, um aus
den ausgewählten Prozesselementen einen
Subprozess zu erstellen (siehe Abbildung
Abbildung 5-13: Subprozess erstellen
5 INTERACTION-DESIGN
46
5-13).
Eine Subprozess-Aktivität wird im normalen Zustand wie eine Aktivität mit einem
Plus-Zeichen dargestellt. Vergrößert der Benutzer diese mittels einer Pinch-Geste,
wird der enthaltene Subprozess angezeigt (siehe Abbildung 5-14). Dies folgt An-
forderung 7 nach einem direkten Interface und setzt den Ansatz eines Interaction-
Rich-Systems.
Abbildung 5-14: Subprozess öffnen
Da keine globale Skalierung angeboten wird (siehe Anforderung 15), soll es den-
noch für Benutzer möglich sein, teile des Prozessmodels vergrößert zu betrach-
ten. Hierzu eignet es sich, mit zwei Fingern der NDH einen Bereich zu berühren,
der vergrößert werden soll. Anschließend kann die DH auf der Vergrößerung ope-
rieren (siehe Abbildung 5-15) [45]. Die Vergrößerung ist solange sichtbar, solange
der Benutzer mit der NDH den Bildschirm berührt, um den Bereich der Vergröße-
rung zu definieren. Auf der Vergrößerung kann mit der DH interagiert werden.
Abbildung 5-15: Lokale Vergrößerung
5.3 BENUTZEREINGABE MIT MOBILEN GERÄTEN
47
Wird mit dem Smartphone oder Tablet eine Tablet-Touch-Aktion, soll sich diese
identisch der Fingereingabe verhalten. So ist es möglich mit mobilen Geräten zu
skizzieren oder Menüs aufzurufen. Die Vorteile die es bietet, ein individuelles Ein-
gabegerät in der Hand zu haben, werden hierbei genutzt um dem Benutzer eine
einfache Bedienung des Systems zu erlauben (siehe Anforderung 8). Der daraus
folgende Kontextwechsel wird Zugunsten der schnelleren und einfacheren Einga-
be in Kauf genommen. Um dem Benutzer diesen Wechsel zu vereinfachen, wird
auf dem Tabletop ein Hinweis gegeben, welcher suggeriert, dass die Eingabe auf
dem mobilen Gerät erfolgt.
Berührt ein Benutzer den Einstiegspunkt eines Squenzflusses mit einem mobilen
Gerät, erscheint anstelle des radialen Menüs eine Auswahlliste auf dem Gerät des
Benutzers (siehe Abbildung 5-16). Der Vorteil, dass auf Smartphones mittels dem
Daumen einfach durch horizontale Listen gescrollt werden kann, wird hier ausge-
nutzt und das Menü als Liste visualisiert.
Abbildung 5-16: Menübasierte Auswahl auf dem Smartphone
Wird ein mobiles Gerät dazu verwendet, ein neues Prozesselement zu erstellen,
oder umzubenennen, wird dieses als Spezialist für die Texteingabe gesehen.
Durch Optimierungen der Texteingabe bei Smartphones [46, 47], kann die Ge-
schwindigkeit der Eingabe erhöht werden. So kann jeder Benutzer auch individu-
ell seine bevorzugte Art der Texteingabe verwenden, da die Einstellung auf dem
eigenen mobilen Gerät stattfindet und nicht als globale Einstellung des Tabletops
gespeichert wird. Um bei Texteingaben auf mobilen Geräten den Kontext nicht zu
verlieren, wird dem Benutzer dieser auf dem mobilen Gerät dargestellt (siehe Ab-
bildung 5-17).
5 INTERACTION-DESIGN
48
Smartphones bieten als individuelle Ein- und Ausgabegeräte weitere Möglichkei-
ten der Interaktion. Durch die Nutzung des Mikrofons für Sprachaufnahmen und
des Lautsprechers für deren Ausgabe, können auch Sprachanmerkungen aufge-
nommen (siehe Abbildung 5-18) und abgespielt werden ohne andere Benutzer
abzulenken.
Abbildung 5-17: Smartphone als Tastatur
Abbildung 5-18: Sprachanmerkung
Um die syntaktische Qualität der Prozessmodelle zu erhöhen, wird vor einer Kan-
tenerstellung überprüft, ob dadurch die korrekte Syntax von BPMN eingehalten
wird. Die verwendeten Regeln für die Syntaxprüfung sind in Tabelle 5-2 aufge-
führt. Wird eine der aufgeführten Regeln nicht eingehalten, können Prozessele-
mente von Benutzern nicht miteinander verbunden werden.
Regel
Beschreibung
Eine eingehende
und ausgehende
Kante bei Aktivi-
täten
Jede Aktivität darf maximal eine eingehende und maximal eine
ausgehende Kante besitzen. Eine implizite Aufspaltung des Se-
quenzflusses durch Aktivitäten, welche in BPMN einer AND-
Aufspaltung gleichkommt, wird nicht unterstützt. Ebenso wird auf
eine implizite Zusammenführung des Sequenzflusses durch Aktivi-
täten, welche in BPMN einer OR-Zusammenführung entspricht,
verzichtet.
Nur eingehende
oder nur ausge-
hende Kanten bei
Ereignissen
Es werden nur Start- und Ende-Ereignisse unterstützt. Ein Start-
Ereignis hat keine eingehenden, jedoch beliebig viele ausgehende
Kanten. Ein Ende-Ereignis hat beliebig viele eingehende, jedoch
keine ausgehenden Kanten.
5.5 LAYOUTING VON PROZESSELEMENTEN
49
Entweder auf-
spalten oder zu-
sammenführen
des Sequenzflus-
ses bei Gateways
Gateways können Sequenzflüsse aufspalten oder zusammenführen.
Die Kombination der beiden Möglichkeiten in einem Gateway ist
von BPMN zwar erlaubt, macht Prozessmodelle jedoch unüber-
sichtlich. In Process-Touch wird dies jedoch nicht unterstützt. Da-
her kann ein einzelnes Gateway Sequenzflüsse entweder Aufspal-
ten, oder Zusammenführen.
Schleifen nur mit
Gateways
Um Endlosschleifen innerhalb von Prozessmodellen zu verhindern,
wird überprüft, ob sich innerhalb einer Schleife ein Gateway befin-
det.
Keine Mehrfach-
kanten
Prozesselemente können nicht mehrfach miteinander verbunden
werden.
SESE bei Subpro-
zessen
Ein SESE-Block (Single Entry Single Exit) ist ein Teil des Prozessmo-
dells, wobei der gesamte SESE-Block genau eine eingehende und
genau eine ausgehende Kante besitzt [48]. Ein Subprozess kann
nur aus einem SESE-Block erstellt werden.
Tabelle 5-2: Regeln der Syntaxprüfung
Um dem Benutzer die Anordnung von Prozesselementen zu vereinfachen und der
Anforderung nach einem natürlichen, an der Realität angelehnten System nach-
zukommen (siehe Anforderung 3), dürfen keine Raster verwendet werden [30].
Globale Aktionen, wie z.B. ein Layouting-Button, widerspricht Anforderung 15,
welche globale Aktionen ablehnt. Daher sollen Prozesselemente während der
Interaktion immer korrekt angeordnet werden. Die Anordnung der Prozessele-
mente muss hierbei animiert von statten gehen, damit es für den Benutzer nach-
vollziehbar ist, wohin unterschiedliche Prozesselemente verschoben werden. Ziel
ist es, ein sich selbst layoutendes Prozessmodell zu erstellen. Die Verwendung
eines Force-Directed-Graph-Algorithmus ist dafür geeignet [49]. Die Wirkung auf
den Benutzer ist ein zusammenhängendes System, welches sich „lebendig“ an-
fühlt.
5 INTERACTION-DESIGN
50
Abbildung 5-19: Anziehung (Blau) und Abstoßung (rot) der Knoten
Das Prinzip des Layouting-Verfahrens ist es, dass Kanten zwischen zwei Prozes-
selemente als Feder fungieren und folglich diese zusammenhalten. Wird eines der
verbundenen Prozesselemente verschoben, wie durch eine Feder verbunden (sie-
he Abbildung 5-19, blaue Federn). Um eine mögliche Überlagerung der Prozes-
selemente zu verhindern, stoßen sich Prozesselemente zusätzlich gegenseitig ab.
Die Abstoßung ist ähnlich wie bei gleichgepolten Magneten (siehe Abbildung
5-19, rote Felder).
In Abbildung 5-20 ist ein Beispiel des Layouting-Verfahrens zu sehen. Zu Beginn
sind die Kräfte F1, F2 und F3, welche auf die korrespondierenden Prozesselemente
wirken, so gering, dass die Prozesselemente an der jeweiligen Position bleiben
(siehe Abbildung 5-20-a). Der Benutzer verschiebt das zusammenführende Gate-
way, sodass auf die beiden Aktivitäten eine höhere Kraft wirkt, da sie mit dem
zusammenführenden Gateway verbunden sind (siehe Abbildung 5-20-b). Darauf-
hin werden die Aktivitäten so lange in die Richtung der korrespondierenden Kraft
verschoben, bis sich diese wieder unter einem bestimmten Schwellwert befinden
(siehe Abbildung 5-20-c). Durch die Verschiebung der Aktivitäten, erhöht sich die
Kraft F1 (siehe Abbildung 5-20-c), und das aufspaltende Gateway wird in Richtung
der Kraft F1 verschoben (siehe Abbildung 5-20-d).
5.5 LAYOUTING VON PROZESSELEMENTEN
51
a) Verschieben eines Prozesselements
b) Kräfte F2 und F3 werden größer
c) neue Position der Aktivitäten;
Kraft F1 wird größer
d) neue Position des XOR-Gateways
Abbildung 5-20: Ablauf des Layouting-Vefahrens
Dieses Verfahren steht jedoch im Widerspruch zu einigen Gesten und bedarf da-
her Ausnahmen:
Prozesselemente werden verbunden, indem das Quellelement auf das Zie-
lelement gezogen wird. Das Layouting würde diese Interaktion jedoch
nicht zulassen, da das Quellelement das Zielelement verdrängen würde.
Somit muss hierfür eine Ausnahme gelten: Ist es nach den Regeln von
BPMN möglich, das Quellelement (wird gerade vom Benutzer verschoben)
mit einem Prozesselement zu verbinden, darf keine abstoßende Kraft zwi-
schen dem Quellelement und dem Prozesselement wirken. Diese Aus-
nahme gilt nur während der Benutzer ein Prozesselement verschiebt.
Die Interaktion mit Subprozessen stellt eine weitere Ausnahme dar, sofern
die Kindelemente des Subprozesses angezeigt werden. Um Prozessele-
mente innerhalb eines Subprozesses zu verschieben, darf der gesamte
Subprozess nicht von dem Quellelement verdrängt werden.
Datenflüsse erstrecken sich oft über große Teile eines Prozessmodells.
Damit anziehende Kräfte zwischen Prozesselementen mit gemeinsamen
Datenfluss das Layout nicht zerstören, haben Datenflüsse keine anziehen-
den Kräfte. Implizit lassen die gestrichelten Linien der Datenflüsse den Be-
5 INTERACTION-DESIGN
52
nutzer darauf schließen, dass hier keine bzw. weniger Kräfte als bei durch-
gezogenen Linien wirken.
Das Kapitel zeigt auf, wie das System Process-Touch von Benutzern verwendet
werden kann und welche Aktionen angeboten werden. Dabei wird die Notwen-
digkeit von gesten- und menübasierter Benutzereingabe aufgezeigt. Das Gesten-
set wird bestimmt und die Orientierung von Prozesselementen wird diskutiert. Es
wird erläutert, wie sich mobile Geräte einbringen lassen und wie das Layouting-
verfahren funktioniert.
Das in diesem Kapitel erstellte Feinkonzept wird im nächsten Kapitel visuell ange-
reichert um ein einheitliches Look & Feel zu schaffen.
53
6 VISUAL DESIGN
Das Konzept von Process-Touch wird in diesem Kapitel visuell ausgearbeitet.
Hierbei gilt es, Forderungen der Guidelines nach spezieller optischer Gestaltung
unterschiedlicher Plattformen, wie z.B. Microsoft Pixel Sense und Windows 8,
nachzugehen, um ein einheitliches Look&Feel des Gesamtsystems zu gewährleis-
ten [30, 50]. Forderungen der Guidelines können dabei einen technischen oder
ästhetischen Ursprung haben, oder berufen sich auf plattformweite Standards. Da
das System Process Touch nicht für spezielle Geräte und Plattformen konzipiert
ist, werden allgemeine Grundsätze der Gestaltung definiert.
Um ein einheitliches und konsistentes Interface anzubieten, werden folgende
Grundsätze in allen Interaktionselementen verwendet [30]:
Alle Elemente sollen ohne Rahmen dargestellt werden um den Fokus auf
den Inhalt zu richten (Anforderung 7). Es sollen auch keine Texturen oder
Farbverläufe verwendet werden, um das Interface möglichst schlicht zu
halten.
Linien sollen mindestens 2px breit sein, damit sie auch in rotiertem Zu-
stand auf dem Display sauber dargestellt werden können.
Alle klickbaren Elemente sollen mindestens 18mm breit und 18mm hoch
sein. Der Abstand klickbarer Elemente zueinander soll mindestens 3mm
betragen. Dieser Grundsatz gilt für alle Elemente in ihrer Standardgröße.
Auf jede Benutzereingabe soll das System unmittelbar reagieren
(Anforderung 19).
Darauf aufbauend, werden in Kapitel 6.1 Farben für die einzelnen Interaktions-
elemente definiert. Kapitel 6.2 zeigt die verwendeten Icons auf und beschäftigt
sich mit der Typographie der Beschriftungen der Interaktionselemente. Deren
Formen werden in Kapitel 6.3 bestimmt. Kapitel 6.5 beschäftigt sich mit den
Rückmeldungen, welche dem Benutzer während der Interaktion gegeben werden.
Dieser Abschnitt beschäftigt sich mit der Farbwahl für den Hintergrund der ein-
zelnen Interaktionselemente.
6 VISUAL DESIGN
54
Große Displays, wie Tabletop-Systeme, können den Benutzer optisch blenden,
wenn helle und leuchtende Farben großflächig verwendet werden [30]. Dies kann
vor allem bei längerer Benutzung des Systems unangenehm sein. Folglich soll für
das visuelle Design ein dunkler Hintergrund verwendet werden. Kleinere Flächen
und Linien sollen mit satten und kräftigen Farben hervorgehoben werden [30].
Damit die Anwendung nicht zu bunt und verspielt wirkt, wird als Hintergrundfar-
be ein dunkles Grau verwendet (siehe Abbildung 6-1).
Farben werden je nach kulturellem Kontext mit Eigenschaften oder Aussagen as-
soziiert. Diese Arbeit bezieht sich im Weiteren auf den westlichen Kulturraum. So
wird die Farbe Rot als Warnfarbe verstanden, wobei Grün für Erfolg und Bestäti-
gung steht. Gelb wird als neutrale Farbe verwendet um auf eine bestimmte Aktion
oder auf einen bestimmten Systemzustand aufmerksam zu machen. Diese drei
Farben werden mit der beschriebenen Semantik verwendet, um Benutzern Rück-
meldungen zu geben (siehe Kapitel 6.5). Die verwendeten Farbtöne sind in Abbil-
dung 6-1 mit den RGB-Werten dargestellt.
Abbildung 6-1: Farbtöne für Rückmeldungen auf der Hintergundfarbe mit RGB-Werten
Neben Farbtönen, welchen eine Semantik zugordnet werden kann, sollen unter-
schiedliche Bereiche des Systems durch semantisch neutrale Farben gruppiert
werden. So wird ein sattes Blau als Informationsfarbe für Markierungen, dem
Kontextmenü und der Tastatur verwendet. Somit werden Funktionen, welche Pro-
zesselemente verändern, gruppiert. Das Hauptmenü und die Interaktionselemen-
te der Verbindungspfeile werden in der Farbe Hellgrün eingefärbt. Datenelemen-
te und Datenflüsse werden in Magenta dargestellt, um sich von Aktivitäten,
6.2 ICONS UD TYPOGRAPHIE
55
Events, Gateways und Sequenzflüssen abzuheben. Der Eingabepfad, der die
Lasso-Geste repräsentiert, wird mit einem hellen Blau gefüllt, um sich deutlich von
der Skizzeneingabe abzugrenzen und die innenliegende Fläche des Eingabepfads
zu betonen. Die Farben sind in Abbildung 6-2 dargestellt.
Abbildung 6-2: Informationsfarben auf der Hintergrundfarbe mit RGB-Werten
Neben den vorgestellten Farben, wird noch die Farbe Weiß für Prozesselemente,
und die Farbe Schwarz bzw. Dunkelgrau für Beschriftungen verwendet. Das dunk-
le Grau wird vor allem bei Beschriftungen verwendet, welche auf hellen Flächen
positioniert sind. Dadurch verringert sich der Kontrast und die Beschriftung wird
besser lesbar, da sie auf Displays besser wiedergegeben werden kann [30]. Dies
macht sich bei rotierten Elementen besonders bemerkbar.
Icons dienen der visuellen Beschreibung von Aktionen und unterstützen Benutzer,
diese leichter zu verstehen und eine gewünschte Aktion schneller zu finden [51].
Dafür müssen Icons folgende Anforderungen erfüllen [30]:
Icons müssen eine einfache Geometrie aufweisen.
Icons dürfen nicht zu detailliert sein.
Icons müssen skalierbar sein.
Icons müssen sich guten Metaphern aus der Realität bedienen.
Icons müssen ein ähnliches visuelles Gewicht besitzen.
6 VISUAL DESIGN
56
Die Bedeutung der Icons muss dennoch von Benutzern erst erlernt werden. Des-
halb sollen Icons zusätzlich beschriftet werden und ein konsistentes Erschei-
nungsbild wird erschaffen.
Für das Hauptmenü, in dem neue Prozesselemente erstellt werden können, wer-
den kleine Vorschaubilder der Prozesselemente als Icons verwendet. Abbildung
6-3 zeigt die Icons des Hauptmenüs.
AND
XOR
Task
Data
Event
Abbildung 6-3: Icons des Hauptmenüs
Mittels dem Kontextmenü der Prozesselemente können deren Eigenschaften ver-
ändert, und Aktionen, welche sich auf das Prozesselement beziehen, ausgeführt
werden. Die Icons des Kontextmenüs der Prozesselemente sind in Abbildung 6-4
zu sehen.
Unwrap
Subprocess
Duplicate
Delete
Text
Abbildung 6-4: Icons des Kontextmenüs
Neben Icons, werden auch Prozesselemente Beschriftet und im ersten Schritt
muss die Beschriftung vom Benutzer gelesen werden können. Vor allem in NUIs,
wo Interaktionselemente und deren Beschriftung frei rotierbar sind, muss darauf
geachtet werden, dass alle Buchstaben in unterschiedlichen Winkeln auf einem
Display gut dargestellt werden können und somit gut lesbar sind. Die Schriftart
Segoe360 wurde speziell dafür entwickelt [30]. So sind z.B. bei den Buchstaben a,
e, c, die Counters (dt.: Öffnungen innerhalb von Buchstaben) weiter geöffnet, um
diese im gedrehten Zustand deutlicher zu erkennen. Zusätzlich ist der Buchsta-
benabstand größer, damit Buchstaben im gedrehten Zustand nicht miteinander
verschmelzen und einige Buchstaben sind angepasst, um sie besser lesen zu kön-
nen, wenn diese auf dem Kopf stehen. So ist das kleine „l“ verändert worden, um
es von einem großen „I“ besser zu unterscheiden. Auch das kleine „q“ ähnelt bei
vielen Schriftarten in gedrehtem Zustand dem kleinen „b“ (siehe Abbildung 6-5).
6.3 FORMEN DER INTERAKTIONSELEMENTE
57
Abbildung 6-5: Anpassung von Buchstaben bei der Schriftart Segoe360 [30]
Die Form der Prozesselemente ist in der BPMN bereits definiert (siehe Kapitel 3.1).
Events werden als Kreise und Gateways als Rauten (um 45° rotierte Quadrate)
dargestellt. Aktivitäten sind als Rechtecke definiert. Abbildung 6-6 zeigt die Ge-
staltung der verwendeten Prozesselemente (Aktivitäten, Events, Gateways und
Datenelementen).
Abbildung 6-6: Prozesselemente in Process Touch
Die Kreise auf den Verbindungspfeilen sind in Farbe und Form dem Hauptmenü
nachempfunden (siehe Gesetz der Ähnlichkeit in Kapitel 3.5). Ein Tap auf diese
Kreise, bzw. eine Pinch-Geste auf den Hintergurnd, öffnet ein neues Hauptmenü.
Dabei ist Mittelpunkt des Hauptmenüs der Mittelpunkt der Pinch-Geste, bzw. der
Mittelpunkt des Kreises auf einem Verbindungspfeil. Da die Auswahl an Prozes-
selementen keiner Priorisierung unterliegt, sind alle Icons im Hauptmenü gleich
schnell auswählbar. Nach Fitt’s Law müssen somit alle Elemente in gleicher Größe
und gleichem Abstand zur aktuellen Position des Fingers dargestellt werden (sie-
he Kapitel 3.5). Dies lässt sich mit einem radialen Aufbau realisieren. Abbildung
6-7 zeigt das radiale Hauptmenü welches in der Farbe Hellgrün eingefärbt wurde.
6 VISUAL DESIGN
58
Um den Kontrast zum Hintergrund zu erhöhen, werden Icons und deren Beschrif-
tung in der Farbe Weiß dargestellt.
Abbildung 6-7: Hauptmenü
Das Hauptmenü überdeckt häufig angrenzenden Prozesselemente (siehe Abbil-
dung 6-8). Aufgrund des Gesetztes der Schließung (siehe Kapitel 3.5) kann der
Benutzer dennoch die teils verdeckten Elemente problemlos erkennen. Dadurch
ist sichergestellt, dass dem Benutzer der Kontext des Menüs erhalten bleibt.
Abbildung 6-8: Verbindungsmenü
Mit einem langen Tap (1 Sek.) auf ein Prozesselement wird das Kontextmenü ge-
öffnet. In diesem Menü kann der Benutzer das ausgewählte Prozesselement dup-
lizieren, daraus einen Subprozess erstellen, einen Subprozess entpacken, den Text
ändern und das Prozesselement löschen. Auch wenn ein langer Tap ausgeführt
wird, muss das System darauf reagieren, um dem Benutzer mitzuteilen, dass die
Eingabe erkannt wurde (siehe Anforderung 19). Dies wird mittels einer Animation,
6.4 INTERAKTIONSELEMENTE
59
welche über die Wartezeit hinweg einen vollen Kreis zeichnet, visualisiert (siehe
Abbildung 6-9).
Abbildung 6-9: Animation des Kontextmenüs
Das Kontextmenü ist ebenfalls als radiales Menü dargestellt und die Darstellung
des unterscheidet sich von der Darstellung des Hauptmenüs. Die Zusammenge-
hörigkeit des Prozesselements zu den Elementen des Menüs wird mittels dem
Gesetz der Ähnlichkeit (gleiche Farbe und Orientierung; siehe Kapitel 3.5) und
dem Gesetz der Nähe (siehe Kapitel 3.5) erreicht.
Abbildung 6-10: Kontextmenü eines Prozesselements
Die Aktion Text ändern, öffnet eine virtuelle Tastatur. Diese ist durch das Gesetz
der Ähnlichkeit (gleiche Farbe und Orientierung) und dem Gesetz der Nähe mit
dem Prozesselement optisch verbunden. Der Aufbau der Tastatur ist dabei einer
typischen Tastatur von Smartphones nachempfunden. Das Ziel ist es, auf mög-
lichst geringem Platz eine gut handzuhabende Tastatur anzubieten (siehe Abbil-
dung 6-11).
6 VISUAL DESIGN
60
Abbildung 6-11: virtuelle Tastatur auf dem Tabletop-System
Um die Stärken der Tablets als individuelles Single-User-System auszunutzen, ist
auf den Tablets das Hauptmenü, das Kontextmenü und die Tastatur anders als auf
dem Tabletop-System dargestellt. Die hier vorgestellte Visualisierung stützt sich
auf die Windows 8 Design Guidelines [50].
Das Hauptmenü wird auf jedem Tablet nur einmal dargestellt, da immer nur ein
Benutzer mit einem Tablet arbeitet. Die Funktionen des Hauptmenüs, werden am
unteren Rand des Tablet dargestellt und lässt sich mit einer Wischgeste, welche
unterhalb des Displays startet und nach oben auf das Display führt, anzeigen (sie-
he Abbildung 6-12). Die Farbe des Hauptmenüs ist dieselbe wie auf dem Table-
top-System, damit sich Benutzer leichter orientieren können. Auf der linken Seite
des Hauptmenüs sind, im Vergleich zu der Tabletop-Variante, spezielle Funktio-
nen für ein Single-User-System gruppiert. Damit können alle Prozesselemente
selektiert, die Einstellungen aufgerufen und eine Aktion rückgängig gemacht wer-
den. Auf der rechten Seite des Hauptmenüs befinden sich die wichtigsten Funkti-
onen, da die meisten Benutzer Rechtshänder sind und somit besser und schneller
mit der rechten Hand interagieren können.
6.4 INTERAKTIONSELEMENTE
61
Abbildung 6-12: Hauptmenü auf dem Tablet
Das Kontextmenü ist auf den Tablets als Sidebar visualisiert, damit der Benutzer
eine Übersicht über die möglichen Einstellungen und Aktionen bekommt. Die
Sidebar ist auf der rechten Seite positioniert, um Rechtshändern eine bessere In-
teraktion zu bieten (siehe Abbildung 6-13). Wird das Kontextmenü angezeigt,
wird das dargestellte Prozesselement als einziges Prozesselement auf der Ober-
fläche markiert.
Um Beschriftungen der Prozesselemente zu ändern, wird eine Textbox innerhalb
der Sidebar angeboten. Als virtuelle Tastatur greift das System Process-Touch auf
die vom Betriebssystem angebotene Tastatur zurück (siehe Abbildung 6-14).
6 VISUAL DESIGN
62
Abbildung 6-13: Kontextmenü des Tablets
Abbildung 6-14: Tastatur auf dem Tablet mit Autovervollständigung
Die Rückmeldung des Systems auf Benutzereingaben werden in diesem Abschnitt
vorgestellt. Zum einen wird auf die Rückmeldungen bei Verbindungsaktionen von
Prozesselementen, bzgl. der Syntaxprüfung eingegangen (siehe Kapitel 6.5). Wei-
ter zeigt das Kapitel auf, wie das System auf Tablet Touch Aktionen reagiert (siehe
Kapitel 6.5.2).
6.5 RÜCKMELDUNGEN
63
6.5.1 SYNTAXPRÜFUNG
Rückmeldungen bei Verletzung bzw. Einhaltung der BPMN Syntax (siehe Kapitel
5.4) werden visuell durch unterschiedliche Farben dargestellt (siehe Anforderung
2). Versucht ein Benutzer eine Verbindungsoperation auszuführen, welche nicht
syntaxkonform ist, wird das Zielelement mit der Farbe Rot eingefärbt (siehe Ab-
bildung 6-15-a). Ist die Verbindungsaktion syntaktisch korrekt, wird das Zielele-
ment mit der Farbe Grün eingefärbt (siehe Abbildung 6-15-b). Um die Farben
deutlich wahrnehmen zu können, wird das verschobene Prozesselement halb-
transparent dargestellt. Nach der Verbindungsaktion springt das Quellelement
wieder an die ursprüngliche Position und wird für kurze Zeit mit der Farbe Gelb
eingefärbt, um auf die neue Position aufmerksam zu machen (siehe Abbildung
6-15-c).
a) Verletzung der Syntax
b) Einhaltung der Syntax
c) Nach Verbindung ist das
Quellelement wieder an
der ursprünglichen Positi-
on.
Abbildung 6-15: Rückmeldungen bei Verbindungsoperationen
6.5.2 TABLET-TOUCH-AKTIONEN
Werden Tablet Touch-Aktionen ausgeführt, sollen deutliche und leicht erkennba-
re Rückmeldungen seitens der Tablets gegeben werden, da während der Benut-
zeraktion das Tablet vom Körper weggehalten wird somit für den Benutzer nicht
gut sichtbar ist. Es werden vier verschiedene Rückmeldungen angeboten, welche
als modales Pop-up dargestellt werden. Diese werden mittels großen und farbigen
Flächen dargestellt und stellt einen bewussten Bruch der Regel dar, dass intensive
Farben nur auf kleinen Flächen verwendet werden sollen. Drei verschiedene Arten
der Benutzerinteraktion und ein Fehlerfall sind möglich (siehe Abbildung 6-16):
6 VISUAL DESIGN
64
a) Nicht erkannter Tablet-Touch
b) Prozesselemente auf Tabletop
übertragen
c) Prozesselemente mit Tablet selektieren
d) Prozesselement bearbeiten
Abbildung 6-16: Tablettouch Rückmeldungen
Wird auf dem Tablet eine Tablet-Touch-Aktion erkannt, kann jedoch nicht
auf dem Tabletop-System zugeordnet werden, erscheint eine Fehlermel-
dung (siehe Abbildung 6-16-a). Der Hintergrund des modalen Pop-up-
Menüs ist dabei in der Farbe Rot eingefärbt. Das Pop-up-Menü ver-
schwindet nach kurzer Zeit automatisch wieder. Alternativ kann der Be-
nutzer das Pop-up-Menü mit dem Close-Button schließen.
Transferiert der Benutzer Prozesselemente, welche auf dem Tablet erstellt
wurden, mittels einer Tablet-Touch-Aktion auf den Tabletop, wird eine po-
sitive Rückmeldung angezeigt (siehe Abbildung 6-16-b). Der Hintergrund
der positiven Rückmeldung in der Farbe Grün eingefärbt. Diese schließt
sich auch automatisch, jedoch deutlich später als die Fehlermeldung. Dies
hat den Grund, dass der Benutzer mehr Zeit zum lesen haben soll, da die
Elemente vom Tablet verschwunden sind und er nicht von einem Fehler
ausgehen muss.
Startet der Benutzer mittels einer Tablet-Touch-Aktion eine Selektion von
Prozesselementen, wird die Rückmeldung auf dem Tablet in der gleichen
Farbe wie die Füllung der Selektion auf dem Tabletop-System, eingefärbt
(siehe Abbildung 6-16-c). Damit wird dem Benutzer der Zusammenhang
6.6 ZUSAMMENFASSUNG
65
zwischen der Selektion auf dem Tabletop-System und dem Tablet aufge-
zeigt.
Berührt der Benutzer mit der Tablet-Touch-Aktion ein Prozesselement auf
dem Tabletop-System, kann er dieses als Kopie auf dem Tablet bearbeiten
(siehe Abbildung 6-16-d). Um ihm zu verdeutlichen, dass es sich um eine
Kopie handelt und das Prozesselement nicht transferiert wurde, wird es
nur in dem Pop-up-Menü angezeigt. Die Farbe des Pop-up-Menüs ist an
der Farbe der Prozesselemente angelehnt und in Hellgrau gehalten.
Dieses Kapitel zeigt das visuelle Design von Process Touch, welches ein schlichtes
und funktionales Design widerspiegelt. Konsistente Farben, Menüs und Icons der
Interaktionselemente unterstützen den Benutzer in der Interaktion. Durch die zu-
sätzliche Verwendung von informierenden Farben im Fehler- und Erfolgsfall be-
kommt der Benutzer subtile, aber leicht erkennbare und gut verstehbare Rück-
meldungen bzgl. des Systemzustands. Die teils unterschiedliche Gestaltung des
Tabletop- und Tablet-Interfaces führt dazu, dass das Tablet seine Stärken als Sin-
gle-User-System ausspielen kann.
Auf Basis der visuellen Ausarbeitung der einzelnen Interaktionselemente, Menüs
und Dialoge, wird im nächsten Kapitel Process Touch implementiert.
6 VISUAL DESIGN
66
67
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
Developing the user interface of a professional software application is
not easy. It can be a murky blend of data, interaction design, visual de-
sign, connectivity, multithreading, security, internationalization, valida-
tion, unit testing, and a touch of voodoo.
- Josh Smith [52]
In diesem Kapitel wird der Systemaufbau von Process Touch aus technischer Sicht
betrachtet und die verwendeten Technologien, Software Pattern (siehe Kapitel
7.1) und Konzepte der Implementierung (siehe Kapitel 7.2) werden detailliert vor-
gestellt. Nicht alle Konzepte aus Kapitel 5 werden Implementiert. Die lokale Ver-
größerung (siehe Kapitel 5.2) und textuelle bzw. auditive Anmerkungen sind nicht
Umgesetzt. Zudem werden nur Tablets als mobile Geräte verwendet. Speziell wird
auf die Kommunikation zwischen dem Tabletop-System und den Tablets (siehe
Kapitel 7.3), auf die skizzenbasierte Benutzereingabe (siehe Kapitel 7.4) und auf
das Layouting-Verfahren (siehe Kapitel 7.5) eingegangen.
Die Proof-of-Concept-Implementierung wird in der Programmiersprache C# ent-
wickelt und verwendet das Grafik-Framework WPF (Windows Presentation Foun-
dation), welches Teil des .NET-Frameworks ist [53].
Um das visuelle Design, das in Kapitel 6 vorgestellt wurde zu adaptieren, bietet
das Grafik-Framework WPF viele Möglichkeiten. Durch die deklarative Auszeich-
nungssprache XAML die kann das Aussehen der einzelnen Steuerelemente von
ihrer Funktionalität und Logik getrennt werden [54]. Für die graphische Darstel-
lung der Steuerelemente wird von WPF die Direct3D-API angesprochen [55] re-
chenintensive Aufgaben wie z.B. Animationen und Effekte werden von der Gra-
phikkarte übernommen. Zudem kann WPF OpenType- und TrueType-Schriftarten
darstellen, wodurch eine typographische Anpassung möglich ist. Durch die Unter-
stützung des aRGB-Farbraums, welcher zusätzlich zu dem Rot-, Grün- und Blau-
Kanal einen eigenen Transparenz-Kanal (Alpha) anbietet, kann das visuelle Design
vollständig umgesetzt werden.
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
68
Process-Touch gliedert sich in zwei eigenständige Programme. Zum einen ist eine
Anwendung für den Microsoft Pixel Sense notwendig, welche auch als Server-
instanz für die Kommunikation mit den mobilen Geräten dient. Diese Anwendung
basiert auf dem Pixel Sense-SDK und ist nur unter Windows 7 lauffähig. Einzuord-
nen ist diese Anwendung in Abbildung 7-1 auf dem Pfad Desktop Apps C#
.NET. Die zweite Anwendung ist eine Windows-Store-App [56], welche auf mobilen
Geräten mit Microsoft WindowsRT ausgeführt wird und ist in Abbildung 7-1 auf
dem Pfad Windows style Apps XAML C# WinRT APIs zu finden.
Abbildung 7-1: Technologien von Microsoft Windows [57]
Bei der Einordnung der Programme in das in Abbildung 7-1 dargestellte Schema,
zeigt sich, dass beide Programme über unterschiedliche APIs auf unterschiedli-
chen Windows Cores (das von Windows 7 und das von Windows 8) zugreifen.
Um redundanten Code bezüglich der zwei unterschiedlichen Plattformen
(Windows8 App und Windows7 Anwendung) zu minimieren und eine hoch inter-
aktive GUI aufzubauen, ist der Aufbau der Programme bezüglich der Softwarear-
chitektur entscheidend. Das Model-View-ViewModel (MVVM) Design-Pattern (sie-
he Kapitel 7.1.1) liefert die Grundlage dafür, redundanten Code zu vermeiden
[56]. Teile des Softwareprojektes werden anschließend zu einer Portable Class
Library (siehe Kapitel 7.1.2) kompiliert, um sie auf beiden Plattformen ausführen
zu können [57].
7.1 SOFTWAREARCHITEKTUR
69
Ein Design Pattern ist ein Regelsatz, welcher einer Implementierungsempfehlung
gleichkommt. Die Implementierung richtet sich stark an das vorgestellte Pattern,
bricht dieses jedoch an einigen Stellen um flexibler zu sein und Overhead einzu-
sparen [52].
7.1.1 DAS DESIGN-PATTERN MODEL-VIEW-VIEWMODEL
MVVM, steht für Model-View-ViewModel und ist ein weit verbreitetes Design-
Pattern für die Entwicklung von Programmen unter C# mit WPF / XAML [52, 56].
Das MVVM Design-Pattern ist eine Weiterentwicklung des MVC (Model-View-
Controller) bzw. des MVP (Model-View-Presenter) Design-Patterns [58]. Es gliedert
das System in die drei Bereiche Model, View und ViewModel (siehe Abbildung
7-2). Diese haben folgende Aufgaben:
Das Model hält die Daten und implementiert die Geschäftslogik.
Das ViewModel (VM) abstrahiert das Model es macht es der View zugäng-
lich. Zusätzlich bietet das VM Commands an, welche von den EventHand-
lern der View aufgerufen werden. VM Objekte halten nur Referenzen der
Models bzw. von anderen VM, nicht aber der View. Daraus folgt eine lose
Kopplung der View.
Die View wird mittels Datenbindungen (engl.: DataBinding) an die korres-
pondierenden VMs gekoppelt. Dadurch ist ersichtlich, dass eine Benutzer-
schnittstelle (View) eine visuelle Repräsentation der VMs ist.
Abbildung 7-2: Prinzip des MVVM-Patterns
Durch eine Datenbindung wird eine Verbindung der Geschäftslogik (d.h. VM und
Model) und der Benutzeroberfläche hergestellt (d.h. View) [59]. Durch die Daten-
bindung ändern sich die an die Daten gebundenen Steuerelemente automatisch
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
70
bei jeder Änderung des Werts der Daten. Bei einer Änderung der Werte durch die
Steuerelemente, werden die zugrunde liegenden Daten automatisch aktualisiert.
Beispielsweise ändert ein Benutzer den Inhalt eines TextBox-Steuerelements
und die Änderung wird automatisch in der darunterliegenden Variablen aktuali-
siert. Eine Aktualisierung der Darstellung des Wertes durch ein Steuerelement
erfolgt ähnlich dem Observer-Pattern [58]. So schreibt sich das Steuerelement in
den PropertyChangedEventHandler, welcher Änderungen von Variablen-
werten allen eingeschriebenen Objekten mitteilt, des darunterliegenden VMs ein
und wird über ein PropertyChangedEvent auf die Änderung aufmerksam ge-
macht.
Da das VM und Model auf keine spezielle View angewiesen sind um ausgeführt
zu werden, können auch unteschiedliche Views oder UnitTests an ein VM gekop-
pelt werden [52]. Die beiden Anwendungen des Gesamtsystems (Windows-Store-
App und PixelSense-Anwendung) bilden hierbei eine eigene View, welche an die
gleichen VMs gekoppelt sind. Die VMs und Models müssen folglich auf beiden
Plattenformen ausgeführt werden können, um eine doppelte und somit redun-
dante Implementierung zu verhindern. Dies kann mittels dem Konzept der Por-
table Class Library umgesetzt werden und wird im folgenden Kapitel 7.1.2 erläu-
tert.
7.1.2 PORTABLE CLASS LIBRARY
Für das VM und Model (d.h. die Geschäftslogik) wird ein eigenes Software-Projekt
erstellt und in einer eigenen Datei als Portable Class Library (PCL) ausgeliefert
[57]. Eine PCL ist eine dynamische Programmbibliothek (DLL), welche auf unter-
schiedlichen Plattformen ausgeführt werden kann. Dafür werden nur Pakete, Klas-
sen und Methoden verwendet, welche von den beiden Plattformen Windows8
und Windows7, ausgeführt werden können. Somit muss die Logik des Programms
nur einmal implementiert werden und unterschiedliche Plattformen verwenden
dieselbe Codebasis. Dies erleichtert zusätzlich den Datenaustausch zwischen den
Plattformen, da die Daten auf beiden Seiten mittels denselben Klassen serialisiert
bzw. deserialisiert werden können (siehe Kapitel 7.3).
7.2 UMSETZUNG DES PROTOTYPEN
71
Dieses Kapitel beschreibt den generellen Aufbau der Anwendungen anhand des
MVVM Design-Patterns. In Kapitel 7.2.1 und Kapitel 7.2.2 wird die konkrete Im-
plementierung der gemeinsamen Datenbasis beschrieben (d.h. Model und VM).
Kapitel 7.2.3 und Kapitel 7.2.4 zeigen die konkrete Implementierung der jeweili-
gen Benutzeroberfläche. Beide Benutzeroberflächen bauen auf einer gemeinsa-
men Datenbasis auf und bieten eine plattformspezifische, visuelle Repräsentation
der Codebasis.
7.2.1 MODEL-KLASSEN
Die Basis aller Interaktionselemente, welche sich auf der Benutzeroberfläche be-
finden, bildet die abstrakte Klasse ElementBase. Diese Klasse implementiert den
PropertyChangedEventHandler, um die darüber liegenden ViewModel-
Klassen auf Änderungen der Werte der Datenbasis aufmerksam zu machen.
Grundlegende Eigenschaften wie z.B. die Position, die minimale, maximale und
aktuelle Höhe und Breite des Interaktionselements und die Beschriftung werden in
dieser Klasse zusammengefasst. Es werden Methoden angeboten, um den Layou-
ting Vorgang anzustoßen, rudimentäre Syntaxüberprüfungen bzgl. BPMN durch-
zuführen und um Prozesselemente miteinander zu verbinden.
Von der Basisklasse ElementBase erben alle Model-Implementierungen, wie z.B.
ActivityModel, ConnectionModel, GatewayModel, KeyboardModel und
MainMenuModel. Auch wenn z.B. ein Hauptmenü nicht mit anderen Steuerele-
menten verbunden werden kann, reduziert sich die Komplexität der gesamten
Anwendung, wenn allen, auf der Benutzeroberfläche angezeigten Interaktions-
elementen, eine einheitliche Datenbasis zugrunde liegt. Innerhalb dieser Model-
Implementierungen werden die Regeln der Syntaxüberprüfung für jedes Prozes-
selement separat vervollständigt und spezifische Ausprägungen dieser implemen-
tiert. Zum Beispiel enthält die Klasse ActivityModel das Enum ActivityDi-
mension, um die Dimension einer Aktivität (keine, Benutzer, Skript, Prozess) zu
speichern. Das Enum wird über das zugehörige VM mittels Datenbindung der
Benutzeroberfläche zugänglich gemacht, welche je nach Wert der Variable, ein
zugehöriges Symbol anzeigt. Ändert sich der Wert dieses Enums, wird das Symbol
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
72
automatisch angepasst. Das Mapping des Enum-Werts auf ein bestimmtes Sym-
bol wird prinzipiell über BindingConverter implementiert, welche Teil der
plattformabhängigen View sind. Ein BindingConverter ist eine Klasse, welche
das Interface IValueConverter implementiert. Dabei kann für jede Bindung ein
eigener BindingConverter angegeben werden. Allgemein gesprochen, bildet
ein BindingConverter einen bestimmten Datentypen A auf einen anderen
Datentypen B ab (und umgekehrt) [59].
7.2.2 VIEWMODEL-KLASSEN
Die Klasse ViewModel bildet die Basisklasse des gleichnamigen Bereichs des
MVVM-Patterns. Diese Klasse referenziert das Model (ElementBase), welches
der View dadurch zugänglich gemacht wird. Benutzeraktionen, welche die View
empfängt, werden über das Command Pattern [56] der Klasse ViewModel, und
somit auch der Geschäftslogik (d.h. VM und Model) zugänglich gemacht. Hierfür
bietet die Klasse ViewModel Commands an, um auf TouchUp- und TouchDown-
Aktionen des Benutzers reagieren zu können und die Befehle des Kontextmenüs
anzunehmen (d.h. Löschen, Duplizieren, Subprozess entpacken, Subprozess erstel-
len, Tastatur anzeigen). Änderungen von Eigenschaften der Interaktionselemente,
die über Datenbindungen gekoppelt sind, wie z.B. die Position oder Beschriftung,
werden nicht von Commands, sondern von Datenbindungen geregelt.
Von der Basisklasse ViewModel erben alle spezifischen VM-Implementierungen,
wie z.B. ActivityViewModel, ConnectionViewModel, GatewayViewModel,
KeyboardViewModel und MainMenuViewModel. So implementiert z.B. die
Klasse ActivityViewModel die Eigenschaft CornerRadius, welche den Radi-
us der abgerundeten Ecken des Prozesselements, in Abhängigkeit der Größe des
Prozesselements, angibt.
Eine Sonderstellung nimmt das VM MyScatterViewViewModel ein, da es das
korrespondierende VM der obersten visuellen Ebene der Anwendung ist. Dieses
VM hat folgende Aufgaben:
Speichern aller Instanzen anderer VMs.
Selektion und Deselektion der Prozesselemente.
7.2 UMSETZUNG DES PROTOTYPEN
73
Verschieben von Selektionsgruppen von Prozesselementen.
Einfügen neuer Prozesselemente zwischen zwei existierende Prozessele-
mente.
Erzeugen von Menüs und Tastaturen.
Aufbau der horizontalen Kommunikation zwischen VMs mittels dem Ob-
server Pattern.
Erstellen und Löschen von Interaktionselementen mittels Skizzeneingabe.
Erstellen von Subprozessen.
Innerhalb der PCL befindet sich der Namespace Sketch, welcher die Verarbeitung
der Skizzen übernimmt. Die Verfahren für die Skizzenerkennung werden in Kapitel
7.4 aufgezeigt. Da die Klasse SketchViewModel nicht von der abstrakten Klasse
ViewModel erbt und auch kein korrespondierendes Model aufweist, bildet dieses
VM eine Ausnahme. Die Aufgabe der Klasse SketchViewModel ist, die einzel-
nen Punkte des Pfades der Gesteneingabe zu speichern. Dieser Pfad bildet eine
Visualisierung ohne Interaktionsmöglichkeiten und wird daher separat behandelt.
Das Layoutingverfahren (siehe Kapitel 5.5) wird in der Klasse LayoutManager
implementiert und ist ebenfalls Teil der PCL, da es auf allen Plattformen zum Ein-
satz kommt (siehe Kapitel 7.5).
7.2.3 VIEW DES TABLETOP-SYSTEMS
Dieser Abschnitt zeigt die Aufgabe der View und die Implementierung für das
Tabletop-System. Da die Konzepte der Implementierung für das Tabletop-System
und der Tablets gleich sind, werden die Konzepte in diesem Kapitel erklärt und im
nächsten Kapitel 7.2.4 wird auf die spezifischen Merkmale der Tablet-
Implementierung eingegangen.
Die View bildet das ausführbare Programm der Anwendung und referenziert da-
bei die gemeinsame PCL. Das Gesamtsystem besteht aus zwei eigenständigen
Anwendungen, welche ähnlich Aufgebaut sind. Neben den teils unterschiedlichen
Steuerelementen (vgl. Kapitel 6), unterscheiden sie sich hauptsächlich dadurch,
dass sie auf verschiedenen Plattformen aufbauen und folglich verschiedene Soft-
ware-Development-Kits (SDK) verwenden. Der komplette Aufbau der Anwendung
ist anhand von Aktivitäten in Abbildung 7-3 dargestellt.
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
74
Abbildung 7-3: Aufbau der Anwendung
Die Anwendung für das Tapletop-System (PixelSenseView) basiert auf Windows 7
und referenziert das Surface SDK von Microsoft [60]. Das Surface SDK bietet Steu-
erelemente, welche sich für Tabletop-Systeme besonders eignen. Speziell die bei-
den Steuerelemente ScatterView und ScatterViewItem. Ein ScatterVie-
wItem bildet den Container für Steuerelemente, welche sich dadurch mit einfa-
chen Gesten frei drehen, verschieben und skalieren lassen. Die Klasse DragD-
ropScatterViewItem erweitert die Klasse ScatterViewItem, indem speziel-
le Drag&Drop-Aktionen implementiert werden. Innerhalb des Steuerelements
DragDropScatterViewItem befinden sich spezifische Steuerelemente, welche
die einzelnen VMs visuell repräsentieren. Für jedes VM existiert ein korrespondie-
rendes Steuerelement, wie z.B. ActivityControl, ConnectionPoint, Gate-
7.2 UMSETZUNG DES PROTOTYPEN
75
wayControl, Keyboard und MainMenu. Das Steuerelement ActivityCon-
trol, das das Steuerelement für Aktivitäten darstellt, ist, wie alle anderen Steue-
relemente auch, lose an das VM gekoppelt und kommuniziert (hauptsächlich)
über Commands mit diesem.
Ein Steuerelement DragDropScatterViewItem kann dabei nur das Scatter-
View-Steuerelement als visuelles Elternelement besitzen. Das ScatterView-
Steuerelement dient nur als Container. Um die ScatterView mit Verwaltungs-
aufgaben anzureichern, erweitert die Klasse SebaScatterView das Steuerel-
ment ScatterView. Die SebaScatterView erstreckt sich über das komplette
Anwendungsfenster und bildet somit die Grundlage der Anwendung. Als Data-
Context des SebaScatterView–Steuerelements wird die Klasse MyScatter-
ViewViewModel verwendet.
Die Verbindungspfeile der Prozesselemente dürfen sich nicht innerhalb der Se-
baScatterView befinden, da sie sonst in ein ScatterViewItem eingebettet
werden müssen. Durch die Einbettung könnte der Benutzer diese Interaktionsle-
mente verschieben und mit ihnen Interagieren. Die Verbindungspfeile zeigen je-
doch nur Verbindungen an und eine Benutzerinteraktion mit diesen ist nicht
möglich. Die Kreise, welche sich in der Mitte eines Verbindungspfeils befinden,
können als Interaktionselemente genutzt werden (Steuerelement Conntection-
Point) und werden innerhalb des Steuerelements SebaScatterView in ein
Steuerelement DragDropScatterViewItem eingebettet. Um die Pfeile dar-
stellen zu können, wird hinter der transparenten Steuerelement SebaScatter-
View ein ItemsControl-Steuerelement definiert, welches sich ebenfalls über
das komplette Fenster der Anwendung erstreckt. Die Klasse MyScatter-
ViewViewModel ist ebenfalls der DataContext des ItemsControl-
Steuerelements. Somit kann auf die Eigenschaften aller dargestellten Interakti-
onselemente zugegriffen werden. Über das Templating-System von XAML werden
die Verbindungspfeile (d.h. ein Strich und ein rotiertes Dreieck als Pfeilspitze) in-
nerhalb eines Canvas dargestellt. Programmcode 7-1 zeigt exemplarisch das
Template der Verbindungspfeile der Prozesselemente auf, um die verwendeten
Konzepte zu veranschaulichen. Die Daten, welche von diesem Template darge-
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
76
stellt werden, müssen als DataContext des Elternelements gesetzt sein, um darauf
zugreifen zu können. In Zeile 1 wird die ItemSource ausgewählt, welche die
Quelle der darzustellenden Interaktionselemente bildet. Die Quelle wird von der
Liste Connections repräsentiert, welche ein Attribut der Klasse MyScatter-
ViewViewModel ist. Darin sind die Start- (d.h. FromX und FromY) und End-
Koordinaten (d.h. ArrowHeadX und ArrowHeadY) der Verbindungspfeile der
Prozesselemente gespeichert. Die Koordinaten werden verwendet, um eine Linie
zu zeichnen (siehe Zeile 5) und ein rotiertes Dreieck (siehe Zeile 15). Dafür wird in
Zeile 5 (und den folgenden) eine Datenbindung für die Farbe der Linie, für den
Linienstil (d.h. durchgezogen, oder gepunktet), die Linienbreite und für den Start-
und Endpunkt der Linie aufgebaut und teils BindingConverter verwendet. Die Bin-
dingConverter müssen in der View definiert werden, da diese für die Übersetzung
der abstrakten Parameter auf plattformspezifische Parameter zuständig sind.
1 <ItemsControl ItemsSource="{Binding Path=Connections}">
2 <ItemsControl.ItemTemplate>
3 <DataTemplate>
4 <Canvas>
5 <Line Stroke="{Binding StrokeColor,
6 Converter={StaticResource ColorConverter}}"
7 StrokeDashArray="{Binding Strokes,
8 Converter={StaticResource StrokeConverter}}"
9 StrokeThickness="1"
10 X1="{Binding FromX}"
11 Y1="{Binding FromY}"
12 X2="{Binding ArrowHeadX}"
13 Y2="{Binding ArrowHeadY}"
14 />
15 <Polygon Points="{Binding Arrow,
16 Converter={StaticResource PointConverter}}"
17 Fill="{Binding StrokeColor,
18 Converter={StaticResource ColorConverter}}"
19 Stroke="{Binding StrokeColor,
20 Converter={StaticResource ColorConverter}}"
21 StrokeThickness="1"
22 />
23 </Canvas>
24 </DataTemplate>
25 </ItemsControl.ItemTemplate>
26 </ItemsControl>
Programmcode 7-1: ItemTemplate der Verbindungspfeile
Die Anzeige der Pfade der Gesteneingabe wird äquivalent zu den Verbindungs-
pfeilen, innerhalb eines eigenen ItemControl-Steuerelements im Hauptfenster
der Anwendung, implementiert.
7.3 KOMMUNIKATION UND DATENAUSTAUSCH
77
7.2.4 VIEW DER WINDOWS-STORE-APP
Dieses Kapitel zeigt die Implementierung der View für Windows-Store-App, wel-
che auf den Tablets zum Einsatz kommt. Da diese ähnlich wie die Implemtierung
der View Tabletop-Systems ist, wird auf die Unterschiede zwischen der Imple-
mentierungen der Anwendung für das Tabletop-System und der Windows-Store-
App für die Tablets, eingegangen.
Aus der View der Windows-Store-App [56], kann das Microsoft Surface SDK nicht
referenziert werden, da dieses Windows 8 nicht unterstützt [60]. Daher werden in
der Windows-Store-App die beiden Steuerelemente SebaScatterView und
DragDropScatterView mit ähnlicher Funktionalität programmiert. Durch die
Bereitstellung der gleichen Steuerelemente für beide Anwendungen, wurde die
Entwicklung deutlich vereinfacht, und analog zu Kapitel 7.2.3 umgesetzt.
Das Hauptmenü der Windows-Store-App wird global am unteren Rand des Dis-
plays angezeigt. Hierfür wird im Hauptfenster der Anwendung mittels XAML ein
BottomAppBar–Steuerelement definiert, welche die Funktionalität (d.h. Anzeige
mittels Geste, Animationen) übernimmt und mittels Events die Benutzeraktionen
an die korrespondierende Klasse des Hauptfensters delegiert [56].
Das Kontextmenü wird mithilfe des Flyout–Steuerelements implementiert. Hier-
für erweitert das Steuerelement SebaFlyout das Steuerelement Settings-
Flyout und zeigt, abhängig des DataContext (d.h. aktuelles Prozesselement),
spezifische Steuerelemente auf der rechten Seite des Displays an [56]. Die Anzei-
ge mittels einer Wischgeste, das animierte Erscheinen und Verschwinden wird von
dieser Klasse übernommen. Da das Menü global angezeigt wird, kann es inner-
halb jeder Klasse erstellt werden und bedarf keinem korrespondierenden VM-
Objekt.
Das Tabletop-System dient für die Kommunikation mit den Tablets als Server. Das
bedeutet, dass die Kommunikation von den Tablets initiiert werden muss. Für den
Datenaustausch wird die Kommunikationsplattform Windows Communication
Foundation (WCF) verwendet [61] und im Folgenden detailliert aufgezeigt.
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
78
Dabei gibt es drei verschiedene Kommunikationsszenarien zwischen den Tablets
und dem Tabletop-System, welche in Kommunikation 1, Kommunikation 2 und
Kommunikation 3 beschrieben werden.
Kommunikation 1 (Tablet tapt auf Prozesselement):
Unabhängig vom aktuellen Zustand des Tablets, wird auf dem Tablet das
Prozesselement angezeigt auf das getapt wurde. In der Ansicht können die
Eigenschaften dieses Prozesselements geändert werden. Änderungen werden
sofort auf die Anwendung des Tabletop-Systems übertragen (siehe Abbil-
dung 6-16-d).
Kommunikation 2 (Tablet tapt auf freie Fläche auf den Hintergrund):
Dieses Kommunikationsszenario hängt vom Zustand des Tablets ab. Es tritt
ein, wenn auf dem Tablet Prozesselemente vorhanden sind. Diese werden auf
das Tabletop-System übertragen und relativ zum Touchpunkt des Tablets auf
dem Tabletop-System positioniert (siehe Abbildung 6-16-b).
Kommunikation 3 (Tablet selektiert mittels einer Lasso-Geste Prozessele-
mente):
Dieses Kommunikationsszenario hängt ebenfalls vom Zustand des Tablets ab.
Befinden sich auf dem Tablet bereits Prozesselemente, wird bei einer Touch-
Aktion auf den Hintergrund Kommunikation 2 ausgeführt. Sind keine Prozes-
selemente auf dem Tablet vorhanden und der Benutzer tapt auf den Hinter-
grund, kann er mittels einer Lasso-Geste Elemente selektieren, die anschlie-
ßend auf das Tablet übertragen werden.
Das Konzept von WCF basiert auf einer nachrichtenbasierten Kommunikation und
unterstützt dabei verschiedene Transportmechanismen wie z.B. HTTP oder TCP.
Dabei unterscheidet WCF zwischen Clients, die die Verbindung initiieren, und
Diensten, welche auf Anfragen der Clients warten. Die bereitgestellte Kommunika-
7.3 KOMMUNIKATION UND DATENAUSTAUSCH
79
tion wird mittels Verträgen (engl.: Contracts) geregelt. Ein Contract ist ein Inter-
face, welches die aufzurufenden Methoden, die Über- und Rückgabeparameter
definiert (siehe Programmcode 7-2). Ein Contract kann dabei mehrere Operatio-
nen unterstützen (siehe Programmcode 7-2, Zeile 5, Zeile 8, Zeile 11).
1 [ServiceContract(CallbackContract= typeof(PixelSenseToTablet))]
2 public interface TabletToPixelSense
3 {
4 [OperationContract]
5 ClickConfirmation ClickDetected
(
long timeStamp,
List<ElementBase> data,
List<SubprocessTransferHelper> spths
);
6
7 [OperationContract]
8 long Sync(long currentTicks);
9
10 [OperationContract]
11 bool Update(ElementBase updatedElement);
12 }
Programmcode 7-2: Contract TabletToPixelSense
Programmcode 7-3 erstellt, konfiguriert und startet einen WCF-Dienst (d.h. Ser-
viceHost). Der ServiceHost wird in Zeile 1 erstellt, indem der Typ der Klasse
übergeben wird, welche den Contract implementiert (d.h. TabletRequest). Der
zu verwendende Contract ist in Zeile 3 angegeben (d.h. TabletToPixelSense).
Dort ist auch angegeben, dass die Datentransport mittels TCP vonstatten geht
(Zeile 2 bzw. Zeile 3). In Zeile 4 startet der Dienst. Die Ausführung dieses Pro-
grammcodes erfolgt unmittelbar nach dem Start der Anwendung. Dabei bleibt
der Dienst während der gesamten Lebenszeit der Anwendung geöffnet.
1 fileServiceHost = new ServiceHost(
typeof(TabletRequest),
new Uri[]
{
new Uri("net.tcp://localhost")
}
);
2 NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.None);
3 fileServiceHost.AddServiceEndpoint(
typeof(PortableViewModelModel.Contracts.TabletToPixelSense),
tcpBinding,
"Seba"
);
4 fileServiceHost.Open();
Programmcode 7-3: Erstellen eines ServiceHost
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
80
Die Übergabe- und Rückgabeparameter der Methoden des Contracts, stellen da-
bei serialisierbare Datentypen dar. Als Standardserialisierungsprogramm verwen-
det WCF den Data Contract Serializer [62].
Die zu übertragenen Objekte (z.B. ElementBase) zeichnen sich dadurch aus,
dass sie eine Graphstruktur aufweisen. Dies bedeutet, dass jedes Objekt mehrere
Nachfolger, aber auch Vorgänger haben kann. Daher muss bei der Übertragung
darauf geachtet werden, dass die Objekte mittels Referenzen serialisiert werden,
um Zyklen zu vermeiden. Um Objekte mittels dem Data Contract Serializer zu de-
/serialisieren, werden die Klassenvariablen mit einem DataContractAttribute
versehen, um anzugeben, ob und wie eine Klassenvariable serialisiert werden soll.
Abbildung 7-4 zeigt ein Sequenzdiagramm, um die Vorbereitung und Durchfüh-
rung der Kommunikation zwischen dem Tabletop-System und den Tablets zu
veranschaulichen (siehe Kommunikation 1). Auf der linken (Tabletop-
Implementierung) und rechten Seite (Tablet-Implementierung) sind jeweils die
drei Kommunikationspartner der beiden Anwendungen dargestellt, welche jeweils
einen eigenen Thread bilden.
Abbildung 7-4: UML-Sequenzdiagramm – Tablet tapt auf Prozesselement des Tabletops
7.3 KOMMUNIKATION UND DATENAUSTAUSCH
81
Beim dem Start der PixelSenseView-Anwendung (linke Seite), wird neben dem UI-
Thread, der TabletTouchManager-Thread gestartet. Die Aufgabe des Tablet-
TouchManager ist, alle TouchDown-Events der Benutzer, zusammen mit dem be-
rührten Element und dem aktuellen Timecode, global zu speichern. Aufgabe des
UI-Threads ist es, die Benutzeroberfläche darzustellen. Nach dem Programmstart,
startet der UI-Thread den ServiceHost-Thread (siehe Programmcode 7-3).
Auf dem Tablet (siehe Abbildung 7-4, rechte Seite) wird beim Start der Windows-
Store-App der UI-Thread erzeugt, welcher für die Darstellung der Benutzerober-
fläche auf dem Tablet zuständig ist. Der UI-Thread erzeugt den TabletTouch-
Thread sowie den Communication-Thread, welcher für die asynchrone Kommuni-
kation mit dem Tabletop-System zuständig ist und nutzt dessen ServiceHost-
Schnittstelle. Nach der Erstellung schickt der Communication-Thread eine Sync-
Anfrage an das Tabletop-System, um die Uhrzeit zu synchronizieren.
Aufgabe des TabletTouch-Thread ist es, die drei Beschleunigungssensoren des
Tablets zu überwachen. Führt der Benutzer eine Tablet-Touch-Aktion aus (siehe
Abbildung 7-4), befindet sich das Tablet in einer Position, welche eine solche Ak-
tion zulässt. Zusätzlich zeigt der Beschleunigungssensor der Y-Dimension einen
kurzen und starken Ausschlag an. Daraus interpretiert der TabletTouch-Thread,
dass eine Tablet-Touch-Aktion ausgeführt wurde und folglich wird der UI-Thread
benachrichtigt. Dieser delegiert die Aktion an den Communication-Thread, wel-
cher die ClickDetected-Methode des ServiceHosts aufruft.
Der Tap des Benutzers mit dem Tablet (siehe Abbildung 7-4, Linie „Tablet-Touch“)
wurde vom Tabletop-System als TouchDownEvent registriert und folglich vom
TabletTouchManager-Thread zusammen mit dem aktuellen Timecode gespei-
chert. Wird nun die ClickDetected-Methode des ServiceHost-Threads aufgeru-
fen, leitet dieser die Anfrage an die isTabletTouch-Methode des Table-
TouchManger-Threads weiter. Als Übergabeparameter wird der synchronisierte
Zeitpunkt mitgeliefert, an welchem das Tablet die Tablet-Touch-Aktion erkannte.
Wenn der TableTouchManger an einem ähnlichen Zeitpunkt ebenfalls einen
Touch registriert hat, gibt die Methode das VM-Objekt des Interaktionselements,
von dem das TouchDownEvent ausgelöst wurde, an den ServiceHost zurück.
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
82
Dieser überträgt das VM-Objekt zum aufrufenden Tablet und kann vom UI-
Thread dargestellt werden.
Das in Kommunikation 3 beschriebene Szenario hebt sich durch die zeitliche Ver-
zögerung des Rückgabewertes deutlich von den anderen Szenarien ab. Löst der
Benutzer eine Tablet-Touch-Aktion aus, tauschen beide Geräte Informationen
über das Netzwerk aus. Anschließend selektiert der Benutzer mit einer Lasso-
Geste die gewünschten Prozesselemente. Dies kann einige Zeit in Anspruch neh-
men und unter Umständen zu lange für den Rückruf dauern, da nach einer gewis-
sen Dauer, eine Timeout-Exception geworfen wird. Hebt der Benutzer nun das
Tablet vom Tabletop-System (d.h.TouchUpEvent), werden die selektierten Pro-
zesselemente vom Tabletop-System zum Tablet übertragen. Somit muss der Tab-
letop eine Verbinung hin zum Tablet initiieren. Dies ist denkbar, wenn er sich zu-
vor die IP-Adresse des Tablets merkt. Durch die Verwendung eines WinRT-Tablets
ist dies jedoch nicht möglich, da eine Windows-Store-App aus Sicherheitsgrün-
den nicht als „Server“ (d.h. ServiceHost in WCF) fungieren kann. Um das beschrie-
bene Interaktionsszenario dennoch anbieten zu können, werden Callback-
Operationen von WCF verwendet. WCF unterstützt dabei die Funktion, seine Cli-
ents kontaktieren zu können. Während einer Callback-Operation werden die Rol-
len getauscht: Ein Dienst fungiert dabei als Client und der Client wird zum Dienst
[63]. Die Callback-Operation wird als eigener Contract definiert und aus dem ers-
ten Contract referenziert (siehe Programmcode 7-2, Zeile 1). Durch Verwendung
der Callback-Operationen kann der Rückruf der Methode belieb lang nach dem
Aufruf dieser stattfinden, um die selektierten Prozesselemente zum Tablet zu
transportieren.
Dieses Kapitel zeigt, wie Skizzeneingaben der Benutzer verarbeitet werden, wenn
diese auf den Hintergrund der Anwendung Eingaben tätigen. Skizzeneingaben
werden von Process Touch interpretiert, wenn der Benutzer den Finger hebt und
dem System somit signalisiert, dass die Eingabe abgeschlossen ist. Die Skizzen-
eingabe (siehe Abbildung 7-5-a) ist jedoch nicht eindeutig, da der Benutzer auch
frei mittels einer Lasso-Geste mehrere Prozesselemente markieren kann (siehe
Abbildung 7-5-b). Die Unterscheidung der Aktionen, die Erkennung der Skizzen
7.4 SKIZZENBASIERTE BENUTZEREINGABE
83
und die Zuordnung von Prozesselementen zu einem Selektionspfad, werden in
diesem Kapitel aufgezeigt.
a) Skizzeneingabe
b) Selektion mittels Lasso-Geste
Abbildung 7-5: Dualität der Skizzeneingabe
Da es sich um eine Multi-Touch-Anwendung handelt, können mehrere Eingaben
und folglich mehrere Skizzeneingaben zur selben Zeit vorhanden sein. Bei jedem
TouchMoveEvent wird über die mitgesendete TouchID der jeweiligen Berüh-
rung ein neuer Touch-Punkt der Auflistung hinzugefügt. Zusätzlich wird für alle
Prozesselemente die sich auf der Benutzeroberfläche befinden, überprüft, ob sie
sich innerhalb des gezeichneten Pfades befinden. Dieses Kriterium wir für die Un-
terscheidung der mehrdeutigen Eingabe verwendet. Liegt ein Prozesselement
innerhalb des Pfades, handelt es sich bei der Eingabe folglich um eine Selektion
und die Fläche des Pfades wird gefüllt, um dem Benutzer mitzuteilen, dass das
System eine Selektion erkannt hat. Sonst wird versucht die Eingabe als Skizze zu
interpretieren.
Je langsamer der Benutzer die Eingabe tätigt, desto mehr Touch-Punkt werden
vom Tabletop-System detektiert und das daraus resultierende Polygon wird
durch viele Punkte repräsentiert. Da die Algorithmen als Laufzeitkomplexität sich
auf die Anzahl der Punkte beziehen, ist es ratsam diese zu minimieren. Zusätzlich
werden die verwendeten Algorithmen dadurch robuster und liefern bessere Er-
gebnisse.
7.4.1 VEREINFACHUNG EINES POLYGONS
Um unnötige Punkte entlang eines Pfades zu minimieren, wird die Eigenschaft
ausgenutzt, dass Punkte bereits in der richtigen Reihenfolge gespeichert sind.
Folgendes Verfahren wird angewendet um Punkte zu eliminieren [64]:
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
84
Seien Punkt A, B, C aufeinanderfolgend. Der Betrag des Kreuzprodukts | 𝐴𝐵
×
𝐴𝐶
| gibt den Flächeninhalt, des von den Punkten A, B, C aufgespannten Paralle-
logramms, an. Liegt B auf der Linie zwischen A und C ist der Flächeninhalt 0 und
Punkt B kann folglich gelöscht werden. Um den Pfad annähernd zu repräsentieren
wird der Flächeninhalt nicht mit 0 verglichen, sondern Punkt B wird gelöscht,
wenn der Flächeninhalt kleiner als die Fehlerkonstante EPS ist. Dadurch werden
Geraden geglättet, jedoch bleiben Eckpunkte erhalten. Als Algorithmus kann das
Verfahren, wie in Programmcode 7-4 gezeigt, formuliert werden.
1 void Simplify (List<Point> Path)
2 {
3 //Declaration
4 Point A, B, C;
5 double Xab, Yab, Xac, Yac, cross;
6 double EPS = 20;
7
8 for(int i = 0; i < Path.Count - 2; i++)
9 {
10 //Get the points
11 A = Path[i];
12 B = Path[i+1];
13 C = Path[i+2];
14
15 //Calculate X and Y of the vectors AB and AC
16 Xab = B.X - A.X;
17 Yab = B.Y - A.Y;
18 Xac = C.X - A.X;
19 Yab = C.Y - A.Y;
20
21 //Calculate the cross product
22 cross = Math.Abs(Yab * Xac - Xab * Yac);
23 if(cross < EPS) Path.remove(B);
24 }
25 }
Programmcode 7-4: Vereinfachung eines Polygons
In Abbildung 7-6 ist das Ergebnis des Verfahrens exemplarisch aufgeführt. Abbil-
dung 7-6-a zeigt die vom Benutzer skizzierte Form, wobei die einzelnen Eingabe-
punkte eingezeichnet sind. Dabei wird jeder mit seinem Nachfolger durch eine
gerade Linie verbunden. In Abbildung 7-6-b zeigt den Benutzereingabe, nachdem
der Pfad vereinfacht wurde, indem unnötige Punkte gelöscht wurden. Dabei ist zu
erkennen, dass trotz deutlich weniger Punkte, die Form der Skizzeneingabe erhal-
ten bleibt.
7.4 SKIZZENBASIERTE BENUTZEREINGABE
85
a) vor der Vereinfachung
b) nach der Vereinfachung
Abbildung 7-6: Vereinfachung eines Polygons
7.4.2 SYMBOLERKENNUNG
Die Erkennung der Symbole ist essentiell für eine skizzenbasierte Eingabe. Dafür
gibt es verschiedene Techniken, um Symbole zu erkennen [65]. Der $1-
Recognizer [66] wurde durch seine einfache Implementierung und hohe Genauig-
keit populär. Aus diesem und im Folgenden aufgeführten Gründen wird die Dis-
kussion mit diesem Verfahren geführt.
Der $1-Recognizer erkennt Single-Stroke-Symbole, welche aus einem einzelnen
Pfad bestehen. Der Vorteil von Single-Stroke-Symbolen besteht darin, dass die
Komplexität der Symbole geringer ist als bei Multi-Stroke-Gesten, welche aus
mehreren Strichen zusammengesetzt werden. Vor allem in einem Multi-User-
System es schwer ist, mehrere getrennte Eingaben einer einzelnen Geste zuzu-
ordnen. Dies begründet sich aus der Tatsache, dass mehrere Benutzer gleichzeitig
Skizzieren können.
Um ein bestimmtes Symbol zu erkennen, werden vom $1-Recognizer die Einga-
ben vereinfacht, skaliert und rotiert und als unbekannte Vorlage gespeichert. Die
daraus folgende unbekannte Vorlage wird mit zuvor gespeicherten Vorlagen ver-
glichen. Dies geschieht, indem die Distanz der korrespondierenden Punkte be-
rechnet wird. Die Genauigkeit des Verfahrens hängt daher von der Anzahl der
Vorlagen pro Geste und der Anzahl an Gesten ab. Je mehr Vorlagen geladen wer-
den, desto höher ist die Genauigkeit, aber auch die Laufzeit des Algorithmus [66].
Durch die Skalierung der Eingaben ist es nicht möglich Seitenverhältnisse von
Formen zu bestimmen. Folglich können Rechtecke nicht von Quadraten, und El-
lipsen nicht von Kreisen unterschieden werden. Weiter ist es nicht möglich eindi-
mensionale Symbole (z.B. Striche) zu erkennen [66]. Es sollen jedoch die Benut-
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
86
zereingaben aus Kapitel 5.2 (Kreis, Rechteck, Quadrat, Strich) erkannt werden.
Dabei müssen Striche erkannt und Rechtecke von Quadraten unterschieden wer-
den.
Durch die abgeschlossene und überschaubare Menge der angebotenen Skizzen-
eingaben, kann ein eigenes Verfahren verwendet werden. Der Vorteil hierbei ist,
dass Gesten mittels Deskriptoren beschrieben werden können. Dies erhöht die
Robustheit und Performanz des Verfahrens.
Ausgehend von dem vereinfachten Polygon wird, ein Orientierungshistogramm
berechnet. Dies ist ein Array der Länge 180, welches die Winkel von 0 bis 179 re-
präsentiert. Dazu wird der Winkel zwischen zwei aufeinanderfolgenden Punkten
des Polygons berechnet, welcher die Stelle im Array repräsentiert. Der Abstand
der beiden Punkte wird auf den Wert der Stelle, des korrespondierenden Winkels,
addiert.
Die Stelle des maximalen Betrags im Orientierungshistogramm repräsentiert die
Hauptorientierung. Um jedoch mehr Toleranz und die gesamte Orientierung zu
erhalten, wird ein normalisierter Boxfilter der Breite 9 mit den Werten
[1, 1, 2, 3, 5, 3, 2, 1, 1] × 1
19
verwendet. Dieser berechnet eine gewichtete Summe einer bestimmten Umge-
bung. Durch die gewählte Gewichtung, wird das Zentrum, im Vergleich zu den
Rändern, stärker berücksichtigt. Die Summe der Werte des Boxfilters ergibt genau
1. Dies wird als normalisiert bezeichnet. Folglich wird der gewichtete Mittelwert
einer bestimmten Umgebung gebildet. Abbildung 7-7 zeigt beispielhalft die Ver-
wendung eines Boxfilters. Das Maximum der Ausgangsmatrix und der Ergebnis-
matrix sind hervorgehoben.
Durch die Verwendung eines normalisierten Boxfilters wird mehr Toleranz ge-
schaffen und eine Region, im Vergleich zu einer einzelnen Orientierung, wird be-
trachtet.
7.4 SKIZZENBASIERTE BENUTZEREINGABE
87
Abbildung 7-7: Normalisierter Boxfilter ohne Randbehandlung
Abbildung 7-8 zeigt zwei Eingaben mit den dazugehörigen Orientierungshisto-
grammen.
Abbildung 7-8: Orientierungshistogramme samt korrespondierender Skizzeneingabe
Anschließend wird das Polygon um den Betrag der Hauptorientierung, welche
mittels dem Boxfilter berechnet wurde, gedreht und die Höhe (d.h. BBHeight) und
Breite (d.h. BBWidth) der umgebenden Bounding Box (d.h. das kleinste umschließen-
de Rechteck) wird berechnet. BBHeight und BBWidth werden als Merkmale verwendet
(siehe Abbildung 7-9).
Abbildung 7-9: Drehen des Polygons und Berechnung der Bounding Box
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
88
Als zusätzliches Merkmal für die Interpretation der Benutzereingabe eignet sich
die Pfadlänge. Diese ergibt sich durch die Summierung aller Werte im Orientie-
rungshistogramm. Ein weiteres entscheidendes Merkmal für die Interpretation der
Benutzereingabe ist die Pfadöffnung. Diese ergibt sich aus dem Abstand zwischen
dem ersten und dem letzten Punkt des Polygons.
Anhand des Orientierungshistogramms in Kombination mit den Werten BBHeight,
BBWidth, der Pfadlänge und der Pfadöffnung lassen sich die in Tabelle 7-1 gezeig-
ten Gesten unterscheiden.
Geste
Beschreibung
Kreis
Befindet sich der maximale Wert des Orientierungshistogramms unter-
halb der Schwelle Pfadlänge × 0,4 handelt es sich nicht um ein Rechteck.
Folgende Kriterien überprüfen dabei, ob es sich um einen Kreis handelt
und ob anschließend die Eingabe als Event interpretiert werden kann:
BBHeight ≈ BBWidth
Pfadlänge < 𝜋 ∙ (BBHeight + BBWidth)
Pfadöffnung < 𝑀𝑖𝑛(BBHeight, BBWidth)
Strich
Befindet sich der maximale Wert des Orientierungshistogramms über der
Schwelle Pfadlänge × 0,4 und gilt zusätzlich die Forderung, dass
Pfadöffnung ≈ Pfadlänge
gilt, so ist die Eingabe als Strich (d.h. Löschgeste) zu interpretiert.
Rechteck
Befindet sich der maximale Wert des Orientierungshistogramms über der
Schwelle Pfadlänge × 0,4 und gilt zusätzlich die Forderung, dass
BBHeight + BBWidth ≈ Pfadlänge / 2 - Pfadöffnung
gilt, so ist die Eingabe ein Rechteck. Dies ist ein Zwischenzustand, von
dem ausgehend folgende drei Gesten unterschieden werden:
Gateway
Ist die Eingabe ein Rechteck, und zusätzlich gilt die Eigenschaft
BBHeight ≈ BBWidth
handelt es sich hierbei um ein Quadrat (d.h. Gateway).
7.4 SKIZZENBASIERTE BENUTZEREINGABE
89
Anmerkung
Ist die Eingabe ein Rechteck, und zusätzlich gilt die Eigenschaft
Pfadöffnung ≈ 𝑀𝑎𝑥(BBHeight, BBWidth)
handelt es sich um eine eckige Klammer (d.h. Anmerkung).
Aktivität
Ist die Eingabe ein Rechteck, und zusätzlich gilt die Eigenschaft
Pfadöffnung < 𝑀𝑖𝑛(BBHeight, BBWidth) / 2
handelt es sich um ein geschlossenes Rechteck (d.h. Aktivität).
Tabelle 7-1: Erkennung von Gesten
7.4.3 MULTISELEKTION VON PROZESSELEMENTEN
Wird eine Gesteneingabe nicht dazu verwendet, Prozessemente zu erstellen oder
zu löschen, sollen die Prozesselemente innerhalb des Eingabepfades, selektiert
werden. Um zu erkennen, ob sich ein Prozesselement innerhalb eines Eingabe-
pfades befindet, wird das Jordan Curve Theorem in Anlehnung an Frankins [67]
Implementierung verwendet. Dieses besagt, dass sich ein Punkt innerhalb eines
Polygons befindet, wenn jeder aus dem Punkt ausgehende Strahl die Ränder des
Polygons ungerade oft schneidet (siehe Abbildung 7-10). Somit liefert das Verfah-
ren auch bei nicht rein konvexen Polygonen eine korrekte Antwort für Regionen,
die zwar von einem Polygon teils umschlossen sind, jedoch nicht innerhalb des
Polygons sind. Die Komplexität dieses Algorithmus bei einem Polygon mit n
Punkten ist O(n).
Abbildung 7-10: Jordan Curve Theorem
Als Optimierung wird vor der Berechnung der Schnittpunkte überprüft, ob sich
das Prozesselement innerhalb der Bounding Box des Polygons befindet. Die
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
90
Bounding Box eines Polygons mit n Punkten kann mit einer Komplexität von O(n)
berechnet werden. Jedoch muss diese nur bei einer Änderung der Punkte be-
rechnet werden und nicht für jedes Prozesselement neu. Die Überprüfung selbst
braucht wenige Abfragen, mit einer Komplexität O(1). Somit stellt diese Vorge-
hensweise eine Optimierung dar.
Für das Layouting der Prozesselemente wird ein Force-Directed-Graph-
Algorithmus verwendet (vgl. Kapitel 5.5), welcher ein physikalisches System Simu-
liert. Auf jeden Knoten (d.h. Prozesselement) wirkt eine Kraft F (siehe Abbildung
7-11), welche sich aus verschiedenen Kräften zusammensetzt. Übersteigt der Be-
trag der Kraft |F| einen bestimmten Schwellwert (Haftreibung), bewegt sich der
Knoten mit einer bestimmten Geschwindigkeit in Richtung der Kraft.
Abbildung 7-11: Kräfte einzelner Knoten
Zum einen wirkt auf jeden Knoten, der mit einem anderen Knoten verbunden ist
eine Anziehung in Richtung des verbunden Knotens mit dem Betrag
|FAttraction| = ATTRACTION
∗ (
Proximity – SPRINGLENGTH )
wobei ATTRACTION und SPRINGLENGTH Konstanten sind. Proximity ist der Ab-
stand zwischen den zwei Knoten. Dies kann mit einer Feder die zwischen den bei-
den Knoten gespannt ist, veranschaulicht werden (siehe blaue Federn in Abbil-
dung 7-11). Die Anziehungskraft muss für jeden Knoten nur mit den verbundenen
Knoten berechnet werden.
Zum anderen Stoßen sich Knoten, ähnlich gleich gepolten Magneten, gegenseitig
ab. Die Kraft kann mittels dem Gesetz von Coulomb berechnet werden [68]:
7.6 ZUSAMMENFASSUNG
91
|FRepulsion| = - REPULSION / Proximity 2
REPULSION stellt hierbei eine Konstante dar. Proximity ist der Abstand zwischen
den zwei Knoten. Die abstoßende Kraft muss für jeden Knoten mit allen anderen
Knoten innerhalb eines bestimmten Abstands berechnet werden.
Die resultierende Kraft wird bestimmt, indem alle auf einen Knoten wirkenden
Kräfte FAttraction und FRepulsion addiert werden.
Die auf jedes Element wirkenden Kräfte werden parallel von einem eigenen
Thread berechnet. Die Klasse LayoutManager stellt hierfür die statische Metho-
de DoLayout(MyScatterViewViewModel svvm)bereit, welche das überge-
bene VM der ScatterView layoutet. Dadurch, dass die Methode als static
deklariert wird, kann sie global aufgerufen werden. Das Layouting-Verfahren
muss immer dann angestoßen werden, wenn sich die Größe oder Position eines
Prozesselements ändert. Damit immer nur ein Layouting-Thread zur gleichen Zeit
arbeitet, wurden dieser Methode exklusive Zutrittsrechte gegeben. Das Layouting-
verfahren wird solange ausgeführt, solange sich in einem Schleifendurchlauf min-
destens ein Prozesselement bewegt.
Dieses Kapitel gibt tiefe Einblicke in den Aufbau des Proof-of-Concept-
Implementierung von Process Touch. Auf die Umsetzung wichtiger Bestandteile
wird dabei näher eingegangen.
Die verwendete Softwarearchitektur wird beschrieben, und die Einordnung der
einzelnen Klassen in das MVVM-Pattern erläutert. Auf die unterschiedliche Im-
plementierung der Benutzeroberflächen (Views) wird gesondert eingegangen.
Durch die Verwendung einer Portable Class Library kann die gesamte Geschäfts-
logik, die Skizzeneingabe und das Layouting-Verfahren auf beiden Plattformen,
ohne redundanten Code, verwendet werden.
Die Verwendung von WCF als Kommunikationsschnittstelle bietet eine einfache
und zielgerichtete Integration in das Gesamtprojekt. Die Serialisierung mittels
7 PROOF-OF-CONCEPT-IMPLEMENTIERUNG
92
dem Data Contract Serializer ermöglicht eine einfache und zuverlässige Art der
De-/Serialisierung.
93
8 EXPERIMENTELLE VALIDATION
Das in der Arbeit beschriebene Konzept des Multi-User-Software-Systems ist an-
hand von Forschungsergebnissen anderer Veröffentlichungen und Guidelines
entwickelt. Dieses Vorgehen kann als analytische Methode im Sinne der Usability-
Evaluation angesehen werden [69]. Zur Validation des Konzepts, wird dieses im
Folgenden empirisch evaluiert, indem ein Experiment mit Probanden durchge-
führt wird. Dieses Kapitel beschreibt die Definition des Experiments, den detail-
lierten Ablauf und die Auswertung der Daten.
Kapitel 8.1 gibt einen Überblick über das Experiment, stellt die Forschungsfrage
auf und leitet daraus Hypothesen ab. Um diese zu prüfen, wird ein Experiment
definiert und im Folgenden diskutiert. In Kapitel 8.2 wird die Vorbereitung und
Durchführung des Experiments betrachtet und die Validation der Daten aufge-
zeigt. Die gewonnenen Daten werden letztlich in Kapitel 8.3 analysiert und inter-
pretiert. Kapitel 8.4 wertet das Experiment qualitativ aus und zeigt mögliche Ver-
besserungen des Systems auf.
Kollaborative Geschäftsprozessmodellierung hat im Vergleich zur traditionellen
Geschäftsprozessmodellierung viele Vorteile. Wissensaustausch findet z.B. zwi-
schen den beteiligten Benutzern während der Modellierung statt, Ideen können
einfach geteilt und diskutiert werden und das Verständnis des Prozessmodells
steigt bei den Beteiligten [7, 70]. Durch Software-Unterstützung steigt zusätzlich
die Qualität von Prozessmodellen, die kollaborativ erstellt werden [8]. Diese Ar-
beit und insbesondere die Validation kommt der Frage nach, wie ein Software-
System aufgebaut sein muss, um von diesen Vorteilen profitieren zu können. Da-
zu wird ein deduktiver Usability-Test in einem kontrollierten Experiment mit
Between-Subjects-Design angewandt [69]. Im Detail bedeutet das, dass das Soft-
ware-System in verschiedenen Ausprägungen existiert und von verschiedenen
Gruppen von Probanden getestet und bewertet wird.
8 EXPERIMENTELLE VALIDATION
94
8.1.1 KONTEXTAUSWAHL UND ZIELDEFINITION
Das in dieser Arbeit erstellte Multi-User-Software-System stützt sich auf aktuelle
Erkenntnisse der HCI und kommt insbesondere der Forderung nach Tablets als
private Displays nach. Dies führt zu der Forschungsfrage:
Kann durch die Kombination von Tabletop- und Tablet-Geräten eine
bessere Prozessmodellqualität bei der kollaborativen Prozessmodellie-
rung erreicht werden?
Aus dieser Fragestellung heraus wird ein Experiment durchgeführt, um die Zufrie-
denheit der Benutzer mit Konzept, sowie die Qualität der Prozessmodelle zu mes-
sen.
Aus der Forschungsfrage heraus lässt sich folgende Zieldefinition definieren [71]:
Analysiere
das Konzept zur kollaborativen Prozessmodellierung
zum Zweck der
Evaluation
in Bezug auf die
Prozessmodellqualität bei kollaborativer Prozessmodel-
lierung mittels einer Kombination aus Tabletop-
Systemen und Tablets
aus der Sicht eines
Forschers
im Kontext
einer Multi-Object Variation Study [71] an der Universi-
tät Ulm
8.1.2 HYPOTHESENDEFINTION
Basierend auf dem Ziel des Experiments, werden im Folgenden entsprechende
Hypothesen abgeleitet. Das Experiment untersucht zum einen den Einfluss der
Verwendung von Tablets zusätzlich zum Tabletop-System auf die Qualität der
Prozessmodelle, zum anderen den Einfluss auf die Benutzerfreundlichkeit des
Systems, welche wiederum Auswirkungen auf die Qualität haben kann. Die Quali-
tät der Prozessmodelle lässt sich in die Bereiche Granularität, syntaktische, seman-
tische und empfundene Qualität aufteilen [72]. Folglich lassen sich fünf Hypothe-
sen ableiten (siehe Hypothese 1- Hypothese 5).
8.1 FORSCHUNGSFRAGE UND EXPERIMENTDEFINITION
95
Hypothese 1 (Granularität):
Erhöht die zusätzliche Verwendung eines Tablets bei kollaborativer Prozessmodellie-
rung an Tabletop-Systemen die Granularität eines Prozessmodells?
H0,1: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat keinen signifikanten Einfluss auf die Granularität des damit erstellten Prozessmo-
dells.
H1,1: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat signifikanten Einfluss auf die Granularität des damit erstellten Prozessmodells.
Hypothese 2 (Syntaktische Qualität):
Erhöht die zusätzliche Verwendung eines Tablets bei kollaborativer Prozessmodellie-
rung an Tabletop-Systemen, die syntaktische Qualität eines Prozessmodells?
H0,2: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat keinen signifikanten Einfluss auf die syntaktische Qualität des damit erstellten
Prozessmodells.
H1,2: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat signifikanten Einfluss auf die syntaktische Qualität des damit erstellten Prozess-
modells.
Hypothese 3 (Semantische Qualität):
Erhöht die zusätzliche Verwendung eines Tablets bei kollaborativer Prozessmodellie-
rung an Tabletop-Systemen, die semantische Qualität eines Prozessmodells?
H0,3: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat keinen signifikanten Einfluss auf die semantische Qualität des damit erstellten
Prozessmodells.
H1,3: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat signifikanten Einfluss auf die semantische Qualität des damit erstellten Prozess-
modells.
8 EXPERIMENTELLE VALIDATION
96
Hypothese 4 (Empfundene Qualität):
Erhöht die zusätzliche Verwendung eines Tablets bei kollaborativer Prozessmodellie-
rung an Tabletop-Systemen, die von Probanden empfundene Qualität eines Prozess-
modells?
H0,4: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat keinen signifikanten Einfluss auf die von den Probanden empfundene Qualität
des damit erstellten Prozessmodells.
H1,4: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat signifikanten Einfluss auf die von den Probanden emfpundene Qualität des damit
erstellten Prozessmodells.
Hypothese 5 (Benutzerfreundlichkeit):
Erhöht die zusätzliche Verwendung eines Tablets bei kollaborativer Prozessmodellie-
rung an Tabletop-Systemen, die Benutzerfreundlichkeit des Systems?
H0,5: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat keinen signifikanten Einfluss auf die Benutzerfreundlichkeit des in dieser Arbeit
vorgestellten Konzepts.
H1,5: Ein Tablet, welches in Kombination mit einem Tabletop-System verwendet wird,
hat signifikanten Einfluss auf die Benutzerfreundlichkeit des in dieser Arbeit vorge-
stellten Konzepts.
8.1.3 AUFBAU DES EXPERIMENTS
Dieser Abschnitt beschreibt im Detail den Aufbau des Experiments durch die De-
finition der Probanden, des Faktors, der Objekte und der Zielvariablen.
Probanden: Als Probanden dienen Studenten und Doktoranden der Informatik
und Medieninformatik. Alle Probanden haben mindestens Grundkenntnisse in der
Prozessmodellierung und in BPMN. Die Probanden nehmen freiwillig an dem Ex-
periment teil. Dabei werden sie zufällig in Zweiergruppen zusammengestellt um
gemeinschaftlich ein vorgegebenes Szenario zu modellieren.
Objekte: Die Objekte sind zum einen die von den Probanden erstellten Prozess-
modelle in BPMN, zum anderen Log-Dateien, Fragebögen und Audio- und Vide-
8.1 FORSCHUNGSFRAGE UND EXPERIMENTDEFINITION
97
oaufzeichnungen. Die Prozessmodelle und Fragebögen dienen dazu, die Hypo-
thesen zu testen. Log-Dateien, Audio- und Videoaufzeichnungen dienen, zusätz-
lich zu den Fragebögen, dazu, im Anschluss an das Experiment Verbesserungen
am Konzept erarbeiten zu können.
Um sicherzustellen, dass alle Probanden auf dem gleichen Wissensstand bezüg-
lich des zu modellierenden Szenarios sind, wird eine textuelle Szenarienbeschrei-
bung ausgeteilt. Beide Probanden, die gemeinsam das Szenario bearbeiten, be-
kommen jeweils eine Beschreibung des zu modellierenden Szenarios ausgehän-
digt, das jeweils eine unterschiedliche Perspektive auf dasselbe Szenario be-
schreibt. Dies begründet sich aus der Tatsache, dass das zu testende Konzept
explizit für die kollaborative Prozessmodellierung konzipiert wurde und Szenarien
dem typischen Aufgabenkontext der zukünftigen Endbenutzer entsprechen sollen
[69]. Daraus ergibt sich die Notwendigkeit, die Modellierung in Zweiergruppen
von Probanden durchzuführen. Der unterschiedliche Wissensstand bzw. die un-
terschiedlichen Perspektiven auf ein und denselben Geschäftsprozess, werden
durch die verschiedenen Beschreibungen des Szenarios simuliert. Im Folgenden
sind beide Perspektiven des Szenarios dargestellt (siehe Szenario 1 und Szenario
2). Die den Probanden textuell vorgelegte Szenarienbeschreibung befindet sich in
Anhang F
Szenario 1 (Perspektive des Bewerbers):
Ein Bewerber stellt seine Bewerbungsunterlagen zusammen. Hierfür schreibt er einen Lebens-
lauf sowie ein entsprechendes Anschreiben. Anschließend schickt er die Bewerbungsunterla-
gen an das Unternehmen.
Als Antwort bekommt er von dem Unternehmen entweder eine Absage oder eine Einladung
zum Vorstellungsgespräch. Im Falle einer Einladung, wird das Vorstellungsgespräch geführt.
Im Anschluss an das Vorstellungsgespräch erhält der Bewerber wiederrum eine Antwort wel-
che eine Absage, oder einen Gehaltsvorschlag enthält.
Im Falle des Gehaltsvorschlags, prüft er diesen und nimmt ihn an, wenn er seinen Vorstellun-
gen entspricht. Sonst teilt er dem Unternehmen mit, dass der Gehaltsvorschlag zu niedrig ist.
Folglich bekommt er einen neuen Vorschlag von dem Unternehmen. Dies wiederholt sich so
lange, bis der Bewerber mit dem Gehaltsvorschlag einverstanden ist, oder er eine Absage des
Unternehmens bekommt.
8 EXPERIMENTELLE VALIDATION
98
Im Falle einer Einigung bekommt er den Arbeitsvertrag zugeschickt, welchen er ausfüllt und
zurücksendet.
Szenario 2 (Perspektive des Unternehmens):
Das Unternehmen bekommt eine Bewerbung samt Bewerbungsunterlagen zugeschickt. Nach
einer Überprüfung und Bewertung der Bewerbung wird entweder eine Absage oder eine Ein-
ladung zum Vorstellungsgespräch als Antwort verschickt.
Nach dem Vorstellungsgespräch beraten sich alle Beteiligten in dem Unternehmen und das
Unternehmen schickt das entsprechende Resultat an den Bewerber. Diese Antwort kann eine
Absage oder einen Gehaltsvorschlag enthalten.
Nimmt der Bewerber diese nicht an, wird über einen höheren Gehaltsvorschlag beraten.
Nachdem das Unternehmen eine Zusage bekommen hat, verschickt es einen entsprechenden
Arbeitsvertrag.
Ist der Vertrag ausgefüllt eingegangen, wird der Bewerber eingestellt. Hierfür muss die Perso-
nalabteilung informiert werden, die Daten des Arbeitsvertrags in die Mitarbeiterdatenbank
eingetragen werden und ein Arbeitsplatz für den neuen Mitarbeiter eingerichtet werden.
Faktor: Der Faktor ist die Verwendung von Tablets als privates Interaktions-Gerät,
welches zusammen mit dem Tabletop-System zur kollaborativen Prozessmodel-
lierung verwendet wird. Die Faktorstufen sind dabei verwenden und nicht verwen-
den.
Zielvariable: Als Zielvariable betrachten wir die Angemessenheit der Verwendung
von Tablets, zusätzlich zum Tabletop-System. Da sich diese nicht direkt messen
lässt, wurde bereits definiert, dass das Konzept adäquat oder angemessen ist,
wenn eine höhere Usability des Systems und eine höhere Qualität der Prozess-
modelle gemessen werden kann.
Der Grad der Usability wird mittels zwei verschiedener Fragebögen ermittelt, die
nachfolgende vorgestellt werden.
Um eine normgerechte Messung nach DIN EN ISO 9241, welche die maßgebliche
Normenreihe für eine Gestaltung von Systemen mit hoher Usability [69] darstellt,
zu gewährleisten, wird der Fragebogen ISO-Norm 9241/10 verwendet [73] (siehe
Anhang A). Dieser bezieht sich nicht auf konkrete Funktionen oder Handlungsfol-
8.1 FORSCHUNGSFRAGE UND EXPERIMENTDEFINITION
99
gen und hat daher nur Hinweischarakter. Der Fragebogen zeigt nicht auf, wie und
an welchen Stellen Mängel behoben werden können [69]. Der Fragebogen be-
steht aus den Kategorien Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit,
Steuerbarkeit, Erwartungskonformität, Fehlertoleranz, Individualisierbarkeit und
Lernförderlichkeit, welche die Faktoren der User Perceived Quality der DIN EN ISO
9241/110 bilden [74]. Dieser Fragebogen stellt einen reflektierten Ansatz der Be-
wertung dar. Die Probanden werden dabei aufgefordert „den Beurteilungsbogen
äußerst sorgfältig“ auszufüllen. Ein Auszug aus der Kategorie Aufgabenangemes-
senheit ist in Abbildung 8-1 zu sehen.
Abbildung 8-1: Beispiel-Items des ISO-Norm 9241/10
Ergänzend hierzu wird der Fragebogen User Experience Questionnaire (UEQ) ver-
wendet (siehe Anhang B). Dieser misst den Gesamteindruck der Probanden in
Bezug auf das System [75]. Er besteht aus 26 bipolaren Adjektiven mit jeweils
einer 7-Punkt-Likert-Skala. Die Probanden werden angehalten möglichst spontan
zu antworten, damit die unmittelbare Einschätzung der Probanden zum Tragen
kommt [75]. Der UEQ besteht aus den Kategorien Attraktivität, Durchschaubarkeit,
Effizienz, Steuerbarkeit, Stimulation und Originalität. Abbildung 8-2 zeigt einen
Auszug aus dem UEQ.
8 EXPERIMENTELLE VALIDATION
100
Abbildung 8-2: Beispiel-Items des UEQ
Der Grad der Usability leitet sich aus den Medianen und Standardabweichungen
der einzelnen Kategorien beider Fragebögen ab.
Um unter anderem die Homogenität der Probandengruppe zu prüfen, wird ein
selbst erstellter Demographie-Fragebogen verwendet, welcher am Ende der Evalu-
ation von den Probanden ausgefüllt wird (siehe Anhang C). Dieser beinhaltet die
im folgenden Absatz definierten Fragen zur empfundenen Prozessmodellqualität,
Fragen bezüglich der Prozessmodellierungs-Erfahrung, persönliche Angaben (Alter,
Geschlecht, Tätigkeit, Bildung) und die Möglichkeit für Probanden, textuelles
Feedback als Freitext zu geben.
Die Qualität der Prozessmodelle wird durch die drei Dimensionen syntaktische,
semantische und empfundenen Qualität charakterisiert [72]. Die syntaktische Qua-
lität wird gemessen, indem syntaktische Fehler (z.B. syntaktische Regelverletzun-
gen) der Prozessmodellierungssprache des Prozessmodells (z.B. BPMN) gezählt
werden. Die semantische Qualität besteht aus den in Tabelle 8-1 aufgeführten
Dimensionen.
Dimension
Beschreibung
Korrektheit
Alle Elemente eines Prozessmodells sind korrekt und relevant.
Vollständigkeit
Keine relevanten Aspekte der Domäne (Szenario) fehlen.
Relevanz
Alle Elemente im Prozessmodell sind für den Prozess relevant.
Authentizität
Die gegebene Repräsentation spiegelt einen korrekten Eindruck der
Domäne wider.
Tabelle 8-1: Dimensionen semantischer Qualität
8.1 FORSCHUNGSFRAGE UND EXPERIMENTDEFINITION
101
Die vier Unterdimensionen der semantischen Qualität werden durch zwei Model-
lierungsexperten unabhängig voneinander bewertet. Jede Dimension wird auf
einer 7-Punkt-Likert-Skala einzeln bewertet und dient der Konsensbildung. Die
Skala geht von 1 (starke Ablehnung) bis 7 (starke Zustimmung).
Die empfundene Qualität basiert auf dem Grad der Zustimmung des Probanden
mit dem Prozessmodel [76]. Hierfür bewerten Probanden unabhängig voneinan-
der nach der Modellierung das Prozessmodel in den von Tabelle 8-2 gezeigten
Dimensionen.
Dimension
Beschreibung
Zustimmung
Die Zustimmung beschreibt den Grad, indem das Prozessmodell mit
dem Geschäftsprozess der realen Welt übereinstimmt.
Fehlende
Aspekte
Die Fehlenden Aspekte beschreiben signifikante Aspekte, welche in
dem Prozessmodell fehlen.
Akkurate
Beschreibung
Die Akkurate Beschreibung misst den Grad der Genauigkeit der
Übereinstimmung zwischen dem Prozessmodell und dem Ge-
schäftsprozess der realen Welt
Fehler
Die Dimension Fehler beschreibt den Grad der ernsthaften Fehler in
dem Prozessmodell.
Zufriedenheit
Die Zufriedenheit gibt den Grad der Zufriedenheit mit dem Pro-
zessmodell wieder.
Tabelle 8-2: Kategorien empfundener Qualität
Diese Kategorien werden jeweils mittels einer 5-Punkt-Likert-Skala bewertet. Die
Skala geht von 1 (starke Ablehnung) bis 5 (starke Zustimmung).
Die Granularität eines Prozessmodells wird mittels der Komplexität des Prozess-
modells gemessen (d.h. Anzahl an Aktivitäten, Kanten, Gateways und Ausfüh-
rungspfade) [77].
Für die qualitative Evaluation in Hinblick auf mögliche Verbesserungen des in
dieser Arbeit vorgestellten Systems, werden die Audio- und Videoaufzeichnungen
und die Log-Dateien herangezogen. Die Log-Dateien zeichnen das Nutzungsver-
halten der Probanden während der Prozessmodellierung auf. Die Log-Dateien
bestehen aus folgenden Typen von Einträgen:
8 EXPERIMENTELLE VALIDATION
102
1. Anzahl an Prozesselementen, welche mittels Gesten erzeugt wurden.
2. Anzahl an Prozesselementen, welche mittels Menüs erzeugt wurden.
3. Anzahl an Prozesselementen, welche mittels Gesten gelöscht wurden.
4. Anzahl an Prozesselementen, welche mittels Menüs gelöscht wurden.
5. Anzahl an Tablet-Touch-Aktionen.
6. Anzahl an Buchstaben, welche mit der Tabletop-Tastatur geschrieben wur-
den.
7. Anzahl an Buchstaben, welche mit der Tablet-Tastatur geschrieben wur-
den.
8. Anzahl an Prozesselementen auf dem Tablet, bevor diese auf den Table-
top übertragen wurden.
9. Anzahl an Prozesselementen, welche auf dem Tablet erzeugt wurden.
10. Anzahl an Prozesselementen, welche auf dem Tabletop erzeugt wurden.
11. Anzahl an Verbindungs-Aktionen von Prozesselementen, die auf dem Tab-
let durchgeführt wurden.
12. Anzahl an Verbindungs-Aktionen von Prozesselementen, die auf dem Tab-
letop durchgeführt wurden.
Da bei dem Faktorlevel nicht-verwenden einige Einträge der Log-Dateien nicht
aussagekräftig sind, können dabei nur die ersten vier Dimensionen ausgewertet
werden. Da diese Auswertung rein qualitative Ziele verfolgt, stellt dies keine Ein-
schränkung des Experiments dar.
8.1.4 GESTALTUNG DES EXPERIMENTS
Um der Forderung nachzukommen, dass alle gesammelten Daten aus einer un-
abhängigen Zufallsvariable (Faktor) kommen, verwenden wir den Ansatz der Ran-
domisierung. Hierfür werden die Zweiergruppen der Probanden abwechselnd ei-
nem Faktorlevel (d.h. verwenden bzw. nicht verwenden) zugeordnet. Die davon
abhängigen Variablen sind Modellqualität und Usability. Diese werden von der
Hypothese abgeleitet und von den Objekten repräsentiert [71]. So stellt der Auf-
bau ein randomisiertes, balanciertes Single-Faktor-Experiment dar. Dabei handelt
es sich um ein Single-Faktor-Experiment, da nur ein Faktor (d.h. der Einsatz von
Tablets) variiert. Abbildung 8-3 gibt einen Überblick über den Aufbau des Expe-
riments.
8.1 FORSCHUNGSFRAGE UND EXPERIMENTDEFINITION
103
Messtechnik und Datenerhebungsmethode: Für die Durchführung des Experiments
wird als Tabletop-System der Samsung SUR40 mit Microsoft PixelSense verwen-
det (ehemals Microsoft Surface 2 bezeichnet [78]). Für die Probanden, die dem
Faktorlevel verwenden zugeordnet werden, liegt jeweils ein Tablet bereit. Hierbei
handelt es sich um ein Microsoft Surface RT der ersten Version, welches ohne
externe Tastatur (d.h. TouchCover, bzw. TypeCover) oder Maus verwendet wird.
Auf den Geräten wird das in dieser Arbeit entwickelte System verwendet. Weiter
werden Eingaben und Aktionen vom System aufgezeichnet und in Log-Dateien
gespeichert.
Für Audio- und Videoaufzeichnungen wird eine Sony HDR-CX570 Kamera samt
Stativ verwendet. Der Ton wird mit dem internen Mikrofon aufgenommen.
8.1.5 VALIDITÄT DES EXPERIMENTS
Jedes Experiment birgt Risiken, welche das Resultat beeinflussen bzw. unbrauch-
bar machen können. Die Validität kann dabei in zwei Dimensionen unterteilt wer-
den. Die interne Validität geht der Frage nach, ob die beobachteten Effekte nur
aus der Veränderung der unabhängigen Variable abzuleiten sind. Die externe Va-
lidität betrachtet, ob die Resultate sich generalisieren bzw. auf andere Gruppen
übertragen lassen.
Interne Validität: Um sicherzustellen, dass Unterschiede in der Messung nur auf
die Veränderung der Kontrollvariable zurückzuführen ist, kontrollieren wir poten-
tielle Einflussfaktoren:
Ein Ungleichgewicht der zwei Gruppen der Faktorlevel wird durch ab-
wechselnde Zuweisung der Zweiergruppen der Probanden vermieden.
Probanden werden zufällig in Zweiergruppen eingeteilt, um einer Aus-
wahlverzerrung entgegenzuwirken.
Um einen Wissenstransfer ausschließen zu können, bearbeiten Probanden
nur ein Szenario.
Damit alle Probanden gleiches Vorwissen bzgl. des Systems mitbringen,
hat kein Proband das System im Vorfeld gesehen, ausprobiert bzw. das
Konzept gehört.
8 EXPERIMENTELLE VALIDATION
104
Durch die Vorlage des Szenarios (d.h. Domänen-Wissen) wird bei allen
Probanden bzw. Teams das gleiche Vorwissen bzgl. der Domäne sicherge-
stellt.
Aufgrund der starken Marktdurchdringung von Smartphones und Tablets
kann ein unterschiedlicher Erfahrungsstand mit Touch-Systemen vernach-
lässigt werden. Weiter sind alle Probanden Studenen bzw. Doktoranden
der Informatik und bringen Standesgemäß eine gewisse Technikaffinität
mit. Somit kann davon ausgegangen werden, dass alle Probanden ausrei-
chend Erfahrung mit Touch-Systemen mitbringen.
Mögliche unterschiedliche Erfahrung mit Prozessmodellierung wird
dadurch ausgeschlossen, dass nur Probanden am Experiment teilnehmen,
die mindestens Grundkenntnisse in der Prozessmodellierung haben.
Um negative Einflüsse aufgrund von Müdigkeit oder Hunger auszuschlie-
ßen, wird das Experiment zu einer Tageszeit durchgeführt, wo dies ausge-
schlossen werden kann.
Das Experiment wird in einem ruhigen, abgeschlossenen Raum durchge-
führt, um Ablenkungen der Probanden ausschließen zu können.
Die erwartete Dauer des Experiments pro Gruppe ist ca. 40 min. Dies
schließt negative Auswirkungen aufgrund eines Mangels an Motivation
oder Konzentration aus.
Alle Probanden nehmen freiwillig an dem Experiment teil.
Externe Validität: Alle Probanden haben einen akademischen Hintergrund, was die
Generalisierbarkeit einschränkt. Jedoch weisen alle Probanden grundlegende
Kenntnisse in der Prozessmodellierung auf. Da sich Modelle von Studenten und
Modellierungsexperten nicht unterscheiden lassen [79], können die Probanden
dieses Experiments als Stellvertreter für Modellierungsexperten angesehen wer-
den, welche ein grundlegendes Training in der Prozessmodellierung bekommen
haben. Die verwendete Hard-/Software und die Implementierung des Konzepts
kann die Generalisierbarkeit einschränken.
Jedoch wurde durch das Experiment-Design festgelegt, dass beide Gruppen mit
demselben Tabletop-System arbeiten und es nur einen Faktor (d.h. den Einsatz
von Tablets) gibt. Somit ist es wichtig auf diesen Faktor zu achten. Bei dem Micro-
8.2 ABLAUF DES EXPERIMENTS
105
soft Surface RT handelt es sich um ein leichtes, gut verarbeitetes Tablet. Durch
den Verzicht auf externe Tastaturen, welche für dieses Tablet verfügbar sind, kann
die Hardware als neutral betrachtet werden, da keine besonders negativen oder
positiven Eigenarten vorhanden sind.
Dieser Abschnitt basiert auf der Experimentdefinition (siehe Kapitel 8.1) und be-
schreibt detailliert den vollständigen Ablauf des Experiments.
8.2.1 VORBEREITUNG
Probanden werden für das Experiment eingeladen. Die Probanden werden nicht
über die zu untersuchenden Aspekte des Experiments informiert, wissen jedoch,
dass das Experiment Teil einer Masterarbeit ist. Allen Probanden wird Anonymität
gewährleistet. Vor dem eigentlichen Experiment wird mittels einer Vorstudie ge-
prüft, dass die Hard- und Software zuverlässig läuft, alle technischen Geräte (Ka-
mera, Mikrofon) funktionieren und die Anweisungen und Fragen für die Proban-
den verständlich sind.
8.2.2 DURCHFÜHRUNG
Das Experiment wird in einem ruhigen Raum der für die Zeit des Experiments re-
serviert wird, an der Universität Ulm durchgeführt. Es kann immer nur eine Zwei-
ergruppe von Probanden gleichzeitig am Experiment teilnehmen. Das Experiment
wird innerhalb von zwei Wochen durchgeführt, wobei jede Sitzung zwischen 60
und 80 Minuten dauert und folgendermaßen abläuft:
Dem Versuchsleiter liegt ein Leitfaden vor (siehe Anhang D), anhand diesem er
das Experiment leitet. So gibt er zu Beginn eine kurze Einführung in das System
und teilt den Probanden die Szenarienbeschreibugn aus. Nachdem diese von den
beiden Probanden unabhängig gelesen wurde, bearbeiten diese kollaborativ das
Szenario mithilfe des Tabletops und ja nach Faktorlevel auch mithilfe des Tablets.
Nach Beendigung des Szenarios teilt der Versuchsleiter die Fragebögen aus. Um
die Emotionen und spontanen Gedanken der Probanden festzuhalten füllen die
Probanden erst den UEQ und anschließend den ISO-Norm 9241/10 aus. Zuletzt
8 EXPERIMENTELLE VALIDATION
106
füllen die Probanden den Demographie-Fragebogen aus. Abbildung 8-3 stellt
den Ablauf graphisch dar.
Während der ganzen Zeit werden Audio- und Videoaufzeichnungen erhoben und
ausgewählte Aktionen (siehe Kapitel 8.1.4) werden vom System während der Be-
arbeitung der Szenarien in einer Log-Datei gespeichert.
Am Ende haben Probanden die Möglichkeit auf dem Fragebogen Feedback zu
hinterlassen.
Abbildung 8-3: Ablauf des Experiments
8.3 DATENANALYSE UND INTERPRETATION
107
8.2.3 VALIDATION DER DATEN
Insgesamt nahmen 20 Probanden an dem Experiment teil. Alle Durchgänge liefen
den Vorstellungen nach ab und somit konnten die Daten aller Probanden ver-
wendet werden. 10 Probanden sind Studenten und 10 Probanden Doktoranden.
Von den 20 Probanden sind 3 weiblich und 17 männlich. Die Probanden wurden
nach ihrer Erfahrung (Analysieren, Modellieren, Auskennen, System Beherrschen)
mit BPMN gefragt, da dies eine Voraussetzung für die Teilnahme an dem Experi-
ment ist. Auf einer Likert-Skala von 1 bis 7 beträgt der Median der Mediane 5,5
mit einer Standardabweichung von 1,6. In den letzten 12 Monaten modellierten
die Probanden durchschnittlich 25,6 Modelle und haben im Schnitt 3,5 Jahre Er-
fahrung mit BPMN. Folglich erfüllen alle Probanden die Voraussetzungen und
passen in die gesuchte Probandengruppe. Kritisch zu betrachten sind die α-Fehler
der Unterschiede der Probanden, welche einen anderen Faktorlevel zugewiesen
bekamen. Diese entstanden durch die zufällige Zuweisung der Probanden in einer
der beiden Gruppen. So ist die Gruppe mit dem Faktorlevel mit Tablet etwas Er-
fahrener (Median 0,75 Punkte) und haben längere Erfahrung mit BPMN (durch-
schnittlich 2,1 Jahre).
In diesem Abschnitt werden die gesammelten Daten ausgewertet und interpre-
tiert (siehe Kapitel 8.3.1) und die Hypothesen getestet (siehe Kapitel 8.3.2). Die
von den Probanden erstellten Prozessmodelle sind in Anhang G abgebildet, die
Rohdaten des Experiments sind in Anhang H zu finden.
8.3.1 DATENANALYSE UND BESCHREIBENDE STATISTIK
Abbildung 8-4 zeigt Box Plots (Median, Minimum und Maximum, als auch das
erste und dritte Quartil) der sieben Kategorien des ISO-Norm 9241/10 Fragebo-
gens, welche die Benutzerfreundlichkeit repräsentieren. Hierbei sind die beiden
Faktorlevel mit Tablet und ohne Tablet gegenübergestellt.
8 EXPERIMENTELLE VALIDATION
108
Abbildung 8-4: Box Plots der Kategorien des ISO-Norm 9241/10 Fragebogens
Die Kategorien des ISO-Norm 9241/10 Fragebogens werden im Median um 0,5
Punkte (auf einer Likert-Skala von 1 bis 7) besser Bewertet, wenn der Faktorlevel
mit Tablets angewendet wird (siehe Abbildung 8-4). Im Besonderen ist die Kate-
gorie Steuerbarkeit um 2 Punkte besser, die Kategorie Selbstbeschreibungsfähig-
keit um 1,5 Punkte und die Kategorie Fehlertolleranz um 1 Punkt besser bewertet,
wenn die Probanden zusätzlich mit Tablets arbeiteten.
Abbildung 8-5 zeigt die Box Plots (Median, Minimum und Maximum, als auch das
erste und dritte Quartil) des UEQ. Durchschnittlich sind die einzelnen Dimensio-
nen des Fragebogens gleich gut bewertet. Unterschiede innerhalb der einzelnen
Dimensionen weisen keine deutliche Signifikanz auf. Somit kann zusammenge-
fasst werden, dass tendenziell beide Varianten des getesteten Systems eine ähnli-
che User Experience bieten.
8.3 DATENANALYSE UND INTERPRETATION
109
Abbildung 8-5: Box Plots der Dimensionen des UEQ Fragebogens
In Abbildung 8-6 sind die Werte des Loggers als Box Plots (Median, Minimum und
Maximum, als auch das erste und dritte Quartil) zusammengefasst dargestellt.
Darin ist zu sehen, dass bei dem Faktorlevel mit Tablets, im Median 28 Prozes-
selemente weniger erstellt, aber auch 25 Prozesselemente weniger gelöscht wer-
den. Somit kann davon ausgegangen werden, dass die Modellierung von Pro-
zessmodellen mit Tablets tendenziell präziser oder konzentrierter abläuft. Weiter
sind die Probanden des Faktorlevels mit Tablet im Durchschnitt über 7 Minuten
schneller als die Probanden, welche den Faktorlevel kein Tablet zugewiesen be-
kommen. Die Anzahl der getippten Buchstaben unterscheidet sich hingegen bei
unterschiedlichen Faktorlevel nicht.
Zusammenfassend kann eine Tendenz hin zur besseren Usability mit Tablets aus-
gemacht werden, jedoch ist diese nicht signifikant.
8 EXPERIMENTELLE VALIDATION
110
Abbildung 8-6: Box Plots der zusammengefassten Werte des Loggers
8.3.2 HYPOTHESENTEST
Aufgrund der geringen Probandenzahl von 20, wird an dieser Stelle auf einen
formellen Hypothesentest verzichtet, da er nicht aussagekräftig ist. Auf Tenden-
zen soll in diesem Abschnitt dennoch hingewiesen werden.
Die semantische und empfundene Qualität der Prozessmodelle, bei unterschiedli-
chen Faktorlevel, zeigen keine Unterschiede auf. Die syntaktische Qualität der
Prozessmodelle ist bei dem Faktorlevel mit Tablets durchschnittlich leicht höher
(1,6 Fehler weniger). Durch die implementierte Fehlerprüfung konnten Probanden
an vielen Stellen die Syntax jedoch auch nicht verletzen. Als Signifikant kann der
Unterschied der syntaktischen Qualität jedoch nicht angesehen werden. Die Gra-
nularität ist bei beiden Faktorlevels gleich. Die Benutzerfreundlichkeit wurde be-
reits in Kapitel 8.3.1 diskutiert und lässt auch keine deutlichen Unterschiede er-
kennen. Somit kann keine der fünf Hypothesen, welche in Kapitel 8.1.2 definiert
wurden, zurückgewiesen werden.
Durch die Beobachtung des Experiments, die Audio- und Videoaufzeichnungen
und das Feedback der Probanden, welches teils Verbal während dem Experiment
als auch textuell auf den Fragebögen gegeben wurde, kann eine qualitative Aus-
8.4 QUALITATIVE AUSWERTUNG
111
wertung des Systems erfolgen. Die folgenden Aussagen lassen sich nicht anhand
der gemessenen Daten belegen, haben ihren Ursprung jedoch in dem Experi-
ment. Die Erkenntnisse können als Verbesserungsvorschläge für zukünftige Sys-
teme verwendet werden.
8.4.1 TABLETOP-SYSTEM
Das verwendete Tabletop-System Sur40 von Samsung mit Microsofts Pixel Sense
Technologie zeigt einige Schwachstellen. So muss der Raum komplett abgedun-
kelt werden, um die Touch-Erkennung, welche mit Infrarotlicht arbeitet, vor Son-
nenlicht zu schützen. Dies schränkte in dem Experiment die Lesbarkeit der ge-
druckten Szenarien ein, welche die Probanden bekommen. Durch die geringe
Höhe von 83cm werden Benutzer beeinflusst die Haltung der Hand bei Touch-
Aktionen in einer Weise anzupassen, dass die Finger meist ausgestreckt sind und
die Erkennung der Touch-Aktion besser funktioniert. Der Nachteil der geringen
Höhe ist, dass Probanden über Rückenschmerzen klagten, teils in die Hocke gin-
gen, oder sich an einer Stuhllehne abstützten. Somit kann verallgemeinert wer-
den, dass langes Stehen und Arbeiten an einem niedrigen Tabletop-System kör-
perlich anstrengend ist.
In vielen Fällen standen Probanden sich an der langen Tischkante gegenüber
(siehe auch [30]). Da Prozessmodelle gerichtet sind, wurde der Sequenzfluss typi-
scherweise auf der linken Seite begonnen und breitete sich nach rechts hin aus.
Modellieren Benutzer kollaborativ unterschiedliche Sichten auf denselben Prozess
und stehen sich dabei gegenüber, starten die Teilbereiche auf unterschiedlichen
Seiten. Abbildung 8-7 zeigt dies exemplarisch auf. Eine Verbindung (z.B. mit Da-
tenelementen) kreuzt dabei die komplette Arbeitsfläche.
Abbildung 8-7 Modellierung an gegenüberliegenden Seiten des Tabletop-Systems
8 EXPERIMENTELLE VALIDATION
112
Da sich BPMN als Standard durchgesetzt hat, wird auch in dem System, welches
in dieser Arbeit vorgestellt wird, diese Notationssprache verwendet. Es wurde in
dem Experiment beobachtet, dass durch die freie Orientierung der Elemente,
XOR- und AND-Gateways öfters verwechselt wurden. Die Ähnlichkeit der Symbole
der beiden Prozesselemente in rotiertem Zustand wird in Abbildung 8-8 deutlich
aufgezeigt.
Abbildung 8-8 Ähnlichkeit von AND und XOR bei freier Orientierung
Daraus folgt, dass die Ähnlichkeit reduziert werden muss. Eine Lösung wird in
Verbesserung 1 aufgezeigt.
Verbesserung 1 (Ähnlichkeit der Symbolik reduzieren):
Um der Verwechslung frei rotierter Prozesselemente entgegenzuwirken,
muss die Ähnlichkeit der Symbolik von AND- und XOR-Elementen reduziert
werden. So kann die Symbolik der Logik herangezogen werden. Ein AND-
Gatter wird mit einem &-Symbol, ein OR-Gatter mit ≥1 und ein XOR-Gatter
mit =1 beschriftet.
8.4.2 GESTEN
Prozesselemente werden dreimal so häufig mit Gesten erstellt als mittels dem
Menü. Dies zeigt, dass die Gesten gut gewählt sind und Benutzer gerne mit Skiz-
zen arbeiten. Die Lösch-Geste wurde sogar zehnmal häufiger verwendet als die
Löschoperation mittels dem Menü. Dies mag auch an der Einfachheit der Lösch-
Geste liegen. Diese Einfachheit wird jedoch bei vielen Probanden zum Problem,
da sie versehentlich Prozesselemente löschen. Folglich ergibt sich die Forderung
nach einer komplexeren Gestaltung der Lösch-Geste um versehentliche
Löschoperationen zu minimieren (siehe Verbesserung 2).
8.4 QUALITATIVE AUSWERTUNG
113
Verbesserung 2 (Erhöhung der Komplexität der Lösch-Geste):
Um versehentliche Löschoperationen zu minimieren, muss die Komplexität
der Lösch-Geste erhöht werden. Verschiedene Ansätze sind dazu in der Lite-
ratur zu finden [4, 43, 32, 66].
Die Gesten für ein Gateway (Quadrat) und eine Aktivität (Rechteck) sind einigen
Probanden zu ähnlich, bzw. kann beobachtet werden, dass Rechtecke, welche fast
Quadrate waren, von Process Touch als Gateway interpretiert werden (siehe Ver-
besserung 3).
Verbesserung 3 (Anpassung der Grenzwerte für Quadrate):
Rechtecke, die von Benutzern skizziert wurden, wurden falsch kategorisiert.
Die Grenzwerte für die Unterscheidung von Rechteck und Quadrat müssen
besser angepasst werden.
8.4.3 LAYOUTING VON PROZESSMODELLEN
Das Layouting-Verfahren (siehe Kapitel 5.5) wird teils als störend empfunden. So
schreibt ein Proband, dass die automatische Anpassung […] einen Tick zu stark sei.
Einige Probanden fordern eine Funktion, welche das Prozessmodell sauber layou-
tet, oder dass die Ausrichtung der Prozesselemente auf einem Raster basiert. Die-
se Forderungen stehen allerdings im Widerspruch zu einem natürlichen Interface.
Die unterschiedliche Wahrnehmung und Wirkung auf Probanden zeigt jedoch,
dass an dieser Stelle Potential für Verbesserungen vorhanden ist (siehe Verbesse-
rung 4).
8 EXPERIMENTELLE VALIDATION
114
Verbesserung 4 (Layouting-Verfahren):
Benutzern ist es wichtig, dass das resultierende Prozessmodell übersichtlich
dargestellt wird. Der verwendete Layouting-Algorithmus erfüllt hierbei nicht
alle Bedürfnisse der Benutzer. Durch widersprüchliche Forderungen (NUI vs.
Raster; Funktion für sauberes Layout vs. Keine Globalen Aktionen
(Anforderung 15)) kann keine konkrete Verbesserung aufgezeigt werden. Je-
doch kann beobachtet werden, dass das implementierte Verfahren nicht voll
zufriedenstellend ist.
Das Layouting-Verfahren arbeitet in der Weise, dass zwei Prozesselemente die
nicht miteinander verbunden werden können, sich gegenseitig abstoßen, auch
wenn der Benutzer ein Prozesselement gerade verschiebt und auf ein anderes
legen will. Der Hintergrund hierfür ist, dass es auch bei Verschiebe-Operationen
zu keiner Verdeckung kommt. Es wird jedoch beobachtet, dass es für Probanden
nicht immer nachvollziehbar ist, wann Prozesselemente verbunden werden kön-
nen und wann nicht. Die Verdrängung von Prozesselement, mit denen Probanden
ein anderes Prozesselement verbinden wollten, führt zu Frustration. Aus dieser
Beobachtung heraus folgt Verbesserung 5.
Verbesserung 5 (Klares Feedback):
Benutzer brauchen ein klares Feedback seitens des Systems, wenn Aktionen
nicht durchführbar sind. Verschiebt ein Benutzer ein Prozesselement, darf
kein anderes von diesem abgestoßen werden, auch wenn die beiden nicht
miteinander verbunden werden können. Um den Grundsatz der Fehlerver-
meidung beizubehalten, ist es ratsam die Prozesselemente z.B. in der Farbe
Rot einzufärben wenn eine Verbindungsaktion nicht möglich ist, um dies
dem Benutzer zu verdeutlichen.
8.4.4 MENÜS
Bei der Erstellung, des in dieser Arbeit vorgestellten Systems, wird davon ausge-
gangen, dass Menüs nur geöffnet werden, wenn Benutzer sie auch verwenden
wollen. Durch eine komplexe Geste (Pinch-Geste) wird eine versehentliche Öff-
8.4 QUALITATIVE AUSWERTUNG
115
nung ausgeschlossen. Sollte dies dennoch vorkommen, schließen sich Menüs
nach einer bestimmten Zeit automatisch. Es wird jedoch beobachtet, dass Pro-
banden nicht verwendete Menüs auch selbst schließen wollen. Die automatische
Schließung der Menüs wurde weder positiv hervorgehoben, noch negativ be-
mängelt (siehe Verbesserung 6).
Verbesserung 6 (Menüs Schließen):
Benutzer wollen, zusätzlich zur automatischen Schließung der Menüs, die
Möglichkeit haben, Menüs manuell zu schließen.
Eine Möglichkeit, diese Verbesserung umzusetzen ist, einen Schließen-Button im
Hauptmenü mittig anzuordnen. Aus dem Mittelpunkt heraus entsteht das Menü
durch eine Animation und lässt sich folglich auch an dieser Stelle wieder schlie-
ßen (siehe Abbildung 8-9).
Abbildung 8-9: Verbessertes Menü mit Schließen-Button
8.4.5 VOLLSTÄNDIGKEIT VON BPMN
Die vorhandenen Prozesselemente stellen nur einen Teil der BPMN-Spezifikation
dar. Aufgrund zeitlicher Probleme werden nicht mehr Prozesselemente imple-
mentiert. Einige Probanden kritisieren vor allem das Fehlen von Messages, Pools
und Lanes.
8.4.6 IMPLEMENTIERUNGSFEHLER
Trotz vorhandener Fehler im System, musste dieses jedoch nicht neu gestartet
werden und Probanden konnten im Experiment die Arbeit zu jederzeit fortsetzen.
Da alle Probandengruppen der beiden Faktorlevel mit Tablet und ohne Tablet
dasselbe System verwendeten, haben die Fehler eventuell das Ergebnis absolut
beeinflusst, jedoch nicht relativ auf die Unterschiede der beiden Gruppen bezo-
8 EXPERIMENTELLE VALIDATION
116
gen. Tabelle 8-3 geht auf die im System vorhandenen Fehler bezüglich der Im-
plementierung ein.
Fehler
Beschreibung
Menü öffnen
Wird auf dem Tabletop ein Touch Erkannt, kann das Menü nicht
mittels einer Pinch-Geste geöffnet werden.
Fehlende Kanten
bei Subprozess
entpacken
Wird ein Subprozess ausgepackt (engl.: unwrap) wird das Start- und
Ende-Prozesselement des Subprozesses nicht automatisch mit den
Umliegenden Elementen verbunden.
Fehlende Kanten
bei Undo
Wird auf dem Tablet die Rückgängig-Funktion (engl.: undo) ver-
wendet, erscheint zwar das gelöschte Prozesselement wieder, je-
doch die Verbindungen dieses Prozesselements nicht.
Zu lange Ant-
wortzeiten
Bei komplexen Berechnungen bezüglich des Layouts, kann es vor
allem auf den Tablets zu Verzögerungen kommen.
Zurück-Taste
Wird die Zurück-Taste der Tastatur länger gedrückt, erwarten Be-
nutzer, dass Buchstaben der Reihe nach gelöscht werden. Dies wur-
de nicht implementiert.
Cursor per Tap
setzen
Bei dem Tabletop-System kann der Cursor nicht per Tap, sondern
nur mittels den Pfeiltasten der angezeigten Tastatur verändert wer-
den.
Text von Sub-
prozess automa-
tisch löschen
Wird der Text von neuen Prozesselementen geändert, löscht sich
dieser automatisch, wenn die Tastatur angezeigt wird. Bei Subpro-
zessen wurde dieses Verhalten versehentlich nicht implementiert.
Tabelle 8-3: Implementierungsfehler
Zusammenfassend lässt sich sagen, dass die Ergebnisse des Experiments darauf
hindeuten, dass es aus Anwendersicht keine Vor- bzw. Nachteile hat, zusätzlich
zum Tabletop-System ein Tablet zu verwenden. Hingegen stellt dies aus Sicht
eines Interaction-Designers eine wichtige Erkenntnis dar. So kann es vor allem bei
8.5 ZUSAMMENFASSUNG
117
größeren Benutzerzahlen hilfreich sein, wenn Benutzer ein privates Ein-
/Ausgabegerät verwenden.
Für die Weiterentwicklung des Systems ist vor allem die qualitative Auswertung
von großer Bedeutung, da, wie in Kapitel 8.4 aufgezeigt, viele Verbesserungen
abgeleitet werden konnten.
8 EXPERIMENTELLE VALIDATION
118
119
9 ZUSAMMENFASSUNG UND AUSBLICK
Das Ziel dieser Arbeit ist es, ein Tabletop-System für kollaborative Geschäftspro-
zessmodellierung zu erstellen. Dafür werden Grundlagen bzgl. BPMN, HCI und
der Wahrnehmungspsychologie erläutert.
Durch eine Literaturarbeit können bestehende Konzepte aus der HCI adressiert
und generelle Anforderungen an ein Tabletop-System identifiziert werden. An-
schließend erfolgt die Übertragung der Konzepte und Anforderungen in die Do-
mäne der Geschäftsprozessmodellierung. Dabei identifiziert diese Arbeit Anforde-
rungen, welche das System erfüllen muss.
Das Interaction-Design führt die einzelnen Anforderungen zusammen, um ein
stimmiges Feinkonzept zu erstellen. Dabei dient es als Verbindung der einzelnen
Ein- und Ausgabekonzepte, zeigt das verwendete Gestenset auf und arbeitet De-
taillösungen aus.
Das Feinkonzept wird visuell ausgearbeitet und im Anschluss als Proof-Of-
Concept-Implementierung umgesetzt. Das Konzept, bei einem Tabletop-System
zusätzlich Tablets zu verwenden, wird durch ein Experiment validiert. Die Ergeb-
nisse zeigen keine Tendenz auf, dass es im durchgeführten Szenario Vor- oder
Nachteile mit sich bringt, Tablets zu verwenden. Möglich Vorteile des privaten
Interaktionsgeräts könnten sich bei größeren Gruppen zeigen. Das Experiment
zeigt jedoch, dass es keine Nachteile hat und somit das Tablet stimmig in das
Gesamtkonzept eingebunden ist. Durch die Erhebung der Usability während des
Experiments kann zusammenfassend gesagt werden, dass das Konzept von den
Benutzern angenommen wird.
Mithilfe des Prototyps können in Zukunft noch weitere Konzepte durch Experi-
mente validiert werden. Folgende Fragestellungen können dabei adressiert wer-
den:
Erhöht die Verwendung eines Layouting-Algrithmus die Qualität der Pro-
zessmodelle?
9 ZUSAMMENFASSUNG UND AUSBLICK
120
Ab welcher Gruppengröße ist bei der kollaborativen Geschäftsprozessmo-
dellierung eine signifikant bessere Usability, durch den zusätzlichen Ein-
satz von Tablets, zu erwarten?
Hat die Verwendung einer Syntaxprüfung signifikante Auswirkungen auf
die Benutzerzufriedenheit oder die Qualität der Prozessmodelle?
Schränkt die Verwendung der Syntaxprüfung die Kreativität der Benutzer
bei der Erstellung von Prozessmodellen ein?
Soll die Syntaxprüfung, Regelverletzungen nur aufzeigen oder diese un-
terbinden?
Neben zusätzlichen Experimenten, kann das System in Zukunft weiter implemen-
tiert werden um BPMN voll zu unterstützen, und die bereits aufgezeigten Kon-
zepte im System anzubieten.
A ISO-NORM 9241/10
IX
A. ISO-NORM 9241/10
Abbildung A-1: Seite 1 des ISO-Norm 9241/10
A ISO-NORM 9241/10
X
Abbildung A-2: Seite 2 des ISO-Norm 9241/10
F 1.1
F 1.2
F 1.3
F 1.4
F 1.5
A ISO-NORM 9241/10
XI
Abbildung A-3: Seite 3 des ISO-Norm 9241/10
F 2.1
F 2.2
F 2.3
F 2.4
F 2.5
A ISO-NORM 9241/10
XII
Abbildung A-4: Seite 4 des ISO-Norm 9241/10
F 3.1
F 3.2
F 3.3
F 3.4
F 3.5
A ISO-NORM 9241/10
XIII
Abbildung A-5: Seite 5 des ISO-Norm 9241/10
F 4.1
F 4.2
F 4.3
F 4.4
F 4.5
A ISO-NORM 9241/10
XIV
Abbildung A-6: Seite 6 des ISO-Norm 9241/10
F 5.1
F 5.2
F 5.3
F 5.4
F 5.5
A ISO-NORM 9241/10
XV
Abbildung A-7: Seite 7 des ISO-Norm 9241/10
F 6.1
F 6.2
F 6.3
F 6.4
F 6.5
A ISO-NORM 9241/10
XVI
Abbildung A-8: Seite 8 des ISO-Norm 9241/10
F 7.1
F 7.2
F 7.3
F 7.4
F 7.5
B USER EXPERIENCE QUESTIONNAIRE
XVII
B. USER EXPERIENCE QUESTIONNAIRE
Abbildung B-1: Seite 1 des User Experience Questionnaires
B USER EXPERIENCE QUESTIONNAIRE
XVIII
Abbildung B-2: Seite 2 des User Experience Questionnaires
F 1
F 2
F 3
F 4
F 5
F 6
F 7
F 8
F 9
F 10
F 11
F 12
F 13
F 14
F 15
F 16
F 17
F 18
F 19
F 20
F 21
F 22
F 23
F 24
F 25
F 26
C ALLGEMEINE FRAGEN
XIX
C. ALLGEMEINE FRAGEN
Abbildung C-1: Seite 1 des Allgemeinen Fragebogens
F 1.1
F 1.2
F 1.3
F 1.4
F 1.5
F 2.1
F 2.2
F 2.3
F 2.4
C ALLGEMEINE FRAGEN
XX
Abbildung C-2: Seite 2 des Allgemeinen Fragebogens
F 2.5
F 2.6
F 3.1
F 3.2
F 3.3
F 3.4
D LEITFADEN FÜR DEN EXPERIMENTLEITER
XXI
D. LEITFADEN FÜR DEN EXPERIMENTLEITER
Abbildung D-1: Seite 1 des Leitfadens für den Experimentleiter
D LEITFADEN FÜR DEN EXPERIMENTLEITER
XXII
Abbildung D-2: Seite 2 des Leitfadens für den Experimentleiter
E EINVERSTÄNDNISERKLÄRUNG
XXIII
E. EINVERSTÄNDNISERKLÄRUNG
Abbildung E-1: Einverständniserklärung
F ANWENDUNGSSZENARIEN
XXIV
F. ANWENDUNGSSZENARIEN
Abbildung F-1: Anwendungsszenario – Bewerber
F ANWENDUNGSSZENARIEN
XXV
Abbildung F-2: Anwendungsszenario - Unternehmen
F ANWENDUNGSSZENARIEN
XXVI
G PROZESSMODELLE DER PROBANDEN
XXVII
G. PROZESSMODELLE DER PROBANDEN
Abbildung G-1: Prozessmodell der Probanden 1 und 2
G PROZESSMODELLE DER PROBANDEN
XXVIII
Abbildung G-2: Prozessmodell der Probanden 3 und 4
G PROZESSMODELLE DER PROBANDEN
XXIX
Abbildung G-3: Prozessmodell der Probanden 5 und 6
G PROZESSMODELLE DER PROBANDEN
XXX
Abbildung G-4: Prozessmodell der Probanden 7 und 8
G PROZESSMODELLE DER PROBANDEN
XXXI
Abbildung G-5: Prozessmodell der Probanden 9 und 10
G PROZESSMODELLE DER PROBANDEN
XXXII
Abbildung G-6: Prozessmodell der Probanden 11 und 12
G PROZESSMODELLE DER PROBANDEN
XXXIII
Abbildung G-7: Prozessmodell der Probanden 13 und 14
G PROZESSMODELLE DER PROBANDEN
XXXIV
Abbildung G-8: Prozessmodell der Probanden 15 und 16
G PROZESSMODELLE DER PROBANDEN
XXXV
Abbildung G-9: Prozessmodell der Probanden 17 und 18
G PROZESSMODELLE DER PROBANDEN
XXXVI
Abbildung G-10: Prozessmodell der Probanden 19 und 20
H DATEN DES EXPERIMENTS
XXXVII
H. DATEN DES EXPERIMENTS
ohne
mit
ohne
mit
ohne
mit
mit
ohne
mit
ohne
F 1.1
3
2
6
5
6
5
5
4
6
6
6
4
6
6
5
5
3
6
5
6
F 1.2
5
3
3
3
3
2
2
2
4
4
4
2
6
6
6
6
5
4
2
3
F 1.3
2
2
3
5
1
6
6
5
4
4
6
5
2
5
1
4
7
2
4
7
F 1.4
2
2
5
7
7
7
4
5
5
6
5
6
6
6
4
3
6
3
6
6
F 1.5
5
4
5
5
5
3
4
3
6
6
7
3
6
6
6
6
5
6
6
6
F 2.1
3
2
6
6
3
5
5
6
3
6
6
2
7
7
6
1
3
4
5
5
F 2.2
4
3
6
6
5
7
7
6
7
7
5
6
7
7
6
6
6
6
6
6
F 2.3
3
3
7
2
4
5
2
2
4
5
6
5
7
7
6
3
4
6
6
6
F 2.4
2
2
4
4
5
4
2
2
2
4
5
1
6
5
4
1
3
2
4
1
F 2.5
2
2
4
5
5
3
2
2
2
5
5
1
5
6
4
5
3
2
3
1
F 3.1
7
7
1
3
1
1
4
6
4
1
1
1
6
3
4
1
4
7
1
1
F 3.2
5
7
7
6
2
5
2
6
7
5
7
7
7
4
3
7
7
7
7
6
F 3.3
5
4
7
6
1
4
5
6
4
5
1
3
7
7
4
7
6
5
1
7
F 3.4
2
2
6
6
5
2
4
4
5
6
7
6
6
6
2
7
4
6
1
7
F 3.5
7
4
6
5
6
7
4
3
6
6
1
5
7
7
2
2
6
5
7
7
F 4.1
6
2
6
6
5
7
6
6
6
6
6
5
7
7
3
6
5
4
3
6
F 4.2
5
7
7
6
7
7
5
6
6
7
4
2
7
7
5
7
7
6
6
6
F 4.3
5
6
5
5
6
7
4
6
4
6
5
3
7
7
4
6
6
7
6
2
F 4.4
7
6
7
6
5
7
5
1
4
7
6
4
6
6
7
7
6
6
5
4
F 4.5
6
2
7
6
7
6
6
6
6
6
7
6
7
7
7
6
6
6
7
7
F 5.1
3
2
6
6
6
4
2
3
6
5
7
2
6
3
1
2
7
6
6
4
F 5.2
4
6
7
6
5
7
2
4
5
6
1
2
3
6
1
6
6
7
7
7
F 5.3
1
1
1
4
4
7
1
4
4
6
2
6
4
6
5
1
6
7
5
1
F 5.4
4
2
6
5
3
2
1
2
5
5
1
3
5
5
1
4
6
6
5
1
F 5.5
1
3
2
2
1
2
2
2
2
3
1
2
4
6
2
1
3
4
1
1
F 6.1
1
1
1
1
1
1
2
4
4
1
2
4
6
1
4
1
4
4
5
7
F 6.2
1
1
1
2
1
2
2
5
4
1
3
5
6
4
5
1
3
5
3
5
F 6.3
4
1
6
4
2
7
3
6
6
5
6
6
6
7
3
6
7
6
2
7
F 6.4
1
1
1
1
1
2
3
5
4
2
4
5
6
2
6
6
4
5
5
6
F 6.5
5
1
1
3
1
2
2
2
4
2
2
2
7
6
6
1
6
6
4
7
F 7.1
6
7
7
5
7
7
4
6
7
6
7
5
7
7
7
6
7
6
7
7
F 7.2
6
7
7
6
4
2
6
6
6
5
7
2
7
7
6
5
6
6
7
7
F 7.3
4
7
7
4
7
6
5
6
6
6
6
5
7
6
2
6
7
6
7
5
F 7.4
5
7
7
6
7
7
5
6
5
6
7
6
7
7
3
6
7
7
7
6
F 7.5
2
3
7
6
2
5
6
7
3
6
7
2
6
7
2
5
3
6
5
3
1≙--- 2≙-- 3≙- 4≙+/- 5≙+ 6≙++ 7≙+++
Tabelle H-1: Daten des ISO-Norm 9241/10
H DATEN DES EXPERIMENTS
XXXVIII
ohne
mit
ohne
mit
ohne
mit
mit
ohne
mit
ohne
F 1
5
3
5
5
6
6
5
5
6
6
6
6
4
5
5
3
6
6
4
6
F 2
5
4
6
6
6
6
6
7
6
6
6
5
5
5
5
4
6
7
6
6
F 3
2
2
1
2
1
4
3
4
2
1
1
1
1
1
1
2
2
2
2
4
F 4
2
3
1
2
2
2
2
2
1
2
2
3
3
4
2
4
1
2
3
1
F 5
3
4
2
3
2
2
2
4
4
2
2
3
3
3
3
4
2
3
3
3
F 6
5
5
6
6
6
5
6
6
5
6
6
6
6
6
6
5
6
4
5
5
F 7
3
6
6
6
7
6
6
6
6
6
7
6
6
6
6
5
7
5
5
5
F 8
4
2
4
4
4
5
3
3
6
4
5
4
3
2
6
3
6
4
2
4
F 9
5
2
6
5
3
2
4
6
2
3
5
3
3
6
4
6
4
5
5
4
F 10
2
2
1
2
2
4
3
5
1
1
1
1
1
1
2
3
3
3
1
4
F 11
4
3
6
5
6
6
5
3
5
4
6
4
5
4
5
2
5
4
3
5
F 12
3
4
2
3
3
2
3
4
2
3
2
2
2
4
1
5
2
2
4
2
F 13
5
4
5
4
6
6
4
7
7
5
5
4
5
5
5
4
5
5
3
7
F 14
5
4
5
5
6
6
5
6
6
5
6
6
5
4
5
4
4
5
5
6
F 15
5
6
7
7
5
5
6
5
6
7
7
7
7
7
6
5
6
6
6
4
F 16
5
4
5
5
6
5
6
4
6
6
6
5
5
5
5
4
6
5
3
6
F 17
4
5
2
4
4
3
4
7
3
2
3
3
4
6
4
6
2
4
3
2
F 18
3
3
1
2
2
2
3
2
3
2
1
2
3
3
2
3
2
3
2
3
F 19
3
5
2
3
4
3
3
3
2
2
2
3
3
6
2
5
3
3
5
3
F 20
2
3
6
3
5
5
5
3
5
6
4
4
2
3
5
2
6
4
2
5
F 21
4
6
2
3
2
3
3
7
5
5
5
4
3
4
2
3
3
3
6
4
F 22
4
2
5
5
6
6
4
5
3
6
5
5
4
3
6
3
4
2
2
5
F 23
4
5
2
3
2
3
4
2
6
4
2
4
2
3
3
2
6
4
1
5
F 24
3
4
2
3
1
3
1
4
2
3
2
2
2
3
1
3
2
3
5
2
F 25
3
4
2
2
2
2
1
3
2
2
2
2
2
4
1
5
3
3
5
2
F 26
6
6
6
7
6
5
6
4
6
7
7
6
7
6
6
5
6
5
6
4
1≙--- 2≙-- 3≙- 4≙+/- 5≙+ 6≙++ 7≙+++
Tabelle H-2: Daten des UEQ
H DATEN DES EXPERIMENTS
XXXIX
ohne
mit
ohne
mit
ohne
mit
mit
ohne
mit
ohne
F 1.1
4
4
4
4
5
4
3
1
4
4
4
2
5
5
4
4
4
6
3
4
F 1.2
3
4
1
5
5
4
4
1
2
4
4
2
5
5
4
4
5
6
2
1
F 1.3
2
4
1
4
5
4
3
2
2
4
4
1
5
4
2
4
4
6
2
4
F 1.4
3
3
4
4
5
5
3
1
4
4
4
2
5
5
5
4
5
5
5
5
F 1.5
3
3
4
4
5
5
2
1
3
3
4
3
5
5
4
4
4
5
4
4
F 2.1
1
1
6
4
5
6
6
7
6
7
7
7
5
6
1
2
5
5
6
7
F 2.2
1
2
6
3
5
5
5
6
5
7
7
7
3
6
1
2
6
5
6
7
F 2.3
2
2
7
5
5
7
6
7
6
7
7
7
5
5
3
5
7
6
6
6
F 2.4
2
2
6
5
5
5
6
4
4
3
6
6
6
6
4
5
5
6
5
3
F 2.5
0
0
6
3
4
3
4
5
5
6
8
6
4
4
2
2
3
3
1,5
1,5
F 2.6
0
0
12
4
5
15
25
30
10
100
5
50
2
10
1
30
18
20
75
100
F 3.1
34
37
27
34
26
25
30
29
28
34
30
31
25
28
25
26
24
25
25
27
F 3.2
m
m
m
m
m
m
m
m
m
m
w
m
w
m
m
m
m
m
m
w
F 3.3
mi
mi
mi
mi
s
s
i
mi
mi
mi
mi
i
s
s
s
s
s
s
s
s
F 3.4
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
H
1≙--- 2≙-- 3≙- 4≙+/- 5≙+ 6≙++ 7≙+++
:
m=männlich
w=weiblich
h=Hochschule
s=Student
i=Informatiker
mi=wissenschaftlicher Mitarbeiter
Tabelle H-3: Daten des Fragebogens Allgemeine Fragen
H DATEN DES EXPERIMENTS
XL
ohne
mit
ohne
mit
ohne
mit
mit
ohne
mit
ohne
Aktivitäten
22
24
29
23
26
25
23
20
23
16
Kanten
34
41
52
22
36
22
36
31
39
24
Gateways
11
6
13
12
7
9
7
6
9
4
Datenelemente
12
7
12
8
6
6
0
9
0
0
Events
1
8
4
2
2
7
5
4
5
4
Datenkanten
24
19
32
14
15
16
0
21
0
0
Anzahl der
Modelle
2
2
2
1
3
2
1
1
1
1
Elemente mit
Geste erzeugt
64
43
27
46
27
56
49
63
38
22
Elemente mit
Menü erzeugt
28
16
66
18
34
10
16
29
18
23
Elemente mit
Geste gelöscht
56
18
31
24
31
20
42
66
16
24
Elemente mit
Menü gelöscht
4
0
14
1
5
0
10
2
1
0
Anzahl Tablet-
Touch
0
24
0
1
0
11
13
0
4
0
Buchstaben
Tabletop
928
484
1182
791
941
769
49
880
343
897
Buchstaben
Tablet
0
512
0
139
0
317
932
0
539
0
Tabletop
erzeugt
92
59
93
47
61
28
24
92
25
45
Tablet erzeugt
0
0
0
15
0
37
41
0
31
0
Verbindung
Tabletop
102
80
119
50
79
34
24
96
29
37
Verbindung
Tablet
0
0
0
12
0
21
29
0
13
0
# vor Tablet-
Touch
0
0
0
10
0
3
10,44
0
5,25
0
Dauer
46,25
35,18
52,35
41,72
35,7
39,1
56,62
51,15
26,8
20,3
Korrektheit
7
5
6
6
5
7
7
7
7
5
Vollständigkeit
7
6
7
5
4
6
4
6
5
3
Relevanz
7
6
7
6
4
6
7
7
6
6
Authentizität
5
3
7
5
4
6
4
7
5
4
Korrektheit
6
6
7
5
5
7
7
6
6
6
Vollständigkeit
7
6
7
5
5
6
6
5
6
5
Relevanz
7
6
5
7
6
7
7
7
7
6
Authentizität
6
6
6
6
5
7
6
7
6
6
1≙--- 2≙-- 3≙- 4≙+/- 5≙+ 6≙++ 7≙+++
Tabelle H-4: Weitere Daten des Experiments
H DATEN DES EXPERIMENTS
XLI
Rollen integrieren
Drehen ist nicht so komfortabel
Rollen (Pools und Lanes) wären sehr hilfreich
Automatisches Anordnen/Ausrichten zur besseren Übersicht
System auf dem Tablet reagiert bei vielen Elementen sehr träge
Layoutalgorithmus? Wenn ja, sehr uninnovativ
Olal, slap dat table
Texteingabe: Alles löschen bei langen drücken auf "<-"
evtl. Cursor per Tap setzen
Das aufeinanderschieben der Elemente ist etwas umständlich. Schöner wäre es vielleicht mit den Finger
zwei Knoten zu verbinden
Wichtig: Löschvorgänge müssen erschwert werden & rückgängig gemacht werden können!
Das Verschieben von Elementen liefert unvorhersehbare Resultate, da sich andere Elemente teilweise
mitbewegen
Beim Drehen und Anordnen wäre ein Raster sehr hilfreich und würde deutlich die Übersichtlichkeit
erhöhen
Text von Subprozess löscht sich auf Pixelsense nicht automatisch
Wenn man auf dem Surface mehrmals Undo nach einer Übertragung macht kommen die Elemente
wieder, nicht jedoch die Verbindungen zwischen ihnen.
Beim übertragen vom Tablet an den Tisch wurde alles laut Tablet erfolgreich übertragen, aber auf dem
Tisch war nichts zu sehen.
Als ein neuer Task auf dem Tisch erstellt wurde & dessen Beschreibung geändert wurde, war das Über-
tragene wieder sichtbar und der neu erstellte Task verschwunden
Einmal ist es vorgekommen, dass ein Task unabsichtlich gelöscht wurde, als dessen Beschreibung
korrigiert wurde. Dabei wurde zu lang auf den Backspace Button gedrückt.
Ein Undo-Button auf dem Tisch wäre nützlich gewesen.
Die Bedienbarkeit des Tisches lässt zu wünschen übrig…
Usability ist noch ein Problem mit dem Tisch. Manche Sachen sind nicht so einfach.
Vielleicht statt mit dem Tablet auf den tisch gehauen, soll man "drag-and-drop" Funktionen nutzen?
alignment ist manchmal problematisch
Fehlen von bestimmen BPMN Konstrukten macht modellierung anfangs schwer (z.B. Pools & Lanes)
insgesamt interessant und motivierend
effizient durch gleichzeitiges modellieren
Sehr gute Idee, ein paar Verbesserungsvorschläge
"Usertoken o.Ä.", damit das System weiß, wo der Modellierer am Tisch steht und so neue Elemente
korrekt ausrichtet (unnötiges Drehen der Elemente verhindern)
Erweiterung um Lanes, Intermediate Events
Ich denke die automatische Anpassung des Layouts ist einen Tick zu stark
Sehr interessantes und innovatives System. Der spielerische Aspekt macht sehr viel aus.
Gefällt mir!!!
sehr cooles System - echt innovativ! Weiter so!
Pools/Lanes wären wichtige Erweiterungen für das System um besser zu Aktivieren
H DATEN DES EXPERIMENTS
XLII
nettes System, aber Bedienung an vielen Stellen noch Hakelig. Das AutoLayout und das Drehen ermög-
lichen es nicht, ein sauberes Layout zu erzeugen bzw. nur mit sehr viel Aufwand
Positiv ist, dass zwei oder mehr Leute gleichzeitig am Modell arbeiten können.
Durch Drehen und AutoLayout ist das Modell sehr unübersichtlich, was meiner Meinung nach die
Arbeit erschwert
Die exakte Semantik von BPMN mit diesen 4 Symbolen sollte man lernen, dann ist das Modell am Ende
vielleicht korrekter.
Gelöschte Transitionen können nicht immer wiederhergestellt werden. Insb. Wenn die Richtung verän-
dert wurde
neue Elemente tauchen irgendwo auf ohne, dass man dies sofort meinte
Gestenerkennung für Erzeugung der Basiselemente häufig fehlerhaft
Subprozesse können nicht erstellt werden
Hat Spaß gemacht ;-)
Tabelle H-5: Feedback der Probanden
ABKÜRZUNGSVERZEICHNIS
XLIII
ABKÜRZUNGSVERZEICHNIS
BPM
Business Process Management
BPMN
Business Process Model and Notation
CBPM
Collaborative BPM
GUI
Graphical User Interface
HCI
Human Computer Interaction
ISO
Internationale Organisation für Normung
MVC
Model View Controller (Software Design Pattern)
MVP
Model View Presenter (Software Design Pattern)
MVVM
Model View ViewModel (Software Design Pattern)
NFC
Near Field Communication
NUI
Natural User Interface
RFID
Radiofrequency Identification
UEQ
User Experience Questionnaire
WCF
Windows Communication Foundation
WinRT
Windows Runtime (Windows 8 Betriebssystem für ARM Prozesso-
ren)
WPF
Windows Presentation Foundation
HTTP
Hypertext Transfer Protocol
TCP
Transmission Control Protocol
NDH
Nicht dominante Hand
DH
Dominante Hand
XAML
Extensible Application Markup Language
ABKÜRZUNGSVERZEICHNIS
XLIV
ABBILDUNGSVERZEICHNIS
XLV
ABBILDUNGSVERZEICHNIS
Abbildung 3-1: BPMN-Kategorien .............................................................................................. 7
Abbildung 3-2: Ereignisse in BPMN ............................................................................................ 8
Abbildung 3-3: Sequenzfluss in BPMN ...................................................................................... 8
Abbildung 3-4: Nachrichtenfluss in BPMN .............................................................................. 8
Abbildung 3-5: Assoziation in BPMN ......................................................................................... 9
Abbildung 3-6: Aktivitäten in BPMN .......................................................................................... 9
Abbildung 3-7: Portale in BPMN.................................................................................................. 9
Abbildung 3-8: Datenobjekt in BPMN .................................................................................... 10
Abbildung 3-9: Pool in BPMN .................................................................................................... 10
Abbildung 3-10: Lane in BPMN ................................................................................................. 10
Abbildung 3-11: Anmerkung in BPMN ................................................................................... 10
Abbildung 3-12: Prozessmodell ................................................................................................ 11
Abbildung 3-13: Prinzip von Touch&Interact [12] ............................................................. 14
Abbildung 3-14: Aufbau von PhoneTouch [18] .................................................................. 15
Abbildung 3-15: Automatische Extraktion von Modellen aus einem Bild ................ 16
Abbildung 3-16: Skizzenbasierte Eingabe ............................................................................. 17
Abbildung 3-17: Gesetz der Nähe ............................................................................................ 17
Abbildung 3-18: Gesetz der Ähnlichkeit ................................................................................ 18
Abbildung 3-19: Gesetz der Schließung ................................................................................ 18
Abbildung 4-1: Tabletop als zentrale Instanz ...................................................................... 31
Abbildung 4-2: Alternativer Systemaufbau ........................................................................... 32
Abbildung 4-3: Skizzenbasierte Eingabe ............................................................................... 34
Abbildung 4-4: Auswahl der Prozesselemente .................................................................... 34
Abbildung 4-5: Gedrucktes und mit NFC-Tags präpariertes Prozessmodell ........... 35
Abbildung 4-6: Mobile Augmented Reality .......................................................................... 36
Abbildung 4-7: Projizierte Information................................................................................... 36
Abbildung 5-1: Hauptmenü öffnen ......................................................................................... 40
Abbildung 5-2: Arbeiten mit Verbindungspfeilen .............................................................. 40
Abbildung 5-3: Virtuelle Tastatur ............................................................................................. 41
Abbildung 5-4: Aktivität erstellen ............................................................................................. 43
ABBILDUNGSVERZEICHNIS
XLVI
Abbildung 5-5: Gateway erstellen ............................................................................................ 43
Abbildung 5-6: Ereignis erstellen .............................................................................................. 44
Abbildung 5-7: Prozesselemente verschieben .................................................................... 44
Abbildung 5-8: Elemente verbinden ....................................................................................... 44
Abbildung 5-9: Selektierung von Prozesselementen ........................................................ 44
Abbildung 5-10: Tap auf Hintergrund .................................................................................... 45
Abbildung 5-11: Zoomen ............................................................................................................ 45
Abbildung 5-12: Löschgeste ....................................................................................................... 45
Abbildung 5-13: Subprozess erstellen .................................................................................... 45
Abbildung 5-14: Subprozess öffnen ........................................................................................ 46
Abbildung 5-15: Lokale Vergrößerung ................................................................................... 46
Abbildung 5-16: Menübasierte Auswahl auf dem Smartphone ................................... 47
Abbildung 5-17: Smartphone als Tastatur ............................................................................ 48
Abbildung 5-18: Sprachanmerkung ........................................................................................ 48
Abbildung 5-19: Anziehung (Blau) und Abstoßung (rot) der Knoten ......................... 50
Abbildung 5-20: Ablauf des Layouting-Vefahrens ............................................................. 51
Abbildung 6-1: Farbtöne für Rückmeldungen auf der Hintergundfarbe mit RGB-
Werten ................................................................................................................................................ 54
Abbildung 6-2: Informationsfarben auf der Hintergrundfarbe mit RGB-Werten ... 55
Abbildung 6-3: Icons des Hauptmenüs .................................................................................. 56
Abbildung 6-4: Icons des Kontextmenüs ............................................................................... 56
Abbildung 6-5: Anpassung von Buchstaben bei der Schriftart Segoe360 [30] ....... 57
Abbildung 6-6: Prozesselemente in Process Touch ........................................................... 57
Abbildung 6-7: Hauptmenü ........................................................................................................ 58
Abbildung 6-8: Verbindungsmenü .......................................................................................... 58
Abbildung 6-9: Animation des Kontextmenüs .................................................................... 59
Abbildung 6-10: Kontextmenü eines Prozesselements .................................................... 59
Abbildung 6-11: virtuelle Tastatur auf dem Tabletop-System ...................................... 60
Abbildung 6-12: Hauptmenü auf dem Tablet ...................................................................... 61
Abbildung 6-13: Kontextmenü des Tablets .......................................................................... 62
Abbildung 6-14: Tastatur auf dem Tablet mit Autovervollständigung ...................... 62
Abbildung 6-15: Rückmeldungen bei Verbindungsoperationen ................................. 63
Abbildung 6-16: Tablettouch Rückmeldungen ................................................................... 64
ABBILDUNGSVERZEICHNIS
XLVII
Abbildung 7-1: Technologien von Microsoft Windows [57] .......................................... 68
Abbildung 7-2: Prinzip des MVVM-Patterns ........................................................................ 69
Abbildung 7-3: Aufbau der Anwendung ............................................................................... 74
Abbildung 7-4: UML-Sequenzdiagramm – Tablet tapt auf Prozesselement des
Tabletops ........................................................................................................................................... 80
Abbildung 7-5: Dualität der Skizzeneingabe........................................................................ 83
Abbildung 7-6: Vereinfachung eines Polygons ................................................................... 85
Abbildung 7-7: Normalisierter Boxfilter ohne Randbehandlung .................................. 87
Abbildung 7-8: Orientierungshistogramme samt korrespondierender
Skizzeneingabe ................................................................................................................................ 87
Abbildung 7-9: Drehen des Polygons und Berechnung der Bounding Box ............. 87
Abbildung 7-10: Jordan Curve Theorem ................................................................................ 89
Abbildung 7-11: Kräfte einzelner Knoten .............................................................................. 90
Abbildung 8-1: Beispiel-Items des ISO-Norm 9241/10 ................................................... 99
Abbildung 8-2: Beispiel-Items des UEQ ............................................................................... 100
Abbildung 8-3: Ablauf des Experiments .............................................................................. 106
Abbildung 8-4: Box Plots der Kategorien des ISO-Norm 9241/10 Fragebogens 108
Abbildung 8-5: Box Plots der Dimensionen des UEQ Fragebogens ......................... 109
Abbildung 8-6: Box Plots der zusammengefassten Werte des Loggers .................. 110
Abbildung 8-7 Modellierung an gegenüberliegenden Seiten des Tabletop-
Systems ............................................................................................................................................. 111
Abbildung 8-8 Ähnlichkeit von AND und XOR bei freier Orientierung ................... 112
Abbildung 8-9: Verbessertes Menü mit Schließen-Button ........................................... 115
Abbildung A-1: Seite 1 des ISO-Norm 9241/10 .................................................................... ix
Abbildung A-2: Seite 2 des ISO-Norm 9241/10 ..................................................................... x
Abbildung A-3: Seite 3 des ISO-Norm 9241/10 .................................................................... xi
Abbildung A-4: Seite 4 des ISO-Norm 9241/10 ................................................................... xii
Abbildung A-5: Seite 5 des ISO-Norm 9241/10 .................................................................. xiii
Abbildung A-6: Seite 6 des ISO-Norm 9241/10 .................................................................. xiv
Abbildung A-7: Seite 7 des ISO-Norm 9241/10 ................................................................... xv
Abbildung A-8: Seite 8 des ISO-Norm 9241/10 .................................................................. xvi
Abbildung B-1: Seite 1 des User Experience Questionnaires ........................................xvii
Abbildung B-2: Seite 2 des User Experience Questionnaires ...................................... xviii
ABBILDUNGSVERZEICHNIS
XLVIII
Abbildung C-1: Seite 1 des Allgemeinen Fragebogens ................................................... xix
Abbildung C-2: Seite 2 des Allgemeinen Fragebogens .................................................... xx
Abbildung D-1: Seite 1 des Leitfadens für den Experimentleiter ................................. xxi
Abbildung D-2: Seite 2 des Leitfadens für den Experimentleiter ................................ xxii
Abbildung E-1: Einverständniserklärung ............................................................................. xxiii
Abbildung F-1: Anwendungsszenario – Bewerber ...........................................................xxiv
Abbildung F-2: Anwendungsszenario - Unternehmen .................................................... xxv
Abbildung G-1: Prozessmodell der Probanden 1 und 2 .............................................. xxvii
Abbildung G-2: Prozessmodell der Probanden 3 und 4 ............................................. xxviii
Abbildung G-3: Prozessmodell der Probanden 5 und 6 ................................................ xxix
Abbildung G-4: Prozessmodell der Probanden 7 und 8 ................................................. xxx
Abbildung G-5: Prozessmodell der Probanden 9 und 10 ............................................. xxxi
Abbildung G-6: Prozessmodell der Probanden 11 und 12 ......................................... xxxii
Abbildung G-7: Prozessmodell der Probanden 13 und 14 ........................................ xxxiii
Abbildung G-8: Prozessmodell der Probanden 15 und 16 ........................................ xxxiv
Abbildung G-9: Prozessmodell der Probanden 17 und 18 ..........................................xxxv
Abbildung G-10: Prozessmodell der Probanden 19 und 20...................................... xxxvi
TABELLENVERZEICHNIS
XLIX
TABELLENVERZEICHNIS
Tabelle 5-1: Aktionen des Kontextmenüs .............................................................................. 41
Tabelle 5-2: Regeln der Syntaxprüfung .................................................................................. 49
Tabelle 7-1: Erkennung von Gesten ......................................................................................... 89
Tabelle 8-1: Dimensionen semantischer Qualität ............................................................. 100
Tabelle 8-2: Kategorien empfundener Qualität................................................................. 101
Tabelle 8-3: Implementierungsfehler .................................................................................... 116
Tabelle H-1: Daten des ISO-Norm 9241/10 .................................................................... xxxvii
Tabelle H-2: Daten des UEQ ................................................................................................ xxxviii
Tabelle H-3: Daten des Fragebogens Allgemeine Fragen .......................................... xxxix
Tabelle H-4: Weitere Daten des Experiments ........................................................................ xl
Tabelle H-5: Feedback der Probanden ................................................................................... xlii
TABELLENVERZEICHNIS
L
LITERATURVERZEICHNIS
LI
LITERATURVERZEICHNIS
[1]
J. Freund, „Geschäftsprozesse: Die zwölf wichtigsten Fragen zum Business-
Process-Management“, IDG Business Media GmbH, 21 Juli 2008. [Online].
Available: http://www.computerwoche.de/a/die-zwoelf-wichtigsten-fragen-
zum-business-process-management,1869128. [Zugriff am 10 Januar 2014].
[2]
B. Funk, J. Gómez, P. Niemeyer und F. Teuteberg, „Geschäftsprozess-
integration mit SAP - Fallstudien zur Steuerung von Wertschöpfungs-
prozessen entlang der Supply Chain“, Heidelberg: Springer, 2010.
[3]
G. M. Olson und J. S. Olson, „Distance Matters“, in Journal Human-Computer
Interaction, Volume 15, Issue 2, S. 139-178, 2000.
[4]
J. Kolb, B. Rudner und M. Reichert, „Towards Gesture-based Process
Modeling on Multi-Touch Devices“, in International Journal of Information
System Modeling and Design, Volume 4 Issue 4, S. 280-293, Heidelberg,
Germany, 2012.
[5]
H. Wittern, „Empirical Study Evaluating Business Process Modeling on Multi-
Touch Devices“, in Proceedings of the 2012 IEEE International Conference on
Software Science, Technology and Engineering (SWSTE '12), S. 20-29,
Washington, DC, USA, 2012.
[6]
J. Rekimoto und M. Saitoh, „Augmented Surfaces: A Spatially Continuous
Work Space for Hybrid Computing Environments“, in Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems (CHI '99), S.
378-385, New York, NY, USA, 1999.
[7]
B. Scholtz, A. Calitz und I. Snyman, „The Usability of Collaborative Tools:
Application to Business Process Modelling“, in Proceedings of the South
African Institute for Computer Scientists and Information Technologists
Conference (SAICSIT '13), S. 347-358, New York, NY, USA, 2013.
LITERATURVERZEICHNIS
LII
[8]
P. Rittgen, „Collaborative Modeling of Business Processes: A Comparative
Case Study“, in Proceedings of the 2009 ACM symposium on Applied
Computing (SAC '09), S. 225-230, New York, NY, USA, 2009.
[9]
S. Oppl und C. Stary, „Facilitating Shared Understanding of Work Situations
Using a Tangible Tabletop Interface“, in Behaviour & Information
Technology, Volume 33, Number 6, S. 619-635, Bristol, PA, USA, 2013.
[10]
D. Wachholder und S. Oppl, „Interactive Coupling of Process Models: A
Distributed Tabletop Approach to Collaborative Modeling“, in Proceedings
of the 2014 European Conference on Cognitive Ergonomics (ECCE '14), Artikel
31, 8 Seiten, Vienna, Austria, 2014.
[11]
J. Edelman, A. Grosskop, M. Weske und L. Leifer, „Tangible Business Process
Modeling: A New Approach“, in Proceedings of the 17th International
Conference on Engineering Design, ICED. Volume 9, S. 153-168, 2009.
[12]
R. Hardy und E. Rukzio, „Touch & Interact: Touch-based Interaction of
Mobile Phones with Displays“, in Proceedings of the 10th international
conference on Human computer interaction with mobile devices and services
(MobileHCI '08), S. 245-254, New York, NY, USA, 2008.
[13]
S. Döweling, T. Tahiri, B. Schmidt, A. Nolte und M. Khalibeigi, „Collaborative
Business Process Modeling On Interactive Tabletops“, in Proceedings of the
21st European Conference on Information Systems (ECIS '13), Research in
Progress, Paper 29, 2013.
[14]
J. Burkhardt, „Collaborative Process Modelling with Multi-Touch Tables“,
Diploma Thesis, Ulm, Germany, 2013.
[15]
Object Management Group, „Business Process Model and Notation, Version
2.02“, 20 Januar 2014. [Online]. Available: http://www.omg.org/spec
/BPMN/2.0.2/. [Zugriff am 3 Juli 2014].
LITERATURVERZEICHNIS
LIII
[16]
E. Rukzio, „Physical Mobile Interactions: Mobile Devices as Pervasive
Mediators for Interactions with the Real World“, München, 2006.
[17]
M. Dettweiler, „Computer „Surface“: Windows 7 ist vom Tisch - Technik &
Motor - FAZ“, Frankfurter Allgemeine Zeitung, 27 Januar 2012. [Online].
Available: http://www.faz.net/aktuell/technik-motor/computer-surface-
windows-7-ist-vom-tisch-11627206.html. [Zugriff am 28 Januar 2014].
[18]
D. Schmidt, F. Chehimi, E. Rukzio und H. Gellersen, „PhoneTouch: A
Technique for Direct Phone Interaction on Surfaces“, in Proceedings of the
23nd annual ACM symposium on User interface software and technology
(UIST '10), S. 13-16, New York, NY, USA, 2010.
[19]
R. Hardy, E. Rukzio, P. Holleis und M. Wagner, „Mobile Interaction with
Static and Dynamic NFC-based Displays“, in Proceedings of the 12th
international conference on Human computer interaction with mobile devices
and services (MobileHCI '10), S. 123-132, New York, NY, USA, 2010.
[20]
B. Pfleging, E. d. C. Valderrama Bahamondez, A. Schmidt, M. Hermes und J.
Nolte, „MobiDev: a Mobile Development Kit for Combined Paper-based and
In-situ Programming on the Mobile Phone“, in CHI '10 Extended Abstracts
on Human Factors in Computing Systems (CHI EA '10), S. 3722-3738, New
York, NY, USA, 2010.
[21]
C. H. Damm, K. M. Hansen und M. Thomsen, „Tool Support for Cooperative
Object-oriented Design: Gesture-based Modelling on an Electronic
Whiteboard“, in Proceedings of the SIGCHI conference on Human Factors in
Computing Systems (CHI '00), S. 518-525, New York, NY, USA, 2000.
[22]
S. Cheema, S. Gulwani und J. LaViola, „QuickDraw: Improving Drawing
Experience for Geometric Diagrams“, in Proceedings of the SIGCHI
Conference on Human Factors in Computing Systems (CHI '12), S. 1037-1064,
New York, NY, USA, 2012.
LITERATURVERZEICHNIS
LIV
[23]
R. Malaka, A. Butz und H. Hußmann, „Medieninformatik - Eine Einführung“,
Pearson Studium, 2009.
[24]
P. Fitts, „The Information Capacity of the Human Motor System in
Controlling the Amplitude of Movement“, in Journal of Experimental
Psychology, Volume 47, Number 6, S. 381-391, 1954.
[25]
S. D. Scott, K. D. Grant und R. L. Mandryk, „System Guidelines for Co-
located, Collaborative Work on a Tabletop Display“, in Proceedings of the
eighth conference on European Conference on Computer Supported
Cooperative Work (ECSCW'03), S. 159-178, Norwell, MA, USA, 2003.
[26]
R. Kruger und S. Carpendale, „Orientation and Gesture on Horizontal
Displays“, in UbiComp 2002 Workshop on Collaboration with Interactive
Walls and Tables, Gotenborg, Sweden, 2002.
[27]
P. Dragicevic und Y. Shi, „Visualizing and Manipulating Automatic
Document Orientation Methods Using Vector Fields“, in Proceedings of the
ACM International Conference on Interactive Tabletops and Surfaces (ITS '09),
S. 65-68, New York, NY, USA, 2009.
[28]
L. Barnkow, „Kollaboration an Multitouch-Tischen: Visualisierung von Besitz
bei Gruppenarbeit“, in Master Thesis, Hamburg, Germany, 2012.
[29]
G. Schiavo, G. Jacucci, T. Ilmonen und L. Gamberini, „Evaluating an
Automatic Rotation Feature in Collaborative Tabletop Workspaces“, in
Proceeding CHI '11 Extended Abstracts on Human Factors in Computing
Systems (CHI EA '11), S. 1315-1320, New York, NY, USA, 2011.
[30]
Microsoft Corporation, „Microsoft Surface 2.0 Design and Interaction
Guide“, Juli 2011. [Online]. Available: http://www.microsoft.com/en-
us/download/details.aspx?id=26713. [Zugriff am 14 Jannuar 2014].
LITERATURVERZEICHNIS
LV
[31]
C. Shen, K. Ryall, C. Forlines, A. Esenther, F. D. Vernier, K. Everitt, M. Wu, D.
Wigdor, M. Ringel Morris, M. Hancock und E. Tse, „Informing the Design of
Direct-Touch Tabletops“, in IEEE Computer Graphics and Applications,
Volume 26, Issue 5, S. 36-46, Los Alamitos, CA, USA, 2006.
[32]
J. O. Wobbrock, M. Ringel Morris und A. D. Wilson, „User-defined Gestures
for Surface Computing“, in Proceedings of the SIGCHI Conference on Human
Factors in Computing Systems (CHI '09), S. 1083-1092, New York, NY, USA,
2009.
[33]
D. Kirk, S. Izadi, O. Hilliges, R. Banks, S. Taylor und A. Sellen, „At Home with
Surface Computing?“, in Proceedings of the SIGCHI Conference on Human
Factors in Computing Systems (CHI '12), S. 159-168, New York, NY, USA,
2012.
[34]
Y. Rogers und S. Lindley, „Collaborating Around Vertical and Horizontal
Large Interactive Displays: Which Way is Best?“, in Interacting with
Computers, Volume 16, Number 6, S. 1133-1152, 2004.
[35]
A. Fox, B. Johanson, P. Hanrahan und T. Winograd, „Integrating Information
Appliances into an Interactive Workspace“, in Journal IEEE Computer
Graphics and Applications, Volume 20, Issue 3, S. 54-65, Los Alamitos, 2000.
[36]
H. Suzuki und H. Kato, „Interaction-level Support for Collaborative Learning:
AlgoBlock-an Open Programming Language“, in The first international
conference on Computer support for collaborative learning (CSCL '95), S. 349
- 355, 1995.
[37]
D. Schneider, J. Seifert und E. Rukzio, „MobIES: Extending Mobile Interfaces
Using External Screens“, in Proceedings of the 11th International Conference
on Mobile and Ubiquitous Multimedia (MUM '12), S. 1-2, Ulm, Germany,
2012.
LITERATURVERZEICHNIS
LVI
[38]
G. Broll, J. Hamard, M. Paolucci, M. Haarländer, M. Wagner, S. Siorpaes, E.
Rukzio, A. Schmidt und K. Wiesner, „Mobile Interaction with Web Services
Through Associated Real World Objects“, in Proceedings of the 9th
international conference on Human computer interaction with mobile devices
and services (MobileHCI '07), S. 319-321, New York, NY, USA, 2007.
[39]
M. de Sá, J. Antin, D. Shamma und E. F. Churchill, „Mobile Augmented
Reality: Video Prototyping“, in Proceedings of CHI '11 Extended Abstracts on
Human Factors in Computing Systems (CHI EA '11), S. 1897-1902, New York,
NY, USA, 2011.
[40]
D. Baur, S. Boring und S. Feiner, „Virtual Projection: Exploring Optical
Projection as a Metaphor for Multi-device Interaction“, in Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems (CHI '12), S.
1693-1702, New York, NY, USA, 2012.
[41]
Samsung , „Samsung GT-I8530“, 2014. [Online]. Available:
http://www.samsung.com/de/consumer/mobile-device/mobilephones/
archive-mobile-phones/GT-I8530BAADBT. [Zugriff am 3 September 2014].
[42]
P. Brandl, C. Forlines, D. Wigdor, M. Haller und C. Shen, „Combining and
Measuring the Benefits of Bimanual Pen and Direct-touch Interaction on
Horizontal Interfaces“, in Proceedings of the working conference on
Advanced visual interfaces (AVI '08), S. 154-161, New York, NY, USA, 2008.
[43]
M. Frisch, J. Heydekorn und R. Dachselt, „Diagram Editing on Interactive
Displays using Multi-Touch and Pen Gestures“, in Proceedings of the 6th
international conference on Diagrammatic representation and inference
(Diagrams'10), S. 182-196, Heidelberg, Germany, 2010.
[44]
K.-P. Yee, „Two-handed Interaction on a Tablet Display“, in Proceedings of
CHI '04 Extended Abstracts on Human Factors in Computing Systems (CHI EA
'04), S. 1493-1496, New York, NY, USA, 2004.
LITERATURVERZEICHNIS
LVII
[45]
D. Käser, M. Agrawala und M. Pauly, „FingerGlass: Efficient Multiscale
Interaction on Multitouch Screens“, in Proceedings of the SIGCHI Conference
on Human Factors in Computing Systems (CHI '11), S. 1601-1610, New York,
NY, USA, 2011.
[46]
Nuance, „Swype | About“, Nuance, [Online]. Available:
http://www.swypeinc.com/category/about/. [Zugriff am 30 Januar 2014].
[47]
S. MacKenzie, „The Design and Evaluation of a High-performance Soft
Keyboard“, in Proceedings of the SIGCHI conference on Human Factors in
Computing Systems (CHI '99), S. 25-31, New York, NY, USA, 1999.
[48]
J. Kolb und M. Reichert, „A flexible approach for abstracting and
personalizing large business process models“, in ACM SIGAPP Applied
Computing Review, Volume 13, Issue 1, S. 6-18, New York, NY, USA , 2013.
[49]
T. M. Fruchterman und E. M. Reingold, „Graph-drawing by Force-directed
Placement“, in Software: Practice and experience, Volume 21, Issue 11, S.
1129-1164, 1991.
[50]
Microsoft, „Windows 8 Design and coding guidelines - Updated for
Windows 8.1“, 2014. [Online]. Available: http://download.microsoft.com/
download/C/0/A/C0AEF0CC-B969-406D-989A-4CDAFDBB3F3C/
W8_1_Guidlines.pdf. [Zugriff am 26 August 2014].
[51]
C. Moser, „User Experience Design“, Springer-Verlag, 2012.
[52]
J. Smith, „WPF Apps With The Model-View-ViewModel Design Pattern“,
Microsoft, Februar 2009. [Online]. Available: http://msdn.microsoft.com/en-
us/magazine/dd419663.aspx. [Zugriff am 31 03 2014].
[53]
Microsoft, „Windows Presentation Foundation“, 2014. [Online]. Available:
http://msdn.microsoft.com/de-de/library/ms754130(v=vs.110).aspx. [Zugriff
am 2 September 2014].
LITERATURVERZEICHNIS
LVIII
[54]
Microsoft, „XAML Overview (WPF)“, 2014. [Online]. Available:
http://msdn.microsoft.com/de-de/library/ms752059(v=vs.110).aspx. [Zugriff
am 2 September 2014].
[55]
Microsoft, „Introducing Windows Presentation Foundation“, 2014. [Online].
Available: http://msdn.microsoft.com/en-us/library/aa663364.aspx. [Zugriff
am 2 September 2014].
[56]
B. Dewey, „Getting Started with Metro Style Apps“, O’Reilly Media, Inc.,
2012.
[57]
D. Meixner, „Windows 8 + Windows Phone 8 Cross Platform App
Development mit C#/XAML“, Microsoft, 5 April 2013. [Online]. Available:
http://blogs.msdn.com/b/dmx/archive/2013/04/05/windows-8-windows-
phone-8-cross-platform-app-development-mit-c-xaml-teil-1.aspx. [Zugriff
am 31 März 2014].
[58]
J. Bloch, „Effective Java“, Addison-Wesley, 2008.
[59]
Microsoft, „Data Binding Overview“, 2014. [Online]. Available:
http://msdn.microsoft.com/de-de/library/ms752347(v=vs.110).aspx. [Zugriff
am 2 September 2014].
[60]
Microsoft, „Microsoft PixelSense Design and Development“, 2014. [Online].
Available: http://msdn.microsoft.com/en-US/windows/desktop/
hh241326.aspx. [Zugriff am 2 September 2014].
[61]
Microsoft, „Windows Communication Foundation“, 2014. [Online]. Available:
http://msdn.microsoft.com/de-de/library/dd456779(v=vs.110).aspx. [Zugriff
am 2 September 2014].
[62]
Microsoft, „Data Contract Serializer“, 2014. [Online]. Available:
http://msdn.microsoft.com/de-de/library/ms731072(v=vs.110).aspx. [Zugriff
am 3 September 2014].
LITERATURVERZEICHNIS
LIX
[63]
J. Lowy, „WCF: Working with One-Way Calls, Callbacks, And Events“,
Microsoft MSDN Magazine, 2014. [Online]. Available:
http://msdn.microsoft.com/en-us/magazine/cc163537.aspx#S2. [Zugriff am
3 September 2014].
[64]
Max, „Stack Overflow“, 13 Juni 2010. [Online]. Available:
http://stackoverflow.com/questions/3032630/optimizing-simplifying-a-
path/3032686#3032686. [Zugriff am 14 Mai 2014].
[65]
J. Reaver, T. Stahovich und J. Herold, „How to make a Quick$: Using
Hierarchical Clustering to Improve the Efficiency of the Dollar Recognizer“,
in Proceedings of the Eighth Eurographics Symposium on Sketch-Based
Interfaces and Modeling (SBIM '11), S. 103-108, New York, NY, USA, 2011.
[66]
J. O. Wobbrock, A. D. Wilson und Y. Li, „Gestures Without Libraries, Toolkits
or Training: a $1 Recognizer for User Interface Prototypes“, in Proceedings of
the 20th annual ACM symposium on User interface software and technology
(UIST '07), S. 159-168, New York, NY, USA, 2007.
[67]
W. R. Franklin, „PNPOLY - Point Inclusion in Polygon Test“, 21 Januar 2014.
[Online]. Available: http://www.ecse.rpi.edu/Homepages/wrf/Research/
Short_Notes/pnpoly.html. [Zugriff am 8 Mai 2014].
[68]
Wikipedia contributors, „Coulombsches Gesetz“, 28 Mai 2014. [Online].
Available: http://de.wikipedia.org/wiki/Coulombsches_Gesetz. [Zugriff am 9
September 2014].
[69]
F. Sarodnick und H. Brau, „Methoden der Usability Evaluation -
Wissenschaftliche Grundlagen und praktische Anwendung“, Verlag Hans
Huber, 2011.
[70]
J. Barjis, „CPI Modeling: Collaborative, Participative, Interactive Modeling“, in
Proceedings of the Winter Simulation Conference (WSC '11), S. 3099-3108,
2011.
LITERATURVERZEICHNIS
LX
[71]
C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell und A. Wesslén,
„Experimentation in Software Engineering - An Introduction“, Kluwer
Academic Publishers, Norwell, MA, USA, 2000.
[72]
O. I. Lindland, G. Sindre und A. S0lvberg, „Understanding Quality in
Conceptual Modeling“, in IEEE Software, Volume 11, Number 2, S. 42-49,
1994.
[73]
J. Prümper, „ergo-online® - Fragebogen ISONORM“, 7 August 2012.
[Online]. Available: http://www.ergo-online.de/site.aspx?url=html
/software/verfahren_zur_ beurteilung_der/fragebogen_isonorm_online.htm.
[Zugriff am 1 August 2014].
[74]
International Organization for Standardization, „ISO 9241-11“, 1998.
[Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/
catalogue_detail.htm?csnumber=16883. [Zugriff am 5 Juli 2014].
[75]
A. Hinderks, „UEQ-Online“, [Online]. Available: http://www.ueq-online.org/.
[Zugriff am 17 Juli 2014].
[76]
P. Rittgen, „Quality and Perceived Usefulness of Process Models“, in
Proceedings of the 2010 ACM Symposium on Applied Computing (SAC '10), S.
65-72, New York, NY, USA, 2010.
[77]
V. Gruhn und R. Laue, „Complexity Metrics for Business Process Models“, in
In Proceedings of the ninth International Conference on Business Information
Systems (BIS'2006), S. 1–12, Klagenfurt, Austria, 2006.
[78]
A. Robertson, „Microsoft rebrands original Surface table-based touchscreen
as PixelSense“, 19 Juni 2012. [Online]. Available:
http://www.theverge.com/2012/6/19/3096652/microsoft-surface-table-
rebranded-as-pixelsense. [Zugriff am 1 August 2014].
LITERATURVERZEICHNIS
LXI
[79]
H. Reijers und J. Mendling, „A Study Into the Factors That Influence the
Understandability of Business Process Models“, in IEEE Trans. on Systems
Man and Cybernetics, Volume 41, Number 3, S. 449-462, 2011.
LITERATURVERZEICHNIS
LXII
LXIII
NAME
Sebastian Ronis
MATRIKELNUMMER
680536
ERKLÄRUNG
Ich erkläre, dass ich die Arbeit selbstständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel verwendet habe.
Ulm, den ______________________________ ___________________________________________
Datum Sebastian Ronis
