Entwicklung einer Applikation zur Durchführung von Card-Sorting ...

Fakultät für Elektrotechnik, Informatik und Mathematik
Institut für Informatik
Fachgebiet Mensch-Computer-Interaktion
Fürstenallee 11
33102 Paderborn
Entwicklung einer Applikation
zur Durchführung von
Card-Sorting Experimenten auf
einem Multi-Touch-Tisch
Bachelor-Arbeit
im Rahmen des Studiengangs Informatik
zur Erlangung des Grades
Bachelor of Science
von
Markus Rose
Hüfferweg 26
33100 Paderborn
betreut durch
M.Sc. Adrian Hülsmann
vorgelegt bei
Prof. Dr. Gerd Szwillus
und
Jun-Prof. Dr. Christoph Sorge
Paderborn, Januar 2013

Erklärung
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser
als Teil einer Prüfungsleistung angenommen worden ist. Alle Ausführungen, die
wörtlich oder sinngemäß übernommen worden sind, sind als solche gekennzeichnet.
Ort, Datum
Unterschrift
iii

Inhalt
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Card-Sorting 7
2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Offenes Card-Sorting . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Geschlossenes Card-Sorting . . . . . . . . . . . . . . . . . 9
2.2.3 Mehrfache Zuordnung . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Hierarchisches Card-Sorting . . . . . . . . . . . . . . . . . 10
2.2.5 Reverse Card-Sorting . . . . . . . . . . . . . . . . . . . . . 10
2.2.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Bisherige Implementierungen . . . . . . . . . . . . . . . . . . . . . 11
3 Technische Grundlagen 13
3.1 WeCaSo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Projekt erstellen . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Aufbau der WeCaSo Datenbank . . . . . . . . . . . . . . . 16
3.2 Multitouch-Tisch . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Geschichte der Multitouch-Geräte . . . . . . . . . . . . . . 18
3.2.2 Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Mr. T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Multitouch-Gesten 25
4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
v

Inhalt
4.2 Multitouch-Gesten für Card-Sorting . . . . . . . . . . . . . . . . . 27
4.2.1 Karte verschieben . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2 Karte kopieren . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.3 Karte löschen . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.4 Beschreibung eines Begriffs . . . . . . . . . . . . . . . . . . 35
4.2.5 Hierarchisches Einfügen . . . . . . . . . . . . . . . . . . . 35
4.2.6 Gruppieren von Karten . . . . . . . . . . . . . . . . . . . . 36
4.2.7 Experiment beenden . . . . . . . . . . . . . . . . . . . . . 43
5 Architektur der Applikation 45
5.1 Geschäftslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1 Datenanbindung an WeCaSo . . . . . . . . . . . . . . . . . 45
5.1.2 Projekt laden . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.3 Karten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.4 Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.5 Interaktionen . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Präsentationslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6 Bedienung der Applikation 55
6.1 Projekt laden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Durchführung von Experimenten . . . . . . . . . . . . . . . . . . 57
6.2.1 Elemente verschieben . . . . . . . . . . . . . . . . . . . . . 58
6.2.2 Karten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.3 Karten gruppieren . . . . . . . . . . . . . . . . . . . . . . 60
6.2.4 Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3 Experiment beenden . . . . . . . . . . . . . . . . . . . . . . . . . 66
7 Zusammenfassung und Ausblick 69
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Anhang 71
A.1 Inhalt der CD-Rom . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.2 Voraussetzungen zum Ausführen der Applikation . . . . . . . . . 71
Literatur 75
vi

Abbildungsverzeichnis
3.1 Projekt in WeCaSo anlegen . . . . . . . . . . . . . . . . . . . . . 15
(a) Fragebogen anlegen . . . . . . . . . . . . . . . . . . . . . . . 15
(b) Begriffe und Kategorien definieren . . . . . . . . . . . . . . 15
3.2 Unterbrechung der Totalreflexion . . . . . . . . . . . . . . . . . . 20
3.3 Darstellung eines projektiv-kapazitiven Multitouch-Screens . . . . 21
3.4 Multitouch-Tisch MisterT . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Aufbau des Benutzertests von North u.a. . . . . . . . . . . . . . . 28
(a) Physische Variante . . . . . . . . . . . . . . . . . . . . . . . 28
(b) Desktop-Variante . . . . . . . . . . . . . . . . . . . . . . . . 28
(c) Multitouch-Tisch-Variante . . . . . . . . . . . . . . . . . . . 28
4.2 Verschieben von Karten . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Kopieren von Karten . . . . . . . . . . . . . . . . . . . . . . . . . 31
(a) Kopieren durch Ziehen . . . . . . . . . . . . . . . . . . . . . 31
(b) Kopieren durch Tab-Geste . . . . . . . . . . . . . . . . . . . 31
4.4 Löschen von Karten . . . . . . . . . . . . . . . . . . . . . . . . . . 34
(a) Löschen durch Wischen . . . . . . . . . . . . . . . . . . . . 34
(b) Löschen durch Verschieben nach außen . . . . . . . . . . . . 34
4.5 Hierarchisch Einfügen . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Gruppieren von Karten mit allgemeinen Gesten . . . . . . . . . . 38
(a) Gruppieren durch sequenzielles Berühren . . . . . . . . . . . 38
(b) Gruppieren durch Lasso-Selektion . . . . . . . . . . . . . . . 38
4.6 Gruppieren mit Pile-n-Browse . . . . . . . . . . . . . . . . . . . . 38
4.8 Gruppieren von Karten mit Blasen . . . . . . . . . . . . . . . . . 39
4.9 Gruppieren teilen . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1 Klassendiagramme Card-Sorting-MTT . . . . . . . . . . . . . . . 46
5.2 Oberfläche von Card-Sorting-MTT . . . . . . . . . . . . . . . . . 52
vii

Abbildungsverzeichnis
6.1 Wizard zum Laden eines Projekts . . . . . . . . . . . . . . . . . . 56
(a) Projektnamen eingeben . . . . . . . . . . . . . . . . . . . . 56
(b) Falscher Projektname eingegeben . . . . . . . . . . . . . . . 56
(c) Willkommensnachricht . . . . . . . . . . . . . . . . . . . . . 56
(d) Anleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
(e) Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Verschieben von Karten und Kategorien . . . . . . . . . . . . . . 58
(a) Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
(b) Kategorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 Karte kopieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Karte löschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.5 Einblenden der Beschreibung . . . . . . . . . . . . . . . . . . . . . 60
6.6 Gruppierung erstellen . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.7 Kategorie erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.8 Kategorie benennen . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.9 Einzelne Karte zu einer Kategorie hinzufügen . . . . . . . . . . . 64
6.10 Gruppierung zu einer Kategorie hinzufügen . . . . . . . . . . . . . 65
6.11 Karten durch Lasso-Selektion einer Kategorie hinzufügen . . . . . 65
6.12 Experiment beenden . . . . . . . . . . . . . . . . . . . . . . . . . 66
viii

1 Einleitung
1.1 Motivation
Bei der Entwicklung einer Applikation oder Webseite ist für den Entwickler wegen
des Pflichtenheftes unmittelbar klar, was die Applikation oder Webseite leisten
soll. Bei der Gestaltung der Oberfläche machen Entwickler jedoch oft einen entscheidenden
Fehler. Sie gestalten die Oberfläche bzw. die Navigationsstruktur der
Oberfläche nach persönlichem Maßstab bezüglich der Benutzung und Gestaltung.
Sie vernachlässigen dabei gerne, dass ihre kognitiven Fähigkeiten in diesem Bereich
oft ausgeprägter sind als bei den späteren Benutzern.
In diesem Zusammenhang spricht man von der Usability einer Software oder
Webseite. Usability steht im Englischen für Benutzbarkeit oder Gebrauchstauglichkeit.
Sie ist ein entscheidender Aspekt, der über den Erfolg oder Misserfolg
einer Anwendung entscheidet.
Die Usability einer Anwendung oder Webseite wird mit Hilfe von Usability-Tests
untersucht. Zum einen gibt es Usability-Tests, die von Usability-Experten durchgeführt
werden, welche die Aufgabe haben, sich in die späteren Benutzer hineinzuversetzen
und typische Arbeitsabläufe mit dem Programm durchführen. Durch
langjährige Erfahrung stellen sie schnell mögliche Usability Probleme fest. Auch
stellen Usability-Experten Probleme in Anwendungen fest, die dem Benutzer nicht
direkt auffallen, aber zu einer Verschlechterung der Benutzbarkeit führen können.
Es besteht jedoch die Gefahr, dass Usability-Experten die technischen Fähigkeiten
der späteren Benutzer über- oder unterschätzen. Aus diesem Grund gibt es
auch Usability-Tests, die mit späteren Benutzern der Anwendung durchgeführt
werden. So wird festgestellt, wie Benutzer die Anwendung bedienen und welche
Erwartungen sie in diese haben.
Usability-Tests sollten so früh wie möglich im Entwicklungsprozess durchgeführt
werden. Wenn die Applikation schon fertiggestellt ist, wird eine solche Überprü-
1

1. Einleitung
fung mit Sicherheit dazu führen, dass an der Applikation noch Änderungen vollzogen
werden müssen bzw. der Aufbau komplett überarbeitet werden muss, was
mit enormen Kosten verbunden sein kann.
Einer dieser Usability-Tests, der am Anfang einer Entwicklung von späteren
Benutzern durchgeführt wird, ist das Card-Sorting. Bei einem Card-Sorting bekommen
die Testteilnehmer, die sich aus der Gruppe der späteren Benutzer zusammensetzt,
vom Testleiter, in der Regel einer der Entwickler, Karten mit den geplanten
Navigationspunkten oder Menüeinträgen. Die Testteilnehmer haben dann
die Aufgabe, diese Begriffe in vordefinierte oder vom Testteilnehmer selbst erstellte
Kategorien einzuordnen. Aus den Zuordnungen kann der Testleiter dann eine
geeignete Navigationsstruktur extrahieren. Im Detail werde ich Card-Sorting im
Kapitel 2 beschreiben.
Das ursprüngliche Card-Sorting 1 wird mit Papierkarten auf einem normalen Tisch
durchgeführt. Dies hat jedoch einige Nachteile. Der Testleiter und die Testpersonen
müssen an einem Ort sein. Die Ergebnisse müssen durch einen Protokollanten
zwecks Auswertung erfasst werden. Um dies zu verhindern, sind im Laufe der Zeit
verschiedene Card-Sorting Applikationen, zumeist webbasiert, entwickelt worden.
Dadurch brauchen Testleiter und Testteilnehmer nicht mehr an einem Ort sein.
Auch der administrative Aufwand wird dadurch verringert. Ein Card-Sorting Experiment
kann einmalig definiert werden und von beliebig vielen Testteilnehmern
durchgeführt werden. Auch die Auswertung kann durch solche Applikationen automatisiert
werden.
Der Nachteil ist jedoch, dass ein webbasiertes Card-Sorting gewisse technische Fähigkeiten
der Testteilnehmer voraussetzt. Abhängig von der Fähigkeit der Testteilnehmer
müssen diese erst mehr oder weniger aufwändig in das System eingeführt
werden.
Die Nachteile, die sich für die Testteilnehmer ergeben, könnten durch ein Multitouch
basiertes Card-Sorting verringert oder gar ganz vermieden werden. Geräte
mit Multitouch Bedienung erhalten immer mehr Einzug in unseren Alltag. Dies
hat nicht zuletzt mit dem Boom von Smartphones und Tablets zu tun. Aber auch
wer noch nie mit einem Multitouch-Gerät gearbeitet hat, wird sich schnell in die
Bedienung einarbeiten können. Bei der Umsetzung einer Card-Sorting Anwendung
1 Im späteren Verlauf der Arbeit als klassisches Card-Sorting beschrieben.
2

1.2 Zielsetzung
auf einem Multitouch-Tisch wird sich der Benutzer schnell in die Bedienung der
Anwendung einarbeiten können.
Dies unterstreicht auch die Studie Touch it, move it, scale it - Multitouch von
Christine Höflacher u.a. [BKH09], die im Jahr 2009 die Usability des Microsoft
Surface Tisches untersucht haben und unter anderem zu folgendem Ergebnis kamen:
„[D]ie Bedienung des MS Surface ist intuitiv. Sie baut auf Vorwissen auf,
das der Nutzer bereits besitzt und unbewusst anwendet. Die Bedienung ist so für
neue Nutzer leicht zu verstehen.“
Gerade das Zurückgreifen auf Vorwissen kann bei der Umsetzung einer Card-
Sorting Anwendung auf einem Multitouch-Tisch von entscheidender Bedeutung
sein. Die Benutzer werden beim Anordnen bzw. Verschieben der Karten schnell
eine Beziehung zum klassischen Card-Sorting herstellen können.
Während es mit Maus und Tastatur nur möglich ist, Interaktionen sequenziell
auszuführen, können diese auf einem Multitouch-Tisch auch parallel ausgeführt
werden. So können zum Beispiel gleichzeitig mehrere Karten einer Kategorie zugeordnet
werden.
1.2 Zielsetzung
Ziel dieser Arbeit ist es, eine Applikation zur Durchführung von Card-Sorting
Experimenten auf einem Multitouch-Tisch zu entwickeln. Die Anwendung soll
innerhalb des Microsoft .NET 4.0 Frameworks ausführbar sein. Näheres zur Entwicklungsumgebung
ist im Kapitel 3.3 beschrieben.
Zur Durchführung von Card-Sorting-Experimenten müssen diese der zur entwickelnden
Applikation zu Verfügung stehen. Dazu sollen Experimente aus der Datenbank
der Online-Card-Sorting-Applikation WeCaSo geladen werden. WeCaSo
ist ein im Fachgebiet Mensch-Computer-Interaktion der Universität Paderborn
entwickeltes Online-Card-Sorting, mit dem der Testleiter Card-Sorting-Projekte
erstellen kann. Die Testteilnehmer können diese über einen Webbrowser aufrufen
und durchführen. WeCaSo wird in Kapitel 3.1 näher beschrieben.
Der Fokus dieser Arbeit liegt somit auf der reinen Durchführung von Card-Sorting-
Experimenten auf einem Multitouch-Tisch. Das heißt es wird eine Oberfläche für
das Card-Sorting erstellt und entsprechende Gesten für die Durchführung entwickelt.
3

1. Einleitung
Die technischen Fähigkeiten der späteren Benutzer sind sehr unterschiedlich. Die
Gesten sollten deshalb so gewählt werden, dass auch unerfahrene Benutzer sich
schnell in die Interaktionen der Anwendung einarbeiten können. Dies soll vor allem
dadurch geschehen, dass die Gesten mit der durchzuführenden Aktion in Verbindung
gebracht werden können. Ein klassisches Beispiel dafür ist das Zoomen in
Multitouch-Anwendungen. Typischerweise wird dies durch das Bewegen von zwei
Fingern in entgegengesetzter Richtung bzw. aufeinander Zubewegen von zwei Fingern
auf dem zu zoomenden Objekt durchgeführt.
Erfahrene Benutzer erwarten durch neue Anwendungen aber auch Vereinfachungen.
Sie wollen die Karten zum Beispiel erst einmal grob vorsortieren, alle markieren
bzw. gruppieren und mit einer Geste der entsprechenden Kategorie hinzufügen.
1.3 Vorgehensweise
Die Entwicklung von Multitouch-Gesten findet in der Forschung immer mehr Zuspruch.
So wurden im Laufe der letzten Jahre immer mehr wissenschaftliche Arbeiten
veröffentlicht, die sich mit diesem Thema beschäftigen.
Im Rahmen dieser Arbeit werden diverse wissenschaftliche Arbeiten dahingehend
untersucht, ob sie Gesten beinhalten, die für ein Card-Sorting nützlich sind. Daraus
werden sich für jede benötigte Aktion jeweils mehrere Gesten als nützlich
herausstellen. Diese sollen anschließend miteinander verglichen und gegeneinander
abgewogen werden, welche Geste für die Durchführung einer Aktion am sinnvollsten
ist. Ausschlaggebend dafür werden auch die Benutzerstudien sein, die in
den meisten der untersuchten Arbeiten durchgeführt werden. Diese Untersuchung
wird in Kapitel 4 vorgenommen.
Im weiteren Verlauf muss eine Anbindung an WeCaSo entwickelt werden. Die
Daten der Experimente müssen aus einer Datenbank ausgelesen und die Ergebnisse
anschließend wieder in die Datenbank übertragen werden.
WeCaSo arbeitet mit einer MySQL Datenbank. Eine Schnittstelle zum Zugriff
auf die Daten von außen ist in WeCaSo nicht vorhanden. Die Daten müssen somit
direkt aus der Datenbank ausgelesen werden. Das Übertragen der Ergebnisse
geschieht ebenfalls über entsprechende Datenbankaufrufe. Der Zugriff auf die Datenbank
wird in Kapitel 5.1.1 beschrieben.
Außerdem muss eine Multitouch-Oberfläche entwickelt werden, auf der die Benut-
4

1.3 Vorgehensweise
zer die Card-Sorting Experimente durchführen. Darauf aufbauend werden dann
die in Kapitel 4.2 festgelegten Gesten implementiert. Die Architektur der Applikation
ist in Kapitel 5 erläutert und die Bedienung der Applikation in Kapitel 6
beschrieben.
5

2 Card-Sorting
2.1 Grundlagen
Das Card-Sorting zählt zu den von späteren Benutzern durchgeführten Usability-
Tests. In einer empirischen Untersuchung mit mindestens 15 Teilnehmern wird die
Navigationsstruktur einer Webseite oder Applikation durch die jeweiligen Testteilnehmer
ermittelt bzw. in einer Variante des Card-Sortings auf Gebrauchstauglichkeit
überprüft.
Wie in der Einleitung beschrieben, sollte das Card-Sorting so früh wie möglich im
Entwicklungsprozess durchgeführt werden, da sonst im schlimmsten Fall die Navigationsstruktur
neu erstellt werden muss. Mit Erhalt des Pflichtenheftes steht für
die Entwickler schnell fest, welche Navigationspunkte oder Menüeinträge die spätere
Applikation oder Webseite benötigt. Zu diesem Zeitpunkt sollte Card-Sorting
zum Einsatz kommen.
Donna Spencer und Todd Warfel [SW04] schreiben über die umfangreichen Möglichkeiten
von Card-Sorting: „Card Sorting is a great, reliable, inexpensive method
for finding patterns in how users would expect to find content or functionality.“
Dieses Zitat spiegelt die Mächtigkeit von Card-Sorting gut wieder. Mit wenig Aufwand
und geringen Kosten können Entwickler schon vor dem eigentlichen Entwicklungsprozess
feststellen, was die späteren Benutzer von der Anwendung erwarten
bzw. wie und wo sie erwarten die Navigationspunkte zu finden.
2.2 Funktionsweise
Innerhalb eines Card-Sortings gibt es drei Aufgabenbereiche. Zum ersten der Testleiter,
der in der Regel aus der Gruppe der Entwickler stammt. Der Testleiter erstellt
für jeden Testteilnehmer einen Satz von Karten, auf denen er jeweils den Na-
7

2. Card-Sorting
men des Navigationspunktes schreibt. Für das geschlossene Card-Sorting muss er
zusätzlich noch Karten für die Namen der Kategorien erstellen, denen die Karten
zugeordnet werden sollen. Bevor das Experiment beginnt, erklärt der Testleiter
den Testteilnehmern, was ihre Aufgaben sind und welches Ziel mit dem Experiment
verfolgt werden soll. Am Ende des Experiments muss der Testleiter die
Ergebnisse des Card-Sorting Experiments auswerten und daraus eine geeignete
Navigationsstruktur entwickeln.
Als nächstes sind die Testteilnehmer zu nennen. Sie repräsentieren die Gruppe der
späteren Benutzer und haben die Aufgabe, die Karten entweder selbst gewählten
oder vorgegebenen Kategorien zuzuordnen 1 . Während der Testdurchführung sollen
die Testteilnehmer laut denken. Dadurch kann festgestellt werden, ob es für
die Testteilnehmer leicht war, die Begriffe zuzuordnen bzw. ob es Probleme bei
der Zuordnung gibt. Diese Erkenntnis ist für den Testleiter sehr wichtig, da er
ansonsten nur das Ergebnis sieht und nicht feststellen kann, ob es eventuell doch
keine gute Navigationsstruktur ist.
Die lauten Gedanken der Testteilnehmer werden während der Testdurchführung
von Protokollanten notiert. Die Protokollanten haben drüber hinaus die Aufgabe,
nach Durchführung des Experiments die Zuordnungen der Karten zu protokollieren.
Wie bereits erwähnt, gibt es unterschiedliche Varianten, ein Card-Sorting Experiment
durchzuführen. Bei der Benutzung von Card-Sorting sollte nicht nur
eine Variante benutzt werden. Die Varianten bauen vielmehr aufeinander auf und
helfen dem Testleiter eine immer weiter verbesserte Navigationsstruktur zu entwickeln.
Im Folgenden werden die gebräuchlichsten Varianten vorgestellt, die auch
von WeCaSo unterstützt werden.
2.2.1 Offenes Card-Sorting
Eines der Varianten ist das offene Card-Sorting. Hier überlässt der Testleiter den
Testteilnehmern, geeignete Namen für die Kategorien zu definieren und die Karten
entsprechend zuzuordnen. Der Vorteil dabei ist, dass der Testteilnehmer hier
einen breiten Spielraum hat, die Begriffe zuzuordnen. Für den Testleiter kann
hier jedoch das Problem entstehen, dass er sehr viele verschiedene Kategorien be-
1 Dies ist von der Variante des Card-Sortings abhängig und wird im weiteren Verlauf des Kapitels
erläutert.
8

2.2 Funktionsweise
kommt und daraus nicht unbedingt eine geeignete Navigationsstruktur erstellen
kann. Das kann vor allem dann passieren, wenn sich die gewählten Oberbegriffe
nicht adäquat zusammenfassen lassen.
Das offene Card-Sorting sollte benutzt werden, um zu Anfang eine Idee zu bekommen,
was die Testteilnehmer von der späteren Navigationsstruktur erwarten.
Aus den Ergebnissen sollten entsprechende Kategorien extrahiert werden und anschließend
mit dem geschlossenem Card-Sorting verifiziert werden.
2.2.2 Geschlossenes Card-Sorting
Bei einem geschlossenem Card-Sorting bekommt der Testteilnehmer zusätzlich zu
den Karten auch die Namen der Kategorien. Er darf während des Experiments
keine neue Kategorie anlegen. Außerdem muss er versuchen, jede Karte einer Kategorie
zuzuordnen. Das geschlossene Card-Sorting kann dazu benutzt werden, die
aus den Ergebnissen eines offenen Card-Sorting-Experiments extrahierten Kategorien
zu verifizieren. Es kann aber auch benutzt werden, um zu prüfen, ob von
Entwicklern ausgedachte Kategorien von den Testteilnehmern angenommen werden.
Es ist jedoch vorteilhafter diese Kategorien aus einen offenen Card-Sorting
zu gewinnen.
Durch die Ergebnisse kann der Testleiter dann überprüfen, ob die von ihm gewählten
Kategorien den Testteilnehmern Schwierigkeiten bei der Zuordnung bereiten
oder es den Testteilnehmern leicht fällt die Begriffe zuzuordnen. Hier ist vor allem
das laut Gedachte der Testteilnehmer und die Zeit wichtig, die für das Zuordnen
eines Begriffs gebraucht wird. Haben die Testteilnehmer Schwierigkeiten bestimmte
Begriffe zuzuordnen, so sollte die Benennung der Kategorien erneut überdacht
bzw. zusätzliche Kategorien erstellt werden.
2.2.3 Mehrfache Zuordnung
Testteilnehmer stehen öfter vor dem Problem, dass sie einen Begriff nicht nur einer
Kategorie zuordnen könnten, sondern mehreren. Um dies zu verhindern, kann
das mehrfache Zuordnen eines Begriffs erlaubt werden. Dies gibt dem Testleiter
ein Feedback darüber, ob die Namen für die Kategorien unter Umständen noch
präziser definiert werden müssen bzw. Kategorien zusammengefasst oder anders
benannt werden sollten.
9

2. Card-Sorting
2.2.4 Hierarchisches Card-Sorting
Ein Problem an den bisher vorgestellte Card-Sorting-Varianten ist, dass nur sehr
flache Navigationsstrukturen erstellt werden können. Es gibt nur eine Ebene von
Kategorien, in denen alle Navigationspunkte einsortiert werden. Gerade bei komplexen
Webseiten ist dies jedoch realitätsfern. Hier kann das hierarchische Card-
Sorting eingesetzt werden. Hierbei können innerhalb der Kategorien noch Unterkategorien
definiert werden, denen dann wieder Begriffe zugeordnet werden.
2.2.5 Reverse Card-Sorting
Alle vorgestellten Card-Sorting Methoden haben eine gemeinsame Schwäche. Es
kann nicht ermittelt werden, ob die Namen der Navigationspunkte wirklich vorteilhaft
gewählt sind. Auch kann es sein, dass die Navigationsstruktur, die aus
einem offenen oder geschlossenen Card-Sorting ermittelt wird, in der späteren Navigationsstruktur
den Nutzervorstellungen nicht entsprechen.
Damit eine fertige Navigationsstruktur überprüft werden kann, kommt das Reverse-
Card-Sorting zum Einsatz. Es wird eingesetzt, wenn schon eine fertige Navigationsstruktur
besteht, z.B. als Ergebnis einer der vorgestellten Card-Sorting Varianten.
Die Testteilnehmer bekommen Aufgabenkarten, auf denen ein Navigationspunkt
steht, den sie in der Navigationsstruktur suchen sollen. Der Testleiter zeigt den
Testteilnehmern dann die Kategorien der ersten Navigationsebene. Der Testteilnehmer
muss auswählen in welcher Kategorie er den Begriff, der auf der Aufgabenkarte
steht, vermutet. Ist der Begriff innerhalb der gewählten Kategorie, so ist
er fertig. Gibt es in dieser Kategorie noch weitere Unterkategorien, so muss der
Testteilnehmer erneut eine Kategorie auswählen, in der er den gesuchten Begriff
vermutet. Dies wird solange fortgeführt bis der Begriff gefunden ist oder es keine
weiteren Unterkategorien in der Navigationsstruktur gibt. In diesem Fall kann der
Testteilnehmer die Aufgabe überspringen oder aus der Navigationsstruktur einen
anderen Weg wählen.
Während des Tests notiert der Protokollant, welchen Pfad durch die Navigationsstruktur
der Testteilnehmer gewählt hat, inklusive der falschen Pfade. Der
Testleiter kann daraus folgern, ob seine gewählte Navigationsstruktur geeignet ist
oder noch angepasst werden muss.
10

2.3 Bisherige Implementierungen
2.2.6 Zusammenfassung
Eine Card-Sorting-Variante sollte möglichst nicht autonom durchgeführt werden.
Damit eine gute Navigationsstruktur erzielt wird, ist es empfehlenswert alle vorgestellten
Varianten durchzuführen. Um das Ergebnis nicht zu verfälschen, sollte
auch immer etwas Zeit zwischen den Tests liegen.
Auch wenn alle Card-Sorting-Varianten durchgeführt wurden, erhält man höchstens
eine gute Navigationsstruktur. Eine optimale Navigationsstruktur wird es
wohl niemals geben und kann auch mit einem Card-Sorting nicht ermittelt werden.
Dafür sind die Menschen zu unterschiedlich in ihren Erwartungen.
2.3 Bisherige Implementierungen
Die Vorbereitungen für ein Card-Sorting Experiment sind beim klassischen Card-
Sorting relativ aufwendig. Es müssen für jeden Testteilnehmer Karten mit Begriffen
erstellt werden. Auch müssen Testleiter und Testteilnehmer am gleichen
Ort sein. Das mag für Anwendungen, die in einem bestimmten Firmenumfeld
zum Einsatz kommen, noch praktikabel sein. Allerdings ist dies bei Anwendungen
oder Webseiten für ein breites Benutzerspektrum schwieriger. Deswegen macht es
Sinn, dass Testleiter und Testteilnehmer nicht am gleichen Ort sein müssen. Hierfür
gibt es bereits diverse Webanwendungen für Card-Sorting.
Ein bekannter Vertreter ist das kostenpflichtige WebsortSort 2 . Hier können Experimente
definiert, durchgeführt und ausgewertet werden.
Eine Alternative dazu ist, die in der Arbeitsgruppe Mensch-Computer-Interaktion
von Andreas Vdovkin [Vdo08] entwickelte Webapplikation WeCaSo 3 . Mit WeCa-
So können ebenfalls Card-Sorting-Experimente erstellt und durchgeführt werden.
Eine direkte Auswertung ist mit WeCaSo nicht möglich, die Ergebnisse können
aber als XML oder CSV Datei exportiert werden.
In Kapitel 3.1 wird WeCaSo näher beschrieben, da die dort erstellten Experimente
als Grundlage für die hier entwickelte Card-Sorting Anwendung dienen.
Diese Ergebnisse können mit dem ebenfalls in der Arbeitsgruppe von Sebastian
Emmrich [Emm08] entwickelten casolysis importiert und ausgewertet werden.
2 WebSort: http://uxpunk.com/websort/index.php, aufgerufen am 08.01.2013.
3 http://cardsort.cs.upb.de/, aufgerufen am 08.01.2013
11

3 Technische Grundlagen
3.1 WeCaSo
Die Card-Sorting Experimente, die mit der hier entwickelten Multitouch Anwendung
durchgeführt werden sollen, werden in dem von Andreas Vdovkin [Vdo08]
im Rahmen seiner Bachelorarbeit entwickelten webbasierten Card-Sorting Anwendung
WeCaSo erstellt.
Damit in WeCaSo ein Card-Sorting Experiment angelegt werden kann, ist es
erforderlich, dass sich der Benutzer (Testleiter) auf der WeCaSo Homepage 1 registriert.
Nach der anschließenden Anmeldung bekommt der Benutzer eine Übersicht
über seine existierenden Projekte. Außerdem kann er neue Projekte anlegen.
Verwirrend dürfte hier die Bezeichnung Projekt sein, weil zuvor von Card-Sorting
Experimenten gesprochen wird. Ein Projekt in WeCaSo ist eine Art Container,
in dem neben dem Experiment noch ein Begrüßungstext, eine Anleitung für das
Experiment, ein Fragebogen und eine Danksagung definiert werden.
3.1.1 Projekt erstellen
Beim Erstellen eines neuen Projekts muss der Benutzer folgende Angaben machen:
Name des Projekts, der beliebig vergeben kann. Er kann außerdem im Nachhinein
verändert werden.
Art des Experiments:
• offenes Card-Sorting
• geschlossenes Card-Sorting
• Reverse-Card-Sorting
1 http://cardsort.cs.upb.de, aufgerufen am 08.01.2013.
13

3. Technische Grundlagen
Multiple-Insert erlauben legt fest, dass Begriffe in mehrere Kategorien eingeordnet
werden dürfen.
Hierarchisches Sortieren legt fest, dass Karten in beliebig tiefe Ebenen eingeordnet
werden dürfen.
Sprache des Projekts ist wichtig, wenn ein Projekt in mehreren Sprachen erstellt
werden soll, damit dem Benutzer die gewünschte Sprache angezeigt wird.
Wunschadresse des Projekts ist Bestandteil der URL, die aufgerufen wird, um
das Projekt im Browser zu öffnen. Dieser Name darf nach dem Erstellen des
Projekts nicht mehr verändert werden. Außerdem ist der Name innerhalb
der Datenbank eindeutig.
Enddatum des Projekts legt fest, bis zu welchem Datum dieses Projekt von Testteilnehmern
durchgeführt werden darf.
Hat der Benutzer das Projekt angelegt, kann er dieses über die Projektübersicht
öffnen und die Projektdetails definieren. Diese Details sind in folgende Kategorien
unterteilt.
Willkommens-Nachricht wird der Testperson zu Beginn des Projekts angezeigt.
Die Willkommensnachricht enthält allgemeine Informationen über das Projekt
und soll die Testteilnehmer zur Durchführung motivieren.
Fragebogen der von der Testperson ausgefüllt werden soll. Es können freie Fragen
formuliert werden, die der Benutzer über ein Textfeld beantwortet. Es
können auch Fragen mit vordefinierten Antworten erstellt werden. Entweder
ist eine Antwort oder mehrere Antworten möglich. Die Beantwortung einer
Frage kann als notwendig oder optional definiert werden (vgl. Abbildung
3.1(a)).
Anleitung erklärt der Testperson die Durchführung des Projekts. Die Anleitung
kann während der Durchführung jederzeit wieder aufgerufen werden.
Begriffe und Kategorien werden beim offenen oder geschlossenen Card-Sorting-
Experimenten angezeigt. Hier definiert der Testleiter die Begriffe mit einer
optionalen Beschreibung. Bei geschlossenen Card-Sorting-Experimenten
werden zusätzlich die Namen der Kategorien angegeben (vgl. Abbildung
3.1(b)).
14

3.1 WeCaSo
(a) Fragebogen anlegen
(b) Begriffe und Kategorien definieren
Abbildung 3.1: Projekt in WeCaSo anlegen
15

3. Technische Grundlagen
Navigationsstruktur für Reverse-Card-Sorting-Projekte. Hier legt der Benutzer
die Navigationsstruktur fest und welche Begriffe in dieser Struktur gefunden
werden sollen.
Danksagung wird nach dem Beenden des Projekts angezeigt.
Bei einem geschlossenem Experiment hat der Benutzer zusätzlich die Möglichkeit,
das Experiment in mehreren Sprachen zur Verfügung zu stellen. Hierbei wird
neben dem vorhandenen Projekt ein neues Projekt angelegt. Der Benutzer muss
hierbei die Willkommensnachricht, Anleitung und Danksagung in die entsprechende
Sprache übersetzen. Bei den Punkten Fragebogen und Begriffe und Kategorien
werden die in der Ursprungssprache definierten Felder angezeigt und es muss der
jeweilige Begriff in die neue Sprache übersetzt werden.
Die genaue Durchführung des Projekts wird hier nicht beschrieben, da diese
durch die hier entwickelte Applikation ersetzt wird.
Jedes durchgeführte Projekt wird anonym in der Datenbank gespeichert. Eine
Auswertung erfolgt nicht direkt in WeCaSo. Die Ergebnisse können als CSV oder
XML Datei exportiert werden. Zur Auswertung kann das von Sebastian Emmrich
[Emm08] entwickelte Casolysis 2 verwendet werden.
3.1.2 Aufbau der WeCaSo Datenbank
Für die Durchführung eines in WeCaSo angelegten Projekts muss auf die Datenbank
zugegriffen werden. Im folgenden werden die in dieser Anwendung benötigten
Tabellen beschrieben. Es wird lediglich auf die Spalten einer Tabelle eingegangen,
die von der hier zu entwickelnden Anwendung benötigt werden.
project__base enthält pro Experiment genau eine Zeile und stellt grundlegende
Werte für das Projekt bereit von denen in dieser Anwendungen die folgenden
Werte benötigt werden:
project_id ist die eindeutige Id des Projekts.
2 Download unter http://cardsort.cs.upb.de/_files/downloads/casolysis26-10-2008.
jar, aufgerufen am 08.01.2013
Handbuch unter http://cardsort.cs.upb.de/_files/downloads/handbuch.pdf, aufgerufen
am 08.01.2013
16

3.1 WeCaSo
type gibt an, ob es sich um ein offenes, geschlossenes oder ein reverse Card-
Sorting-Experiment handelt.
url_name ist der eindeutige Name des Projekts, der für das Laden des Projekts
benötigt wird.
multiple_insert ist ein boolescher Wert der angibt, ob mehrfaches Verwenden
eines Begriffs erlaubt ist.
hierarchy ist ein boolescher Wert der festlegt, ob hierarchisches Einfügen
erlaubt ist.
project__meta dient als generischer Speicher und kann pro Experiment beliebig
viele Zeilen enthalten. In dieser Tabelle sind neben Log-Einträgen auch die
in der Anwendung benötigten Daten für die Willkommensnachricht, die Anleitung
und die Danksagung enthalten. Die Zuordnung der Daten zu einem
Projekt wird über die project_id als Fremdschlüssel vollzogen.
project__questions enthält die Fragen für ein Projekt. Jede Zeile dieser Tabelle
repräsentiert eine Frage. Für die Anwendung werden folgende Spalten
benötigt:
question_id ist die eindeutige Id der Frage.
project_id legt über einen Fremdschlüssel fest, zu welchem Projekt die
Frage gehört.
question_text ist die eigentliche Frage als String.
question_type legt den Typ der Frage fest. Freie Fragen kann der Testteilnehmer
durch Eingabe eines Textes beantworten. Dagegen bekommt er
bei den anderen beiden Fragetypen Antworten vorgegeben. Von diesen
entweder nur eine (Single Choise) oder mehrere (Multiple Choise)
ausgewählt werden dürfen.
is_required gibt an, ob die Beantwortung der Frage optional ist oder beantwortet
werden muss.
project__questions_answers enthält die Antwortmöglichkeiten für geschlossene
Fragen. Jede Zeile stellt eine Antwortmöglichkeit dar. Aus dieser Tabelle
werden die Spalten question_id, die den Fremdschlüssel zu der entsprechenden
Frage enthält und text, in der die Antwortmöglichkeit als String
hinterlegt ist.
17

3. Technische Grundlagen
experiment__data enthält die Begriffe und Kategorien mit denen das Experiment
durchgeführt werden soll. Aus dieser Tabelle werden die nachfolgenden
Spalten benötigt:
data_id ist die eindeutige Id des Begriffs oder der Karte.
data_type legt fest, ob es sich um eine Karte (item) oder Kategorie (pile)
handelt.
project_id ist der Fremdschlüssel zur Verbindung mit einem Projekt.
value gibt den Namen des Begriffs oder der Kategorie an.
description wird mit einem Wert belegt, wenn beim Anlegen des Projekts
zu einem Begriff eine Beschreibung angegeben ist.
3.2 Multitouch-Tisch
Unter Touch-Systemen versteht man berührungssensitive Eingabegeräte, die in
der Regel direkt auf einem Bildschirm angebracht sind. Bekannt sind solche Eingabegeräte
schon länger bei sogenannten Sensorbildschirmen. Zu finden sind diese
z.B. an Schaufenstern von Apotheken, Informationsterminals auf Messen oder an
Sehenswürdigkeiten und Industrieanlagen. Die Sensorbildschirme haben den Vorteil,
dass sie leicht zu reinigen und geringer anfällig gegenüber Vandalismus sind,
als dies bei einer Tastatur oder Maus der Fall ist. Bei diesen Geräten liegt der
Fokus darauf, Maus und Tastatur äquivalent zu ersetzen. Sie akzeptieren daher
in der Regel nur ein Eingabegerät, also einen Finger. Bei dieser Technik liegt ein
Netz aus feinen elektrischen Adern über dem Bildschirm, woraus die Position der
Eingabe errechnet werden kann.
Im Gegensatz dazu sind berührungssensitive Eingabegeräte, die mehrere Eingaben
gleichzeitig verarbeiten können, sogenannte Multitouch-Geräte, bis zum Jahr
2007 der breiten Öffentlichkeit nahezu unbekannt.
3.2.1 Geschichte der Multitouch-Geräte
Durch das Erscheinen des iPhones von Apple sind berührungssensitive Eingabegeräte
mit Multitouch-Unterstützung über Nacht berühmt geworden. Aber auch
Microsoft bringt im Jahr 2007 ein Multitouch System auf den Markt, das Microsoft
Surface, später unter dem Namen Microsoft PixelSense vertrieben. Das Microsoft
18

3.2 Multitouch-Tisch
Surface ist ein 30 Zoll großer Multitouch-Tisch, der vor allem für kollaborative
Aufgaben im Bereich Freizeit und Arbeit konzipiert ist.
Multitouch-Systeme entstehen im Jahr 2007 jedoch nicht aus dem Nichts. Die
Entwicklung dieser Systeme lässt sich bis in das Jahr 1982 zurückverfolgen, wie
Bill Bution, Forschungsleiter bei Microsoft Research, auf seiner Webseite [Bux07]
zur Geschichte von Multitouch-Systemen beschreibt.
In diesem Jahr entwickelt Nimish Mehta ein System, dass auf einer gefrorenen
Glasplatte beruht. Auf dieser können Bilder gezeichnet werden und von einer
unter der Scheibe platzierten Kamera erfasst werden. Da die Glasplatte durch den
Frost weiß ist und an den Stellen, an denen die Finger das Bild zeichnet, schwarze
Flecken entstehen, kann die Kamera auf diese Farbunterschiede reagieren und der
Computer das Bild auswerten.
Die heute weit verbreiteten kapazitiven Displays zum Erkennen von Multitouch-
Eingabegeräten gehen sogar bis in das Jahr 1965 zurück. E.A. Johnson beschreibt
in diesem Jahr ein funktionierendes Verfahren für Touch-Screens.
Ebenfalls keine völlige Neuentdeckung sind Greifgesten (Pinch), wie sie in nahezu
allen neuen Multitouch Systemen vorkommen. Diese lassen sich bis in das Jahr
1983 zurückdatieren.
In diesem Zusammenhang ist Bill Buxton [Bux07] voll zuzustimmen, wenn er
kritisiert, dass im Marketing gerne von der großen Erfindung gesprochen wird,
obwohl es das nicht ist, sondern das Ergebnis von jahrzehntelanger Forschung.
3.2.2 Technik
Durch die jahrzehntelange Forschung kann auch nicht von dem Multitouch-System
gesprochen werden. Vergleicht man den Microsoft Surface mit Apples iPhone, sieht
man, dass der Benutzer mit beiden Geräten fast das gleiche machen kann, die Entwickler
jedoch auf zwei völlig unterschiedliche Techniken setzen.
Während bei dem Microsoft Surface die Erkennung von Gesten durch eine, im unteren
Bereich des Tisches installierte, Kamera erfolgt, kommen bei Smartphones
und Tablets größtenteils kapazitive Displays zum Einsatz.
Einen guten Überblick über die unterschiedlichen Techniken bietet die Studie
Multi-Touch - Technologie, Hard-/Software und deren Anwendungsszenarien von
Dieter Spath u.a. [SHL + 12]. Aus dieser Studie werden die gängigsten Techniken
im folgenden vorgestellt.
19

3. Technische Grundlagen
Diffused Illumination
Beim Diffused Illumination wird das Bild mit einem Beamer auf eine matte Acrylplatte
projiziert. Eine Kamera, die mit einem Filter ausgestattet ist, der sichtbares
Licht filtert und nur infrarotes List durchlässt, observiert die Acrylplatte aus Sicht
des Beamers. Außerdem wird der Tisch mit Infrarotstrahler ausgestattet, die die
Platte möglichst gleichmäßig bestrahlen.
Je mehr sich ein Finger der Acrylplatte nähert, desto mehr infrarotes Licht wird
von dem Finger reflektiert und von der Kamera als weißer Punkt erfasst. Da in Sonnenstrahlen
viel infrarotes Licht enthalten ist, kann diese Technik nicht im Freien
oder in von Sonnenstrahlen beleuchteten Räumen eingesetzt werden. Optimal ist
bei dieser Technik ein abgedunkelter oder mit künstlichem Licht ausgestrahlter
Raum.
Die Vorteile dieses Systems sind, dass der Bildschirm für eine Geste nicht berührt
werden muss, sondern auch schon eine Annäherung erkannt wird. Außerdem gibt
es bei diesem System keine Einschränkung bei der gleichzeitigen Berührung mit
mehreren Finger. Nachteilig ist jedoch die große Bauweise dieses Systems, dafür
ist es aber für große und überdimensionale Anzeigen geeignet.
Des Weiteren kann das System die Umrisse von Objekten erkennen, die sich auf
der Platte befinden.
Frustrated Total Internal Reflection
Abbildung 3.2: Unterbrechung der Totalreflexion
Quelle: Spath u.a.[SHL + 12]
Der Aufbau des Frustrated Total Internal Reflection (FTIR) Systems ist dem
des Diffused Illumination (DI) sehr ähnlich. Im Gegensatz zum DI erfolgt die Infrarotbestrahlung
nicht aus der Projektionssicht. Die Lichtquellen werden bei diesem
20

3.2 Multitouch-Tisch
System am Rand platziert und beleuchten dabei eine klare Acrylglasplatte. Das
System basiert auf dem Effekt der Totalreflektion, der dafür sorgt, dass die Platte
durch die Lichtquellen gleichmäßig bestrahlt wird. Durch den Einsatz der klaren
Acrylglasplatte muss darüber oder darunter eine zusätzliche Projektionsfläche angebracht
werden, da sonst das Bild vom Beamer nicht auf der Platte dargestellt
werden kann.
Berührt ein Finger die Scheibe, so wird die Totalreflektion unterbrochen und das
Licht trifft auf den Finger. Dieser reflektiert das Licht senkrecht durch die Scheibe
zur Kamera (vgl. Abbildung 3.2).
Bei diesem System können ebenfalls beliebig viele Berührungspunkte erkannt werden.
Es hat jedoch auch den gleichen Nachteil im Hinblick auf externe Infraroteinstrahlung.
Im Gegensatz zum DI muss ein tatsächlicher Kontakt zur Platte
bestehen. Es reicht keine Annäherung, wie beim DI. Objekte, die auf der Platte
platziert werden, können nur teilweise erkannt werden. Die Objekte müssen
bestimmte Materialeigenschaften und ein Mindestgewicht vorweisen. Das System
ist, wie das DI, für große und überdimensionale Displays geeignet, benötigt jedoch
ebenfalls einen großen Unterbau
Projektiv-Kapazitive Verfahren
Abbildung 3.3: Darstellung eines projektiv-kapazitiven Multitouch-Screens
Quelle: Spath u.a.[SHL + 12]
Das wohl bekannteste Multitouch System ist das Projektiv-Kapazitive Verfahren.
Dieses Verfahren kommt bei Geräten zum Einsatz, die sehr kompakt konzi-
21

3. Technische Grundlagen
piert sein müssen, wie Smartphones oder Tablets.
Bei diesem System werden über das Display verschiedene transparente Schichten
mit Sende- und Empfangsantennen gelegt (vgl. Abbildung 3.3). Das Erkennen
einer Berührung wird durch Messen der Spannungen in den Empfangsantennen
berechnet. Dadurch das ein Finger die Oberfläche berührt, lässt die kapazitive
Kopplung in den umgebenden Bereichen des Bildschirms nach. Durch diesen Spannungsabfall
werden die Berührungspunkte relativ exakt ermittelt.
Die Anzahl der Finger, die das System gleichzeitig berühren, ist wie in den beiden
vorherigen Systemen, beliebig. Der Nachteil dieses Systems ist, dass es keine Umrisse
von Objekten erkennen kann, die auf dem Display abgelegt sind. Das System
kann sehr flach konzipiert werden, eignet sich allerdings nur für kleine Displays.
Infrarot-Lichtvorhang
Bei dem System des Infrarot-Lichtvorhangs werden an zwei sich nicht gegenüberliegenden
Kanten infrarote Lichtquellen montiert, die dadurch auf einer Glasplatte
ein Gitter bilden. An den jeweils gegenüberliegenden Seiten werden Infrarot-
Empfangseinheiten angebracht. Bei diesem System ist keine Kamera oder Projektor
nötig. Unter der Glasscheibe wird lediglich ein Display verbaut. Der Glasscheibe
kommt in diesem System keine funktionale Bedeutung zu. Sie dient lediglich
dem Schutz des Displays.
Wird die Glasplatte berührt, so wird die Lichtverbindung zwischen den dazwischenliegenden
Sende- und Empfangseinheiten in x- und y-Richtung unterbrochen.
Daraus kann die Position der Berührung errechnet werden. Berühren mehrere Finger
gleichzeitig die Glasplatte, so kommt es zu Verdeckungseffekten. Das heißt, es
werden Berührungen erkannt, die gar keine sind. Beispielsweise wenn Finger 1 den
Punkt (a,b) berührt und Finger 2 den Punkt (c,d), so wird auch Punkt (c,b) als
Eingabe erkannt.
Laser Light Plane
Die Laser Light Plane ist, abgesehen davon, wie die Finger von den Infrarotstrahlen
beleuchtet werden, von der Funktionsweise und dem Aufbau mit dem FTIR
und DI identisch. Bei dieser Technologie werden jedoch ein oder mehrere Lasermodule
verwendet, die auf dem Display eine Oberfläche aus Infrarotlicht aufspannen.
Wird diese Fläche von etwas durchbrochen, so erkennt dies die Infrarotkamera.
22

3.2 Multitouch-Tisch
Die Vor- und Nachteile dieses Systems sind ebenfalls mit denen der FTIR und DI
in allen wichtigen Punkten identisch.
Infra Red Light Plane
Das Infra Red Light Plane System ist technisch und in der Funktionsweise ähnlich
dem IR Light Plane. Die Unterbrechung der Lichtquellen wird von den eingebauten
Sensoren erkannt und durch Algorithmen in Bewegungsdaten umgerechnet.
Das System kann lediglich zwei Punkte gleichzeitig erkennen. Dafür kann die
Eingabe berührungsfrei erfolgen und es werden auch Umrisse, wie z.B. eine Hand
erkannt. Das System ist für kleine und große Displays geeignet und ermöglicht
eine flache Bauweise.
3.2.3 Mr. T
Abbildung 3.4: Multitouch-Tisch MisterT
Der in der Arbeitsgruppe Mensch-Computer-Interaktion vorhandene Multitouch-
Tisch ist im Rahmen einer Masterarbeit geplant und gebaut worden. Sein Name
ist Mr. T (vgl. Abbildung 3.4).
Die Oberfläche des Tisches besteht aus einer 8mm dicken Glasscheibe mit Projektionsfolie.
Die Projektionsfolie ist von oben auf der Glasplatte angebracht, damit
23

3. Technische Grundlagen
neben Multitouch-Eingaben auch Objekte, die auf dem Tisch liegen, als solche
durch die Kamera erkannt werden können.
Im Inneren des Tisches befindet sich ein Full-HD Projektor, der das Bild von unten
auf die Glasscheibe projiziert.
In jeder Ecke des Tisches sind Laser angebracht, die auf der Oberfläche einen Laserteppich
bilden. Wird die Glasoberfläche berührt, so werden die Laserstrahlen
gebrochen und nach unten geleitet. Durch zwei PS3 Kameras werden diese umgeleiteten
Laserstrahlen erfasst und die Position auf der Glasplatte berechnet.
Durch die hohe Bilddatenverarbeitung ist der Multitouch-Tisch an eine leistungsstarken
Desktop-PC mit Intel i7 Prozessor und einer ATI Radeon HD 5970 angeschlossen.
3.3 Entwicklungsumgebung
Diese Applikation wird mit der Entwicklungsumgebung Microsoft Visual Studio
2010 als Microsoft .NET 4.0 Anwendung erstellt. Für die Erstellung der Oberfläche
kommt das Microsoft Framework Windows Presentation Foundation (WPF)
zum Einsatz.
WPF zeichnet sich vor allem dadurch aus, dass Präsentation und Geschäftslogik
getrennt sind. Das wird vor allem dadurch deutlich, dass beim Erstellen der Oberfläche
die Auszeichnungssprache XAML (Extensible Application Markup Language)
zum Einsatz kommt. XAML beschreibt den Aufbau der Oberfläche bzw. noch
wichtiger die Hierarchie innerhalb der Oberfläche in einem XML-basiertem Stil.
Eine weitere Stärke von WPF ist ein auflösungsunabhängiges und vektorbasiertes
Renderingmodul. Dieses Renderingmodul nutzt zur Berechnung nicht, wie früher
üblich, die CPU, sondern den Prozessor der Grafikkarte (GPU) [Mica].
Zur Entwicklung von Multitouch Anwendungen wird ferner das Microsoft Surface
2.0 SDK benötigt. Dies ist eine Erweiterung von WPF und Microsoft XNA. Das
SDK stellt die Unterstützung zur Erkennung von Fingereingaben zur Verfügung.
Außerdem stellt es spezielle Oberflächenelemente zur Verfügung, die direkt Fingereingaben
erkennen und spezielle Operationen, wie das Drehen oder Vergrößern
des Elements unterstützen.
Für die Entwicklung der Geschäftslogik kommt die von Microsoft entwickelte Programmiersprache
C# zum Einsatz.
24

4 Multitouch-Gesten
4.1 Einführung
Trotz der unterschiedlichen Systeme zur Erkennung von Gesten, können die gleichen
Gesten auf nahezu allen Multitouch Systemen durchgeführt werden. Ausnahmen
sind hier die Systeme, die nur eine begrenzte Anzahl von gleichzeitigen
Eingaben verarbeiten können.
Die Entwicklung von Interaktionsgesten ist in den vergangenen Jahren immer
mehr in den Fokus der Forschung gerückt. Mike Wu u.a. [WSR + 06] kritisieren an
den bisherigen Arbeiten allerdings:
While many interesting gestural interaction techniques have been proposed,
their design has been mostly ad-hoc and has not been presented
within a contructive design framework
Der Fokus liegt somit zu Anfang darauf, was funktioniert und nicht wie es funktioniert,
was auch durchaus adäquat ist. Sollen allerdings Interaktionsgesten für
die breite Öffentlichkeit bereitgestellt werden, sollten grundlegende Funktionen
durch einheitliche Gesten durchgeführt werden können. Bei der Entwicklung eines
neuen Dateiexplorers für ein Desktop-Computer, würde kein Entwickler auf die
Idee kommen, den Doppelklick für etwas anderes zu benutzen, als das Öffnen eines
Ordners oder einer Datei.
Das Ziel von Wu u.a. [WSR + 06] ist ein Designkonzept für neue Multitouch Gesten
zu erstellen, die durch den Benutzer leicht zu verstehen und auszuführen sind. Sie
haben dafür die folgenden drei Design-Prinzipien entwickelt:
Gesture Registration wird durch eine ausgeprägte Haltung am Anfang festgelegt.
Diese legt den Rahmen für den dynamischen und abschließenden Teil fest.
25

4. Multitouch-Gesten
Gesture Relaxation sorgt für den dynamischen Teil. Das heißt, das Ausführen
der Geste soll den Benutzer nicht anstrengen, wie es für kurze Zeit während
der Registrierungsphase der Fall ist.
Gesture and Tool reuse bezieht sich auf den Einsatz der gleichen Geste, einschließlich
der Haltung der Hand und der Finger, die die Oberfläche berühren,
um verschiedenen Aufgaben zu erfüllen.
Nach diesen Design-Prinzipien entwickeln Wu u.a. [WSR + 06] mehrere grundlegende
Gesten und haben diese durch Benutzertests verifizieren lassen. Eine dieser
Gesten ist die Cut/Copy and Paste Geste. Ziel dieser Geste ist es, einen Bereich
der Oberfläche auszuwählen und zu kopieren oder auszuschneiden und an anderer
Stelle wieder einzufügen. Dies soll mit einer ununterbrochenen Geste geschehen.
In der Gesture Registration Phase wird mit der Hand der zu kopierende oder auszuschneidende
Bereich ausgewählt. Während der Gesture Relaxation Phase wird
der Bereich feiner gewählt. Anschließend wird der gewählte Bereich verschoben.
In der anderen Hand hat der Benutzer einen Stylus Stift. Befindet sich der Stift
auf dem Element, auf dem die Aktion gestartet wird, so wird der selektierte Bereich
kopiert. Ist der Stylus Stift auf einem anderen Bereich des Tisches wird der
verschobene Bereich ausgeschnitten.
Hier ist ein weiterer Vorteil von Multitouch-Gesten zu erkennen. Mit einem Desktop-
Computer ist der zu kopierende Bereich auszuwählen. Daran anschließend muss
über das Menü gewählt werden, ob dieser kopiert oder ausgeschnitten werden soll.
Im Anschluss daran muss über das Menü die Aktion Einfügen gewählt werden. Da
das Programm nicht weiß, an welcher Stelle der Ausschnitt wieder eingefügt werden
soll, wird dieser an einer beliebigen Stelle eingefügt. Der Benutzer muss das
kopierte oder ausgeschnittene Bild danach an die gewünschte Stelle bewegen. Diese
Einzelschritte werden bei Wu u.a. [WSR + 06] in einer Geste vereint. Auch werden
zwei Aktionen mit dieser Geste bewältigt, abhängig von der Position des Stiftes.
Beim Kopieren hält der Benutzer das ursprüngliche Element fest. Es wird also
nur kopiert. Beim Ausschneiden wird das Element nicht festgehalten und deshalb
ausgeschnitten. In dieser Arbeit wird zwar zwischen Finger und Stift unterschieden,
es ist aber keine Schwierigkeit diese Geste auch mit zwei Fingern umzusetzen.
Somit steht ein erstes Designkonzept zur Verfügung. Es ist jedoch kritisch zu
betrachten, dass Wu u.a. [WSR + 06] die Gesten als Experten selber entwickeln.
26

4.2 Multitouch-Gesten für Card-Sorting
Die Benutzer werden nicht in die Entwicklung miteinbezogen, ihnen werden die
Gesten nur erklärt und sie müssen sie ausführen.
Wie in der Einleitung dieser Arbeit ausgeführt, ist es erforderlich spätere Benutzer
an der Entwicklung teilhaben zu lassen (vgl. Kapitel 1.1). Dieses Problem
erkennen auch Jacob O. Wobbrock u.a. [WMW09]. Sie lassen in einer Studie Testteilnehmer,
die bisher keine Erfahrung mit Multitouch-Geräten haben, Gesten für
27 grundlegende Aktionen durchführen. Dazu gehören u.a. das Verschieben von
Elementen, Löschen, Zoomen, Vervielfältigen usw. Jede dieser Aufgaben sollten
die Benutzer mit einer und mit zwei Händen ausführen.
Insgesamt werden im Rahmen dieses Experiments 1080 Gesten protokolliert und
zusammen mit dem laut Gedachten der Testteilnehmer analysiert. Die jeweils am
meisten benutzte Geste wird in die Sammlung von Gesten übernommen. Diese
Sammlung ist konfliktfrei und beinhaltet immerhin 57% aller benutzten Gesten.
Zusammengefasst kommen Wobbrock u.a. [WMW09] zu folgendem Ergebnis:
Our findings indicate that users rarely care about the number of fingers
they employ, that one hand is preferred to two, that desktop idioms
strongly influence users’ mental models, and that some commands elicit
little gestural agreement, suggesting the need for on-screen widgets.
Somit folgt für die Entwicklung von Gesten, dass diese möglichst so erstellt werden
sollten, dass sie mit einer Hand auszuführen sind. Dagegen kümmern sich die
Benutzer selten um die Anzahl der eingesetzten Finger. Das bedeutet, dass völlig
unterschiedliche Funktionen nicht mit einer Geste ausgeführt werden sollten, die
sich nur über die Anzahl der eingesetzten Finger unterscheidet.
Einen weiteres Problem ist, dass die Testpersonen den Multitouch-Tisch stark
mit einem Computer in Verbindung bringen, der durch die Maus nur ein Zeiger
hat und der Benutzer auch nicht direkt mit der Oberfläche in Kontakt kommt.
Es ist somit für die Benutzer zu Anfang schwierig, die Bedienmöglichkeiten eines
Multitouch-Systems voll auszuschöpfen.
4.2 Multitouch-Gesten für Card-Sorting
Es gib bereits diverse desktopbasierte Applikationen, mit denen Card-Sorting
Experimente durchgeführt werden können (vgl. Kapitel 2.3). Einen Ansatz zur
Durchführung von Card-Sorting Experimenten auf einem Multitouch-Tisch gibt
27

4. Multitouch-Gesten
es bislang noch nicht. Man könnte jetzt natürlich die Frage stellen, ob es effektiv
ist, solch eine Multitouch Anwendung umzusetzen.
Genau mit dieser Frage beschäftigen sich Chris North u.a. [NDL + 09]. In ihrer
Arbeit haben Testpersonen die Aufgabe, Objekte auf einem physischen Tisch (vgl.
Abbildung 4.1(a)), einem Multitouch Tisch (vgl. Abbildung 4.1(b)) und an einem
Desktop-PC mit der Maus (vgl. Abbildung 4.1(c)) zu sortieren. Das Szenario des
Sortierens ist auch Hauptbestandteil in Card-Sorting-Experimenten.
(a) Physische Variante
(b) Desktop-Variante
(c) Multitouch-Tisch-Variante
Abbildung 4.1: Aufbau des Benutzertests von North u.a.
Quelle: North u.a.[NDL + 09]
Vor dem Experiment sind von North u.a. [NDL + 09] Gesten für den Multitouch-
Tisch definiert worden, von denen man annimmt, dass die Testpersonen diese aus
der physischen Welt übernehmen werden. Diese vergleichen sie mit den tatsächlich
von den Testpersonen gewählten Gesten. Des Weiteren wird untersucht, wie
schnell die Testpersonen die Aufgaben erledigen. Außerdem wird untersucht, wie
sehr sich die Testpersonen von der physischen oder computergestützten Durchführung
beeinflussen lassen.
Die Aufgabe ist, viele verschieden farbige Elemente nach ihrer Farbe zu sortieren.
28

4.2 Multitouch-Gesten für Card-Sorting
Es soll dabei auch untersucht werden, wie die Testpersonen diese Elemente gruppieren
und verschieben.
An der Untersuchung nehmen 32 Personen teil, die hauptsächlich Forscher und
Softwareentwickler sind, jedoch keine Erfahrung mit Multitouch-Systemen haben.
Jeder Benutzer führt nur zwei der drei Aufgaben durch, wobei der Multitouch-
Tisch in jeder Aufgabe vorkommt. Die Testteilnehmer werden in die folgenden
vier Gruppen aufgeteilt:
1. Gruppe fängt mit dem Sortieren am physischem Tisch an und wechselt anschließend
an den Multitouch-Tisch.
2. Gruppe hat die gleiche Aufgabe wie die erste Gruppe, allerdings in umgekehrter
Reihenfolge.
3. Gruppe sortiert die Elemente erst am Desktop Computer und anschließend am
Multitouch-Tisch.
4. Gruppe hat die gleiche Aufgabe wie die dritte Gruppe, allerdings in umgekehrter
Reihenfolge.
Aus den Ergebnissen der Sortierungsaufgaben lassen sich einige interessante
Aspekte für die Entwicklung einer Card-Sorting-Applikation für den Multitouch-
Tisch extrahieren. Wie die vorherigen Studien schon feststellen, nehmen die Testpersonen
einen Multitouch-Tisch oft als Computer wahr. Bei diesem Experiment
versuchen immerhin 56% den Finger als Maus zu benutzen. Für Multiselektion
wird jedoch auch versucht einen weiteren Finger zu benutzen. Noch interessanter
ist die Tatsache, dass 50% der Testteilnehmer, die mit der Aufgabe am Desktop-
Computer beginnen, konsequent damit weiter machen, den Finger als Maus zu
benutzen. Im Gegensatz dazu benutzen nur bei 25% der Teilnehmer den Finger
als Maus, die mit dem Sortieren am physischen Tisch starten.
Wird bei diesen Zahlen bedacht, dass es sich bei den Testpersonen um Leute handelt,
die tagtäglich am Computer sitzen, sind 25% schon relativ niedrig. Beim
Card-Sorting kann unterstellt werden, dass es häufig nicht solche Experten sind.
Haben diese Personen das Card-Sorting bisher nur an einem normalen Tisch ausgeführt,
bestehen gute Chancen, dass sie sich auf einer Multitouch-Anwendung
für Card-Sorting gut zurechtfinden werden.
Die Testteilnehmer die das physische und Multitouch-Tisch Experiment durchführen,
erkennen auch schnell die Grenzen eines Multitouch-Tisches. Aktionen, wie
29

4. Multitouch-Gesten
Objekte außerhalb des Arbeitsbereichs zu platzieren, Objekte aufnehmen oder auf
dem Tisch zu verschieben, ohne ein anderes Objekt zu berühren, werden auf dem
physischen Tisch sehr oft gemacht, während das auf dem Multitouch-Tisch kaum
festzustellen ist.
Allerdings muss auch ein anderer Umstand beleuchtet werden. Sinnvolle Gesten,
die aus der physischen Welt übernommen werden könnten, werden teilweise nicht
übernommen. So haben z.B. auf dem physischen Tisch 38% der Teilnehmer beim
Verschieben eines Objekts über eine längere Distanz die Hand gewechselt, auf dem
Multitouch-Tisch kein einziger.
Im Ergebnis lässt sich feststellen, dass Benutzer in einem Multitouch-Tisch eine
Mischung aus physischem Tisch und Desktop-Computer sehen. Sie nutzen jedoch
nicht immer die Vorteile der beiden Systeme, sondern machen es sich teilweise
schwerer als es nötig wäre.
Wichtig ist auch das Ergebnis der letzten Aufgabe. In dieser wird die Zeit gemessen,
die für die Sortierungen benötigt wird. Hier stellen North u.a. [NDL + 09]
fest, dass das Sortieren mit der Maus immer langsamer ist, als auf einem physischen
Tisch oder Multitouch-Tisch. Das Sortieren auf dem physischen Tisch geht
in allen Kombinationen schneller. Die Teilnehmer, die erst an dem physischen
Tisch sitzen und anschließend an den Multitouch-Tisch wechseln, sind auf dem
Multitouch-Tisch signifikant schneller als bei allen anderen Kombinationen. Auch
dies ist ein weiteres Argument für eine Multitouch Anwendung für die Durchführung
von Card-Sorting-Experimenten.
Im Folgenden werden mögliche Gesten für alle Aktionen, die zur Durchführung
von Card-Sorting-Experimenten benötigt werden, vorgestellt und entsprechende
Vor- und Nachteile gegeneinander abgewägt.
4.2.1 Karte verschieben
Eine der unumstrittenste Geste auf einem Multitouch-Tisch ist die zum Verschieben
von Elementen. Unabhängig davon, ob Wu u.a [WSR + 06] mit den selbst
definierten Gesten, Wobbrock u.a. [WMW09] mit den von Benutzern erstellten
Gesten oder andere wissenschaftliche Ausarbeitungen zu diesem Thema herangezogen
werden, wird immer die gleiche Geste beschrieben.
Mit einem Finger wird das zu verschiebende Element festgehalten, so dass es sich
30

4.2 Multitouch-Gesten für Card-Sorting
Abbildung 4.2: Verschieben von Karten
Quelle: Wobbrock u.a.[WMW09]
unter dem Finger befindet. Mit diesem Finger wird die Karte anschließend an die
Stelle verschoben, an der der Benutzer diese platzieren möchte. Zum endgültigen
Platzieren lässt der Benutzer die Karte wieder los.
Diese Geste sollte auf jeden Fall auch für das Card-Sorting gewählt werden. Sie ist
für die Aktion praktisch Standard und gibt dem Benutzer während der gesamten
Ausführung ein visuelles Feedback.
4.2.2 Karte kopieren
Zum Kopieren von Elementen auf einem Multitouch-Tisch gibt es diverse Ansätze.
(a) Kopieren durch Ziehen
(b) Kopieren durch Tab-Geste
Abbildung 4.3: Kopieren von Karten
Quellen: 4.3(a) Frisch u.a.[FHD09] 4.3(b) Wobbrock u.a.[WMW09]
Salvator Fuentes u.a. [FSHC11], die das Multitouch-Framework InnovaTouch
entwickeln, arbeiten vor allem über die Anzahl der Finger. So wird das kopieren
gestartet, indem der Benutzer mit vier Fingern das zu kopierende Element berührt.
Zum Einfügen der Kopie wird ebenfalls mit vier Fingern die Stelle berührt,
an der die Kopie eingefügt werden soll.
Diese Geste ist sehr an einen Desktop Computer angelehnt, trotz der Tatsache,
31

4. Multitouch-Gesten
dass vier Berührungspunkte nötig sind. Im Ergebnis der Arbeit von Wu u.a.
[WSR + 06] wird ausgeführt, dass „die Studie ebenfalls die Wichtigkeit von visuellem
Feedback während der Gesteninteraktion herausstellte“ 1 Ziel einer Geste
sollte es also sein, eine komplette Aktion 2 in einer ununterbrochenen Geste durchzuführen,
was hier nicht der Fall ist.
Des Weiteren ist diese Geste auch schwer zu merken. Mit vier Fingern, die für
diese Aktion nötig sind, kann niemand das Kopieren in Verbindung bringen. Zu
dieser Einschätzung kommen Fuentes u.a. [FSHC11] allerdings im Ergebnis ihrer
Arbeit selber, indem sie ausführen, dass „[...] die Lernkurve für die copy/paste
Gesten nicht so glatt war wie wir erwartet haben.“ 3
Ein weiterer Kritikpunkt ist die Fläche, die benötigt wird, um vier Finger auf dem
Multitouch-Tisch zu platzieren. Die Karten müssten eine entsprechende Größe haben,
was jedoch, aufgrund der nicht allzu langen Namen der Begriffe, in der Regel
nicht nötig ist.
Die benutzerdefinierte Geste von Wobbrock u.a [WMW09] zum Duplizieren eines
Elements (vgl. Abbildung 4.3(b)) geht in die gleiche Richtung, wie bei Fuentes
u.a. [FSHC11]. Hier ist jedoch nur ein Finger nötig, um das entsprechende Element
zu duplizieren. Es gibt hier allerdings auch ein, wenn auch wenig aussagekräftiges,
visuelles Feedback, welches Element kopiert wird. Das Element wird während des
Kopiervorgangs mit einer Markierung versehen.
Nachdem die Gesten von Fuentes u.a. [FSHC11] und Wobbrock u.a. [WMW09]
nicht überzeugen können, soll die Geste von Wu u.a. [WSR + 06] zum Duplizieren
von Elementen betrachtet werden. Dort wird zwar ein Bildausschnitt kopiert, es
ist jedoch kein Problem, dies auf das Card-Sorting zu übertragen. Der Benutzer
hält mit einem Finger den zu kopierenden Bildausschnitt fest und zieht mit dem
anderen Finger eine Kopie an das Ziel.
Das visuelle Feedback ist während der gesamten Ausführung gegeben. Der Benutzer
verschiebt den Bildausschnitt, hält diesen jedoch an der ursprünglichen Stelle
1 Übersetzt aus dem Englischen. Original: The study also highlighted the importance of visual
feedback throughout a gesture interaction.
2 Hier: Kopieren einer Karte und an anderer Stelle wieder einfügen
3 Übersetzt aus dem Englischen. Original: [...] the learning curve for the copy/paste gestures
was not as smooth as we expected.
32

4.2 Multitouch-Gesten für Card-Sorting
fest, so dass dieser im übertragenen Sinn nicht weggezogen werden kann.
Eine weitere interessante Arbeit ist in diesem Zusammenhang die Arbeit von
Matthias Frisch u.a. [FHD09]. Sie entwickeln ein Konzept zum Erstellen von Graphen
auf einem Multitouch-Tisch. In dieser Arbeit wird das Kopieren ebenfalls so
gehandhabt, wie bei Wu u.a. [WSR + 06].
Im Ergebnis sollte die von Wu u.a. [WSR + 06] und Frisch u.a. [FHD09] vorgestellte
Geste zum Kopieren benutzt werden (vgl. Abbildung 4.3(a)). Die Gesten
der beiden erst genannten Arbeiten lehnen sich zu sehr an Desktop Systeme an,
ohne ein vernünftiges visuelles Feedback zu bieten. In der jetzt gewählten Geste
hat der Benutzer ein ständiges visuelles Feedback und kann schnell eine Verknüpfung
zwischen Kopieren und der Geste herstellen. Der Ablauf der Geste sollte
somit wie folgt sein.
1. Der Benutzer berührt mit zwei Fingern die zu kopierende Karte.
2. Ein Finger bleibt auf der Karte, während der andere Finger eine Kopie der
Karte bewegt.
3. Am Ziel wird die Kopie der Karte losgelassen. Anschließend auch die festgehaltene
Karte.
4.2.3 Karte löschen
Es soll möglich sein, duplizierte Karten wieder zu löschen. Initial vorhandene Karten
dürfen nicht gelöscht werden. Auch hierfür gibt es verschiedene Wege, diese
Funktion in einer Multitouch-Geste umzusetzen.
Bei der Arbeit von Wu u.a. [WSR + 06] kann der Anwender auf den Multitouch-
Tisch schreiben. Das Geschriebene konnte dann gelöscht werden.
In der Registrierungsphase muss der Benutzer die Faust auf den zu löschenden
Bereich legen und während der Durchführungsphase mit einer flachen Hand den
Text wegwischen. Diese Geste ist relativ aufwendig umzusetzen, da es sich um
einen Kontaktpunkt handelt und anhand der Größe der berührten Fläche berechnet
werden muss, ob es sich um einen Finger oder eine Faust handelt. Vor allem
ist hier die Unterscheidung bei Extremen relativ schwierig. Es wird fast unmöglich
33

4. Multitouch-Gesten
(a) Löschen durch Wischen
(b) Löschen durch Verschieben
nach außen
Abbildung 4.4: Löschen von Karten
Quellen: 4.4(a) Frisch u.a.[FHD09] 4.4(b) Wobbrock u.a.[WMW09]
sein zwischen einer Kinderfaust und einem dicken Finger eines Erwachsenen zu
unterscheiden. Außerdem werden die Karten wahrscheinlich kleiner sein als die
Faust oder die Hand, so dass es bei eng aneinanderliegenden Karten zu Seiteneffekten
kommen kann. Es könnten Karten gelöscht werden, die ursprünglich nicht
gelöscht werden sollten. Außerdem ist diese Geste wegen der zu geringen Größe
der Karten nicht praktikabel.
Die gleiche Kritik, die im vorherigen Kapitel an der Arbeit von Fuentes u.a.
[FSHC11] angebracht wird, kann in diesem Kapitel wiederholt werden (vgl. Kapitel
4.2.2). In der Arbeit soll das Löschen mit doppeltem Berühren von drei Fingern
auf dem zu löschenden Element durchgeführt werden. Die Geste ist schwer merkbar
und kann auch nicht mit physischen Gegebenheiten oder Computeraktionen
verknüpft werden. Sie sollte aus diesen Gründen ebenfalls ausscheiden.
Frisch u.a. [FHD09] haben in ihrer Arbeit zwei Gesten zum Löschen festgelegt.
Bei der einen wird, wie bei Wu u.a. [WSR + 06] eine Wischgeste verwendet, allerdings
mit einem Finger und nicht mit der ganzen Faust/Hand (vgl. Abbildung
4.4(a)). Hier würde der Effekt nicht mehr auftreten, dass versehentlich andere
Karten mitgelöscht werden.
Die andere von Frisch u.a. [FHD09] vorgestellte Geste löscht ein Element, indem es
nach außerhalb des Bildschirms gezogen wird (vgl. Abbildung 4.4(b)). Diese Geste
scheint am praktikabelsten zu sein. Der Benutzer bekommt immer ein visuelles
Feedback und man kann es mit der wirklichen Welt in Verbindung setzen, indem
34

4.2 Multitouch-Gesten für Card-Sorting
man sagt, die Karte wird vom Tisch geworfen bzw. außerhalb des Sichtbereichs
verschoben.
Ein weiteres Argument für diese Geste ist, dass Wobbrock u.a. [WMW09] diese
als die von den Testpersonen favorisierte Geste beschreiben.
Zusammengefasst sollte die Geste zum Löschen von duplizierten Karten so entwickelt
werden, dass der Anwender die Karte berührt und diese an einen beliebigen
Rand des Multitouch-Tisches verschiebt (vgl. Abbildung 4.4(b)). Wird der Finger
außerhalb des für Eingaben überwachten Bereichs gezogen, so soll die duplizierte
Karte gelöscht werden. Wird dieses mit einer nicht duplizierten Karten durchgeführt,
so soll diese neben dem äußeren Rand abgelegt werden.
4.2.4 Beschreibung eines Begriffs
In WeCaSo können zu jedem Begriff Beschreibungen hinzugefügt werden. Zur Anzeige
dieser Beschreibungen sollte ein so genannter Tooltip dienen. Zum Aktivieren
dieses Tooltips sollte die entsprechende Karte einmal berührt werden und wieder
losgelassen werden. Der Tooltip verschwindet nach einer gewissen Zeit oder wenn
die Karte verschoben wird.
Dies ist eine Standard-Aktion, um einen Tooltip anzuzeigen und sollte demnach
auch so verwendet werden.
4.2.5 Hierarchisches Einfügen
Für das hierarchische Einfügen von Karten muss zunächst eine Unterkategorie
innerhalb einer bestehenden Kategorie erstellt werden. Dies geschieht dadurch,
dass eine Karte innerhalb einer Kategorie zu einer Unterkategorie wird. In wissenschaftlichen
Arbeiten konnte keine Lösung zu so einer Anforderung gefunden
werden. Es stehen verschiedene Optionen zur Verfügung.
Wird eine Karte auf eine Karte geschoben, die sich in einer Kategorie befindet,
könnte die Karte in der Kategorie zu einer Unterkategorie werden und die geschobene
Karte in diese neue Unterkategorie eingefügt werden. Dies ist allerdings sehr
fehleranfällig, da eine Karte auch versehentlich auf eine andere geschoben werden
kann und der Benutzer diese in die Kategorie einfügen wollte. Eine andere Option
wäre eine Karte eine gewisse Zeit über eine Karte in einer Kategorie zu halten.
Durch visuelles Feedback soll angezeigt werden, dass aus dieser Karte eine Un-
35

4. Multitouch-Gesten
terkategorie erstellt wird, wenn der Benutzer die Karte an dieser Stelle loslassen
würde. Diese Option ist weniger fehleranfällig und könnte durchaus so umgesetzt
werden.
Eine dritte Alternative wäre den Vorgang des Verschiebens zu beginnen und mit
Name
Abbildung 4.5: Hierarchisch Einfügen
einen Finger der anderen Hand die Karte in einer Kategorie zu berühren, die zu
einer Unterkategorie werden soll (vgl. Abbildung 4.5). Sobald der Finger die Karte
in der Kategorie berührt, wird diese zu einer Unterkategorie und als solche dargestellt.
Wird der Vorgang abgebrochen, wird die Karte, die zur Unterkategorie
werden sollte, wieder zu einer normalen Karte.
Die dritte Option scheint für diese Aktion am geeignetsten zu sein. Man suggeriert
mit dem Finger der zweiten Hand, dass die Karte nicht auf der anderen Karte
platziert werden soll, sondern hier, wo der Finger drauf zeigt, eingefügt werden
soll.
4.2.6 Gruppieren von Karten
Gruppieren von Karten zu einer Kategorie ist essentieller Bestandteil bei der
Durchführung von Card-Sorting-Experimenten. Bei der Gruppierung sollte die
Testperson nicht von vorgeschriebenen Faktoren der Anwendung beeinflusst werden.
Dies unterstreicht Jasmin Kuhn [Kuh12] in ihrer Bachelorarbeit:
Anders als bei klassischen Card Sorting setzt WeCaSo voraus, dass zuerst
die Gruppennamen gebildet werden. Eine Möglichkeit diese Reihenfolge
zu umgehen besteht darin zwar Felder für Gruppennamen zu
erzeugen, diese jedoch vorerst nicht auszufüllen. Diese Vorgehensweise
36

4.2 Multitouch-Gesten für Card-Sorting
ermöglicht es den Testpersonen Begriffe erst zusammen zu gruppieren
und jeder Gruppe anschließend einen Namen zu geben. Werden die
Gruppennamen zu Beginn festgelegt, so besteht die Gefahr, dass sich
der Proband zu früh auf eine bestimmte Kategorie fixiert und Zusammenhänge
zwischen Begriffen nicht mehr unvoreingenommen wahrnehmen
kann.
Der Benutzer sollte somit erst die Möglichkeit bekommen, Elemente in Gruppen
vorzusortieren. Dies ist auf dem Multitouch-Tisch kein Problem, da die Karten
beliebig positioniert werden können. Das Überführen dieser Gruppen sollte mit
einfachen Gesten umsetzbar sein.
Gruppieren von Elementen ist auch zumeist Bestandteil der Arbeiten die in den
vorangegangenen Kapiteln dieses Abschnittes untersucht werden. Daneben gibt
es auch Arbeiten, die sich ausschließlich mit dem Gruppieren von Elementen auf
dem Multitouch-Tisch beschäftigt haben.
Wu u.a. [WSR + 06] haben dafür die Pile-n-Browse Geste entwickelt (vgl. Abbildung
4.6). Bei dieser werden beide Hände aufrecht auf die Oberfläche des Tisches
gelegt. Alle sich dazwischen befindlichen Karten werden durch aufeinanderzubewegen
der Hände auf einen Stapel geschoben.
Ähnlich geht Dzmitry Aliakseyeu [ASLG06] in seiner Arbeit vor. Er beschäftigte
sich mit dem Navigieren, Reorganisieren und Umpositionieren von Stapeln. Neben
dieser Arbeit gibt es noch diverse andere Arbeiten, die in diese Richtung gehen.
Das hat auch den Grund, dass der Multitouch-Tisch Microsoft Surface vor allem
dem kollaborativen Arbeiten dient. Hier macht es durchaus Sinn, Gruppen von
Elementen auf einen Stapel zu legen und diese anschließend beiseite zu legen oder
einem anderen Mitarbeiter zu übergeben.
Für das Card-Sorting ist dieses Prinzip jedoch nur bedingt geeignet. Es wäre in
diesem Fall immer nur die obere Karte sichtbar. Der Benutzer sollte in der Lage
sein, zu überblicken, welche Begriffe sich bereits in der Gruppe befinden, um entscheiden
zu können, ob eine neu der Gruppe hinzugefügte Karte dort hinein passt
oder durch die neu hinzugefügte Karte die Gruppierung eventuell geteilt werden
muss.
Ein weiteres Argument, die gegen ein Gruppieren mittels Stapel spricht, ist die
Größe der Karten. Während in den zitierten Arbeiten Fotos oder ganze Dokumente
37

4. Multitouch-Gesten
gruppiert werden, müssen beim Card-Sorting lediglich relativ kleine Karten gruppiert
werden. Des Weiteren ist ein Card-Sorting fast nie so groß, dass man bei der
Anzahl der Karten den Überblick verlieren könnte oder der Platz für die Karten
nicht ausreicht und diese sich überdecken.
(a) Gruppieren durch sequenzielles Berühren
(b) Gruppieren durch Lasso-
Selektion
Abbildung 4.7: Gruppieren von Karten mit allgemeinen Gesten
Quelle: Wobbrock u.a.[WMW09]
Abbildung 4.6: Gruppieren mit
Pile-n-Browse
Quelle: Wu u.a.[WSR + 06]
Zum Selektieren von Elementen, was im all-
gemeinen einer Gruppierung entspricht, auf dem
Multitouch-Tisch haben Frisch u.a. [FHD09]
und Wobbrock u.a. [WMW09] jeweils zwei Gesten
definiert. Zum einen, indem eine Karte
festgehalten wird und nach und nach durch
Berühren weiterer Karten diese der Gruppe
hinzugefügt werden (vgl. Abbildung 4.7(a)).
Dieses Verfahren scheidet für das Card-Sorting
generell aus, da es für mehrere Gruppen zur
gleichen Zeit nicht praktikabel ist. Es könnte
höchstens für jede Gruppe die jeweiligen Karten
verschieden eingefärbt werden. Wichtig ist
bei mehreren Gruppen aber auch das Gesetz
der Nähe. Dies wäre in diesem Fall leicht verletzbar.
Die zweite Geste, die beide Arbeiten definieren,
ist die sogenannte Lasso-Selektion (vgl.
Abbildung 4.7(b)). Mit einem Finger werden
alle Karten einer Gruppe umrandet. Nachdem
eine Umrandung fertig ist, könnte anschließend ein Algorithmus dafür sorgen, dass
die Karten sinnvoll ausgerichtet werden und somit direkt eine übersichtliche Grup-
38

4.2 Multitouch-Gesten für Card-Sorting
pe für die Kategorie entsteht. Außerdem ist es bei dieser Methode möglich mehrere
unterscheidbare Gruppen darzustellen, die leicht auseinander gehalten werden können.
Es können hier auch Karten hinzugefügt werden, die automatisch durch das
Programm eingeordnet werden und unter Umständen die Umrandung vergrößern.
Des Weiteren ist es damit auch kein Problem zwei Gruppen zusammenzufügen.
Auch hier müsste das Programm dafür sorgen, dass die Elemente vernünftig angeordnet
werden und die Umrandung an die Größe der Gruppe angepasst wird.
Das Gruppieren bzw. Selektieren mit einem Lasso ist bereits aus klassischen
Desktop-Umgebungen bekannt, lässt sich jedoch auch gut in einer Multitouch
Anwendung realisieren und wird von den Benutzern intuitiv genutzt. Dies zeigt
die Tatsache, dass es bei Wobbrock u.a. [WMW09] als favorisierte Geste verwendet
wird.
(a) (b) (c) (d) (e)
Abbildung 4.8: Gruppieren von Karten mit Blasen
Quelle: Watanabe u.a.[WWI07]
Einen ganz anderen Ansatz verfolgten dagegen Nayuko Watanabe u.a. [WWI07].
Sie gruppieren Elemente mit Hilfe von Blasen (vgl. Abbildung 4.8). Dazu wird
jedes einzelne Element von einem Kreis (der Blase) umrandet. Wenn sich zwei
Elemente berühren, so verschmelzen die jeweiligen Blasen zu einer einzigen Blase
(vgl. Abbildung 4.8 (a)-(c)). Dies ist natürlich mit allen Blasen möglich, unabhängig
davon wie viel Elemente diese enthalten. Es sind auch Operationen innerhalb
einer Blase möglich. So kann die gesamte Blase verschoben werden, es können
auch einzelne Elemente aus der Blase gezogen werden. Wird ein Element aus der
Blase gezogen, wird die Blase an der austretenden Stelle vergrößert. Irgendwann
ist der Abstand so groß, dass die Blasen in zwei Teile auseinandergerissen werden.
Es bleibt die ursprünglich Blase, die unter Umständen etwas verkleinert wird und
eine kleine Blase mit nur dem heraus gezogenen Element übrig (vgl. Abbildung
4.8 (c)-(e)). Dieser Effekt lässt sich ebenfalls bei Seifenblasen beobachten und ist
39

4. Multitouch-Gesten
somit der physischen Welt ähnlich und gut merkbar.
Abbildung 4.9: Gruppieren teilen
Quelle: Watanabe u.a.[WWI07]
Eine Blase kann auch geteilt werden, indem ein Finger durch die Blase gezogen
wird und die Elemente rechts und links der gezogenen Linie in zwei Blasen aufgeteilt
werden. (vgl. Abbildung 4.9)
Die Umsetzung dieses Gruppierungsprinzips wird schwer zu realisieren sein, da
hier viele Berechnungen im Bezug auf die Positionierung während des Verschiebens
notwendig sind. Allerdings ist das Konzept aus dem Desktop-Bereich gänzlich
unbekannt und aus diesem Grund für eine Multitouch Anwendung sehr gut geeignet,
auch weil die visuellen Rückgaben sehr intuitiv sind. Das Verhalten der Blasen
lässt sich, wie schon beschrieben, sehr gut aus der physischen Welt übertragen.
Es stellt sich trotz des guten Designs die Frage, ob eine solche Gruppierung
sinnvoll ist bzw. von Benutzern positiv angenommen wird. Dieser Frage haben
sich Florian Geyer u.a. [GHR12] in ihrer Benutzerstudie gewidmet. In dieser vergleichen
sie ob es effektiver ist, eine Gruppe zu erstellen und anschließend die
Elemente dort hineinzuziehen bzw. Elemente grob vorzusortieren und um diese
eine Gruppe zu zeichnen, wie dies bei der Lasso-Selektion der Fall ist oder das
von Watanabe u.a. [WWI07] entwickelte Prinzip der Gruppierung mit Blasen zu
verwenden.
Die Benutzerstudie ist von Geyer u.a. [GHR12] folgendermaßen durchgeführt:
Users were given the task to group and regroup 30 colored rectangles
into clusters according to five different colors. In order to avoid carryover
effects, six participants started with the Bin and the other six
started with the Bubble condition. Each task covered a grouping and a
regrouping phase: First, the rectangles appeared distributed randomly
on the display. Then, users were asked to group shapes freely according
40

4.2 Multitouch-Gesten für Card-Sorting
to their colors. After a five second break, the colors of the shapes were
shuffled and participants had to regroup the objects again. Compared
to the grouping phase, the rectangles were now already clustered, forcing
a regrouping. The whole task procedure consisted of 16 trials (4
runs x 2 interface conditions x 2 phases), whereby the first run was
practice and was excluded from data analysis.
Für das Card-Sorting ist hier vor allem die Phase interessant, in der die Benutzer
die über die gesamte Fläche verteilten Elemente gruppieren. Das Gruppieren aus
den Blasen heraus, nachdem die Farben innerhalb der jeweiligen Gruppen ausgetauscht
werden, sind ebenso interessant, werden aber im Bereich des Card-Sortings
nicht stark in Anspruch genommen werden.
Aus den Ergebnissen der Studie ergibt sich, dass die Testteilnehmer im Durchschnitt,
über alle Aufgaben gesehen, für das Gruppieren mit Blasen 54 Sekunden
benötigten. Dagegen benötigten die Testteilnehmer für das andere Verfahren im
Durchschnitt 87 Sekunden. Das Gruppieren mit Blasen ist also signifikant schneller.
Das Umgruppieren ist in beiden Fällen ungefähr gleich schnell. Hier ergibt sich zumindest
kein Nachteil für das Gruppieren mit Blasen. Zusammenfassend kommen
Geyer u.a. [GHR12] zu folgendem Ergebnis:
The findings of our study showed that the proximity concept is more
beneficial for grouping tasks on a digital surface than the traditional
container concept. Participants interacted more often with multiple fingers
and both hands, which depicts that grouping based on proximity
is capable of harnessing more advantages of bimanual and multi-touch
interaction than grouping based on containment.
Maßgeblich für dieses Ergebnis ist sicherlich auch, dass Gruppieren mit Blasen
in einem Desktop-System nicht zum Einsatz kommt. Die Anwender werden somit
nicht auf Computerinteraktionen zurückgreifen, was in den allgemeinen Gesten
fast immer der Fall ist, sondern mehr eine Beziehung zur physischen Welt aufbauen.
Diese Methode ist zudem intuitiv und muss nicht aufwendig erklärt oder
erlernt werden.
41

4. Multitouch-Gesten
Zusammengefasst lässt sich feststellen, dass das Prinzip der Blasen sowohl mit
Blick auf die Zeit, die zum Sortieren benötigt wird, als auch im Hinblick auf die
Nutzerakzeptanz die favorisierte Geste für das Gruppieren von Karten sein sollte.
Gruppierung verschieben
Wie Wu u.a. [WSR + 06] beschreiben, sollten gleiche Aufgaben auch mit gleichen
Gesten durchgeführt werden. Somit sollte das Verschieben von Gruppen genauso
geschehen, wie das Verschieben der Karten (vgl. Kapitel 4.2.1). Wegen des
Fat-Finger Problems sollte die Initialisierungsphase von der des Verschiebens von
Karten allerdings unterschiedlich sein. Karten werden mit einem Finger über die
Oberfläche verschoben. Gruppen sollten mit zwei Fingern verschoben werden. Damit
wäre es immer noch die gleiche Geste, aber ohne die Gefahr, dass der Anwender
versehentlich eine Karte verschiebt. Bei vollen Gruppen ist es, gerade mit dicken
Fingern, schwierig eine noch nicht mit Karten bedeckte Fläche zu finden.
Ein Problem, sich diese Unterscheidung zu merken, sollten die Anwender in der
Regel nicht haben. Ein Finger für ein kleines Element (die Karten) und zwei Finger
für ein großes Element (die Gruppierung).
Gruppierung löschen
Von dem im vorherigen Abschnitt gesprochenen Wiederverwendbarkeit von Gesten
sollte beim Löschen von Gruppierungen verzichtet werden. Die Geste zum
Löschen einer Karte (vgl. Kapitel 4.2.3) ist bei einer Gruppierung nicht sinnvoll.
Es soll schließlich nur die Gruppierung und nicht die Elemente innerhalb dieser
Gruppe gelöscht werden. Es würde sich zwangsläufig die Frage stellen, an welche
Position die Karten der Gruppe platziert werden, wenn die Gruppe an den Rand
des Multitouch-Tisch verschoben wird. Soll die ursprüngliche Position der Karten
gespeichert werden und an dieser wieder eingefügt werden oder an der Stelle platziert
werden, an der die Gruppe gelöscht wurde?
Für diesen Fall käme die von Frisch u.a. [FHD09] alternativ beschriebene Geste
in Frage (vgl. Abbildung 4.4(a)). Dort wird durch mehrmaliges Wischen nach
rechts und links über ein Element dieses gelöscht. Für diese Geste spricht, dass
die Elemente, die sich in dieser Gruppierung befinden an der Stelle bleiben und
lediglich die visuelle Umrandung wegfällt. Für die Karten wird eine solche Geste
nicht Praktikabel sein. Mit einem Finger, der über die Karte wischt, wird diese
verschoben. Das soll auch nicht geändert werden. Eine zweite Möglichkeit wäre,
42

4.2 Multitouch-Gesten für Card-Sorting
diese Aktion mit zwei Fingern durchzuführen. Dann würde aber, sofern sich eine
Karte in einer Gruppe befindet, die Gruppe verschoben. Die Aktion mit noch mehr
Fingern auszuführen macht noch weniger Sinn, da die Karten nicht groß genug
sind.
In Abwägung aller Vor- und Nachteile muss für diesen Fall leider von dem
Grundsatz abgewichen werden, gleiche Funktionen mit gleichen Gesten auszuführen.
4.2.7 Experiment beenden
Eine Geste zum Beenden einer Multitouch-Anwendung konnte in wissenschaftlichen
Ausarbeitungen nicht gefunden werden. Diese wird in der Anwendung allerdings
benötigt, da nach Beendigung des Experiments Daten in die Datenbank
geschrieben werden müssen. Das Schließen über den Standard-Schließen-Button
in der oberen rechten Ecke des Applikationsfensters ist auf Grund der Größe des
Tisches keine optimale Lösung. Der Benutzer müsste einmal quer über den Tisch
greifen, um den Button zu erreichen. Außerdem ist dieser nicht für Fingereingaben
konzipiert, so dass sich wieder das Fat-Finger Problem stellt.
Eine zweite Alternative wäre das Einfügen eines Menüs. Da bislang nicht zu erkennen
ist, dass mehrere Menüeinträge nötig sind, macht ein Menü für eine Aktion,
die einmalig ausgeführt wird, wenig Sinn. Ein Button zum Beenden des Experiments
sollte aus diesen Gründen ebenfalls ausscheiden.
Da Windows 8 auf die Bedienung mit Multitouch Gesten ausgelegt ist, gibt es
für diese Anforderung eine Geste zum Beenden von Metro Apps. Diese ist auf der
Homepage zu Windows 8 [Micb] wie folgt beschrieben:
Ziehen Sie die App über die Touch-Bedienung oder mit der Maus vom
oberen Bereich des Bildschirms zum unteren Bildschirmrand.
Je weiter sich Windows 8 verbreitet, umso mehr rechnen die Benutzer damit, dass
sich Anwendungen auf diese Weise schließen lassen. Das spricht für die Verwendung
der Geste in dieser Applikation.
43

5 Architektur der Applikation
Durch die Benutzung von Windows Presentation Foundation (WPF) ist die Implementierung
in zwei Teile aufgeteilt. Zum einen in die Präsentationslogik, die
die Gestaltung der Oberfläche mit der Markup Language XAML beschreibt (vgl.
Kapitel 5.2). Zum anderen in die Geschäftslogik, in der die Funktionen der Anwendung
in der Programmiersprache C# geschrieben sind (vgl. Kapitel 5.1).
5.1 Geschäftslogik
In diesem Kapitel werden die wichtigsten Funktionen und Klassen der Anwendung
beschrieben. Eine vollständige Übersicht der Softwarearchitektur bietet das
Klassendiagramm (vgl. Abbildung 5.1).
5.1.1 Datenanbindung an WeCaSo
Die mittels WeCaSo erstellten Card-Sorting-Projekte (vgl. Kapitel 3.1) werden in
einer MySQL Datenbank gespeichert. Es besteht in WeCaSo keine Schnittstelle
für den Zugriff auf die Projekte, so dass ein direkter Datenbankzugriff nötig ist.
Eine direkte Programmierschnittstelle für den Zugriff auf MySQL Datenbanken
ist in Visual Studio 2010 nicht vorhanden. Aus diesem Grund muss der MySQL
Connector/Net 1 installiert sein. Dieser Client wird in das Entwicklungsprojekt als
Referenz eingebunden und in den entsprechenden Klassen importiert.
Experimente laden
Für das Laden der Experimente werden Datenbankzugriffe auf die in Kapitel 3.1.2
vorgestellten Tabellen durchgeführt. Es sind insgesamt drei Datenbankabfragen
1 Download unter http://www.mysql.com/downloads/connector/net/, aufgerufen am
11.01.2013
45

5. Architektur der Applikation
=QuestionY}
mQuestionYin>questionId>1>intM>in>type>1>stringM>in>idRequired>1>boolM>in>questionText>1>stringM>in>answers>1>List*string>}
=answers>1>List*string>
=counter>1>int
=id>1>int
=isRequired>1>bool
=questionId>1>int
=questionText>1>string
=type>1>string
mAnswers>1>List*string>{READONLY}
mId>1>int{READONLY}
mIsRequired>1>bool{READONLY}
mQuestionId>1>int{READONLY}
mQuestionText>1>string{READONLY}
mType>1>string{READONLY}
Question
mCardItemYin>dataId>1>intM>in>text>1>stringM>in>description>1>stringM>in>isMultipleCard>1>bool>0>false}
=CardItemY}
mDeepCopyY}>1>CardItem
mSetCardPositionYin>center>1>PointM>in>orientation>1>double}
=counter>1>int
=canSetPosition>1>bool
=center>1>Point
=dataId>1>int
=description>1>string
=id>1>int
=isMultipleCard>1>bool
=orientation>1>double
=pileId>1>int
=text>1>string
mCanSetPosition>1>bool{READONLY}
mCenter>1>Point{READONLY}
mDataId>1>int{READONLY}
mDescription>1>string{READONLY}
mDraggedCard>1>Object
mId>1>int{READONLY}
mIsMultipleCard>1>bool
mOrientation>1>double{READONLY}
mPileId>1>int
mText>1>string{READONLY}
CardItem
=PileItemY}
mPileItemYin>text>1>stringM>in>isWritable>1>bool}
mPileItemYin>dataId>1>intM>in>text>1>stringM>in>isWritable>1>bool}
mSetPilePositionYin>center>1>Point}
=canSetPosition>1>bool
=center>1>Point
=counter>1>int
=dataId>1>int
=id>1>int
=isWritable>1>bool
=pileCards>1>Observablecollection*CardItem>
=text>1>string
mCanSetPosition>1>bool
mCenter>1>Point{READONLY}
mDataId>1>int{READONLY}
mDraggedPile>1>Object
mId>1>int{READONLY}
mIsWritable>1>bool{READONLY}
mPileCards>1>Observablecollection*CardItem>
mText>1>string
PileItem
mLoadExperimentItemsY}
mLoadInitialDataYin>projectName>1>string}>1>bool
mProjectYin>position>1>Point}
mConvertHTMLToPlaneTextYin>textToConvert>1>string}>1>string
=cardItemList>1>ObserverableCollection*CardItem>
=connectionString>1>string
=instructions>1>string
=multipleInsert>1>bool
=pileItemList>1>ObserverableCollection*PileItem>
=position>1>Point
=projectId>1>int
=projectName>1>string
=questions>1>List*Question>
=thanks>1>string
=type>1>string
=welcome>1>string
=wizardPage>1>string
mCardItemList>1>ObserverableCollection*CardItem>
mInstructions>1>string{READONLY}
mMultipleInsert>1>bool{READONLY}
mPileItemList>1>ObserverableCollection*PileItem>
mPosition>1>Point
mProjectName>1>string
mQuestions>1>List*Question>{READONLY}
mThanks>1>string{READONLY}
mType>1>string{READONLY}
mWelcome>1>string{READONLY}
mWizardPage>1>string
Project
mOnCardCollectionDragCompletedY}
mOnCardItemCollectionDropY}
mOnCardMoveY}
mOnCardTouchDownY}
mOnDragCanceledY}
mOnDropTargetDragEnterY}
mOnDropTargetDragLeaveY}
mOnListBoxItemAddedY}
mOnPileCardDragCompletedY}
mOnPileCardPreviewTouchDownY}
mOnPileCollectionTouchDownY}
mOnPileCollectionTouchMoveY}
mOnPileCollectionTouchUpY}
mOnPileDragCanceledY}
mOnPileDragCompletedY}
mOnPileDropY}
mOnPilePreviewTouchDownY}
mOnPileTouchUpY}
mOnPolygonTouchDownY}
mOnPolygonTouchMoveY}
mOnPolygonTouchUpY}
=cardItemList>1>ObserverableCollection*CardItem>
=currentProject>1>ObserverableCollection*Project>
=doubleTouchHasTimeAndPos>1>bool
=doubleTouchPoint>1>Point
=doubleTouchTime>1>TimeSpan
=pileItemList>1>ObserverableCollection*PileItem>
mCardItemList>1>ObserverableCollection*CardItem>
mCardItemSelectorList>1>ObserverableCollection*CardItemSelector>
mPileItemList>1>ObserverableCollection*PileItem>
MainWindow
mQuestionDataTemplateSelectorY}
mSelectTemplateYin>item>1>ObjectM>in>container>1>DependencyObject}>1>DataTemplate
=QuestionCheckBoxTemplate>1>DataTemplate
=QuestionRadioButtonTemplate>1>DataTemplate
=QuestoinTextBoxTemplate>1>DataTemplate
QuestionDataTemplateSelector
mInitProjectDataTemplateSelectorY}
mSelectTemplateYin>item>1>ObjectM>in>container>1>DependencyObject}>1>DataTemplate
=InitInstructions>1>DataTemplate
=InitLoadProject>1>DataTemplate
=InitQuestions>1>DataTemplate
=InitWelcomeMessage>1>DataTemplate
=Thanks>1>DataTemplate
InitProjectDataTemplateSelector
j
jffC
Pffj
jffC
j
PffC
PffC
j
j
j
Abbildung 5.1: Klassendiagramme Card-Sorting-MTT
46

5.1 Geschäftslogik
nötig. Zuerst werden die grundlegenden Projektdaten, wie die Willkommensnachricht,
Anleitung und Danksagung geladen (vgl. Listing 5.1). Im Anschluss daran
werden die Fragen mit ihren jeweiligen Antworten aus der Datenbank geladen (vgl.
Listing 5.2). Zu guter Letzt werden die für die Durchführung des Experiments benötigten
Begriffe und Kategorien aus der Datenbank geladen (vgl. Listing 5.3).
Der Begriff %PROJECT_NAME% in den Listings ist ein Keyword und soll den
url-Namen des Projekts darstellen, den der Benutzer eingibt. Diese kleinschrittigen
Datenbankabfragen haben den Vorteil, dass die gewonnen Daten direkt in die
entsprechenden Datenstrukturen eingefügt werden können. Bei Kombination der
Abfragen wären unnötig viele Datenverarbeitungen nötig gewesen.
1 mysql > SELECT pb. project_id , pb.type , pb. multiple_insert
, pm.name , pm. text
2 FROM project__base AS pb LEFT JOIN project__meta AS pm
ON pb. project_id = pm. project_id
3 WHERE pb. url_name = ’% PROJECT_NAME %’
Listing 5.1: Experiment-Daten laden
1 mysql > SELECT pq. question_id , pq. question_type , pq.
is_required , pq. question_text , pqa . text
2 FROM project__questions AS pq LEFT JOIN
project__questions_answers AS pqa ON pq. question_id =
pqa . question_id
3 WHERE pq. project_id = currentProject . ProjectId
Listing 5.2: Fragebogen des Experiments laden
1 mysql > SELECT ed.data_id , ed. data_type , ed.value , ed.
description
2 FROM experiment__data AS ed LEFT JOIN project__base AS
pb ON ed. project_id = pb. project_id
3 WHERE pb. url_name = ’% PROJECT_NAME %’
Listing 5.3: Begriffe und Kategorien laden
47

5. Architektur der Applikation
Ergebnisse übertragen
Aufgrund der zu knappen Zeit und dem Fokus auf der Durchführung von Card-
Sorting Experimenten auf dem Multitouch-Tisch ist diese Funktion noch nicht
umgesetzt. Die Vorbereitungen für das Übertragen der Ergebnisse ist in der Applikation
berücksichtigt. Somit wird es keine große Schwierigkeit sein, diese Funktion
zu einem späteren Zeitpunkt in die Applikation einzufügen.
5.1.2 Projekt laden
Beim Starten der Applikation wird ein Objekt der Klasse Project angelegt. Dieses
Objekt enthält alle Daten, die für die Durchführung eines Projekts benötigt
werden.
Nach Eingabe eines gültigen Projektnamens im Wizard wird das Card-Sorting-
Projekt mit den Datenbankabfragen (vgl. Kapitel 5.1.1) durch die Methode Load-
InitialData() geladen. Innerhalb dieser Methode werden private Klassenvariablen
bedatet, die entweder Aussagen über die Projekteigenschaften machen 2 oder
Daten die der Benutzer für die Durchführung des Projekts benötigt 3 . Für alle
Variablen stehen schreibgeschützte Eigenschaftsfelder zur Verfügung, da diese im
späteren Verlauf entweder zur Darstellung oder innerhalb der Programmlogik benötigt
werden, aber nicht verändert werden dürfen.
Des Weiteren werden Listen für die Begriffe (cardItemList), Kategorien (pile-
ItemList) und Fragen (questions) erstellt. Während für die Fragen eine Liste
vom Datentyp List verwendet wird, kommen für Begriffe und Kategorien Listen
vom Datentyp ObservableCollection zum Einsatz. Der Grund ist, dass sich die
beiden Listen während der Laufzeit der Applikation verändern und diese Veränderungen
direkt auf der Oberfläche abgebildet werden müssen. Bei offenen Card-
Sorting-Experimenten werden z.B. die Kategorien erst zur Laufzeit erstellt und
die Karten diesen Kategorien zugeordnet. Die zugeordneten Karten müssen anschließend
aus der Liste der Begriffe entfernt werden. Im Gegensatz zu Listen vom
Typ List stellt eine ObservableCollection Benachrichtigungen bereit, die aus-
2 projectId für die Id des Projekts, type legt fest um welche Art von Card-Sorting-Experiment
es sich handelt und multipleInsert zum Bestimmen, ob Begriffe vervielfältigt werden dürfen.
3 welcome ist der String der die Willkommensnachricht enthält, instruction beinhaltet die
Anleitung für das Experiment und thanks repräsentiert die Danksagung am Ende des Experiments.
48

5.1 Geschäftslogik
gelöst werden sobald Elemente hinzugefügt oder entfernt werden. Die Oberfläche
reagiert auf diese Benachrichtigungen und passt diese entsprechend an.
5.1.3 Karten
Karten (Begriffe) werden durch die Klasse CardItem repräsentiert. Beim Auslesen
aus der Datenbank wird für jede Karte ein Objekt dieser Klasse erstellt. Das
Objekt erhält eine eindeutige Id, die für die programminterne Datenverarbeitung
genutzt wird. Des Weiteren werden aus der Datenbank neben dem Namen des
Begriffs auch die Beschreibung des Begriffs und die Id, die der Begriff in der Datenbank
besitzt, dem Objekt als Eigenschaft hinzugefügt. Als eindeutige Id für
eine Karte kann die Id aus der Datenbank nicht benutzt werden, da bei duplizierten
Karten diese nicht mehr eindeutig wäre. Das erstellte Objekt wird der
ObservableCollection cardItemList hinzugefügt.
Die Klasse stellt außerdem Variablen zur Verfügung, die für die Programmlogik
notwendig sind. Mit der Methode setPosition(Point center, double orientation)
kann die Position und Drehung der Karte auf der Oberfläche festgelegt
werden. Bei Karten die während der Durchführung dupliziert werden, wird die
Variable isMultipleCard = true gesetzt. Damit wird festgelegt, dass dieses Objekt
bzw. diese Karte gelöscht werden darf.
Auf jede der beschriebenen Variablen lässt sich über ein Eigenschaftsfeld von außen
zugreifen. Bis auf das Eigenschaftsfeld IsMultipleCard sind diese schreibgeschützt.
5.1.4 Kategorien
Wird ein geschlossenes Card-Sorting-Experiment geladen, wird nach dem Laden
des Projekts für jede Kategorie ein Objekt der Klasse PileItem erstellt. Dieses
Objekt bekommt beim Erstellen über eine statische Klassenvariable eine eindeutige
Id zugewiesen. Außerdem wird über die Variable text der Name der Kategorie
festgelegt. Wird ein offenes Card-Sorting-Experiment ausgeführt, werden die Kategorien
erst zur Laufzeit angelegt. Bei diesen Kategorien wird der Text auf Bitte
geben Sie einen Namen ein... festgelegt. Damit wird dem Benutzer signalisiert,
dass er die Kategorie benennen muss. Es besteht zwischen offenen und geschlossenen
Experimenten ein weiterer Unterschied. Während in geschlossenen Experimenten
der Name der Kategorie vorgegeben ist und nicht verändert werden darf,
49

5. Architektur der Applikation
ist dies bei offenen Experimenten erforderlich. Damit innerhalb der Programmlogik
dieser Umstand berücksichtigt wird, muss zusätzlich die Variable isWritable
gesetzt werden. Diese gibt an, ob die Benennung der Kategorie vom Benutzer
verändert werden darf. Jedes Objekt der Klasse PileItem wird der Observable-
Collection pileItemList hinzugefügt.
Optional können Kategorien über die Methode setPilePosition(Point center)
auf der Oberfläche positioniert werden. Dieses ist nötig, wenn z.B. zwei Kategorien
übereinander liegen. In diesem Fall soll eine Kategorie automatisch zu Seite
verschoben werden.
Zum Speichern von Karten in einer Kategorie besitzt jedes PileItem-Objekt eine
ObservableCollection pileCards. Beim Hinzufügen einer Karte in eine Kategorie
wird das Objekt der Karte der Sammlung hinzugefügt.
5.1.5 Interaktionen
In diesem Kapitel wird neben dem Verschieben von Elementen auf einem Multitouch-Tisch
das Zeichnen eines Polygons aus Sicht der Programmlogik vorgestellt.
Weitere Interaktionen werden nicht vorgestellt, da es den Rahmen der Arbeit
sprengen würde.
Die Bedienung der Oberflächen-Elemente, die im folgenden Kapitel 5.2 vorgestellt
werden, erfolgt größtenteils durch die Behandlung von Events, die von diesen
ausgelöst werden. Die Karten müssen zum Teil zwischen verschiedenen Steuerelementen
verschoben werden. Zur Realisierung ist Drag and Drop nötig.
Das Surface SDK 2.0 bietet mit der SurfaceDragDrop Klasse ein eigenständiges
Interface für diese Operationen. Diese Drag and Drop Klasse sorgt im wesentlichen
dafür, dass der Benutzer während der Drag and Drop Phase den Eindruck
bekommt, er würde das Element tatsächlich verschieben. Innerhalb der Anwendung
wird beim Berühren einer Karte ein visueller Cursor erstellt, der das Aussehen
des zu verschiebenden Elements einnimmt. Gleichzeitig wird das berührte
Element ausgeblendet. Für den Benutzer sieht es jetzt so aus, als ob er die Karte
unter seinem Finger habe. Die Karte kann jetzt beliebig verschoben werden. Wird
die Karte wieder abgelegt, muss zwischen zwei Fällen unterschieden werden. Wird
die Karte auf dem ursprünglichen Elternelement wieder abgelegt, wird die Position
der ausgeblendeten Karte auf die des Cursors gesetzt und anschließend sichtbar
gemacht. Im zweiten Fall wird das Element auf einem anderen Steuerelement ab-
50

5.2 Präsentationslogik
gelegt. Hier muss dafür gesorgt werden, dass die Daten der Karten dem anderen
Steuerelement hinzugefügt werden und im anderen Steuerelement gelöscht werden.
Eine weitere interessante Funktion ist das Zeichnen einer Gruppierung. Durch
Berühren eines beliebigen freien Bereichs auf der Oberfläche, wird ein Grafikobjekt
vom Type Polygon angelegt. Polygone bestehen aus einer Sammlung von Punkten,
die jeweils durch Linien zwischen den Punkten zu einer geschlossenen Form
verbunden werden. Der erste Punkt eines neuen Polygons ist der, der gerade vom
Finger berührt wird. Während der Finger über die Oberfläche wischt, wird durch
ein Event immer wieder die aktuelle Position des Fingers als Punkt der Sammlung
von Punkten hinzugefügt. So entsteht ein immer größer werdendes Polygon.
Während des Zeichnen kann es passieren, dass Steuerelemente, die eine höhere
Position in z-Richtung besitzen, die Zeichnung abbrechen lassen. Um dies zu verhindern,
wird während eines Zeichenvorgangs die Möglichkeit des Interagieren mit
diesen Elementen deaktiviert und erst wieder aktiviert, wenn durch Anheben des
Fingers das Zeichnen beendet wird.
5.2 Präsentationslogik
Nachdem im vorherigen Kapitel die Geschäftslogik grob beschrieben wurden, wird
in diesem Kapitel die Präsentationslogik, also der Aufbau der Oberfläche beschrieben.
Die Oberfläche der Applikation (vgl. Abbildung 5.2) besteht aus zwei übereinander
liegenden Steuerelementen vom Typ ScatterView, die über die gesamte
Größe der Anwendung gezogen sind. Dieses Steuerelement besitzt ein Container
in dem sich Steuerelemente vom Typ ScatterViewItem befinden. ScatterViewItems
sind auf Multitouch-Interaktionen ausgelegte Steuerelemente. Diese können z.B.
auf der Oberfläche beliebig verschoben oder gedreht werden.
Jede Karte und Kategorie wird jeweils von einem ScatterViewItem dargestellt. Das
Anlegen von ScatterViewItems wird durch die ObservableCollections cardItem-
List und pileItemList beeinflusst, die über Datenbindung als ItemsSource an
die ScatterViews gebunden werden. Das ist auch der Grund für die Verwendung
von zwei übereinander liegenden ScatterViews, da ein ScatterView jeweils nur eine
Liste als Quelle binden kann. Da in beiden Listen unterschiedliche Objekttypen
51

5. Architektur der Applikation
Abbildung 5.2: Oberfläche von Card-Sorting-MTT
gespeichert werden, ist ein Zusammenlegen nicht möglich.
Außerdem haben Karten und Kategorien ein anderes Design. Dieses Design wird
als DataTemplate über Datenbindung an die ScatterView-Eigenschaft ItemTemplate
gebunden. Das DataTemplate für die Karten besteht aus einem Rechteck
auf dem ein Label platziert ist. Dieses Label stellt den Begriff der Karte dar.
Dagegen ist das DataTemplate für die Kategorien komplexer. Im oberen Bereich
befindet sich eine SurfaceTextBox mit dem Namen der Kategorie. Abhängig vom
Typ des ausgeführten Card-Sorting-Experiments ist diese Textbox beschreibbar
oder schreibgeschützt. Im unteren Bereich befindet sich eine SurfaceListBox, die
alle Karten enthält, die dieser Kategorie zugeordnet sind.
Das Übereinanderlegen von ScatterView Steuerelementen stellt für die Programmlogik
kein Problem dar. Solange Steuerelementen kein Hintergrund zugewiesen
ist, sind diese für die Programmlogik praktisch nicht sichtbar. Das obere
ScatterView dient lediglich dazu, die ScatterViewItems für die Karten darzustellen.
Das untere ScatterView ist neben der Darstellung der Kategorien auch für die
Auswertung von Benutzerinteraktionen zuständig. Bei dieser Auswertung können
auch Elemente beeinflusst werden, die durch das obere ScatterView verwaltet werden.
Da die jeweiligen ScatterViewItems einen Hintergrund besitzen, kann auf diese
durch den Anwender auch zugegriffen werden. Der Anwender sieht von der Übereinanderlagerung
der Steuerelemente nichts. Für ihn liegen auf der Oberfläche
52

5.2 Präsentationslogik
lediglich Elemente mit Karten und Kategorien, mit denen er interagieren kann.
Zum Bilden von Gruppen ist es nötig auf der Oberfläche ein Polygon zu zeichnen.
Das Starten der Zeichnung kann durch ein Event, dass von dem unteren
ScatterView ausgelöst wird, gestartet werden. Es ist jedoch nicht möglich, das gezeichnete
Polygon dem ScatterView als Element hinzuzufügen. Hierzu ist ein Steuerelement
vom Type Canvas nötig. Auf Canvas können als Kindelemente beliebige
Grafikobjekte dargestellt werden. Das Canvas wird über den beiden ScatterViews
platziert und besitzt ebenfalls keinen Hintergrund, da keine direkten Interaktionen
mit diesem Steuerelement stattfinden.
53

6 Bedienung der Applikation
In diesem Kapitel wird die Durchführung von den aus WeCaSo geladenen Card-
Sorting-Projekten mit der entwickelten Applikation vorgestellt. Es wird erläutert,
wie ein Projekt geladen wird und mit welchen Gesten die einzelnen Aktionen
ausgeführt werden. Die Gesten werden jeweils mit Bildern aus der Anwendung
verdeutlicht. Die roten oder weißen Ovale, die sich auf den Bildern befinden, sind
durch den Microsoft Surface Input Simulator 1 simulierte Finger. Ist der simulierte
Finger rot eingefärbt bedeutet das, dass sich der Finger im direkten Kontakt mit
der Oberfläche befindet. Ist kein direkter Kontakt vorhanden, wird der simulierte
Finger weiß dargestellt.
6.1 Projekt laden
Nach dem Laden des Projekts muss sich der Benutzer die Willkommensnachricht
und Anleitung ansehen und einen Fragebogen ausfüllen. Diese Anforderung ist in
einem Wizard realisiert (vgl. Abbildung 6.1), durch den sich der Benutzer navigieren
muss, um am Ende mit dem Card-Sorting-Experiment beginnen zu können.
Aufgrund der Verwendung und Kombination von unterschiedlichen Steuerelementen
ist die farbliche Kombination von Schriftfarbe und Hintergrund teilweise mangelhaft.
Dies sollte im weiteren Verlauf der Entwicklung angepasst werden.
Nach dem Starten der Applikation wird der Benutzer aufgefordert einen Projektnamen
einzugeben (vgl. Abbildung 6.1(a)). Wie in Kapitel 3.1.2 beschrieben
ist dies der url_name, da dieser das Projekt eindeutig identifiziert. Den Namen
bekommt der Benutzer vom Testleiter genannt. Da an einem Multitouch-Gerät
keine physische Tastatur vorhanden ist, bekommt der Benutzer, sobald der Fokus
in das Textfeld gesetzt ist, eine virtuelle Tastatur angezeigt, über die der Projekt-
1 Online unter http://msdn.microsoft.com/en-us/library/ff727737.aspx, aufgerufen am
12.01.2013
55

6. Bedienung der Applikation
(a) Projektnamen eingeben
(b) Falscher Projektname eingegeben
(c) Willkommensnachricht
(d) Anleitung
(e) Fragebogen
Abbildung 6.1: Wizard zum Laden eines Projekts
56

6.2 Durchführung von Experimenten
name eingegeben werden kann.
Nach der Eingabe muss der Benutzer den Button Weiter berühren. Im Hintergrund
werden die Datenbankabfragen ausgeführt (vgl. Listings 5.1 und 5.2). Ist
der Projektname falsch geschrieben bzw. nicht in der Datenbank vorhanden, wird
dem Benutzer eine Fehlermeldung angezeigt (vgl. Abbildung 6.1(b)), dass das
Projekt nicht gefunden werden konnte. Ist der Name korrekt, wird die Willkommensnachricht
des geladenen Projekts angezeigt. Alternativ kann der Benutzer
mit Berühren des Buttons Schließen die Anwendung beenden.
Mit Anzeige der Willkommensnachricht (vgl. Abbildung 6.1(b)) befindet sich
der Benutzer in der eigentlichen Projektumgebung. Ab diesem Punkt wird der
Button Schließen durch den Button Abbrechen ersetzt. Beim Berühren von Abbrechen
wird die Ausführung des Projekts abgebrochen. Die Anwendung wird jedoch
nicht geschlossen, sondern der Dialog zur Eingabe des Projektnamens wird wieder
angezeigt. Damit kann der Benutzer wählen, ob ein neues Projekt geladen oder
die Applikation endgültig geschlossen werden soll.
Mit Berühren des Button Weiter wird die Anleitung angezeigt (vgl. Abbildung
6.1(c)). Ab dieser Seite wird der Button Zurück aktiviert, so dass der Benutzer
sich frei durch die Seiten des Wizards bewegen kann.
Nach Berühren des Buttons Weiter wird der Fragebogen angezeigt (vgl. Abbildung
6.1(d)). Einige der Fragen sind optional, die anderen müssen beantwortet
werden (vgl. Kapitel 3.1.1). Diese Prüfung ist noch nicht implementiert worden,
so dass der Fragebogen praktisch übersprungen werden kann, obwohl Pflichtfragen
vom Anwender nicht beantwortet worden sind. Der Button Weiter wird auf
dieser Seite durch den Button Fertig ersetzt. Nach Berühren des Buttons wird der
Wizard geschlossen und die Karten und Kategorien werden auf der Oberfläche
angezeigt.
6.2 Durchführung von Experimenten
Die zu einem Projekt gehörenden Karten und im Fall von geschlossenen Experimenten
zusätzlich die Kategorien werden zufällig über der Oberfläche verteilt
(vgl. Abbildung 5.2).
57

6. Bedienung der Applikation
6.2.1 Elemente verschieben
(a) Karte
(b) Kategorie
Abbildung 6.2: Verschieben von Karten und Kategorien
Die in Kapitel 4.2.1 und 4.2.6 beschriebenen Gesten zum Verschieben von Elementen
sind in dieser Anwendung identisch umgesetzt. Wie in Abbildung 6.2 zu
sehen ist, wird für das Verschieben einer Karte ein Finger benötigt und für das
Verschieben eines Stapels zwei Finger. Das ist notwendig, um zu unterscheiden
ob eine Karte in der Kategorie, die von einem Finger berührt wird, verschoben
werden soll oder die gesamte Kategorie.
Karten und Kategorien können beliebig auf der Oberfläche verschoben werden.
Wird eine Karten auf einer Kategorie abgelegt, so wird diese dort eingefügt. Das
Einfügen von Elementen ist in Kapitel 6.2.4 detailliert beschrieben.
6.2.2 Karten
Kopieren
Zum Kopieren einer Karte muss der Benutzer diese mit zwei Fingern berühren
(vgl. Abbildung 6.3(a)). Zum Erstellen der Kopie bleibt ein Finger auf der Karte
und mit dem anderen Finger wird die Kopie an die gewünschte Stelle gezogen
(vgl. Abbildung 6.3(b)). Ist die kopierte Karte an der gewünschten Position, können
die Finger die Berührung von den Karten lösen und der Kopiervorgang ist
abgeschlossen (vgl. Abbildung 6.3(c)).
Wie in den Abbildungen zu sehen ist, hat die kopierte Karte einen grünen Hintergrund,
während die anderen Karten einen roten Hintergrund haben. Kopierte
58

6.2 Durchführung von Experimenten
(a) (b) (c)
Abbildung 6.3: Karte kopieren
Karten dürfen im Gegensatz zu den vorhandenen Karten wieder gelöscht werden.
Damit der Benutzer ein direktes visuelles Feedback bekommt, welche Karten gelöscht
werden dürfen, haben die duplizierten Karten einen grünen Hintergrund.
Der rote Hintergrund der übrigen Karten soll dem Benutzer signalisieren, dass
diese nicht gelöscht werden dürfen.
Löschen
Abbildung 6.4: Karte löschen
Zum Löschen einer Karte muss diese an einen beliebigen Rand verschoben werden
(vgl. Abbildung 6.4). Verlässt der Finger mit einer duplizierten Karte den
äußeren Bereich der Anwendung, wird diese gelöscht. Handelt es sich nicht um
eine duplizierte Karte, wird die Karte am äußeren Rand eingefügt.
Beschreibung eines Begriffs
In WeCoSo-Projekten gibt es die Möglichkeit zu Begriffen eine Beschreibung anzugeben.
Diese Beschreibung ist in dieser Applikation mit Hilfe eines Tooltips
realisiert (vgl. Abbildung 6.5).
Tooltips sind aus Desktop-Anwendungen bekannt und werden angezeigt, sobald
59

6. Bedienung der Applikation
Abbildung 6.5: Einblenden der Beschreibung
der Mauszeiger ein Element berührt. Diese Möglichkeit besteht in einer Multitouch-
Anwendung naturgemäß nicht. In dieser Applikation wird der Tooltip angezeigt,
wenn die Karte kurz mit einem Finger berührt wird und bleibt anschließend ein
paar Sekunden geöffnet. Dieses Verhalten wird so von der Entwicklungsumgebung
angeboten und ist aus diesem Grund nicht verändert. Es werden nur Tooltips
angezeigt, wenn die Karte tatsächlich eine Beschreibung hat. Alternativ wäre zu
überlegen, ob bei diesen Karten ein Tooltip angezeigt wird, der dem Benutzer
sagt, dass keine Beschreibung vorhanden ist.
6.2.3 Karten gruppieren
Gruppierung erstellen
Testteilnehmer sortieren die Karten bei einem physischen Card-Sorting in der Regel
erst grob vor, bevor sie diese den Kategorien zuordnen. Außerdem beeinflusst
ein zu frühes Anlegen von benannten Kategorien die Entscheidungsfindung der
Testteilnehmer (vgl. Kapitel 4.2.6).
Diese Punkte sind bei der Entwicklung dadurch gelöst, dass der Benutzer, eine
benannte Kategorie nur anlegen kann, wenn er vorher eine Gruppierung gebildet
hat. Optimal wäre die Gruppierung von Karten durch das Prinzip der Blasen zu
realisieren (vgl. Kapitel 4.2.6). Wie bereits geschrieben ist der Implementierungsaufwand
sehr hoch und kann im Rahmen dieser Arbeit nicht realisiert werden.
Zum Erstellen einer Gruppierung ist die ebenfalls vorgestellte Lasso-Selektion
umgesetzt worden. Zum Starten einer Lasso-Selektion berührt der Benutzer einen
nicht durch Karten oder Kategorien verdeckten Bereich der Oberfläche (vgl. Abbildung
6.6(a)). Zum Ziehen des Lassos muss der Finger um die zu gruppierenden
Elemente gezogen werden. Während des Ziehens wird direkt ein Polygon erstellt,
60

6.2 Durchführung von Experimenten
(a) (b) (c)
Abbildung 6.6: Gruppierung erstellen
dass auf dem Weg, den der Finger zurücklegt, gezeichnet wird (vgl. Abbildung
6.6(b)). Sind alle zu gruppierenden Elemente innerhalb des Polygons kann der
Finger die Oberfläche verlassen. Die Benutzung eines Polygons zur Bildung eines
Lassos ist abweichend von Wobbrock u.a. [WMW09], die eine Linie um die Elemente
ziehen. Der Vorteil eines Polygons ist jedoch, dass eine direkte Umrandung
gezeichnet wird. Bei der Benutzung einer Linie müssen zusätzliche Fehlerbehandlungen
implementiert werden. So muss bedacht werden, was passiert wenn der
Benutzer keinen geschlossenen Kreis zeichnet. Soll die Linie automatisch zu einem
Kreis geschlossen werden oder die Erstellung abgebrochen werden?
Es können beliebig viele Gruppierungen zur gleichen Zeit auf der Oberfläche existieren.
Gruppierung verschieben
Das Verschieben einer Gruppierung wird nicht, wie am Anfang des Kapitels beschrieben
(vgl. Kapitel 6.2.1), mit zwei Fingern, sondern mit einem Finger durchgeführt.
Dazu muss ein nicht von einer Karte verdeckter Bereich innerhalb des
Polygons berührt werden. Danach wird das Polygon samt Inhalt an die gewünschte
Position verschoben.
Eine Umsetzung mit zwei Fingern wäre wünschenswert, aber mit der gewählten
Methode nicht möglich, da zur Positionsberechnung beide Finger berücksichtigt
werden. Dadurch kommt es zu dem Effekt, dass die Karten wahllos auf der Oberfläche
verstreut werden. Im Zuge der weiteren Entwicklung kann hierfür ein anderer
Weg eingeschlagen werden, der jedoch aufgrund der Zeitknappheit nicht mehr
realisiert ist.
61

6. Bedienung der Applikation
Gruppierung löschen
Durch das veränderte Verhalten beim Verschieben einer Gruppierung kann die
geplante Wischgeste nicht wie beschrieben umgesetzt werden (vgl. Kapitel 4.2.6).
Wischt man mit einem Finger über die Gruppierung, wird diese verschoben.
Die Geste zum Löschen einer Gruppierung ist daraufhin in eine Schüttelgeste
umgewandelt worden. Der Anwender muss die Gruppierung innerhalb einer kurzen
Zeitspanne je zweimal nach links und rechts bewegen. Ist das geschehen, wird das
Polygon, das die Gruppierung darstellt, gelöscht. Diese Geste ist für den Anwender
aufgrund des visuellen Feedbacks verständlich und leicht zu merken.
6.2.4 Kategorien
Sofern es sich um ein offenes Card-Sorting-Experiment handelt, werden aus den
gezeichneten Gruppierungen Kategorien erstellt. Im Gegensatz dazu werden bei einem
geschlossenem Experiment die Kategorien direkt angezeigt und müssen nicht
erstellt werden. Es stellt sich natürlich unweigerlich die Frage, wieso hier dieses
zweistufige Verfahren gewählt ist.
Der Benutzer soll sich beim offenen Card-Sorting nur darauf konzentrieren, die
Karten sinnvoll zu gruppieren und sich nicht durch voreiliges Benennen selbst
irritieren lassen. Ein weiterer Grund ist, dass es möglich sein soll, die Gruppierungen
zusammenzufügen. Wären beide Gruppen benannt, wäre nicht klar, welche
Benennung übernommen werden soll.
Im Fall des geschlossenen Card-Sortings kommt hinzu, dass zu Anfang Begriffe
nicht einer Kategorie direkt zugeordnet werden brauchen und als Gruppe zwischengelagert
werden können.
Kategorie erstellen
Das hier vorgestellte Szenario ist nur in offenen Card-Sorting-Experimenten durchführbar.
In geschlossenen Card-Sortings ist das Erstellen einer Kategorie aus einer
Gruppe gesperrt.
Abbildung 6.7 zeigt das Erstellen einer Kategorie. Der Benutzer führt auf der
Gruppierung zwei Berührungen kurz hintereinander aus 2 . Die graphische Gruppierung
wird daraufhin gelöscht und die Karten in eine unbenannte Kategorie
2 Analog zum Doppelklick in Desktop-Systemen.
62

6.2 Durchführung von Experimenten
(a)
(b)
Abbildung 6.7: Kategorie erstellen
Abbildung 6.8: Kategorie benennen
überführt. Der Benutzer hat nach dem Erstellen der Kategorie über die virtuelle
Tastatur einen Namen einzugeben (vgl. Abbildung 6.8). Im Moment ist noch
keine Fehlerbehandlung implementiert, die überprüft, ob eine Kategorie am Ende
einer Durchführung wirklich benannt wurde. Dies wäre im weiteren Verlauf der
Entwicklung wünschenswert.
Der Benutzer hat in offenen Card-Sorting-Experimenten jederzeit die Möglichkeit
den Namen der Kategorie zu ändern.
Karten hinzufügen
Gerade bei geschlossenen Card-Sorting-Experimenten muss die Möglichkeit bestehen,
Karten einer Kategorie hinzuzufügen. Die Größe eine Kategorie ist zu
Anfang relativ klein gewählt. Das soll verhindern, dass unnötig Platz verbraucht
wird. Werden mehr als zwei Elemente hinzugefügt, wird die Kategorie beim Hinzufügen
weiterer Karten in der Höhe angepasst.
63

6. Bedienung der Applikation
Es gibt mehrere Möglichkeiten, Karten den Kategorien hinzuzufügen. Zum einen
(a)
(b)
(c)
(d)
Abbildung 6.9: Einzelne Karte zu einer Kategorie hinzufügen
können einzelne Karten den Kategorien hinzugefügt werden. Hierbei gibt es zwei
unterschiedliche Szenarien. Wird die Karte an einer Stelle auf der Kategorie abgelegt,
an der sich nicht bereits eine Karte befindet, wird diese am Ende der Liste
eingefügt (vgl. Abbildungen 6.9(a) und 6.9(b)). Wird die Karte dagegen auf einer
bereits in der Kategorie befindlichen Karte abgelegt, wird die vorhandene und alle
folgenden Karten um eine Stelle nach unten verschoben und dafür die neue Karte
eingefügt (vgl. Abbildungen 6.9(c) und 6.9(d)).
Sollen Karten die in einer Gruppe zusammengefasst sind, einer vorhandenen Kategorie
hinzugefügt werden, wird die Gruppe auf eine Kategorie geschoben (vgl.
Abbildung 6.10(a)). Anschließend wird die Gruppierung gelöscht und die enthaltenen
Karten an das Ende der Liste in der Kategorie hinzugefügt (vgl. Abbildung
6.10(b)). Wichtig dabei ist das sich der Finger beim Aufheben der Berührung auf
64

6.2 Durchführung von Experimenten
(a)
(b)
Abbildung 6.10: Gruppierung zu einer Kategorie hinzufügen
der Kategorie befindet. Wäre der Bereich der Gruppierung dafür verwendet worden,
hätte es passieren können, dass eine (größere) Gruppierung zwei Kategorien
überdeckt und somit nicht klar gelöst werden kann, welcher Kategorie die Karten
hinzugefügt werden sollen.
(a)
(b)
Abbildung 6.11: Karten durch Lasso-Selektion einer Kategorie hinzufügen
Sollte ein Benutzer Karten erst grob in der Nähe einer Kategorie vorsortieren,
um diese anschließend der Kategorie hinzuzufügen, kann das Einfügen direkt
durch die Lasso-Selektion erledigt werden. Dazu umschließt der Benutzer nicht nur
die Karten, die verschoben werden sollen, sondern auch die Kategorie, in der die
Karten eingefügt werden sollen (vgl. Abbildung 6.11(a)). Nachdem das Erstellen
der Gruppierung abgeschlossen ist, werden die Karten der Kategorie hinzugefügt
und der Gruppierungsrahmen direkt gelöscht (vgl. Abbildung 6.11(b)).
65

6. Bedienung der Applikation
Karten entfernen
Genauso wie eine Karte einer Kategorie hinzugefügt wird, kann diese auch wieder
entfernt werden. Beim Entfernen einer Karte wird nach dem Ablegen der Karte
an einer anderen Position die Liste so angepasst, dass keine Lücken entstehen.
Außerdem wird die Höhe der Kategorie verkleinert.
Ist bei einem offenem Card-Sorting die letzte Karte aus einer Kategorie entfernt,
wird die komplette Kategorie entfernt.
6.3 Experiment beenden
Abbildung 6.12: Experiment beenden
Zum Beenden eines Experiments muss der Benutzer die Oberfläche im oberen
Bereich berühren und den Finger nach unten ziehen. Hat der Finger den unteren
Rand erreicht, wird ein Dialog angezeigt (vgl. Abbildung 6.12). Dieser enthält die
Danksagung aus dem WeCaSo-Projekt und die Frage, ob das Experiment wirklich
geschlossen werden soll. Wird die Frage verneint, wird der Dialog wieder geschlossen
und der Benutzer kann das Experiment weiter ausführen. Bestätigt er die
66

6.3 Experiment beenden
Frage, wird die Anwendung geschlossen.
Zu diesem Zeitpunkt sollte eine Fehlerprüfung stattfinden, ob alle Karten zugeordnet
worden sind und alle Kategorien einen Namen haben. Sollte es zu Fehlern
kommen, sind dem Benutzer diese anzuzeigen. Außerdem sollten bei erfolgreicher
Prüfung die Ergebnisse in der Datenbank gespeichert werden. Beide Punkte sind
noch nicht umgesetzt und müssten im Rahmen der Weiterentwicklung realisiert
werden.
67

7 Zusammenfassung und Ausblick
7.1 Zusammenfassung
Diese Arbeit beschäftigt sich mit der Implementierung einer Applikation zur Durchführung
von Card-Sorting-Experimenten.
Zu Anfang der Arbeit wird untersucht, ob eine solche Multitouch-Anwendung
einen Mehrwert für Testleiter und Testteilnehmer hat. Dies ist u. a. durch die Arbeit
von North u.a. [NDL + 09] bestätigt. Die reine Durchführungszeit von Card-
Sorting-Experimenten wird auf dem Multitouch-Tisch zwar höher sein als auf
einem physischen Tisch, jedoch schneller als eine Anwendung an einem Desktop-
Computer. Es ist weiter festgestellt worden, dass viele Nachteile, die das klassische
Card-Sorting und die computergestützten Card-Sorting-Anwendung haben mit einer
Multitouch-Anwendung beseitigt werden können.
Im nächsten Schritt ist untersucht worden, für welche Aktionen in einem Card-
Sorting-Experiment Gesten benötigt werden. Durch Untersuchung verschiedener
Wissenschaftlicher Arbeiten sind für jede Aktion verschiedene Gesten identifiziert
worden. Diese Gesten sind auf Vor- und Nachteile und Umsetzbarkeit für die
Anwendung untersucht worden. Im Ergebnis ist für jede Aktion eine Geste entstanden,
von der anzunehmen ist, dass sie von Benutzern schnell erlernt werden
kann. Dazu ist es wichtig, dass die Gesten den Benutzern während der Interaktion
ein visuelles Feedback geben, leicht zu merken sind und eine Assoziation zur
physischen Welt hergestellt werden kann.
Der Großteil der identifizierten Gesten ist in die Anwendung mit eingeflossen.
Die Anwendung kann Card-Sorting-Projekte aus der Datenbank von WeCaSo laden.
Es können offene und geschlossene Experimente durchgeführt werden. Eine
Übertragung der Ergebnisse ist noch nicht möglich, soll aber zu einem späteren
69

7. Zusammenfassung und Ausblick
Zeitpunkt umgesetzt werden.
Insgesamt steht mit dieser Anwendung eine gute Alternative zum klassischen und
desktopbasierten Card-Sorting zur Verfügung. Viele Vorteile der beiden Varianten
sind in dieser Applikation zusammengefasst worden und viele Nachteile existieren
nicht mehr. So ist der administrative Aufwand für den Testleiter geringer als
auf einem klassischen Card-Sorting. Für den Testteilnehmer ist diese Applikation
leichter zu verstehen und durchzuführen, als ein desktop-basiertes Card-Sorting-
Programm.
7.2 Ausblick
Mit dieser Applikation ist ein erster Schritt zu einem Card-Sorting auf Multitouch-
Tischen gemacht worden. Es fehlt allerdings noch das hierarchische Einfügen von
Karten und das Reverse-Card-Sorting, welche im weiteren Verlauf der Entwicklung
umgesetzt werden sollten.
Es sind aber auch technische Aspekte zu verbessern. Der Pfad zu der Datenbank
und die Anmeldedaten sind in der Anwendung hart kodiert und können nicht ohne
Weiteres verändert werden. Hier ist zu überlegen, ob man auf eine Konfigurationsdatei
zurückgreift oder einen Administrationsbereich einrichten sollte.
Die direkten Zugriffe auf die Datenbank sind kritisch. Eine Änderung der Datenbankstruktur
kann dazu führen, dass die Anwendung nicht mehr ausgeführt
werden kann. Es wäre wünschenswert wenn WeCaSo eine Schnittstelle zur Verfügung
stellen würde, auf die ohne Gefahr einer Änderung der Datenbank zugegriffen
werden könnte.
Weiter ist es nötig noch mehr Fehlerbehandlungen in die Anwendung einzubauen.
So wird nicht geprüft, ob notwendige Fragen im Fragebogen beantwortet sind
oder alle Kategorien einen Namen bekommen. Weiter wird nicht überprüft, ob
alle Karten zugeordnet worden sind.
Das Zurückspielen der Ergebnisse in die Datenbank ist elementarer Bestandteil
der Anwendung und wird in Absprache mit der Arbeitsgruppe zeitnah implementiert.
70

Anhang A
A.1 Inhalt der CD-Rom
• Ausarbeitung als PDF: Ausarbeitung.pdf
• Quellen der Ausarbeitung: Benutzte Arbeiten
• Applikation CardSortingMTT: CardSortingMTT\CardSortingMTT.exe
• Quellcode von CardSortingMTT: CardSortingMTT_Quellcode.rar
• MySQL-Dump: Sonstiges\cardsort.sql
• WeCaSo-Webservice: Sonstiges\wecaso.zip
• XAMPP: Sonstiges\xampp-win32-1.8.0-VC9-installer.exe
• Multitouch-Vista: Sonstiges\MultiTouchVista.zip
A.2 Voraussetzungen zum Ausführen der
Applikation
Zum Ausführen der Applikation wird Visual Studio 2010 benötigt, da es sonst zu
ungeklärten Abstürzen der Applikation kommt. Außerdem muss für den Zugriff
auf die Datenbank von WeCaSo die Serversoftware XAMPP 1.7.4 oder neuer installiert
sein 1 .
Im folgenden wird die Einrichtung von WeCaSo und die Konfiguration des virtuellen
Touch-Devices MultiTouch-Vista beschrieben.
1 Version 1.8.0 befindet sich auf der CD
71

A.
A.2.1 Installation von WeCaSo
MySQL
1. XAMPP öffnen und den Apache und MySQL Server starten.
2. Im Webbrowser http://localhost/phpmyadmin aufrufen.
3. Im Reiter User einen neuen Benutzer mit folgenden Daten anlegen:
• User name: cardsort
• Password: 1122
• Host: local
• Die Checkbox im Abschnitt Database for user auf Create database with
same name and grant all privileges setzen.
4. In die erstellte Datenbank cardsort wechseln und über den Reiter Import
den SQL-Dump cardsort.sql von der CD importieren.
In der Dump-Datei sind bereits vier Demo-Projekte enthalten:
DemoOffen ein offenes Card-Sorting-Experiment
DemoOffenMulti ein offenes Card-Sorting-Experiment mit Multiple-Insert
DemoGeschlossen ein geschlossenes Card-Sorting-Experiment
DemoGeschlossenMulti ein geschlossenes Card-Sorting-Experiment mit Multiple-
Insert
Diese Schritte sind ausreichend, um die vier Demo Projekte auszuführen. Sollen
eigene Projekte erstellt werden, ist es erforderlich den WeCaSo-Webservice einzurichten.
WeCaSo-Webservice
1. Den Apache und MySQL Server stoppen
2. Im Installationsverzeichnis von XAMPP 2 in den Ordner apache\conf\extra
wechseln und in die Datei httpd-vhosts.conf folgenden Zeilen einfügen.
2 Bei der Standardinstallation C:\xampp
72

A.2 Voraussetzungen zum Ausführen der Applikation
1 < VirtualHost *:80 >
2 DocumentRoot C:/ xampp / htdocs /
3 ServerName localhost
4
5
6 < VirtualHost *:80 >
7 DocumentRoot C:/ xampp / htdocs / wecaso_de /
public /
8 ServerName cardsort . localhost
9
3. Die Datei wecaso_de.zip von der CD in den Ordner htdocs des XAMPP
Installationsverzeichnisses entpacken.
4. Den Apache und MySQL Server starten.
Über die Adresse http://cardsort.localhost kann WeCaSo aufgerufen werden.
Sollte es zu einem Fehler beim öffnen der Seite kommen, muss die Subdomain
in die Datei C:\Windows\System32\drivers\etc\hosts eingetragen werden und
der Computer muss im Anschluss neugestartet werden. Die host Datei sollte wie
folgt aussehen:
1 127.0.0.1 localhost
2 127.0.0.1 cardsort . localhost
Nach Aufruf der Seite kann man sich als neuer Benutzer registrieren und anschließend
neue Card-Sorting-Projekte anlegen.
A.2.2 Virtuelles Touch-Device
Die Applikation kann ebenfalls auf einem Desktop-Computer ausgeführt werden.
Hierfür wird die Anwendung Multi-Touch Vista von der CD benötigt. Nach Konfigurieren
dieser Anwendung wird jede angeschlossene Maus zu einem eigenständigen
Zeigergerät. Die folgende Konfigurationsanleitung ist von radar-touch.com
[Rad] übernommen.
1. Das Archiv in einen beliebigen Ordner entpacken.
73

A.
2. Im Startmenü zur Eingabeaufforderung navigieren 3 und über das Kontextmenü
Als Administrator ausführen auswählen.
3. Mit der Eingabeaufforderung in das Multi-Touch Vista Verzeichnis wechseln
und von dort weiter in das Verzeichnis Driver.
4. Von dort „Install Driver.cmd“ ausführen.
5. Nach erfolgreicher Installation über die Systemsteuerung den Geräte-Manager
öffnen.
6. Das Gerät Eingabegeräte → UniversalSoftwareHIDdevice deaktivieren
und direkt wieder aktivieren.
7. In der Systemsteuerung Stift- und Fingereingabe öffnen und im Reiter Fingereingabe
diese aktivieren, sofern dies noch nicht automatisch geschehen
ist.
8. In den Multi-Touch Vista Ordner wechseln und folgende Dateien ausführen:
a) Multitouch.Service.Console.exe
b) Multitouch.Driver.Console.exe
c) Multitouch.Configuration.WPF.exe
9. Im Dialog Multitouch configuration das Gerät MultipleMice aktivieren. Auf
den Button Configure device klicken und im Dialog den Haken setzen. Den
Dialog mit Ok schließen.
10. Die in Punkt 8 gestarteten Dateien schließen.
Ab jetzt können durch Starten von Multitouch.Driver.Console.exe und Multtouch.Service.Console.exe
die virtuellen Zeigergeräte aktiviert werden. Für
die Durchführung der Applikation werden zwei Mäuse benötigt.
3 In Windows 7: Start → AlleP rogramme → Zubehör
74

Literatur
[ASLG06] Aliakseyeu, Dzmitry, Sriram Subramanian, Andrés Lucero
und Carl Gutwin: Interacting with piles of artifacts on digital tables.
In: Proceedings of the working conference on Advanced visual
interfaces, AVI ’06, Seiten 159–162, New York, NY, USA, 2006. ACM.
[BKH09]
[Bux07]
[Emm08]
[FHD09]
Burmester, Prof. Dr. Michael, Franz Koller und Christine
Höflacher: Touch it, move it, scale it - Multitouch. Technischer
Bericht, Hochschule der Medien Stuttgart, 2009.
Buxton, Bill: Multi-Touch Systems that I Have Known and Loved.
online unter: http://www.billbuxton.com/multitouchOverview.
html, aufgerufen am 26.12.2012, 2007.
Emmrich, Sebastian: Casolysis: Entwurf und Implementierung eines
Werkzeugs zur Analyse von Card-Sorting-Experimenten. Bachelorarbeit,
Universität Paderborn, 2008.
Frisch, Mathias, Jens Heydekorn und Raimund Dachselt: Investigating
multi-touch and pen gestures for diagram editing on interactive
surfaces. In: Proceedings of the ACM International Conference
on Interactive Tabletops and Surfaces, ITS ’09, Seiten 149–156, New
York, NY, USA, 2009. ACM.
[FSHC11] Fuentes, Salvador, J. Alfredo Sánchez, Osvaldo Huerta
und Ofelia Cervantes: InnovaTouch: a multi-touch framework to
support gesture recognition for innovation activities. In: Proceedings
of the Companion Proceedings of the 10th Brazilian Symposium on
Human Factors in Computing Systems and the 5th Latin American
Conference on Human-Computer Interaction, IHC+CLIHC ’11, Seiten
12–13, Porto Alegre, Brazil, Brazil, 2011. Brazilian Computer Society.
75

Literatur
[GHR12]
Geyer, Florian, Anita Höchtl und Harald Reiterer: Harnessing
the benefits of bimanual and multi-finger input for supporting grouping
tasks on interactive tabletops. In: Proceedings of the 7th Nordic
Conference on Human-Computer Interaction: Making Sense Through
Design, NordiCHI ’12, Seiten 496–499, New York, NY, USA, 2012.
ACM.
[Kuh12]
Kuhn, Jasmin: Entwicklung eines Leitfadens zum Praxiseinsatz innovativer
Card Sorting Werkzeuge. Bachelorarbeit, Universität Paderborn,
2012.
[Mica]
Einführung in WPF. Webseite. Online unter msdn.microsoft.com/
de-de/library/vstudio/aa970268(v=vs.100).aspx, aufgerufen am
31.12.2012.
[Micb] Erste Einblicke in Windows - Schließen einer App, Herunterfahren
des PCs und vieles mehr. Webseite. Online
unter http://windows.microsoft.com/de-DE/windows-8/
settings-search-shutdown-basics#1TC=t1, aufgerufen am
26.12.2012.
[NDL + 09] North, Chris, Tim Dwyer, Bongshin Lee, Danyel Fisher, Petra
Isenberg, George Robertson und Kori Inkpen: Understanding
Multi-touch Manipulation for Surface Computing. Technischer
Bericht, Berlin, Heidelberg, 2009.
[Rad]
A short manual how to install Multitouch Vista. Webseite. Online unter
http://ck174.server2.raumopol.de/wordpress/wp-content/
uploads/2012/05/Install-Multitouch-Vista220512.pdf, aufgerufen
am 17.01.2013.
[SHL + 12]
Spath, Dieter, Anette Weisbecker (Hrsg.), Uwe Laufs,
Micha Block, Jasmin Link, Antonino Ardilio, Andreas
Schuller und Janina Bierkandt: Multi-Touch - Technologie,
Hard-/Software und deren Anwendungsszenarien. Technischer Bericht,
Fraunhofer IAO, Stuttgart, 2012.
76

Literatur
[SW04]
[Vdo08]
Spencer, Donna und Todd Warfel: Card sorting: a definitive
guide. online unter: http://www.boxesandarrows.com/view/card_
sorting_a_definitive_guide, aufgerufen am 26.12.2012, 2004.
Vdovkin, Andreas: Entwicklung einer webbasierten Card Sorting
Applikation. Bachelorarbeit, Universität Paderborn, 2008.
[WMW09] Wobbrock, Jacob O., Meredith Ringel Morris und Andrew
D. Wilson: User-defined gestures for surface computing. In:
Proceedings of the SIGCHI Conference on Human Factors in Computing
Systems, CHI ’09, Seiten 1083–1092, New York, NY, USA, 2009.
ACM.
[WSR + 06] Wu, Mike, Chia Shen, Kathy Ryall, Clifton Forlines und
Ravin Balakrishnan: Gesture Registration, Relaxation, and Reuse
for Multi-Point Direct-Touch Surfaces. In: Proceedings of the
First IEEE International Workshop on Horizontal Interactive Human-
Computer Systems, TABLETOP ’06, Seiten 185–192, Washington,
DC, USA, 2006. IEEE Computer Society.
[WWI07]
Watanabe, Nayuko, Motoi Washida und Takeo Igarashi: Bubble
clusters: an interface for manipulating spatial aggregation of graphical
objects. In: Proceedings of the 20th annual ACM symposium on
User interface software and technology, UIST ’07, Seiten 173–182, New
York, NY, USA, 2007. ACM.
77