2010 Diplom D. Wuttig

Transcription

Fakultät Informatik
Institut für Software- und Multimediatechnik
Lehrstuhl für Mediengestaltung
„Entwicklung einer Schnittstelle zur Integration
von Interaktionselementen in die Forschungsumgebung
Bildsprache LiveLab 2.0“
Diplomarbeit
zur Erlangung des akademischen Grades
Diplom - Medieninformatiker
Daniel Wuttig
Dresden, den 13.01.2010
Daten zur Diplomarbeit
Technische Universität Dresden
Fakultät Informatik
Institut für Software- und Multimediatechnik
Lehrstuhl für Mediengestaltung
Hochschullehrer:
Prof. Dr.-Ing. habil. Rainer Groh
Betreuer:
Dipl. - Medieninf. Dietrich Kammer
Diplomand:
Daniel Wuttig
Matrikelnummer:
2936191
Thema:
„Entwicklung
einer
Schnittstelle
zur
Integration
von
Interaktionselementen in die Forschungsumgebung Bildsprache
LiveLab 2.0“
Bearbeitungszeit:
15.04.2009 - 14.01.2010
III
Selbständigkeitserklärung
Hiermit erkläre ich, Daniel Wuttig, dass ich die vorliegende Diplomarbeit zum
Thema:
„Entwicklung einer Schnittstelle zur Integration von Interaktionselementen in die
Forschungsumgebung Bildsprache LiveLab 2.0“
selbständig verfasst habe. Es wurden keine anderen Quellen und Hilfsmittel als die
angegebenen benutzt.
Dresden, den 13.01.2010
_______________________
Daniel Wuttig
V
Danksagung
An dieser Stelle möchte ich mich bei all denjenigen bedanken, die mich bei der
Anfertigung dieser Diplomarbeit fachlich und persönlich unterstützt haben.
Ein besonderer Dank geht an Prof. Dr.-Ing. habil. Rainer Groh und Dipl.-Medieninf.
Dietrich Kammer für die engagierte und kompetente Betreuung meiner
Diplomarbeit und für viele kreative Ideen.
Ich bedanke mich bei meinen Eltern, die mir dieses Studium erst ermöglicht haben.
Ein besonderer Dank gilt Denise Winkler die eigene Interessen zugunsten meiner
Diplomarbeit zurückstellte.
VII
Inhaltsverzeichnis:
1 Einleitung ............................................................................................ 1 1.1 Zielstellung ................................................................................. 4 1.2 Gliederung ................................................................................. 4 2 Grundlagen ......................................................................................... 7 2.1 Computergrafik .......................................................................... 7 2.2 Software-Technologie ............................................................... 11 2.3 User-Interface-Design................................................................ 15 3 Interaktion und Gestaltungsmethoden............................................... 23 3.1 Interaktionsgestaltung .............................................................. 23 3.2 Navigation ................................................................................ 29 3.3 Manipulation ............................................................................ 35 3.4 Zusammenfassung .................................................................... 36 4 Synthese ........................................................................................... 37 4.1 Vergleich verschiedener Orientierungshilfen .............................. 37 4.2 Differenzierung der Menü-Varianten ......................................... 46 4.3 Analyse vorhandener 3D-Widgets ............................................. 49 5 Konzeption und Implementierung ..................................................... 53 5.1 Entwicklung des Interaktionskonzepts ....................................... 53 5.2 Konzeption der Navigationsunterstützung ................................. 62 5.3 Entwicklung der Service-Architektur .......................................... 68 6 Ergebnisse ......................................................................................... 73 7 Zusammenfassung ............................................................................ 79 7.1 Fazit ......................................................................................... 79 7.2 Ausblick .................................................................................... 80 A Glossar .............................................................................................. 81 B Literaturverzeichnis............................................................................ 85 C Abbildungsverzeichnis ....................................................................... 91 D Tabellenverzeichnis............................................................................ 93 IX
1 Einleitung
Moderne
Rechner
und
Ausgabemedien
ermöglichen
es,
fotorealistische
Abbildungen virtueller Räume zu generieren und darzustellen. Diese finden vor
allem im Unterhaltungssektor, aber auch im Entwicklungsbereich in Form von
3D-Modellierungswerkzeugen Anwendung. Die Computerspiele-Industrie entwickelt
schon
seit
vielen
Jahren
Spiele
der
unterschiedlichsten
Genres,
deren
Handlungsraum virtuelle 3D-Umgebungen sind. Ebenso wie die Spiele-Entwicklung
bedient sich die Filmindustrie der 3D-Anwendungen für die Umsetzung von Szenen
beziehungsweise kompletten Filmen oder kombiniert virtuelle Objekte mit realen
Szenen. Weiteres Potenzial verbirgt sich in der Präsentation komplexer Daten im
dreidimensionalen Raum: Dreidimensionale Datenmengen und ihre Relationen
lassen sich auf drei räumlichen Achsen abbilden und erlauben somit eine Exploration
in allen Raumrichtungen.
Als wesentlicher Faktor der Immersion, des Eintauchens in diese Welten, zählt nicht
nur der Realitätsgrad der 3D-Darstellungen dieser Welten, sondern vielmehr die
„gemeinsame Anwesenheit der Anwender an einem ‚Ort‘ mit vielfältigen Optionen
zur Kommunikation und Interaktion“ [Breuer 2007, S. 8]. Ähnlich wie in der Realität
soll es dem Benutzer möglich sein, Gegenstände zu berühren, diese zu verschieben,
zu drehen oder mit Werkzeugen zu bearbeiten. Die einzigartige Eigenschaft
virtueller Welten, physikalische Gesetze zu simulieren und zu verändern, bietet
Potenzial für neue Entwicklungen im Interaktionsdesign.
Aktuelle Technik kann die virtuelle Welt nicht mit der Gesamtheit der haptischen,
akustischen, visuellen, gustatorischen und olfaktorischen Sinneskanäle bereichern
[Fernando et al. 2006]. Das akustische und das visuelle Erscheinungsbild einer Szene
lassen sich, wie Abbildung 1.1 aufzeigt, mit den bisherigen Mitteln ähnlich einem
Foto darstellen. 3D-Soundsysteme vermitteln einen räumlichen Klangeindruck.
Haptische Merkmale von Oberflächen lassen sich nur über die Reflexions- und
Absorptionseigenschaften der Oberfläche abbilden. Gewicht und Volumen eines
Objekts können über sogenannte Force-Feedback (Kraft-Rückmeldung)-Geräte
repräsentiert werden (vgl. [Fernando et al. 2006]). Dabei erhält der Anwender neben
akustischen und visuellen auch haptische Rückmeldungen.
Die Interaktion in einem virtuellen 3D-Raum mit realen 2D-Eingabegeräten weist ein
komplexes Problem bei der Übersetzung auf: Die Bewegung der Maus, als
Stellvertreterin der 2D-Eingabegeräte, vollzieht sich standardmäßig nur in zwei
Dimensionen. Eine direkte Übertragung dieser Bewegung auf ein virtuelles Objekt
verschiebt dieses ebenfalls in zwei Dimensionen. Spezielle Eingabegeräte erlauben
1
EINLEITUNG
eine Verschiebung entlang aller Raumachsen gleichzeitig. Jedoch sind diese nicht an
jedem Arbeitsplatz verfügbar. Ohne jegliche räumliche Begrenzungen und
Anhaltspunkte ist nicht ersichtlich, in welche Richtung ein Objekt innerhalb der
virtuellen Welt bewegt wird. Ein Ansatz zur Lösung dieses Problems ist die
Entwicklung sogenannter Widgets, die als Mittler zwischen mausbasierter
Interaktion und zu manipulierendem Objekt in der virtuellen Welt dienen.
Abbildung 1.1: reale Landschaft (links); fotorealistische Abbildung dieser Landschaft im
Computerspiel ‚Crysis‘ (rechts) [Crytek 2008]
Orientierung ist ein wichtiger Aspekt der Interaktion und hat in virtuellen Welten
essenzielle Bedeutung (vgl. [Däßler 1998]). Eine effektive Interaktion in einer endlosen komplexen virtuellen Welt ohne Referenzsystem ist nur gegeben, wenn sich
der Anwender darin orientieren kann. Es ist daher notwendig, Elemente und
Methoden weiterzuentwickeln, die den Nutzer bei der Orientierung aktiv oder passiv
unterstützen. Werkzeuge wie Kompass, Sextant, GPS und Kartenmaterial aus der
Realität können in ähnlicher Weise in die Virtualität übertragen werden. Aufgrund
der Unbeschränktheit virtueller Welten sind jedoch auch andere Werkzeuge
beziehungsweise Hilfsmittel denkbar als die aus der Realität bekannten.
Am Lehrstuhl für Mediengestaltung der Fakultät Informatik der Technischen
Universität Dresden wurde die Forschungsumgebung Bildsprache LiveLab (BiLL)
entwickelt, um im Rahmen von studentischen Arbeiten Themen aus den Bereichen
der Wahrnehmungstheorie, der Interaktionsgestaltung und der technischen
Visualistik zu untersuchen (vgl. [Ebner 2007]).
2
EINLEITUNG
BiLL ist eine Applikation zur Darstellung von 3D-Szenen, die aus zwei Fenstern,
einem Editor-Fenster und einem Viewer-Fenster, besteht. Das Editor-Fenster dient
der Veränderung von verschiedenen Parametern der betrachteten Szene. Das
Viewer-Fenster zeigt die geladene 3D-Szene im Fenster- oder Vollbild-Modus. Diese
Trennung von Bearbeitung und Ansicht ist zugleich Ausgangspunkt für die
Zielstellung dieser Arbeit.
Bisherige Umsetzungen studentischer Arbeiten – beispielsweise das Plug-in für die
Erweiterte
Perspektivische
Korrektur
oder
das
Plug-in
für
die
interaktive
Farbperspektive – stellten ihre Funktionalität ausschließlich im Editor-Fenster zur
Verfügung. Besonders bei der Untersuchung von 3D-Szenen im Vollbildmodus mit
einem Bildschirm ist es kompliziert, zwischen Viewer-Fenster und Editor-Fenster zu
wechseln, um Einstellungen an den Plug-ins vorzunehmen. Das Viewer-Fenster wird
hierbei teilweise vom Editor-Fenster verdeckt. Die Verwendung mehrerer Monitore
löst dieses Problem, jedoch erhöhen sich dadurch die Interaktionswege und die
direkte Verknüpfung von Funktionalität und Objekt in der 3D-Szene ist weiterhin
nicht gegeben.
Aus dem Gebieten der Interaktionsgestaltung und des User-Interface-Designs
ergeben sich interessante Ansätze zur Lösung der zuvor aufgezeigten Probleme und
Defizite der Anwendung Bildsprache LiveLab. Die folgende Zielstellung wird die
Schwerpunkte der Untersuchungen dieser Arbeit herausstellen und erläutern.
Abbildung 1.2:
Viewer-Fenster (Vollbild) und Editor-Fenster der Arbeitsumgebung BiLL
3
EINLEITUNG
1.1 Zielstellung
Im Rahmen dieser Diplomarbeit wird das bestehende Interaktionskonzept der
Arbeitsumgebung Bildsprache LiveLab untersucht. Die vorhandenen Defizite werden
aufgezeigt und dienen im Anschluss als Ausgangspunkt für die Entwicklung eines
neuen Konzepts. In diesem Zusammenhang werden verschiedene Menüformen,
3D-Widgets und Orientierungshilfen analysiert. Die Resultate dieser Betrachtungen
sind die Basis für die Entwicklung und Umsetzung des neuen Interaktionskonzepts
für BiLL.
Darüber hinaus wird eine Orientierungshilfe für die Forschungsumgebung entwickelt
und
implementiert.
Zusätzlich
muss
BiLL
um
eine
Service-Architektur
(SceneWidgetService) erweitert werden, welche die Umsetzung und Integration des
Interaktionskonzepts gewährleistet. Exemplarisch wird die Funktionalität eines
bereits existierenden Plug-ins mit Hilfe der zuvor entwickelten Service-Architektur in
den Viewer integriert. Das Plug-in zur Steuerung der Beleuchtung innerhalb der
Szene wird mit Interaktionselementen ergänzt und in das neu entwickelte Interaktionskonzept integriert.
1.2 Gliederung
Die Diplomarbeit ist in sieben Kapitel untergliedert. Nach einer Einführung in Form
der Motivation und Zielstellung folgt im zweiten Kapitel die Definition und
Abgrenzung verschiedener Begriffe, die im Verlauf dieser Arbeit von Bedeutung
sind. Dabei wird auf computergrafische, softwaretechnologische und gestalterische
Fachtermini eingegangen, die grundlegend für diese Arbeit sind.
In Kapitel Drei werden Arbeiten zur Interaktionsgestaltung, Navigation und
Manipulation von 3D-Umgebungen betrachtet. Hierbei liegt der Schwerpunkt auf
der Untersuchung bestehender Navigationsformen und der Darstellung, welche
Elemente und Methoden bereits entwickelt wurden, um den Anwender zu führen
und zu unterstützen. Das vierte Kapitel untersucht die zusammengestellten
Orientierungshilfen, 3D-Widgets und Menü-Varianten anhand zuvor entwickelter
Kriterien hinsichtlich ihrer Portierbarkeit zur Umsetzung der Zielstellung in
Bildsprache LiveLab.
Anhand der gewonnenen Erkenntnisse werden in Kapitel Fünf die einzelnen
Aspekte
des
Gesamtkonzepts
separat
analysiert
und
entworfen.
Deren
Implementierung wird auszugsweise erläutert. Im Anschluss stellt Kapitel Sechs ein
Anwendungsszenario vor, welches den Prozess der Integration und Nutzung der
neuen Funktionalität im Viewer-Fenster erläutert. Hierzu wird am Beispiel des LichtPlug-ins gezeigt, wie die Funktionen, die sich zuvor im Editor-Fenster befanden,
gleichzeitig im Viewer-Fenster nutzbar sind. Ebenso werden die Nutzungsvarianten
4
EINLEITUNG
des überarbeiteten Interaktionsangebots des Viewer-Fensters beschrieben und die
Navigations- und Orientierungshilfe in Bezug auf ihren Mehrwert für die
Arbeitsumgebung beurteilt. Ein Fazit der Arbeit und ein Ausblick für zukünftige
Entwicklungen schließen die Diplomarbeit ab.
5
6
2 Grundlagen
In diesem Kapitel werden grundlegende Begriffe aus den Gebieten der
Computergrafik, der Software-Technologie und der Mensch-Computer-Interaktion
erklärt. Die Arbeit baut auf diesen Definitionen auf und greift bei der Konzeption
und Implementierung des Interaktionsmodells auf sie zurück.
2.1 Computergrafik
Im Folgenden werden computergrafische Begriffe erläutert, die zum Verständnis
dieser Arbeit beitragen. Das Konzept des Szenengraphs, die virtuelle Kamera und
deren Eigenschaften werden definiert.
Szenengraph
Ein Szenengraph ist eine objektorientierte, strukturelle Beschreibung einer dreidimensionalen Szene. Ein Szenengraph ist ein azyklischer, gerichteter Graph und
besteht aus einem oder mehreren Knoten (nodes). Aus graphentheoretischer Sicht
sind dem Elternknoten (parent, das Wurzelelement der Szene oder Objektgruppen)
die Kindknoten (child, einzelne Objekte der Szene) untergeordnet.
Verbund
Beleuchtung
Kamera
Kamera
Kugel
Verbund
Material
Würfel
Abbildung 2.1: Abstrahierte Darstellung eines Szenengraphen
Jeder Kindknoten hat einen oder mehrere Elternknoten. Meist wird jedem
Kindknoten nur ein Elternknoten zugeordnet. Dadurch wird eine hierarchische
Baumstruktur erzeugt. Diese Struktur zur Darstellung einer Szene vereinfacht die
Manipulation von Objekten beziehungsweise Objektgruppen, da Modifikationen der
7
GRUNDLAGEN
Parameter eines Elternknoten alle darunter liegenden Kindknoten beeinflussen. Die
Bearbeitung mehrerer Objekte wird durch das Anlegen eines übergeordneten
Modifikationsknotens vereinfacht (vgl. [Wernecke 2005]).
Das Konzept des Szenengraphen zur Beschreibung dreidimensionaler Szenen wird
unter anderem in dem Echtzeit-Grafik-Toolkit OpenSceneGraph verwendet.
OpenSceneGraph (OSG) ist zugleich auch die Visualisierungskomponente der
Forschungsumgebung Bildsprache LiveLab und verwendet zum Rendern OpenGL –
eine
Programmierschnittstelle
zur
Entwicklung
von
zwei-
beziehungsweise
dreidimensionalen Grafikanwendungen. Vorteile des Szenengraphen in OSG sind
Performanz, Produktivität, Übertragbarkeit und Skalierbarkeit (vgl. [OSG Developer
2007]). Diese Eigenschaften werden nun genauer erläutert.
Performanz
Durch das Verbergen von Objekten, die bei einer Projektion nicht sichtbar sein
werden,
da
sie
außerhalb
des
Sichtfensters
liegen,
lässt
sich
der
Berechnungsaufwand minimieren. Die hierarchische Struktur eines Szenengraphen
vollzieht auf diesem auf effiziente Weise Operationen. Beispielsweise werden alle
Objekte unterhalb eines Knotens mit einer Operation auf diesem ausgeblendet, der
Zugriff auf alle Unterobjekte ist nicht notwendig.
Am zuvor abgebildeten Szenengraph würde dies bedeuten, dass alle Elemente
unterhalb des Beleuchtungsknotens direkt von Änderungen der Parameter des
Knotens beeinflusst würden. Das Sortieren von Zuständen erlaubt es, ähnliche
Objekte zur selben Zeit zu verarbeiten und verursacht somit keine mehrfachen
Aufrufe (vgl. [OSG Developer 2007]).
Produktivität
Der Szenengraph übernimmt das Management der Grafik und kapselt somit
unüberschaubaren OpenGL-Quellcode. Das abstrakte Konzept kapselt Quellcode zur
Erzeugung von Objekten in 3D-Szenen. Die Komposition von Objekten vereinfacht
sich durch das hierarchische Zusammensetzen um ein Vielfaches. Das Konzept des
Szenengraphen integriert sich in die objektorientierte Programmierung und bildet
einen flexiblen und wiederverwendbaren Entwurf (vgl. [OSG Developer 2007]).
Übertragbarkeit
Ein Szenengraph, wie er in OpenSceneGraph verwendet wird, kapselt die unteren
Schichten des Rendering-Prozesses und reduziert dadurch den plattformspezifischen
Programmieraufwand (vgl. [OSG Developer 2007]).
8
GRUNDLAGEN
Skalierbarkeit
Ein wohlstrukturierter Szenengraph erlaubt es den Programmierern, ihren Fokus auf
die Entwicklung eigener Anwendungen zu legen, während das Abbildungssystem
des Szenengraphen die darunter liegende Hardware-Konfiguration organisiert (vgl.
[OSG Developer 2007]).
Alternative Verfahren
Besondere Formen zur Speicherung beziehungsweise Deklaration von Szenen sind
Szenenbeschreibungssprachen
–
Scene
Description
Languages
(SDL).
Diese
beschränken sich nicht auf die Auflistung von Primitiven, sondern beschreiben eine
3D-Szene mit einer Art Programmiersprache. Beispiele hierfür sind die Virtual Reality
Modeling Language (VRML), X3D oder die von POV-Ray (vgl. [Oaks 2009])
verwendete, der Programmiersprache C ähnelnde Syntax. Diese besteht aus
Bezeichnungen, Schlüsselwörtern, Gleitkommaausdrücken, Strings und speziellen
Symbolen (vgl. [Oaks 2009]).
VRML ist ein deklaratives Dateiformat für 3D-Objekte oder 3D-Welten und wurde
hauptsächlich für den Einsatz im Internet und Intranet entwickelt. Ebenso war
beabsichtigt, es als universelles Austauschformat für 3D-Grafik und Multimedia zu
verwenden (vgl. [Web3D Consortium 1997]). Vorteile dieser Beschreibungssprachen,
speziell von VRML und X3D, sind ihre einfache Manipulation und Erzeugung. Als
nachteilig erwies sich die Dateigröße aufgrund der nicht binären, sondern
textbasierten Speicherung der 3D-Objekte.
9
GRUNDLA
AGEN
Virtuellee Kameraa
Zur Abbildung virtueller Szeneen wurde in der Co
omputergraffik das virrtuelle
odell entwicckelt. Dieses geht in seiner Funktion auf das K
Kameramode
ell der
Kameramo
„Camera obscura“ zurück (vgl. [Barsky et al. 2003], [Franke
[
200
07]). Die virrtuelle
GL durch ihre Position (eye),
(
ihre Ausrichtung
A
(center) un
nd die
Kamera istt in OpenG
Orientierun
ng
(up
v
vector)
fesstgelegt.
Alle
A
Parameter
drei
werden
über
dreidimenssionale Vekttoren definieert.
top
leftt
right
bottom
Abbildung
g 2.2:
Modell der virtuellen
n Kamera und ihrer Parameteer (eye, center,, up vector) (lin
nks);
Modell der
d virtuellen Kamera
K
und De
efinition des Sicchtkörpers anh
hand der Param
meter:
left, right, top, bottom, near, far (rechts)
Der Positio
onsvektor gibt den Pun
nkt der Kam
mera im Welltkoordinateensystem an
n. Auf
welchen Punkt
P
die Kaamera in deer Szene blicckt, wird du
urch den Au
usrichtungsvvektor
festgelegt.. Der Verbin
ndungsvektor zwischen
n Positions- und Ausricchtungsvekttor ist
die Sichtacchse der Kaamera. Die Drehung der Kamera um die Sicchtachse gib
bt der
Orientierun
ngsvektor an.
Der Raum der durch die virtuellee Kamera errfasst und auf
a dem Mo
onitor abgebildet
d
den Sichtkörper
S
(Abbildung
g 2.2 (rechtts)) beschrieeben. In Op
penGL
wird, ist durch
wird dieseer durch die Parameter left, right, top und bo
ottom definieert. Die Nah
h und
Ferngrenzee des Sichttkörpers wird durch die
d Parametter near un
nd far festg
gelegt
(Abbildung
g 2.2 (links))).
Die Navigation der Kamera
K
in virtuellen Welten
W
wird
d in OSG ü
über sogena
annte
n realisiert. Diese transsformieren die
d Bewegu
ungen der Maus
Matrix-Maanipulatoren
abhängig
von
derr
gedrückkten
Mausstaste
(linkke,
mittlere,
e)
rechte
in
amera. Durrch das Beschränken von
Positionsveeränderungeen der virrtuellen Ka
Freiheitsgrraden werdeen die Navigationsrichttungen redu
uziert und eermöglichen
n eine
einfacheree
Handhab
bung.
Freiheitsgrade
definieren
n
die
Traanslations-
und
Rotationsaachsen der virtuellen Kamera
K
(vgl. [Schwall 2004]).
2
Sech
hs Freiheitsgrade
10
GRUNDLAGEN
sind für eine Kamera definiert. Drei davon beschreiben die Translation entlang der
Raumachsen des kartesischen Koordinatensystems (vgl. [Stevens, Lewis 2003]).
Analog dazu bilden die Rotationen um diese Achsen die restlichen drei Freiheitsgrade (vgl. Abbildung 2.3).
Abbildung 2.3: Die sechs Freiheitsgrade der virtuellen Kamera
Mit diesen Freiheitsgraden ist jede Position, Ausrichtung und Orientierung der
Kamera im Raum formal definiert. Die Maus als Eingabegerät deckt nur zwei
Freiheitsgrade ab – Bewegung der Maus vor-zurück und links-rechts. Durch die
Kombination der Bewegung der Maus und einer Maus-Taste werden alle sechs
Freiheitsgrade kontrolliert. Jedoch wirkt die Kontrolle über alle Freiheitsgrade für
unerfahrene Nutzer kompliziert und nicht intuitiv (vgl. [Herczeg 2006]).
2.2 Software-Technologie
Die
zur
Umsetzung
der
theoretischen
Konzepte
verwendeten
software-
technologischen Methoden und Konzepte werden im Folgenden erläutert. Das
Konzept der objektorientierten Programmierung ist dabei Ausgangspunkt für das
Komponentensystem, auf dem die Forschungsumgebung Bildsprache LiveLab
basiert.
Objektorientierte Programmierung
Als objektorientierte Programmierung wird die Modularisierung von Programmieranweisungen bezeichnet. Diese Strukturierung verbirgt die eigentliche Implementierung von Funktionalität und zeigt nach außen nur die zur Interaktion erforderliche
Programmierschnittstelle. Das heißt, Objekte vereinen Funktionen und Daten
beziehungsweise Ressourcen.
Programme, die objektorientiert entwickelt werden, bestehen aus einer Vielzahl von
miteinander agierenden Objekten. Der Programmierer legt bei der Entwicklung die
Struktur der Objekte anhand von Klassen fest. Auf Basis dieser Klassen werden zur
11
GRUNDLAGEN
Laufzeit eines Programms Objekte erzeugt, die Instanzen genannt werden. Durch
das Konzept der Kapselung können die Eigenschaften von Objekten nur über die
vom Objekt selbst bereitgestellten Methoden verändert beziehungsweise gelesen
werden. Damit wird die interne Struktur eines Objekts sichergestellt. Durch das
Prinzip der Vererbung wird es Objekten ermöglicht, Methoden und Eigenschaften
von anderen zu erben und diese zu spezialisieren.
Zur Repräsentation der Klassenstruktur eines Programms wurde eine grafische
Notationsform – Unified Modeling Language (UML) – von der Object Management
Group (OMG) entwickelt. Diese Notation wird in der vorliegenden Arbeit zur
Darstellung der einzelnen Klassen und ihres Zusammenwirkens verwendet. In Form
von Klassendiagrammen werden die einzelnen Klassen und ihre Relationen
dargestellt. Sequenzdiagramme zeigen die Interaktion zwischen Benutzer und
System und den Austausch von Informationen innerhalb des Systems.
Komponentensystem POCO
Die komponentenbasierte Software-Entwicklung beruht auf dem Konzept, dass
Software-Systeme ähnlich wie Maschinen aus mehreren Bauteilen aufgebaut sind.
Ebenso wie im Maschinenbau sind in der Software-Technologie Komponenten zu
identifizieren, die für ein lauffähiges System zwingend notwendig sind. Ferner
müssen Verbindungsmöglichkeiten definiert werden, die zur Erweiterbarkeit des
Systems dienen. Komponentenbasierte Software erleichtert die Entwicklung von
Software-Systemen, da bestehende Komponenten miteinander verknüpft werden
können, ohne sie neu zu programmieren.
Ein Komponentensystem ist die Portable Component Open Service Platform (POCO
OSP). Diese ist eine Übertragung der Open Services Gateway initiative (OSGi),
welche in der Programmiersprache Java spezifiziert ist, in die Programmiersprache
C++ (vgl. [OSGi Alliance 2004]). Die Arbeitsumgebung Bildsprache LiveLab 2.0
wurde auf Basis des Komponentensystems POCO implementiert. POCO dient dabei
als Mittler zwischen dem Betriebssystem und der C++-Standard-Bibliothek.
Das verwendete Komponentenmodell von POCO basiert auf dem Konzept von
Bundles. Bundles sind Software-Komponenten, bestehend aus ausführbarem
Quellcode und der dazugehörigen Konfiguration sowie den notwendigen Daten und
Ressourcen. Der Begriff wird in dieser Arbeit gleichbedeutend mit dem Begriff Plugin verwendet. Plug-ins erweitern eine Basisanwendung und stellen neue Features für
andere Bundles bereit. Die Kommunikation der Bundles untereinander wird über
Services realisiert, die über eine zentrale Service-Registrierung verwaltet werden.
Bundles können sich an Services registrieren und somit deren Funktionen nutzen
oder selbst einen eigenen Service bereitstellen und eigene Funktionalitäten für
andere Bundles bereitstellen (vgl. [AppInf 2008]).
12
GRUNDLAGEN
Bildsprache LiveLab 2.0
Die
Forschungsumgebung
Bildsprache
LiveLab
ist
eine
Plattform
für
die
Untersuchung von wahrnehmungstheoretischen Phänomenen. Im Vergleich zu
anderen 3D-Anwendungen ist BiLL ein erweiterbares Betrachtungswerkzeug für 3DSzenen und dient nicht der Erstellung von neuen 3D-Szenen. Einfache
Möglichkeiten zur Modifikation von Objekten zählen zu den Basisfunktionen der
Grundanwendung. Objekte können ein- oder ausgeblendet werden und anhand
von Buttons sind ihre Position und Rotation sowie Skalierung veränderbar. Das
Konzept der Plug-in-Architektur bietet die Option der Erweiterbarkeit der
Basisfunktionalitäten.
Im Rahmen von Beleg- und Diplomarbeiten wurden verschiedene Plug-ins
entwickelt, die den Funktionsumfang von BiLL erweiterten. Die Architektur der
Forschungsumgebung wurde im Rahmen einer Diplomarbeit überarbeitet und auf
Basis des Komponentensystems POCO reimplementiert (vgl. [Kammer 2009]). Diese
Überarbeitung erfolgte aufgrund der steigenden Anzahl an Plug-ins und deren
Kommunikationsbedarf untereinander. Durch die Integration von sogenannten
Services (vgl. Komponentensystem POCO) wurde eine einfachere und stabilere
Kommunikation zwischen den Plug-ins im Vergleich zur Vorgängerversion erreicht
(vgl. [Kammer 2009]).
Services werden von Plug-ins bereitgestellt. Andere Plug-ins melden sich an einem
bestehenden Service an, um auf Ereignisse des Service zu reagieren oder die vom
Service bereitgestellten Methoden zu nutzen. Bereits etablierte Funktionen können
somit anderen Plug-ins zur Verfügung gestellt werden.
Das derzeitige Erscheinungsbild der Anwendung umfasst ein Editor-Fenster
(Abbildung 2.4) und ein Viewer-Fenster (Abbildung 2.5). Im Viewer-Fenster wird
eine dreidimensionale Szene betrachtet. Die Navigation durch die dargestellte 3DSzene erfolgt mit Hilfe der Maus. Der Editor bietet standardmäßig die
Repräsentation des Szenengraphen in einer Baumstruktur, Informationen zum
jeweils selektierten Knoten des Szenengraphen sowie zu Kameraparametern. Zudem
sind verschiedene Kameranavigatoren über eine Tastenkombination auswählbar.
Über den Menüpunkt Extras erhält man Zugang zum BundleAdmin. Mit diesem
werden neue Bundles geladen oder bereits aktive Bundles wieder entladen. Durch
Hinzufügen von Bundles erweitert sich die Funktionalität der Anwendung zur
Laufzeit.
Neu entwickelte Plug-ins stellen ihre Funktionalität in Form eines neuen Reiters im
Editor-Fenster bereit. Die strikte Trennung von Editor- und Viewer-Fenster
ermöglicht keine Änderungen von Einstellungen direkt im Viewer-Fenster.
13
GRUNDLAGEN
Abbildung 2.4: Editor-Fenster der Umgebung BiLL mit Szenengraph der geladenen Szene
Abbildung 2.5:
14
Viewer-Fenster mit geladenem 3D-Modell
GRUNDLAGEN
2.3 User-Interface-Design
Das Hauptaugenmerk dieser Arbeit liegt auf der Interaktionsgestaltung von
Software, daher sind Begriffe wie Orientierung, Interaktion, Widget und MenüStrukturen vorab zu erläutern und für den Kontext von Bildsprache LiveLab
einzugrenzen.
Orientierung
Der Begriff der Orientierung leitet sich vom lateinischen oriens, zu deutsch
aufgehend beziehungsweise sich nach dem Aufgang der Sonne ausrichten, ab.
Diese Handlung erlaubt es den Menschen, sich zurechtzufinden. Besonders in
unbekannten Umgebungen bedarf es einer Orientierungsphase, um sich in diesen
gezielt zu bewegen. Eine Phase der Orientierung ist auch im Umgang mit virtuellen
Welten zu beobachten. Der Nutzer findet sich in einer ihm unvertrauten Umgebung
wieder und muss seine Position darin feststellen.
STAPELKAMP
konstatiert:
„Orientierung
bedarf
Transformationen“
(vgl.
[Stapelkamp 2007], S. 131). Der Mensch braucht visuelle Bezugssysteme
beziehungsweise feste visuelle Anker oder Landmarken (vgl. [Groh 2005]). Die
Transformation der Umwelt in Karten und Wegbeschreibungen dient auch der
Weitergabe von Wissen über die Umgebung. Dies findet sich auch im Aufbau von
Gedächtnissystemen beziehungsweise Orte-Bilder-Systemen wieder. Komplexe
Inhalte werden mit einem Ortssystem überlagert, Sachverhalte werden in Bilder
eingefügt und somit ‚verortet‘ (vgl. [Groh 2005]). Das Durchwandern dieser Pfade
beschreibt das Abfragen der Informationen.
Als Verdeutlichung soll exemplarisch die Erinnerung an einen Arbeitsprozess anhand
eines bekannten Pfades dienen, der durchschritten wird. Markante Punkte entlang
des Weges spiegeln dabei einzelne Arbeitsschritte wider. Der Nutzer eines
derartigen Gedächtnissystems generiert einen mentalen Raum, der einer virtuellen
Umgebung gleicht. Diese Fähigkeit der Verbindung von Orten und Bildern bietet
auch für die Orientierung in virtuellen Welten Potenzial.
Bei der Darstellung von virtuellen Informationsräumen ist es notwendig, die Daten
zu transformieren und dem Nutzer im übertragenen Sinne eine Karte zu geben, mit
welcher diese computergenerierte Welt orientierbar wird (vgl. [Stapelkamp 2007]).
In diesem Fall ist die Karte der Repräsentant einer Orientierungshilfe für virtuelle
Umgebungen. Die Gestaltung der Karte hängt immer von der Umgebung, aus der
die Daten heraus generiert wurden, und vom Kontext, in dem sie präsentiert
werden, ab.
15
GRUNDLAGEN
Orientierung bedeutet ferner, sich leiten zu lassen, und bezieht sich in diesem
Zusammenhang auf Informationsaustausch und die Bereitschaft des Dazulernens.
Eine neue Umgebung ist ungewohnt und anders. Je neuer und komplexer eine
derartige Umgebung ist, desto intensiver ist die Lernphase für das Begreifen des
neuen Systems für den Nutzer (vgl. [Stapelkamp 2007]). Dies gilt sowohl für reale
Umgebungen als auch für virtuelle Informationsräume. Für den Interface- und
Interaktionsgestalter ergibt sich daher die Aufgabe, ein Orientierungssystem zu
schaffen, welches dem Nutzer einen kurzen und nachvollziehbaren Lernprozess
abfordert.
Metaphern helfen dabei, ein abstraktes, unbekanntes System auf ein konkretes,
bekanntes System abzubilden. Metapher leitet sich vom griechischen metaphora ab
und bedeutet Übertragung. Die Arbeit mit Metaphern erleichtert den Einführungsprozess neuer Funktionen, da diese mit dem Anwender vertrauten Eigenschaften
verknüpft werden.
Interaktion
Interaktion ist kein absoluter Begriff und wird daher in verschiedenen Fachgebieten
auch unterschiedlich definiert:
„Wechselwirkung, Wechselbeziehung. soziologischer Grundbegriff für
den Sachverhalt, dass sich Individuen oder Gruppen durch ihr
aufeinander
bezogenes
Handeln
gegenseitig
beeinflussen“
[Reinhold et al. 2000, S. 305].
Das Psychologische Wörterbuch bestimmt Interaktion wie folgt:
„Interaktion [lat.], wechselseitige Beeinflussung. Statische & Wechselwirkung. Von C.L. Hüll wurde die Bezeichnung ‚interaction principle‘ für
die gegenseitige Beeinflussung afferenter Nervenimpulse eingeführt,
womit
er
teilweise
berücksichtigte
und
die
Entdeckungen
der
die
elementaristische
Gestaltpsychologen
Auffassung
isolierter
Stimuluswirkung aufgab“ [Dorsch et al. 2004, S. 282].
STRUBE beschreibt Interaktion schließlich im Rahmen des Fachgebiets der
Kognitionswissenschaften:
„Mit Interaktion wird das wechselseitige Aufeinander-Bezug-Nehmen
handelnder Akteure in einem konkret historischen lebensweltlichen
Zusammenhang,
dem
I.-Kontext
bezeichnet.
Der
I.-Kontext
ist
gekennzeichnet durch die in ihm geltenden allgemeinen Handlungsorientierungen, die bereits zu den geteilten Wissensbeständen der
Akteure gehören oder im Umgang mit bedeutsamen Personen im
16
GRUNDLAGEN
Sozialisationsprozess erworben werden vertreten ...“ [Strube 1996,
S. 284-285].
Der Begriff der Interaktion variiert je nach der Wissenschaft und dem Kontext, in
welchem er verwendet wird. Grundlegend findet bei Interaktion ein wechselseitiges
Aufeinander-Einwirken statt. Die einzelnen Definitionen ergänzen diesen Begriff
durch erklärende Adjektive, um auf die besonderen Bedingungen ihres Fachgebiets
einzugehen.
Zusammenfassend setzt sich Interaktion aus ‚Inter‘ – drückt aus, dass eine
Verbindung zwischen etwas besteht – und ‚Aktion‘ – es wird eine Handlung ausgeführt – zusammen. Es besteht demnach eine gegenseitige Beeinflussung von
Handlungen zwischen verschiedenen Handelnden. Im Kontext der MenschComputer-Interaktion sind die aufeinander einwirkenden Akteure der Nutzer und
der Computer. Beide wirken aktiv auf das Gegenüber ein und gestalten somit einen
Interaktionsprozess.
Icons
Der Begriff Icon stammt aus dem Englischen und bedeutet ‚Ikone‘. Dieser wiederum
leitet sich vom griechischen ikonos, zu deutsch ‚Bild‘ ab (vgl. [Stapelkamp 2007]).
Eine Ikone ist ein Heiligenbild, das kein direkter Träger von Information ist. Der
unmittelbare Umgang mit dem Bild in einem vorgegebenen Kontext offenbart erst
den Inhalt des Bildes (vgl. [Stapelkamp 2007]). Icons sind ebenfalls erst im richtigen
Kontext verständlich.
Der Einsatz von Icons dient der Kommunikations- und Interaktionsunterstützung
zwischen Benutzeroberflächen und Nutzern. Diese Benutzeroberflächen sind nicht
rechnergebunden. Auch Hinweis- beziehungsweise Verkehrsschilder oder alltägliche
Gegenstände weisen Benutzeroberflächen auf, die mit Icons versehen sind. Als
Bestandteil des Interface sollen Icons die Kommunikation initiieren und einen Dialog
zwischen Nutzer und System ermöglichen (vgl. [Stapelkamp 2007]). Die
Kommunikation über Icons ist auch bei fehlender Sprachkenntnis oder Lesefähigkeit
der Anwender möglich, sofern sie im kulturanthropologischen Kontext sinnvoll
eingesetzt werden.
Merkmale für den ordnungsgemäßen und benutzerfreundlichen Einsatz von Icons
sind:

Präzision der Aussage

Reduktion auf das Wesentliche

eindeutige Interpretierbarkeit

Transport umfangreicher Botschaften
17
GRUNDLAGEN
STAPELKAMP unterteilt Icons in zwei Gruppen. Die eine Gruppe umfasst die
visuellen Repräsentanten von Objekten oder Themen, die andere alle diejenigen, die
Vorgänge und Funktionen beschreiben. Das Icon grenzt sich von den Begriffen der
Metapher und des Symbols ab, hat aber Gemeinsamkeiten mit Piktogrammen. Diese
Abgrenzung erfolgt auf Basis der zuvor genannten Merkmale von Icons.
Widgets
Widget ist die Abkürzung von „window gadget“ und wurde erstmals im
Zusammenhang mit Benutzungsschnittstellen im Rahmen des Projekts Athena im
Jahr 1988 angewendet. PREIM definiert Widgets als „eine Kombination aus einer
Geometrie und dem dazugehörigen Verhalten zur Steuerung oder Anzeige von
Information“ [Preim 1999, S. 435] [Conner 1992, S. 2]. Sie stellen eine Interaktionsschnittstelle zwischen dem Nutzer und dem zu manipulierenden Objekt her und
dienen der direkten Manipulation von Objekteigenschaften. Widgets sind somit
Träger von Informationen über das Interaktionsobjekt.
Die Anfänge der Widgets sind im Bereich zweidimensionaler Benutzerschnittstellen
zu
finden,
sie
wurden
jedoch
mit
dem
Aufkommen
dreidimensionaler
Entwicklungsumgebungen auch auf den 3D-Kontext in Form von 3D-Widgets
adaptiert. Sie unterstützen den Nutzer bei den Basisaufgaben im virtuellen 3DRaum: Selektion, Positionierung, Rotation und Skalierung (vgl. [Bowman et al.
2001]). Widgets sind Elemente, die durch das Drücken der linken Maustaste und das
Bewegen
der
Maus
die
Verschiebung,
Rotation
und
Skalierung
von
Szenenelementen ermöglichen (vgl. [Dachselt 2004]).
PREIM formuliert die Definition für Widgets allgemein. Für den konkreten Fall der
3D-Widgets klassifiziert DACHSELT diese wie folgt (Tabelle 2.2 und Tabelle 2.2):
Direkte 3D-Objektinteraktion
Objekselektion
Manipulation der 3D-Szene
Orientierung und Navigation
Direkte Selektion
Direkte Blickpunktselektion
Okklusionsselektion
Geführter Transport
Distanzselektion
Miniaturdarstellungen
Geometrische Manipulation
Steuerung der Szenenpräsentation
Lineare Transformation
Lichtmanipulation
Nichtlineare Transformation
Kameramanipulation
High-Level
Soundsteuerung
Objektmanipulation
Tabelle 2.1:
18
Klassifikation von Widgets nach DACHSELT [Dachselt 2004].
GRUNDLAGEN
Exploration und Visualisierung
Anwendungskontrolle
Geometrische Exploration
Diskrete Wertgeber
Hierarchie Visualisierung
Aktivierung
Visualisierung von Graphen
Zwei Zustände
Visualisierung von 2D-Daten
Multiple Zustände
Wissenschaftliche Visualisierung
Kontinuierliche Wertgeber
Skalare Werte
Multiple Werte
Spezielle Werteingaben
Farbwähler
Menüselektion
Temporäre Optionsmenüs
Einzelmenüs
Menühierarchien
Container
Tabelle 2.2:
Klassifikation von 3D-Widgets nach DACHSELT [Dachselt 2004].
DACHSELT unterscheidet zunächst vier Hauptkategorien: die direkte 3D-ObjektInteraktion, die Manipulation der 3D-Szene, die Exploration und Visualisierung sowie
die Anwendungskontrolle. Eine direkte Objektinteraktion wird durch Widgets zur
Objektselektion und zur geometrischen Manipulation gekennzeichnet. Die direkte
Selektion eines Objekts oder einer Objektgruppe erfolgt durch die Auswahl mit
einem Eingabegerät (Maus). Die Auswahl mehrerer Objekte erfolgt durch die
Okklusionsselektion, durch einen Volumen-Cursor mit einer Selektionsgeometrie
oder durch die Distanzselektion, die entfernte Objekte auswählt, beispielsweise
durch eine virtuelle Hand, die in die Tiefe des Raumes greift und Objekte somit
auswählt. Für den Einsatz an einem Desktop-Rechner eignen sich die direkte
Selektion und der Volumen-Cursor. Beide Verfahren sind bereits in Bildsprache
LiveLab integriert.
Die geometrischen Manipulationen unterteilt DACHSELT in lineare Transformationen
(Translation, Rotation und Skalierung), nicht-lineare Transformationen (Verdrehen,
Verbiegen und Verjüngen von Objekten) und High-Level-Objektmanipulationen
(freie Deformationen, Pfadverformungen).
Die Kategorie der Manipulation der 3D-Szene unterteilt DACHSELT in zwei
Unterkategorien: „Orientierung und Navigation“ sowie „Steuerung der Szenenpräsentation“ [Dachselt 2004, S. 73]. Zur ersten zählen Widgets, die eine direkte
Blickpunktselektion erlauben, die Auswahl vordefinierter Sichten oder einen
geführten Transport als Mittel der Navigation nutzen. Der Orientierung sind
Miniaturdarstellungen der 3D-Szene zugehörig.
19
GRUNDLAGEN
Die Kategorie „Exploration und Visualisierung“ umfasst die geometrische
Exploration, die hierarchische Visualisierung, die Visualisierung von Graphen, die
Visualisierung
von
2D-Daten
und
die
wissenschaftliche
Visualisierung
[Dachselt 2004, S. 73]. Die Anwendungskontrolle differenziert DACHSELT in fünf
Unterkategorien: Zustandsänderung/diskrete Wertgeber, kontinuierliche Wertgeber,
spezielle
Werteingaben,
Menü-Selektion
und
Container.
Widgets
zur
Zustandsänderung sind solche, die aktivierend beziehungsweise deaktivierend
wirken oder mehrere Zustände annehmen können. Als kontinuierliche Wertgeber
nennt DACHSELT jene, die skalare Werte abbilden und solche, die multiple Werte
darstellen. Zur Verdeutlichung der speziellen Werteingaben führt er beispielsweise
einen Farbwähler auf, da dieser mehrere Werte (Farbanteile des jeweiligen
Farbmodells) gleichzeitig ändert. In die Unterkategorie „Menü-Selektion“ werden
die temporären Optionsmenüs, die Einzelmenüs und die mehrstufigen MenüHierarchien eingeordnet (vgl. [Dachselt 2004]).
Menüs
Hinter einem Menü verbirgt sich eine gruppierte visuelle Darbietung verschiedener
Auswahlmöglichkeiten mittels Textfeldern oder Icons. Die Signalverarbeitung nach
dem Aktivieren eines Menüpunkts durch den Nutzer bleibt für diesen verborgen. Die
Gruppierung der Auswahl erfolgt entweder rein funktional oder thematisch
geordnet. Die Präsentation des Menüs ist vom jeweiligen Interaktionsdesign
abhängig und bietet verschiedene kontextbezogene Varianten (vgl. [Stapelkamp
2007]) beziehungsweise Gestaltungsformen (vgl. [DIN 1997b]). Eine Auflistung
verschiedener Menü-Varianten, die STAPELKAMP bereits identifiziert hat, gibt einen
Überblick über die Thematik der Menügestaltung.

Menü-Hintergrund-Integration

Karteikarten-Register

Pull-down-Menü

Drop-down-Menü

Menü als Bestandteil der Erzählform

Radial-Menü
Für die Gestaltung von Menüs fasst HERCZEG folgende Gesichtspunkte zusammen:
Die Kodierung der Menü-Elemente erfolgt anhand der allgemeinen Informationskodierungsmittel Text, Grafik, Farbe und Größe. Deren Anordnung wird durch die
Regeln der Gestaltungsgesetze bestimmt und ist entweder vertikal, horizontal,
mehrspaltig, mehrzeilig, mehrspaltig oder gruppiert.
Für die Abbildung großer Auswahlmengen werden hierarchisch verkettete Menüs
verwendet. Dazu zählen kaskadierende Menüs, Menübäume und scrollende Menüs.
Die Reihenfolge der Menü-Elemente wird durch unterschiedliche Faktoren bestimmt.
20
GRUNDLAGEN
Die Wichtigkeit, die Häufigkeit der Verwendung oder die alphabetische Reihenfolge
zählen dabei zu den wesentlichen Faktoren.
Der Hauptaspekt bei der Gestaltung ist die Art des Erscheinungspunkts beziehungsweise der Erscheinungsort (vgl. [Herczeg 2006]). Darin unterscheiden sich die zuvor
genannten Menü-Varianten, die STAPELKAMP identifiziert hat, grundlegend.
Die Anzahl der Auswahlmöglichkeiten an Menü-Elementen ist ein weiteres Merkmal
der Menü-Gestaltung. Die Auswahl der einzelnen Menü-Elemente durch den
Anwender ist durch die vorhandenen Eingabe- und Ausgabegeräte vorgeschrieben.
Der Nutzer hat die Möglichkeit, neben dem Finger auch die Maus beziehungsweise
die Tastatur für die Selektion von Menüpunkten zu nutzen. Menüs stellen besonders
für unerfahrene Nutzer eine einfache und intuitive Form der Interaktion dar, die
schnell erlernt wird. Zudem wirken Menüs durch eine geeignete grafische Aufbereitung als Erinnerungshilfe (vgl. [Herczeg 2006]). Durch ihre definierte
Funktionalität sind kaum syntaktische Eingabefehler möglich, zugleich führt dies den
Nachteil der fehlenden Parameterübergabe mit sich.
21
22
3 Interaktion und
Gestaltungsmethoden
In diesem Kapitel werden Arbeiten aus den Bereichen der allgemeinen Interaktion
und deren Gestaltung beschrieben. Im Speziellen wird auf Navigationsmetaphern
und -formen als Aspekte der Interaktion eingegangen.
3.1 Interaktionsgestaltung
Vor 30 Jahren wurden Personal Computer nur im wissenschaftlichen Bereich
benutzt. Besondere Fachkenntnisse waren für ihre Bedienung notwendig. Dies
änderte sich im Laufe der Zeit und Computer wurden für viele Menschen zugänglich
(vgl. [Moggridge 2007]). Daraus ergab sich die Notwendigkeit, die Computertechnologie beziehungsweise deren Schnittstelle zum Menschen so zu gestalten, als
wären sie ein Teil des alltäglichen Lebens. Benutzerschnittstellen sollten sowohl
gefühlsansprechende wie auch funktionelle Qualitäten aufweisen (vgl. [Herczeg
2006]).
Das folgende Kapitel beschäftigt sich zunächst mit den Grundfragen der
Interaktionsgestaltung, die von VERPLANK aufgestellt wurden. Dadurch wird die
Herangehensweise an die Gestaltung von Interaktionshandlungen aufgezeigt und
deren Bedeutung für die Effektivität einer Benutzerschnittstelle erläutert.
Grundfragen der Interaktionsgestaltung
VERPLANK konstatiert in einem Interview mit MOGGRIDGE, dass sich drei
Grundfragen während des Prozesses der Interaktionsgestaltung ergäben, die sich
jeder Interaktionsgestalter stellen müsse: zunächst die „How do you do?“-Frage
[Moggridge 2007, S. 127]. Bei dieser Frage steht das Handeln des Anwenders im
Vordergrund. Wie handelt er und wie würde er die notwendigen Aufgaben
ausführen? Hierfür müssen Interaktionsgestalter den Angebotscharakter von
Objekten so entwerfen, dass dem Nutzer eindeutig deren Funktionalität sowie
Funktionsweise gezeigt wird.
23
INTERAKTION UND GESTALTUNGSMETHODEN
Zur Erfüllung der Aufgaben muss der Anwender Parameter und Eigenschaften von
Objekten steuern. Für die Gestaltung von Steuerelementen, die dies bewerkstelligen,
gibt es laut VERPLANK zwei mögliche Steuerungsarten:

die kontinuierliche Steuerung

die diskrete Steuerung
Während bei einer kontinuierlichen Manipulation die Steuerung komplett in den
Händen des Nutzers liegt, delegiert der Anwender die Kontrolle im Fall der diskreten
Steuerung an den Rechner. Ein Beispiel aus der realen Welt sind Lautstärkeregler an
einem Radio, welche kontinuierlich gedreht werden können oder stufenweise über
Tasten am Gerät die Lautstärke regulieren. Im Virtuellen können Objekte entweder
kontinuierlich verschoben werden oder in vorgegebenen Schritten.
Die Interaktion mit einem Objekt geschieht entweder direkt oder indirekt. Während
bei der direkten Interaktion der Benutzer Veränderungen an Objekten unmittelbar
vollzieht, wird bei der indirekten Interaktion ein Vermittler eingeführt. Der Nutzer
agiert somit nicht mit dem Objekt selbst, sondern mit den Interaktionselementen der
Zwischenschicht, welche als Mittler zwischen Benutzer und Objekt dienen.
Abbildung 3.1: Die “How do you...?”-Fragen nach VERPLANK [Moggridge 2007, S. 126]
Eine weitere Frage, die sich der Interaktionsgestalter laut VERPLANK stellen muss, ist
die „How do you feel?“-Frage [Moggridge 2007, S. 127]. Hierbei ist das Feedback
des Systems, mit dem der Nutzer interagiert, essenzieller Bestandteil des
Gestaltungsprozesses. Die sensorischen Qualitäten der Präsentation des Feedbacks
sind daher von grundlegender Bedeutung. Wie dem Nutzer seine Handlungen
gespiegelt werden, entscheidet darüber, wie wohlgestaltet ein System ist.
24
Die dritte Frage, die im Rahmen der Interaktionsgestaltung aufkommt, ist die „How
do you know?“-Frage [Moggridge 2007, S. 127]. Wesentliche Aufgabe eines
Interaktionsgestalters ist es, dem Nutzer beim Verstehen des Systems zu helfen und
zu erklären, was gerade passiert und warum es passiert. Daher ergibt sich die
Notwendigkeit, dem Nutzer ein Bild beziehungsweise eine Karte über die
Funktionsweise eines komplexen Systems zu geben, welche das System erklärt. Die
Wege beziehungsweise Pfade auf der Karte zeigen dabei, was zu einem bestimmten
Zeitpunkt geschieht und warum.
Der Interaktionsgestaltungsprozess
Den Prozess der Gestaltung kennzeichnet VERPLANK durch vier Schritte: Motivation,
Bedeutung, Modi und Abbildung. Jeder Gestaltungsprozess ist durch ein
aufgetretenes Problem oder eine Inspiration motiviert. Daraus ergibt sich das
Gestaltungsziel. Eine geeignete Metapher zur Verknüpfung der ausgehenden
Motivation mit dem Ziel des Gestaltungsvorschlags ist die Grundlage für die
Entwicklung von Anwendungsszenarien. Anhand der Szenarien werden die
notwendigen Aufgaben identifiziert, unter einem konzeptionellen Modell vereint
und verschiedene Modi definiert. Erst anhand dieses Modells entscheiden sich die
Gestaltung der Benutzerschnittstelle und das Arrangement der erforderlichen
Steuerelemente (vgl. [Moggridge 2007]).
Abbildung 3.2: Skizze des Interaktionsdesignprozesses nach VERPLANK [Moggridge 2007 S. 130]
Motivation
Die Gestaltung neuer Interaktionskonzepte beginnt mit der Identifizierung von
Problemen während der Verwendung bestehender Interaktionsmechanismen oder
mit der Idealisierung eines Zustands, der erstrebenswert ist.
25
Bedeutung
Eine Metapher verknüpft Wissen aus einer bekannten Domäne mit einem
unbekannten Zielbereich (vgl. [Marcus 1994]). Bekannte Funktionsweisen, Konzepte
und Begriffe werden auf unbekannte Situationen projiziert, um den Umgang mit
diesen zu erleichtern. Unter diesem Gesichtspunkt erklärt sich die Metapher im
Kontext des Designs. Anhand von diversen Anwendungsszenarien wird in diesem
Schritt der Zusammenhang zwischen der Metapher und dem System verdeutlicht.
Daraus leitet sich die Absicht der Metapher ab (vgl. [Moggridge 2007]).
Modi
Essenziell für die Gestaltung eines Interaktionskonzepts ist es, die Aufgaben und
Absichten der Nutzer genau zu kennen. Die Modi repräsentieren in diesem
Zusammenhang die verschiedenen Aufgabenbereiche. Dabei ist zu ergründen,
welches Wissen der Nutzer zu einem bestimmten Zeitpunkt in einem speziellen
Modus an Informationen hat und bereitgestellt bekommt.
Welcher Typ von Nutzer das System bedient, entscheidet über die Wahl des Modus.
Wird das System im Expertenmodus oder im Anfängermodus bedient? Die
Aufstellung von Nutzerprofilen ist dabei von Bedeutung und wird im Folgenden
detailliert erläutert (vgl. [Moggridge 2007]).
Abbildung
Dies ist der letzte Schritt beim Gestalten von Interaktion. Erst in diesem Schritt wird
das Erscheinungsbild der Steuerelemente festgelegt und ihre Anordnung auf der
Präsentationsfläche oder im Präsentationsraum strukturiert. Das gilt für SoftwareInterfaces im Virtuellen ebenso wie für Hardware-Interfaces in der Realität.
Der von VERPLANK vorgestellte Prozess der Interaktionsgestaltung weist Parallelen
zum zielorientierten Interaktionsdesign von COOPER auf. Dieser verfolgt bei der
Gestaltung von Interaktionen eine durch die Ziele bestimmte und vorangetriebene
Gestaltung (vgl. [Cooper et al. 2007]). Die Aufgaben zum Bewerkstelligen eines
konkreten Ziels variieren dabei.
Der Gestaltungsprozess ist nach COOPER wie folgt gekennzeichnet:
26

Interview mit den Anwendern

Erstellung von Personas

Zieldefinition

Ausarbeitung von Szenarien
Zunächst werden die Anwender bezüglich ihrer Absichten und Ziele, die sie mit der
Nutzung des Systems verfolgen, befragt. Anhand dieser Informationen lassen sich
im zweiten Schritt sogenannte Personas erstellen. Personas sind imaginäre, aber
spezifische Beispielnutzer des zu gestaltenden Systems (vgl. [Cooper et al. 2007],
[Andrews 2009]). COOPER weist darauf hin, dass nicht für den ‚Durchschnittsnutzer‘
gestaltet werden darf, sondern immer für klar definierte Nutzergruppen, die auch
Stereotype genannt werden.
Die entwickelten Personas werden im Gestaltungsprozess genutzt, um zu
überprüfen, ob die Gestaltung den Anforderungen dieser Nutzer gerecht wird. Für
jede Persona müssen Ziele definiert werden, die wiederum den Ausgangspunkt für
die Generierung von Szenarien bilden. Zum Erreichen dieser Ziele werden Szenarien
entworfen, die genau beschreiben, wie eine Persona an ein konkretes Ziel gelangt.
Die Szenarien reichen von primären über notwendige bis hin zu hinreichenden
Szenarien.
Für die Erarbeitung des Interaktionskonzepts für Bildsprache LiveLab in dieser Arbeit
werden die beiden sich ergänzenden Methoden, der Interaktionsgestaltungsprozess
nach VERPLANK und die zielorientierte Interaktionsgestaltung nach COOPER,
Anwendung finden.
Gestaltungskriterien
Nach der Konzeption erfolgt deren praktische Umsetzung in der Forschungsumgebung Bildsprache LiveLab. Dafür sind Gestaltungskriterien von Bedeutung, die
nachstehend dargestellt werden. Diese Kriterien werden von HERCZEG erläutert und
stützen sich auf die in der DIN EN ISO-Norm 9241 festgehaltenen Regeln zur
Software-Ergonomie.
Anwendungsgerechte Gestaltung
Eine
Analyse
der
Anwendungsszenarien
liefert
neben
den
erforderlichen
Funktionalitäten auch eine Vielzahl von nicht-funktionalen, qualitativen Anforderungen an ein System. Als leitender Aspekt der anwendungsgerechten Gestaltung sind die funktionalen und qualitativen Anforderungen zu sehen. Deren
Realisierung wirkt sich direkt auf die Nützlichkeit und Einsetzbarkeit eines Systems
aus (vgl. [Herczeg 2006]).
Ergonomie der Gestaltung
Für die Ergonomie der Gestaltung sind Kriterien erforderlich, die bewerten, wie gut
ein System an seine Nutzer angepasst ist. Diese Kriterien erfassen die Gebrauchstauglichkeit eines interaktiven Systems (vgl. [Herczeg 2006]). In DIN EN ISO 9241-11
[DIN 1997a] wurden hierfür die drei Kriterien definiert:
27

Effektivität

Effizienz

Zufriedenstellung
Die Effektivität bezieht sich auf die Reduktion des zeitlichen Aufwands, der zur
Lösung einer konkreten Aufgabe nötig ist. Die Effizienz wiederum beschreibt die
Höhe des Lernaufwands, der notwendig ist, um das System zu bedienen. Die
Erfüllung der Ansprüche des Nutzers durch die Software spiegelt sich in dessen
Zufriedenstellung wider (vgl. [Herczeg 2009]). Weitere Aspekte der SoftwareErgonomie wurden in anderen Abschnitten von DIN EN ISO 9241 formuliert.
Ästhetik der Gestaltung
Im Rahmen der Gestaltung interaktiver Systeme müssen neben anwendungsspezifischen und ergonomischen Aspekten auch ästhetische und emotionale
Aspekte berücksichtigt werden. Aufgrund der Tatsache, dass bei heutigen Systemen
die visuellen Eigenschaften im Vordergrund stehen, ist diesen bei der Gestaltung das
Hauptaugenmerk zu schenken. Jedoch müssen zukünftige Systeme alle Sinne
bedienen (vgl. [Herczeg 2006]).
Gestaltungskriterien für Widgets
DACHSELT zeigt vier Anforderungen für die Gestaltung von Widgets auf (vgl.
[Dachselt 2004]): Ein Widget muss durch die Geometrie und das Aussehen seine
Handhabung kommunizieren. Die Funktionalität muss eindeutig vermittelt werden.
Die Geometrie eines Widgets darf keine wichtigen Teile des zu manipulierenden
Objekts verdecken. Sie sollte so gewählt werden, dass sie aus allen Blickwinkeln
eindeutig erkennbar und identifizierbar ist. Der Nutzer soll während des gesamten
Manipulationsprozesses ständig Informationen über den Zustand des Widgets
erhalten. Die zu verändernden Freiheitsgrade müssen klar erkennbar und die
Aktionen unmittelbar sichtbar sein (WYSIWYG-Paradigma).
Durch eine Beschränkung der Freiheitsgrade wird die Aufgabenerfüllung erleichtert
(vgl. [Snibbe et al. 1992]). Ebenso sind Positionierungshilfen wie Raster beziehungsweise Linienzüge oder das Einrasten an bestimmten Positionen zum Beschränken
von Freiheitsgraden zu zählen (vgl. [Dachselt 2004]).
28
3.2 Navigation
Navigation ist eine Form der Interaktion und beschreibt im Umgang mit virtuellen
Welten zwei Fähigkeiten: Zum einen dient sie der Erkundung und Orientierung an
einem bestimmten Ort, zum anderen der Änderung der Betrachterposition, das
heißt sie beschreibt die Fähigkeit, sich fortzubewegen (vgl. [Fechter 1999]). Im
Folgenden werden verschiedene Formen der Navigation sowie Navigationsmetaphern erläutert.
Navigationsformen
Als Medium ist in diesem Sinne jeder Träger von Information anzusehen. Dazu
zählen sowohl jede Art von elektronischen Medien als auch Produkte mit
mechanischen Funktionen. Printmedien sind ebenfalls Informationsträger und
besitzen Formen der Navigation. Ein Inhaltsverzeichnis eines Buches ist eine
Navigationsstruktur, die durch Kapitelnamen und Seitenzahlen die Navigation durch
das Buch ermöglicht. Diese zunächst lineare Struktur besitzt durchaus nichtlinearen
Charakter. Querverweise in einem Text können als Sprungmarken für definierte
Stellen im Buch dienen. Dadurch ist die Navigationsstruktur eines Printmediums
nicht zwangsläufig linear.
Die Wahl der Navigationsform ist unabhängig vom Medium, vielmehr ist die Absicht
von Interesse, mit der ein Inhalt vermittelt wird beziehungsweise in welchem
Kontext dieser dargestellt wird. STAPELKAMP unterscheidet die Navigationsformen
daher nicht nach Medientypen, sondern nach den Kontexten, in denen sie verwendet werden.

direkte Manipulation

hierarchische Navigationssysteme

Site map

Image map

Anker-Navigation

Suche

alphabetische Index-Navigation

Guided tour

Geleitete beziehungsweise manipulierte Navigation

eigenwillige Navigation
Für die zu entwickelnden Konzepte sind die direkte Manipulation und die
hierarchischen Navigationssysteme von Bedeutung und werden im Folgenden näher
betrachtet.
29
Die direkte Manipulation ist die unmittelbarste Form der Navigation. Der Nutzer hat
die Möglichkeit, durch Maus und Tastatur die grafische Benutzeroberfläche direkt zu
beeinflussen. Die Einheit aus virtuellem Mauszeiger und physischer Maus ist der
verlängerte Arm in die virtuelle Welt. Je nach Anwendung und Werkzeug wird der
Mauszeiger als Zeiger, als Hand oder Stift dargestellt und repräsentiert auf diese
Weise das Werkzeug, welches der Nutzer mit der physischen Maus im Virtuellen
bedient. Basiselemente der direkten Manipulation sind nach STAPELKAMP die
Selektion, das Verschieben, die Rotation, das Scrollen und das Zoomen beziehungsweise Skalieren (vgl. [Stapelkamp 2007]).
Selektion
Als Selektion bezeichnet man die Auswahl eines oder mehrerer Elemente aus der
Menge aller auswählbaren Objekte einer Szene. Um erfolgreich mit diesen
Elementen einer 3D-Szene zu interagieren, ist die Selektion von Objekten
grundlegend. Erst durch eine Auswahl werden zu manipulierende Elemente
identifiziert (vgl. [Schwall 2004]). Die Auswahl muss nicht auf ein Gesamtobjekt
beschränkt sein, auch die Selektion von Objektelementen wie Flächen, Kanten,
Scheitelpunkten oder Objektteilgruppen ist möglich. Auf diese Art der partiellen
Auswahl wird in dieser Arbeit nicht weiter eingegangen, da sich Bildsprache LiveLab
als Präsentations- und Experimentierumgebung von Modellierungswerkzeugen
abgrenzt.
Drei verschiedene Gruppen von Selektionen lassen sich unterscheiden: diskrete,
lokale und entfernte. Die diskrete Selektion ist die Auswahl eines oder mehrerer
Objekte ohne direkten Kontakt mit den Objekten selbst (vgl. [Schwall 2004]). Diese
Methode erlaubt es, auch nicht sichtbare Objekte beispielsweise über eine Liste
auszuwählen (vgl. [Steinicke et al. 2004]). Dies ist vergleichbar mit der Listendarstellung des Szenengraphen in BiLL.
Mittels lokaler und entfernter Selektion wählt der Nutzer die Objekte direkt aus
seinem Arbeitsbereich aus. Der Unterschied zwischen beiden liegt in der Zugriffsart
auf die Objekte. Die lokale Selektion zeichnet sich durch die Auswahl der Objekte
über die Virtuelle-Hand-Metapher aus. Die entfernte Selektion, von DACHSELT auch
Distanzselektion
genannt,
erfolgt
über
Ray-Casting-Metaphern
oder
Cone-
Metaphern (vgl. [Schwall 2004]; [Dachselt 2004]).
Verschieben (Translation)
Das Positionieren eines Objekts beziehungsweise eines Werkzeugs entlang einer
oder mehrerer Raumachsen wird Verschieben genannt. Dabei wird unterschieden,
ob die Verschiebung entlang der Raumachsen oder entlang einer Fläche,
aufgespannt durch zwei Raumachsen, oder entlang eines beliebigen Vektors
beziehungsweise einer beliebigen Fläche im Raum vollzogen wird. Je nach
30
Anwendungsfall ist eine Einschränkung der Verschiebung möglich. Die Einschränkungen reichen von Kollisionsdetektion mit anderen Objekten bis hin zum
Begrenzen von Verschiebungsachsen.
Weiterhin erfolgt die Translation diskret oder kontinuierlich. Während die
kontinuierliche Verschiebung eine freie Positionierung zulässt, wird durch diskrete
Translation das Objekt in definierten Schritten verschoben oder an vordefinierte
Positionen versetzt (vgl. [Schwall 2004]).
Drehung (Rotation)
Die Rotation eines Objekts oder eines Werkzeugs um die Raumachsen oder die
Kombination von Rotationen um diese Achsen bezeichnet die Änderung der
Ausrichtung eines oder mehrerer Objekte. Durch die Kombination von Rotationen
um verschiedene Raumachsen ist jede Ausrichtung eines Objekts oder der virtuellen
Kamera möglich. Ähnlich der Translation sind auch beim Rotieren kontinuierliche
sowie diskrete Drehungen ausführbar.
Jede Rotation erfolgt um ein Rotationszentrum, um das ein Objekt gedreht wird. In
der Praxis findet sich die objektzentrierte Rotation am häufigsten wieder, aber auch
ein außerhalb des Objektzentrums liegendes Rotationszentrum ist umsetzbar (vgl.
[Schwall 2004]).
Skalierung
Der Begriff der Skalierung beschreibt die relative Größenveränderung eines Objekts.
Diese vollzieht sich entweder simultan in allen drei Raumachsen gleich oder selektiv
entlang einer oder zwei Raumachsen. Skaliert werden die Objekte um ein Zentrum
herum. Liegt dieser Punkt im Zentrum des Objekts, verändert sich seine Position
während der Skalierung nicht. Liegt er außerhalb des Objektmittelpunkts, verschiebt
sich das Objekt relativ zur Ausgangsposition (vgl. [Schwall 2004]).
Als Spezialfall der Skalierung ist der Zoom zu erwähnen, er stellt die Skalierung der
Abbildungsfläche dar, die alle abgebildeten Objekte gleichermaßen vergrößert oder
verkleinert. Durch das Zoomen wird dem Nutzer die Illusion vermittelt, dass er sich in
eine Szene hinein beziehungsweise aus ihr heraus bewegt (vgl. [Stapelkamp 2007]).
Räumliche Navigationsmetaphern
Wie alle Interaktionsformen unterliegt auch die Navigation einer Metapher. Hierzu
wurden verschiedene Ideen der Bewegung in dreidimensionalen Umgebungen
aufgegriffen und bereits in vielen Anwendungen implementiert. GROH differenziert
zwei Betrachtersituationen: die Feldherren-Metapher und die Wanderer-Metapher
(vgl. [Groh 2005]).
31
Die Feldherren-Metapher verbildlicht das Auftauchen (Emersion) des Nutzers über
einer Szenerie. Sie dient der Planung der nächsten Aufgabe und vermittelt ein
Überblickswissen über die Szene. Konträr dazu stellt die Wanderer-Metapher das
Eintauchen (Immersion) des Nutzers in die Szene dar, dieser findet sich inmitten der
Szene wieder und erkundet diese aus dieser Position.
Vier wesentliche Navigationsmetaphern unterscheidet WARE in virtuellen Welten:
die
World-in-hand-Metapher,
die
Eyeball-in-hand-Metapher,
die
Wanderer-
Metapher und die Flug-Metapher. Die von GROH genannten Betrachtersituationen
bezüglich der Immersion und Emersion spiegeln sich darin wider. Im Folgenden
werden die einzelnen Navigationsmetaphern genauer betrachtet und anhand von
Anwendungsszenarien erläutert.
World-in-hand Metapher
Das Auge des Nutzers befindet sich an einem festen Punkt, während er Teile der
Szene greift und sie somit relativ zu seinem Blickpunkt bewegt. Der Nutzer hat ein
abstraktes Modell der Szene als Steuereinheit in seinen Händen und dreht und
verschiebt dieses durch Bewegen der Hand (vgl. [Ware 2009]).
Die World-in-hand-Metapher eignet sich besonders gut für Szenen, die einzelne und
kompakte Objekte darstellen. Objekte sind intuitiv bewegbar. Für die Navigation ist
ein spezielles Steuerelement zur Bestimmung der Neigung und Position der Hand
notwendig. Die Betrachtersituation ist in diesem Fall die Feldherren-Sicht, da der
Nutzer eine Draufsicht auf die dargestellten Objekte hat.
Abbildung 3.3: Navigationssteuerung World-in-hand-Controller (nach WARE) (links); virtuelle Szene
mit korrespondierenden Freiheitsgraden zur Steuerung der Szene (rechts)
Eyeball-in-hand Metapher
Der World-in-hand-Metapher steht die Eyeball-in-hand-Metapher gegenüber. Der
Nutzer hat hierbei die Kontrolle über die virtuelle Kamera, welche die Szene
abbildet, indem er die Kamera relativ zur Szene bewegt (vgl. Abbildung 3.4). Dies ist
32
nach WARE und OSBORNE die effektivste Methode, um den Blickpunkt zu
verändern (vgl. [Ware 2009]). Diese Navigationsmetapher ist vorteilhaft für freie
Explorationen von großen 3D-Szenen. Auch die Eyeball-in-hand-Metapher stellt eine
Form der Feldherren-Sicht auf die Szene dar.
Abbildung 3.4: Navigationssteuerung Eyeball-in-hand-Controller (nach Ware) (links); virtuelle Szene
und korrespondierende Freiheitsgrade an der Kamera (rechts)
Die Wanderer-Metapher
Einen ganz anderen Ansatz verfolgt dagegen die Wanderer-Metapher, die es den
Individuen in einer virtuellen Welt gestattet, sich durch Gehen in dieser
fortzubewegen. Entweder wird dies durch bekannte Eingabegeräte wie Maus und
Tastatur abstrahiert oder der Anwender führt tatsächlich eine Gehbewegung aus.
Abbildung 3.5:
Die Wanderer-Metapher – Laufband als Eingabegerät (links); Sicht des Nutzers in die
virtuelle Welt (rechts)
Jedoch setzt dem die reale Welt Grenzen in Form von Gebäudemauern. Verschiedene Versuche wurden unternommen, um diese Beschränkung zu überwinden.
Beispielsweise können Sportgeräte wie der Stepper die Gehbewegungen des laufenden Anwenders in die virtuelle Welt übertragen.
33
Eine weitere Entwicklung wurde in Zusammenarbeit mit dem Max-Planck-Institut für
Biologische Kybernetik in Tübingen, der TU München, der University of Rome und
der ETH Zürich gemacht (vgl. [Max-Planck-Gesellschaft 2005]). Der sogenannte
CyberWalk ist eine Maschine aus mehreren Laufbändern, die auf einer Art überdimensionierter Kette einer Planierraupe angebracht sind. Ein Positionsbestimmungssystem richtet die Laufbänder so aus, dass der darauf Laufende sich zu
jedem Zeitpunkt mittig befindet und nicht über den Rand hinaus läuft. Jede
Änderung der Position im Realen wird ins Virtuelle übertragen.
Der Nutzer dieses Geräts trägt ein am Kopf angebrachtes Bildschirmsystem, das ihm
die Sicht in die virtuelle Welt ermöglicht. Dieses System ist für eine einzelne Person
konzipiert und ermöglicht Rundgänge in virtuellen Welten ohne physische Beschränkungen der realen Welt.
Abbildung 3.6:
CyberWalk-Skizze nach [Max-Planck-Gesellschaft 2005]
Die Flug Metapher
Besonders
in
Terrain-Visualisierungen
haben
sich
sogenannte
Fly-through-
Navigationsformen etabliert. Diese ermöglichen eine flugähnliche Fortbewegung
durch die Szene. Dabei kann der Flug einem Hubschrauber oder einem Flugzeug
nachempfunden sein. Als Eingabegerät für eine derartige Steuerung ist ein Joystick
geeignet, da dieser der Steuereinheit eines Fluggeräts ähnelt.
Jede der vorgestellten Navigationsmetaphern ist abhängig vom jeweiligen
Anwendungsfall und dem Aufgabenbereich des Systems. Dementsprechend sind die
jeweiligen Metaphern an die Navigationsaufgaben Erkunden, Suchen und
Manövrieren anzupassen (vgl. [Bowman et al. 2001]).
Beim Erkunden einer Szene verschafft sich der Nutzer nur einen Überblick über die
gesamte Szene und ihre Merkmale. Beim Suchen hingegen möchte er an eine
bestimmte Position navigieren. Letztendlich stellt das Manövrieren eine präzise
34
Navigation über kurze Entfernungen dar, um eine geeignete Sicht auf etwas zu
erreichen und spezielle Aufgaben von hier aus auszuüben (vgl. [Bowman et al.
2001]).
3.3 Manipulation
Die Veränderung von Objekten, deren Darstellung und Parametern umfasst der
Begriff der Manipulation. Je nach Objekttyp sind unterschiedliche Eigenschaften
veränderbar (vgl. [Schwall 2004]). Diese Veränderungen werden entweder direkt am
Objekt vollzogen oder über Menü-Elemente. Für direkte Objektveränderungen
werden 3D-Widgets eingesetzt, um die Steuerung der Manipulation zu vereinfachen
(vgl. [Dachselt 2004]).
Manipulationen im Kontext von BiLL lassen sich anhand der Klassifikation von 3DWidgets nach DACHSELT in drei Bereiche gliedern, die in dieser Arbeit als relevant
erachtet werden (vgl. [Dachselt 2004]). Diese drei Bereiche umfassen die Steuerung
der Szenenrepräsentation, die geometrischen Manipulationen von Objekten sowie
die Orientierung und Navigation in der Szene. In der folgenden Tabelle sind für die
einzelnen Bereiche Beispiele aufgeführt, wie sie in der Forschungsumgebung BiLL zu
finden sind.
Steuerung der
Szenenrepräsentation
Geometrische
Manipulation
Orientierung und
Navigation
Lichtmanipulation
Scherung
Zoom
Kameramanipulation
Translation
Schwenk / Neigen
Soundsteuerung
Rotation
Öffnungswinkel
Skalierung
Tabelle 3.1:
Bereiche von Manipulationen
Zur Steuerung der Szenenrepräsentation gehören die Änderungen der Beleuchtungsverhältnisse, die Modifikation von Soundquellen und bereichsübergreifend
auch die Manipulation der Kamera, wobei die einzelnen veränderbaren Parameter
des Kamerasystems zur Kategorie der Orientierung und Navigation gehören.
Das Zoomen der virtuellen Kamera ist entweder bildstruktureller oder technischer
Natur. Die Veränderung des Öffnungswinkels bewirkt einen Zoom, ebenso wie das
Verschieben der Kamera nach vorn oder hinten entlang der optischen Achse.
Als geometrische Manipulationen sind objektverändernde Methoden wie die
Scherung, die Translation, die Rotation oder die Skalierung zu nennen. Das
35
Hauptaugenmerk dieser Arbeit bezieht sich auf die Realisierung der direkten
geometrischen Manipulationen und der Kamerasteuerung. Dies wird in der
folgenden Synthese genauer analysiert.
3.4 Zusammenfassung
In diesem Kapitel wurden Arbeiten aus dem Bereich Interaktion beziehungsweise
Navigation und Manipulation vorgestellt. Im anschließenden Syntheseteil der Arbeit
werden
verschiedene
Gestaltungskriterien
Orientierungshilfen
analysiert
und
und
beurteilt.
3D-Widgets
Anhand
der
auf
Basis
der
Methoden
der
Interaktionsgestaltung von VERPLANK und COOPER wird im fünften Kapitel das
Interaktionskonzept für Bildsprache LiveLab entwickelt und dessen Implementierung
erläutert.
Zur exemplarischen Darstellung der Verwendung der entwickelten ServiceSchnittstelle wird ein bestehendes Plug-in zur Steuerung der Beleuchtung erweitert.
Hierbei werden geometrische Manipulationen zur Anwendung kommen, um die
Positionierung und Ausrichtung von Lichtquellen in der Szene vorzunehmen.
36
4 Synthese
In diesem Kapitel werden verschiedene Orientierungshilfen, Menü-Varianten und
3D-Widgets auf ihre Nutzbarkeit zur Umsetzung der im ersten Kapitel vorgestellten
Zielstellung hin analysiert. Dabei werden zunächst die Orientierungshilfen
vergleichend untersucht. Sie werden anhand ihrer Vorteile und Nachteile bezüglich
der Anwendbarkeit in der Forschungsumgebung Bildsprache LiveLab ausgewählt.
Weiterhin werden verschiedene Manipulations-Widgets in dreidimensionalen
Räumen analysiert und auf ihre Umsetzbarkeit und Nutzbarkeit für BiLL beurteilt.
Vergleichend werden bereits existierende Menü-Varianten untersucht und deren
Gebrauchstauglichkeit zur Umsetzung der Zielstellung ermittelt. Die Resultate der
theoretischen Untersuchungen der folgenden Abschnitte dienen als Grundlage für
den konzeptionellen Entwurf und die praktische Realisierung.
4.1 Vergleich verschiedener
Orientierungshilfen
Bereits auf zweidimensionalen Interaktionsflächen wie Landkarten oder Büchern
wurden Orientierungshilfen entwickelt. Auf Landkarten dient zum Beispiel eine
Windrose zum Einnorden mit einem Kompass. Das Inhaltsverzeichnis von Büchern
zeigt dem Leser, wo er sich gerade befindet oder auf welcher Seite ein einzelnes
Kapitel beginnt. Die Entwicklung von Orientierungshilfen findet auch in
dreidimensionalen virtuellen Umgebungen statt. Insbesondere die Darstellung
abstrakter Informationsräume erfordert eine effektive Orientierung, was wiederum
die Effizienz der Interaktion in diesen Räumen maßgeblich erhöht.
Verschiedene Hilfen zur Verbesserung der Orientierung werden im Folgenden
einzeln untersucht und anschließend unter dem Gesichtspunkt der Zielstellung
dieser Arbeit miteinander verglichen.
Minimap
In 3D-Computerspielen haben sich zur Orientierung verkleinerte Draufsichten auf
die Spielumgebung, sogenannte Minimaps, durchgesetzt (Abbildung 4.1). Darauf ist
entweder die nähere Umgebung oder das gesamte Gebiet in verkleinerter Draufsicht
abgebildet. Meist befinden sich darauf Indikatoren für die Spielerposition sowie ein
Nordpfeil zur Ausrichtung der Karte. Ihre Ausprägungen sind je nach Spielgenre
unterschiedlich.
37
SYNTHESE
Abbildung 4.1: Minimap von World of Warcraft [Blizzard entertainment 2009] (links), Minimap von
Age of Empires 3 [Microsoft 2005] (mitte), Minimap von Caesar IV [HeavenGames LLC
2009] (rechts)
Vorwiegend werden Minimaps zur Repräsentation von flächigen Umgebungen
genutzt. Mehrstufige Gebiete wie Gebäude werden etagenweise abgebildet.
Geschichtete Gebiete lassen sich nur bedingt auf einer Minimap darstellen. Die
Minimap ist für räumliche Umgebungen mit mehreren Ebenen nicht geeignet, da
sich dann Teile beziehungsweise Ebenen in der Karte gegenseitig verdecken.
Koordinatenkreuz
In 3D-Modellierungswerkzeugen wie Autodesk 3ds Max oder Autodesk Maya
werden Koordinatenkreuze zur Identifikation der Ausrichtung genutzt (Abbildung
4.2). Ein kleines Koordinatenkreuz, bestehend aus den drei Raumachsen X, Y und Z,
wie in Abbildung 4.2 am linken unteren Bildschirmrand zu sehen, zeigt die Lage des
Koordinatenursprungs relativ zur Betrachterposition.
Dies ist eine sehr abstrakte Darstellung und erfordert eine genaue Kenntnis der
dargestellten Szene und der Funktionsweise des Koordinatensystems. Der Nutzer
erhält über das Koordinatenkreuz keine Information bezüglich der eigenen Position
innerhalb der Szene. Je nach Anwendung ändern sich die Achsen für die Tiefe (zAchse) beziehungsweise die Höhe (y-Achse).
Die Abbildung eines Koordinatenkreuzes findet sich auch direkt in Objekten wieder.
Hierbei beschreibt das Koordinatenkreuz die Ausrichtung des Objekts relativ zum
Koordinatensystem der Szene.
38
SYNTHESE
Abbildung 4.2:
Koordinatenkreuz in der Anwendung Autodesk® 3ds Max®
Raster
Eine Methode zur Strukturierung von Flächen und Räumen ist deren Unterteilung in
gleich große Segmente. Diese Segmentierung ist sowohl für flächige als auch für
räumliche Darstellungen geeignet. In Abbildung 4.2 ist ein Raster auf der xy-Ebene
zu sehen. Anhand dieses Rasters erhält man eine Referenz bezüglich der Längen
und Distanzen. Dies erlaubt die Abschätzung der räumlichen Relationen zwischen
Objekten.
Räumliche Raster unterteilen einen dreidimensionalen Raum in kleine räumliche
Segmente. Diese können „je nach Raumcharakter, eine kubische, eine zylindrische
oder […] eine sphärische Struktur besitzen“ [Groh 2005, S. 173] (Abbildung 4.4,
Abbildung 4.5). Räumliche Raster mit einer sehr dichten Rasterweite verdecken in
bestimmten Betrachtersituationen die eigentliche 3D-Szene oder sind der
Orientierung nicht dienlich (vgl. [Stork 2000]). Der Aspekt der Anpassbarkeit der
Rasterweite wird dadurch ein entscheidender Punkt beim Einsatz dieser Methode als
Orientierungshilfe.
Ein sphärisches Raster wird beispielsweise auf der Erdkugel verwendet. Die
Unterteilung erfolgt hierbei durch Längen- und Breitengrade. Zylindrische Raster
eignen sich zum Beispiel für Tunneldarstellungen. Kubische Raster finden sich in
Anwendungen zur Darstellung der räumlichen Anordnung von Atomen in Kristallstrukturen wieder.
39
SYNTHESEE
Abbildung 4.3:
4 Kubischess Raster zur Daarstellung von Kristallstruktur
K
ren [Semicondu
uctor Applet Service
(SAS)
(
2009]
A
Abbildung
4.4:
Zylindrischees Raster (linkss), kubisches Raaster von innen
n (rechts)
Abbild
dung 4.5: Sph
härisches Rasteer von außen (links), sphärisches Raster von
n innen (rechts)
40
SYNTHESE
ViewCube, ViewSphere und 3D-Kompass
Autodesk stellt mit dem sogenannten ViewCube ein 3D-Widget vor (vgl.
[Azam Khan 2008], Abbildung 4.6 (links)), das die aktuelle Blickrichtung der Kamera
wiedergibt und aus selektierbaren Elementen besteht, die wiederum vordefinierte
Kamerapositionen repräsentieren. Durch das Auswählen eines Elements mit einem
Eingabegerät wird die Kamera an diese vordefinierte Position verschoben und zum
Zentrum der Szene ausgerichtet.
Ein ähnliches 3D-Widget namens ViewSphere wurde von BRUNNETT entwickelt.
„Sein Funktionsprinzip besteht darin, dass ein die Gesamtwelt
repräsentierendes Objekt in einem separaten Fenster immer aus der
Richtung gerendert und dargestellt wird, die der aktuellen Blickrichtung
des Avatars in der virtuellen Welt entspricht“ [Brunnett et al. 2000, S. 7].
Beide Konzepte ähneln sich im Verhalten, unterscheiden sich hingegen in den Interaktionsmöglichkeiten und der Eingliederung in die dargestellte Szene. Durch das
Markieren eines Punktes auf der Oberfläche der ViewSphere wird ein zum Mittelpunkt des Objekts zeigender Vektor definiert, der die aktuelle Blickrichtung in die
Szene bestimmt.
Abbildung 4.6:
Verschiedene
Autodesk ViewCube (links) [Azam Khan 2008], 3D-Kompass (Mitte) [Brunnett et al.
2000], ViewSphere (rechts) [Brunnett et al. 2000]
Abstraktionsstufen
des
ViewCube
sind
für
unterschiedliche
Nutzertypen geeignet. Für erfahrene Nutzer genügt die Darstellung des Würfels mit
beschrifteten Seitenflächen (Abbildung 4.7). Die Abbildung von 2D-Ansichten auf
den Flächen des Würfels ist für weniger erfahrene Anwender geeignet (Abbildung
4.7). Ein 3D-Modell innerhalb des Würfels und transparente Außenseiten erhöhen
den Wiedererkennungswert für Anfänger (vgl. [Azam Khan 2008]) (Abbildung 4.7).
41
SYNTHESE
Abbildung 4.7: ViewCube mit Beschriftung (1), mit Bildern (2), mit 3D-Modell (3),
ohne Beschriftung (4) [Azam Khan 2008]
World-in-Miniature
STOAKLEY stellt als Orientierungsunterstützung die sogenannte World-in-Miniature
(WIM) vor (vgl. [Stoakley et al. 1995], Abbildung 4.8). Die gesamte dreidimensionale
Szene wird als Miniaturansicht in das Betrachtungsfenster über die aktuelle Sicht
eingeblendet. Dadurch erhält der Nutzer ein Feedback über seine derzeitige
Betrachtungsposition in der abgebildeten virtuellen Welt. Die Miniaturansicht ist
entweder entlang der Sicht des Betrachters ausgerichtet oder unterliegt einer vordefinierten Sicht.
Eine Weiterentwicklung der WIM stellt die Scaled and scrolling WIM (SSWIM) dar
[Wingrave et al. 2006]. Die feste Größe der WIM zeigt zwar die ganze Szene als
Miniatur, aber die verschiedenen Detailstufen, die während der Interaktion und
Navigation in 3D-Szenen notwendig sind, erfordern eine detailliertere Sicht auf die
Szene. Durch Zoomen und Scrollen kann der Nutzer einen beliebigen Ausschnitt der
WIM-Darstellung erstellen. Dadurch wird die WIM für die unterschiedlichen Aufgaben eines Nutzers individualisierbar.
42
SYNTHESE
Abbildung 4.8: World-in-Miniature [Stoakley et al. 1995]
Die vorgestellten Orientierungshilfen unterscheiden sich in verschiedenen Merkmalen, zum Beispiel ihrer Größe, Position, der Verdeckung anderer Elemente und
dem Interaktionspotenzial.
Aus der Zielstellung dieser Arbeit leiten sich Kriterien und Merkmale zur Bewertung
der Nutzbarkeit für die Umsetzung ab. Der Abstraktionsgrad ist für die Performance,
für die Erkennbarkeit und die Einheitlichkeit der Orientierungshilfe von Bedeutung.
Die Anzahl der Dimensionen, die von der jeweiligen Orientierungshilfe abgebildet
werden, ist maßgebend für die Integration in eine dreidimensionale Umgebung. Die
Interaktivität identifiziert, inwiefern der Anwender mit der Orientierungshilfe selbst
Einfluss auf die Betrachterposition nimmt, das heißt seine Orientierung individuell
steuert. Anhand der Lesbarkeit wird die Eindeutigkeit und Erkennbarkeit der
Orientierungshilfe unter den Rahmenbedingungen der verschiedenen Bildschirmauflösungen, der Fenstergrößen des Viewer-Fensters und den Szenenausmaßen
ermittelt.
43
SYNTHESE
Abstraktionsgrad
Dimensionalität
Interaktivität
Intuitive Lesbarkeit
WIM
niedrig
3D
niedrig
mittel
SSWIM
niedrig
3D
hoch
gut
hoch
3D
hoch
gut
Minimap
mittel
2D
mittel
gut
Raster
hoch
2D / 3D
niedrig
in 2D gut, in 3D mittel
hoch
3D
niedrig
ViewCube
3D-Kompass
Koordinatenkreu
z
Tabelle 4.1:
gut, mit
Referenzsystem
Kriterien zur Bewertung der Orientierungshilfen im Kontext der Zielstellung
Anhand des hohen Abstraktionsgrads des ViewCube ist dieser unabhängig von der
abgebildeten 3D-Szene für unterschiedliche Szenarien einsetzbar. Das Konzept der
World-in-Miniature ist nur bedingt für den Einsatz in der Forschungsumgebung BiLL
geeignet. Bei 3D-Szenen mit einem sehr großen Ausmaß wirkt die miniaturisierte
Abbildung sehr unübersichtlich und Rückschlüsse auf die eigene Betrachterposition
sind nur bedingt möglich. Der Abstraktionsgrad ist in diesem Fall sehr niedrig, da die
dargestellte Szene identisch mit der verkleinerten Darstellung ist.
Die Minimap ist für die Umsetzung der Orientierungshilfe in BiLL ungeeignet, da sie
ohne Nachbearbeitung ebenfalls nur einen geringen Abstraktionsgrad besitzt. Die
dargestellte Szene würde von einer Draufsicht aus betrachtet und Objekte, die näher
zur Kamera dieser Sicht sind, verdecken fernere Objekte.
Im Vergleich zu den anderen Konzepten repräsentiert die Minimap die 3D-Szene als
zweidimensionales Abbild in Form einer Draufsicht. Dies gibt einen Überblick über
die Szene und die eigene Position in der Szene. Ein Rückschluss auf die Blickrichtung
ist nur in zwei Dimensionen gegeben. Die anderen Konzepte können hingegen
mehrere Ansichten darstellen und bieten daher ein breiteres Spektrum an Möglichkeiten.
Der Grad der Interaktivität ist beim ViewCube aufgrund der Interaktionsflächen sehr
hoch. Ebenso ist das Konzept der SSWIM durch das Zoomen und Scrollen zur
Sichtanpassung durch eine hohe Interaktivität gekennzeichnet. Eingeschränktere
Interaktionsmöglichkeiten bietet die Minimap. Der Anwender hat damit lediglich
Einfluss auf den dargestellten Ausschnitt und ggf. vordefinierte Landmarken zum
Ansteuern. Das Raster dient lediglich zur Orientierung und unterstützt die
Navigation nur passiv. Das Raster kann bei der Positionierung von Objekten unterstützend und führend wirken.
44
SYNTHESE
Die intuitive Lesbarkeit beziehungsweise Erkennbarkeit ist von den technischen
Möglichkeiten beziehungsweise Gegebenheiten abhängig und wird daher nur
beiläufig betrachtet. Dem WIM-Konzept wurde eine mittlere Lesbarkeit attestiert, da
es durch die Größe, die es auf dem Bildschirm einnimmt, den Rest der 3D-Szene
verdeckt. Die Positionierung des WIM neben die Szene verkleinert wiederum den
Darstellungsbereich der 3D-Szene. Das SSWIM-Konzept löst die Defizite des WIMKonzepts durch Zoomen und Scrollen, dadurch sind Detailansichten bestimmter
Bereiche auch im SSWIM möglich.
Die Lesbarkeit der Minimap ist gut, da dieses Verfahren dem Kartenlesen aus der
Realität nachempfunden ist und dadurch einen Bezug zu dieser herstellt.
Verschiedene Zoomstufen der Minimap unterstützen die Lesbarkeit und die Betrachtung von bestimmten Regionen der abgebildeten Szene ist möglich.
Beim Konzept des ViewCube wurde die Lesbarkeit ebenfalls als gut identifiziert, da
die Beschriftung der einzelnen Seiten eine eindeutige Zuordnung ermöglicht und bei
niedrigen Auflösungen des Viewer-Fensters dennoch lesbar ist. Die intuitiven
Rückschlüsse auf die Betrachtungsrichtung sind durch die bekannte Würfelform und
die beschrifteten Seiten eindeutig.
Ein flächiges Raster ist auch in räumlichen Umgebungen greifbar und verstärkt
durch die Fluchten von parallelen Linien den Tiefeneindruck. Die Nutzung von 3DRastern ist nur bedingt sinnvoll, da diese die Szene durch eine geringe Rasterweite
unnötigerweise verdecken. In frontalen Ansichten sind sie nicht mehr als 3D-Raster
erkennbar, sondern reduzieren sich auf ein 2D-Raster. Die Dreidimensionalität eines
3D-Rasters wird erst durch die Bewegung des Rasters beziehungsweise durch eine
Drehung um das Raster herum erkennbar.
Die Orientierungshilfen unterscheiden sich ebenfalls in der Positionierung und dem
Informationsgewinn, den sie mit sich führen (vgl. [Henzen 2009]). Die folgende
Tabelle gibt Aufschluss über die Positionierung, ob direkt im Objekt, über der Szene
oder als eigenständiges Element neben der Szene. Welche Informationen über die
Szene, die Objekte und den eigenen Standpunkt lassen sich von ihnen ablesen?
45
SYNTHESEE
Positio
onierung
im Objekt
üb
ber der
S
Szene
Inform
mation
extern
Richtung
Posittion
WIM
x
x
x
SSWIM
x
x
x
ViewCube
3D-Kompasss
x
x
Minimap
x
x
Raster
x
Koordinatenkreuz
x
Tabelle 4.2:
Absttand
x
x
x
x
x
x
Posittionierung und
d Informationen bezüglich Richtung, Positio
on und Abstan
nd
Zusammen
nfassend zeeigt sich, dass
d
alle Konzepte
K
fü
ür BiLL den
nkbar wäre
en. In
Anbetrach
ht des Konteextes und der
d Nutzung
g, die mit BiLL
B
angestrrebt wird, isst das
Konzept des
d ViewCub
be im Vergleich zu den anderen Konzepten zweckdienlicher.
Somit wird
d dieser fürr die Nutzun
ng und Auffgaben inneerhalb der A
Arbeitsumge
ebung
BiLL adapttiert und im
mplementierrt. Die Konzeption und
d Implemen
ntierung wird im
fünften Kaapitel detailliert erläuterrt.
4.2 Differen
nzierun
ng derr Menü
ü-Varia
anten
Um eine geeignete
g
M
Menü-Varian
nte für das Interaktionsskonzept zu
u finden, we
erden
die bereitss in 2.3 vorg
gestellten Menütypen
M
auf
a ihre Nuttzbarkeit im
m Hinblick au
uf die
Zielstellung
g des Kon
nzepts unteersucht. Zunächst werrden die eeinzelnen MenüM
Varianten beispielhaftt aufgeführt und ihre Ch
harakteristikka erläutert.
Ab
bbildung 4.9: Menü-Hinterg
grund-Integrattion (links); Karrteikarten-Regiister (rechts)
46
SYNTHESE
Ab
bbildung 4.10:: Pull-down-M
Menü (links); Drop-down-Me
D
enü (rechts)
Abbildun
ng 4.11: Menü als Bestandtteil der Erzählfo
orm (links); Rad
dial-Menü (recchts)
Um zu entscheeiden, welch
hes Menü sich zur Umsetzung
U
des Konzep
pts eignet,
den verschieedene Kriterrien zur Beu
urteilung au
ufgestellt. Vo
on vornhereein können
werd
die Menü-Varian
M
nten Menü--Hintergrund-Integratio
on und Men
nü als Bestaandteil der
Erzäh
hlform zur Realisierung
g des Interaaktionskonze
epts ausgesschlossen w
werden. Die
erste Variante eignet sich faast ausschlieeßlich für flä
ächige Interaaktionsoberfflächen. Da
diesees Menü in
n den Hinttergrund in
ntegriert ist, ist der Einsatz
E
in räumlichen
Umgebungen nicht geeigneet.
Die Variante,
V
daas Menü alss Bestandteil der Erzähllform zu inttegrieren, isst beispielsweisee bei gefüh
hrten Touren beziehungsweise bei einer geleeiteten Navigation von
Vorteeil. Dadurch
h wird die eigentliche Navigation durch texttuelle Elemeente unterstützt. Die Zielsteellung dieser Arbeit sieh
ht dies nichtt vor.
47
SYNTHESE
Navigationswege
kurz
mittel
Elementanzahl
lang
1-10
x
Radial-Menü
Repräsentation
10+
textuell
grafisch
x
x
x
Pull-down
x
x
x
Drop-down
x
x
x
x
x
x
Karteikarten-Register
Tabelle 4.3:
Kriterien zur Beurteilung der Menü-Varianten
Die Länge der Navigationswege, die der Nutzer mit dem Mauszeiger oder einem
anderen Eingabegerät, im Fall eines Multi-touch-Displays die Hand des Nutzers,
zurücklegen muss, um seine Aufgabe effektiv zu erledigen, ist von entscheidender
Bedeutung für die Gestaltung von Benutzeroberflächen. Ein Radial-Menü ordnet alle
Elemente im gleichen Abstand um den Mittelpunkt eines Kreises an. Dies bewirkt,
dass die Wege zwischen dem Punkt des Aufrufs und den Elementen gleich sind.
Durch die kompakte Form sind diese Wege zudem auch kurz, was Vorteile für den
Einsatz im Multi-touch-Bereich bietet (vgl. [Callahan et al. 1988]).
Die Navigationswege beim Pull-down- und beim Drop-down-Menü sind unterschiedlich lang und erhöhen sich mit der Anzahl der Elemente, die im Menü
angeordnet sind. Das Karteikarten-Register bietet auf kompakte Art und Weise
Zugang zu den Menü-Elementen, jedoch sind die Navigationswege durch die feste
Position des Menüs lang. Die Anzahl der Elemente, die ein Radial-Menü beinhalten
kann, ist durch die Anordnung beschränkt. Eine Lösung hierfür ist eine hierarchische
Gliederung der Elemente.
Anordnung
Position
hierarchisch
heterarchisch
dynamis
ch
Radial-Menü
x
x
x
Pull-down
x
x
x
Drop-down
x
x
x
KarteikartenRegister
Tabelle 4.4:
x
fest
x
Anordnung der Elemente und Position des Menüs
Eine geringe Anzahl an Menü-Elementen trägt zur Übersichtlichkeit und schnellen
Erfassung der abgebildeten Elemente bei. Ein Pull-down-Menü kann wesentlich
mehr Elemente aufnehmen, die Zeit zum Auffinden von Menü-Elementen steigt
ebenfalls. Das Gleiche gilt für das Karteikarten-Register. Eine hierarchische Menü48
SYNTHESE
Struktur wird vom Radial-Menü, vom Pull-down- und vom Drop-down-Menü
unterstützt. Das Karteikarten-Register bietet diese Möglichkeit nicht.
Die einzelnen Elemente innerhalb eines Menüs können entweder durch reinen Text
oder Bilder repräsentiert werden oder durch eine Kombination aus beiden. Das
Radial-Menü eignet sich, um beides darzustellen. Die anderen Menü-Varianten
repräsentieren die Menü-Elemente meist nur textuell. Die Position, an der das Menü
eingeblendet wird, ist das letzte Kriterium bei der Analyse der verschiedenen MenüVarianten. Entweder wird das Menü kontextbezogen eingeblendet oder es ist dauerhaft fest an einer Position verankert.
Nach der Analyse der Menü-Varianten anhand der beschriebenen Kriterien zeichnet
sich das Radial-Menü als geeignete Variante zur Umsetzung des Interaktionskonzepts ab. Es ermöglicht die grafische sowie textuelle Präsentation, die
hierarchische Ordnung von Menü-Elementen und bewirkt ein schnelles Arbeiten
durch kurze Interaktionswege. Ein weiterer, bisher noch nicht untersuchter positiver
Punkt bei der Verwendung eines Radial-Menüs ist seine kontextbezogene
Aktivierung beziehungsweise Einblendung. Dabei werden die Hintergrundelemente
nur für den Zeitraum der Aktivierung des Menüs verdeckt. Gleichzeitig erhöht dies
den Fokus auf das Menü.
4.3 Analyse vorhandener 3D-Widgets
Zur Analyse der vorhandenen 3D-Widgets wird ein für diese Arbeit wichtiger Teil
genauer untersucht. Eine sehr umfangreiche Kategorisierung und Untersuchung von
Widgets wurde bereits von DACHSELT vorgenommen (vgl. [Dachselt 2004]). Anhand
dieser werden die zu untersuchenden Widgets ausgewählt, die für die Umsetzung
der Interaktionskomponente notwendig sind. Die wesentlichen Widgets gliedern
sich in die Kategorien der direkten 3D-Objektinteraktion, der Manipulation der 3DSzene und der Anwendungskontrolle.
Direkte 3D-Objektinteraktion
Darunter zählen alle Verfahren, die eine direkte Manipulation an Objekten einer 3DSzene
vornehmen
(vgl.
[Dachselt
2004]).
Dazu
gehören
selektive
sowie
objektgeometrieverändernde Verfahren, die mittels eines Hilfsobjekts (gizmo)
arbeiten. Bereits etablierte Widgets sind das Rotations-, das Skalierungs- und das
Verschiebungs-Widget.
Diese finden sich in Modellierungswerkzeugen wie Autodesk 3ds Max, Maya,
Maxon Cinema4D und Blender. Derartige Widgets helfen dem Anwender bei der
Interaktion mit Objekten in einer 3D-Szene, indem sie ein Hilfsobjekt repräsentieren,
welches als Mittler zwischen den 2D-Interaktionen des Eingabegeräts und der
Manipulation am 3D-Objekt dient. Dadurch werden komplexe Objekte auf ein
49
SYNTHESE
einfaches Hilfsobjekt reduziert, mit dem der Nutzer interagiert. Die Änderungen am
Hilfsobjekt werden direkt auf das komplexe Objekt übertragen und der Anwender
erhält sofort eine visuelle Rückmeldung.
Abbildung 4.12: Rotations-Widget (links); Translations-Widget (Mitte); Skalierungs-Widget (rechts)
Mit dem Mauszeiger können Teile des Widgets selektiert und verändert werden.
Beim Rotations-Widget dienen die farbigen Ringe der Selektion der Raumachse, die
als Rotationsachse dient (siehe Abbildung 4.12 (links)). Die Geometrie des Widgets
repräsentiert das daran gebundene Objekt in einer vereinfachten Form.
Mittels des Translations-Widgets können Objekte entlang der Raumachsen
verschoben werden. Je nach Selektion einer Achse und dem Verschieben mit der
Maus wird das Objekt versetzt. Die Form eines Achsenkreuzes mit Pfeilen ist die
übliche Darstellung des Widgets (siehe Abbildung 4.12 (Mitte)). Die Pfeile dienen
dabei als Angriffspunkte für die Interaktion mit einem Eingabegerät.
Das Skalierungs-Widget ähnelt im Aufbau den bereits vorgestellten Widgets. Dabei
wird wiederum eine Hilfsform um das Objekt herum gelegt: ein Quader, dessen
Ecken und Seitenflächen mit Elementen für die verschiedenen Interaktionen
versehen sind (siehe Abbildung 4.12 (rechts)). So wird durch Verschieben des
grünen Elements in der Mitte einer Seitenfläche das Objekt in die entsprechende
Richtung gedehnt beziehungsweise gestaucht, während an den Ecken eine
Skalierung über zwei oder drei Dimensionen möglich ist.
Manipulation der 3D-Szene
Dazu gehören alle Widgets, mit denen sich die Parameter der Szene verändern
lassen und solche, die den Blickpunkt beziehungsweise die Betrachterposition
manipulieren (vgl. [Dachselt 2004]). Beispiele hierfür sind Lichtquellenmanipulation,
Kameramodifikation und Sound-Veränderungen. Für diese Arbeit sind nur die
beiden ersten Veränderungsmöglichkeiten von Bedeutung. Für die Änderungen der
Kameraparameter (Position und Ausrichtung) muss nicht zwingend ein Widget
vorhanden sein, diese erfolgen direkt durch Mausbewegungen und das Drücken
einer zusätzlichen Maus-Taste. Das Wechseln zwischen verschiedenen Modi zur
Kamerasteuerung wird in Modellierungswerkzeugen durch Mausbewegungen und
50
SYNTHESE
das Drücken von Modifikationstasten der Tastatur (Strg, Alt oder Umschalttaste)
realisiert.
Welche Navigationsmetapher dabei zum Einsatz kommt, variiert je nach Anwendung. In BiLL sind bereits die Eyeball-in-hand-Metapher und zwei Ausprägungen der
Flug-Metapher integriert. Eine geführte Navigation in Form einer Kamerafahrt an
eine bestimmte Position ist noch nicht vorhanden und würde sich als Erweiterung
für BiLL eignen.
Anwendungskontrolle
Darunter fallen Widgets zur Zustandsänderung, Werteingabe-Auswahl und
Container-Widgets. Diese können eine Vielzahl an Kontrollaufgaben annehmen.
Unter anderem wird die indirekte Manipulation von Parametern darüber
bewerkstelligt. Widgets zur Anwendungskontrolle ähneln den Konzepten von 2DGUI-Elementen, sind aber nicht zwangsläufig 3D-Varianten der 2D-GUI-Widgets.
Aufgrund ihrer flexiblen Einsatzmöglichkeiten schreibt DACHSELT diesen einen
besonderen Stellenwert zu (vgl. [Dachselt 2004]).
51
SYNTHESE
52
5 Konzeption und
Implementierung
In diesem Kapitel werden anhand der im dritten Kapitel vorgestellten Methoden der
Interaktionsgestaltung die verschiedenen Konzepte zur Interaktion und Navigation
für Bildsprache LiveLab vorgestellt. Die Entwürfe werden auf Basis des Interaktionsgestaltungsprozesses nach VERPLANK und der Resultate der Synthese entwickelt.
Das Gesamtkonzept ist in drei Teile gegliedert: Interaktionskonzept, Navigationsunterstützung und Service-Architektur. Jedes Teilgebiet wird getrennt von den
anderen Bereichen betrachtet. Jedoch greifen alle drei als Gesamtlösung ineinander
über.
5.1 Entwicklung des Interaktionskonzepts
Der erste Schritt im Gestaltungsprozess nach VERPLANK ist die Motivation. Zur
Entwicklung eines Interaktionskonzepts führte die Unzulänglichkeit an Optionen
innerhalb des Viewer-Fensters, mit der Szene zu interagieren. Dem Nutzer war es
bislang nur erlaubt, die Kamera durch die Szene zu navigieren und Objekte darin zu
selektieren. Dies ist für eine interaktive Arbeitsumgebung nicht ausreichend und
erfordert ein neues Interaktionskonzept.
Nach COOPERS Methode des zielorientierten Interaktionsdesigns sind als Nutzer der
Forschungsumgebung BiLL die Entwickler des Systems selbst zu sehen. Diese
erweitern die Funktionalität der Basisanwendung im Rahmen von Diplom- und
Belegarbeiten. In der Gestaltung des Interaktionskonzepts werden sie als primäre
Nutzer des Systems angesehen und dementsprechend wird das Konzept auf sie
ausgerichtet. Die Persona, die sich daraus ergibt, wird im Folgenden Nutzer,
Anwender oder Entwickler genannt. Diese Begriffe werden äquivalent verwendet
und beschreiben den typischen Nutzer der Anwendung Bildsprache LiveLab.
Die Ziele, die sich für den Anwender formulieren, ergeben sich aus den Absichten,
die dieser im Umgang mit der Forschungsumgebung verfolgt. Die Entwicklung und
Umsetzung neuer Funktionalitäten ist das primäre Ziel. Diese Funktionalität anderen
Anwendern zugänglich zu machen, wird als sekundäres Ziel betrachtet. Als Idee zur
Repräsentation der einzelnen Plug-ins und ihrer Funktionen ergab sich die Metapher
einer Werkzeugsammlung (toolbox-container) mit verschiedenen Werkzeugkisten
(toolbox),
die
wiederum
verschiedene
Werkzeuge
(tools)
beinhalten.
Die
Werkzeugkisten stehen für die Plug-ins der Forschungsumgebung und die Werkzeuge symbolisieren die spezifischen Funktionen der Plug-ins. Die Werkzeug53
KONZEPTION UND IMPLEMENTIERUNG
sammlung ist die Verbildlichung der Verwaltungseinheit der Werkzeugkästen und
Werkzeuge.
Auf die Methoden der Gestaltung der Interaktion folgt die Konkretisierung von
Szenarios. Diese beschreiben, wie die zuvor erzeugte Metapher funktioniert. Wenn
die Forschungsumgebung BiLL gestartet ist und Plug-ins geladen wurden, sind
standardmäßig das Editor- und das Viewer-Fenster geöffnet. Im Editor-Fenster findet
der Nutzer den kompletten Funktionsumfang der geladenen Plug-ins wieder. Im
Viewer-Fenster sieht der Anwender zunächst eine 3D-Szene und die Standardelemente des Head-up-Displays.
Mittels Klicken der rechten Maus-Taste auf ein Objekt oder in den Hintergrund der
3D-Szene öffnet sich ein Menü mit einer Auswahl an Elementen, welche die
geladenen Plug-ins repräsentieren, die für das gewählte Objekt Funktionen
bereithalten. Durch die Auswahl eines Plug-ins werden dem Nutzer die zur Verfügung stehenden Funktionen angeboten. Mit einem Klick auf ein Werkzeugsymbol
wird dessen Funktionalität aktiviert. Der Nutzer ist dadurch in der Lage, Einstellungen sofort im Viewer-Fenster zu ändern, ohne in das Editor-Fenster zu wechseln.
Eine Service-Struktur verwaltet das Interaktionskonzept und stellt Funktionen und
Objekte bereit, die es dem Programmierer erlauben, neue Werkzeuge im Viewer
bereitzustellen. Die Architektur dieser Service-Struktur wird in 0 vorgestellt und
detailliert erläutert.
Anforderungsanalyse
Die für das Interaktionskonzept entwickelte Metapher ist Ausgangspunkt für die
Anforderungsanalyse. Die Selektion von Objekten funktioniert entweder über das
Editor-Fenster und den dazugehörigen Szenen-Explorer oder über das ViewerFenster. Nur über den Szenen-Explorer erhält der Nutzer ein visuelles Feedback
durch die Hervorhebung des Objektnamens. Im Viewer-Fenster bleibt das selektierte
Objekt unbeeinflusst. Für eine effektive Interaktion mit Objekten der 3D-Szene
müssen selektierte Objekte hervorgehoben werden, damit dem Anwender deutlich
wird, mit welchem Objekt er interagiert.
54
Abbildung 5.1: Das Editor-Fenster von BiLL
Neben der Markierung von selektierten Elementen der 3D-Szene sind die visuellen
Repräsentationen der Plug-ins und ihre Funktionen in Form einer benutzerfreundlichen hierarchischen Menü-Variante der erste Punkt unter den nichtfunktionalen Anforderungen. Die Möglichkeit der individuellen Gestaltung der einzelnen Elemente des Menüs ist der zweite Punkt im Bereich der nicht-funktionalen
Anforderungen. Das Hinzufügen von Elementen zum Menü und die Verknüpfung
der entsprechenden Funktionalität mit dem Element im Menü sind die funktionalen
Anforderungen an das Konzept. Für die Gestaltung des Menüs ist zusätzlich wichtig,
dass dieses die Szene nicht unnötig verdeckt.
Ferner muss dem Nutzer zu jedem Zeitpunkt gezeigt werden, in welchem Modus er
sich befindet. Zwei Modi werden zunächst unterschieden: zum einen der Navigationsmodus zur freien Steuerung der Kamera und zum anderen der Manipulationsmodus zum Modifizieren von Szenenelementen.
Funktionale Anforderungen:

Hinzufügen von Menü-Elementen (Werkzeug, Werkzeugkiste)

Verknüpfen von Funktion und Menü-Element (Werkzeug)

Anzeige des aktuellen Modus
55
Nicht-funktionale Anforderungen:

benutzerfreundliches Menü

individuelle Gestaltung von Menü-Elementen
Die funktionalen Anforderungen bilden den Ausgangspunkt für den weiteren
Entwurf der softwaretechnologischen Umsetzung. Das Hinzufügen von individuellen
Menü-Elementen bietet dem Nutzer die Möglichkeit, unter noch zu definierenden
Rahmenbedingungen Menü-Elemente zu gestalten und als Menü-Element zu
nutzen. Deren Gestaltung erfolgt mittels eines 3D-Modellierungswerkzeugs.
Die Rahmenbedingungen hierfür sind die Größe der 3D-Szene und das Dateiformat.
Hierfür wurde die Größe des Objekts auf 1x1x1 generische Einheiten festgelegt. Das
Dateiformat von OpenSceneGraph (.osg) und das Austauschformat von Autodesk
(*.3ds) sind die bevorzugten Formate. Das Verknüpfen der Funktionalität mit einem
Menü-Element (Werkzeug) soll auf eine einfache Art und Weise geschehen und
durch Methoden der SceneWidgetService-Komponente vereinheitlicht werden.
Entwurf und Implementierung
Nach gründlicher Analyse der Anforderungen an das Interaktionskonzept folgen der
Entwurf und anschließend die Implementierung. Nach VERPLANK fließt in diesen
Schritt die Bedeutung der Metaphern zur Funktionsweise des Konzepts und den
generierten Szenarien ein. Das Resultat dieser Phase ist ein konkretes Modell des
Interaktionskonzepts. Ein Sequenzdiagramm zeigt den Ablauf einer Beispielhandlung eines Anwenders und verdeutlicht somit die interne Funktionsweise.
Anhand des Modells und der Anwendungsfälle werden Implementierungsdetails
erläutert.
Zunächst sind die funktionalen Kriterien der zentrale Punkt des Entwurfs. Die
Umsetzung der nicht-funktionalen Kriterien ist ein iterativer Prozess, der durch
mehrere Evaluationen ein zufriedenstellendes Ergebnis hervorbringt. Sie wird daher
in dieser Arbeit als unerheblich behandelt.
Die Anforderung an das Konzept, Menü-Elemente hinzuzufügen, ist der wichtigste
Punkt. Jeder Entwickler muss die Möglichkeit haben, Werkzeuge zu erstellen, das
heißt anderen Nutzern Funktionalitäten im Viewer-Fenster zur Verfügung zu stellen.
Der Entwickler hat durch Einbindung des SceneWidgetService Zugriff auf die
Methoden zur Erstellung von Werkzeugkisten und Werkzeugen. Durch einen
Methodenaufruf wird eine neue Werkzeugkiste erstellt, die durch die Werkzeugsammlung (toolbox-container) verwaltet wird.
Eine Werkzeugkiste wird durch einen eindeutigen Namen definiert und ist dadurch
einzigartig. Der Name (_toolboxName) wird aus dem Wort TOOLBOX, gefolgt von
56
einem Bindestrich und dem Namen des Plug-ins gebildet. Die Zuordnung der Werkzeuge zur Werkzeugkiste erfolgt über diesen eindeutigen Namen.
_toolboxName = TOOLBOX-PLUGINNAME
Nachdem diese Werkzeugkiste angelegt wurde, wird über einen weiteren
Methodenaufruf des SceneWidgetService ein Werkzeug erstellt und der zuvor
erzeugten Werkzeugkiste hinzugefügt. Das Werkzeug wird ebenfalls durch einen
eindeutigen Namen identifiziert. Dieser setzt sich aus dem Wort TOOL, gefolgt von
einem Bindestrich, einer Funktionsbezeichnung, einem weiteren Bindestrich und
dem Namen des Plug-ins, zu dem dieses Werkzeug gehört, zusammen.
_toolName = TOOL-FUNKTION-PLUGINNAME
Das folgende Klassendiagramm zeigt die interne Struktur der Verwaltung der Werkzeuge und Werkzeugkisten.
Abbildung 5.2:
Klassenstruktur des Entwurfs der Toolboxen und Tools
Die Repräsentation der internen Struktur im Viewer-Fenster wird durch den
SceneWidgetService bewerkstelligt. Da jedes Plug-in eigene Werkzeuge bereitstellt,
eignet sich eine zweischichtige hierarchische Menü-Struktur zur Darstellung und
57
Führung des Nutzers. Eine einschichtige Auswahl von Werkzeugen würde die
Zuordnung von Werkzeugen zu Werkzeugkisten nicht gewährleisten.
Die Menü-Struktur wird entweder mittels eines Ring-Menüs oder über eine vertikale
beziehungsweise horizontale Menü-Variante abgebildet. Aufgrund der Übersichtlichkeit und der kurzen Interaktionswege, die im vorangegangenen Kapitel beim
Vergleich verschiedener Menü-Varianten als entscheidende Kriterien aufgezeigt
wurden, liegt der Fokus bei der Entwicklung auf dem Ring-Menü.
Die erste Menü-Ebene bildet die Werkzeugkisten in Form eines Ringes ab. Die
Werkzeugkisten-Icons werden durch 3D-Icons – ein dreidimensionales Objekt in
Form einer 3D-Szene – repräsentiert, die beim Erstellen einer Werkzeugkiste
angelegt wurden. Um die zugehörigen Werkzeuge anzuzeigen, muss eine Werkzeugkiste selektiert und angeklickt werden. Um diese herum öffnet sich die zweite
Ebene, welche die dazugehörigen Werkzeuge darstellt, in Form eines Halbkreises.
Die visuelle Repräsentation erfolgt nach dem gleichen Prinzip, nach dem die Werkzeugkisten abgebildet werden.
Abbildung 5.3: Ring-Menü (links) und hierarchisches Ring-Menü mit zweiter Menü-Ebene (rechts)
Im konkreten Anwendungsfall sieht dies wie folgt aus: Der Anwender wählt mit
einem Klick der rechten Maus-Taste über dem selektierten Objekt das Kontextmenü
für die Plug-ins aus. Es öffnet sich um das Objekt herum eine Auswahl anwendbarer
Plug-ins. Je nach Kontext variiert die Anzahl der Plug-ins, die nutzbar sind. Wird zum
Beispiel auf eine Lichtquelle geklickt, erscheinen nur die Plug-ins, die Funktionalitäten bezüglich der Beleuchtung haben.
Der Anwender wählt mit einem Links-Klick auf ein Plug-in-Icon das Plug-in aus,
dessen Funktionen er benutzen will. Die von diesem bereitgestellten Funktionen
werden daraufhin um das 3D-Icon des Plug-ins herum angezeigt. Durch Links-Klick
auf ein Werkzeug-Icon wird die daran gebundene Funktionalität ausgeführt. Dieses
Anwendungsszenario beschreibt den grundlegenden Gedanken, den das Interaktionskonzept verfolgt und wie es benutzt wird.
58
Diese Schritte erklären nach VERPLANKS Interaktionsgestaltungsprozess die Stufe
der Bedeutung des Konzepts, das heißt die Metapher wird mittels Szenarien erklärt
und verdeutlicht deren Sinnhaftigkeit. Die Gestaltung der 3D-Icons erfordert viel
Erfahrung, um eine verständliche Repräsentation der Werkzeuge und Steuerelemente zu entwickeln. Auf die qualitative Hochwertigkeit der 3D-Icons wird in
dieser Diplomarbeit verzichtet und stattdessen das Hauptaugenmerk auf die Interaktion gelegt.
Das
folgende
Sequenzdiagramm
veranschaulicht
den
eben
erläuterten
Anwendungsfall und zeigt die Kommunikation zwischen den einzelnen Komponenten.
Nutzer
BiLL
SceneWidgetService
ToolboxContainer
right click
event click right
add menu to scene
create menu
for all plugins
show menu
select toolbox
event selected node
add submenu to scene
create submenu
for selected toolbox
show submenu
select tool
event selected node
event selected tool
execute function of tool
Abbildung 5.4: Sequenzdiagramm eines Anwendungsfalls
Je nach Aufgabe oder Absicht, die der Anwender verfolgt, muss zwischen
verschiedenen Modi gewechselt werden. Der Anwender muss zwischen Navigationsund Manipulationsmodus wechseln können. Die Notwendigkeit dieser Trennung
von Navigation und Manipulation wird durch die vorhandenen Eingabegeräte
bestimmt. Beide Handlungen werden durch Bewegungen der Maus in Kombination
mit dem Drücken einer der Maus-Tasten bewirkt.
Somit ist eine Möglichkeit, dies zu differenzieren, die Einführung zweier Interaktionsmodi: Der eine Modus ist der Standardmodus und dient der Navigation
59
innerhalb der 3D-Szene. Durch Umschalten in den Manipulationsmodus wird die
freie Navigation in der Szene unterbunden und die Modifikation von Objekten und
Widgets wird gestattet. Zur visuellen Kennzeichnung des aktuellen Modus wird die
Hintergrundfarbe der Szene entsprechend geändert. Der Wechsel zwischen beiden
Modi erfolgt durch das Drücken der Tabulator-Taste. Da diese noch nicht von bereits
entwickelten Plug-ins benutzt wird, wird sie als Schalter zwischen den Modi
fungieren.
Aufbau eines 3D-Icons für BiLL
Die 3D-Icons, die im Menü zur Abbildung der Werkzeugkisten und Werkzeuge
benutzt werden, sind kleine 3D-Szenen, die ein einzelnes Objekt – das 3D-Icon –
enthalten. Das 3D-Icon wird beim Erstellen einer Toolbox beziehungsweise eines
Tools in Form einer Pfadangabe für die entsprechende Datei übergeben und
referenziert.
Für die Gestaltung eines 3D-Icons sind Richtlinien beziehungsweise Gestaltungsvorgaben einzuhalten, um die Einheitlichkeit der 3D-Icons innerhalb der Anwendung
BiLL zu wahren. Folgende Merkmale sind dabei von den Entwicklern zu beachten:
Merkmal
Wert
Dateiformat
3ds; osg
Dimension
1x1x1 generische Einheiten
Textur der Toolbox
grau: (158,158,158)
magenta: (226,18,106)
Textur der Tool
grau: (158,158,158)
blau: (25,70,144)
Form
radial
Tabelle 5.1:
Merkmale und Werte für die Tools und Toolboxen
Der Entwickler muss ein 3D-Icon im Dateiformat *.3ds oder im OpenSceneGrapheigenen Format *.osg zur Verfügung stellen. Beim Erstellen mit gängigen 3DModellierungswerkzeugen ist darauf zu achten, dass generische Einheiten
verwendet werden und dass 3D-Icons die Ausmaße einer Einheit in allen drei
Dimensionen nicht überschreiten. Hierfür wurde eine Beispieldatei als Ressource
erstellt, die den Entwicklern zur freien Verfügung steht.
Die Überarbeitung der Standard-Elemente (HUD-Elemente), die im Viewer sichtbar
sind, ist ebenfalls Bestandteil des Konzepts. Die HUD-Elemente basieren auf einer
ähnlichen Struktur wie die Werkzeuge, jedoch sind sie fest am oberen Rand des
60
Viewer-Fensters verankert. Im visuellen Erscheinungsbild unterscheiden sie sich
durch eine quadratische Form von den Werkzeug-Icons. Ferner ist für Entwickler das
Hinzufügen von neuen HUD-Elementen möglich. Somit werden die Standardfunktionen des Viewers erweitert. Die farbliche Gestaltung der HUD-Elemente ist an
das Gestaltungskonzept der Basisanwendung angelehnt und passt sich dadurch in
das Gesamterscheinungsbild ein. In Tabelle 5.2 sind die entwickelten 3D-Icons
abgebildet, die für das Interaktionskonzept benutzt wurden.
HUD-Elemente
Vollbild
Schließen
Light-Plug-in
EPK-Plug-in
Vorlage
Rotieren
Editor-Fenster
Toolboxen
Tools
Tabelle 5.2:
Translation
Übersicht der entwickelten HUD-Elemente und 3D-Icons
Das 3D-Icon des Beleuchtungs-Plug-ins symbolisiert eine Glühbirne und deutet
darauf hin, dass es sich um eine Werkzeugkiste zur Modifikation von Lichtquellen
handelt. Für das bereits vorhandene Plug-in zur Korrektur perspektivischer Verzerrungen ist ein 3D-Icon entwickelt worden, welches die Objektdeformation darstellt,
die durch einen hohen Öffnungswinkel der Kamera hervorgerufen wird. Die 3DIcons für das Rotations-Werkzeug und das Verschieben-Werkzeug sind äquivalent zu
bereits etablierten Icons in 3D-Modellierungswerkzeugen gestaltet.
61
5.2 Konzeption der
Navigationsunterstützung
Die Visualisierung abstrakter Daten im dreidimensionalen Raum erschafft eine uns
fremde Umgebung ohne jegliche Bezugspunkte zur Lokalisierung von oben, unten,
vorn, hinten, rechts und links. Um dieser Desorientierung Abhilfe zu schaffen, wird
ein Widget für die Forschungsumgebung Bildsprache LiveLab bereitgestellt, das zum
einen die Erfassung der momentanen Blickrichtung erleichtert und zum anderen
einen schnellen Wechsel zwischen verschiedenen Sichten erlaubt.
Anforderungsanalyse
Ähnlich der Anforderungsanalyse des Interaktionskonzepts vollzieht sich der Prozess
beim Konzipieren der Navigationsunterstützung. Ausgangspunkt der Analyse ist der
Orientierungsverlust in abstrakten Abbildungen von dreidimensionalen Informationsräumen. Die Frage, die sich stellt, ist folgende: Wie kann man den Nutzer mit einem
bekannten Objekt oder Verhalten helfen, sich in einer fremden Umgebung zu
orientieren?
Durch das Bewegen der virtuellen Kamera werden Objektrelationen innerhalb der
Szene wahrgenommen und Tiefeninformationen leiten sich durch die relative
Bewegung der Objekte zueinander ab (Bewegungsparallaxe). Dadurch erhält der
Nutzer eine Vorstellung vom Aufbau der Szene. Jedoch beinhalten abstrakte Szenen
meist keine visuellen Bezugssysteme. Die Erfassung von Richtungen wie oben oder
unten ist somit nicht gegeben.
Die Navigationsunterstützung muss folgende funktionalen sowie nicht-funktionalen
Anforderungen erfüllen:

Betrachtungsrichtungsrepräsentation in Echtzeit

Wechsel zwischen verschiedenen Sichten

geführter Sichtwechsel
Nicht-funktionale Anforderungen:

Benutzerfreundlichkeit

Individualisierbarkeit

Vermeidung von Sichteinschränkungen
Anhand der aufgestellten Anforderungen an das Navigationskonzept und der
bereits im dritten Kapitel vorgestellten Orientierungs- und Navigationshilfen wird im
Folgenden das Konzept für BiLL konkretisiert und seine Implementierung erläutert.
62
Entwurf und Implementierung
Aufbauend auf dem von Autodesk Research entwickelten ViewCube wird der
sogenannte Navigationswürfel (NaviCube) als Navigations- und Orientierungshilfe
für die Forschungsumgebung Bildsprache LiveLab vorgestellt. Der Grundgedanke
dafür ist die Einführung einer Miniaturvorschau. Diese zeigt die derzeitig geladene
Szene in der linken oberen Ecke des Viewer-Fensters aus der aktuellen Blickrichtung
an. Jedoch erweist sich diese verkleinerte Vorschau als nachteilig bei großen Szenen
und abstrakten Darstellungen. Sehr große und abstrakte Szenen sind nicht klar
erkennbar (vgl. Abbildung 5.5) und Rückschlüsse auf die Betrachtungsrichtung
lassen sich in abstrakten Szenen nur schwer ziehen, wie sich in Abbildung 5.5 zeigt.
Abbildung 5.5:
Stadtszene mit WIM oben links (links), abstrakte Szene mit WIM oben links (rechts)
Vielmehr wirkt die verkleinerte Vorschau als Bestandteil der Szene und grenzt sich
nicht von ihr ab. Eine farbige Hinterlegung der Miniatur würde diese von der
eigentlichen Szene abgrenzen, aber die nicht-funktionale Anforderung der
Vermeidung
der
Sichteinschränkung
ist
dadurch
nicht
gewährleistet.
Die
Navigationsunterstützung wird somit nur minimal erweitert.
Ein abstrahiertes Element wie eine Windrose, die auf Landkarten zu finden ist, bietet
das Potenzial, die Anforderungen umzusetzen. Diese meist aufwändig verzierten
Illustrationen der Himmelsrichtungen geben auf antiken Karten Aufschluss über die
Lage des abgebildeten Gebiets.
63
Abbildung 5.6: Tabvla geograregni Congo 1598 [University of Florida 1598]
Diese bewährte Methode zur Orientierung auf zweidimensionalen Darstellungen
von Landschaften ist auch in virtuellen Räumen anwendbar. Jedoch ist eine direkte
Konvertierung ins dreidimensional Virtuelle nicht möglich, sondern bedarf eines
Zwischenschritts. Dieser beschreibt die Erweiterung um eine dritte Dimension. Die
Reduktion der Windrose auf eine quadratische Fläche mit vier Unterteilungen dient
als Zwischenschritt zum Erreichen der Dreidimensionalität.
Abbildung 5.7: (1) Windrose, (2) reduzierte Windrose, (3) Grundkörper des NaviCube
Diese Fläche wird im nächsten Schritt zu einem Kubus (Grundform des NaviCube)
herausgetragen. Durch die drei Dimensionen werden die Himmelsrichtungen
obsolet. Für eine Beschriftung der Seiten des Würfels eignen sich bekannte Bezeichnungen wie links, rechts, oben, unten, hinten und vorn. Mit diesen Begriffen ist der
Nutzer aus der realen Welt vertraut und eine Zuordnung zu den Ansichten ist
gegeben.
64
Wie die Windrose der Positionsbestimmung dient, so wird der NaviCube die
Betrachtungsrichtung wiedergeben. Der NaviCube ist nicht nur hilfreich zur
Bestimmung der Betrachtungsrichtung, vielmehr werden über ihn vordefinierte
Ansichten angesteuert. Dazu wird der Grundkörper in 26 Teile unterteilt.
Abbildung 5.8: In 26 Elemente unterteilter Würfel
Jede Seite des Kubus besitzt ein zentrales Element welches die jeweilige Frontalsicht
auf diese Seite darstellt (Flächenelemente). Des Weiteren werden zwei benachbarte
Seiten jeweils durch ein Element verbunden (Kantenelemente). Drei aneinandergrenzende Seiten bilden die dritte Kategorie von Elemente (Eckenelemente).
Abbildung 5.9:
(links) Seitenelemente des Würfels, (Mitte) Kantenelemente des Würfels, (rechts)
Eckenelemente des Würfels
Die so entstandenen Elemente sind Interaktionselemente, die beim Klicken mit der
Maus aktiviert werden und die aktuelle Sicht des Nutzers verändern. Jedes Element
des Würfels repräsentiert eine vordefinierte Betrachtungsrichtung. Diese Sichten sind
so bestimmt, dass die Kamera senkrecht auf die Flächen, Kanten oder Ecken blickt.
Durch Klicken mit der Maus auf eines der Elemente wird die Kamera der virtuellen
Szene an diese Position geschwenkt. Diese Bewegung geschieht nicht abrupt,
sondern wird durch einen Übergang in Form einer Kamerafahrt vollzogen.
65
Abbildung 5.10: Kamerafahrt entlang eines Kreisbogens
Der Entwurf der Navigationsunterstützung spiegelt das Konzept der von GROH
beschriebenen datenbildkonformen Interaktion wider (vgl. [Groh 2005]), das heißt
die Szenenstruktur und ihre Geometrie bleiben erhalten, nur die Sicht auf diese
ändert sich. Das Ergebnis des Entwurfs ist ein texturierter Würfel mit unterschiedlich
eingefärbten und beschrifteten Elementen:
Abbildung 5.11: Texturiertes Modell des NaviCube für BiLL
Die farbliche Absetzung der einzelnen Elemente dient der Differenzierung und
erleichtert die Auswahl eines bestimmten Elements des Würfels. Die Beschriftungen
der zentralen Elemente der Seitenflächen des NaviCube dienen der Orientierung und
zeigen dem Nutzer, auf welche Seite des Modells die virtuelle Kamera schaut.
Darüber hinaus ist der Nutzer in der Lage, bestimmte Sichten zu speichern. So sind
interessante Blickwinkel in einer Art Sichtensammlung gespeichert und können zu
einem späteren Zeitpunkt wieder abgerufen werden, ähnlich einem bildhaften
Gedächtnis. Zur besseren Wiederauffindbarkeit sind die Sichten in Form eines
kleinen Bildes (Screenshot) neben den HUD-Elementen visualisiert.
66
Die Umsetzung des NaviCube-Konzepts in der Forschungsumgebung Bildsprache
LiveLab erfolgte in Anlehnung an die Ergebnisse von Autodesk Research (vgl. [Azam
Khan 2008]). Hierzu wurde ein 3D-Modell eines Würfels angefertigt. Dieser Würfel
besteht aus 26 einzelnen Objekten. Jedes dieser Objekte ist mit einem eindeutigen
Namen bezeichnet. Anhand des eindeutigen Namens ist jedes Element direkt
ansprechbar.
Der speziell für dieses Widget entwickelte NaviCubeEventHandler ruft für jedes
Element die daran gebundene Funktion auf. Das heißt, Funktionen sind an die
eindeutigen Bezeichnungen der NaviCube-Elemente geknüpft und können dadurch
identifiziert und aufgerufen werden. Der NaviCubeEventHandler erbt von der Klasse
EventHandler des Frameworks OpenSceneGraph, diese kann auf verschiedene
Ereignisse wie Maus-Ereignisse, Render-Ereignisse oder Tastatureingaben im ViewerFenster reagieren.
Die für den EventHandler des NaviCube wichtigen Ereignisse sind zum einen die
Maus-Eingaben des Nutzers zum Aktivieren einer bestimmten Sicht und das FrameEreignis zum Bewegen der Kamera an die gewählte Position. Das folgende
Sequenzdiagramm verdeutlicht die Kommunikation zwischen den einzelnen Komponenten, die bei der Interaktion des Nutzers mit dem NaviCube beteiligt sind.
Nutzer
SceneWidgetEventHandler
NaviCubeEventhandler
BiLL
click Left on NaviCube
WidgetEvent click Left
set steps to
move camera
move camera
WidgetEvent click Left
move camera
one step
each frame
Abbildung 5.12: Sequenzdiagramm für die Navigation mit dem NaviCube
Mit Hilfe eines modifizierten CameraCallback des OpenSceneGraph-Framework wird
die Betrachtungsrichtung des NaviCube mit der Hauptsicht des Viewer-Fensters
synchronisiert. Durch diese beiden Mechanismen kann entweder mit dem NaviCube
navigiert werden oder mit der Standardnavigation im Viewer-Fenster.
Der NaviCube ist Bestandteil des erweiterten Head-up-Display (Arbeitstitel:
AdvancedHUD). Die Einstellmöglichkeiten für diese befinden sich in Form eines
neuen Reiters im Editor-Fenster. Darüber sind verschiedene Änderungen von
67
Parametern des NaviCube möglich. Transparenz, Größe und Abstand zwischen
Kamera und 3D-Szene sind stufenweise einstellbar. Die Geschwindigkeit der
Kameradrehung zu vordefinierten Sichten ist ebenfalls einstellbar.
Damit das vorgestellte Interaktionskonzept und die eben vorgestellte Navigationsunterstützung umgesetzt werden können, wird im Folgenden die verbindende
Service-Architektur entwickelt und ihre Implementierung beschrieben.
5.3 Entwicklung der Service-Architektur
Die Service-Architektur SceneWidgetService stellt das zentrale Bindeglied zwischen
den Plug-ins und der Darstellung und Interaktivität im Viewer-Fenster dar. Sie bildet
auch die Grundlage für die Umsetzung des NaviCube. Für den Entwurf der ServiceStruktur werden anhand der vorangegangenen Entwürfe von Navigations- und
Interaktionskonzept die Anforderungen an die Service-Architektur analysiert. Daran
schließen sich der Entwurf und die Implementierung des Service in die bestehende
Anwendung an.
Anforderungsanalyse
Wie bereits in 5.1 und 5.2 wurden für das Interaktionskonzept und die
Navigationsunterstützung funktionale Anforderungen analysiert, die von der ServiceArchitektur erfüllt werden müssen. Diese stellt die Schnittstelle zwischen den Plugins und den Interaktionskonzept dar. Die dafür aufgestellten funktionalen Anforderungen sind:

Vereinheitlichung der Werkzeugauswahl

Bereitstellen von Manipulationsobjekten

Verwaltung von Toolboxen und Tools

Verwaltung des Ereignissystems für Werkzeuge und Widgets
Der Service, der von dieser Architektur bereitgestellt wird, umfasst Funktionen zur
Erstellung von Werkzeugkisten (Toolboxen) und Werkzeugen (Tools) sowie
individuell gestaltbaren Widgets. Die Darstellung im Viewer-Fenster und das
Interaktionsmanagement sind ebenfalls Aufgabe des SceneWidgetService. Wenn ein
Entwickler Funktionalität im Viewer-Fenster anbieten möchte, muss dies auf einem
einfachen und schnellen sowie verständlichen Weg geschehen.
68
Während der Laufzeit von BiLL müssen neu hinzugefügte Plug-ins in der Lage sein,
ihre Funktionalität sofort zur Verfügung zu stellen. Des Weiteren muss eine
Benachrichtigung an beteiligte Plug-ins gesendet werden, wenn ein Ereignis
ausgelöst wird, welches im Zusammenhang mit den Toolboxen und den Tools sowie
den Widgets steht.
Die Bereitstellung vordefinierter Manipulations-Widgets (Dragger) zum Verschieben,
Rotieren und Skalieren von Objekten gehört ebenfalls in das Repertoire an
Funktionalitäten des SceneWidgetService. Zukünftige Erweiterungen müssen auf
diese Sammlung an Manipulations-Widgets zugreifen können und sie für eigene
Entwicklungen nutzen. Diese Dragger sind den aus Modellierungswerkzeugen
bekannten Widgets nachempfunden (vgl. Abbildung 4.12: Rotations-Widget
(links); Translations-Widget (Mitte); Skalierungs-Widget (rechts)) und erhöhen den
Wiedererkennungswert. Individuelle Anpassungen sind denkbar und erhöhen deren
flexiblen Einsatz.
Entwurf
Die zuvor aufgestellten Anforderungen werden nun im Entwurf mit Hilfe von
Klassendiagrammen
konkretisiert.
Dadurch
werden
der
Aufbau
und
die
Funktionsweise der SceneWidgetService-Komponenten verdeutlicht. Ein kurzer
Einblick in die Implementierung zeigt die Funktionsprinzipien der Software-Komponente.
Das
folgende
Klassendiagramm
zeigt
die
wesentlichsten
Klassen
der
SceneWidgetService-Struktur. Die Service-Struktur wurde in Form eines Plug-ins
realisiert. Dieses wird über den BundleAdmin von BiLL während der Laufzeit
hinzugefügt und gestartet. Die Klasse SceneWidget ist für den Start des Plug-ins
zuständig und initialisiert den SceneWidgetService. Nachdem dieser aktiv ist, wird
die Klasse ToolboxContainer erstellt, um neue Werkzeugkisten aufzunehmen.
Der SceneWidgetEventHandler wird als nächstes gestartet, um Ereignisse seitens des
SceneWidgetService und des Viewer-Fensters zu registrieren und weiterzuleiten.
Nachdem alle Basiselemente gestartet wurden, ist das Plug-in bereit, durch andere
Plug-ins Werkzeugkisten, Werkzeuge und Widgets zu erstellen und zu verwalten.
Das
Entfernen
der
eben
genannten
Elemente
wird
ebenfalls
über
den
SceneWidgetService sichergestellt. Dabei wird immer auf einen konsistenten
Szenengraph geachtet sowie darauf, dass dieser in der Struktur durch das Entfernen
von Elementen nicht „zerbricht“, das heißt inkonsistent wird, und für die RenderEngine nicht mehr lesbar beziehungsweise interpretierbar ist.
69
Abbildung 5.13: Klassendiagramm des SceneWidgetService
70
Nachdem dies gestartet wurde, steht ein SceneWidgetService zur Verfügung, der
Methoden zur Erstellung von Widgets, Werkzeugen und Werkzeugkisten anbietet.
Bill::SceneWidget::Widget* createWidget(const std::string& name, std::string
fileNameForGeometry);
Bill::SceneWidget::Widget* createWidget(const std::string& name, std::string
fileNameForGeometry, osg::ref_ptr<osgGA::GUIEventHandler>
eventHandler);
void removeWidget(const std::string& name);
Bill::SceneWidget::Widget* getWidgetByName(const std::string& name);
Bill::SceneWidget::Toolbox* addToolbox(const std::string& name, const std::string&
fileNameForGeometry);
void removeToolbox(const std::string& name);
Bill::SceneWidget::Tool* addToolToToolbox(const std::string& toolName, const
std::string& toolboxName, const std::string& fileNameForGeometry);
void removeToolFromToolbox(const std::string& toolName, const std::string&
toolboxName);
Bill::SceneWidget::ToolboxContainer* getToolboxContainer();
Code 5-A:
Methoden des SceneWidgetService
Des Weiteren registriert der Service Ereignisse und verteilt diese über das
Ereignissystem von POCO. Plug-ins, die sich an der Ereignisverwaltung WidgetEvents
registriert haben, werden darüber informiert und erhalten ein Ereignisobjekt
WidgetEvent mit Informationen bezüglich Name und Art des Ereignisses. Darüber
hinaus ist darin die Maus-Position gespeichert, an der das Ereignis im Viewer-Fenster
ausgelöst wurde. Der SceneWidgetEventHandler ist die zentrale Einheit, welche die
Ereignisse auslöst und an die Ereignisverwaltung übermittelt.
Für die Erstellung neuer Werkzeugkisten stellt der SceneWidgetService eine
Methode bereit, die ein Objekt der Klasse Toolbox erzeugt und in die Werkzeugkistenverwaltung ToolboxContainer einfügt. Ähnlich vollzieht sich die Erstellung
eines neuen Werkzeugs. Dieses wird nicht in die Werkzeugkistenverwaltung eingefügt, sondern direkt an die entsprechende Werkzeugkiste gebunden.
71
72
6 Ergebnisse
Die Umsetzung des Interaktionskonzepts brachte auf der einen Seite eine
Schnittstelle für Entwickler hervor und auf der anderen ein über das Viewer-Fenster
aufrufbares Menü zur Wahl eines bestimmten Werkzeugs. Zukünftige Entwickler der
Forschungsumgebung BiLL haben dadurch die Möglichkeit, ihre zuvor bereitgestellten Funktionalitäten direkt im Viewer-Fenster verfügbar zu machen. Die
Resultate der einzelnen Umsetzungen werden an dieser Stelle überblicksartig
resümiert.
Das Interaktionskonzept
Exemplarisch wurde dies für das Beleuchtungs-Plug-in umgesetzt und durch eine
Dokumentation schrittweise erklärt. Nachdem das Plug-in zur Steuerung der
Beleuchtung und zum Hinzufügen von Lichtquellen geladen wurde, sind im ViewerFenster zwei Funktionen auswählbar. Jede Lichtquelle ist durch Aktivieren der
Translation in der Szene mittels eines Translations-Widgets frei verschiebbar entlang
der drei Raumachsen.
Die Rotation von Lichtquellen ist durch Aktivieren des Rotationsmodus möglich.
Dabei sind sowohl Rotationen um die Raumachsen als auch freie Rotationen
ausführbar. Die Unterstützung erfolgt hierbei durch ein Rotations-Widget. Ferner
wurde eine Sammlung an Dragger-Elementen angelegt, die für andere Entwickler
zur Umsetzung ihrer Ziele bereitsteht. Am Beispiel des Plug-ins zur Beleuchtungssteuerung wird gezeigt, wie mit Hilfe der SceneWidgetService-Architektur die
Einbindung in das Viewer-Fenster erfolgt.
Zunächst erfolgt die Registrierung der Klasse TabLighting des Plug-ins am
SceneWidgetService.
_pService = pContext->registry().findByName(
"de.tudresden.bill.SceneWidgetService");
_pSceneWidgetService = _pService->castedInstance<SceneWidgetService>();
Code 6-A:
Registrierung am SceneWidgetService
Anschließend erfolgt die Erstellung einer Werkzeugkiste durch die Methode
addToolbox
des
SceneWidgetService.
Mit
dieser
werden
der
Name
der
Werkzeugkiste und der Pfad zur Datei des 3D-Icons für die Repräsentation des LichtPlug-ins im Viewer-Fenster übergeben.
lightPlugin = _pSceneWidgetService->addToolbox("TOOLBOX-LIGHT",
"resources/SceneWidget/roundIcons/lightPlugin.osg");
73
ERGEBNISSE
Code 6-B:
Erstellung der Werkzeugkiste
Daraufhin werden der eben erstellten Werkzeugkiste die Werkzeuge hinzugefügt.
Die Methode addToolToToolbox erstellt diese und bindet sie gleichzeitig an die
Werkzeugkiste.
_translateDraggerWidget = _pSceneWidgetService->addToolToToolbox("TOOL-TRANSLATELIGHT", "TOOLBOX-LIGHT",
"resources/SceneWidget/roundIcons/translateLight.osg");
_rotateDraggerWidget = _pSceneWidgetService->addToolToToolbox("TOOL-ROTATE-LIGHT",
"TOOLBOX-LIGHT", "resources/SceneWidget/roundIcons/rotateLight.osg");
Code 6-C:
Erstellung der Werkzeuge
Nachdem die Werkzeuge erstellt wurden, wird die Funktion festgelegt, die
ausgeführt wird, wenn ein Werkzeug vom Anwender im Viewer-Fenster ausgewählt
wird. In diesem Fall ist es die Funktion handleDragger innerhalb der Klasse
TabLighting.
_pSceneWidgetService->widgetEvents().action += Poco::Delegate<TabLighting,
WidgetEvent>(this, &TabLighting::handleDragger);
Code 6-D:
Festlegen der auszuführenden Methode
Die Methode wird aufgerufen und die folgenden Parameter werden durch die
Ereignisbenachrichtigung des SceneWidgetService an diese übergeben:
void TabLighting::handleDragger(const void* sender, WidgetEvent& widgetEvent)
Code 6-E:
Parameterübergabe an die Funktion des Beleuchtungs-Plug-ins
Im Parameter widgetEvent sind Name und Typ des Ereignisses enthalten; darüber
hinaus auch die Position der Maus, als dieses ausgelöst wurde. Der Name ist
entscheidend, da er ausgewertet wird, um die entsprechende Funktionalität zu
aktivieren. Dies erfolgt über einen Vergleich des übergebenen Namens und eines
festgelegten Textteils (String).
switch(widgetEvent.name())
{
case(("TOOL-ROTATE-LIGHT"):
case(("TOOL-TRANSLATE-LIGHT"):
}
Code 6-F:
Auswertung des Namens, den das Event mit sich führt
Je nachdem, welcher Fall zutrifft, wird der Dragger zur Rotation oder zum
Verschieben von Lichtquellen aktiviert. Beim Erstellen einer Lichtquelle werden die
Dragger für die Translation und die Rotation generiert und an die Lichtquelle
gebunden. Das so entstandene Konstrukt aus Lichtquelle, Dragger und Transformationsknoten wird an die 3D-Szene angefügt (vgl. Abbildung 6.1) und ist
anschließend im Viewer- und im Editor-Fenster gleichermaßen zu verändern.
74
ERGEBNISSE
Kamera
Verbund
Verbund
Material
Kugel
Würfel
Verbund
Rotationsdragger
Translationsdragger
steuert
steuert
Verbund
Lichtquelle
Marker
Abbildung 6.1: Szenengraph mit angefügtem Subgraph aus Lichtquelle, Marker zur Repräsentation in
der Szene, Rotations-Dragger und Translations-Dragger
Die Manipulation der Lichtquelle im Viewer-Fenster bietet eine schnelle und direkte
Veränderung mit sofortiger visueller Rückmeldung. Rotationen im Raum sind für den
Anwender intuitiver, wenn dieser einen virtuellen Gegenstand hat, welcher auf
native Art und Weise bedient wird. Die Ausrichtung anhand von Winkelangaben im
Editor bietet Präzision, aber stellt sich als nicht unmittelbar nachvollziehbar dar.
Die Kombination aus beiden, Viewer- und Editor-Fenster, bietet daher ein breites
Spektrum an Interaktionsmöglichkeiten und Manipulationen für Lichtquellen. Die für
das Licht-Plug-in implementierten Funktionen zur Veränderung der Position und
Ausrichtung sind auch auf andere Objekte übertragbar. Abbildung 6.2 zeigt die
Dragger zum Manipulieren von Lichtquellen und die Marker, welche die Lichtquelle
repräsentieren.
75
ERGEBNISSE
Abbildung 6.2: Viewer-Fenster mit geladener Szene und zwei Lichtquellen mit Rotations-Draggern;
links rot leuchtendes Punktlicht, rechts weiß leuchtendes Spotlicht
Das Navigationskonzept
Der NaviCube, ein interaktives Widget zur Orientierung in dreidimensionalen
virtuellen Welten, wurde für Bildsprache LiveLab ausgehend vom Konzept des
ViewCube implementiert (vgl. [Autodesk 2008]). Dieses unterstützt den Nutzer bei
der Navigation und Orientierung in 3D-Szenen. Die in BiLL geladenen Szenen sind
entweder frei mit Hilfe der Maus oder eines Touch-Displays erkundbar oder mittels
des NaviCube sind vordefinierte Kamerasichten wählbar.
Dabei vollzieht die Kamera eine Fahrt vom Startpunkt bis hin zum Zielpunkt, der
gewählten vordefinierten Kamerasicht. Dies vermittelt auf eine reproduzierbare
Weise ein animiertes Bild der dargestellten 3D-Szene: reproduzierbar aufgrund der
vordefinierten Sichten, die jederzeit wieder wählbar sind.
Als problematisch erwies sich die Verwendung des NaviCube in Kombination mit
dem Plug-in zur Erzeugung von 360°-Panorama- und 360°-Objektdarstellungen.
Dabei wird eine Darstellung einer 3D-Szene aus mehreren Kamerabildern
zusammengesetzt, die einen Blickbereich streifenweise abbilden. Dies bedeutet
wiederum, dass entweder eine Hauptkamera festgelegt wird oder, wenn ein
Kamerasystem aus gleichberechtigten Kameras vorliegt, dass eine Hauptkamera
nicht definiert werden kann. Somit ist der Einsatz des NaviCube für derartige
76
ERGEBNISSE
Projektionsverfahren ungeeignet oder muss durch Einschränkungen an diese
angepasst werden.
Ähnlich verhält sich der NaviCube auf gekrümmten Projektionsflächen. Entweder der
NaviCube wird mit der Projektionsfläche verzerrt oder er wird in einer gesonderten
Projektionsfläche dargestellt und über die gekrümmte Ebene gelegt.
Für die Darstellung des NaviCube mit stereoskopischen Verfahren ist keine
Überarbeitung des Konzepts notwendig. Die Abbildungssoftware muss jedoch
stereoskopische Verfahren unterstützen und den NaviCube auf einer Ebene vor allen
anderen Szenenelementen darstellen. Dadurch wird der Effekt verstärkt, dass er eine
gesonderte Position über der Bildebene hat.
Durch Effekte der interaktiven Farbperspektive kann der NaviCube durch
verschiedene Aktionen hervorgehoben werden. Beispielsweise ist eine farbliche
Akzentuierung denkbar, wenn sich der Nutzer mit dem Eingabegerät dem Würfel
nähert oder diesen aktiviert. Auch der Abstand zur Szene ist durch eine farbliche
Gestaltung des NaviCube vorstellbar.
Die Service-Architektur
Durch die implementierte SceneWidgetService-Architektur wurde der Forschungsumgebung BiLL eine Komponente hinzugefügt, welche die bisherige Interaktionsmöglichkeiten und Gestaltungsmöglichkeiten bedeutend erweitert. Durch die
strukturierte Verwaltung der Widgets und Werkzeuge wird der Programmieraufwand für die Entwickler reduziert. Die Wiederverwendbarkeit wird erhöht und
durch eine Dokumentation unterstützt. Durch das Bereitstellen von zusammengesetzten Dragger-Widgets in Form von Klassen ist es für zukünftige Entwickler
möglich, auf einfache Weise individuelle Interaktionselemente in BiLL zu integrieren.
77
78
7 Zusammenfassung
Abschließend werden an dieser Stelle die Ergebnisse der Arbeit zusammengefasst
und es wird ein Resümee der inhaltlichen Aspekte gezogen. Ein Ausblick auf
weiterführende Arbeiten zeigt Ideen und Konzepte für zukünftige Entwicklungen
auf, die sich im Verlauf der Bearbeitung des Themas ergaben.
Das Ziel dieser Arbeit war die Entwicklung eines Interaktionskonzepts für die
Forschungsumgebung Bildsprache LiveLab. Durch intensive Untersuchung und
Recherche eröffnete sich ein weiterer Aspekt der Interaktion mit virtuellen Welten –
die Navigation darin. Die Zielstellung erweiterte sich um die Entwicklung und
Integration eines navigationsunterstützenden Elements.
Einführend wurden die Grundlagen der Computergrafik, der Software-Technologie
und des User-Interface-Designs erläutert, welche zum Verständnis dieser Arbeit
notwendig sind. Die theoretischen Grundlagen der Interaktionsgestaltung sowie die
Untersuchung von Navigationsmetaphern dienten als Basis für die Konkretisierung
der Konzepte.
Vergleichend wurden bereits bestehende Orientierungshilfen untersucht und im
Kontext der Forschungsumgebung BiLL analysiert und selektiert. Verschiedene
Menü-Varianten wurden betrachtet, für die Umsetzung des Interaktionskonzepts
ausgewählt und auf ihre Nutzbarkeit hin untersucht.
Aufbauend auf den Ergebnissen der Untersuchungen wurden die Konzepte für die
Interaktion und die Navigation speziell für BiLL entworfen und Implementierungsdetails
erläutert.
Die
im
Rahmen
der
Umsetzung
entwickelte
SceneWidgetService-Architektur ging aus diesem Schritt als zentrale Komponente
hervor.
Die Betrachtung der entstandenen Ergebnisse gibt einen Überblick über die
erreichten Ziele und Einblick in die Nutzung der Funktionen und Methoden zur
Gestaltung und Implementierung eigener Widgets und Werkzeuge.
7.1 Fazit
Die Interaktion in virtuellen Welten erfordert neue Denkweisen bei der Entwicklung
von Interaktionskonzepten und Werkzeugen. Die Phänomene dieser Welten bieten
Potenzial für neue Handlungsmuster, die es zu ergründen gilt. Zugleich muss der
79
ZUSAMMENFASSUNG
Mensch als Nutzer dieser Welten geführt und bei seinen Aufgaben entsprechend
unterstützt werden.
Bezugssysteme und Orientierungshilfen bieten genau dieses Potenzial und müssen
anwendungsspezifisch gestaltet werden. Besonders im Hinblick auf Virtual Reality
und Augmented Reality müssen Interaktionskonzepte auf die Anwendung, die
Aufgaben und die zugrunde liegende Technik angepasst werden.
Diese Arbeit lieferte einen Überblick über Gestaltungsmethoden, die zum erfolgreichen Entwickeln von Interaktionskonzepten verwendet werden. Ebenso wurden
verschiedene Orientierungshilfen vorgestellt, die bereits in 3D-Modellierungswerkzeugen zum Einsatz kommen. Die prototypische Implementierung zeigt die
theoretische Konzeption in einem Anwendungskontext.
7.2 Ausblick
Die
Interaktion
mit
Gegenständen
ist
ein
wesentlicher
Bestandteil
der
Wahrnehmung unserer Umwelt. Auch in virtuellen Welten ist die Interaktion mit
Gegenständen, Objekten und der Gesamtszene ein entscheidendes Kriterium für die
Wahrnehmung und den Immersionsgrad dieser Welt. Die in dieser Arbeit
entwickelten
Navigationshilfen
und
Interaktionskonzepte
wurden
für
die
Anwendung auf einem 2D-Display entwickelt. Zu untersuchen wäre, wie sie in 3DPräsentationsräumen (CAVE) integriert werden. Deren unterstützendes Verhalten für
den Anwender muss in Studien evaluiert werden.
Besonders für die direkte Interaktion mit den Händen ist es notwendig Widgets zu
entwickeln, die intuitive mit den Händen benutzt werden. Durch die Nutzung von
Infrarot Trackingsystemen ist die Erkennung der Handposition und Fingerstellung
möglich und kann direkt auf das Widget übertragen werden.
Zukünftige Systeme zur Modellierung, Gestaltung und Präsentation von virtuellen
Welten werden zunehmend an den Nutzer angepasst oder passen sich selbst an
diesen an. Hierfür werden die Vorgehensmodelle der nutzerzentrierten Interaktionsgestaltung und des zielorientierten Gestaltens weiterhin eine wichtige
Position einnehmen. Die Standardisierung dieser Methoden würde ein Regelwerk
hervorbringen, nach dem Benutzeroberflächen gestaltet werden, die auf die
Nutzergruppen zugeschnitten sind und eine intuitive Bedienung bereitstellen.
Für die Arbeitsumgebung Bildsprache LiveLab wurde ein Grundstein gelegt, der auf
verschiedene Art und Weise erweitert werden muss. Erst durch weitere Entwicklung
kann sich das Potenzial des Interaktionskonzepts entfalten. Ebenso können durch
die Service-Architektur weitere Navigationshilfen implementiert und mit bestehenden verglichen werden.
80
A Glossar
3D-SZENE
Eine 3D-Szene beschreibt die Gesamtheit aller Objekte,
Materialien, Texturen und Beleuchtung einer virtuellen
Szenerie.
API
Application Programming Interface – Ist eine
Programmierschnittstelle, die von einem Software-System für
andere Programme zur Verfügung gestellt wird, um das
System in diese einzubinden.
CONE-METAPHER
Ähnlich der Ray-Casting-Metapher dient hierbei ein
kegelförmiges Objekt zur Selektion von Objekten ähnlich dem
Lichtkegel einer Taschenlampe.
EMERSION
Als Emersion wird das Auftauchen bezeichnet. Der Nutzer
nimmt eine Position über den Dingen ein.
EVENT
Ist ein Ereignis, das entweder vom Benutzer oder vom System
ausgelöst wird. Das System reagiert auf dieses Ereignis mit
Benachrichtigungsmethoden. Software-Einheiten, die an einem
bestimmten Ereignis interessiert sind, werden benachrichtigt.
FEATURE
Als Feature bezeichnet man in der Software-Technologie die
Funktionalitäten einer Software. Dabei können
Funktionalitäten wiederum aus mehreren Funktionen
bestehen.
GADGET
Ist ein technisches Gerät mit außergewöhnlicher Funktionalität.
Dieses soll den Nutzer bei spezifischen Aufgaben sinnvoll
unterstützen.
GEOMETRIEKNOTEN
Ein Geometrieknoten ist die Beschreibung der Geometrie eines
virtuellen Objekts anhand einer dreidimensionalen Punktwolke.
GIZMO
Ist im Englischen ein Platzhalterwort für ein Ding. In der
Computergraphik wird dieser Begriff für die Hilfsgeometrie von
Widgets verwendet.
GPS
Global Positioning System – ist ein System aus Satelliten, das
zur Positionsbestimmung und Navigation auf der Erde genutzt
wird.
81
ANHANG
GUI
Graphical User Interface – ist die grafische
Benutzungsoberfläche von Programmen. Darüber steuert der
Nutzer die Anwendung mit unterschiedlichen Eingabegeräten.
HEAD-UP-DISPLAY
Ist ein System, welches für den Nutzer wichtige Information in
den Sichtbereich einblendet. Die Informationen können auch
Interaktionskomponenten sein und die Anwendungssteuerung
unterstützen.
ICON
Im Kontext der grafischen Benutzeroberflächen beschreibt
dieser Begriff ein Symbol, welches ein Repräsentant für ein
Objekt wie zum Beispiel eine Datei, ein Programm oder ein
Ordner ist.
IMMERSION
Dies bezeichnet das Eintauchen in die virtuelle Welt. Das
Vereinnahmen durch die Präsentation der Virtualität.
INTERFACE
Ist eine Schnittstelle zwischen zwei verschiedenen
Komponenten. Diese dient als Vermittler zwischen den beiden
Komponenten. Die grafische Benutzeroberfläche einer
Anwendung dient als Mittler zwischen Nutzer und Software. In
der objektorientierten Programmierung vereinbaren
Schnittstellen gemeinsame Signaturen von Methoden und
Funktionen, welche in unterschiedlichen Klassen implementiert
werden.
MAP / MAPPING
Als Mapping wird der Prozess der Abbildung bezeichnet. In der
objektorientierten Programmierung bildet eine Map ein Objekt
A auf ein Objekt B ab. Beim Durchsuchen der Map erhält man
durch Objekt A Zugriff auf Objekt B.
OBJECT
Ist ein 1989 gegründetes Konsortium, das sich mit der
MANAGMENT
Entwicklung von Standards für die herstellerunabhängige,
GROUP
systemübergreifende, objektorientierte
Programmierung beschäftigt.
OPENGL
Ist eine Spezifikation für eine plattform- und
programmiersprachenunabhängige Programmierschnittstelle z
ur Entwicklung von 2D- und 3D-Computergrafik.
PLUG-IN
Das Ansichtskoordinatensystem ist so definiert, dass der
Ursprung links unten auf der Bildebene liegt.
82
ANHANG
RAY-CASTING-
Diese Metapher beschreibt die Selektion von Objekten, bei der
METAPHER
ausgehend von der virtuellen Hand ein zylinderförmiger Strahl
zur Objektselektion verwendet wird.
SEQUENZDIAGRAMM Das Sequenzdiagramm beschreibt die zeitliche Abfolge von
Interaktionen zwischen einer Menge von Objekten innerhalb
eines zeitlich begrenzten Kontextes.
SERVICE
Ein Service ist ein Dienst, der von einer Software-Komponente
bereitgestellt wird. Dieser wiederum stellt Methoden und
Objekte bereit und verwaltet diese.
TOUCH-SCREEN
Ist ein Computereingabegerät, bei dem durch Berührung der
Oberfläche des Bildschirms der Computer mit den Fingern oder
der ganzen Hand gesteuert werden kann.
UML
Ist eine von der Object Management Group (OMG) entwickelte
und standardisierte Sprache für die Modellierung von Software
und anderen Systemen.
VIRTUELLE-HAND-
Bei der Virtuelle-Hand-Metapher wird in der virtuellen
METAPHER
Umgebung das reale Eingabegerät als virtuelles Werkzeug
dargestellt und reale Aktionen am Eingabegerät werden direkt
auf dieses übertragen.
83
ANHANG
B Literaturverzeichnis
ANDREWS, K. (2009): Human-Computer Interaction, zuletzt aktualisiert am
02.06.2009.
APPINF (2008): POCO OpenServicePlatform, zuletzt aktualisiert am 06.08.2008,
zuletzt geprüft am 08.01.2010.
BARSKY, B. A.; HORN, D. R.; KLEIN, S. A.; PANG, J. A.; YU, M. (2003): Camera Models
and Optical Systems Used in Computer Graphics: Part I, Object-Based Techniques.
In: LECTURE NOTES IN COMPUTER SCIENCE, S. 246–255.
BLIZZARD ENTERTAINMENT (2009): World of Warcraft. Online verfügbar unter
www.wow-europe.de.
BOWMAN, D. A.; KRUIJFF, E.; LAVIOLA JR, J. J.; POUPYREV, I. (2001): An introduction to
3-D user interface design. In: Presence: Teleoperators & Virtual Environments, Jg. 10,
H. 1, S. 96–108.
BREUER, M. (2007): Second Life und business in virtuellen Welten. In: White Paper
Berlin, S. 1–62.
BRUNNETT, G.; LORENZ, M.; WAGNER, H. (2000): Navigations- und Orientierungshilfen
in virtuellen Welten, zuletzt aktualisiert am 05.07.2000.
CALLAHAN, J.; HOPKINS, D.; WEISER, M., et al. (Hg.) (1988): An empirical comparison of
pie vs. linear menus. Proceedings of the SIGCHI conference on Human factors in
computing systems: ACM New York, NY, USA.
CONNER, B. D.; SNIBBE, S. S.; HERNDON, K. P., et al. (Hg.) (1992): Three-dimensional
widgets. Proceedings of the 1992 symposium on Interactive 3D graphics: ACM.
COOPER, A. Reimann R.; CRONIN, D. (2007): About face 3. The essentials of
interaction design. Completely rev. and updated, [3. ed.]. Indianapolis, Ind.: Wiley.
DACHSELT,
R.
(2004):
Eine
deklarative
Komponentenarchitektur
und
Interaktionsbausteine für dreidimensionale multimediale Anwendungen: Der Andere
Verlag.
DÄßLER,
R.
(1998):
Virtuelle
Informationsräume
mit
VRML.
Informationen
recherchieren und präsentieren in 3D. Unter Mitarbeit von Hartmut Palm.
Heidelberg: Dpunkt Verl.
DIN DEUTSCHES INSTITUT FÜR NORMUNG E.V. (1997): Anforderungen an die
Gebrauchstauglichkeit - Leitsätze. Berlin: Beuth, Nr. 9241-11.
85
ANHANG
DIN DEUTSCHES INSTITUT FÜR NORMUNG E.V. (1997): Anforderungen an die
Gebrauchstauglichkeit - Leitsätze. Berlin: Beuth, Nr. 9241-14.
DORSCH, F.; HÄCKER, H. O.; BECKER-CARUS, C. (2004): Dorsch Psychologisches
Wörterbuch. [15000 Stichwörter, 800 Testnachweise]. 14., vollst. überarb. und erw.
Aufl. Bern: Huber.
EBNER, T. (2007): BiLL - Bildsprache LiveLab. Konzeption und Realisierung einer
interaktiven Arbeitsumgebung für die Erforschung wahrnehmungsrealistischer
Projektion, zuletzt aktualisiert am 14.02.2008.
FECHTER, J. (1999): Verhalten, Kommunikation und Interaktion in Virtuellen 3DUmgebungen, zuletzt aktualisiert am 26.11.1999.
FERNANDO, T.; MURRAY, N.; GAUTIER, G.; MIHINDU, S.; LOUPOS, K.; GRAVEZ, P. et al.
(2006): State-of-the-art in VR. Intuition Virtual Reality, zuletzt aktualisiert am
10.11.2006.
FRANKE, I. S. (2007): Malerei als Leitbild - Universum der technischen Bilder, zuletzt
aktualisiert am 23.04.2007.
GROH,
R.
(2005):
Das
Interaktions-Bild.
Theorie
und
Methodik
der
Interfacegestaltung. Dresden: TUDpress.
GROH, R. (2006): Virtuelle Phänomene, zuletzt aktualisiert am 20.06.2006, zuletzt
geprüft am 03.11.2009.
HEAVENGAMES
LLC
(2009):
Caesar
4.
Online
verfügbar
unter
http://caesar4.heavengames.com.
HELLER, A. (2000): Brockhaus - die Enzyklopädie. In vierundzwanzig Bänden. [20.,
überarb. und aktualisierte Aufl.]. Leipzig: Brockhaus.
HENZEN, C. (2009): Orientierung in Punktwolkenvisualisierungen, zuletzt aktualisiert
am 29.09.2009.
HERCZEG, M. (2006): Interaktionsdesign. Gestaltung interaktiver und multimedialer
Systeme. München: Oldenbourg.
HERCZEG, M. (2009): Software-Ergonomie. Theorien, Modelle und Kriterien für
gebrauchstaugliche interaktive Computersysteme. 3., vollst. überarb. und erw. Aufl.
München: Oldenbourg.
HERNDON, K. P.; ZELEZNIK, R. C.; ROBBINS, D. C., et al. (Hg.) (1992): Interactive
Shadows. Proceedings of the 5th annual ACM symposium on User interface
software and technology: ACM New York, NY, USA.
86
ANHANG
KAMMER, D. (2009): Neukonzeption einer erweiterbaren Software-Architektur für ein
echtzeitfähiges Visualisierungssystem, zuletzt aktualisiert am 10.06.2009.
KECK, M. (2009): Entwicklung eines Visualisierungskonzepts für Dateien im
dreidimensionalen Informationsraum, zuletzt aktualisiert am 16.06.2009.
KHAN, A.; MORDATCH, I.; FITZMAURICE, G., et al. (Hg.) (2008): ViewCube: a 3D
orientation indicator and controller. Proceedings of the 2008 symposium on
Interactive 3D graphics and games: ACM New York, NY, USA.
KURTENBACH, G.; BUXTON, W. (Hg.) (1993): The limits of expert performance using
hierarchic marking menus. Proceedings of the INTERACT'93 and CHI'93 conference
on Human factors in computing systems: ACM New York, NY, USA.
MARCUS, A. (Hg.) (1994): Managing metaphors for advanced user interfaces.
Proceedings of the workshop on Advanced visual interfaces: ACM New York, NY,
USA.
MAX-PLANCK-GESELLSCHAFT (2005): CyberWalk - ungehindertes Gehen in virtuellen
Welten. Europäisches Projekt zur Entwicklung einer neuartigen Laufplattform.
Microsoft,
(2005):
Age
of
Empires
3.
Online
verfügbar
unter
www.ageofempires3.com.
MILLER, T.; ZELEZNIK, R. (Hg.) (1999): The design of 3D haptic widgets. Proceedings of
the 1999 symposium on Interactive 3D graphics: ACM New York, NY, USA.
MOGGRIDGE, B. (2007): Designing interactions. Cambridge, Mass.: MIT Press.
OAKS, H. (2009): POV-Ray. Online verfügbar unter www.povray.org, zuletzt
aktualisiert am 2008.
ORLAMÜNDER, D. (2004): Computergrafik und OpenGL. Eine systematische
Einführung. Unter Mitarbeit von W. Mascolus. München: Hanser.
OSG
DEVELOPER
(2007):
OpenSceneGraph.
Online
verfügbar
unter
www.openscenegraph.org, zuletzt aktualisiert am 2007.
OSGI ALLIANCE (2004): Listeners Considered Harmful: The “Whiteboard” Pattern.
Online verfügbar unter http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf.
PIERCE, Jeff (2001): Expanding the Interaction Lexicon for 3D Graphics, zuletzt
aktualisiert am 13.12.2001, zuletzt geprüft am 01.10.2009.
PREIM, B. (1999): Entwicklung interaktiver Systeme. Grundlagen, Fallbeispiele und
innovative Anwendungsfelder ; mit 20 Tabellen. Berlin: Springer.
87
ANHANG
REINHOLD, G.; SAMNEK, S.; RECKER, H. (2000): Soziologie-Lexikon. 4. Aufl. München:
Oldenbourg.
SCHWALL, J. (2004): 3D-Interaktion, zuletzt aktualisiert am 11.10.2004.
SEMICONDUCTOR APPLET SERVICE (SAS) (2009): Educational Java Applet Service (JAS).
University
of
Buffalo.
Online
verfügbar
unter
http://jas.eng.buffalo.edu/education/solid/genUnitCell/index.html, zuletzt geprüft am
03.12.2009.
SHARP, H.; ROGERS, Y.; PREECE, J. (2007): Interaction design. Beyond humancomputer interaction. 2. ed. Chichester: Wiley.
SNIBBE, S. S.; HERNDON, K. P.; ROBBINS, D. C.; CONNER, D. B.; VAN DAM, A. (1992):
Using deformations to explore 3D widget design. In: ACM SIGGRAPH Computer
Graphics, Jg. 26, H. 2, S. 351–352.
STAPELKAMP, T. (2007): Screen- und Interfacedesign. Gestaltung und Usability für
Hard- und Software. (Springer-11774 /Dig. Serial]). Online verfügbar unter
http://dx.doi.org/10.1007/978-3-540-32950-3
/
http://www.gbv.de/dms/hebis-
darmstadt/toc/182135667.pdf.
STEINICKE, F.; ROPINSKI, T.; HINRICHS, K. (2004): Selektion von Objekten in Virtuellen
Umgebungen mit der Improved Virtual Pointer-Metapher.
STEVENS, B. L.; LEWIS, F. L. (2003): Aircraft control and simulation. 2. ed. Hoboken,
NJ: Wiley.
STOAKLEY, R.; CONWAY, M. J.; PAUSCH, R. (Hg.) (1995): Virtual reality on a WIM:
Interactive worlds in miniature. Proceedings of the SIGCHI conference on Human
factors in computing systems: ACM Press/Addison-Wesley Publishing Co. New York,
NY, USA.
STORK, A. (2000): Effiziente 3D-Interaktions-und Visualisierungstechniken für
benutzer-zentrierte Modellierungssysteme. In: Diss. TU Darmstadt.
STRUBE, G. (1996): Wörterbuch der Kognitionswissenschaft. Stuttgart: Klett-Cotta.
SZYPERSKI, C.; GRUNTZ, D.; MURER, S. (2003): Component software. Beyond objectoriented programming. 2nd ed. London: Addison-Wesley (Addison-Wesley
component software series).
UNIVERSITY OF FLORIDA (1598): Tabvla geograregni Congo. Herausgegeben von
George A. Smathers Libraries.
88
ANHANG
WARE, C. (2009): Information visualization. Perception for design. 2. ed., [Nachdr.].
Amsterdam: Elsevier [u.a.].
WEB3D CONSORTIUM (1997): The Virtual Reality Modeling Language.
WERNECKE, J. (2005): The inventor mentor. Programming object-oriented 3D
graphics with open inventor release 2. 12th print. Reading, Mass., Bonn: AddisonWesley.
WINGRAVE, C.; HACIAHMETOGLU, Y.; BOWMAN, D. (Hg.) (2006): Overcoming world in
miniature limitations by a scaled and scrolling WIM. Proceedings of IEEE Symposium
on 3D User Interfaces: Citeseer.
WUTTIG, D. (2008): Konzeption und Realisierung von multiperspektivischen
Projektionen durch mehrere Kameras in der Arbeitsumgebung Bildsprache LiveLab
(BiLL), zuletzt aktualisiert am 27.06.2008, zuletzt geprüft am 15.09.2009.
ZIEGLER,
J.
(Hg.)
(2007):
Interaktion
mit
komplexen
Informationsräumen.
Visualisierung, Multimodalität, Kooperation. München, Wien: Oldenbourg.
Screenshots
3D Studio MAX
Autodesk 2009
Age of Empires
Microsoft 2005
Caesar 4
Heaven Games LLC 2006
circular-application-menu
Cole Anstey 2008
Crysis
Crytek 2008
Monkey Island
Lucas Film Games 1990
Word 2007
Microsoft 2006
World of Warcraft
Blizzard Entertainment 2009
89
ANHANG
90
C Abbildungsverzeichnis
ABBILDUNG 1.1: REALE LANDSCHAFT (LINKS); FOTOREALISTISCHE ABBILDUNG DIESER
LANDSCHAFT IM COMPUTERSPIEL ‚CRYSIS‘ (RECHTS) [CRYTEK 2008] .......... 2 ABBILDUNG 1.2: VIEWER-FENSTER (VOLLBILD) UND EDITOR-FENSTER DER
ARBEITSUMGEBUNG BILL .................................................................... 3 ABBILDUNG 2.1: ABSTRAHIERTE DARSTELLUNG EINES SZENENGRAPHEN ............................... 7 ABBILDUNG 2.2: MODELL DER VIRTUELLEN KAMERA UND IHRER PARAMETER (EYE, CENTER, UP
VECTOR) (LINKS); MODELL DER VIRTUELLEN KAMERA UND DEFINITION DES
SICHTKÖRPERS ANHAND DER PARAMETER: LEFT, RIGHT, TOP, BOTTOM, NEAR,
FAR (RECHTS) .................................................................................. 10 ABBILDUNG 2.3: DIE SECHS FREIHEITSGRADE DER VIRTUELLEN KAMERA ............................. 11 ABBILDUNG 2.4: EDITOR-FENSTER DER UMGEBUNG BILL MIT SZENENGRAPH
DER GELADENEN SZENE ..................................................................... 14 ABBILDUNG 2.5: VIEWER-FENSTER MIT GELADENEM 3D-MODELL ..................................... 14 ABBILDUNG 3.1: DIE “HOW DO YOU...?”-FRAGEN NACH VERPLANK
[MOGGRIDGE 2007, S. 126] ............................................................ 24 ABBILDUNG 3.2: SKIZZE DES INTERAKTIONSDESIGNPROZESSES NACH VERPLANK
[MOGGRIDGE 2007 S. 130] ............................................................. 25 ABBILDUNG 3.3: NAVIGATIONSSTEUERUNG WORLD-IN-HAND-CONTROLLER (NACH WARE)
(LINKS); VIRTUELLE SZENE MIT KORRESPONDIERENDEN FREIHEITSGRADEN ZUR
STEUERUNG DER SZENE (RECHTS) ........................................................ 32 ABBILDUNG 3.4: NAVIGATIONSSTEUERUNG EYEBALL-IN-HAND-CONTROLLER (NACH WARE)
(LINKS); VIRTUELLE SZENE UND KORRESPONDIERENDE FREIHEITSGRADE AN DER
KAMERA (RECHTS) ........................................................................... 33 ABBILDUNG 3.5: DIE WANDERER-METAPHER – LAUFBAND ALS EINGABEGERÄT (LINKS); SICHT
DES NUTZERS IN DIE VIRTUELLE WELT (RECHTS) ....................................... 33 ABBILDUNG 3.6: CYBERWALK-SKIZZE NACH [MAX-PLANCK-GESELLSCHAFT 2005] ............ 34 ABBILDUNG 4.1: MINIMAP VON WORLD OF WARCRAFT [BLIZZARD ENTERTAINMENT 2009]
(LINKS), MINIMAP VON AGE OF EMPIRES 3 [MICROSOFT 2005] (MITTE),
MINIMAP VON CAESAR IV [HEAVENGAMES LLC 2009] (RECHTS) ............. 38 ABBILDUNG 4.2: KOORDINATENKREUZ IN DER ANWENDUNG AUTODESK® 3DS MAX® ........ 39 ABBILDUNG 4.3: KUBISCHES RASTER ZUR DARSTELLUNG VON KRISTALLSTRUKTUREN
[SEMICONDUCTOR APPLET SERVICE (SAS) 2009] .................................. 40 ABBILDUNG 4.4: ZYLINDRISCHES RASTER (LINKS), KUBISCHES RASTER VON INNEN (RECHTS) ... 40 ABBILDUNG 4.5: SPHÄRISCHES RASTER VON AUßEN (LINKS), SPHÄRISCHES RASTER VON INNEN
(RECHTS) ........................................................................................ 40 ABBILDUNG 4.6: AUTODESK VIEWCUBE (LINKS) [AZAM KHAN 2008],
3D-KOMPASS (MITTE) [BRUNNETT ET AL. 2000],
VIEWSPHERE (RECHTS) [BRUNNETT ET AL. 2000].................................... 41 91
ANHANG
ABBILDUNG 4.7: VIEWCUBE MIT BESCHRIFTUNG (1), MIT BILDERN (2), MIT 3D-MODELL (3),
OHNE BESCHRIFTUNG (4) [AZAM KHAN 2008] ..................................... 42 ABBILDUNG 4.8: WORLD-IN-MINIATURE [STOAKLEY ET AL. 1995] ................................... 43 ABBILDUNG 4.9: MENÜ-HINTERGRUND-INTEGRATION (LINKS);
KARTEIKARTEN-REGISTER (RECHTS) ..................................................... 46 ABBILDUNG 4.10: PULL-DOWN-MENÜ (LINKS); DROP-DOWN-MENÜ (RECHTS) ..................... 47 ABBILDUNG 4.11: MENÜ ALS BESTANDTEIL DER ERZÄHLFORM (LINKS);
RADIAL-MENÜ (RECHTS) ................................................................... 47 ABBILDUNG 4.12: ROTATIONS-WIDGET (LINKS); TRANSLATIONS-WIDGET (MITTE);
SKALIERUNGS-WIDGET (RECHTS) ........................................................ 50 ABBILDUNG 5.1: DAS EDITOR-FENSTER VON BILL.......................................................... 55 ABBILDUNG 5.2: KLASSENSTRUKTUR DES ENTWURFS DER TOOLBOXEN UND TOOLS .............. 57 ABBILDUNG 5.3: RING-MENÜ (LINKS) UND HIERARCHISCHES RING-MENÜ MIT
ZWEITER MENÜ-EBENE (RECHTS) ......................................................... 58 ABBILDUNG 5.4: SEQUENZDIAGRAMM EINES ANWENDUNGSFALLS.................................... 59 ABBILDUNG 5.5: STADTSZENE MIT WIM OBEN LINKS (LINKS),
ABSTRAKTE SZENE MIT WIM OBEN LINKS (RECHTS) ................................. 63 ABBILDUNG 5.6: TABVLA GEOGRAREGNI CONGO 1598 [UNIVERSITY OF FLORIDA 1598] ..... 64 ABBILDUNG 5.7: (1) WINDROSE, (2) REDUZIERTE WINDROSE,
(3) GRUNDKÖRPER DES NAVICUBE ...................................................... 64 ABBILDUNG 5.8: IN 26 ELEMENTE UNTERTEILTER WÜRFEL ............................................... 65 ABBILDUNG 5.9: (LINKS) SEITENELEMENTE DES WÜRFELS, (MITTE) KANTENELEMENTE DES
WÜRFELS, (RECHTS) ECKENELEMENTE DES WÜRFELS ............................... 65 ABBILDUNG 5.10: KAMERAFAHRT ENTLANG EINES KREISBOGENS ....................................... 66 ABBILDUNG 5.11: TEXTURIERTES MODELL DES NAVICUBE FÜR BILL .................................... 66 ABBILDUNG 5.12: SEQUENZDIAGRAMM FÜR DIE NAVIGATION MIT DEM NAVICUBE ................ 67 ABBILDUNG 5.13: KLASSENDIAGRAMM DES SCENEWIDGETSERVICE. .................................. 70 ABBILDUNG 6.1: SZENENGRAPH MIT ANGEFÜGTEM SUBGRAPH AUS LICHTQUELLE,
MARKER ZUR REPRÄSENTATION IN DER SZENE, ROTATIONS-DRAGGER UND
TRANSLATIONS-DRAGGER ................................................................. 75 ABBILDUNG 6.2: VIEWER-FENSTER MIT GELADENER SZENE UND ZWEI LICHTQUELLEN MIT
ROTATIONS-DRAGGERN; LINKS ROT LEUCHTENDES PUNKTLICHT,
RECHTS WEIß LEUCHTENDES SPOTLICHT ................................................ 76 CODE 5-A: METHODEN DES SCENEWIDGETSERVICE
71 CODE 6-A: REGISTRIERUNG AM SCENEWIDGETSERVICE
73 CODE 6-B: ERSTELLUNG DER WERKZEUGKISTE
74 CODE 6-C: ERSTELLUNG DER WERKZEUGE
74 CODE 6-D: FESTLEGEN DER AUSZUFÜHRENDEN METHODE
74 CODE 6-E: PARAMETERÜBERGABE AN DIE FUNKTION DES BELEUCHTUNGS-PLUG-INS
74 CODE 6-F: AUSWERTUNG DES NAMENS, DEN DAS EVENT MIT SICH FÜHRT
74
92
D Tabellenverzeichnis
TABELLE 2.1: KLASSIFIKATION VON WIDGETS NACH DACHSELT [DACHSELT 2004]. ...... 18 TABELLE 2.2: KLASSIFIKATION VON 3D-WIDGETS NACH DACHSELT [DACHSELT 2004]. 19 TABELLE 3.1: BEREICHE VON MANIPULATIONEN ....................................................... 35 TABELLE 4.1: KRITERIEN ZUR BEWERTUNG DER ORIENTIERUNGSHILFEN IM
KONTEXT DER ZIELSTELLUNG .............................................................. 44 TABELLE 4.2: POSITIONIERUNG UND INFORMATIONEN BEZÜGLICH RICHTUNG,
POSITION UND ABSTAND ................................................................... 46 TABELLE 4.3: KRITERIEN ZUR BEURTEILUNG DER MENÜ-VARIANTEN .............................. 48 TABELLE 4.4: ANORDNUNG DER ELEMENTE UND POSITION DES MENÜS ......................... 48 TABELLE 5.1: MERKMALE UND WERTE FÜR DIE TOOLS UND TOOLBOXEN ....................... 60 TABELLE 5.2: ÜBERSICHT DER ENTWICKELTEN HUD-ELEMENTE UND 3D-ICONS .............. 61 93