Widgets für interaktive Displays

Transcrição

Fakultät für Elektrotechnik, Informatik und Mathematik
Institut für Informatik
Fachgebiet Mensch-Computer-Interaktion
Fürstenallee 11
33102 Paderborn
Widgets für interaktive Displays
Herausforderungen an den Entwurf und
prototypische Implementierung eines
eigenen Konzepts
Bachelorarbeit
im Rahmen des Studiengangs Informatik
zur Erlangung des Grades
Bachelor of Science
von
Fabian Mense
betreut durch
M. Sc. Adrian Hülsmann
vorgelegt bei
Prof. Dr. Gerd Szwillus
und
Prof. Dr.-Ing. Steffen Becker
Paderborn, 10. Oktober 2014
II
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig angefertigt
habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als
solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Ich verpflichte mich, meine Bachelorarbeit den Richtlinien der Studienordnung
entsprechend aufzubewahren und sie auf Verlangen jederzeit herauszugeben.
Ort, Datum
Unterschrift
III
IV
Abstract
Die Entwicklung von effizienten Interaktionsformen im Umgang mit interaktiven
Tabletop-Systemen ist ein beliebtes Forschungsgebiet. Ein Ziel ist es, den Anwendern
einfache und intuitive Lösungen in Form von Widgets an die Hand zu geben, um den
gerätespezifischen Problemen, wie der Selektion von weit entfernten Objekten, zu
begegnen. Gleichzeitig soll die Leistungsfähigkeit der Anwender dadurch erhöht werden.
Ein gegenwärtiges Problem ist es, einen Überblick über die bereits entwickelten Widgets
zu erhalten. Denn, auch wenn eine Vielzahl an Lösungen entwickelt wurde, gibt es kein
zentrales Verzeichnis der verfügbaren Widgets und keine einheitlichen Standards für die
Entwicklung eigener Widgets.
Aus diesem Grund präsentiere ich in dieser Arbeit eine Klassifizierung für Widgets.
Hierfür wurden die vorherrschenden Forschungsergebnisse analysiert und nach dem
Interaktionsziel des Anwenders kategorisiert.
Zusätzlich wurde ein kurzer Leitfaden entworfen, welcher eine Hilfestellung bei der
Entwicklung eigener Widgets bietet. Dort werden bewährte Methoden genannt und auf
Problemfelder hingewiesen. Auf diesen Ergebnissen aufbauend wurde zudem ein eigenes
prototypisches „TidyUp“-Widget entwickelt, mit welchem sich unübersichtliche
Bildschirmoberflächen aufräumen lassen, indem die vorhandenen Elemente kompakt
angeordnet werden. Dadurch wird neuer Platz auf dem Bildschirm geschaffen, ohne dass
vorhandene Elemente geschlossen werden müssen.
V
VI
Inhalt
1
Einleitung ......................................................................................................................................................... 1
1.1 Motivation ...................................................................................................................................................... 1
1.2 Problembeschreibung und Zielsetzung ........................................................................................... 2
1.3 Struktur der Arbeit .................................................................................................................................... 3
2
Technische Grundlagen ............................................................................................................................. 5
2.1 Entwicklung der Multi-Touch-Oberflächen ................................................................................... 5
2.2 Multi-Touch-Tische ................................................................................................................................... 7
2.2.1 Grundlegende Eigenschaften ...................................................................................................... 7
2.2.2 Der Multi-Touch-Tisch Mister T. ............................................................................................... 9
2.3 Eingabeparadigmen interaktiver Benutzungsoberflächen ................................................. 10
2.3.1 CLI - Command Line Interfaces ............................................................................................... 10
2.3.2 GUI – Graphical User Interfaces .............................................................................................. 10
2.3.3 NUI – Natural User Interfaces .................................................................................................. 10
2.4 Definition des Widget-Begriffs .......................................................................................................... 12
2.4.1 Begriffsherkunft ............................................................................................................................. 12
2.4.2 Vielfältigkeit des Widget-Begriffs .......................................................................................... 12
2.4.3 Präzisierung der Definition zu GUI-Widgets .................................................................... 15
3
Untersuchung von Widgets .................................................................................................................. 17
3.1 Vorteile von Widgets ............................................................................................................................. 17
3.2 Nachteile von Widgets .......................................................................................................................... 19
3.3 Anwendungsdomänen von Widgets............................................................................................... 20
3.3.1 Herausforderungen allgemeiner Touch-Interfaces ....................................................... 20
3.3.2 Herausforderungen an interaktive Tabletop-Systeme ................................................ 22
3.3.3 Weitere Anwendungsfelder von Widgets .......................................................................... 24
3.4 Aktivierung von Widgets ..................................................................................................................... 25
VII
Inhalt
3.4.1 Automatische (De-)Aktivierung.............................................................................................. 25
3.4.2 Statische Haltungen ...................................................................................................................... 26
3.4.3 Dynamische Gesten ....................................................................................................................... 26
3.4.4 Tangible User Interfaces............................................................................................................. 27
3.5 Klassifikation ............................................................................................................................................. 28
3.5.1 Verwandte Arbeiten ..................................................................................................................... 28
3.5.2 Systematik ......................................................................................................................................... 29
3.5.3 Vorstellung der Kategorien ....................................................................................................... 30
3.5.4 Objektselektion ............................................................................................................................... 31
3.5.5 Anwendungskontrolle ................................................................................................................. 34
3.5.6 Kooperative Arbeit ........................................................................................................................ 36
3.6 Leitfaden für den Widget-Entwurf .................................................................................................. 38
3.6.1 Grundgedanken .............................................................................................................................. 38
3.6.2 Widget-Design ................................................................................................................................. 39
3.6.3 Implementierung ........................................................................................................................... 41
4
Umsetzung eines eigenen Widgets ................................................................................................... 43
4.1 Grundlagen ................................................................................................................................................. 43
4.1.1 Idee „TidyUp“-Widget .................................................................................................................. 43
4.1.2 Entwicklungsumgebung ............................................................................................................. 44
4.2 Gestaltung ................................................................................................................................................... 44
4.2.1 Visuelle Gestaltung ........................................................................................................................ 44
4.2.2 Aktivierung des Widgets ............................................................................................................ 45
4.2.3 Motion Design .................................................................................................................................. 46
4.3 Architektur der Anwendung .............................................................................................................. 48
4.3.1 Übersicht ............................................................................................................................................ 48
4.3.2 Beschreibung ................................................................................................................................... 50
4.3.3 MainSurfaceWindow .................................................................................................................... 50
VIII
Inhalt
4.3.4 MyImagePool ................................................................................................................................... 50
4.3.5 DragDropScatterView .................................................................................................................. 51
4.3.6 MyPostureRecognizer.................................................................................................................. 51
4.3.7 MyGestureRecognizer.................................................................................................................. 52
4.3.8 MyGestureHandler ........................................................................................................................ 53
4.4 Beispielhafte Verwendung des Widgets ....................................................................................... 54
4.5 Evaluierung des Widgets ..................................................................................................................... 57
5
Fazit.................................................................................................................................................................. 59
5.1 Zusammenfassung .................................................................................................................................. 59
5.2 Diskussion und Ausblick ...................................................................................................................... 60
6
Literaturverzeichnis ................................................................................................................................ 61
7
Anhang ............................................................................................................................................................ 67
7.1 Inhalt der CD-ROM .................................................................................................................................. 67
7.2 Systemvoraussetzungen für das Widget ...................................................................................... 67
7.3 Ausführung des Widgets auf Mister T. .......................................................................................... 67
7.4 Ausführung des Widgets auf PCs ohne Touch-Interface ...................................................... 68
IX
X
Abbildungsverzeichnis
Abbildung 1: Aufbau des Microsoft Surface (Derene, 2007) ............................................................. 7
Abbildung 2: Beispielhafte Auswahl verschiedener Windows Gadgets ................................... 13
Abbildung 3: „Hybrides“ Widget zur Steuerung von Music-Player-Funktionen und
Anzeige von Titel-Informationen (Google Inc., 2012) ....................................................................... 13
Abbildung 4: Web-Widget zur Veröffentlichung auf der Homepage (S-Bahn Berlin GmbH,
2012) ......................................................................................................................................................................... 14
Abbildung 5: Widget im Notizprogramm OneNote zur Unterstützung der TouchBedienung (Bott, 2012) .................................................................................................................................... 15
Abbildung 6: Vergleich von Maus- und Touch-Interaktion. Durch das „Fat-FingerProblem“ werden der genaue Berührungspunkt und etwaige grafische Rückmeldungen
überdeckt (Bachl et al., 2010). ...................................................................................................................... 21
Abbildung 7: Beispiel einer Technik zur Verhinderung von Okklusion. Sobald der
Benutzer mit seinem Finger eine Schaltfläche berührt und somit eventuell verdeckt (a),
wird die Schaltfläche entsprechend größer dargestellt (b) (Shen et al., 2006). ................... 23
Abbildung 8: Möglichkeit der pixelgenauen Auswahl über das Widget „Cross-Keys“
(Albinsson & Zhai, 2003). ................................................................................................................................ 31
Abbildung 9: Item innerhalb des Zielbereichs ...................................................................................... 44
Abbildung 10: Zwei Items in StackView-Ansicht (links) und fünf Items in BarViewAnsicht (rechts) .................................................................................................................................................... 45
Abbildung 11: Fünf-Finger-Handhaltung zur Aktivierung des Widgets ................................... 46
Abbildung 12: Drehbewegung im oder gegen den Uhrzeigersinn zum Heranziehen der
Bildschirmelemente ........................................................................................................................................... 47
Abbildung 13: Abschlussgeste zur Erstellung eines Containers mit den herangezogenen
Elementen als Inhalt .......................................................................................................................................... 47
Abbildung 14: Ausgangssituation................................................................................................................ 54
Abbildung 15: Aktivierung des Widgets über die Haltung der linken Hand .......................... 55
Abbildung 16: Ausführung von Kreisgesten der rechten Hand zum Heranziehen der
Elemente .................................................................................................................................................................. 56
Abbildung 17: Ergebnis nach dem Anheben der Hände. .................................................................. 56
Abbildung 18: Darstellung der Container-Elemente als BarView. .............................................. 57
XI
1 Einleitung
1.1 Motivation
Die Beliebtheit von Multi-Touch-Systemen, wie Smartphones oder Tablets, nimmt seit
einiger Zeit stark zu. Dies ist vor allem auf die Natürlichkeit dieser Eingabetechnik
zurückzuführen, welche die direkte Manipulation von Bildschirmobjekten durch die
Finger des Benutzers ermöglicht. Durch die Dynamik dieses Trends erschließen sich für
diese Eingabetechnik immer weitere Anwendungsgebiete und Interaktionstechniken
zwischen Mensch und Computer.
Eine weitere Gattung von Geräten, die dadurch in den Fokus rückt, sind die sogenannten
interaktiven Tabletop-Systeme oder Multi-Touch-Tische. Eine Studie des Fraunhofer AIO
bestätigt das große Marktpotenzial und einen verstärkten Bedarf dieser Lösungen im
Unternehmensumfeld. Gerade in kooperativen Arbeitsumgebungen werden sich Vorteile
versprochen, beispielsweise durch das gleichzeitige Arbeiten mehrerer Personen an
einem gemeinsamen Projekt (Spath et al., 2009).
Aufgrund des Verzichts auf das gewohnte Eingabeparadigma mittels Tastatur- und
Mausbedienung und der Größe dieser Systeme gibt es Bedarf an gleichzeitig effizienter
Interaktion und nützlicher Aufgabenunterstützung über die Multi-Touch-Bedienung.
Beispielsweise können Bildschirminformationen durch Gegenstände, die sich auf der
Tischoberfläche befinden, verdeckt werden oder Inhalte sind aufgrund ihrer Entfernung
vom Benutzer nicht erreichbar. Hier liegen die Notwendigkeit und die Vorteile von
Widgets.
Widgets
sind
grafische
Benutzerschnittstellen,
die
mittels
geschickter
Interaktionstechniken eine Unterstützung bei der Aufgabenerledigung bieten. Sie können
bei Bedarf aktiviert werden und sind dann durch Gesten steuerbar. Sie ermöglichen eine
Manipulation der Daten direkt am Ort der Bildschirminformation und eine, an das
jeweilige Anwendungsszenario angepasste, Hilfestellung.
Eine Vielzahl an Widgets wurde bereits entwickelt, um diesen Anforderungen zu
begegnen. Daher ist es interessant, die Widgets, welche speziell für Tabletop-Systeme
entworfen wurden, zu untersuchen.
1
1 Einleitung
1.2 Problembeschreibung und Zielsetzung
Die gegenwärtige intensive Forschung im Bereich der Multi-Touch-Interaktion brachte
bereits eine Fülle von Widgets hervor. Durch diese Vielfalt ist es schwierig, einen
Überblick über die angebotenen Widgets zu bekommen. Auch bleibt es nicht aus, dass
verschiedene Widgets gleiche Aktivierungs- und Steuerungsgesten besitzen und somit
untereinander nicht kompatibel sind. Für Derboven, Roeck und Verstraete (2012) ist es
dieser Mangel an Standardisierung, welcher die Forschung an Strukturen von MultiTouch-Widgets wertvoll macht.
Das erste Ziel dieser Arbeit ist es, eine Kategorisierung für Multi-Touch-Widgets zu
erarbeiten. Dafür soll zunächst eine Übersicht über mögliche Anwendungsszenarien der
Widget-Interaktion gegeben werden. Außerdem sollen im Rahmen der Kategorisierung
weitere Charakteristiken von Widgets herausgestellt werden. Dazu zählen die Vorteile
und Nachteile der Widgets, die Möglichkeiten der Aktivierung von Widgets, sowie ein
Leitfaden, welche Schritte notwendig sind, um ein neues Widget zu entwickeln.
Der Fokus dieser Aufgabe liegt auf Widgets, welche sich durch eine Touch-Interaktion
bedienen lassen. Um die Aufgabenstellung einzugrenzen, werden aus diesem Grund
Tangible Widgets nur am Rand erwähnt, fließen aber nicht mit in die Kategorisierung ein.
Dies sind Widgets, die über physikalische Objekte auf der Bildschirmoberfläche gesteuert
werden. Ferner wird auf die Einbeziehung von 3D-Widgets verzichtet, weil diese einen
eigenen Forschungsbereich darstellen.
Das zweite Ziel ist die eigenständige Entwicklung eines prototypischen Widgets für
interaktive Tabletop-Systeme. Zu diesem Zweck soll einleitend aus der vorherigen
Aufgabe ein bisher unzureichend bearbeiteter Anwendungsbereich für Widgets ermittelt
werden. Für diesen Bereich soll dann ein neues Widget entworfen, implementiert und
hinsichtlich des Potenzials evaluiert werden. Eingesetzt werden soll die entwickelte
Technik auf dem Multi-Touch-Tisch „Mister T.“, welcher im Rahmen einer Masterarbeit
an der Universität Paderborn gebaut wurde.
2
1.3 Struktur der Arbeit
1.3 Struktur der Arbeit
Die Arbeit ist in fünf Kapitel gegliedert. Aus der Zielsetzung ist erkennbar, dass im
weiteren Verlauf im Wesentlichen zwei Hauptaufgaben beantwortet werden – die
Klassifikation verfügbarer Widgets und der Entwurf eines eigenen prototypischen
Widgets.
Um zuvor einen Einblick in die Thematik zu bekommen, werden im nachfolgenden Kapitel
2 die Entwicklungen im Bereich der Multi-Touch-Geräte und der Benutzungsoberflächen
in einen geschichtlichen Kontext eingeordnet. Außerdem wird eine grundlegende
Definition des Widget-Begriffs gegeben, um ein Verständnis der Thematik für den Verlauf
der weiteren Kapitel zu schaffen.
Das Kapitel 3 widmet sich den Charakteristiken von Widgets. Die veröffentlichten
Lösungen aus wissenschaftlichen Arbeiten werden gemäß ihrer Anwendungsszenarien
analysiert, um einen Überblick für relevante Widgets im Tabletop-Bereich zu bekommen.
Anhand dieser Grundmenge von Forschungsergebnissen sollen dann systematisch
Gemeinsamkeiten und Muster erkannt werden, welche in eine Kategorisierung von
Widgets einfließen können. Darüber hinaus soll ein kurzer Leitfaden für den Entwurf
eines neuen Widgets entwickelt werden.
Diese Ergebnisse der Kategorisierung und des Leitfadens werde ich anschließend im
Kapitel 4 aufgreifen, um ein bisher unterrepräsentiertes Anwendungsszenario
aufzudecken. Für diesen Problembereich soll dann ein neues Widget entwickelt werden.
Im Rahmen dessen wird sowohl die Entstehung des Widget-Designs, als auch die
Architektur der Anwendung dokumentiert. Zusätzlich wird eine beispielhafte
Verwendung des neu erstellen Widgets erläutert und mögliche Erweiterungen reflektiert.
Schließlich folgt im Kapitel 5 eine Zusammenfassung der gesamten Arbeit, in welcher die
wesentlichen Erkenntnisse dargelegt werden. In einem Ausblick wird dann auf mögliche
weiterführende Arbeiten eingegangen.
3
4
2 Technische Grundlagen
Dieses Kapitel bildet die Grundlage für die spätere Untersuchung von Widgets im Umfeld
von interaktiven Tabletop-Systemen. In einem ersten Teil werde ich kurz die
geschichtliche Entwicklung von Multi-Touch-Oberflächen beschreiben, um den
derzeitigen Erfolg dieser Technik darzulegen. Dann folgt ein Abschnitt, der sich speziell
den Multi-Touch-Tischen widmet. Hier werden die Anwendungsszenarien und
Möglichkeiten dieser Technik angesprochen. Der, für die spätere Entwicklung meines
Widgets verwendete, Multi-Touch-Tisch Mister T. wird ebenfalls technisch erläutert. In
einem weiteren Teil beschreibe ich die Entwicklung der Eingabeparadigmen bei der
Mensch-Maschine-Interaktion. Ein besonderes Augenmerk setze ich dabei auf die
Unterstützung der Benutzer durch Multi-Touch-Systeme. Anschließend werde ich die
Vielfältigkeit des Widget-Begriffs erklären und eine für den Zweck dieser Arbeit gültige
Definition geben. Auf diesen Erläuterungen werden dann die weiteren Kapitel der Analyse
und Entwicklung von Widgets aufbauen.
2.1 Entwicklung der Multi-Touch-Oberflächen
Die Erforschung berührungsempfindlicher Eingabegeräte ist kein Phänomen moderner
Computersysteme. So wurde beispielsweise bereits in den 1960er Jahren eine SingleTouch-Eingabetechnik beschrieben (Johnson, 1965). Aufgrund ihrer eingeschränkten
Möglichkeiten, wurde die Single-Touch-Technik allerdings größtenteils für das Zeigen
und Klicken als Ersatz der Maus verwendet. Erst die Multi-Touch-Technologie
ermöglichte den Einsatz von vielfältigen Gesten oder die Arbeit von mehreren Personen
an einem Bildschirm.
Die Entwicklung der Multi-Touch-Technik lässt sich bis auf das Jahr 1982 zurückführen
und basierte vorerst vor allem auf der Auswertung von Hand- und Fingerbewegungen
durch eine Kamera. Zu diesem Zeitpunkt entwickelte Nimish Mehta an der Universität von
Toronto ein System, welches auf einer vereisten Glasplatte basiert. Über eine optische
Erkennung lassen sich Fingerbewegungen auf der Glasplatte nachvollziehen und so als
Eingabe
für
ein
Zeichenprogramm
nutzen
(Mehta,
1982).
Das
erste
berührungsempfindliche Display beruht auf kapazitiven Sensoren und wurde 1984 von
Bob Boie entwickelt. Es wurde dazu eingesetzt, die Position von Bildschirmobjekten
5
durch mehrere Finger zu verschieben (Buxton, 2007). Diese Technik ermöglichte es,
dünnere und leichtere Multi-Touch-Interfaces herzustellen.
Ein frühes Multi-Touch-Tabletop-System wurde von Pierre Wellner 1991 unter dem
Namen DigitalDesk entwickelt (Wellner, 1991). Die Besonderheit liegt darin, dass sich
über dem Benutzer eine Einheit aus Projektor und Kamera befindet, welche den
Bildschirminhalt auf eine Tischplatte projiziert und Bewegungen verarbeiten kann. Somit
ist eine direkte Interaktion mit den Bildschirmobjekten möglich. Darüber hinaus ist das
System in der Lage sowohl Finger, als auch Stifte zur Eingabe und physische Dokumente
auf der Oberfläche zu erkennen. Ein weiteres bedeutendes Projekt ist das TabletopSystem DiamondTouch, entwickelt 2001 am MERL (Dietz & Leigh, 2001). Es besteht aus
einem Gehäuse ähnlich einer Tischplatte, einem Projektor und einem PC zur Steuerung
der Komponenten. Das Bild wird wiederum durch den, oberhalb des Gehäuses
angebrachten, Projektor angezeigt. Die zur Auswertung der Eingabe benötigten Sensoren
befinden sich allerdings in Form mehrerer Antennen direkt innerhalb des Gehäuses.
Durch diese Einfachheit im Aufbau der Komponenten konnte das System auch
kommerziell an Privatanwender vertrieben werden. Jedoch liegt der Fokus dieses
Systems auf der kooperativen Arbeit im Unternehmensumfeld, da sich erstmals
Interaktionen bis zu vier Personen durch Sensoren in deren Stühlen zuordnen ließen
(Dietz & Leigh, 2001).
Der kommerzielle Erfolg der Multi-Touch-Technik gelang im Jahr 2007 durch die
Vorstellung des Apple iPhone (Grossman, 2007) und Microsofts Surface (Buxton, 2007) –
einem interaktiven Multi-Touch-Tisch. Der Microsoft Surface ist als geschlossenes System
entworfen. In die Oberfläche ist ein Rückprojektions-Bildschirm von 76cm Durchmesser
eingelassen, dessen Projektor sich mit fünf Infrarot-Kameras zum Erfassen von Eingaben
und einem PC innerhalb des Systems befindet. Durch die Infrarot-Kameras lassen sich
neben Fingern auch Objekte, die an ihrer Unterseite durch sogenannte Tags
gekennzeichnet sind, erkennen und unterscheiden.
6
2.2 Multi-Touch-Tische
Abbildung 1: Aufbau des Microsoft Surface (Derene, 2007)
Dieses System wurde von Microsoft und Samsung weiterentwickelt und führte im Jahr
2011 zur aktuellen Entwicklungsstufe Surface 2.0. Hier wurde durch den Einsatz einer
102cm großen LCD-Anzeige mit eingebauter Multi-Touch-Technologie die Gesamthöhe
des Systems auf 10cm verringert. Während Samsung die Hardware vertreibt, bietet
Microsoft mit dem Surface 2.0 SDK eine Entwicklungsumgebung zur Erstellung eigener
Anwendungen. Seit dem Jahr 2012 wird die Entwicklung aufgrund der gleichnamigen
Tablet-Serie unter dem Namen Microsoft PixelSense fortgeführt.
2.2.1 Grundlegende Eigenschaften
Ein interaktives Tabletop-System besitzt als charakterisierendes Merkmal eine
horizontale Oberfläche, welche sowohl Informationen anzeigt, als auch die Schnittstelle
zwischen Mensch und Maschine bildet. Der Erfolg eines Tabletop-Systems hängt dabei
besonders von dem Zusammenspiel der Komponenten Touch-Schnittstelle, Display und
Software ab (Müller-Tomfelde, 2010, S. 6–7). Verglichen mit gewohnten, über Maus und
Tastatur gesteuerten, Systemen sehen Shen et al. (2006) drei wesentliche Vorteile von
Multi-Touch-Tischen. Zuerst wird genannt, dass die Tischoberfläche zugleich Display und
Eingabeschnittstelle ist. Dies ermögliche eine natürliche und intuitive Interaktion und
reduziere die kognitive Last bei der Benutzung. Zweitens eröffnet ein Tisch für die
Anwender die Gelegenheit der Arbeit von Angesicht zu Angesicht, was den Erfolg von
gemeinschaftlicher Arbeit begünstige. Drittens wird der großflächige Arbeitsbereich
hervorgehoben, welcher die Arbeitsweise positiv beeinflussen könne.
Die soziale Komponente ist eines der dominierenden Forschungsgebiete im Bereich der
Anwendungsszenarien interaktiver Tabletop-Systeme. Im Unternehmensumfeld lässt
7
sich
ein
interaktiver
Multi-Touch-Tisch
für
gemeinschaftliche
Arbeiten,
wie
Gruppendiskussionen oder Meetings einsetzen. Dieses Szenario wird häufig auch als
Groupware bezeichnet. Auch hier können die Benutzer von der Interaktivität der
Oberfläche profitieren. So gibt es in Meetings häufig die Situation, dass digitale
Dokumente
vorab
ausgedruckt
und
anschließend
an
alle
Teilnehmer
zu
Informationszwecken verteilt werden. Für die Ermittlung einer Problemlösung kann
dann jeder Mitarbeiter Notizen auf seinem vorliegenden Blatt anfertigen, damit diese
später wiederum digitalisiert in einem Beschluss zusammengefasst werden. Diese
Sprünge zwischen analoger und digitaler Welt könnten nach Müller-Tomfelde mit der
Unterstützung durch ein interaktives System entfallen:
It is a logical consequence to avoid the detour and the inherent media break
by transforming the surface of the table into a display able to show media that
are active and can be computer-generated and computer-controlled. (MüllerTomfelde, 2010, S. vi)
Neben diesem Groupware-Szenario gibt es eine Reihe weiterer Einsatzgebiete. In einem
White Paper über den Microsoft Surface-Tisch werden einige Anwendungsfelder ergänzt.
Dazu gehören zum einen klassische Disziplinen, wie die Datenvisualisierung zur
Präsentation oder der Unterhaltungs-Bereich, die durch neue Möglichkeiten bereichert
werden. Zum anderen werden jedoch auch Bereiche, wie interaktive Beratungsgespräche
oder der Customer-Self-Service genannt. Letzterer beschreibt eine Situation, in welcher
Kunden eigenständig Produkte über Multi-Touch-Tische konfigurieren oder sich über die
Produkteigenschaften informieren können (Bollhoefer, Meyer & Witzsche, 2009). Die
Ziele in der Entwicklung interaktiver Tabletop-Systeme liegen vorrangig in der Schaffung
von natürlichen Interaktionsmustern, um letztendlich eine effizientere und schnellere
Arbeit zu ermöglichen.
Allerdings gibt es durch diese Systeme auch neue Problemfelder, was auf den Formfaktor
und die relativ frühe Phase in der Entwicklung zurückzuführen ist. Durch die meist
Windows-basierten Systeme sind zwar gängige Desktop-Anwendungen lauffähig, für die
oben genannten Anwendungsszenarien müssen die Hersteller sie allerdings auf den
Multi-Touch- oder Multiuser-Bereich anpassen (Janssen, 2009). Darüber hinaus nennt
Müller-Tomfelde noch die Sichtbarkeit oder Erreichbarkeit von Bildschirminformationen
als weiteren Problembereich (Müller-Tomfelde, 2010, S. 4).
8
2.2.2 Der Multi-Touch-Tisch Mister T.
Die spätere Implementierung eines eigenen Widgets im Kapitel 4 werde ich auf dem
Multi-Touch-Tisch Mister T. testen. Dieser wurde von Adrian Hülsmann im Rahmen
seiner Masterarbeit entworfen und gebaut. Der Name ist ein Akronym für „Multi-Touch
Interactive Surface and Tangible Exploration Research Table”. Für die Anzeige der
Bildinformationen wurde eine Glasplatte verwendet, auf der eine Projektionsfolie
aufgebracht wurde. Die Darstellungsfläche des Tisches beträgt 160cm * 90cm, wobei das
Bild über einen Full-HD Beamer und einen Spiegel von unten auf die Glasplatte übertragen
wird. Zur Erkennung von Touch-Eingaben wurden insgesamt vier Infrarot-Laser in die
Ecken des Tisches eingelassen und außerdem zwei Kameras zur Erfassung der
Berührungspunkte integriert. Die Erkennung arbeitet nach dem Laser-Light-Plane (LLP)
Prinzip, in welcher die Laser eine Fläche von Infrarotlicht über der Oberfläche des
Displays erzeugen (Hülsmann, 2011). Wird diese Fläche durch die Berührung des
Displays unterbrochen, können über die Kameras die Berührungspunkte berechnet
werden (Spath et al., 2009, S. 21–22). Außerdem können die Kameras auch Objekte über
sogenannte Tags an der Unterseite der Objekte erkennen und unterscheiden. Die
Berechnungen sowie die Programmlogik des Systems werden von einem Windows 7-PC
übernommen.
Der Aufbau dieses interaktiven Tabletop-Systems ist also ähnlich zu dem der ersten
Microsoft Surface Version. Jedoch lassen sich durch die höhere Auflösung von 1980x1080
Pixeln zu 1024x768 Pixeln wesentlich mehr Informationen auf der Oberfläche anzeigen.
Diese ist flächenmäßig zudem etwa 6 Mal so groß wie beim Surface und eignet sich so in
höherem Maße für die simultane Arbeit mehrerer Personen.
9
2.3 Eingabeparadigmen interaktiver Benutzungsoberflächen
Eine häufig genannte Anforderung an touchbasierte Systeme ist eine möglichst natürliche
Bedienung. Im Folgenden werde ich einen kurzen Überblick über die unterschiedlichen
Eingabeparadigmen geben. Ein Eingabeparadigma beschreibt die Art und Weise der
Mensch-Maschine-Interaktion, die nötig ist, um eine gewünschte Funktion auszuführen.
Dadurch wird in großem Maße beeinflusst, welcher Personenkreis als Zielgruppe
angesprochen wird und welche Software-Lösungen für das jeweilige Eingabeschema
angeboten werden können.
2.3.1 CLI - Command Line Interfaces
Eine der ersten Interaktionstechniken war das Kommandozeilen-Interface, welches ab
der Mitte der 1960er Jahre verwendet wurde. Nutzer mussten über die Tastatur in eine
Eingabekonsole Befehle aus einem endlichen Vokabular eingeben, um Funktionen
auszulösen. Diese Technik gilt zwar als effizient, ist aber gleichzeitig fehleranfällig und
aufgrund der Komplexität vorwiegend für Experten zugänglich (Ziegler, 1996).
2.3.2 GUI – Graphical User Interfaces
Die Einführung der grafischen Benutzerschnittstelle hatte zum Ziel, einem größeren Kreis
von Menschen die Bedienung eines Computers zu ermöglichen. Das Konzept hinter
diesem Interaktionsstil wird oft durch das Akronym WIMP (windows, icons, menus,
pointing devices) beschrieben. Es steht für die einzelnen Bestandteile von GUI-Interfaces
in der Form von Fenstern, grafischen Symbolen als Repräsentation von Dokumenten oder
Funktionen, Menüs und einem Zeigegerät zur Auswahl der Bildschirmobjekte.
Die Verwendung von Metaphern für GUI-Elemente, wie die Desktop-Metapher, Ordner
oder der Papierkorb, sollten eine Vertrautheit bei der Arbeit mit Computern schaffen.
Für die Verwendung im Umfeld von interaktiven Multi-Touch-Systemen ist diese Technik
mit ihrem WIMP-Konzept allerdings aufgrund fehlender Unterstützung der Multi-UserBenutzung nicht optimal. Müller-Tomfelde kritisiert außerdem die Beschränkung des
Fingers als Zeigegerät in einem „finger-as-cursor“ Modell (Müller-Tomfelde, 2010, S. 190).
2.3.3 NUI – Natural User Interfaces
Eine große Bedeutung, auch für interaktive Tabletop-Systeme, kommt deshalb dem
Interaktionsstil des natürlichen User Interfaces zu. Buxton nennt die aufstrebenden
10
2.3 Eingabeparadigmen interaktiver Benutzungsoberflächen
Techniken
der
Touch-Technologie,
Gesichts-
und
Spracherkennung
und
Bewegungssensoren als Treiber der Entwicklung der natürlichen Benutzerschnittstelle
(Buxton, 2010).
In dem Buch „Brave NUI World“ wird der Begriff NUI wie folgt definiert:
A NUI is not a natural user interface, but rather an interface that makes your
user act and feel like a natural. (Wigdor & Wixon, 2011, S. 14)
Die Natürlichkeit bezieht sich also nicht auf die Hardware an sich, sondern auf die Art und
Weise der Interaktion zwischen Mensch und Maschine. Ein Werkzeug, dessen Bedienung
sich natürlich und vertraut anfühlt, reduziere den Lernaufwand und motiviere den
Benutzer zusätzlich, um die kompletten Möglichkeiten der Technik auszunutzen.
Die Multi-Touch-Technologie ist ein Bestandteil dieser Interaktion, da auf Maus und
Tastatur als Eingabegeräte zugunsten der Bedienung durch Finger verzichtet werden
kann. Dies führte zu einer erneuten Verringerung von Barrieren bei der Benutzung von
Technik und damit zu einer Erweiterung der Benutzerzahl (Wigdor & Wixon, 2011).
Zudem werden die Prinzipien der „Joy of Doing“ und des „Contextual Environments“, in
welchem die Anwendungsumgebung die möglichen ausführbaren Aktionen vorgibt, als
treibende Faktoren des Erfolgs dieser Interaktionsform genannt (Wixon, 2008).
Dabei soll die natürliche Benutzerschnittstelle nach Mann (2001) jedoch nicht die
vorhandenen Eingabeparadigmen verdrängen, sondern je nach Anwendungsszenario als
Alternative zu CLI und GUI auftreten (wie zitiert in Blank, 2013, S. 3).
11
2.4 Definition des Widget-Begriffs
Um eine wissenschaftliche Untersuchung von Widgets führen zu können, muss der Begriff
zuvor präzise definiert werden. Daher werde ich im Folgenden erst die Begriffsherkunft
klären und dann die Vielseitigkeit des Widget-Begriffs erläutern. Abschließend wird die,
für den Inhalt dieser Arbeit relevante, Bedeutung dargelegt.
2.4.1 Begriffsherkunft
Im Kontext der Computertechnologie wurde der Begriff „Widget“ erstmals während der
Entwicklung des Projekt Athena (Arfman & Roden, 1992) verwendet. Im Rahmen dieser
Forschung des MIT, der Digital Equipment Corporation und IBM entstand das X Window
System - ein Protokoll zur Erstellung von grafischen Benutzerschnittstellen. Der Ausdruck
Widget entstand dabei aus einer Zusammenführung der Begriffe „window“ und „gadget“,
also ein ingenieurhaft erstelltes, kleines und nützliches Werkzeug (Swick & Ackerman,
1988).
In den Oxford Dictionaries wird der Begriff folgendermaßen beschrieben: “An application,
or a component of an interface, that enables a user to perform a function or access a
service” (Oxford Dictionaries, 2014). Ein Widget sei also eine Anwendung oder Teil einer
Schnittstelle, welche es dem Benutzer ermöglicht, eine Funktion oder einen Dienst
auszuführen.
2.4.2 Vielfältigkeit des Widget-Begriffs
Die
obige
Definition
des
Begriffs
Widget
bietet
allerdings
einen
großen
Interpretationsspielraum, weshalb er in der Informationstechnologie an vielen Stellen
und für unterschiedliche Sachverhalte verwendet wird. Selbst im Umfeld von MultiTouch-Systemen werden verschiedene Dinge als Widget bezeichnet. Trotz der vielfältigen
Besetzung des Widget-Begriffs liegt eine Gemeinsamkeit aller Definitionen darin, dass der
Benutzer des Widgets durch eine geschickte Mensch-Maschine-Interaktion eine Funktion
oder ein Problem leichter lösen kann, als über die standardmäßige Bedienungsweise. In
der Literatur werden unter anderem die folgenden Kategorien unterschieden:
Desktop Widgets. In die Kategorie der Desktop Widgets fallen unter anderem die, mit
Windows Vista eingeführten, „Windows Gadgets“ oder Apples „Dashboard
Widgets“. Sie stellen eine bestimmte Art von Anwendung dar, die meist nur eine
12
einzige Funktion anbietet und vom Nutzer auf dem Desktop platziert werden kann.
Hierzu zählen beispielsweise ein Kalender, eine Wetteranwendung oder ein
Taschenrechner.
Abbildung 2: Beispielhafte Auswahl verschiedener Windows Gadgets
Mobile Widgets. Diese Kategorie der Widgets ist als eine Unterkategorie der Desktop
Widgets anzusehen und beschreibt die Erweiterung auf mobile Endgeräte und
Smartphones. Widgets für Googles Android-Plattform bieten beispielsweise, im
Gegensatz zu den statischen App-Verknüpfungen, das dynamische Nachladen von
Inhalten oder die Ausführung eines Befehls an. Konkret werden die Typen
„Information Widgets“, „Control Widgets“, „Collection Widgets“ und „Hybrid
Widgets“ unterschieden (Google Inc., 2012).
Abbildung 3: „Hybrides“ Widget zur Steuerung von Music-Player-Funktionen
und Anzeige von Titel-Informationen (Google Inc., 2012)
Web Widgets. Der vom World Wide Web Consortium (W3C) erstellte Standard der
„Packaged Web Apps (Widgets)“ beschreibt Widgets als eine Klasse von
webbasierten, client-seitigen Anwendungen (World Wide Web Consortium [W3C],
2012). Diese verwenden klassische Web-Standards. Der Vorteil dieser Technik
betrifft vor allem mobile Endgeräte, da für die jeweiligen Dienste lediglich einmalig
die Programmlogik geladen werden muss, damit Inhalte anschließend dynamisch
13
angezeigt werden können. Im Unterschied zu den oft proprietären Mobile Widgets
oder Apps funktionieren die Web Widgets nach dem „write once, run anywhere”Prinzip (Koch, 2009) unabhängig vom verwendeten Betriebssystem.
Abbildung 4: Web-Widget zur Veröffentlichung auf der Homepage (S-Bahn
Berlin GmbH, 2012)
GUI Widgets. Anders als in den Definitionen zuvor wird das GUI Widget nicht als
eigenständige Anwendung selbst definiert, sondern als ein Element der grafischen
Benutzerschnittstelle (GUI). Ziel ist die Unterstützung des Benutzers bei der
Aufgabenlösung durch das Anzeigen von, für den jeweiligen Anwendungskontext
geeigneten, Steuerelementen. Diese angezeigten Interaktionselemente bilden für
den Benutzer einen Bereich zur direkten Manipulation der Bildschirmdaten. Den
Fokus bilden hier also das spezielle „look and feel“ der Interaktionselemente,
sowie die flüssige und geschickte Interaktion (Ziegler, 1996).
14
Abbildung 5: Widget im Notizprogramm OneNote zur Unterstützung der
Touch-Bedienung (Bott, 2012)
2.4.3 Präzisierung der Definition zu GUI-Widgets
Für die Bearbeitung meiner Forschungsfrage lege ich die Definition der GUI Widgets – im
Folgenden unter dem Begriff „Widget“ verwendet – zu Grunde. Um ein Verständnis über
den Aufbau eines Widgets und die Bedeutung für interaktive Tabletop-Systeme zu
bekommen, werde ich nachstehend die Eigenschaften eines GUI Widgets weiter
präzisieren.
Widgets besitzen einen modulhaften Aufbau. Es lassen sich also mehrere atomare
Steuerelemente, wie Buttons und Slider, zu einer Elementgruppe zusammenfügen. Dies
führt dazu, dass sich sowohl einfache single-purpose Widgets, als auch mächtigere
Werkzeuge mit einer größeren Funktionsvielfalt bilden lassen. Damit die verfügbare
Bildschirmfläche
nicht
mit
Steuerelementen
überlagert
wird,
sind
Widgets
standardmäßig nicht sichtbar beziehungsweise in einem inaktiven Zustand. Es bedarf
einer expliziten Aktivierung durch den Benutzer, um die Interaktionselemente
anzuzeigen oder zu aktivieren. Innerhalb des klassischen Eingabeparadigmas mit Maus
und Tastatursteuerung geschieht dies beispielsweise durch einen Klick mit der Maus. Im
Bereich der Multi-Touch-Oberflächen ist dies über eine Handgeste möglich. Ebenso lassen
sich die Widgets entweder automatisch nach erfolgreicher Ausführung eines Befehls oder
durch manuelle Aktionen wieder ausblenden. Die gezielte Aktivierung hat den Vorteil,
dass die Interaktionselemente direkt an der Stelle angezeigt werden können, an welcher
der Benutzer Informationen manipulieren möchte.
15
Im Kontext von interaktiven Tabletop-Systemen besteht ein Bedarf an diesen Lösungen,
weil sich gewohnte Konzepte mit statisch angeordneten Interaktionselementen nicht
immer auf die erforderlichen Einsatzgebiete übertragen lassen. Dies wird beispielsweise
bei der Verwendung des Systems durch mehrere Benutzer zur gleichen Zeit oder durch
die Verdeckung von Bildschirminhalten durch physische Gegenstände, die sich im
Arbeitsalltag auf der Bildschirmoberfläche befinden (bspw. Aktenordner), deutlich.
16
3 Untersuchung von Widgets
Im vorherigen Kapitel wurde bereits an einigen Stellen auf die Probleme und
Herausforderungen eingegangen, die durch die Entwicklung der Multi-Touch-Systeme
entstanden. Im folgenden Kapitel bearbeite ich mit der Kategorisierung von Widgets den
ersten
Hauptbestandteil
meiner
Zielsetzung.
Zuvor
werden
allerdings
die
Anwendungsdomänen von Widgets hinsichtlich der Multi-Touch-Interaktion im
Allgemeinen und der Verwendung im Bereich interaktiver Tabletop-Systeme im
Speziellen erläutert. Für die Kategorisierung selbst wurden etwa 90 verschiedene
Widgets und Widget-Toolkits aus
wissenschaftlichen Forschungsarbeiten und
Konferenzbeiträgen analysiert. Ziel dieser Klassifizierung ist es dabei auch, mögliche
Bedarfe in bisher unterrepräsentierten Kategorien aufzudecken und als Ergebnis für die
spätere Entwicklung eines eigenen Widgets zu verwenden. Außerdem gehe ich näher auf
die Vorteile und Nachteile der Benutzung von Widgets im alltäglichen Arbeitsumfeld ein.
Anschließend werden die in diesem Kapitel gewonnenen Erkenntnisse für die
Bearbeitung der Forschungsfrage „Was muss geleistet werden, um neue Widgets zu
designen?“ verwendet, um einen kurzen Leitfaden der Widget-Erstellung zu beschreiben.
3.1 Vorteile von Widgets
Ein genereller Vorteil von Widgets im Bereich von Multi-Touch-Systemen ist, dass
Anwendungsfolgen und Anwendungsszenarien schneller und sicherer ausgeführt werden
können, als ohne den Einsatz dieser Technik. Denn durch ihren Charakter als
„Problemlöser“ werden Widgets häufig dazu eingesetzt, umständliche und langwierige
Anwendungsfolgen über geschickte Aktionen abzukürzen und zu vereinfachen. Teilweise
befähigt der Einsatz eines bestimmten Widgets den Benutzer auch erst dazu, eine Aufgabe
auszuführen – beispielsweise bei Arbeiten, die sich nicht direkt von der klassischen MausTastatur-Bedienung auf Multi-Touch-Oberflächen übertragen lassen.
Aus dieser Fähigkeit, Aufgabenbereiche effizienter und sicherer ausführen zu können,
folgen dann weitere Effekte für verschiedene Personengruppen.
Für Anwender entsteht das Gefühl, die Tätigkeiten komfortabler erledigen zu können.
Dies resultiert nicht zuletzt auch aus der bereits angesprochenen natürlichen Eingabe
17
über die Finger des Anwenders. Außerdem weisen Widgets meist eine hohe Usability auf,
weil die Entwickler schon beim Design eines Widgets sorgfältig planen müssen, wie die
Funktionen auf einer relativ kleinen Aktionsfläche sinnvoll angeordnet werden können.
Aufgrund dieses besonderen Zusammenspiels von der Nützlichkeit eines Widgets zur
Lösung eines Problems auf der einen Seite und der meist guten Benutzbarkeit auf der
anderen Seite, entsteht nach Hassenzahl, Beu und Burmester (2001) das Gefühl der „Joy
of Use“ (Hassenzahl et al., 2001, S. 6). Diese Zufriedenheit und Freude an der Anwendung
sorgt dafür, dass die Benutzer in der alltäglichen Arbeit mit dem System bereit sind, die
Funktionen der Widgets zu erforschen und effizient einzusetzen.
Nachfolgend werden noch einige ausgewählte positive Eigenschaften von Widgets
hervorgehoben und erläutert.
Die benutzergesteuerte Aktivierung von Widgets erzeugt durch das Einblenden der
Interaktionselemente
im
direkten
Blickfeld
des
Anwenders
einen
ähnlichen
Aufmerksamkeit erregenden Effekt, wie Popups im Web-Umfeld. Der Anwender wird also
unmittelbar mit den ausführbaren Funktionen konfrontiert, was zu einer intensiveren
Auseinandersetzung mit den angebotenen Möglichkeiten führt, als bei der Ausführung
von Operationen über ein Menü.
Darüber
hinaus
sind
die
Operationen
der
Widgets
auf
den
spezifischen
Anwendungskontext des Systems angepasst und bieten somit eine Menge von Befehlen
an, welche dem Benutzer bei der Lösung seiner aktuellen Aufgabe weiterhelfen kann.
Ein weiterer Aspekt ist die intuitive Bedienung. Diese wird über die direkte Interaktion
mit Objekten an ihrer aktuellen Bildschirmposition erreicht. Auf diese Weise wird für die
Anwender der kognitive Aufwand bei der Erinnerung an die, zur Aufgabenerledigung
nötigen, Anwendungsfolgen verringert.
Alle hier aufgezählten Punkte führen – wenn sie optimal eingesetzt und aufeinander
abgestimmt werden – zu eben jenen Kriterien, wie beispielsweise der Zeitbedarf für die
Erlernung einer Funktion oder die Zeitspanne und Fehlerrate zur Ausführung einer
Aufgabe, welche Shneiderman und Plaisant (2010) nennen, um die Usability-Ziele
Effektivität, Effizienz und Befriedigung zu erreichen.
18
3.2 Nachteile von Widgets
3.2 Nachteile von Widgets
Die im vorherigen Abschnitt erwähnten Vorteile von Widgets setzen eine durchdachte
Abstimmung auf das jeweilige System und einen quantitativ passenden Einsatz der
Technik voraus. Würde man für jedes beobachtete Problem ein Widget entwerfen, führte
dieser „Overuse“ von Widgets zu einer verringerten Bedienbarkeit des Gesamtsystems.
Widgets sind also kein Allheilmittel für die Interaktion mit interaktiven TabletopSystemen.
Gleichzeitig existieren auch einige generelle Nachteile der Widget-Interaktion. Diese
Nachteile manifestieren sich in Gefahren, mit welchen sich Entwickler bei der
Implementierung auseinandersetzen müssen.
Ein grundsätzlicher Nachteil von Widgets zeigt sich im Fehlen von einheitlichen
Konventionen, sowohl für ihre Aktivierung, als auch für die Gestaltung (Derboven et al.,
2012). Die fehlende Standardisierung bei der Aktivierung kann mit der wachsenden
Anzahl an unterschiedlichsten Widgets zu inkonsistentem Verhalten führen. Zwar sind
Widgets meist auf einen Anwendungskontext beschränkt, es können aber durchaus
Widgets auf unterschiedlichen Ebenen gleichzeitig aktiv sein. Beispielsweise zur
Ausführung von Basisfunktionalitäten für das Betriebssystem und als Unterstützung
einer
Benutzeranwendung.
Haben
diese
Widgets
nun
einen
identischen
Aktivierungsvorgang, überlagern sie sich und können so unvorhergesehene Effekte
auslösen. Das Fehlen eines einheitlichen Verzeichnisses von Widget-Aktivierungen zu
ihren jeweiligen Anwendungsprogrammen macht eine Vermeidung von identischen
Aktivierungen schwer realisierbar. Die Idee, die eigenen Gesten komplexer zu gestalten,
um eine versehentliche Aktivierung anderer Widgets auszuschließen, ist ebenso
impraktikabel, da dieser Schritt zu einem erhöhten Lernaufwand auf Seiten der Anwender
führt und somit die Gefahr besteht, dass ein Widget aufgrund der aufwendigen
Aktivierung gemieden wird. Aus einer nicht einheitlichen Gestaltung von Widgets
entsteht die Gefahr, dass das gesamte „look and feel“ des Systems beeinträchtigt wird und
Anwender durch diese Inkonsistenz Aufgaben nicht in der gewohnten Geschwindigkeit
erledigen können.
Ein weiterer konzeptioneller Nachteil von Widgets ist der anfänglich schwierige Einstieg
beim Erlernen der Interaktionstechniken. Denn systemweit kann es eine Vielzahl von
19
Widgets für die unterschiedlichsten Anwendungszwecke geben. Sie alle sind initial für
den
Anwender
nicht
sichtbar
und
warten
darauf
in
einer
bestimmten
Anwendungssituation aktiviert zu werden. Um sämtliche Funktionen nutzen zu können,
müssen Anwender diese Aktionen also entweder durch Ausprobieren selbst erforschen
oder sie im Handbuch nachlesen. Diese Anforderung wird allerdings durch Rettig (1991)
etwas überspitzt mit den Worten „Nobody Reads Documentation“ (S.19) als nicht
durchsetzbar eingestuft. Zudem sollte die Verwendung der Widgets unmittelbar
erschließbar sein, da sonst der Aufwand zum Merken der verwendeten Techniken steigt.
3.3 Anwendungsdomänen von Widgets
Die möglichen Anwendungsfelder von Widgets sind ebenso vielfältig, wie die Fülle der
verschiedenen verfügbaren Lösungen selbst. Ihr Charakter als Problemlöser beeinflusst
diese Vielfalt maßgeblich. Darum erscheint es sinnvoll Anwendungsdomänen aus den
Herausforderungen der Touch-Interaktion abzuleiten. Dadurch, dass sich beispielsweise
erlernte Vorgehensweisen der Maus- und Tastaturbedienung nicht direkt auf TabletopSysteme übertragen lassen, wurden nach und nach hilfreiche Steuerelemente entwickelt,
um auf die angepassten Umstände zu reagieren. Denn grundsätzlich sind die klassischen
Desktop-Anwendungsprogramme auch auf einer Tabletop-Plattform lauffähig. Die
treibenden Erfolgsfaktoren der Widgets sind allerdings die mit ihnen erreichbare
Effizienz in der Bedienung und die damit einhergehende Akzeptanz auf Seiten der
Benutzer.
Aufgrund des modulhaften Aufbaus von Widgets sind die Anwendungsfelder teilweise
schwer zu präzisieren, da Widgets oft gleich mehrere Funktionen vereinen. Außerdem
lassen sich weitere Domänen abseits der Problemfelder bestimmen. Der nachfolgende
Abschnitt soll einen umfassenden Überblick über die Anwendungsdomänen der Widgets
geben.
3.3.1 Herausforderungen allgemeiner Touch-Interfaces
In ihrem Forschungsbericht zu den Herausforderungen an das Design der
Benutzerschnittstelle für Multi-Touch-Interfaces nennen Bachl, Tomitsch, Wimmer und
Grechenig (2010) im Wesentlichen drei Problemklassen. Dies sind displaybasierte
Herausforderungen,
userbasierte
Herausforderungen
und
eingabebasierte
Herausforderungen. Während die Anforderungen an das Display vor allem auf die
20
Ausgestaltung des Hardware-Interfaces eingehen, beschäftigen sich die übrigen
Kategorien mit den Problemen, welche durch die Interaktion mit touchbasierten
Systemen entstehen. Nachfolgend werde ich zuerst die potenziellen Anwendungsfelder
für Widgets nennen, die Bachl et al. für die allgemeine Gattung der Touch-Displays
ermittelt haben. Hierzu zählen beispielsweise auch Smartphones und Public Displays.
Später wird in diesem Kapitel dann auf die spezielle Situation der interaktiven TabletopSysteme eingegangen.
Zu den nutzerbasierten Herausforderungen wird die Okklusion gezählt. Gemeint ist mit
diesem Begriff die Verdeckung von GUI-Elementen oder grafischer Rückmeldung durch
die Hände des Anwenders. Erscheint ein Interaktionsobjekt nach der Aktivierung direkt
unterhalb des Berührungspunktes auf dem Bildschirm, kann dieses vom Handballen des
Benutzers komplett oder teilweise verdeckt werden. In diesem Fall ist es nicht direkt
ersichtlich, ob die Funktion nun korrekt ausgeführt wurde oder ob ein Bedienungsfehler
vorliegt, was zu einer Verwirrung des Benutzers führt. Außerdem wird grafisches
Feedback häufig durch den Finger überdeckt. Verglichen mit der Interaktion mittels Maus
und Tastatur konnte der Effekt des „Hineindrückens“ eines Buttons direkt
wahrgenommen werden.
Abbildung 6: Vergleich von Maus- und Touch-Interaktion. Durch das „FatFinger-Problem“ werden der genaue Berührungspunkt und etwaige grafische
Rückmeldungen überdeckt (Bachl et al., 2010).
Ein weiterer Faktor im Bereich der benutzerbasierten Herausforderungen ist die
Beachtung der individuellen körperlichen Unterschiede der Benutzer. Konnten bisher
unterschiedliche Handgrößen durch die Wahl einer entsprechenden Maus berücksichtigt
werden, spielt die Größe der Finger beziehungsweise der Hände der Benutzer für TouchDisplays eine größere Rolle.
Zur Kategorie der eingabebasierten Herausforderungen zählen Bachl et al. alle
touchbasierten Arten der Datenmanipulation. Generell wird jedoch auch auf die reine
21
Funktionsvielfalt der Eingabe-Hardware eingegangen. So verfügt eine gängige
Computermaus über drei Tasten und ein Scrollrad. Dies ermöglicht die Verwendung vier
unterschiedlicher Funktionen über ein Eingabegerät. Der menschliche Finger hingegen
löst auf einem einfachen Touch-Interface allerdings nur Berührungspunkte aus. Die
Verwendung von Gesten oder Multi-Touch-Eingabe kann diese Limitierung auf eine
einzelne Funktion aufheben, bringt aber auch den Nachteil, dass nicht alle Systeme diese
Techniken nach den gleichen Konventionen implementieren. Bei der Dateneingabe über
eine Bildschirmtastatur wird wiederum das Problem des fehlenden haptischen Feedbacks
als problematisch angesehen. Dies führe erneut zur Notwendigkeit der grafischen
Rückmeldung an einer geeigneten Stelle des Bildschirms (Bachl et al., 2010).
3.3.2 Herausforderungen an interaktive Tabletop-Systeme
Neben den Herausforderungen an allgemeine Touch-Interfaces, geben Bachl et al. auch
die folgenden Fälle speziell für das Umfeld der Tabletop-Systeme an.
Zum einen wird die zuvor genannte Beeinträchtigung der Verdeckung von GUI-Elementen
bei horizontalen Displays um die Unterarme der Benutzer und sich willkürlich auf der
Oberfläche befindliche Gegenstände erweitert. In diesem Umfeld ist es also nicht
ausreichend, nur die Verdeckung durch den Benutzer selbst in Betracht zu ziehen,
sondern darüber hinaus auch Möglichkeiten anzubieten, auf die Verdeckung von Objekten
in zufälliger Größe und Position zu reagieren. Zudem wird mit der Ermüdung und
Belastung der Muskeln aufgrund der Größe dieser Systeme ein neuer Aspekt in Bezug auf
die Ergonomie hinzugefügt. Die Varianten der Problemlösung sind in dieser Aufgabe
vielfältig. So können Widgets zum leichteren Erreichen eines entfernten Objekts oder
auch eine grundsätzlich andere Aufteilung der Displayfläche eingesetzt werden. Als
Beispiel ist hier das von Shen et al. (2006) entwickelte System zu nennen, welches
gleichzeitig Feedback am Ort der Interaktion und um das aktivierte Objekt selbst bietet.
22
(a)
(b)
Abbildung 7: Beispiel einer Technik zur Verhinderung von Okklusion. Sobald
der Benutzer mit seinem Finger eine Schaltfläche berührt und somit eventuell
verdeckt (a), wird die Schaltfläche entsprechend gr ößer dargestellt (b) (Shen
et al., 2006).
Um auch den Einsatzbereich der kooperativen Arbeit zu berücksichtigen, wird zudem der
Bedarf an Techniken zur Verwaltung von „dedicated zones“ (Bachl et al., 2010, S. 4) – also
nutzereigenen Bereichen auf der Bildschirmfläche erwähnt. Morris, Ryall, Shen, Forlines
und Vernier (2004) schildern in ihrer Forschung zum sozialen Verhalten bei der
Benutzung von Groupware auf interaktiven Tabletop-Systemen sogar das Problem des
Stehlens von Dokumenten oder Informationen, wenn die persönlichen Bereiche der
Teilnehmer fließende Übergänge bieten würden. Außerdem würden Effekte wie die
Kollision oder Überlappung von Fenstern unterschiedlicher Nutzer auftreten, welche den
Arbeitsfluss beeinträchtigen könnten (Morris et al., 2004).
Überdies nennen Shen, Vernier, Forlines und Ringel (2004) folgende „Fundamental
tabletop UI functionality“, welche über die bereits genannten Anwendungsfelder
hinausgeht. Der Bereich „Visual document management“ enthält die Forderung, ein zu
bearbeitendes Dokument müsse sich willkürlich drehen und verschieben lassen, um
jederzeit auf den Blickwinkel des Benutzers ausgerichtet werden zu können. Zusätzlich
sollen Dokumente an ihrer aktuellen Position steuerbar sein, um nicht mit einem
gegebenenfalls entfernteren Rahmen des Hauptprogramms interagieren zu müssen.
Unter der Anforderung des „Digital tabletop layout“ sind die Erstellung und die
Verwaltung von Bildschirmunterbereichen zusammengefasst. Hierzu zählen neben den
oben genannten „dedicated zones“ als privater Bereich auch öffentliche Zonen, in denen
alle beteiligten Personen Objekte ablegen und bearbeiten können. Darüber hinaus soll es
23
möglich sein, den Bildschirmbereich in kleinere Unterbereiche teilen zu können, wobei
jeder
Unterbereich
die
Funktionalität
eines
eigenständigen
Tabletop-Systems
übernimmt. Schließlich wird im Bereich des „Multi-user support“ der Bedarf nach Menüs
beschrieben, die sich für jede beteiligte Person duplizieren lassen, um auch dem Problem
der Erreichbarkeit zu begegnen. Darüber hinaus gibt es die allgemeine Forderung nach
Techniken zur Unterstützung der nebenläufigen Arbeit mehrerer Beteiligter (Shen et al.,
2004).
3.3.3 Weitere Anwendungsfelder von Widgets
Zusätzlich zu ihrer Aufgabe als „Problemlöser“ für die Anforderungen an Multi-TouchDisplays werden Widgets überdies auch genutzt, um die Funktionsvielfalt zu erhöhen und
um die Effizienz der Bedienung zu steigern. Die Forschung konzentriert sich dabei vor
allem auf die als wirtschaftlich vielversprechend angesehenen Anwendungsbereiche.
Eine Studie von Benko, Morris, Brush und Wilson (2009) erforschte die
Anwendungsfelder interaktiver Tabletop-Systeme von erfahrenen Benutzern. Dabei
belegten die Betrachtung von Unterhaltungsmedien (36%) und die kooperativen
Arbeiten (31%), wie beispielsweise Brainstorming, die Spitzenplätze. Diese Ergebnisse
sind in Einklang mit der Bewertung der Angemessenheit eines Tabletop-Systems zur
Lösung einer spezifischen Aufgabe. Auch hier wurden Entertainment, Visualisierung und
kooperative Aufgaben als „sehr geeignet“ zur Lösung mit Tabletop-Systemen bewertet.
Daraus folgt indirekt die Anforderung an die Forschung, entsprechende Widgets zur
Erleichterung dieser Tätigkeiten zu entwickeln, welche insgesamt von den technischen
Vorteilen der Multi-Touch-Tische profitieren können und welche auch in der klassischen
Mensch-Computer-Interaktion
noch
nicht
entworfen
wurden.
Denkbar
wäre
beispielsweise ein Widget im Groupware-Umfeld, welches Steuerungsmöglichkeiten für
den öffentlichen Bereich des Displays enthält und sich über Gesten unter den
Teilnehmern weiterreichen lässt. Auf diese Weise kann die Konsistenz der
Arbeitsergebnisse sichergestellt werden und gleichzeitig würde dem Problem der
Erreichbarkeit von GUI-Elementen begegnet.
24
3.4 Aktivierung von Widgets
Wie bereits in Kapitel 2.4 beschrieben, besitzen Widgets die beiden Zustände „aktiv“ und
„inaktiv“. Während das Widget im aktiven Zustand Benutzereingaben entgegennimmt
und Funktionen ausführen kann, nimmt es im inaktiven Zustand keine Eingaben entgegen
und ist daher ausgeblendet. Um zwischen diesen beiden Zuständen zu wechseln, also
entweder das Widget auf Anforderung anzeigen zu lassen oder auszublenden, werden
verschiedene Techniken eingesetzt. Diese Routinen und die Probleme im Entwurf von
Aktivierungsmechanismen sollen im Folgenden näher erläutert werden.
Grundsätzlich lassen sich die Aktivierungsmöglichkeiten von Widgets in zwei Klassen
unterteilen – die automatische, anwendungsgesteuerte Aktivierung und die durch eine
Benutzeraktion
angeforderte,
manuelle
Aktivierung.
In
die
Klasse
der
benutzergesteuerten Aktivierung von Widgets fallen einerseits statische Finger- und
Handhaltungen (engl.: postures) und andererseits dynamische Gesten (engl.: gestures).
Außerdem gibt es die Möglichkeit, Widgets über physische Objekte auf der TouchOberfläche - sogenannte Tangible User Interfaces – zu aktivieren.
3.4.1 Automatische (De-)Aktivierung
Erstere Klasse wird in produktiven Systemen überwiegend zur Deaktivierung von
Widgets genutzt. Häufig ist durch den Anwendungszweck des Widgets im Vorfeld
bekannt, dass nach der Ausführung einer durch das Widget bereitgestellten Funktion
selbiges Widget im Anschluss deaktiviert werden kann, da ein Anwendungsschritt
beendet wurde. Dies ist vor allem bei single-purpose Widgets der Fall, welche
beispielsweise für die Auswahl einer Datei oder eine einzelne Eingabe zuständig sind. Die
automatische Aktivierung von Widgets kann beispielsweise durch einen Moduswechsel
des Anwendungsprogramms, vom Betrachtungs- in den Bearbeitungsmodus, ausgelöst
werden.
Eine besondere Form stellt die automatische Aktivierung durch externe Ereignisse dar.
Viele interaktive Tabletop-Systeme können neben Berührungspunkten auch auf der
Bildschirmoberfläche abgestellte Gegenstände erkennen. Auf diese Weise kann ein
Widget beispielsweise auf die Verdeckung von Informationen durch einen Gegenstand
automatisch reagieren.
25
Bei der automatischen (De-)Aktivierung von Widgets entstehen kaum Probleme in der
Interaktion des Benutzers mit dem Tabletop-System, da entsprechende Steuerelemente
je nach aktuellem Anwendungszustand ein- und ausgeblendet werden. Eine große
Einschränkung dieser Technik besteht aber darin, dass hierfür eindeutige Workflows und
Regeln für die Zeitpunkte der Aktivierung und Deaktivierung von Widgets existieren
müssen. Diese Eindeutigkeit ist in den wenigsten praktischen Fällen gegeben, weshalb die
automatische (De-)Aktivierung eine eher untergeordnete Rolle in der Forschung spielt.
3.4.2 Statische Haltungen
Im Bereich der statischen Haltungen oder auch „static postures“ (Malik & Laszlo, 2004, S.
292) erwähnen Shen et al. (2006) vier unterschiedliche Kategorien von Aktionen. Dazu
zählen bestimmte Haltungen der gesamten Hand, einfache Berührungen der Finger,
Posen mit einer gewissen Verweilzeit der Finger auf dem Display oder eine spezifische
Anzahl aufeinanderfolgender Berührungen des Bildschirms. Für jede dieser Aktionen
lassen sich dabei verschiedene Parameter festlegen, welche nötig sind, um das
entsprechende Widget zu aktivieren. Hierzu zählen beispielsweise die erforderliche
Anzahl von Fingern, die zeitliche Abfolge der Berührungen oder die Entfernung der
Berührungspunkte untereinander.
3.4.3 Dynamische Gesten
Im Gegensatz zu den statischen Postures beinhalten Hand- und Fingergesten stets einen
dynamischen Teil. In ihrer Forschung über Gesten im Rahmen digitaler Tabletop-Systeme
nennen Wobbrock, Morris und Wilson (2009) die vier zentralen Dimensionen „form,
nature, binding and flow“ (S. 1086) für die Klassifizierung von Gesten. Die Eigenschaft
„form“ bezieht sich dabei auf die Art der Bewegung während der Geste, unterschieden in
Positionsänderungen der Hand oder der Bewegung einzelner Finger. Der Begriff „nature“
definiert die Beschaffenheit der Geste. Diese kann der Form eines Symbols
nachempfunden sein (beispielsweise das Zeichnen eines Fragezeichens, um die
Hilfefunktion aufzurufen), eine Metapher abbilden oder abstrakter Natur sein. Die
Eigenschaft „binding“ beschreibt, ob die Geste auf einem Objekt ausgeführt wurde, eine
Bindung zum Ort der Ausführung besitzt oder unabhängig von Objekten oder
Ausführungsposition ist. Schließlich schildert die Dimension „flow“, ob die Geste bereits
eine direkte Rückmeldung während der Ausführung auslöst oder ob erst mit Abschluss
der Geste eine Funktion ausgeführt wird.
26
3.4.4 Tangible User Interfaces
Die technologische Realisierung von Tangible User Interfaces variiert je nach
Forschungsgruppe. Meist wird eine Kamera, die sich unterhalb der Projektionsoberfläche
des Multi-Touch-Tisches befindet, dazu eingesetzt die unterschiedlichen Tangible Bits zu
erkennen. Dies geschieht durch eine eindeutige Markierung, welche an der Unterseite der
Tangibles angebracht ist. Sobald der Benutzer also ein dementsprechend ausgestattetes
Interaktionselement auf die Tischoberfläche legt, wird dieses erkannt und das System
kann automatisch ein dazugehöriges Widget aktivieren. Diese Aktivierungsmöglichkeit
benötigt somit keinen weiteren Lernaufwand auf Seiten der Benutzer und birgt auch nicht
die Risiken einer versehentlichen Aktivierung. Auf der anderen Seite entstehen durch
diese Techniken auch neue Herausforderungen, wie beispielsweise die Entscheidung wie
viele unterschiedliche Tangible User Interfaces für ein Anwendungsszenario eingesetzt
werden sollten.
27
3.5 Klassifikation
In diesem Abschnitt befasse ich mich mit der Klassifikation von Widgets, welche ein
zentraler Bestandteil dieser Arbeit ist. Dafür werde ich Forschungsarbeiten um die
Themen Multi-Touch-Interaktion und interaktive Tabletop-Systeme analysieren und im
Hinblick auf die Interaktionstechniken untersuchen. Mein Ziel ist es dabei, wesentliche
wiederkehrende Interaktionsprobleme aufzudecken und die Widgets, welche diesen
Problemen begegnen, verschiedenen Klassen zuzuordnen.
Forschergruppen um Buxton, Morris (beide Microsoft Research), Shen (MERL) und
Weitere entwickelten im Rahmen ihrer Forschung im Bereich der interaktiven TabletopSysteme sowohl eine Reihe an kompletten geschlossenen Systemen, als auch eine Vielzahl
atomarer Widgets für jeweils eine spezifische Problemstellung. Zusätzlich werden über
Konferenzen, wie der jährlichen „ACM International Conference on Interactive Tabletops
and Surfaces“, weitere Beiträge zur Widget-Interaktion publiziert.
Gerade diese Vielfalt an angebotenen Widgets stellt allerdings ein Problem für Entwickler
und Anwender gleichermaßen dar. Durch fehlende Standardisierung und das Fehlen
eines zentralen Anlaufpunktes oder Verzeichnisses bisheriger Arbeiten ist es schwierig,
einen Überblick über den aktuellen Forschungsstand zu bekommen. Mögliche Anwender
können beispielsweise Schwierigkeiten haben, ein geeignetes Widget für ihre
Problemstellung zu finden. Entwicklern fehlt hingegen ein Anhaltspunkt darüber, welche
Bereiche bereits über ausreichende Lösungen verfügen.
3.5.1 Verwandte Arbeiten
Dachselt (2004) leistete im Rahmen seiner Dissertation bereits eine Klassifikation von
3D-Widgets. Dies sind Widgets, welche speziell auf den Einsatz in VR-Applikationen
(Virtuelle Realität) entworfen wurden.
Die Klassifikation erfolgte dabei nach dem Kriterium „Einsatzbereich / Interaktionsziel“
(Dachselt, 2004, S. 58). Als Hauptkategorien wurden die Punkte „3D-Objektselektion“,
„Objektmanipulation“, „Exploration und Visualisierung“ und „Anwendungskontrolle“
festgelegt (Dachselt, 2004, S. 59).
28
3.5 Klassifikation
Diese Einordnung ist für meine Arbeit insofern nützlich, da sie neben reinen 3DInteraktionstechniken auch einige Konzepte von 2D-Widgets enthält, welche ohne
größere Anpassungen für den Einsatz in VR-Umgebungen verwendet werden können.
Außerdem ermöglicht mir die Arbeit von Dachselt die Übernahme einiger
Anwendungsszenarien, die gleichermaßen in der 2D- und 3D-Interaktion vorhanden sind.
3.5.2 Systematik
Um ein geeignetes Kriterium für die Klassifikation zu bestimmen, müssen zum einen das
angestrebte Ziel und zum anderen die Eigenschaften der Widgets selbst betrachtet
werden.
Da
mein
Klassifikationsergebnis
primär
für
Entwickler
neuer
Interaktionsmethoden hilfreich sein soll, verwende ich im Folgenden das, schon von
Dachselt
eingesetzte,
Klassifikationskriterium
nach
Einsatzbereich
bzw.
dem
Interaktionsziel des Nutzers. Dies bezieht sich auf „die generelle Teilaufgabe und das
beabsichtigte Ziel einer Handlung […] ohne auf technische Teilhandlungen einzugehen.
Dieses Kriterium entspricht am ehesten einer pragmatischen Herangehensweise, wo Ziele
verfolgt werden, wie z.B.: die Auswahl eines Objektes.“ (Dachselt, 2004, S. 58). Eine
ermittelte Klassifikation (beispielsweise „Objektselektion“) kann dann, je nach
Problemfeld spezifiziert werden („Pixelgenaue Selektion“). Diese Klassifikation stützt sich
in gewisser Weise also auch auf die, vorab in diesem Kapitel aufgezählten,
Herausforderungen und Problemfelder der Widget-Interaktion.
Meine Klassifikation wird sich dabei auf die Kernbereiche der interaktiven TabletopSysteme fokussieren. Dazu zählen neben dem kooperativen Arbeiten, die auf TouchEingaben angepasste Anwendungssteuerung, sowie die Selektion einzelner Objekte.
Widgets, die innerhalb einer Spezialanwendung angeboten werden, werden für diese
Kategorisierung nicht betrachtet. Hierfür müssten zuerst einheitliche Kriterien zur
Auswahl dieser Anwendungen aufgestellt werden. Außerdem sind die innerhalb einer
Anwendung verwendeten Widgets häufig nicht zentral dokumentiert, was eine Aufnahme
in die Menge der zu analysierenden Widgets ausschließt.
29
3.5.3 Vorstellung der Kategorien
Durch meine Wahl des Interaktionsziels als Klassifikationskriterium ist es sinnvoll, die
bereits ausgearbeiteten Anwendungsdomänen von Widgets im Tabletop-Umfeld auf
Berührungspunkte zu untersuchen und gleichzeitig mit den, von Dachselt festgelegten,
Kategorien abzugleichen.
Eine Übernahme der Kategorien Objektselektion und Anwendungskontrolle erscheint
logisch, da sich diese mit den gefundenen Anwendungsdomänen decken. Als dritte
Hauptkategorie für meine Klassifikation wähle ich die Unterstützung von Widgets bei der
kooperativen Arbeit aus, weil dieser Bereich bereits als treibende Kraft des Erfolgs
interaktiver Tabletop-Systeme herausgestellt wurde.
Die nachfolgende Tabelle gibt einen Überblick über die Kategorien. Alle Unterpunkte
stehen stellvertretend für einen Problembereich in der Interaktion, der durch Widgets
gelöst werden kann. Diese Unterpunkte sind das Ergebnis der Analyse der betrachteten
Forschungsergebnisse.
Objektselektion
Pixelgenaue Selektion
Selektion bei Okklusion
Distanzselektion
Anwendungskontrolle
Menü-Navigation
Texteingabe
Spezielle Werteingaben
Kooperative Arbeit
User-Identifikation
Raum-Management
Tabelle 1: Widget-Klassen und ihre Unterkategorien
In der folgenden Klassifikation werde ich zunächst die jeweilige Hauptkategorie
hinsichtlich ihrer Relevanz erläutern. Danach nenne ich die zu dieser Kategorie
gehörenden Elemente, wobei diese analog zur Rolle der Widgets als „Problemlöser“
ausgearbeitet werden. Abschließend folgt eine Übersichtstabelle mit beispielhaften
Widgets, welche diesen Unterpunkten zuzuordnen sind.
30
3.5 Klassifikation
3.5.4 Objektselektion
Die Objektselektion gehört zu den am häufigsten ausgeführten Aktionen im Multi-TouchBereich und ist eine Ausgangssituation vieler weiterer Aktionen.
Die pixelgenaue Selektion stellt aufgrund der Tatsache, dass der zur Auswahl
eingesetzte Finger meist den Zielpunkt der Selektion verdeckt, ein Problemfeld der
Touch-Interaktion generell dar. Als Technik für pixelgenaue Selektion von Inhalten wird
beispielsweise die Shift-Technik (Vogel & Baudisch, 2007) eingesetzt. Sobald der
Benutzer eine Position auf dem Bildschirm für einen kurzen Zeitraum auswählt, erscheint
eine Lupe mit einem einstellbaren Versatz (Shift) zum Berührungspunkt, welche den
Bereich um den ausgewählten Punkt vergrößert darstellt. Als Hilfe bei der Orientierung
zeigt ein kleines Fadenkreuz die aktuell registrierte Position der Interaktion an. Somit
wird die gewohnte und erlernte Situation bei der Mausbedienung wiederhergestellt und
eine pixelgenaue Selektion ermöglicht.
Neben der Shift-Technik werden auch virtuelle Buttons als Unterstützung verwendet.
Albinsson und Zhai (2003) stellten eine Implementierung für virtuelle Buttons vor, bei
der sich bei Bedarf ein Fadenkreuz mit Pfeiltasten am äußeren Rand einblenden lässt
(Albinsson & Zhai, 2003). Dabei bewegt jede Betätigung eines Buttons das Zentrum des
Kreuzes um einen Pixel in die gewünschte Richtung.
Abbildung 8: Möglichkeit der pixelgenauen Auswahl über das Widget „Cross Keys“ (Albinsson & Zhai, 2003).
Die Kategorie der Okklusionsselektion umfasst neben der Verdeckung von
Bildschirmobjekten
Bildschirmoberfläche
durch
den
Anwender
befindlichen
auch
physischen
den
Umgang
Objekten,
wie
mit
auf
der
beispielsweise
Aktenordnern.
Während erstgenannte Okklusion durch die bereits genannte Shift-Technik behandelt
werden kann, beschreibt SnapRail (Furumi, Sakamoto & Igarashi, 2012) eine Lösung, die
31
Selektion bei Verdeckung von Items durch physische Objekte ermöglicht. Sobald ein
Objekt auf der Bildschirmoberfläche platziert wird, erscheint ein navigierbarer Kreis um
das Objekt, welcher die verdeckten Elemente enthält.
Widgets zur Distanzselektion gewinnen an Bedeutung, je größer die Ausmaße der
Tabletop-Systeme werden. Die eingesetzten Techniken reichen von einer einfachen
„Armverlängerung“ in Form eines versetzten Cursors zu Widgets, die ein gezieltes
Heranziehen des anvisierten Objekts wie ein Lasso ermöglichen.
32
3.5 Klassifikation
Klasse: Objektselektion
Kategorie
Pixelgenaue Selektion
Widget
Shift
Cross-Keys
Abbildung
Okklusionsselektion
SnapRail
Referenz
Albinsson & Zhai,
2003
Statische Haltung
Furumi et al., 2012
1 Finger
Der Nutzer zeichnet
einen Kreis um das
auszuwählende
Objekt. Ein Tippen
in den Kreis blendet
das Fadenkreuz und
die Steuerelemente
ein.
1 Finger
Sobald ein
Gegenstand (hier:
Tasse) auf Objekten
platziert wird,
ordnen diese sich auf
einem Ring um das
Objekt an.
Aktivierung
Vogel & Baudisch,
2007
Statische Haltung
Eingabeform 1 Finger
Info
Ein Verweilen des
Fingers auf einer
Position (a) öffnet
ein
Ausschnittsfenster
mit Zielmarkierung
mit einem gewissen
Versatz (b)
Automatisch
I-Grabber
Distanzselektion
HandyScope
Abednego, Lee, Moon &
Park, 2009
Dynamisch
2 Hände, 2 Finger
Nach zwei adjazenten
Taps (mit Entfernung von
maximal 20cm) wird ein
Greifarm aktiviert.
Während der Finger an
der Wurzel des Greifarms
durchgehend gehalten
wird, lässt sich der Arm
über den anderen Finger
steuern. Sobald ein Finger
angehoben wird,
selektiert der Greifarm
das darunterliegende
Objekt.
Kuribara, Yoshikawa,
Shizuki & Tanaka, 2014
Statische Haltung +
Geste
2 Hände, 3 Finger
Die linke Hand aktiviert
über eine statische
Haltung mit Daumen und
Zeigefinger das Widget
(a). Über einen Finger
der anderen Hand lässt
sich nun eine Art
Fernglas einblenden,
welches entfernte
Bildschirmregionen
anzeigt (b).
33
3.5.5 Anwendungskontrolle
Die Klasse der Anwendungskontrolle beschreibt alle Vorgänge zur Interaktion mit einer
Anwendungssoftware und der Dateneingabe innerhalb dieser Anwendung.
Ein zentraler Bestandteil ist dabei die Menü-Navigation. Dies ist eine besondere
Herausforderung bei Tabletop-Systemen, da der Aktionsradius des Benutzers – den er
ermüdungsfrei bedienen kann – nicht den kompletten Bildschirmbereich abdeckt.
Widgets zur Distanzselektion könnten hier zwar verwendet werden, lösen aber oftmals
nicht das Problem der Lesbarkeit entfernter Menüpunkte. Shneiderman entwickelte
mehrere Menü-Techniken, die speziell auf einen geringen Platzbedarf ausgelegt sind und
sich so für eine Umsetzung als Widget, welches im unmittelbaren Interaktionsradius des
Nutzers angezeigt werden kann, eignen (Shneiderman & Plaisant, 2010, S. 244–287).
Die Nutzung von bloßen Fingern zur Texteingabe gilt als unzulänglich (Ryall, Forlines,
Chia Shen, Morris & Everitt, 2006, S. 93). Auf der anderen Seite werden aber auch die
Vorteile von dynamisch darstellbaren On-Screen-Tastaturen genannt. So könne die
Anzahl von Fehleingaben verringert werden, indem nur die aktuell gültige Menge der
Eingabesymbole angezeigt wird (beispielsweise bei E-Mail-Adressen). Auch die
Benutzerfreundlichkeit kann durch skalierbare und anpassbare Tastatur-Widgets
gesteigert werden. Grundsätzlich werden Tastatur-Widgets der Kategorien „Soft
Keyboards“, die Eingaben über gewohntes Tippen ermöglichen, und „Gesture-based
Keyboads“, die Wörter über durchgehende Wischbewegungen erkennen, unterschieden
(Hinrichs, Schmidt, Isenberg, Hancock & Carpendale, 2008).
Spezielle Werteingaben, die über alphanumerische Eingaben hinausgehen, sind eine
Kategorie, in welcher Widgets ihre Stärken gegenüber der Maus- und Tastaturbedienung
ausspielen können. Anstelle der Farbauswahl über einen Mausklick auf eine Farbfläche
können hier beispielsweise natürlichere Selektionen über den Einsatz der Finger
verwendet werden.
34
3.5 Klassifikation
Klasse: Anwendungskontrolle
Kategorie
Menü-Navigation
Widget
Swiss Army Menu
Texteingabe
Hierarchical Square
Menu
BubbleQwerty
Cirrin
Ahlström, Cockburn,
Gutwin & Irani, 2010
Automatisch
1 Hand, 1 Finger
Die Aktivierung erfolgt
bei Auswahl eines
Hauptmenüpunktes. Jede
Hierarchieebene ist
versetzt zur darüber
liegenden Ebene
angeordnet, sodass auch
eine AufwärtsNavigation möglich ist.
Hinrichs et al., 2008
Mankoff & Abowd,
1998
Automatisch
1 Hand, 1 Finger
Der Benutzer
schreibt ein Wort,
indem er die
entsprechenden
Buchstaben über
eine
Wischbewegung
abfährt.
Anhand einer
Heuristik werden
passende Eingaben
erkannt.
Spezielle
Werteingaben
Music Mixing Surface
Abbildung
Referenz
Bonnet & Appert,
2011
Aktivierung Statische Haltung
Eingabeform 1 Hand, 1 Finger
Info
Die Aktivierung des
Menüs ist über
einen doppelten
Tap oder eine Geste
möglich. Zentrale
Elemente sind der
Puck (rot) und das
umgebende
Gummiband. Ein
Menüitem wird
durch verschieben
des Pucks selektiert.
Automatisch
1 Hand, 1 Finger
Die Tastatur vergrößert
nach Eingabe des ersten
Buchstaben die statistisch
wahrscheinlichsten
Nachfolgebuchstaben.
Durch die Transparenz ist
es trotzdem möglich,
Buchstaben nahe der
vergrößerten Elemente
auszuwählen.
Gelineck, Andersen &
Büchert, 2013
Dynamisch
1 Hand, 1 Finger
Jede Tonspur verfügt
über ein
InstrumentenWidgets. Darüber
lassen sich
zugehörige
Eigenschaften durch
Wischbewegungen
verstärken oder
verringern.
35
3.5.6 Kooperative Arbeit
Einer der Haupteinsatzzwecke für Tabletop-Systeme besteht in der Arbeit mehrerer
Personen hinsichtlich einer gemeinsamen Aufgabenstellung. Lösungen in Form von
Widgets für diese kooperative Arbeit reichen von Techniken, die eine geschickte
Zusammenstellung von Informationen ermöglichen, zu kompletten Systemumgebungen,
die auf mehrere Ebenen der Gruppenarbeit ausgelegt sind.
Wichtig für den Erfolg dieser Lösungen ist eine flüssige und zielführende Bedienung.
Deshalb konzentrieren sich viele Widgets auf die grundsätzlichen Anforderungen, wie der
Unterscheidbarkeit von Touch-Eingaben durch mehrere Akteure oder der sinnvollen
Aufteilung der Bildschirmfläche.
Lösungen zur Unterstützung der Unterscheidbarkeit der beteiligten Personen reichen
von einer simplen farblichen Hervorhebung von Pointern bis hin zu Widgets mit einer
vollständigen Rechteverwaltung. Während eine farbliche Unterscheidung bei den
Benutzern primär ein Bewusstsein über die Aktivitäten ihres Teams erzeugt, ermöglicht
eine Rechteverwaltung im Groupware-Szenario beispielsweise eine Aufteilung in eine
Personengruppe, die Informationsitems suchen und einreichen darf, und Moderatoren,
die diese Items dann in ein Ergebnisdokument einfügen können.
Mithilfe von Widgets zum Raum-Management wird versucht, eine mögliche Unordnung,
erzeugt durch eine Vielzahl von Elementen auf der Bildschirmfläche, zu verhindern. Eine
statische Lösung teilt den Bildschirm in feste private Gebiete und eine gemeinsam
nutzbare Fläche auf. Die privaten Bereiche unterstützen einzelne Gruppenmitglieder
dabei, alternative Lösungen zu erarbeiten oder Nebenaufgaben zu lösen. Durch eine klare
Kennzeichnung der Bereiche spiegeln die darin liegenden Items einen Eigentums-Status
wieder, wodurch Zugriffs-Konflikte vermieden werden. Daneben existieren dynamische
Techniken, die eine temporäre Bindung oder Weitergabe von Widgets an Benutzer
anbieten. So wird eine effiziente Ausnutzung des Bildschirms gewährleistet, da nicht jeder
Teilnehmer ein eigenes vollständiges Widget-Toolset benötigt.
36
3.5 Klassifikation
Klasse: Kollaborative Arbeit
Kategorie
Widget
MAUI Toolkit
Abbildung
User-Identifikation
iDwidgets
Raum-Management
Table-for-N (aus iDwidgets)
TeamTag
Referenz
Hill & Gutwin, 2003
Ryall et al., 2005
Ryall et al., 2005
Aktivierung
Eingabeform
Beschreibung
Automatisch
1 Hand, 1 Finger
Jeder Benutzer bekommt
eine Farbe zugewiesen,
sodass seine Aktionen
eindeutig zugeordnet
werden können.
Automatisch
1 Hand, 1 Finger
Jeder Benutzer bekommt
eine Farbe zugewiesen. Die
Leiste unterhalb eines jeden
Items zeigt an, welche
Benutzer Rechte zur
Bearbeitung des Items
haben.
Automatisch
1 Hand, 1 Finger
Anhand der Nutzerzahl (hier: 2)
wird der Bildschirm in mehrere
private (grün und pink), sowie
einen öffentlichen Bereich (grau)
aufgeteilt.
Morris, Paepcke,
Winograd &
Stamberger, 2006
Automatisch
1 Hand, 1 Finger
Die Bedienelemente
sind zentralisiert
angeordnet und lassen
sich Benutzern
zuweisen, um Platz zu
sparen
37
3.6 Leitfaden für den Widget-Entwurf
Nachdem nun in diesem Kapitel näher auf die Charakteristiken von Widgets für MultiTouch-Systeme eingegangen wurde und eine Klassifizierung von Widgets beschrieben
wurde, folgt nun eine Orientierungshilfe, die den Entwicklungsprozess bei der Erstellung
eines neuen Widgets beschreibt.
Für den Erfolg eines Widgets lassen sich offenkundig keine einzelnen Schlüsselfaktoren
erkennen. Vielmehr muss das Endprodukt als Einheit von den späteren Anwendern als
nützlich, intuitiv und vor allem flüssig zu bedienen eingeschätzt werden.
Um dies zu erreichen, lassen sich drei Abschnitte definieren. Diese finden sich in ähnlicher
Art auch in einem Microsoft-Leitfaden über die Entwicklungen von Multi-TouchApplikationen
für
den
interaktiven
Surface-Tisch.
Dabei
beginnt
der
Entwicklungsvorgang mit Grundgedanken („Key Considerations“) über das intendierte
Ziel und die Zielgruppe des Widgets. In einem zweiten Schritt erfolgt dann die
Ausgestaltung der Visuellen Darstellung („Design Principles“). Abschließend kann der
Entwurf dann anhand der Zielvorstellungen implementiert werden (Microsoft
Corporation, 2011).
In den folgenden Abschnitten werde ich auf den genauen Ablauf und die Überlegungen
innerhalb dieser drei Abschnitte näher eingehen.
3.6.1 Grundgedanken
Der Charakter eines Widgets als Problemlöser wurde bereits in diesem Kapitel
thematisiert. Auch die Grundüberlegungen beim Entwurf eines neuen Widgets sollten
sich deshalb um das zu erreichende Ziel der Interaktion drehen. Außerdem spielt es eine
wichtige Rolle, in welcher Umgebung das Widget eingesetzt werden soll. Die
Designentscheidungen sind also stets anhand der Fragestellungen „Welches Problem soll
das Widget lösen?“ und „In welchem Umfeld, bezüglich der Hardware und des
Benutzerkreises, wird das Widget verwendet?“ auszurichten.
Eine generelle Entscheidung ist, ob die zu entwickelnde Lösung ein single- oder multipurpose Widget darstellen soll. Beispielsweise können Funktionalitäten aus verwandten
Problembereichen in das Endprodukt aufgenommen werden. Ein Vorteil der multipurpose Widgets ist, dass durch den größeren abgedeckten Problembereich eine größere
38
Relevanz des Widgets erzielt wird. Außerdem reduziert sich im Idealfall die Anzahl der
gleichzeitig anwendbaren Techniken auf dem Zielsystem, weil Widgets mit geringerem
Funktionsumfang ersetzt werden können. Die gestiegene Komplexität kann allerdings
auch Nachteile mit sich bringen. Für Anwendungsszenarien, die den gestiegenen
Funktionsumfang nicht benötigen, ist die Bedienung komplexer, als eigentlich nötig.
Ferner ist es sinnvoll, sich einen Überblick über vorhandene Lösungen aus dem
angestrebten Problembereich zu verschaffen. Hierfür kann auch die in Abschnitt 3.5
gefundene Kategorisierung hilfreich sein. Je nach Dichte der bereits vorhandenen Werke
ist es möglich auf diesen Ideen aufzubauen. Dies führt zu einer größeren Einheitlichkeit
und unterstützt die Entstehung von Konventionen für die Gestaltung von Widgets. In der
aktuell vorherrschenden Situation gibt es zwar eine gewisse Konsistenz innerhalb
einzelner Forschungsgruppen, allerdings sind die Interaktionsmuster von Widgets
zwischen diesen Gruppen oftmals nicht einheitlich. Auf der einen Seite verstärkt dies
natürlich die Innovation, für den Anwender dagegen wird es erschwert sich einen
Überblick über die eigenen Möglichkeiten zu verschaffen, da sich die Widgets
unterschiedlich verhalten.
Abschließend ist anzumerken, dass nicht zwingend alle Zielvorstellungen erreicht
werden können. Beispielsweise kann ein Widget, welches auf die Benutzung in
Einzelarbeit ausgelegt ist, nicht gleichermaßen in einer kooperativen Umgebung
eingesetzt werden. Dies wird auch als Zielkonflikt zwischen dem individuellen und dem
Gruppennutzen beschrieben (Nacenta, Pinelle, Gutwin & Mandryk, 2010, S. 305).
3.6.2 Widget-Design
Sobald die grundsätzlichen Überlegungen für die Ausrichtung des Widgets abgeschlossen
wurden, kann mit der Planung des Widget-Designs begonnen werden. Dazu gehören
neben Überlegungen zum Aussehen der Steuerelemente auch die Art und Weise der
Aktivierung des Widgets und das Motion Design – also die Ausgestaltung der Interaktion
des Anwenders mit dem Widget.
Prinzipiell
können
die
traditionellen
Gestaltungsgrundlagen
für
die
„Benutzungsschnittstellen von interaktiven Systemen“ (ISO 9241-110:2006) aufgegriffen
werden. Hierzu zählen die Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit,
Lernförderlichkeit, Steuerbarkeit, Erwartungskonformität, Individualisierbarkeit und
39
Fehlertoleranz. Nachfolgend werden die genauen Auswirkungen dieser Anforderungen
auf die drei Design-Prozesse erläutert.
Visuelle Gestaltung. Das Design der Steuerelemente eines Widgets ist deshalb wichtig,
weil das Widget innerhalb einer spezifischen Anwendungsaufgabe ausgeführt
wird. Es darf sich also für den Benutzer im Kontext dieses Workflows nicht fremd,
sondern flüssig in Bezug auf die Aufgabenerledigung, anfühlen. Diese flüssige
Bedienung wird auch als konsistentes und angenehmes Erlebnis beschrieben
(Microsoft Corporation, 2011, S. 6). Der Gesamteindruck kann dabei durch die
Einhaltung einzelner Regeln erzielt werden. Zu diesen Regeln gehören ein
einfaches und klares Design der Interaktionselemente, ein hierarchischer und
strukturierter Aufbau und eine aufgabenzentrierte Darstellung, die zum
Erforschen einlädt.
Aktivierung. Widgets werden auf interaktiven Tabletop-Systemen meist in einer
Umgebung zusammen mit einigen weiteren Anwendungen mit Multi-TouchBedienung ausgeführt. Deshalb ist es wichtig, einen Überblick über das geplante
Zielsystem zu bekommen. Auf diese Weise können mögliche Interferenzen mit
bereits vorhandenen Interaktionsformen vermieden werden. Denn Widgets
befinden sich einen Großteil der Zeit im inaktiven Zustand – sie sind also für den
Anwender nicht sichtbar und warten auf eine Aktivierung in Form einer statischen
Handhaltung oder Geste. Es kann nun der Effekt auftreten, dass zwei Widgets auf
die gleiche Geste reagieren und somit der Anwender verwirrt wird.
Außerdem muss eine geeignete Balance zwischen den Parametern Einfachheit und
Eindeutigkeit gefunden werden. Je einfacher ein Widget aktiviert werden kann,
desto größer ist die Gefahr, überschneidende Aktionen innerhalb der
Systemumgebung zu erzeugen. Auf der anderen Seite erzeugt eine komplexere
Aktivierungsaktion unnötige Barrieren und einen erhöhten Lernaufwand auf der
Seite der Benutzer.
Motion Design. Unter dem Punkt Motion Design ist die gesamte Interaktion mit dem
aktiven Widget, vor allem aber die für die Bedienung auszuführenden Gesten
zusammengefasst. Da die Akzeptanz eines Widgets stark mit dem Nutzerbedürfnis
nach einer flüssigen und natürlichen Multi-Touch-Bedienung verbunden ist, sollte
40
auf das Design der Interaktionsmuster einer Anwendung – auch „gesture set“
genannt - besonders geachtet werden (Benko et al., 2009).
Kin
(2012)
untersuchte
Interaktionsmuster
in
allgemeiner
seiner
Arbeit
Studien
sowohl
Multi-Touch-Applikationen,
als
über
die
auch
die
Bedienung von interaktiven Tabletop-Systemen und erarbeitete daraus einige
Designrichtlinien (Kin, 2012, S. 22-23 und 61-63). So wird empfohlen, das
Nutzungsverhalten des Widgets zu analysieren und für die am häufigsten
benötigten Operationen die einfachsten Gesten zu verwenden. Die Bewegung
während der Geste solle darüber hinaus eine Verbindung zum Effekt der Handlung
haben, sodass die Anwender sich bereits über das Interaktionsziel an die Geste
erinnern können. Die Verwendung von bis zu zwei Fingern je Hand verbessere die
Effizienz, wobei die Unterstützung von Gesten mit mehr als zwei Fingern je Hand
keinen weiteren Vorteil biete. Interaktionen mit mehreren Fingern einer Hand
sollten außerdem primär dazu eingesetzt werden, um mehrere Funktionen
unterscheiden zu können, als zur Auswahl mehrerer unabhängiger Ziele.
Abschließend wird eine Einschränkung auf höchstens eine Operation zu jedem
Zeitpunkt empfohlen, da der Mensch stets auf eine bestimmte Position fokussiert
ist (Raskin, 2000). Dies verringert zudem die Komplexität für die anschließende
Implementierung.
3.6.3 Implementierung
In einem letzten Schritt erfolgt die Umsetzung des Entwurfs über die Implementierung
des Widgets. Eine Schwierigkeit besteht darin, dass im Vergleich zu klassischen DesktopAnwendungen nicht nur eine Maus als Pointing-Device verarbeitet werden muss, sondern
auf umfassendere Touch-Events reagiert werden muss. Diese können nicht nur durch
Finger, sondern auch die Unterarme der Anwender, sowie physische Gegenstände auf der
Bildschirmoberfläche ausgelöst werden.
Für die Implementierung gibt es mehrere Entwicklungs-Frameworks, die speziell auf die
Anforderungen von Multi-Touch-Systemen ausgerichtet sind. Ein Beispiel dafür ist das
Microsoft Surface SDK, welches ich im folgenden Kapitel für die Entwicklung eines
eigenen Widgets näher beschreiben werde.
41
42
4 Umsetzung eines eigenen Widgets
Im vergangenen Kapitel wurde detailliert auf die Einsatzbereiche von Widgets
eingegangen und es wurden beispielhafte Lösungen im Rahmen der Klassifizierung näher
beschrieben. Nun soll ein neues prototypisches Widget für eine bisher unzureichend
bearbeitete Problemstellung entworfen und entwickelt werden.
Dazu werde ich im Folgenden zuerst die Grundgedanken für die neue Technik aufzeigen.
Danach werden die einzelnen Bestandteile des Widgets, wie das Design und die
Interaktionstechniken erläutert. Zudem wird die Phase der Implementierung
dokumentiert. Abschließend folgt eine Auswertung darüber, inwieweit das entwickelte
Widget die eingangs beschriebene Problemstellung löst.
4.1 Grundlagen
4.1.1 Idee „TidyUp“-Widget
Die große Displayfläche eines Multi-Touch-Tisches verleitet dazu, vorübergehend nicht
benötigte Elemente aus dem eigentlichen Aktionsbereich herauszuschieben und weit
entfernt vom Benutzer abzulegen, um diese Elemente bei einem möglichen späteren
Zugriff nicht erneut öffnen zu müssen. Dieses Vorgehen birgt die Gefahr, über die Zeit
immer mehr Elemente auf der Bildschirmfläche anzusammeln, sodass die Arbeitsfläche
zunehmend
unübersichtlich
wird.
Außerdem
lässt
es
sich
bei
manchen
Aufgabenstellungen, wie dem Zusammentragen von Informationen, schlicht nicht
vermeiden eine große Anzahl an Elementen gleichzeitig geöffnet zu haben.
Diese Problemstellung greift Elemente der Kategorien Okklusion und Distanzselektion
auf. Widgets, welche für diese beiden Bereiche entwickelt wurden, bieten allerdings keine
befriedigende Lösung dieser Aufgabe. Sie gehen meist entweder auf ein einzelnes Element
ein oder behandeln Aktionen in einem eingeschränkten Bereich des Bildschirms.
Aus diesem Grund soll ein „TidyUp“-Widget entworfen werden, welches die Ordnung des
Bildschirminhalts wiederherstellt. Dazu sollen sich alle auf dem Bildschirm sichtbaren
Elemente schrittweise an eine festgelegte Position bewegen lassen. Darüber hinaus soll
es möglich sein, die Elemente optional für eine übersichtliche Darstellung in eine Art
Container zu verschieben.
43
4.1.2 Entwicklungsumgebung
Das Widget wird innerhalb einer Surface-Anwendung mit dem Microsoft Surface SDK 2.0
umgesetzt. Als Entwicklungsumgebung für die Implementierung kommt das Microsoft
Visual Studio 2010 zum Einsatz.
Das Surface SDK 2.0 schränkt zwar den Spielraum bei der Gestaltung der
Benutzerschnittstelle ein, bietet aber auch Vorteile durch die bereits vorhandene
Codebasis. So enthält die Windows Presentation Foundation (WPF), welche für die
Ausgestaltung der GUI-Elemente verwendet wird, bereits an die Touch-Interaktion
angepasste „Surface Controls“. Diese Steuerelemente besitzen grundlegende MultiTouch-Funktionalitäten, wodurch in der Entwicklung früher Ergebnisse sichtbar sind.
Die Entwicklung der Programmlogik, welche das Funktionsspektrum des Widgets
umfasst, wird in der Programmiersprache C# realisiert.
4.2 Gestaltung
4.2.1 Visuelle Gestaltung
Für die grafische Darstellung des Widgets werden im Wesentlichen zwei Bestandteile
benötigt. Der erste Teil ist ein Zielbereich, in welchen die geöffneten Elemente bewegt
werden. Der Zielbereich wird durch einen hellblau gerahmten Kreis gekennzeichnet.
Abbildung 9: Item innerhalb des Zielbereichs
44
4.2 Gestaltung
Elemente, welche sich mit ihrem Zentrum innerhalb des Zielbereichs befinden, werden
bei Ausführung einer Aufräum-Geste auf eine übersichtliche Art und Weise dargestellt.
Hierfür wird die zweite grafische Komponente benötigt. Die Elemente aus dem
Zielbereich sollen zur aufgeräumten Darstellung in einem Container abgelegt werden
können.
Bei der Gestaltung dieses Containers konnte auf Standard-Steuerelemente des Surface
SDK zurückgegriffen werden. Die Wahl fiel hier auf die LibraryContainer-Klasse. Sie
nimmt eine generische Collection an Items auf und kann diese Elemente dann in zwei
umschaltbaren Ansichten darstellen – zum einen als Stapel (StackView) und zum anderen
als Leiste mit nebeneinander angeordneten Elementen (BarView).
Abbildung 10: Zwei Items in StackView-Ansicht (links) und fünf Items in
BarView-Ansicht (rechts)
Das Oberflächendesign beschränkt sich dabei, wie in den Design-Richtlinien gefordert, auf
die Darstellung der wesentlichen Informationen und liefert ein konsistentes und
einheitliches Erscheinungsbild.
4.2.2 Aktivierung des Widgets
Ziel des Widgets ist es, in jedem Anwendungskontext eine Hilfestellung zu bieten. Eine
Aktivierung soll also zu jeder Zeit möglich sein, sobald der Benutzer Elemente auf der
Bildschirmfläche anordnet. Aus diesem Grund darf die Aktivierungsaktion nicht zu
Konflikten mit gängigen Gesten oder Handhaltungen anderer Anwendungen führen.
Daher habe ich mich dazu Entschlossen, eine Handhaltung mit fünf Fingern der linken
Hand als Aktivierungshandlung zu verwenden (siehe Abbildung 11). Die Funktionalität
des eigentlichen Widgets soll dann mit einem Finger der rechten Hand bewältigt werden.
45
Diese Rollenzuweisung der Hände im Rahmen der beidhändigen Interaktion wird bereits
von Guiard vorgeschlagen. Während die nicht-dominante Hand den Rahmen der
Handlung vorgibt, soll die dominante Hand die primäre Aktion ausführen (Guiard, 1987).
Abbildung 11: Fünf-Finger-Handhaltung zur Aktivierung des Widgets
Durch die Aktivierung über die Einbeziehung aller fünf Finger der linken Hand entsteht
zugleich ein Platz unterhalb der Handfläche, der später für die organisierte Ablage der
Elemente verwendet werden kann. Mit dem Anheben der linken Hand wird das Widget
unmittelbar deaktiviert und unbeabsichtigte Eingaben werden verhindert.
4.2.3 Motion Design
Bei der Ausführung einer bestimmten Geste sollen nun alle Elemente in mehreren
Schritten langsam an den Interaktionspunkt der Geste herangeführt werden. Hierfür
wurde eine Kreisgeste, die wahlweise im Uhrzeigersinn oder gegen den Uhrzeigersinn
ausgeführt werden kann, ausgewählt. Diese Drehbewegung soll eine Analogie zur realen
Welt, beispielsweise beim Einholen einer Angelschnur oder der Sogwirkung eines
Wirbelsturms, wiederspiegeln. Denn die Akzeptanz einer Geste korreliert stark mit den
mentalen Modellen auf Seiten der Benutzer und nicht unbedingt mit der Komplexität der
Aktion oder der Anzahl der verwendeten Finger (Wobbrock et al., 2009). Daher sind
Assoziationen zur realen Welt oder Metaphern ein geeignetes Mittel, um den Lernvorgang
einer neuen Interaktionstechnik zu verbessern.
46
4.2 Gestaltung
Abbildung 12: Drehbewegung im oder gegen den Uhrzeigersinn zum
Heranziehen der Bildschirmelemente
Zum Abschluss der Geste sollte es möglich sein, die nun herangezogenen Elemente in
einen Container zu verschieben. An dieser Stelle wird die nicht dominante Hand, welche
seit der Aktivierung des Widgets auf dem Touch-Display ruht, in die Aktion einbezogen.
Über den Zeigefinger der rechten Hand muss dazu eine Wischbewegung vom Stapel der
Elemente beginnend in die Handfläche der linken Hand hinein ausgeführt werden.
Abbildung 13: Abschlussgeste zur Erstellung eines Containers mit den
herangezogenen Elementen als Inhalt
Diese Technik wurde von der Forschungsgruppe um Yoshikawa, Shizuki und Tanaka
eingeführt und als Abschlussgeste in den Widgets HandyWidgets (2012) und HandyScope
(2014) bereits erprobt.
47
4.3 Architektur der Anwendung
4.3.1 Übersicht
Das nachfolgende Klassendiagramm des „TidyUp“-Widgets bietet einen Einblick in die
Architektur der Anwendung. Grün markierte Klassen wurden direkt aus dem Surface SDK
2.0 entnommen. Blau hinterlegte Klassen wurden eigenständig implementiert. Zur
besseren Übersicht wurden Klassen und Attribute, die keinen direkten Bezug zur
Problemstellung haben, ausgelassen. So kann detaillierter auf das Zusammenwirken der
einzelnen Klassen eingegangen werden.
48
<<Enum>>
TimedPoint
SurfaceWindow
MyGestureSet
- touchID: int
- p: Point
- time: double
+ NONE
+ CIRCLE
+ FLICK_LEFT
+ TimedPoint(id: int, p: Point, time: double)
+ GetID(): int
+ GetPoint(): Point
+ GetTime(): double
MainSurfaceWindow
0..*
- isPosture: bool
- isGestureReady: bool
- AddItem(): void
- ClearItems(): void
- ShowPostureTooltip(): void
posturePositions
0..5
holdPositions
0..*
MyPostureRecognizer
- isPosture: bool
- DesiredFingers : int = 5
0..1
0..1
imagePool
postureRecognizer
MyImagePool
- images: List<string>
+ GetImagePath(): string
+ GetPoolSize(): int
+ RemoveImagePath(imagePath: string): void
MyGestureRecognizer
ScatterViewItem
targetArea
+ Content: object
+ TouchUp(sender: object, e:
TouchEventArgs): void
0..*
0..1
0..1
gestureRecognizer
0..1
ScatterView
0..1
MyGestureHandler
gestureHandler
+ TouchDown(sender: object, e:
+ TouchMove(sender: object, e:
+ TouchUp(sender: object, e:
+ HoldGesture(sender: object, e:
+ OnManipulationStarted(sender: object,
args: RoutedEventArgs): void
+ OnCursorDrop(sender: object, args:
SurfaceDragDropEventArgs): void
- centerPosition: Point
- points: List<Point>
- referenceVector: Vector
- circleProgress: Circle
- lastAngle: double
- isClockwise: bool
+ MyGestureRecognizer(center: Point): void
+ SetCenter(center: Point): void
+ AddPoint(p: Point): void
+ GetPointCount(): int
+ CheckGesture(): MyGestureSet
+ Reset(): void
items
DragDropScatterView
+ AddHoldPosition(fingerID: int, p: Point) : void
+ RemoveHoldPosition(fingerID int): void
+ IsPosturePerformed(): bool
+ GetHoldCount(): int
+ IsInsideHand(testPoint: Point): bool
+ Reset(): bool
- CheckPosture(): bool
+ MyGestureHandler(scatterView,
libraryContainer, targetArea)
+ HandleGesture(gesture: MyGestureSet,
isPosture: bool, center: Point)
+ ItemsToPoint(p: Point): void
+ CreateLibraryContainer(itemsCenter: Point,
Point desiredPosition): void
0..1
scatterView
0..1
scatterView
libraryContainer
0..1
LibraryContainer
0..1
libraryContainer
+ ItemsSource: IEnumerable
+ Drop(sender: object, e:
SurfaceDragDropEventArgs): void
49
4.3.2 Beschreibung
Die Klasse MainSurfaceWindow ist die Hauptklasse, welche beim Start die weiteren
benötigten Komponenten initialisiert. Die Klasse selbst stellt mit dem Programmfenster
den Anwendungsrahmen zur Verfügung. Der Grundaufbau der Anwendung besteht aus
dem DragDropScatterView, welcher sich über das gesamte Programmfenster erstreckt.
Dies ist eine Fläche, welche ScatterViewItems mit beliebigem Inhalt aufnehmen und
darstellen kann. Die einzelnen ScatterViewItems besitzen auf diese Weise bereits
grundlegende Multi-Touch-Funktionalitäten und können beispielsweise verschoben,
gedreht oder vergrößert werden. Das „TidyUp“-Widget benötigt zwei zentrale Items, die
bereits im Abschnitt Gestaltung und Design erklärt wurden. Dies ist zum einen der Kreis
zum Anzeigen des Zielgebietes und zum anderen der LibraryContainer, welcher die
herangezogenen Elemente übersichtlich darstellen soll. Zusätzlich lassen sich durch den
Anwender weitere ScatterViewItems mit jeweils einem Bild als Inhalt hinzufügen. Diese
Elemente sollen die Dokumente und Objekte symbolisieren, die für die unübersichtliche
Arbeitsfläche verantwortlich sind.
Nachfolgend werde ich die einzelnen Klassen näher beschreiben und einige Methoden,
die für die Kernfunktionalität der Anwendung wichtig sind, erläutern.
4.3.3 MainSurfaceWindow
Die Hauptklasse dient als Schnittstelle zwischen den Benutzereingaben und der
Programmlogik. Events auf dem ScatterView oder dessen Items werden an die jeweiligen
Klassen zur Gestenerkennung oder Gestenbehandlung weitergegeben.
void AddItem(). Die Methode AddItem() fügt dem ScatterView ein neues
ScatterViewItem an einer zufälligen Position hinzu.
void ClearItems(). Über ClearItems() können alle hinzugefügten Elemente in einem
Schritt wieder entfernt werden.
4.3.4 MyImagePool
Die Klasse MyImagePool unterstützt das MainSurfaceWindow beim Hinzufügen neuer
ScatterViewItems mit einem Bild als Inhalt. Bei ihrer Initialisierung lädt sie alle
Bilddateien aus dem Ressourcen-Ordner der Anwendung und speichert sie in einer
Collection.
50
string GetImagePath(). Nun kann über die Funktion GetImagePath() der Pfad eines der
gespeicherten Bilder abgefragt werden. Die Klasse stellt dabei sicher, dass Bilder
nicht doppelt verwendet werden können.
int GetPoolSize(). Die Größe des verbleibenden Bilder-Pools kann über die Funktion
GetPoolSize() geprüft werden.
4.3.5 DragDropScatterView
Die Klasse DragDropScatterView erweitert die, im Surface SDK 2.0 integrierte, Klasse
ScatterView um Drag&Drop-Funktionalitäten. Diese werden benötigt, um Elemente nach
der vollständigen Ausführung der Geste aus dem LibraryContainer heraus wieder auf die
Bildschirmoberfläche ziehen zu können. Zudem verarbeitet die Klasse weitere TouchEreignisse und stellt damit eine zentrale Komponente der Benutzerschnittstelle dar.
OnCursorDrop. Das Ereignis OnCursorDrop wird ausgelöst, sobald ein Element aus einer
anderen Quelle auf dem ScatterView abgelegt wurde. In diesem Fall wird das
Element aus der ursprünglichen Quelle entfernt und als Inhalt eines neuen
ScatterViewItems neu hinzugefügt.
HoldGesture. Das Event HoldGesture ermöglicht die Erkennung der AktivierungsHandhaltung, da es ausgeführt wird sobald ein Benutzer seinen Finger für drei
Sekunden an einer Position auf dem ScatterView hält.
TouchDown, TouchMove und TouchUp. Die übrigen Ereignisse TouchDown,
TouchMove und TouchUp geben jeweils Aufschluss darüber an welchen Positionen
auf dem ScatterView Interaktionen stattfinden. Diese Positionen werden dann vom
MyGestureRecognizer entgegengenommen und verwendet, um die Ausführung
einer Geste zu erfassen. Jeder erkannte Finger bekommt dabei eine ID zugewiesen.
Werden also Bewegungen oder Haltungen durch einen Finger ausgeführt, kann
dieser in der Phase zwischen Berührung des Bildschirms und dem Anheben des
Fingers eindeutig identifiziert werden.
4.3.6 MyPostureRecognizer
Die Klasse MyPostureRecognizer nimmt Punkte entgegen, an denen Finger-Haltungen
erkannt wurden. Diese Positionen werden dann bezüglich ihrer Entfernung und zeitlichen
51
Abfolge dahingehend untersucht, ob eine entsprechende Fünf-Finger-Haltung zur
Aktivierung des Widgets ausgeführt wurde.
void AddHoldPosition(int fingerID, Point p). Über die Methode AddHoldPosition(int
fingerID, Point p) wird eine neue Halteposition innerhalb der Klasse registriert.
Dazu wird eine Liste mit Elementen des Typs TimedPoint verwaltet, die neben der
ID des Fingers und der Touch-Position auch den genauen Zeitpunkt der Berührung
erfasst.
void RemoveTouchPoint(int fingerID). Die Methode RemoveTouchPoint(int fingerID)
ermöglicht es einen bereits gesetzten TimedPoint wieder aus der Liste zu
entfernen, beispielsweise nach dem Anheben eines Fingers.
bool IsPosturePerformed(). Die Funktion IsPosturePerformed() gibt zurück, ob zum
aktuellen Zeitpunkt eine Fünf-Finger-Handhaltung ausgeführt wird. Dazu wird
nach jeder Änderung an der Punktmenge über die private CheckPosture()Funktion überprüft, ob die gegenwärtigen Haltungs-Positionen sowohl von der
Entfernung untereinander zu einer Handgröße passen, als auch in einem zeitlichen
Rahmen von maximal 5 Sekunden erfolgten.
bool IsInsideHand(Point testPoint). Diese Methode überprüft, ob der übergebene
Punkt innerhalb der Handfläche liegt. Dies wird benötigt, um das Ziel der WischGeste zu prüfen und um den LibraryContainer nach erfolgreicher Ausführung des
Widgets innerhalb der Handfläche anzeigen zu lassen.
4.3.7 MyGestureRecognizer
Die Klasse MyGestureRecognizer arbeitet ähnlich, wie die zuvor beschriebene Klasse
MyPostureRecognizer. Die Aufgabe der Klasse besteht darin, aus einer Menge an
Interaktionspunkten zu ermitteln, ob eine vordefinierte Geste ausgeführt wurde. Für das
„TidyUp“-Widget ist es lediglich nötig auf eine Kreisgeste in beliebiger Drehrichtung zu
reagieren. Dazu wird die Hilfsklasse Circle benötigt, welche den Fortschritt der Kreisgeste
speichert.
void SetCenter(Point center). Die Methode SetCenter(Point center) wird aufgerufen,
sobald ein Finger auf dem Touchscreen aufgesetzt wird. An dieser Stelle wird dann
das Zielgebiet für die heranzuholenden Elemente positioniert.
52
void AddPoint(Point p). Sobald der zuvor aufgesetzte Finger Bewegungen auf der
Touch-Oberfläche ausführt, werden die erreichten Positionen in regelmäßigen
Abständen
über
die
AddPoint(Point
p)-Methode
an
die
Klasse
MyGestureRecognizer übermittelt.
MyGestureSet CheckGesture(). Die CheckGesture()-Methode analysiert die aktuelle
Punktmenge dahingehend, ob die einzelnen Punkte einer der vordefinierten
Gesten entspricht. Falls eine entsprechende Geste erkannt wurde, wird ihr Wert
über die Enumeration MyGestureSet zurückgegeben.
4.3.8 MyGestureHandler
Die
Klasse
MyGestureHandler
erhält
über
die
zentrale
Verwaltungsklasse
MeinSurfaceWindow Zugriff auf die grafischen Elemente der Anwendung. Sie wird
verwendet, um die Neuausrichtung dieser Elemente nach einer erkannten Geste
vorzunehmen. Hierzu zählen beispielsweise das Einblenden des Zielgebiets an der
gewünschten Position, das Heranziehen der Dokumente und die Erstellung des
LibraryContainers.
void ItemsToPoint(Point p). Die private Methode ItemsToPoint(Point p) wird bei einer
erfolgreich abgeschlossenen Kreisgeste ausgeführt. Ziel ist es, die Elemente auf der
Bildschirmoberfläche schrittweise näher an den übergebenen Zielpunkt zu
bewegen. Dazu wird für jedes Element separat ein Zielpunkt abhängig zur
Entfernung zum Kreismittelpunkt festgelegt. Über eine Animation gelangen die
Elemente dann zu ihrem berechneten Zielpunkt. Falls sich ein Element bereits in
unmittelbarer Nähe des Ablagestapels befindet, wird es direkt auf diesen Stapel
bewegt.
void CreateLibraryContainer(Point itemsCenter, Point desiredPosition). Die
Methode CreateLibraryContainer behandelt den Abschluss des Widgets. Nach
erfolgter Wischbewegung in die Handfläche der linken Hand müssen die Elemente
auf dem Ablagestapel nun in einen Container verschoben werden. Um die
Elemente des Ablagestapels identifizieren zu können, wird der Parameter
itemsCenter übergeben. Alle Dokumente in unmittelbarer Entfernung zu dieser
Position werden als Quellelemente innerhalb des LibraryContainers registriert.
53
Anschließend wird dieser an der desiredPosition innerhalb der linken Handfläche
des Benutzers eingeblendet.
void HandleGesture(MyGestureSet gesture, bool isPosture, Point center). Die
Methode HandleGesture wird durch die Verwaltungsklasse aufgerufen und führt
die internen Methoden ItemsToPoint oder CreateLibraryContainer abhängig von
den übergebenen Parametern aus.
4.4 Beispielhafte Verwendung des Widgets
Nachdem
in
den
vergangenen
Abschnitten
sowohl
auf
das
Design
der
Benutzerschnittstelle, als auch auf die technische Architektur des „TidyUp“-Widgets
eingegangen wurde, wird nun ein beispielhafter Einsatz der Anwendung beschrieben.
Die Ausgangssituation zeigt die Oberfläche eines Multi-Touch-Tisches nach einer
gewissen Arbeitszeit mit vielen geöffneten und über den Bildschirm verteilten Elementen.
Diese werden zur Veranschaulichung durch Bildelemente dargestellt.
Abbildung 14: Ausgangssituation
Zur Aktivierung des „TidyUp“-Widgets muss nun zuerst eine Fünf-Finger-Handhaltung
mit der linken Hand ausgeführt werden. Diese Handhaltung wird während der gesamten
Ausführungszeit beibehalten. Nach einer Verweildauer von drei Sekunden bestätigt eine
Tooltip-Nachricht die korrekte Ausführung der Haltung und das Widget ist aktiviert.
54
4.4 Beispielhafte Verwendung des Widgets
Abbildung 15: Aktivierung des Widgets über die Haltung der linken Hand
Um nun die Bildschirmelemente schrittweise heranzuziehen, führt der Benutzer
fortlaufende Kreisgesten mit der rechten Hand aus. Die Anwendung reagiert dabei sowohl
auf Kreisbewegungen im Uhrzeigersinn, als auch gegen den Uhrzeigersinn. Die
ursprünglich gewählte Richtung muss allerdings während der Ausführung beibehalten
werden. Als Zielpunkt der herangezogenen Elemente wird der erste Berührungspunkt der
Kreisgeste gewählt. Alternativ kann der Zielbereich auch vor Ausführung der Kreisgesten
über eine einfache Berührung mit der rechten Hand explizit festgelegt werden.
Die Elemente nähern sich mit jeder weiteren Kreisgeste erkennbar dem eigeblendeten
Zielbereich an, welcher über einen Kreis mit hellblauem Rahmen dargestellt wird. Dies
kann fortgesetzt werden, bis sich die gewünschte Anzahl an Objekten innerhalb des
Zielgebiets befindet.
55
Abbildung 16: Ausführung von Kreisgesten der rechten Hand zum
Heranziehen der Elemente
Zum Abschluss der Geste hat der Benutzer nun zwei Optionen. Entweder er belässt die
Objekte auf dem Ablagestapel oder er entscheidet sich dazu, die Elemente in einem
Container übersichtlich abzulegen. Hierzu muss eine Wischgeste vom Stapel aus in die
linke Handfläche ausgeführt werden. Dies erzeugt den zuvor beschriebenen
LibraryContainer. Nun können die Finger angehoben werden und der Benutzer kann
seine ursprüngliche Arbeit fortsetzen.
Abbildung 17: Ergebnis nach dem Anheben der Hände.
56
4.5 Evaluierung des Widgets
Der LibraryContainer wird standardmäßig als StackView dargestellt. Für eine bessere
Übersicht über die enthaltenen Items lässt sich die Ansicht über den Button an der
Unterseite des Containers auf die BarView-Darstellung umschalten.
Abbildung 18: Darstellung der Container-Elemente als BarView.
4.5 Evaluierung des Widgets
Anhand des zuvor angeführten Anwendungsbeispiels ist ersichtlich, dass das „TidyUp“Widget die gewünschte Hilfestellung für den ursprünglich ermittelten Problembereich
bietet. Obwohl sich die Anwendung bei der prototypischen Umsetzung auf die
wesentlichen Funktionalitäten beschränkt, kann sich der Benutzer ein Bild von der
erzielten Veränderung nach der Reorganisation der Bildschirmelemente machen.
Anstelle von realen Dokumenten werden in der prototypischen Version des Widgets
einfache Bilddateien verwendet.
Die Erkennungs-Algorithmen für die Aktivierungshaltung und die Kreisgeste arbeiten
zuverlässig. Für die Gestenerkennung wurden verschiedene Lösungen erprobt. Die
besten Ergebnisse hinsichtlich der Performance und Erkennungsrate wurden über
regelmäßige Berechnungen des Winkels zwischen dem Startpunkt der Kreisgeste und
dem aktuellen Touch-Punkt erzielt. Falls die Anwendung zu einem späteren Zeitpunkt um
die Erkennung weiterer Gesten ergänzt werden sollte, ist der Einsatz einer
eigenständigen Erkennungs-Bibliothek sinnvoll. Das Projekt „$1 Unistroke Recognizer“
ermöglicht die Aufzeichnung von beliebigen Formen und ermittelt zur Laufzeit aus einer
57
übergebenen Punktmenge diejenige Geste, welche die Größte Ähnlichkeit zu den
aufgezeichneten Vorlagen aufweist (Wobbrock, Wilson & Li, 2007).
Eine naheliegende Erweiterung wäre, die ursprüngliche Position der Elemente zum
Zeitpunkt der unübersichtlichen Anordnung in den Zielcontainer zu übernehmen. Hierzu
könnte beispielsweise die Funktion des LibraryContainers genutzt werden, eigene
Untergruppen als GroupDescriptions zu erstellen. Auf diese Weise können eingelagerte
Elemente leichter wiedergefunden werden, beispielsweise wenn sich ein Element,
welches am linken Bildschirmrand abgelegt wurde, auch am linken Rand des erstellten
LibraryContainers wiederfindet.
58
5 Fazit
5.1 Zusammenfassung
Im Rahmen dieser Arbeit wurde in einem ersten Schritt eine Klassifizierung für Widgets,
mit dem Fokus auf Widgets für interaktive Tabletop-Systeme, erarbeitet.
In diesem Zusammenhang wurde gezeigt, dass die Anwendungsdomänen von Widgets
stark mit den entstandenen Problemfeldern der Interaktion mit interaktiven TabletopSystemen verknüpft sind. Diese Tatsache bestimmt maßgeblich ihren Charakter als
Problemlöser. Die anschließende Klassifizierung erfolgte anhand des Interaktionsziels,
welches der Anwender mithilfe des Widgets erreichen will. Als Hauptkategorien der
Klassifikation wurden die Objektselektion, die Anwendungskontrolle und die kooperative
Arbeit ermittelt. Die einzelnen Unterkategorien entsprechen dann den zuvor
beschriebenen Problemfeldern, wie beispielsweise Distanzselektion oder MenüNavigation.
Begleitend zur Klassifizierung wurde auf die Aktivierungsmöglichkeiten der Widgets
eingegangen. Diese lassen sich im Wesentlichen in zwei Kategorien einteilen – die
automatische,
anwendungsgesteuerte
Aktivierung
und
die
benutzergesteuerte
Aktivierung. In die Kategorie der manuellen Aktivierung fallen einfache Handhaltungen,
dynamische
Gesten
oder
auch
die
Verwendung
von
externen
physischen
Interaktionselementen in Form von Tangible User Interfaces.
Der erste Abschnitt dieser Arbeit wurde schließlich durch einen Leitfaden komplettiert,
in welchem auf die Herausforderungen bei der Entwicklung eines Widgets eingegangen
wird. Hier wurde besonders der Stellenwert einer flüssigen Interaktion und einem
reduzierten Design hervorgehoben, um eine breite Akzeptanz auf der Seite der Anwender
zu erreichen.
In einem zweiten Schritt erfolgte die Entwicklung des prototypischen „TidyUp“-Widgets.
Mit diesem Widget lassen sich Bildschirmoberflächen aufräumen, die durch viele
gleichzeitig geöffnete Elemente unübersichtlich geworden sind. Es wurde als SurfaceAnwendung umgesetzt und auf dem Multi-Touch-Tisch Mister T. der Universität
Paderborn getestet. Insgesamt leistet es die gewünschte Hilfestellung für die ermittelte
59
5 Fazit
Problemstellung und kann gegenwärtigen Lösungen, die auf die Positionierung einzelner
Elemente abzielen, vorgezogen werden.
5.2 Diskussion und Ausblick
Die Ergebnisse meiner Arbeit dienen einer grundlegenden Übersicht und Einordnung
bereits geleisteter Forschung. Da es bis dato keine Einteilungsvorgaben und auch keine
global gültigen Standards bei der Entwicklung von Widgets gibt, ist es schwer einen
Überblick über die große Zahl von Forschungsarbeiten zu erlangen. Sowohl für
Anwender, Forscher, als auch für Entwickler ist es interessant zu sehen, welche
Ergebnisse es bereits in der Forschung gibt. Anwender können auf diese Weise erfahren,
welche Hilfestellungen durch den Einsatz von Widgets bereits angeboten werden und
benutzt werden können. Forschungsteams bekommen einen Einblick in welchen
Bereichen und Anwendungsfeldern noch keine ausreichenden Problemlösungen
entworfen wurden.
Als Ansatz für zukünftige Arbeiten ist eine detailliertere Betrachtung und Ausweitung der
Problemfelder, die für Klassifizierung zugrunde gelegt wurden, sinnvoll. Diese Erhöhung
des Detailgrades würde ein noch größeres Spektrum der verfügbaren Widgets abdecken,
als es im Rahmen dieser Arbeit möglich war.
Außerdem erscheint eine grundlegende Standardisierung von Widgets, gerade im
Anbetracht der wachsenden Beliebtheit von Multi-Touch-Systemen, zweckmäßig. Dies
könnte hin zu einem zentralen Verzeichnis für Widget-Benutzungsschnittstellen führen.
In dieses könnten dann neu erscheinende Forschungsergebnisse mit Kategorien und
Eigenschaften eingetragen werden. Auf diese Weise ließen sich Hindernisse beim Entwurf
neuer Widgets, wie der Abgleich der nebeneinander existierenden Aktivierungs- und
Interaktionsgesten, verringern.
60
6 Literaturverzeichnis
Abednego, M., Lee, J.-H., Moon, W. & Park, J.-H. (2009). I-Grabber: Expanding Physical
Reach in a Large-Display Tabletop Environment Through the Use of a Virtual Grabber.
In G. Morrison, S. Subramanian, S. Carpendale, M. Haller & S. Scott (Hrsg.), the ACM
International Conference (S. 61–64).
Ahlström, D., Cockburn, A., Gutwin, C. & Irani, P. (2010). Why it’s Quick to be Square:
Modelling New and Existing Hierarchical Menu Designs. In E. Mynatt, D. Schoner, G.
Fitzpatrick, S. Hudson, K. Edwards & T. Rodden (Hrsg.), the 28th International
Conference (S. 1371–1380).
Albinsson, P.-A. & Zhai, S. (2003). High Precision Touch Screen Interaction. In G. Cockton
& P. Korhonen (Hrsg.), the Conference (S. 105–112).
Arfman, J. M. & Roden, P. (1992). Project Athena: Supporting distributed computing at
MIT. IBM Systems Journal, 31 (3), 550–563.
Bachl, S., Tomitsch, M., Wimmer, C. & Grechenig, T. (Hrsg.). (2010). Challenges for
Designing the User Experience of Multi-touch Interfaces.
Benko, H., Morris, M. R., Brush, A. B. & Wilson, A. D. (2009). Insights on Interactive
Tabletops: A Survey of Researchers and Developers. Microsoft Research.
Blank, C. (2013). Gesten im dreidimensionalen Raum. Hamburg: HAW Hamburg.
Bollhoefer, K. W., Meyer, K. & Witzsche, R. (2009, 04. Februar). Microsoft Surface und das
Natural User Interface (NUI). Berlin: Technical report, Pixelpark.
Bonnet, D. & Appert, C. (2011). SAM: The Swiss Army Menu. In M. Riveill (Hrsg.), 23rd
French Speaking Conference (S. 1).
Bott, E. (CBS Interactive, Hrsg.). (2012). Microsoft delivers OneNote MX, first Metro style
Office 2013 app. Verfügbar unter http://www.zdnet.com/microsoft-delivers-onenotemx-first-metro-style-office-2013-app-7000001050/
Buxton, B. (2007). Multi-Touch Systems that I Have Known and Loved. Microsoft
Research, 56, 1–11.
61
Buxton, B. (2010). Natural User Interfaces: Voice, Touch and Beyond. Zugriff am
01.10.2014. Verfügbar unter https://www.microsoft.com/enus/news/features/2010/jan10/01-06cesnui.aspx
Dachselt, R. (2004). Eine deklarative Komponentenarchitektur und Interaktionsbausteine
für dreidimensionale multimediale Anwendungen. Dissertation, Technische Universität
Dresden. Tönning.
Derboven, J., Roeck, D. de & Verstraete, M. (2012). Semiotic analysis of multi-touch
interface design: The MuTable case study. International Journal of Human-Computer
Studies, 70 (10), 714–728.
Derene, G. (Hearst Communication Inc., Hrsg.). (2007). Microsoft Surface: Behind-theScenes First Look. Verfügbar unter
http://www.popularmechanics.com/technology/gadgets/news/4217348
Dietz, P. & Leigh, D. (2001). DiamondTouch: A Multi-User Touch Technology. In J. Marks
& E. Mynatt (Hrsg.), the 14th Annual ACM Symposium (S. 219–226).
Furumi, G., Sakamoto, D. & Igarashi, T. (2012). SnapRail: A Tabletop User Interface
Widget for Addressing Occlusion by Physical Objects. In O. Shaer, C. Shen, M. R. Morris
& M. Horn (Hrsg.), the 2012 ACM International Conference (S. 193–196).
Gelineck, S., Andersen, J. & Büchert, M. (2013). Music Mixing Surface. In A. Quigley, G.
Jacucci, M. Horn & M. Nacenta (Hrsg.), the 2013 ACM International Conference (S. 433–
436).
Google Inc. (Google Inc., Hrsg.). (2012). Developer Docs: Widgets. Verfügbar unter
http://developer.android.com/design/patterns/widgets.html
Grossman, L. (Time Inc., Hrsg.). (2007). Invention Of the Year: The iPhone. Zugriff am
01.10.2014. Verfügbar unter
http://content.time.com/time/specials/2007/article/0,28804,1677329_1678542_16
77891,00.html
Guiard, Y. (1987). Asymmetric Division of Labor in Human Skilled Bimanual Action. The
Kinematic Chain as a Model. Journal of Motor Behavior, 19 (4), 486–517.
Hassenzahl, M., Beu, A. & Burmester, M. (2001). Engineering Joy. IEEE Software, 18 (1),
70–76.
62
Hill, J. & Gutwin, C. (2003). Awareness Support in a Groupware Widget Toolkit. In K.
Schmidt, M. Pendergast, M. Tremaine & C. Simone (Hrsg.), the 2003 International ACM
SIGGROUP Conference (S. 258–267).
Hinrichs, U., Schmidt, H., Isenberg, T., Hancock, M. & Carpendale, S. (2008). BubbleType:
Enabling Text Entry within a Walk-Up Tabletop Installation. Computer Science:
University of Calgary.
Hülsmann, A. (2011). Multitouch-enabled Widget Library and Programming Framework
for Tangible User Interaction Development on LLP-based Tabletop Surfaces.
Unveröffentlichte Masterarbeit, Universität Paderborn.
Janssen, J.-K. (Heise Zeitschriften Verlag, Hrsg.). (2009). Fass mich an! Microsofts
Multitouch-Tisch Surface startet in Deutschland, Heise Zeitschriften Verlag. Zugriff am
01.10.2014. Verfügbar unter http://heise.de/-291980
Johnson, E. A. (1965). Touch Display — A Novel Input/Output Device for Computers.
Electronics Letters, 1 (8), 219–220.
Kin, K. (2012). Investigating the Design and Development of Multitouch Applications.
Verfügbar unter http://www.escholarship.org/uc/item/0c0871cf
Koch, P.-P. (2009). Introduction to W3C Widgets - QuirksBlog. Zugriff am 01.10.2014.
Verfügbar unter
http://www.quirksmode.org/blog/archives/2009/04/introduction_to.html
Kuribara, T., Yoshikawa, T., Shizuki, B. & Tanaka, J. (2014). HandyScope: A Remote
Control Technique Using Circular Widget on Tabletops. In M. Jones, P. Palanque, A.
Schmidt & T. Grossman (Hrsg.), the Extended Abstracts of the 32nd Annual ACM
Malik, S. & Laszlo, J. (2004). Visual Touchpad: A Two-handed Gestural Input Device. In R.
Sharma, T. Darrell, M. Harper, G. Lazzari & M. Turk (Hrsg.), the 6th International
Mankoff, J. & Abowd, G. D. (1998). Cirrin: A Word-Level Unistroke Keyboard For Pen
Input. In E. Mynatt & R. J. K. Jacob (Hrsg.), the 11th Annual ACM Symposium (S. 213–
214).
Mehta, N. (1982). A flexible machine interface. MA Sc. Thesis.
63
Microsoft Corporation, Maki, J. (Mitarbeiter) (Microsoft Corporation, Hrsg.). (2011).
Microsoft® Surface® 2.0 Design and Interaction Guide. Principles & Guidelines for
Designing and Developing Surface Applications, Microsoft Corporation.
Morris, M. R., Paepcke, A., Winograd, T. & Stamberger, J. (2006). TeamTag: Exploring
Centralized versus Replicated Controls for Co-located Tabletop Groupware. In G.
Olson & R. Jeffries (Hrsg.), the SIGCHI Conference (S. 1273).
Morris, M. R., Ryall, K., Shen, C., Forlines, C. & Vernier, F. (2004). Beyond “Social
Protocols”: Multi-User Coordination Policies for Co-located Groupware. In J. Herbsleb
& G. Olson (Hrsg.), the 2004 ACM Conference (S. 262–265).
Müller-Tomfelde, C. (2010). Tabletops - Horizontal Interactive Displays (Humancomputer interaction series). London: Springer-Verlag London Limited.
Nacenta, M. A., Pinelle, D., Gutwin, C. & Mandryk, R. (2010). Individual and Group
Support in Tabletop Interaction Techniques. In C. Müller-Tomfelde (Hrsg.), Tabletops
- Horizontal Interactive Displays (Human-computer interaction series, S. 303–333).
London: Springer London.
Oxford Dictionaries. (2014). "widget". Oxford Dictionaries, Oxford University Press.
Zugriff am 01.10.2014. Verfügbar unter
http://www.oxforddictionaries.com/definition/english/widget
Raskin, J. (2000). The Humane Interface. New Directions for Designing Interactive
Systems. Reading, Mass.: Addison-Wesley.
Rettig, M. (1991). Nobody Reads Documentation. Communications of the ACM, 34 (7), 19–
24.
Ryall, K., Esenther, A., Everitt, K., Forlines, C., Morris, M. R., Shen, C. et al. (2005).
iDwidgets: Parameterizing Widgets by User Identity. In D. Hutchison, T. Kanade, J.
Kittler, J. M. Kleinberg, F. Mattern, J. C. Mitchell et al. (Hrsg.), Human-Computer
Interaction - INTERACT 2005 (Lecture Notes in Computer Science, Bd. 3585, S. 1124–
1128). Berlin, Heidelberg: Springer Berlin Heidelberg.
Ryall, K., Forlines, C., Chia Shen, Morris, M. R. & Everitt, K. (2006). Experiences with and
Observations of Direct-Touch Tabletops. In First IEEE International Workshop on
Horizontal Interactive Human-Computer Systems (TABLETOP '06) (S. 89–96).
64
S-Bahn Berlin GmbH (S-Bahn Berlin GmbH, Hrsg.). (2012). Web-Widgets.
Fahrplanauskunft und Fahrplanänderungen auf Ihrer Internetseite. Verfügbar unter
http://www.s-bahn-berlin.de/web-widgets
Shen, C., Ryall, K., Forlines, C., Esenther, A., Vernier, F. D., Everitt, K. et al. (2006).
Informing the Design of Direct-Touch Tabletops. IEEE Computer Graphics and
Applications, 26 (5), 36–46.
Shen, C., Vernier, F. D., Forlines, C. & Ringel, M. (2004). DiamondSpin: An Extensible
Toolkit for Around-the-Table Interaction. In E. Dykstra-Erickson & M. Tscheligi
(Hrsg.), the 2004 Conference (S. 167–174).
Shneiderman, B. & Plaisant, C. (2010). Designing the User Interface. Strategies for
Effective Human-Computer Interaction (5. ed., internat. ed). Upper Saddle River:
Addison-Wesley.
Spath, D., Weisbecker, A., Laufs, U., Block, M., Link, J., Ardilio, A. et al. (2009). Studie:
Multi-Touch. Technologie, Hard-/Software und deren Anwendungsszenarien
(Weisbecker, A., Hrsg.). : Fraunhofer IAO. Zugriff am 01.10.2014. Verfügbar unter
http://wiki.iao.fraunhofer.de/index.php/Studie:_Multi-Touch_-_Technologie,_Hard/Software_und_deren_Anwendungsszenarien
Swick, R. R. & Ackerman, M. S. (1988). The X Toolkit: More Bricks for Building UserInterfaces or Widgets for Hire. In Usenix Winter (S. 221–228). Citeseer.
Vogel, D. & Baudisch, P. (2007). Shift: A Technique for Operating Pen-Based Interfaces
Using Touch. In M. B. Rosson & D. Gilmore (Hrsg.), the SIGCHI Conference (S. 657–
666).
Wellner, P. (1991). The DigitalDesk calculator: tangible manipulation on a desk top
display. In Proceedings of the ACM Symposium on User Interface Software and
Technology (S. 27–33).
Wigdor, D. & Wixon, D. (2011). Brave NUI World. Designing Natural User Interfaces For
Touch and Gesture. Burlington, MA: Elsevier Inc.
Wixon, D. (Adaptive Path, Hrsg.). (2008). UX Week 2008 - The Challenge of Emotional
Innovation. Zugriff am 01.10.2014. Verfügbar unter http://vimeo.com/2893051
65
Wobbrock, J. O., Morris, M. R. & Wilson, A. D. (2009). User-Defined Gestures for Surface
Computing. In D. R. Olsen, R. B. Arthur, K. Hinckley, M. R. Morris, S. Hudson & S.
Greenberg (Hrsg.), the SIGCHI Conference (S. 1083–1092).
Wobbrock, J. O., Wilson, A. D. & Li, Y. (2007). Gestures without Libraries, Toolkits or
Training: A $1 Recognizer for User Interface Prototypes. In C. Shen, R. Jacob & R.
Balakrishnan (Hrsg.), the 20th Annual ACM Symposium (S. 159–168).
World Wide Web Consortium (Hrsg.). (2012). Packaged Web Apps (Widgets) - Packaging
and XML Configuration (Second Edition). W3C Recommendation 27 November 2012.
Zugriff am 01.10.2014. Verfügbar unter http://www.w3.org/TR/widgets/
Yoshikawa, T., Shizuki, B. & Tanaka, J. (2012). HandyWidgets: Local Widgets Pulled-out
from Hands. In O. Shaer, C. Shen, M. R. Morris & M. Horn (Hrsg.), the 2012 ACM
International Conference (S. 197–200).
Ziegler, J. (1996). Interactive Techniques. ACM Computing Surveys, 28 (1), 185–187.
66
7 Anhang
7.1 Inhalt der CD-ROM
Auf dem beigefügten Datenträger befinden sich folgende Dateien:
-
Digitale Form dieser Ausarbeitung
/Ausarbeitung/BA-fmense.pdf
-
Online verfügbare Quellen der Ausarbeitung
/Ausarbeitung/Quellen/
-
Vorausgesetzte Software
/Software/
-
Ausführbare Version des „TidyUp“-Widgets
/TidyUpWidget/
7.2 Systemvoraussetzungen für das Widget
Bedingt durch den Einsatz des Surface SDK 2.0 werden Endgeräte mit den folgenden
Systemumgebungen unterstützt:
Eine 32-bit oder 64-bit Edition eines der folgenden Windows® 7 Betriebssysteme:
-
Windows 7 Home Premium
Windows 7 Professional
Windows 7 Ultimate
Zusätzliche Anforderungen:
-
Microsoft Visual C#® 2010 Express Edition oder Microsoft Visual Studio® 2010
.NET Framework 4.0 (in Visual C# 2010 und Visual Studio 2010 enthalten)
Microsoft XNA® Framework Redistributable 4.0
7.3 Ausführung des Widgets auf Mister T.
1. Starten Sie die Anwendung Community Core Vision (CCV), welche TouchEingaben erkennt und als TUIO-Daten verarbeitet.
2. Starten sie den BSQSimulator und verbinden Sie ihn mit dem Port 3334. Somit
werden die TUIO-Daten in Windows-Touch-Events übersetzt.
3. Starten Sie die Widget-Anwendung, indem Sie die Datei
\TidyUpWidget\bin\Release\TidyUpWidget.exe auf der CD ausführen
67
7 Anhang
7.4 Ausführung des Widgets auf PCs ohne Touch-Interface
Anmerkung: Zur Ausführung der Anwendung auf einem Endgerät ohne Touch-Interface
wird der Microsoft Input Simulator aus dem Surface SDK 2.0 zur Simulation von TouchEingaben vorausgesetzt.
1. Stellen Sie sicher, dass die Software aus den Systemvoraussetzungen vollständig
installiert wurde.
2. Starten Sie den Microsoft Input Simulator. Und stellen Sie ihn auf Finger-Eingabe
ein.
3. Starten Sie die Widget-Anwendung, indem Sie die Datei
\TidyUpWidget\bin\Release\TidyUpWidget.exe auf der CD ausführen
68

Widgets für interaktive Displays

Transcrição

Documentos relacionados

Hazard Detection and Risk Assessment System

Widgets - Stud.IP

MetaWatch Smartwatch | Erste Schritte

Checkliste für Projektinitiatoren

Psychotest: Sind Sie ein Selbermacher

Druckbare Anleitungen Herunterladen

Ich will keine Schokolade (Trude Herr)

Skript zu Benutzungsoberflächen

Sport und Hand - sportklinik basel

¨Ubungsblatt 6 Aufgabe 1: Codebreaker (6 Punkte, B)

Wasserabweisende Offroad Pants in neuem, wasserabweisendem