Dissertation
Unterstützung expliziter Articulation Work
Interaktive Externalisierung und Abstimmung mentaler Modelle
ausgeführt zum Zwecke der Erlangung des akademischen Grades eines
Doktors der technischen Wissenschaften unter der Leitung von
o. Univ.-Prof. DI Dr. Christian Breiteneder
E188 – Institut für Softwaretechnik und Interaktive Systeme
o. Univ.-Prof. DI Dr. Christian Stary
Institut für Wirtschaftsinformatik – Communications Engineering
Johannes Kepler Universität Linz
eingereicht an der Technischen Universität Wien
Fakultät für Informatik
von
Stefan Oppl
0055503
Reithoffergasse 2d/3, 4400 Steyr
Diese Dissertation haben begutachtet
o. Univ.-Prof. DI Dr. Christian Breiteneder o. Univ.-Prof. DI Dr. Christian Stary
Steyr, am 28. Juni 2010
 
 
Die approbierte Originalversion dieser Dissertation ist an der Hauptbibliothek 
der Technischen Universität Wien aufgestellt (http://www.ub.tuwien.ac.at). 
 
The approved original version of this thesis is available at the main library of 
the Vienna University of Technology  (http://www.ub.tuwien.ac.at/englweb/). 
 
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde
Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt und die den benutzten
Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.
Steyr, am 28. Juni 2010
Kurzfassung
Der Erfolg von (kooperativer) Arbeit beruht auf einem gemeinsamen Verständnis der be-
troffenen Abläufe durch die beteiligten Personen. Dieses gemeinsame Verständnis wird
der Theorie von Strauss zufolge durch die ständige und unbewusste Durchführung von
Tätigkeiten zur Abstimmung mit anderen Individuen erreicht. Beim Auftreten von Situa-
tionen, die von den Beteiligten als komplex und problematisch wahrgenommen werden,
müssen nach Strauss bewusst dezidierte Aktivitäten der Abstimmung und zum Errei-
chen einer gemeinsamen Sichtweise durchgeführt werden. Sowohl die Identifikation der
Notwendigkeit von Abstimmungsaktivitäten als auch deren Durchführung werden maß-
geblich von den individuellen Wahrnehmungen der beteiligten Personen beeinflusst. Auf
diesen Aspekt geht Strauss nicht ein, so dass auch Arbeiten, die sich bei der Entwicklung
von Instrumenten der Unterstützung der Abstimmung auf dessen Arbeiten beziehen, die
individuelle Dimension nicht explizit berücksichtigen. Wird diese individuelle Dimension
ignoriert, so hat dies negative Auswirkungen auf das Arbeitsergebnis. Ziel dieser Arbeit
ist deshalb die Unterstützung der Abstimmungsprozesse über Arbeitsabläufe unter ex-
pliziter Berücksichtigung der Bedürfnisse der beteiligten Individuen. Zu diesem Zweck
werden Methoden aus der Theorie der mentalen Modelle nach Johnson-Laird mit den
Anforderungen aus der Abstimmung von Arbeitsabläufen zusammengeführt.
Um die Abstimmung zu unterstützen, setzt der hier vorgestellte Ansatz die koopera-
tive Bildung und Diskussion diagrammatischer Modelle ein. Dieser Zugang ist aus der
Theorie der Bildung und Veränderung mentaler Modelle abgeleitet. Die Externalisie-
rung der mentalen Modelle in Form von diagrammatischen Modellen ist nach Seel ein
Weg zur Reflexion und Kommunikation derselben und ermöglicht so die Entwicklung
einer gemeinsamen Sichtweise auf den kooperativen Arbeitsablauf. Methodisch baut die
Arbeit auf Strukturlegetechniken und Concept Mapping auf, welche sich zur Externa-
lisierung mentaler Modelle eignen. Die dort vorgeschlagenen Methoden werden unter
Bezugnahme auf die Abstimmung von individuellen Sichtweisen auf Arbeitsabläufe zu-
sammengeführt. Wesentlich für die kooperative Anwendung ist deren Durchführung auf
einer durch mehrere Personen unmittelbar und gleichzeitig manipulierbaren Modellie-
rungsoberfläche. Die entwickelte Methodik wird deshalb durch ein Tabletop Interface –
eine horizontale Interaktionsoberfläche mit rechnerbasierten Unterstützungsfunktionen
– zu einem Instrument ergänzt, mit dem die Durchführung von Abstimmungsaktivitäten
unterstützt werden kann.
Das Tabletop Interface ermöglicht die kooperative Bildung von Modellen mittels physi-
schen Bausteinen, die auf der Interaktionsoberfläche platziert werden. Das Modell kann
so unmittelbar und simultan von mehreren Personen erfasst und manipuliert werden.
Technologisch basiert das System auf der Identifikation der Bausteine mittels Markern,
die durch eine Kamera in Echtzeit erfasst werden. Die erfasste Information wird durch
das System interpretiert, so dass Aktivitäten zur Modellbildung identifiziert werden kön-
nen. Die Darstellung von Information zum erstellten Modell erfolgt durch Rückprojektion
auf die Interaktionsoberfläche und einen Bildschirm, der als erweiterter Ausgabekanal für
nicht auf der Oberfläche darstellbare Information dient. Durch zusätzliche Rechnerun-
terstützung werden kooperationsunterstützende Maßnahmen wie die Wiederherstellung
vergangener Modellzustände ermöglicht. Die persistente Ablage der erstellten Modelle
erfolgt als Topic Map, einem standardisierten Datenformat zur flexiblen Repräsentation
semantischer Netze, das eine Wieder- und Weiterverwendbarkeit der erstellten Modelle
gewährleistet.
Die Effektivität der Unterstützung von Abstimmungsaktivitäten durch das System
wird im Rahmen einer empirischen Untersuchung untersucht. Dabei wird die Verwend-
barkeit des interaktiven Systems selbst, dessen Nutzen bei der Abstimmung mentaler
Modelle sowie letztendlich die Auswirkungen bei der Durchführung von Abstimmungs-
aktivitäten in Arbeitsprozessen untersucht. Die Ergebnisse zeigen, dass das Werkzeug
verständlich und benutzbar ist und das Instrument in seiner Gesamtheit sowohl positi-
ve Wirkungen auf die Kooperation zwischen den beteiligten Personen hat als auch die
Bildung einer gemeinsamen Sichtweise auf den betrachteten Arbeitsablauf hat.
Abstract
Successful (cooperative) work requires that the involved workers develop a common
understanding of the modalities of their interaction. According to Strauss, common un-
derstanding emerges from continuously and unconsciously conducted activities for ali-
gnment of understanding. In situation perceived to be complex or problematic by the
involved persons, Strauss suggests that alignment activities have to triggered and con-
ducted deliberately. Individual perceptions affect both, the identification of the need
for alignment and alignment itself. Strauss does not explicitly address this aspect in his
theory. Approaches that support alignment based upon Strauss’ work thus also largely
ignore the individual, cognitive dimension of alignment. Ignoring the individual dimen-
sion, however, has negative impact on the success of work processes. Accordingly, this
work aims at extending the scope of alignment support by explicitly considering the per-
ceptions and needs of individuals. The theory of mental models here is used to extend
Strauss’ concepts and develop effective support for developing a common understanding
of work processes.
Following the theory of mental model development by Seel, the cooperative creation of
diagrammatic models as representations of mental models can aid their alignment and
the development of a common understanding. Suitable methods for building representa-
tions of mental models include structure elaboration techniques and concept mapping.
Both methods have properties that are support the cooperative creation of models. In
this work, they are integrated to form a method that is useable in the context of the
alignment of cooperative work. The main feature for cooperation support is that mo-
deling takes places on a simultaneously accessible and physically manipulable modeling
surface. The method thus is complemented with a tabletop interface – a horizontally
mounted interaction surface that is augmented with computer support – to effectively
support the alignment of individual views on cooperative work processes.
Tangible tokens are used to cooperatively build models on the interaction surface. By
physically placing the tokens, the model can be manipulated simultaneously by several
people. Token identification is based on visual markers that are tracked by a camera in
real time. The gathered information is interpreted by the system to identify modeling
activities. Model information is displayed by back-projecting it onto the surface from
underneath. An traditional screen is provided as an additional output channel for in-
formation that cannot be displayed directly on the interaction surface. Cooperation is
further supported by additional features like reconstruction support for former model
states. Persistent model representation is based upon the standardized XML Topic Map
format, which allows for a reusable, self-contained representation of generic semantic
networks.
The systems’s effectiveness in supporting the alignment of work is tested in an empi-
rical study. In three steps, the system’s usability, its effects on the alignment of mental
models and the effectiveness in supporting the development of a common understanding
of work processes are examined. The results of the study show that the system is com-
prehensible and useable. Positive effects on both, the cooperation among people during
modeling and the alignment of individual views of cooperative work, have been observed.
für
Felix und Sabrina
Vorwort
Arbeiten wie diese entstehen nie ohne Unterstützung und Einfluss von außen. Zahlreiche
Menschen haben mich auf meinem Weg zum Abschluss dieser Arbeit begleitet. Diesen
Menschen möchte ich an dieser Stelle danken.
Prof. Alois Ferscha habe ich zu verdanken, dass sich das Feld der Forschung als per-
sönliche und berufliche Perspektive für mich auftat. Er nahm mich noch während meines
Informatik-Studiums an seinem Institut auf und ermöglichte mir erste Erfahrungen im
wissenschaftlichen Alltag zu sammeln. Für seine Anleitung und Unterstützung möchte
ich mich bedanken.
Andreas Auinger hat mir den Weg in in die interdisziplinäre Forschung eröffnet, indem
er zum richtigen Zeitpunkt an mich dachte und mich für meine heutige Stelle vorschlug.
Er stand mir danach als Bürokollege und Freund mit Rat und Tat zur Seite und ist
mir auch heute noch ein wichtiger Diskussionspartner. Meinen ehemaligen Kollegen Pe-
ter Eberle und Jeannette Hemmecke danke ich für die Erweiterung meines fachlichen
Horizonts, die Rückspiegelung meiner Arbeit aus anderen Disziplinen und ihren me-
thodischen Input zu den Grundlagen und zum empirischen Teil dieser Arbeit. In Peter
Eberles Garage entstand außerdem unter seiner federführenden Mitwirkung der Tisch,
der ein zentrales Element des hier vorgestellten Systems ist. Simon Vogl begleitet mich
seit Beginn meiner Tätigkeit an der Universität Linz und trug mit seinen Ideen und tech-
nischen Kenntnissen wesentlich zum aktuellen Entwicklungsstand des hier vorgestellten
Werkzeugs bei. Matthias Neubauer war und ist mir als Studierender, Diplomand und
nun Kollege eine große Stütze, wertvoller Diskussionspartner und Freund.
Auch meinen übrigen ehemaligen und aktuellen Arbeitskollegen gebührt Dank für ih-
re Unterstützung, ihr Verständnis und ihre Bereitschaft, meine Experimente über sich
ergehen zu lassen. An dieser Stelle ist auch den unzähligen Studierenden zu danken,
die an der Evaluierung des entwickelten Werkzeugs mitgewirkt haben. Ohne die Unter-
stützung meiner Diplomanden Florian Furtmüller, Thomas Feiner, Matthias Neubauer,
Josef Bohninger, Daniel Bindreiter und Patrick Wahlmüller wäre das Werkzeug heute
funktional nicht so erweiterbar und so umfassend evaluiert, wie es sich nun darstellt.
Prof. Christian Stary hat mich in den vergangenen fünf Jahren in meiner Denk- und
Arbeitsweise geprägt und diese fundamental verändert. Seiner Führung und Anleitung
ohne Vorgaben zu machen, seinem Vorbild und seiner Sichtweise auf wissenschaftliche
Arbeit ist es zu verdanken, dass diese Dissertation in der vorliegenden Form fertigge-
stellt wurde. Er hat mir ermöglicht, meinen fachlichen Horizont zu erweitern, über den
Tellerrand der Informatik hinaus zu sehen und „Unberechenbarkeit“ als wesentliches
Prinzip der Wissenschaften und den dort handelnden Akteuren zu erkennen. Nicht nur
in Forschung und Lehre habe ich von ihm fürs Leben gelernt.
Prof. Christian Breiteneder hat mich in seiner Arbeitsgruppe an der TU Wien aufge-
nommen, als meine interdisziplinären Ansprüche die Möglichkeiten an der Kepler Uni-
versität Linz überstiegen. Für seine Offenheit, seine jederzeitige Bereitschaft zur Unter-
stützung und die Begutachtung dieser Arbeit möchte ich mich herzlich bedanken.
Prof. Markus Peschl danke ich für die zahlreichen Diskussionen, die Motivation in
Zeiten, in denen kein Fortschritt erkennbar war und der Möglichkeit, mein System in
einem Beitrag zu seinem Buch über Kognition und Technologie im kooperativen Lernen
zu beschreiben. Dieser Beitrag bildete den Nukleus für die Niederschrift der Dissertation
und zwang mich, endlich mit dem Explizieren meiner Arbeit zu beginnen. Die leider viel
zu seltenen Treffen mit Prof. Tom Gross und Jürgen Steimle waren stets motivierend
für mich und bestärkten mich, die Dissertation endlich zu einem guten Abschluss zu
bringen.
Neben all diesen Personen aus dem beruflichen Umfeld gebührt vor allem meiner Fami-
lie besonderer Dank. Meine Eltern haben mir meine Neugier mit auf den Weg gegeben,
mir meine Ausbildung ermöglicht und mich immer in meinen Entscheidungen bestärkt.
Meiner Mutter danke ich außerdem für die tagelange akribische Korrektur dieser Arbeit,
durch die der Lesefluss nun nicht mehr durch Buchstabendreher und verirrte Beistriche
beeinträchtigt wird.
Sabrina hat mit mir seit nunmehr beinahe 10 Jahren alle privaten und beruflichen Hö-
hen gefeiert und Tiefen durchgestanden. Sie ergänzt und kompensiert meine chaotische
Ader perfekt und hat mir wann immer notwendig die vollkommene Vertiefung in die
Arbeit an meiner Dissertation ermöglicht. Gleichzeitig hat sie immer dafür gesorgt, dass
ich das „echte“ Leben nicht aus den Augen verliere und war dann ein Regulativ, wenn
mir der Blick für die Verhältnismäßigkeit meines Tuns abhanden kam. Danke für deine
Unterstützung und dein Verständnis.
Seit zweieinhalb Jahren zeigt mir Felix, was im Leben wirklich wesentlich ist. Sein
sonniges Gemüt und seine bedingungslose Liebe waren und sind mir ein stetiger Quell
der Freude und Motivation.
Steyr, am 28. Juni 2010
Inhaltsübersicht
1. Einführung 1
I. Methoden zur Unterstützung der Abstimmung kooperativer
Arbeit 19
2. Articulation Work 22
3. Mentale Modelle 76
4. Methodik und Anwendungszenarien 98
II. Interaktive Externalisierung und Abstimmung 112
5. Anforderungen an ein Werkzeug 115
6. Grundlagen der Realisierung und verwandte Arbeiten 121
7. Eingabe und Interpretation 173
8. Ausgabe 238
9. Persistierung 271
III. Evaluierung des Instruments 300
10.Konzeptuelle Einordnung des Werkzeugs 302
ix
11.Überblick über die empirische Untersuchung 328
12.Evaluierung der Verwendbarkeit des Werkzeugs 352
13.Evaluierung der Anwendung des Instruments 399
14.Evaluierung der durchgeführten Articulation Work 431
15.Schlussbetrachtungen 452
Anhang 476
A. Literatur zum Themengebiet Articulation Work 477
B. Daten der empirischen Untersuchung 492
Verzeichnisse 532
Abbildungsverzeichnis 532
Tabellenverzeichnis 535
Abkürzungsverzeichnis 537
Bildquellen 539
Publikationen im Kontext dieser Arbeit 542
Literaturverzeichnis 545
Lebenslauf 566
x
.
xi
Inhaltsverzeichnis
1. Einführung 1
1.1. Forschungsfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.2. Zusammenfassung der Zusammenhänge . . . . . . . . . . . . . . . 11
I. Methoden zur Unterstützung der Abstimmung kooperativer
Arbeit 19
2. Articulation Work 22
2.1. Begriffsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2. Ausprägungen von Articulation Work . . . . . . . . . . . . . . . . . . . . 25
2.2.1. Unterscheidung nach Fjuk, Smørdal und Nurminen . . . . . . . . 28
2.2.2. Unterscheidung nach Hampson und Junor . . . . . . . . . . . . . 31
2.2.3. Unterscheidung nach Færgemann et al. . . . . . . . . . . . . . . . 33
2.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3. Abzustimmende Arbeitsaspekte . . . . . . . . . . . . . . . . . . . . . . . 41
2.4. Unterstützung von Articulation Work . . . . . . . . . . . . . . . . . . . . 43
2.4.1. Vorgehen zur detaillierten Betrachtung . . . . . . . . . . . . . . . 44
2.4.2. Modeling Articulation Work in Software Engineering Processes . 45
2.4.3. Taking CSCW seriously: Supporting Articulation Work . . . . . . 48
2.4.4. Supporting articulation work using software configuration ma-
nagement systems . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4.5. Coordination Mechanisms: Towards a Conceptual Foundation of
CSCW Systems Design . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.6. Taking Articulation Work Seriously: An Activity Theoretical Ap-
proach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.4.7. TeamSpace: an environment for team articulation work and vir-
tual meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.8. Supporting different dimensions of adaptability in workflow mo-
deling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
xii
Inhaltsverzeichnis
2.4.9. Mundane knowledge management and microlevel organizational
learning: An ethological approach . . . . . . . . . . . . . . . . . . 60
2.4.10. Modelling Cooperative Work: Chances and Risks of Structuring . 61
2.4.11. Recursive Articulation Work in Ariadne: The Alignment of Mea-
nings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.4.12. Combining Communication and Coordination Toward Articulati-
on of Collaborative Activities . . . . . . . . . . . . . . . . . . . . 66
2.4.13. Interactive Process Models . . . . . . . . . . . . . . . . . . . . . . 67
2.4.14. Torres, a Conceptual Framework for Articulation Work across
Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.4.15. Gegenüberstellung und Zusammenfassung . . . . . . . . . . . . . 70
2.5. Thought processes und Articulation Work . . . . . . . . . . . . . . . . . 72
2.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.6.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 74
2.6.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 74
3. Mentale Modelle 76
3.1. Articulation Work und mentale Modelle . . . . . . . . . . . . . . . . . . 77
3.2. Begriffsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.3. Bildung und Veränderung mentaler Modelle . . . . . . . . . . . . . . . . 80
3.4. Externalisierung mentaler Modelle . . . . . . . . . . . . . . . . . . . . . 84
3.4.1. Methode des lauten Denkens . . . . . . . . . . . . . . . . . . . . 86
3.4.2. Strukturlegetechniken . . . . . . . . . . . . . . . . . . . . . . . . 89
3.4.3. Concept Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.5.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 96
3.5.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 97
4. Methodik und Anwendungszenarien 98
4.1. Durchführungsrahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.2. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2.1. Einarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2.2. Konzeptsammlung . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.3. Konzeptstrukturierung . . . . . . . . . . . . . . . . . . . . . . . . 104
4.2.4. Restrukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.3. Anwendungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.3.1. Verfeinerung mentaler Modelle . . . . . . . . . . . . . . . . . . . 106
4.3.2. Wissenstransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.3.3. Abstimmung mentaler Modelle . . . . . . . . . . . . . . . . . . . 108
4.3.4. Aushandlung mentaler Modelle . . . . . . . . . . . . . . . . . . . 109
4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.4.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 110
xiii
Inhaltsverzeichnis
4.4.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 111
II. Interaktive Externalisierung und Abstimmung 112
5. Anforderungen an ein Werkzeug 115
5.1. Anforderungen aus Strukturlegetechniken . . . . . . . . . . . . . . . . . . 116
5.2. Anforderungen aus Concept Mapping . . . . . . . . . . . . . . . . . . . . 116
5.3. Anforderungen aus Articulation Work . . . . . . . . . . . . . . . . . . . . 117
5.4. Grundlegende Technologieentscheidung . . . . . . . . . . . . . . . . . . . 118
5.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.5.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 119
5.5.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 119
6. Grundlagen der Realisierung und verwandte Arbeiten 121
6.1. Historischer Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.2. Lernprozesse und Tangible Interfaces . . . . . . . . . . . . . . . . . . . . 123
6.3. Kooperation und Tangible Interfaces . . . . . . . . . . . . . . . . . . . . 125
6.3.1. Intuitive und simultane Manipulierbarkeit . . . . . . . . . . . . . 126
6.3.2. Fokus-stärkende Wirkung . . . . . . . . . . . . . . . . . . . . . . 127
6.3.3. Awareness, Gestik und performative Bedeutung der Handlungen . 128
6.3.4. Externalisierungsfunktion und Rolle als Boundary Object . . . . 128
6.3.5. Implikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces . . . . . . 130
6.4.1. Bricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.4.2. Graspable User Interfaces . . . . . . . . . . . . . . . . . . . . . . 134
6.4.3. Tangible Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.4.4. Containers, Tokens und Tools . . . . . . . . . . . . . . . . . . . . 137
6.4.5. Tangible Objects Meaning . . . . . . . . . . . . . . . . . . . . . . 139
6.4.6. Das MCRpd Interaktions-Modell . . . . . . . . . . . . . . . . . . 140
6.4.7. Tokens und Constraints nach Ullmer . . . . . . . . . . . . . . . . 143
6.4.8. Degree of Coherence . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.4.9. Tokens und Constraints nach Shaer et al. . . . . . . . . . . . . . 147
6.4.10. Kategorien von TUI-Anwendungen . . . . . . . . . . . . . . . . . 149
6.4.11. Taxonomie für Tangible User Interfaces . . . . . . . . . . . . . . . 150
6.4.12. Tangible Bits: Beyond Pixels . . . . . . . . . . . . . . . . . . . . 152
6.4.13. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.5. Tabletop Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.5.1. Historische Entwicklung . . . . . . . . . . . . . . . . . . . . . . . 162
6.5.2. Aktuelle Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.6. Tabletop Interfaces zur Erstellung diagrammatischer Modelle . . . . . . . 166
6.6.1. Historische Entwicklung . . . . . . . . . . . . . . . . . . . . . . . 166
xiv
Inhaltsverzeichnis
6.6.2. Aktuelle verwandte Ansätze . . . . . . . . . . . . . . . . . . . . . 168
6.7. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.7.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 171
6.7.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 171
7. Eingabe und Interpretation 173
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion . . . . . . . . . . . 174
7.1.1. In Frage kommende technologische Ansätze . . . . . . . . . . . . 174
7.1.2. In Frage kommende Frameworks . . . . . . . . . . . . . . . . . . 181
7.1.3. Technologieentscheidung . . . . . . . . . . . . . . . . . . . . . . . 190
7.2. Konzeption und Umsetzung der Hardwarekomponenten . . . . . . . . . . 196
7.2.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.2.2. Tokens und Input-Werkzeuge . . . . . . . . . . . . . . . . . . . . 198
7.2.3. Eingabe auf der Tischoberfläche . . . . . . . . . . . . . . . . . . . 208
7.3. Benutzerinteraktion mit dem Werkzeug . . . . . . . . . . . . . . . . . . . 211
7.3.1. Hinzufügen und Verändern von Modellelementen . . . . . . . . . 211
7.3.2. Benennen von Modellelementen . . . . . . . . . . . . . . . . . . . 212
7.3.3. Verbinden von Modellelementen . . . . . . . . . . . . . . . . . . . 213
7.3.4. Löschen von Elementen und Verbindungen . . . . . . . . . . . . . 215
7.3.5. Einbettung von Zusatzinformation . . . . . . . . . . . . . . . . . 215
7.3.6. Kontrolle der Modellierungshistorie . . . . . . . . . . . . . . . . . 217
7.4. Erfassung der Benutzerinteraktion durch Software . . . . . . . . . . . . . 218
7.4.1. Interpretation der Rohdaten . . . . . . . . . . . . . . . . . . . . . 219
7.4.2. Stabilisierung der Erkennungsleistung . . . . . . . . . . . . . . . 221
7.4.3. Erkennung von Markierungen und Verbindungen . . . . . . . . . 226
7.4.4. Erkennung von geöffneten Tokens . . . . . . . . . . . . . . . . . . 228
7.4.5. Benennung von Modellelementen . . . . . . . . . . . . . . . . . . 231
7.4.6. Festlegung der Bedeutung von Modellelementen . . . . . . . . . . 233
7.4.7. Tracking des Modellzustandes . . . . . . . . . . . . . . . . . . . . 233
7.4.8. Verteilung des Modellzustandes . . . . . . . . . . . . . . . . . . . 235
7.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
7.5.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 237
7.5.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 237
8. Ausgabe 238
8.1. Auszugebende Information . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.2. Technologische Grundlage der Ausgabe . . . . . . . . . . . . . . . . . . . 239
8.2.1. Ansätze zur kohärenten Ausgabe . . . . . . . . . . . . . . . . . . 240
8.2.2. Ansätze zur entkoppelten Ausgabe . . . . . . . . . . . . . . . . . 243
8.2.3. Technologie-Entscheidung . . . . . . . . . . . . . . . . . . . . . . 245
8.2.4. Frameworks zur Ausgabe . . . . . . . . . . . . . . . . . . . . . . 247
8.3. Ausgabe von Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
xv
Inhaltsverzeichnis
8.3.1. Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.3.2. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
8.3.3. Ausgabe von Information zum Modell . . . . . . . . . . . . . . . 253
8.3.4. Ausgabe zur Kontrolle des Systems . . . . . . . . . . . . . . . . . 258
8.4. Umsetzung der Ausgabe mit Software . . . . . . . . . . . . . . . . . . . . 263
8.4.1. Ausgabe des Modellzustands . . . . . . . . . . . . . . . . . . . . . 265
8.4.2. Ausgabe der Modellierungshistorie . . . . . . . . . . . . . . . . . 266
8.4.3. Umsetzung der Wiederherstellungsunterstützung . . . . . . . . . 267
8.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
8.5.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 270
8.5.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 270
9. Persistierung 271
9.1. Topic Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
9.1.1. Topics, Subjects, Topic Names und Variants . . . . . . . . . . . . 275
9.1.2. Associations und Roles . . . . . . . . . . . . . . . . . . . . . . . . 277
9.1.3. Occurrences und Datatypes . . . . . . . . . . . . . . . . . . . . . 277
9.1.4. Metamodellierung in Topic Maps . . . . . . . . . . . . . . . . . . 278
9.1.5. Statements und Scopes . . . . . . . . . . . . . . . . . . . . . . . . 281
9.1.6. Reification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
9.1.7. Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
9.2. Abbildung von Modellen auf Topic Maps . . . . . . . . . . . . . . . . . . 283
9.2.1. Grundlegende Abbildung . . . . . . . . . . . . . . . . . . . . . . . 284
9.2.2. Abbildung des Metamodells . . . . . . . . . . . . . . . . . . . . . 285
9.2.3. Abgrenzung von Submodellen . . . . . . . . . . . . . . . . . . . . 288
9.2.4. Flexibilisierung der Abbildung . . . . . . . . . . . . . . . . . . . . 290
9.3. Technische Umsetzung der Persistierung von Modellen . . . . . . . . . . 290
9.3.1. Topic Map Engine . . . . . . . . . . . . . . . . . . . . . . . . . . 291
9.3.2. Dynamische Metamodelle . . . . . . . . . . . . . . . . . . . . . . 293
9.4. Export graphischer Repräsentationen . . . . . . . . . . . . . . . . . . . . 294
9.4.1. Ausgabeformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
9.4.2. Technische Umsetzung des graphischen Exports . . . . . . . . . . 296
9.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
9.5.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 299
9.5.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 299
III. Evaluierung des Instruments 300
10.Konzeptuelle Einordnung des Werkzeugs 302
10.1. Einordnung in den Bricks-Designraum . . . . . . . . . . . . . . . . . . . 302
10.2. Bestimmung der Eigenschaften des Graspable User Interfaces Ansatz . . 305
xvi
Inhaltsverzeichnis
10.3. Betrachtung im Lichte des Tangible Bits Ansatzes . . . . . . . . . . . . . 306
10.4. Einordnung in das Ordnungssystem von Holmquist et al. . . . . . . . . . 308
10.5. Einordnung in das Object-Meaning-Kontinuum . . . . . . . . . . . . . . 309
10.6. Betrachtung im Lichte des MCRpd-Modells . . . . . . . . . . . . . . . . 310
10.7. Einordnung in den Tokens+Constraints Kontext . . . . . . . . . . . . . . 312
10.8. Einordnung in das Framework nach Koleva et al. . . . . . . . . . . . . . 314
10.9. Spezifikation des TAC-Schemas nach Shaer et al. . . . . . . . . . . . . . 316
10.10.Einordnung in die Kategorien von TUI-Anwendungen . . . . . . . . . . . 319
10.11.Einordnung in die Taxonomie von Fishkin . . . . . . . . . . . . . . . . . 320
10.12.Betrachtung im Lichte der Retrospektive von Ishii . . . . . . . . . . . . . 324
10.13.Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
10.13.1.Eignung der konzeptuellen Ansätze zur Beschreibung von TUIs . 325
10.13.2.Verbesserungspotential für das Werkzeug . . . . . . . . . . . . . . 326
10.13.3.Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 327
10.13.4.Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 327
11.Überblick über die empirische Untersuchung 328
11.1. Zu untersuchende Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 329
11.1.1. Evaluierung der Verwendbarkeit des Werkzeugs . . . . . . . . . . 330
11.1.2. Evaluierung der Modellbildung . . . . . . . . . . . . . . . . . . . 330
11.1.3. Evaluierung der Effekte der Articulation Work . . . . . . . . . . . 331
11.2. Globales Untersuchungsdesign . . . . . . . . . . . . . . . . . . . . . . . . 332
11.2.1. Block 1: Technische Evaluierung . . . . . . . . . . . . . . . . . . 333
11.2.2. Block 2: Aushandlung von Zusammenarbeit 1 . . . . . . . . . . . 335
11.2.3. Block 3: Concept Mapping 1 . . . . . . . . . . . . . . . . . . . . . 337
11.2.4. Block 4: Aushandlung von Zusammenarbeit 2 . . . . . . . . . . . 339
11.2.5. Block 5: Concept Mapping 2 . . . . . . . . . . . . . . . . . . . . . 341
11.3. Eingesetzte Werkzeuge und Verfahren . . . . . . . . . . . . . . . . . . . . 343
11.3.1. Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
11.3.2. Signifikanztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
11.3.3. Korrelationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
11.3.4. Fragebögen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
11.3.5. Interaktionsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . 348
11.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
11.4.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 350
11.4.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 351
12.Evaluierung der Verwendbarkeit des Werkzeugs 352
12.1. Hypothesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
12.1.1. Konzeptuell begründete Hypothesen . . . . . . . . . . . . . . . . 353
12.1.2. Explorativ gebildete Hypothesen . . . . . . . . . . . . . . . . . . 355
12.2. Untersuchungsdesign und Durchführung . . . . . . . . . . . . . . . . . . 357
xvii
Inhaltsverzeichnis
12.2.1. Operationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 357
12.2.2. Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
12.3. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
12.3.1. Repräsentation diagrammatischer Modelle . . . . . . . . . . . . . 364
12.3.2. Kooperatives Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . 366
12.3.3. Einsetzbarkeit in unterschiedlichen Kontexten . . . . . . . . . . . 373
12.3.4. Wiederherstellung vergangener Modellzustände . . . . . . . . . . 376
12.3.5. Nicht-Behinderung . . . . . . . . . . . . . . . . . . . . . . . . . . 378
12.3.6. Gewöhnung an das Werkzeug . . . . . . . . . . . . . . . . . . . . 385
12.3.7. Herstellung von Verbindern . . . . . . . . . . . . . . . . . . . . . 388
12.3.8. Verwendung des Löschtokens . . . . . . . . . . . . . . . . . . . . 391
12.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
12.4.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 398
12.4.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 398
13.Evaluierung der Anwendung des Instruments 399
13.1. Hypothesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
13.1.1. Konzeptuell begründete Hypothesen . . . . . . . . . . . . . . . . 400
13.1.2. Explorativ gebildete Hypothesen . . . . . . . . . . . . . . . . . . 402
13.2. Untersuchungsdesign und Durchführung . . . . . . . . . . . . . . . . . . 402
13.2.1. Operationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 403
13.2.2. Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
13.3. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
13.3.1. Keine semantische Einschränkung der Externalisierung . . . . . . 411
13.3.2. Repräsentation beliebig umfangreicher Modelle . . . . . . . . . . 415
13.3.3. Reflexion des Modellierungsverlaufs . . . . . . . . . . . . . . . . . 417
13.3.4. Wirkung auf die Kooperation bei der Modellerstellung . . . . . . 420
13.3.5. Abbildung von Zusammenhängen ohne Verbinder . . . . . . . . . 424
13.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
13.4.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 429
13.4.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 430
14.Evaluierung der durchgeführten Articulation Work 431
14.1. Hypothesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
14.1.1. Konzeptuell begründete Hypothesen . . . . . . . . . . . . . . . . 432
14.2. Untersuchungsdesign und Durchführung . . . . . . . . . . . . . . . . . . 433
14.2.1. Operationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 433
14.2.2. Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
14.3. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
14.3.1. Abstimmung individueller Modelle . . . . . . . . . . . . . . . . . 436
14.3.2. Auswirkungen auf die Ergebnisse kooperativer Arbeit . . . . . . . 441
14.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
xviii
Inhaltsverzeichnis
14.4.1. Beitrag zur globalen Zielsetzung . . . . . . . . . . . . . . . . . . . 451
14.4.2. Weitere Verwendung der Ergebnisse . . . . . . . . . . . . . . . . 451
15.Schlussbetrachtungen 452
15.1. Zusammenfassung der Argumentation . . . . . . . . . . . . . . . . . . . . 453
15.2. Zusammenfassung der Evaluierung . . . . . . . . . . . . . . . . . . . . . 455
15.2.1. Empirische Untersuchung . . . . . . . . . . . . . . . . . . . . . . 455
15.2.2. Gegenüberstellung der empirischen und konzeptuellen Untersuchung457
15.3. Erfüllung der Anforderungen an das Werkzeug . . . . . . . . . . . . . . . 460
15.4. Bewertung hinsichtlich der globalen Zielsetzung . . . . . . . . . . . . . . 465
15.4.1. Wie kann die Durchführung undWirkung von „ArticulationWork“
charakterisiert werden? . . . . . . . . . . . . . . . . . . . . . . . . 466
15.4.2. Wie kann explizite „Articulation Work“ effektiv unterstützt werden?467
15.4.3. Globale Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . 470
15.5. Offene Aspekte und Entwicklungspotential . . . . . . . . . . . . . . . . . 471
15.5.1. Entwicklungspotential des Werkzeugs . . . . . . . . . . . . . . . . 472
15.5.2. Prüfung der effektiven Unterstützung . . . . . . . . . . . . . . . . 473
15.5.3. Alternative Anwendungsfelder . . . . . . . . . . . . . . . . . . . . 474
15.6. Schluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Anhang 476
A. Literatur zum Themengebiet Articulation Work 477
A.1. Literaturquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
A.2. Relevante Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
B. Daten der empirischen Untersuchung 492
B.1. Verfügbare Rohdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
B.2. Durchgeführte Auswertungen . . . . . . . . . . . . . . . . . . . . . . . . 493
B.2.1. Überblicksauswertung . . . . . . . . . . . . . . . . . . . . . . . . 494
B.2.2. Interaktionsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . 495
B.2.3. Deskriptive Parameter . . . . . . . . . . . . . . . . . . . . . . . . 495
B.2.4. Signifikanztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
B.2.5. Codierung offener Items . . . . . . . . . . . . . . . . . . . . . . . 497
B.3. Verwendete Fragebögen . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
B.3.1. Fragebögen aus Evaluierungsblock 1 . . . . . . . . . . . . . . . . 498
B.3.2. Fragebögen aus Evaluierungsblock 4 . . . . . . . . . . . . . . . . 506
B.3.3. Fragebögen aus Evaluierungsblock 5 . . . . . . . . . . . . . . . . 523
Verzeichnisse 532
xix
Inhaltsverzeichnis
Abbildungsverzeichnis 532
Tabellenverzeichnis 535
Abkürzungsverzeichnis 537
Bildquellen 539
Publikationen im Kontext dieser Arbeit 542
Literaturverzeichnis 545
Lebenslauf 566
xx
1. Einführung
„No one person embodies the requisite knowledge to comprehend complex organizational
problems, or the requisite variety to clarify equivocal issues“ (Tyre und Von Hippel, 1997)
An dieser Aussage begründen Tyre und Von Hippel die unbedingte Notwendigkeit zur
Kooperation bei der Durchführung von Arbeit in Organisationen. Arbeit in Organisation
ist ein inhärent kooperatives System (Helmberger und Hoos, 1962) zur Erreichung eines
Ziels (Semmer und Udris, 2004), in dem das Ziel nur durch das Zusammenwirken der
Beiträge aller beteiligten Individuen erreicht werden kann (Strauss, 1985) (Tyre und
Von Hippel, 1997). Diese Individuen haben unterschiedliche Kenntnisse, Fähigkeiten
und Interessen, die zusammengeführt und aufeinander abgestimmt werden müssen um
Kooperation zu ermöglichen (Schmidt, 1994).
Griffin und Hauser (1992) fassen in ihrer Arbeit eine Reihe von Studien zusammen,
die eine starke Korrelation zwischen funktionierender Kommunikation und Kooperati-
on in Unternehmen und dem Erfolg neuer Produkte belegen. Auch bei Untersuchungen
von Arbeitsabläufen selbst konnte die Relevanz von Kooperation zwischen Individuen
bestätigt werden. Hinsichtlich der Relevanz von Kooperation zwischen Organisationen
beschreiben Kumar und Van Dissel (1996) die Risiken, die in organisationsübergreifen-
den Arbeitsprozessen auftreten können. Sowohl in klassischen organisationsübergreifen-
den Wertschöpfungsketten als auch in stärker vernetzten Organisationen sind den Au-
toren zufolge potentiellen Kosten der Kooperation zwischen den beteiligten Instanzen
im Allgemeinen als das Auftretens von unterschiedlichen Interpretationen der Modalitä-
ten der Zusammenarbeit im Speziellen wesentliche zu berücksichtigende Aspekte. Tsai
(2002) zeigt in einer empirischen Studie die positive Wirkung von kooperationsfördern-
den Maßnahmen auch für Anwendungsfälle innerhalb von Organisationen. Insbesondere
Tätigkeiten zur Wissensteilung und Informationsaustausch können sich demnach positiv
auf Fähigkeiten der Organisation („organizational capabilities“) auswirken. Phua und
Rowlinson (2004) weisen die Relevanz von Kooperation auf Ebene der beteiligten Perso-
nen für Projekte im Baugewerbe empirisch nach. Roy (2001) zeigt anhand von Studien,
dass die Abstimmung der Zusammenarbeit in Organisationen ein kritischer Erfolgsfak-
tor ist. Erfolgt sie nicht oder ist sie nicht erfolgreich, so leidet darunter die Fähigkeit zur
Zielerreichung. Individuen, die ähnliche Denkmuster („cognitive processes“) entwickelt
haben, arbeiten besser zusammen und liefern bessere Ergebnisse, als Gruppen, in denen
dies nicht der Fall ist (Roy, 2001).
1
1. Einführung
Eine Beschäftigung mit den Möglichkeiten zur Unterstützung kooperativer Arbeit und
der Verbesserung derselben ist deshalb ein vielfach adressiertes Thema der Forschung
vor allem in der Soziologie (etwa Strauss (1993) oder Suchman (1995)) oder den Or-
ganisationswissenschaften (etwa Argyris und Schön (1978), Kim (1993) oder Firesto-
ne und McElroy (2003)) und führte auch zur Bildung neuer Forschungsfelder wie der
„Computer-supported Cooperative Work“ (CSCW – nach Grudin (1994) etwa ab Mitte
der 1980er-Jahre). Die Einbindung von Informationtechnologie zur Unterstützung ko-
operativer Arbeit eröffnet neue Möglichkeiten der Zusammenarbeit und beseitigte viele
Hindernisse – vor allem jene im Zusammenhang, die im Zusammenhang mit Kommunika-
tion und der Verfügbarkeit von Information stehen (Grudin, 1988). Bei der Entwicklung
von Systemen, die kooperative Arbeit unterstützen, müssen nach Grudin (1988) zwei As-
pekte beachtet werden: der Verständnis der zu unterstützenden Phänomene und Abläufe
in der Arbeitsrealität der betroffenen Personen1 sowie das Verständnis der Arbeitsweise
der betroffenen Individuen selbst2.
Ein Ansatz, der im Rahmen von CSCW zur Erklärung kooperativer Arbeit und zur
Ableitung von Unterstützungsmaßnahmen herangezogen wurde Schmidt und Bannon
(1992), ist das Konzept der „Articulation Work“ Strauss (1985). „Articulation Work“
erklärt die nach Roy (2001) – wie oben zitiert – erfolgskritischen Prozesse der Abstim-
mung von Zusammenarbeit und bildet die Grundlage für eine Vielzahl von Ansätzen
zur Unterstützung derselben (etwa (Cabitza et al., 2006), Raposo et al. (2004) oder
Davenport (2002)). In der Literatur sind jedoch keine Arbeiten zu identifizieren, die
den Zusammenhang zwischen der Verwendung von „Articulation Work“ als Grundlage
der Entwicklung von Unterstützungsmaßnahmen und der Berücksichtigung beider von
Grudin (1988) formulierten Forderungen untersuchen bzw. bestätigen. Dies ist jedoch
notwendig, um die Unterstützung kooperativer Arbeit in ihrer Gesamtheit – also un-
ter Berücksichtigung sowohl der kooperativen Arbeitsprozesse sowie der Beiträge der
beteiligten Individuen – sicherstellen zu können (Grudin, 1988).
Das Konzept „Articulation Work“ wird von Strauss (1985) zur Beschreibung der un-
terschiedlichen Qualitäten von Tätigkeiten im Rahmen kooperativer Arbeit eingeführt.
Es werden damit all jene Tätigkeiten erfasst, die der Planung und gegenseitigen Ab-
stimmung kooperativer Arbeit sowie der Auflösung etwaig auftretender Unklarheiten
oder Hindernisse bei der Zielerreichung dienen. Komplementär dazu bezeichnet Fujimura
(1987) jenen Anteil an Arbeit, der der unmittelbaren Zielerreichung bzw. der Wertschöp-
fung dient, als „Production Work“. Im Sinne von Strauss dient die „Articulation Work“
also dazu, die „Production Work“ zu ermöglichen und aufrecht zu erhalten oder deren
1„We need to have a better understanding of how groups and organizations function and evolve than is
reflected in most of the systems that have been developed. [. . . ] [One approach is to] start out with
a problem situation defined by workers, and work beside them a long time in order to develop a new
system that is ’owned’ by the workers. . . “ (Grudin, 1988, S.90)
2„If we are going to support groups that include any diversity at all, we will have to learn much more
about how different kinds of people work.“(Grudin, 1988, S.91)
2
1. Einführung
Durchführbarkeit wieder herzustellen. Entsprechend der Grundannahme von (Strauss,
1985), dass jeder Arbeitsablauf ein inhärent kooperativer Vorgang ist, ermöglicht bzw.
erhält „Articulation Work“ also eine funktionierende Kommunikation und Zusammen-
arbeit in Arbeitsabläufen. Zentral ist dabei vor allem die gegenseitigen Offenlegung der
Annahmen aller beteiligten Personen, die den individuellen Arbeitsbeiträgen zugrunde
liegen3. Die Arbeiten von Strauss haben rein deskriptiven Charakter, sie beschreiben
das beobachtbare Phänomen des Auftretens von „Articulation Work“, treffen aber keine
Aussagen über deren Wirkmechanismen oder etwaige Möglichkeiten zur Unterstützung
derselben.
„Articulation Work“ ist nach Strauss integraler Bestandteil jedes kooperativen Ar-
beitsablaufs. Jene sozialen, unbewusst ausgeführten Tätigkeiten, die der Abstimmung
der individuellen Arbeitsbeiträge dienen, bezeichnet Strauss (1988) bzw. Fjuk et al.
(1997) als implizite „Articulation Work“. Mit steigender Komplexität der „Production
Work“ steigt auch der Aufwand der dazu notwendigen „Articulation Work“ an (Strauss,
1988). Die Komplexität steigt hier mit der Anzahl der benötigten Arbeitsschritte, den
dazu benötigten Kompetenzen und der Anzahl der involvierten Personen. Je komplexer
(„problematic“) eine Interaktion ist, desto notwendiger wird nach (Strauss, 1988) eine
explizite Beschäftigung mit dem Vorgang der Artikulation. Werden Tätigkeiten in die-
sem Rahmen bewusst durchgeführt, so spricht man von expliziter „Articulation Work“
(Strauss, 1988) (Fjuk et al., 1997).
Der Begriff der „problematischen Interaktion“ bedarf einer näheren Betrachtung, um
als Kriterium der Abgrenzung zwischen impliziter und expliziter „Articulation Work“
herangezogen werden zu können. Strauss zitiert diesbezüglich Hughes unmittelbar nach
seiner Definition von „problematic interaction“: „[O]ne man’s routine of work is made
up of the emergencies of other people“ (Hughes, 1971, zitiert nach (Strauss, 1993)). Das
Merkmal, an dem die Notwendigkeit der Durchführung expliziter „Articulation Work“
begründet wird, ist demnach also ausschließlich durch individuelle Wahrnehmung beur-
teilbar. Die bewusste Durchführung von Abstimmungsaktivitäten ist immer dann not-
wendig, wenn zumindest eine der beteiligten Personen die Arbeitssituation als „proble-
matisch“ wahrnimmt. Wie bereits oben erwähnt, beschreibt Strauss in seinen Arbeiten
zwar das Phänomen „Articulation Work“ und dessen Wirkung (also im Wesentlichen was
„Articulation Work“ ist), verzichtet aber auf eine detaillierte Betrachtung der Abläufe
und Tätigkeiten bei der Durchführung der derselben (also wie „Articulation Work“ funk-
tioniert). Insbesondere ignoriert er den individuellen Aspekt von „Articulation Work“,
also jene die kognitiven Phänomene, die durch „Articulation Work“ beeinflusst werden
bzw. die die Auslöser für deren Durchführung sind. Strauss ist sich dieser Auslassung
3„Reconciling incommensurate assumptions and procedures in the absence of enforceable standards is
the essence of articulation.“(Gerson und Star, 1986, S. 266)
3
1. Einführung
bewusst4, und bezeichnet diese kognitiven Vorgänge in späteren Arbeiten (etwa (Strauss,
1993)) als wichtig für das Verständnis der Abläufe bei der Durchführung von „Articula-
tion Work“, ohne jedoch näher auf diese einzugehen. Diese Auslassung führt dazu, dass
die von Grudin (1988) formulierte Forderung nach einem Verständnis der individuellen
Arbeitsweisen bei kooperativer Arbeit bei der ausschließlichen Verwendung des Konzepts
der „Articulation Work“ nicht erfüllt werden kann. Dies hat Auswirkungen auf spätere
Arbeiten anderer Autoren, die sich der Unterstützung von „Articulation Work“ wid-
men (etwa Schmidt und Bannon (1992), Simone et al. (1999) oder Baker und Millerand
(2007)).
Durch die Fokussierung auf die soziale Dimension von Arbeit im Allgemeinen und „Ar-
ticulation Work“ im Besonderen berücksichtigen die vorgeschlagenen Unterstützungsan-
sätze ebenfalls vorrangig auf die Unterstützung sozialen (Kommunikations-)Prozesse. Als
Konsequenz sind die meisten Ansätze vor allem zur Unterstützung impliziter „Articulati-
on Work“ geeignet und berücksichtigen die Möglichkeit des Auftretens „problematischer
Interaktionen“ nicht explizit. Deutlich wird dies beispielsweise bei den Arbeiten von (Sa-
rini und Simone, 2002a) – die Autoren schlagen ein System vor, dass die Durchführung
von „Articulation Work“ in domänenübergreifenden Arbeitssituationen unterstützen soll
– ein wesentliches Problem ist den Autoren zufolge hier die Sicherstellung eines gemeinsa-
men Begriffsverständnisses. Der Ansatz der Unterstützung im Arbeitsablauf selbst wird
detailliert beschrieben. Durch die rechnerbasierte Identifikation und Anzeige analoger
Begrifflichkeiten aus den betroffenen Domänen soll der soziale Kommunikationsprozess
ermöglicht bzw. erleichtert werden. Der Aspekt der Erhebung der Begrifflichkeiten und
deren Zuordnung zueinander – also jener Aspekt, der die einzelnen Individuen und de-
ren Wahrnehmung der Domänen involviert – wird nur am Rande und eher oberflächlich
behandelt5.
Arbeiten, die sich mit dem Vorgang der Abstimmung von Arbeit beschäftigen, oh-
ne sich explizit auf Strauss’ Konzept von „Articulation Work“ zu beziehen (wie et-
wa (Jørgensen, 2004)), berücksichtigten häufig auch stärker den Aspekt der konkreten
Durchführung von „Articulation Work“ und eignen sich durch ihren Fokus auf die dezi-
dierte Unterstützung des Abstimmungsprozesses an sich (und nicht nur die Schaffung der
dazu notwendigen Rahmenbedingungen) auch für explizite „Articulation Work“. Auch
in diesen Fällen erfolgt jedoch die Berücksichtigung der Rolle der beteiligten Individuen
und deren Unterstützung nur in Einzelfällen (etwa bei Herrmann et al. (2002)), womit
die Forderung von Grudin (1988) wiederum nicht erfüllt werden können.
4„[. . . ] many social scientist pay almost no attention to interior activity: ignoring it, taking it for
granted, but leaving it unexamined, or giving it the kind of abstract but not very detailed analysis
[. . . ]“(Strauss, 1993, S. 131)
5„For sake of testing the integration we are aiming at, we defined the simplest protocol: all the users
involved in the reconciliation process can communicate among themselves to define the correspon-
dences, while a single Actor assumes the Role of Manager of the Reconciliation Artifact and is in
charge of keeping it updated.“(Sarini und Simone, 2002a, S. 10)
4
1.1. Forschungsfragen
Die Unterstützung expliziter „Articulation Work“ ist also ein bislang nur selten ex-
plizit adressiertes Themenfeld. Durch die historische Entwicklung des Forschungsgebiets
bedingt wurde die Rolle der beteiligten Individuen dabei nur am Rande berücksichtigt
(was wiederum zur Fokussierung auf Maßnahmen zu führt, die auf die Unterstützung von
sozialen Abstimmungsprozessen im Arbeitsablauf – also impliziter „Articulation Work“
– abzielen). In dieser Arbeit werden deshalb die Möglichkeiten zur Unterstützung explizi-
ter „Articulation Work“ durch die Berücksichtigung der Rolle der beteiligten Individuen
erfasst und daraus ein konkretes Unterstützungsinstrument entwickelt. Um die tatsäch-
liche Unterstützung von „Articulation Work“ nachzuweisen, wird dessen Effektivität im
Kontext der „Production Work“ geprüft. Zusammengefasst kann die globale Zielsetzung
dieser Arbeit wie folgt beschreiben werden:
Globale Zielsetzung
In der vorliegenden Arbeit sind die Möglichkeiten zur methodischen Unter-
stützung von expliziter Articulation Work unter Berücksichtigung relevanter
Theoriebildungen zur Rolle der beteiligten Individuen zu erfassen, auf Ba-
sis dieser Erkenntnisse geeignete Methoden auszuwählen, diese in einem
Instrument umzusetzen und dessen Effektivität im Kontext der Production
Work zu prüfen.
1.1. Forschungsfragen
Aus der oben formulierten globalen Zielsetzung müssen zur strukturierten Bearbeitung
detaillierte Fragestellungen abgeleitet werden. Die formulierten Forschungsfragen und
deren detaillierte Fragestellungen bilden die Ankerpunkte des inhaltlichen Aufbaus dieser
Arbeit und werden in allen folgenden Kapiteln referenziert, um den Bezug zur globalen
Zielsetzung herzustellen. In Abbildung 1.1 sind die Forschungsfragen und Fragestellun-
gen sowie deren Beziehung untereinander nochmals graphisch dargestellt.
In der globalen Zielsetzung wird die Unterstützung expliziter „Articulation Work“ ge-
fordert. Um diese Forderung zu erfüllen, ist es notwendig, das Konzept der „Articulation
Work“ zu untersuchen, um Ansatzpunkte für die exakte Abgrenzung expliziter „Articu-
lation Work“, deren Unterstützung sowie der Beurteilung der effektiven Durchführung
derselben zu erfassen. Dies ist Gegenstand der ersten Forschungsfrage.
5
1.1. Forschungsfragen
Forschungsfrage 1
Wie kann die Durchführung und Wirkung von „Articulation Work“ charak-
terisiert werden?
Im Rahmen der ersten Forschungsfrage können mehrere voneinander unabhängig zu
bearbeitende Fragestellungen identifiziert werden, deren Beantwortung und Verknüpfung
letztendlich zur Beantwortung der Forschungsfrage selbst führt.
Ein Aspekt der ersten Forschungsfrage ist die Klärung des Begriffs „Articulation Work“
selbst. Oben wurde bereits angedeutet, wie „Articulation Work“ von anderen Teilen eines
Arbeitsablaufs abgegrenzt werden kann. Die Beschreibung der Durchführung von „Arti-
culation Work“, also der möglichen Tätigkeiten und Rahmenbedingungen, bedarf aber
einer detaillierten Betrachtung der existierenden Literatur. Die Wirkung von „Articula-
tion Work“ (also: „Woran zeigen sich Konsequenzen der Durchführung von Articulation
Work und wie können diese ausgeprägt sein?“) muss ebenfalls Gegenstand der Betrach-
tung sein, um Ansatzpunkte zur Beurteilung deren Effektivität identifizieren zu können.
Aus diesen beiden Aspekten ergibt sich Fragestellung 1.
Fragestellung 1 Was ist „Articulation Work“ und wie wirkt sie im Arbeitsprozess?
„Articulation Work“ dient der Beseitigung „problematischer“ Situationen in der „Pro-
duction Work“. Die Einschätzung, ob eine Situation „problematisch“ ist und ob die „Pro-
bleme“ beseitigt wurden, obliegt jedoch der subjektiven Einschätzung der handelnden
Individuen. Auch die Entscheidung zur Durchführung expliziter „Articulation Work“
(aufgrund von implizit nicht auflösbaren wahrgenommenen „Problemen“) obliegt den
involvierten Personen. Die Durchführung von „Articulation Work“ ist damit wesentlich
von den handelnden Individuen beeinflusst, wird von diesen angestossen und auch wieder
beendet. Für die Betrachtung der Möglichkeiten zur Unterstützung von „Articulation
Work“ ist es deshalb von Interesse, wie die beteiligten Individuen beurteilen, ob eine
Situation „problematisch“ ist und ob dies nach der Durchführung von Tätigkeiten im
Rahmen von „Articulation Work“ nicht mehr der Fall ist (und diese deshalb beendet
werden kann). Der Aspekt der individuellen Wahrnehmung und Denkprozesse wird von
Strauss (1993, S. 131) als wichtig für die Erklärung von „Articulation Work“ bezeichnet,
jedoch explizit nicht weiter betrachtet. Zur Beantwortung der Fragestellung 2 ist des-
halb die Betrachtung anderer, auf die Wahrnehmungs- und Denkprozesse der beteiligten
Individuen eingehender Theorien notwendig.
6
1.1. Forschungsfragen
Fragestellung 2 Wie kann die Wahrnehmung von Arbeitsabläufen durch die an diesen
beteiligten Individuen erklärt werden?
Die Beantwortung der beiden bisher formulierten Fragestellungen ermöglicht eine um-
fassende Charakterisierung von „Articulation Work“ sowohl hinsichtlich deren Durch-
führung als auch deren Wirkung auf die „Production Work“. Die Beantwortung der
Forschungsfrage geht insofern über den aktuellen Stand der Literatur hinaus, als dass
sie auch die beteiligten Individuen vor, während und nach der Durchführung von „Ar-
ticulation Work“ in die Betrachtung mit einbezieht. Durch die Erweiterung des Be-
trachtungsbereichs ergeben sich potentiell neue Ansatzpunkte für die Unterstützung
von „Articulation Work“, die in der zweiten Forschungsfrage erfasst werden sollen.
Forschungsfrage 2
Wie kann explizite „Articulation Work“ effektiv unterstützt werden?
Auch die zweite Forschungsfrage bedarf zur umfassenden Bearbeitung der Untertei-
lung in mehrere Fragestellungen, die sich aus der Formulierung der globalen Zielsetzung
ergeben. Im Gegensatz zur ersten Forschungsfrage sind die Fragestellung hier nicht un-
abhängig voneinander bearbeitbar sondern bauen zum Teil aufeinander auf. Die ersten
beiden Fragestellungen beschäftigen sich mit der Unterstützung von „Articulation Work“
und stellen sowohl die methodischen Möglichkeiten als auch die konkrete Umsetzung dar.
Die zweiten beiden Fragestellungen fokussieren auf die geforderte „effektive Unterstüt-
zung“. Hier wird im ersten Schritt geklärt, woran sich die effektive Unterstützung von
„Articulation Work“ zeigt und wie diese beurteilt werden kann. Im zweiten Schritt wird
das umgesetzte Instrument in diesem Sinne geprüft.
Bei der Betrachtung der Unterstützungsmöglichkeiten für „Articulation Work“ muss
zwischen deren impliziter und expliziter Ausprägung unterschieden werden. Implizite
„Articulation Work“ ist ein nicht formalisierter Prozess, der von den beteiligten In-
dividuen unbewusst durchgeführt wird. Die Unterstützungsmöglichkeiten beschränken
sich hier auf die Schaffung der sozialen bzw. technologischen Rahmenbedingungen, die
die Durchführung impliziter „Articulation Work“ ermöglichen. Explizite „Articulation
Work“ basiert hingegen auf der bewussten Beschäftigung der Individuen mit der „pro-
blematischen“ Arbeit. Sie hat das Ziel, einen Zustand herzustellen, in dem implizite
„Articulation Work“ (wieder) möglich ist, d.h. in dem die beteiligten Individuen die
Situation nicht mehr als zu komplex bzw. „problematisch“ wahrnehmen. Bei der Unter-
stützung expliziter „Articulation Work“ ist es deshalb sinnvoll, vor allem auch Methoden
7
1.1. Forschungsfragen
zur Unterstützung der Individuen im Prozess der Durchführung von „Articulation Work“
zu erfassen.
Fragestellung 3 Welche Methoden können zur Unterstützung von „Articulation Work“
herangezogen werden?
Wie oben bereits erwähnt, ist die Unterstützung impliziter „Articulation Work“ ein
umfassend erforschtes Gebiet, während kaum Arbeiten zur Unterstützung expliziter „Ar-
ticulation Work“ vorhanden sind. Diese Hypothesen werden durch die Beantwortung
der Fragestellung 3 verifiziert. Gelingt dies, kann an dieser Stelle auf die Unterstüt-
zung expliziter „Articulation Work“ fokussiert werden. Die ermöglicht gleichzeitig eine
Fokussierung auf Methoden, die im Sinne der obigen Ausführungen die beteiligten In-
dividuen bei der Durchführung von expliziter „Articulation Work“ unterstützen. Diese
Methoden sind in der Folge in einem Instrument umzusetzen. Als „Instrument“ wird an
dieser Stelle die Gesamtheit aller Maßnahmen zur Unterstützung der Durchführung der
Methoden bezeichnet. Die Auswahl der geeigneten Methoden sowie die Umsetzung in
einem Instrument sind Gegenstand der Fragestellung 4.
Fragestellung 4 Wie kann ein Instrument zur Unterstützung von expliziter „Articula-
tion Work“ umgesetzt werden?
Die Forderung nach einer effektiven Unterstützung von expliziter „Articulation Work“
bedingt die Festlegung des Effektivitätskriteriums. Unter Berücksichtigung der obigen
Ausführungen sind einerseits die Durchführung (sowohl deren grundsätzliche Ermögli-
chung als auch die Durchführung im Sinne der vorgeschlagenen Methodik) und ande-
rerseits die Wirkung der „Articulation Work“ (sowohl auf individueller Ebene als auch
auf Ebene der „Production Work“) mögliche Merkmale, die hinsichtlich der Effektivität
der Unterstützung beobachtet werden können. Die Festlegung der konkreten Form der
Beurteilung hängt von den Ergebnissen der Forschungsfrage 1 ab und wird im Rahmen
der Bearbeitung von Fragestellung 5 beantwortet.
Fragestellung 5 Wie kann die Effektivität der Unterstützung von expliziter „Articula-
tion Work“ beurteilt werden?
Die Beurteilung des umgesetzten Instruments anhand des Kriteriums der effektiven
Unterstützung von „Articulation Work“ bildet den letzten Schritt in der Bearbeitung
der Forschungsfrage 2. Die Beantwortung der Forschungsfrage ist nur dann möglich, wenn
das aus der Theorie abgeleitete Instrument tatsächlich eine Möglichkeit zur effektiven
Unterstützung von „Articulation Work“ darstellt. Zur Bearbeitung dieser Fragestellung
müssen sowohl die Fragestellung 4 als auch die Fragestellung 5 abgeschlossen sein.
Fragestellung 6 Ermöglicht das Instrument die effektive Durchführung von expliziter
„Articulation Work“?
8
1.1. Forschungsfragen
Die Beantwortung der Forschungsfrage 2 erfolgt durch die Darstellung eines möglichen
Instruments für die Unterstützung expliziter „Articulation Work“. Kann die Effektivität
der Unterstützung durch dieses Instruments bestätigt werden, so kann bei Beantwortung
aller vorangegangener Fragestellungen auch die globale Zielsetzung als erfüllt angesehen
werden.
Die Zusammenhänge zwischen der globalen Zielsetzung, den Forschungsfragen und den
einzelnen Fragestellungen sind in Abbildung 1.1 nochmals graphisch zusammengefasst.
Abbildung 1.1.: Forschungsfragen und Fragestellungen
9
1.2. Aufbau der Arbeit
Diese Fragestellungen müssen im Rahmen der Durchführung dieser Arbeit beantwortet
werden. Dazu wird in der Zusammenfassung jedes Kapitels auf diese Fragen referenziert
und der jeweilige Beitrag zu deren Beantwortung identifiziert. In den Schlussbetrach-
tungen in Kapitel 15 ist die globale Zielsetzung schließlich wieder aufzugreifen und einer
abschließenden Bewertung hinsichtlich ihrer Erfüllung zu unterziehen.
1.2. Aufbau der Arbeit
In diesem Abschnitt wird die Struktur der Arbeit auf globaler Ebene dargestellt. Zusätz-
lich wird der inhaltliche Aufbau der einzelnen Kapitel zueinander in Beziehung gesetzt
und so der rote Faden durch die Arbeit transparent gemacht.
Die hier vorgestellte Struktur ist auszugsweise auch am Beginn jedes Kapitels beschrie-
ben und graphisch dargestellt, um die Einordnung der Kapitel in den Gesamtzusammen-
hang der Arbeit zu erleichtern.
1.2.1. Überblick
Die Arbeit gliedert sich inhaltlich in drei große Teile, die durch das Einleitungs- und
Schlusskapitel eingerahmt werden.
Teil I behandelt die der Unterstützung von „Articulation Work“ zugrunde liegenden
Forschungsgebiete und erfasst die in diesen vorgeschlagenen konkreten Maßnahmen und
Methoden zur Unterstützung. Der Teil deckt damit die Beantwortung der ersten oben
formulierten Forschungsfrage ab und trägt durch die Betrachtung des methodischen Teils
der Unterstützung bereits zur Beantwortung der Forschungsfrage 2 bei. Im Einzelnen
umfasst Teil I ein Kapitel über „Articulation Work“ (Fragestellung 1, Kapitel 2) und
ein Kapitel über „Mentale Modelle“ (Fragestellung 2, Kapitel 3). Teil I endet mit einem
Kapitel über Methodik der Anwendungsszenarien, in dem beschrieben wird, wie mentale
Modelle für die Verwendung für „Articulation Work“ externalisiert und abgestimmt wer-
den können und trägt damit bereits zur Forschungsfrage 2 bei (Fragestellung 3, Kapitel
4).
Teil II behandelt die Umsetzung des Werkzeugs selbst. Er trägt damit wesentlich zur
Beantwortung der zweiten oben formulierten Forschungsfrage bei, indem er das bislang
auf methodischer Ebene beschriebene Unterstützungsinstrument technisch vervollstän-
digt. Das erste Kapitel greift die Ergebnisse des ersten Teils auf und leitet daraus die
Anforderungen an das Werkzeug ab (Teil der Beantwortung der Fragestellung 4, Kapitel
5). In Kapitel 6 werden die konzeptuellen Grundlagen für die Implementierung aus dem
Kontext von Tangible Interfaces heraus aufgearbeitet. Die Kapitel 7, 8 und 9 beschreiben
nacheinander die technische Umsetzung des Werkzeugs – beginnend von den Eingabe-
10
1.2. Aufbau der Arbeit
kanälen über die Ausgabekanäle bis zu Persistierung der Modelle. Sie beantworten also
die Fragestellung 4.
Teil III behandelt die Evaluierung des Werkzeugs. Er deckt damit im Wesentlichen
den zweiten Teil der zweiten Forschungfrage ab, klärt das Konzept der „effektiven Un-
terstützung von Articulation Work“ und prüft diese für das entwickelt Instument. Da-
bei beginnt Kapitel 10 mit einer konzeptuellen Betrachtung des umgesetzten Systems
(also einer theoretischen Einordnung des Werkzeugs auf Basis der Ergebnisse von Ka-
pitel 6, den konzeptuellen Grundlagen der Implementierung). In Kapitel 11 werden die
grundsätzliche Ausrichtung der empirischen Untersuchung und die durchgeführten Eva-
luierungen beschrieben. Die Kapitel 12, 13 und 14 beschäftigen sich mit der Ableitung
der Hypothesen und deren Prüfung auf den unterschiedlichen Untersuchungsebenen der
Arbeit. Dies beginnt mit der Prüfung der grundsätzlichen Verwendbarkeit des Systems
(Kapitel 12), setzt mit der Prüfung der Eignung für die Externalisierung mentaler Mo-
delle fort (Kapitel 13) und endet mit der Prüfung der Eignung für „Articulation Work“
selbst (Kapitel 14).
In der Zusammenfassung jedes Kapitels wird auf die betroffenen Fragestellung refe-
renziert und der jeweilige Beitrag zur Erreichung der globalen Zielsetzung identifiziert.
Der Schlussteil (Kapitel 15) fasst die Ergebnisse der Arbeit nochmals zusammen und
spiegelt diese in ihrer Gesamtheit auf die ursprüngliche Zielsetzung zurück.
Die Gesamtstruktur dieser Arbeit ist in Abbildung 1.2 nochmals zusammenfassend
dargestellt. Die Beziehungen zwischen den einzelnen Kapiteln sind als Pfeile zwischen den
einzelnen Blöcken dargestellt, wobei jeweils der Endpunkt Ergebnisse des Startpunktes
als Grundlage für die weiteren Ausführungen verwendet.
Anhang A ist als Ergänzung zu Kapitel 2 (Articulation Work) zu sehen und stellt die
gesamte zu diesem Gebiet erschienene Literatur strukturiert dar.
Anhang B ergänzt die Evaluierungskapitel in Teil III durch eine Zusammenfassung der
im Rahmen der Untersuchung erhobenen Daten.
1.2.2. Zusammenfassung der Zusammenhänge
Dieser Abschnitt stellt die wesentlichen inhaltlichen Zusammenhänge der Arbeit dar
und vermittelt so ein erstes Bild des roten Fadens durch die Arbeit. Er ergänzt somit
die im letzten Abschnitt dargestellte Struktur der Arbeit um eine detaillierte inhaltliche
Sicht und fasst das Vorgehen bei der Bearbeitung der in Abschnitt 1.1 formulierten
Forschungsfragen zusammen.
Kapitel 2 beginnt mit einer generellen Begriffsbestimmung zum Themenfeld „Articu-
lation Work“. Diese bildet die Grundlage für den nächsten Abschnitt, in dem auf Basis
der Literatur geklärt wird, wie sich „Articulation Work“ manifestiert und in welchen
11
1.2. Aufbau der Arbeit
Abbildung 1.2.: Zusammenhänge zwischen den Kapiteln der Arbeit
12
1.2. Aufbau der Arbeit
unterschiedlichen Ausprägungen sie das tut. Das Ergebnis ist in Abbildung 2.3 zusam-
mengefasst und spannt die in dieser Arbeit verwendete Taxonomie auf. In den beiden
folgenden Abschnitten wird auf Basis der Literatur dargestellt, was (welche Arbeitsas-
pekte) Gegenstand von „Articulation Work“ ist und wie „Articulation Work“ unterstützt
werden kann (siehe dazu auch Anhang A für eine Gesamtübersicht über die zu „Articula-
tion Work“ verfügbare Literatur). Schließlich greift der letzte Abschnitt die Ergebnisse
der Literaturstudien wieder auf und identifiziert eine konzeptuelle Lücke bei der Be-
trachtung von kooperativer Arbeit anhand der Theorie von Strauss, die auch schon im
Rahmen der Einleitung identifiziert wurde – nämlich die bislang vernachlässigte Rolle
des Individuums bei „Articulation Work“ und dessen konkrete Tätigkeiten. Zu diesem
Aspekt existieren wenige Aussagen in der Literatur zu „Articulation Work“, Strauss
(1993) selbst weist jedoch darauf hin, dass eine konzeptuelle Lücke entsteht, wenn auf
die sozialen und organisationalen Aspekte von „Articulation Work“ fokussiert wird, die
individuellen „thought processes“ aber außer Acht gelassen werden.
In Kapitel 3 wird die identifizierte Lücke aufgegriffen und konzeptuell mit dem Er-
klärungsmodell der mentalen Modelle (Johnson-Laird, 1981) hinterlegt. Im Kontext von
„Articulation Work“ sind mentale Modelle jener Beitrag, den jedes beteiligte Individu-
um einbringt und der in der Folge Gegenstand der Abstimmung und Aushandlung sein
muss, um eine gemeinsame Sichtweise zu entwickeln und „contingencies“ aufzulösen (was
letztendlich das Ziel von „Articulation Work“ ist (Gerson und Star, 1986)). Dementspre-
chend beschäftigt sich der nächste Abschnitt mit der Bildung und Veränderung mentaler
Modelle, wobei als wesentliches Hilfsmittel dazu die Externalisierung derselben identi-
fiziert wird (Seel, 1991). Zur Externalisierung werden drei in der Literatur genannte
Ansätze vorgestellt (Ifenthaler, 2006). Diesen sind Strukturlegetechniken (Dann, 1992)
sowie Concept Mapping (Novak und Cañas, 2006) zuzurechnen, die in der Folge durch
ihre kooperative Anwendbarkeit als die für „Articulation Work“ am besten geeigneten
Ansätze identifiziert werden (vor allem Strukturlegetechniken unterstützen inhärent den
Abstimmungsprozess von mentalen Modellen (Groeben und Scheele, 2000)).
Dies führt zu Kapitel 4, in dem auf Basis der beiden Ansätze die Methoden zur Exter-
nalisierung von mentalen Modellen beschrieben werde. Diese werden den Eigenschaften
von „Articulation Work“ gegenüber gestellt und daraus ein Vorgehen abgeleitet, dass
Strukturlegetechniken und Concept Mapping in einer Methodik zusammenführt. Diese
Methodik soll möglichst offen (im Sinne von prozedural und inhaltlich flexibel) die Exter-
nalisierung und Abstimmung mentaler Modelle ermöglichen. Der zweite Teil des Kapitels
stellt mögliche Anwendungsszenarien vor, die im Kontext von „Articulation Work“ auf-
treten können. Diese Anwendungsszenarien schlagen die Brücke zu den Anwendungen im
Rahmen der Evaluierung (siehe Kapitel 11), da diese den einzelnen Evaluierungsteilen
zugeordnet werden können.
Das Methodik-Kapitel leitet in Teil II der Arbeit über, wo die konkrete Unterstützung
von „Articulation Work“ durch ein Werkzeug besprochen wird. Als Ausgangspunkt für
das Kapitel 5 wird auf Teil I und dort speziell auf das Kapitel zur Methodik zurückge-
13
1.2. Aufbau der Arbeit
griffen und aus den dortigen Ergebnissen Anforderungen an ein Werkzeug abgeleitet, das
die vorgeschlagene Vorgehensweise unterstützt. Konzeptuell ist hier zwischen Anforde-
rungen zu unterscheiden, die aus der Concept Mapping Methodik stammen (im Wesent-
lichen „Flexibilität der Repräsentation“), Anforderungen, die von Strukturlegetechniken
abzuleiten sind (im Wesentlichen „Physikalität der Repräsentation“) und jenen, die di-
rekt aus „Articulation Work“ abgeleitet werden können (im Wesentlichen „Kooperative
Bedienbarkeit“).
Die Festlegung dieser Anforderungen ist die Grundlage der konkreten Umsetzung des
Werkzeugs. Kapitel 5 endet mit der Feststellung, dass aufgrund der Anforderungen aus
allen drei Bereichen ein „Tangible Tabletop Interface“ geeignet ist, entsprechende Werk-
zeugunterstützung zu liefern. „Tangible“ motiviert sich dabei aus der in Strukturlege-
techniken geforderten Physikalität der Abbildung, „Tabletop“ aus der unmittelbaren
kooperativen Bearbeitbarkeit, die durch „Articulation Work“ selbst gefordert wird und
„Interface“ (in diesem Kontext ist darunter die Rechnerunterstützung zu verstehen)
durch die im Rahmen von Concept Mapping vorgeschlagenen Maßnahmen zur Model-
lierungsunterstützung, die nur durch Funktionen im Rechner realisiert werden können.
Vor der konkreten Umsetzung geht das folgende Kapitel (Kapitel 6) detailliert auf
die Thematik der „Tangible Tabletop Interfaces“ ein. Neben einem historischen Über-
blick schlägt Abschnitt 6.2 ausgehend von der eher technologiezentrierten Sichtweise der
„Tangible Interface“-Forschung die Brücke zurück zu den mentalen Modellen und Lern-
prozessen, die in Kapitel 3 („Mentale Modelle“) besprochen wurden. Einige der genann-
ten Aspekte lassen sich auch auf die Anforderungen von „Articulation Work“ abbilden,
was im zweiten Teil dieses Abschnitts beschrieben wird. Als zweiten Brückenschlags in
den Grundlagenteil wird die Forschung zu den Auswirkungen von „Tangible Interfaces“
auf die Kooperation der Anwender betrachtet – ein Bereich der unmittelbar für „Articu-
lation Work“ selbst relevant ist und damit die Brücke zurück zu Kapitel 2 schlägt. Mit
diesen beiden Abschnitten (6.2 und 6.3) wird nochmals (aus „technischer“ Sicht) be-
gründet, das „Tangible Interfaces“ für den geplanten Anwendungsbereich (kooperative
Externalisierung und Abstimmung mentaler Modelle) geeignet sind.
Der zweite Teil von Kapitel 6 (ab Abschnitt 6.4) beschäftigt sich mit Ansätzen, „Tan-
gible Interfaces“ konzeptuell zu betrachten. Dazu wird die existierende Literatur um-
fassend aufgearbeitet und strukturiert dargestellt. Dieser Teil wird in Kapitel 10 wieder
aufgegriffen und zur Einordnung des entwickelten Systems in den Designraum der „Tan-
gible Interface“-Forschung verwendet. Auch in den Kapiteln 7 und 8, die die konkrete
Umsetzung des Werkzeugs beschreiben, wird auf einzelne dieser konzeptuellen Erklä-
rungsmodelle zurückgegriffen, die explizit für die Unterstützung der Konzeption von
Tangible Interfaces entwickelt wurden.
Teil 3 von Kapitel 6 wird wieder konkreter und engt den Betrachtungsbereich von
„Tangible Interfaces“ auf „Tabletop Interfaces“ ein, um letztendlich auf „Tabletop In-
terfaces zur Erstellung diagrammatischer Modelle“ zu fokussieren, was im Wesentlichen
14
1.2. Aufbau der Arbeit
die unmittelbare „Related Work“ zu der vorliegenden Arbeit aus technischer Sicht dar-
stellt. Auch dazu wird jeweils die verfügbare Literatur (aus historischer Sicht sowie den
„State of the Art“) aufgearbeitet.
Nach diesem umfassenden Überblickskapitel behandeln die Folgekapitel die konkrete
technische Umsetzung des Werkzeugs. Das Werkzeug wurde dazu konzeptuell in drei
Blöcke unterteilt. Kapitel 7 beschäftigt sich mit der Eingabe von Information über das
„Tabletop Interface“ und der Aufbereitung und Interpretation der Eingabedaten für den
spezifischen Anwendungsfall (also der „Modellierung“). Dabei erfolgt die Beschreibung
vom Allgemeinen ins Spezielle und beginnt mit der Darstellung der grundlegenden Mög-
lichkeiten, auf einem „Tabletop Interface“ Benutzereingaben zu ermöglichen. Auf Basis
der Anforderungen aus Kapitel 5 wird eine Technologieentscheidung getroffen (optische
Erkennung der Bausteine). Dazu werden in der Folge die in diesem Bereich verfügbaren
Softwareframeworks dargestellt und wiederum strukturiert gegenübergestellt. Die folgen-
de Framework-Entscheidung für das ReacTIVision-System (Kaltenbrunner und Bencina,
2007) ermöglicht die Festlegung des konkrete Hard- und Softwaredesign für die Erken-
nung von Benutzereingaben. In den folgenden Abschnitten wird die Implementierung
beginnend von der Benutzungsschnittstelle (in diesem Fall Hardware) hin zur Richtung
Software zur Erkennung und Interpretation der Benutzereingaben dargestellt. Nach der
Beschreibung der Hardware in Abschnitt 7.2 wird in Abschnitt 7.3 die Interaktion der
Benutzer mit dem Werkzeug beschrieben. Damit kommt die Anwendungssicht (also die
„Modellierung“) ins Spiel, die benötigt wird, um die Interpretation der Eingabedaten zu
beschreiben. Dies erfolgt in Abschnitt 7.4. Das Kapitel endet an jenem Punkt, wo auch in
der Software eine Schnittstelle zur Entkopplung und Modularisierung eingeführt wurde
– bei der Übergabe der interpretierten und auf Modellierungsaktivitäten abstrahierten
Eingabedaten an die weiterverarbeitenden Schichten (siehe Abbildung 7.19).
Kapitel 8 widmet sich der Ausgabe und ist analog zu Kapitel 7 aufgebaut. Beginnend
von den grundsätzlichen Möglichkeiten zur Ausgabe immer weiter fokussiert, bis die kon-
kreten Umsetzung der Informationsausgabe mittels dem JHotDraw-Framework (Gamma
und Eggenschwiler, 1996) dargestellt werden kann. Wo in Kapitel 7 durch Beschreibung
der Benutzerinteraktionen auf den konkreten Anwendungsfall der Technologie fokussiert
wurde, wird hier zum gleichen Zweck die Beschreibung und Zuordnung der auszuge-
benden Information in Abschnitt 8.3 beschrieben und die Unterscheidung getroffen, ob
die Ausgabe direkt auf der Tischoberfläche oder disloziert auf einer separaten Darstel-
lungsfläche zu passieren hat. Die Feststellung, dass mehrere Ausgabekanäle benötigt
werden, um die auszugebende Information darstellen zu können, führt zum konkreten
Softwaredesign in Abschnitt 8.4. Dieses ist durch den Einsatz eines Dispatchers modular
aufgebaut und erweiterbar angelegt (siehe Abbildung 8.3 bzw. Abbildung 8.11).
In Kapitel 9 wird die Persistierung der erstellten Modelle und der gewonnenen Me-
tainformation besprochen. Dazu identifiziert der einleitende Abschnitt auf Basis der Not-
wendigkeit einer flexiblen Repräsentationsform „Topic Maps“ (ISO JTC1/SC34/WG3,
2008) als ein geeignetes Mittel für die Abbildung. In der Folge wird wieder auf den
15
1.2. Aufbau der Arbeit
konkreten Anwendungsfall eingegangen. Nach der Beschreibung von „Topic Maps“ wird
die Abbildung der erstellten Modelle auf „Topic Maps“ und letztendlich die konkrete
Implementierung der Persistierung dargestellt. Abschnitt 9.4 stellt die unterschiedlichen
Möglichkeiten zum graphischen Export der Modelle dar, der für die unmittelbare Do-
kumentation des Modellierungsprozesses und -ergebnisses notwendig ist. Dieses Kapitel
schließt Teil II der Arbeit ab.
In Teil III wird die Evaluierung des Werkzeugs behandelt. Dies beginnt mit der kon-
zeptuellen Einordnung des erstellten Werkzeugs. Dazu werden sämtliche Ansätze zur
Konzeptualisierung von Tangible Interfaces aus Abschnitt 6.4 herangezogen und das
Werkzeug in seiner aktuellen Implementierung in diese eingeordnet. Das Ziel ist da-
bei einerseits, das Werkzeug in die bisherige Forschung einzuordnen, andererseits aber
auch etwaiges Verbesserungspotential zu identifizieren, das etwa durch Inkonsistenzen
der Ausprägungen innerhalb der jeweiligen Betrachtungsdimensionen aufgedeckt wer-
den kann. Während die Einordnung in allen 12 betrachteten Ansätzen möglich ist, kann
Verbesserungspotential nur in 7 Ansätzen identifiziert werden. In der Zusammenfassung
des Kapitels wird einerseits die Eignung eines Ansatzes zur Einordnung des vorliegen-
den Systems und der ggf. entstehenden Mehrwert besprochen. Andererseits wird das
Verbesserungspotential aufgezeigt, das sich aus der rein konzeptuellen Betrachtung des
Systems ableiten lässt. Im Rahmen der empirischen Untersuchung in den folgenden Ka-
piteln werden diese Punkte aufgegriffen und hinsichtlich ihrer tatsächlich in der Praxis
aufgetretenen Relevanz betrachtet.
Die Kapitel 11 bis 14 beschreiben die empirische Untersuchung. Kapitel 11 ist dabei
wiederum als Übersichtskapitel konzipiert. Dort werden die zu untersuchenden Aspekte
aus der Zielsetzung abgeleitet und die Einteilung in die Kapitel 12 bis 14 argumen-
tiert. Untersuchungen werden auf Ebene des Werkzeugs (Benutzbarkeit), der „Mentalen
Modelle“ (Eignung des Werkzeugs zur Externalisierung) sowie von „Articulation Work“
selbst (Unterstützung des Aushandlungsprozesses) durchgeführt. Für jeden dieser Blöcke
wird eingeführt, auf Basis welcher Literatur die Untersuchung angelegt werden kann. In
der darauf folgenden Beschreibung des globalen Untersuchungsdesigns werden alle durch-
geführten Untersuchungen vorgestellt. Diese Vorstellung umfasst den Anwendungskon-
text, die Aufgabenstellung sowie die Beschreibung der Teilnehmer bzw. deren Hinter-
grund. Die Zuordnung zwischen den Untersuchungen und den untersuchten Aspekten
erfolgt im Rahmen der Vorstellung der jeweiligen Untersuchung und zusammengefasst
nochmals im letzen Abschnitt des Kapitels. Nach der Vorstellung der Untersuchungen
werden die eingesetzten empirischen und statistischen Methoden beschrieben, auf die in
den Kapiteln 12 bis 14 nur noch namentlich verwiesen wird.
Die Kapitel 12 bis 14 widmen sich der Prüfung der drei identifizierten Untersuchungs-
ebenen. Alle drei Kapitel sind identisch aufgebaut. Im jeweils ersten Abschnitt werden
die zu prüfenden Hypothesen abgeleitet. Diese Ableitung erfolgt aus der Zielsetzung,
hinterlegt mit den konzeptuellen Grundlagen der Arbeit aus Teil I. Zusätzlich werden
explorativ gebildete Hypothesen formuliert, die nicht unmittelbar aus der Zielsetzung ab-
16
1.2. Aufbau der Arbeit
leitbar sind, die aber Auffälligkeiten abbilden, die im Rahmen der ersten, explorativen
Untersuchungen des Werkzeugs offensichtlich wurden und die an dieser Stelle nochmals
dezidiert geprüft werden sollen, um die Vermutungen zu bestätigen oder diese widerlegen
zu können. Im auf die Formulierung der Hypothesen folgenden Abschnitt über Untersu-
chungsdesign und Durchführung werden einerseits die Hypothesen operationalisiert (d.h.
deren konkrete Prüfung vorgestellt und argumentiert) und in der Folge die Durchführung
der Untersuchungen beschrieben. An dieser Stelle wird auf die im vorhergehenden Kapi-
tel vorgestellten Untersuchungen zurückgegriffen und der jeweils relevante Teil im Detail
beschrieben. Der dritte Abschnitt jedes Kapitels präsentiert die Ergebnisse der Untersu-
chung. Für jede Hypothese wird die Auswertung durchgeführt, das Ergebnis diskutiert
und in einem separaten Unterabschnitt nochmals zusammengefasst. Die Beschreibung
der Auswertung umfasst dabei sowohl quantitative Daten (z.T. graphisch aufbereitet)
als auch qualitative Ergebnisse, die meist in der Form von Transkripten von Auszügen
aus Modellierungsprozessen eingefügt werden.
In den Schlussbetrachtungen in Kapitel 15 werden die Ergebnisse der Evaluierung zu-
sammengefasst und auf Anforderungen an das Werkzeug sowie die globale Zielsetzung
rückgespiegelt. Aufbauend darauf werden weitere Entwicklungsmöglichkeiten des Werk-
zeugs aufgezeigt und weiterführende Anwendungsszenarien beschrieben. Eine Reflexion
des gesamten Entstehungsprozesses schließt diese Arbeit ab.
Abbildung 1.3 stellt die Bezüge zwischen den Kapitel und den zu bearbeitenden Fra-
gestellungen nochmals graphisch dar. Die hier abgebildeten Bezüge werden auch in den
Zusammenfassungen der jeweiligen Kapitel beschrieben und inhaltlich argumentiert.
17
1.2. Aufbau der Arbeit
Abbildung 1.3.: Zusammenhang zwischen Zielsetzung und Struktur der Arbeit
18
Teil I.
Methoden zur Unterstützung der
Abstimmung kooperativer Arbeit
19
Methodik zur Unterstützung der Abstimmung kooperativer Arbeit
Einleitung
In diesem Teil werden die Möglichkeiten zur methodischen Unterstützung der Durch-
führung von „Articulation Work“ umfassend erhoben und dargestellt. Dazu werden die
Grundlagen der relevanten Forschungsgebiete aufgearbeitet und deren möglicher Beitrag
zur Konzeption eines Unterstützungsinstruments identifiziert. Dies beantwortet die erste
in Kapitel 1 formulierte Forschungsfrage („Wie kann die Durchführung und Wirkung von
Articulation Work charakterisiert werden?“). Bei der Betrachtung dieser Forschungsge-
biete liegt der Fokus in diesem Teil auf in der Literatur vorgeschlagenen Maßnahmen
zur Unterstützung von „Articulation Work“, wodurch durch die Erfassung der metho-
dischen Alternativen bereits hier ein Beitrag zur Beantwortung der zweiten Forschungs-
frage („Wie kann explizite Articulation Work effektiv unterstützt werden?“) geleistet
wird.
Wie bereits in Kapitel 1 beschrieben, baut diese Arbeit auf dem Konzept „Articu-
lation Work“ auf. „Articulation Work“ ist ein Erklärungsmodell für jenen Anteil an
(vornehmlich kooperativer) Arbeit, in dem die Tätigkeiten zur eigentlichen Zielerrei-
chung abgestimmt werden und etwaig auftretende Probleme aufgelöst werden, so dass
die „produktive Arbeit“, die der Zielerreichung dient, wieder aufgenommen werden kann.
Die Durchführung von „Articulation Work“ ist ein alltäglicher Vorgang in jedem Arbeits-
prozess und wird zumeist unbewusst und ungeplant durchgeführt. In bestimmten, als
besonders „problematisch“ wahrgenommenen Situationen ist die implizite Durchführung
jedoch nicht möglich, es ist notwendig, sich explizit mit der Abstimmung der problema-
tischen Situation zu beschäftigen. Im Rahmen der Aufarbeitung der Grundlagen dieser
Arbeit ist es notwendig, jene Situationen zu identifizieren, die zur Notwendigkeit von
„expliziter Articulation Work“ führen können, deren konkrete Ausgestaltung zu unter-
suchen und die in der Literatur vorgeschlagenen Möglichkeiten zur Unterstützung von
„Articulation Work“ aufzuarbeiten. Auf Basis dieser Ergebnisse kann letztendlich iden-
tifiziert werden, welche Aspekte bei der Unterstützung „expliziter Articulation Work“
als wichtig zu erachten sind.
Ein Aspekt, auf die Theorie von „Articulation Work“ nicht eingeht, ist die Rolle
und Aktivität der an der Durchführung der „Articulation Work“ beteiligten Individuen
(Strauss, 1993). Aus individueller Sicht ist die Durchführung von „ArticulationWork“ ein
Mittel, die jeweiligen kognitiven Erklärungsmodelle für die Durchführung der Arbeit (die
„mentalen Modelle“) so aufeinander abzustimmen bzw. zu ergänzen, dass eine gemeinsa-
me Sichtweise auf die durchzuführenden Aktivitäten und zu beachtenden Schnittstellen
erreicht wird. Für die Unterstützung von „Articulation Work“ bedeutet dies, dass das
Forschungsgebiet der „mentalen Modelle“ und vor allem deren Veränderung hinsichtlich
möglicher methodischer Ansätze untersucht werden muss.
Wesentlich bei der Veränderung mentaler Modelle ist in kooperativen Arbeitssituatio-
nen die Externalisierung der mentalen Modelle (Seel, 1991). Die Externalisierung (als
20
Methodik zur Unterstützung der Abstimmung kooperativer Arbeit
Prozess und Ergebnis) ermöglicht die Reflexion der eigenen Sichtweise auf die reale Welt
und die dortigen Handlungsalternativen als auch deren Kommunizierbarkeit. Im Sin-
ne der Unterstützung von „Articulation Work“ ist von Interesse, welche Methoden zur
Externalisierung vorgeschlagen werden und welche sich besonders für den Einsatz in
kooperativen Situationen eignen. Aus diesen Methoden ist in der Folge eine für die Un-
terstützung von „Articulation Work“ geeignete Variante auszuwählen bzw. abzuleiten.
Diese bildet in der Folge zusammen mit einer zu entwickelnden technischer Werkzeugun-
terstützung ein Instrument, dass eine effektive Unterstützung von „Articulation Work“
ermöglicht.
Kapitel 2 arbeitet die Grundlagen des Themengebiets „Articulation Work“ auf und
geht auf die Konzeptbildung in diesem Bereich, die unterschiedlichen Ausprägungen und
die Möglichkeiten der Unterstützung ein. In Kapitel 3 wird die individuelle Dimension
der Durchführung von „Articulation Work“ betrachtet und mit dem Konzept der „men-
talen Modelle“ ein Erklärungsansatz für die in diesem Zusammenhang ablaufenden bzw.
durchzuführenden Prozesse beschrieben. Die Beschreibung der Methoden zur Externali-
sierung mentaler Modelle leitet schließlich über zu Kapitel 4, in dem eine Methodik zur
Unterstützung der Durchführung von „Articulation Work“ abgeleitet und beschrieben
wird. Diese Methodik bildet die Grundlage für die in Kapitel 5 abgeleiteten Anforde-
rungen an ein Werkzeug zur Unterstützung derselben. Die Abbildung der Methodik in
konkreten Anwendungsszenarien, die unterschiedliche Kontext der Durchführung von
„Articulation Work“ abdecken, bildet wiederum die Grundlage für das in Kapitel 11
beschriebenen Design der im Rahmen der empirischen Untersuchung durchgeführten
Anwendungen des entwickelten Werkzeugs.
21
2. Articulation Work
In diesem Kapitel wird das Konzept „Articulation Work“ dargestellt und in den Kon-
text von menschlicher Arbeit gestellt. Der erste Teil geht auf die historische Entwicklung
des Begriffs „Articulation Work“ und die unterschiedlichen Herangehensweisen zu des-
sen Verständnis ein. Der zweite Teil des Kapitels widmet sich den Aktivitäten, die im
Rahmen von „Articulation Work“ durchgeführt werden, den Merkmalen, an denen sich
effektive „Articulation Work“ zeigt, sowie den Möglichkeiten der Unterstützung von
„Articulation Work“ durch organisationale und technische Maßnahmen. Abbildung 2.1
stellt dieses Kapitel und dessen Aufbau im Kontext der anderen inhaltlich vor- und
nachgelagerten Kapitel dar.
Abbildung 2.1.: Kapitel „Articulation Work“ im Gesamtzusammenhang
2.1. Begriffsbestimmung
Das Konzept „Articulation Work“ wurde als Erklärungsmodell für eine bestimmte Art
von menschlicher Arbeit Mitte der 1980er Jahre von Strauss (1985) eingeführt. Neben
22
2.1. Begriffsbestimmung
Strauss (1985) tragen auch die Arbeiten von Gerson und Star (1986) und Fujimura
(1987) wesentlich zur Begriffsbestimmung und Konzeptbildung bei. Die vorhandene Li-
teratur, die Bezug auf „Articulation Work“ nimmt (siehe Anhang A), referenziert im
Wesentlichen auf eine oder mehrere dieser drei Arbeiten. Der Kontext, in dem die Ent-
wicklung der im Folgenden vorgestellten Konzepte erfolgte, war die komplexe, von viel
Interaktion an zahlreichen Schnittstellen geprägte Arbeit in Krankenhäusern (Strauss,
1985), in der Wissenschaft (Fujimura, 1987) und in Versicherungsunternehmen (Gerson
und Star, 1986), die die jeweiligen Autoren in mehreren Fallstudien untersuchten.
Um in der Folge einen einheitlichen Begriffsraum aufspannen zu können, ist vorab der
Begriff „Arbeit“ zu klären. Die eben genannten Autoren führen keine explizite Definition
an, weshalb hier auf eine Definition zurückgegriffen wird, die im Kontext der folgenden
Ausführungen zur „inneren“ Struktur von Arbeit nach „außen“ hinreichend umfassend
ist1. Semmer und Udris (2004) definieren vor dem Hintergrund der Organisationspsy-
chologie „Arbeit“ wie folgt:
„Arbeit ist zielgerichtete menschliche Tätigkeit zum Zwecke der Transformation und
Aneignung der Umwelt aufgrund selbst- oder fremddefinierter Aufgaben, mit gesellschaft-
licher, materieller oder ideeller Bewertung, zur Realisierung oder Weiterentwicklung in-
dividueller oder kollektiver Bedürfnisse, Ansprüche und Kompetenzen.“
Arbeit ist also ein menschliches Phänomen, Träger von Arbeit sind immer Menschen.
Arbeit definiert sich außerdem durch ihre Zielgerichtetheit und findet immer in Inter-
aktion mit der Umwelt statt. Die Ziele, auf die Arbeit ausgerichtet ist, leiten sich aus
Aufgaben ab, die sich Menschen selbst setzten können oder die ihnen vorgegeben werden.
Diese Aufgaben dienen der Erreichung von individuellen oder kollektiven Bedürfnissen
und Ansprüchen bzw. der (Weiter-)Entwicklung von Kompetenzen. Die Bewertung der
Zielerreichung muss nicht unbedingt aus materieller Perspektive erfolgen sondern kann
auch ideell oder gesellschaftlich begründet sein.
In dieser Arbeit wird der Begriff „Arbeit“ vor allem auch im organisationalen Kontext
gesehen. Ein wesentlicher Aspekt ist in diesem Zusammenhang die Arbeitsteilung, also
die koordinierte Tätigkeit mehrerer Individuen um ein gemeinsames Ziel zu erreichen.
Dies stellt die obige Definition nicht in Frage (Schmidt, 1994), erweitert jedoch den
Betrachtungsbereich explizit auch auf Arbeit, die gemeinschaftlich durchgeführt wird2.
„Articulation Work“ ist jener Anteil der gesamten durchgeführten Arbeit, der der
Abstimmung mit anderen Individuen dient. Diese Abstimmung ist notwendig, um das
eigentliche Arbeitsziel erreichen zu können. Arbeit wird von den oben angeführten Au-
toren als inhärent kooperativer Prozess gesehen, der immer auf Interaktion mit anderen
1Auf eine umfassende Literaturstudie und die Entwicklung eines darauf aufbauenden „Arbeits“-Begriffs
wurde hier verzichtet, da dies über den Betrachtungsbereich und Anspruch dieser Arbeit hinausgeht
2„[. . . ] work is an individual phenomenon in so far as labor power happens to be tied to individuals
and cannot be separated from the individuals. That is, a cooperative work process, is performed by
individuals with individual interests and motives.“(Schmidt, 1994, S. 353)
23
2.1. Begriffsbestimmung
Menschen basiert bzw. diese bedingt (Strauss formuliert diese Annahme in Bezugnahme
auf Hughes (1971) prägnant mit der Aussage „work rests ultimately on interaction“).
Diese Annahme ist insofern zulässig, als dass selbst Arbeitsabläufe, die selbst keine
Kooperation mit anderen Menschen mit sich bringen, zumindest auf den Ergebnissen
anderer Arbeitsabläufe aufbauen oder als Grundlage weiterer Arbeitsabläufe dienen.
Interaktion tritt also in jedem Arbeitsprozess zumindest zu Beginn und am Ende in un-
mittelbarer oder mittelbarer3 Form auf. Diese Annahme wird auch von Schmidt (1994)
unterstützt, der darauf hinweist, dass individuelle Arbeit und kooperative Arbeit oft
nicht klar abgrenzbar sind bzw. dynamisch ineinander übergehen4.
Jener Teil von Arbeit, der der eigentlichen Zielerreichung dient, wird im hier vorgestell-
ten Erklärungsmodell als „Production Work“ bezeichnet (Fujimura, 1987). „Production
Work“ ist komplementär zu „Articulation Work“ zu sehen und umfasst alle Aktivitäten,
die der „Wertschöpfung“ im wörtlichen Sinn dienen. „Production Work“ sind also alle
Tätigkeiten, die mit der Schaffung jener Werte (oder Ergebnisse) befasst sind, die durch
den Arbeitsablauf erreicht werden sollen.
Abbildung 2.2.: Konzeptualisierung von Arbeitsabläufen
Teile eines Arbeitsablaufs dienen also der Zielerreichung an sich („Production Work“).
Andere Teile dienen der Abstimmung zwischen den involvierten Akteuren, um ein ge-
meinsames Verständnis über die jeweiligen Schnittstellen – also die Berührungspunkte
zwischen den Tätigkeiten – zu entwickeln (siehe Abbildung 2.2). Diese Entwicklung eines
3Unter „mittelbar“ ist hier Interaktion zu verstehen, die nicht im direkten Kontakt zwischen Indivi-
duen abläuft, sondern lediglich indirekt durch die Ergebnisse eines Arbeitsprozesses (Materialien,
Dokumente, . . . ) vermittelt wird.
4„Cooperative work and individual work should not be conceived of as different work domains. In daily
work practice, cooperative and individual activities are inextricably interwoven. [. . . ] More than that,
the boundary between individual and cooperative work is dynamic in the sense that people enter into
cooperative work relations and leave them according to the requirements of the current situation and
the technical and human resources at hand.“(Schmidt, 1994, S. 352)
24
2.2. Ausprägungen von Articulation Work
gemeinsamen Verständnisses bzw. diese „Koordination“ ist kritisch für den Erfolg von
kooperativer Arbeit (Strauss, 1993) und wird als „Articulation Work“ bezeichnet.5
„Articulation Work“ ermöglicht also funktionierende Kommunikation und Zusammen-
arbeit im eigentlichen Arbeitsablauf. Zentral ist dabei vor allem die gegenseitigen Offen-
legung der Annahmen aller beteiligten Personen, die den individuellen Arbeitsbeiträgen
zugrunde liegen6.
„Articulation Work“ ist keine Tätigkeit, die zu einem bestimmten Zeitpunkt im Ar-
beitsprozess durchgeführt wird und dann als abgeschlossen betrachtet werden kann7.
Vielmehr wird „Articulation Work“ immer auch begleitend zur eigentlichen produkti-
ven Arbeit durchgeführt und umfasst neben planenden und koordinierenden Tätigkeiten
auch das Erkennen von Fehlentwicklungen bzw. von Situationen, in denen eine erneute
Koordination notwendig ist8.
Der Begriff „Articulation Work“ ist im Englischen zweideutig und von Strauss auch
bewusst so gewählt. Einerseits wird damit ausgedrückt, dass Arbeit („Work“) artikuliert
wird, andererseits zeigt der Begriff, das die Artikulation selbst ebenfalls Arbeit ist (also
Zeit und Ressourcen in Anspruch nimmt) und auch also solche wertgeschätzt werden
muss (Fujimura, 1987). Gleichzeitig kennzeichnet er auch die rekursive Natur von „Arti-
culation Work“, die somit jederzeit selbst Gegenstand von „Articulation Work“ werden
kann (Star und Strauss, 1999). „Articulation Work“ ist kein klar abgegrenztes und struk-
turiertes Konzept – sie tritt je nach Arbeitssituation in unterschiedlichen Spielarten auf.
Die Unterscheidung dieser Arten von „Articulation Work“ ist für die Unterstützung
derselben relevant und wird daher im folgenden Abschnitt genauer betrachtet.
2.2. Ausprägungen von Articulation Work
Wie bereits von Gerson und Star (1986) angeführt, argumentiert auch Strauss, dass Ar-
tikulation immer passieren muss (und passiert), wo Menschen zusammenarbeiten, um
zu vermeiden, dass unbekannte Aspekte Probleme bei der Durchführung der Arbeit ver-
ursachen (Strauss, 1988). „Articulation Work“ ist kein revolutionäres Konzept, sondern
fasst Tätigkeiten unter einem Begriff zusammen, die seit jeher Teil jeder Zusammen-
arbeit zwischen Menschen sind (Strauss, 1988). Grundsätzlich geht Strauss davon aus,
5„Since the plurality of tasks making up their totality, as well as the relations of actors to tasks, are
not automatically articulated, actors must do that too, and often in complex ways. We call the work
of doing this ”articulation work” – a supra-type of work.“(Strauss, 1985)
6„Reconciling incommensurate assumptions and procedures in the absence of enforceable standards is
the essence of articulation.“(Gerson und Star, 1986, S. 266)
7„The articulation work involves the pre-articulation of the tasks, their management and post-
articulation.“(Raposo et al., 2004, S. 121)
8„Articulation consists of all the tasks involved in assembling, scheduling, monitoring, and coordinating
all of the steps necessary to complete a production task.“(Gerson und Star, 1986, S. 266)
25
2.2. Ausprägungen von Articulation Work
dass „Articulation Work“ immer abläuft, egal wie einfach oder kompliziert, wie einge-
spielt oder neuartig eine (Zusammen-)Arbeit ist (Strauss, 1988). Sehr wohl existieren
jedoch Unterschiede in der Qualität der Arbeit, die sich auf die Form der Artikulation
auswirken, die zu deren Abstimmung notwendig ist: „A useful fundamental distinction
between classes of interaction is between the routine and the problematic. Problematic
interactions involve ’thought’, or when more than one interactant is involved then also
’discussion’.“ (Strauss, 1993, S. 43). Dieses Zitat zeigt im Übrigen auch, dass „Interac-
tion“ im Sinne von Strauss nicht unbedingt ein kollektives Phänomen ist, sondern auch
individuell (im Bezug auf die (unbelebte) Umgebung) auftreten kann.
Je komplexer („problematic“) eine Interaktion ist, desto notwendiger wird laut Strauss
eine explizite Beschäftigung mit dem Vorgang der Artikulation. Bei einfachen, eingespiel-
ten („routine“) Interaktionen bleibt die Artikulation zumeist implizit, verborgen und in-
formell9 (Hampson und Junor, 2005). Ein grundlegendes Problem, dass Artikulation für
jeden noch so also einfach wahrgenommenen Arbeitsvorgang potentiell relevant macht,
spricht Strauss mit den Worten von Hughes unmittelbar nach der Definition von „pro-
blematic interaction“ an: „[O]ne man’s routine of work is made up of the emergencies
of other people“ (Hughes, 1971) zitiert nach (Strauss, 1993).
„Articulation Work“ tritt also in zwei Qualitäten auf. Ist der Bedarf zur Abstimmung
bekannt und werden Tätigkeiten zur Abdeckung dieses Bedarf bewusst durchgeführt,
so spricht man von expliziter „Articulation Work“ (Strauss, 1988) (Fjuk et al., 1997).
Die Abstimmung von Tätigkeiten, die ständig während der Zusammenarbeit unbewusst
ausgeführt wird, bezeichnet man als implizite „Articulation Work“10. Letztgenannte Art
ist es auch, die von den Arbeitenden „automatisch“ zur Anwendung gebracht wird,
sobald Änderungen in der Arbeitsumgebung oder Probleme auftreten (Strauss, 1988).
Implizite „Articulation Work“ stößt aber an ihre Grenzen, wenn die Arbeitssituation als
„problematisch“ (Strauss, 1988) oder „komplex“ (Schmidt, 1990, S. 23f) wahrgenommen
wird. Es wird dann notwendig, dezidierte Abstimmungs-Aktivitäten anzustoßen, also
explizite „Articulation Work“ durchzuführen.
Diese Abstimmungs-Aktivitäten können konkret wiederum unterschiedliche Ausprä-
gungen annehmen (Gasser, 1986):
Fitting (bzw. „Accomodation“ (Bendifallah und Scacchi, 1987)) Tätigkeiten zur Pla-
nung bzw. Anpassung der Arbeitspraxis an gegebene bzw. veränderte Umweltbe-
dingungen.
9entsprechend der „Sozialisation“ im aus der Domäne der Wissensgenerierung und -teilung stammen-
den SECI-Zyklus (Nonaka und Takeuchi, 1995)
10The explicit articulation is thus connected to the planning and decisions regarding the salient dimen-
sions of work – who, what, when, how – while implicit articulation is invaluable when carrying out
activities in situated circumstances, in order to handle contingencies.(Fjuk et al., 1997, S.5)
26
2.2. Ausprägungen von Articulation Work
Augmenting (bzw. „Negotiation of additional [maintainance] activities“ (Bendifallah
und Scacchi, 1987)) Planung von zusätzlichen kurz- oder mittelfristigen Tätigkei-
ten, um das Auftreten von erkannten Problemen zu verhindern.
Working around Entwicklung von Strategien zur Vermeidung des Auftretens von Si-
tuationen, in denen Probleme auftreten, ohne deren Ursache zu beseitigen.
In einer späteren Arbeit geht Strauss auf den bislang nicht betrachteten temporalen As-
pekte des Auftretens von expliziter „Articulation Work“ ein (Corbin und Strauss, 1993)
und unterscheidet dabei zwischen „Working out Original Arrangements“ (also der erst-
maligen Vereinbarung der Modalitäten einer Zusammenarbeit) und „Reworking Arran-
gements“ (also der Veränderung von getroffenen Vereinbarungen, die durch Änderungen
im Arbeitskontext nicht mehr angewandt werden können). Während der Ausgangspunkt
in diesen beiden Fällen unterschiedlich ist, ist doch die Zielsetzung die gleiche – Ziel ist
es, die individuellen Standpunkte und Sichtweisen („stances“) soweit abzugleichen, dass
eine Zusammenarbeit möglich ist. Diese Aktivitäten unterscheiden sich insofern von der
laufend im Arbeitsablauf durchgeführten „Articulation Work“, als dass sie die Indivi-
duen dazu zwingen, aus dem Arbeitssystem herauszusteigen und dieses als Gesamtes
zum Gegenstand der „Articulation Work“ zu machen (Corbin und Strauss, 1993). Dies
umfasst auch die Aushandlung der Modalitäten der im Arbeitsablauf durchgeführten
„Articulation Work“, wodurch deren rekursive Natur (Star und Strauss, 1999) deutlich
wird. Sarini und Simone (2002a) beschäftigen sich explizit mit „rekursiver Articulation
Work“ und führen als wesentliche Ziele die Entwicklung eines gemeinsamen Verständ-
nisses über die Arbeitsdomäne („alignment of meaning“) sowie die Abstimmung des
Arbeitsablaufs selbst („alignment of procedures“) an. Diesem breiten Verständnis von
„Articulation Work“ schließen sich auch Baker und Millerand (2007) aufgrund empiri-
scher Erkenntnisse an.
Die Schritte, die im Rahmen von der Erarbeitung von „arrangements“ durchgeführt
werden müssen, geben Corbin und Strauss (1993) wie folgt an (und beziehen sich dabei
im Wesentlichen auf jene Tätigkeiten, die von Sarini und Simone (2002a) als „alignment
of procedures“ bezeichnet werden):
1. Jedes beteiligte Individuum definiert für sich, welche Aspekte der Arbeit verein-
bart werden müssen und legt seine Position dazu („stance“) fest. Mögliche Aspekte
betreffen die durchzuführenden Schritte, mögliche Verantwortlichkeiten und benö-
tigte Ressourcen11.
2. Die beteiligten Individuen interpretieren die explizierten Standpunkte und Sicht-
weisen („stances“) der jeweils anderen.
11„what needs to be done, by whom, what resources are needed, what one has to offer, what one expects
from others, who has what power, and so forth“(Corbin und Strauss, 1993, S. 76)
27
2.2. Ausprägungen von Articulation Work
3. Basierend auf diese Interpretation passt das Individuum seine Standpunkte und
Sichtweisen an oder behält diese bei und verändert ggf. seine Verhandlungsstrate-
gie.
4. Die Schritte 1-3 werden wiederholt, bis eine für alle Individuen akzeptable Verein-
barung erreicht ist.
Die zeitliche und konzeptuelle Unterscheidung zwischen „Working out Original Arran-
gements“ und „Reworking Arrangements“ lässt jedoch die häufiger auftretende „Arti-
culation Work“ im Arbeitsprozess (die durchgeführt wird, ohne aus dem Arbeitssystem
heraus zu steigen) außen vor. Während eines Arbeitsablaufs kann neben „Reworking Ar-
rangements“ (das als Eskalationsstufe bei der Behandlung von Vereinbarungen zu sehen
ist, auf deren Basis die Arbeit nicht mehr fortgesetzt werden kann und gleichbedeutend
mit den Tätigkeiten „augmenting“ und „working around“ in (Gasser, 1986) ist) auch
das Lösen von problematischen Situationen im Rahmen der aktuellen Vereinbarungen
(„resolving contingencies“ (Gerson und Star, 1986) bzw. „fitting“ (Gasser, 1986)) im
Rahmen von „Articulation Work“ durchgeführt werden.
Neben den beschriebenen Unterscheidungen führt Strauss keine weitere systematische
Betrachtung von „Articulation Work“ hinsichtlich deren Ausprägungen durch. In der
Literatur konnten drei weitere Ansätze zur Differenzierung zwischen unterschiedlichen
Arten von „Articulation Work“ auf Basis einer unterschiedlichen Konzeptualisierung der
abzustimmenden Arbeit identifiziert werden (siehe Anhang A für eine umfassende Dar-
stellung der zu „Articulation Work“ verfügbaren Literatur). Fjuk et al. (1997) stellen
„Articulation Work“ der „Activity Theory“ (Leont’ev, 1978) gegenüber und unterschei-
den so verschiedene Ebenen in Arbeitsabläufen, die abzustimmen sind. Hampson und
Junor (2005) führen ein Raster ein, das „Articulation Work“ hinsichtlich der Art des Ar-
beitsprozesses unterschiedet, in dem sie zur Anwendung kommt. Færgemann et al. (2005)
unterscheiden Varianten von „Articulation Work“ nach der organisationalen „Reichwei-
te“ der zugrunde liegenden Arbeitsprozesse. Alle drei Ansätze werden in der Folge im
Detail beschrieben. Das Ziel ist es hier, die unterschiedlichen Konzeptualisierungen von
„Articulation Work“ so umfassend darzustellen, dass es in der Folge möglich wird, diese
in einem gemeinsamen Modell zusammenzuführen und aufbauend auf diesem identifizie-
ren zu können, wo bzw. welche Aktivitäten unterstützt werden können.
2.2.1. Unterscheidung nach Fjuk, Smørdal und Nurminen
Fjuk et al. (1997) betrachten „Articulation Work“ im Kontext von CSCW12 und versu-
chen ein konzeptuelles Framework zu entwickeln, das die Rolle von Computersystemen
im Kontext individueller und kollektiver Tätigkeiten erklärt – sie entwickeln also ein
Erklärungsmodell für die Funktionsweise sozio-technischer Systeme (Emery und Trist,
1960). Während die Implikationen von „Articulation Work“ für CSCW an dieser Stel-
12Computer Supported Cooperative Work
28
2.2. Ausprägungen von Articulation Work
le nicht näher von Belang sind (siehe dazu Abschnitt 2.4.6), ist aber das theoretische
Framework, das die Autoren ihren Ausführungen zu Grunde legen von Interesse.
Fjuk et al. (1997) bauen ihre Überlegungen auf die „Activity Theorie“ (Tätigkeits-
Theorie) auf, die maßgeblich von Leont’ev (1972) geprägt wurde. Die Autoren argu-
mentieren, dass diese einen Ansatzpunkt biete, die von Strauss als relevant erkannten
aber nicht näher behandelten „externen Faktoren“, die Arbeit beeinflussen, zu berück-
sichtigen. Der Begriff der „externen Faktoren“ umfasst alle Einflussfaktoren, die nicht
unmittelbar Teil des Arbeitsablaufs, sondern technologischer, organisationaler, kulturel-
ler, wirtschaftlicher oder physiologischer Natur sind.
Ohne an dieser Stelle näher auf die „Activity Theory“ 13 einzugehen, seien hier die
drei Kernkonzepte der Theorie erwähnt:
• Activity (Tätigkeit)
• Action (Aktion)
• Operation (Operation)
Diese drei Konzepte bilden eine Hierarchie, in denen eine „Activity“ an oberster Stelle
steht. Eine „Activity“ ist eine menschliche Tätigkeit, die durch ein Motiv getrieben ist
und der (vorerst) individuellen Bedürfnisbefriedigung dient. Eine „Activity“ setzt sich
aus mehreren „Actions“ zusammen, die jede für sich ein aus dem Motiv heraus begründ-
bares Ziel haben und zur Bedürfnisbefriedigung direkt oder indirekt beitragen. „Actions“
setzen sich wiederum aus „Operations“ zusammen, also einzelnen, nicht mehr bewusst
ausgeführten Handlungen, die durch die Bedingungen des jeweiligen Umgebungskontexts
bestimmt werden. Während Individuen lernen, transformieren sie laufend „Actions“ zu
„Operations“, automatisieren also deren Ausführung, sodass sich die kognitive Belastung
verringert (als klassisches Beispiel kann hier das Erlernen des Autofahrens dienen).
Die „Activity Theory“ beschreibt als psychologisches Modell vorerst das Individuum
und dessen Verhalten. In sozialen Systemen, die auf Interaktion basieren, stößt das Mo-
dell jedoch an die Grenzen der erklärbaren Phänomene. Engeström (1987) baut auf der
klassischen „Activity Theory“ auf und erweitert diese um den Aspekt der Gemeinschaft
sowie der Interaktion in dieser sowie der Rolle von Artefakten („Objects“) in derar-
tigen Settings. Fjuk et al. (1997) bemängeln aber in ihrer Arbeit, dass Engeström in
seinen Ausführungen abstrakt bleibt und nicht den Konkretisierungsgrad der originä-
ren „Activity Theory“ erreicht, was das Zusammenspiel der unterschiedlichen Ebenen
(„Activity“, „Action“ und „Operation“) betrifft.
Hinsichtlich der näheren Betrachtung von „Articulation Work“ unterscheiden Fjuk
et al. (1997) in Bezugnahme auf Strauss (1993) zwei Ebenen („levels“) von „Articulation
Work“, namentlich „planned“ und „situated Articulation Work“. Diese Unterscheidung
korrespondiert den Autoren nach im Wesentlichen mit der Unterscheidung zwischen „ex-
13für eine allgemein verständliche Einführung unter Berücksichtigung der praktischen Implikationen
siehe Dahme und Raeithel (1997) oder Nardi und Kaptelinin (2006)
29
2.2. Ausprägungen von Articulation Work
pliziter“ und „impliziter Articulation Work“. „Planned“ bezieht sich hier darauf, dass
die „Articulation Work“ der Koordination eines vordefinierten Arbeitsablaufs dient, also
nicht zur unmittelbaren Bewältigung von aufgetretenen Problemen dient. „Situated Ar-
ticulation Work“ hingegen läuft ad-hoc im Arbeitsablauf bei Bedarf (d.h. zur Beseitigung
von aufgetretenen Problemen) ab. Aufgrund dieser Definitionen (die auch der unabhän-
gig davon getroffenen Unterscheidung zwischen „ad-hoc alignment“ und „coordination
of predefined work“ bei Schmidt und Simone (2000) entspricht), ist eine Gleichsetzung
dieser Unterscheidung mit dem Unterschied zwischen impliziter und expliziter „Arti-
culation Work“ im Sinne von Strauss (1993) fragwürdig. Die Autoren relativieren die
strikte Entsprechung auch selbst mit späteren Aussagen in der Arbeit, in der auf „si-
tuated Articulation Work“ Bezug genommen wird, die aber ob der herausfordernden
Natur des Arbeitsablaufs „expliziter“ abzulaufen habe (Fjuk et al., 1997, S. 15). Die
Unterscheidung zwischen „situated“ und „planned Articulation Work“ wird hier des-
halb als eigenständig und orthogonal zu impliziter und expliziter „Articulation Work“
betrachtet.
Unter Einbeziehung der „Activity Theory“ und basierend auf der Unterscheidung zwi-
schen „Activity“, „Action“ und „Operation“ führen Fjuk et al. (1997) außerdem zwei
unterschiedliche Arten von „Articulation Work“ ein, die sich in ihren Bezugspunkten
unterschieden und jeweils für den Fall individueller und kollektiver Tätigkeiten bzw.
Aktionen betrachtet werden.
Articulation of action within individual activity Die Artikulation von Aktionen inner-
halb einer Tätigkeit entspricht einer bewussten Planung eines Vorgehens zur Er-
reichung von definierten Zielen. Diese Form von „Articulation Work“ ist per De-
finition explizit. Sie umfasst lediglich Planungsaktivitäten eines Individuums und
umfasst die Klärung der Fragen „wer“ (in diesem Zusammenhang das Individuum
selbst oder andere) „was“ (im Sinne des zu erreichenden Ziels) „wo“ (im Sinne des
örtlichen, zeitlichen oder organisationalen Kontexts) „wie“ (im Sinne der Opera-
tionalisierung der Aktionen zur Zielerreichung) arbeitet.
Articulation of operation within action in individual activities Die Auswahl und Aus-
führung von Operationen im Kontext einer Aktion erfolgt zumeist nicht bewusst
basierend auf Erfahrungswissen. Tatsächlich kann die Auswahl von adäquaten Ope-
rationen als ein permanenter Fluss von, mit der produktiven Arbeit verwobenen,
„Articulation Work“-Vorgängen gesehen werden, der implizit auch in individuellen
Arbeitssituationen abläuft. In diesem Zusammenhang ist es wichtig zu erwähnen,
dass Operationen in „problematischen“ Situationen (im Sinne von Strauss) zu Ak-
tionen werden können, die nicht mehr unbewusst und automatisiert ablaufen kön-
nen. Mit dieser Transformation wird auch die „Articulation Work“ explizit und
muss das individuelle Vorgehen der geänderten Situation anpassen.
Articulation of individual action within collective activity Die Artikulation von Ak-
tionen innerhalb eine kollektiven Tätigkeit geht in den Gegenständen der Artikula-
30
2.2. Ausprägungen von Articulation Work
tion über die im individuellen Fall zu berücksichtigenden Planungsaspekte („wer“,
„was“, „wann/wo“, „wie“) hinaus. Zusätzlich müssen um Zuge der Artikulation die
Regeln der Kommunikation und Arbeitsteilung zwischen den am Arbeitsprozess
Beteiligten artikuliert werden. Die Artikulation umfasst hier auch die die gegen-
seitige Offenlegung und Kenntnisnahme der individuellen „kognitiven Strukturen“
und existierender Annahmen über den Arbeitsablauf.
Articulation of individual operation within action in collective activity Im Gegensatz
zur individuellen Artikulation von Operationen im Kontext von Aktionen ist die-
se im kollektiven Fall seltener implizit abzuwickeln. Unterschiedliche Auffassungen
über Herangehensweisen oder Missverständnisse bedürfen zum Teil einer expliziten
Klärung, um die Zielerreichung zu gewährleisten. Operationen werden hier damit
oft auf die Ebene von Aktionen gehoben und bewusst ausgehandelt.
Articulation of collective action in collective activity Die Kategorie der kollektiven
Aktion wird von (Fjuk et al., 1997) nicht im Detail behandelt, da die „Activi-
ty Theory“ selbst diese nicht behandelt und auch keinerlei anderen diesbezüglich
verwendbaren Forschungsergebnisse verwendbar wären. Jede Tätigkeit involviert
auch kollektive Aktionen wie Aushandlungen, Konsensfindung oder gemeinsame
Problemlösung. Bei der Artikulation von kollektiven Aktionen müssen alle betei-
ligten Individuen ihre Perspektive, ihr Wissen und ihre Überlegungen einbringen,
um die gemeinschaftliche Entwicklung voranzutreiben. Fjuk et al. (1997) treffen
hier keine Aussagen hinsichtlich der Implikationen für „Articulation Work“.
Articulation of operations within collective actions in collective activity Bei Zusam-
menarbeit auf Aktionsebene kann es zu konfliktionären Situationen kommen, wenn
die per Definition nicht bewusst geplante Durchführung der individuellen Opera-
tionen zur Zielerreichung nicht zu der kollektiven Aktion beiträgt. Vor allem, wenn
die individuellen Vorstellungen des Arbeitsablaufs divergieren („weak common con-
ceptual structures“), kann es notwendig sein, explizite „Articulation Work“ anzu-
stoßen, um diese Vorstellungen offenzulegen und abzugleichen.
Innerhalb eines Arbeitsablaufs können auch mehrere der hier beschriebenen Kategori-
en auftreten. Teile von Arbeitsabläufen können durch Änderungen im Arbeitskontext die
Kategorie wechseln und somit mehr oder weniger explizite „Articulation Work“ notwen-
dig machen. Durch die Unterscheidung zwischen kollektiver Tätigkeit und Aktion wird es
möglich, „Articulation Work“ je nach Enge der Interaktion und den damit auftretenden
unterschiedlichen Artikulationsbedürfnissen entsprechend auszulegen.
2.2.2. Unterscheidung nach Hampson und Junor
Hampson und Junor (2005) verwenden „Articulation Work“ als Framework zur Erklä-
rung von „interactive customer service“, also jenen Kundenbeziehungen, bei denen die
Interaktion zwischen Anbieter und Kunden im Vordergrund steht. Im Rahmen ihrer
31
2.2. Ausprägungen von Articulation Work
Arbeit zeigen die Autoren auch die historische Entwicklung des Begriffs „Articulation
Work“ auf und entwickeln einen Raster zur Einordnung unterschiedlicher Ausprägungen
von Arbeit, die wiederum unterschiedliche Arten von „Articulation Work“ bedingen.
Dieses Raster ist hier von Interesse.
Bezugnehmend auf Strauss (1993) unterschieden die Autoren einerseits zwischen Ar-
beitsabläufen, die routine sind, und solchen, die non-routine sind. Außerdem kann zwi-
schen Arbeitsabläufen unterschieden werden, die visible oder invisible sind (Star und
Strauss, 1999). Während visible work all jene Arbeitsabläufe umfasst, die als solche wahr-
genommen werden, bezieht sich invisible work auf alle Arbeitsabläufe, die stattfinden,
aber nicht „offiziell“ wahrgenommen werden (also etwa nicht in einem Prozessmodell
repräsentiert sind). Daraus ergeben sich vier zu unterscheidende Settings, in denen „Ar-
ticulation Work“ stattfindet und die sich sowohl in der konkret als „Articulation Work“
ausgeführten Tätigkeit, als auch in der möglichen methodischen und/oder technischen
Unterstützung unterscheiden.
Visible routine work beschreibt jene Arbeitsabläufe, die von klassischen Management-
Ansätzen erfasst werden, formalisiert werden können und in Unternehmen oft nor-
miert vorgegeben sind (etwa in Form von Prozessmodellen oder durch die Vor-
gaben eines Workflow-Management-Systems). „Articulation Work“ findet hier zu
definierten Zeitpunkten und explizit ausgelöst statt, um die normierten Abläufe
zu definieren bzw. diese an veränderte Rahmenbedingungen anzupassen.
Visible non-routine work beschreibt Arbeitsabläufe in Umgebungen, die so dynamisch
sind, dass normierte Abläufe aufgrund der raschen, nicht absehbaren Veränderun-
gen der Anforderungen nicht sinnvoll einsetzbar sind. „Articulation Work“ tritt
hier regelmäßig implizit und explizit auf, da jede Veränderung eine – je nach Aus-
maß der Veränderung implizite oder explizite – Neuabstimmung der Zusammen-
arbeit nach innen und außen benötigt.
Invisible routine work umfasst all jene Arbeitsabläufe in Unternehmen, die zwar eta-
bliert sind, von den traditionellen Steuer- und Kontroll-Werkzeugen im Unterneh-
men jedoch nicht erfasst werden. Sie sind formal nicht normiert, treten jedoch so
regelmäßig auf, dass sich eine routinemäßige Herangehensweise herausbildet. „Ar-
ticulation Work“ läuft hier bei Veränderungen der Rahmenbedingungen zumeist
implizit ab und sorgt dafür, dass die Interaktion zwischen den Beteiligten weiter
funktioniert. Explizite „Articulation Work“ unter Einbeziehung der betroffenen
Personen kann hier dafür sorgen, Arbeitsabläufe dieser Kategorie in den Bereich
der „visible routine work“ überzuführen.
Invisible non-routine work umfasst jene Arbeitsabläufe, die zur Behandlung von unvor-
hergesehenen Anforderungen durchgeführt werden und die nach außen hin nicht
sichtbar wird. Typisch treten derartige Situationen bei Ausnahmefällen in eta-
blierten Arbeitsabläufen auf, bei denen die Tätigkeiten zu Wiederherstellung einer
„regelkonformen“ Situation oft nicht durch Steuer- und Kontrollelemente erfasst
32
2.2. Ausprägungen von Articulation Work
werden und durch die Einzigartigkeit der Ausnahme oder des Kontexts, in dem
diese auftritt, keine etablierten Handlungsmuster existieren. „Articulation Work“
ist hier ad-hoc notwendig, um adäquat auf die Anforderungen der Umwelt re-
agieren zu können. Sowohl explizite und implizite „Articulation Work“ kann hier
zu Anwendung kommen, wobei als Entscheidungskriterien zwischen diesen bei-
den Ausprägungen die wahrgenommene Komplexität der Situation sowie die zur
Lösung zur Verfügung stehende Zeit zu berücksichtigen sind.
In unterschiedlichen Arbeitssituationen können diese vier Kategorien auch kombiniert
auftreten. Zudem können manche Arbeitsabläufe durch erfolgreich durchgeführte „Arti-
culation Work“ in eine andere Kategorie verschoben werden, wo der Bedarf an laufender
ad-hoc Abstimmung geringer oder nicht vorhanden ist. Andere Arbeitsabläufe sind ih-
rer Natur nach nicht strukturierbar und formalisierbar, so dass „Articulation Work“ ein
inhärenter Bestandteil des Ablaufs ist und trotz wiederholter Durchführung auch bleibt.
2.2.3. Unterscheidung nach Færgemann et al.
Færgemann et al. (2005) sprechen einen Aspekt von „Articulation Work“ an, der von
anderen Autoren in dieser Form nicht erwähnt wird. Das strukturierende Merkmal ist in
diesem Fall die „Reichweite“ der Arbeit, die zu koordinieren ist. Die „Reichweite“ (grob
unterteilt in „lokal“ und „global“) beschreibt, ob die kooperierende Instanzen (Individu-
en oder Organisationseinheiten) miteinander vertraut sind, im täglichen Arbeitsverlauf
ständig kooperieren und auch Zugriff auf die gleichen Informationsquellen haben und
diese identisch interpretieren. Ist dies nicht der Fall, liegt ein „globales“ Arbeitssetting
vor, in dem „Articulation Work“ anders als in lokalen Settings unterstützt werden muss.
Die Autoren führen dementsprechend vier unterschiedliche „Reichweiten“ von „Arti-
culation Work“ an:
internal beschreibt „Articulation Work“, die zwischen ständig eng zusammenarbeiten-
den Individuen in einem etablierten Arbeitskontext durchgeführt wird.
semi-internal beschreibt die „Articulation Work“, die zwischen eng kooperierenden,
aber organisational getrennten Einheiten auftritt.
semi-external bezeichnet die „Articulation Work“, die zwischen sporadisch interagie-
renden, organisational getrennten Einheiten auftritt, die jedoch noch unter einem
gemeinsamen konzeptuellen Dach (also z.B. innerhalb eine bestimmen Arbeitsdo-
mäne) arbeiten.
external bezeichnet jene „Articulation Work“, die über organisationale Grenzen hin-
weg durchgeführt wird, und in der auch kein gemeinsames Domänenwissen mehr
vorausgesetzt werden kann.
33
2.2. Ausprägungen von Articulation Work
Je weiter die Reichweite der „Articulation Work“ gefasst ist, desto expliziter und for-
malisierter muss diese den Autoren zufolge auch durchgeführt werden14
2.2.4. Zusammenfassung
In diesem Abschnitt wurden vier Arbeiten näher vorgestellt, die sich der Strukturierung
des Konzepts „Articulation Work“ widmen. Die grundlegende Strukturierung bietet be-
reits Strauss (1985) (bzw. Strauss (1988) und Strauss (1993)). Die drei übrigen Arbeiten
bauen auf Strauss auf und vertiefen das Verständnis von „Articulation Work“ weiter, in
dem sie vor allem den im Zuge von „Articulation Work“ behandelten Gegenstand weiter
detaillieren und strukturieren. Die drei Arbeiten gehen hierbei unterschiedliche Wege.
Fjuk et al. (1997) setzen „Articulation Work“ in Beziehung zur aus der Psychologie
stammenden „Activity Theory“ während Hampson und Junor (2005) und Færgemann
et al. (2005) im Kontext der Soziologie bleiben und neben den Arbeiten von Strauss z.B.
auch auf (Star und Strauss, 1999) aufbauen.
Fasst man die Konzepte zur Strukturierung von „Articulation Work“ aus allen hier
besprochenen Arbeiten zusammen, so ergibt sich folgender Überblick:
• Ausprägung der „Articulation Work“
– implizit vs. explizit15
• Ziel der „Articulation Work“
– situated vs. planned16 bzw.
ad-hoc alignment vs. coordination of predefined work17
– working out original arrangements vs. reworking arrangements18 vs. resolving
contingencies19
• Reichweite der „Articulation Work“
– internal vs. semi-internal vs. semi-external vs. external20
• Gegenstand der „Articulation Work“
– alignment of procedures vs. alignment of meanings21
14„local articulation work often is based on immediate access and visibility [. . . ] articulation work
across unit boundaries is [. . . ] much more demanding and is more dependent on a high degree of
formalization in the interaction and coordination undertaken.“ (Færgemann et al., 2005, S. 178f)
15in (Strauss, 1993)
16in (Fjuk et al., 1997)
17in (Schmidt und Simone, 2000)
18in (Corbin und Strauss, 1993)
19z.B. in (Gerson und Star, 1986)
20in (Færgemann et al., 2005)
21in (Sarini und Simone, 2002a)
34
2.2. Ausprägungen von Articulation Work
– routine vs. non-routine work22 bzw.
routine vs. problematic interaction (mit der belebten oder unbelebten Um-
welt) 23
– visible vs. invisible work24
– individual activity vs. collective activity vs. collective action25
• Abstraktionsgrad des Gegenstandes der „Articulation Work“
– activity-action vs. action-operation26
Bezüglich des Ziels von „Articulation Work“ sind im Wesentlichen zwei Gegensatz-
paare zu identifizieren. „Situated Articulation Work“ wird während des Arbeitsablaufs
beim Auftreten von unvorhergesehenen Problemen durchgeführt und dient der ad-hoc-
Abstimmung der Beteiligten. Obwohl diese in den meisten Fällen implizit abläuft, sind
doch Fälle vorstellbar, in denen eine explizite, d.h. bewusst durchgeführte, „Articulation
Work“ sinnvoll bzw. notwendig ist (siehe weiter unten – Gegenstand der „Articulation
Work“). „Planned Articulation Work“ dient der Koordination von vordefinierten Ar-
beitsabläufen und kann – je nach Arbeitskontext – implizit oder explizit auftreten. Ein
Großteil der Autoren, die den Begriff „Articulation Work“ prägen (u.a. (Strauss, 1985),
(Gerson und Star, 1986) und z.T. auch (Schmidt und Bannon, 1992)), schränken diese
auf deren Durchführung zur Lösung von im Arbeitsprozess aufgetretenen Probleme (also
„situated“) ein. Die Durchführung von „Articulation Work“ zur Koordination von Ar-
beitsabläufen wird nur selten und erst in späteren Arbeiten explizit angesprochen (etwa
bei (Grinter, 1996) oder (Fjuk et al., 1997)).
Die Unterscheidung zwischen „working out arrangements“, „reworking arrangements“
und „resolving contingencies“ ist eine weitere Kategorisierung der Zielsetzung von „Ar-
ticulation Work“, die sich auf den Zeitpunkt der Durchführung bezieht. Die beiden
erstgenannten Ausprägungen sind dabei im Regelfall explizit, da sie eine bewusste Be-
schäftigung mit dem Arbeitsablauf bedingen, und steigen aus dem Arbeitssystem heraus.
„Resolving contingencies“ wird im aktuellen Arbeitskontext durchgeführt und kann je
nach wahrgenommener Komplexität des Problems implizit oder explizit auftreten. „Re-
working arrangements“ ist wie „resolving contingencies“ immer „situated“, da es im-
mer aufgrund einer im Arbeitsprozess auftretenden problematischen Situation ausgelöst
wird, die die Durchführung der bis dahin geltenden Modalitäten der Zusammenarbeit
unmöglich macht. „Working out arrangements“, also die initiale Festlegung der Moda-
litäten einer Zusammenarbeit, kann nicht in die Unterscheidung zwischen „situated“
und „planned“ eingeordnet werden, da die „Articulation Work“ in diesem Fall weder
22in (Hampson und Junor, 2005)
23in (Strauss, 1993)
24u.a. in (Suchman, 1995), (Suchman, 1999), (Star und Strauss, 1999), (Hampson und Junor, 2005)
25in (Fjuk et al., 1997)
26in (Fjuk et al., 1997)
35
2.2. Ausprägungen von Articulation Work
auf aufgetretenen Problemen beruht, noch die Koordination eines bereits bestehenden
Arbeitsablaufs zum Ziel hat.
Die Reichweite von „Articulation Work“ ist orthogonal zu den bereits genannten Un-
terscheidungen zu nennen, da diese alle in einer der vier Reichweiten-Kategorien auf-
treten können. Tendenziell ist „Articulation Work“ mit größerer Reichweite (also „semi-
external“ oder „external“) eher explizit, da der Abstimmungsbedarf im Allgemeinen
größer ist.
Hinsichtlich des Gegenstandes von „Articulation Work“ sind fünf unterschiedliche Ka-
tegorisierungen zu identifizieren. Die jeweiligen Ausprägungen weisen in der Folge auf
die Art der durchzuführenden „Articulation Work“ hin.
Die Unterscheidung zwischen „routine“ und „non-routine work“ bezieht sich darauf,
ob der fragliche Arbeitsablauf für die beteiligten Personen alltäglich ist und unter be-
kannten Rahmenbedingungen stattfindet oder nicht. Je stärker der „non-routine“-Anteil
in einem Arbeitsablauf zum Tragen kommt, desto expliziter muss im Allgemeinen die
„Articulation Work“ sein – bei Routine-Arbeit ist der Bedarf an Articulation gering und
beschränkt sich auf implizit durchführbare Detailabstimmungen zwischen den Beteilig-
ten.
Obwohl vordergründig unterschiedlich, bezieht sich die nächste Kategorisierung „rou-
tine vs. problematic interaction“ auf den gleichen Sachverhalt. Strauss (1993), von dem
diese Unterscheidung stammt, bezeichnet Interaktion als die Grundlage von Arbeitsab-
läufen und als wesentlichen Bestandteil derselben. Der hier verwendete „routine“-Begriff
kann deshalb mit jenem der zuvor beschriebenen Unterscheidung gleichgesetzt werden.
Der Begriff der „problematic interaction“ beschreibt insofern das gleiche Phänomen wie
jener der „non-routine work“ als dass er sich ebenfalls auf die erhöhte kognitive Belas-
tung der beteiligten Personen bei der Zielerreichung bezieht. Dementsprechend impliziert
„problematic interaction“ eine meist explizite „Articulation Work“, während „routine in-
teraction“ meist durch implizite „Articulation Work“ produktiv gehalten werden kann.
Die Unterscheidung zwischen „visible“ und „invisible work“ bezieht sich auf die Sicht-
barkeit eines Arbeitsablaufs in seinem Durchführungskontext und dessen Wahrnehmung
durch andere – vor allem auch übergeordnete – organisationale Instanzen. Während
„visible work“ der Erfüllung definierter Aufgaben dient, formalisiert werden kann und
durch Steuer- und Kontrollinstrumente oder organisationale Unterstützungswerkzeuge
erfasst werden kann, bleibt „invisible work“ im organisationalen Kontext verborgen und
ist nur für die handelnden Individuen sichtbar (und wird dementsprechend auch orga-
nisational nicht unterstützt und wertgeschätzt). Für „Articulation Work“ hat dies per
se keine unmittelbaren Auswirkungen, außer dass „visible work“ immer ein Ergebnis ex-
pliziter „Articulation Work“ ist. Dies bedeutet gleichzeitig, dass explizite „Articulation
Work“ (unter Einbeziehung sowohl der unmittelbar am Arbeitsablauf beteiligten Per-
sonen als auch der „übergeordneten“ Instanzen) dazu beitragen kann, „invisible work“
zu „visible work“ zu machen (siehe dazu auch (Fujimura, 1987)). „Articulation Work“
36
2.2. Ausprägungen von Articulation Work
ist somit ein Mittel, einen Abgleich zwischen dem offiziellen (organisational festgeschrie-
benen) Verständnis eines Arbeitsablaufs und dem tatsächlichen Ablauf, wie er in der
Praxis ausgeführt wird, durchzuführen. „Articulation Work“ kann damit eine Reali-
sierung eines organisationalen Lernschritts sein, der im Sinne von Argyris und Schön
(1978) die „espoused theories“ (die offiziell veröffentlichten Theorien über Arbeit) mit
den „theories-in-use“ (die tatsächlich handlungsleitenden Theorien) abgleicht bzw. im
Sinne von Sachs (1995) einen „tacit organisational view“ in einen „explicit organisatio-
nal view“ überführen (siehe dazu auch die Ausführungen in Kapitel 1).
Die Enge der notwendigen Kooperation bei der Durchführung eines Arbeitsablaufs
(festgemacht an den Handlungs-Kategorien der „Activity Theory“) ist Gegenstand der
letzten Kategorie. „Individual activity“ beschreibt Arbeitsabläufe, die im Wesentlichen
von einem Individuum ausgeführt werden und lediglich an den Schnittstellen zu Beginn
und am Ende Interaktion benötigen. „Collective Activity“ beschreibt Arbeitsabläufe,
in denen mehrere Individuen klar abgegrenzte Teile der Arbeit übernehmen und Inter-
aktion an festgelegten Schnittstellen bzw. zu festgelegten Zeitpunkten stattfindet. Dies
entspricht im Wesentlichen der klassischen Arbeitsteilung in Unternehmen im tayloris-
tischen Sinne. „Collective Action“ beschreibt tatsächlich kooperative Arbeit im engeren
Sinn, deren Durchführung nur durch enge Interaktion mehrere Individuen auch in Detail-
aspekten notwendig ist. Je enger die Kooperation, desto notwendiger wird „Articulation
Work“, wobei diese in allen Fällen sowohl in ihrer impliziten als auch expliziten Ausprä-
gung zum Einsatz kommen kann.
Zur Identifikation der im Einzelfall sinnvollen Variante von „Articulation Work“ (im-
plizit oder explizit) ist die Berücksichtigung der letztgenannten Unterscheidung hinsicht-
lich des Abstraktionsgrades der „Articulation Work“ notwendig. Beschäftigt sich „Ar-
ticulation Work“ mit der abstrakteren Ebene zwischen „activity“ und „action“, steht
die Betrachtungsdimension „Was?“ (also die Ziele und das generelle Vorgehen) im Zen-
trum. Bei Arbeitsabläufen, die „non-routine“ sind, kommt eher explizite „Articulation
Work“ zum Einsatz. Bei „routine“-Arbeitsabläufen ist „Articulation Work“ auf dieser
abstrakten Ebene implizit nicht und explizit nur dann notwendig, wenn der Ablauf selbst
nicht mehr anwendbar ist (also „problematic“ bzw. „non-routine“ wird) und hinterfragt
werden soll („reworking arrangements“). Auf der konkreten Ebene zwischen „action“
und „operation“ (also der Frage nach dem „Wie?“) kommt in individuell abgehandelten
Arbeitsabläufen vorrangig implizite „Articulation Work“ zum Einsatz. Treten unvor-
hergesehene Probleme auf oder werden etablierte Operationen als nicht mehr adäquat
wahrgenommen, kommt zur Klärung wieder explizite „Articulation Work“ zum Ein-
satz. In kollektiven Arbeitsprozessen ist die Enge der Interaktion entscheidend. Bei klar
separierbaren Arbeitsanteilen (also bei Interaktion auf „activtiy“-Ebene) bleibt die Ent-
scheidung zur konkreten Umsetzung beim Individuum und die „Articulation Work“ im
Normalfall implizit (für Ausnahmen siehe die Ausführungen zu individuellen Arbeitsab-
läufen in Abschnitt 2.2.1). Bei Arbeitsabläufen mit enger Interaktion auf Aktionsebene
muss diese im Normalfall im Vorhinein („working out arrangements“) durch explizite
37
2.2. Ausprägungen von Articulation Work
„Articulation Work“ ausgehandelt werden. Während des Arbeitsablaufs kann wieder-
um implizite „Articulation Work“ zurückgegriffen werden, wobei auf Grund der Anzahl
der beteiligten Personen die Wahrscheinlichkeit steigt, dass ein beteiligtes Individuum
die Interaktion als „problematic“ empfindet und dies wiederum explizite „Articulation
Work“ notwendig macht.
Zusammenfassend können die in den letzen Abschnitten beschriebenen Zusammen-
hänge wie in Abbildung 2.3 dargestellt beschrieben werden. Diese Darstellung stellt den
Versuch einer Strukturierung des Konzepts „Articulation Work“ dar, um deren mögliche
Ausprägungen in unterschiedlichen Arbeitskontexten zu zeigen. Sie ist keine Beschrei-
bung der möglichen Abläufe eines „Articulation Work“-Prozesses. In der Abbildung sind
die wesentlichen Inhalte der oben behandelten Einteilungen abgebildet.
Abbildung 2.3.: Articulation Work im Durchführungskontext
Die erste Unterscheidung, die am oberen Rand der Grafik dargestellt ist, betrifft den
Zeitpunkt der Durchführung von „Articulation Work“. Während von den meisten Auto-
ren lediglich jene Phasen eines Arbeitsprozesses zu „Articulation Work“ gezählt werden,
die während der Durchführung der „Production Work“ auftreten, bezeichnen Corbin und
Strauss (1993) selbst auch den Vorlauf eines Arbeitsprozesses (also die Konzeptions- und
Planungsphase) als „Articulation Work“ (auch die ursprüngliche Definition von Stauss
38
2.2. Ausprägungen von Articulation Work
schließt diese Phase nicht aus). Nach Corbin und Strauss (1993) ist „Articulation Work“
in dieser Phase immer explizit (entsprechend dem in dieser Arbeit angegebenen Schema).
Obwohl grundsätzlich nichts gegen eine implizite Durchführung dieser Phase spräche (bei
„einfachen“ Arbeitsaufgaben, die von (etablierten Gruppen von) Individuen übernom-
men werden), wird diese Variante von den Autoren nicht erwähnt und deshalb in der
Abbildung nicht dargestellt. Je nach Kontext, in dem die „Articulation Work“ durch-
geführt wird (organisational, d.h. in offiziellem Rahmen oder informell ausschließlich in
der lokalen Arbeitsumgebung) führt sie zu „visible“ oder „invisible work“.
„Articulation Work“, die im Zuge des Arbeitsablaufs ausgeführt wird, kann zwei Zwe-
cken dienen. Einerseits kann sie im Falle etablierter Arbeitsabläufe („routine“) der Ko-
ordination der ohnehin definierten Abläufe dienen (die nicht notwendigerweise „visible“
sein müssen). Dies wird im Regelfall implizit ablaufen, lediglich bei komplexen Arbeits-
abläufen oder etwa in verteilt organisierten Arbeitsumgebungen (vgl. (Carstensen und
Schmidt, 1999)) wird eine explizite Beschäftigung mit der Koordination notwendig sein.
Andererseits kann „Articulation Work“ auch in Situationen („ad-hoc“) zur Anwendung
kommen, in denen keine etablierten Arbeitsabläufe existieren oder diese aufgrund von
Veränderung in der Arbeitsumgebung nicht adäquat sind. Dieser Fall beschreibt „Ar-
ticulation Work“ im engeren Sinne, die der Wiederherstellung der Arbeitsfähigkeit in
Situationen dient, in denen die Ausführung von „Production Work“ (aus welchen Grün-
den auch immer) nicht mehr möglich ist.
Bei der „ad-hoc“-Anwendung von „Articulation Work“ sind unterschiedliche Eskala-
tionsstufen zu unterscheiden. In vielen Situationen, die von einzelnen beteiligten Indivi-
duen als „problematisch“ oder „non-routine“ wahrgenommen werden, ist die Auflösung
dieser Bedenken durch einfache implizite „Articulation Work“, also ohne bewusste Be-
schäftigung im Rahmen der üblichen sozialen Interaktion möglich. Wird die aktuelle
Arbeit als so „problematisch“ wahrgenommen, dass sie nicht durchgeführt bzw. aufrecht
erhalten werden kann, muss eine explizite (d.h. bewusste) Beschäftigung mit der Situati-
on erfolgen, um die „Production Work“ wieder in einen operativen Zustand zu versetzen
oder verbleibende Unklarheiten implizit beseitigen zu können.
Es können jedoch Situation auftreten, in denen die aktuelle Arbeitspraxis nicht mehr
soweit angepasst werden kann, dass die „Production Work“ wieder aufgenommen werden
kann. Dies ist vor allem in Situationen der Fall, in denen es zu massiven Veränderungen
des Arbeitskontexts gekommen ist (etwa durch veränderte Vorschriften, neue Werkzeuge
oder Personaländerungen). In diesen Fällen muss die Arbeitspraxis selbst hinterfragt
werden, was nach (Corbin und Strauss, 1993) im Wesentlichen einer Neuplanung unter
Berücksichtigung der bislang gemachten Erfahrungen entspricht. Diese Überarbeitung
ist immer explizit und kann je nach Durchführungskontext wiederum zu „visible“ oder
„invisible work“ führen. Sie umfasst je nach Art des aufgetretenen Problems „alignment
of meaning“ (also die Entwicklung einer gemeinsamen Sicht aller beteiligten Individuen
auf die Arbeitsdomäne) und / oder „alignment of procedures“ (also die Abstimmung der
Modalitäten der Zusammenarbeit).
39
2.2. Ausprägungen von Articulation Work
An dieser Stelle ist es wichtig, nochmals darauf hinzuweisen, dass die getroffenen
Unterscheidungen keine strikte, präskriptive Kategorisierung von „Articulation Work“
darstellen. Wie auch von Schmidt und Simone (2000) angemerkt27, sind die Grenzen zwi-
schen den unterschiedlichen Ausprägungen von „Articulation Work“ fließend. Auch die
Kontexte, die zur Durchführung einer bestimmten Ausprägung führen, sind dynamisch
und können sich während der Durchführung der „Articulation Work“ selbst ändern. Für
diese Arbeit bedeutet dies, das sich die Unterstützung von „Articulation Work“ nicht auf
eine bestimmte Ausprägung beschränken darf – vielmehr muss ein Weg gefunden werden,
unterschiedliche Anforderungen an die gegenseitige Abstimmung in unterschiedlichen
Kontexten zu realisieren.
In der Darstellung nicht enthalten sind die Unterscheidungen, die nach (Fjuk et al.,
1997) auf die „Activity Theory“ zurückzuführen sind. Es sind dies die Unterscheidung
nach Kooperations-Art der Arbeit („individuell“ vs. „lose kooperativ“ vs. „eng koopera-
tiv“) und dem Abstraktionsgrad der „Articulation Work“ (abstrakt zwischen „activity“
und „action“ vs. konkret zwischen „action“ und „operation“). Hintergrund der Entschei-
dung, diese Unterscheidungen in der Abbildung zu vernachlässigen, ist deren fehlende
Wirkung auf die Ausprägung der durchgeführten „Articulation Work“ (implizit oder ex-
plizit). In allen Kooperations-Arten ist die Durchführung von sowohl impliziter als auch
expliziter „Articulation Work“ auf beiden Abstraktionsstufen denkbar. Es ändert sich
lediglich die konkrete Ausgestaltung der „Articulation Work“ bzw. die Notwendigkeit
einer eventuellen Unterstützung.
Außerdem fehlt in der Darstellung die Unterscheidung anhand der Reichweite von
„Articulation Work“ nach (Færgemann et al., 2005). Diese hat durchaus Einfluss auf die
Ausprägung der durchgeführten „Articulation Work“, steht aber vollständig orthogonal
zu den abgebildeten Unterscheidungen. Die Komplexität der Darstellung wäre deshalb
durch die Integration dieser Unterscheidung auf ein Maß angestiegen, das eine sinn-
volle Interpretation der Grafik nicht mehr zugelassen hätte. Die Reichweite ist deshalb
implizit in der Unterscheidung nach „routine“ und „non-routine work“ codiert, da domä-
nenübergreifende Arbeitssituationen tendenziell eher „non-routine“ bzw. „problematic“
sind und dadurch eher zu expliziterer „external Articulation Work“ führen.
Auf Basis dieser dargestellten Struktur werden die im folgenden Abschnitt beschrie-
benen Arbeitsaspekte in unterschiedlichen Ausprägungen von „Articulation Work“ ab-
gestimmt bzw. koordiniert. Jede dieser Ausprägungen muss in den unterschiedlichen
Kontexten, in denen sie auftreten können, verschieden stark und mit unterschiedlichen
Mitteln unterstützt werden. Abschnitt 2.4 widmet sich auf Basis einer Literaturstudie
27„As already indicated, the general modalities of articulation work which we for the sake of clarity
discussed separately — ad hoc alignment and improvisation on the basis of mutual awareness versus
action constrained by coordinative artifacts and protocols — are not ‘natural kinds’ in the Aristotelian
sense: they do not exist as distinct domains of action, they are analytical distinctions.“(Schmidt und
Simone, 2000, S. 7)
40
2.3. Abzustimmende Arbeitsaspekte
dem State-of-the-Art der Möglichkeiten dieser Unterstützung aus organisationer, metho-
discher und technischer Sicht.
2.3. Abzustimmende Arbeitsaspekte
Bei der Durchführung von „Articulation Work“ ist das Ziel etwaige im Rahmen eines
Arbeitsablaufs aufgetreten Unklarheiten oder Probleme aufzulösen. Diese Probleme und
Unklarheiten können unterschiedliche Aspekte der Arbeit (etwa die durchzuführenden
Schritte, die beteiligten Personen und Verantwortlichkeiten oder die zu verwendenden
Ressourcen) betreffen. Um „Articulation Work“ umfassend zu beschreiben und eine fun-
dierte Unterstützung gewährleisten zu können, ist eine nähere Beschäftigung mit diesen
potentiell abzustimmenden Arbeitsaspekten notwendig.
Abbildung 2.4 zeigt eine Übersicht über Aspekte, die im Rahmen von „Articulation
Work“ Gegenstand der Abstimmung zwischen den beteiligten Individuen sein können
(entnommen aus (Schmidt und Simone, 1996)). In Abbildung 2.5 sind diese Aspekte
nochmals hinsichtlich der Zusammenhänge zwischen ihnen diagrammatisch dargestellt.
Obwohl diese Übersicht aus Beobachtungen induktiv abgeleitet ist und keinen An-
spruch auf Vollständigkeit erhebt, zeigt sie doch eine Anzahl von konkreten Ausprägun-
gen der von Strauss angeführten Dimensionen von Arbeit, die im Rahmen von „Arti-
culation Work“ abzustimmen sind („Wer?“, „Was?“, „Wann/Wo?“ und „Wie?“). Die
Autoren klären also, welche Aspekte von Arbeit konkret von der Abstimmung betroffen
sein können. Mit der Unterscheidung zwischen den nominalen Aspekten von Arbeit und
der konkreten Manifestation eines Arbeitsablaufs im organisationalen Kontext stellen
die Autoren einen in dieser Form bislang nicht explizit angesprochenen Unterschied bei
der Durchführung von „Articulation Work“ dar.
Konzeptuell unterscheiden die Autoren auch zwischen Arbeitsaspekten, die den Ar-
beitsablauf an sich betreffen („cooperative work arrangement“) und Aspekten, die den
Durchführungsrahmen der Arbeit, also deren Umfeld oder organisationalen Kontext be-
schreibt („field of work“). Die Berücksichtigung beider Aspekte wird bereits bei Strauss
(1988) als ein wesentliches Merkmal von „Articulation Work“ identifiziert, bei Schmidt
und Simone (1996) aber erstmals in dieser expliziten Form dargestellt und abgegrenzt.
Konkret nimmt also die Frage nach dem „Womit?“ – also den Arbeitsmitteln, den
Ressourcen bzw. dem Arbeitsumfeld an sich – sowohl auf konzeptueller als auch auf
konkreter Ebene eine großen Stellenwert ein. Die Behandlung dieses Aspektes dient vor
allem der Bildung einer gemeinsamen Sichtweise auf den Arbeitskontext, in dem der
betreffende Arbeitsablauf abgehandelt wird.
41
2.3. Abzustimmende Arbeitsaspekte
Abbildung 2.4.: Abzustimmende Arbeitsaspekte (entnommen aus (Schmidt und Simone,
1996))
42
2.4. Unterstützung von Articulation Work
Abbildung 2.5.: Zusammenhänge zwischen Arbeitsaspekten (entnommen aus (Divitini
und Simone, 2000))
Von Interesse sind auch die den einzelnen Aspekten zugeordneten Prädikate, die eine
Aussage über die konkret durchzuführenden Aktivitäten zulassen. Diese Aktivitäten sind
sowohl dem Bereich der „Production Work“ (z.B. „do“, „use“) als auch der „Articula-
tion Work“ zuzuordnen (z.B. „assign to“, „allocate“). Zum Teil sind auch Beziehungen
zwischen den Aspekten angeführt, die eine notwendige Abstimmung über die Grenzen
der einzelnen Aspekte hinweg anzeigen (z.B. „Task realized by Activity“ oder „Role
responsible for Task“).
Für diese Arbeit ist die Beschreibung der abzustimmenden Aspekte von Interesse, als
dass an diesen die Effektivität der Durchführung von „Articulation Work“ beobachtet
werden kann. Diese Effektivität ist dann gegeben, wenn eine gemeinsame Sichtweise auf
die abzustimmenden Gegenstände, konkret also die relevanten Aspekte des Arbeitsab-
laufs selbst sowie jene aus dessen Umfeld, entwickelt wurde.
2.4. Unterstützung von Articulation Work
Nach den ersten Arbeiten von Strauss zum Thema „Articulation Work“ wurde das Kon-
zept bald als Erklärungsmodell für die Vorgänge aufgenommen, die im Zuge kooperativer
Arbeit ablaufen. Bereits 1986 verweisen Gerson und Star auf die Notwendigkeit einer
expliziten Unterstützung von „Articulation Work“28. Anhand der historischen Entwick-
lung von Mitte der 1980er-Jahre bis Ende des ersten Jahrzehntes des neuen Jahrtausends
werden in den folgenden Abschnitten Maßnahmen zur Unterstützung beschrieben und in
den jeweiligen Anwendungskontext gesetzt. Hierbei werden alle Arbeiten berücksichtigt,
die sich direkt auf den von Strauss geprägten „Articulation Work“-Begriff beziehen.
28„Methods for analyzing due process means, in this perspective, explicit procedures for evaluating and
reconciling incompatibilities among different bodies of tacit local knowledge.“(Gerson und Star, 1986,
S. 266)
43
2.4. Unterstützung von Articulation Work
In der Literatursuche wurden dazu Datenbanken aus den Bereichen Informatik, Psy-
chologie, Soziologie, den Wirtschaftswissenschaften sowie der Organisationslehre durch-
sucht (für eine detaillierte Auflistung siehe Abschnitt A.1). Nach der initialen Suche
wurde jeweils auch die in den gefundenen Arbeiten referenzierte Sekundärliteratur auf-
gearbeitet. Des weiteren wurden mit Hilfe von rückwärts verlinkenden Datenbanken (wo
vorhanden) Publikationen erfasst, die die bislang gefundenen Arbeiten referenzieren und
diese hinsichtlich ihrer Relevanz überprüft. Insgesamt ergab sich so eine Sammlung von
70 Publikationen (inklusive der grundlegenden Arbeiten, die bereits oben beschrieben
wurden). Von diesen 70 Publikationen wurden 13 Arbeiten im Kontext dieses Abschnitts
einer näheren Betrachtung unterzogen, da sie Aussagen zur Unterstützung von „Arti-
culation Work“ treffen. Die übrigen Publikationen geben hierzu keine Aussage ab oder
sind im Kontext größerer Forschungsvorhaben entstanden, die bereits durch eine reprä-
sentative Arbeit in der detaillierten Betrachtung enthalten sind.
Sämtliche Arbeiten sind in Anhang A hinsichtlich ihres Inhalts beschrieben und ihrer
Relevanz für die Unterstützung von „Articulation Work“ beurteilt. In Anhang A ist
außerdem eine Übersichtsgrafik zu finden, die das gesamte Feld an Publikationen zum
Thema „Articulation Work“ visualisiert und die Zusammenhänge zwischen den einzelnen
Arbeiten und Forschungsvorhaben aufzeigt.
2.4.1. Vorgehen zur detaillierten Betrachtung
Zur strukturierten Betrachtung der Unterstützung von „Articulation Work“ wird ein
einheitlicher Raster angewandt, anhand dessen die aus unterschiedlichen Forschungs-
gebieten stammenden und in unterschiedlichen Anwendungsdomänen angewandten Ar-
beiten einander gegenüber gestellt werden können. Neben den eigentlichen Unterstüt-
zungsmaßnahmen ist zur Bewertung derselben auch Kontextinformation notwendig, die
die unterschiedlichen Ansätze offenlegt. Folgende Merkmale bzw. Inhalte einer Arbeit
werden dazu betrachtet:
Kontext Forschungsgebiet aus dem das Konstrukt „Articulation Work“ betrachtet wird
bzw. in dessen Kontext es zur Anwendung gebracht wird und / oder abstraktes
oder konkretes Problemfeld, in dem „Articulation Work“ als Analysedimension
oder zur Ableitung von Maßnahmen angewandt wird.
Unterstützung Konkrete oder abstrakte Maßnahmen oder Werkzeuge, die zur Unter-
stützung von „Articulation Work“ vorgeschlagen und/oder umgesetzt werden. Ggf.
unterschieden in
• organisationale Unterstützung
• methodische Unterstützung
• technische Unterstützung
44
2.4. Unterstützung von Articulation Work
Auswirkungen Tatsächliche oder vermutete Auswirkungen der Unterstützung auf die
durchgeführte „Articulation Work“.
Bewertung Zusammenfassung des Beitrags der Arbeit zur Unterstützung von „Articu-
lation Work“ hinsichtlich der unterstützten Ausprägungen inklusive einer Beur-
teilung der möglichen Generalisierbarkeit der vorgeschlagenen Maßnahmen bzw.
vorgestellten Werkzeuge.
Die als relevant betrachteten Publikationen sind methodisch unterschiedlich ausgerich-
tet. Ein großer Anteil beschreibt rein empirisch-deskriptiv ein beobachtetes Phänomen
und zieht Schlüsse hinsichtlich möglicher bzw. notwendiger Ausprägungen von „Articu-
lation Work“ in bestimmten Anwendungsdomänen. Ein anderer Teil fokussiert auf die
organisationale und/oder technische Unterstützung von „Articulation Work“, zum Teil
ohne auf eigene empirische Ergebnisse aufzubauen oder diese zu erheben. Aus diesem
Grund kann das oben angegebene Raster nicht immer vollständig befüllt werden. Wo hin-
sichtlich einer bestimmten Dimension keine Information vorhanden ist, wird explizit im
Text darauf hingewiesen. Wo mehrere Publikation eines Autors oder einer Gruppe zum
gleichen Forschungsgegenstand existieren, wurden die umfassendsten Arbeiten (i.A. jene,
die das jeweilige Forschungsvorhaben abschließend beschreiben) herausgegriffen und ex-
emplarisch detailliert ausgearbeitet. Alle übrigen Arbeiten des Forschungsgegenstandes
A sind in entsprechend der jeweils hier beschriebenen Publikation zugeordnet.
2.4.2. Modeling Articulation Work in Software Engineering
Processes
Die erste Publikation, die sich mit der organisationalen Unterstützung von „Articulation
Work“ in Form der expliziten Berücksichtigung von „Articulation Work“ in formalisier-
ten Ablaufmodellen beschäftigt, ist die Arbeit von Mi und Scacchi (1991).
Kontext
Mi und Scacchi (1991) betrachten „Articulation Work“ im Kontext der Softwareentwick-
lung und argumentieren für deren explizite Berücksichtigung in Software Engineering
Prozessen. In einer Literaturstudie zeigen sie, dass (die zum Zeitpunkt der Erstellung)
verfügbaren Software-Engineering-Prozess-Modellierungs-Techniken die Einbindung von
„Articulation Work“ in die Vorgehensmodelle nicht ermöglich29. Die Autoren selbst ha-
ben ihren Hintergrund ebenfalls in der Domäne des Software Engineering und wählen
ihren Zugang zu Thematik dementsprechend, indem sie eine formale Abbildung des „Ar-
29„After we compare these findings with the process modeling techniques, it becomes apparent that
current software process modeling techniques do not directly address articulation work.“(Mi und
Scacchi, 1991, S. 192)
45
2.4. Unterstützung von Articulation Work
ticulation Work“-Prozesses und eine Unterstützung durch regelbasierte Heuristiken zur
Lösungsfindung vorschlagen.
Unterstützung
Die Autoren formalisieren im ersten Schritt den Ablauf von „Articulation Work“ im
Kontext von Softwareengineering (siehe Abbildung 2.6). Die einzelnen Schritte leiten
sie aus drei empirischen Studien ab, die sowohl hinsichtlich ihres Inhalts als auch ihrer
Durchführung nicht näher beschrieben werden.
Abbildung 2.6.: Artikulations-Prozess (entnommen aus (Mi und Scacchi, 1991))
Die Autoren beziehen sich also offensichtlich auf explizite „Articulation Work“, die
„ad-hoc“ – beim Auftreten eines Problems im Software Engineering Prozess – ausgelöst
wird.
Zur Durchführung dieses Prozesses schlagen die Autoren einen Satz von regelbasier-
ten Heuristiken vor, aus denen die betroffenen Individuen (hier: „agents“) auswählen
können. Diese Heuristiken beschreiben mögliche Tätigkeiten im Zuge der „Articulati-
on Work“ (ausdefiniert durch ECA30-Regelsätze). Dabei geben die Autoren Heuristiken
zur Problemlösung („problem-solving heuristics“, die der direkt Behebung der aufgetre-
tenen Probleme dienen) und Heuristiken zur Auswahl geeigneter Lösungen („selection
heuristics“) an.
30Event-Condition-Action
46
2.4. Unterstützung von Articulation Work
Auswirkungen
Das vorgeschlagene System wurde auf konzeptueller Ebene entwickelt und nicht prak-
tisch umgesetzt. Insofern existieren keinerlei reale Erfahrungen mit dem Ansatz. Anhand
eines hypothetischen Beispiels demonstrieren die Autoren jedoch die Anwendung des
Modells und der Heuristiken.
Der Vorteil liegt im Wesentlichen darin, dass der „Articulation Work“-Prozess durch
seine Formalisierung bekannt ist („visible“ in Sinne der Ausführungen in Abschnitt 2.2.2)
und dementsprechend auch offiziell auftreten „darf“. Durch den vorgegebenen Satz an
Heuristiken sind außerdem die Alternativen zur Problembehandlung und deren Durch-
führung bekannt. Die Autoren geben diese Heuristiken für den Bereich des Software-
Engineering an, betonen aber deren exemplarischen Charakter – die Heuristiken und
vor allem deren konkrete Umsetzung (durch die Spezifikation von ECA-Regeln) müssen
an die jeweilige Arbeits-Domäne angepasst werden.
Bewertung
Das vorgeschlagene Prozess-Modell von „Articulation Work“ bildet den Ablauf auf so
abstrakter Ebene ab, dass es für „ad-hoc explicit Articulation Work“ zur Lösung unmit-
telbar auftretender Probleme allgemein (d.h. unabhängig von der Anwendungsdomäne)
anwendbar ist und auch in mit den von Corbin und Strauss (1993) genannten Schritten
bei der Durchführung expliziter „Articulation Work“ in Einklang gebracht werden kann.
Die Angabe von (exemplarischen) Heuristiken zur Durchführung des Artikulations-
Prozesses ist insofern sinnvoll, als dass diese domänen- und organisations-spezifische
Lösungsstrategien auch für unerfahrene Teilnehmer zugänglich machen können.
In Bezug auf die Generalisierbarkeit des Ansatzes problematisch zu sehen ist jedoch
die Verwendung von ECA-Regeln zur Spezifikation der Durchführung der einzelnen Heu-
ristiken. Die Angabe derartiger Regeln ist nicht in allen Anwendungsbereichen in einem
sinnvollen Detaillierungsgrad möglich. Vor allem soziale Prozesse in kooperativen Um-
gebungen, auf die die Autoren der ursprünglichen Literatur zum Thema „Articulation
Work“ stark Bezug nehmen, können in diesen Regeln nicht sinnvoll (im Sinne einer
Durchführungsvorschrift) abgebildet werden.
Kontext Unterstützung von Software Engineering
Art von AW ad-hoc explizit
Unterstützung organisational durch Formalisierung und a-priori-
Spezifikation des Articulation-Prozesses („Was?“) und
dessen Ausgestaltung („Wie?“)
Auswirkungen Definiertes Vorgehen, wie „Articulation Work“ durchge-
führt werden muss
47
2.4. Unterstützung von Articulation Work
2.4.3. Taking CSCW seriously: Supporting Articulation Work
Schmidt und Bannon (1992) begründen mit dieser Arbeit eine Entwicklungsrichtung
der CSCW, die neben der Unterstützung der eigentlichen produktiven Arbeit auch auf
die Unterstützung von „Articulation Work“ fokussiert. Sie beschreiben damit erstmals
Anforderungen an die und Möglichkeiten der technische Unterstützung von „Articulation
Work“.
Kontext
Schmidt und Bannon (1992) widmen sich in ihren Ausführungen der kooperativen Arbeit
und der Unterstützung derselben durch Computersysteme. Sie argumentieren, dass zum
Zeitpunkt der Erstellung der Arbeit CSCW auf einer sehr formalisierten, strukturierten
Sichtweise von kooperativer Arbeit aufbaut (z.B. im Sinne einer präskriptiven Workflow-
Unterstützung) und Aspekte wie individuelle Arbeitsweise und Kommunikation unter
den Beteiligten vernachlässigt. Dieser Sichtweise setzen sie einen Ansatz entgegen, der
auch die Unterstützung von „Articulation Work“ berücksichtigt und damit den handeln-
den Individuen selbst die Kontrolle über die Interaktion gibt31.
Die Autoren selbst arbeiten vor ihrem Hintergrund aus der Informatik, der Soziolo-
gie und den Arbeitswissenschaften. Sie stellen die Technologie nicht ins Zentrum ihrer
Überlegungen, sondern betonen deren unterstützende Funktion für Individuen, die in Or-
ganisationen arbeiten. Die Untersuchungsdomäne ist dabei explizit nicht eingeschränkt,
kooperative Arbeit wird in allen ihren Ausprägungen und in beliebigen Kontexten be-
trachtet32.
Unterstützung
Bei ihren Ausführungen zur unterstützenden Wirkung von CSCW bei „Articulation
Work“ konzentrieren sich die Autoren auf zwei Aspekte von CSCW und zeigen, wie diese
ausgestaltet sein müssen, um „Articulation Work“ zuzulassen bzw. zu unterstützen.
Der erste Aspekt, auf den eingegangen wird, ist die Unterstützung von Workflows
durch Computersysteme. Um hier „Articulation Work“ zu berücksichtigen, ist die Unter-
stützung der Selbst-Organisation der kooperierenden Personen ein zentraler Punkt33. In
31„Thus, by entering into cooperative work relations, the participants must engage in activities that are,
in a sense, extraneous to the activities that contribute directly to fashioning the product or service
and meeting requirements.“(Schmidt und Bannon, 1992, S. 8)
32„In sum, we certainly want CSCW to address the aspects of computer support for cooperative work
wherever they occur.“(Schmidt und Bannon, 1992, S. 11)
33„Computer support of cooperative work should aim at supporting self-organization of cooperative
ensembles as opposed to disrupting cooperative work by computerizing formal procedures.“(Schmidt
und Bannon, 1992, S. 17)
48
2.4. Unterstützung von Articulation Work
diesem Sinne argumentieren die Autoren gegen einen fixen, unveränderlich vorgegebenen
Workflow mit a-priori definierten Zuständigkeiten, sondern schlagen die Ermöglichung
bzw. Unterstützung von Aushandlungsprozessen vor, in denen der Arbeitsablauf ent-
sprechend dem aktuellen Arbeitskontext angepasst und kooperativ abgearbeitet werden
kann. Anhand der angeführten Beispiele wird deutlich, dass dabei eher von „Articulation
Work“ zur Koordinierung etablierter Arbeitsprozesse ausgegangen wird, die vorgeschla-
gene Unterstützungsfunktionalität ist jedoch auch für „ad-hoc Articulation Work“ sinn-
voll anzuwenden (in Klammer jeweils die Zuordnung zur Art von „Articulation Work“):
• Offenlegung des der Workflowunterstützung zugrunde liegenden Modells und Un-
terstützung der Interpretation und Reflexion desselben („ad-hoc implicit and ex-
plicit Articulation Work“)
• Unterstützung der Anpassung des Modells an den aktuellen Arbeitskontext („ex-
plicit resolving contingencies“)
• Ermöglichung der flexiblen Anwendung bzw. dynamischen Veränderung des Mo-
dells während der Ausführung des Arbeitsablaufs („implicit and explicit coordina-
tion of predefined work“)
• Unterstützung zur Veränderung bzw. Neuerstellung von Modellen, um die Arbeit
an veränderte organisationale Rahmenbedingungen anzupassen („reworking arran-
gements“)
• Dokumentation und Kommunikation aller Veränderungen des Modells oder Ab-
weichungen während der Ausführung (in allen Fällen)
• Unterstützung der Aushandlung eines gemeinsamen Verständnisses des Modells
(„ad-hoc explicit Articulation Work“)
Der zweite Aspekt, auf den näher eingegangen wird, ist jener der Kooperation mit-
tels geteilter Informationsräume, also Ablagesysteme für Informationen, auf die mehrere
Personen Zugriff haben. Als zentral wird hier die Unterstützung der Entwicklung einer
einheitlichen Interpretation der verfügbaren Information gesehen34. Die Autoren führen
hier drei Funktionen an, die ein CSCW-System unterstützen muss:
• Unterstützung der Identifikation des Erstellers die Information
• Offenlegung der Kontexts der Information (im Sinne einer Relation zur Ursprungs-
bzw. Anwendungsdomäne)
• Kontrolle über den Zugriff auf Information durch den Ersteller
Die genannten Aspekte zielen allesamt nicht auf die Unterstützung direkter Interaktion
ab, sondern ermöglichen durch die Erfassung von Metadaten im Wesentlichen eine Beur-
teilung von geteilt verfügbarer Information durch Individuen, während diese damit arbei-
34„At the level of the objects themselves, shareability may not be a problem, but in terms of their
interpretation, the actors must attempt to jointly construct a common information space which goes
beyond their individual personal information spaces.“(Schmidt und Bannon, 1992, S. 21)
49
2.4. Unterstützung von Articulation Work
ten. Die „Articulation Work“, die hier unterstützt wird, ist durch die semi-automatisierte
Erfassbarkeit bzw. die automatisierte Anzeige zumeist implizit.
Auswirkungen
Aufgrund der konzeptuellen Natur der Arbeit stehen keine Angaben zu etwaigen Aus-
wirkungen der Maßnahmen zur Verfügung.
Bewertung
Schmidt und Bannon (1992) sind die ersten, die sich mit der technischen Unterstüt-
zung von „Articulation Work“ in beliebigen Anwendungsdomänen und in all ihren Aus-
prägungen beschäftigen. Sie geben dabei Anforderungen („Was?“) an diese technische
Unterstützung an, gehen jedoch nicht auf deren Umsetzung („Wie?“) ein.
Auf Anforderungsebene wird jedoch umfassend hinsichtlich unterschiedlicher Artikulations-
Bedürfnisse argumentiert, so dass die Arbeit als Grundlage zur Konzeption einer kon-
kreten technischen Unterstützung von „Articulation Work“ herangezogen werden kann.
Kontext Umsetzung von CSCW-Systemen (Workflow-Support,
Shared Information Spaces, Cooperative Tools)
Art von AW alle Arten und Ausprägungen von „Articulation Work“
(Workflow Planung und Unterstützung), implizit (Infor-
mation Sharing)
Unterstützung technisch durch Maßnahmen, die sowohl die selbstge-
steuerte Anpassung von Arbeitsabläufen an den aktu-
ellen Arbeitskontext als auch die Entwicklung eines ge-
meinsamen Verständnis über den Arbeitsablauf und die
verwendeten Arbeitsartefakte ermöglicht
Auswirkungen —
2.4.4. Supporting articulation work using software configuration
management systems
Grinter (1996) führt in dieser Arbeit die Ideen von Bendifallah und Scacchi (1987) und
Schmidt und Bannon (1992) weiter und zeigt, wie die Softwareentwicklung als koopera-
tiver Prozess durch computerbasierte Werkzeuge unterstützt werden kann.
50
2.4. Unterstützung von Articulation Work
Kontext
Die Autorin betrachtet die Rolle von „Articulation Work“ im Kontext der Softwareent-
wicklung und zeigt anhand zweier qualitativer empirischer Studien die Auswirkungen
eines computerbasierten Configuration Management Systems bei der kooperativen Er-
stellung von Software.
Grinter beschäftigt sich mit zwei Arten von Aufgaben, die im Rahmen eines Software-
Entwicklungs-Prozesses im Rahmen von „Articulation Work“ zu bewältigen sind. Einer-
seits ist die tägliche Arbeit abzustimmen, so dass sichergestellt ist, dass die gerade erstell-
te Software korrekt funktioniert. Andererseits muss sichergestellt werden, dass auch das
gesamte Produkt als Einheit funktioniert. Während die erstere Herausforderung durch
das in den Fallstudien eingesetzte Configuration Management System unterstützt wurde
(im Rahmen von „resolving contingencies“, die sowohl implizit als auch explizit war),
waren im zweiten Fall organisationale Maßnahmen wie die Bildung von Koordinations-
Kommitees (also „explicit coordination of predefined work“) notwendig.
Unterstützung
In der Arbeit detailliert beschrieben sind die Eigenschaften und Auswirkungen des Con-
figuration Management Systems, so dass hier nur dessen Unterstützungsleistung berück-
sichtigt werden kann. Konkret muss hier weiter auf jene Fälle von „resolving contingen-
cies“ eingeschränkt werden, die von Problemen in Arbeitsabläufen ausgelöst werden,
die auf konfliktionierende (Teil-)Ergebnisse der produktiven Arbeit zurückzuführen sind
(hier: simultan editierter Source-Code, der nicht automatisiert zusammengeführt werden
kann)
Während der Entwicklung von Software wird durch das Configuration Management
System dargestellt, ob bzw. durch wen ein bestimmter Teil des Source Codes zur Zeit
bearbeitet wird. So kann die simultane und potentiell zu Konflikten führende Bearbei-
tung durch andere Personen vermieden werden. Diese Information muss weder explizit
ins System eingepflegt noch abgerufen werden und ist deshalb als Unterstützung von
impliziter „Articulation Work“ zu klassifizieren.
Sind bereits Konflikte aufgetreten, unterstützt das System die Auflösung derselben
durch eine adäquate Darstellung der betroffenen Teile des Source Codes, so dass den
zusammenarbeitenden Individuen eine Grundlage zur Erörterung und Auflösung des
Konflikts zur Verfügung steht. Diese Darstellung muss „geeignet“ sein – welche Arten
von Zusatzinformation und welche Form der Darstellung dies gewährleistet, ist domä-
nenabhängig. Im konkreten Fall wird die zusätzliche Angabe einer Begründung für Än-
derungen in Source Code Teilen empfohlen, um bei der Auflösung der Konflikte fundiert
argumentieren zu können.
51
2.4. Unterstützung von Articulation Work
Auswirkungen
Den Software Entwicklern wird die Freiheit gelassen, Konflikte durch sequentielle Bear-
beitung zur vermeiden oder diese (z.B. aus Zeitdruck) bewusst in Kauf zu nehmen und
deren Auflösung ggf. in einem separaten Schritt durchzuführen.
Bewertung
Die Arbeit von Grinter (1996) geht auf einen Spezialfall von „resolving contingencies“
ein und zeigt, welche Unterstützungsleistung ein Software-Werkzeug bei der Ausgestal-
tung eines Arbeitsprozesses leisten kann, in dem sich die produktive Arbeit stark an
Artefakten (hier: Source-Code) materialisiert. In derartigen Arbeits-Umgebungen sind
die vorgeschlagenen bzw. beschriebenen technischen Maßnahmen sinnvoll und führten
in den angeführten Fällen zum Erfolg.
Kontext Unterstützung von Software Entwicklung
Art von AW „resolving contingencies“ implizit und explizit (zur Ver-
meidung bzw. zur Beseitigung von konfliktionierenden
Arbeitsergebnissen)
Unterstützung resolving contingencies implizit: Visualisierung aktuell
durch andere Personen bearbeitete bzw. verwendete Ar-
beitsgegenstände; resolving contingenciesv explizit: ad-
äquate Darstellung der konfliktionierenden Ergebnisse
(Darstellung domänenabhängig)
Auswirkungen Wahlfreiheit der interagierenden Individuen bei der Aus-
gestaltung ihres Arbeitsablaufs.
2.4.5. Coordination Mechanisms: Towards a Conceptual Foundation
of CSCW Systems Design
Schmidt und Simone (1996) entwickeln in ihrer Arbeit ein generisches Vorgehen zur Kon-
zeption von technischer Unterstützung von „Articulation Work“. Aufbauend auf früheren
Arbeiten der Autoren (z.B. (Schmidt, 1990) und (Schmidt und Bannon, 1992)) formu-
lieren die Autoren eine Notation zur Spezifikation von CSCW-Systemen, die auf der
Unterstützung von „Articulation Work“ aufbauen.
Kontext
Die Arbeit führt den in früheren Arbeiten der Autoren bereits propagierten Ansatz der
Konzeption von CSCW-Systemen zur Unterstützung von „Articulation Work“ fort. Die
Herangehensweise ist stark technisch orientiert, begründet sich jedoch immer aus dem
52
2.4. Unterstützung von Articulation Work
jeweiligen Anwendungskontext oder theoretischen Überlegungen aus den Arbeitswissen-
schaften.
Unterstützung
Die Autoren legen einen klaren Fokus auf die technische Unterstützung von „Articulation
Work“ in der Form von CSCW-Systemen, für die sie eine Notation zur Spezifikation
derselben entwickeln. Bevor sie jedoch im Detail auf deren Entwicklung eingehen, führen
sie – als Grundlage für die weitere Entwicklung und als historischen Kontext – etablierte
organisationale Maßnahmen zur Unterstützung von „Articulation Work“ an.
Bei den angeführten organisationalen Maßnahmen führen die Autoren die Nützlich-
keit von Artefakten, die für ihren Anwendungsbereich die notwendige Durchführung
von „Articulation Work“ formalisieren und definieren und damit die Komplexität der
alltäglich Interaktion reduzieren35. Beispiele für derartige Artefakte sind etwa Check-
listen, Formulare zur Meldung von Fehlern o.ä.. Die Artefakte sind dabei immer Teil
eines „Koordinationsmechanismus“, der den Umgang mit einer aufgetretenen Situation
oder einer Aufgabe beschreibt. Neben dem Artefakt enthält dieser Mechanismus auch
ein „Koordniationsprotokoll“, das den Ablauf bzw. das Vorgehen und den Umgang mit
dem Artefakt beschreibt. Diese Protokolle sind dabei nicht als strikt vorgegebenen Ab-
laufmuster zu verstehen, sondern sollen Individuen ermöglichen, in Standardfällen ohne
Planungsaufwand ein fixes Vorgehen zur Verfügung zu haben und bei Bedarf dieses
an den jeweiligen Fall anpassen zu können (in Sinne von „situated action“ (Suchman,
1987))36. Die Rolle des Artefakts ist dabei die „Vergegenständlichung“ des Protokolls
und damit die Erhöhung der Zugänglichkeit desselben. Außerdem repräsentiert das Ar-
tefakt während der Durchführung der „Articulation Work“ deren aktuellen Status und
Fortschritt. Aus all diesen Ausführungen kann abgeleitet werden, dass sich die Autoren
immer auf explizite „Articulation Work“ im Arbeitsablauf beziehen.
Der eigentliche Schwerpunkt der Arbeit ist jedoch die technische Unterstützung von
„Articulation Work“. Aufbauend auf den zuvor ausgeführten organisationalen Maßnah-
men wird gezeigt, wie diese durch technische Mittel umgesetzt und unterstützt bzw.
verbessert werden können. Die Grundidee besteht darin, sowohl die Artefakte als auch
Teile der Protokolle in den Rechner zu transferieren und durch die digitale Repräsenta-
tion die Flexibilität zu gewinnen, die bei „coordination of predefined work“ im konkre-
35„Faced with a high degree of complexity of articulation work, cooperating actors typically use a special
category of artifacts which, in the context of a set of conventions and procedures, stipulate and
mediate articulation work and thereby are instrumental in reducing its complexity and in alleviating
the need for ad hoc communication.“(Schmidt und Simone, 1996, S. 159)
36„As a generalization, we find that a protocol stipulates the articulation of distributed activities by
conveying affordances and constraints to the individual actor which the actor, as a competent member
of the particular ensemble, can apply without further contemplation and deliberation unless he or
she, again as a competent member, has accountable reasons not to do so.“(Schmidt und Simone,
1996, S. 173)
53
2.4. Unterstützung von Articulation Work
ten Arbeitsablauf notwendig ist. Die grundlegenden Anforderungen an ein technisches
System, das „Articulation Work“ unterstützt, sind deshalb auch die Formbarkeit der
Koordinationsmechanismen („malleability“, also die Anpassbarkeit an den aktuellen Ar-
beitskontext), sowie die Verknüpfbarkeit der Koordiniationsmechnismen untereinander
(„linkability“), um die in komplexen Arbeitssituationen notwendige Durchführung von
mehreren voneinander abhängigen Koordinationsmechnismen zu unterstützen.
Diese Forderungen werden im Rahmen des „Ariadne“-Ansatzes umgesetzt, der in
(Schmidt und Simone, 1996) konzeptuell beschrieben ist. Die tatsächliche Implemen-
tierung von „Ariadne“ wird unter anderem in (Divitini und Simone, 2000) und (Sarini,
2003) beschrieben und ist Gegenstand von Abschnitt 2.4.11.
Auswirkungen
Da keine konkrete Anwendung des Systems beschrieben wird (bzw. dessen Implemen-
tierung zum Zeitpunkt der Erstellung der Arbeit nicht abgeschlossen war), können hier
keine praktischen Auswirkungen des Ansatzes angegeben werden.
Generell ist zu erwarten, dass durch die Einführung von Koordinationsmechanismen
der Aufwand für „coordination of predefined work“ sinkt bzw. deren Komplexität redu-
ziert wird. Durch die technische Unterstützung ist es möglich, die notwendige Flexibilität
zu wahren, um die spezifizierten Koordinationsmechanismen an den aktuelle Arbeitskon-
text anzupassen, sowie den gesamten Verlauf eines „Articulation Work“-Prozesses durch
die Verknüpfbarkeit mehrerer Koordinationsmechanismen und dabei trotzdem die Über-
nahme der jeweils relevanten Kontextinformation nahtlos zu unterstützen.
Bewertung
Schmidt und Simone (1996) zeigen umfassend die Unterstützung von expliziter „Arti-
culation Work“ unmittelbar in Arbeitsabläufen – die vorgeschlagenen Konzepte können
jedoch ebenso auf „Articulation Work“ im Vorfeld von Arbeitsabläufen zu deren Konzep-
tion angewandt werden. Die vorgestellte technische Unterstützung setzt die organisatio-
nalen Maßnahmen um und ermöglicht die Realisierung von flexiblen, an den jeweiligen
Kontext angepassten bzw. anpassbaren Werkzeugen.
Vor allem die Konzeptualisierung von Koordinationsmechanismen in Protokolle und
Artefakte ist ein wesentlicher Beitrag zum Verständnis der Koordination von Individuen
in Arbeitsabläufen und ein Ansatzpunkt zur Reduktion der Komplexität von Abstim-
mungsprozessen bzw. deren Vermeidung.
Die formulierten Anforderungen an ein technisches System („malleability“ und „linka-
bility“) sind vor allem für den unmittelbaren Einsatz in Arbeitsprozessen als wesentliche
Erfolgskriterien für die praktische Einsetzbarkeit eines derartigen Systems.
54
2.4. Unterstützung von Articulation Work
Kontext Umsetzung von CSCW-Systemen
Art von AW explizit, im Regelfall im Arbeitsablauf
Unterstützung organisational durch Koordinationsmechanismen, die
aus einem vorgeschlagenen Vorgehen („Protokoll“) und
einem zugehörigen „Artefakt“ (als Repräsentant des
Protokolls und zur Dokumentation) bestehen; technisch
durch Umsetzung der Koordinationsmechanismen im
Rechner mit dem Ziel, die geforderte Flexibilität und
Verknüpfbarkeit derselben zu gewährleisten
Auswirkungen Reduktion der Komplexität der „Articulation Work“,
Flexibilität bei der Durchführung von „expliziter Arti-
culation Work“
2.4.6. Taking Articulation Work Seriously: An Activity Theoretical
Approach
Neben den in Abschnitt 2.2.1 bereits beschriebenen konzeptuellen Arbeiten zu „Articu-
lation Work“ enthält die Arbeit von Fjuk et al. (1997) auch Ansätze zur Unterstützung
von „Articulation Work“.
Kontext
Fjuk et al. (1997) beschäftigen sich mit der technischen Unterstützung von „Articulation
Work“ mittels CSCW-Systemen. Ihre Ansätze leiten sie aus der „Activity Theory“ ab,
die ihre Wurzeln in der Psychologie (Leont’ev, 1972) bzw. in ihrer erweiterten Variante
in den Arbeitswissenschaften (Engeström, 2000) hat.
Unterstützung
Entsprechend den in Abschnitt 2.2.1 bereits beschriebenen unterschiedlichen Arten von
Arbeit, in denen „Articulation Work“ auftreten kann (individuelle Arbeit, lose und eng
gekoppelte kooperative Arbeit), unterscheiden die Autoren auch bei der Betrachtung der
Unterstützung von „Articulation Work“ nach diesen drei Gruppen.
Im Falle individueller Arbeit kann „Articulation Work“ auf abstrakter Ebene („ac-
tion within activity“) durch die automationsgestützte Verwaltung von Arbeitsorganisa-
tionswerkzeugen wie Kalendern und Todo-Listen unterstützt werden. Die „Articulation
Work“ auf konkreter Ebene („operation within action“) kann – im Falle der computerge-
stützten Abwicklung der zugehörigen „Production Work“ insofern unterstützt werden,
als dass die Benutzungsschnittstelle so an die Arbeitsdomäne angepasst ist, dass die
55
2.4. Unterstützung von Articulation Work
Notwendigkeit der Beschäftigung mit den technischen Eigenschaften und der Bedienung
des Systems geringer wird.
Bei lose gekoppelter kooperativer Arbeit zielt die geforderte Unterstützung von „Arti-
culation Work“ auf die Organisation der Arbeitsteilung ab. Dabei muss unter anderem
die Zuordnung von organisationalen Rollen zu beteiligten Individuen, die Erteilung von
Zugriffsrechten, sowie die Festlegung von Schnittstellen zwischen den Beteiligten be-
rücksichtigt werden. Während des Arbeitsprozesses ist die Verfügbarkeit von expliziten
Kommunikationskanälen und Mitteln zur Teilung von Daten notwendig.
Bei eng gekoppelter kooperativer Arbeit steigen die Anforderungen an Werkzeuge zur
Unterstützung von „Articulation Work“ insofern noch weiter, als dass hier zusätzlich die
Aushandlung der Durchführung von konkreten Arbeitsschritten, sowie die Abstimmung
untereinander in synchroner Zusammenarbeit unterstützt werden muss.
Auswirkungen
Die Arbeit beschreibt die Unterstützung von „Articulation Work“ auf rein konzeptueller
Ebene und führt keinerlei Auswirkungen derselben auf den Arbeitsprozess an.
Bewertung
Die Vorschläge der Autoren stehen weitgehend in Einklang mit dem Ausführungen von
Schmidt und Simone (1996) (siehe oben). Dies ist insofern bemerkenswert, als dass die
Ableitung der Maßnahmen auf Basis der „Activity Theory“ erfolgt, auf die in der anderen
Arbeit nicht Bezug genommen wurde.
Fjuk et al. formulieren Anforderungen an die technische Unterstützung von „Arti-
culation Work“ (in allen Kontexten, vorrangig explizit, in Teilaspekten auch implizit)
und führen exemplarisch Werkzeuge an, mit denen diese erfüllt werden können. Sie ge-
ben jedoch (im Gegensatz zu Schmidt und Simone (1996)) kein Konzept an, wie die
Unterstützung von „Articulation Work“ allgemein (d.h. unabhängig von jeweiligen An-
wendungsfall) realisiert werden kann.
Kontext Umsetzung von CSCW-Systemen auf Basis der Activity
Theory
Art von AW alle
Unterstützung durch computerunterstützte Werkzeuge zur Arbeitsor-
ganisation, Kommunikation und Aushandlung von Zu-
sammenarbeit
Auswirkungen keine angeführt
56
2.4. Unterstützung von Articulation Work
2.4.7. TeamSpace: an environment for team articulation work and
virtual meetings
Fuchs et al. (2001) beschreiben ein technisches System, dass die Zusammenarbeit in
Gruppen durch Unterstützung von „Articulation Work“ erleichtern soll.
Kontext
Die Autoren beschreiben die technische Unterstützung von „Articulation Work“ in (ver-
teilt arbeitenden) Gruppen mittels CSCW-Technologie. Ihr Anwendungsbereich ist die
Softwareentwicklung, in deren Kontext die Teams von Programmierern, die geographisch
verteilt sind, bei deren Zusammenarbeit unterstützen. Im Rahmen dieses Anwendungs-
gebietes wurde auch eine Studie zur Erhebung der Anforderungen an die technische
Unterstützung durchgeführt.
Unterstützung
Fuchs et al. (2001) präsentieren ein konkret umgesetztes System, das eine Reihe von
Werkzeugen zur Unterstützung von „Articulation Work“ bietet:
• „Task structured workspace“ Werkzeug zum Aufgabenmanagement und zur geteil-
ten Bearbeitung von Informations-Objekten. Dient außerdem als Container für die
übrigen Werkzeuge.
• „Place-based adaptation to work modes“ Die Autoren unterscheiden unterschied-
liche zu unterstützende „work modes“ („work“, „meeting“, „social“) und unter-
stützen diese unterschiedlich, indem die Benutzungsschnittstelle an den jeweiligen
Modus und dessen Artikulations-Anforderungen adaptiert wird.
• „Synchronous and asynchronous communication and awareness“ Werkzeug zur
Planung und Durchführung von virtuellen Meetings (inkl. Audio- und Video-
Übertragung) sowie Anzeige des aktuellen Tätigkeits- und Verfügbarkeitsstatus
von Mitarbeitern.
Auswirkungen
Das System wurde zum Zeitpunkt der Erstellung des Artikels nicht operativ eingesetzt.
Die Autoren treffen auch keine expliziten Aussagen zu den erwarteten Effekten des Sys-
tems.
57
2.4. Unterstützung von Articulation Work
Bewertung
Die Autoren gehen sehr konkret auf einzelne Werkzeuge zur Unterstützung von „Ar-
ticulation Work“ ein (ohne diese im Detail abzugrenzen und die zu unterstützenden
Aspekte zu motivieren). Sie beziehen sich auf Schmidt und Bannon (1992) und unter-
stützen auch die dort genannten wesentlichen Aspekte von „Articulation Work“. Die
konzeptuelle Aussagekraft ist ob der Fokussierung auf eine konkrete Implementierung
eher gering einzuschätzen.
Domäne Umsetzung von CSCW-Systemen zur Unterstützung
von Software-Entwicklung
Art von AW implizite und explizite „coordination of predefined
work“, expliztes „ad-hoc alignment“
Unterstützung technisch Werkzeuge zur aufgaben- und kontextorien-
tierten Anpassung der Benutzungsschnittstelle, Werk-
zeuge zur Kommunikation und zur Herstellung von Awa-
reness
Auswirkungen keine angeführt
2.4.8. Supporting different dimensions of adaptability in workflow
modeling
Divitini und Simone (2000) stellen ein System zur Unterstützung von etablierter koope-
rativer Arbeit in Form eines adaptiven Workflow-Systems vor, dessen Verhalten durch
die Durchführung von „Articulation Work“ beeinflusst werden kann bzw. die Durchfüh-
rung derselben unterstützt.
Kontext
Die Autoren bauen in ihrer Arbeit auf die von Schmidt und Simone (1996) vorgestellten
Konzepte auf und konkretisieren den Aspekt der Koordination von etablierten Arbeits-
abläufen („coordinating predefined work“). Dabei nehmen sie Bezug auf die Verwendung
von Workflow-Management-Systemen und integrieren die in diesem Bereich etablierten
Konzepte mit dem „Ariadne“-Ansatz von Schmidt und Simone (1996). Die Unterstüt-
zung von „Articulation Work“ erfolgt damit klar mit technischen Hintergrund.
Unterstützung
An dieser Stelle werden lediglich jene Unterstützungs-Maßnahmen beschrieben, die über
die in der Besprechung der Arbeit von Schmidt und Simone (1996) bereit genannt wur-
den, hinausgehen. Die Autoren schlagen vor, verteilte Arbeit bzw. deren Abstimmung
58
2.4. Unterstützung von Articulation Work
anstatt mit WfMS37 mit „Computational Coordination Mechanisms“ zu unterstützen.
Diese Koordinations-Mechanismen sind an den jeweiligen Anwendungsfall angepasste
computerbasierte Werkzeuge, die die Abstimmung der beteiligten Individuen während
der Durchführung eines Arbeitsablaufs unterstützten sollen. Wesentlich ist, dass das hier
vorgeschlagene Konzept die domänenabhängige Spezifikation dieser „Computational Co-
ordination Mechanisms“ umfasst bzw. auf diesem basiert.
Aufbauend auf den in Abschnitt 2.3 bereits beschriebenen abzustimmenden Arbeitsas-
pekten (hier: „Categories of Articulation Work“) können abhängig vom abzustimmenden
Aspekt Sprachen entworfen bzw. existierenden Sprachen auf diese Aspekte abgebildet
werden. Dies ermöglicht eine domänengerechte Spezifikation von „Computational Coor-
dination Mechanisms“ und damit die Unterstützung von „Articulation Work“ bereits in
der Phase der Planung eines Arbeitsablaufs.
Das so spezifizierte System unterstützt in der Folge die Ausführung von Arbeitsabläu-
fen. Es erlaubt auch (gesteuert durch ein festgelegtes Berechtigungssystem) unterschied-
lich starke, temporäre oder permanente Änderungen des spezifizierten Koordinations-
mechanismus.
Auswirkungen
Die Autoren machen keine Angaben über eine konkrete Anwendung des Ansatzes in der
Praxis. Durch die flexible Spezifikationsmöglichkeit der Koordinationsmechanismen ist
laut den Autoren eine reduzierte Komplexität bei der Spezifikation bzw. die exaktere
Abbildung der relevanten Information möglich38.
Bewertung
Die vorliegende Arbeit nimmt erstmals auf die Rolle von Modellen bei der technischen
Unterstützung von „Articulation Work“ Bezug. Die Autoren argumentieren, dass die Ad-
äquatheit der Repräsentationsform von Information im Rahmen expliziter „Articulation
Work“ ein wesentliches Erfolgskriterium ist. Obwohl die konkrete technische Umsetzung
nicht beschrieben ist, ist diese konzeptuelle Anforderung für das weitere Vorgehen be-
rücksichtigenswert.
37Workflow-Management-System
38„[. . . ] overcome some of the limits of almost all current approaches to process modeling [. . . ]: either
a restricted language focusing on a specific type of representation or a language comprehensive of
all potentially needed features, requiring the user to manage an overwhelming complexity.“(Divitini
und Simone, 2000, S. 377)
59
2.4. Unterstützung von Articulation Work
Kontext Integration von CSCW-Konzepten mit WfMS-Ansätzen
Art von AW „working out original arrangements“, explizite „coordi-
nation of predefined work“, explizites „resolving contin-
gencies“ sowie „reworking arrangements“
Unterstützung methodisch: Auswahl bzw. Definition einer adäquaten
Modellierungssprache, um Koordinationsmechanismen
zu spezifizieren, technisch: Möglichkeit der Ausführung
und Anpassung dieser Koordinationsmechanismen
Auswirkungen Vereinfachte Spezifikation der Koordinationsmechanis-
men, flexible Koordination bei der Ausführung des Ar-
beitsablaufs
2.4.9. Mundane knowledge management and microlevel
organizational learning: An ethological approach
Davenport (2002) beschreibt „Articulation Work“ als eine Form von „alltäglichem Wis-
sensmanagment“, mit Hilfe dessen beteiligte Individuen im Arbeitsprozess lernen und
ihre Kompetenzen erweitern („situated learning“).
Kontext
Davenport (2002) betrachten „Articulation Work“ aus einer Lern-Perspektive (unter
Bezugnahme auf „situated learning“ (Lave und Wenger, 1991)) und bezeichnen es als
alltägliches Wissensmanagement („mundane knowledge management“). Sie führt in wei-
terer Folge aus, inwiefern „situated learning“ in geographisch verteilten Gruppen durch
Informationstechnologie unterstützt werden kann und beziehen sich dabei auf das Kon-
zept der „Communities of Practice“ (Wenger, 1999).
Die Autorin verfolgt dabei eine enge Auffassung von „Articulation Work“ und bezieht
sich lediglich auf „routine interaction“ in Gruppen von Individuen.
Unterstützung
Anhand einer Fallstudie identifiziert die Autorin die unterschiedlichen Handlung-Phasen,
die im Rahmen eines Lernprozesses im Rahmen von „Articulation Work“ auftreten und
zeigt, wie diese im konkreten Fall unterstützt wurden. Wesentlich ist hier nicht die
konkrete technische Unterstützung, die sich auf die Bereitstellung einer Kommunikation-
Plattform beschränkte, sondern der verfolgte methodische Ansatz, die auf die Konzepte
der „Communities of Practice“ zurückgreift.
Während der eigentliche Arbeitsdurchführung arbeitet die betreffende Gruppe von In-
dividuen selbstgesteuert und koordiniert sich selbst. In Fällen, in denen ein Problem auf-
60
2.4. Unterstützung von Articulation Work
tritt („resolving contingencies“), erweist sich das Eingreifen eines „facilitators“ im Sinne
von Wenger (1999) als hilfreich. Dieser übernimmt die Aufgabe, die durchzuführende
„Articulation Work“ zu koordinieren und zu moderieren, so dass die aufgetretene pro-
blematische Situation gelöst werden kann. Die Rolle des „facilitators“ kann dabei auch
dynamisch von einem bereits beteiligten und in dieser Hinsicht kompetenten Individuum
übernommen werden und muss nicht permanent besetzt werden. „Kompetent“ bedeutet
in diesem Zusammenhang, die eingesetzten technischen Werkzeuge zu beherrschen, Do-
mänenwissen zu haben und Kompetenz in der Extraktion und Zusammenfassung von
Wissen der einzelnen beteiligten Individuen zu haben.
Auswirkungen
In der Arbeit sind keine konkreten Ergebnisse der getroffenen Maßnahmen angeführt.
Die Generalisierbarkeit der aus der Fallstudie abgeleiteten Maßnahmen wird explizit
nicht behandelt und bleibt offen.
Bewertung
Die Arbeit führt das Konzept der „Communities of Practice“ mit jenem der „Arti-
culation Work“ zusammen. Die Autorin zeigt, dass die nicht formalisierte Interaktion
in Communities ein geeignetes Mittel ist, um zumindest die einfacheren (im Sinne von
„unproblematischen“) Fälle von „Articulation Work“ zu bewältigen. Inwieweit sich diese
Organisationsform auch für komplexere Problemfälle eignet, bleibt offen.
Die Arbeit zeigt jedoch als eine von wenigen Ansätzen einen nicht durch Technik
getriebenen Weg der Unterstützung von „Articulation Work“ auf und ist aus diesem
Grund berücksichtigenswert.
Kontext „situated learning“, Wissensmanagement, „Commu-
nities of Practice“
Art von AW „coordinating predefined work“ & „resolving contingen-
cies“
Unterstützung durch die organisationale und technische Unterstützung
von „Communities of Practice“
Auswirkungen —
2.4.10. Modelling Cooperative Work: Chances and Risks of
Structuring
61
2.4. Unterstützung von Articulation Work
Herrmann et al. (2002) beschäftigen sich mit Modellen von soziotechnischen Arbeits-
prozessen und zeigen auf, dass zu deren (kooperativen Erstellung) „Articulation Work“
notwendig ist.
Kontext
Herrmann et al. (2002) beschreiben die (kooperative) Bildung von diagrammatischen
Modellen in sozio-technischen Systemen und deren Auswirkung auf den realen Arbeits-
ablauf. Sie beziehen sich dabei nur am Rande auf „Articulation Work“ (im Kontext der
CSCW-Forschung von Schmidt und Bannon (1992)) und bezeichnen damit jene Vorgän-
ge, die notwendig sind, um die individuellen Sichtweisen der am Arbeitsablauf beteiligten
Personen abzustimmen und in einem gemeinsamen Modell zu repräsentieren („articu-
lating and negotiating“ – siehe Abbildung 2.7). In anderen Publikationen der Autoren
wird ein Modellierungswerkzeug (Herrmann et al., 2004a) und eine Methode (Herrmann
et al., 2004b) beschrieben, die diesen Vorgang unterstützen soll.
Abbildung 2.7.: Mentale Modelle im Kontext der Arbeitsmodellierung (entnommen aus
(Herrmann et al., 2002))
Unterstützung
Im Rahmen mehrerer Fallstudien zeigen die Autoren, dass die Verwendung von diagram-
matischen Modellen als externalisierte Repräsentation von individuellen Sichten auf Ar-
beitsabläufe bei deren Abstimmung und Verbesserung – also bei der Durchführung von
„Articulation Work“ – hilfreich ist. Externalisierte Modelle bringen jedoch auch Risiken
62
2.4. Unterstützung von Articulation Work
mit sich, die durch eine adäquate Unterstützung des Modellierungsprozesses gemindert
werden müssen. Konkret erwähnen die Autoren die schwierige Veränderbarkeit einmal
niedergeschriebener Arbeitsabläufe, die potentiell fehlerhafte oder unzureichende Ab-
bildung des Arbeitsablaufs im Modell sowie (im Kontext der kooperativen Erstellung)
jene Unzulänglichkeiten des Modells, die durch bewusst falsch oder nicht offengelegte
Arbeitsaspekte aus „politischen“ Gründen entstehen.
In der Folge entwickeln Herrmann et al. Anforderungen an einen Modellierungspro-
zess sowie eine Modellierungssprache, die diese Risiken so weit möglich vermeiden und
„Articulation Work“ unterstützen:
• Modelle müssen „aus dem Arbeitsablauf heraus“ entstehen, also von den unmit-
telbar betroffenen Personen entwickelt werden und dürfen nicht von „außerhalb“
übergestülpt werden.
• Die Modellierungssprache muss es erlauben, die Dynamik der abgebildeten Struk-
turen darzustellen.
• Sie muss sowohl zur Abbildung (präskriptiver) exakter Arbeitsabläufe („scripts“)
als auch zur Abbildung des (Orientierung gebenden) Arbeitskontext („maps“) ge-
eignet sein.
• Detaillierungs- und Abstraktionsgrad der Abbildung müssen frei wählbar sein.
• Information über den Modellierungsverlauf selbst muss im Modell abbildbar sein.
• Die Modellierungssprache muss die Abbildung beliebiger Aspekte von Arbeit (nicht
nur Aktivitäten und Ressourcen, sondern z.B. auch Rollen oder Kompetenzen)
erlauben.
• Der Modellierungsvorgang muss durch ein flexibles Werkzeug unterstützt werden,
das die Verwendung der Unterstützungsfunktionalitäten ermöglicht aber nicht er-
zwingt.
• Das Werkzeug sollte den Export der Modelle in beliebige Datenformate ermögli-
chen, um deren Weiterverarbeitbarkeit zu gewährleisten.
Auswirkungen
Anhand der Fallstudien zeigen die Autoren, dass das ein Vorgehen nach den beschriebe-
nen Richtlinien, sowie eine entsprechende Werkzeugunterstützung bei der Abstimmung
von kooperativen Arbeitsabläufen hilfreich ist (siehe dazu auch (Herrmann et al., 2000)).
Bewertung
Die Arbeit kann als ein Beitrag zur Unterstützung von „Articulation Work“ im Sinne
von „making agreements“ verstanden werden, auch wenn dies nicht explizit so benannt
63
2.4. Unterstützung von Articulation Work
wird. In diesem Zusammenhang führen die Autoren die Nützlichkeit von externalisierten
Modellrepräsentation bei der Abstimmung und Aushandlung von Arbeitsabläufen an.
Für diese Form der Unterstützung werden konkrete Anforderungen sowohl methodischer
als auch technischer Natur gegeben, was diese Arbeit zu einer wertvollen Quelle für die
weiteren Ausführungen in der vorliegenden Arbeit macht.
Kontext Modellierung von Arbeit,
Art von AW explizites „agreement making“
Unterstützung flexible Modellierung von Arbeitsabläufen unter Einbe-
ziehung der unmittelbar beteiligten Individuen
Auswirkungen Erleichterung bzw. Ermöglichung der Abstimmung oder
Aushandlung von kooperativen Arbeitsabläufen
2.4.11. Recursive Articulation Work in Ariadne: The Alignment of
Meanings
(Sarini und Simone, 2002a) beschäftigen sich mit „recursive Articulation Work“, also
jener Form, deren Gegenstand selbst wiederum „Articulation Work“ ist. Die Autoren
leiten Anforderungen an die Unterstützung dieser Form von „Articulation Work“ ab
und zeigen die konkrete Umsetzung als Teil des „Reconciler“-Systems.
Kontext
Die Arbeit baut auf den oben bereits beschriebenen Arbeiten (Schmidt und Bannon,
1992) und (Divitini und Simone, 2000) auf und beschäftigt sich mit der technischen
Unterstützung von „Articulation Work“ durch CSCW-Systeme. Konkret wird auf jene
Fälle von „Articulation Work“ eingegangen, wo „alignment of meaning“ (also die Ab-
stimmung der individuellen Verständnisse der Arbeitsdomäne) notwendig ist. Es ist kein
spezifischer Anwendungsbereich angeführt, das Konzept hat den Anspruch, generisch
anwendbar zu sein.
Unterstützung
Die Arbeit behandelt zwei unterschiedliche Phasen von „Articulation Work“: jene, in
denen die beteiligten Individuen die auftretende Probleme abgrenzen, detailliert spezifi-
zieren und (Teil-)Lösungen aushandeln („agreement making“) und jene, in denen Koordi-
nationsprobleme durch die gesammelte Information bereits vor dem Auftreten verhindert
werden („coordination of predefined work“). Während zweitere Unterstützung an dieser
Stelle nicht näher behandelt wird, da es sich bei der vorgeschlagenen Implementierung
lediglich um ein Vorschlagssystem für Begriffe an der Benutzungsschnittstelle handelt,
muss erstere Unterstützungsform näher betrachtet werden.
64
2.4. Unterstützung von Articulation Work
Der dabei angestoßene Unterstüzungsprozess ist ein Koordinationsmechanismus im
Sinne von Divitini und Simone (2000). Im Rahmen der Ausführung desselben wird
ein „Reconciliation Artifact“ generiert und enthält eine Abbildung der individuellen
Begriffswelten der beteiligten Individuen, die untereinander in Korrespondenz gesetzt
werden. Wie die Externalisierung der Begriffe, sowie deren Assoziation untereinander
ablaufen, schränkt der Ansatz bewusst nicht ein bzw. legt sich nur vorläufig fest39. Das
„Reconciler“-System unterstützt dabei die Erfassung und Verwaltung der offengelegten
Begriffe. Wie es den Artikulationsprozess konkret unterstützt, ist in Mark et al. (2002a)
angeführt, hier aber nicht Gegenstand einer detaillierteren Betrachtung, da vorrangig
technische Implementierungsdetails beschrieben wurden.
Auswirkungen
In der vorliegenden Arbeit werden keine Aussagen hinsichtlich der tatsächlichen Aus-
wirkungen der Unterstützung getroffen. Auch Mark et al. (2002a) kommen auf Basis
einer empirischen Studie zu dem Schluss, dass die Unterstützungleistung nicht allgemein
nachgewiesen werden kann und ist stark von der individuellen Nutzungsbereitschaft ab-
hängig.
Bewertung
Die Autoren gehen auf die Unterstützung jenes Teils von „Articulation Work“ ein, der
zur Abstimmung der individuellen Sichten auf den Arbeitsablauf und der jeweiligen
Begriffswelten eingesetzt wird. Auch wenn sie in der konkreten methodischen Umsetzung
vage bleiben, ist erstmals eine explizite Beschäftigung mit der Unterstützung dieser
Phase vorhanden.
Kontext CSCW
Art von AW explizites „agreement making“, „coordination of prede-
fined work“
Unterstützung durch die Abstimmung der individuellen Sichten auf ei-
ne Domäne, der Offenlegung des Vokabulars in einem
geteilten Artefakt und dessen Verwendung während der
Arbeit
Auswirkungen —
39„For sake of testing the integration we are aiming at, we defined the simplest protocol: all the users
involved in the reconciliation process can communicate among themselves to define the correspon-
dences, while a single Actor assumes the Role of Manager of the Reconciliation Artifact and is in
charge of keeping it updated.“(Sarini und Simone, 2002a, S. 10)
65
2.4. Unterstützung von Articulation Work
2.4.12. Combining Communication and Coordination Toward
Articulation of Collaborative Activities
Raposo et al. (2004) decken in ihrer Arbeit zur (technischen) Unterstützung kooperativer
Arbeit explizit alle Zeitpunkte, in denen „Articulation Work“ auftreten kann, ab („pre-
articulation“, „coordination“, „post-articulation“).
Kontext
Die Autoren schlagen eine technische Unterstützung von „Articulation Work“ mittels
CSCW-Werkzeugen vor. Sie fassen dabei das Konzept „Articulation Work“ sehr weit
und inkludieren neben der Planungs- und Durchführungsphase eines Arbeitsablaufs auch
dessen Nachlauf („post-articulation“), in dem die durchgeführte Koordination reflektiert
wird. Zur Unterstützung verfolgen die Autoren einen formalisierten Ansatz, der auf
Konzepten der theoretischen Informatik aufbaut. Das Anwendungsgebiet ihres Ansatzes
schränken die Autoren nicht ein und berücksichtigen explizit lose wie auch eng gekop-
pelte kooperative Arbeitsabläufe mit beliebig vielen beteiligten Individuen.
Unterstützung
Je nach Phase der „Articulation Work“ unterscheiden die Autoren zwischen unterschied-
lichen Arten der Unterstützung. Für die „pre-“ und „post-articulation“-Phase wird die
Verwendung von „conversation clichés“ zur Aushandlung von „commitments“ vorge-
schlagen. Während der „coordination“-Phase werden die „commitments“ automations-
gestützt zur Anwendung gebracht.
„Conversation clichés“ sind im Wesentlichen Zustandsautomaten, die den Rahmen
einer Konversation zwischen Individuen vorgeben. Sie dienen jeweils der Erreichung einer
bestimmten Art von „commitment“. „Commitments“ sind logische Konstrukte, in denen
die individuelle Zustimmung oder Ablehnung zu Aussagen ausgedrückt werden kann,
die die Koordination beschreiben. Weiters ist es möglich, explizit kein „commitment“ zu
einer Aussage abzugeben. Auf Basis dieser „commitments“ bestimmt ein Algorithmus
die Modalitäten der Zusammenarbeit.
Während der „coordination phase“ kommt ein „task/interdependency-model“ zum
Einsatz, das im Wesentlichen einem auf die „commitments“ abgestimmten Aktivitäts-
diagramm entspricht. In diesem Modell werden letztlich die durchzuführenden Aufgaben
und deren gegenseitige Abhängigkeiten definiert. Während der Ausführung kann das
System dann auf diese Abhängigkeiten hinweisen bzw. die notwendigen Koordinations-
mechanismen auslösen.
66
2.4. Unterstützung von Articulation Work
Auswirkungen
Konkrete Auswirkungen werden in der Publikation nicht angeführt. Die Autoren er-
wähnen die Simulierbarkeit und Verifizierbarkeit der erstellten Modelle als Vorteil der
formalen Repräsentation.
Bewertung
Die Autoren verfolgen einen – im Gegensatz zu anderen Arbeiten – stark regulatorischen
Ansatz zur Unterstützung von „Articulation Work“. Die vorgeschlagenen Mechanismen
zur Abstimmung und Koordination von kooperativer Arbeit versuchen, den Arbeitsver-
lauf durch computergestützte Vorgaben in einem definierten Rahmen zu halten und so
das Auftreten von problematischen Situationen zu verhindern.
Der Vorteil dieses eher restriktiven Vorgehens liegt in der Formalisierbarkeit der In-
teraktionsmuster und Arbeitsabläufe und der damit verbundenen Verifizierbarkeit und
Simulierbarkeit der erstellten Modelle.
Kontext CSCW, Formale Modelle von Interaktion
Art von AW explizites „making arrangements“, explizite „coordina-
tion of predefined work“
Unterstützung „making arrangements“: Aushandlungsunterstützung
durch „Conversation Clichés“, „coordination“ durch die
Ausführung der ausgehandelten Aufgabenmodelle
Auswirkungen formale Verifizierbarkeit und Simulierbarkeit
2.4.13. Interactive Process Models
Jørgensen (2004) beschreibt die Verwendung von „interaktiven“ Prozessmodellen in or-
ganisationalen Arbeitsprozessen und die Veränderung dieser Prozesse durch Modellie-
rungsvorgänge. Dabei bezeichnet er den Modellierungsvorgang als „Articulation Work“.
Kontext
Im Gegensatz zu den anderen hier behandelten Arbeiten steht bei Jørgensen (2004) nicht
die Unterstützung der Koordination von Arbeitsprozessen im Vordergrund. Die Arbeit
beschäftigt sich mit Prozessmodellen (also ablauforientierten Modellen von Arbeit) und
sieht „Articulation Work“ als jene Tätigkeit, die zur Erstellung dieser Modelle notwendig
ist. Die Rückwirkung der Modelle auf die reale Arbeitswelt wird als „Model Activation“
bezeichnet. Modellierung ist hierbei eine Aktivität, die von den betroffenen Personen
selbst ausgeführt wird, die erstellten Modelle bilden dementsprechend die individuelle
Sicht auf eine Arbeitsablauf ab. Insofern ist der vorgestellt Ansatz tatsächlich als eine
67
2.4. Unterstützung von Articulation Work
Form von „making arrangements“ (als Variante von expliziter, planender „Articulation
Work“) zu sehen.
Unterstützung
Jørgensen führt Anforderungen an eine Modellierungssprache an, die „ArticulationWork“
unterstützt. Diese sollte:
• einfach sein und nur wenige Basiselemente enthalten. Elemente der realen Welt
sollten eindeutig in das Modell abgebildet werden können. Die Aussage des Modells
sollte möglichst intuitiv erschließbar sein.
• visuell bzw. graphisch darstellbar sein. Die Darstellung sollte sowohl einen Über-
blick über das Gesamtmodell als auch detaillierte an sichten einzelner Ausschnitte
ermöglichen.
• Konstrukte enthalten, die auf die jeweilige Anwendungsdomäne der Modellierenden
abgebildet bzw. angepasst werden können.
• nicht statisch hinsichtlich der Bedeutung der verwendeten Modellelemente sein.
Die Bedeutung der Modellelemente kann sich während der Erstellung der Modelle
durch Aushandlung oder Reflexion verändern.
Der Autor führt zur Erfüllung dieser Anforderungen eine Modellierungssprache ein, die
den Ansatz des „semantic holism“ verfolgt. In Sprachen, die den Ansatz des „semanti-
schen Holismus“ berücksichtigen, haben Modellelemente keine eindeutige, fix vorgegebe-
nen Bedeutung. Vielmehr erschließt sich der Bedeutung der einzelnen Elemente erst aus
dem Gesamtzusammenhang des Modells, also aus dem Zusammenspiel aller Elemente.
Auch im Feld der „coordination of predefined work“ liefert Jørgensen (2004) Ansät-
ze zur Unterstützung von Articulation Work, indem er die erstellten Modelle semi-
automatisiert („interactive“) ausführbar macht („activation“).
Auswirkungen
Der Autor führt keine konkrete Evaluierung seines Ansatzes an, weshalb keine Aussa-
gen zu den Auswirkungen des Ansatzes in der Praxis gemacht werden können. Aus der
zugrunde liegenden Literatur leitet er jedoch ab, dass der gewählte Ansatz zur Modellie-
rung eine adäquatere und einfachere Abbildung der Realität durch in der Modellierung
ungeübte Individuen ermöglicht als andere gängige Modellierungs-Methoden.
Bewertung
Die Fokussierung auf Modellbildung als Aktivität im Rahmen von „Articulation Work“
ist ein Alleinstellungsmerkmal dieser Arbeit. Jørgensen berücksichtigt die für „Articula-
68
2.4. Unterstützung von Articulation Work
tion Work“ notwendige Flexibilität in der technischen und methodischen Unterstützung
derselben und stellt Anforderungen auf, die eine Modellierungssprache erfüllen muss, um
„Articulation Work“ adäquat zu unterstützen. Die Unterstützung der Ausführung der
Modelle in interaktiver Form ohne die im WfMS üblichen strikten Abläufe kommt einer
flexiblen Koordination des eigentlichen Arbeitsablaufs ebenfalls entgegegen.
Kontext Prozessmodellierung, Workflow-Managment
Art von AW explizites „making arrangements“, „coordinating prede-
fined work“
Unterstützung „making arrangements“: durch flexible, anwenderzen-
trierte Modellbildung, „coordinating“: durch interaktive
Ausführung der erstellten Modelle
Auswirkungen adäquate und einfache Abbildung sowie intuitive Inter-
pretierbarkeit der Modelle und damit Unterstützung von
expliziter „Articulation Work“ durch Modelle von Ar-
beit
2.4.14. Torres, a Conceptual Framework for Articulation Work
across Boundaries
Cabitza et al. (2006) stellen mit „Torres“ ein Framework vor, das sich speziell zur Un-
terstützung von „globaler Articulation Work“ eignet.
Kontext
Cabitza et al. (2006) entwickeln den weiter oben beschriebenen Ansatz von Sarini und
Simone (2002a) weiter und wenden ihn unter Bezugnahme auf Færgemann et al. (2005)
auf „globale Articulation Work“ an. Die Autoren stehen damit in der Tradition der tech-
nischen Unterstützung von „Articulation Work“ durch CSCW-Werkzeuge und wenden
diese im speziellen auf Situationen an, in denen Individuen oder Organisationseinheiten
kooperieren müssen, die außerhalb des betreffenden Arbeitsablaufs keine kooperativen
Tätigkeiten durchführen.
Unterstützung
Die Autoren bleiben grundsätzlich bei dem Ansatz von Sarini und Simone (2002a), die
Koordination von Arbeit mittels Artefakten zu unterstützten, die auf den jeweiligen An-
wendungsfall angepasst sind. „Torres“ ist dabei ein Framework zur Erstellung derartiger
Artefakte. Dazu wird ein zweistufiger Prozess vorgeschlagen, der die domänenübergrei-
fende Verständlichkeit der artikulierten Information sicherstellen soll.
69
2.4. Unterstützung von Articulation Work
In der ersten Phase werden von jedem beteiligten Individuum bzw. von jeder betei-
ligten Instanz „Local Formal Representations“ der jeweiligen Domäne erstellt werden.
Diese enthalten nicht Modelle der Arbeitsabläufe selbst sondern lediglich die wesentli-
chen Konzepte der Domäne, die potentiell missverständlich sein können.
In der zweiten Phase werden die „Local Formal Representations“ zu einem einheit-
lichen, vorgegebenen Modell von „Articulation Work“ mittels ebenfalls vorgegebener
Relationen in Beziehung gesetzt. Dadurch ist es möglich, etwaig auftretende Missver-
ständnisse automationsgestützt aufzulösen bzw. zu vermeiden.
Auswirkungen
Die Autoren leiten die Eigenschaften ihres Systems aus den Beobachtungen in einer
Fallstudie aus dem medizinischen Bereich ab. Die Implementierung war jedoch zum
Zeitpunkt der Publikation nicht abgeschlossen, auch in Folgepublikationen (z.B. (Ca-
bitza et al., 2009)) ist keine explizite Beschreibung von Auswirkungen des Systems im
praktischen Einsatz vorhanden.
Bewertung
Die Autoren entwickeln den in Sarini und Simone (2002a) vorgeschlagenen „Reconciler“-
Ansatz weiter und detaillieren vor allem jene Phase, in der „alignment of meanings“
durchgeführt wird. Methodisch schlagen die Autoren einen individuell durchzuführende
zweistufigen Prozess vor, dessen Ergebnisse automatisiert mit den Ergebnissen der ande-
ren Individuen zusammengeführt werden. Methodisch ist dies der detaillierteste Ansatz
der Arbeiten der Gruppe rund um Simone und wird deswegen an dieser Stelle betrach-
tet.
Kontext CSCW
Art von AW „making arrangements“
Unterstützung methodisch: Abstimmung unterschiedlicher Domänen-
modelle und Erstellung von Informations-Artefakten,
die domänenübergreifend verständlich sind
Auswirkungen —
2.4.15. Gegenüberstellung und Zusammenfassung
Die Möglichkeiten zur Unterstützung von „Articulation Work“ sind ob der großen Spann-
weite möglicher Ausprägungen vielfältig. Im Allgemeinen zeigt sich die Tendenz, dass
die Unterstützung bei einfacheren Formen (wie „coordination of predefined work“) eher
mittels rein organisationalen Mitteln erfolgen kann, während bei komplexeren Formen
70
2.4. Unterstützung von Articulation Work
von „Articulation Work“ zusätzlich auch technische Mittel eingesetzt werden und me-
thodische Unterstützung angeboten wird. Außerdem soll durch technische Unterstützung
der Phase, die dem eigentlichen Arbeitsablauf voraus geht (Planung, „making original
arrangements“) das Auftreten von problematischen Situationen (und damit der Bedarf
nach komplexen Formen von „Articulation Work“) während der Durchführung des Ar-
beitsablaufs vermieden werden.
Für einfache Formen von „Articulation Work“, in denen etablierte Arbeitsabläufe ko-
ordiniert bzw. kleine Unklarheiten oder Hindernisse beseitigt werden müssen, werden
in der Literatur immer wieder soziale Mechanismen als ausreichendes Regulativ be-
schrieben (z.B. in (Raposo et al., 2001) oder (Schmidt, 1994)). Davenport (2002) nennt
„Communities of Practice“ (Wenger, 1999) als mögliches Instrument zur Institutionali-
sierung dieser sozialen Mechanismen. Einen Spezialfall stellen hier jene Arbeitsabläufe
dar, die verteilt durchgeführt werden und in denen deshalb die sozialen Mechanismen
durch technische Mittel ermöglicht werden müssen (Færgemann et al., 2005). In die-
sen Fällen werden auch einfache Formen von „Articulation Work“ technisch unterstützt
(z.B. bei (Divitini und Simone, 2000) oder (Fuchs et al., 2001)).
Je komplexer die Arbeitssituation wahrgenommen wird, desto notwendiger wird eine
explizite Beschäftigung mit den abzustimmenden Arbeitsaspekten (auch bei Arbeits-
abläufen, die nicht oder nur in Teilaspekten kooperativ bearbeitet werden (Fjuk et al.,
1997)). Letztendliches Ziel ist es immer, einen Status (wieder-)herzustellen, in dem sozia-
le, implizite Mechanismen zur Koordination ausreichen. Organisationale (z.B. bei (Grin-
ter, 1996)) oder auch technische Unterstützung (z.B. bei (Schmidt und Simone, 2000)
und allen auf dieser Publikation aufbauenden Arbeiten) kann hierbei hilfreich sein.
Bei der technischen Unterstützung von „Articulation Work“ können zwei Ansatzpunk-
te unterschieden werden. Einerseits kann die Lösung von aufgetretenen Problemen unter-
stützt werden (z.B. bei (Grinter, 1996)) oder deren Auftreten von vorneherein verhindert
werden (z.B. bei (Raposo et al., 2004)). Andererseits kann „Articulation Work“ bei der
Planung von Arbeitsprozessen unterstützt werden, wobei unter anderem die Koordinati-
onsmechanismen während der Durchführung des Arbeitsablaufs vereinbart werden (z.B.
bei Sarini und Simone (2002b) und den darauf aufbauenden Arbeiten). Ziel ist es hier,
schon im Vorfeld den Arbeitsablauf bzw. die unterschiedlichen Sichten darauf soweit ab-
zustimmen, dass die Koordination möglichst unproblematisch und implizit abgehandelt
werden kann.
Diese Form von „Articulation Work“ wird vom Großteil der in diesem Bereich tätigen
Autoren durch Modelle der zu koordinierenden Arbeit als explizite Artefakte im Arti-
kulationsprozess unterstützt (z.B. bei (Divitini und Simone, 2000), (Sarini und Simone,
2002a), (Raposo et al., 2004) oder (Jørgensen, 2004)). Diese Modelle werden von den
beteiligten Personen erstellt und müssen syntaktisch einfach bzw. intuitiv zu handha-
ben und semantisch flexibel sein (Herrmann et al., 2002) (Jørgensen, 2004). Der Inhalt
der Modelle kann sowohl der eigentliche Arbeitsablauf sein (Divitini und Simone, 2000)
71
2.5. Thought processes und Articulation Work
als auch die allgemeinen Struktur der Arbeitsdomäne konzeptuell abbilden (Sarini und
Simone, 2002a).
Die existierenden Arbeiten in diesem Bereich setzten allerdings die Existenz dieser
Modelle voraus bzw. schaffen die konzeptuellen Rahmenbedingungen, um die Erstel-
lung derartiger Modelle zu ermöglichen. Dabei sind sie immer durch den Anspruch ein-
geschränkt, die Modelle automationsgestützt zur Unterstützung der Koordination im
Arbeitsablauf selbst weiterzuverarbeiten. Die Anforderung an die Modellierungssprache
sind also nur zum Teil aus den Bedürfnissen der Benutzer abgeleitet, sondern vielmehr
ein Kompromiss zwischen den Anforderungen des technischen Systems und der Bedürf-
nisse der Benutzer. Mit der konkreten Erstellung der Modelle selbst beschäftigen sich
lediglich Herrmann et al. (2002) sowie Jørgensen (2004), auch sie gehen aber nicht auf
die konkrete Unterstützung der Individuen im Modellierungsprozess ein.
Die Unterstützung der an einem Arbeitsablauf beteiligten Individuen bei Modellbil-
dung und -abstimmung als „Articulation Work“ weist an dieser Stelle also Lücken auf,
die bislang nicht behandelt wurden. Dies ist insofern problematisch, als dass vor allem
komplexe Formen von „Articulation Work“ auf externe Repräsentationen zurückgreifen,
um die Abstimmung zu erleichtern. Im weiteren Verlauf dieser Arbeit wird deswegen
versucht, methodische und technische Hilfsmittel zu entwickeln, die auf Modellen ba-
sierende „Articulation Work“ unterstützen kann. Einen möglichen Ansatzpunkt dazu
liefert bereits Strauss (1993).
2.5. Thought processes und Articulation Work
Zur Zielsetzung von „Articulation Work“ und deren Unterstützung treffen die im letzten
Abschnitt betrachteten Arbeiten klare Aussagen. Offen bleiben jedoch vor allem bei der
Unterstützung komplexerer Formen von „Articulation Work“ explizite Aussagen zu den
notwendigen Leistungen der Individuen im Prozess der Artikulation, deren konkrete
Ausgestaltung und der möglichen Unterstützung.
Bereits Strauss ist sich dieser (konzeptuellen) Auslassung bewusst40, und beschäftigt
sich in späteren Arbeiten (etwa (Strauss, 1993)) auch mit jenen kognitiven Vorgängen,
die von ihm als „thought processes“ oder „mental activities“ bezeichnet werden und
40„[. . . ] many social scientist pay almost no attention to interior activity: ignoring it, taking it for
granted, but leaving it unexamined, or giving it the kind of abstract but not very detailed analysis
[. . . ]“(Strauss, 1993, S. 131)
72
2.6. Zusammenfassung
die untrennbar mit jeder Art von Tätigkeit und Interaktion verbunden sind41 und diese
beeinflussen42.
Im Kontext der Abstimmung von Arbeitsabläufen kommt den „thought processes“ der
Individuen große Bedeutung zu, da sie den sichtbaren individuellen Handlungen zugrun-
de liegen bzw. diese beeinflussen. „Articulation Work“ wirkt sich also auf die „thought
processes“ der beteiligten Individuen aus (wie auch von Davenport (2002) im Kontext
des „situated learning“ erwähnt). Strauss interessiert sich allerdings ausschließlich für
die dynamischen Aspekte der Interaktion zwischen Individuen, nicht aber für die Aus-
gangspunkte und Ergebnisse der zugrunde liegenden „thought processes“.43
Die Repräsentationen, auf denen „thought processes“ beruhen und operieren, sind
jedoch für die Unterstützung von „Articulation Work“ von Interesse. Vorhandene Ar-
beiten (etwa (Herrmann et al., 2002) oder (Jørgensen, 2004)) beschäftigen sich lediglich
mit bereits externalisierten Repräsentationen, gehen jedoch ebenfalls nicht auf deren
Erstellung oder Ursprung ein. Die kognitions-wissenschaftlichen Ansätze zu Schemata
((Rumelhart und Norman, 1978) (vgl. nach Hanke, 2006)) und mentalen Modellen ((vgl.
Seel, 1991)) sind ein Erklärungsansatz für diese Lücke (Herrmann et al., 2002).
2.6. Zusammenfassung
In diesem Abschnitt wurde „Articulation Work“ als ein Erklärungsmodell für die koordi-
nierenden Abläufe bei kooperativer menschlicher Arbeit eingeführt. Nach einer Begriffs-
klärung auf Basis der zur Thematik publizierten Literatur wurden die unterschiedlichen
Ausprägungen beschrieben, in denen „Articulation Work“ auftreten kann und in welchen
Situationen welche Ausprägung auftritt. Den Abschluss des allgemeinen Teils bildet eine
Übersicht über die Gegenstände von „Articulation Work“, also jene Arbeitsaspekte, die
potentiell abgestimmt werden müssen.
Der zweite Teil des Kapitels beschreibt technische und methodische Möglichkeiten zur
Unterstützung der Durchführung von „Articulation Work“. Die dort identifizierten An-
sätze zeigen ein breites Spektrum von Möglichkeiten der Unterstützung für unterschied-
liche Ausprägungen von „Articulation Work“. Vor allem im Bereich der Unterstützung
von „explizter Aritculation Work“, also der bewusst angestossenen und durchgeführten
Form von „Articulation Work“, kommen in einem Großteil der Arbeiten diagrammati-
41„These [thought processes] accompany visible action, as well as precede and follow in conditional and
consequential modes“(Strauss, 1993, S. 146)
42„Even well-grooved, routine action and interaction may be accompanied by thought [. . . ] directly
relevant to the work at hand. As I vacuum the house, barely noticing my movements, still I give
myself commands [. . . ]“(Strauss, 1993, S. 132)
43„I use the gerund ’ing’ after ’symbol’ [bei der Beschreibung von ’symbolizing’, Anm.] to signify that
my principal interest is, again, in interaction rather than its products, for symbols are precipitates
of interaction“(Strauss, 1993, S. 149)
73
2.6. Zusammenfassung
sche Modelle zum Einsatz. Diese erleichtern die Abstimmung und ermöglichen die ein-
facherer und schnellere Entwicklung einer gemeinsamen Sichtweise auf den betrachteten
Arbeitsablauf.
2.6.1. Beitrag zur globalen Zielsetzung
Hinsichtlich der in Kapitel 1 formulierten Forschungsfragen und Fragestellungen wurde in
diesem Kaptitel vor allem die Fragestellung 1 („Was ist Articulation Work und wie wirkt
sie im Arbeitsprozess“) behandelt. Die relevanten Konzepte und Untersuchungen wurden
in den Abschnitten 2.1 und 2.2 erarbeitet und einander gegenübergestellt (auf Grundlage
der in Anhang A aufgearbeiteten Literatur zum Themengebiet „Articulation Work“).
Das Ergebnis der Aufarbeitung ist eine Konzeption von „Articulation Work“, in der alle
in der Literatur genannten Auslöser, Ausprägungen und Zielsetzungen berücksichtigt
wurden (siehe Abbildung 2.3).
In Abschnitt 2.3 wurde mit der Betrachtung der im Rahmen von „Articulation Work“
abzustimmenden Aspekte der „Production Work“ jene Betrachtungsgegenstände identi-
fiziert, an denen sich die Durchführung von „Articulation Work“ zeigt. Für diese Arbeit
ist dies von Interesse, als dass an diesen die Effektivität der Durchführung von „Ar-
ticulation Work“ beobachtet werden kann. Diese Effektivität ist dann gegeben, wenn
eine gemeinsame Sichtweise auf die abzustimmenden Gegenstände, konkret also die re-
levanten Aspekte des Arbeitsablaufs selbst sowie jene aus dessen Umfeld, entwickelt
wurde. Dies ist ein erster Beitrag zur Bearbeitung der Fragestellung 5 („Wie kann die
Effektivität der Unterstützung von expliziter Articulation Work beurteilt werden?“).
Die in Abschnitt 2.4 dargestellte Literatur zum Themengebiet der Unterstützung von
„Articulation Work“ konkretisiert einerseits die Beantwortung der Fragestellung 1 hin-
sichtlich der Wirkungsweise in Arbeitsprozessen, trägt aber andererseits vor allem zur Er-
arbeitung der Möglichkeiten zur methodischen Unterstützung von „Articulation Work“
bei (Fragestellung 3). Auf Basis der dortigen Ergebnisse zeigt sich, wie in Abschnitt
2.4.15 beschrieben, dass in existierenden Arbeiten zur Unterstützung von „Articulation
Work“ nur auf die zu unterstützenden Phänomene und Abläufe eingegangen wurde. Die
zweite von Grudin (1988) formulierte Forderung nach einer Berücksichtigung der Bedürf-
nisse und Tätigkeiten der beteiligten Individuen (siehe Kapitel 1) wurde bislang nicht
behandelt. Abschnitt 2.5 weist auf einen möglichen Ansatzpunkt hin, die Fragestellung
3 im Sinne von Grudin (1988) vollständiger bearbeiten zu können.
2.6.2. Weitere Verwendung der Ergebnisse
Die zur Unterstützung von „Articulation Work“ von mehreren Autoren vorgeschlagene
Erstellung von diagrammatischen Modelle wird in existierenden Arbeiten methodisch
nur teilweise behandelt. Vor allem die Rolle der beteiligten Individuen und deren Unter-
74
2.6. Zusammenfassung
stützung im Erstellungsprozess bleibt unklar. Dies ist insofern problematisch, als dass
die erfolgreiche Durchführung von „Articulation Work“ die Einbindung aller beteiligten
Individuen bedingt und deren Sichtweise auf den abzustimmenden Arbeitsablauf berück-
sichtigen muss. Als Ansatzpunkt, die Berücksichtigung dieser individuellen Beiträge bei
der Durchführung von „Articulation Work“ sicherzustellen und methodisch sowie mit
einem Werkzeug zu unterstützen, wurde das Konzept der „Mentalen Modelle“ als geeig-
net identifiziert. In Kapitel 3 werden diese nun konzeptuell eingeführt und hinsichtlich
der Anforderungen im Rahmen der Durchführung von „Articulation Work“ betrachtet.
75
3. Mentale Modelle
In diesem Kapitel wird das Konzept der „mentalen Modelle“ eingeführt, das in dieser Ar-
beit als Erklärungsansatz für jene Aspekte von „Articulation Work“ verwendet wird, die
die nicht sichtbaren, kognitiven Beiträge eines beteiligten Individuums betreffen. Nach
einer Einführung in die Begriffswelt der mentalen Modelle wird die Argumentation aus
dem Kapitel „Articulation Work“ nochmals aufgegriffen und die mögliche Rolle men-
taler Modelle für die Durchführung derselben erörtert. In der Folge werden Methoden
eingeführt, mit denen mentale Modelle externalisiert und kommuniziert werden können.
Basierend auf diesen Beschreibungen wird im letzten Teil des Kapitels untersucht, welche
Herausforderungen sich bei der Anwendung dieser Methoden im Kontext von „Articu-
lation Work“ ergeben können. Abbildung 3.1 stellt dieses Kapitel und dessen Aufbau im
Kontext der anderen inhaltlich vor- und nachgelagerten Kapitel dar.
Abbildung 3.1.: Kapitel „Mentale Modelle“ im Gesamtzusammenhang
76
3.1. Articulation Work und mentale Modelle
3.1. Articulation Work und mentale Modelle
Wie bereits im vorgehenden Kapitel beschrieben, werden in vorhandenen Arbeiten zu
„Articulation Work“ deren Auftreten, Kontext und Wirkung beschrieben, nicht aber jene
Aspekte ihrer Durchführung, die die individuellen Aktivitäten betreffen. Der eigentliche
Gegenstand der Abstimmung, die im Rahmen der „Articulation Work“ erfolgen soll,
wird ebenfalls nicht konkret festgelegt. Strauss spricht von „putting together tasks, task
sequences, task clusters - even aligning larger units such as lines of work and subprojects
- in the service of work flow“ (Strauss, 1988, S. 2), und konkretisiert: „the specific
questions about tasks of course include: what, where, when, how, for how long, how
complex, how well defined are their boundaries, how attainable are they under current
working conditions, how precisely are they defined in their operational details, and what
is the expected level of performance. (Which of those are the most salient dimensions
depends on the organizational work context under study, and we cannot emphasize too
much that it is the researcher who must discover these saliences.)“ (Strauss, 1985, S. 6).
Strauss lässt also offen, was es exakt ist, das abgestimmt werden muss bzw. verlagert
diese Frage in den konkreten Einzelfall.
Strauss spricht diese Auslassung in einer späteren Arbeit explizit an (Strauss, 1993, S.
131) und führt – wie im letzten Kapitel bereits erwähnt – das Konstrukt der „thought
processes“ ein. Im Kontext der Abstimmung von Tätigkeiten kommt den „thought pro-
cesses“ der Individuen insofern Bedeutung zu, als dass sie den sichtbaren individuellen
Handlungen zugrunde liegen bzw. diese beeinflussen. „Articulation Work“ wirkt sich also
auf die „thought processes“ der beteiligten Individuen aus. „Thought processes“ umfas-
sen „images, imaginations, projections of scenes, [. . . ] flashes of insight, rehearsals of
action, construction and reconstruction of scenarios, the spurting up of metaphors or
comparisons, the reworking and reevaluating of past scenes and one’s actions within
them, and so on and on“ (Strauss, 1993, S. 130) - also im Wesentlichen alle kogniti-
ven Vorgänge, die unmittelbar oder mittelbar im Zusammenhang mit den sichtbaren
Arbeitsaspekten, insbesondere den Tätigkeiten zur Zielerreichung und der wahrgenom-
menen Arbeitsumgebung, stehen. Strauss interessiert sich allerdings ausschließlich für
die dynamischen Aspekte der Interaktion zwischen Individuen, nicht aber für die Aus-
gangspunkte und Ergebnisse der zugrunde liegenden „thought processes“ (Strauss, 1993,
S. 149).
3.2. Begriffsbestimmung
Das Konzept der „mentalen Modelle“ wird grundsätzlich verwendet, um zu erklären
„wie Menschen die Welt verstehen – genauer: wie sie ihr Wissen benutzen, um sich
bestimmte Phänomene der Welt subjektiv plausibel zu machen“ (Seel, 1991, S. VII).
Mentale Modelle sind dabei Erklärungsmodelle der Welt, die von Menschen auf Basis
77
3.2. Begriffsbestimmung
von Alltagserfahrungen, bisherigem Wissen und darauf basierenden Schlussfolgerungen
gebildet werden. Ein mentales Modell wird dann vom jeweiligen Individuum als Basis
verwendet, um die Welt zu verstehen und ggf. Vorhersagen über deren Verhalten zu
bilden. (Seel, 1991, S. VII)
Im Wesentlichen wurde das Forschungsfeld der mentalen Modelle durch zwei Arbeiten
maßgeblich beeinflusst. Johnson-Laird (1981) sowie de Kleer und Brown (1981) führen
den Begriff als eigenständigen Forschungsgegenstand ein und legen damit die Grundlage
für einen Großteil der nachfolgenden Arbeiten in dem Gebiet. Im Kontext dieser Arbeit
wird auf das von Seel (1991) vorgeschlagene Verständnis von „mentalen Modellen“ zu-
rückgegriffen. Seel (1991) versucht, die unterschiedlichen Richtungen der Forschung im
Bereich der mentalen Modelle zusammenzuführen und daraus die Bedeutung von Men-
talen Modellen für Lernvorgänge (unter die – im breiten Verständnis von Seel – auch die
hier relevanten Abstimmungsvorgänge fallen) und Möglichkeiten zu deren Unterstüt-
zung abzuleiten. Die folgenden Ausführungen basieren deshalb auf den Ausführungen
von Seel und seiner Mitarbeiter (Ifenthaler (2006), Pirnay-Dummer (2006) und Hanke
(2006)).
Mentale Modelle sind nach Ifenthaler (2006, S. 7) „kognitive Konstruktionen, die ab-
hängig von der jeweiligen Situation und vom semantischen Wissen einer Persone ad
hoc konstruiert werden“. Ein mentales Modell ist also kein permanentes kognitives Kon-
strukt, sondern wird auf Basis vorhandenen Wissens in bestimmten Situationen ad-hoc
gebildet (siehe dazu auch Abschnitt 3.3). In engem Zusammenhang mit dem Begriff der
mentalen Modelle ist jener der „Schemata“ zu nennen. „Schemata“ unterscheiden sich ih-
rer Definition nach nur in Detail von „mentalen Modellen“1 Ein „Schema“ repräsentiert
nach Seel (2003b, S. 57) „das aufgrund vielfältiger Einzelerfahrungen mit Objekten, Per-
sonen, Situationen und Handlungen erworbene verallgemeinerbare und abstrakte Wissen
einer Person.“ Schemata werden benutzt um „Wissensstrukturen zu beschreiben, welche
typische Zusammenhänge eines Realitätsbereiches repräsentieren.“ (Ifenthaler, 2006, S.
8). Auf Basis dieser „Schemata“ treffen Individuen treffen Handlungsentscheidungen in
bestimmten Situationen. „Schemata“ sind dabei als „Vorlagen“ zu sehen, die adäquate
Handlungen für einen bestimmten Situationstypus vorgeben (im Sinne der erwähnten
„Verallgemeinerbarkeit“) und Individuen damit zur raschen, unmittelbaren Handlung
befähigt, ohne ausführliche Planungstätigkeiten durchführen zu müssen. In Abgrenzung
dazu werden „mentale Modelle“ ad-hoc in Situationen gebildet, wo keine Schemata vor-
handen sind oder vorhandene nicht angewandt werden können.
Ifenthaler (2006) beschreibt den Zusammenhang zwischen Schemata und mentalen
Modellen wie in Abbildung 3.2 dargestellt. Er bezieht sich dabei auf das „Äquilibrations“-
78
3.2. Begriffsbestimmung
Abbildung 3.2.: Schemata und mentale Modelle (entnommen aus Ifenthaler (2006, S.
10))
Prinzip nach Piaget (1976). Demnach entwickelt sich das Wissen eines Indiviuums durch
die komplementären Prozesse „Assimilation“ und „Akkommodation.“
Solange eine wahrgenommene Situation auf existierende Schemata abgebildet wer-
den kann und daraus unmittelbar Handlungen abgeleitet werden können, spricht man
von „Assimilation“ der wahrgenommene Information. „Assimilation“ festigt bestehende
Schemata, gestaltet diese ggf. in Details exakter aus oder um, stellt die grundlegenden
Annahmen, die dem Schema zugrunde liegen, aber nicht in Frage. Kann die wahrge-
nommene Information nicht auf existierende Schemata abgebildet werden, kommt es
zur „Akkommodation“, also der (ad-hoc) Bildung eines mentalen Modells und darauf
aufbauend zur „Restrukturierung, Veränderung und Neuorganisation“ (Ifenthaler, 2006)
der betreffenden Schemata. Schemata und mentale Modelle können damit auch als jene
Strukturen interpretiert werden, die beim „Single-“ bzw. „Double-Loop-Learning“ nach
Argyris und Schön (1978) zum Einsatz kommen. Im Kontext von „Articulation Work“
sind mentale Modelle in jenen Situation von Interesse, die als so „problematisch“ wahr-
genommen werden, dass keine Fortführung der operativen Arbeit mehr möglich ist (auf
individueller Ebene also evtl. existierende „Schemata“ nicht mehr zum Einsatz gebracht
werden können). In diesen Situationen muss „explizite Articulation Work“ durchgeführt
werden, um auf Basis eines mentalen Modells dieses selbst zu verändern, auszugestalten
und soweit mit der Umwelt abzustimmen, dass eine Wiederaufnahme der operativen
1Tatsächlich wird nach Ifenthaler (2006) der Begriff der „mentalen Modelle“ von manchen Autoren
zugunsten von „Schemata“ als überflüssig bezeichnet, da zweitere die auftretenden kognitiven Phä-
nomene ausreichend beschreibt.
79
3.3. Bildung und Veränderung mentaler Modelle
Arbeit (bzw. die Bildung von adäquaten Schemata) möglich wird. Um auf die Durch-
führung von „expliziter Articulation Work“ unter Bezugnahme auf die mentalen Modelle
der Individuen näher eingehen zu können, werden im nächsten Abschnitt die Bildung
und Veränderung mentaler Modelle näher betrachtet.
3.3. Bildung und Veränderung mentaler Modelle
Nach Seel (1991) umfasst die Bildung mentaler Modelle zwei Komponenten: Eine de-
klarative Komponente, in der bereichs- bzw. domänen-spezifisches Wissen in der Form
von hier nicht näher spezifizierten, strukturierten Wissensbasen abgelegt wird und eine
operative Komponente, in der auf Grundlage dieser Wissensbasen Schlüsse gezogen und
neues Wissen abgeleitet wird, die über das ursprüngliche domänenspezifische Wissen
hinausgeht.
Das in den Wissensbasen repräsentierte Wissen kann auf Alltagserfahrung basieren
oder durch Vermittlung oder Instruktion begründet werden. Im ersteren Fall ist das
Wissen dann als konkret und handlungsbezogen anzusehen, im zweiten Fall ist das Wis-
sen eher auf abstrakter, formaler Ebene anzusiedeln. Analog dazu kann auch in der
operativen Komponente die Schlussfolgerung entweder induktiv auf Basis eines „intui-
tionsbegründeten“ Regelsystems gezogen werden oder durch Deduktion mittels einem
formal begründbaren Regelsystem gebildet werden (Seel, 1991).
Die Modifikation und Erweiterung der eigenen Wissensbasen und die (Weiter-) Ent-
wicklung der kognitiven Fähigkeiten, die für die Ableitung von Schlussfolgerungen not-
wendig sind, bezeichnet Seel (1991) als „Lernen“. Lernen ist ”mit der Verarbeitung indivi-
dueller Erfahrungen mit sowie vermittelter Information über die Welt, ihre Struktur und
Evidenz verbunden und kann als ein Prozess permanenter konzeptueller Veränderungen
verstanden werden.” (Seel, 1991, S. 23). Lernen setzt damit die Fähigkeit und Bereit-
schaft voraus, ”vermittelte Weltauffassungen zu verstehen, zu akzeptieren und sodann
den eigenen gedanklichen Konstruktionen zugrunde zu legen” (Seel, 1991, S. 23). Im We-
sentlichen entspricht dies einer Verallgemeinerung jener Vorgänge, die im Rahmen von
nicht rein koordinierender sondern abstimmender und vor allem planender „Articulation
Work“ durchgeführt werden.
In Zusammenhang mit diesem Verständnis von „Lernen“ sind verschiedene Arten von
mentalen Modellen zu unterscheiden. Seel (1991) differenziert zwischen „Novizenmodel-
len“ und „Expertenmodellen“ (diese Unterscheidung trifft implizit auch Norman (1983)
im Kontext der Verwendung mentaler Modelle in der HCI2). Ein „Novizenmodell“ ist
ein Alltagsmodell, dass ad-hoc in einer Problemsituation gebildet wird und dem Indivi-
duum, das es gebildet hat, in der aktuellen Situation als plausibel wahrgenommen wird
(auch wenn es objektiv falsch ist). Es reicht aus, um adäquate Reaktionen auf die gegebe-
2Human Computer Interaction
80
3.3. Bildung und Veränderung mentaler Modelle
ne Situation abzuleiten, ohne dass notwendigerweise eine Begründung der Handlungen
möglich wäre oder diese nicht mit dem tatsächlichen Grund der Problembewältigung
übereinstimmen3. Je öfter die Anwendung eines „Novizenmodells“ zum Erfolg führt,
umso stabiler wird es zur Grundlage des Handelns des Individuums in der jeweiligen
Situation.
„Expertenmodelle“ (oder „wissenschaftliche Modelle“) sind hingegen inhaltlich voll-
ständiger und bilden die Ursache-Wirkungs-Zusammenhänge der beobachtbaren Realität
ab (sind also „objektiv korrekt“). Sie sind im allgemeinen differenzierter und bedienen
sich einer adäquateren mentalen Codierung – d.h. Begriffssystem – als „Novizensysteme“
(die sich i.A. vertrauter Begriffssysteme bedienen, auch wenn diese einer anderen Do-
mäne entstammen oder objektiv inkorrekt sind). Auch die Kompetenz des Individuums
im Umgang mit dem mentalen Modell ist in diesem Fall höher. Der Übergang von ei-
nem „Novizenmodell“ zu einem „Expertenmodell“ erfolgt dabei durch „Lernen“ im oben
genannten Sinn. (Ifenthaler, 2006)
„Expertenmodelle“ müssen aber nicht immer den erwünschten Endzustand eines Lern-
prozesses darstellen. Durch die gesteigerte Komplexität des Modells wird dessen ad-hoc-
Anwendung schwieriger, die Nützlichkeit des Modells ist deshalb eingeschränkt (vgl.
Ifenthaler, 2006, S. 20). Hier zeigt sich eine Analogie mit dem Bereich „Articulation
Work“, wo es – wie im letzten Kapitel beschrieben – ebenfalls nicht als erforderlich
angesehen wird, dass jedes beteiligte Individuum eine detaillierte Gesamtsicht auf den
Arbeitsablauf hat. Vielmehr ist es ausreichend, die jeweils relevanten Schnittstellen zu
abzustimmen und einen groben Überblick über den Gesamtzusammenhang zu haben.
Ifenthaler (2006) erweitert deshalb die binäre Klassifikation durch „Erklärungsmodel-
le“, die er konzeptuell zwischen „Novizen-“ und „Expertenmodellen“ ansiedelt. Ein „Er-
klärungsmodell“ „beinhaltet alle notwendigen Informationen, um ein Problem bezüglich
des Sachverhaltes und der Anforderungssituation richtig zu lösen. Einem Erklärungsmo-
dell wird dabei ein hoher Grad an Nützlichkeit beigemessen, was in Bezug auf die kognitive
Leistung zu einer ergonomischen Problemlösung führt. Je nach Komplexität des Sach-
verhaltes und der damit verbundenen Anforderungssituation kann ein Erklärungsmodell
einem Novizenmodell oder einem Expertenmodell sehr ähnlich sein“ (Ifenthaler, 2006, S.
21). „Erklärungsmodelle“ sind also je nach Art der zugrunde liegenden Problemstellung
unterschiedlich aufgebaut. Ziel eines „Erklärungsmodells“ ist es immer, bestmöglich zur
Problemlösung beizutragen, diese also für das Individuum im Kontext der jeweiligen
Problemstellung möglichst einfach zu gestalten. Ein „Erklärungsmodell“ gewinnt dabei
durch „Lernen“ an Reifegrad, es nähert sich einem „Expertenmodell“ immer weiter an.
Im Kontext von „Articulation Work“ ist der Begriff des „Erklärungsmodells“ ein hilf-
reiches Konstrukt. Je nach Reifegrad des betreffenden mentalen Modells wird eine be-
stimmte Arbeitssituation als mehr oder weniger komplex wahrgenommen. Je komplexer
3„[. . . ] most people’s understanding of the devices they interact with is surprisingly meager, imprecisely
specified, and full of inconsistencies, gaps and idiosyncratic quirks.“(Norman, 1983, S. 8)
81
3.3. Bildung und Veränderung mentaler Modelle
eine Arbeitssituation wahrgenommen wird, desto größer ist der Bedarf nach expliziter
„Articulation Work“, also der expliziten Beschäftigung mit dem Arbeitsprozess, dessen
Reflexion und der Abstimmung der eigenen Wahrnehmung mit anderen beteiligten In-
dividuen. Diese Beschäftigung mit dem Arbeitsprozess, also jene Tätigkeiten, die im
Rahmen der „Articulation Work“ durchgeführt werden, entsprechen – wie oben bereits
beschrieben – dem hier beschriebenen „Lernen“, wobei in kooperativen Arbeitssituati-
on die Quellen „vermittelter Information“ vorrangig die anderen beteiligten Individuen
oder organisationale Artefakte sind, die den Arbeitsablauf beschreiben.
Die Veränderung mentaler Modelle weist zwei grundlegende Schwierigkeiten auf. Bei
bereits als nicht adäquat erkannten mentalen Modellen (wie sie bei „Articulation Work“,
die in „non-routine work“ bzw. „problematic work“ ausgeführt wird, auftreten), besteht
grundsätzlich die Bereitschaft zur Veränderung (im Sinne einer „Akkommodation“ des
mentalen Modells an die als verändert wahrgenommene Umweltbedingungen), die Her-
ausforderung besteht aber darin, die notwendigen Informationen vermittelt zu bekom-
men, also an diese zu gelangen und adäquat dargeboten zu bekommen. Eine weitere
Schwierigkeit ergibt sich in Situationen, in denen nicht alle involvierten Individuen die
Situation als „problematisch“ wahrnehmen und deshalb keine grundlegende Bereitschaft
zeigen, ihre der Arbeit zugrunde liegenden Annahmen (also ihre mentalen Modelle)
zu verändern (Ifenthaler (2006) spricht von „hoher Veränderungsresistenz“). Dies tritt
vor allem im Situationen auf, in denen „Articulation Work“ nicht aus einer allgemein
wahrgenommen Problemsituation heraus durchgeführt wird, sondern entweder mit rein
planendem Charakter angestoßen wird oder nur für einzelnen beteiligte Individuen so
stark „problematisch“ ist, dass eine explizite Beschäftigung mehrerer oder aller am Ar-
beitsablauf beteiligten notwendig ist.
Aus der Theorie der mentalen Modelle heraus begründet, müssen also drei Rahmen-
bedingungen gegeben sein, um „explizite Articulation Work“ durchführen zu können:
1. Die Beteiligten müssen bereit sein, ihre mentalen Modelle abzustimmen und das
individuelle Verständnis der Schnittstellen abzugleichen.
2. Die von den beteiligten Individuen benötigte Information über den Arbeitsablauf
muss von den anderen Beteiligten zur Verfügung gestellt werden können oder in
der Form organisationaler Artefakte vorliegen.
3. Die benötigte Information muss in adäquater Form dargeboten werden, um die
individuellen mentalen Modelle mit diesen in Einklang zu bringen.
Anforderung 1 ist eine Frage des sozialen Verhaltens der beteiligten Personen bzw. der
Organisationskultur und kann ggf. durch organisationale Maßnahmen (z.B. durch die
Förderung von „Communities of Practice“ (Wenger, 1999)) unterstützt werden. Anfor-
derung 2 kann trivial zu erfüllen sein, wenn der Kontext des Arbeitsablaufs (d.h. das
Umfeld, in dem die Arbeit durchgeführt wird, u.a. inkl. aller beteiligten Individuen)
bekannt ist. In komplexen, neuartigen oder unbekannten Arbeitssituationen muss auch
die Erfüllung dieser Anforderung unterstützt werden. Ansatzpunkte dafür liefert im Be-
82
3.3. Bildung und Veränderung mentaler Modelle
reich von „Articulation Work“ etwa Grinter (1996) (siehe Abschnitt 2.4.4) oder Fuchs
et al. (2001) (siehe Abschnitt 2.4.7), umfassend mit dieser Thematik beschäftigt sich der
Forschungsbereich der „Organisational Memories“ (zur technischen Unterstützung siehe
etwa (Abecker et al., 1998) oder (Diefenbruch et al., 2002)4).
Anforderung 3 wird in der Forschung zum Thema „Articulation Work“ von Sarini und
Simone (2002a) im Kontext des „alignment of meanings“ angesprochen, bei dem eine
automationsgestützte Abbildung unterschiedlicher Domänenvokabulare die grundsätzli-
che Verständigung bzw. die Vermeidung von Missverständnissen vermeiden soll. Diese
Maßnahme ermöglicht allerdings erst die Abstimmung mentaler Modelle, unterstützt
diese aber noch nicht unmittelbar. Im Sinne der adäquaten Form der Darbietung argu-
mentieren auch Divitini und Simone (2000), (Jørgensen, 2004) und vor allem Herrmann
et al. (2002) mit der Forderung von flexiblen bzw. an die Bedürfnisse der Benutzer an-
passbaren Modellierungsprachen bei der Verwendung von externalisierten Modellen als
Unterstützung der Durchführung von „Articulation Work“ (siehe dazu die Abschnitte
2.4.8, 2.4.13 und 2.4.10).
Hinsichtlich Anforderung 3 argumentiert Seel (1991) im Bereich der mentalen Modelle
für die Nützlichkeit externalisierter Repräsentationen zur Verbesserung von mentalen
Modellen. Er vertritt die Auffassung, dass „die Externalisierung die Konstruktion ei-
nes mentalen Modells ’vervollkommnet’“, was er darauf zurückführt, dass „erst aus der
Zielsetzung heraus, sich einem anderen mitzuteilen, die Präzision einer gedanklichen
Konstruktion resultiert, die für die Erklärung einer Weltergebenheit erforderlich ist“
(Seel, 1991, S. 155). Die Bildung von Externalisierungen mentaler Modelle verbessert
also einerseits das individuelle mentale Modell, indem sie Lücken und Inkonsistenzen
bewusst macht, und ermöglicht andererseits die Kommunikation mit anderen Individuen
und ist damit die Grundlage der Vermittlung von Information und damit des „Lernens“
und „Articulation Work“ im hier beschriebenen Sinn. Seel (1991) lässt jedoch offen, in
welcher Form die Repräsentation erfolgt, um die Vermittelbarkeit bestmöglich sicherzu-
stellen5. Ifenthaler (2006), Hanke (2006) und Pirnay-Dummer (2006) weisen an dieser
Stelle jedoch auf qualitative Unterschiede der Eignung unterschiedlicher externer Re-
präsentationsformen mentaler Modelle zur Externalisierung und Vermittlung derselben
hin. Auf diese unterschiedlichen Formen und deren Eignung wird im nächsten Abschnitt
eingegangen.
Grundsätzlich konnte jedoch hier gezeigt werden, dass „Articulation Work“ die men-
talen Modelle der beteiligten Individuen verändert bzw. auf diesen aufbaut. In weiterer
Folge wurde deutlich, dass zur expliziten Durchführung von „Articulation Work“ auch
aus der Theorie der mentalen Modelle heraus die Verwendung von externalisierten Mo-
dellen (wie bereits von Divitini und Simone (2000), Herrmann et al. (2002) und Jørgensen
(2004) ohne den Hintergrund der mentalen Modelle vorgeschlagen) sinnvoll ist.
4eine detaillierte Darstellung des Forschungsgebiets ist in (Maier, 2008) zu finden
5„Internalisierung von Erkenntnismitteln setzen Zeichensysteme (auditiver, visueller oder anderer
Natur) für die Verschlüsselung der semantischen Gebilde voraus“(Seel, 1991, S. 155)
83
3.4. Externalisierung mentaler Modelle
Diese Forderung nach einer Externalisierung mentaler Modelle, um deren Abstimmung
zu unterstützten wird auch durch die Ausführungen von Senge (1990) und Kim (1993)
gestützt, die mentale Modelle6 als ein wichtiges Konzept im Kontext des organisationalen
Lernens identifizieren. Mentale Modelle bilden dort die Grundlage für Handlungen von
Individuen in Organisationen und müssen geteilt werden, um der Organisation selbst
eine Weiterentwicklung (einen „organisationalen Lernschritt“) zu ermöglichen.
3.4. Externalisierung mentaler Modelle
Die Externalisierung von „mentalen Modellen“ ist immer ein zweistufiger Prozess (siehe
Abbildung 3.3), in dem jeweils eine Transformation des Kodierungssystems stattfindet.
Die wahrgenommene Realität (das „Weltwissen“) wird (ad-hoc) in ein mentales Modell
abgebildet werden. Soll dieses externalisiert werden, ist dazu ein weiterer Übersetzungs-
bzw. Abbildungsschritt notwendig. Gleichzeitig führt nach Stachowiak (1973) jede Mo-
dellbildung neben der „Abbildung“ auch zur „Verkürzung“, d.h. dass das Modell nicht
die gesamte Information des Originals enthält, sondern nur jene Aspekte, die vom Er-
steller als relevant wahrgenommen werden7. In diesem Sinne können sie nur in einem
bestimmten (zeitlichen, personellen und operationalen) Kontext für das Original stehen
(„pragmatisches Merkmal“ – jedes Modells ist für einen bestimmten Zweck konstruiert8).
Herausfordernd ist im Kontext von „Articulation Work“ das Abbildungsmerkmal, also
die notwendige Übersetzungsleistung bei der Externalisierung eines mentalen Modells.
Externalisierung umfasst nach Hanke (2006) immer die „Repräsentation“ als auch die
„Kommunikation“ eines mentalen Modells. Die Relevanz dieser beiden Aspekte ver-
schiebt sich je nach Kontext bzw. Zielsetzung der Externalisierung. Dient diese eher der
individuellen Verständnisbildung, steht die „Repräsentation“ im Vordergrund (diesen
Zweck erfüllt nach (Seel, 1991) auch bereits das mentale Modell selbst, die Externali-
sierung hat schärfenden Charakter). Die externalisierte Repräsentation soll nach Seel
(1991, S. 187) in Bezug auf das repräsentierte mentale Modell
• vollständig
• konzise
6in einem etwas breiteren Verständnis, welches im Wesentlichen auch Schemata umfasst: „[mental
models are] deeply ingrained assumptions, generalizations, or even pictures and images that influence
how we understand the world and how we take action.“Senge (1990)
7„Modelle erfassen im allgemeinen nicht alle Attribute des durch sie repräsentierten Originals, son-
dern nur solche, die den jeweiligen Modellerschaffern und / oder Modellbenutzern relevant schei-
nen.“(Stachowiak, 1973)
8„Modelle sind ihren Originalen nicht per se eindeutig zugeordnet. Sie erfüllen ihre Ersetzungsfunk-
tion: für bestimmte — erkennende und / oder handelnde, modellbenutzende — Subjekte; innerhalb
bestimmter Zeitintervalle und unter Einschränkung auf bestimmte gedankliche oder tatsächliche Ope-
rationen.“(Stachowiak, 1973)
84
3.4. Externalisierung mentaler Modelle
Abbildung 3.3.: Externalisierung mentaler Modelle (entnommen aus (Ifenthaler, 2006))
• kohärent und konkret
• bedeutungshaltig und korrekt
sein. Das Kodierungssystem muss hier also so gewählt werden, dass eine möglichst un-
mittelbare Abbildung der mentalen Modelle auf die externalisierte Repräsentation (und
vice versa) möglich ist.
In Situationen, in denen mentale Modelle zusätzlich auch anderen Individuen ver-
mittelt werden sollen, steht „Kommunikation“ im Vordergrund. Die „Kommunizierbar-
keit“ eines mentalen Modells hat Auswirkungen auf die wählbaren Kodierungssysteme
zur Externalisierung. Das gewählte Kodierungssystem muss allen beteiligten Individuen
verständlich sein, während dieses Kriterium bei der individuellen Verständnisbildung ir-
relevant ist (Hanke, 2006). Im Rahmen von „Articulation Work“ steht im Allgemeinen
die „Kommunikation“ bei der Externalisierung im Vordergrund, wobei diese ohne eine
adäquate „Repräsentation“ nicht möglich ist. Ziel muss es also sein, Kodierungssysteme
zur Verfügung zu stellen, die
• allen beteiligten Individuen verständlich sind, und
• eine möglichst unmittelbare Abbildbarkeit der mentalen Modelle auf die externa-
lisierte Repräsentation ermöglicht.
Kodierungssysteme können „auditiver, visueller oder anderer Natur“ (Seel, 1991, S.
155) sein. Das gebräuchlichste Kodierungssystem ist die natürliche Sprache. Diese ist im
Sinne der ersten Anforderung oft eine gute Wahl, bietet aber aufgrund ihrer Generizität
nur wenig Möglichkeiten, sowohl den Repräsentations- als auch den Kommunikations-
prozess bei der Externalisierung explizit zu unterstützen. Ifenthaler (2006) stellt mehrere
Methoden vor, die sich spezifisch zum Zwecke der Externalisierung mentaler Modelle eig-
nen und zu qualitativ höherwertigen Externalisierungsergebnisse führen sollen. Dies sind
im Einzelnen:
85
3.4. Externalisierung mentaler Modelle
• Methode des lauten Denkens
• Strukturlegetechniken
• Concept Mapping
Auch (Huss, 2003) erwähnt diese Ansätze im Zusammenhang mit der Externalisierung
„mentaler Repräsentationen“. In der Folge werden die genannten Ansätze detaillierter
betrachtet. Dabei kommt folgender Raster zum Einsatz:
Konzept beschreibt die grundlegenden Konzepte des Ansatzes und die darauf aufbau-
ende Zielvorstellung
Vorgehen beschreibt, wie die Zielerreichung methodisch sichergestellt werden soll.
Unterstützung beschreibt, welche (technischen) Unterstützungsmaßnahmen vorgeschla-
gen werden.
Bewertung fasst die Eigenschaften der Methode zusammen und beurteilt sie hinsichtlich
ihrer Eignung für „Articulation Work“
3.4.1. Methode des lauten Denkens
Die „Methode des lauten Denkens“ (Van Someren et al., 1994) beschreibt ein Vorgehen,
bei dem Individuen während ihrer operativen Tätigkeit ihre Gedanken und die Motive
für ihr Handeln verbalisieren.
Konzept
Die Grundidee der „Methode des lauten Denken“ basiert darauf, alle Gedanken, die
eine Tätigkeit begleiten, laut auszusprechen ohne sich auf diese Verbalisierung explizit
zu konzentrieren (und etwa über Formulierungen nachzudenken oder Interpretationen
durchzuführen). Es werden keine Fragen gestellt, das externalisierende Individuum wird
ggf. lediglich daran erinnert, seine Gedanken auszusprechen. Nach Van Someren et al.
(1994) hat diese Form der Externalisierung keinen negativen Einfluss auf die Durchfüh-
rung der eigentlichen Tätigkeit.
Die „Methode des lauten Denkens“ wird immer mit dem Ziel durchgeführt, die kogniti-
ven Prozesse in einer bestimmen Situation offenzulegen. Dazu muss eine Problemstellung
ausgewählt werden, die diese Situation auslöst und möglichst keine oder geringe Neben-
effekte aufweist. Zu diesen Nebeneffekten gehört etwa die kognitive Überforderung des
Individuums, wenn die Aufgabe als zu schwierig wahrgenommen wird. Gleichzeitig führt
eine zu einfache Aufgabe zu einer routinisierten Abarbeitung, deren kognitiven Prozesse
zumeist implizit und schwer zu externalisieren sind (vgl. „Operations“ in der „Activity
Theory“ (Leont’ev, 1978)). Der wahrgenommene Schwierigkeitsgrad der Aufgabe steht
86
3.4. Externalisierung mentaler Modelle
in direktem Bezug zu der Expertise des Individuums (als unabhängige Variable), die
damit bei der Auswahl der Problemstellung berücksichtigt werden muss.
Die „Methode des lauten Denkens“ wird oft mit Retrospektion kombiniert. Retrospek-
tion ist die angeleitete Reflexion über eine Tätigkeit im Nachhinein (also nach Abschluss
der Tätigkeit). Im Falle der Kombination mit der „Methode des lauten Denkens“ wird
diese Reflexion mit Protokollen der verbalisierten Gedanken durchgeführt, was Unklar-
heiten in diesen Protokollen beseitigt und eine tiefergehende Reflexion ermöglichen kann.
Die Ergebnisse der „Methode des lauten Denkens“ werden auf Basis von Audio- oder
Video-Aufnahmen möglichst exakt transkribiert. Die Auswertung der Protokolle erfolgt
im Normalfall nicht durch das Individuum selbst, sondern wird interpretativ durch Drit-
te durchgeführt. Von Van Someren et al. (1994) wird dazu unter anderem vorgeschlagen,
eine Aufgaben-Analyse durchzuführen, deren Ergebnis im Allgemeinen ein (diagramma-
tisches) Modell der Aufgaben und Tätigkeiten des Individuum zur Zielerreichung ist.
Vorgehen
Van Someren et al. (1994) beschreiben einen prototypischen Ablauf der „Methode des
lauten Denkens“, der hier angegeben wird. Die Durchführung der Methode sollte in einer
möglichst ungestörten, ruhigen Umgebung erfolgen. Das Individuum wird instruiert, bei
der Problemlösung laut mitzusprechen und alles zu sagen, was ihm durch den Kopf geht
(für konkrete Formulierungsvorschläge der Fragestellungen siehe (Van Someren et al.,
1994, S. 43)). Bevor die eigentliche Problemstellung bekannt gegeben wird, kann bei
in der Methode ungeübten Individuen eine „Aufwärmphase“ durchgeführt werden, in
der etwa anhand der Lösung einer einfachen Schlussrechnung das Verbalisierung der
Überlegungen zu deren Lösung geübt werden kann.
Während der Durchführung der Methode beschränkt sich der Untersuchungsleiter dar-
auf, das Individuum an das Aussprechen seiner Gedanken zu erinnern, sobald dieses zu
sprechen aufhört. Der gesamte Verlauf der Aufgabenbearbeitung wird mittels Audio-
oder Video-Ausrüstung aufgezeichnet.
Nach Abschluss der Methode wird die gesamt Aufzeichnung transkribiert. Bei der
Transkription muss auf höchste Exaktheit geachtet werden, auch Sprechpausen oder
nichtverbale Geräusche des Individuums sind relevant. Liegt eine Videoaufzeichnung vor,
so wird das Transkript um die beobachteten Tätigkeiten des Individuums ergänzt. Das
fertige Transkript kann dem Individuum im Sinne der Retrospektion zur Kommentierung
vorgelegt werden, bei der Ergänzungen oder Erklärungen angebracht werden können
(aber als solche gekennzeichnet werden müssen).
Zur Auswertung der Ergebnisse der „Methode des lauten Denkens“ werden unter-
schiedliche Methoden herangezogen, die im Detail in (Van Someren et al., 1994) be-
schrieben sind. Da hier lediglich die Externalisierung selbst von Interesse ist, wird auf
diese Methode an dieser Stelle nicht näher eingegangen.
87
3.4. Externalisierung mentaler Modelle
Unterstützung
Eine technische Unterstützung der „Methode des lauten Denkens“ ist von den Entwick-
lern der Methode (Van Someren et al., 1994) grundsätzlich nicht vorgesehen. Lediglich
zur Dokumentation der artikulierten Information wird eine Aufzeichnung mittels Video-
oder Audio-Ausrüstung empfohlen. Diese Dokumentation ist notwendig, um eine mög-
lichst vollständige Auswertung der Information zu gewährleisten und eine Abbildung auf
eine strukturierte Externalisierung des zugrunde liegenden mentalen Modells zu ermög-
lichen.
Senge (1990) schlägt zur verbalen Externalisierung von mentalen Modellen einen An-
satz vor, der der „Methode des lauten Denkens“ nahe kommt, die Gedanken des Indi-
viduums aber verschriftlicht. Bei Einsatz der „left-hand column“9 wird ein Blatt Papier
in zwei Spalten geteilt, wobei in der rechten Spalte eine Transkription der Handlungen
bzw. der Konversation eines Individuums eingetragen wird. In der linken Spalte werden
die Gedanken und handlungsmotivierenden Überlegungen eingetragen und den sichtba-
ren Handlungen in der rechten Spalte zugeordnet. Ein Nachteil dieser Methode ist, dass
er – auch wenn er technisch unterstützt wird – nur im Nachhinein durchgeführt werden
kann, um den eigentlichen Arbeitsablauf nicht zu unterbrechen.
Bewertung
Die „Methode des lauten Denkens“ (Van Someren et al., 1994) ist die einzige der vor-
geschlagenen Methoden zur Externalisierung mentaler Modelle, welche nicht auf eine
graphische Repräsentationsform zurückgreift. Die externalisierende Person muss wäh-
rend der Aufgabenbearbeitung unmittelbar ihre kognitiven Prozesse und Denkmuster
verbalisieren. Dies ist für viele Menschen ungewohnt und führt oft zu unvollständigen
Repräsentationen. Detailliertes Nachfragen ist hier deshalb notwendig. Die gewonnen
Daten (etwa aus Audio- oder Videomitschnitten des Versuchsszenarios) werden struk-
turiert ausgewertet, kategorisiert und interpretiert. Hier liegt auch die Schwierigkeit des
Verfahrens – in der Interpretation ist eine eindeutige Zuordnung zu bestimmten ko-
gnitiven Prozessen oft nicht möglich, die Repräsentation des mentalen Modells bleibt
unvollständig oder ist inkonsistent. (Ifenthaler, 2006, S. 28)
In einer informellen Variante ist die „Methode des lauten Denkens“ jedoch vor allem
für den Einsatz in nicht komplexen Fällen von „Articulation Work“ geeignet (also et-
wa bei kleineren Änderung im Arbeitskontext, die die Anpassung einzelner Tätigkeiten
aber nicht die Adaption des gesamten Arbeitsablaufs benötigen). Dabei kann auf eine
Aufzeichnung ggf. verzichtet werden, da die Durchführung der unmittelbaren Kommuni-
kation dient und deren Ergebnisse nicht weiter interpretiert oder anderweitig verwendet
werden müssen.
9Eine detaillierte Beschreibung der Methode ist in (Senge et al., 1994) erschienen
88
3.4. Externalisierung mentaler Modelle
3.4.2. Strukturlegetechniken
Strukturlegetechniken sind Methoden, in denen gelegte Strukturen zur Repräsentati-
on von „Wissen“ eingesetzt werden. Die gelegten Strukturen (die im Wesentlichen aus
Knoten und Kanten unterschiedlicher Bedeutung bestehen) bilden dabei die Zusammen-
hänge einzelner Konstrukte ab, wie sie die legende Person wahrnimmt. Der Prozess des
Legens ist eine „Rekonstruktion subjektiver Theorien“ (Dann, 1992) und stellt eine „[. . . ]
verstehende Beschreibung von Handlungen nicht aus der Perspektive eines außenstehen-
den Beobachters, sondern aus Sicht der handelnden Person, des Akteurs selber“ (Dann,
1992, S. 2) dar.
Konzept
Das Konzept der Strukturlegetechniken entstammt im Wesentlichen einem Forschungs-
programm zur Entwicklung von Ansätzen zur „rekonstruktiven Erhebung subjektiver
Theorien“ (Dann, 1992). „Subjektive Theorien“ sind dabei im Wesentlichen den menta-
len Modellen und Schemata gleichzusetzen10 (Kluwe, 1990, zitiert nach (Huss, 2003)).
Strukturlegetechniken sind nicht als reine Erhebungsmethoden zu sehen, sondern be-
einflussen durch den Lege-Vorgang selbst die zu externalisierenden mentalen Modelle
und bilden damit die Grundlage für eine mögliche Veränderung des Agierens im Ar-
beitskontext (Dann, 1992, S. 6). Die Grundidee von Strukturlegetechniken ist die freie
Anordnung und Assoziation von Begriffen. Je nach Variante kann dies individuell oder
in Gruppen, mit oder ohne Moderator bzw. Untersuchungsleiter geschehen. Der Pro-
zess ist dann abgeschlossen, wenn die Beteiligten die Repräsentation als eine adäquate
Abbildung ihrer Denkmodelle sehen. Vor allem in kooperativen Sitzungen ist dies mit
Aushandlungs- und Abstimmungsprozessen während der Repräsentation verbunden, was
Strukturlegetechniken in der Durchführung potentiell aufwändig macht.
Strukturlegetechniken sind hinsichtlich der Art und dem Umfang der vorgegebenen
Konstrukte nicht einheitlich aufgebaut. Es existieren Ansätze, in denen sämtliche Struk-
turelemente (also Konzepte und Arten von Beziehungen) vorgeben sind und die vom
Externalisierenden „lediglich“ die Anordnung dieser Strukturelemente verlangen. Dem
gegenüber stehen Strukturlege-Varianten, die weder die Konzeptklassen (und dement-
sprechend auch keine konkreten Konzepte) noch die Beziehungsarten vorgeben und deren
Festlegung dem Externalisierenden überlassen (für einen Überblick über Varianten siehe
(Ifenthaler, 2006, S. 29)). Im Fall der gängigen HSLT11 (Scheele und Groeben, 1988)
wird ein zweistufiges Vorgehen gewählt, bei dem im ersten Schritt die Konzepte durch
ein vorgegebenes Frageschema erhoben werden und im zweiten Schritt die Anordnung
10„Subjektive Theorien [. . . ] sind nicht nur unmittelbar handlungserklärend, -rechtfertigend oder –lei-
tend; d.h. sie beziehen sich über die unmittelbare Erklärung/Rechtfertigung etc. eigener Handlungen
hinaus auf z.B. ganze Handlungskategorien [. . . ]“ (Scheele und Groeben, 1988, S. 34)
11Heidelberger Strukturlegetechnik
89
3.4. Externalisierung mentaler Modelle
und Assoziation durchgeführt wird. Die Strukturen, die durch den Externalisierenden ge-
bildet werden sind im Sinne von Stachowiaks „Allgemeiner Modelltheorie“ (Stachowiak,
1973) als „diagrammatische Modelle“ einzustufen (also ein im Normalfall graphisches,
jedoch nicht ikonisches Darstellungsmodell).
Vorgehen
Je nach Variante von Strukturlegetechniken werden mehr oder weniger starke Vorgaben
hinsichtlich des Ablaufs der Externalisierung gemacht. In der Literatur (z.B. (Ifenthaler,
2006)) wird die Dialog-Konsens-Methodik, die im Rahmen der Heidelberger Strukturle-
getechnik (Scheele und Groeben, 1988) zur Anwendung kommt, als einer der elaborier-
testen Ansätze bezeichnet. Exemplarisch wird diese deshalb an dieser Stelle betrachtet.
Die Dialog-Konsens-Methodik sichert die Adäquatheit der während des Legeprozes-
ses entstehenden mentalen Modelle durch laufende „kommunikative Validierung“ des
Verständnisses ab. Um die kognitive Last zu reduzieren, wird dem eigentlichen Struk-
turlegeprozess eine Erhebungs-Phase vorgelagert, in der die relevanten Strukturelemente
(Konzepte und Assoziationen) identifiziert werden.
In der Erhebungsphase werden mittels einem semistrukturierten Interview (exempla-
rischer Aufbau siehe (Scheele und Groeben, 1988)) werden Konzepte identifiziert, die für
den jeweiligen Problembereich von Interesse sind. Die Identifikation erfolgt durch den
Untersuchungsleiter auf Basis des Interview-Protokolls und nicht durch das externalisie-
rende Individuum selbst. Das Individuum bestätigt, verändert oder erweitert in der Folge
im Dialog mit dem Untersuchungsleiter die identifizierten Konzepte. Die Strukturierung
der Konzepte erfolgt mittels vorgegebenen Relationen (die – so wie die Konzepte – als
Kärtchen vorliegen). Die HSLT definiert insgesamt 20 Relationsarten und sieht keine
Erweiterung derselben vor. Die Strukturierung wird sowohl vom externalisierenden In-
dividuum als auch von Untersuchungsleiter unabhängig voneinander vorgenommen und
dann im Rahmen eines Dialog-Konsens-Prozesses gegenübergestellt und das Verständnis
abgeglichen. Ziel ist hier, dass der Untersuchungsleiter das mentale Modell des Indvidu-
ums versteht. Scheele und Groeben (1988) schlagen vor, bei komplexen Sachverhalten die
Konsensbildung über die Konzepte in einem separaten Dialog-Konsens-Prozess durch-
zuführen, bevor die Strukturierung vorgenommen wird.
Auch andere Strukturlegetechniken (siehe (Dann, 1992)) bleiben beim Konzept des
Dialog-Konsenses und trennen zwischen der Phase der Konzepterhebung und der der
Konzeptstrukturierung. Sie unterscheiden sich in der Zielsetzung der Externalisierung
(und sind zum Teil nur für bestimmte Formen von mentalen Modelle geeignet) sowie
im Grad der Vorstrukturierung (also inwieweit Konzepte und / oder Beziehungen be-
reits vorgegeben sind). Entsprechend der jeweiligen Offenheit bzw. Eingeschränktheit der
Strukturlegetechnik ist die Phase der Konzept- (bzw. Beziehungs-)Sammlung mehr oder
weniger stark ausgeprägt. Gemein ist allen Strukturlegetechniken, dass zwei dedizierte
90
3.4. Externalisierung mentaler Modelle
Phasen der Konzeptsammlung und der Konzeptstrukturierung durchgeführt werden, die
in der Folge im Dialog-Konsens iterativ solange verfeinert werden, bis alle beteiligten
Personen (also der Untersuchungsleiter und das externalisierende Individuum) mit dem
Ergebnis zufrieden sind.
Unterstützung
Als technologische Unterstützung von Strukturlegetechniken wird in der Literatur mehr-
fach (u.a. bei (Huss, 2003) und (Ifenthaler, 2006)) die Software MaNET12 (Eckert, 1998)
erwähnt13. Von den Entwicklern dieses Produkts wird dieses aber wiederholt als Software
zur computerunterstützten Generierung von „Concept Maps“ (siehe Abschnitt 3.4.3)
bezeichnet. Tatsächlich verschwimmen ob der fehlenden physischen Repräsentation des
Modells (es wird ausschließlich am Rechner konstruiert) und dem offenen semantischen
Konzept (im Gegensatz zur HSLT) die Grenzen zu „Concept Mapping“-Werkzeugen
im Sinne der Entwickler dieses Ansatzes (Novak und Cañas, 2006). Ein ähnliches Bild
zeigt sich bei Mandl und Fischer (2000), die bei der Unterstützung von Methoden zur
„Strukturdarstellung“ auf „Concept-Mapping“-Werkzeuge verweisen.
Eine explizite Unterstützung des physischen Legeaspekts von Strukturlegetechniken
wird in der Literatur nicht erwähnt. Aktuell existieren allerdings Bestrebungen, compu-
terunterstützte „Concept Mapping“-Ansätze in den physischen Raum zu transferieren
(Do-Lenh et al., 2009) (Tanenbaum und Antle, 2009). Diese Ansätze werden in Abschnitt
6.6.2 im Rahmen der Beschreibung der verwandten Arbeiten genauer betrachtet.
Bewertung
Strukturlegetechniken bedienen sich einer physischen Abbildung der mentalen Model-
le durch die externalisierende Person. Sie zählen damit hinsichtlich des Ergebnisses zu
den graphischen Verfahren zur Externalisierung mentaler Modelle. Konzeptuell besteht
keine Einschränkung auf individuelles Externalisieren, das Verfahren kann auch in Grup-
pen angewandt werden. Die beteiligten Personen bilden Begriffsnetzwerke, die die deren
Handlungen zugrunde liegenden Annahmen und Modelle abbilden. Strukturlegetechni-
ken werden in den gängigen Varianten durch Dialog-Konsens-Methoden unterstützt, in
denen die Modelle in Interaktion zwischen dem Externalisierenden und dem Modera-
tor bzw. Versuchsleiter entstehen. Grundsätzlich ist dies aber nicht notwendig und wird
auch nicht in allen Strukturlege-Varianten angewandt.
Hinsichtlich der Auftrennung des Externalisierungsprozesses in zwei Phasen (Konzept-
Sammlung und –Strukurierung) ist bei der Durchführung im Rahmen von „Articulation
Work“ eine fakultative Durchführung der ersten Phase möglich und angemessen. Durch
12Mannheimer Netzwerk-Elaborations-Technik
13http://www.marescom.net (Abruf am 21.08.2009)
91
3.4. Externalisierung mentaler Modelle
die inhaltliche Offenheit von „Articulation Work“ sind viele Konstrukte nur in ihrem
Kontext sinnvoll verständlich und müssen deshalb unmittelbar in die Struktur einge-
bettet werden oder werden erst aus dieser ersichtlich. Eine strikte Teilung in Sammlung
und Strukturierung ist daher in diesem Anwendungsbereich fragwürdig. Bei der Model-
lierung komplexer Zusammenhänge ist außerdem eine möglichst hohe Flexibilität der
Repräsentationsform von Vorteil, um den Modellierungsprozess nicht zur behindern und
eine Fokussierung auf den Modellierungsgegenstand zu ermöglichen (Goguen, 1993, S.
6). Dies wird im Kontext von „Articulation Work“ (Schmidt und Simone, 2000, S. 10)
und insbesondere bei der Verwendung von diagrammatischen Modellen zu diesem Zweck
(Jørgensen, 2004, S. 23) als wesentlich erachtet.
Im Falle von „Articulation Work“ ist von einer wechselseitigen Abstimmung der men-
talen Modelle der beteiligten Individuen auszugehen (obgleich es Szenarien geben kann,
in der klassische Experten-Laien-Settings im Sinne eines unidirektionalen Wissenstrans-
fers auftreten – diese werden hier jedoch als Spezialfall des allgemeinen, wechselseitigen
Szenarios betrachtet). Dazu ist eine Auflösung der in der ursprünglichen Methode vor-
gesehenen strikten Trennung zwischen „Proband“ und „Untersuchendem“ hin zu einer
gleichberechtigten Rolle aller Beteiligten notwendig. Zu untersuchen bleibt, ob die Rolle
des Moderators und „Ermöglichers“ (im Sinne der Unterstützung bei der Werkzeug-
benutzung), die ansonsten vom Untersuchungsleiter eingenommen wird, nach wie vor
explizit wahrgenommen werden muss (durch eine Person, die ansonsten nicht in den
Dialog-Konsens-Prozess eingebunden ist).
Kritisch betrachtet wird die lange Durchführungsdauer der Externalisierungs-Prozesse,
die eine nicht unwesentliche Belastung der Teilnehmer darstellt. Auch die Komplexität
mancher Ansätze (etwa der HSLT mit ihren 20 unterschiedlichen Beziehungstypen) stellt
eine nicht unwesentliche kognitive Belastung der Teilnehmer dar. Neuere Ansätze emp-
fehlen zur Reduktion des Aufwandes den Einsatz von rechnerbasierten Werkzeugen, ohne
dabei jedoch spezifischer zu werden. (Ifenthaler, 2006, S. 29f)
3.4.3. Concept Mapping
Concept Mapping (Novak und Cañas, 2006) ist eine Methode, in der semantische offene
diagrammatische Modelle graphisch erstellt werden. Sie dienen der flexiblen Abbildung
von Begriffen (Konzepten) und deren Zusammenhänge. Die erstellte Struktur entspricht
einem Graphen mit Knoten, die die Konzepte repräsentieren und Kanten, die gerichtet
oder ungerichtet die Beziehungen zwischen den Konzepten herstellen und durch Beschrif-
tung zusätzlich spezifiziert werden können. Concept Mapping sollte ob der potentiellen
Komplexität der entstehenden Modelle Novak und Cañas (2006) zufolge durch rechner-
basierte Werkzeuge unterstützt werden.
92
3.4. Externalisierung mentaler Modelle
Konzept
Concept Maps sind graphische Strukturen, in denen durch Knoten und Kanten Begriffe
und deren Zusammenhänge dargestellt werden. Die Begriffe („Konzepte“) werden dabei
anhand des Themas der Concept Map ausgewählt, die zumeist in Form einer Fokus-Frage
vorliegt. Ein Konzept ist nach (Novak und Cañas, 2006, S. 1) „a perceived regularity in
events or objects, or records of events or objects, designated by a label“. Konzepte sind
also allgemeine Aussagen über Phänomene oder Objekte, die durch einen Bezeichner
beschrieben werden können. Diese Bezeichner sind im Allgemeinen kurz und sollten 1-2
Worte umfassen.
Die Konzepte werden untereinander mit Beziehungen verbunden, wobei die Kombina-
tion aus zwei oder mehreren Konzepten und einer Beziehung als „Proposition“ bezeichnet
wird. „Propositioen“ sind nach Novak und Cañas (2006, S. 1) „statements about some
object or event in the universe, either naturally occurring or constructed“. Beziehungen
können grundsätzlich gerichtet oder ungerichtet sein und müssen durch eine Beschriftung
(„linking word“) mit (beliebiger) Bedeutung versehen werden. Nach Novak und Cañas
(2006) enthalten Concept Maps meist eine hierarchische Struktur, in der die allgemei-
nen Konzepte am oberen Rand angeordnet sind und nach unten hin immer spezifischer
werden. Daneben gibt es „cross-links“, die Beziehungen außerhalb der hierarchischen
Struktur darstellen und Konzepte zueinander in Beziehung setzen, die in unterschiedli-
chen Bereichen der Concept Map stehen. Die grundlegende Struktur eine Concept Map
ist in Abbildung 3.4 als Concept Map dargestellt.
Abbildung 3.4.: Struktur einer Concept Map (entnommen aus (Novak und Cañas, 2006,
S. 2))
93
3.4. Externalisierung mentaler Modelle
Concept Maps werden verwendet, um exploratives Lernen zu unterstützen. In diesem
Fall bilden Individuen die ihnen bewussten Zusammenhänge der Realität in der Con-
cept Map ab und erschließen bei der individuellen oder kooperativen Erstellung den
Problembereich vollständiger, was zur Entwicklung eines umfassenderen Verständnisses
beiträgt. Nach Novak und Cañas (2006) können Concept Maps auch verwendet wer-
den, um (implizites) Expertenwissen abzubilden (die Autoren beziehen sich hier auf die
„Wissenspirale“ nach Nonaka und Takeuchi (1995). Im Wesentlichen ermöglichen Con-
cept Maps damit das Externalisieren sowohl von Laien- als auch Expertenmodellen im
Sinne von Seel (1991) und unterstützen auch die Weiterentwicklung von Laienmodellen
hin zu ausgereifteren Erklärungs- oder Expertenmodellen. Damit ist eine grundsätzli-
che Eignung für den Einsatz im Rahmen von auf der Externalisierung von Modellen
basierender „Articulation Work“ gegeben.
Vorgehen
Novak und Cañas (2006) schlagen vor, bei der Konstruktion einer Concept Map mit
der Festlegung einer Fokus-Frage zu beginnen. Die Fokus-Frage muss klar formuliert
sein und spezifisch auf das Problem oder den Sachverhalt eingehen, der in der Con-
cept Map repräsentiert werden soll. Die Fokus-Frage dient nicht nur der Festlegung des
Gegenstands der Concept Map, sondern auch deren Abgrenzung nach außen (d.h. dass
die Frage so spezifisch sein muss, dass Abweichungen vom intendierten Gegenstand der
Concept Map erkannt werden können).
Im nächsten Schritt werden die relevanten Konzepte gesammelt. Novak und Cañas
(2006) sprechen von 15-25 Konzepten, die im ersten Durchlauf maximal verwendet wer-
den sollten. Diese Konzepte können grob entsprechend ihrer Abstraktheit vorsortiert
werden, um die Erstellung der Concept Map im nächsten Schritt zu erleichtern.
Die vorläufige Concept Map, die im nächsten Schritt erstellt wird, basiert auf den
hierarchischen Zusammenhängen zwischen den gesammelten Konzepten. Zwischen diesen
wird in der Folge nach „cross-links“ gesucht. Alle identifizierten Beziehungen müssen
benannt werden. Im Zuge dieser ersten Herstellung von Beziehungen ergeben sich im
Normalfall weitere Konzepte, die in die Concept Map aufgenommen werden müssen.
Dies erfolgt im Zuge eines erneuten Durchlaufs durch den beschriebenen Prozess. Nach
Novak und Cañas (2006) benötigt eine Concept Map mindestens drei dieser Durchläufe,
um ausreichende Qualität erreichen zu können.
Unterstützung
Novak und Cañas (2006) erwähnen, dass Concept Mapping mittels Haftnotizen auf Pa-
pier oder Whiteboards durchgeführt werden kann, empfehlen aber, ein rechnerbasiertes
94
3.5. Zusammenfassung
Werkzeug – die CMapTools (Cañas et al., 2004) – einzusetzen, das den Erstellungspro-
zess unterstützt und den Umgang mit der entstehenden Komplexität erleichtert.
Dieses Werkzeug ermöglicht neben der Unterstützung des Mapping-Prozesses (d.h.
der Nachverfolgung des Prozesses und der Möglichkeit, einzelne Schritte rückgängig zu
machen) auch eine erweiterte Abbildung der Concept Map selbst. Diese umfasst unter
anderem auch die Einbindung von externen Ressourcen (Dateien am Rechner), was von
Novak und Cañas (2006) als wesentlich zur Einbettung der Concept Map in den Kontext
des Problemumfelds angesehen wird.
Bewertung
Concept Mapping ist ein Ansatz zur computer-basierten Strukturierung und Visualisie-
rung von Konzept-Netzwerken (Novak und Cañas, 2006). Durch die Rechnerunterstüt-
zung ergeben sich Vorteile hinsichtlich der Flexibilität der Darstellung und der Archivie-
rung der Modelle. Konzeptuell werden wie bei Strukturlegetechniken Begriffsnetzwerke
gebildet, wobei die methodische Hinterlegung bei Concept Mapping Ansätzen nicht so
variantenreich und detailliert ausgeführt ist.
Durch die digitale Repräsentation ist eine Concept Map leichter ohne Konsequen-
zen zu manipulieren, da Änderungen jederzeit rückgängig gemacht werden können. Dies
ermöglicht Experimente mit dem Modell und erlaubt dem Externalisierenden eine um-
fassendere Ergründung und Reflexion der Modelle. Kritisch wird jedoch die im Gegen-
satz zu Strukturlegetechniken fehlende Unmittelbarkeit der Externalisierung betrachtet
– jeder Externalisierung-Prozess muss am Rechner umgesetzt werden und setzt damit
Kompetenz im Umgang mit diesem Medium voraus. Ifenthaler (2006, S. 30f)
Für die Durchführung von „Articulation Work“ sind Concept Maps durch ihre se-
mantische Offenheit vor allem zur expliziten Unterstützung von „alignment of meaning“
geeignet (vgl. (Sarini und Simone, 2002a), beschrieben in Abschnitt 2.2). Bei der rechner-
gestützten Durchführung von Concept Mapping ist aber die Wirkung der auf einen Be-
nutzer ausgerichteten Benutzungsschnittstelle (Monitor sowie Maus und Tastatur) auf
die Interaktion zwischen den Beteiligten zu berücksichtigen.
3.5. Zusammenfassung
In diesem Kapitel wurde das Konzept der „Mentalen Modelle“ eingeführt und dessen
Relevanz für die Durchführung expliziter „Articulation Work“ beschrieben. In weite-
rer Folge wurden die Externalisierung mentaler Modelle, deren Rückwirkung auf die
kognitven Prozesse der Individuen sowie Methoden zu Unterstützung des Externalisie-
rungsvorganges beschrieben. Der Zusammenhang des Themenbereichs der „Mentalen
95
3.5. Zusammenfassung
Modelle“, deren Externalisierung und deren Einbettung in den Gesamtzusammenhang
von „Articulation Work“ ist in Abbildung 3.5 nochmals zusammenfassend dargestellt.
Abbildung 3.5.: Mentale Modelle und Articulation Work im Gesamtzusammenhang
„Mentale Modelle“ sind ein Erklärungskonzept für jene mentalen Strukturen und Vor-
gänge, mit Hilfe derer Individuen ihre Wahrnehmungen der realen Welt erklären und
Handlungsalternativen ableiten. Durch Lernprozesse können „Mentale Modelle“ verfei-
nert oder grundlegend verändert werden. Quellen für neue Information, die in mentalen
Modellen abgebildet wird, können die Wahrnehmung der realen Welt, dokumentarische
Ressourcen oder andere Individuen sein. Ein wesentlicher Unterstützungsfaktor für die
Reflexion und Verfeinerung mentaler Modelle ist deren Externalisierung. Diese ist außer-
dem die Voraussetzung für die Kommunikation und Abstimmung verschiedener mentaler
Modelle.
3.5.1. Beitrag zur globalen Zielsetzung
In diesem Kapitel wird mittels der Theorie der mentalen Modelle die Wahrnehmung der
an Arbeitsabläufen beteiligten Individuen erklärt. Die Erarbeitung der Konzeption der
mentalen Modelle in Abschnitt 3.2 sowie die Beschreibung deren Bildung und Verände-
rung in Abschnitt 3.3 beantworten also Fragestellung 2 („Wie kann die Wahrnehmung
von Arbeitsabläufen durch die an diesen beteiligten Individuen erklärt werden?“).
Die in Abschnitt 3.1 dargestellten Zusammenhänge stellen mentale Modelle in den
Kontext von „Articulation Work“ und bilden so die Brücke, die die beiden Fragestel-
lungen verbindet. Die Forschungsfrage 1 („Wie kann die Durchführung und Wirkung
von Articulation Work charakterisiert werden?“) wird damit sowohl aus Sicht der klas-
sischen Literatur zu „Articulation Work“ als auch aus Sicht der handelnden Individuen
betrachtet und im Sinne von Grudin (1988) umfassend beantwortet.
96
3.5. Zusammenfassung
Analog zur Kapitel 2 werden auch in diesem Kapitel die Möglichkeiten der methodi-
schen Unterstützung von im Rahmen von „Articulation Work“ durchzuführenden Akti-
vitäten aus Sicht der mentalen Modelle beschrieben. Die dazu in Abschnitt 3.4 dargestell-
ten Methoden tragen damit zur Beantwortung von Fragestellung 3 („Welche Methoden
können zur Unterstützung von Articulation Work herangezogen werden?“) bei und er-
gänzen die in Kaptel 2 erfassten Ansätze zur Unterstützung um Methoden, die explizit
auf die Verständnisbildung der an einem Arbeitsablauf beteiligten Individuen eingehen.
3.5.2. Weitere Verwendung der Ergebnisse
Während die Externalisierung auch rein verbal erfolgen kann, ist die Verwendung einer
expliziten, graphischen Repräsentation vorteilhaft. Diese wirkt vor allem in Situationen,
in denen mentale Modelle offengelegt und kommuniziert werden sollen, als Ankerpunkt
und Dokumentation, anhand derer eine Abstimmung der individuellen Sichten erfol-
gen kann. Methoden, deren Eignung zur Externalisierung mentaler Modelle empirisch
belegt ist, sind unter anderem Strukturlegetechniken und Concept Mapping. Für die
im Rahmen dieser Arbeit verfolgte Unterstützung von „expliziter Articulation Work“
bieten beide Methoden Vor- und Nachteile. Deswegen wird im folgenden Kapitel eine
Synthese dieser beiden Methoden angestrebt, die deren Vorteile vereint und gleichzeitig
die nachteilig wirkenden Faktoren zu vermeiden sucht.
97
4. Methodik und Anwendungszenarien
In diesem Kapitel wird die Methodik vorgestellt, die zur Externalisierung von mentalen
Modellen im Rahmen von „Articulation Work“ zur Anwendung kommt. Die Inhalte die-
ses Kapitels bauen auf den Ergebnissen der Kapitel 2 und 3 auf. Die Anforderungen an
die Unterstützung durch ein Werkzeug, die sich aufgrund der hier vorgestellten Methodik
ergeben, werden in Kapitel 5 identifiziert und in weiterer Folge in einem Werkzeug um-
gesetzt. Abbildung 4.1 stellt dieses Kapitel und dessen Aufbau im Kontext der anderen
inhaltlich vor- und nachgelagerten Kapitel dar.
Abbildung 4.1.: Kapitel „Methodik und Anwendungsszenarien“ im Gesamtzusammen-
hang
Den Schlussfolgerungen zufolge, die Ifenthaler (2006) hinsichtlich der Eignung der
beschriebenen Methoden zur Externalisierung von mentalen Modellen zieht, sind jene
Ansätze, die auf der Bildung diagrammatischer Modelle basieren, besser für die Un-
terstützung expliziter „Articulation Work“ geeignet als Methoden, die auf einer rein
natürlichsprachlichen Repräsentation aufbauen. Dies liegt vor allem in der höheren Abs-
traktion begründet, die die externe Repräsentation als interindividuellen Ankerpunkt für
Kommunikation besser geeignet macht. Dies deckt sich mit den Aussagen von Sarini und
Simone (2002a), Herrmann et al. (2002), Raposo et al. (2004) oder Jørgensen (2004), die
98
4.1. Durchführungsrahmen
aus Sicht von „Articulation Work“ für die Verwendung von (diagrammatischen) Model-
len zur Unterstützung argumentieren.
Betrachtet man nun die beiden Vertreter der auf diagrammatischen Modellen aufbau-
enden Methoden – Strukturlegetechniken und Concept Mapping –, so zeigt sich hinsicht-
lich der Eignung zum Unterstützung von „Articulation Work“ kein eindeutiger Vorteil
für eine der beiden Methoden. Vielmehr weisen beide in diesem Kontext Vor- und Nach-
teile auf. Hier wird deshalb versucht, die Vorteile von Strukturlegetechniken – im We-
sentlichen die Unmittelbarkeit der physischen Repräsentation – mit jenen von Concept
Mapping – der Flexibilität der Modellierung sowie der Möglichkeit der Unterstützung
des Modellierungsprozesses durch Computersysteme – zu vereinen.
Dabei wird auf das methodische Vorgehen von „Concept Mapping“ im Sinne der koope-
rativen Verständnisbildung, die bei „Strukturlegetechniken“ angewandt wird, adaptiert
und die Modellierungsumgebung an den bei „Strukturlegetechniken“ vorgeschlagenen
Durchführungsrahmen angepasst.
4.1. Durchführungsrahmen
Der Rahmen, in explizite „Articulation Work“ mit Unterstützung von externalisierten
Modellen durchgeführt wird, ist an den Aufbau von Strukturlegetechniken angelehnt. Ei-
ne wesentliche Eigenschaft ist hierbei die physische Modellierungsoberfläche, auf der das
Modell mittels real vorhandener und unmittelbar manipulierbaren Elementen aufgebaut
wird.
Im Sinne der Abstimmung unterschiedlicher Sichten muss eine kooperative, nicht ex-
klusive Manipulierbarkeit des Modells gewährleistet sein. Das Modell selbst ist – orien-
tiert an der Offenheit der Repräsentation bei „Concept Mapping“ – weder in der Art
der Elemente noch der Beziehungen eingeschränkt.
Hinsichtlich des Durchführungsrahmen ist auch die Notwendigkeit des Einsatzes einer
Person zu diskutieren, die den Externalisierungsprozess anleitet und steuernd in diesen
eingreift. Die Dialog-Konsens-Methode, die im Rahmen von Strukturlegetechniken zur
Anwendung kommt, sieht die Rolle eines Untersuchungsleiters vor, der den Ablauf der
Externalisierung strukturell anleitet. Inhaltlich hat der Untersuchungsleiter jedoch keine
neutrale Rolle inne, sondern tritt im Rahmen des Dialog-Konsens-Prozesses in Interak-
tion mit der externalisierenden Person. Ziel des Untersuchungsleiters ist es, das mentale
Modell der externalisierenden Person zu erschließen und zu verstehen. In kooperativen
Situationen (die von der Dialog-Konsens-Methode nach (Scheele und Groeben, 1988)
nicht explizit berücksichtigt werden), wo gegenseitiges Verständnis erreicht werden muss,
wechselt demnach die Rolle des Untersuchungsleiters inhaltlich gesehen dynamisch.
Aus Sicht der Prozesssteuerung kann zu diesem Zeitpunkt nicht entschieden werden, ob
ein Untersuchungsleiter benötigt wird oder nicht. Bei Strukturlegetechniken beschränkt
99
4.2. Vorgehen
sich dessen Aufgabe auf die Sicherstellung der Fokussierung der beteiligten Personen auf
die jeweilige Aufgabe. Im Rahmen der Concept Mapping Methode ist ein intervenieren-
der Untersuchungsleiter nicht vorgesehen. Für den hier vorgestellten Ansatz bedeutet
dies, dass die Rolle der Untersuchungsleiters vorerst unbesetzt bleibt, methodisch aber
im Sinne der Rolle bei Strukturlegetechniken zulässig ist.
4.2. Vorgehen
Sowohl im Bereich der Strukturlegetechniken als auch im „Concept Mapping“ wird vor-
geschlagen, den initialen Modellierungsprozess in zwei Phasen – Konzeptsammlung und
Konzeptstrukturierung – zu teilen und in der Folge das Modell iterativ solange zu verän-
dern bzw. zu erweitern, bis alle Beteiligten mit der Lösung zufrieden sind (im Bereich der
Strukturlegetechniken wird die als „Dialog-Konsens“ bezeichnet, im „Concept Mapping“
spricht man von „Revisionen“ des Modells, die erstellt werden müssen). Beide Abläufe
sind in Abbildung 4.2 dargestellt.
Das „Dialog-Konsens“-Vorgehen nach Scheele und Groeben (1988) ist stark reglemen-
tiert und in den einzelnen Schritten mit definierten Methoden bzw. Vorgehensvorschrif-
ten hinterlegt. Die im Rahmen von „Concept Mapping“ vorgeschlagene Methode ist
hier offener und ist damit für die Anwendung im Rahmen von „expliziter Articulation
Work“ besser geeignet. Dies liegt am eher informellen Durchführungsrahmen von „expli-
ziter Articulation Work“ begründet, deren Ausgestaltung individuell verschieden ist und
zwischen den Beteiligten (implizit) ausgehandelt wird. Ziel ist hier, den Artikulations-
Prozess zu unterstützen und nicht, ihn zu formalisieren und in vorgegebene Ablauf-
Grenzen zu pressen.
Auch die zweiphasige Durchführung des Modellierungsprozesses muss unter diesem Ge-
sichtspunkt hinterfragt werden. Die Unterteilung in zwei Phasen ist bei der Beschreibung
von konzeptuellen Modellen (zum „alignment of meanings“) sinnvoll. Begründet liegt
dies in der Vielfalt möglicher Strukturierierungsvarianten bei dieser Art von Modellen.
Im Gegensatz dazu ist die zweistufige Abhandlung der Externalisierung bei Modellen von
Abläufen (bei „alignment of procedures“) nur bedingt sinnvoll, da Aktivitäts-Konzepte
im Normalfall bereits in deren kausalen Abfolge externalisiert und dann bzw. parallel
mit zusätzlichen Konzepten hinterlegt werden. Die Verwendung dieser Form von Model-
len ist bei der Abstimmung von Arbeit gängig, wird aber weder bei Concept Mapping
noch bei Strukturlegetechniken explizit angesprochen. Insofern ist die explizite Durch-
führung der ersten Phase – also der Konzeptsammung – als optional anzusehen. Im Sinne
der Methode zur Erstellung von Concept Maps nach Novak und Cañas (2006) werden
Konzeptsammlungs-Phasen in den iterativen Modellverfeinerungsprozess eingeflochten,
wenn dies in der Situation als notwendig wahrgenommen wird.
100
4.2. Vorgehen
Abbildung 4.2.: Externalisierung mentaler Modelle mittels Strukturlegetechniken und
Concept Mapping
101
4.2. Vorgehen
Die im Folgenden beschriebene Methodik basiert wie oben angeführt auf den in Kapi-
tel 3 vorgestellten Methoden „Strukturlegetechniken“ und „Concept Mapping“. Für die
Anpassung an den Durchführungskontext im Rahmen von „Articulation Work“ wurden
jene in Abschnitt 2.4 beschriebenen Ansätze zur Unterstützung von „Articulation Work“
herangezogen, die Aussagen zu den Anforderung eine eine Methodik treffen. Im Einzel-
nen sind dies Corbin und Strauss (1993)1, Jørgensen (2004)2, Cabitza et al. (2006)3
sowie Herrmann et al. (2002)4. Letztere Arbeit spezifiziert aber vor allem Anforderun-
gen an eine etwaige Werkzeugunterstützung, weshalb sie in Kapitel 5 nochmals näher
berücksichtigt wird.
Die einzelnen Schritte, die bei der Durchführung der Methodik zur Anwendung kom-
men, sind im Einzelnen:
• Einarbeitung
• Konzeptsammlung
• Konzeptstrukturierung
• Restrukturierung
Diese Aufzählung gibt keine Reihenfolge der durchzuführenden Schritte vor. Vielmehr
sind die einzelnen Blöcke als Module zu sehen, die je nach Anwendungsfall zu einem belie-
bigen Zeitpunkt im Externalisierungsprozess (auch mehrfach) zur Anwendung kommen
oder auch entfallen können. Im Folgenden wird die Durchführung der einzelnen Schritte
kurz umrissen und angegeben, in welchen Situationen deren Einsatz angemessen bzw.
notwendig ist.
4.2.1. Einarbeitung
Die Einarbeitung wird nach Bedarf durchgeführt, wenn zumindest eine Person nicht mit
der Methodik oder dem unterstützenden Werkzeug vertraut ist. Im Rahmen einer Er-
klärungsphase wird den Teilnehmern die Funktionalität des Werkzeugs vorgestellt und
dessen Verwendung im Rahmen der Methodik dargelegt. Dies erfolgt durch eine Person,
die sowohl mit dem Werkzeug als auch der Methodik vertraut ist. Neben einem etwaigen
Untersuchungsleiter kann diese Rolle auch durch einen anderen Teilnehmer wahrgenom-
men werden, der bereits eine Externalisierung mit Unterstützung der Methodik und des
Werkzeugs teilgenommen hat.
Der Erklärungsphase kann auch eine freie Experimentier-Phase angeschlossen werden,
in der die Teilnehmer die Gelegenheit haben, ohne Vorgaben das Werkzeug zu verwenden
und dessen Funktionalität zu erfassen. Nach Bedarf kann dazu auch ein exemplarisches
1beschrieben auf Seite 27 in dieser Arbeit
2beschrieben auf Seite 68
3beschrieben auf Seite 69
4beschrieben auf Seite 63
102
4.2. Vorgehen
Thema vorgegeben werden, anhand dessen die Durchführung der Methodik gezeigt bzw.
durchgespielt werden kann.
Zu beachten ist im Rahmen der Einarbeitung, dass die Offenheit der Methodik nicht
unbeabsichtigt eingeschränkt wird, indem durch Erklärungen oder Beispiele struktu-
relle oder inhaltliche Vorgaben gemacht werden, an denen sich die Teilnehmer in der
Folge bei der Durchführung der Externalisierung orientieren. Strukturell betrifft dies
etwa Vergleiche mit unter Umständen bekannten Methoden wie „Mind Mapping“, des-
sen hierarchischer Aufbau jedoch nicht die Offenheit der Strukturen zulässt, die in der
vorliegenden Arbeit möglich und notwendig sind. Inhaltliche Einschränkungen können
etwa durch Beispiele von Konzeptklassen vorgegeben werden, die von den Teilnehmern
unreflektiert übernommen werden und die dadurch die semantische Offenheit der Re-
präsentation einschränken.
4.2.2. Konzeptsammlung
Bei der Sammlung der Konzepte wird neben den im Rahmen von „Concept Mapping“
und Strukturlegetechniken vorgeschlagenen Vorgehen eine weitere Einschränkung vorge-
nommen, die aus den Erkenntnissen der Forschung im Bereich der „Articulation Work“
stammt. Sowohl „Concept Mapping“ als auch Strukturlegetechniken führen keine ex-
plizite inhaltliche Klassifizierung der gesammelten Konzepte durch – es werden keine
Klassen von Konzepten gebildet, die einen gemeinsamen Aspekt oder Bezugspunkt auf-
weisen. Während „Concept Mapping“ eine derartige Strukturierung zumindest zulässt,
ist diese bei Strukturlegetechniken nicht vorgesehen.
Bereits Strauss spricht von den „salient dimensions of work“ (Fjuk et al., 1997, S.5), die
im Rahmen von „Articulation Work“ abgestimmt werden müssen und deren Wichtigkeit
für die jeweils beteiligten Individuen von Anwendungsfall zu Anwendungsfall verschieden
sein kann. Auch Sarini und Simone (2002a) unterstützen mit ihrer Arbeit die Abstim-
mung unterschiedlicher Perspektiven auf einen Arbeitsablauf anhand der Identifikation
gemeinsamer Konzeptklassen und deren Ausprägungen. Die Ebene der Konzeptklassen
spielen den genannten Autoren zufolge also im Rahmen von „Articulation Work“ ei-
ne nicht unwesentliche Rolle. Sie werden in der hier vorgeschlagenen Methodik deshalb
explizit berücksichtigt.
Dazu sind zwei Vorgehensweisen vorstellbar. Einerseits kann ein Satz an domänen-
bzw. anwendungsspezifischen Konzeptklassen vorgegeben werden, der von den Benut-
zern verwendet werden muss. Anderseits können die Konzeptklassen selbst Gegenstand
von „ArticulationWork“ sein und erst während des Externalisierungsvorganges festgelegt
werden. Diese Variante erscheit im Anwendungsgebiet von „Articulation Work“ besser
geeignet, da sie die Denkstrukturen der beteiligten Individuen auf mehreren Ebenen of-
fenlegt. Unerfahrene Benutzer können mit der Offenheit des Ansatzes jedoch überfordert
sein, was sich darin äußert, dass keine oder sehr allgemeine, umfassende Konzeptklas-
103
4.2. Vorgehen
sen ohne Unterscheidungskraft gebildet werden. Ein möglicher Lösungsansatz ist hier
die Kombination der beiden beschriebenen Ansätze, indem ein Kernsatz an domänen-
spezifischen Konzeptklassen vorgegeben wird, gleichzeitig aber eine Erweiterung durch
individuelle Konzeptklassen ermöglicht wird. Diese Variante ist in Oppl und Weichhart
(2005) hinsichtlich ihrer Durchführung und Auswirkungen beschrieben.
4.2.3. Konzeptstrukturierung
Die Konzeptstrukturierung erfolgt in der hier beschriebenen Methodik entsprechend dem
Vorgehen bei „Concept Mapping“ vollständig offen, d.h. dass keine semantisch vordefi-
nierten Arten von Beziehungen verwendet werden. Anwender sind in der Bezeichnung
der Beziehungen vollkommen frei und können diese auch explizit nicht bezeichnen, wenn
dies von ihnen nicht notwendig wahrgenommen wird (als Abweichung zum „Concept
Mapping“). Syntaktisch sind Beziehungen immer binär, haben also nur zwei Endpunkte
und können ungerichtet, gerichtet oder bidirektional sein. Die Einschränkung auf binä-
re Beziehungen gegenüber „Concept Mapping“ wird basierend auf den Annahmen bei
Strukturlegetechniken getroffen. Dort werden grundsätzlich binäre Zusammenhänge ver-
wendet, da diese eindeutiger erfassbar sind. Beziehungen mit mehr als zwei Endpunkten
sind oft mehrdeutig und anfällig für Missinterpretation.
Vor der Festlegung von Beziehungen erfolgt in der hier beschriebenen Methode (analog
zu Strukturlegetechniken) die initiale Strukturierung der Konzepte durch räumliche An-
ordnung derselben auf der physischen Modellierungsoberfläche. Bereits dabei kann in die
Position der Konzepte Bedeutung codiert werden. So ist es möglich, rein durch die Po-
sitionierung Hierarchien oder Kausalzusammenhänge anzudeuten. Die Methodik macht
hier keine Vorgaben, lässt aber diese Form der Bedeutungsfestlegung explizit zu. Für das
resultierende Modell hat dies die Auswirkung, dass dessen Semantik nicht ausschließlich
in dessen Netzwerkgraphen codiert ist, die Erfassung der Bedeutung der Knoten (Kon-
zepte) und Kanten (Beziehungen) alleine also nicht ausreicht. Vielmehr muss auch die
exakte Positionierung der Knoten (Konzepte) in die Repräsentation des Modells mit
aufgenommen werden. Zur Rekonstruktion des Modells ist dies ohnehin notwendig, an
dieser Stelle geht die Bedeutung der Position jedoch weiter und codiert für sich stehend
semantisch hinterlegte Zusammenhänge.
4.2.4. Restrukturierung
Unter Restrukturierung wird hier die Neuanordnung von bereits verwendeten Konzep-
ten auf der Modellierungsoberfläche verstanden. Wie zuvor erwähnt, ist in den Posi-
tionen der Konzepte oft Information über deren Beziehung zueinander codiert. Neben
der Veränderung von explizit hergestellten Verbindungen zwischen Konzepten ist so
auch durch Veränderung der Konzept-Positionen eine Änderung der Modellbedeutung
104
4.3. Anwendungsszenarien
möglich. Zweiteres kommt im Kontext von „Articulation Work“ vor allem dann zum
Tragen, wenn der wahrgenommene Kontext von Arbeitsabläufen abgebildet wird und
dieser zwischen mehreren Personen ausgehandelt wird (vgl. (Wahlmüller, 2010) bzw.
Kapitel 13). Dabei werden Konzepte im Rahmen ihrer (wahrgenommenen) Bedeutung
für den Arbeitsablauf in bzw. um diesen an- und umgeordnet und spezifizieren so dessen
Durchführungsrahmen näher aus.
Die Restrukturierung kann sich auch auf eine Veränderung der explizit angegebenen
Verbindungen zwischen Konzepten beziehen. Im Gegensatz zu einer Veränderung der
räumlichen Anordnung der Konzepte müssen in diesem Fall die betreffenden Verbindun-
gen entfernt werden und entsprechend neue hinzugefügt werden. In beiden Fällen ist es
in Hinblick auf eine Werkzeugunterstützung wichtig, die Durchführung experimenteller
Veränderungen zu ermöglichen, die einfach rückgängig gemacht werden können. Dazu
ist es notwendig, bestimmte Modellzustände als Referenz kennzeichnen zu können, die
in der Folge als Bezugspunkte für eine allfällige Wiederherstellung dienen können.
4.3. Anwendungsszenarien
Die eben beschriebenen Schritte bei der Anwendung der Methodik sind, wie bereits
erwähnt, als Bausteine zu verstehen, die je nach Anwendungsszenario unterschiedlich
zusammengesetzt werden können oder auch wegfallen können. Außerdem ist jeweils eine
individuelle oder kooperative Anwendung möglich. Auch diese Entscheidung ist vom
jeweiligen Anwendungszenario abhängig.
In der Folge werden nun exemplarisch einige mögliche Anwendungsszenarien der Me-
thodik beschrieben, die sich aus dem Einsatz derselben im Rahmen von „Articulation
Work“ ableiten lassen. Neben den beschriebenen Szenarien sind aufgrund der Offenheit
der Methodik auch weitere Anwendungsvarianten denkbar. Im Rahmen von „Articula-
tion Work“ treten folgende Einsatzszenarien auf:
• Verfeinerung mentaler Modelle
• Wissenstransfer
• Abstimmung mentaler Modelle
• Aushandlung mentaler Modelle
Diese Szenarien wurden auch im Rahmen der Evaluierung in unterschiedlichen Anwen-
dungsblöcken abgebildet (siehe Kapitel 11) und dienen als Grundlage der empirischen
Überprüfung der dort formulierten Hypothesen.
105
4.3. Anwendungsszenarien
4.3.1. Verfeinerung mentaler Modelle
Die Verfeinerung mentaler Modelle ist ein Anwendungsfall einer nicht kooperativen, aus-
schließlich individuellen Anwendung der Methodik. Die „Articulation Work“, in deren
Rahmen die Externalisierung durchgeführt wird, hat reflexiven Charakter und dient
der Vertiefung des Verständnisses eines realen Phänomens. Ziel ist es, die beobachteten
Abläufe oder Ereignisse besser erklären zu können, um so letztendlich adäquatere Hand-
lungsalternativen ableiten zu können. Die Aufgabenstellung lautet dementsprechend,
das aktuelle Verständnis des Phänomens zu externalisieren und in der Folge anhand der
externalisierten Repräsentation nach möglicherweise veränderten oder erweiterbaren Er-
klärungsansätzen zu suchen (siehe dazu die Beschreibung des Ansatzes von Fjuk et al.
(1997) in Abschnitt 2.2.1).
Bestehen keine Vorkenntnissen des Individuums in der Durchführung der Methodik
bzw. der Verwendung der Werkzeugunterstützung, so wird die Aktivität „Einarbeitung“
durchgeführt. Dies ist in diesem Szenario der einzige Punkt, an dem eine zweite Per-
son (also ein „Prozessbegleiter“) eingreift. In den späteren Phasen – der eigentlichen
Externalisierung – ist lediglich das betreffende Individuum beteiligt.
Je nach individueller Präferenz beginnt der eigentliche Externalisierungsvorgang mit
einer dedizierten Konzeptsammlungsphase oder einer bereits von Beginn an verwobe-
nen Sammlungs- und Strukturierungsphase. Auch bei Beginn mit einer Konzeptsamm-
lungsphase geht die darauf folgende Strukturierungsphase mit einer iterativ verwobenen
Ergänzung bzw. Veränderung der Konzepte einher. Der erste Teil der Anwendung ist
abgeschlossen, wenn die initiale externalisierte Repräsentation den wahrgenommenen
Ist-Zustand für das Individuum abbildet.
Im zweiten Teil wird die externalisierte Repräsentation als Grundlage für eine tiefer-
gehende Erklärung des realen Phänomens herangezogen. Im Rahmen dieses reflexiven
Prozesses kann es zu Restrukturierungen im Modell kommen, um dessen Ausdrucksstär-
ke oder Erklärungskraft zu verbessern. Dies kann Ergänzungen (wie etwa die Berück-
sichtigung von Ausnahme- oder Spezialfällen) umfassen, aber auch zu einer grundlegen-
den Veränderung des ursprünglichen Erklärungsansatzes führen (siehe „Assimilation“
vs. „Akkommodation“ in Abschnitt 3.2 bzw. die Unterscheidung zwischen „single-loop
learning“ und „double-loop learning“ bei Argyris (1976)).
Die Anwendung der Methodik ist abgeschlossen, wenn für das Individuum ein konsis-
tenter mentaler Zustand erreicht ist (das Erklärungsmodell also als konsistent wahrge-
nommen wird). Dies kann auch der ursprüngliche Ausgangszustand sein, der durch die
Externalisierung bestätigt und weiter gefestigt wurde. Bei einer Veränderung des menta-
len Modells muss sich dieses in der Folge in der praktischen Anwendung bei der Entwick-
lung von Handlungsalternativen bei der Konfrontation mit dem gegebenen Phänomen
in der realen Welt bewähren (im Sinne des „assess“ im OADI5-Zyklus des individuellen
5Observe – Assess – Design – Implement
106
4.3. Anwendungsszenarien
Lernens bei Kim (1993)). Die Anwendung der Methodik dient hier also der Entwicklung
neuer Erklärungsansätze und Handlungsalternativen, deren Bestätigung und Festigung
erfolgt erst in der praktischen Anwendung.
4.3.2. Wissenstransfer
Das Szenario „Wissenstransfer“ bezieht sich auf Situationen, in denen Wissen von ei-
ner Person an ein oder mehrere Individuen weitergegeben werden muss. Im Rahmen
von „Articulation Work“ kann diese Situation auftreten, wenn ein Arbeitsablauf von
manchen Beteiligten aufgrund von mangelnder Erfahrung oder Unkenntnis als proble-
matisch wahrgenommen wird, zumindest eine Person aber das Faken- oder Handlungs-
wissen besitzt, um adäquate Handlungsalternativen ableiten zu können (siehe hier etwa
den Übergang von „invisible work“ zu „visible work“ in der Beschreibung des Ansatzes
von Hampson und Junor (2005) in Abschnitt 2.2.2). Ziel ist hier, das relevante Wis-
sen von der kompetenten Person zu den unerfahrenen Persone zu transferieren, diese
also „lernen“ zu lassen. Die Aufgabenstellung lautet dementsprechend, die relevanten
Konzepte und Beziehungen zur Erklärung der Situation und der Ableitung von Hand-
lungsalternativen durch das kompetente Individuum zu externalisieren. Aufbauend auf
der externalisierten Repräsentation wird eine kooperative Reflexionsphase durchgeführt.
Der erste Teil der Durchführung entspricht im Wesentlichen dem im ersten Szenario
beschriebenen Vorgehen. Die Konzeptsammlung und -strukturierung erfolgt initial indi-
viduell, wobei die „lernenden“ Individuen an diesem Teil des Prozesses bereits beobach-
tend teilnehmen können. Die externalisierende Person kann den Externalisierungsprozess
durch Anwendung der Prinzipien der „Methode des lauten Denkens“ (siehe Abschnitt
3.4.1) nachvollziehbarer machen.
Der kooperative Teil der Durchführung beginnt mit einer Erklärungs- und Reflexi-
onsphase, der die externalisierte Repräsentation zugrunde liegt und als Bezugs- und
Ankerpunkt dient. Je nach Verlauf des Prozesses kann diese Reflexion in eine (Re-
)Strukturierungsphase übergehen, in der die Repräsentation bei punktuell auftretenden
Verständnisschwierigkeiten verfeinert bzw. konkretisiert werden kann.
Der Prozess ist abgeschlossen, wenn sowohl die „lernenden“ Individuen die als proble-
matisch wahrgenommene Situation für sich auflösen können und auch das externalisie-
rende Individuum den Eindruck gewinnt, dass die zu vermittelnden Konzepte von den
„Lernenden“ akkommodiert wurden. Der tatsächliche Erfolg des Wissenstransfers zeigt
sich wiederum erst in der praktischen Durchführung von Handlungen in der fraglichen
Situation bzw. deren Auswirkungen in der Realität.
107
4.3. Anwendungsszenarien
4.3.3. Abstimmung mentaler Modelle
Die Abstimmung mentaler Modelle ist das erste Szenario in den eine tatsächlich koope-
rative Externalisierung vorgenommen wird. Im Rahmen von „Articulation Work“ tritt
diese Variante dann auf, wenn etablierte, individuelle bzw. lokale Arbeitsabläufe existie-
ren, die aufgrund von neuen Anforderungen oder Rahmenbedingungen so abgestimmt
werden müssen, dass sie interoperabel bzw. kooperativ durchführbar sind. Dies ist der
im Rahmen von „Articulation Work“ am häufigsten genannte Anwendungsfall, auf den
auch Strauss bereits in seinen ersten Arbeiten Bezug nimmt.
Ziel ist hier, die individuellen Arbeitsabläufe und deren wahrgenommene Rahmenbe-
dingungen soweit offen zu legen, dass eine Identifikation der Schnittstellen zwischen den
einzelnen Teilen und die Etablierung eines kooperativen Arbeitsablaufs möglich wird.
Alternativ kann dieses Szenario auch dann auftreten, wenn ein organsiational spezi-
fizierter Soll-Prozess den tatsächlichen Arbeitsabläufen gegenüber gestellt werden soll
bzw. aus diesen ein Soll-Prozess entwickelt werden soll. Die Aufgabenstellung lautet
in allen Fällen im ersten Schritt, die individuellen Beiträge zu dem angepeilten koope-
rativen Arbeitsablauf zu identifizieren und soweit zu externalisieren, dass diese für die
anderen beteiligten Individuen erfassbar werden (im Falle der Existenz eines organisatio-
nalen Soll-Prozesses wird diese durch ein die Organisation repräsentierendes Individuum
eingebracht). Im zweiten Schritt erfolgt eine kooperative Abstimmung der individuellen
Beiträge, im Rahmen derer der globale Ablauf ausgehandelt wird bzw. potentielle Kon-
fliktstellen identifiziert bzw. beseitigt werden.
Das Szenario ist grundsätzlich kooperativ und baut im ersten Teil auf den beiden
zuvor beschriebenen Szenarien auf. Dies bedeutet konkret, dass die Externalisierung
der individuellen Beiträge wie in Szenario 2 geschildert, zwar jeweils von den einzel-
nen Teilnehmern separat durchgeführt wird, dass zum Zwecke der Verständlichkeit die
anderen beteiligten Personen beobachtend teilnehmen können. Die individuellen Beiträ-
ge müssen dabei nur soweit offengelegt werden, wie sie die möglichen Schnittstellen im
zu entwickelnden gemeinsamen Arbeitsablauf betreffen – nicht jedes teilnehmende Indi-
viduum muss ein detailliertes mentales Modell der gesamten durchzuführenden Arbeit
haben bzw. entwickeln. In Arbeitsabläufen, in denen die möglichen Kooperations-Stellen
nicht abschätzbar sind, kann eine selektive Externalisierung jedoch problematisch sein.
In diesem Fall müssen die individuellen Beiträge iterativ bei der kooperativen Zusam-
menführung soweit detailliert werden, dass eine Festlegung der Zusammenarbeit möglich
wird.
Nach der Externalisierung der individuellen Beiträge folgt im zweiten Teil eine koope-
rative Phase, in der aufbauend auf den individuellen Beiträgen die Konzeptsammlung
und -strukturierung auf globaler Ebene durchgeführt wird. Sofern sichergestellt ist, dass
die teilnehmenden Individuen in der ersten Phase ein Verständnis über die sie betreffen-
den Arbeitsbeiträge entwickelt haben, kann diese Abstimmung auf abstrakterer Ebene
erfolgen. Dies bedeutet, dass die gemeinsame Externalisierung nicht auch die gesammel-
108
4.3. Anwendungsszenarien
ten individuellen Beiträge enthält, sondern sich lediglich auf diese bezieht und in der
Repräsentation vorrangig die Schnittstellen und Interaktionsabläufe abgebildet werden.
In dieser Phase können Sammlung, Strukturierung und Restrukturierung ggf. ineinander
fließen bzw. nicht klar abgegrenzt werden. Durch die bereits gegebenen Repräsentatio-
nen der individuellen Beiträge ist eine Ausgangsbasis vorhanden, die im Rahmen der
Abstimmung einen raschen Wechsel zwischen den einzelnen Aktivitäten ermöglich.
Der Prozess ist abgeschlossen, wenn alle teilnehmenden Individuen ihre Sichtweisen
auf den gesamten Arbeitsablauf soweit abgestimmt haben, dass eine Durchführung des-
selben möglich ist. Unmittelbar kann dies nur durch die Rückmeldung der persönlichen
Wahrnehmung und Eindrücke der Teilnehmer überprüft werden. Die tatsächlichen Aus-
wirkungen auf die Arbeitspraxis – im konkreten Fall die Etablierung oder Veränderung
eines kooperativen Arbeitsablaufs – kann wiederum nur während der Durchführung im
Rahmen der „Production Work“ beurteilt werden.
4.3.4. Aushandlung mentaler Modelle
Im Gegensatz zu den übrigen Szenarien geht das hier beschriebene Szenario nicht von
etablierten, gefestigten mentalen Modellen oder existierenden Arbeitsabläufen aus. Viel-
mehr werden hier von Beginn an kooperativ mentale Modelle zu einer gegebenen Fra-
gestellung entwickelt und reflektiert. Im Rahmen von „Articulation Work“ treten diese
Situationen vor allem dann auf, wenn ein kooperativer Arbeitsablauf neu geplant wer-
den muss, ohne dass dieser zuvor von den beteiligten Personen als Ganzes oder in Teilen
durchgeführt wurde (siehe dazu die Ausprägung „working out original arrangements“ in
der Beschreibung des Ansatzes von Corbin und Strauss (1993) in Abschnitt 2.2).
Ziel ist es, auf Basis der individuellen Vorkenntnisse und Erfahrungen einen kooperati-
ven Arbeitsablauf bzw. dessen Durchführungskontext auszuhandeln. Die Aufgabenstel-
lung lautet dementsprechend, eine Externalisierung zu entwickeln, die den kooperativen
Ablauf, die benötigten Rahmenbedingungen und ggf. den Aspekt der Arbeitsteilung
abbildet.
Dieses Szenario ist in der Durchführung der Methodik flexibel. Im Vergleich zu den
anderen beschriebenen Szenarien sind individuelle Externalisierungsphasen nicht not-
wendigerweise durchzuführen. Die gesamte Entwicklung beginnend mit der Festlegung
der Konzeptklassen über die Sammlung der Konzepte sowie deren Strukturierung und
Restrukturierung erfolgt kooperativ. Jede Aktivität kann dabei iterativ während des
Prozesses mehrfach zum Einsatz kommen. Während in Szenario 3 ein „bottom-up“-
Ansatz zur Entwicklung der gemeinsamen Sicht verwendet wird (ausgehend von den
individuellen Beiträgen wird ein übergreifender, globaler Ablauf auf abstrakterer Ebene
entwickelt), kommt hier tendenziell ein „top-down“-Ansatz zum Einsatz, bei dem zu-
erst im Überblick der kooperative Arbeitsablauf ausgehandelt wird und erst in einem
109
4.4. Zusammenfassung
fakultativen zweiten Schritt die individuellen Beiträge detailliert externalisiert werden
können (wobei dies nicht unmittelbar und nicht kooperativ erfolgen muss).
Wie in Szenario 3 ist die Durchführung der Methodik dann abgeschlossen, wenn alle
beteiligten Personen ihre Sichtweise auf den globalen Arbeitsablauf bzw. dessen Kontext
als ausreichend repräsentiert wahrnehmen. Wiederum zeigt sich die Adäquatheit der
erstellten Externalisierung zur realen Welt erst im der praktischen Anwendung der durch
die Aushandlung entwickelten mentalen Modelle.
4.4. Zusammenfassung
In diesem Kapitel wurde die Methodik zur Externalisierung von mentalen Modellen im
Rahmen von „Articulation Work“ entwickelt. Als Grundlage dafür dienen die in Kapi-
tel 3 beschriebenen Methoden „Concept Mapping“ und „Strukturlegetechniken“. Diese
wurden hinsichtlich ihrer Eignung für „Articulation Work“ beschrieben und beurteilt.
Unter Berücksichtigung der dadurch festgelegten Rahmenbedingungen (kooperative Um-
gebung, geringe zur Verfügung stehende Einarbeitungszeit, ggf. stark heterogene mentale
Modelle der teilnehmenden Individuen) wurden aus beiden Methoden jene Aspekte ex-
trahiert und kombiniert, die zur Unterstützung geeignet erschienen. Die Ableitung der
Methodik mündet in der Beschreibung der notwendigen Rahmenbedingungen sowie der
im Rahmen der Durchführung auftretenden Aktivitäten.
Aufgrund der unterschiedlichen Ausprägungen von „Articulation Work“ ist die Be-
schreibung eines idealtypischen Ablaufs der Methodik nicht möglich. Deshalb wurden
exemplarisch vier mögliche Ausprägungen herangezogen und hinsichtlich ihrer Durch-
führung beschrieben. Diese Ausprägungen bilden auch die Grundlage für die Ableitung
jener Anwendungen, die der Evaluierung zugrunde liegen (siehe Kapitel 11). Das Anwen-
dungsszenario „Abstimmung mentaler Modelle“ ist dabei jenes, dass das ursprüngliche,
von (Strauss, 1985) vorgeschlagene Verständnis von „Articulation Work“ („resolving
contingencies“) am ehesten abbildet. Dieses Szenario wurde deshalb im Rahmen der
Evaluierung am häufigsten in Aufgabenstellungen abgebildet (siehe Abschnitt 11.2).
4.4.1. Beitrag zur globalen Zielsetzung
In diesem Kapitel wurde auf Basis der in den Kapiteln 2 und 3 erfolgten Beantwortung
der Fragestellung 3 der erste Schritt zur Beantwortung der Fragestellung 4 („Wie kann
ein Instrument zur Unterstützung von expliziter Articulation Work umgesetzt werden?“)
durchgeführt. In dieser Arbeit wird unter einem „Instrument“ die Gesamtheit aller Maß-
nahmen verstanden, die zur Unterstützung notwendig sind. Insbesondere umfasst die
Festlegung einer zur Unterstützung von expliziter „Articulation Work“ geeigneten Me-
thodik sowie die Konzeption und Umsetzung eines die Durchführung dieser Methodik
110
4.4. Zusammenfassung
unterstützenden Werkzeugs. Der methodische Aspekt der Konzeption des Instruments
wurde in diesem Kapitel beschrieben.
Mit der Festlegung der Methodik einher geht ein Beitrag zur Beantwortung der Fra-
gestellung 5 („Wie kann die Effektivität der Unterstützung von expliziter Articulation
Work beurteilt werden?“). Abschnitt 4.3 führt Anwendungsszenarien an, die darlegen,
wie die vorgestellte Methodik im Rahmen unterschiedlicher Ausprägungen expliziter
„Articulation Work“ angewandt werden kann. Für die Prüfung der Effektivität der Un-
terstützung ist das Instrument in konkreten Ausprägungen dieser Anwendungsszenarien
zu verwenden.
4.4.2. Weitere Verwendung der Ergebnisse
Die hier beschriebene Methodik bedingt eine technische Unterstützung der Durchfüh-
rung. Basierend auf den hier beschriebenen Aktivitäten, die im Rahmen der Methodik
auftreten, werden im nächsten Kapitel die Anforderungen an ein den Externalisierungs-
Prozess unterstützendes Werkzeug abgeleitet. Diese bilden die Grundlage für die Um-
setzung des Werkzeugs, die in den Kapiteln 7 bis 9 beschrieben ist.
111
Teil II.
Interaktive Externalisierung und
Abstimmung
112
Interaktive Externalisierung und Abstimmung
Einleitung
Basierend auf den dieser Arbeit zugrundeliegenden Forschungsgebieten und der daraus
abgeleiteten Methodik, die in den letzten Kapiteln beschrieben wurden, wird in diesem
Teil auf die konkreten Unterstützungsmöglichkeiten von „Articulation Work“ durch tech-
nische Werkzeuge eingegangen. Ziel dieses Teils ist es, sowohl das hier vorgeschlagene
Vorgehen bei der Unterstützung expliziter „Articulation Work“ als auch die Unterstüt-
zung, die ein Werkzeug dabei leisten kann, umfassend dazustellen. Dies entspricht Ver-
follständigung der Beantwortung des ersten Teils der zweiten in Kapitel 1 formulierten
Forschungsfrage („Wie kann explizite Articulation Work effektiv unterstützt werden?“).
Die Beurteilung der Effektivität bleibt in diesem Teil noch außen vor, es werden ledig-
lich weitere Meßkriterien identifiziert, anhand derer die Effektivität der Unterstützung
geprüft werden kann. Der methodische Aspekt der Unterstützung wurde bereits in Teil
I behandelt.
Auf Grundlage der Methodik, die im Kontext von Concept Mapping und Strukturle-
getechniken vorgeschlagen wird und unter Berücksichtigung der Anforderungen, die aus
dem inhärent kooperativen Anwendungsszenario abgeleitet werden können, muss das
Vorgehen zur Durchführung von expliziter „Articulation Work“ festgelegt werden.
In Rahmen der Festlegung des Vorgehens werden auch jene Aspekte identifiziert, in
denen Unterstützung durch technische Werkzeuge sinnvoll und notwendig ist. Die An-
forderungen, die sich aus diesen Aspekten ableiten lassen, bilden die Grundlage für
die Konzeption und Umsetzung eines Werkzeugs, das diese Unterstützung bietet. Die
technischen Details der Implementierung dieses Werkzeugs und die zugrunde liegenden
konzeptuellen und technologischen Grundlagen bilden den Kern dieser Arbeit.
Der Aufbau dieses Teils folgt dem eben umrissenen inhaltlichen Vorgehen. Am En-
de des Kapitels 3 wurde die Methodik zur Unterstützung expliziter Artikulation Work
beschrieben. Aus diesem werden im folgenden Kapitel 5 jene Bereiche identifiziert, in
denen eine technologische Unterstützung notwendig ist und die Anforderungen an ein
Werkzeug abgeleitet, das diese Unterstützung bietet. Die vier folgenden Kapitel beschäf-
tigen sich mit der Umsetzung des Werkzeugs. Dabei wurde der Implementierungsstand
beschrieben, mit dem das Werkzeug im Großteil der Evaluierungen eingesetzt wurde. Je-
ne Weiterentwicklungen, die in den letzten Phasen der Evaluierung umgesetzt wurden,
betreffen ausschließlich die Interaktion mit dem Werkzeug und hatten keinen Einfluss
auf die technische Realisierung. Die Veränderungen gründeten jeweils auf aus vorher-
gehenden Anwendungen gebildeten Hypothesen und wurde zur Überprüfung derselben
prototypisch umgesetzt. Die Beschreibung der Veränderung zum in der Folge beschrie-
benen Referenzstand wird dementsprechend im Rahmen der Beschreibung der Evaluie-
rungsergebnisse in den Kapiteln 12 bis 14 vorgenommen.
Kapitel 6 beschäftigt sich mit den konzeptuellen Grundlagen des Forschungsgebiets
„Tangible Interfaces“, das die Basis für die technische Umsetzung bildet. Kapitel 7
113
Interaktive Externalisierung und Abstimmung
beschäftigt sich mit jenen Technologien und Softwarekomponenten, die für die Infor-
mationseingabe in das technische System verwendet werden. Dabei wird auch auf die
konkrete Interaktion der Benutzer mit dem System eingegangen. Kapitel 8 beschreibt
die Ausgabeseite des technischen Systems und behandelt die Umsetzung des Informa-
tionsflusses vom System zu den Benutzern. Letztendlich wird in Kapitel 9 beschrieben,
welche Maßnahmen zu Sicherung der Ergebnisse der expliziten „Articulation Work“ ge-
troffen werden müssen und welche Möglichkeiten der technischen Umsetzung bestehen
bzw. gewählt wurden.
114
5. Anforderungen an ein Werkzeug
Dieses Kapitel dient der Überleitung von den bislang auf konzeptueller Ebene beschrie-
benen Überlegungen hin zur tatsächlichen Umsetzung der Werkzeugunterstützung für
„Articulation Work“ mittels der Externalisierung und Abstimmung mentaler Model-
le. Basierend auf den Erkenntnissen aus den Kapiteln 2 und 3 sowie der in Kapitel 4
entwickelten Methodik werden hier die funktionalen Anforderungen an das Werkzeug
beschrieben. Abbildung 5.1 stellt dieses Kapitel und dessen Aufbau im Kontext der
anderen inhaltlich vor- und nachgelagerten Kapitel dar.
Abbildung 5.1.: Kapitel „Anforderungen an ein Werkzeug“ im Gesamtzusammenhang
Die Anforderungen lassen sich jeweils auf einen von drei dieser Arbeit zugrunde liegen-
den Ansätzen zurückführen, die in den Kapiteln 2 und 3 beschrieben sind. Größtenteils
sind sie direkte Konsequenzen auf den Vorgaben hinsichtlich Struktur und Vorgehen,
die von Strukturlegetechniken oder Concept Mapping gemacht werden. Es ist jedoch zu-
115
5.1. Anforderungen aus Strukturlegetechniken
sätzlich notwendig, auf die zur Durchführung expliziter „Articulation Work“ selbst zu-
rückzugreifen, um die Eignung des Werkzeugs nicht nur für generische Externalisierung
von mentalen Modellen selbst sicherzustellen. Vielmehr muss auch die Berücksichtigung
der speziellen Anwendungsbedingungen und Betrachtungsgegenstände im Rahmen von
„Articulation Work“ gewährleistet werden.
5.1. Anforderungen aus Strukturlegetechniken
Anforderung 1 Physische Abbildung beliebiger diagrammatischer Modelle
Ein Werkzeug zur Unterstützung von Strukturlegetechniken muss das grundlegende
Konzept der Methodik vollständig unterstützten. Es muss möglich sein, Konzepte auf
einer Modellierungs-Oberfläche zu platzieren und zueinander in Beziehung zu setzen.
Der gesamte Modellstatus muss visuell auf der Oberfläche erkennbar sein.
Anforderung 2 Unterstützung der iterativen Aushandlung des Modells
Im Sinne der Unterstützung der Dialog-Konsens-Methodik sind ist der Austausch über
das Modell durch das Werkzeug zu unterstützen. Vor allem muss es möglich sein, Anmer-
kungen über Konsens oder Dissens über einzelnen Modellteile oder das gesamte Modell
explizit mit in die Repräsentation aufzunehmen.
Anforderung 3 Ermöglichung experimenteller Veränderungen am Modell
Es muss möglich sein, das Modell experimentell zu verändern und ggf. zu einem frühe-
ren stabilen Modellzustand zurückzukehren. Dies erlaubt eine konsequenzlose Erkundung
von Lösungsräumen und unterstützt damit den Dialog-Konsens-Prozess. Das Werkzeug
muss also stabile Modellzustände erfassen und deren Rekonstruktion unterstützen.
5.2. Anforderungen aus Concept Mapping
Anforderung 4 Nicht vorgegebene Semantik der Modellierungselemente
Wie oben bereits argumentiert und auch aus Seel (1991)1 abzuleiten, sind zur Un-
terstützung von expliziter „Articulation Work“ vor allem Varianten von Strukturlege-
techniken geeignet, die im Sinne von Concept Mapping keine Vorgaben hinsichtlich der
zu verwendenden Konzepte und Verknüpfungen machen. Das Werkzeug muss dement-
sprechend die Offenheit bieten, beliebige Klassen von Konzepten und Verknüpfungen
1siehe Seite 85 in dieser Arbeit
116
5.3. Anforderungen aus Articulation Work
zu definieren (z.B. Klasse „organisationale Rolle“) und von diesen beliebige Instanzen
zu bilden und zu benennen (z.B. Instanz „Geschäftsführer“). Gleichzeitig muss sicher-
gestellt werden, dass die festgelegte Semantik im Modell mit abgebildet wird und nicht
verloren geht.
Anforderung 5 Verknüpfung mit digitalen Ressourcen
Die Einbindung von digitalen Ressourcen (Dateien, Hyperlinks,. . . ) ermöglicht die Ein-
bindung des Modells in den organisationalen Kontext und erleichtert so einerseits die
Verständnisbildung und ermöglicht andererseits die Verwendung der Repräsentation als
unmittelbare Handlungsanleitung mit Verknüpfungen zu den betroffenen Arbeitsgegen-
ständen (siehe dazu auch die Beschreibung von (Jørgensen, 2004) auf Seite 68 in dieser
Arbeit).
Anforderung 6 Bearbeitung von beliebig umfangreicher Modellen
Umfangreiche Modelle enthalten oft eine große Anzahl von Konzepten und viele Ver-
knüpfungen. Das Werkzeug muss das Modell in einer Form darstellen, die dessen Er-
fassung und Manipulation ermöglicht, ohne die Repräsentierenden kognitiv zu sehr zu
belasten.
5.3. Anforderungen aus Articulation Work
Anforderung 7 Kooperative und unmittelbare Manipulierbarkeit des Modells
Zur Unterstützung von expliziter „Articulation Work“ muss das Werkzeug kooperative
Strukturlege-Prozesse erlauben. Es muss möglich sein, das gelegte Modell simultan zu
erweitern oder zu verändern.
Anforderung 8 Persistente Ablage des Modells und Möglichkeit zur Rekonstruktion
Die persistente Ablage eines Modells (z.B. als digitale Repräsentation) und Werkzeug-
unterstützung zur Rekonstruktion eines abgelegten Modells erlaubt die Wiederaufnahme
eines unterbrochenen Strukturlegeprozesses bzw. die Reflexion und Anpassung bereits
erstellter Modelle zu einem späteren Zeitpunkt. Diese Forderung wird auch von Herr-
mann et al. (2002) angeführt (siehe Seite 63 in dieser Arbeit) und unter anderem von
Shipman und Hsieh (2000) zur Nachvollziehbarkeit bei Erstellung und Konsum von ver-
netzen Inhalten (dort: Hypertext) vorgeschlagen2.
2„By recording and replaying the authoring process, navigable history can re-situate an author after
a gap in the authoring process. Similarly, in a collaborative authoring process, an author can play
117
5.4. Grundlegende Technologieentscheidung
5.4. Grundlegende Technologieentscheidung
Basierend auf den oben identifizierten Anforderungen kann nun eine grundlegende Ent-
scheidung hinsichtlich der Technologie zur Umsetzung der Werkzeugunterstützung ge-
troffen werden. Aufgrund der Anforderungen, die aus dem Bereich der „Strukturlege-
techniken“ sowie „Articulation Work“ selbst abgeleitet wurden, ist die Unterstützung
durch ein Werkzeug notwendig, das die Erstellung und Repräsentation der Modelle im
physischen Raum ermöglicht.
Ein Teil der Anforderungen, die im Bereich des „Concept Mapping“ und ebenfalls wie-
der der „Articulation Work“ identifiziert werden konnten, können hingegen nur realisiert
werden, wenn das Werkzeug mit rechner-unterstützter Funktionalität angereichert wird.
Einerseits ist es nun also notwendig, das Modell physisch abzubilden, was der Verwen-
dung eines Werkzeugs mit bildschirmbasierter Benutzungsschnittstelle entgegensteht.
Andererseits ist zur Umsetzung mancher Anforderungen die Verwendung eines Rechners
notwendig, so dass das Modell auch digital erfasst und repräsentiert werden muss.
Ein Ansatz der Mensch-Maschine-Interaktion, der die Verwendung von interaktiven
Systemen mit nicht-traditionellen Benutzungsschnittstellen untersucht, ist jener der „Tan-
gible Interfaces“. Als „Tangible Interfaces“ werden im Allgemeinen Benutzungsschnitt-
stellen bezeichnet, die ein Computersystem mit auf den jeweiligen Anwendungsfall ab-
gestimmten physischen Artefakten kontrollierbar machen, die gleichzeitig zur Informa-
tionsausgabe durch das Computersystem verwendet werden.
Für den hier vorliegenden Anwendungsfall – der interaktiven kooperativen Erstellung
von diagrammatischen Modellen – bietet sich die Verwendung eines „Tangible Tabletop
Interface“ an. Als Spezialfall eines „Tangible Interface“ wird hier eine Tischoberfläche
als Ein- und Ausgabekanal verwendet, auf dem physische Artefakte zur Interaktion mit
dem System verwendet werden. Die Ähnlichkeit dieses Ansatzes mit dem Anwendungs-
szenario im Falle von „Strukturlegetechniken“ spricht für eine Verwendung von „Tangible
Tabletop Interfaces“ zur Umsetzung des in dieser Arbeit zu entwickelnden Werkzeugs.
through the events since his/her last authoring session to quickly determine the activity of the other
authors. Finally, in many situations, information becomes harder to interpret as its context changes
over time. By returning to the state of the information space at the time of authoring, disambiguation
of the information may become possible. For the reader who is not also the writer of the hypertext
there are additional uses of navigable history. A reader replaying the author’s writing process can
gain insight into the motivation of the author and have a greater understanding of the author’s
writing style. Such an understanding is important in collaborative work and in other contexts, like
education and literary analysis.“ (Shipman und Hsieh, 2000)
118
5.5. Zusammenfassung
5.5. Zusammenfassung
In diesem Kapitel wurden die Anforderungen an das zu entwickelnden Werkzeug aus
den Ergebnissen der Kapitel 2, 3 und 4 abgeleitet. Insgesamt konnten 8 Anforderungen
identifiziert werden, die hier – unabhängig von der konkreten Umsetzung – rein aus Sicht
der konzeptuell zu unterstützenden Tätigkeit beschrieben wurden.
Im letzten Abschnitt dieses Kapitels wurde auf Basis der Ergebnisse der Anforde-
rungserhebung jene Klasse von Systemen identifiziert, deren Verwendung die grundle-
gende Forderung nach physischer Modellbildung und gleichzeitiger Unterstützung durch
computerbasierte Werkzeuge erfüllen kann. „Tangible Interfaces“ sind hier mit ihrem
Anspruch, konkrete, physische Benutzungsschnittstellen für interaktive Computersyste-
me zur Verfügung zu stellen, durch die Ähnlichkeiten zu „Strukturlegetechniken“ bei der
gleichzeitigen Möglichkeit zur Umsetzung von rechnergestützten Funktionen einsetzbar.
5.5.1. Beitrag zur globalen Zielsetzung
Die in diesem Kapitel formulierten Anforderungen bilden die Brücke zwischen Methodik
und Werkzeug im Rahmen der Beantwortung der in Kapitel 1 formulierten Fragestel-
lung 4 („Wie kann ein Instrument zur Unterstützung von expliziter Articulation Work
umgesetzt werden?“).
Am Ende von Teil I beschriebene Methodik ist Teil des zur Unterstützung von „Arti-
culation Work“ konzipierten Instruments. Dieses wird durch das durch die hier formu-
lierten Anforderungen hinsichtlich seiner Funktionalität festgelegten Werkzeug zu jene
Instrument ergänzt, das Gegenstand der Fragestellung 4 ist.
Die hier formulierten Anforderungen repräsentieren gleichzeitig die aus methodischer
Sicht notwendigen Funktionen zur Unterstützung des kooperativen Externalisierungs-
und Abstimmungsprozesses und damit der Durchführung von „Articulation Work“ ab.
Die Erfüllung der Anforderungen ist damit eine Voraussetzung zur effektiven Unterstüt-
zung von „Articulation Work“. In diesem Sinne sind sie auch ein Beitrag zur Beantwor-
tung der Fragestellung 5 („Wie kann die Effektivität der Unterstützung von expliziter
Articulation Work beurteilt werden?“) und müssen als Beurteilungskriterien herangezo-
gen werden.
5.5.2. Weitere Verwendung der Ergebnisse
In den folgenden Kapiteln wird nun aufbauend auf der Grundsatzentscheidung für die
Entwicklung eines „Tangible Interfaces“ das Werkzeug in allen in den Anforderungen
angesprochenen Aspekten spezifiziert. Zusätzlich sind auch jeweils die konkrete techni-
sche Umsetzung sowie allfällige Einschränkungen, die diese Umsetzung mit sich brachte,
beschrieben.
119
5.5. Zusammenfassung
Kapitel 6 geht – noch unabhängig von dem konkreten hier entwickelten Werkzeug –
auf die Eigenschaften von Tangible Interfaces und deren Spezifikation ein. Daneben wird
in diesem Kapitel auch die „Related Qork“ aus konzeptueller und technischer Sicht auf-
gearbeitet. In den Kapiteln 7, 8 und 9 werden die Implementierungsalternativen und die
konkrete Umsetzung des Werkzeugs getrennt für die Eingabe von Information (also die
Modellbildung selbst), die Ausgabe von Information sowie die Sicherstellung der Persis-
tierung der Modelle beschrieben. Die Überprüfung der Erfüllung der hier spezifizierten
Anforderungen ist Gegenstand der Kapitel 12 und 13, die Teil der Beschreibung der
Evaluierung des hier entwickelten Systems sind.
120
6. Grundlagen der Realisierung und
verwandte Arbeiten
Zur Umsetzung des Werkzeugs wurde – wie in Kapitel 5 gefordert – ein „Tangible Table-
top Interface“ verwendet. Tabletop Interfaces zeichnen sich im Generellen dadurch aus,
dass im Gegensatz zu handelsüblichen Rechnern nicht nur die Software sondern auch
die Hardware applikationsspezifisch ist und nicht für beliebige Anwendungen eingesetzt
werden kann. Die Hardware bildet dabei einen Teil oder die gesamte Benutzungsschnitt-
stelle sowohl ein- als auch ausgabeseitig ab. Im speziellen Fall eines „Tangible Tabletop
Interfaces“ basiert der Benutzerinteraktion auf der Verwendung physischer Bausteine
(„Tokens“), die auf der physischen Oberfläche des Interfaces manipuliert werden. Diese
Interaktionsform wird von Tabletop Interfaces ergänzt, die die Benutzerinteraktion aus-
schließlich auf Gesten bzw. Berührungen der Oberfläche abbilden (horizontal verbaute
„Touch-“ bzw. „Multi-Touch-Displays“).
Tabletop Interfaces wurden Mitte der 1990er-Jahren in den Arbeiten von Ishii & Ull-
mer erstmals vorgestellt. Auch die erste Anwendung, die sich mit Modellierung auf
Tabletop Interfaces beschäftigt, stammt aus dieser Zeit. Mit dem Fortschreiten der
technologischen Entwicklung ist heute ein Status erreicht, in dem mit Hilfe generi-
scher Identifikations-Frameworks schnell und ohne großen Aufwand Applikationen mit
„tangiblen“ Eingabekanälen erstellt werden können. Zur Zeit noch im Prototypenstatus
befinden sich Systeme, die sich mit Möglichkeiten des tangiblen Informationsoutputs
beschäftigt. Der Rückkanal vom Rechner zum Benutzer wird heute zumeist durch die
Projektion von Inhalten auf die Arbeitsoberfläche umgesetzt.
In den folgenden Abschnitten wird die historische Entwicklung von Tabletop Inter-
faces sowie der aktuelle Stand der Entwicklung im Anwendungsbereich dieser Arbeit
betrachtet. Es werden dabei die grundlegenden Konzepte und Eigenschaften der jeweili-
gen Arbeiten betrachtet und das Potential hinsichtlich der Umsetzung von in Kapitel 5
identifizierten Anforderungen an das hier entwickelte Werkzeug betrachtet. Abbildung
6.1 stellt dieses Kapitel und dessen Aufbau im Kontext der anderen inhaltlich vor- und
nachgelagerten Kapitel dar.
6.1. Historischer Überblick
121
6.1. Historischer Überblick
Abbildung 6.1.: Kapitel „Grundlagen der Realisierung und verwandte Arbeiten“ im Ge-
samtzusammenhang
Wellner (1993) und Suzuki und Kato (1995) werden als jene Arbeiten angesehen, die
die Vision von alternativen Benutzungsschnittstellen für Computer maßgeblich geprägt
haben. „Alternativ“ bedeutet in diesem Zusammenhang die Verwendung von Ein- und
Ausgabekanälen, die sich von den herkömmlichen Werkzeugen wie Tastatur und Maus
bzw. Bildschirmen insofern unterscheiden, als dass sie eine unmittelbare Interaktion mit
der digital repräsentierten Information ermöglichen und deren Zustand in der realen
Welt widerspiegeln.
Der Begriff der „Tangible“ bzw. „Graspable Interfaces“ – also der „berührbaren“ oder
„begreifbaren“ Benutzungsschnittstellen — stammt ebenfalls aus der Mitte der neunzi-
ger Jahre des zwanzigsten Jahrhunderts. Fitzmaurice et al. (1995) werden im Allgemei-
nen als die Ersten betrachtet, die den Begriff des „Graspable User Interfaces“ prägen
und damit die Manipulierbarkeit digitaler Information durch physische Mittel beschrei-
ben. Fitzmaurice (1996) präzisiert später den Begriff durch die Abgrenzung zwischen
(herkömmlichen, maus-, tastatur- und bildschirmbasierenden) zeitlich gemultiplexten
Schnittstellen, bei denen der Informationsaustausch zwischen Benutzer und System über
einen Kanal zeitlich hintereinander erfolgt und den (neuartigen, berührbaren) räumlich
gemultiplexten Schnittstellen, bei denen mehrere Kanäle gleichzeitig zur Interaktion zwi-
schen Benutzer und System verwendet werden können.
122
6.2. Lernprozesse und Tangible Interfaces
Der Begriff des „Tangible User Interfaces“ (TUI) wurde kurz danach bzw. parallel
dazu von Ishii und Ullmer (1997) eingeführt. Ishii und Ullmer verfolgen dabei bei der
Definition den umgekehrten Weg und sprechen von einer „Augmentation der realen Welt
durch eine Kopplung von digitaler Information and physische Objekte“1.
Die erwähnte Kopplung wurde von Beginn an bidirektional verstanden. Dies bedeu-
tet, dass sowohl der Zustand der realen Welt die digitale Welt beeinflusst als such um-
gekehrt die digitale Welt auf die reale Welt zurück wirkt. Der Fokus der Entwicklung
lag in den ersten zehn Jahren der Entwicklung des Feldes klar auf den erstgenannten
Aspekt. Erforscht wurde im Wesentlichen die Manipulation von digitaler Information
mittels physischer Werkzeuge, der Zustand der digitalen Welt wurde zumeist ausschließ-
lich dargestellt, beeinflusste aber die reale Welt nicht weiter. Die Kopplung des physi-
schen Zustands der realen Welt an digitale Information (etwa die Veränderung der Form
oder Position von physischen Interface-Objekten durch die Ergebnisse einer im Rechner
durchgeführten Berechnung) wurde nur in Ausnahmefällen angesprochen (zumeist un-
ter der Bezeichnung „Ambient Interface“ (Gross, 2003)), strukturiert untersucht wurde
dieser Aspekt erstmals von Patten und Ishii (2007). Nach wie vor verzichtet ein Großteil
der vorgeschlagenen Systeme auf die automatisierte Manipulation der realen Welt und
beschränkt sich auf die Ausgabe der Information über einen optischen Kanal.
Technologisch gründet sich das Gebiet der Tangible Interfaces auf den Entwicklun-
gen im Bereich des Ubiquitous Computing (Weiser, 1991) und der Augmented Reality
(Azuma, 1997). Auch heute ist die Abgrenzung noch eher konzeptuell zu sehen. Die tech-
nischen Mittel der Umsetzung sind vor allem hardwareseitig nach wie vor nicht spezifisch
den einzelnen Gebieten zuzuordnen, lediglich softwareseitig ist eine Spezialisierung durch
die Entwicklung dedizierter Software-Frameworks zu erkennen.
6.2. Lernprozesse und Tangible Interfaces
Die Anwendungsbereiche von Tangible Interfaces sind historisch breit gestreut, lassen
jedoch eine Fokussierung auf die Unterstützung von kreativen und planenden Prozes-
sen erkennen. Ein wichtiger Anwendungsbereich war schon in den ersten Jahren akti-
ver Forschung das Gebiet der Unterstützung von Lernprozessen (Resnick et al., 1998).
Zurückgreifend auf die Ideen Pestalozzis, Montessoris (Montessori, 2005) und Piagets
(Piaget, 1976) bzw. Papert (Papert, 2000) schlagen Resnick et al. (1998) physische
Objekte mit Mitteln der IT anzureichern um Spielzeuge („digital manipulatives“) zu
schaffen, mit denen Kinder interagieren können und sich so physikalische bzw. system-
theoretische Konzepte spielerisch zu erschließen. Die Objekte fungieren dabei einerseits
als Baumaterialien und „Eingabekanal“ für den Rechner, andererseits gleichzeitig auch
als „Ausgabe“- bzw. Feedbackkanal über die Wirkung die in der digitalen Welt (etwa
1“augment the real physical world by coupling digital information to everyday physical objects and
environments”(Ishii und Ullmer, 1997)
123
6.2. Lernprozesse und Tangible Interfaces
in einer Simulation) mit der Eingabekonstellation erzielt wurde. In einer empirischen
Studie untersuchen Price et al. (2003) die Verwendung von „Tangibles“ in spielerischen
Lernsituationen. Sie identifizieren mehrere positive Effekte, darunter hohe Motivation
bei der Interaktion mit dem System und umfassende kooperative Aktivitäten, die durch
das System ermöglicht bzw. unterstützt werden. Als prominentes Ergebnis stellen die
Autoren die stark ausgeprägte Tendenz zur Reflexion des Spielprozesses und der Erklä-
rung der eigenen Tätigkeiten heraus. Sie setzen dieses Verhalten mit dem von Schön
(1984) im Kontext von organisationalem Lernen beschriebene Phänomen der „reflection
in action“ gleich.
Die Erkenntnisse der Entwicklungen und empirischen Untersuchungen in diesem Be-
reich wurden sowohl in der frühkindlichen Bildung (Zuckerman et al., 2005) als auch
in organisationalen Lernprozessen zur Erhebung und Abstimmung von Strukturen und
Abläufen in Unternehmen (The LEGO Group, 2002) eingesetzt. Die dort verfolgten Kon-
zepte sind für diese Arbeit insofern von Interesse, als dass Tangible Interfaces dabei zur
Modellbildung im engeren Sinne und – im Falle der organisationalen Anwendung – auch
für „Articulation Work“ im Allgemeinen eingesetzt wurden.
Marshall (2007) versucht die möglichen Einflussfaktoren und Wirkungen von Tangible
Interfaces auf Lernprozesse zu strukturieren und in einem analytischen Framework zu be-
schreiben. Er identifiziert sechs Perspektiven und exemplarisch mögliche Ausprägungen,
die es erlauben, die Verwendung eines Tangible Interfaces in Lernprozessen strukturiert
zu betrachten (siehe Abbildung 6.2).
Abbildung 6.2.: Tangible Interfaces in Lernprozessen (entnommen aus Marshall (2007))
Die Perspektive „Learning Domains“ bezieht sich hier auf den Anwendungsbereich des
TUI2. Im konkreten Fall ist diese mit der Arbeits-Domäne, in der die „ArticulationWork“
durchgeführt wird, gleichzusetzen und ändert sich deshalb je nach Anwendungsfall.
In der Perspektive „Possible Learning Benefits“ betonen die Autoren mit Bezugnah-
me auf Arbeiten aus den Kognitionswissenschaften die potentiell positiven Aspekte von
2Tangible User Interface
124
6.3. Kooperation und Tangible Interfaces
physischen Repräsentationen, die durch die haptische Wahrnehmbarkeit verständlicher
als rein visuelle Repräsentationen sind. In diesem Zusammenhang erwähnen die Autoren
auch die Eignung von Tangible Interfaces in kooperativen Lernsituationen, in denen das
Interface durch seine physische Präsenz einen „shared space“ erzeugt, in dem Kommu-
nikation und Interaktion erleichtert werden.
Relevant im Kontext von „Articulation Work“ bzw. der Externalisierung und Ab-
stimmung von mentalen Modellen sind die beiden Lernformen, die in der Perspektive
„Learning Activity“ identifiziert wurden. Demnach ermöglichen Tangible Interfaces be-
sonders explorative und expressive Aktivitäten. Erstere beziehen sich auf eine Erfor-
schung einer existierenden physischen Repräsentation, die experimentell verändert wer-
den kann und die Entwicklung eines tiefergehenden Verständnisses für das repräsentierte
Phänomen ermöglicht. Zweitere beziehen sich auf Erzeugung von Repräsentationen mit
dem Tangible Interface. Dabei kann die Abbildung direkt erfolgen, alternativ kann aus
der Interaktion mit dem Interface eine Repräsentation (etwa eines Arbeitsablaufs) vom
System automatisiert abgeleitet werden.
Die übrigen Perspektiven sind für den hier betrachteten Anwendungsfall nur bedingt
relevant („Concretness and sensori-directness“) oder werden in späteren Abschnitten
noch detaillierter behandelt („Integration of representations“ bzw. „Effects of physica-
lity“). Auf sie wird hier deshalb nicht näher eingegangen.
6.3. Kooperation und Tangible Interfaces
„Articulation Work“ wird in einem Großteil der Anwendungen kooperativ durchgeführt.
Die hier zu unterstützende „explizite Articulation Work“ zur Abstimmung mentaler
Modelle mittels Externalisierung findet immer unter Beteiligung mehrerer Individuen
statt, die simultan versuchen, ihre individuellen Sichtweisen auf einen Arbeitsablauf ab-
zustimmen. In Kapitel 3 wurde auf die Nützlichkeit von physischen Repräsentationen
bei der Externalisierung mentaler Modelle verwiesen. Auch in der Domäne der Tangible
Interfaces wurde die Wirkung der dedizierten, physischen Schnittstelle auf die Koope-
ration der beteiligten Individuen untersucht (erstmals in (Hornecker, 2001)). Die dort
gezogenen Schlüsse sind Gegenstand dieses Abschnitts.
Tangible Interfaces bieten durch die physische Ausgestaltung der Benutzungsschnitt-
stelle oft die Möglichkeit, nicht exklusiven Zugriff auf die Funktionen des Systems und
so eine kooperative Verwendung zu ermöglichen. Hornecker (2004) geht über die rein
simultane Zugreifbarkeit auf das System hinaus und attestiert Tangible Interfaces ei-
ne inhärent kooperationsunterstützende Wirkung. Sie identifiziert im Kern vier sozial
Effekte von Tangible Interfaces:
• Intuitive und simultane Manipulierbarkeit
• Fokus-stärkende Wirkung
125
6.3. Kooperation und Tangible Interfaces
• Awareness, Gestik und perfomative Bedeutung der Handlungen
• Externalisierungsfunktion und Rolle als Boundary Object
Diese Effekte werden in den folgenden Abschnitten kurz auf Basis der Ausführungen
der Autorin zusammengefasst und in den Kontext der Unterstützung von „Articulation
Work“ gesetzt. Für eine detaillierte Beschreibung sei hier auf (Hornecker, 2004, S. 147-
212) verwiesen. Auch die Referenzen zu den einzelnen hier wiedergegebenen Hypothesen
sind dort zu finden – in dieser Arbeit wurde auf deren Angabe verzichtet.
6.3.1. Intuitive und simultane Manipulierbarkeit
Tangible Interfaces wird eine intuitive Manipulierbarkeit zugeschrieben. Dies bedeutet
in diesem Zusammenhang, dass der Zugang zum System spielerisch und erfahrungsorien-
tiert erfolgen kann und keine Übersetzung der intendierten Handlungen auf am Rechner
ausführbare Aktivitäten erfolgen muss. Dies ist vor allem für Personen eine Erleichte-
rung, denen der abstahierender Zugang schwerfällt. Konkret zeigt sich das unter anderem
bei der Externalisierung von Handlungswissen, das an bestimmte Situationen gebunden
ist und von den handelnden Personen nur schwer bzw. nicht generalisiert werden kann.
Kann während der Externalisierung in der realen, physischen Welt verblieben werden,
erleichtert dies den Zugang zum System und führt im Allgemeinen zu vollständigeren
bzw. stimmigeren Externalisierungen.
Zudem ermöglicht ein einfacher Zugang zum System eine Konzentration auf die ei-
gentliche Arbeitsaufgabe – das Werkzeug tritt in den Hintergrund. Wichtig ist in diesem
Zusammenhang die Anforderung, Änderung einfach rückgängig machen zu können, so
dass inhaltliche Experimente einfach und ohne Aufwand korrigiert werden können, wenn
sie sich als nicht zielführend erweisen (Klemmer et al., 2002).
Die simultane Manipulierbarkeit vieler Tangible Interfaces fördert ebenfalls die Ko-
operation bei der Benutzung des Systems. Der nicht-exklusive Zugang zur Benutzungs-
schnittstelle ermöglicht erst eine unmittelbare Zusammenarbeit am Arbeitsgegenstand.
In Kombination mit der intuitiven Manipulierbarkeit wird der Kooperations-Aspekt
noch weiter gestärkt, da Spezialkompetenzen zur Bedienung des Systems nicht not-
wendig sind. Der Zugang zur Schnittstelle wird damit auch egalitärer und schließt nicht
einzelne Benutzergruppen von der Bedienung des Werkzeugs aus. Dies wird vor allem in
partizipartiven Planungs- und Entwurfsprozessen (wie „expliziter Articulation Work“)
deutlich, in denen Personen unterschiedlicher Fach- und Medienkompetenz zusammen-
arbeiten müssen.
Der physische Interaktionsraum führt neben der simultanen Manipulierbarkeit auch zu
natürlicheren Interaktionsabläufen zwischen den beteiligten Individuen. Im Gegensatz
zu Systemen, bei denen im virtuellen Raum interagiert wird, müssen keine expliziten
Synchronisationsmechanismen eingeführt werden, die etwa Bearbeitungskonflikte ver-
meiden. Die Abstimmung erfolgt durch die unmittelbare Manipulation direkt und muss
126
6.3. Kooperation und Tangible Interfaces
nicht weiter technisch unterstützt werden. Auch ist im Allgemeineren eine feingranula-
rere Interaktion als bei bildschirmbasierter Zusammenarbeit zu beobachten. „Feingra-
nular“ bedeutet hier, dass der Aktivitätsfokus („Turn-taking“) öfter wechselt und somit
zu gleichmäßigeren Einzelbeiträgen im Gesamtergebnis führt.
6.3.2. Fokus-stärkende Wirkung
Physische Modelle, die mittel Tangible Interfaces erstellt werden oder Gegenstand des-
selben sind, wirken nicht nur räumlich fokussierend, sondern konkretisieren auch die
inhaltliche Interaktion und fördern lösungsorientierte Diskussionen.
Die inhaltlich fokussierende Wirkung ist auf mehrere Aspekte zurückzuführen, die bei
unterschiedlichen Ausprägungen von Tangible Interfaces unterschiedlich stark auftreten.
Die folgenden Ausführungen sind im Kontext von (den in dieser Arbeit relevanten) tisch-
basierten Systemen zu sehen, auf die sich auch Hornecker (2004) vorrangig bezieht.
Der erste erwähnenswerte Einflussfaktor ist die fokussierende Wirkung einer physisch
im Zentrum stehenden Repräsentation, die von den beteiligten Individuen „umringt“
wird. Diese Konstellation schafft einen gemeinsamen „Transaktionsraum“ und wirkt als
„soziales Signal“ für die Kommunikationsaufnahme. Entfernte (etwa auf eine Wand pro-
jizierte) Repräsentationen führen nicht zu derartigen Konstellationen.
Die physische Repräsentation wird zu einem gemeinsamen Bezugspunkt und erzeugt
sozialen Druck, sich bei der Diskussion auf sie zu beziehen. Zudem erleichtert sie die
Durchsetzung der Forderung nach Konkretisierung von artikulierten Gedanken und vi-
sualisiert gleichzeitig die Auswirkungen möglicher Entscheidungen.
Die „Öffentlichkeit“ physischer Repräsentationen, deren Veränderung für alle beteilig-
ten Individuen einsehbar ist, fördert die individuelle Reflexion von eingebrachten Ideen
und Gedanken und erleichtert gleichzeitig die Konsensfindung und pragmatische Kon-
fliktlösung.
Wesentliche Faktoren für die fokussierende Wirkung von physischen Repräsentationen
sind deren Größe, die Sichtbarkeit und Öffentlichkeit sowie deren Materialiät. Hinsicht-
lich der Größe existiert sowohl eine Unter- als auch eine Obergrenze für das Auftreten der
fokusfördernden Wirkung. Ist die Repräsentation zu klein, ist sie unter Umständen nur
für einen Teil der beteiligten Individuen zu erkennen und verhindert eine nicht-exklusive
Manipulation. Ist sie zu groß, kann die Repräsentation unter Umständen nicht in ihrer
Gesamtheit erfasst werden.
Neben der Fokuswirkung der Repräsentation ist auch jene der verwendeten Werkzeuge
zur Manipulation des Systemzustandes relevant. Im Gegensatz zu generischen Werkzeu-
gen wie Tastatur und Maus schränken physisch für eine bestimmte Aufgabe ausgelegte
Werkzeuge den Interaktionsraum auf natürliche Art und Weise ein. Konzeptuell durch-
dachtes Interaktionsdesign führt so zu einer Fokussierung auf die möglichen Aktionen
127
6.3. Kooperation und Tangible Interfaces
und lenken die Aufmerksamkeit der Individuen auf jene Strukturen, die durch diese
manipuliert werden.
6.3.3. Awareness, Gestik und performative Bedeutung der
Handlungen
Die physische Präsenz einer Benutzungsschnittstelle im realen Raum erlauben, im Ge-
gensatz zu bildschirmbasierten Schnittstellen, die Aufmerksamkeit nicht ausschließlich
auf die Interaktion mit dem System zu konzentrieren. Vielmehr ist es möglich durch die
periphäre Wahrnehmung der Umgebung die „Awareness“ (Dourish und Bellotti, 1992) –
also das Bewusstsein über das, was im räumlichen und inhaltlichen Kontext der eigent-
lichen Aufgabe passiert – zu erhöhen.
Die „Awareness“ umfasst auch bzw. vor allem die Tätigkeiten anderer Individuen, die
an der Interaktion beteiligt sind3. Durch die räumliche Nähe sind die Handlungen dieser
Individuen nicht nur in ihrer Konsequenz (also der Wirkung auf die Repräsentation) er-
kennbar, sondern umfassender wahrnehmbar. Handlungen werden schon durch die begin-
nende Bewegung vor ihrer Durchführung wahrgenommen, auch die eigentliche Handlung
erzeugt wahrnehmbare Effekte. Dadurch kommt es zu einer impliziten Abstimmung der
Handlungen der einzelnen Personen (gleichzusetzen mit der Durchführung von „impli-
cit Articulation Work“), eine explizite Aushandlung der kooperativen Handhabung der
Schnittstelle ist im Normalfall nicht mehr notwendig. Dies korreliert mit der im letzten
Abschnitt dargestellten Hypothese, dass physische Benutzungsschnittstellen gegenüber
der eigentliche Arbeitsaufgabe in den Hintergrund treten und eine stärke Fokussierung
auf diese erlauben.
Das physisch vorhandene Modell fungiert außerdem als Referenzrahmen für non-verbale
Kommunikation etwa mittels Gesten. Durch Zeigen auf oder Antippen von Elementen ei-
nes TUI wird nicht nur der Fokus der Interaktion auf den durch dieses Element repräsen-
tierten Aspekt gelenkt. Je nach Stärke und Ausprägung der referenzierenden Handlung
kann damit auch eine performative Bedeutung verbunden sein. So kann zum Beispiel
das Weiterreichen eines Elements die Übergabe der Kontrolle ausdrücken oder starkes
Antippen eines Elements mit der Aufforderung verknüpft sein dieses in der Diskussion
zu berücksichtigen.
6.3.4. Externalisierungsfunktion und Rolle als Boundary Object
Die Unterstützung von Externalisierung mittels physischer Modelle wurde bereits im
Kapitel 3 beschrieben. Tangible Interfaces sind als eben solche Modelle zu verstehen, die
3„awareness is an understanding of the activities of others, which provides a context for your own
activity.“(Dourish und Bellotti, 1992, S. 1)
128
6.3. Kooperation und Tangible Interfaces
eine Schnittstelle zur Manipulation von beliebigen realen oder virtuellen Phänomenen
bieten. Wie bereits in Kapitel 3 angeführt, wirken physische Modelle als „Ankerpunkte“
sowohl für individuelle kognitive Vorgänge als auch in der Kommunikation zwischen
Individuen.
Die Unterstützung von kognitiven Vorgängen, also der Wirkung von Tangible Inter-
faces als „Denkhilfe“ ist insofern gegeben, als dass die physische Repräsentation Ein-
gaben dauerhaft abbildet und so verhindert, dass diese im Verlauf der Externalisierung
untergehen. Die Repräsentation wirkt so außerdem kummulativ und führt Aspekte zu-
sammen, die in keinem offensichtlichen Zusammenhang stehen. Sie bildet in weiterer
Folge auch eine Basis um unter Berücksichtigung aller externalisierten Aspekte Varian-
ten der ursprünglichen Repräsentation zu bilden.
Externalisierte Repräsentationen wirken auch bei der Kommunikation unterstützend,
fungieren in diesem Zusammenhang also als „Sprechhilfe“. Eng in Zusammenhang mit
dieser Wirkung steht der Begriff der „Boundary Objects“ (Star, 1989). „Boundary Ob-
jects“ sind Objekte, die der Entwicklung eines gemeinsamen Verständnisses zwischen
Individuen aus unterschiedlichen Domänen dienen. Sie bieten im Kern eine fixe, für al-
le Beteiligten einheitlich verständliche Repräsentation eines beliebigen Phänomens und
sind gleichzeitig so flexibel, dass sie in den jeweiligen Domänen mit spezifischer Bedeu-
tung angereichert werden können. Tangible Interfaces wirken – wenn deren Design offen
genug angelegt ist – als „Boundary Objects“ und erleichtern so die Herausbildung gegen-
seitigen Verständnisses. In diesem Zusammenhang ist auch die Entstehungshistorie einer
physischen Repräsentation von Interesse. Durch die Nachverfolgbarkeit der Entstehung
kann das Verständnis der Repräsentation erleichtert werden, da die Herausbildung der
im Ergebnis enthaltenen Strukturen nachvollziehbar wird.
6.3.5. Implikationen
Die hier vorgestellten kooperationsfördernden Aspekte von Tangible User Interfaces wur-
den von Hornecker (2004) im Rahmen ihrer Dissertation aus der Literatur identifiziert
und empirisch überprüft. Bereits aus der obigen Zusammenfassung wird erkennbar, das
ein Großteil der identifizierten Aspekte für „Articulation Work“ im Allgemeinen und die
Externalisierung und Abstimmung von mentalen Modellen im Speziellen relevant ist.
Obwohl Hornecker (2004) keine Anforderungen an das Design von Tangible Interfaces
identifiziert, deren Beachtung zu einer kooperationsfördernden Wirkung führt, können
jedoch aus den theoretischen Ausführungen Hinwiese abgeleitet werden, wie ein TUI
konzipiert werden muss:
• Die physische Repräsentation muss räumlich und technisch egalitär zugänglich sein.
Das Werkzeug darf die Interaktion zwischen den Benutzern nicht einschränken oder
behindern.
129
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
• Die Größe der Benutzungsschnittstelle muss so ausgelegt sein, dass sowohl eine
simultane Manipulierbarkeit der gesamten Repräsentation als auch deren indivi-
duelle Erfassbarkeit für alle beteiligten Individuen gegeben ist.
• Die Elemente des Tangible Interfaces müssen so konkret sein, dass die Benutzer
ihnen eindeutig Bedeutung zuweisen können, gleichzeitig aber offen, dass sie als
„Boundary Objects“ zwischen Benutzern aus unterschiedlichen Fachdomänen fun-
gieren können.
• Änderungen müssen ohne bleibende Konsequenzen durchgeführt werden können
bzw. leicht rückgängig gemacht werden können.
• Eine Nachverfolgbarkeit der Entstehungshistorie (ggf. mit Identifikation der indi-
viduellen Beiträge) kann zur Verständnisbildung beitragen.
6.4. Konzeptualisierung und Klassifikation von Tangible
Interfaces
Die Entwicklung des Forschungsgebiets der „Tangible Interfaces“ wurde von mehreren
konzeptuellen Arbeiten maßgeblich beeinflusst. Die dort vorgeschlagenen Erklärungs-
modelle definieren das Gebiet und grenzen es gegenüber anderen Forschungsbereichen
ab. Sie dienen außerdem als Grundlage für die strukturierte Betrachtung und Konzep-
tion konkreter Tangible Interfaces. Im Folgenden werden diese konzeptuellen Arbeiten
beschrieben und auf deren Kontext und Spezifika eingegangen.
Zur strukturierten Betrachtung von Tangible Interfaces ist es außerdem notwendig
jene Dimensionen zu identifizieren, an denen sich konkrete Systeme einordnen und un-
terscheiden lassen. Die Ausprägungen dieser Dimensionen ergeben ein Begriffssystem,
das bei der Aufbereitung von unterschiedlichen Tangible Interfaces sowie deren Ver-
gleich helfen kann. Die hier vorgestellten Ansätze tragen verschieden detailliert und von
unterschiedlichen Standpunkten aus zu dieser Thematik bei. Sie werden in der Folge
strukturiert dargestellt und in Kapitel 10 auf das in dieser Arbeit entwickelte System
angewandt um so das System-Design aus konzeptueller Sicht zu reflektieren und poten-
tielle Verbesserungs- und Erweiterungsmöglichkeiten zu identifizieren.
Allgemein ist anzumerken, dass eine Vielzahl von Ausdrücken im sich entwickelnden
Forschungsgebiet mehrfach belegt wurden und/oder nicht eindeutig definiert sind. Im
Folgenden werden die Ausdrücke der jeweiligen Autoren übernommen. Eine Interpre-
tation bzw. Abbildung auf die Terminologie anderer Autoren wird nur vorgenommen,
wo sie im jeweiligen Artikel explizit angeführt wurde. In der Zusammenfassung dieses
Abschnitts wird versucht, die unterschiedlichen Terminologien nochmals zusammenzu-
fassen und einen Satz an Ausdrücken festzulegen, der im Folgenden für diese Arbeit
Anwendung findet.
130
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Am Ende jeder Beschreibung sind in einer tabellarischen Zusammenfassung jeweils die
zentralen Konzepte und Beiträge des Ansatzes angeführt. Die Tabellen weisen einheitlich
Einträge zu folgenden Themen auf:
Kategorien von Tangible Interfaces, die im Beitrag identifiziert werden (inkl. Unter-
scheidungsmerkmal zur Kategoriebildung).
Konzepte , die bei der Betrachtung bzw. beim Design eines Tangible User Interfaces
zur Anwendung kommen.
Eigenschaften , die ein Tangible User Interface bzw. dessen Komponenten aufweisen
können.
PD-Brücke : Aussagen, die der Beitrag zur Natur oder Ausgestaltung der Brücke zwi-
schen physischer und digitaler Welt macht.
Wird in einem Beitrag keine Aussage zu einem oder mehreren dieser Themen gemacht,
so ist dies explizit durch „—“ angeführt.
Die Ansätze, die in dieser Betrachtung berücksichtigt wurden, sind in der Reihenfolge
der zeitlichen Entstehung angeordnet. Eine Beschreibung und Visualisierung der kausa-
len Zusammenhänge und Bezugnahmen erfolgt in der Zusammenfassung der Ergebnisse
in Abschnitt 6.4.13. Bei der Beschreibung der Arbeiten wird nicht auf sämtliche vorge-
stellten Aspekte eingegangen. Es wird vielmehr auf jene Teile eingegangen, die sich mit
der Konzeptualisierung oder Klassifikation von Tangible User Interfaces beschäftigen.
Die berücksichtigten Ansätze wurden im Rahmen einer umfassenden Literaturstudie
identifiziert und sind im Einzelnen:
• Bricks (Fitzmaurice et al., 1995)
• Graspable User Interfaces (Fitzmaurice, 1996)
• Tangible Bits (Ishii und Ullmer, 1997)
• Containers, Tokens und Tools (Holmquist et al., 1999)
• Tangible Object Meaning (Underkoffler und Ishii, 1999)
• Das MCRpd Interaktions-Modell (Ullmer und Ishii, 2000)
• Tokens and Constraints (Ullmer, 2002)
• Degree of Coherence (Koleva et al., 2003)
• Tokens and Constraints zur Spezifikation (Shaer et al., 2004)
• Kategorien von TUI-Anwendungen (Klemmer et al., 2004)
• Tangible User Interfaces Taxonomy (Fishkin, 2004)
• Tangible Bits: Beyond Pixels (Ishii, 2008)
131
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
6.4.1. Bricks
Mit „Bricks“ stellen Fitzmaurice et al. (1995) das erste als „Graspable User Interface“
bezeichnete System vor. Dieses bildet die Grundlage für weitere Arbeiten der Autoren
(z.B. Fitzmaurice (1996)), die in der Folge noch behandelt werden (siehe Abschnitt
6.4.2).
Konzeptuell spannen die Autoren am Ende der Arbeit einen „Design Space“ auf, der
mögliche Eigenschaften und Parameter eines Tangible User Interfaces definiert und auch
deren möglichen Ausprägungen festlegt. Dabei werden einerseits technische Aspekte des
Interfaces abgedeckt, andererseits wird aber auch der Aufbau und die Verwendung des
TUI berücksichtigt. Die Ausprägungen sind dabei rein beschreibender Natur und wer-
den nicht für eine wie auch immer geartete Bewertung oder Klassifikation genutzt. Das
Beschreibungsschema ist stark auf auf Interfaces mit aktiv untereinander kommunizie-
renden Komponenten („Bricks“) abgestellt, die zur Manipulation einer digitalen An-
wendung verwendet werden und auf einer physischen Oberfläche bedient werden. Passi-
ve bzw. rein informationstragende Elemente ohne Manipulationsfunktion werden nicht
berücksichtigt. Dies liegt in der Natur der von den Autoren entwickelten Anwendung
und dem zum Zeitpunkt der Erstellung herrschenden Mangel an alternativen Systemen
begründet.
Brick’s internal ability Haben die physischen Elemente Mechanismen, die zur Darstel-
lung oder Manipulation von Information benutzt werden können? Diese Mechanis-
men können physischer oder elektronischer Natur sein. (Mögliche Ausprägungen:
„inert“ – „simple expressions“ – „smart“)
Input & Output Welche Eigenschafen der physischen Objekte werden zur Eingabe von
Information erfasst bzw. zu Ausgabe verwendet? (Keine Ausprägungen, Aufzäh-
lung der Eigenschaften für Input und Output)
Spatially aware Kann ein Brick seine Umgebung und/oder andere Bricks wahrnehmen?
(Mögliche Ausprägungen: „unaware“ – „mutually aware“ – „aware of surroun-
dings“)
Communication Wie kommunizieren Bricks untereinander bzw. mit einer eventuell vor-
handenen Hintergrund-Infrastruktur (Mögliche Ausprägungen: „Wireless“ – „Te-
thered“ – „Grid board“)
Interaction time span Wie lange dauert eine Interaktion der Benutzer mit dem System
bei der Erfüllung einer vorgegebenen Aufgabe? (Mögliche Ausprägungen: „quick
(within seconds)“ – „interaction cache (seconds - minutes)“ – „long-term (days,
months, years)“)
Bricks in use at same time Wieviele physische Elemente werden simultan verwendet?
(Mögliche Ausprägungen (höhere Werte stehen für Größenordnung): „1“ – „2“ –
„5-10“ – „50-100“)
132
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Function assignment Wie oft und mittels welchem Vorgehen wird Bricks Funktionali-
tät zugeordnet? (Mögliche Ausprägungen: „permanent“ – „programmable“ – „tran-
sient“)
Interaction representations Werden physische und virtuelle Objekte gleichzeitig ver-
wendet, um den Systemzustand darzustellen bzw. zu manipulieren? (Mögliche Aus-
prägungen: „all physical“ – „mix, physical dominates“ – „balanced mix“ – „mix,
virtual dominates“ – „all virtual“)
Physical & Virtual layers Werden physische und virtuelle Interaktions-Schichten sepa-
rat oder kohärent dargestellt? (Mögliche Ausprägungen: „direct (superimposed)“
– „indirect (separated)“)
Bond between physical & virtual layers Wie stark sind die physischen mit den virtu-
ellen Objekten gekoppelt? (Mögliche Ausprägungen: „tightly coupled (real time
sync)“ – „loosely coupled (batch sync)“)
Operating granularity Wie groß ist der Refenzrahmen für die Interaktion mit den phy-
sischen Elementen und wie genau werden die Positionen der Elemente aufgelöst?
(Mögliche Ausprägungen: „Desktop (fractions of inches accuracy)“ – „Room (inch
accuracy)“ – „Building (room accuracy)“)
Operating surface type Werden die physischen Elemente auf einer fix vorgegebenen,
unveränderlichen Oberfläche verwendet oder kann sich die Oberfläche dynamisch
verändern (z.B. Information anzeigen)? (Mögliche Ausprägungen: „static (e.g. pa-
per)“ – „dynamic (e.g. screen)“)
Operating surface texture Welche Auflösung oder Textur besitzt die Arbeitsoberflä-
che, auf der die physischen Elemente bewegt werden? (Mögliche Ausprägungen:
„discrete (e.g. grid board)“ – „continuous, smooth movement“)
Betrachtungsgegenstand ist bei diesem Ansatz das gesamte TUI, auf speziifische Ei-
genschaften einzelnen Komponenten wird nicht separat eingegangen. Die physischen
Elemente (hier „Bricks“) werden nicht im Detail betrachtet, sondern nur hinsichtlich
ihrer Verwendung im Gesamtsystem und ihrer technischen Einbindung berücksichtigt.
Kategorien —
Konzepte Brick
Eigenschaften Gesamtsystem: Brick’s internal ability, Input & Output,
Spatially aware, Communication, Interaction time span,
Bricks in use at same time, Function assignment, Inter-
action representations, Physical & virtual layers, Bond
between physical & virtual layers, Operating granulari-
ty, Operating surface type, Operating surface texture
PD-Brücke —
133
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
6.4.2. Graspable User Interfaces
Fitzmaurice legt in jener Arbeit, in der der Begriff des „Graspable User Inferfaces“ erst-
mals ausführlich eingeführt wird (Fitzmaurice, 1996), auch Eigenschaften fest, anhand
derer sich die „Graspability“ einer Benutzungsschnittstelle zeigt und beurteilen lässt. Im
wesentlichen handelt es sich dabei um einen auf die für die Beurteilung der „Graspabili-
ty“ relevanten reduzierten Satz an Eigenschaften, die bereits in (Fitzmaurice et al., 1995)
angeführt wurden (siehe Abschnitt 6.4.1). Die Beurteilung erfolgt auf einer generischen
Skala mit Ausprägungen von „niedrig“ bis „hoch“, wobei „hohe“ Werte in mehreren
Eigenschaften auf eher hohe „Graspability“ hinweisen. Die Eigenschaften beziehen sich
auf Tangible User Interfaces, die lediglich Werkzeuge zur Manipulation von digitalen Da-
ten besitzen, jedoch keine physische Repräsentation von Information aufweisen. Diese
Einschränkung ist wiederum auf die historische Entwicklung des Gebiets und die ersten
Versuche GUI-Paradigmen in den physischen Raum zu übersetzten zurückzuführen.
Space-multiplexing Ändern sich die Zuordnungen zwischen physischen Elementen und
digitalen Funktionen über die Zeit oder existiert eine permanente Zuordnung?
(Mögliche Ausprägungen: kontinuierlich von „transient, always reassign“ – „per-
manent, never reassign“)
Concurrency Ist die gleichzeitige Ausführung mehrere Operationen mit mehreren phy-
sischen Elementen (abhängig oder unabhängig voneinander) möglich und vorgese-
hen? (Mögliche Ausprägungen: „1“ – „occasionally 2“ – „2“ – „3“ – „more than
3“)
Physical form Lässt sich aus der physischen Form auf die ausgeführte Funktion schließen
oder sind die Werkzeuge generisch für unterschiedliche Funktionen verwendbar?
(Mögliche Ausprägungen: „generic“ – „specific“)
Spatially aware Erfasst und berücksichtigt das System die Positionen, Orientierung
und/oder Nähe der physischen Objekte bei der Interpretation der Interaktion?
(Mögliche Ausprägungen: „unaware“ – „aware“)
Spatial reconfigurability Kann das System in unterschiedlichen physischen Kontexten
betrieben werden oder kann es ausschließlich ortsgebunden eingesetzt werden?
(Mögliche Ausprägungen (bezogen auf TUIs aus einzelnen, handhabbaren Objek-
ten): „permanent location“ – „stationary“ – „track“ – „tethered“ – „free-ranging
(rapid layout)“)
Fitzmaurice stellt mit diesen Eigenschaften ein Framework für die Einordnung eines
TUI als Gesamtsystem zur Verfügung und geht nicht auf einzelne Komponenten ein. Die
Eigenschaften beziehen sich auf das Design des Systems und ignorieren dessen Verhal-
ten. Die ersten beiden und die letzte Eigenschaft sind mit einer kontinuierlichen Skala
hinterlegt, physical form und spatially aware sind binäre Eigenschaften, die entweder
gegeben sein können oder nicht.
134
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Kategorien —
Konzepte —
Eigenschaften Gesamtsystem: Space-multiplexing (transient – perma-
nent), Concurrency (1 – mehr als 3), Physical form (ge-
neric, specific), Spatially aware (unaware, aware), Spati-
al reconfigurability (permanent location – free-ranging)
PD-Brücke —
6.4.3. Tangible Bits
Ishii und Ullmer (1997) stellen in ihrer Arbeit die Idee der „Tangible Bits“ vor, die die
virtuelle Welt mit der realen Umwelt verknüpfen soll. Dabei wird digitale Information
mit realen Objekten oder Phänomenen gekoppelt und so „tangibel“ gemacht. Die Auto-
ren unterscheiden drei grundsätzliche Kernkonzepte, mit Hilfe derer die Idee umgesetzt
werden kann:
Interactive Surfaces , bei denen beliebige Oberflächen in der realen Welt (etwa Wände
oder Schreibtische) zu aktiven Schnittstellen zur virtuellen Welt werden.
Coupling Bits and Atoms , wo physischen Objekten Information zugeordnet wird, so
dass die realen Objekte zu Trägern von und Schnittstellen zu digitaler Information
werden.
Ambient Media , bei deren Einsatz Information über die Umgebung der Benutzer ver-
mittelt wird (z.B. mittels Veränderung der Beleuchtung) ohne die eigentliche Tä-
tigkeit zu unterbrechen.
Die Autoren ordnen Tangible Bits an die Schnittstelle zwischen den Forschungsgebie-
ten „Ubiquitous Computing“ und „Augmented Reality“ ein. „Ubiquitous Computing“
(Weiser, 1991) beschäftigt sich mit Anwendungen, in denen Computer nicht mehr als
als solche wahrnehmbare Werkzeuge eingesetzt werden, sondern in der Umgebung inte-
griert sind und von Benutzern nicht mehr bewusst wahrgenommen, sondern nur noch
als Teil der Alltagswelt benutzt werden. Tangible Bits erben von dieser Forschungsrich-
tung die Idee der physischen, natürlichen Interaktion zwischen Benutzern und Rechner,
unterscheiden sich aber insofern, dass nach wie vor ein Interface zur virtuellen Welt
vorhanden ist, diese also zum Teil noch bewusst wahrgenommen wird. In diesem Aspekt
ähneln Tangible Bits den Ideen, die aus der „Augmented Reality“ Forschung stammen.
Augmented Reality beschäftigt sich mit Methoden, die die reale Welt mit digitaler Infor-
mation nahtlos ergänzen bzw. anreichern. Vor allem im Bereich der Ausgabetechnologien
werden bei Tangible Bits viele aus dem „Augmented Reality“-Bereich stammende Kon-
zepte eingesetzt.
Nach dieser grundlegenden Begriffsklärung stellen die Autoren Prototypen vor, die
sowohl das Konzept der „Interactive Surfaces“ als auch der „Ambient Media“ umsetzten.
Erwähnenswert ist im Zusammenhang mit dieser Arbeit der Prototyp „metaDESK“
135
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
(Ullmer und Ishii, 1997), eine interaktive Oberfläche in Form eines Tisches, auf der die
klassischen Interaktionselemente eines GUI4 in die reale Welt transferiert wurden. Dabei
wurden die GUI-Elemente auf TUI-Elemente abgebildet5:
• Windows werden auf „Lenses“ abgebildet, also Linsen, die Information zu realen,
physischen Elementen anzeigen.
• Icons werden in der physischen Welt als „Phicons“ abgebildet und sind im Wesent-
lichen phyischen Objekte, die Information repräsentieren.
• Menüs werden durch „Trays“ repräsentiert, in denen Phicons an unterschiedlichen
Stellen abgelegt werden können, wobei jeweils eine spezifische Operation an die
Ablageposition gebunden ist.
• Handles (Elemente zur Manipulation von GUI-Objekten) werden durch „Phandles“
abgebildet. Dies sind im Wesentlichen Phicons, die zur Eigabe von Information
verwendet werden können.
• Widgets (Kontroll- und Steuerelemente) werden durch „Instruments“ abgebildet,
welche Phicons sind, die zur Steuerung der jeweiligen Applikation dienen.
Ohne hier weiter auf die Beispiele der Autoren einzugehen, ist doch das den Proto-
typen zugrunde liegende Designkonzept erwähnenswert, etablierte Metaphern aus der
realen oder digitalen Welt für die Benutzerinteraktion zu verwenden. In der Diskussion
ihrer Ergebnisse identifizieren die Autoren die Thematik der Metaphern, die die Brücke
zwischen realer und virtueller Welt schlagen, als eine der interessantesten offenen Fra-
gen für weitere Forschung auf dem Gebiet. Als Schlussfolgerung ihrer Erfahrungen mit
den erstellten Prototypen schlagen sie außerdem vor „optischen“ Metaphern besondere
Aufmerksamkeit zu schenken, da diese für den Brückenschlag besonders geeignet sind.
Als optische Metaphern verwenden die Autoren vor allem Beleuchtung, Schattenwurf
und Linsen. Sie bilden diese realen Phänomene auf die Schnittstelle zwischen digitaler
und realer Welt ab, so dass z.B. digitale Beleuchtung Information sichtbar macht, die
in „unbeleuchteten“ Gebieten fehlt, dass reale Objekte digitale Schatten werfen können
und so zusätzliche Information transportieren oder dass eine digitale Linse verwendet
wird, um reale Objekt „näher“ zu betrachten und Zusatzinformation einzublenden. Bei
der Verwendung von Methaphern wird darauf hingewiesen, dass es wichtig ist, auf ein
realitätsgetreues Verhalten der digital augmentierten Artefakte zu achten um eine naht-
lose Integration der digitalen Information in die reale Welt zu ermöglichen.
4Graphical User Interface
5dies stellt im Übrigen die historisch erste Erwähnung des Begriffs „Tangible User Interface“ dar
136
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Kategorien Interactive Surfaces, Coupling Bits and Atoms, Ambient
Media (Einordnung nach Anwendungsfall)
Konzepte Lenses, Phicons, Tray, Phandles, Instruments
Eigenschaften —
PD-Brücke zentraler Aspekt: Verwendung etablierter Metaphern
6.4.4. Containers, Tokens und Tools
Holmquist et al. (1999) legen ihre Arbeit als konzeptuelle Betrachtung von interaktiven
Systemen an, in denen physische Objekte verwendet werden, um auf digitale Informa-
tion zuzugreifen bzw. diese zu manipulieren. Das Einteilungsschema, das die Autoren
vorschlagen, basiert auf der Art und Weise, in der Information an diese physischen Ob-
jekte gebunden ist. Grundsätzlich unterschieden sie zwischen Containern, Tokens und
Tools. Eine exakte Abgrenzung bzw. eindeutige Zuordnung zu einer Kategorie ist dabei
nicht immer möglich oder sinnvoll.
Der hier vorgestellte Ansatz fokussiert auf die physische Interaktion als Eingabeme-
dium, auf den Aspekt der Informationsausgabe wird nicht eingegangen. Dies ist für das
Verständnis der folgenden Beschreibungen im Kontext der späteren historischen Ent-
wicklung wichtig und muss bei der Anwendung dieses Ansatzes berücksichtigt werden.
Containers
Als Container werden all jene Objekte bezeichnet, an die beliebige digitale Information
gebunden werden kann. Ein Container ist also ein unspezifisches physisches Objekt in
einem Tangible User Interface. Sein Aussehen oder andere physische Eigenschaften lassen
keine Aussage über die Art der angebundenen Information bzw. die Information selbst
zu.
Beliebige physische Objekte können als Container agieren, sofern sie die Möglichkeit
bieten Information in bzw. auf ihnen abzulegen oder wenn sie durch eine Infrastruktur
eindeutig identifizierbar sind, so dass Information an sie gebunden werden kann. Contai-
ner agieren somit ausschließlich als physische Informationsträger und können verwendet
werden um Information zwischen Systemen zu transportieren.
Ein typisches Beispiel ist die Verwendung eines Füllfederhalters als Container, an den
beliebige Information gebunden werden kann, um diese von einem Ort zum anderen
transportieren zu können. Der Füllfederhalter steht in keinem direkten Zusammenhang
mit der angebundenen Information, aus seinem Erscheinungsbild oder seinen Eigenschaf-
ten kann nicht auf die angebundene Information geschlossen werden.
137
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Tokens
Tokens sind physische Objekte, deren äußeres Erscheinungsbild bzw. deren Eigenschaf-
ten in irgendeiner Weise mit der durch sie repräsentierten Information zusammenhängen.
Das physische Objekt und die angebundene Information sind nicht mehr voneinander un-
abhängig, sondern stehen in einem konzeptuellen Zusammenhang. Die äußere Form oder
andere physische Eigenschaften dienen of als Hinweis auf die angebundenen Informati-
onsart oder stehen sogar in Zusammenhang mit der konkret angebundenen Information.
Ein typisches Beispiel für ein Token ist ein Buch, an das über eine eindeutige Identifi-
kation (etwa ein RFID6-Tag) der jeweilige Text oder Zusatzmaterial gebunden wird. Das
physische Buch steht dabei in direktem Zusammenhang mit der angebundenen digitalen
Information.
Tools
Tools sind physische Elemente, die nicht Information, sondern Funktionen repräsentie-
ren. Die Anwendung von Tools hat dabei nicht unbedingt physische Auswirkungen, jene
digitalen, virtuellen Objekte, auf die das Tool angewandt wird, werden aber entsprechend
der Funktion des Tools manipuliert.
Beispiele für Tools sind physische Objekte, die zur Auswahl digitaler Objekte dienen
oder Objekte wie Linsen, deren Anwendung zusätzliche Information zu anderen Contai-
nern oder Tokens abruft.
Zugriff auf und Interaktion mit Tokens und Containern
Der Zugriff auf die Information, die an ein Token oder einen Container gebunden ist,
erfolgt über Information Faucets (also „Informations-Zapfhähne“ oder „-Armaturen“).
Diese Faucets sind aktive Komponenten (im Gegensatz zu Tokens und Containern, die
im Allgemeinen passive Komponenten sind, also keine dedizierte Elektronik enthalten).
Deren Aufgabe besteht darin, aus Tokens oder Containern, die in deren Reichweite ge-
langen, die angebundene Information zu extrahieren und auszugeben. Faucets können
auch dazu verwendet werden, den Zugriff auf Information einzuschränken. So kann die
Ausgabe von Information an eine bestimmte Kombination von Tokens oder Containern
gebunden werden oder von einem bestimmten Aufenthaltsort abhängig gemacht werden.
Die Anbindung von Information an ein Token oder einen Container kann ebenfalls
eingeschränkt sein, bzw. ist im Fall von Tokens per Definition durch den notwendigen
Zusammenhang zwischen physischem Element und Information eingeschränkt. Neben
dieser konzeptuell notwendigen Einschränkung können auch weitere Regeln geprüft wer-
den oder z.B. die Bindung zwischen Objekt und Information statisch (d.h. unveränder-
6Radio Frequency Identification
138
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
bar) gespeichert werden.
Kategorien —
Konzepte Container, Token, Tool, Faucet
Eigenschaften —
PD-Brücke Zugriff auf an physische Elemente gebundene Informa-
tion nur via Faucets, kein direkter Zugriff vorgesehen
6.4.5. Tangible Objects Meaning
Im Rahmen der Entwicklung einer „Interactive Surface“ zur Stadtplanung („Urp“) stel-
len Underkoffler und Ishii (1999) ein Kontinuum von möglichen Bedeutungen bzw. Ver-
wendungszwecken der physischen Objekte eines TUI vor. Die Ausprägungen auf der
Achse unterscheiden sich in der Stärke der Abstraktion der verwendeten Objekte von
ihren Gegenstücken in der realen Welt. Im Zentrum der Achse stehen nicht abstrahierte
Objekte, die in Struktur und Verhalten ihren realen Entsprechungen ähneln.
Abbildung 6.3.: Bedeutung von Objekten in TUIs (adaptiert übernommen aus (Under-
koffler und Ishii, 1999))
Object as noun Derartige Objekte sind Platzhalter für Objekte der realen Welt, denen
sie in Form und Verhalten weitgehend entsprechen. Sie stehen für das reale Objekt
und werden in dessen Sinne verwendet.
Object as verb Die Bedeutung betreffender Objekte reduziert sich auf deren Funktio-
nalität, die Objekte sind nicht mehr Teil der Repräsentation des Systemzustandes
sondern werden dazu verwendet, diesen (entsprechend ihrer Funktion) zu verän-
dern.
Object as reconfigurable tool Das Objekt wird funktional vollständig von seiner ei-
gentlichen Natur abstrahiert verwendet. Die physischen Eigenschafen stehen nicht
mehr in Beziehung zu seiner Verwendung zur Manipulation des Systemzustandes.
Die Funktionalität ist dynamisch zuweis- bzw. auswählbar.
139
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Object as attribute Objekte werden auf eine ihrer Eigenschaften reduziert. Nur diese
wird verwendet, um den Systemzustand abzubilden. Mögliche Eigenschaften sind
z.B. Form, Farbe oder Gewicht des Objekts.
Object as pure Object Das Objekt wird zum reinen Informationsträger, bei dem die
Information nicht in Bezug zur physischen Form oder den Eigenschaften des Ob-
jekts steht.
Die Achse ist dabei als konzeptueller Ring zu verstehen, der sich an den beiden Enden
wieder schließt. Einem Objekt, dessen physischen Eigenenschaften keine Rolle im TUI
mehr spielen, kann beliebig Inhalt oder Funktionalität zugewiesen werden, wodurch die
Grenze zwischen linkem und rechtem Ende der Achse verschwimmt.
Kategorien —
Konzepte Object as pure object, Object as attribute, Object as
noun, Object as verb, Object as reconfigurable tool
Eigenschaften —
PD-Brücke abhängig von der Art der Tokens
6.4.6. Das MCRpd Interaktions-Modell
Basierend auf früheren Arbeiten (siehe Abschnitt 6.4.3) entwickeln Ullmer und Ishii
(2000) ein Modell zur Beschreibung der Interaktion mit Tangible User Interfaces. Es
handelt sich bei dieser Arbeit um den ersten Ansatz, der sich diesem Bereich aus Sicht
der Systemstruktur nähert und nicht ausschließlich eine reine Klassifikation nach be-
stimmten Merkmalen eines Systems vornimmt.
Die Autoren grenzen TUIs von GUIs insofern ab, als das TUIs über eine nahtlose In-
tegration zwischen Repräsentation des Systemzustandes und dessen Kontrolle aufweisen
(im Gegensatz zu GUIs, bei denen der Systemzustand über einen graphischen Kanal
ausgegeben wird und über andere Kanäle, etwa Tastatur und Maus, kontrolliert wird).
Mit der Forderung nach nahtloser Integration von Repräsentation und Kontrolle – also
im Wesentlichen einer Einheit von Eingabe- und Ausgabe-Kanälen – wird ein eher strik-
tes Verständnis von TUIs vorgeschlagen. Als Tangible User Interface kann ein System
demnach nur bezeichnet werden, wenn es Ein- und Ausgabe kohärent über einen Kanal
führt.
Diese Verständnis setzten die Autoren in der Folge in einem Interaktionsmodell für
TUIs um, dass die Struktur eines Tangible User Interfaces konzeptuell beschreibt. Das
Modell wird dabei analog zum MVC7-Modell konzipiert, in dem „View“ und „Control-
ler“ strikt getrennt betrachtet werden. Entsprechend der engeren Kopplung zwischen
7Model-View-Controller
140
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Abbildung 6.4.: Interaktionsmodelle für GUI und TUI (übernommen von Ullmer und
Ishii (2000))
Repräsentation und Kontrolle wird die Bezeichnung MCRpd8-Modell vorgeschlagen (sie-
he Abbildung 6.4). Anhand der Gegenüberstellung zwischen MVC- und MCRpd-Modell
wird die Unterscheidung zwischen GUI und TUI deutlich. Beiden Ansätzen ist gemein,
dass der Systemzustand im Rechner durch ein Model dargestellt wird. Unterschiede zei-
gen sich in der Art der Manipulation und Manifestation dieses Models. Bei GUIs ist
Eingabe und Ausgabe strikt getrennt. Die Manipulation des Systemzustandes erfolgt
durch die Komponente Control, in der physische Kontrollgeräte eine Veränderung des
Zustandes erlauben. Die Kontrollgeräte sind dabei im Allgemeinen generisch, d.h. un-
abhängig vom konkreten Anwendungsfall (also etwa Maus oder Tastatur). Erst durch
digitale Kontroll-Elemente wird die Ein- und Ausgabe applikationsspezifisch angepasst.
Die Ausgabe erfolgt durch die Komponente View, wobei auch in diesem Fall ein generi-
sches Ausgabegerät (etwa ein Bildschirm) verwendet wird. Im Falle eines TUI existiert
keine Trennung zwischen Ein- und Ausgabe. Das Model manifestiert sich durch eine
Representation in der realen Welt. Diese Representation hat eine physische Komponen-
te (REP-P) und eine digitale Komponente (REP-D), die miteinander verknüpft sind.
Die digitale Komponente der Repräsentation umfasst dabei all jene Information, die
nicht durch physische, berührbare Elemente dargestellte wird (etwa Projektion, Audio,
. . . ). Sie steht dabei jedoch nicht für sich selbst sondern ist immer von eine physischen
Repräsentations-Komponente abhängig bzw. dieser zugeordnet. Die physischen Kompo-
nenten (REP-P) spielen insofern eine zentrale Rolle, als dass ihnen auch die Control
zugeordnet ist und über sie damit der Systemzustand manipuliert werden kann. Die
physischen Komponenten des Ausgabe-Kanals fungieren also zugleich als Instanzen des
Eingabe-Kanals.
Basierend auf diesem Ansatz identifizieren die Autoren vier Kern-Charakteristika von
Tangible User Interfaces, die sich jeweils an den physischen Komponenten zeigen:
8Model-Control-Representation (physical and digital)
141
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
• Physikalische Repräsentationen sind mit digitaler Information gekoppelt
• Physikalische Repräsentationen enthalten Mechanismen zur Kontrolle des Systems
• Physikalische Repräsentationen sind in der Wahrnehmung der Benutzer mit digi-
talen Repräsentationen gekoppelt
• Der physische Zustand eines Tangible Interfaces stellt die Kernaspekt des System-
zustandes dar
Aufbauend auf diesen Eigenschaften entwickeln die Autoren in der Folge ein Schema,
das unterschiedliche Ansätze bei der Konzeption eines Tangible Interfaces abdeckt. Als
zentrale Ansätze werden „spatial“ (räumliche), „relational“ (relationale) und „construc-
tive“ (konstruierende) Ansätze unterschieden. Räumliche Ansätze nutzen die Anordnung
der physischen Elemente in einem Referenzrahmen um den Systemzustand zu repräsen-
tieren bzw. zu manipulieren. Bei relationalen Ansätzen ist die räumliche Anordnung
unwesentlich, lediglich die Beziehungen zwischen den Elementen codieren den System-
zustand. Konstruierende Ansätze sind zwischen den beiden erstgenannten Ansätzen ein-
zuordnen, da sie Beziehungen zwischen Elementen durch eine räumliche Anordnung der
Elemente zueinander abbilden. Systeme, in denen Information lediglich in der Zuord-
nung zu einem physischen Element codiert wird und nicht in der Beziehung zwischen
den Elementen, werden in die Kategorie der „associative“ (assoziativen) Ansätze einge-
ordnet.
Als zusätzliche Gestaltungsdimension führen die Autoren die Konzeption der physi-
schen Repräsentationen an, die bereits von Ullmer und Ishii (1997) eingeführt wurde.
Unterschieden wird hier zwischen „iconic“ und „symbolic representations“, wobei ikoni-
sche Elemente einen Bezug zu dem jeweils repräsentierten Objekt der realen Welt haben
(etwa ein Bild einer Person), während diese Möglichkeit der Zuordnung bei symboli-
schen Elementen nicht gegeben ist (etwa bei der Repräsentation einer Person durch ein
rotes Rechteck). Aus einer umfassenden Betrachtung der zum Zeitpunkt der Erstellung
des Artikels verfügbaren Tangible User Interfaces schließen die Autoren, dass ikonische
Repräsentationen vorrangig in räumlichen und assoziativen Ansätzen zum Einsatz kom-
men, während symbolische Repräsentationen eher bei relationen oder konstruierenden
Ansätzen anzutreffen sind.
Kategorien spatial, relational, constructive, associative (Einordnung
nach Art der Informationsrepräsentation)
Konzepte Model, Rep-P, Rep-D, Control
Eigenschaften Rep-P: iconic, symbolic
PD-Brücke Informationsrepräsentation immer an ein physisches Ob-
jekt gebunden. Manipulation der Information erfolgt
mittels dem gleichen Objekt
142
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
6.4.7. Tokens und Constraints nach Ullmer
Der Token+Constraint-Ansatz wurde von Ullmer (2002) erstmals vorgestellt und Ullmer
et al. (2005) aktualisiert veröffentlicht. Ullmer et al. gehen dabei erstmals von dem
Grundsatz aus, dass ein TUI zwei grundlegende Arten von physischen Komponenten
enthält: Objekte, die digitale Information repräsentieren und Objekte, die die Interaktion
mit Computersystemen bzw. die Manipulation des Systemzustands ermöglichen.
In ihren weiteren Ausführungen identifizieren die Autoren zwei grundlegende Arten
von TUIs, die sich historisch herausgebildet hätten. Einerseits existieren „interactive
surfaces“, bei denen physische Objekte benutzt werden um Information auf einer aktiven
Oberfläche (zumeist projiziert oder durch einen Bildschirm realisiert) zu manipulieren.
Andererseits werden „constructive assemblies“ genannt, deren physische Objekte ohne
umgebende Infrastruktur ausschließlich durch reale oder logische Verbindungen zwischen
ihnen den Systemzustand ausdrücken. Die Autoren definieren nun eine dritte Art von
Systemen und platzieren diese konzeptuell zwischen den beiden zuvor genannten Kate-
gorien. Mit „tokens and constraints“ werden Systeme mit zwei unterschiedlichen Arten
von physischen Elementen eingeführt. „Tokens“ stehen für Objekte, die digitale Infor-
mation repräsentieren. „Constraints“ werden verwendet um (digitale) Funktionalität auf
diese Tokens anzuwenden (siehe Abbildung 6.5).
Abbildung 6.5.: Arten von Tangible User Interfaces – von links nach rechts: interactive
surfaces, tokens+constraints, constructive assemblies (übernommen aus
Ullmer et al. (2005))
In der Folge beschreiben Ullmer et al. die Details des Tokens+Constraints-Ansatzes.
Sie gehen dabei zuerst auf die Benutzer-Interaktion in einem Tokens+Constrains-basieren
System ein. Diese ist immer in zwei Phasen unterteilt, wobei in der ersten Phase „asso-
ciate“ Tokens einem oder mehreren Constraints zugeordnet werden. In der zweiten Phase
„manipulate“ werden die Tokens im Kontext der Constraints manipuliert, wodurch die
digitalen Daten, die an das Token gebunden sind, geändert werden.
Danach widmen sich die Autoren der Abbildung digitaler Information bzw. deren
Manipulation auf physische Elemente und definieren vier grundlegende Arten von Be-
ziehungen, die Information abbilden sein können:
• die absolute Position eines Tokens in Bezug zu einem Constraint
• die relative Position eines Tokens in Bezug zu einem Constraint
143
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
• die absolute Position eines Tokens in Bezug zu anderen Tokens
• die relative Position eines Tokens in Bezug zu anderen Tokens
Unter „Position“ sind dabei auch andere spatiale Parameter eines Tokens (wie die Ori-
entierung) zu verstehen.
Nach einer Reihe von Betrachtungen der konzeptuellen Hintergründe und Beispie-
len kommen die Autoren zu einem weiteren relevanten Punkt, in dem Sie ausführen,
wie bzw. warum Tangible Interfaces für Benutzer leichter verständlich sein können als
traditionelle GUI-basierte Systeme. Bezugnehmend auf Bellotti et al. (2002) versuchen
Sie Antworten auf fünf von diesen Autoren gestellten Fragen zu finden, die für jede
Benutzungsschnittstelle geklärt werden müssen. An dieser Stelle stehen nun nicht die
Antworten von Ullmer et al. im Mittelpunkt des Interesses, sondern die Fragen, die
einen konzeptuellen Rahmen für das Design einer Benutzungsschnittstelle liefern. Die
Fragen stammen aus der Arbeit von Bellotti et al. (2002):
Address Wie weiß das System, dass Benutzer mit ihm und nicht mit anderen (Systemen
oder Personen) interagiert?
Attention Wie bemerken Benutzer, wenn das System auf eine Interaktionsanforderung
reagiert?
Action Wie weiß das System, welchem Objekt der Befehl der Benutzer gilt?
Alignment Wie wissen Benutzer, dass das System ihren Befehl korrekt verstanden und
ausgeführt hat?
Accident Wie werden Missverständnisse zwischen den Benutzern und dem System auf-
gelöst?
Ullmer et al. beantworten diese Fragen für den Tokens+Constraints-Ansatz jeweils aus
konzeptueller und technologischer Sicht.
Am Ende des Artikels geben die Autoren Varianten des Token+Constraints-Ansatzes
an. Durch die Festlegung auf die notwendige Physikalität von Tokens und Constraints ist
der Design-Raum eingeschränkt, obwohl die konzeptuellen Überlegungen auch breitere
Anwendung finden können. Aus diesem Grund variieren die Autoren ihren Ansatz und
geben Alternativen an, die den Grundüberlegungen entsprechen aber unter Umständen
nicht alle Vorteile des Kernansatzes aufweisen:
• Verwendung von visuellen, graphischen Constraints und physischen Tokens
• Verwendung von physischen Constraints für graphische Token
• Verwendung von physischen Constraints für nicht-massive Tokens (z.B. Flüssigkei-
ten)
• Verwendung von Tokens und Constraints in durch die Benutzer anpassbaren Größen
• Alternative Semantik bei der Abbildung zwischen physischer und digitaler Welt
144
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Abschließend wird betont, dass ausgereifte TUIs selten in „Reinform“ auftreten, d.h.
dass sie nicht exakt einer Kategorie wie „interactive surface“ oder „tokens+constraints“
zugeordnet werden können.
Kategorien interactive surfaces, tokens+constraints, constructive
assemblies
Konzepte Tokens, Constraints
Eigenschaften Token: Form, absolute und relative Position in Bezug zu
Constraints oder anderen Tokens
PD-Brücke Codiert in Tokens und in den Beziehungen zwischen To-
kens und Constraints
6.4.8. Degree of Coherence
Koleva et al. (2003) schlagen ein Framework vor, dass die Klassifikation von Tangible
Interfaces ermöglicht und so das Verständnis der möglichen Verknüpfungen zwischen
physischer und digitaler Welt vertiefen soll. Im Gegensatz zu dem von Ullmer und Ishii
(2000) mit dem MCRpd-Modell vorgeschlagenen relativ strikten Verständnis eines Tan-
gible Interfaces öffnen Koleva et al. den Begriff und definieren eine kontinuierliche Skala
von „Tangibility“, die sich am Grad der „Coherence“ (Kohärenz) zwischen realer und
digitaler Welt bemisst. Hohe Kohärenz sagt dabei aus, dass das physische Objekt und
sein digitales Gegenstück als ein „Ding“ wahrgenommen werden, also nicht voneinander
abgrenzbar sind.
Entlang diesem Kontinuum führen die Autoren Kategorien ein, die die typischen Ei-
genschaften eines Systems im betreffenden Bereich der Skala beschreiben. Diese Kate-
gorien dienen als Einordnungsschema für Elemente von Tangible Interfaces und können
als Grundlage einer Gegenüberstellung unterschiedlicher TUIs bzw. deren Komponenten
dienen. Entlang der Kohärenz-Skala legen die Autoren folgende Kategorien fest, die sich
jeweils auf die Bedeutung des physische Objekt für die Benutzungssschnittstelle beziehen
(beginnend mit niedriger Kohärenz):
General-purpose tool Ein Werkzeug, das zur Manipulation verschiedener digitaler Ob-
jekte benutzt werden kann und dabei unterschiedliche Operationen auf diesen Ob-
jekten auslösen kann.
Specialized tool Ein Werkzeug, das eine bestimmte Operation auslöst, diese aber auf
unterschiedliche digitale Objekte anwenden kann.
Identifier Objekte, die als Referenz auf ein digitales Objekt agieren. Die Referenz ist
nicht zwangsweise permanent, sondern kann unter Umständen dynamisch verän-
dert werden.
145
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Proxy Objekte, die insofern enger an die digitale Information gekoppelt sind als Identi-
fier, als dass durch sie die digitale Information manipuliert und nicht nur abgerufen
werden kann.
Projection Objekte, die so eng an die digitale Repräsentation gebunden sind, dass des-
sen physische Eigenschaft Information direkt repräsentiert und die Existenz der
Information von der Existenz des Objekts abhängig ist.
Illusion of same objects Keine Koppelung im engeren Sinne sondern Identität zwischen
realem Objekt und digitaler Information. Ist dann gegeben, wenn beide Komponen-
ten ausschließlich gemeinsam auftreten oder für Benutzer nahtlos von der digitalen
in die reale Welt und umgekehrt übergehen.
In der Folge detaillieren die Autoren diese Kategorien und identifizieren Eigenschaften,
die eine Verknüpfung zwischen realer und digitaler Welt aufweisen kann und an denen
sich der Grad an Kohärenz bemisst bzw. an denen er sichtbar wird:
Transformation Beschreibt, wie Manipulationen am realen Objekt in die virtuelle Welt
umgesetzt werden. Literal Mediation liegt vor, wenn Manipulationen in realer und
virtueller Welt analog umgesetzt werden (wenn z.B. eine Bewegung eines Objekts
auch in eine Bewegung dessen realer Repräsentation umgesetzt wird). Transfor-
med Mediation liegt vor, wenn eine Manipulation eines realen Objekts eine nicht
unmittelbar assozierbare Reaktion in der digitalen Welt auslöst (bei der Rotation
eines Tokens etwa die Lautstärke eines Audiokanals verändert).
Sensing of Interaction Beschreibt, auf welche Parameter eines Objektes der realenWelt
die digitale Repräsentation reagiert. Die möglichen Ausprägungen reichen von einer
einfachen Reaktion auf die Präsenz eines Objekts bis zur kontinuierlichen Reaktion
auf alle sechs Freiheitsgrade des physischen Objekts.
Configurability of Transformations Gibt an, ob die Transformation, die zwischen phy-
sischem Objekt und digitaler Repräsentation angewandt wird, vorgegeben oder
konfigurierbar ist. Mögliche Ausprägungen sind konfigurierbar und fixiert.
Lifetime of Link Gibt an, ob die Assoziation zwischen physischem Objekt und digita-
ler Repräsentation nach der Kopplung permanent ist oder zur Laufzeit verändert
werden kann. Mögliche Ausprägungen sind temporär und permanent.
Autonomy Beschreibt, ob eine Existenzbeziehung zwischen dem realen Objekt und der
digitalen Repräsentation besteht, ob also die digitale Ressource unabhängig vom
realen Objekt existiert oder bei der Kopplung erzeugt wird. Mögliche Ausprägun-
gen sind autonom und abhängig.
Cardinality of Link Gibt an, ob die Zuordnung zwischen realem Objekt und digitaler
Repräsentation eindeutig ist oder ein mehrdeutige Zuordnung von physischer zu
digitaler Welt oder umgekehrt möglich ist. Die vorrangig auftretende Ausprägung
ist eine eindeutige Abbildung (1:1), aber auch 1:n- oder n:1-Abbildungen sind
möglich (wobei n unbeschränkt oder beschränkt sein kann).
146
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Link Source Gibt an, ob der Gegenstand der Manipulation das physische Objekt oder
die digitale Repräsentation ist. Die digitale Repräsentation ist dann die Quelle
der Kopplung, wenn Änderungen an ihr Auswirkungen auf das physische Objekt
haben.
Das hier vorgestellte Framework stellt erstmals die Art der Verknüpfung zwischen
realer und digitaler Welt in das Zentrum der Betrachtung und klassifiziert Tangible User
Interfaces entlang dieser Dimension. Die Idee der Berücksichtigung dieses Aspektes bei
der Einordnung von TUIs wird später von Fishkin (2004) (siehe Abschnitt 6.4.11) wieder
aufgegriffen und – vereinfacht – in seine mehrdimensionale Taxonomie für Tangible User
Interfaces integriert.
Kategorien —
Konzepte General-purpose tool, specialized Tool, Identifier, Proxy,
Projection, Illusion of same objects
Eigenschaften PD-Brücke: Transformation, Sensing of Interaction,
Configurability of Transformation, Lifetime of Line, Au-
tonomy, Cardinitality of Link
PD-Brücke Zentraler Aspekt: Coherence - Maß für die Enge der
Bindung zwischen physischem Objekt und digitaler In-
formation (kann für die einzelnen Teile eines Systems
unterschiedlich sein)
6.4.9. Tokens und Constraints nach Shaer et al.
Shaer et al. (2004) haben in ihrer Arbeit den Anspruch einen Satz von Konstrukten zu
identifizieren, der eine umfassende Beschreibung der Struktur und Funktionalität von
Tangible User Interfaces ermöglicht. Letztendliches Ziel ist es eine konzeptuelle Basis zu
schaffen, die die Entwicklung eines Software-Toolkits zur Spezifikation, Simulation und
Implementierung von TUIs ermöglicht. Shaer et al. (2004) bauen dabei auf dem „Token
& Constraints“-Ansatz von Ullmer (2002) auf und detaillieren das Constraint-Konzept,
so dass es eine umfassendere Beschreibung eines TUIs erlaubt.
Die grundlegenden Konzepte des Ansatzes orientieren sich an der Annahme, dass die
Struktur und Funktion eines TUI an den Beziehungen zwischen physischen Objekten
und digitaler Information festgemacht werden kann. Diese Konzepte sind im Einzelnen:
Pyfo Ein physisches Objekt, das als Teil eines TUI eingesetzt wird.
Token Ein Pyfo, das digitale Information oder eine Funktion zur Veränderung von In-
formation repräsentiert.
Constraint Ein Pyfo, das das Verhalten des Tokens, dem es zugeordnet ist, einschränkt.
Die physischen Eigenschaften des Constraints weisen auf die Art der Manipulation
147
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
des Tokens und die Interpretation der Kombination zwischen Token und Constraint
hin. Constraints können auf drei Arten einschränkend wirken:
• Die physischen Eigenschaften des Constraints (Form, Material, Orientierung,
. . . ) weisen auf die möglichen und nicht erwünschten Manipulationen des
zugehörigen Tokens hin
• Das Constraint schränkt den physischen Interaktionsraum des Tokens ein
• Das Constraint wirkt als Referenzrahmen für das Token und erlaubt dessen
Interpretation
Variable Digitale Information oder eine Funktion zur Veränderung von Information.
Können für sich existieren oder an ein Pyfo gekoppelt sein und dadurch ein Token
erzeugen.
TAC Ein TAC9 repräsentiert die Beziehung zwischen einem Token, dessen zugeordneter
Variable und einem oder mehreren Constraints. TACs legen fest, wie Benutzer mit
dem System interagieren können.
Basierend auf diesen Konzepten werden fünf Kerneigenschaften identifiziert, die ein
Tangible User Interface bzw. dessen Elemente aufweisen können. Diese Kerneigenschaf-
ten sind:
Couple Ein Pyfo muss an eine Variable gekoppelt sein um als Token zu gelten.
Relative Definition Jedes Pyfo muss ein Token, ein Constraint oder beides sein.
Association Ein TAC bildet sich aus der physischen Zuordnung eines Tokens zu einem
Constraint. Dem TAC können weitere Constraints zugeordnet werden.
Computational Interpretation Physische Manipulation eines Tokens hat eine eindeutig
interpretierbare Auswirkung auf die digitale Welt.
Manipulation Jedes TAC kann in der physischen Welt diskret, kontinuierlich oder auf
beide Arten manipuliert werden. Das Constraint legt die möglichen Arten der
Manipulation fest.
Zur Spezifikation eines Tangible User Interfaces werden nun diese Konzepte zur An-
wendung gebracht, um sowohl Struktur als auch Verhalten des TUI festzulegen. Bei der
Spezifikation werden die TACs definiert, indem auf Seite der Struktur das betroffene
Token und die zugehörigen Constraints angeführt werden. Zur Spezifikation des Verhal-
tens wird die betroffene Variable, die Aktion, die in der physischen Welt ausgeführt wird
und die zu erwartende Reaktion des Systems angeführt.
9Token and Constraint
148
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Kategorien —
Konzepte Pyfo, Token, Constraint, Variable, TAC
Eigenschaften Couple, Relative Definition, Association, Computational
Interpretation, Manipulation
PD-Brücke Variables (Elemente der digitalenWelt) machen ein Pyfo
(Objekt der realen Welt) zu einem Token
6.4.10. Kategorien von TUI-Anwendungen
Auf Basis einer umfassenden Literaturrecherche im Bereich von interaktiven Systemen,
bei denen physische Objekte zur Interaktion und Informationseingabe benutzt werden,
identifizieren Klemmer et al. (2004) vier Kategorien von Ansätzen, die bei der Umsetzung
eines TUI verfolgt werden können.
Spatial Applications Applikationen, bei denen die Interaktion auf einer beliebigen Ober-
fläche (Wände, Tische, Whiteboard, . . . ) abgewickelt wird und Information über
diese Oberfläche dargestellt und manipuliert werden kann. Dazu gehören auch
Systeme, die ohne physische Elemente (außer der Oberfläche) arbeiten.
Topological Applications Applikationen, bei denen die Kontrolle des Systems über die
Herstellung von Beziehungen zwischen physischen Objekten durchgeführt wird.
Associative Applications Applikationen, bei denen physische Objekte als Referenz auf
digitale Information fungieren und diese durch Interaktion mit einer Hintergrund-
Infrastruktur abgerufen werden kann.
Forms Applikationen, bei denen papierbasierte Interaktionen zu einem bestimmten Zeit-
punkt (nicht kontinuierlich) in die digitale Welt übernommen werden (z.B. durch
Scannen und OCR10-Verarbeitung).
Die Autoren gehen nicht weiter ins Detail und verzichten auf eine Betrachtung der
unterschiedlichen Eigenschaften des Systems. Sie geben lediglich an, dass die meisten
der betrachteten Applikationen Gemeinsamkeiten über die Grenzen der Applikations-
kategorien hinweg aufweisen. Dies umfasst die Tatsache, dass das vorherrschende Sys-
temdesign die Verbindung zwischen physikalischer (tangibler) Eingabe und graphischer
Ausgabe ist. Die graphische Ausgabe erfolgt dabei entweder kohärent mit der Eingabe
(auf der gleichen Oberfläche), auf einem separaten Bildschirm, der sich aber nahe dem
Eingabemedium befindet oder entfernt auf von den eingebenden Benutzern nicht unmit-
telbar zugreifbaren Ausgabemedien. Interfaces, die die Ausgabe auf andere Arten (z.B.
haptisch) gestalten, werden von den Autoren explizit vernachlässigt, da sie für die eigene
Forschung keine Relevanz haben.
10Optical Character Recognition
149
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Kategorien Spatial, Topological, Associative, Forms
Konzepte —
Eigenschaften —
PD-Brücke —
6.4.11. Taxonomie für Tangible User Interfaces
Fishkin (2004) versucht in seiner Arbeit, den Begriff des Tangible User Interfaces zu
definieren und ein Kategorienschema zu schaffen, in das sich auf tangibler Interaktion
basierende Systeme einordnen lassen. Sein Ziel ist es, ein Framework zur Verfügung zu
stellen, auf Basis dessen sich Systeme vergleichen lassen und das das Design von Tangible
Interfaces unterstützen kann.
Fishkin fasst den Begriff des Tangible Interfaces sehr breit und definiert ein Interaktives
System mit tangiblem Interface als eines, in dem die Eingabe über die Manipulation (im
wörtlichen Sinn, also mit den Händen) von phyischen Objekten vorgenommen wird und
die Ausgabe die physische Natur eines Objektes verändert. Diese Definition umfasst auch
Systeme mit „herkömmlichen“ Interfaces.
Nach dieser umfassenden Definition strukturiert Fishkin den Raum möglicher Tangi-
ble Interfaces durch die Einführung zweier Analysedimensionen, anhand derer er seine
Taxonomie aufspannt. Diese beiden Dimensionen sind „Embodiment“ und „Metaphor“,
die orthogonal zueinander stehen. Hohe Werte dieser beiden Dimensionen bezeichnen
„tangiblere“ Systeme. „Hohe Tangibilität“ ist jedoch kein Qualitätskriterium, sondern
lediglich eine Eigenschaft, die ein System für einen bestimmten Anwendungsfall besser
oder schlechter geeignet machen kann.
Embodiment
Die Dimension „Embodiment“ beschreibt, wie eng die Eingabe am Interface mit der
Ausgabe gekoppelt ist. Das Kriterium zu Einordnung ist hier der Ort der Wahrnehm-
barkeit des Systemzustandes und der Systemaktivität. Je kohärenter die Ausgabe- und
Eingabe-Kanäle sind – je näher sich also die Informationsausgabe bei der Eingabe befin-
det – desto höher ist die Ausprägung dieser Dimension. Fishkin unterscheidet hier vier
Ausprägungen:
Full Bei „full Embodiment“ ist das Ausgabegerät gleichzeitig das Eingabegerät. Der
Zustand des Geräts ist direkt in seinen physischen Eigenschaften abgebildet.
Nearby „nearby Embodiment“ tritt auf, wenn die Ausgabe nahe dem Eingabeobjekt
auftritt und eng an dieses gebunden ist, also in direktem, unmittelbaren Zusam-
menhang steht.
150
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Environmental „environmental Embodiment“ ist gegeben, wenn die Ausgabe im unmit-
telbaren Umfeld des auftritt aber sich nicht unmittelbar am tangiblen Eingabeob-
jekt manifestiert. Typische Vertreter dieser Ausprägung sind akustische Ausgabe-
kanäle.
Distant Von „distant Embodiment“ spricht man, wenn Ein- und Ausgabekanäle voll-
ständig räumlich entkoppelt sind, der Fokus der Aufmerksamkeit der Benutzer also
nicht gleichzeitig auf Ein- und Ausgabekanal liegen kann.
Metaphor
Die Dimension „Metaphor“ bildet die Eigenschaft von Tangible Interfaces ab, auf eine
Benutzerinteraktion so zu reagieren, wie die reale Welt auf eine entsprechende Aktion
reagiert. Die Ausprägung in „Metaphor“ ist also dann hoch, wenn das System analog
zu realem, physikalisch begründbarem Verhalten reagiert. Hier sind grundsätzlich zwei
Kategorien zu unterscheiden, in denen der Bezugspunkt der „Methaphor“ verschieden
ist. „Metaphor“ kann sich entweder auf das Aussehen des jeweiligen Objektes beziehen
oder auf die Bewegung des Objektes Bezug nehmen. Im ersten Fall spricht Fishkin von
„Metaphor of Noun“, im zweiten Fall von „Metaphor of Verb“. Die Ausprägungen auf
der „Metaphor“-Dimension gruppieren sich dann wie Folgt:
None Die Interface-Objekte zeigen weder in Form noch Funktion eine Analogie zur
Realität
Noun Diese Analogie ist gegeben, wenn am Interface Objekte existieren, die eine reale
Entsprechung haben, aber nicht wie diese manipuliert werden können. Ein klas-
sisches Beispiel aus traditionellen interaktiven Systemen ist die „Fenster“- oder
„Schreibtisch“-Metapher (sind analog zu realen Fenstern bzw. Schreibtischen aus-
gelegt, bieten aber andere Interaktionsmöglichkeiten). Bei Tangible User Interfaces
ist diese Zuordnung dann gegeben, wenn ein Eingabeobjekt so aussieht wie ein Ob-
jekt der realen Welt, aber keine weiteren Eigenschaften mit diesem teilt.
Verb Eine Zuordung zu dieser Kategorie erfolgt, wenn die Interaktion mit einem Objekt
eine reale Entsprechung hat, dieses jedoch selbst keine Analogie zur realen Welt
bildet. Diese Ausprägung tritt bei TUIs unter anderem bei Gestensteuerung von
Systemen auf.
Noun and Verb Hier hat das betreffende Objekt selbst eine Entsprechung in der realen
Welt und auch dessen Verwendung ist analog zu jener der realen Entsprechung.
Die Objekte sind dennoch nach wie vor unterschiedlich, das reale Objekt kann
nicht im Tangible Interface eingesetzt werden, umgekehrt bietet das TUI-Objekt
nicht die reale Funktionalität des realen Objektes.
Full In der höchsten Ausprägung existiert kein Unterschied zwischen TUI-Objekt und
realem Objekt - es gibt keine Analogie mehr, weil die Objekte identisch sind.
151
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Dieser Zustand ist erreicht, wenn Benutzer das TUI-Objekt manipulieren und sich
die reale Welt entsprechend verändert. Beispiele für Systeme auf dieser Stufe sind
zum Beispiel digital augmentierte Whiteboards, wo mit elektronischen Markern
auf eine Oberfläche „geschrieben“ wird, wobei die hinterlassene „Tinte“ simultan
projiziert wird.
Anwendung der Taxonomie
Fishkin wendet seine Taxonomie auf die oben bereits beschriebenen Ansätze von (Holm-
quist et al., 1999) und (Underkoffler und Ishii, 1999) an und zeigt, dass sich diese einord-
nen lassen. Er ordnet nach einer umfassenden Literaturstudie außerdem über 60 konkrete
Tangible Interfaces in seine Taxonomie ein und stellt diese anhand deren Ausprägungen
gegenüber. Ein offener Punkt ist die Verbindung zum MCRpd-Framework (Ullmer und
Ishii, 2000), das Fishkin als komplementär bezeichnet und das auf einer anderen Abs-
traktionsstufe operiere.
Kategorien —
Konzepte —
Eigenschaften Embodiment: full, nearby, environmental, distant, Me-
taphor: none, noun, verb, noun and verb, full
PD-Brücke wird in Struktur und Verhalten durch die Ausprägungen
auf den beiden Dimensionen der Taxonomie charakteri-
siert (kann für die einzelnen Teile eines Systems unter-
schiedlich sein)
6.4.12. Tangible Bits: Beyond Pixels
Ishii (2008) fasst die bisherige Entwicklung des Forschungsgebiets der Tangible User In-
terfaces zusammen und schlägt konzeptuell die Brücke von den wegweisenden Tangible
Bits-Arbeiten über das MCRpd-Interaktions-Modell bis hin zu heute aktuellen Katego-
rien von Tangible User Interfaces.
Die Grundlage der Betrachtungen ist das in (Ullmer und Ishii, 2000) MCRpd-Interaktions-
Modell, das hier (und bereits in (Ullmer et al., 2005)) als MCRit11-Modell bezeichnet
wird. (wobei „it“ für „intangible“ und „tangible“ steht und „pd“ für „physical“ und „di-
gital“ aus der ursprünglichen Abkürzung ersetzt). Basierend auf der Trennung zwischen
Input und Output eines interaktiven Systems (oder Control und Representation) und der
auf dieser Trennung aufbauenden Abgrenzung zur GUIs, wird die Struktur eine TUI so
konzeptualisiert, das eben diese Trennung nicht mehr vorhanden ist. Die grundlegenden
Komponenten des MCRit-Modells sind (angelehnt an das MCRpd-Modell) die digitale
11Model-Control-Representation (intangible and tangible)
152
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Information, die repräsentiert und manipuliert werden muss, sowie die tangible Reprä-
sentation des Systemzustandes (siehe Abbildung 6.6). An die tangible Repräsentation
sind die Eingabekanäle des Systems – die Control-Elemente – gekoppelt. Die tangible
Repräsentation wird durch die intangible Repräsentation ergänzt, mittels der zusätz-
liche, dynamisch veränderliche Information abhängig vom Systemzustand ausgegeben
werden kann.
Abbildung 6.6.: Überblick über das MCRit-Modell (entnommen aus Ishii (2008))
Basierend auf der konzeptuellen Grundlage gibt Ishii die grundlegenden Eigenschaften
von TUIs an:
Computational Coupling of tangible representations to underlying digital information
and computation. Der zentrale Aspekt jedes TUI ist die Kopplung von realen Ar-
tefakten mit digitaler Information und diese Information manipulierende Funktio-
nen. Zu berücksichtigen ist dabei die Art der Abbildung, also welche Prinzipien der
Übersetzung und welche Metaphern (bei Ishii: „Embodiment“) verwendet werden.
Embodiment of mechanisms for interactive control with tangible representations. In
TUIs werden die physischen Repräsentationen des Systemzustandes gleichzeitig
auch zur Steuerung des Systems verwendet. Von Interesse sind hier die Fähigkeiten
des Tangibles selbst (“inert“, also passive Objekt, die durch Benutzer manipuliert
werden müssen oder „actuated“, also aktive Elemente, die selbständig Änderungen
des Systemzustandes ausgeben können), die Beschränkung des Interaktionsraums
(“unconstrainted“ – unbeschränkt, „weakly constrainted“ – nur schwach einge-
schränkt, wie bei der Interaktion auf Oberflächen, oder „tightly constrainted“ –
stark eingeschränkt, z.B. bei Tokens, die nur entlang einer Achse bewegt werden
153
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
können) sowie die durch die physische Form der Tokens und die Constraints vor-
gegebenen bzw. angedeuteten Interaktionen und deren Kohärenz mit der dadurch
manipulierten digitalen Information.
Perceptual Coupling of tangible representations to dynamic intangible representations.
Die wahrgenommene Koppelung zwischen dem physischen Anteil des Systemzu-
standes und dem intangiblen (z.B. projizierten oder akustischen) Anteil ist der
dritte wichtige Aspekt, der beim Design von Tangible Interfaces zu berücksich-
tigen ist. Der kritische Faktor ist dabei nach Ishii die Reaktion des intangiblen
Anteil auf Änderung des tangiblen Anteils in Echtzeit. Zwischen der Manipulation
von physischen Elementen und eine adäquaten Reaktion des Systems, die sich auch
auf die intangible Repräsentation auswirkt, darf nur minimale, idealerweise nicht
als solche wahrgenommene Verzögerung liegen.
Je nach Ausprägung dieser Eigenschaften können sich TUIs in unterschiedliche Kate-
gorien von Systemen manifestieren. Basierend auf den bereits von Ullmer et al. (2005)
angegebenen Kategorien (siehe Abschnitt 6.4.7) erweitert Ishii das Schema und identi-
fiziert acht Kategorien von TUIs:
Tangible Telepresence Systeme, bei denen entfernte physische Objekte digital mitein-
ander gekoppelt werden, so dass Manipulationen eines Objekts an den gekoppelten
Objekten physisches Feedback auslösen können. Durch die Koppelung zwischen
entfernter Ein- und Ausgabe können Präsenz-Aspekte auch in dissoziierten An-
wendungsfällen übermittelt werden.
Tangibles with kinetic Memory Systeme, die Manipulation physischer Objekte auf-
nehmen und diese Manipulationen auch wieder physisch wiedergeben können.
Constructive Assembly Entspricht der von Ullmer et al. (2005) angegebenen Kate-
gorie und umfasst Systeme, bei denen der Systemzustand durch die (physische)
Verknüpfung von physischen Elementen repräsentiert und manipuliert wird.
Tokens and Constraints Entspricht der von Ullmer et al. (2005) angegebenen Katego-
rie und umfasst Systeme, die informationstragende physische Elemente zur Reprä-
sentation des Systemzustandes benutzen und die möglichen Interaktionen mittels
ebenfalls physischer Constraints beschränken bzw. vorgeben.
Interactive Surfaces – Tabletop UI Entspricht der von Ullmer et al. (2005) angegebe-
nen Kategorie und umfasst Systeme, bei denen physische Objekte auf einer Ober-
fläche manipuliert werden, um den Systemzustand zu verändern. Dabei wird meist
zusätzlich visuelles Feedback auf der Oberfläche ausgegeben, wodurch Eingabe-
und Ausgabemedium kohärent sind.
Continuous Plastic TUI Umfasst Systeme, die in der Lage sind, die äußere Form ihrer
physischen Repräsentationen zu verändern bzw. auf derartige Formänderungen mit
Änderungen des Systemzustandes reagieren.
154
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Augmented Everyday Objects Systeme, bei denen physische Objekte des Alltagslebens
mit Technologie ausgestattet werden, die einen wie auch immer gearteten Mehrwert
bei der Benutzung bieten kann.
Ambient Media Systeme, bei denen interaktive Systeme durch Zusatzinformation er-
gänzt werden, die nicht von der eigentlichen Arbeitsaufgabe ablenken. Im engeren
Sinne handelt es sich dabei nach Ishii nicht um ein TUI, die Kategorie hat aber
insofern Relevanz, als dass nicht die herkömmlichen Ausgabekanäle (wie Bildschir-
me) benutzt werden um digitale Information zu repräsentieren.
Grundlegend gemein sind jedoch allen Arten von Systemen ein Satz von Merkmalen,
die sie in ihrer Eigenschaft als TUIs mitbringen und die sich dem Autor zufolge durchwegs
vorteilhaft auf die Interaktion mit den Benutzern auswirken können:
Double Interaction Loop – Immediate Tactile Feedback Tangible User Interfaces ver-
fügen inhärent über zwei Feedbackschleifen, über die den Benutzern Reaktionen auf
deren Eingaben rückgespiegelt werden. Die erste, unmittelbare, Feedback-Schleife
ist die haptische Erfahrung bei der Manipulation der physischen Element. Die Re-
aktion ist sofort sichtbar und muss nicht durch das System erfasst, interpretiert und
ausgegeben werden. Die zweite Schleife wird über die intangible Repräsentation des
Systemzustands realisiert, auf der sich ebenfalls Reaktionen auf Benutzereingaben
manifestieren. Dabei muss die Benutzerinteraktion jedoch erfasst und interpretiert
werden, bevor eine adäquate Reaktion erstellt und ausgegeben werden kann. Diese
Reaktion kann umfassender als in der ersten Schleife ausfallen, benötigt jedoch
mehr Zeit.
Persistency of Tangibles Bei TUIs wird ein wesentlicher Anteil des Systemzustandes
durch die Konfiguration des physischen Elemente dargestellt. Diese sind ihrer Na-
tur nach persistent, repräsentieren diesen Anteil des Systemzustandes also unab-
hängig von etwaiger Infrastruktur und sind auch verfügbar, wenn diese abgeschaltet
ist.
Coincidence of Input and Output Spaces Ein grundlegendes Designkriterium von TUIs
ist die Kohärenz (bei Ishii: Koinzidenz) von Eingabe- und Ausgabekanälen. Dies er-
möglicht eine nahtlose Interaktion und Informationsrepräsentation im physischen
und digitalen Raum.
Special Purpose vs. General Purpose In Abgrenzung zu GUIs, die im Normalfall zur
Interaktion mit beliebigen Applikationen verwendet werden können, sind TUIs
eher spezifisch auf einen bestimmten Anwendungsfall hin ausgerichtet und und
werden dementsprechend konzipiert. Wichtig ist hier vor allem die Berücksichti-
gung den Benutzern vertrauter Metaphern bei der Konzeption der Informations-
repräsentation und der Manipulations-Werkzeuge.
Space-Multiplexed Input Generell ermöglichen TUIs eine parallele Manipulation meh-
rerer räumlich verteilter physischer Objekte zur gleichen Zeit. Es ist damit möglich
155
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
kollaborative Interaktion zu unterstützen, bei der mehrere Benutzer den Systemzu-
stand simultan beeinflussen. Die Kollaboration kann dabei auch räumlich verteilt
stattfinden, wenn Mechanismen existieren, die den Systemzustand der einzelnen
TUI-Instanzen synchron hält (z.B. durch Aktuatoren).
Im seinen Schlussbetrachtungen führt Ishii die größten Mängel des noch jungen For-
schungsgebiets der Tangible User Interfaces aus: es fehle an „Killer Applications“, an
skalierbaren Toolkits und an verlässlichen und validierten Design Prinzipien.
Kategorien Tangible Telepresence, Tangibles with kinetic Memory,
Constructive Assembly, Tokens and Constraints, Inter-
active Surfaces – Tabletop UI, Continuous Plastic TUI,
Augmented Everyday Objects, Ambient Media
Konzepte Digital Information, Tangible Representation, Control,
Intangible Representation
Eigenschaften Gesamtsystem: Computational Coupling, Embodiment
of Control Mechanisms, Perceptual Coupling
PD-Brücke Abhängig von der Art des Systems, grundsätzlich aber
immer Koppelung zwischen tangibler Repräsentation
und Control
6.4.13. Zusammenfassung
Die in den vorhergehenden Abschnitten betrachteten Arbeiten sind in Ansatz, Aus-
gangspunkt und Vorgehensweise höchst unterschiedlich. Ihnen ist jedoch gemein, dass
sie sich mit der Konzeptualisierung von Tangible User Interfaces beschäftigen. Die Ar-
beiten können dabei entlang zweier Dimensionen nach Ziel und Betrachtungsgegenstand
klassifiziert werden. Hinsichtlich der Zielsetzung sind Arbeiten, die auf die Spezifikati-
on eines TUI ausgerichtet sind, von solchen zu unterscheiden, die auf die Evaluation
existierender Systeme ausgelegt wurden (im Sinne von detailliert angegebenen Merk-
malen, die ein System aufweisen muss um eine bestimmte Eigenschaft zu haben). Als
dritte Ausprägung sind noch Ansätze zu identifizieren, die eine Einordnung in einen Re-
ferenzrahmen ermöglich sollen, ohne die Eigenschaften des TUI im Detail zu betrachten.
Hinsichtlich des Betrachtungsgegenstandes sind unterschiedliche Detaillierungsgrade zu
erkennen, wobei hier die beiden Ausprägungen „Gesamtsystem“ und „einzelne physische
Elemente“ als Extremwerte zur Klassifikation herangezogen werden. Hinsichtlich des Be-
trachtungsgegenstandes ist noch zu unterscheiden, ob sich die Arbeit auf die Struktur
des TUI konzentriert oder sich darüber hinaus auch explizit mit dessen Verwendung
beschäftigt. Ansätze der zweiten Art werden in der Tabelle kursiv gesetzt. Jeder Ansatz
verfolgt über diese Einordnung hinaus noch spezifische Zielsetzungen, die der Übersicht-
lichkeit wegen in dieser ersten Einordnung nicht angegeben werden.
156
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Die Einordnung in die Kategorien (siehe Tabelle 6.1) erfolgt aufgrund der von den
jeweiligen Autoren in den Artikeln explizit genannten Zielsetzungen oder – wenn die-
se nicht vorhanden oder aussagekräftig sind – aufgrund der von Autoren gewählten
Schwerpunktsetzungen und unter Berücksichtigung des jeweiligen Gesamtzusammen-
hangs (übergeordnetes Forschungsvorhaben). Ansätze, die zu mehreren Kategorien Bei-
träge liefern, werden in allen betreffenden Feldern angeführt.
Tabelle 6.1.: Kategorien von konzeptuellen Arbeiten im Gebiet Tangible User Interfaces
(kursiv gesetzte Arbeiten gehen auch auf das Verhalten von TUIs ein)
Gesamtsystem einzelne physische Elemente
Spezifikation Bricks
MCRpd-Interaktions-Modell
Tangible Bits: Beyond Pixels
Containers, Tokens und Tools
Tokens+Constraints
Tokens and Constraints
nach Shaer et al.
Evaluation Graspable User Interfaces Taxonomie für Tangible User
Interfaces
Einordnung Tangible Bits
Tokens+Constraints
Kategorien von
TUI Anwendungen
Tangible Bits: Beyond Pi-
xels
Tangible Objects Meaning
Degree of Coherence
In dieser Aufstellung ist zu erkennen, dass ein Großteil der Ansätze nicht auf den
Interaktionsaspekt des Anwendungsfalls eingeht, für den das betrachtete TUI konzipiert
ist, sondern sich auf die strukturellen Aspekte des Systems beschränkt.
Den umfassendsten Ansatz zur Spezifikation bietet die Arbeit „Tokens and Cons-
traints“ von (Shaer et al., 2004), der aufbauend auf der Arbeit von Ullmer (2002) einen
modifizierten Token+Constraints-Ansatz vorstellt. Dieser eignet sich durch ein breiteres
Verständnis des Constraint-Begriffs für die allgemeine Spezifikation der Struktur eines
TUI. Zusätzlich stellt er ein Schema zur Verfügung, in dem – basierend auf der Struktur
– auch das Verhalten des Systems spezifiziert werden kann.
Zur detaillierten Evaluation eines TUI bietet sich die Taxonomie von Fishkin (2004)
an, der in seiner Arbeit in zwei Dimensionen sowohl die Betrachtung der Struktur als
auch der Verwendung der Objekte eines TUI in den spezifizierten Interaktionsabläufen
erlaubt.
157
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Ausdrucksstärke der konzeptuellen Ansätze
Grundsätzlich sind jene Ansätze, die sich mit der detaillierten Beschreibung eines TUI
befassen, ausdrucksstärker als jene Ansätze, die ein System lediglich global betrachten.
Dies bezieht sich jedoch in erster Linie auf die Quantität der generierten Daten, quali-
tativ gesehen ergänzen beide Sichtweisen einander und sind sowohl bei Spezifikation als
auch Evaluation komplementär anzuwenden. Der Fokus der Betrachtung der jeweiligen
Ansätze ist in Tabelle 6.1 angeführt und wird hier nicht separat unterschieden.
Einige der vorgestellten Ansätze sind inhaltlich insofern als überholt anzusehen, als
dass sie heute gängige Techniken und Interaktionsparadigmen nicht adäquat abbilden
können. Dies gilt sowohl in struktureller Hinsicht als auch in Bezug auf das Verhal-
ten eines Systems. Die strukturellen Konzepte haben sich konzeptuell von „werkzeug-
zentrierten“ auf „informations-zentrierte“ Sichtweise weiter entwickelt. Ältere, „werkzeug-
zentrierte“ Ansätze betrachten die physischen Elemente ausschließlich als Werkzeuge
zur Manipulation digitaler Information, die nach wie vor herkömmlich visuell ausgege-
ben wird und keine physische Manifestation besitzt. Typische Vertreter dieser Sichtweise
sind die Arbeiten von Fitzmaurice et al. (1995) und Fitzmaurice (1996). Ab der Arbeit
von Ishii und Ullmer (1997) wird der Aspekt der physischen Repräsentation von In-
formation berücksichtigt, womit erstmals eine umfassende Beschreibung von Systemen
ermöglicht wird, die heute als TUI bezeichnet werden.
In der Folge wurden unterschiedliche Ansätze vorgestellt, die auf verschiede Aspekte
in der Beschreibung der Struktur eingehen. Ein grundlegendes Unterscheidungsmerk-
mal der Ansätze ist ihre Herangehensweise an die Unterscheidung zwischen physischen
Objekten, die Information repräsentieren und solchen, die Information manipulieren (in
wenigen Fällen werden auch Werkzeuge zur Systemsteuerung separat betrachtet). Eine
Herangehensweise ist die strikte konzeptuelle Trennung zwischen physischen Objekten,
die zur Informationsrepräsentation verwendet werden und solchen, die als Werkzeug
zur Manipulation eingesetzt werden. Typische Vertreter sind hier die Arbeiten von Is-
hii und Ullmer (1997) und Holmquist et al. (1999). Dem hingegen steht die Herange-
hensweise die Bedeutung eines physischen Objekts für eine bestimmte Anwendung auf
einem Kontinuum einzuordnen und Objekte damit als eher „werkzeug-artig“ oder eher
„repräsentations-artig“ (oder beides integrierend) einzuordnen. Typische Vertreter für
diese Herangehensweise sind die Arbeiten von Underkoffler und Ishii (1999), Koleva
et al. (2003) und Fishkin (2004). Einen dritten Weg gehen die Ansätze von Ullmer und
Ishii (2000) und darauf aufbauend Ishii (2008), die physische Elemente immer als Kombi-
nation eines Repräsentations- und Kontroll-Anteils sehen und diese konzeptuell separat
behandeln. Implizit in dieser Tradition stehen auch die Ansätze von Ullmer (2002) und
Shaer et al. (2004), die mit dem „Tokens und Constraints“-Konzept einerseits eine dritte
Art von physischen Objekten – die Constraints, die den Interaktionsraum beschränken
– einführen, andererseits aber bei den eigentlich zur Interaktion verwendeten physischen
Elementen nicht zwischen Repräsentationen und Werkzeugen unterscheiden. Funktio-
158
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
nalität wird vielmehr durch die Manipulation eines (informationstragenden) Tokens im
Kontext von Constraints ausgelöst – Tokens haben somit einen Kontroll-Aspekt im Sinne
von Ullmer und Ishii (2000).
Seltener anzutreffen sind Arbeiten, die explizit auf die Beschreibung oder Evaluation
der Interaktionsabläufe eines TUI eingehen. Fishkin (2004) behandelt diesen Aspekt im
Rahmen der „Metaphor“-Dimension seiner Taxonomie. Er unterscheidet dort zwischen
TUIs oder TUI-Komponenten, deren Interaktionsmetaphern eher an Objekten der realen
Welt und / oder an Tätigkeiten der realen Welt angelehnt sind. Werden alle Kompo-
nenten eines TUI in diese Dimension eingeordnet, so ermöglicht dies die Prüfung, ob die
Metaphern konsistent gewählt wurden (Oppl, 2009b). Die Interaktionsabläufe im Detail
sind jedoch bei Fishkin (2004) nicht Gegenstand der Betrachtung. Auf detaillierter Ebe-
ne gehen lediglich Shaer et al. (2004) auf Interaktionsabläufe im Allgemeinen und der
Spezifikation im Speziellen ein. Die Autoren erweitern dazu den Token+Constraints-
Ansatzes (Ullmer, 2002) um einen Interaktionsaspekt, der auf Basis der strukturellen
Eigenschaften eines TUI deren dynamisches Zusammenspiel untereinander und mit den
Benutzern festlegt. Damit wird es möglich, ein TUI sowohl in Struktur als auch Verhalten
umfassend zu spezifizieren.
Nomenklatur
Hinsichtlich der Bezeichnung der Elemente eines TUI existiert keine einheitliche Nomen-
klatur, die konsistent über mehrere Arbeiten hinweg verwendet wird. Die Tabellen 6.2
und 6.3 gibt eine Übersicht über die für die einzelnen konzeptuellen Elemente verwen-
deten Begriffe.
Diese Arbeit folgt in der Bezeichnung der physischen Elemente dem TAC-Ansatz von
(Shaer et al., 2004) und verwendet generell der Begriff des „Tokens“. Zur Abgrenzung
wird, wo nötig, von „Modellierungstokens“ (jene Tokens, die Information repräsentie-
ren) und „Werkzeugtokens“ (jene Tokens, die Funktionalität auslösen) unterschieden.
Der digitale Aspekt eines TUI wird selten explizit benannt, der von (Shaer et al., 2004)
gewählte Begriff der „Variable“ ist im Kontext der Repräsentation von Modellen aber zu
spezifisch bzw. aus dem Kontext der Softwareentwicklung heraus unpassend vorbelegt.
Deshalb wird im Allgemeinen nach (Ishii, 2008) von „digitaler Information“ gesprochen,
wenn explizit auf die digitale Repräsentation des Modells Bezug genommen wird, wird
der Begriff „Modell-Elemente“ verwendet. Eine weitere Ausdifferenzierung der Nomen-
klatur zur Bezeichnung von anwendungsspezifischen Eigenschaften des hier vorgestellten
Werkzeugs erfolgt im Rahmen der folgenden Kapitel.
Die hier vorgestellten Ansätze werden nach der Beschreibung des Werkzeugs in Kapitel
10 wieder aufgegriffen und auf das hier entwickelte System angewandt. Damit werden
zwei Ziele verfolgt. Einerseits soll die praktische Anwendbarkeit der Ansätze und deren
159
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Tabelle 6.2.: Gegenüberstellung der Nomenklatur zur Beschreibung der Elemente eines
TUI – Teil 1
Arbeit physisches
Objekt zur
Informations-
repräsentation
physisches
Werkzeug zur
Informations-
manipulation
physische
Beschrän-
kung des
Interakti-
onsraums
digitale
Objekte
Bricks — Brick — —
Graspable
User Inter-
faces
— — — —
Tangible
Bits
Phicon Phandle (In-
formationsma-
nipulation),
Instrument
(Systemsteue-
rung)
Tray —
Containers,
Tokens und
Tools
Container (un-
spezifische
Form), Token
(spezifische
Form)
Tool — —
Tangible
Objects
Meaning
Object as
pure object
(unspezifische
Form), Object
as attribute
(teilspezifisch),
Object as noun
(spezifische
Form)
Object as verb
(fix gebundene
Funktionalität),
Object as recon-
figurable tool
(konfigurierbare
Funktionalität)
— —
MCRpd
Inter-
aktions-
Modell
Rep-P Control — Model,
Rep-D
(Manifes-
tation)
160
6.4. Konzeptualisierung und Klassifikation von Tangible Interfaces
Tabelle 6.3.: Gegenüberstellung der Nomenklatur zur Beschreibung der Elemente eines
TUI – Teil 2
Arbeit physisches
Objekt zur
Informations-
repräsentation
physisches
Werkzeug zur
Informations-
manipulation
physische
Beschrän-
kung des
Interakti-
onsraums
digitale
Objekte
Tokens +
Constraints
Tokens Tokens + Cons-
traints
Constraints —
Degree of
Coherence
Identifier (un-
spezifische
Form), Pro-
xy (von hier
an: spezifische
Form, Enge
der Bindung
ansteigend),
Projection, Il-
lusion of same
objects
General purpose
tools (kon-
figurierbare
Funktionalität),
Specialized tools
(fix gebundene
Funktionalität)
— —
TAC Token-Pyfo Token-Pyfo Constraint-
Pyfo
Variable
TUI-
Anwendungs-
Kategorien
— — — —
Taxonomie
für TUIs
— — — —
Tangible
Bits: Bey-
ond Pixels
tangible
Representation
Control — digital in-
formation,
intangible
represen-
tation
(Manifes-
tation)
161
6.5. Tabletop Interfaces
Verwendbarkeit für ein konkretes, im Vergleich zu den in den Artikeln vorgestellten
Beispielen komplexes und flexibles System überprüft werden. Andererseits soll versucht
werden, aus der theoretisch-konzeptuellen Betrachtung des Werkzeugs Inkonsistenzen
im Design zu erkennen und potentiell verbesserungswürdige Aspekte des Werkzeugs zu
identifizieren. Eine Gegenüberstellung mit den Ergebnissen der praktischen Evaluierung
erlaubt in der Folge auch die Überprüfung des Aussagekraft derartiger auf theoretischen
Konzepten basierenden Betrachtungen bzw. Spezifikationen.
6.5. Tabletop Interfaces
Tabletop Interfaces sind Benutzungsschnittstellen, bei denen die Interaktion mit einem
Computersystem über eine (im Allgemeinen horizontal angebrachte) Tischplatte durch-
geführt wird. Tabletop Interfaces sind nicht als echte Untermenge von Tangible Interfaces
zu sehen. Systeme, bei denen die Interaktion mittels direkter Berührung der Oberflä-
che mit den Händen („Touch-“ bzw. „Multitouch“-Systeme) durchgeführt wird, werden
ebenfalls zu den Tabletop Interfaces gezählt, sind aber aufgrund des fehlenden phy-
sischen Repräsentationsaspekts des Systemzustandes nicht als unbedingt als Tangible
Interface zu klassifizieren.
Im Sinne einer Aufarbeitung der „Related Work“ beschränkt sich diese Arbeit hier
auf jene Systeme, die historisch für die Entwicklung des Feldes der „Tangible Tabletop
Interfaces“ wichtig waren bzw. sind und jene Arbeiten, in denen inhaltlich ähnliche
Zielsetzungen wie in dieser Arbeit verfolgt wurden, auch wenn das zugrunde liegende
Tabletop Interface keine „tangiblen“ Aspekte aufweist.
6.5.1. Historische Entwicklung
Tabletop Interfaces wurden erstmals von Wellner (1993) beschrieben, der damit gemäß
der Vision „back to the real world“ Wellner et al. (1993) beabsichtigte, die Trennung
zwischen der realen Welt und dem digitalen Inforamtionsraum zu beseitigen und eine
nahtlose, natürliche Interatkion mit Computersystemen zu ermöglichen. Im Bereich der
Tangible Interfaces wurde bereits mit der Einführung des Begriffs von Ishii und Ullmer
(1997) die Geräteklasse der „Interactive Surfaces“ identifiziert, in die Systeme eingeord-
net wurden, die eine mit digitaler Information angereicherte physische Oberfläche als
Ausgabemedium verwenden, auf der zur Eingabe physische Objekt manipuliert werden.
Diese Klasse von Systemen ist nicht auf Tische eingeschränkt, sondern umfasst z.B.
auch digital augmentierte Wände. Das MetaDESK-System, das in der gleichen Arbeit
als Beispiel für Interactive Surfaces vorgestellt wird, kann als das erste in der Literatur
beschriebene Tangible Tabletop Interface bezeichnet werden.
162
6.5. Tabletop Interfaces
Frühere Arbeiten, wie die von Fitzmaurice (1996) beschriebenen „Bricks“, setzten zur
Interaktion physische Bausteine ein, die lediglich einen Bezug zueinander aufweisen, aber
keine gemeinsame Oberfläche als Referenzrahmen benötigen und verwenden (”relational
interfaces” im Sinne von Ullmer und Ishii (2000)). Fasst man den Begriff der Interac-
tive Surfaces nach Ishii und Ullmer (1997) eng, so fallen derartige Systeme aufgrund
des fehlenden gemeinsamen physischen Referenzrahmens nicht in diese Klasse. In jenen
Fällen, in denen trotzdem ein räumlich entsprechend begrenztes physisches „Trägerme-
dium“ benötigt wird (also eine klassische, nicht digital augmentierte Tischoberfläche
zur Anordnung der Elemente des Interfaces eingesetzt wird), kann trotzdem von einem
„Tangible Tabletop Interface“ gesprochen werden.
Anfänge
Das Sensetable-System (Patten et al., 2001) ist die erste in der Literatur beschriebe-
ne „Interactive Surface“ Plattform, die breit in unterschiedlichen Anwendungsszenarien
eingesetzt wurde. Es steht inhaltlich in der Tradition des MetaDESK-Systems (Ishii und
Ullmer, 1997) und basiert technologisch auf eine Tischoberfläche, auf die von oben proji-
ziert wird und mit der mittels auf die Oberfläche aufgesetzten „Pucks“ interagiert werden
kann. Die Feststellung der Position der „Pucks“ erfolgt mittels einem magnetischem Po-
sitionierungssystem. Die Positionsbestimmung auch mehrerer Objekte gleichzeitig kann
damit quasi verzögerungsfrei und mit einer Genauigkeit im mm-Bereich durchgeführt
werden.
Das BUILD-IT-System (Fjeld, 2001) ist eines der ersten Systeme, in dem Tabletop In-
terfaces zur Unterstützung von kooperativen Arbeitsprozessen eingesetzt werden. Fjeld
et al. (1997) führen den Begriff des „Natural User Interfaces“ und meinen damit die
kohärente Manipulierbarkeit von Objekten auf physischen und digitalen Oberflächen. In
der konkreten Implementierung des BUILD-IT-Systems (Fjeld, 2001) steht eine horizon-
tale Oberfläche zur Verfügung, auf der physische Objekte platziert werden können und
auf die synchron anwendungsspezifische Information projiziert wird. Zusätzlich steht ei-
ne vertikale Oberfläche zur Erweiterung der Darstellungsraums zur Verfügung, auf der
lediglich Information angezeigt wird, während eine physische Manipulation nicht möglich
ist. Das System wurde in unterschiedlichen Anwendungsszenarien zum Einsatz gebracht,
und einer Evaluierung hinsichtlich seiner Benutzbarkeit und seinen Auswirkungen auf
die Arbeit der Benutzer unterzogen. Die Ergebnisse dieser Untersuchung sprechen im
Wesentlichen für die Nützlichkeit von Tabletop User Interfaces, auch wenn aufgrund
technischer Restriktionen die Verwendbarkeit des Systems eingeschränkt war. Die Wir-
kung des Systems auf kooperative Arbeit wurde explizit nicht untersucht.
163
6.5. Tabletop Interfaces
6.5.2. Aktuelle Plattformen
Mit dem stärker werdenden Forschungsinteresse im Bereich der Tabletop Interfaces und
dem zunehmenden kommerziellen Interesse ist in den letzten Jahren die zunehmen-
de Verfügbarkeit von Applikationsplattformen für Tabletop Interfaces zu beobachten,
die sowohl einen definierten Satz von Hardware-Funktionalität (also dem eigentlichen
Tabletop Interface) als auch eine Programmierschnittstelle für die Entwicklung eige-
ner Applikationen mit sich bringt. Mit Stand von Ende 2009 werden in der aktuellen
Forschung vor allem drei Lösungen eingesetzt, von denen zwei auch die Hardware kom-
merziell vertreiben und eine lediglich die Software und Bauanleitungen für das Tabletop
Interface anbietet. Absehbar ist hier die weitere Diversifizierung des Angebots, wobei
auf die neueren Anbieter an dieser Stelle jedoch nicht weiter eingegangen wird.
ReacTable
Der ReacTable (Kaltenbrunner et al., 2006) ist ein auf einem Tangible Tabletop Interface
beruhendes kooperatives Musikinstrument, dessen Hardwarekomponente und Software-
Schnittstelle zur visuellen Identifikation von Objekten auf der Oberfläche generisch ein-
setzbar sind. Die Hardware des ReacTable besteht aus einem Tisch, dessen Oberfläche
semitransparent ausgeführt ist. Die Objekte werden durch auf deren Unterseite ange-
brachten visuellen Markern identifiziert. Zugleich wird von der Unterseite mittels einem
Projektor zusätzliche Information auf die Oberfläche projiziert.
Die zur Objektidentifikation verwendeten Marker sind proprietär und bilden einen ein-
deutigen Code ab, der softwareseitig das ensprechende Element identifiziert. Die Anzahl
der Marker ist erweiterbar, wobei deren Form frei gewählt werden kann. Zusätzlich zu
Identifikation von Elementen kann die Software auch Fingerberührungen visuell erken-
nen, wodurch die Oberfläche multi-touch-fähig wird.
Die Software ist plattformübergreifend für Windows, Mac OS X und Linux als Open
Source Software verfügbar. Die Analyse des Kamerabilds erfolgt in Quasi-Echtzeit mit
15 bis 20 Bildern pro Sekunde (abhängig vom eingesetzten Rechner). Die Information für
auf der Oberfläche erkannte Elemente oder Finger wird über das proprietäre aber mitt-
lerweile auch von anderen Anbietern eingesetzte TUIO-Protokoll über einen UDP12-Port
ausgegeben und kann so von beliebigen Clients übernommen und verarbeitet werden.
In den Softwarepaketen sind vorgefertigte Clients für die Programmiersprachen C und
Java enthalten.
12User Datagram Protocol
164
6.5. Tabletop Interfaces
Microsoft Surface
Die Microsoft Surface13 ist ein kommerzielles Produkt, dass als Paket von Hard- und
Software von Microsoft vertrieben wird. Die Hardwarekomponente stellt sich als ein in
sich abgeschlossenes System ohne vorgesehene Manipulationsmöglichkeit der Benutzer
oder Entwickler dar. Sie besteht dabei aus einer Tischoberfläche, die semitransparent
ausgeführt ist und von unten projiziert wird. Die Erfassung von Benutzerinteraktion
erfolgt visuell mittels unter der Oberfläche installierten Kameras. Der Fokus liegt dabei
auf der Identifikation von Berührungen mit einem oder mehreren Fingern bzw. durch
eine oder mehrere Personen. Zusätzlich können Objekte durch ihren Umriss oder durch
proprietäre visuelle Codes identifiziert werden. Die Identifikation erfolgt dabei in Quasi-
Echtzeit mit mehreren Bildern pro Sekunde (exakte Werte unbekannt). Der Tisch selbst
ist in Form und Bauhöhe eher als Besprechungs- bzw. Bartisch denn als Arbeitstisch
ausgeführt.
Softwareseitig kommt ein modifizierte bzw. erweitere Version von Windows Vista zum
Einsatz. Die Microsoft Surface bietet neben einer Reihe von vorinstallierten Anwen-
dungen auch die Möglichkeit, mittels einem API14 auf die Information der Oberfläche
identifizierten Objekte und Finger zuzugreifen und diese in eigenen Anwendungen zu
verarbeiten. Diese Anwendungen müssen auf Microsoft’s .NET-Framework basieren, um
an das API angebunden werden zu können.
DiamondTouch
Der DiamondTouch (Dietz und Leigh, 2001) ist ein Projekt von den Mitsubishi Research
Labs15, dass mittlerweile kommerziell von dem Unternehmen Circle Twelve16 vertrieben
wird. Im Gegensatz zu den anderen beiden vorgestellten Ansätzen setzt der Diamond-
Touch kein visuelles Identifikationverfahren ein, sondern verwendet ein auf kapazitiver
Erkennung basierendes Verfahren, dass durch seine Ausführung nicht nur die Identifi-
kation mehrerer gleichzeitiger Berührungen sondern auch die eindeutige Identifikation
von Benutzern (auch über die Zeit bei nicht ununterbrochener Berührung) ermöglicht.
Das System unterstützt jedoch keine Identifkation von Objekten, es können lediglich
Berührungen identifiziert werden. Die Hardwareausführung ähnelt jener der Microsoft
Surface, allerdings wird im Gegensatz zu den anderen beiden Lösungen von oben auf
die Oberfläche projiziert. Um eine eindeutige Identifikation der handelnden Personen
gewährleisten zu können, müssen diese außerdem auf je einem von bis zu vier an dem
System angeschlossenen Stühlen sitzen.
13http://www.microsoft.com/surface/
14Application Interface
15http://www.merl.com/projects/DiamondTouch/
16http://www.circletwelve.com/
165
6.6. Tabletop Interfaces zur Erstellung diagrammatischer Modelle
Die Identifikations-Software arbeitet unter Windows oder Linux und liefert über ein
API die Berührungsinformation an eine vom Entwickler zu erstellende Applikation. Das
API kann dabei aus unterschiedlichen gängigen Programmiersprachen (wie C++, Java
oder Adobe Flash) angesprochen werden.
6.6. Tabletop Interfaces zur Erstellung
diagrammatischer Modelle
In diesem Abschnitt werden Systeme beschrieben, die sich der Erstellung diagramma-
tischer Modelle auf tischbasierten Benutzungsschnittstellen widmen, also ein zu dieser
Arbeit verwandtes Werkzeug mit verwandter Technologie umsetzen. Die eigentliche Ziel-
setzung unterscheidet sich im Einzelfall, die Verwandtschaft beschränkt sich auf die Un-
terstützung im Vorgang der Modellbildung.
Nicht betrachtet werden hier Systeme, die sich zwar mit Modellbindung im weiteren
Sinne beschäftigen, deren Betrachtungsgegenstand aber nicht diagrammatische Modelle
sind. Derartige Systeme haben oft den Anspruch, die Modellbildung weniger abstrakt
zu gestalten und vor allem die Modellverwendung durch Simulationen an das Verhalten
des dargestellten Phänomens in der realen Welt anzunähern. Ein klassisches Beispiel
ist hier Urp (Underkoffler und Ishii, 1999), ein Stadtplanungssystem, bei dem Objekte,
die Gebäude repräsentieren, maßstabsgetreu auf einer Oberfläche platziert werden kön-
nen. Je nach ausgeführter Simulation können in Echtzeit die Lichtverhältnisse bei Son-
neneinstrahlung oder die Luftströmungen im arrangierten Gebäude-Ensemble verfolgt
werden. Systeme dieser Klasse beschäftigen mit anderen Aspekten von Modellbildung
und vernachlässigen explizite Repräsentation der konzeptuellen Beziehungen zwischen
Modellelementen. Sie sind deshalb nicht als verwandte Arbeiten zu klassifizieren.
Im ersten Unterabschnitt werden Systeme betrachtet, die sich historisch mit der The-
matik der Modellierung mittels Tangible (Tabletop) Interfaces beschäftigen. Der zweiter
Unterabschnitt stellt zwei Arbeiten vor, die parallel zur vorliegenden Arbeit entwickelt
wurden und sich so wie diese mit den konkreten Modellierungsaufgaben im Rahmen von
Concept Mapping beschäftigen, das, wie in Kapitel 4 beschrieben, auch eine methodische
Grundlage dieser Arbeit darstellt.
6.6.1. Historische Entwicklung
Die Unterstützung der Bildung von diagrammatischen Modellen mittels Tangible In-
terfaces wird seit der Jahrtausendwende in der Literatur behandelt. Tatsächlich sind
jedoch nur drei Arbeiten zu identifizieren, die sich mit der Bildung diagrammatischer
Modelle beschäftigen und in der Literatur so ausführlich beschrieben sind, dass eine Be-
rücksichtigung an dieser Stelle möglich ist. Zu diesen Arbeiten existieren jeweils mehrere
166
6.6. Tabletop Interfaces zur Erstellung diagrammatischer Modelle
Publikationen, als Referenz wurde hier jeweils jene Publikation herangezogen, in der das
System am ausführlichsten dokumentiert ist.
Tangible Business Process Analyser
Historisch wurde der Anwendungsfall der Modellbildung mit Tangible Interfaces bereits
auf der ersten funktionsfähigen „Interactive Surface“, dem Sensetable (Patten et al.,
2001), umgesetzt. Der „Tangible Business Process Analyser“ (Mori et al., 2004) ist eine
Anwendung, die auf Basis des Sensetable implementiert wurde und dazu dient, Work-
flows zu modellieren, deren Parameter einzustellen und in der Folge die Ergebnisse einer
Simulation zu visualisieren. Das Modell selbst hat dabei keine physische Ausprägung
sondern wird lediglich projiziert. Wie in vielen Systemen aus dieser Generation von Tan-
gible Tabletop Interfaces (z.B. auch (Fitzmaurice et al., 1995)) werden auch in dieser
Arbeit nur die Manipulations-Werkzeuge selbst physisch ausgeführt. Die Repräsentation
der Information (hier: das Modell) verbleibt digital und wird z.B. durch Projektion auf
die Tischoberfläche dargestellt. Die Manipulation der Modellelemente selbst sowie der
zur Simulation notwendigen Parameter wird durch Einsatz der „Pucks“ des Sensetable-
Systems durchgeführt.
Designer’s Outpost
Ein Werkzeug zur kooperativen konzeptuellen Planung von Websites ist der „Designer’s
Outpost“ (Klemmer et al., 2001). Dabei handelt es sich streng genommen nicht um ein
Tabletop Interface, da die interaktive Oberfläche vertikal angebracht ist. Die sonstigen
technischen und inhaltlichen Eigenschaften sind jedoch jenen des hier vorgestellten Sys-
tems so ähnlich, dass eine Betrachtung im Rahmen der verwandten Arbeiten angemessen
ist.
Das „Designer’s Outpost“-System ermöglicht es, die Seiten einer Website als Kno-
ten eines Modells auf der interaktiven Oberfläche abzubilden. Dazu werden physisch
Haftnotizen beschriftet und platziert. Diese können durch eine Erfassung mittels einer
Kamera auch „virtualisiert“ werden. Virtualisierte Haftnotizen ermöglichen in der Folge
auch das über mehrere Standorte verteilte Modellieren. Links zwischen den Seiten einer
Website können als Beziehungen zwischen den Haftnotizen dargestellt werden. Diese Be-
ziehungen werden mit einem stiftartigen Werkzeug auf die Oberfläche „gezeichnet“ und
bleiben auch erhalten, wenn die Haftnotizen anders platziert werden. Zum Entfernen
einer Beziehung wird ein „Radiergummi“ verwendet, mit dem diese „ausradiert“ werden
kann.
Als wesentlich für die Nachvollziehbarkeit der erstellten Website-Struktur bezeichnen
Klemmer et al. (2002) deren Erstellungsgeschichte. Sie unterstützen mit ihrem Werk-
zeug also die Verfolgung und den Abruf der Entstehungshistorie eines Modells. Durch
167
6.6. Tabletop Interfaces zur Erstellung diagrammatischer Modelle
die Visualisierbarkeit unterschiedlicher Entwicklungszweige ist auch die Vergleichbarkeit
sequentiell entwickelter Modellvarianten möglich.
Digital Montessori-inspired Manipulatives
Die Entwicklung der „Digital Montessori-inspired Manipulatives“ (Zuckerman et al.,
2005) basiert auf den pädagogischen Ansätzen von Maria Montessori (Montessori, 2005).
Die Autoren beschreiben ein System zur Erschließung physikalischer Zusammenhänge
(z.B. Regelkreise) mittels konzeptueller Modelle, die durch die physische Anordnung
und Zusammenschaltung von funktionalen Bausteinen erzeugt werden. Entsprechend der
Prinzipien von Montessori wird vor allem die physische Unmittelbarkeit der Modellreprä-
sentation als nützlich für den angestrebten Lernerfolg gesehen. Ein zweiter wesentlicher
Aspekt ist die Möglichkeit zur Selbstkontrolle, d.h. der eigenständigen Überprüfbarkeit
der Wirkung der modellierten physikalischen Zusammenhänge. Dazu wird durch das Sys-
tem auf Basis des erstellten Modells eine Simulation durchgeführt und deren Ergebnisse
direkt auf den Bausteinen visualisiert. Zum Einsatz kommen dabei Miniatur-Displays
bzw. Leuchdioden, die in den Bausteinen integriert sind. Die Struktur des Modells wird
aus der Leitfähigkeit der physischen Verbinder zwischen den Bausteinen abgeleitet.
Es ist somit weder externe Infrastruktur zur Erhebung der Modellparameter noch
zur Visualisierung von zusätzlicher Information notwendig. Dementsprechend muss die
Oberfläche, auf der modelliert wird, keine speziellen Eigenschaften aufweisen oder mit
Sensoren und Aktuatoren angereichert werden. Die Klassifikation als „Tabletop Inter-
face“ bezieht sich deshalb hier alleine auf den Nutzungskontext, nicht aber auf die tech-
nischen Eigenschaften des Werkzeugs.
6.6.2. Aktuelle verwandte Ansätze
In der aktuellen Literatur sind zwei Ansätze beschrieben, die so wie das vorliegende
System ein Tabletop Interface verwenden, um semantisch offene diagrammatische Mo-
delle in der Form von „Concept Maps“ abzubilden. Diese beiden Arbeiten werden im
Folgenden kurz beschrieben und hinsichtlich ihrer technischen Umsetzung betrachtet.
A Tangible Approach to Concept Mapping
Tanenbaum und Antle (2009) schlagen ein System vor, mit dem Concept Maps im Lehr-
und Lernkontext erstellt werden können. Sie bedienen sich dazu eines Tabletop Inter-
faces, bei dem die Concept Map vollständig digital von unten auf die Tischoberfläche
projiziert wird. „Vollständig digital“ bedeutet hier, dass sowohl die Knoten der Concept
Map als auch deren Kanten und sämtliche Beschriftungen digital dargestellt werden und
nicht physisch auf der Oberfläche vorhanden sind.
168
6.6. Tabletop Interfaces zur Erstellung diagrammatischer Modelle
Die Manipulation der Objekte erfolgt mittels „Pucks“ (Auswahlelemente im Sinne des
„Sensetable“-Systems), mit Hilfe derer die Elemente der Concept Map erzeugt und ver-
schoben und gelöscht werden können. Technisch kommt dazu das ReacTIVision-System
des ReacTable (vgl. Abschnitt 6.5.2) zum Einsatz. Auf der Unterseite der „Pucks“ sind
die visuellen Codes des ReacTIVision-Systems angebracht, die von unten mit einer Ka-
mera erfasst werden.
Die Autoren beschreiben eine Reihe von während der Evaluierung identifizierten Ei-
genschaften der Umsetzung des Werkzeugs, deren Berücksichtigung bei der Konzeption
des hier behandelten Systems notwendig ist:
• Die Erkennung der „Pucks“ war instabil (zu kleine Codes), dadurch traten Pro-
bleme beim Verschieben von Knoten aus (diese wurden „verloren“).
• Die Oberfläche wurde als zu klein wahrgenommen, um sinnvoll eine Concept Map
abbilden zu können (max. 6-7 Knoten auf der Oberfläche möglich).
• Das Herstellen von Verbindern durch Zusammenführen zweier „Pucks“, die jeweils
ein Element tragen, scheint in der Benutzung verständlich und leicht erlernbar zu
sein.
• Das vorliegende System unterstützt lediglich ungerichtete Verbindungen. Benutzer
benötigen jedoch gerichtete und ungerichtete Verbindungen, um alle sinnvollen
Beziehungen in der Concept Map eindeutig darstellen zu können.
• Das vorliegende System arbeitet mit fest vorgegebenen Knoten und Kanten, die
jedoch frei angeordnet und assoziiert werden können. Die festen Vorgaben wurden
jedoch von den Benutzern als zu einschränkend wahrgenommen.
Multi-finger interactions with papers on augmented tabletops
Do-Lenh et al. (2009) setzen ihre Anwendung ebenfalls im Zusammenhang mit der Un-
terstützung von Lehr- und Lernprozessen ein. Sie verwenden dazu ein portables System,
dass die Erstellung von Concept Maps auf beliebigen ebenen Oberfläche ermöglicht. Die
Knoten der Concept Map werden dabei durch Kärtchen symbolisiert, die mit zweidi-
mensionalen Barcodes versehen sind, um deren Position erkennen zu können. Die Posi-
tionserkennung wird mittels einer auf einem Galgen montierten Kamera vorgenommen.
Verbindungen werden ausschließlich projiziert, wozu ein neben der Kamera montierter
Projektor verwendet wird. Zur Informationseingabe können die Knoten-Kärtchen bereits
beschriftet vorliegen oder während der Modellierung mit einer virtuellen Tastatur mit
einer Bezeichnung versehen werden, die dann ebenfalls projiziert werden. Verbindun-
gen werden hergestellt, indem die betreffenden Kärtchen zusammengeführt werden oder
mittels einem speziellen Steuerkärtchen verbunden werden.
Zusätzlich zu den mit der Kamera erfassbaren Elemente, die mit einem 2D-Barcode
versehen sind, können auch die Postionen von Fingerberührungen auf der Oberfläche
169
6.7. Zusammenfassung
erkannt werden. Dazu wird ein Laserstrahl knapp über der Oberfläche ausgestrahlt, der
bei auf der Oberfläche aufgesetzten Fingern nach oben abgelenkt wird und so an der
Stelle der Berührung einen klar identifizierbaren Punkt auf dem Kamerabild hinterlässt.
Es ist so möglich, auch mehrere Berührungen simultan zu erkennen. Lediglich vertikal
hintereinander angeordnete Finger können zu Erkennungsproblemen führen.
In der konkreten Anwendung werden die Fingergesten mit den Postionsinformationen
der Kärtchen kombiniert, um etwa Verbindungen durch Markieren mit zwei Fingern
löschen zu können oder auf der virtuellen Tastatur (die auf einem ebenfalls mit einem
Barcode versehenen größeren Kärtchen aufgedruckt ist) Text eingeben zu können.
Zur Evaluation führten die Autoren eine vergleichende Studie unter Berücksichtigung
des vorgestellten Werkzeugs und den rein rechnerbasierten CMapTools (Cañas et al.,
2004) durch. Sie beschreiben einen Unterschied in der beobachteten Kooperation der
Teilnehmer bei der kollaborativen Erstellung einer Concept Map. Konkret ist eine Ko-
operation der Teilnehmer im Falle des Tabletop Interfaces bereits von Beginn der Mo-
dellierung an zu beobachten gewesen, während bei Einsatz der CMapTools eine stärkere
Unterteilung in individuelle und kooperative Arbeitsphasen zu erkennen war. Weiters
wurde auch in diesem Fall die Oberfläche als zu klein für eine sinnvolle Modellierung der
gestellten Aufgabe wahrgenommen. Das Löschen von Verbindungen konnte mittels der
bereits beschriebenen Finger-Aktion oder mittels einem Kärtchen ausgeführt werden.
Diese Redundanz wurde von Benutzern als nützlich und unterstützend wahrgenommen
und auch in der konkreten Anwendung komplementär verwendet.
6.7. Zusammenfassung
In diesem Kapitel wurden – noch unabhängig von der konkreten Implementierung des
Werkzeugs – die Grundlagen des Forschungsgebiet der Tangible (Tabletop) Interfaces
beschrieben. Die Entscheidung, das Werkzeug mittels einer „begreifbaren“ Benutzungs-
schnittstelle umzusetzen, wurde in Kapitel 5 getroffen und begründet. In den nun fol-
genden Kapiteln wird auf die Konzeption und Umsetzung des Werkzeugs auf technischer
Ebene eingegangen. Dieses Kapitel ist als Brücke zu sehen, die die relevanten Begriffe
einführt und den State-of-the-Art zusammenfasst.
Die Schnittstelle zu den Ausführungen im ersten Teil dieser Arbeit werden durch die
Abschnitte zu der Wirkung von Tangible Interfaces auf Lernprozesse und Kooperation
gebildet. Im Mittelteil des Kapitels wurden konzeptuelle Ansätze beschrieben, die sich
mit der Begriffsbildung, Klassifikation und Spezifikation von Tangible Interfaces beschäf-
tigen. Diese dienen in weiterer Folge dazu, die in dieser Arbeit verwendete Nomenklatur
festzulegen und mögliche Herangehensweisen zum Design des Werkzeugs zu identifizie-
ren. Auf die hier beschrieben Arbeiten wird auch in Kapitel 10 zurückgegriffen, um das
170
6.7. Zusammenfassung
hier entwickelte Werkzeug in das Forschungsfeld einzuordnen und mögliche konzeptuell
begründbare Schwachstellen und Verbesserungspotential zu identifizieren.
Die letzten Abschnitte in diesem Kapitel bilden die Brücke zu den nun folgenden
technologie-orientierten Kapiteln. Sie fokussieren auf Tabletop Interfaces (also Schnitt-
stellen, deren Referenzrahmen Tischoberflächen sind) und Tangible Interfaces, die zur
Modellbildung eingesetzt werden. Die beiden Abschnitte stellen dabei die historische
Entwicklung und den State-of-the-Art aus Systemsicht dar und bilden so die technische
„related work“ zum im Folgenden beschriebenen Werkzeug.
6.7.1. Beitrag zur globalen Zielsetzung
Dieses Kapitel trägt die konzeptuellen Grundlagen zur Bearbeitung des Werkzeug-Aspektes
im Rahmen der Beantwortung von Fragestellung 4 („Wie kann ein Instrument zur Unter-
stützung von expliziter Articulation Work umgesetzt werden?“) bei. Die Beschäftigung
mit diesen Grundlagen in den Abschnitten 6.2 und 6.3 ist notwendig, um auf Basis der
in Kapitel 5 angeführten Technologieentscheidung für die Verwendung eines „Tabletop
Interfaces“ für die Unterstützung der konzipierten Methodik dessen konkrete Ausgestal-
tung fundiert vornehmen zu können. In Abschnitt 6.6 werden interaktive Systeme vor-
gestellt, die der vorgeschlagenen Methodik zugrundeliegende oder verwandte Methoden
unterstützen, so die aus technischer Sicht unmittelbare „Related Work“ dieser Arbeit
darstellen und damit ebenfalls zur Beantwortung der Fragestellung 4 beitragen.
Eine Voraussetzung zur effektiven Unterstützung von „Articulation Work“ ist wie
in Kapitel 1 argumentiert eine effektive Verwendbarkeit der konzipierten Instruments.
Während für deren Beurteilung notwendigen Messkriterien bereits in Kaptitel 5 iden-
tifiziert wurden, kann die zu erwartende Verwendbarkeit auch auf Basis konzeptueller
Überlegungen zur Gestaltung von „Tangible Interfaces“ bzw. „Tabletop Interfaces“ er-
folgen. In diesem Sinne trägt Abschnitt 6.4 insofern zu Fragestellung 5 („Wie kann
die Effektivität der Unterstützung von expliziter Articulation Work beurteilt werden?“)
bei, als dass in ihm die existierenden Arbeiten zur konzeptuellen Beschreibung bzw. zur
Gestaltung von „Tangible Interfaces“ aufgearbeitet werden und etwaige zu beachtende
Gestaltungsrichtlinien identifiziert werden können, deren Einhaltung in weiterer Folge
geprüft werden kann.
6.7.2. Weitere Verwendung der Ergebnisse
Die Ergebnisse dieses Kapitels bilden die Grundlage für die Durchführung der Konzepti-
on des Werkzeugs und der Benutzerinteraktion mit diesem in den Kapiteln 7 und 8 dar.
Während ein Großteil der Ergebnisse das Rahmenwerk für die Konzeption der Werk-
zeugs bildet, fließen einige Ergebnisse wie die Taxonomie nach Fishkin (2004) direkt in
das Design ein.
171
6.7. Zusammenfassung
Die Ergebnisse des Abschnitts 6.4 werden außerdem in Kaptitel 10 wieder aufgegriffen
und für die Beurteilung des Werkzeugs auf konzeptueller Ebene zur Identifikation von
etwaigen Schwachstellen oder Verbesserungspotential eingesetzt.
172
7. Eingabe und Interpretation
In diesem Kapitel wird jener Teil des Werkzeugs beschrieben, in dem die Interaktion
der Benutzer mit dem System erfasst und interpretiert wird. Abbildung 7.1 stellt dieses
Kapitel und dessen Aufbau im Kontext der anderen inhaltlich vor- und nachgelagerten
Kapitel dar.
Abbildung 7.1.: Kapitel „Eingabe und Interpretation“ im Gesamtzusammenhang
Der erste Abschnitt behandelt grundlegende Möglichkeiten zur Erfassung der Benut-
zerinteraktion auf Tabletop Interfaces und endet mit der Identifikation einer für den
Anwendungsfalls geeigneten Technologie. Diese wird durch die Beschreibung von da-
für verfügbaren Frameworks konkretisiert, was letztendlich in der Entscheidung für ein
konkretes Produkt mündet.
Basierend auf dieser Entscheidung wird in den darauf folgenden beiden Abschnitten
auf das Design der Hard- und Softwarekomponenten eingegangen, die unmittelbar der
Eingabe von Information durch Benutzer dienen. Der Ausgabeaspekt wird hier bewusst
173
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
ausgeklammert und im nächsten Kapitel beschrieben. Dieses Kapitel endet mit einer
Beschreibung der Interpretationsroutinen, die aus den durch das Framework gelieferten
Rohdaten höherwertige, anwendungsspezifische Information extrahieren und diese den
nachgeordneten Software-Modulen zur Verfügung stellen.
7.1. Möglichkeiten zur Erfassung von
Benutzerinteraktion
Im Gegensatz zu Systemen mit dezidierten Eingabegeräten (wie Tastatur oder Maus)
ist die Informationseingabe bei Tangible Interfaces unmittelbar an physische Tokens
gebunden, die unabhängig voneinander und gegebenenfalls auch simultan manipuliert
werden können. Diese Manipulation muss von einer vorhandenen Infrastruktur erfasst
und interpretiert werden. Der wesentliche Unterschied zu dezidierten Eingabegeräten
besteht darin, dass die Manipulation des physischen Artefakts selbst für den Benutzer
bedeutungstragend ist und nicht nur dem Zweck einer Zustandsänderung im digitalen
Informationsraum dient. Dies impliziert, dass der Zustand der verwendeten Tokens bzw.
der aktuelle Wert der relevanten Parameter (z.B. Position, Rotation, Form, . . . ) erfasst
werden können, ohne die Bedeutung der Tokens oder deren Manipulierbarkeit in der
realen Welt zu beeinträchtigen. Je nach Anwendungsfall kommen dafür mehrere un-
terschiedliche technologische Ansätze in Frage. Die Beurteilungskriterien die dabei zu
berücksichtigen sind, umfassen die zu erhebenden Parametern und die notwendige Er-
fassungsrate des Zustandes der Tokens sowie die Anzahl der simultan zu erfassenden
Tokens bzw. Parameter.
Im konkreten System muss – wie aus den Anforderungen in Kapitel 5 ableitbar – die
planare Position von mehreren Tokens in Echtzeit (d.h. mehrmals pro Sekunde mit für
den Benutzer nicht wahrnehmbaren Verzögerungen) erfasst werden. Neben der Positi-
on ist noch die Rotation eines Tokens als Raumparameter von Interesse. Bezüglich des
Zustands eines Tokens muss erfasst werden können, ob es geöffnet oder geschlossen ist
und ob es eingebettete Objekte enthält oder nicht. Mit diesen Anforderungen wird in
den folgenden Unterabschnitten ein technologischer Ansatz zur Umsetzung der Interak-
tionserkennung ausgewählt.
7.1.1. In Frage kommende technologische Ansätze
Bei der Auswahl möglicher technologischer Ansätze zur Erfassung der Benutzerinterak-
tion müssen die zu erfassenden Parameter unterschiedlich behandelt werden. Konkret
werden hier Ansätze zur Erfassung der Raumparameter (Position, Rotation) und An-
sätze, die Zustandsänderungen des Tokens erfassbar machen, unterschieden.
174
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Raumparameter
Zur Erfassung von Raumparametern von Tokens bieten sich mehrere technologische An-
sätze an. In Frage kommen für das konkrete Tabletop Interface nur Technologien, die
eine Erfassung dieser Parameter mit einer Genauigkeit im Zentimeter- bis Millimeter-
Bereich ermöglichen, da eine niedrigere Raumauflösung zu zu großen Ungenauigkeiten
in der Positionsbestimmung führt, die einen Einsatz für das hier vorgestellte Werkzeug
nicht erlaubt. Im Folgenden werden die in Frage kommenden Technologien in ihren
Grundzügen beschrieben und hinsichtlich ihrer Eignung für das konkrete System bewer-
tet.
Optisch Optische Positionsbestimmung erfolgt mit Hilfe von Kamera-Systemen und
Methoden der digitalen Bildverarbeitung. Die Kamera erfasst dabei die zu identifizie-
renden Tokens. Das resultierende Bild wird mit in Software umgesetzten Algorithmen
ausgewertet. Dadurch können zumindest Identität und Position, zumeist aber auch wei-
tere Raumparameter (wie Rotation) aller im Erfassungsbereich der Kamera befindlichen
Tokens ermittelt werden. Neben dem optischen Erfassungsbereich bestimmen zudem die
Auflösung der Kamera sowie die Größe der Tokens die letztendlich erfassbare Fläche.
Optische Systeme sind bei schlechten oder wechselnden Lichtverhältnissen generell eher
fehleranfällig und nicht robust gegen Verdeckungen von Tokens (etwa durch Gliedmaßen
oder andere Tokens).
Hinsichtlich des Identifikationsansatzes können zwei Arten von Systemen unterschie-
den werden. Codebasierte Systeme verwenden zur Identifikation eines Tokens einen von
der Kamera erfassbaren Code (etwa einen „Barcode“), der eindeutig einem Token zu-
geordnet werden kann. Featurebasierte Systeme identifizieren ein Token aufgrund seiner
äußeren Eigenschaften, zumeist über dessen Form (Schattenriss). Letztere bieten den
Vorteil, dass ein Token nicht durch das Anbringen eines zusätzlichen Codes optisch
verändert werden muss. Der größte Nachteil besteht in der Eigenschaft, dass nur To-
ken mit unterschiedlichen Formen eindeutig identifiziert werden können. Die eindeutige
Identifikation von mehreren Tokens einer Bauart ist bei featurebasierten Systemen nicht
möglich. Codebasierte Systeme verwenden zumeist nicht herkömmliche EAN1-Barcodes
sondern robustere Systeme, bei denen eine Erkennung auch unter widrigen Beleuch-
tungsbedingungen oder niedrigen Bildauflösungen möglich ist und die zum Teil auch die
Extraktion zusätzliche Information über weitere Raumparameter (wie Rotation, teilwei-
se auch Parameter der dritten Dimension wie Neigung oder Entfernung) ermöglichen.
Codebasierte Systeme können hinsichtlich der Art der Codierung der Identitätsin-
formation wiederum in zwei Klassen unterschieden werden. Eine Gruppe von Ansät-
zen integriert die eigentliche Nutzinformation, also im Wesentlichen die tokenspezifische
Identifikationsnummer, direkt in den Code und ermöglicht so ein direktes Auslesen der
1European Article Number
175
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Information (z.B. bei QRCode (ISO JTC1/SC31, 2006)). Die zweite Gruppe verwendet
eine indirekte Zuordnung zwischen Token-ID und Code. Bei derartigen Ansätzen muss
die Identität eines Tokens in einem Zwischenschritt über eine Mapping-Tabelle abge-
bildet werden, im Gegenzug ist die Ausgestaltung des Codes flexibler, im Allgemeinen
kann dabei eine höhere Robustheit bei der Erkennung erreicht werden (z.B. ARToolkit
(Kato et al., 2000)).
Kapazitiv Kapazitive Ansätze basieren auf der Änderung der Kapazität von Leiterbah-
nen, die durch deren Berührung mit leitfähigem Material verursacht wird. Ursprünglich
wurde die Technologie zur Umsetzung von berührungssensitiven Oberflächen entwickelt,
kann jedoch auch zum Tracking von Tokens verwendet werden. Im Gegensatz zu druck-
empfindlichen Oberflächen (klassischen „Touchscreens“) ist keine Druckausübung zur
Erkennung notwendig, es können außerdem auch mehrere Tokens (bzw. Finger) gleich-
zeitig erkannt werden.
Technologisch bedingt müssen bei kapazitiven Ansätzen alle zu identifizierenden Ob-
jekte die Oberfläche des Systems berühren. In dieser Oberfläche ist ein Metallgitter ein-
gebettet, zwischen dessen Adern eine elektrische Kapazität gemessen werden kann. Diese
Kapazität verändert sich, sobald die Adern berührt werden (wobei die Tokens in einen
entsprechend geeigneten Material ausgeführt sein müssen). Durch die lokale Änderung
der Kapazität kann die Position einer Berührung festgestellt werden. Die Genauigkeit
ist dabei durch die Rasterweite des Metallgitters beschränkt. Der größte Nachteil eines
kapazitiven Ansatzes ist in diesem Kontext aber, dass die Identität eine Tokens nicht
direkt festgestellt werden kann (die Kapazitätsänderung ist für alle Token identisch).
Zudem ist die Extraktion weiterer Raumparameter (wie Rotation) nicht bzw. nur mit
zusätzlichen Aufwand möglich. Die Vorteile von kapazitiven Systemen liegen in der hohen
Robustheit der Erkennung auch bei widrigen Umgebungseinflüssen (Lichtverhältnisse,
Schmutz) sowie der prinzipiell beliebig großen und beliebig geformten Oberfläche, die
zur Erkennung verwendet werden kann.
Kapazitive Systeme eignen sich also zur Positionsbestimmung, nicht aber zur Identifi-
kation von Tokens. Dies macht sie für den konkreten Anwendungsfall nur in Kombination
mit einer anderen Technologie geeignet.
Elektromagnetisch Die Ausstattung von Tokens mit elektromagnetisch erfassbaren
Einheiten (z.B. RFID-Chips) ermöglicht ebenfalls die Erfassung von Raumparametern.
Vorrangig eignet sich diese Technologie jedoch zur Identifikation von Tokens, die Posi-
tionsbestimmung kann nur mit erheblichem technischen Aufwand durchgeführt werden.
RFID-Chips (als Beispiel für einen elektromagnetischen Ansatz) sind passive Bauteile,
die bei Energieversorgung durch ein elektrisches Feld aktiv werden und ihrerseits eine
eindeutige Identifikationsnummer senden (im einfachsten Fall, komplexere Varianten
sind möglich, werden hier aber nicht betrachtet). Historisch stammt die Technologie aus
176
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
der Logistik und Warenwirtschaft und dient der Identifikation von Gütern und nicht der
exakten Positionsbestimmung. Diese ist somit auch nur mittels erweiterter Infrastruktur
möglich. Zum Auslesen eines RFID-Chips wird ein Lesegerät mit Antenne benötigt. Aus
der Feldstärke, mit der diese Antenne die Antwort des Chips empfängt, kann auf die
Entfernung des Chips von der Antenne geschlossen werden. Durch Kreuzpeilung mit
mindestens zwei Antennen, deren Position bekannt ist, kann somit auf die ungefähre
Position des Chips (und damit des Tokens, in das dieser eingebaut ist) geschlossen wer-
den. Durch den Einsatz von „Antennenarrays“ (matrixförmig angeordneten Antennen)
mit geringer Reichweite ist so eine verhältnismäßig exakte (Größenordnung einige cm)
Positionsbestimmung möglich. Die Feststellung der Ausrichtung eines Tokens (Rotation)
ist auf diesem Wege allerdings nicht möglich. Die Identifikation eines Tokens ist jedoch
unabhängig von Sichtkontakt und unmittelbarer Berührung und somit äußerst robust
gegen Umgebungseinflüsse.
Elektromagnetische Systeme eignen sich wegen des hohen technischen Aufwandes bei
gleichzeitig beschränkter Genauigkeit nur bedingt zur Feststellung von Raumparame-
tern. Durch die Ausrichtung auf Extraktion der Identitätsinformation ist der Ansatz
jedoch gut zur Kombination mit anderen Technologien wie kapazitiven Ansätzen geeig-
net, die ihre Stärken in der Bestimmung der Raumparameter haben.
Akustisch Akustische Ansätze zur Positionsbestimmung basieren im Allgemeinen auf
der Laufzeitmessung von Ultraschallwellen im Raum. Mit entsprechender Infrastruktur
ist damit in einem begrenzten Bereich eine hochexakte Feststellung der Raumparameter
in drei Dimensionen (Genauigkeit im mm-Berich) sowie die Identifikation von Tokens
möglich.
Ultraschallbasierte Techniken zur Positionsbestimmung basieren auf dem Einsatz von
Bakensendern an bekannten Positionen. Diese Sender werden zumeist an der Zimmerde-
cke montiert und senden periodisch einen Ultraschallimpuls aus. Dieser Impuls wird von
den Tokens (die in diesem Fall aktive Bauteile mit Stromversorgung sind) empfangen,
die daraufhin einen sie identifizierenden Impuls zurücksenden. Aus der Laufzeit zwischen
Absetzen des Sendeimpuls und Empfangen des Antwortimpulses bei verschiedenen Ba-
ken lässt sich so die Position des Tokens im Raum feststellen. Problematisch ist hierbei
jedoch die durch den auf sequentieller Zeitmessung basierenden Ansatz beschränkte An-
zahl von verfolgbaren Tokens, wenn Echtzeit-Ansprüche gestellt werden. Zudem ist der
Ansatz nicht robust gegen (akustisch) verdeckte Tokens. Eine Anfälligkeit gegenüber
anderen Störeinflüssen besteht nicht.
Für die Feststellung von Raumparametern sind ultraschall-basierte Systeme generell
ausgezeichnet geeignet. Auch die Identifikation von Tokens ist prinzipiell möglich. Bei der
Bewertung hinsichtlich des Einsatzes für Tabletop Interfaces ist jedoch zu bedenken, dass
eine drei-dimensionale Positionierung nicht zu den allgemeinen Anforderungen zählt und
177
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
nur in speziellen Anwendungsfällen sinnvoll sein kann. Zudem kann die Notwendigkeit
von stromversorgten Tokens einen Nachteil bzw. ein Hindernis beim Einsatz darstellen.
Bewertung Im konkreten Anwendungsfall ist die Feststellung der Identität sowie der
planaren Position und Rotation von mehreren Tokens in hoher Genauigkeit sowie in
Echtzeit gefordert. Aus oben genannten Gründen sind kapazitive und elektromagneti-
sche Systeme im Einzeleinsatz nur bedingt geeignet. Akustische Systeme sind für den
Anwendungsfall als zu aufwändig und unflexibel und stoßen außerdem bei der Anzahl
der simultan zu verfolgenden Tokens an ihre Grenzen.
Die Kombination von kapazitiven und elektromagnetischen Systemen ist grundsätzlich
eine Möglichkeit, die in Betracht gezogen werden könnte. Auch optische Systeme genü-
gen den Anforderungen und kommen damit in Frage. Der kombinierte Ansatz ist im
Vergleich mit optischen Systemen als robuster gegen Störeinflüsse aus der Umgebung zu
betrachten. Für optische Systeme sprechen hingegen die weitaus geringeren Aufwände
für Infrastruktur und Tokens sowohl bei Anschaffung als auch bei Wartung und Betrieb.
Durch die geringere Komplexität des Systems sind auch weniger potentielle Fehlerquel-
len vorhanden, was bei der Erstellung des Werkzeug-Prototypen hilfreich ist. Aufgrund
dieser Aspekte und einer vergleichbaren zu erwartenden Erkennungsleistung wurde für
den hier vorgestellten Anwendungfall die Entscheidung getroffen ein optisches System
zur Bestimmung der Positionsparameter sowie der Identität der Tokens einzusetzen.
Tokenzustand
Hinsichtlich des Tokenzustands sind im Kontext des hier vorgestellten Anwendungsfalls
Informationen zu erheben, die den Inhalt des Tokens betreffen. Wie in Abschnitt 7.2
beschrieben, sind die Modellierungs-Tokens als Container ausgeführt, die geöffnet und
geschlossen werden können und in die kleinere Tokens als Trägen von Zusatzinformati-
on hineingelegt werden können. Die Auswahl eines Ansatzes, der die Identifikation des
Öffnungs-Zustandes eines Tokens sowie dessen Inhalt erlaubt, ist Gegenstand dieses Ab-
schnitts. Dazu wird grundlegend zwischen dem Einsatz von passiven Tokens und aktiven
Tokens unterschieden. Passive Tokens besitzen keine zusätzliche Elektronik, die geforder-
ten Informationen können lediglich durch die bereits vorhandene (optische) Infrastruk-
tur festgestellt werden. Aktive Tokens werden hingegen mit zusätzlicher Elektronik zur
Zustandsbestimmung ausgestattet, was allerdings eine Energieversorgung jedes Tokens
bedingt.
Passive Token Bei passiven Tokens muss sichergestellt werden, dass die bereits vor-
handene Infrastruktur die Zustandsänderungen eines Tokens erfassen kann. Da die vor-
handene Infrastruktur auf optischen Technologien basiert, müssen sich alle Zustandsän-
178
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
derungen im äußeren – durch die Kamera erfassbaren – Erscheinungsbild eines Tokens
widerspiegeln.
Der Öffnungszustand eines Tokens kann durch Kameras einfach erfasst werden, wenn
sich – je nach eigesetzter Technologie – durch das Öffnen der Umriss des Tokens verändert
oder ein weiterer Code sichtbar wird bzw. der bestehende Code modifiziert wird. Diese
Anforderung kann also durch passive Tokens erfüllt werden.
Zur Erfassung des Inhalts eines Container-Tokens sind zwei Ansätze denkbar. Einer-
seits kann der Inhalt eines Tokens zu einem bestimmten Zeitpunkt erfasst werden, an-
dererseits ist auch eine Erfassung der Änderung des Tokeninhalts möglich (Erfassung
des Vorgangs von Hineinlegen und Herausnehmen). Diese beiden Möglichkeiten sind
hinsichtlich der Umsetzbarkeit mit passiven Token unterschiedlich zu beurteilen. Eine
Erfassung das aktuellen Tokeninhalts ist mit optischen Systemen nur schwer möglich.
Die einzige sich bietende Möglichkeit ist die Verwendung von transparenten Teilbereichen
der Außenfläche eines Tokens. Damit ist es grundsätzlich möglich, den Inhalt eines To-
kens mit einer externen Kamera zu erfassen. Sowohl bei feature- als auch code-basierten
Ansätzen sind jedoch Verdeckungen, Verzerrungen oder zu geringe Kameraauflösung
potentiell problematisch und machen diesen Ansatz für den praktischen Einsatz unge-
eignet.
Die Erfassung der Änderung des Tokeninhalts lässt sich mit optischen Systemen ein-
fach implementieren. So kann der Vorgang des Hineinlegens als auch des Herausnehmens
von einer Kamera erfasst werden. Die größte Herausforderung hierbei ist die Identifika-
tion des Tokens, das eingebettet wird. Hier kann es wiederum durch Verdeckungen zu
Erkennungsschwierigkeiten führen, was in diesem Fall einen permanent fehlerhaften Mo-
dellzustand zur Folge hat, der im Falle wiederholter Fehlerkennungen sogar inkrementell
zu größeren Abweichungen führen kann. Diesem Umstand kann lediglich durch eine
explizite Aktion des Benutzers Rechnung getragen werden, der das betreffende einzu-
bettende Token ins Sichtfeld der Kamera halten muss, bis das System Feedback über
eine erfolgreiche Erkennung gibt. Diese Lösung ist allerdings hinsichtlich der Anforde-
rung, die Technologie für den Benutzer vollkommen in den Hintergrund treten zu lassen,
suboptimal.
Aktive Token Aktive Tokens beinhalten zusätzliche Sensorik, die die Erfassung des To-
kenzustands ermöglicht. Derartige Tokens benötigen allerdings eine Energieversorgung
und müssen über eine Möglichkeit zur Datenübertragung verfügen um den Tokenzustand
an das System zu übermitteln. Weiters ist im Allgemeinen eine Steuereinheit notwendig
um die Sensoren zu kontrollieren, die Daten zu aggregieren und letztendlich zu übertra-
gen.
Im konkreten Fall einer optisch arbeitenden Infrastruktur bietet sich eine (ggf. auflad-
bare) Batterie als Energiequelle an, um im Kamerabild Verdeckungen durch ansonsten
eventuell zu verwendende Kabel zu vermeiden. Eine Stromversorung über die Oberfläche
179
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
(wie z.B. im Pin & Play System (Van Laerhoven et al., 2003) vorgestellt) scheidet hier
aus, da die Blöcke dann mit Krafteinsatz auf die Oberfläche gesetzt werden müssten und
nicht verschoben werden können.
Als Steuerungseinheit bieten sich neben selbst auf der Basis von Mikrocontrollern wie
dem PIC oder 8051 (James, 1997) konzipierten Systemen auch Plattformen an, die ex-
plizit für den Anwendungszweck der Ansteuerung von Sensoren oder Aktuatoren und
der Kommunikation mit einem Basissystem gefertigt werden. Exemplarisch kann hier
die Smart-ITs-Plattform (Gellersen et al., 2004) angeführt werden, die neben der flexi-
blen Ansteuerbarkeiten von unterschiedlichen Sensoren bereits Module zur Vernetzung
untereinander und mit zentralen Diensten in der Infrastruktur anbietet.
Aus den eben angeführten Gründen ist zur Datenübertragung eine drahtlos arbeiten-
de Technologie am geeignetsten. Aufgrund der geringen benötigten Reichweite und der
Anforderung möglichst energieeffizient zu arbeiten, bieten sich die Technologien „Blue-
tooth“ (Bluetooth SIG, 2007) und „ZigBee“ (ZigBee Alliance, 2007) an. Bluetooth er-
reicht höhere Übertragungsraten, ist aber in der Anzahl der gleichzeitig verwendbaren
Geräte (max. 7) für den hier vorgestellten Anwendungsfall zu beschränkt. Ein ZigBee-
Netz kann mit bis zu 255 Geräten gleichzeitig arbeiten und ist außerdem im Einsatz
energiesparender. Für den gegebenen Anwendungsfall erschiene also ZigBee als geeig-
nete Technologie (und wurde auch bereits in (Ferscha et al., 2008) in einem ähnlichen
Anwendungsfall erfolgreich eingesetzt).
Zur Feststellung des Öffnungsstatus eines Container-Tokens bieten sich bei aktiven
Sensortechnologien mehrere Möglichkeiten an. Der Einsatz eines Schaltelements, das
beim Öffnen den Kontakt herstellt oder unterbricht, ist eine nahe liegende Lösung. Auch
der Einsatz eines Drehelements am Angelpunkt des Öffnungsschaniers, dessen elektrische
Eigenschaften (z.B. Widerstand oder Kapazität) sich mit dem Öffnungswinkel ändern,
kann angedacht werden. Damit ist nicht nur eine Unterscheidung zwischen den Zustän-
den „offen“ oder „geschlossen“ sondern auch die Identifikation von Zwischenzuständen
möglich.
Der Inhalt eines Container-Tokens kann ebenfalls mit unterschiedlichen Technologien
erfasst werden. Die Zielsetzung ist hier nicht der Positionsbestimmung der eingebet-
teten Tokens sondern lediglich die Feststellung der Identität. Naheliegend ist hierzu
der Einsatz von elektromagnetischen Ansätzen wie oben beschrieben. Durch das An-
bringen von z.B. RFID-Chips an den einzubettenden Tokens sowie eines Lesegeräts im
Container-Token kann die Identifikation robust durchgeführt werden. Alternativ bieten
sich Systeme an, die auf Gewichtsmessung basieren. Über einen in das Container-Token
eingebauten Sensor wird dabei das Gesamtgewicht der eingebetteten Tokens bestimmt.
Bei entsprechender Konzeption der einzubettenden Tokens (unterschiedliche Gewichte)
kann aus dem Gesamtgewicht auf die tatsächlich enthaltenen Tokens geschlossen werden.
Ein Nachteil dieses Ansatzes ist die beschränkte Anzahl von erfassbaren Tokens und die
180
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
notwendige exakte Fertigung jedes einzelnen Tokens, da es bei Gewichtsabweichungen
zu Fehlerkennungen kommt.
Bewertung Hinsichtlich der erreichbaren Flexibilität und zu erwartenden Servicequa-
lität ist in diesem Abschnitt eine Entscheidung zugunsten aktiver Tokens zu treffen. Im
Gesamtkontext betrachtet und unter Berücksichtigung der Entscheidung für optische
Systeme zur Bestimmung der Positionsparameter ist diese Wahl jedoch zu relativieren.
Wie oben beschrieben, erlaubt eine auf optischen Systemen beruhende Infrastruktur
grundlegend die Umsetzung der geforderten Funktionalität. Gleichzeitig wird die Kom-
plexität des Systems massiv reduziert und die Erstellung zusätzlicher Tokens vereinfacht
(da keine zusätzliche Elektronik notwendig ist). Der Wegfall von Energieversorgung und
Sensorlogik in den Token reduziert deren Gewicht und ermöglicht gleichzeitig mehr Platz
für einzubettende Tokens.
Für den hier beschriebenen Anwendungsfalls bzw. die prototypische Umsetzung des
Werkzeugs wird deshalb auf aktive Tokens verzichtet und der Einsatz von passiven To-
kens bevorzugt. Der Mehraufwand in Erstellung und Wartung des Systems beim Einsatz
aktiver Tokens wiegt in der Gesamtheit betrachtet die zu erwartende höhere Erkennungs-
qualität nicht auf.
7.1.2. In Frage kommende Frameworks
Unter Anbetracht der im vorherigen Abschnitt getroffenen grundlegender Technologie-
entscheidung zugunsten optischer Erkennungstechnologie mit passiven Tokens werden
nun unterschiedliche Frameworks betrachtet, die die Umsetzung dieses Ansatzes erlau-
ben. Dabei sind zwei Klassen von Frameworks zu unterscheiden:
Generische Frameworks für Tangible Interfaces ermöglichen generell die Koordination
von Services, die die Kopplung von Sensoren und Aktuatoren mit Interpretations-Logik
und letztendlich konkreten Applikationen erlauben. Sie gehen dabei nicht auf konkrete
Sensortechnologien (wie die hier verwendeten optischen Ansätze) ein sondern versuchen
eine Abstraktionsebene einzuführen, die die Applikationen von der konkreten Technolo-
gie entkoppelt und damit flexibler macht.
Frameworks für video-basierten Input für Tangible Interfaces sind spezialisierte Pro-
dukte, die konkret für die Umsetzung von optischen Ansätzen zur Eingabe von Daten bei
Tangible Interfaces ausgelegt sind. Durch die Spezialisierung auf optische Identifikation
liegt ihr Vorteil im geringeren technischen Aufwand bei der Einrichtung und auch wäh-
rend des Betriebs. Echtzeit-Anforderungen sind oft nur mit spezialisierten Frameworks
zu erfüllen. Eine Kombinationsmöglichkeit zwischen Produkten der beiden Kategorien
ergibt sich beim Einsatz eines spezialisierten Frameworks als Eingabe-Modul für eine
generisches Framework. Durch diesen Ansatz kann die einfache Inbetriebnahme spe-
181
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
zialisierter Frameworks mit der Flexibilität generischer Frameworks zusammengeführt
werden.
Generische Frameworks
Generische Frameworks zur Behandlung von Input und Output bei Tangible Interfaces
sind historisch nicht exakt von anderen Frameworks abzugrenzen, die im Umfeld des
Ubiquitous bzw. Pervasive Computing (Weiser, 1991) entwickelt wurden. Von konkre-
ter Technologie abstrahierende Frameworks wurden erstmals im Zusammenhang mit
„Context-aware Computing“ (Schilit et al., 1994) erwähnt, um Applikationen die Mög-
lichkeit zu bieten Information aus der Umgebung über beliebige Sensoren zu erfassen,
diese zu aggregieren und zu interpretieren. Aufbauend auf dieser Interpretation sollen
Aussagen über den aktuellen Zustand der Umgebung (den „Kontext“) getroffen werden
können, die die Applikationen wiederum zur Adaption benutzen können. Der Rück-
kanal, also die Ansteuerung von Aktuatoren, wurde erst in späteren Entwicklungen
berücksichtigt. Ein Großteil der Systeme dient explizit nicht der Erstellung von markt-
reifen Applikationen sondern widmet sich eher der Umsetzung von „Rapid Prototyping“-
Ansätzen im Bereich der Tangible Interfaces. Begründet wird dies mit der oft subop-
timalen Ressourcen-Ausnutzung, die mit der Generalisierung und Flexiblisierung des
Frameworks einhergeht.
Die Aufzählung der hier beschriebenen Frameworks erhebt keinen Anspruch auf Voll-
ständigkeit. Bei der Auswahl wurde darauf geachtet, historische bzw. für den konkreten
Anwendungsfall geeignete Ansätze aufzunehmen und in ihren wesentlichen Eigenschaf-
ten zu beschreiben.
Context Toolkit Das Context Toolkit (Dey et al., 2001) ist das historisch erste Frame-
work, das versucht, die starre Verbindung zwischen Sensoren und Applikationslogik
aufzubrechen. Es führt eine konfigurierbare Schicht ein, die eine schnellere, generische-
re Applikationsentwicklung ermöglicht und die Wiederverwendung einmal entwickelter
Komponenten ermöglicht.
Konzeptuell existieren im Framework drei Arten von Komponenten: „Context Wid-
gets“, „Context Interpreters“ und „Context Aggregators“. „Context Widgets“ imple-
mentieren die Ansteuerung beliebiger Software- und Hardwaresensoren und sind für das
Sammeln von Information über die Umgebung zuständig. Sie vermitteln zwischen der
physischen Umgebung und den konzeptuell höher liegenden Komponenten, indem sie
die unverarbeiteten Kontextdaten mittels einer geeigneten Schnittstelle kapseln und be-
stimmte Funktionen zur ersten Auswertung der Rohdaten ausführen. Eine Anwendung
kann diese Daten verwenden, ohne dass sie Detailkenntnisse über die zugrunde liegenden
Sensortechnologien haben muss. „Context Interpreter“ aggregieren die Sensordaten zu
komplexeren Kontextinformationen d.h. sie konvertieren und interpretieren die Daten
182
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
mehrerer „Context Widgets“ und versuchen diese zu einheitlichen Clustern zusammen-
zufassen. „Context Aggregators“ dient der Zusammenführung verschiedener Kontext-
informationen, die für bestimmte Anwendungen relevant sind. „Context Aggregators“
bilden damit die Schnittstelle zu den eigentlichen Applikationen.
Das Context Toolkit bietet nicht nur eine Softwareschnittstelle zu physischen Sensoren,
es trennt auch die Akquisition und Repräsentation von der Auslieferung der Daten an
kontextsensitive Applikationen.
SiLiCon Context Framework Das SiLiCon Context Framework (Beer et al., 2003) ist
ein Vertreter jener Klasse von Frameworks, deren Verhalten zur Laufzeit dynamisch kon-
figurierbar ist. Dies bedeutet im konkreten Fall, dass Applikationen, die auf Basis des
SiLiCon Context Framework erstellt wurden, ihr Verhalten und ihren Aufbau aufgrund
eintretender Ereignisse verändern können. Dies betrifft sowohl das Aktivieren und Deak-
tivieren von Input- und Output-Kanälen also auch die Veränderung der Interpretation
der eingehenden Information und die Reaktion darauf. Das Framework wurde entworfen
um Szenarien beschreiben zu können, in denen interaktive Systeme kontextsensitiv –
d.h. abhängig vom aktuellen Zustand ihrer Umwelt – reagieren müssen.
Die grundlegenden Bausteine des SiLiCon Context Framework sind „Entitäten“, die
Objekte der realen Welt konzeptuell abbilden. Diese „Entitäten“ besitzen „Attribute“,
also Eigenschaften, mit Hilfe derer die Entität näher beschrieben wird. Über „Attri-
bute“ kann die Wahrnehmung einer „Entität“ von deren Umwelt sowie deren Interak-
tionsmöglichkeiten mit derselben beschrieben werden. Mit Hilfe von ECA-Regeln wird
beschrieben, auf welche Wahrnehmung der Umwelt („Event“) eine Entität unter welchen
Bedingungen („Condition“, formuliert auf Basis des internen Zustands der Entität) mit
welchen Aktivitäten („Acti“on) reagiert. Diese Regeln können zur Laufzeit dynamisch
verändert und nachgeladen werden. Außerdem ist es möglich, in „Actions“ das Nachladen
von Entitäten oder das Hinzufügen oder Entfernen einzelner Attribute durchzuführen
(Oppl, 2004, S. 90).
Das SiLiCon Context Framework abstrahiert durch seine konzeptuelle Struktur mit
dem Einsatz von „Entitäten“ und „Attributen“ nicht so stark von der realen Welt wie
das zuvor beschriebene Context Toolkit – die Abbildung ist im ersten Schritt „direk-
ter“ und muss erst im zweiten Schritt technisch konkretisiert werden, ein klassischer
Softwareengineeringprozess (im Sinne von „Analyse – Design – Implementierung“) wird
damit vollständiger (auch in den ersten Phasen) durch das Framework abgebildet und
unterstützt.
Papiermaché Papiermaché (Klemmer et al., 2004) ist eines der ersten Rapid Prototyp-
ing Frameworks, die dezidiert zur Entwicklung von Tangible Interfaces entworfen wur-
den. Es fokussiert auf die Anbindung von Inputtechnologien für passive Objekte (RFID
oder optische Ansätze) und stellt Applikationen eine abstrahierte Sicht auf die reale Welt
183
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
zur Verfügung (in Form einer Repräsentation der erfassten Objekte als „Phobs“ – Phy-
sical Objects –, die die für die jeweilige Applikation relevanten Daten kapseln). Andere
Eingabekanäle sind in der zur Verfügung stehenden Implementierung nicht vorgesehen
– die Einordnung als generisches Framework ist aufgrund der übrigen Architektur trotz-
dem gerechtfertigt. Der Benachrichtigungsmechanismus erfolgt wie im Context Toolkit
ereignisgesteuert – d.h. jede Änderung der erfassten Umgebung generiert ein Ereignis
im Framework, das an die weiterverarbeitende Applikation weitergeleitet wird.
Im Sinne des Rapid Prototyping stellt Papiermaché als einziges hier betrachtetes
Framework eine Art Entwicklungs- und Laufzeitumgebung für Tangible Interfaces zur
Verfügung. Mittels dieser können Applikationsentwickler etwa Eingabekanäle auswählen
und die Interpretation der Rohdaten zur Laufzeit konfigurieren. Die Entwicklungsum-
gebung macht die zugrundeliegende Hardware für den Entwickler dabei transparent, er
muss sich also nicht um die Details der technischen Anbindung kümmern, ist dafür aber
auf die bereits implementierten Hardware-Schnittstellen beschränkt. Die Interpretation
der Daten beschreibt der Entwickler in Source Code, der über definierte Schnittstellen
in das Framework eingebunden wird. Über ein Monitoring-Interface kann die Arbeit des
Frameworks zur Laufzeit beobachtet werden um so z.B. Fehlverhalten oder ineffiziente
Konfigurationen aufzudecken.
Papiermaché versucht mittels der Integration von vorgegebenen Eingabekanälen, die
konfiguriert werden können, einen Teil der Komplexität bei der Entwicklung von Tangi-
ble Interface abzumildern. Der übrige konzeptuelle Aufbau ähnelt dem Context Toolkit
– Interpretation der Daten und Verwendung in einer Applikation sind konzeptuell ge-
trennt. Papiermaché ist in seiner Ausrichtung auf den Einsatz für Tangible Interfaces
ausgelegt, die auf der Manipulation von einzelnen physischen Objekten und der Bezie-
hungen zwischen diesen beruht. Es ist damit nicht so flexibel einsetzbar wie die anderen
betrachteten Frameworks, ist aber für den hier vorgestellten Anwendungsfall grundsätz-
lich geeignet.
TUIpist Das TUIpist-Framework (Furtmüller, 2007) wurde im Zusammenhang mit
der hier vorgestellten Arbeit entwickelt (Furtmüller und Oppl, 2007). TUIpist verfolgt
einen ähnlich modularen Ansatz wie die anderen hier vorgestellten Frameworks, setzt
jedoch zur Koordination der Module untereinander einen daten-zentrierten Ansatz – auf
dem LINDA-Konzept (Carriero und Gelernter, 1989) beruhende Tuplespaces – ein. Die
konzeptuelle Modulstruktur ist ähnlich der Aufteilung, die bereits von Dey et al. (2001)
im Context Toolkit vorgeschlagen wurde.
Die grundlegenden Module, die im Framework verwendet werden, sind „Sensoren“,
„Aggragtoren“ und „Anwendungen / Aktuatoren“ (siehe Abbildung 7.2). „Sensor“-Module
binden externe Datenquellen an das Framework an. Sie enthalten dazu eine sensor-
spezifische Komponente, die die Schnittstelle zur jeweiligen Hard- bzw. Software bildet.
Über diese Schnittstelle gelieferte Daten werden in einer zweiten Komponente vorverar-
184
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
beitet und soweit abstrahiert, dass die Datenrepräsentation unabhängig von der die Da-
ten liefernden Sensortechnologie ist (z.B. Abbildung von GPS2-Koordinaten auf logische
Positionsinformation, die auch aus anderen Quellen stammen könnte). „Aggregatoren“
fassen die Information mehrerer „Sensor“-Module zusammen und interpretieren ggf. ein-
ander ergänzende oder auch widersprechende Information. Sie werden immer aktiv, wenn
neue Sensordaten zur Verfügung stehen und aktualisieren dabei die Information über den
Gesamtzustand der den Framework bekannten Umwelt. „Anwendungen / Aktuatoren“
bilden letztendlich die Schnittstelle zu konkreten Applikationen, die ihr Verhalten an
den aktuellen Umweltzustand anpassen bzw. diesen darstellen oder Aktuatoren, die ba-
sierend auf dem aktuellen Umweltzustand Aktionen in dieser setzen. „Anwendungen /
Aktuatoren“ filtern dabei wieder den von „Aggregatoren“ gelieferten Gesamtzustand der
bekannten Umwelt und liefern nur die für die Applikation relevanten Daten aus. Dabei
kann erneut eine Nachverarbeitung der Daten, z.B. im Sinne einer Anpassung an eine
externe Schnittstelle, erfolgen.
Abbildung 7.2.: Architektur des TUIpist-Framework (eigene Abbildung übernommen
aus (Furtmüller und Oppl, 2007))
Die Verbindung der Komponenten erfolgt wie erwähnt datenzentriert. Eine wesent-
liche Eigenschaft dieses Ansatzes ist, dass keine explizite Verknüpfungen zwischen den
Modulen definiert werden. Die Zuordnung erfolgt vielmehr indirekt durch die Daten
selbst. Jedes Modul kann Datensätze („Tuple“) in einem definierten Format generieren
und in einen gemeinsam genutzten Datenraum – den „Tuplespace“ – stellen. Andere
Module können nun Anfragen an den „Tuplesp“ace stellen, ob Daten, deren Struktur
oder Inhalt gewissen Kriterien entspricht, vorhanden sind. Ist dies der Fall, können diese
Daten aus dem „Tuplespace“ entnommen werden und nach erfolgter Verarbeitung in
modifizierter Form wieder eingestellt werden (siehe Abbildung 7.3). Das „Tupel“space-
Konzept erlaubt auch eine dynamische Erweiterung bzw. Veränderung sowohl der Ein-
2Global Positioning System
185
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
und Ausgabekanäle als auch der internen Datenverarbeitung zur Laufzeit, indem zusätz-
lich Module am „Tupelspace“ registriert werden. Durch die lose Koppelung der Module
muss keine zusätzliche Konfiguration an anderen Modulen oder am „Tuplespace“ selbst
vorgenommen werden.
Abbildung 7.3.: Zusammenspiel der Komponenten in TUIpist (eigene Abbildung über-
nommen aus (Furtmüller und Oppl, 2007))
Die Implementierung von TUIpist auf Basis des Java Jini-Frameworks (Arnold et al.,
1999) ermöglicht eine Verteilung der einzelnen Module einer Applikation auf unterschied-
liche Rechner (im Sinne eines „verteilten Systems“ (Stary, 1994)) ohne zusätzlich vom
Implementierer zu berücksichtigenden Koordinationsaufwand. Es können damit auch
(räumlich) entfernte Sensoren oder Webapplikationen angebunden werden und der ggf.
auftretende Rechenaufwand zur Aggregation oder Interpretation von Daten auf mehrere
Rechner verteilt werden.
Frameworks für video-basierten Input
Im Gegensatz zu den eben beschriebenen generischen Frameworks wurden die hier vor-
gestellten Frameworks explizit für die Behandlung von video-basiertem Input entwickelt.
Wie oben bereits erwähnt, stehen die hier beschriebenen Frameworks mit den eben an-
geführten generischen Frameworks insofern in Zusammenhang, als dass sie zumeist als
Sensor-Komponente in generischen Ansätzen eingesetzt werden können. In ihrer grund-
legenden Ausrichtung sind sie jedoch zumeist für den unmittelbaren Einsatz in einer
Endanwendung konzipiert.
Die hier vorgestellten Systeme implementieren den Ansatz des code-basierten opti-
schen Trackings. Feature-basierte Ansätze kommen im konkreten Anwendungsfall nicht
in Frage, da zur Modellierung eine Vielzahl von gleichartigen Objekten eingesetzt werden,
die sich in ihrem äußeren Erscheinungsbild nicht unterscheiden und damit in feature-
basierten Ansätzen nicht eindeutig identifiziert werden können.
186
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Wie bereits im letzten Abschnitt erhebt auch die hier angeführte Aufzählung keinen
Anspruch auf Vollständigkeit. Neben der Darstellung der historischen Entwicklung des
Feldes und der Beschreibung von in Forschung und Praxis relevanten Ansätzen wurde bei
der Auswahl vor allem auf freie Verwendbarkeit und Zugriff auf den Source-Code der Er-
kennungsroutinen geachtet, da die Notwendigkeit applikationsspezifischer Anpassungen
nicht auszuschließen war (etwa um benötigte aber nicht direkt unterstützte Parameter
zu extrahieren).
AR Toolkit Das AR Toolkit („Augmented Reality Toolkit“) (Kato et al., 2000) ist
historisch das erste in breitem Umfang eingesetzte Framework zur optischen Identifika-
tion von Elementen in der realen Welt. Das AR Toolkit verwendet zur Identifikation
Marker, in die selbst keine Information codiert ist, und eine Mapping-Tabelle zur Ver-
knüpfung mit digitaler Information. Die Marker des AR Toolkit (siehe Abbildung 7.4)
werden durch Mustererkennung identifiziert und weisen bis auf den schwarzen Rahmen,
der einen Marker begrenzt, keine verpflichtenden Elemente auf. Die Form der Marker
ist also vorgegeben, ihr Inhalt kann frei gestaltet werden, zur Identifikation ist es aber
notwendig, das die zu erkennenden Marker im Vorhinein beim Framework registriert
werden.
Abbildung 7.4.: AR Toolkit Marker (Quelle: www.hitl.washington.edu/artoolkit/)
Das AR Toolkit ist auf die Verwendung in Anwendungen im Bereich der Augmented
Reality ausgelegt und liefert die aus dem Bild extrahierte Information in einer Form, die
eine Weiterverarbeitung mittels Frameworks aus dieser Domäne möglich macht. Kon-
kret werden Raumparameter als Transformationsmatrizen ausgegeben, die eine direkte
Umsetzung der Information in eine Darstellung mittels OpenGL ermöglichen. Die Anbin-
dung von Kameras an das Framework wird über plattformspezifische Treiber realisiert,
das AR Toolkit selbst empfängt einen Bildstrom, den es auswertet. Die Erkennungs-
software ist in C implementiert, bietet aber Wrapper für andere Programmiersprachen
(unter anderem Java). Sie wird als Bibliothek in die eigentliche Applikation eingebunden.
Visual Codes Das Visual Codes System (Rohs, 2005) ist ein Vertreter der direkt co-
dierenden Ansätze, d.h. dass die Nutzinformation ohne Zwischenschritt direkt aus dem
Code extrahiert werden kann. Im Gegensatz zu den standardisierten und kommerzi-
ell genutzten Code-Formate QR-Code (ISO JTC1/SC31, 2006) oder Datamatrix (GS1,
187
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
2008), die eine Kapazität von bis zu einigen hundert Byte haben, bietet das Visual Code
System lediglich 83 Bits an Nutzinformation an (siehe Abbildung 7.5), was dazu führt,
das in vielen Anwendungsfällen ein Mapping durch die Anwendung durchgeführt wird,
um die zu verwaltende Information abbilden zu können.
Abbildung 7.5.: Visual Codes – Aufbau und Features (übernommen von Rohs und Gfel-
ler (2004))
Der Vorteil des Visual Code Systems liegt in der Auswertbarkeit einer Vielzahl von
Raumparametern bei gleichzeitig geringem Bedarf an Rechenkapazität. In der Stan-
dardimplementierung werden neben der Position und der Rotation in der Ebene auch
die Neigungsparameter im Raum extrahiert. Der Erkennungsalgorithmus läuft dabei in
Echtzeit und kann unverändert sogar auf Java-fähigen Mobiltelefonen ausgeführt wer-
den. Durch die relativ geringe Datendicht der Codes reichen dementsprechend auch
verhältnismäßig niedrig auflösende Bilder (z.B. 320 x 240 Bildpunkte) für eine Erken-
nung aus. Wie alle anderen optischen Ansätzen leidet das Visual Code System unter
Erkennungsproblemen bei wechselnden Lichtverhältnissen und insbesondere bei schlech-
tem Kontrast. Diese Verhalten kann in der vorliegenden Implementierung auch nicht
durch Anpassung der Kameraparameter (Bildverstärkung o.ä.) korrigiert werden.
Das Visual Code System muss von auf ihm aufbauenden Applikationen direkt auf
Source-Code-Ebene eingebunden werden, eine vorgegebene externe Schnittstelle existiert
nicht. Anbindungsroutinen für Kameras existieren nur für Mobiltelefone und müssen für
andere Plattformen ggf. neu erstellt werden.
ReacTIVision ReacTIVision (Kaltenbrunner und Bencina, 2007) ist ein frei verfügba-
res Framework zu optischen Erkennung von Codes in Echtzeit. ReacTIVision arbeitet mit
proprietären Codes (siehe Abbildung 7.6), in denen die Information nicht an bestimmte
Positionen sondern im Wesentlichen in die Anzahl und Schachtelung der Schwarz-Weiß-
Übergänge codiert ist. Der Umfang der direkt in einen Marker codierbaren Informati-
on ist damit beschränkt und nicht direkt auf ein binäres Codierungsschema abbildbar.
Deswegen wird ein Mapping-Ansatz verwendet, um die eigentliche Nutzinformation auf
Codes abzubilden. Grundsätzlich ist jedoch die direkte Codierung eine beschränkten
Anzahl von Bits möglich, ist aber in der aktuellen Implementierung nicht unmittelbar
vorgesehen.
188
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Durch die Art der Informationscodierung ist die Erkennungsleistung von ReacTIVision
auch unter schlechten Lichtbedingungen oder bei verzerrtem Eingangsbildern akzeptabel
bis sehr gut. Die Form der Codes ist außerdem nicht vorgegeben, sie kann frei gewählt
werden. Sogar händisch gezeichnete Codes können erkannt werden, da ausschließlich eine
geschlossene Außenlinie und entsprechende Schwarz-Weiß-Übergänge innerhalb dieser
Linie erfassbar sein müssen.
Abbildung 7.6.: ReacTIVision Code
Die ReacTIVision-Software ist plattformübergreifend für Windows, Linux und Mac
OS X verfügbar. Sie greift über plattformspezifische Schnittstellen auf eine angeschlos-
sene Kamera zu und wertet das empfangene Bild in Echtzeit aus. Dabei sind bei einer
Kameraauflösung von 1024 x 768 Bildpunkten Bildraten von 15-20 Bildern pro Sekunde
erreichbar. Diese Leistung wird auch durch eine höhere Anzahl von gleichzeitig im Bild
vorhandenen Codes nicht merklich geringer.
Neben der Position der Codes wird auch deren aktuelle Rotation sowie die erste Ablei-
tung dieser drei Parameter (also ein Maß für die Bewegung) extrahiert. Zudem können
Finger, die die Oberfläche berühren, erkannt und deren Position extrahiert werden. Dies
ist auch für mehrere Finger möglich, wobei eine eindeutige Zuordnung über die Zeit
erhalten bleibt und so rudimentäre Multitouch-Funktionen umgesetzt werden können.
Als problematisch stellt sich wie auch bei allen anderen betrachteten optischen Ansät-
zen die Abhängigkeit der Erkennungsqualität von der Umgebungsbeleuchtung bzw. deren
Änderung über die Zeit dar. ReacTIVision arbeitet mit adaptiven Filteralgorithmen zur
Aufbereitung des Bildes, was jedoch nur leichte Beleuchtungsschwankungen ausgleichen
kann. Die Software kann manuell an die Beleuchtungsverhältnisse angepasst werden
(Einstellung der Blendenöffnung und der Bildverstärkung), bei sich ändernden Licht-
verhältnissen muss jedoch regelmäßig eine Nachführung der Parameter vorgenommen
werden.
Die aus dem Bilderstrom gewonnenen Daten werden im Falle einer Änderung zumin-
dest eines Wertes über eine Netzwerkschnittstelle (UDP-basiert) in einem proprietären
Protokoll zur Verfügung gestellt. Zu diesem Protokoll werden Schnittstellen und Re-
ferenzimplementierungen in unterschiedlichen Programmiersprachen – unter anderem
C(++) und Java – zur Verfügung gestellt. Applikationen können diese Schnittstelle
189
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
implementieren und werden mittels sechs zu implementierenden Methoden an die Er-
kennungsroutinen angebunden (je 3 für Code- und für Fingertracking).
7.1.3. Technologieentscheidung
Auf Basis der Anforderungen, die im Anwendungsfall an das Werkzeug gestellt werden,
ist nun nach der grundsätzlichen Entscheidung für ein auf optischen Ansätzen basieren-
den System die Entscheidung für ein konkretes Framework zu treffen.
Vergleich der Frameworks für videobasierten Input
Für die Anbindung von videobasiertem Input wurde drei Frameworks vorgestellt. Diese
Frameworks sind nun hinsichtlich mehrere Aspekte zu vergleichen, die sich aus den Anfor-
derungen der zu erstellenden Applikation sowie der Forderung nach möglichst einfacher
(im Sinne von weniger aufwändig) Einbindung des Frameworks ergeben. Im Einzelnen
sind dies
• die Unterstützung bei der Einbindung von Kameras und eine Schnittstelle zur
Programmiersprache Java,
• eine stabile und in Echtzeit ablaufende Bilderkennung,
• eine ausreichende Anzahl von Codes (Größenordnung 100),
• die Extraktion von Position und Rotationsinformation für Codes im Erfassungs-
bereich der Kamera,
• die Art der Kopplung von Framework und darauf aufbauender Applikation, sowie
• die technische und lizenzrechtliche Möglichkeit, die Frameworks an die eigenen
Anforderungen anzupassen.
ReacTIVision bietet die umfassendste Unterstützung zur Einbindung unterschiedli-
cher Videoquellen und ist zur Anwendungsseite hin durch die Netzwerkschnittstelle am
flexibelsten einsetzbar. Alle drei Ansätze bieten Schnittstellen bzw. Konnektoren für die
Programmiersprache Java an. Die Frameworks selbst sind in C(++) oder Java erstellt
und können auf den gängigen Plattformen (Windows, Linux, Mac OS x) ausgeführt wer-
den. Eine Verteilung der Applikation auf mehrere Rechner wird nur von ReacTIVision
explizit unterstützt.
Hinsichtlich der eigentlichen Bilderkennungs-Routinen sind die Ansätze in ihrer Leis-
tung und Geschwindigkeit vergleichbar, leiden aber alle unter der Abhängigkeit von der
Umgebungsbeleuchtung. ReacTIVision bietet hier als einziger Ansatz die Möglichkeit,
Kameraparameter zur Laufzeit nachzuführen und so Schwankungen der Umgebungshel-
ligkeit auszugleichen.
190
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Durch den eingesetzten Mapping-Ansatz sind AR Toolkit und ReacTIVision hinsicht-
lich Form und Inhalt der Codes flexibler als direkt codierende Ansätze wie Visual Codes.
Dies ist im konkreten Anwendungsfall relevant, da aufgrund der Token-Form und deren
beschränkter Größe eine ideale Platzausnutzung erfolgen muss, um ausreichende Erken-
nungsleistung zu gewährleisten.
Die Extraktion der Raumparameter (Neigungsinformation, . . . ), die von AR Tool-
kit und Visual Codes ermöglicht wird, ist bei tisch-basierten Werkzeugen wie dem hier
vorgestellten nicht notwendig – die Erhebung planarer Parameter (Position und Ro-
tation) ist ausreichend. AR Toolkit liefert aufgrund seiner Ausrichtung auf Augmented
Reality-Anwendung die Parameter in Form einer Transformationsmatrix, die für die Ver-
arbeitung in 3D-Umgebungen wie OpenGL direkt geeignet ist, im hier verfolgten Ansatz
jedoch einer zusätzlich Umrechnung auf das benötigte Parameterformat unterzogen wer-
den müsste.
Die Anzahl der verfügbaren und zuverlässig unterscheidbaren Codes muss für die hier
vorgeschlagene Anwendung in der Größenordnung 100 liegen. Visual Codes und Reac-
TIVision erfüllen diese Anforderung, AR Toolkit bietet im Lieferumfang weniger Codes
an, diese können jedoch erweitert werden und bieten auch in der geforderten Anzahl
noch ausreichend Unterscheidungsmerkmale für eine zuverlässige Unterscheidung (Wag-
ner und Schmalstieg, 2003).
Das AR Toolkit und Visual Codes müssen direkt über eine Einbindung von Biblio-
theken in die eigene Applikation integriert werden. ReacTIVision ist hier flexibler und
wird über einen Netzwerkport mit der Zielapplikation verbunden. Dies kommt dem hier
verfolgten Ansatz entgegen, da ein verteilter Betrieb aufgrund der hohen Rechenanfor-
derungen oder im Betrieb mit mehreren Ausgabegeräten notwendig werden kann.
Von AR Toolkit und ReacTIVision steht der Source-Code zur Verfügung. Lizenzrecht-
lich erlauben das AR Toolkit und ReacTIVision explizit eine Veränderung des Source-
codes unter der GNU Public Licence3 bzw. der Lesser GNU Public Licence4. AR Toolkit
verfolgt dabei einen Dual Licensing Ansatz, der einen kommerziellen Einsatz kosten-
pflichtig macht. Zu Visual Codes sind keine Lizenzinformationen erhältlich, auch der
Sourcecode steht nicht zum Download bereit.
Auf Basis der in Tabelle 7.1 angegeben Gegenüberstellung ist erkennbar, dass das
ReacTIVision-Framework für den hier verfolgten Ansatz am besten geeignet ist. Betrach-
tet man die funktionalen Anforderungen, sind zwar alle Frameworks grundsätzlich geeig-
net, die nicht-funktionalen Anforderungen – vor allem die plattform-übergreifende Ein-
setzbarkeit, die Möglichkeit zum verteilten Betrieb und die gute Unterstützung beliebi-
ger Kameras sowie deren Konfigurierbarkeit – sprechen für die ReacTIVision-Plattform.
Diese wird deshalb zur Umsetzung des Werkzeugs verwendet. Der zusätzliche Einsatz
3http://www.gnu.org/licenses/gpl-3.0.html
4http://www.gnu.org/licenses/lgpl-3.0.html
191
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Tabelle 7.1.: Gegenüberstellung der Frameworks für video-basierten Input
AR Toolkit Visual Codes ReacTIVision
Kamera-
unterstützung
nativ auf allen
unterstützten
Plattformen
(Interfaces &
Features treiber-
abhängig)
nativ nur für
Mobiltelefone
nativ auf allen
unterstützten
Plattformen
Plattformen Windows, Li-
nux, Mac OS
X
Java-basiert auf
allen Plattfor-
men
Windows, Li-
nux, Mac OS
X
Schnittstelle zu
Java
extern nativ ja
Stabilität der
Bilderkennung
abhängig von
den verwendeten
Markern
eher hoch hoch
Kompensations-
möglichkeit
bei schlechten
Lichtbedingun-
gen
nein nein ja
Geschwindigkeit
der Bilderken-
nung
> 10 fps > 10 fps > 10 fps
Anzahl von
gleichzeitig
erkennbaren
Codes
keine Einschrän-
kung
keine Einschrän-
kung
keine Einschrän-
kung
Erkennung von
Position
implizit ja ja
Erkennung von
Rotation
implizit ja ja
Kopplung von
Framework und
Applikation
eng eng lose
Source-Code
verfügbar
ja nein ja
Lizenz GPL, kommerzi-
ell
unbekannt GPL, LGPL
192
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
eines generischen Frameworks zur Flexibilisierung der Applikationsstruktur ist damit
nach wie vor möglich und wird im nächsten Abschnitt diskutiert.
Vergleich der generischen Frameworks
Der Einsatz eines generischen Frameworks ist im konkreten Anwendungsfall für die Mo-
dularisierung der Interpretations- und Output-Module denkbar. Eine weitere Anwen-
dung von generischen Frameworks ist die Sicherstellung der Skalierbarkeit der Anzahl
der Ausgabemodule ggf. auch während des Betriebs der Applikation (um z.B. weite-
re Viewer-Module zur Beobachtung des Modellierungsvorganges während der Laufzeit
zuschalten zu können). Die Aspekte die beim Vergleich der vorgestellten Ansätze be-
rücksichtigt werden müssen, sind deshalb
• die Unterstützung von modularen funktionalen Einheiten sowie
• die Möglichkeit diese zur Laufzeit zu laden und entfernen und
• die Konfigurierbarkeit der Verknüpfungen dieser Module.
Daneben sind nicht-funktionale Anforderungen wie
• Skalierbarkeit,
• Effizienz bei der Weiterleitung und Verteilung der Anwendungsdaten und
• die Lizenzbestimmungen des Frameworks
zu berücksichtigen.
Die Modularisierung der Applikation wird von allen vier vorgestellten Frameworks
unterstützt. Das Context Toolkit, Papiermaché und TUIpist unterscheiden dabei kon-
zeptuell zwischen unterschiedlichen Arten von von Modulen (im Wesentlichen „Input“,
„Verarbeitung“ und „Output“), das SiLiCon Context Framework unterscheidet nicht
zwischen unterschiedlichen Modultypen, dort wird die Rolle eines Moduls ausschließlich
über seine Attribute (also die nach außen sichtbaren funktionalen Einheiten) definiert.
Eine Erweiterbarkeit der Applikation zur Laufzeit ist nur beim SiLiCon Context
Framework und bei TUIpist möglich. Das SiLiCon Context Framework arbeitet hier
mit eigens erstellten Java-Classloadern, die das Nachladen von Klassen (Modulen) und
deren Integration in die Infrasturktur erlauben. TUIpist verwendet die inhärent dynami-
sche Erweiterbarkeit des Java Jini Frameworks (Arnold et al., 1999), auf Basis dessen es
implementiert wurde. Das Context Toolkit und Papiermaché erlauben kein Nachladen
oder Entfernen funktionaler Einheiten während der Laufzeit.
Die Konfiguration der Verbindungen zwischen den Modulen ist bei allen Frameworks
möglich, konzeptuell jedoch unterschiedlich ausgeführt. Im Context Toolkit und in Pa-
piermaché muss die Verbindung direkt im Programmcode codiert werden und wird im
wesentlichen auf Methodenaufrufe abgebildet. Das SiLiCon Context Framework verwen-
det ereignisbasierte Regeln, um Module zu verknüpfen. Ein von einem Modul ausgelöstes
193
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Ereignis kann hier (ggf. durch Bedingungen eingeschränkt) Aktionen in anderen Modu-
len auslösen. Eine Besonderheit dieses Ansatzes ist, das Teile der Interpretationslogik
(also der Erkennung von Benutzerinteraktion aus den Rohdaten) in die Regeln ausge-
lagert werden und damit jederzeit dynamisch verändert werden können. So kann zum
Beispiel die Interpretation der Nähe zwischen zwei Token in einer Regel codiert wer-
den und so in die Reihe der zulässigen (bzw. erkennbaren) Interaktionen aufgenommen
werden. TUIpist benötigt hingegen keinerlei explizite Verbindung der Module, da sämtli-
che Koordination über den geteilten Datenraum ausgeführt wird. Die Verknüpfungslogik
wird hier in die Module verschoben, die selbst wissen müssen, für welche Daten für sie
ggf. relevant sind und welche sie deshalb dem Tuplespace entnehmen.
Hinsichtlich der Skalierbarkeit der Frameworks können aufgrund mangelnder Ver-
gleichsdaten keine fundierten Aussagen getroffen werden. Hinzuweisen ist jedoch auf
die Unterstützung von verteiltem Betrieb einer Applikation durch das SiLiCon Context
Framework (via SOAP-Aufrufe (Curbera et al., 2002) und das TUIpist Framework (via
Jini und Java RMI5 (Downing, 1998)). Durch diese Verteilbarkeit ist kann die Problema-
tik mangelnder Rechenressourcen umgangen werden, die vor allem bei rechenintensiven
Anwendungen wie der eingesetzten Bildanalyse im optischen Tracking auftritt.
Die Beurteilung der Effizienz der Frameworks ist hier in Hinblick auf die geforderte
Echtzeit-Interaktion mit dem System als relevant zu erachten. Das Haupt-Kriterium für
Effizienz ist dementsprechend die Verzögerung zwischen Eingabe-Ereignissen und dem
Feedback auf Applikationsebene, die beim Einsatz der Frameworks auftritt. Eine Beur-
teilung in absoluten Zahlen kann hier mangels entsprechenden Datenquellen ebenfalls
nicht erfolgen, konzeptuell sind aber bei den Frameworks, in denen Module direkt durch
Programm-Code verknüpft werden (Context Toolkit und Papiermaché), eher geringe
Verzögerungen zu erwarten. Die beiden Frameworks, die mit expliziter und konfigu-
rierbarer Middleware zur Datenvermittlung arbeiten (SiLiCon Context Framework und
TUIpist) lassen eher höhere Verzögerungen erwarten, wobei der ereignisbasierte Ansatz
des SiLiCon Context Framework dem daten-basierten Ansatz von TUIpist insofern über-
legen ist, als bei der datenbasierten Interaktion die Module in regelmäßigen Intervallen
nach neuen Daten suchen müssen (Polling, „Information Pull“-Ansatz), während bei er-
eignisbasierten Ansätzen die Benachrichtigung der betroffenen Module automatisch und
zum Zeitpunkt des Auftretens des Ereignisses erfolgt („Information Push“-Ansatz). Der
„Information Pull“-Ansatz sorgt dabei einerseits für erhöhten Kommunikationsaufwand
und potentiell für Verzögerungen bei Ereignissen, die innerhalb eines Polling-Intervalls
auftreten.
Auf Basis der in Tabelle 7.2 angegebenen Gegenüberstellung sind das SiLiCon Con-
text Framework und TUIpist als die beiden am besten geeigneten Kandidaten für den
Einsatz als generisches Framework im hier vorgestellten Anwendungsfall. Das Context
5Remote Methode Invocation
194
7.1. Möglichkeiten zur Erfassung von Benutzerinteraktion
Tabelle 7.2.: Gegenüberstellung der generischen Frameworks
Context
Toolkit
SiLiCon
Context
Frame-
work
Papiermaché TUIpist
Modularität ja ja ja ja
Erweiterbarkeit
zur Laufzeit
nein ja nein ja
dynamisch kon-
figurierbare Or-
chestirierung
nein ja nein ja
Skalierbarkeit schlecht gut schlecht sehr gut
Effizienz bei der
Weiterleitung
von Daten
sehr gut gut sehr gut ausreichend
Lizenz unbekannt unbekannt Open-
Source
(nicht
näher
bestimmt)
Eigen-
entwicklung
195
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Toolkit und Papiermaché scheiden aus verschiedenen Gründen, vor allem aufgrund der
mangelnden Flexibilität aus.
Stellt man die beiden verbleibenden Frameworks gegenüber, so sind hinsichtlich der
funktionalen Anforderungen keine Vorteile für einen der beiden Kandidaten zu identi-
fizieren. Hinsichtlich der nichtfunktionalen Anforderungen hat TUIpist hinsichtlich der
Skalierbarkeit leichte Vorteile, da das Nachladen von neuen Instanzen weniger Aufwand
versacht als im Fall des SiLiCon Context Framework (lediglich Laden eines Moduls im
ersten Fall gegenüber Laden und Einbinden über eine Änderung der Regelbasis im zwei-
ten Fall). Außerdem ist die technologische Basis der Verteilungsarchitektur in TUIpist
konzeptuell auf höherer Ebene angesiedelt und mächtiger in der Verwaltung der Ap-
plikationsstruktur (unter anderem werden neue Module bei TUIpist automatisch in die
Infrastruktur eingebunden, sobald sie angemeldet werden, im SiLiCon Context Frame-
work muss für jeden Kommunikationskanal die IP-Adresse des Empfängers bekannt sein
und in die Regelbasis aufgenommen werden).
Hinsichtlich der Effizienz der Kommunikation bietet das SiLiCon Context Frame-
work gegenüber TUIpist aus den oben beschriebenen Gründen (Benachrichtung über
Änderungen gegenüber Polling) Vorteile. Für die hier beschriebene Applikation fällt
die Entscheidung trotzdem zugunsten TUIpist. Neben der generell weniger aufwän-
digen Konfiguration kommt die Struktur von TUIpist einem iterativen Software-Ent-
Ïwicklungsprozess insofern eher entgegen, als dass die Modularisierung von initialen,
monolithischen Prototypen (z.B. basierend auf der Struktur des zuvor ausgewählten
ReacTIVision-Frameworks) einfacher möglich ist. Dies liegt darin begründet, dass in der
modularen und dynamischen Struktur von TUIpist die gesamte Applikationslogik in den
Modulen enthalten ist und so Teile aus einer monolithischen Applikation herausgelöst
und direkt übernommen werden können, wobei lediglich die Logik der Datenübergabe
von direkten Methoden-Aufrufen auf die TUIpist-Routinen zum Zugriff auf den Tuple-
space umgearbeitet bzw. erweitert werden muss. Beim korrekten Einsatz des SiLiCon
Context Framework wandert wie oben beschrieben ein Teil der Applikationslogik in
die Regelbasis, was erhöhten Aufwand bei der iterativen Entwicklung verursacht und
außerdem das Zusammenspiel der Applikations-Module unübersichtlicher und schwerer
fassbar macht.
7.2. Konzeption und Umsetzung der
Hardwarekomponenten
Basierend auf der oben getroffenen Technologieentscheidung zugunsten eines optischen,
video-basierten Input-Systems für das hier zu erstellende Tabletop Interface wird in die-
sem Abschnitt das konkrete Hardware-Design beschrieben. Dies umfasst die Beschrei-
bung des Tabletop Interfaces im Überblick und detaillierte Betrachtungen des Token-
196
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Designs sowie der Tisch-Oberfläche, die als Input-Kanal dient. Weiters werden spezi-
fische Herausforderungen und der jeweilige hier verfolgte Lösungsansatz beschrieben.
Nicht Gegenstand dieses Abschnitts sind jene Hardware-Komponenten, die für die Aus-
gabe von Information eingesetzt werden. Obwohl hier im Überblick angeführt, werden
sie detailliert erst in Kapitel 8 über die Visualisierung der Modellierungsinformation
beschrieben.
7.2.1. Überblick
Das Tabletop Interface ist als Tisch mit einer Oberfläche von 100 cm x 80 cm ausgeführt.
Die Höhe beträgt 110 cm. Die wesentlichen Hardwarekomponenten sind die Tischober-
fläche, die in semi-transparentem Acrylglas ausgeführt ist und die Bodenplatte, in die die
Kamera zum optischen Tracking der Tokens auf der Oberfläche sowie der Videoprojektor
zur Ausgabe von Information auf der Oberfläche (Projektion von unten) eingebaut sind
(siehe Abbildung 7.7). Der Tisch ist auf allen Seitenflächen mit Platten aus expandiertem
Polystyrol (Styropor) verkleidet, um im Inneren kontrollierte Umgebungslichtbedingun-
gen für die Bilderfassung mit der Kamera zu schaffen. Die kontrollierten Bedingungen
werden durch den Einsatz von vier Beleuchtungsmodulen gewährleistet, die ebenfalls in
der Bodenplatte integriert sind und über den Seitenflächen eingebaute Streuscheiben für
eine einheitliche, diffuse Beleuchtung der Tischinnenraums sowie der Oberfläche sorgen.
Abbildung 7.7.: Überblick über den Aufbau des Werkzeugs – Eingabekomponenten
Am Tisch befindet sich zusätzlich ein Bildschirm, auf dem entsprechend der Anforde-
rungen zur Unterstützung der Modellierung Zusatzinformation ausgegeben wird. Eine
197
7.2. Konzeption und Umsetzung der Hardwarekomponenten
zweite Kamera, die am Bildschirm sitzt und der unterstützenden Erfassung von In-
formation dient (zum Beispiel der bereits erwähnten Registrierung von geschachtelten
Tokens).
Das gesamte System ist so zerlegbar, dass es im Kofferraum eines Mittelklassewa-
gens transportiert werden kann. Es werden dazu die Verkleidungsplatten und Tischbeine
entfernt, die Tischplatte kann dann direkt auf die Bodenplatte gesetzt und verbunden
werden. Das Volumen reduziert sich dabei auf 100 cm x 80 cm x 20 cm, wobei die
Tischbeine, die Verkleidungsplatten und der Videoprojektor separat transportiert wer-
den müssen. Ein Zusammenbau des Systems inklusive Kalibrierung der Eingabe- und
Ausgabe-Kanäle ist in etwa 30 Minuten möglich.
7.2.2. Tokens und Input-Werkzeuge
In diesem Abschnitt werden die einzelnen durch die Benutzer manipulierbaren Token-
Arten beschrieben. Neben den eigentlichen Modellierungstokens sind dies die Tokens
zur Einbettung in Container sowie die Werkzeugtokens, von denen es Ausführungen
zur Manipulation des Modells und Tokens zur Auslösung bzw. Kontrolle spezifischer
Funktionalitäten gibt.
Modellierungs-Tokens
Die eingesetzten Modellierungs-Tokens sind aus nicht transparentem Acrylglas gefertigt.
Ihre Außenmaße betragen in etwa (je nach Form) 10 cm x 6 cm in der Grundfläche
und 4 cm in der Höhe. Damit ist einerseits eine ausreichende Größe zur Anbringung
der ReacTIVision-Codes gewährleistet, andererseits sind noch klein genug, um in einer
Hand gehalten und manipuliert werden zu können. Die Codes werden auf der Unterseite
der Tokens angebracht und auch von unten erfasst (siehe nächster Abschnitt), um eine
Verdeckung der Codes während der Manipulation zu verhindern (siehe Abbildung 7.8).
Die Modellierungs-Tokens wurden in drei Ausführungen gefertigt (siehe Abbildung
7.9). Diese unterscheiden sich in Form und Farbe und können während der Modellie-
rung von den Benutzern frei mit Bedeutung belegt werden. Die Auswahl der Formen
und Farben erfolgte inspiriert von den Symbolen gängiger Modellierungsnotationen in
Abstimmung mit fertigungstechnischen Einschränkungen. Eine Untersuchung geeigne-
ter Token-Formen und eine auf diesen Ergebnissen basierende Umsetzung wurde nicht
vorgenommen. Dies liegt vor allem in der Tatsache begründet, dass sich der Fokus der
hier vorgestellten Arbeit im Entwicklungsprozess von einem Werkzeug zur Geschäfts-
prozessmodellierung (mit vorgegebener Notation) hin zu einem allgemeiner einsetzbaren
Werkzeug zur generischen Modellierung konzeptueller Modelle (ohne vorgegebene Nota-
tion) entwickelte. Die Auswahl der Token-Formen fiel in die erste Phase, wodurch die
198
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Abbildung 7.8.: An Tokens angebrachte ReacTIVision-Codes zur Identifikation
Abbildung 7.9.: Arten von Modellierungstokens
199
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Tokens im äußeren Erscheinungsbild an gängige Notationen zur Ablauf-Modellierung
angelehnt sind. Die Token-Form hat aber bei Benutzern ohne Modellierungs-Vorbildung
geringen bis keinen Einfluss auf den Modellierungsprozess (siehe Kapitel 12 – Evaluie-
rung des Werkzeugs).
Abbildung 7.10.: Rückwand von Container Tokens
Wie in der Beschreibung der Anforderungen gefordert und oben bereits beschrieben,
sind die Modellierungs-Tokens als Container ausgeführt. Im Abschnitt 7.1.1 über die
Erkennung des Token-Zustands wurde beschrieben, das beim Einsatz von optischem
Tracking eine Möglichkeit geschaffen werden muss, im Kamerabild zu erkennen, ob ein
Token geöffnet ist oder nicht. Um den durchgängigen Einsatz des Erkennungsframeworks
(ReacTIVision) zu gewährleisten wird zu diesem Zweck ein zweiter Code eingesetzt (sie-
he Abbildung 7.10), der nur dann für die Kamera sichtbar wird, wenn das Token geöffnet
ist. Hardwareseitig ist dies so umgesetzt, das die Modellierungstokens einen Öffnungs-
mechanismus besitzen, dessen Scharnier nicht am Deckel sitzt (und damit nur diesen
beweglich macht), sondern an der Bodenplatte, wodurch sich beim Öffnen eines Con-
tainers nicht nur der Deckel, sondern auch die Hinterwand des Tokens bewegt (siehe
Abbildung 7.11). Die Hinterwand kommt im geöffneten Zustand auf der Oberfläche des
Tisches zu liegen, wodurch der auf ihr angebrachte zweite Code für die Kamera sichtbar
wird. So kann durch das an sich zur Positionsbestimmung eingesetzte optische Tracking-
system zuverlässig auch den Öffnungs-Zustand der Tokens auf der Oberfläche erkennen.
Konzeptuell sind bei der Beschreibung der Verwendung dieser Tokens verschiedene
Ebenen zu unterscheiden, die klar voneinander abgegrenzt werden müssen und in denen
deshalb unterschiedliche Bezeichnungen verwendet werden. Diese Ebenen und die Be-
ziehungen zwischen diesen sind in Abbildung 7.12 in Form einer einfachen Taxonomie
200
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Abbildung 7.11.: Geöffnetes Container Token
dargestellt. Als „Modellelement“ wird jenes Konzept bezeichnet, das als Teil des eigentli-
chen Modells die darzustellenden Inhalte repräsentiert und semantisch Bedeutung trägt.
Dieses Modellelement wird in Hardware durch das eben beschriebene „Modellierungs-
Token“ repräsentiert, das in Bezugnahme auf seine Eigenschaft, zusätzliche Informa-
tion beinhalten zu können auch als „Container-Token“ bezeichnet werden kann. Das
Modellierungs-Token trägt einen eindeutigen „(ReacTIVision-)Marker“, welcher wie-
derum einen eindeutigen „Code“ repräsentiert. Softwareseitig wird das Modellelement
durch ein „Objekt“ (im objektorientieren Sinn, also die Instanz einer Klasse) repräsen-
tiert, das ein Attribut enthält, in dem eine „ID“ abgelegt wird. Diese ID entspricht dem
Code, der hardwareseitig durch den ReacTIVision-Marker repräsentiert wird und er-
möglicht so eine eindeutige Zuordnung zwischen Hardware- und Softwarerepräsentation
eines Modellelements.
Einbettbare Tokens
Die einbettbaren Token erlauben wie in Abschnitt 7.2 beschrieben die Verschachtelung
von Modellen und das Hinzufügen von Zusatzinformation. Sie werden in einem definier-
ten Interaktionsvorgang an Information gebunden und dann in einen Container gelegt.
Hinsichtlich des Hardware-Designs sind folgende Anforderungen zu beachten:
• Die Token müssen klein genug sein, um auch mehrere Einheiten in einem Container
unterzubringen.
• Sie müssen gleichzeitig groß genug sein, um einen ReacTIVision-Code zur eindeu-
tigen Identifikation anzubringen.
201
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Abbildung 7.12.: Modellelemente – Taxonomie
• Sie müssen so ausgeführt sein, dass haptisch oder akustisch erkennbar ist, ob in
einem geschlossenen Container Tokens eingebettet sind oder nicht (z.B. durch Ver-
änderung des Gewichts oder Geräusche beim Schütteln eines Containers).
Die einbettbaren Tokens wurden aus flexiblen Kunststoffmatten gefertigt und mit
einem Metallstück versehen (siehe Abbildung 7.13), das einerseits als Griff dient und
andererseits sowohl das Gewicht erhöht und akustisches Feedback beim Schütteln ei-
nes Container-Tokens verursacht. Die einbettbaren Tokens wurden exemplarisch in drei
Ausführungen gefertigt, je nach Art und Anzahl der einzubettenden Information kann
eine Definition weiterer Tokens sinnvoll sein. Folgende Tokens wurden für den aktuellen
Entwicklungsstand des Werkzeugs angefertigt:
• Einbettung von Teilmodellen (inhärente Kernfunktionalität des Werkzeugs)
• Einbettung von digitalen Ressourcen bzw. Dateien am lokalen Rechner (Erweite-
rung zur Verknüpfung des Modells mit den realen digitalen Ressourcen aus dem
Arbeitskontext)
• Einbettung von Fotos (Erweiterung zur Verknüpfung des Modells mit dem realen
Arbeitskontext, z.B. mittels Fotos von Arbeitsmitteln oder Personen)
Alle Tokens sind auf der Unterseite mit einem ReacTIVision-Code versehen, der sie
eindeutig identifiziert (siehe Abbildung 7.13). Aufgrund der beschränkten Größe der To-
kens ist dieser Code von der Kamera, die die Tischoberfläche erfasst, nur in der Mitte
der Oberfläche erfassbar (da dort die geringsten Linsen-Verzerrungen auftreten und der
Code somit noch erkannt werden kann). Um etwaige Bedienungsprobleme zu vermeiden
202
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Abbildung 7.13.: Einbettbare Tokens
wurde deshalb die Interaktion mit einbettbaren Tokens (Registrierung, Binden von Infor-
mation) auf die in Abbildung 7.7 dargestellte zweite Kamera (“Registrierungs-Kamera“)
verlegt, die durch die physische Nähe zu den Modellierenden die Codes der einbettbaren
Tokens problemlos erfassen kann.
Werkzeug-Tokens
Neben den Tokens, die Modellierungsinhalte repräsentieren, wurden auch Tokens an-
gefertigt, die der Interaktion mit dem System an sich und der Steuerung des Model-
lierungsablaufs dienen. Hier sind zwei Arten zu unterscheiden: einerseits gibt es Werk-
zeuge, die der Manipulation des Modells dienen (z.B. Herstellung von Verbindungen
zwischen Tokens, Benennung von Tokens) und andererseits solche, die der Steuerung
von modellierungsunterstützender Zusatzfunktionalität dienen (etwa Tokens, mit denen
die Rückverfolgung der Modellierungshistorie gesteuert werden kann). Außerdem sind
orthogonal zu dieser Klassifizierung noch Tokens zu unterscheiden, die beim Einsatz ein
Ereignis auslösen und solche, die das System solange in einen anderen Zustand versetzen,
bis sie wieder entfernt werden (gleich einem Taster). Im Folgenden werden die einzelnen
Werkzeuge beschrieben und den eben definierten Kategorien zugeordnet.
Manipulation des Modells Die bei der Verwendung des Systems wichtigstenWerkzeug-
Tokens sind jene, die zur Benennung und Verbindung von Modellierungs-Tokens ver-
wendet werden. Diese Markierungs-Tokens sind als auf die Oberfläche aufsetzbare Stäbe
konzipiert, die unten eine Standfläche aufweisen, welche auch den Code aufnimmt. Am
oberen Ende ist eine Verbreiterung angebracht, die eine stabile Handhabung gewährleis-
203
7.2. Konzeption und Umsetzung der Hardwarekomponenten
tet (siehe Abbildung 7.14). Bedingt durch die kleine Standfläche kann nur der einfachste
ReacTIVision-Code verwendet werden, der lediglich aus einem schwarzen Ring besteht.
Das ReacTIVision-System erkennt diesen Ring nicht als regulären Code, sondern als
„Cursor“, also als Zeiger, der ausschließlich eine Position in der Ebene besitzt, aber kei-
ne Rotation aufweist. Für die Verwendung zur Markierung von Modellierungs-Tokens
zum Zwecke der Benennung oder Verbindung ist dies auch nicht notwendig.
Abbildung 7.14.: Markierung-Token
Das Modellierungswerkzeug muss zwischen unterschiedlichen Arten von Verbindungen
unterscheiden können, da diese bei der vorgestellten Art der Externalisierung zum Ein-
satz kommen können. Im Wesentlichen ist zwischen ungerichteten und gerichteten Ver-
bindern zu unterscheiden. Im Gegensatz zu ungerichteten Verbindern weisen gerichtete
Verbinder Pfeilspitzen an einem Ende oder an beiden Enden auf. Für die Werkzeug-
Tokens bedeutet dies, dass neben den bereits beschriebenen, einfachen Markierungs-
Tokens auch solche zum Einsatz kommen, die anstatt einer runden Grundfläche eine
größere, dreieckige Grundfläche aufweisen, die eine Pfeilspitze symbolisiert (siehe Ab-
bildung 7.14). Technisch werden die beiden Arten von Markierungs-Tokens durch einen
zweiten Cursor-Code unterschieden, der an Tokens mit dreieckiger Grundfläche zusätz-
lich angebracht ist.
Die Markierungs-Tokens sind der Kategorie der ein Ereignis auslösenden Tokens zu-
zuordnen. Dies bedeutet, dass das System zu jenem Zeitpunkt eine Aktion setzt, an
dem das Token auf die Oberfläche aufgesetzt wird. Wird ein Markierungs-Token auf der
Oberfläche belassen, verursacht es keine weiteren Aktionen, bis es entfernt und erneut
aufgesetzt wird.
Dem hingegen ist das nächste hier behandelte Token der Kategorie der den System-
zustand beeinflussenden Tokens zuzuordnen. Es hat also solange Auswirkungen auf den
204
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Modellierungsablauf, solange es auf der Oberfläche belassen wird. Die konkrete Funkti-
on dieses Tokens ist der Wechsel in einen Werkzeugmodus, der ein explizites Entfernen
bzw. Löschen von Bestandteilen des Modells, insbesondere Verbindungen, erlaubt. Das
Token ist als Radiergummi ausgeführt und codiert so die Metapher des expliziten Lö-
schens von Information aus dem Modell (siehe Abbildung 7.15). An der Unterseite des
Tokens ist eine ReacTIVision-Code angebracht, um es gegenüber dem System eindeutig
zu identifizieren.
Abbildung 7.15.: Lösch-Token
Der Einsatz der Lösch-Tokens verändert im System im Wesentlichen die Interpretation
des Markierungs-Tokens, das nun anstatt der Herstellung einer Verbindung das Löschen
derselben auslöst. Der zugehörige Interaktionsablauf ist im Detail in Abschnitt 7.3.4
dargelegt.
Ein weiteres Werkzeug im Kontext der Manipulation des Modells ist das Registrierungs-
Token für die Benennung von Blöcken mittels handgeschriebenen Haftnotizen. Wie in
Abschnitt 7.3.2 im Detail ausgeführt, gibt es zwei Möglichkeiten um ein Modellierungs-
Token zu benennen. Einerseits kann der herkömmlich Eingabeweg über die Tastatur ge-
wählt werden, andererseits ist es möglich, die Modellierungs-Tokens mittels aufgeklebten
Haftnotizen zu benennen. Um die handgeschriebene Information in die digitale Informa-
tion übernehmen zu können, wird diese mittels Bildanalyse-Verfahren aus einem Bild
extrahiert, das von der oben bereits erwähnten Registrierungskamera (siehe Abbildung
7.7) aufgenommen wird. Die Aufnahme wird durch das erwähnte Registrierungstoken
ausgelöst. Dieses fungiert gleichzeitig als Halter für noch unbeschriftete Haftnotizen und
weist am linken und rechten Rand jeweils einen ReacTIVision-Code auf (siehe Abbildung
205
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Abbildung 7.16.: Registrierungstoken
7.16). Diese beiden Codes erlauben es im Bild die Position der Haftnotiz und damit die
zu extrahierende Information zu identifizieren.
Das Registrierungstoken ist in die Kategorie der Ereignis auslösenden Tokens einzu-
ordnen. Seine Verwendung erwies sich im praktischen Einsatz als wenig intuitiv und
technisch instabil bzw. zu langsam, so dass – wie erwähnt – als alternativer Eingabeweg
zusätzlich eine Tastatur ins System aufgenommen wurde. Die Interaktionsabläufe sind
in beiden Fällen ähnlich und werden im Detail in Abschnitt 7.3.2 dargestellt.
Steuerung von Unterstützungsfunktionen Im Werkzeug wurden entsprechend den
Anforderungen aus Kapitel 5 den Modellierungsablauf unterstützende Funktionen im-
plementiert. Diese werden über dezidierte Werkzeug-Tokens gesteuert. Der Anwendungs-
bereich dieser Art von Tokens ist die Steuerung aller Funktionen, die im Kontext der
Verfolgbarkeit der Modellierungs-Historie umgesetzt wurden.
Das Snapshot-Token dient der durch die Benutzer ausgelösten Speicherung des ak-
tuellen Systemzustandes. Wie in Abschnitt 7.4 beschrieben, verfolgt das System den
Modellierungsablauf und speichert selbsttätig stabile Systemzustände (zur Identifikati-
on dieser Zustände siehe Abschnitt 7.3). Zusätzlich können Benutzer mit eben dem hier
beschriebenen Token die explizite Aufnahme des aktuellen Modellzustandes veranlassen,
wenn dieser als wesentlich wahrgenommen wird. Das Token ist als ereignis-auslösendes
Element konzipiert und wird durch kurzes Aufsetzen des Tokens auf die Modellierungs-
oberfläche aktiviert. Physisch ist es prototypisch als großes rotes Quadrat ausgeführt, an
dessen Oberseite ein Griffstück angebracht ist (siehe Abbildung 7.17). Auf der Unterseite
sitzt wiederum ein ReacTIVision-Code zur Identifikation des Tokens.
206
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Abbildung 7.17.: Snapshot-Token
Neben der Speicherung von Modellzuständen können diese auch wieder abgerufen und
in ihrer zeitlichen Sequenz dargestellt werden. Zur Aktivierung des Historien-Modus
und zur Navigation in der Zeitlinie wurde ein weiteres Token eingeführt, das als einzi-
ges sowohl der zustandsverändernden als auch der ereignisauslösenden Token-Kategorie
zuzuordnen ist. Zustandsverändernd wirkt das History-Token insofern, als dass das Auf-
setzen auf die Oberfläche das System in den Historienmodus schaltet und ein Entfernen
die aktuelle Modell-Ansicht wieder herstellt. Durch Rotation des Token im bzw. gegen
den Uhrzeigersinn kann nun durch die in ihrer zeitlichen Abfolge angeordneten gespei-
cherten Modellzustände navigiert werden. Die Rotation löst dabei jeweils nach einem
bestimmten zurückgelegten Drehwinkel ein Ereignis aus, das den entsprechend vorherge-
henden bzw. nachfolgenden Systemzustand abruft. Um die Rotation möglichst natürlich
handhabbar zu machen, ist das Token mit runder Grundfläche etwa handflächengroß
ausgeführt (siehe Abbildung 7.18). Auf der Unterseite der Grundfläche ist wiederum der
ReacTIVision-Code angebracht.
Das letze hier behandelte Token zur Steuerung einer Unterstützungsfunktion ist jenes,
dass die in Kapitel 5 als Anforderung definierte und in Abschnitt 8.3.4 im Detail be-
schriebene Wiederherstellungsunterstützung auslöst. Die Verwendung dieses Tokens ist
identisch mit jener des oben beschriebenen Snapshot-Tokens. Wie dieses ist es der er-
eignisauslösenden Kategorie zuzuordnen und aktiviert die Wiederherstellungsunterstüt-
zung, wenn es bei aktivem Historien-Modus auf der Modellierungsoberfläche aufgesetzt
wird. Die eigentliche Wiederherstellungsunterstützung ist dem Ausgabe-Kanal zuzuord-
nen und in ihrem Ablauf deshalb im Detail in Kapitel 8 (Abschnitt 8.3.4) beschrieben.
207
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Abbildung 7.18.: History-Token
7.2.3. Eingabe auf der Tischoberfläche
Nachdem nun die Tokens beschrieben wurden, die den Benutzern unmittelbar zur Inter-
aktion mit dem System dienen, liegt der Fokus dieses Abschnitts nun auf der technischen
Umsetzung der Erfassung der aktuell auf der Oberfläche sichtbaren ReacTIVision-Codes
und damit der Tokens.
Wie bereits oben beschrieben, wurde bei der Umsetzung des optischen Tracking-
Ansatzes eine Identifikation der Codes von der Unterseite gewählt, um etwaigen Erken-
nungsproblemen mit Verdeckungen vorzubeugen. Dies bedingt, dass die Modellierungs-
oberfläche für Kameras möglichst transparent sein muss um den Identifikationsvorgang
nicht negativ zu beeinflussen. Grundsätzlich bietet sich dazu der Einsatz einer (Acryl-
)Glasplatte an, die keinen Einfluss auf die Erfassung der auf ihr platzierten Codes hat.
Der Einsatz einer (Acryl-)Glasplatte bringt jedoch zwei Probleme mit sich. Einerseits
kann die Verwendung einer transparenten Oberfläche dazu führen, dass Modellierende
durch den Einblick auf den inneren Aufbau des Systems von der Aufgabe abgelenkt
bzw. irritiert werden. Andererseits verhindert eine transparente Oberfläche den Einsatz
derselben als Rückkanal zur Darstellung von zusätzlicher Information durch einen Vi-
deoprojektor. Dies ist im konkreten Fall besonders schwerwiegend, da die a-priori unspe-
zifischen Modellierungs-Tokens erst durch die Projektion der zusätzlichen Information
explizit bedeutungstragend werden. Deswegen wurde eine semi-transparente Acrylglas-
Oberfläche eingesetzt, die einerseits für die Erfassung der Codes ausreichend durchlässig
ist, andererseits aber auch das projizierte Licht soweit bricht, dass die darzustellende
Information auf der Oberfläche sichtbar ist.
Die Kamera – eine AVT Guppy F080B (Allied Vision Technologies GmbH, 2008) –
sitzt wie in Abbildung 7.7 schematisch dargestellt in der Mitte der Bodenplatte. Sie ist
208
7.2. Konzeption und Umsetzung der Hardwarekomponenten
mit einem Weitwinkel-Objektiv ausgestattet, das es erlaubt, die gesamte Oberfläche zu
erfassen, ohne dass der Tisch höher als 100 cm sein muss (Öffnungswinkel etwa 45°). Die
Kamera bietet eine Auflösung von 1024 x 768 Bildpunkten und ist über eine Firewire-
Schnittstelle (IEEE 1394 (Bloks, 1996)) mit dem Rechner verbunden. Die Kamera kann
so bis zu 30 Bilder pro Sekunde an den Rechner senden. Das Weitwinkelobjektiv ver-
ursacht Verzerrungen in den Randbereichen, was trotz der Möglichkeit von ReacTIVi-
sion, das Bild softwareseitig zu entzerren, dazu führt, dass links und rechts etwa 10 cm
der Tischoberfläche nicht zur Identifikation von Codes verwendet werden können. Die-
ser Problematik kann aufgrund der beschränkten Kameraauflösung nur durch größere
Codes begegnet werden, was durch die beschränkte Größe der Tokens nicht möglich ist.
Im Prototypen wurden deshalb die Randbereiche des Systems ausgespart und können
zur Ablage von aktuell nicht eingesetzten Tokens verwendet werden.
Illumination und Umgebungslichtabhängigkeit
Optische Tracking-Systeme leiden generell unter ihrer Abhängigkeit von den Umge-
bungslichtbedingungen. Probleme, die in diesem Zusammenhang auftreten, hängen nicht
nur mit der absoluten Stärke der Einstrahlung von Umgebungslicht zusammen (die zu
schwach, aber auch zu stark sein kann), sondern auch mit der Änderung der Lichtbedin-
gungen über die Zeit. Gegenstand dieses Abschnitts ist die genauere Erörterung dieser
Problematik und die Darlegung von Möglichkeiten ihr zu begegnen.
Zu geringe Umgebungshelligkeit führt zu Erkennungsproblemen, da der Kamera nicht
ausreichen Licht und damit Kontrast zur Verfügung steht, um ein Bild zu liefern, in dem
die ReacTIVision-Codes zuverlässig identifiziert werden können (dies gilt im Übrigen
auch für alle anderen optischen Identifikations-Ansätze). Das Problem wird zusätzlich
verschärft, da zur Aufnahme des Bildes nicht das Spektrum des sichtbaren Lichts ver-
wendet wird, sondern in den Infrarot-Bereich (“near infrared“, Wellenlänge etwa 550
nm) ausgewichen wird. Dies ist notwendig, da die Kamera andernfalls Reflexionen des
auf die Oberfläche projizierten Ausgabe-Kanals (siehe Kapitel 8) erfasst, was eine Iden-
tifikation der Codes unmöglich macht. Die meisten Kunstlicht-Quellen strahlen jedoch
nicht ausreichend Licht im verwendeten Infrarot-Bereich ab, um eine ausreichende und
gleichmäßige Ausleuchtung der Oberfläche zu gewährleisten. Dieser Problematik wurde
dadurch begegnet, dass im betreffenden Infrarot-Bereich strahlende Beleuchtungsquellen
in den Tisch (konkret in den Ecken der Bodenplatte) eingebaut wurden (siehe Abbil-
dung 7.7). Um eine gleichmäßige, diffuse Ausleuchtung zu erreichen, wurde der Tisch
rundum mit weißen Kunststoffplatten mit strukturierter Oberfläche verkleidet, die das
vorhandene Licht streuen. Um Reflexionen der Lichtquellen (die nach oben abstrahlen)
auf der Oberfläche zu vermeiden, wurden etwa 50 cm über den Lichtquellen Streuschei-
ben angebracht. So konnte eine diffuse Beleuchtungssituation geschaffen werden, deren
Stärke ausreicht, um die Codes auch bei vollkommener Dunkelheit in der Umgebung
zuverlässig zu erkennen.
209
7.2. Konzeption und Umsetzung der Hardwarekomponenten
Das zweite Problemfeld betrifft zu starke Lichteinstrahlung aus der Umgebung. Zu
hohe Umgebungshelligkeit führt zu einem Überstrahlen des Kamerabildes in manchen
Bereichen, womit in Teilen der Oberfläche keine Codes erkannt werden können. Dies
liegt in dem von ReacTIVision eingesetzten adaptiven Code-Extraktions-Algorithmus
begründet, der bei schwachen oder guten Beleuchtungsverhältnissen leichte Unterschiede
in der Ausleuchtung korrigieren kann, bei starken Unterschieden oder großer Helligkeit
jedoch nicht mehr zuverlässig funktioniert. Wie bereits erwähnt, arbeitet die Kame-
ra im Infrarot-Bereich. Dies ist dann problematisch, wenn starke Sonneneinstrahlung
vorhanden ist, da diese einen hohen Anteil an Licht der relevanten Wellenlänge ent-
hält. Auch bestimmte Kunstlichtquellen wie Leuchtstoffröhren, die unmittelbar über
dem Tisch angebracht sind, verursachen Probleme. Während punktuelle Helligkeitszo-
nen („Spotlights“) nicht durch die Software korrigiert werden können und vermieden
werden müssen, kann eine generell zu hohe Umgebungshelligkeit durch die Kalibrierung
der ReacTIVision-Software bzw. der ihr zugrunde liegenden Kamera-Treiber korrigiert
werden. Im Konkreten ermöglicht ReacTIVision bei Firewire-Kameras eine Veränderung
der Kamerablende (größere Blende – weniger Licht am Sensor) sowie der Signalverstär-
kung (weniger Verstärkung – dunkleres Bild). Durch Veränderung dieser beiden Para-
meter kann nahezu jede Beleuchtungssituation korrigiert werden, sofern sie über die Zeit
stabil bleibt.
Bei Umgebungslicht-Bedingungen, die sich über die Zeit verändern (z.B. bei Tages-
licht, das sich durch Wolkenbewegungen oder tageszeitabhängig verändert), kann die
manuelle Konfiguration des ReacTIVision-Frameworks nicht sinnvoll durchgeführt wer-
den. Leichte Veränderung der Helligkeit kann das ReacTIVision-Framework durch den
adaptiven Erkennungs-Algorithmus noch selbst korrigieren, bei größeren Veränderungen
funktioniert jedoch die Erkennung nicht mehr stabil. Dies äußert sich darin, dass Codes
für einige Sekundenbruchteile von der Kamera nicht mehr erfasst werden, was wiederum
zu unerwünschten von Framework gemeldeten Ereignissen führt (z.B. dass ein Container-
Token verschwunden wäre, obwohl es sich physisch noch auf der Oberfläche befindet). Da
diese Erkennungsausfälle im Grenzbereich gerade noch möglicher Erkennung zwar regel-
mäßig auftreten, in ihrer zeitlichen Ausdehnung aber eher kurz sind, wurde im Rahmen
der Interpretation der vom ReacTIVision-Framework gemeldeten Ereignisse eine Stabi-
lisierungsebene eingezogen, die versucht, Ausfälle und Fehlerkennungen zu identifizieren
und dementsprechend nicht an die übergeordneten Software-Ebenen weiterzugeben. Die
in dieser Ebene umgesetzten Maßnahmen sind in Abschnitt 7.4.2 beschrieben.
Durch die Kombination aller beschriebenen Maßnahmen ist es möglich, eine sehr weit-
gehende Einsetzbarkeit des Werkzeugs – unabhängig von den herrschenden Umgebungs-
lichtbedingungen – zu gewährleisten. Lediglich extreme Verhältnisse, wie direkte Ein-
strahlung von in der Stärke variierenden Lichtquellen, verhindern einen stabilen Einsatz
des Systems.
210
7.3. Benutzerinteraktion mit dem Werkzeug
7.3. Benutzerinteraktion mit dem Werkzeug
Bevor nun die Interpretation der Eingabedaten durch die Software beschrieben wird,
muss vorab geklärt sein, auf welche Art und Weise Benutzer mit dem System interagie-
ren können. Bisher wurde geklärt, wie die Eingabe technisch funktioniert und welche
Elemente den Benutzern zur Interaktion mit dem System zur Verfügung stehen. Im
Folgenden werden die einzelnen Aktionen, die Benutzer grundsätzlich im Kontext des
Modellierungsablaufs setzen können, identifiziert und deren konkrete Umsetzung durch
das vorgestellte System beschrieben.
Ein grundsätzliches Designziel war es die Interaktion mit dem System so „natürlich“
wie technisch möglich zu gestalten. Unter „natürlich“ ist hier zu verstehen, dass
• die Eingabe von Information möglichst ausschließlich über direkte Aktionen der
Hände der Benutzer (d.h. ohne Übersetzung in die digitale Welt durch Maus oder
Tastatur) gestaltet werden kann, und
• dass diese Aktionen bzw. deren Ablauf nur durch inhaltliche Vorgaben der Mo-
dellierungsproblematik, nicht aber durch technische Einschränkungen vorgegeben
sind.
Wie bereits im letzen Abschnitt beschrieben, konnten diese Forderungen aufgrund der
Eigenschaften des eingesetzten Tracking-Systems nicht vollständig umgesetzt werden.
Wo noch Einschränkungen hinsichtlich der oben genannten Forderungen bestehen, wird
in den folgenden Abschnitt darauf hingewiesen und ein möglicher Lösungsansatz skiz-
ziert.
7.3.1. Hinzufügen und Verändern von Modellelementen
Um Elemente zu einem Modell hinzuzufügen, müssen entsprechende Tokens auf der
Modellierungsoberfläche platziert werden. Sofern sich diese im Erfassungsbereich der
Kamera befinden, werden sie identifiziert und an der entsprechenden Stelle im Modell
identifiziert. Beim erstmaligen Hinzufügen wird das Token den Benutzern gegenüber
mittels seiner Nummer (die durch den ReacTIVision-Code vorgegeben ist) dargestellt.
Ist das Token bereits benannt und wird erneut hinzugefügt, wird die zuvor vergebene
Benennung geladen und angezeigt.
Beim erstmaligen Hinzufügen eines Elementtyps (also eines roten, blauen oder gelben
Tokens) fragt das System nach der Bedeutung dieses Elementtyps. Diese kann angegebe-
nen werden, darf aber auch unspezifiziert bleiben und kann zu einem späteren Zeitpunkt
festgelegt oder verändert werden. Diese Interaktion zu einem späteren Zeitpunkt muss
explizit dadurch ausgelöst werden, indem ein Token des betreffenden Typs vor die Re-
gistrierungskamera gehalten wird.
211
7.3. Benutzerinteraktion mit dem Werkzeug
Um die Position und Rotation eines Modellelements zu verändern, muss es entspre-
chend an einen anderen Ort verschoben oder gedreht werden. Dabei ist es nicht notwenig,
dass das Token ständig von der Kamera erfasst wird. Kurze Aussetzer in der Erfassung,
die durch schnelles Verschieben oder Abheben des Tokens und Aufsetzen an einem an-
deren Ort ausgelöst werden, werden von der Software ignoriert, das Element wird so
behandelt, als wäre es nicht verschwunden gewesen (hinsichtlich der Auswirkungen des
Verschwindens eines Tokens siehe Abschnitt 7.3.4).
Eine simultane Erweiterung oder Veränderung des Modells durch mehrere Benutzer ist
möglich, die Software schränkt die Anzahl der möglichen zeitgleich ablaufenden Inter-
aktionen nicht ein. Da alle in diesem Abschnitt beschriebenen Interaktionen eindeutig
einem Token zugeordnet werden können und dieses zu jedem Zeitpunkt eindeutig iden-
tifiziert werden kann, kann das System mit dieser Art von Eingaben umgehen. Die
Erfassungsrate liegt in der derzeitigen Implementierung bei etwa 15 Bildern in der Se-
kunde, woraus sich ein Auswerteintervall von etwa 67 Millisekunden ergibt. In diesem
Abstand wird jeweils die gesamte Oberfläche erfasst und etwaige Änderungen an die
Applikationsschicht weitergemeldet.
7.3.2. Benennen von Modellelementen
Die Benennung von Modellelementen ist eine der wichtigsten Interaktionsformen im
Modellierungsprozess. Modellelementen wird damit ein Name zugewiesen, der zur Iden-
tifikation des Elements gegenüber den Benutzern verwendet wird. Um der Anforderung
nach möglichst direkter, unmittelbarer Interaktion mit dem System in der realen Welt
(d.h. auf der Modellierungsoberfläche) nachzukommen, wurde ein auf der Verwendung
von Haftnotizen basierender Interaktionsmodus eingeführt, der zur Benennung von Mo-
dellelementen eingesetzt wird. Alternativ kann die Benennung durch Eingabe der Be-
zeichnung über eine Tastatur erfolgen.
Im Falle der Benennung mittels Haftnotizen wird ein Werkzeugtoken eingesetzt, auf
dem die Haftnotizen angebracht sind. Unmittelbar nach der Platzierung eines Elements
wird eine neue Haftnotiz beschriftet und mittels der Registrierungskamera erfasst. Wäh-
rend die Haftnotiz nun auf dem Modellelement angebracht werden kann, wird im System
das erfasste Bild ausgewertet, der geschriebene Text wird (als Grafik) extrahiert und dem
zuletzt auf der Oberfläche platzierten Token zugeordnet. Soll ein Element nachträglich
(um)benannt werden – wenn also zwischenzeitlich ein weiteres Element platziert wur-
de – muss das zu benennende Element mit dem Markierungstoken ausgewählt werden.
Das Markierungstoken wird dazu in der Nähe des Elements auf die Oberfläche gesetzt.
Visuelles Feedback auf der Oberfläche signalisiert eine erfolgreiche Auswahl. In der Fol-
ge kann die neue Benennung mittels des Registrierungstokens erfasst und am Element
angebracht werden. Die Benennung mittels Haftnotizen ist insofern problematisch, als
dass die Extraktion der handschriftlichen Benennung nur unzuverlässig funktioniert. Dies
212
7.3. Benutzerinteraktion mit dem Werkzeug
liegt vor allem an zu geringem Kontrast zwischen Haftnotiz und Schrift ( bei schlechten
Lichtverhältnissen) und einer zu geringen Auflösung der Registrierungskamera. Außer-
dem werden keine Schrifterkennungs-Algorithmen eingesetzt, wodurch der Schriftzug für
das System immer lediglich eine Menge von Bildpunken ohne weitere Bedeutung bleibt.
Um die Nachteile der Benennung mit Haftnotizen zu vermeiden, wurde ein alterna-
tiver Interaktionsmodus zur Benennung von Modellelementen eingeführt. Dieser läuft
grundsätzlich identisch ab, setzt jedoch anstatt der Haftnotizen eine Tastatur ein, über
die die Benutzer die Benennung dem System bekannt geben. Die eingegebene Informa-
tion wird dann auf der Oberfläche unmittelbar unterhalb des Elements angezeigt (siehe
Abschnitt 8.3.3). Die Auswahl des zu benennenden Elements erfolgt wiederum durch das
Markierungstoken. Die Vorteile dieses Systems liegen in der geringen Fehlerrate und der
hohen Geschwindigkeit der Eingabe (etwa Faktor 10 schneller als die Eingabe mittels
Haftnotiz). Der Nachteil dieses Ansatzes ist der exklusive Zugang zum Eingabemedium,
der Tastatur. Während es beim Einsatz von Haftnotizen grundsätzlich möglich ist, diese
simultan zu erstellen (auch wenn die Registrierung sequentiell erfolgen muss), kann bei
der Verwendung der Tastatur zu einem Zeitpunkt immer nur ein Element bearbeitet
werden.
Grundsätzlich sind die beiden Interaktionsmodi zur Benennenung von Elementen als
Ergänzung zueinander zu sehen. Sie können grundsätzlich gleichzeitig eingesetzt werden
und bieten den Benutzern eine Wahlmöglichkeit zwischen einer langsameren, dafür aber
physisch existenten oder einer schnelleren, dafür nur über die Ausgabekanäle des Systems
sichtbaren Benennung. Die Erkennungsprobleme der Haftnotizen-Variante (die zur Ein-
führung des zweiten Interaktionsmodus geführt hatten) können durch eine Verbesserung
der technischen Rahmenbedingung ausgemerzt werden, wozu aber bei der Erstellung des
hier vorgestellten Prototypen keine Ressourcen vorhanden waren. Im Falle einer Verbes-
serung könnten den Benutzern zwei gleichwertige Eingabekanäle zur Verfügung gestellt
werden. Vorerst bietet der Einsatz der Tastatur jedoch nicht vernachlässigbare Vorteile
hinsichtlich der Zuverlässigkeit und der Genauigkeit der Erfassung von Benennungen.
7.3.3. Verbinden von Modellelementen
Das Verbinden von Modellelementen ist neben dem Hinzufügen und Benennen der dritte
wesentliche Interaktionsmodus, der zum Aufbau eines Modells benötigt wird. Verbindun-
gen werden nicht physisch gelegt sondern mit Werkzeugtokens erstellt und dann über die
Outputkanäle visuell dargestellt. Die Entscheidung gegen eine physische Repräsentation
der Verbindungen fiel zugunsten einer leichteren Veränderbarkeit des gesamten Modells
– das Verschieben eines Elements verursacht so keinen zusätzlichen Aufwand, wohinge-
gen physische Verbinder nachgeführt werden müssen bzw. eine beliebige Neuanordnung
verhindern.
213
7.3. Benutzerinteraktion mit dem Werkzeug
Die Erstellung von Verbindern kann wie die Benennung auf zwei unterschiedliche Arten
erfolgen, die sich aber ihrer Ausdrucksmächtigkeit bzw. Flexibiliät unterscheiden. Der
flexiblere Interaktionsmodus ist jener, der unter Einsatz von zwei Markierungstokens
durchgeführt wird. Dabei wird jeweils ein Markierungstoken neben einem der beiden zu
verbindenden Modellelemente platziert, wodurch diese ausgewählt und anschließend ver-
bunden werden. Das Verbindungskriterium ist, dass die beiden Modellelemente innerhalb
von 3 Sekunden nacheinander ausgewählt werden. Dies erlaubt sowohl eine gleichzeiti-
ge Platzierung von zwei Markierungstokens als auch die Arbeit mit nur einem Token,
das rasch hintereinander neben die zu verbindenden Elemente gesetzt wird. Die Arbeit
mit den herkömmlichen Markierungstokens erzeugt ungerichtete Verbindungen. Wer-
den gerichtete Verbindungen benötigt (deren Richtung mit einer oder im Falle einer
bidirektionalen Verbindung mit zwei Pfeilspitzen angezeigt wird), müssen spezielle Mar-
kierungstokens verwendet werden, deren Grundfläche die Form einer Pfeilspitze hat und
die neben dem entsprechend zu markierenden Modellelemente platziert werden müssen.
Der alternative Interaktionsmodus zur Herstellung einer Verbindung kommt ohne
Werkzeugtokens aus und basiert ausschließlich auf der Manipulation der Modellelemen-
te. Werden zwei Modellelemente an ihren Längsseiten nahe zusammengeführt, so erstellt
das System zwischen diesen beiden Elementen eine Verbindung. Im Interaktionsablauf
bedeutet dies, dass ein Benutzer die beiden zu verbindenden Elemente ergreift und diese
auf der Oberfläche von ihrer ursprünglichen Position aus kurz zusammenführt um sie
danach sofort wieder an ihre Originalposition zurück zu stellen. Die so erstellten Verbin-
dungen sind immer ungerichtet und werden nach der Erstellung gleich behandelt wie mit
den Markierungstokens erstellte Verbindungen. Durch die Vermeidung der Verwendung
von Werkzeugtokens ist dieser Weg zur Herstellung von Verbindungen schneller auszu-
führen als der zuvor beschriebene (etwa um den Faktor 5). Problematisch wird diese Art
der Interaktion dann, wenn die Modellierungsoberfläche bereits sehr voll ist, so dass nur
noch wenig Platz zur Zusammenführung von zwei Elementen vorhanden ist. Auch bei
Bedarf nach gerichteten Verbindern muss auf Markierungstokens zurückgegriffen werden.
Markierungen können unabhängig von ihrem Erstellungsweg auch benannt werden.
Da sie keine physische Repräsentation besitzen, kann der Benennungsmodus mit Haft-
notizen nicht verwendet werden. Die Eingabe von Bezeichnungen erfolgt demnach aus-
schließlich über die Tastatur. Zur Benennung einer Verbindung muss unmittelbar nach
deren Erstellung die Bezeichnung eingegeben werden, diese wird dann der zuletzt erstell-
ten Verbindung zugewiesen. Um eine Bezeichnung zu ändern oder im Nachhinein zuzu-
weisen, muss der Verbinder mittels dem Markierungstoken ausgewählt werden. Durch
nachträgliches Aufsetzen des Pfeilspitzen-Tokens auf eine existierende Verbindung wird
am jeweils näheren Verbindungsende eine Pfeilspitze hinzugefügt oder entfernt werden.
214
7.3. Benutzerinteraktion mit dem Werkzeug
7.3.4. Löschen von Elementen und Verbindungen
Beim Löschen muss zwischen dem Entfernen von Elementen und Verbindungen unter-
schieden werden. Beide Modellaspekte sind nicht nur hinsichtlich der Interaktion mit
dem System unterschiedlich zu behandeln, es besteht vor allem eine Existenzbeziehung
zwischen Elementen und Verbindungen, d.h. dass Verbindungen nicht ohne ihre als End-
punkte dienenden Elemente existieren können und beim Entfernen eines Elements eben-
falls gelöscht werden müssen.
Das Löschen eines Modellelements aus dem aktuellen Modell erfolgt durch Entfernen
der zugehörigen Tokens auf der Oberfläche. Hier muss zwischen Entfernungsvorgängen
unterschieden werden, die vom Benutzer intendiert sind und solchen, die durch die Mani-
pulation des Modells unabsichtlich und kurzzeitig auftreten. Nur in ersterem Fall dürfen
die Verbindungen, die an einem Element hängen, ebenfalls gelöscht werden. Die Unter-
scheidung zwischen den beiden Fällen wurde durch die Einführung eines Zeitintervalls
von 5 Sekunden gelöst, nachdem die betroffenen Verbinder ebenfalls entfernt werden.
Wird also ein Modellelement nur an eine andere Stelle verschoben (und verschwindet
so kurzzeitig aus dem Blickfeld der Kamera), bleiben die Verbindungen erhalten. Wird
das Element zur Seite gestellt, wird es und seine abhängigen Verbindungen zwar auf
den Ausgabekanälen nicht mehr dargestellt, das tatsächliche Löschen erfolgt aber erst
nach 5 Sekunden. Wird das Element innerhalb dieser Zeitspanne wieder auf der Oberflä-
che platziert, wird es und seine abhängigen Verbindungen so behandelt, als ob es nicht
verschwunden gewesen wäre.
Das Löschen von Verbindern ist durch den Einsatz der Lösch-Tokens möglich, das das
System in den Lösch-Modus schaltet, sobald es auf der Oberfläche platziert wird (und
diesen wieder deaktiviert, wenn es entfernt wird)6. Im Lösch-Modus wird der Einsatz
von Markierungstokens alternativ interpretiert. Anstatt der Herstellung einer Verbin-
dung wird bei Markierung von zwei Modellelementen eine eventuell zwischen diesen
vorhandene Verbindung endgültig entfernt. Dabei ist keine Unterscheidung zwischen
gerichteten und ungerichteten Verbindungen notwendig, es können durchgängig die ein-
fachen Markierungstokens eingesetzt werden.
7.3.5. Einbettung von Zusatzinformation
Der Interaktionsablauf zur Einbettung von Zusatzinformation setzt sich aus zwei Teilen
zusammen, die sequentiell abzuarbeiten sind. Der erste Schritt ist der Vorgang des Bin-
dens von Zusatzinformation an ein einbettbares Token. Im zweiten Schritt muss dieses
6Diese Verhalten wurde aufgrund von Erkenntnissen in der empirischen Untersuchung später modi-
fiziert. Das Löschtoken fungierte dann nicht mehr als Schalter zum Aktivieren eines Löschmodus,
sondern ermöglichte ein unmittelbares Entfernen der Verbinder, auf dem es aufgesetzt wird. Details
zu dieser Veränderung und deren Auswirkungen sind in den Abschnitten 10.11, 12.1.2 sowie 12.3.8
angeführt.
215
7.3. Benutzerinteraktion mit dem Werkzeug
Token in einem Container-Token eingebettet werden. Ein dritter Interaktionsablauf in
diesem Zusammenhang ist das Abrufen bzw. die Manipulation der eingebetteten Infor-
mation, der in der Folge ebenfalls im Detail beschrieben wird.
Das Binden von Information an ein einbettbares Token ist ein Vorgang, der nicht aus-
schließlich in der physischen Welt durchgeführt werden kann. Die anzubindende Infor-
mation liegt im Regelfall digital vor und muss damit am Rechner selektiert werden. Der
zugehörige Informationsablauf beginnt mit der Auswahl eines einbettbaren Tokens, des-
sen Form die Art der einzubettenden Information bestimmt. Im konkreten Fall wurden
drei Arten von einbettbaren Tokens erstellt, von denen eines der Umsetzung der Abs-
traktion von Modellen (also der Einbettung von Teilmodellen in ein Containerelement)
dient und die anderen beiden exemplarisch die Anbindung von digitalen Ressourcen aus
der Arbeitsumgebung demonstrieren. Im Sinne des Interaktionsablaufs sind diese Arten
zum Teil unterschiedlich zu behandeln. Bei allen Token startet die Interaktion mit der
Registrierung des Tokens mittels der Registrierungskamera. Handelt es sich dabei um
ein Token, das der Einbettung von Teilmodellen dient, wird der aktuelle Modellzustand
auf der Modellierungsoberfläche erfasst, gespeichert und an das Token gebunden. Der
Vorgang der Informationsanbindung ist in diesem Fall abgeschlossen. Daneben existieren
Tokens, an die beliebige digitale Ressourcen in der Form von Dateien gebunden werden
können. Die Registrierung eines derartigen Tokens öffnet in diesem Fall eine Dialogbox
am Rechner, in der die digitale Ressource ausgewählt werden kann. Die gewählte Datei
wird dann über eine Referenz an das Token gebunden. Die dritte Art von einbettbaren
Tokens demonstriert die Anbindung von spezialisierterer Information, die in einem An-
wendungsfall sinnvoll sein können und ggf. auch gesondert behandelt werden müssen.
Im konkreten Fall wurde die Anbindung von unmittelbar aufgenommenen Bildern im-
plementiert, die so z.B. eine Abbildung eines Ausschnittes der realen Arbeitsumgebung
in das Modell ermöglichen. Im Interaktionsablauf löst die Registrierung eines derarti-
gen Tokens die Speichung eines Bildes, das aktuell von der Registrierungskamera erfasst
wird, aus. Dieses Bild wird an das Token gebunden, der Interaktionsablauf ist damit
ebenfalls wieder beendet.
Im zweiten Schritt, der zur Einbettung von Information notwendig ist, muss das ein-
bettbare Token einem Containertoken zugeordnet werden. Dazu muss das betreffende
Container-Token geöffnet werden. Das einbettbaren Token, an das bereits Information
gebunden wurde, wird erneut mit der Registrierungskamera erfasst, was eine Zuordnung
zwischen diesem Token und dem offenen Container auslöst. Visuelles Feedback über die
Ausgabekanäle zeigt eine erfolgreiche Zuordnung an. Das einbettbare Token kann nun
auch physisch in den Container gelegt werden und ist diesem damit auch in der realen
Welt zugeordnet. Der Interaktionsvorgang endet mit dem Schließen des Containerto-
kens. Der hier beschriebene Vorgang ist insofern als Hilfskonstrukt zu sehen, als das er
nicht notwendig ist, wenn die Containertoken in der Lage wären, ihren Inhalt selbst zu
identifizieren. Wie in Abschnitt 7.1.1 argumentiert, wurde aber auf diese Funktionalität
verzichtet. Dies ist für den prototypischen Einsatz akzeptabel, im Realbetrieb jedoch
216
7.3. Benutzerinteraktion mit dem Werkzeug
insofern problematisch, als dass durch den indirekten, mehrstufigen Zuordnungprozess
ein inkonsistenter Zustand zwischen physischer und digitaler Modellrepräsentation nicht
ausgeschlossen werden kann.
Um eingebettete Information wieder abrufen zu können, wurde ebenfalls ein Inter-
aktionsablauf definiert. Dieser beginnt mit dem Öffnen des entsprechenden Container-
Tokens. Durch Herausnehmen des informationstragenden Tokens und eine Erfassung
desselben mit der Registrierungskamera wird die angebundene Information abgerufen.
Handelt es sich um ein Token mit angebundenem Teilmodell, so wird dieses über die
Output-Kanäle dargestellt. Angebundene digitale Ressourcen werden am Rechner ge-
öffnet und dargestellt. Das eingebettete Token bleibt dem Container-Token zugeordnet,
es muss also zur Konsistenzsicherung nach dem Abrufen der Information wieder in den
Container gelegt werden. Um ein eingebettetes Token aus einem Container zu entfernen,
muss bei der Erfassung dieses Tokens das Radierer-Werkzeug-Token eingesetzt werden
und das System so in den Lösch-Modus versetzt werden. Die Information bleibt dabei
an das einbettbare Token gebunden. Eine Veränderung der angebundenen Information
während eines Modellierungsvorgangs ist nicht vorgesehen, es muss ggf. ein weiteres,
noch unbelegtes einbettbares Token verwendet werden.
7.3.6. Kontrolle der Modellierungshistorie
Die Kontrolle der Modellierungshistorie umfasst im Wesentlich drei Interaktionsblöcke,
die im Folgenden beschrieben werden. Der erste Block behandelt die Erfassung von Mo-
dellzuständen, im zweiten Block wird die Navigation durch die Modellierungshistorie
behandelt und der dritte Block beschäftigt sich mit der Unterstützung der Wiederher-
stellung von gespeicherten Modellzuständen.
Die Erfassung von Modellzuständen erfolgt im Normalfall implizit und muss von den
Benutzern nicht explizit ausgelöst werden. Wenn sich das Modell auf der Modellierungs-
oberfläche länger als 5 Sekunden in einem stabilen Zustand befinden (wenn also weder
die Position, noch die Rotation oder die Benennung der Tokens geändert wurden und
auch keine Verbindungen oder Einbettungen erstellt wurden), wird der aktuelle Mo-
dellzustand gespeichert. Sollen bestimmte Modellzustände aber aufgrund ihrer Relevanz
für den Modellierungsverlauf explizit gespeichert und auch entsprechend gekennzeichnet
werden, so kann das Snapshot-Token eingesetzt werden. Dieses löst, sobald es auf der
Modellierungsoberfläche aufgesetzt wird, die Speicherung des aktuellen Modellzustandes
aus. Das System quittiert die Speicherung mit visuellem Feedback über die Ausgabe-
kanäle. Explizit erfasste Zustände werden im Gegensatz zu automatisch gespeicherten
gekennzeichnet und in den weiterverarbeitenden Modulen (vor allem bei der Persistie-
rung) speziell behandelt.
Die Navigation durch die Modellierungshistorie erfolgt mittels einem rundenWerkzeug-
Token, dass diese Navigation durch Rotation im oder entgegen dem Uhrzeigersinn er-
217
7.4. Erfassung der Benutzerinteraktion durch Software
möglicht. Das System wird durch das Aufsetzen dieses Tokens auf die Modellierungs-
oberfläche in den Historien-Modus geschaltet, was Auswirkungen auf die Darstellung
des Modells in den Outputkanälen (siehe Abschnitt 8.3.3) hat. Bei Aktivierung des
Historien-Modus wird der aktuellste gespeicherte Modellzustand geladen. Durch Dre-
hen des Tokens gegen den Uhrzeigersinn kann in der Zeit zurück navigiert werden. Das
Laden der nächstälteren Modellzustands erfolgt dabei in regelmäßigen Intervallen von
jeweils 45 Grad (8 Modellzustände pro voller Umdrehung). Der absolute zeitliche Ab-
stand zwischen den gespeicherten Modellzuständen, der sich aus dem Auftreten stabiler
Modellzustände ergibt, wird bei der Navigation nicht berücksichtigt – der zurückzule-
gende Winkel ist immer gleich groß. Gleiches gilt sinngemäß für das Drehen des Tokens
im Uhrzeigersinn – dabei wird in regelmäßigen Abständen der nächstjüngere Modell-
zustand geladen. Wird das Token entfernt, wird der Historien-Modus deaktiviert und
wieder in der aktuelle Systemzustand an die Output-Kanäle übergeben.
Soll ein gespeicherter Modellzustand wiederhergestellt werden, so bietet das System
Unterstützung für die dazu notwendige Interaktion. Da weder die Tokens noch der Tisch
selbst über durch den Rechner steuerbare bewegliche Komponenten verfügen, die ei-
ne automatisierten Wiederherstellung eines Modellzustandes ermöglichen, kommt die
Aufgabe der eigentlichen Wiederherstellung den Benutzern zu. Das System unterstützt
dabei insofern, als das über die Ausgabekanäle Information an die Benutzer weiterge-
geben wird, die die korrekte Platzierung der Elemente anleitet (Details dazu sind in
Abschnitt 8.3.4 nachzulesen). Gespeicherte Modellzustände können dabei entweder aus
dem Historienmodus oder aus an eingebettete Tokens gebundene Teilmodelle bezogen
werden. Im ersten Fall wird die Wiederherstellungsunterstützung durch ein spezielles
Token aktiviert, das auf die Oberfläche aufgesetzt wird während der alte Systemzustand
über die Outputkanäle dargestellt wird. Im zweiten Fall muss das Teilmodell, das an
das eingebettete Token gebunden ist, über die Registrierungskamera abgerufen werden,
wodurch es ebenfall über die Outputkanäle dargestellt wird. Während der Darstellung
wird die Wiederherstellungsunterstützung wiederum durch Aufsetzen des betreffenden
Werkzeug-Tokens auf die Oberfläche aktiviert. In beiden Fällen läuft dann die Wie-
derherstellungsunterstüztung durch das System angeleitet automatisiert ab. Nach Ab-
schluss der Wiederherstellung werden die Benutzer aufgefordert eventuell noch vorhan-
dene Werkzeug-Tokens (wie das Historien-Navigations-Token) zu entfernen, wodurch das
System wieder den aktuellen Modellzustand als Grundlage der Darstellung verwendet.
7.4. Erfassung der Benutzerinteraktion durch Software
Das Software-System, das die Benutzereingaben von der Hardwareschnittstelle bis hin
zur abstrahierten Modellierungsinformation aufbereitet, ist Gegenstand dieses Abschnitts.
Die darüber hinausgehenden Komponenten sind Gegenstand der Kapitel 8 und 9. Die
hier behandelten Software-Komponenten umfassen
218
7.4. Erfassung der Benutzerinteraktion durch Software
• jene Komponente, die die Rohdaten von ReacTIVision empfängt und sie hinsicht-
lich der Modellierungsinformation auswertet und interpretiert,
• die Komponente, die für die Stabilisierung der Erkennungsleistung sorgt, wenn
Fehlerkennung oder Erkennungsausfälle auftreten, sowie
• jene Komponente, die für das Tracking des Modellzustandes und damit für die
Nachvollziehbarkeit des Modellierungsablaufs zuständig ist.
Wie in Abschnitt 7.1.3 ausgeführt, soll zur Verknüpfung dieser Komponenten das TUIpist-
Framework zum Einsatz kommen. Im vorliegenden Prototypen wurde das System jedoch
zwar modular aber ohne Einsatz des TUIpist-Frameworks implementiert. Eine erste Um-
setzung der Architektur auf die TUIpist-Strukturen liegt vor, ist jedoch noch nicht im
produktiven Einsatz. An dieser Stelle wird deshalb der Aufbau der Komponenten in
ihrer derzeitigen Implementierung beschrieben, da diese auch bei der Evaluierung des
Werkzeugs eingesetzt wurde. Erste Umsetzungserfahrungen deuten darauf hin, dass der
Aufwand zur Einbindung von TUIpist sich wie erwartet in Grenzen hält.
Die Systemarchitektur, wie sie sich in der derzeitigen Implementierung darstellt, ist
in Abbildung 7.19 dargestellt. Die Komponenten des Interpretations-Moduls leiten sich
aus den umzusetztenden Funktionen und zu erkennenden Interaktionsabläufen (siehe
Abschnitt 7.3) ab. Die Komponenten sowie die Verknüpfungen untereinander werden in
den folgenden Abschnitten im Detail beschrieben, wobei die Struktur der Beschreibung
im Gegensatz zum vorangegangenen Abschnitt nicht an der Funktionalität sondern an
den involvierten Technologien orientiert ist und damit einen weiteren Detaillierungs-
schritt in der Beschreibung der Benutzereingabe im hier vorgestellten System darstellt.
7.4.1. Interpretation der Rohdaten
Das ReacTIVision-Framework liefert, wie in Abschnitt 7.1.2 beschrieben, die aus dem
Kamerabild extrahierten Informationen über die auf der Oberfläche vorhandenen Modellierungs-
Elemente und Werkzeuge. Für jeden erkennbaren Code wird eine separate Nachricht
gesandt, sobald sich zumindest ein Parameter (also Position oder Rotation) verändert.
Diese Nachrichten treffen über die UDP-Schnittstelle bei einem von ReacTIVision bereit-
gestellten Java-Objekt ein, das die Auswertung der Nachricht übernimmt und über einen
Callback-Mechanismus7 vom Anwendungsentwickler implementierte Methoden aufruft,
die auf das jeweilige Ereignis reagieren. Die Ereignisse, die auftreten können, beschrän-
ken sich auf das Erscheinen eines Tokens, die Änderung der Parameter eines Tokens und
das Verschwinden eines Tokens sowie die gleichen drei Ereignisse für die Behandlung ei-
nes Cursors (wie das Markierungs-Werkzeugtoken). Dazu werden jeweils die relevanten
7entsprechend dem in (Gamma et al., 1995) beschriebenen Beobachter-Muster (Observer), das bei
der Entwicklung wiederverwendbarer objektorientierter Software als Entwurfsmuster zum Einsatz
kommt
219
7.4. Erfassung der Benutzerinteraktion durch Software
Abbildung 7.19.: Softwarearchitektur zur Erkennung von Benutzerinteraktion
220
7.4. Erfassung der Benutzerinteraktion durch Software
Parameter zur Verfügung gestellt (im Wesentlichen die ID des Tokens, seine Position, sei-
ne Rotation und einige weitere abgeleitete Parameter, die in der konkreten Anwendung
nicht eingesetzt werden).
In den betreffenden Methoden wird im ersten Schritt ausgewertet, ob das identifizierte
Token ein Modellierungs-Element oder ein Werkzeug ist. Im Falle eines Modellierungs-
Elements wird im nächsten Schritt festgestellt, um welche Art von Token es sich handelt
und ob es im aktuellen Modellierungsvorgang bereits im Einsatz war (ob z.B. bereits
Information über die Benennung des Tokens oder dessen Inhalt vorhanden ist). Diese
Information wird ggf. geladen und den weiterverarbeitenden Komponenten zu Verfügung
gestellt. Im Falle eines Werkzeug-Tokens wird dieses identifiziert und an die für die
Behandlung zuständige Methode weitergeleitet. Diese Methoden schalten das System je
nach Art des eingesetzten Tokens in einen alternativen Zustand oder lösen eine Aktion
auf den übergeordneten Ebenen aus.
Ist für die Interpretation einer Benutzerinteraktion mehr als ein Token notwendig
(z.B. beim Ziehen von Verbindungen), werden die Kandidaten, die möglicherweise den
Beginn einer derartigen Interaktionssequenz darstellen, in einen Buffer geschrieben. Beim
Auftreten eines Tokens, das möglicherweise den zweiten Teil dieser Interaktion darstellt,
wird dieser Buffer geprüft und die Interpretation ggf. auf Basis der gespeicherten und
aktuellen Token-Daten durchgeführt.
Manche Benutzereingaben müssen – um eine komfortable Erstellung des Modells zu
ermöglichen – ggf. auch nach Entfernen eines Tokens für einen bestimmten Zeitraum
gespeichert werden. Beispiele hierfür sind Markierungen, die auch nach Entfernen des
Markierungstokens aktiv bleiben, um Zeit für die Benennung oder die Herstellung einer
Verbindung zu geben oder auch Modellierungstoken, die durch Manipulation temporär
aus dem Erkennungsbereich der Kamera geraten und in diesem Fall nicht sofort als
„entfernt“ interpretiert werden sollen. Auch in diesem Fall werden Buffer eingesetzt,
die die entsprechende Information mit einem Zeitstempel versehen aufnehmen. Zur Si-
cherstellung der Modellkonsistenz (also der Übereinstimmung zwischen physischem und
digitalem Modell) prüfen speziell dazu konzipiert Methoden, die von einem Timer in
regelmäßigen Abständen aufgerufen werden, ob die vorgegebene Gültigkeitsdauer der
Information bereits abgelaufen ist und entfernen diese ggf. endgültig aus dem Buffer und
dem Modell (löschen also konkret eine Markierung oder entfernen ein Modellelement und
alle abhängigen Verbindungen aus dem Modell). Die Zeitintervalle dieser Prüfungen sind
auf den jeweiligen Anwendungsfall abgestimmt und bewegen sich im Bereich zwischen
drei und fünf Sekunden.
7.4.2. Stabilisierung der Erkennungsleistung
Da wie bereits beschrieben beim Einsatz von ReacTIVision bei grenzwertigen Beleuch-
tungsbedingungen zu Erkennungsproblemen oder Fehlerkennungen neigt, wurden im
221
7.4. Erfassung der Benutzerinteraktion durch Software
Programmcode des Interpretationsmoduls Mechanismen verankert, die potentielle Feh-
lerkennungen und Erkennungsprobleme identifizieren und deren Auswirkungen ignorie-
ren sollen. Im Folgenden werden häufige Fehlerquellen benannt und der jeweilige Lö-
sungsansatz beschrieben.
Bildrauschen
Bei wenig vorhandenem Umgebungsumgebungslicht müssen die Kameraparameter wie
oben bereits beschrieben soweit nachgeführt werden, bis wieder ausreichender Bildkon-
trast vorhanden ist. Zur Nachführung eignen sich die Blende der Kamera und die Signal-
verstärkung. Eine offene Blende erhöht den Lichteinfall auf den Sensor und verbessert
damit die Bildhelligkeit und den Kontrast. Je weiter offen die Blende eingestellt ist,
desto geringer ist jedoch auch die Tiefenschärfe des Kamerabilds, d.h. dass die Kamera
sehr exakt auf die Modellierungsoberfläche fokussiert werden muss. Da der Abstand von
der Kamera zu Mitte des Tisches geringer ist als zu den Randbereichen, kann bei offe-
ner Blende nie die gesamte Oberfläche scharf eingestellt werden. Da ein unscharfes Bild
die Erkennungsleistung massiv mindert, sind der Nachführung des Blenden-Parameters
Grenzen gesetzt. Die Signalverstärkung wirkt demhingegen nicht direkt auf die Kamera
sondern auf das von ihr gelieferte Bild und ist deswegen keine physikalischen Beschrän-
kungen unterworfen. Bei der Erhöhung der Signalverstärkung werden helle Bereiche im
Bild heller, dunkle bleiben eher dunkel, der Kontrast wird also erhöht. Problematisch ist
in diesem Kontext, dass nicht nur das Nutzsignal (also das eigentliche Bild) verstärkt
wird, sondern auch das im Bild enthaltene Rauschen. Das Rauschen ist wiederum ein
physikalisches Phänomen der digitalen Bilderfassung und hat seinen Ursprung im bild-
aufnehmenden Chip. Während das Rauschen bei guten Lichtverhältnissen im Vergleich
zum Nutzsignal vernachlässigbar ist, wirkt es bei schlechten Lichtverhältnissen und dem-
entsprechend starker Signalverstärkung störend. Generell ist die Kamera deshalb so zu
kalibirireren, dass der Spielraum bei der Blendeneinstellung maximal ausgenutzt wird
(so dass die gesamte Oberfläche noch scharf abgebildet werden kann) und erst danach
die zu einer stabilen Erkennung notwendige Signalverstärkung eingestellt wird.
Ist trotz maximaler Blendenöffnung so wenig Licht vorhanden, dass es durch eine hohe
notwendige Verstärkung zu Bildrauschen kommt, ergeben sich Probleme bei der Bilder-
kennung. Diese äußern sich teilweise im temporären Nicht-Erkennen von auf der Ober-
fläche platzierten Tokens (weil das den Code enthaltende Nutzsignal im Bildrauschen
untergeht), vor allem aber im Auftreten von „Cursorflackern“. Mit „Cursorflackern“ wird
hier das Phänomen bezeichnet, das der Bilderkennungsalgorithmus vermeintlich auf die
Oberfläche aufgesetzte Cursor-Tokens (wie das Markierungstoken) erkennt und an das
Interpretationsmodul weiterleitet. Es kann so vorkommen, das fehlerhafte Markierun-
gen angezeigt werden oder sogar umgewollte Verbindungen entstehen. Diese Cursor ha-
ben eine sehr geringe Lebensdauer (im Bereich von unter 500 Millisekunden), da das
222
7.4. Erfassung der Benutzerinteraktion durch Software
Rauschen zufallsverteilt und dynamisch ist und eine als Cursor erkannte Konstellation
dementsprechend nicht lange erhalten bleibt.
Um das „Cursorflackern“ zu verhindern, kann einerseits auf Seiten des ReacTIVision-
Frameworks die Cursor-Größe erhöht werden, was die Wahrscheinlichkeit einer Fehler-
kennung durch die größere notwenige Fläche, auf der das Rauschen in der richtigen Form
auftreten muss, reduziert. Dementsprechend müssen aber auch etwaige Cursor-Tokens
in ihrer Größe angepasst werden, was nur in Grenzen möglich ist. Der alternative Ansatz
zur Kompensation von „Cursorflackern“ wurde im Interpretationsmodul implementiert
und basiert auf der Messung der Lebensdauer des Cursors. Wird von ReacTIVision das
Auftreten eines Cursors gemeldet, so wird dieser vom Interpretationsmodul nicht direkt
ausgewertet, sondern in einen Buffer geschrieben. Nach 600 Millisekunden wird geprüft,
ob der Cursor noch vorhanden ist oder ob er bereits wieder entfernt wurde (ob also eine
entsprechende Nachricht von ReacTIVision weitergegeben wurde). Im ersteren Fall kann
von einem bewusst gesetzten Cursor ausgegangen werden und dieser zur Weiterverarbei-
tung freigegeben werden. Im zweiten Fall handelt es sich mit hoher Wahrscheinlichkeit
um „Cursorflackern“, das ignoriert werden kann.
Technisch ist diese Funktion so umgesetzt, dass eine Meldung über das Auftreten eines
Cursors ein entsprechendes Objekt mit Zeitstempel in einen Buffer schreibt. Die Meldung
über das Verschwinden eines Cursors entfernt dieses Objekt dementsprechend wieder aus
dem Buffer. Ein Timer löst alle 300 Millisekunden eine Prüfung des Buffers aus, bei dem
alle Cursor, die älter als 600 Millisekunden sind, zur Weiterverarbeitung frei gegeben
werden. Alle jüngeren Cursor werden unverändert im Buffer belassen und – sofern dann
noch vorhanden – im nächsten Durchlauf erneut geprüft und ggf. frei gegeben. Durch den
potentiell simultanen Zugriff auf den Buffer (durch die Prüfungsroutine und den Cursor
hinzufügenden oder entfernenden Methoden) müssen hier synchronisierte, simultaner
Veränderung gegenüber stabile Buffer-Klassen eingesetzt werden.
Spotlights
Bei ungleichmäßiger Umgebungsbeleuchtung treten auf der Modellierungsoberfläche häu-
fig kleinere Bereiche auf, in denen die Helligkeit gegenüber der Umgebung erhöht ist. Der-
artige Bereiche entstehen unter anderem durch einfallendes Sonnenlicht, das durch un-
zureichende Verdunkelungsmaßnahmen nur zum Teil abgeschirmt wird oder auch durch
Reflexionen, die durch die die Lampe des Videoprojektors verursacht werden. In beiden
Fällen führen diese Bereiche, die im Folgenden als „Spotlights“ bezeichnet werden, zur
Fehlerkennung von Cursorn auf der Oberfläche. Im Gegensatz zum zuvor beschriebe-
nen „Cursorflattern“ bleiben diese „Spotlights“ jedoch über die Zeit stabil und werden
vom ReacTIVision-Framework als ständig vorhandene Cursor identifiziert. Bleibt diese
Fehlerkennung unkompensiert, so wird ein Token, das im Bereich des „Spotlights“ auf-
gesetzt oder dorthin bewegt wird, ohne weitere Benutzerinteraktion markiert (als ob es
223
7.4. Erfassung der Benutzerinteraktion durch Software
mit dem Markierungstoken ausgewählt wird). Dies führt wie zuvor zu Problemen bei
der Benennungen von Tokens bzw. zu unbeabsichtigten Verbindungen.
Um die Fehlerkennung von Cursors durch Spotlights zu verhindern, kann einerseits wie-
derum die Möglichkeit der oben bereits beschriebenen Konfiguration der Cursorgröße im
ReacTIVision-Framework genutzt werden. Da diese jedoch den ebenfalls erwähnten Ein-
schränkungen unterliegt, ist eine Behandlung im Interpretationsmodul notwendig. Der
Lösungsansatz zur Kompensation beruht wiederum auf einer Messung der Lebensdauer
des betreffenden Cursors. Im Gegensatz zur Behandlung des „Cursorflackerns“, bei dem
eine minimale Lebensdauer festgelegt wurde, wird bei der Behandlung von „Spotlights“
eine maximale Lebensdauer definiert, nach deren Überschreitung ein Cursor ignoriert
wird. Diese Grenze ist mit fünf Sekunden festgelegt – jeder Cursor, der länger auf der
Oberfläche identifiziert wird, wird ignoriert. Spotlights sind somit maximal fünf Sekun-
den nach ihrem Auftreten wirksam. Wenn sich in diesem Zeitraum kein Token in der
Nähe des Spotlights befindet, bemerken die Benutzer die Fehlerkennung nicht. Befin-
det sich zum Zeitpunkt der Erkennung ein Token in der Nähe, so wird dieses einmalig
markiert, wobei diese Markierung durch den in Abschnitt 7.3.3 beschriebenen Mechanis-
mus zur Begrenzung der Lebensdauer von Markierungen nach spätestens drei Sekunden
wieder verschwindet.
Technisch wurde diese Kompensationsmaßnahme als Erweiterung des oben beschrie-
benen Buffer-Ansatzes umgesetzt. Bei der Prüfung der Gültigkeit eines Cursor im Buffer
wird nun neben der minimalen Lebensdauer auch die maximale Lebensdauer miteinbe-
zogen. Ist die maximale Lebensdauer überschritten, so wird der Cursor aus dem Buffer
entfernt und damit so behandelt, als ob er von den Oberfläche verschwunden wäre. Diese
Maßnahme ist dann wirksam, wenn die „Spotlights“ tatsächlich über die Zeit stabil er-
kannt werden – setzt die Erkennung eines „Spotlights“ kurzfristig aus, so beginnt mit der
Wiedererkennung desselben die oben beschriebene 5-Sekunden-Frist bis zum Ignorieren
des erkannten Cursors von neuem. Um diese potentiellen Problematik zu begegnen, der
die Positionen von bereits erkannten Spotlights ebenfalls in einem Buffer abgelegt. Tritt
ein neuer Cursor an der Stelle eines bereits bekannten Spotlights auf, wird dieser sofort
ignoriert. Dabei kann die Applikation über die Laufzeit theoretisch zu restriktiv bei der
Akzeptanz von Cursorn umgehen, vor allem, wenn Markierungstokens regelmäßig län-
ger als fünf Sekunden auf der Oberfläche belassen werden und die zugehörigen Cursor
dadurch als Spotlights erkannt und deren Positionen gesperrt werden. In der Praxis ist
dieses Vorgehen jedoch kein Problem, da manuell platzierte Token kaum oder nur zufäl-
lig so positionsstabil auf der Oberfläche platziert werden können, dass exakt die gleiche
(und demnach gesperrte) Position getroffen wird. „Spotlights“ sind demhingegen hoch
positionsstabil und werden dadurch durch diese Maßnahme erfasst.
Ein weiteres Problem, das durch „Spotlights“ verursacht wird, die von unten auf die
Oberfläche geworfen werden (also z.B. durch den Videoprojektor verursacht werden) ist
eine potentielle Verdeckung von Teilen eines ReacTIVision-Codes, wodurch das betrof-
fene Token nicht mehr erkannt werden kann. Da die Störung permanent ist, kann diese
224
7.4. Erfassung der Benutzerinteraktion durch Software
durch Software nicht kompensiert werden und muss durch physische Maßnahmen kom-
pensiert werden. Im konkreten Fall wurde das Spotlight, das durch den Videoprojektor
verursacht wurde, durch eine punktuelle Abdeckung am Umlenkspiegel (siehe Abbildung
7.7) verhindert. Diese Maßnahme verhindert zwar auch eine Projektion im betroffenen
Bereich, diese Beeinträchtigung ist aber insofern akzeptabel, als dass auf der Oberfläche
ein Bereich von lediglich 0,5 cm im Durchmesser betroffen ist.
Überstrahlte Bereiche
Überstrahlte Bereiche können auftreten, wenn sich externe Lichtquellen direkt über der
Tischoberfläche befinden oder bei internen (im Werkzeug eingebauten) Lichtquellen kei-
ne Streuscheiben verwendet werden. Außerdem kann auch durch direkte Sonnenein-
strahlung ein Überstrahlen auftreten. In Abgrenzung zu „Spotlights“ sind überstrahlte
Bereiche großflächiger (potentiell die gesamte Oberfläche) und werden nicht als Cursor
erkannt. Überstrahlte Bereiche verursachen jedoch andere Probleme, die im Folgenden
behandelt werden.
Das größte Problem bei überstrahlten Bereichen ist die Verhinderung der Erkennung
von Codes im betroffenen Teil der Oberfläche. Überstrahlte Bereiche werden am Kame-
rabild unabhängig von den aktuell aufgesetzten Tokens rein weiß abgebildet. Dabei ist
es unwesentlich, dass externe Lichtquellen von Tokens teilweise verdeckt werden – die
Überstrahlungseffekte beeinflussen den adaptiven Erkennungsalgorithmus negativ und
verhindern so trotzdem eine Erkennung. Von Seiten der Interpretationsschicht können
keine Gegenmaßnahmen ergriffen werden, da auch über die Zeit hinweg im Normal-
fall keine Daten vorliegen, aus denen der Systemzustand im Falle von Fehlerkennun-
gen extrapoliert werden könnte. Softwareseitig ist damit nur eine Beeinflussung über
die Kalibrierungsparameter des ReacTIVision-Frameworks möglich. Auch hier ist der
Spielraum insofern eingeschränkt, als das eine Veränderung der Signalverstärkung keine
Verbesserung bringt, da überstrahlte Bereiche bereits den Bilderfassungschip der Kame-
ra übersteuern und damit im betroffenen Bereich keine Information vorhanden ist, die
durch Reduzierung der Bildverstärkung sichtbar gemacht werden könnte. Der einzige
Parameter, dessen Veränderung in diesem Zusammenhang sinnvoll ist, ist die Blenden-
öffnung der Kamera. Durch Schließen der Blende fällt weniger Licht auf den Sensorchip
– das Bild wird dunkler. Jedoch werden auch nicht überstrahlte Bereiche abgedunkelt,
was die Erkennung von Codes in diesen Teilen der Oberfläche schwieriger macht. Hier
kann wiederum eine Erhöhung der Signalverstärkung Abhilfe schaffen, die aber exakt mit
den Grenzwerten der Erkennbarkeit in den ehemals überstrahlten Bereichen abgestimmt
werden muss.
Ein zweites Problem, das bei nicht vollkommen überstrahlten Bereichen auftreten
kann, ist das zuvor bereits beschriebene „Cursorflackern“. Dessen Auftreten liegt in der
Funktionsweise des adaptiven Erkennungsalgorithmus von ReacTIVision begründet, der
in Bereichen mit geringem Kontrast (wie es nicht vollkommen aber beinahe überstrahlte
225
7.4. Erfassung der Benutzerinteraktion durch Software
Bereiche sind) auf geringe Strukturunterschiede im Bild relativ stark reagiert. Als Ge-
genmaßnahmen kommt auf Seite von ReacTIVision die wiederum die Veränderung der
Blende oder der Signalverstärkung in Frage, auf Seiten des Interpretationsmoduls wer-
den die Maßnahmen wirksam, die auch bei herkömmlichen „Cursorflackern“ zum Einsatz
kommen (siehe oben).
Bildverzerrungen
Bildverzerrungen werden durch das eingesetzte Objektiv der Kamera ausgelöst. Je größer
der Öffnungswinkel des Objektivs, desto höher sind bei Standardobjektiven die Verzer-
rungseffekte im Randbereich des erfassten Gebietes. Im konkreten System kommt ein Ob-
jektiv mit starkem Weitwinkel zum Einsatz, das die Erfassung der gesamtem Oberfläche
aus relativ geringem Abstand (und damit geringerer Tischhöhe) ermöglicht. Verzerrungs-
effekte führen im Normalfall zu einer Fehlpositionierung von Token im Randbereich, da
das Kamerabild im Vergleich zur realen Welt gestaucht ist. ReacTIVision bietet dazu die
Möglichkeit mit Hilfe eines Kalibirierungs-Musters eine Entzerrungsmatrix zu erfassen,
die zur Kompensation dieses Fehlers verwendet werden kann. Da die Bildverzerrung sich
zeitlich nicht verändert, ist keine weitergehende Kompensation dieser Fehlerkennung in
höheren Softwareebenen (wie dem Interpretationsmodul) notwendig.
Problematischer wird die Bildverzerrung dann, wenn durch sie in den Randbereich
soviel Bildinformation (durch die Stauchung des Bildes) verloren geht, dass eine Er-
kennung von in diesen Randbereichen platzierten Tokens nicht mehr möglich ist. Dies
tritt auf, wenn die Stauchung so stark wird, dass die schwarzen und weißen Bereich des
Codes nicht mehr trennscharf voneinander zu unterscheiden sind und ineinander fließen.
Je kleiner der Code im Bild dargestellt ist (also je weiter entfernt er ist, je kleiner er
physisch ist oder je geringer die Kameraauflösung ist), desto eher tritt dieser Effekt auf.
Da im gegebenen System sowohl die Entfernung zwischen Kamera und Oberfläche als
auch die Kameraauflösung vorgegeben sind, ist der einzige zu variierende Faktor die phy-
sische Größe des Codes. Diese wird jedoch von den Dimensionen der Tokens bestimmt,
die im konkreten System im Interesse der Handhabbarkeit der Modellierungselemente
eher gering gewählt wurden. Der nicht erkennbare Bereich kann nur durch Einsatz ei-
ner höher auflösenden Kamera oder durch größere Tokens erschlossen werden. Im ersten
Fall würde der Auswertungsaufwand und damit die notwendige Rechenleistung massiv
erhöht, im zweiten Fall wird die Handhabbarkeit negativ beeinflusst und die Anzahl der
gleichzeitig einsetzbaren Tokens reduziert. Softwareseitig kann aufgrund der fehlenden
Information in den Quelldaten keine Kompensation vorgenommen werden.
7.4.3. Erkennung von Markierungen und Verbindungen
Wie in den Abschnitten 7.3.2 und 7.3.3 beschrieben, werden ReacTIVision-Cursor ver-
wendet um eine oder mehrere Elemente auf der Tischoberfläche im Zuge eines Inter-
226
7.4. Erfassung der Benutzerinteraktion durch Software
aktionsablaufs zu markieren. ReacTIVision-Cursor sind helle, kreisrunde Bildbereiche
eines bestimmten Durchmessers. Diese Bildbereiche können durch Marker erzeugt wer-
den, in dem ein leerer weißer Kreis von einem schwarzen Ring umschlossen wird. Al-
ternativ erzeugt auch das Aufsetzen von Fingern derartige Bereiche auf der Oberfläche,
wodurch grundsätzlich die Realisierung eines (Multi-)Touch-Displays möglich ist. Da
durch variierende Fingergrößen und verschiedene Arten des Aufsetzens des Fingers (und
damit verschiedenen Abdrücken auf der Oberfläche) bei unterschiedlichen Modellierern
die Erkennung von Fingern nur teilweise stabil und zuverlässig funktioniert, wurde im
konkreten System die Marker-Variante zur Realisierung von Cursorn gewählt. Diese ist
aufgrund der definierten Größe des hellen Bildbereichs und der damit einhergehenden
exakteren Konfigurierbarkeit auch unempfindlicher gegenüber Störungen.
Im Gegensatz zu vollwertigen ReacTIVision-Markern, die ein Token zu jedem Zeit-
punkt eindeutig identifizieren, können mehrere gleichzeitig eingesetzte Cursor grundsätz-
lich nicht unterschieden werden (da sie alle den gleichen Code aufweisen). ReacTIVision
löst dieses Problem, indem für jeden Cursor eine nach der Reihenfolge des Auftretens ver-
gebene eindeutige Session-ID zugeordnet wird, der einen Cursor bis zum Zeitpunkt des
Verschwindens eindeutig identifiziert (diese Session-ID wird im übrigen auch vollwertigen
Markern zugeordnet, hat aber in der hier vorgestellten Anwendung keine Bedeutung).
Potentiell problematisch ist die Zuordnung einer Session-ID zu einem Cursor dann, wenn
die Beleuchtungsbedingungen schlecht sind, so dass das Cursor-Token nicht durchgän-
gig erkannt wird. In diesem Fall wird bei jeder (Wieder)-Erkennung des betreffenden
Tokens eine neue Session-ID zugeordnet, was gleichbedeutend mit dem Auftreten eines
neuen Cursors ist. Zur Kompensation können die bereits beschriebenen Mechanismen
eingesetzt werden, vor allem das Ignorieren von zeitnah nach dem Verschwinden eines
Cursors auftretenden neuen Cursorn an exakt der gleichen Position verhindert derartige
Fehlerkennungen weitgehend.
Wird ein Cursor-Token auf der Oberfläche aufgesetzt und von ReacTIVision erkannt,
werden die in Abschnitt 7.4.2 beschriebenen Prozesse zur Stabilisierung der Erkennungs-
leistung ausgeführt. Sobald der Cursor entsprechend lange stabil auf der Oberfläche er-
kannt wird, so dass eine Fehlerkennung weitgehend ausgeschlossen werden kann, wird im
Umkreis der Cursorposition (Radius etwa 5 Zentimeter) nach aktuell auf der Oberflä-
che vorhandenen Modellierungs-Tokens gesucht. Das dem Cursor am nächsten liegende
Token wird ausgewählt (insofern es innerhalb der Grenze von 5 Zentimetern liegt). Den
Benutzern wird diese Auswahl über die Ausgabekanäle rückgemeldet. Damit ist der
Markierungsvorgang grundsätzlich abgeschlossen.
In der Verarbeitung von Cursor sind noch zwei Spezialfälle zu betrachten, die im Kon-
text der Herstellung von Verbindungen auftreten. Im ersten Fall muss das Auftreten von
zwei Cursorn erkannt werden, die die zu verbindenden Modellelemente markieren. Eine
Verbindung wird dann hergestellt, wenn die beiden Cursor innerhalb von 3 Sekunden
jeweils in der Nähe eines Modellierungs-Tokens erkannt werden. Die grundlegende Er-
kennung einer Markierung läuft für beide Cursor wie im letzten Absatz beschrieben ab.
227
7.4. Erfassung der Benutzerinteraktion durch Software
Zusätzlich wird nach jeder erkannten Markierung geprüft, ob auf der Oberfläche eine
weitere aktive Markierung vorhanden ist (also eine, die in den letzten drei Sekunden
gesetzt wurde). Ist dies der Fall und wird die andere Markierung nicht bereits für ande-
re Zwecke (z.B. einen gerade laufenden Benennungsvorgang) verwendet, werden beide
Markierungen gelöscht und anstelle derer eine Verbindung zwischen den markierten Mo-
dellelementen eingefügt. Der zweite Spezialfall ist die Erkennung von gerichteten Ver-
bindungen, also das Auftreten von Werkzeug-Tokens, die einen Verbindungsendpunkt
mit Pfeilspitze kennzeichnen. Wie in Abschnitt 7.2.2 beschrieben, unterscheiden sich
diese Tokens von den anderen Markierungstokens durch einen zweiten Cursor-Marker,
der unmittelbar neben dem ersten angebracht ist. Tritt nun ein zweiter Cursor auf der
Oberfläche auf, der sich nahe eines bereits erkannten Cursors befindet (die Benachrich-
tigung über Erkennung erfolgt ereignisgesteuert und damit sequentiell, auch wenn beide
Cursor-Marker gleichzeitig auf der Oberfläche auftreten), muss die bereits erstellte Mar-
kierung für das nächstliegende Modellierungs-Token semantisch umgedeutet werden und
von einem Endpunkt einer ungerichteten Verbindung auf den einer gerichteten Verbin-
dung konvertiert werden.
Softwareseitig erfolgen die betreffenden Prüfungen in jenem Algorithmus, der auch die
Herstellung von Verbindungen prüft. Wenn also ein Cursor auf der Oberfläche auftaucht
und gleichzeitig schon ein weiterer aktiver Cursor vorhanden ist, wird neben den oben
beschriebenen Prüfungen zur Verbindungsherstellung auch eine Prüfung auf Nähe zu
bereits vorhandenen Cursorn durchgeführt und ggf. die Markierung des betroffenen Mo-
dellelements umgewandelt. Diese Veränderung der Markierung wird auch den Benutzern
über die Ausgabekanäle visuell kommuniziert.
7.4.4. Erkennung von geöffneten Tokens
In den Abschnitten 7.2.2 und 7.3.5 wurde bereits die Erkennung des Öffnungszustan-
des eines Modellierungs-Tokens konzeptuell beschrieben. Diese wird durch das Kame-
rasystem und ReacTIVision festgestellt. Dazu ist auf der beweglichen Rückwand der
Modellierungs-Tokens ein ReacTIVision-Code angebracht, der beim Öffnen auf der Mo-
dellierungsoberfläche zu liegen kommt und dadurch von der Kamera erfasst wird. Tech-
nisch sind dazu eine strukturelle Maßnahme und die Implementierung einer entsprechen-
den Interpretationsroutine notwendig.
Die strukturelle Maßnahme betrifft die Erkennung des auf der Rückwand angebrachten
ReacTIVision-Codes. Aufgrund der geringen Größe der Rückwand (10 cm x 4 cm) kann
kein herkömmlicher ReacTIVision-Code in ausreichender Größe angebracht werden. Re-
acTIVision erlaubt jedoch wie in Abschnitt 7.1.2 beschrieben die Erstellung von eigenen
Codes beliebiger Form. Die abgebildete Code-Topologie muss lediglich im Mapping-File
vermerkt werden um eine Abbildung auf einen eindeutigen Identifikationsnummer zu
ermöglichen. Wie in Abbildung 7.10 zu erkennen ist, wurde diese Möglichkeit im vorlie-
228
7.4. Erfassung der Benutzerinteraktion durch Software
genden Fall genutzt. Auf den Rückwänden der Modellierungs-Tokens ist ein einfacher,
länglicher Code angebracht, dessen Identifikationsnummer im Interpretationsmodul die
Routinen zur Beeinflussung des Öffnungszustands eines Tokens aufruft.
Im Interpretationsmodul wird beim Eingehen der Meldung über das Auftauchen eines
entsprechenden Markers dessen Position in Relation mit den Positionen der auf der Mo-
dellierungsoberfläche vorhandenen Modellierungs-Tokens gesetzt. Da auf allen Tokens
die gleichen Marker zur Identifikation des Öffnungszustands angebracht sind, muss das
betroffene Token über die Nähe zum erkannten Marker identifiziert werden. Befindet
sich also der Marker eines Modellierungstokens in unmittelbarer Nähe zum aufgetauch-
ten Token (Radius etwa 2,5 cm), so wird dessen Zustand auf „offen“ gesetzt. Befinden
sich mehrere Modellierungs-Tokens in diesem Radius, was bei sehr eng gesetzten Mo-
dellen möglich ist, so wird das nächstliegende ausgewählt (außer in einigen seltenen
Ausnahmekonstellationen ist das jenes Token, zu dem der erkannte Öffnungs-Marker
gehört). In der Weiterverarbeitung wird das das betreffende Modellelemente repräsen-
tierende Objekt (im objektorientierten Sinn) über die Änderung seines Öffnungszustan-
des benachrichtigt. Dieses wechselt seinen Zustand und löst visuelles Feedback über die
Ausgabekanäle aus. Außerdem reagiert es nun auf Anfragen bezüglich der Einbettung
von Zusatzinformation bzw. deren Abruf.
Sobald das Öffnungs-Token wieder von der Oberfläche verschwindet (das zugehöri-
ge Modellierungs-Token also geschlossen wurde), wird im Umkreis des verschwundenen
Markers nach geöffneten Modellierungs-Tokens gesucht. Das am nächsten liegende Ele-
ment wird geschlossen, was wiederum durch eine entsprechende Benachrichtigung des das
Modellelement repräsentierende Objekt realisiert wird. Grundsätzlich könnte eine Zuord-
nung zwischen Öffnungs-Marker und Modellierungs-Token auch über die Session-ID des
Öffnungs-Markers durchgeführt werden, die im Öffnungsvorgang dem entsprechenden
Modellierungs-Token zugeordnet werden könnte. Von dieser Vorgehensweise wurde je-
doch Abstand genommen, da im Falle von Fehlerkennungen des Öffnungs-Markers (kurz-
fristige Ausfälle, die zur Zuweisung einer anderen Session-ID führen) zu Zuordnung nicht
mehr korrekt vorgenommen werden kann. Deshalb wurde ein zustandsloser („state-less“)
Algorithmus eingesetzt, der durch die erneut durchgeführte Suche nach dem betroffenen
Modellierungs-Token nicht von einer früher gespeicherten Session-ID abhängig ist.
Einbetten und Abrufen von zusätzlicher Information
Im Zusammenhang mit der Erkennung von geöffneten Tokens kann auch die software-
seitige Behandlung von eingebetteter Information beschrieben werden. Diese wurde kon-
zeptuell bereits in Abschnitt 7.3.5 beschrieben. Anhand der nun folgenden Beschreibung
aus software-technischer Sicht kann nun auch die Einbindung der Registrierungs-Kamera
beschrieben werden.
229
7.4. Erfassung der Benutzerinteraktion durch Software
Die Registrierungskamera dient in diesem Kontext der Erkennung von einbettbaren
Tokens, wobei bei der Erkennung drei Fälle unterschieden werden müssen (in Klammer
jeweils die Bedingungen, die zur Auswahl eines der Fälle führen):
1. Information anbinden (noch keine Information angebunden)
2. Token einbetten (Information angebunden, Token noch nicht eingebettet, Container-
Token geöffnet)
3. Information abrufen (Information angebunden, Token noch nicht eingebettet oder
Token eingebettet und Container-Token geöffnet)
Technisch können Fall 1 und 2 auch gleichzeitig auftreten, wenn Information an ein Token
gebunden wird, während gleichzeitig ein Container-Token geöffnet wird. In diesem Fall
erfolgt die Einbettung unmittelbar nach dem Anbinden der Information.
Software-seitig beginnt der Prozess der Behandlung eines einbettbaren Tokens im-
mer gleich mit dem Schritt der Erfassung des einbettbaren Tokens durch die Regis-
trierungskamera. Diese ist konzeptuell als weiterer Eingabekanal zu sehen, die wie die
Hauptkamera Daten an das Interpretationsmodul liefert (siehe Abbildung 7.19), die die-
ses kontextsensitiv (also abhängig vom aktuellen Modellzustand) auswerten muss. Das
Signal der Registrierungskamera wird von einer zweite ReacTIVision-Instanz aufgenom-
men und ausgewertet. Diese ist mittels eines Brückenobjekts an das Interpretationsmodul
angebunden. Dieses Brückenobjekt nimmt eine Vorauswertung statt und liefert bereits
höherwertige Information an das Interpretationsmodul. So ist jegliche Benutzerinterak-
tion, die nicht unmittelbar Information über den aktuellen Modellzustand benötigt, in
diesem Objekt gekapselt (z.B. das Anbinden digitaler Information an ein einbettbares
Token). Interaktion, die verteilt über die Registrierungskamera und die Tischoberflä-
che abläuft, wird an definierten Schnittstellen an das die zuständigen Komponenten im
Interpretationsmodul übergeben.
Im konkreten Fall bedeutet dies, dass nach der Erfassung des Tokens durch die Regis-
trierungskamera die oben getroffene Fallunterscheidung wirksam wird, die – wie eben
angedeutet – je nach Art des einbettbaren Tokens noch zusätzliche Unterscheidungen er-
fährt. Bei Tokens, an die noch keine Information gebunden wurde, wird diese zusätzliche
Unterscheidung wirksam. Bei blauen einbettbaren Tokens wird eine Auswahlbox geöff-
net, mittels der eine anzubindende digitale Ressource im lokalen Dateisystem ausgewählt
werden kann. Ein gelbes Token löst die Aufnahme eines Fotos aus. Dieses wird wieder-
um im lokalen Dateisystem gespeichert und an das Token gebunden. Diese beiden Arten
werden vollständig im Brückenobjekt abgehandelt, den übrigen Komponenten wird ledig-
lich ein Datenobjekt übergeben, das der Weiterverarbeitung (also z.B. der eigentlichen
Einbettung) dient. Die Behandlung eines roten Tokens kann nicht im Brückenobjekt ver-
arbeitet werden, da es der Speicherung von Submodellen dient und dementsprechend auf
Information über den aktuellen Modellzustand auf der Modellierungsoberfläche angewie-
sen ist. Ein rotes Token löst deshalb einen Modellerfassungsvorgang, wie in Abschnitt
230
7.4. Erfassung der Benutzerinteraktion durch Software
7.4.7 weiter unten beschrieben, aus. Das erfasste Submodell wird danach an das rote
Token gebunden.
Ist bereits Information an ein Token gebunden, kann die Erfassung durch die Registie-
rungskamera der Startpunkt für die Fälle 2 oder 3 sein. Fall 2 tritt dann ein, wenn das
einbettbare Token noch keinem Container zugeordnet ist und ein Container geöffnet ist.
In diesem Fall wird das Objekt, das die einzubettende Information repräsentiert, an das
Modell-Objekt des Container-Tokens übergeben und ab diesem Zeitpunkt von diesem
verwaltet. Die erfolgreiche Zuordnung wird über die Ausgabekanäle visuell rückgemel-
det, das Token kann in der Folge auch physisch eingebettet werden (siehe Abschnitt
7.3.5). Fall 3 tritt ein, wenn entweder kein Container geöffnet ist oder das betreffende
Token bereits einem Container zugeordnet ist. Hier tritt wiederum die Unterscheidung
nach Art des einbettbaren Tokens in Kraft. Bei roten Token wird der gespeicherte Mo-
dellzustand über die Ausgabekanäle dargestellt. Bei gelben oder blauen Tokens wird
die angebundene digitale Ressource – wenn möglich – mittels der Standardapplikati-
on des Betriebssystems, die dem betreffenden Dateitypen zugeordnet ist, geöffnet und
dargestellt.
7.4.5. Benennung von Modellelementen
Abschnitt 7.3.2 beschreibt die zur Benennung von Modellelementen und Verbindun-
gen notwendige Interaktion. Wie dort angegeben, existieren zwei Eingabemodalitäten
für diese Funktionalität, die sich in ihrer technischen Umsetzung stark unterscheiden.
Gemeinsam ist beiden, das sie die angegebene Benennung dem jeweils markierten Ele-
ment zuweisen. Ist aktuell kein Modellierungs-Token markiert, wird die Benennung dem
zuletzt hinzugefügten Token zugeordnet. Die Verwaltung der Benennung obliegt dem
Modellobjekt – sie wird jedoch auch im Interpretationsmodul zwischengespeichert, um
die letzte Benennung eines zwischenzeitlich von der Modellierungsoberfläche entfern-
ten Objekts (dessen digitale Repräsentation bereits entfernt wurde) wiederherstellen zu
können. Dies ist notwendig, um die Wiederherstellung von eingebetteten Submodellen
gewährleisten zu können, dessen Modellierungstokens sich während der Modellerstellung
auf einer anderen Ebene nicht auf der Oberfläche befinden.
Benennung mittels Tastatur
Die Benennung mittels Tastatur ist die einzige Interaktion mit den Benutzern, die die
Verwendung eines herkömmlichen Eingabemediums bedingt. Um die Eingabe trotz des
„Medienbruchs“ möglichst nahtlos zu gestalten, wurde die Möglichkeit geschaffen, nach
der Auswahl eines Modellierungs-Tokens ohne weitere Interaktion über die graphische
Benutzungsschnittstelle des Systems mit der Eingabe beginnen zu können. Mit dem
ersten Tastendruck öffnet sich am Bildschirm eine Eingabemaske, mittels der die Be-
nennung durchgeführt werden kann. Eine Bestätigung mit der Eingabe-Taste schließt
231
7.4. Erfassung der Benutzerinteraktion durch Software
die Eingabemaske und weist die Benennung dem ausgewählten Element zu. Beginnt ein
Benutzer ohne vorhergehender Auswahl mit der Informationseingabe, so wird diese dem
zuletzt hinzugefügten Element (Modellelement oder Verbinder) zugewiesen.
Technisch ist die Eingabe mittels einem KeyListener implementiert, der das Beobach-
termuster (Gamma et al., 1995) in Java in Bezug auf Tastatureingaben benachrichtigt.
Das Interpretationsmodul wird also über jeden Tastendruck informiert und muss über
dessen Auswirkungen entscheiden. Ist der Tastendruck nicht dem Systemkonfigurations-
modus (siehe Abschnitt 8.4.1) zuzuordnen, wird die Eingabemaske aktiviert, die dann
alle weiteren Tastatureingaben abfängt, bis sie wieder geschlossen wird. Die Eingabe
wird in der Folge an die zuständigen Komponenten bzw. das betroffene Modell-Objekt
zur Weiterverarbeitung übergeben.
Benennung mittels Haftnotiz
Die Benennung mittels Haftnotiz ermöglicht die handschriftliche Benennung eines Mo-
dellelements oder Verbinders. Technisch wird sie über die Registrierungskamera abgewi-
ckelt. Die Haftnotiz muss dazu beschriftet werden und in der Folge mittels dem Regis-
trierungstoken (siehe Abschnitt 7.2.2) der Registrierungskamera zur Verfügung gestellt.
Die Erkennung des Registrierungstokens löst die Aufnahme eines Bildes aus, aus dem
in weiterer Folge die Beschriftung extrahiert wird. Dazu sind am Registrierungstoken
zwei ReacTIVision-Marker angebracht, die an definierten Positionen links und rechts
von der Haftnotiz sitzen. Durch diese beiden bekannten Position ist eine Ausrichtung
des Bildes möglich, so dass sich die Haftnotiz an einer definierten Position befindet, an
der sie schließlich ausgeschnitten wird. Dazu ist es notwendig, das Bild soweit zu rotie-
ren, dass sich die beiden Marker auf einer horizontalen Achse befinden und der physisch
linke Marker links im Bild dargestellt wird. Danach wird das Bild soweit skaliert, bis
der Abstand der beiden Marker einem vorab definierten Wert entspricht. Damit sind
die Ausmaße der Haftnotiz in horizontaler und vertikaler Richtung bekannt. Wird das
Bild nun soweit verschoben, dass sich die beiden Marker an vordefinierten Positionen
befinden, kann auch die Haftnotiz im Bild lokalisiert werden. Durch einen Ausschneide-
vorgang wird die Haftnotiz extrahiert. Das Bild wird nun mit einem adaptiven Algorith-
mus in eine Schwarz-Weiß-Grafik umgewandet. Der Algorithmus identifiziert dazu die
hellsten Bereiche (die Haftnotiz) und die dunkelsten Bereiche (der Schriftzug) im Bild.
Die hellsten Bereiche werden weiß, die dunkelsten Bereiche werden schwarz gesetzt. Die
dazwischenliegenden Werte mittels einem Schwellwert der bei 2/3 der Differenz zwi-
schen hellstem und dunkelstem Wert liegt, auf weiß oder schwarz gesetzt. Das Resultat
wird den weiterverarbeitenden Komponenten als Pixelgrafik zur Verfügung gestellt (wie
bei der Benennung mittels Tastatur). Durch die Bildverarbeitung ist die Position des
Registrierungstokens im Bild der Registrierungskamera irrelevant, da diese weitgehend
kompensiert werden kann. Durch die adaptive Umrechnung in eine Schwarz-Weiß-Grafik
232
7.4. Erfassung der Benutzerinteraktion durch Software
kann diese Art der Benennung auch bei schlechten Beleuchtungsbedingungen eingesetzt
werden.
7.4.6. Festlegung der Bedeutung von Modellelementen
Durch die Möglichkeit der Festlegung der Bedeutung eines bestimmten Modelltyps (sie-
he Abschnitt 7.3.1) wird die Forderung nach semantisch flexibler Modellierung umge-
setzt. Die Arten von Modellelementen sind semantisch nicht vorbelegt, sondern werden
während des Modellierungsvorgangs spezifiziert. Die Frage nach der Angabe des Bedeu-
tungstyps wird ausgelöst, wenn eine Tokenart erstmals auf der Oberfläche erkannt wird.
Über eine Eingabemaske und die Tastatur kann dann die Bedeutung textuell eingegeben
werden. Wird dieser Vorgang von den Benutzern abgebrochen, besteht die Möglichkeit,
die aktive Nachfrage bezüglich der Bedeutungszuordnung für den laufenden Modellie-
rungsvorgang auszuschalten um im Erstellungsprozess nicht unterbrochen zu werden.
Die Bedeutungszuordnung kann aber immer ausgelöst werden, wenn ein Token in den
Erfassungsbereich der Registrierungskamera gehalten wird. Das System fragt dann nach
der Zuordnung der Bedeutung zum jeweiligen Elementtyp.
Auf den Modellierungsvorgang selbst hat die Festlegung der Bedeutung technisch keine
Auswirkungen. Für die Persistierung des Modells ist sie jedoch von Bedeutung, da neben
dem eigentlichen Modell auch das Metamodell (und damit die Arten von verwendeten
Modellelementen und deren Bedeutung) gespeichert werden (siehe Kapitel 9).
7.4.7. Tracking des Modellzustandes
Das Tracking des Modellzustandes läuft von den Benutzern unbemerkt immer im Hin-
tergrund, kann jedoch auch explizit mit dem Snapshot-Token ausgelöst werden. Auch
die Speicherung von Submodellen auf einbettbare Token greift auf die gleichen Routi-
nen zurück. Die Speicherung von stabilen Modellzuständen basiert auf der Verfolgung
des Zeitpunkts der letzten Änderung im Modell. Dazu wird ein Zeitstempel mitgeführt,
der bei jeder Modelländerung aktualisiert, also auf die aktuelle Systemzeit gesetzt wird.
Änderungen sind das Platzieren, Verschieben oder Entfernen von Modellierungs-Tokens,
das Herstellen oder Löschen einer Verbindung, das Benennen eines Modellelements oder
einer Verbindung und das Einbetten von Zusatzinformation. In regelmäßigen Abständen
wird (durch einen Timer ausgelöst) geprüft, wieviel Zeit seit der letzten Modelländerung
vergangen ist. Sind mehr als fünf Sekunden vergangen, wird der aktuelle Systemzustand
gespeichert und die Prüfung gestoppt, bis die nächste Änderung auftritt. Damit wird
verhindert, dass in langen Phasen ohne Änderung mehr als eine Aufnahme angefertigt
wird.
Bei der Speicherung des Modellzustandes (egal ob automatisiert oder explizit ausge-
löst) wird eine Kopie der digitalen Modellrepräsentation angefertigt. Diese beinhaltet
233
7.4. Erfassung der Benutzerinteraktion durch Software
im Sinne einer „Deep Copy“ Kopien aller Informationen, die im Modell abgelegt sind,
so dass keine Referenzen mehr auf das aktuelle Modell zeigen. Damit wird sicherge-
stellt, dass laufende Änderungen am Modell keine Auswirkungen auf den gesicherten
Zustand haben. Technisch wurde dies gelöst, indem die „clone“-Methode aller daten-
tragenden Objekte (Modellobjekte und Verbindungsobjekte) so überladen wurden, dass
sämtliche referenzierten Objekte (etwa Benennungen, eingebettete Objekte, . . . ) dupli-
ziert werden und im kopierten Objekt Referenzen auf die erstellten Duplikate eingefügt
werden. Dieses Vorgehen ist bei großen Modellen und langer Modellierungszeit durch-
aus speicherintensiv und bedarf einer ausreichenden Größe des Heaps (der ggf. durch
Kommandozeilen-Parameter beim Start des Systems angepasst werden muss).
Navigation in der Modellierungshistorie
Die Navigation in der Modellierungshistorie wird mittels des in den Abschnitten 7.2.2
und 7.3.6 beschriebenen runden Tokens durchgeführt. Die Erkennung der Rotation er-
folgt durch den von ReacTIVision übergebenen Rotationswert des Tokens, der in Ra-
diant geliefert wird. Das Interpretationsmodul schaltet dementsprechend bei jeweils bei
Vielfachen von π
4
(also alle 45◦) einen gespeicherten Schritt weiter oder zurück (je nach
Drehrichtung).
Zur Verwaltung der Modellierungshistorie wird ein Objekt benutzt, das alle gespeicher-
ten Zustände in der Reihenfolge ihrer Speicherung referenziert, den aktuell ausgewähl-
ten Zustand speichert und den Abruf von gespeicherten Zuständen sowie die Navigation
durch diese ermöglicht. Dieses Objekt wird durch das Interpretationsmodul kontrolliert
und gesteuert – für übergeordnete Software-Module ist das Umschalten zwischen dem
aktuellen Modellzustand und einem gespeicherten Zustand transparent. Das Format, in
dem die gespeicherten Zustände ausgeliefert werden, entspricht jenem in dem auch die
aktuellen Modell-Daten verwaltet werden – dadurch wird auch das Umschalten auf einen
gespeicherten Zustand im Zuge einer Wiederherstellung einer vergangenen Modellversion
erleichtert.
Wiederherstellung eines Modellzustandes
Der Ablauf der Wiederherstellungsunterstützung wird – wie in Abschnitt 7.3.6 bereits
erwähnt – erst in Kapitel 8 im Detail beschrieben, da er vorrangig die Ausgabekanäle
betrifft. Da die Modellierungshistorie konzeptuell jedoch im Interpretationsmodul ange-
siedelt ist und der Vorgang der Wiederherstellung auch durch dieses ausgelöst wird (nach
Erkennung des entsprechenden Tokens), werden die technischen Details hier besprochen.
Im Zuge der Wiederherstellungsunterstützung müssen die Unterschiede zwischen dem
aktuellen Modell und dem wiederherzustellenden gespeicherten Zustand erkannt werden,
um die Benutzer schrittweise bei der Wiederherstellung anleiten zu können. Da nur die
234
7.4. Erfassung der Benutzerinteraktion durch Software
physischen Bausteine durch den Benutzer manipuliert werden müssen, beschränkt sich
die Differenzbildung zwischen den Modellen auf diese. Rein digitale Information – wie
die Verbinder – können am Ende des Wiederherstellungsvorgangs geladen und über die
Ausgabekanäle dargestellt werden. Bei den physischen Bausteine, also im wesentlichen
den Modellierungs-Tokens sind im ersten Schritt drei Fälle zu unterscheiden:
• Tokens, die im aktuellen Modell enthalten sind und im wiederherzustellenden Mo-
dell nicht vorhanden waren
• Tokens, die sich im aktuellen Modell an einer anderen Position befinden als im
wiederherzustellenden Modell
• Tokens, die im aktuellen Modell nicht vorhanden sind, im wiederherzustellenden
Modell aber vorhanden waren
Im ersten und dritten Fall reicht für die Erkennung eine Differenzbildung zwischen den
beiden Modellobjekt-Mengen aus, wobei im ersten Fall die Menge der wiederherzustellen-
den Modellobjekte von der aktuellen Menge der Modellobjekte abgezogen werden muss
um die zu entfernenden Tokens zu identifizieren, im dritten Fall umgekehrt die Men-
ge der aktuellen Modellobjekte von der Menge der wiederherzustellenden Modellobjekte
abgezogen wird um die hinzufügenden Tokens zu identifizieren. Im zweiten Fall muss für
jedes Token dessen aktuelle und gespeicherte Position verglichen werden um die zu ver-
schiebenden Tokens zu identifizieren. Zusätzlich muss noch der Inhalt der Tokens (also
deren eingebetteten Tokens) abgeglichen werden um auch hier Differenzen identifizieren
zu können.
Zur Durchführung der Wiederherstellungsunterstützung wird das System in einen spe-
ziellen Zustand geschaltet, in dem es aufgabengesteuert arbeitet. Jede vorzunehmende
Änderung im Modell wird auf eine Aufgabe abgebildet. Eine Aufgabe ist ein speziel-
les Objekt, das neben der vorzunehmenden Änderung auch eine Methode enthält, die
prüft, ob die Aufgabe erfolgreich abgeschlossen wurde (wobei die Bedingungen von der
konkreten Aufgabe abhängen). Befindet sich das System im Wiederherstellungsmodus,
wird bei jeder von ReacTIVision gemeldeten Änderung auf der Modellierungsoberflä-
che geprüft, ob mit dieser Änderung die Aufgabe erfüllt wurde. Ist dies nicht der Fall,
bleibt die Aufgabe aktiv. Wurde die Aufgabe erfüllt, wird durch einen erneuten Vergleich
zwischen Ist- und Soll-Zustand die nächste Aufgabe identifiziert und aktiv gesetzt. Da-
zu wird entsprechendes Feedback auf den Ausgabekanälen ausgegeben. Sobald Ist- und
Soll-Zustand gleich sind, werden die rein digitalen Teile des Modells geladen, womit das
aktuelle Modell dem gespeicherten Zustand vollständig entspricht.
7.4.8. Verteilung des Modellzustandes
Die Verteilung der darzustellenden Modellinformation an die übergeordneten Software-
module ist Gegenstand des letzten Abschnitts in diesem Kapitel. Die interpretierten
und aggregierten Informationen werden jenen Softwaremodulen zur Verfügung gestellt,
235
7.5. Zusammenfassung
die bisher in ihrer Gesamtheit als „Ausgabekanäle“ bezeichnet wurden. Diese Ausga-
bekanäle sind in der vorgestellten Anwendung mehrere grafische Oberflächen, die den
Systemzustand visuell widergeben (siehe dazu Details in Kapitel 8).
Wichtig im Kontext dieses Kapitels ist dabei, dass die Ausgabekanäle frei definier-
bar und erweiterbar sein sollen. Um dieser Anforderung auch vor dem Einsatz eines
Frameworks wie TUIpist gerecht zu werden, wurde eine Verteilungskomponente imple-
mentiert, die auf dem bereits oben mehrmals erwähnten Besuchermuster von Gamma
et al. (1995) basiert. Dabei registrieren sich Ausgabekanäle beim Interpretationsmodul
und werden danach über eine definierte Schnittstelle mit der entsprechenden Modellin-
formation versorgt. Die Schnittstelle ist Teil des Interpretationsmoduls und muss von
jedem Ausgabekanal vollständig implementiert werden, auch wenn dieser die betreffende
Information nicht benötigt (in diesem Fall bleibt die ausgabeseitig aufgerufene Methode
leer).
7.5. Zusammenfassung
In diesem Kaptitel wurde jener Teil des Werkzeugs im Detail beschrieben, der sich mit
der Erfassung und der Interpretation der Benutzereingaben beschäftigt. Im ersten Teil
wurden in Frage kommende technologische Ansätze zur Erfassung der Benutzeraktivität
betrachtet und einander gegenübergestellt. Nach der Entscheidung für den Einsatz eines
optischen Ansatzes wurden für diesen Zweck geeignete Frameworks betrachtet. Dabei
wurden Framework zur optischen Identifikation von physischen Tokens sowie generische
Frameworks, die als Middleware für Tabletop Interfaces geeignet sind, beschrieben und
vergleichen. Die Entscheidung fiel hier zugunsten ReacTIVision (Kaltenbrunner und
Bencina, 2007) als optisches Erkennungsframework und TUIpist (Furtmüller und Oppl,
2007) als Middleware.
Im zweiten Teil wurde die Umsetzung des Hardwarekomponenten beschrieben, die
maßgeblich von den zuvor getroffenen Technologie-Entscheidungen abhängig ist. Dabei
wurde die Infrastruktur des Werkzeugs beschrieben (der „Tisch“), wobei in diesem Kapi-
tel der Fokus auf jenen Komponenten lag, die die Erfassung von Benutzerinteraktion die-
nen. Zusätzlich wurden die eigentlichen Tokens, mit denen die Benutzer mit dem System
interagieren, beschrieben. Hier ist zwischen Modellierungs-Tokens und Werkzeug-Tokens
zu unterscheiden, wobei erstere der eigentlichen Modellbildung dienen und zweitere das
Systemverhalten kontrollieren.
Die eigentliche Interaktion der Benutzer mit dem System ist Gegenstand des dritten
Teils. Hier wurde die Verwendung der Tokens bei der Modellbildung und zur Steue-
rung des Systems skizziert und damit jene Interaktionsabläufe definiert, die vom Sys-
tem erkannt und korrekt interpretiert werden müssen. Die Unterabschnitte dieses Teils
236
7.5. Zusammenfassung
entsprechen im Wesentlichen den Anforderungen, die das Werkzeug erfüllen muss, und
beschreiben deren Umsetzung.
Nach der Definition der Interaktionsabläufe konnte im vierten Teil die software-technische
Behandlung der durch das ReacTIVision-Framework erkannten Eingabedaen beschrie-
ben werden. Die ersten beiden Abschnitte behandeln allgemein die Systemarchitektur
und die Kompensation eventueller Erkennungsprobleme der Tokens auf der Modellie-
rungsoberfläche. Zweiteres ist notwendig, weil optische Frameworks generell sensibel auf
Änderung der Beleuchtungsbedingungen reagieren und es dementsprechend zu (tempo-
rären) Fehlfunktionen bei der Erkennung kommen kann. Dazu wurden die möglichen
Fehlerquellen aufgelistet und die umgesetzten sowie zusätzlich mögliche Kompensati-
onsansätze beschrieben. In den übrigen Abschnitten wird die software-technische Er-
kennung und Behandlung der im vorhergehenden Teil definierten Interaktionsabläufe
beschrieben. Der Fokus lag hier auf den konzeptuellen Implementierungsdetails und der
Beschreibung der Lösung spezifischer Herausforderungen, die durch durch die gewählte
Technologiekonstellation auftreten. Im letzen Abschnitt wurde als Brücke zu den weite-
ren Kapiteln jene Komponente beschrieben, die für die Verteilung der Information an
die weiterverarbeitenden Software-Module zuständig ist.
7.5.1. Beitrag zur globalen Zielsetzung
In diesem Kapitel wird die konkrete Umsetzung des Werkzeugs behandelt. Hinsichtlich
der globalen Zielsetzung tragen die hier dargestellten Inhalte also zur Beantwortung der
Fragestellung 4 bei.
7.5.2. Weitere Verwendung der Ergebnisse
Die in diesem Kapitel getroffenen Technologieentscheidungen beeinflussen die Umset-
zung der in Kapitel 8 beschriebenen Ausgabekanäle. Auch die beschriebene Software-
Architektur wird in Kapitel 8 fortgeführt. Zusammen mit dem in Kapitel 8 beschriebenen
Ausgabekanälen sind die Inhalte dieses Kapitels außerdem Gegenstand der konzeptuellen
Prüfung des Werkzeugs in Kapitel 10.
237
8. Ausgabe
In diesem Kapitel wird die konzeptuelle Ausrichtung und technische Umsetzung jenes
Teils des Werkzeugs behandelt, der sich mit der Ausgabe von Information an die Be-
nutzer beschäftigt. Bei Tangible Interfaces erfolgt die Ausgabe von Information zumeist
kohärent mit dem Eingabemedium, eine physische Trennung zwischen Eingabe- und
Ausgabekanälen wie in der herkömmlichen Mensch-Maschine-Interaktion liegt nicht vor
(Ullmer und Ishii, 2000). Fishkin (2004) relativiert die strikte Forderung nach Kohä-
renz in seiner Taxonomie für Tangible Interfaces (wie in Abschnitt 6.4.11 beschrieben)
und klassifiziert Benutzungsschnittstellen unter anderem nach dem Grad der Kohärenz
von Ein- und Ausgabe. Dementsprechend sind nicht nur jene Ausgabekanäle Gegen-
stand dieses Kapitels, die Information in direkter Verbindung mit den Eingabemedien
zurückspiegeln, sondern auch jene, die Information auf anderen, nicht-kohärenten We-
gen ausgeben. Abbildung 8.1 stellt dieses Kapitel und dessen Aufbau im Kontext der
anderen inhaltlich vor- und nachgelagerten Kapitel dar.
Abbildung 8.1.: Kapitel „Ausgabe“ im Gesamtzusammenhang
Im ersten Abschnitt dieses Kapitels werden auf Basis der in Kapitel 5 genannten
Anforderung an das Werkzeug die den Benutzern mitzuteilenden Informationen identifi-
238
8.1. Auszugebende Information
ziert, noch ohne konkret auf die technologische Realisierung der Ausgabekanäle einzuge-
hen. Im darauf folgenden Abschnitt werden die technischen Möglichkeiten zur Ausgabe
von Information betrachtet. Im Anschluss werden diese Möglichkeiten hinsichtlich ihrer
Eignung für die im konkreten Anwendungsfall auszugebende Information bewertet und
entsprechend zugeordnet.
Auf Basis der grundsätzlichen Technologieentscheidung werden in der Folge Software-
Frameworks beschrieben, die die Realisierung der gewählten Ausgabekanäle ermögli-
chen. Die Entscheidung für ein konkretes Framework wird auf Basis der funktionalen
und nicht-funktionalen Anforderungen an die Ausgabe und deren Umsetzung getroffen.
Der letzte Abschnitt beschreibt die eigentliche Umsetzung der Ausgabekanäle mittels
der gewählten Technologie und geht auf die spezifischen Eigenschaften und Implemen-
tierungsentscheidungen der vorgestellten Lösung ein.
8.1. Auszugebende Information
Den Benutzern des Systems müssen während der Modellierung unterschiedliche Infor-
mation zur Verfügung gestellt werden. Einerseits ist dies Information, die das Modell
selbst betrifft, andererseits muss auch Information ausgegeben werden, die Aspekte des
Modellierungsablaufs beschreibt oder unterstützt.
Die das Modell betreffende Information umfasst folgende Aspekte:
• Die Modellelemente betreffende Information (Art, Position, Benennung)
• Die Verbinder betreffende Information (Art, Endpunkte, Benennung)
• Eingebettete Elemente betreffende Information (Art, Inhalt, Container)
Zur Unterstützung des Modellierungsablaufs müssen folgende Aspekte zur Verfügung
gestellt werden:
• Information über vergangene Modellzustände
• Information zur Wiederherstellung von Modellzuständen
Hier wird bewusst noch nicht auf die technische Umsetzung dieser Ausgabe eingegan-
gen. In den folgenden Abschnitten wird erörtert, welche grundlegenden Technologien in
Frage kommen, bevor auf Basis deren Eignung und den Vorgaben aus den Technologie-
entscheidungen zur Informationseingabe eine konkrete Lösung ausgewählt wird.
8.2. Technologische Grundlage der Ausgabe
Bei der Ausgabe von Information muss im Falle von Tangible Interfaces zwischen An-
sätzen mit unterschiedlich stark ausgeprägter Kohärenz mit den Eingabekanälen unter-
schieden werden. Unter Kohärenz ist hier zu verstehen, dass jene Artefakte, die zur Ein-
239
8.2. Technologische Grundlage der Ausgabe
gabe verwendet werden, gleichzeitig auch die Reaktion des Systems – also die Ausgabe –
wiederspiegeln. In der von Fishkin (2004) vorgeschlagenen Taxonomie (siehe Abschnitt
6.4.11) werden in der Dimension „Embodiment“ auch Werkzeuge als Tangible Interfaces
klassifiziert, bei denen die Ausgabe vollständig von der Eingabe entkoppelt ist. Diesem
Verständnis folgt auch diese Arbeit.
Bei Tabletop Interfaces bietet sich die Tischoberfläche als Ausgabemedium an, um
kohärente Informationsausgabe zu gewährleisten. Die Tischoberfläche dient hier wie in
Kapitel 7 beschrieben der Eingabe und kann durch unterschiedliche technologische Maß-
nahme auch zur Ausgabe genutzt werden. Eine weitere Möglichkeit die Ausgabekohärenz
bei Tabletop Interfaces sicherzustellen bzw. zu steigern, ist die Verwendung der zur In-
teraktion mit dem System verwendeten Tokens als Ausgabemedium. Je nach verfolgtem
Ansatz (bzw. einer Kombination) sind unterschiedliche technische Maßnahmen zu setzen.
In den folgenden Abschnitten werden die erwähnten grundsätzlich in Frage kommenden
Ansätze betrachtet und im Anschluss hinsichtlich ihrer Eignung für das hier entwickel-
te System beurteilt. Basierend auf der grundsätzlichen Technologieentscheidung werden
im Anschluss unterschiedliche technische Lösungen zur Erfüllung der Anforderungen
beschrieben.
8.2.1. Ansätze zur kohärenten Ausgabe
In diesem Abschnitt werden Ausgabeansätze behandelt, die nach (Fishkin, 2004) in der
Embodiment-Dimension den Ausprägungen „full“ oder „nearby“ zuzuordnen sind. Die
Ausgabe erfolgt bei den hier vorgestellten Ansätzen also direkt über die Eingabetokens
(„full“) oder ist räumlich unmittelbar in der Umgebung der Tokens angesiedelt.
Darstellung auf der Tischoberfläche
Bei Tabletop-Interfaces ist die Nutzung der Tischoberfläche ein naheliegender und gän-
giger Ansatz zur Realisierung der Ausgabekanäle. Die Ausgabe erfolgt hierbei vorrangig
visuell, also durch die Darstellung der auszugebenden Information. Ein derart ausge-
staltetes Interface ist hinsichtlich seiner Ausprägung in der Embodiment-Dimension als
„nearby“ zu klassifizieren. Technologisch kommen zur Darstellung horizontal eingesetzte
Bildschirme oder Oberflächen, auf die projiziert werden kann, in Frage.
Bei der Verwendung von Bildschirmen sind die Größe der zur Anzeige verwendbaren
Oberfläche sowie die zur Anzeige verfügbare Auflösung (also indirekt die Größe eines
Bildpunktes) wesentliche Kriterien. Bei heute verfügbaren LCD1-Modulen mit Größen
bis zu 132 cm in der Diagonale und Auflösungen von 1920 x 1080 Bildpunkten ist die
Technologie soweit ausgereift und verfügbar, dass dieser Ansatz grundsätzlich für den
Einsatz in Tabletop Interfaces in Frage kommt. Vorteile sind die geringe Bauhöhe der
1Liquid Crystal Display (Flüssigkristallanzeige)
240
8.2. Technologische Grundlage der Ausgabe
Ausgabeeinheit (im Vergleich zu den im Folgenden vorgestellten Projektions-Lösungen).
Nachteile sind die relative geringe Leuchtstärke, die einen Einsatz bei Tageslichtbedin-
gungen schwierig machen sowie die Blickwinkelabhängigkeit, die bei horizontalem Ein-
bau der Anzeigeeinheit stärker zum Tragen kommt als bei herkömmlicher vertikaler
Verwendung.
Als Alternative zur Verwendung von aktiven Anzeigeeinheiten können Projektoren ver-
wendet werden, die die darzustellende Information auf die Tischoberfläche projizieren.
Hier ist zwischen Lösungen zu unterscheiden, bei denen die Projektion von oben erfolgt
und jenen, bei denen von unten auf eine durchscheinende Tischoberfläche projiziert wird.
Bei ersteren muss der Projektor in ausreichender Höhe über der Tischoberfläche ange-
bracht werden, damit das projizierte Bild die notwendige Größe erreicht. Bei beschränk-
ter Höhe nach oben kann ein Projektor mit Weitwinkelobjektiv oder ein Umlenkspiegel
benutzt werden, der durch eine Vergrößerung des Abstands zwischen Projektor und
Oberfläche auf einer nicht vertikalen Achse die notwendige Bauhöhe reduziert.
Der größte Nachteil eine Projektion von oben ist die Abschattung der projizierten In-
formation bei Manipulationen der Tokens auf der Oberfläche. Dieses Problem tritt nicht
auf, wenn von unten auf eine durchscheinende Oberfläche projiziert wird. Bei diesem Lö-
sungsansatz kommt es zu keinerlei Abschattungen, die Information wird wie bei Einsatz
eines Bildschirms ständig angezeigt. Nachteilig wirkt sich hier der durch den Einsatz
einer durchscheinenden Oberfläche verursachte Leuchtkraftverlust aus. Bei dieser Form
der Projektion wird immer ein Teil des durch den Projektor ausgestrahlten Lichts von
der Oberfläche nach unten zurück reflektiert. Im Gegensatz zur Projektion von oben ist
dadurch der Kontrast der Darstellung wesentlich geringer. Für den Einsatz unter Tages-
lichtbedingungen ist also der erstgenannte Ansatz generell besser geeignet. Ein kritischer
Faktor ist bei der Projektion von unten der notwendige Abstand zwischen Projektor und
Tisch, da sich dieser direkt auf die Höhe des Tisches auswirkt. Um eine akzeptable Bau-
höhe zu erreichen – also den Tisch durch durchschnittliche große Personen bedienbar
zu halten (Höhe nicht mehr als etwa 100 cm) – ist hier der Einsatz eines Umlenkspie-
gels nahezu unabdingbar. Beiden Projektions-Ansätzen gleich ist, dass die abzudeckende
Oberfläche variabel durch den Abstand des Projektors gewählt werden kann. Grenzen
sind hier nach unten durch die Fokussierbarkeit des Projektors bei kleinen Abständen
und nach oben durch die Abnahme der Projektionshelligkeit bei großen Abständen ge-
geben. Bei großen Oberflächen ist zudem auf die verfügbare Auflösung des Projektors
zu achten, da die Größe eines Bildpunktes mit zunehmendem Abstand so ansteigt, dass
eine feinauflösende Projektion der Information auf der Oberfläche nicht mehr möglich
ist.
Aktive Anzeige auf Tokens
Alternativ zur Darstellung auf der Tischoberfläche können bei Tabletop-Interfaces auch
die Tokens selbst als Ausgabekanal dienen. Da hier das Eingabemedium gleich dem Aus-
241
8.2. Technologische Grundlage der Ausgabe
gabemedium ist, ist diese Form der Ausgabe hinsichtlich der Embodiment-Dimension in
die Ausprägung „full“ einzuordnen. Technologisch können je nach Art der darzustellen-
den Information Tokens mit Displays ausgestattet werden oder lediglich visuelle Sta-
tusanzeigen beinhalten, die Feedback über den aktuellen Zustand des Tokens geben. In
beiden Fällen müssen die Tokens generell mit Elektronik und Energieversorgung aus-
gestattet sein und die Möglichkeit haben, selbst oder über eine Verbindung mit der
Infrastruktur ihren Zustand festzustellen.
Um textuelle oder grafische Information auf Tokens darzustellen ist die Verwendung
von Displays notwendig. Bei der Verwendung von herkömmlichen LCD-Displays ist
durch die benötigte Hintergrundbeleuchtung sowie der zur Aufrechterhaltung der Anzei-
ge notwendigen Stromversorgung der Energieverbrauch verhältnismäßig hoch. Alternativ
können neuere Technologien wie OLED2- (Shinar, 2004) oder eInk-Displays (Comiskey
et al., 1998) verwendet werden. OLEDs bestehen aus organischen Materialien und be-
nötigen keine Hintergrundbeleuchtung, da das Material selbst Licht emmitiert. eInk
verwendet eine papierartige Oberfläche zur Anzeige, strahlt selbst kein Licht aus und
ist deshalb auf Umgebungshelligkeit zur Verwendung angewiesen. eInk bietet in hel-
len Umgebungen die besten Kontrastverhältnisse (vergleichbar mit bedrucktem Papier),
kann allerdings beim heutigen Stand der Entwickung keine Farben darstellen. Der größte
Vorteil von eInk liegt in der Eigenschaft, dass die Anzeige auch ohne Energieversorgung
aufrecht bleibt – Energie ist lediglich zur Änderung des Display-Inhalts notwendig.
Durch das Wegfallen der Hintergrundbeleuchtung sind OLED- und eInk-Displays we-
sentlich dünner als LCD-Module und können auch auf nicht ebenen Oberflächen ange-
bracht werden. Allen drei Ansätzen gleich ist, dass zur Ansteuerung des Anzeigemoduls
Elektronik notwendig ist, die die darzustellende Information auf die zur Verfügung ste-
hen Bildpunkte abbildet und das Display entsprechend ansteuert.
Neben der Verwendung eines Displays kann der Status eines Tokens auch mit Leucht-
anzeigen unter Verwendung von LED3-Einheiten visualisiert werden. Der Nachteil dieses
Ansatzes ist die schwierige Realisierbarkeit von komplexen Statusanzeigen - durch die auf
zwei Zustände (ein/aus) beschränkte Aussagekraft einer LED sind andere als bipolare
Visualisierungen schwer zu realisieren. Möglich ist die Verwendung von mehreren LEDs.
Sollen dadurch mehrere voneinander unabhängige Aussagen visualisiert werden, führt
diese Variante jedoch rasch zu schwer erfassbaren und kaum unterscheidbaren Visua-
lisierungen. Lediglich die Kopplung mehrere LEDs zur aussagekräftigen Visualisierung
von dynamischen Zuständen hat sich als intuitiv erfassbar und verständlich erwiesen
(Zuckerman et al., 2005). So können gekoppelte LEDs z.B. dazu verwendet werden,
Flussrichtungen von Ressourcenströmen anzuzeigen, indem eine LED-Reihe entweder
von links nach rechts oder von rechts nach links angesteuert wird. Auch beim Einsatz
von LEDs ist einer ständige Energieversorgung notwendig. Zur Reduktion des Energie-
2Organic Light Emitting Diode
3Light Emitting Diode (Leuchtdiode)
242
8.2. Technologische Grundlage der Ausgabe
verbrauchs können wiederum die oben genannten Alternativ-Technologien OLED und
eInk zum Einsatz kommen, wobei diese aktuell nicht in den Bauformen herkömmlicher
LEDs angeboten werden. eInk-Anzeigen eignen sich aufgrund ihrer langsamen Schalt-
dauer außerdem nicht für die Realisierung dynamischer Anzeigen.
Tokens mit Aktuatoren
Neben der Verwendung von Displays zur Realisierung eines „full embodied“ Ausgabeka-
nals können Tokens auch mit Aktuatoren ausgestattet werden, die es erlauben, das Token
bzw. dessen Verhalten selbst ohne direkte Benutzerinteraktion zu beeinflussen. Beispiele
für Aktuatoren sind unter anderem Vibrationsmodule oder mechanische Einheiten zur
Veränderung der äußeren Form des Tokens oder dessen Position (auf der Tischoberflä-
che). Der Einsatz von Aktuatoren ist ob der technologischen und anwendungsspezifischen
Vielfalt nicht generisch beschreibbar wie das bei reinen optischen Anzeigeeinheiten der
Fall war. Aktuatoren müssen auf den jeweiligen Anwendungsfall abgestimmt sein. Ihr
Einsatz ist im Allgemeinen eher disruptiv, unterbricht durch die vom Benutzer nicht
selbst ausgelöste Interaktion dessen aktuelle Aktivität und zieht die Aufmerksamkeit
auf sich. Dies kann im einzelnen Anwendungsfall erwünscht sein, kann aber zu uner-
wünschten Effekten bei der Verwendbarkeit des Systems führen.
Wie bei Anzeigemodulen müssen auch hier die Tokens mit Energie versorgt werden
und mit Elektronik ausgestattet sein, die für die Ansteuerung der Aktuatoren sorgt.
Im Bereich der Tabletop Interfaces ist die Verwendung von Aktuatoren eher selten
anzutreffen. Im Bereich der Ambient Interfaces kann der Einsatz von Aktuatoren aber
sinnvoll sein, wenn sich das Interface so in die Umgebung seines Einsatzbereichs inte-
grieren kann (Gross, 2003).
8.2.2. Ansätze zur entkoppelten Ausgabe
Ansätze zur entkoppelten Ausgabe werden von Fishkin (2004) in seiner Taxonomie in
der Embodiment-Dimension unter den Ausprägungen „environment“ oder „distant“ ein-
geordnet.
„Environmental Embodiment“ ist dann gegeben, wenn Eingabe- und Ausgabekanäle
räumlich nicht kohärent sind, aber Eingaben trotzdem offensichtlich Reaktionen in der
unmittelbaren Umgebung auslösen. Klassische von Fishkin genannte Ansätze sind hier
Audiokanäle aber auch die Veränderung von Umgebungslicht oder Temperatur. Auch
olfaktorische Interfaces sind in diese Kategorie einzuordnen. In den folgenden Abschnit-
ten werden jedoch ausschließlich audio-basierte Kanäle beschrieben, da diese im Bereich
der Tabletop Interfaces Relevanz besitzen (etwa in (Kaltenbrunner et al., 2006) und
(Pedersen und Hornb, 2009))
243
8.2. Technologische Grundlage der Ausgabe
Die Ausprägung „distant“ kennzeichnet Ansätze, in denen die Eingabekanäle räumlich
von den Ausgabekanälen vollkommen entkoppelt sind bzw. entkoppelt werden können.
Ein Kriterium zur Einordnung eines Ansatzes unter „distant“ ist, dass Benutzer zur
Beobachtung der Ausgabe nicht mehr die Eingabe im Blickfeld haben können (was bei
allen anderen Ausprägungen möglich ist). Klassische Vertreter dieses Ansatzes sind alle
Ansätze, die auf der Darstellung von Information auf herkömmlichen Bildschirmen oder
Projektionsflächen basieren.
Darstellung auf Monitoren
Bei der Darstellung von Information auf Bildschirmen kommen die auch in der her-
kömmlichen Desktop-basierten Mensch-Maschine-Interaktion gängigen Anzeigetechno-
logien zur Anwendung. Im Kontext von Tabletop Interfaces ist bei Monitoren auf die
Sichtbarkeit der Information für alle an der Interaktion beteiligten Personen zu achten
– diese ist nicht nur von der Entfernung zum Monitor abhängig, sondern bei den heute
gängigen LCD-Displays auch vom Blickwinkel. Gegebenenfalls müssen mehrere Monitore
verwendet werden, auf denen entweder simultan die gleiche Information dargestellt wird
oder – abhängig von der Anwendung – lediglich für die jeweils eingenommene Perspektive
relevante Information angezeigt wird. Mit Monitoren kann auch eine vollständig räum-
lich entkoppelte Darstellung realisiert werden, indem die darzustellende Information auf
entfernte Displays übertragen wird. So kann zum Beispiel die Interaktion auf einem
Tabletop Interface bzw. deren Auswirkungen auch räumlich entfernt verfolgt werden.
Generell muss bei entkoppelten Ausgabekanälen darauf geachtet werden, dass bei In-
teraktionen mit den tangiblen Eingabekanälen entsprechend eindeutig zuzuordnendes
Feedback über die Ausgabekanäle rückgespiegelt wird. Bei Tabletop Interfaces ist hier-
bei (wiederum abgängig von der Anwendung) eine schematische Darstellung der Tisch-
oberfläche mit einer Kenntlichmachung des Bereichs, in dem eine Interaktion erkannt
wurde, sinnvoll.
Projektion auf entfernte Oberflächen
Bei Ausgabe mittels Projektion auf entfernte Oberfläche (im Sinne von Oberflächen, die
nicht dem eigentlichen Interface zuzuordnen sind) sind Aspekte wie die Größe des Bil-
des oder die Blickwinkelabhängigkeit der Darstellung meist keine Herausforderung. Mit
einem Projektor können zumeist alle Benutzer ausreichend mit Information bedient wer-
den. Ansonsten gelten die obigen Ausführungen hinsichtlich eindeutig zuzuordnendem
Feedbacks analog.
Bei individueller Nutzung eines Tangible Interfaces ist in der Verwendung von Bild-
schirm oder Projektor noch ein unterschiedlich hoher Grad an Privatheit der Ausgabe-
kanäle festzustellen. Während Bildschirme eher dem mit dem System interagierenden
244
8.2. Technologische Grundlage der Ausgabe
Individuum als Ausgabekanal vorbehalten bleiben, sind projizierte Informationen quasi
öffentlich verfügbar. Abhängig vom Anwendungsszenario des Tangible Interfaces kann
dies erwünscht sein oder nicht.
Audio-basierte Ausgabekanäle
Audio-basierte Ansätze werden hier als Vertreter von Ausgabekanälen vorgestellt, die in
die Kategorie „environmental Embodiment“ eingeordnet werden. Audio-Interfaces ar-
beiten mit akustischer Ausgabe von Information, die im Allgemeinen in Zusammenhang
mit den Eingaben am Tangible Interface stehen.
Die ausgegebene Information kann abstrakt, codiert oder natürlichsprachlich sein. Un-
ter „abstrakter“ Information werden hier akustische Ausgaben verstanden, die nicht un-
mittelbar Bedeutung im sprachlichen Sinn tragen, sondern auf Meldodien oder anderen
Klangmustern basieren. Derartige Formen der Ausgabe kommen vor allem im künstle-
rischen Bereich zum Einsatz (z.B. (Kaltenbrunner et al., 2006), (Pedersen und Hornb,
2009)). „Codierte“ akustische Ausgabe deckt alle Bereiche ab, in denen Klänge verwen-
det werden, um Information zu transportieren, ohne dass diese selbst in diesen Klängen
abgebildet ist. Beispiele hierfür sind Signaltöne, die einen Fehler melden oder anderweitig
die Aufmerksamkeit der Benutzer auf sich ziehen sollen. Unter „natürlichsprachlicher“
akustischer Ausgabe werden hier schließlich alle Ansätze eingeordnet, die die Ausgabe
der Information direkt in Sprache umgesetzt vornehmen. Dies kann mittels gespeicher-
ten (Teil-)Ansagen oder mittels Sprachsynthese realisiert werden. Im Gegensatz zu den
anderen beiden Formen der akustischen Ausgabe ist die natürlichsprachliche Ausgabe
abhängig vom Sprachverständnis der Benutzer und deshalb in einer bestimmten Konfi-
guration nur für einen beschränkten Benutzerkreis nutzbar.
Akustische Ausgabe ist allen ihren Ausprägungen der Embodiment-Dimension „en-
vironment“ zuzuordnen. Sie kann im Allgemeinen (ohne den Einsatz von Ohrhörern)
von allen sich im Umfeld des Interfaces befindlichen Personen wahrgenommen werden.
Bei codierter Ausgabe muss darauf geachtet werden, dass die Interpretation der Signale
bekannt ist bzw. durch unterstützende (visuelle oder taktile) Maßnahmen erschließbar
wird.
8.2.3. Technologie-Entscheidung
Auf Basis der in Abschnitt 8.1 festgelegten auszugebenden Information und den im letz-
ten Abschnitt beschriebenen technologischen Alternativen zur Realisierung unterschied-
lich ausgeprägter Ausgabekanäle können nun grundsätzliche Technologieentscheidungen
getroffen werden.
Für die im Kontext der eigentlichen Modellierung auszugebenden Information (Benen-
nungen, . . . ) ist ein kohärenter Ansatz am besten geeignet, da die Information inhärenter
245
8.2. Technologische Grundlage der Ausgabe
Bestandteil des Modells ist und deshalb räumlich mit den physischen Elementteilen (den
Tokens) in eine einheitliche Modellsicht integriert werden sollte. Mit der bereits in Kapi-
tel 7 argumentierten Entscheidung für passive Tokens ist die Projektion der Information
auf die Tischoberfläche der einzig naheliegende Ansatz. Dabei wird im Sinne der kom-
pakteren Bauweise und der nicht vorhandenen Einschränkung bezüglich Verdeckungen
der Projektion durch modellierende Personen ein Lösungsansatz mit Projektion auf die
Unterseite bevorzugt. Die kompaktere Bauweise ergibt sich aus der Tatsache, dass der
Innenraum des Tisches ohnehin bereits für die Erfassung der Tokens durch die Kame-
ra genutzt wird und dass bei gleichzeitiger Nutzung für die Projektion ein Auf- bzw.
Überbau des Tisches zur Aufnahme des Projektors entfällt.
Die Ausgabe vergangener Modellzustände ist mit den gegebenen technologischen Rah-
menbedingungen hingegen nicht für kohärente Ausgabe geeignet. Passive Tokens können
ihre Position nicht selbstständig verändern, weshalb die auf der Tischoberfläche vor-
handenen Modellierungstokens immer an den Positionen liegen, an denen sie sich im
aktuelleń Modellzustand befinden. Eine kohärente Ausgabe von vergangenen Modellzu-
ständen auf der gleichen Oberfläche ist deswegen nicht möglich – es käme zu Überlage-
rungen der physischen und projizierten Modelldarstellungen. Aus diesem Grund wird ein
zweiter Ausgabekanal verwendet, der die Modellierungshistorie nicht kohärent darstellt.
Akustische Ansätze sind ob der Komplexität der Modelle und deren inhärent visuell-
diagrammatischen Darstellung im Vergleich zu visuellen Ansätzen nicht geeignet. Zu
diesem Zweck wird also ein Bildschirm- oder Projektions-basierter Ausgabekanal imple-
mentiert. Dies hat auch den Vorteil, dass ins Modell zu integrierende digitale Ressourcen
in ihrer „natürlichen“ Umgebung, dem Bildschirm eines Rechners manipuliert und aus-
gewählt werden können. Letztendlich lässt sich ein derartiger Ausgabekanal beliebig
replizieren und auch für entfernte Ausgabe des Modellzustandes nutzen.
Konkret werden für das vorgestellte System zwei Ausgabekanäle genutzt, die beide
auf der visuellen Darstellung von Information basieren und sich in ihrer Ausprägung der
„Embodiment“-Dimension nach Fishkin (2004) unterschieden. Der hauptsächliche Aus-
gabekanal ist die Tischoberfläche, auf ihr wird Information „nearby“ ausgegeben. Für
Funktionen, für die diese kohärente Ausgabeform nicht adäquat einsetzbar ist, existiert
ein zweiter, „distant“ Ausgabekanal in Form eines Bildschirms oder eines externen Pro-
jektors. Dieser Kanal kann in zwei Modi betrieben werden. Wird er nicht benötigt, kann
er entweder deaktiviert werden (und so den Fokus auf den primären Ausgabekanal, die
Tischoberfläche, lenken) oder synchron mit der Tischoberfläche den aktuellen Modellzu-
stand anzeigen. Zweiteres ist sinnvoll, wenn der Modellierungsprozess auch von Personen
verfolgt werden können soll, die sich nicht unmittelbar bei der Modellierungsoberfläche
befinden.
Hardwareseitig ergibt sich aus dieser Entscheidung der in Abbildung 8.2 dargestellte
Aufbau. Dabei kann der in der Standardkonfiguration vorhandene Bildschirm als Ausga-
246
8.2. Technologische Grundlage der Ausgabe
Abbildung 8.2.: Überblick über den Aufbau des Werkzeugs – Ausgabekomponenten
bekanal je nach den räumlichen Gegebenheiten und dem konkreten Anwendungsszenario
durch einen Projektor ersetzt werden.
8.2.4. Frameworks zur Ausgabe
Im Sinne der eben getroffenen Technologieentscheidung wird nun eine Softwarekompo-
nente benötigt, die die Ansteuerung der Ausgabekanäle erlaubt. Diese Softwarekompo-
nente muss im Wesentlichen die Modellinformation, die über die Eingabekanäle erhoben
wurde, visuell ausgeben. Zusätzlich muss sie den Funktionen zur Modellierungsunter-
stützungs einen Kanal zur Kommunikation mit den Benutzern bieten.
Für die graphische Darstellung diagrammatischer Modelle (also vernetzter Struktu-
ren) existieren verschiedene Frameworks, die – basierend auf unterschiedlichen techno-
logischen Ansätzen – die Darstellung von Modellelementen, der Verbindung und der
Manipulation des Modells durch bereits implementierte Funktionalität ermöglichen und
unterstützen.
In Frage kommende Frameworks
Die Anzahl der Möglichkeiten zur Darstellung graphischer Modelle durch Java ist groß.
Die unterschiedlichen Ansätze unterscheiden sich vor allem in der angebotenen Abs-
traktionsstufe, wobei die Pole durch eine direkte Manipulation der Pixelgrafik in der
das Modell dargestellt werden soll einerseits und eine rein logische, von der eigentlichen
247
8.2. Technologische Grundlage der Ausgabe
Darstellung vollständig entkoppelte Repräsentation des Modells andererseits gebildet
werden. Hier wurden nur Frameworks betrachtet, die eine Verwaltung des darzustel-
lenden Modells auf logischer Ebene ermöglichen und die eigentliche Ausgabe auf den
Bildschirm übernehmen und kapseln. Kandidaten für Frameworks, die diese Forderung
erfüllen4, waren zum Zeitpunkt der Technologie-Entscheidung:
• Eclipse GEF (Moore et al., 2004)
• JHotDraw (Gamma und Eggenschwiler, 1996)
• Piccolo (Bederson et al., 2004)
Piccolo stellte sich in der ersten Betrachtung als Framework zur Spezifikation von
Benutzungsschnittstellen heraus, das die Erstellung graphischer Modelleditoren zwar
erlaubt, in seinem Umfang aber weit über die benötigte Funktionalität und Flexibilität
hinausgeht. Dementsprechend umfangreich und komplex ist auch der Anpassungsprozess
des Frameworks an eine gegebene Anwendung. Piccolo wurde in der Betrachtung deshalb
im ersten Schritt zurückgestellt und wurde später, nachdem fokussiertere Frameworks
identifizierte werden konnten, aus der engeren Auswahl entfernt und nicht mehr näher
betrachtet. In der engeren Auswahl standen also noch Eclipse GEF und JHotDraw.
Diese beiden Frameworks werden in der Folge detaillierter betrachtet und hinsichtlich
ihrer Eignung für die zu erstellende Anwendung beurteilt.
Eclipse GEF Das Graphical Editing Framework (Moore et al., 2004) stellt als Teil der
Eclipse Plattform (Holzner, 2004) eine Möglichkeit dar, graphische Editoren zu erstellen
und diese in einer Eclipse Applikation eingebettet auszuführen. Das GEF5 bildet zu-
sammen mit EMF6 (Budinsky et al., 2003) auch die Grundlage für das GMF7 (Eclipse
Foundation, 2009), das die graphische Erstellung von domänen-spezifischen Sprachen
mit nachfolgender Generierung von entsprechenden Klassen ermöglicht. Diese Klassen
binden sich nahtlos in die Eclipse Infrastruktur ein und werden als Teil eines modell-
getriebenen Softwareentwicklungszylus zur Erstellung domänen-spezifischen Applikatio-
nen verwendet.
GEF behandelt lediglich die graphische Ausgabe und erlaubt die Darstellung vernetz-
ter Strukturen, die flexibel ausgestaltet werden können. GEF baut dabei konsequent auf
dem MVC-Konzept (Krasner und Pope, 1988) auf und trennt strikt zwischen Reprä-
sentation der Daten und deren Darstellung. In dieser Eigenschaft liegt auch der größte
Vorteil dieses Ansatzes. Durch die Entkopplung der Visualisierung ist eine flexible Be-
handlung der Ausgabe möglich. Diese kann entsprechend der Notwendigkeiten des jewei-
ligen Ausgabekanals angepasst werden und erlaubt auch eine dynamische Veränderung
bzw. Erweiterung der Darstellung zur Laufzeit.
4identifiziert im Rahmen von (Feiner, 2008) und (Seiringer, 2008)
5Graphical Editing Framework (Eclipse-Komponente)
6Eclipse Modeling Framework
7Graphical Modeling Framework (Eclipse-Komponente)
248
8.2. Technologische Grundlage der Ausgabe
Der größte Nachteil des GEF-Ansatzes liegt für die hier vorgestellte Anwendung in
der engen Verwobenheit mit der Eclipse-Plattform bzw. den starken Abhängigkeiten zu
anderen Komponenten wie dem EMF. Durch diese Abhängigkeiten ist zum ersten der
konzeptuelle und technische Einarbeitungsaufwand höher als in funktional fokussierte-
ren Frameworks. Zum zweiten bringen GEF-basierte Applikationen eine Vielzahl von
Features mit sich, die im konkreten Anwendungsfall nicht benötigt werden. Auf Seiten
der Benutzungsschnittstelle kann die damit einhergehende größere Komplexität zwar
vermieden werden, indem die überflüssigen Elemente ausgeblendet werden, implemen-
tierungsseitig bleibt die Komplexität und die damit einhergehende größere Anzahl von
potentiellen Fehlerquellen aber bestehen.
JHotDraw Das JHotDraw-Framework (Gamma und Eggenschwiler, 1996) ist eine Java-
Implementierung des Smalltalk-Frameworks HotDraw (Brant, 1995). Dieses wurde ent-
wickelt, um einerseits eine einfache Möglichkeit zur Erstellung graphischer Editoren be-
liebiger Natur zu bieten und andererseits die Stärken und Möglichkeiten objektorientier-
ter Softwareentwicklung unter Einsatz der von (REF Entwurfsmuster) vorgeschlagenen
Entwurfsmuster zu zeigen.
JHotDraw nutzt intensiv objektorientierte Konzepte, vor allem die dynamische Ty-
pisierung von Objekten und implementiert einen Großteil seiner Features als Instanzen
der eben erwähnten Entwurfsmuster. Dies erleichtert die Adaptierung und Erweiterung
des Systems für eigenen Anwendungsfälle und ermöglicht eine rasche, unaufwändige Im-
plementierung anwendungsspezifischer graphischer Editoren.
Ein Vorteil von JHotDraw liegt in der überschaubaren Struktur und im insgesamt
für graphische Editoren-Frameworks eher kompakten Aufbau. Dies ist sowohl auf die
resultierenden Applikationen bezogen, die wenig Ressourcen benötigen und ohne merk-
liche Verzögerung starten, als auch auf Framework-Klassen-Struktur zur Erstellung die-
ser Applikationen, die eine rasche Entwicklung ohne hohen Einarbeitungsaufwand oder
weitgehende Parametrisierungen ermöglicht.
Ein weiterer Vorteil von JHotDraw ist die Eigenständigkeit seiner Klassenbibliothek,
die von keinen anderen Bibliotheken abhängt. Die einzige zu erfüllende Abhängigkeit
besteht zum Fenster-Management-System Java SWING, das ohnehin Teil des JRE8 ist.
JHotDraw-basierte Applikationen können so ohne weiteren Installations-Aufwand auf
allen Rechneren ausgeführt werden, auf denen ein JRE vorhanden ist. Zusätzlich ist
SWING auch Teil jener Bibliotheken, die von Java Applets zur Ausführung in Browsern
verwendet werden können. Jede JHotDraw-Applikation kann damit ohne Modifikation
lediglich durch Austausch der Basisklasse über eine HTTP9-Verbindung geladen und im
Browser ausgeführt werden.
8Java Runtime Environment
9Hypertext Transfer Protocol
249
8.3. Ausgabe von Information
Framework-Entscheidung
Für das konkret zu implementierende System sind grundsätzlich beide Frameworks ge-
eignet. JHotDraw weist in der Standarddistribution einen geringeren, dafür aber auf die
eigentliche Visualisierungsaufgabe fokussierteren Funktionsumfang auf, was sich positiv
auf den für die Verwendung notwendigen Lernaufwand auswirkt. Für die Entwicklung
des prototypischen Systems wurde neben diesem Grund aufgrund der leichtgewichtigeren
Bibliothek und geringeren Abhängigkeiten von externen Bibliotheken sowie des größe-
ren Umfangs von in der Standarddistribution mitgelieferten benötigten Funktionalitäten
JHotDraw ausgewählt.
In einer im Kontext der hier vorgestellten Arbeit angefertigten Diplomarbeit (Feiner,
2008) wurde ein auf GEF basierendes System entwickelt, das an die existierenden Einga-
bekanäle angebunden werden kann und prototypisch zeigt, wie GEF für die Darstellung
flexibler Modelle (im Sinne von dynamisch zugewiesener Semantik und Visualisierung)
eingesetzt werden kann. Ein zusätzlicher Aspekt dieser Arbeit ist die Möglichkeit zum
synchronen verteilten Betrieb mehrerer Instanzen der Applikation, die simultan am glei-
chen Modell arbeiten. Die Arbeit schafft damit die Voraussetzungen, synchron an mehre-
ren (physischen oder graphischen) Schnittstellen ein Modell kooperativ zu manipulieren.
Sie ist außerdem aufgrund der gemeinsamen Basis-Infrastruktur in Instanzen der Eclipse
Rich Client Platform (McAffer und Lemieux, 2005) integrierbar und kann so nahtlos in
komplexere, auf dieser Plattform basierende Systeme integriert werden.
8.3. Ausgabe von Information
In diesem Abschnitt wird nun auf Basis der eben getroffenen Framework-Entscheidung
und unter Berücksichtigung der grundsätzlichen Entscheidung für zwei Ausgabekanäle,
die in Abschnitt 8.2 getroffen wurde, die konkrete Informationsausgabe für das hier
vorgestellte Werkzeug beschrieben.
Wie bereits in Kapitel 7 auf abstrakter Ebene beginnend, wird zuerst das Konzept be-
schrieben, das bei der Umsetzung der Ausgabe verfolgt wird. Aufbauend darauf wird die
Architektur der Software beschrieben, die auf den in Kapitel 7 beschriebenen Komponen-
ten aufsetzt und für die Ansteuerung der Ausgabekanäle sorgt. Nach einer detaillierten
Beschreibung der konkreten Ausgabeform für alle ausgebenden Informationstypen wird
schließlich die Implementierung des hier verfolgten Ansatzes in Software vorgestellt.
8.3.1. Konzept
Wie bereits oben beschrieben wird die auszugebende Information im konkreten Werk-
zeug auf zwei Ausgabekanäle verteilt. Grundsätzlich wird Information auf einem mit den
250
8.3. Ausgabe von Information
Eingabekanälen räumlich kohärenten Kanal (der Tischoberfläche) ausgegeben. Ist dies
aufgrund der Art der auszugebenden Information nicht adäquat möglich, wird der zwei-
te Ausgabekanal als primäres Kommunikationsmedium verwendet. In der übrigen Zeit
spielt der zweite Ausgabekanal eine untergeordnete Rolle und kann zur unterstützenden
simultanen Visualisierung der am primären Kanal ohnehin ausgegebenen Information
dienen.
Während eines Modellierungsvorgangs bleibt der Fokus der Ausgabe grundsätzlich am
primären Ausgabekanal, der Tischoberfläche. Auf dieser wird Information kohärent mit
den vorhandenen Tokens ausgegeben. In lediglich zwei Fällen erhält der zweite Ausga-
bekanal den Fokus:
• Wenn Information ausgegeben werden muss, die nicht kohärent mit den auf der
Oberfläche vorhanden physischen Tokens dargestellt werden kann (z.B. bei der
Ausgabe von gespeicherten Modellzuständen).
• Wenn Interaktion mit den Benutzern einen Fokus auf die digitale Welt, also auf
über den Rechner zugreifbare Ressourcen hat (wie bei der Auswahl von Dateien
zur Einbettung in Container-Tokens).
In beiden Fällen wird das Modell auf der Oberfläche nicht simultan verändert, den
Benutzern ist es möglich, sich auf die Interaktion mit dem sekundären Ausgabekanal zu
konzentrieren.
Während der Arbeit mit dem Werkzeug, bei der der zweite Ausgabekanal grundsätz-
lich nicht benötigt wird, kann mit diesen auf unterschiedliche Arten umgegangen werden.
Zum einen kann der zweite Ausgabekanal abgeschaltet werden, also keine Ausgabe über
den Bildschirm oder externen Projektor mehr erfolgen. Vorteil dieser Lösung ist, das
ein Fokuswechsel auf den sekundären Ausgabekanal eindeutig erkennbar ist, da dazu
die Darstellung explizit aktiviert wird. Während der eigentlichen Modellierung werden
Benutzer nicht abgelenkt und können auf die Interaktion auf der Tischoberfläche fokus-
sieren.
Zum anderen ist es möglich, am sekundären Ausgabekanal die Ausgabe des primä-
ren Kanals zu spiegeln, auf diesem also synchron die gleiche Information auszugeben
wie auf der Tischoberfläche. Ein Vorteil dieser Lösung ist, dass in dieser Darstellung
zusätzlich Information eingeblendet werden kann, die auf der Tischoberfläche in der
Überdeckung zwischen physischen Elementen und projizierter Information nicht darge-
stellt werden kann. So ist unter anderem denkbar, die Abstaktionsstufe, auf der aktuell
modelliert wird, am sekundären Ausgabekanal zu visualisieren. Diese Information ist
aus dem Modell auf der Tischoberfläche nicht erkennbar (weder eingebettete Teilmodel-
le noch übergeordnete Modelle sind auf im Modell ohne weitere Interaktion sichtbar).
Für den Modellierungsvorgang ist diese Information aber auch zumeist nicht unmittel-
bar relevant. Ist sie nun auf der sekundären Oberfläche permanent sichtbar, besteht
für Benutzer die Möglichkeit, rasch und ohne zusätzlichen Interaktionsaufwand einen
Überblick über den Kontext des aktuell bearbeiteten (Teil-)Modells zu erhalten.
251
8.3. Ausgabe von Information
Ein zweiter Aspekt der Spiegelung der Ausgabe auf dem sekundären Ausgabekanal ist
das unmittelbare Feedback, das Benutzern über die Tätigkeit des Systems zur Verfü-
gung gestellt wird. Wenn ein Modellierungstoken bewegt oder geöffnet wird, erfolgt eine
unmittelbare Reaktion in der Modellvisualisierung auf dem sekundären Ausgabekanal.
Auch eventuelle Fehlerkennungen werden offensichtlich, wenn z.B. ein Element von der
sekundären Visualisierung verschwindet, obwohl es auf der Oberfläche noch vorhanden
ist. Für die Benutzer ist damit das Systemverhalten klarer erkennbar, die Bildung eines
mentalen Modells zur Erklärung der Funktionsweise des Werkzeugs ist einfacher und
lenkt nach der Einarbeitungsphase nicht mehr von der eigentlichen Tätigkeit ab (Nor-
man, 1983). Letztendlich besteht bei der Einbindung mehrerer Benutzer die Möglichkeit,
allen Beteiligten einen Überblick über den aktuellen Modellzustand zur Verfügung zu
stellen, auch wenn diese im Moment nicht aktiv am Werkzeug arbeiten. Nachteile dieses
Ansatzes liegen einerseits in der möglichen Ablenkung der Benutzer von der eigentlichen
Modellierungsoberfläche (was insofern weitgehend unkritisch ist, als dass die gesamte
Information über den sekundären Informationskanal zur Verfügung gestellt wird), vor
allem aber darin, das der Wechsel des Interaktionsfokus von einem Ausgabekanal zum
anderen nicht mehr so explizit sichtbar wird wie im ersten Ansatz. Benutzer sind so
unter Umständen desorientiert und können dem Systemverhalten nicht folgen.
Aus den vorangegangenen Ausführungen ist ersichtlich, dass beide Ansätze Vor- und
Nachteile bieten, die nicht eindeutig für eine der beiden Lösungen sprechen. Vielmehr
muss im einzelnen Anwendungsfall abgewogen werden, welche Lösung eher geeignet ist.
Einflussfaktoren sind dabei die Anzahl der an der Modellierung teilnehmenden Benutzer
(bessere Verfolgbarkeit des Modellierungsvorgangs bei synchroner Anzeige auf beiden
Kanälen), die Modellierungsaufgabe an sich (generelle Notwendigkeit der Nutzung des
sekundären Ausgabekanals) sowie das persönliche Modellierungsverhalten der Beteilig-
ten (eher am Bildschirm oder eher an der Tischoberfläche orientiert). Aus diesen Grün-
den werden beide Formen der Verwendung des sekundären Ausgabekanals unterstützt,
wobei die Benutzer durch eine Tastenkombination zwischen den beiden Modi umschalten
können – also ggf. auch in unterschiedlichen Phasen eines Modellierungsvorgangs eine
unterschiedliche Konfiguration der Ausgabekanäle nutzen können.
8.3.2. Architektur
Wie im letzten Abschnitt beschrieben, unterscheidet sich die Ausgabe von Information
auf den beiden Ausgabekanälen nur in einigen Fällen, im synchronen Ausgabemodus wird
weitgehend die gleiche Information zum Teil – den unterschiedlichen Ausgabemedien
geschuldet – in unterschiedlichen Ausgabeformen dargestellt.
Grundsätzlich wird die Architektur der Ausgabekanal-Verwaltung erweiterbar angelegt
um veränderte Anforderungen an das Werkzeug oder erweiterte Funktionalität umset-
zen zu können. Basis dieser erweiterbaren Architektur ist das in Abschnitt 7.4.8 bereits
252
8.3. Ausgabe von Information
beschriebene Modul zur Verteilung des aktuellen Modellzustandes an die verwendeten
Ausgabekanäle. Jeder Ausgabekanal, der über Änderungen am Modell an den Eingabe-
kanälen benachrichtigt werden soll, muss ein definiertes Interface implementieren, das
jene Methoden definiert, die zur Datenübermittlung zwischen dem Interpretationsmodul
und den Ausgabekanälen notwendig sind. In der konkreten Implementierung sind zur
Zeit zwei auf JHotDraw basierende Ausgabekanäle umgesetzt, zusätzlich existiert ein
weiteres Modul, das gegenüber dem System als Ausgabekanal agiert, die übermittelte
Information selbst jedoch wieder an beliebige via TCP10/IP11 angebundene Clients ver-
teilt (siehe Abbildung 8.3). Auf diesem Weg können entfernte Ausgabekanäle realisiert
werden, die es erlauben den Modellierungsprozess auch ohne räumliche Anwesenheit
zur verfolgen. Mittels der gleichen Schnittstelle können auch weitere, nicht auf visuelle
Ausgabe beschränkte Kanäle wie z.B. akustische Benachrichtigungen mit Information
versorgt werden.
Durch die flexible Architekur von JHotDraw ist es möglich, unterschiedliche Ausga-
bekanäle mit der gleichen Codebasis durch den Einsatz verschiedener Basisklassen als
vollständig eigenständige Applikation auszuführen oder als Applet in Webbrowsern zu
starten (siehe Abbildung 8.11). Auf diese Weise ist es möglich die einmal implementier-
te Visualisierung des Modellzustandes für die lokalen Ausgabekanäle sowie für entfernte
Betrachter zu verwenden, die alle über die gleiche Schnittstelle synchron mit Information
versorgt werden.
8.3.3. Ausgabe von Information zum Modell
Um im Folgenden auf die Details der Implementierung eingehen zu können, muss an
dieser Stelle noch ausgeführt werden, welche Arten von Information in welcher Form
über welchen Kanal ausgegeben werden. Grundsätzlich sind konzeptuell zwei Arten von
Information zu unterscheiden. Dieser Abschnitt behandelt die Ausgabe von Information
zum Modell selbst, im folgenden Abschnitt werden jene Informationen Ausgabekanälen
zugeordnet, die der Kontrolle des Systems und der Unterstützung des Modellierungsvor-
gangs dienen.
Information zu Modellelementen
Information, die im Zusammenhang mit einzelnen Modellelementen ausgegeben wird,
wird unmittelbar auf der Modellierungsoberfläche, also am primären Ausgabekanal, dar-
gestellt. Wenn der sekundäre Ausgabekanal für synchrone Modelldarstellung konfiguriert
ist oder entfernte Modellbetrachter eingesetzt werden, so wird diese Information auch
10Transport Control Protocol
11Internet Protocol
253
8.3. Ausgabe von Information
Abbildung 8.3.: Softwarearchitektur zur Verwaltung der Ausgabekanäle
254
8.3. Ausgabe von Information
dort dargestellt. Die Ausgabe auf entfernten Ausgabekanälen ist dabei immer identisch
mit jener am sekundären Ausgabekanal. Dabei wird das Modellelement selbst graphisch
repräsentiert, um eine Zuordnung der Information zu ermöglichen. Auf der Tischoberflä-
che ist eine separate Darstellung des Modellelements nicht notwendig, das dieses durch
die kohärente Eingabe ohnedies durch das entsprechende Modellierungstoken dargestellt
wird (siehe Abbildung 8.4)
Abbildung 8.4.: Darstellung von Modellelementen
(links: Tischoberfläche, rechts: Bildschirm)
In der aktuellen Implementierung wird lediglich die Bezeichnung des Tokens auf beiden
Ausgabekanälen explizit ausgegeben. Der Typ des Tokens ist in der Farb- und Form-
gebung codiert. Auf dem sekundären Ausgabekanal sind die Elemente in der graphi-
schen Darstellung den physischen Elementen nachempfunden und bilden deren Farbe
und Grundriss ab. Zusätzlich wird ein Element, das als Container fungiert, am sekun-
dären Ausgabekanal durch eine Markierung gekennzeichnet.
Ebenfalls nur auf der sekundären Oberfläche explizit ausgegeben wird die Information
hinsichtlich der aktuellen Rotation eines Modellierungstokens. Auf der Oberfläche ist
diese am physischen Token erkennbar bzw. wird durch diese festgelegt. In der graphischen
Repräsentation am sekundären Ausgabekanal muss diese Rotation ebenfalls abgebildet
und nachgeführt werden.
Information zu Verbindern
Da Verbinder nicht physisch existieren, sondern immer über die Ausgabekanäle darge-
stellt werden müssen, gelten die nun folgenden Ausführungen für beide Ausgabekanäle.
Wird ein Verbinder hergestellt, so kann neben den beiden Endpunkten (Modellelemen-
ten) auch noch die Richtung des Verbinders sowie eine Bezeichnung festgelegt werden.
Ein Verbinder wird auf den Ausgabekanälen als Linie dargestellt, die zwei Modellie-
rungstokens bzw. deren graphische Repräsentation verbindet (siehe Abbildung 8.5). Die
Richtung des Verbinders wird über Pfeilspitzen angegeben, die an den Enden der Linien
angebracht werden (siehe Abbildung 8.6). Dabei können diese Pfeilspitzen fehlen (unge-
255
8.3. Ausgabe von Information
Abbildung 8.5.: Darstellung von Verbindern (oben Tischoberfläche, unten Bildschirm)
256
8.3. Ausgabe von Information
richteter Verbinder), an einem Ende angebracht werden (gerichteter Verbinder) oder an
beiden Enden dargestellt werden (bidirektionaler Verbinder). Die Ausgabe der Benen-
nung eines Verbinders erfolgt – sofern vorhanden – zentriert auf halbem Weg zwischen
den verbundenen Modellelementen unterhalb der Linie.
Abbildung 8.6.: Darstellung gerichteter Verbinder
Information zu eingebetteten Elementen
Im Kontext der Ausgabe von Information zu eingebetteten Elementen müssen unter-
schiedliche Modellaspekte berücksichtigt werden. Im einzelnen sind dies:
• Öffnungszustand von Modellelementen
• Anzahl und Art der eingebetteten Elemente
• Information, welche an eingebettete Elemente gebunden ist
Der Öffnungszustand von Modellelementen ist auf der Tischoberfläche durch den Zu-
stand des jeweiligen Containertokens ersichtlich. Auch die Art und Anzahl der einge-
betteten Elemente ist sichtbar, wenn ein Containertoken geöffnet ist. Am sekundären
Ausgabekanal, also auf dem Bildschirm wird ein geöffnetes Modellelement vergrößert
dargestellt um innerhalb der Fläche des Elements visuelle Repräsentationen der einge-
betteten Elemente einblenden zu können. Somit ist auch am sekundären Ausgabekanal
erkennbar, wann bzw. dass ein Element geöffnet ist (siehe Abbildung 8.7).
Jene Information, die an die eingebetteten Elemente gebunden ist, wird auf beiden
Kanälen nicht ohne explizite Benutzerinteraktion dargestellt. Fordern die Benutzer auf
einem Eingabekanal die Darstellung der eingebetteten Information an, so wird diese
auf dem sekundären, nicht kohärenten Ausgabekanal dargestellt. Eine Darstellung der
angebundenen Information auf der Tischoberfläche kann durch die physisch vorhanden
257
8.3. Ausgabe von Information
Abbildung 8.7.: Darstellung von Containern und eingebetteten Elementen
(links Tischoberfläche, rechts Bildschirm)
Modellelemente gestört werden. Die eingebetteten Submodelle bzw. die sonstigen digi-
talen Ressourcen werden also auf dem Bildschirm dargestellt. Die Submodelle ersetzen
dabei den aktuellen Modellzustand temporär, andere Ressourcen werden mittels der im
Betriebssystem definierten Standardapplikation geöffnet.
8.3.4. Ausgabe zur Kontrolle des Systems
Neben der eigentlichen Modellinformation wird auch Information ausgegeben, die zum
Feedback über den Systemzustand oder der Kontrolle desselben notwendig ist. Wo mög-
lich wird auch in diesem Fall die Tischoberfläche als primärer Ausgabekanal genutzt.
Zustands- und Ereignismeldungen
Bei der Verwendung der die Modellierung unterstützenden Werkzeuge muss den Be-
nutzern Feedback über deren Erkennung bzw. den durch diese ausgelösten Änderung
des Systemzustandes gegeben werden. Dabei ist zwischen jenen Interaktionen zu unter-
scheiden, die ein Ereignis auslösen und jenen, die den Systemzustand permanent ändern.
Dieser Unterschied muss auch in der Visualisierung den Benutzern kommuniziert werden.
Dabei kann es duch die vom System nicht beeinflussbaren physischen Werkzeugtokens
zu potentiellen Missverständnissen kommen. Wird ein Werkzeugtoken, das lediglich ein
Ereignis auslöst (wie zum Beispiel das Markierungstoken), von den Modellierenden auf
der Oberfläche belassen, kann dieses unter Umständen als zustandsverändernd und nicht
als ereignisauslösend wahrgenommen werden.
Elementauswahl Wird mittels demMarkierungstoken ein Element ausgewählt, so müs-
sen die Benutzer über die Erkennung der Markierung benachrichtigt werden. Dabei muss
258
8.3. Ausgabe von Information
erkenntlich sein, welches Element ausgewählt wurde und wie lange die Auswahl gültig
ist. Die Auswahl eines Elements ist grundsätzlich ein Ereignis, ist jedoch immer Teil ei-
ner umfassenderen Interaktion, in der die Benutzer das ausgewählte Element verwenden
(z.B. dieses benennen).
Abbildung 8.8.: Markierung von Modellelementen
Die Anzeige der Auswahl erfolgt auf beiden Ausgabekanälen mittels einer ovalen Mar-
kierung, die das ausgewählte Element umschließt (siehe Abbildung 8.8). Diese wird so-
lange angezeigt, bis die Interaktion, der sie zuzuordnen ist, abgeschlossen ist oder ein
anderes Element ausgewählt wird. Außerdem ist es möglich, eine Markierung durch ex-
plizite Interaktion (erneute Auswahl mit dem Markierungstoken) wieder zu entfernen.
Verbindungsherstellung Die Herstellung von Verbindungen kann auf zwei unterschied-
liche Arten durch die Benutzer ausgelöst werden. Wird eine Verbindung duch die Aus-
wahl zweier Modellelemente hergestellt, werden die eben beschriebenen ovalen Markie-
rungen zur Visualisierung der Auswahl verwendet. Dabei kann es zur Auswahl eines
Elements als Endpunkt einer gerichteten Verbindung kommen. Die ovale Markierung
wechselt in diesem Fall die Farbe um die erfolgreiche Erkennung einer Pfeilspitze rück-
zumelden. Nachdem beide Endpunkte erkannt und markiert wurden, wird unmittelbar
die Verbindung hergestellt. Diese wird initial als eine Linie dargestellt, die in Farbe und
Strichstärke hervorsticht und in der Folge in einer Animation durch eine herkömmliche
Verbindung ersetzt. Diese Animation dient dazu, das Ereignis der Verbindungsherstel-
lung klar zu visualisieren und die Aufmerksamkeit der Benutzer auf dieses Ereignis zu
lenken.
Werden zwei Elemente durch ihre räumliche Nähe zueinander in Beziehung gesetzt und
eine Verbindung hergestellt, entfallen die ovalen Markierungen (da keine explizite Aus-
wahl der Elemente erfolgt). Es wird lediglich die Animation zur Verbindungsherstellung
dargestellt. Auf diesem Wege ist keine direkte Herstellung von gerichteten Verbindern
möglich.
259
8.3. Ausgabe von Information
explizite Snapshots Im Zusammenhang mit der Speicherung der Modellierungshistorie
(also der über die Zeit veränderten Modellzustände) ist es möglich neben der automa-
tischen Speicherung auch explizit der Aufnahme eines Snapshots auszulösen. Während
bei der automatischen Speicherung kein Feedback an die Benutzer gegeben wird (da
auch keine Interaktion zum Auslösen derselben stattfindet), wird im Falle einer explizi-
ten Speicherung den Benutzern die erfolgreiche Durchführung der Aktion rückgemeldet.
Die Speicherung des Snapshots ist ein Ereignis ohne zeitliche Ausdehnung und wird
dementsprechend visualisiert. Dies erfolgt in Form eines kurzen Aufblitzens sowohl der
Tischoberfläche als auch des Bildschirms. Die Verwendung der gespeicherten Modellzu-
stände und deren Visualisierung wird in Abschnitt 8.3.4 im Detail behandelt.
Löschmodus Im Gegensatz zu den in den vorangegangenen Abschnitten behandelten
Werkzeugen löst der Einsatz des Lösch-Tokens kein Ereignis aus, sondern schaltet das
System in einen anderen Zustand, solange es auf der Oberfläche vorhanden ist. Dies
spiegelt sich auch in der Visualisierung wieder. Solange das Lösch-Token von der Kame-
ra erfasst wird, wird auf beiden Ausgabekanälen der Hintergrund des Modells (also die
gesamte Tischoberfläche bzw. der gesamte Bildschirm) in roter Farbe dargestellt, wäh-
rend im Vordergrund nach wie vor der aktuelle Modellzustand visualisiert wird. Dies
entspricht den Interaktionsmöglichkeiten der Benutzer – das Modell kann nach wie vor
manipuliert werden, jene Interaktionen, die aber im Normalfall eine Verbindung her-
stellen, löschen diese in diesem Modus wieder. Wird das Lösch-Token entfernt, wechselt
der Hintergrund wieder auf die Standard-Farbe, das System reagiert auf dei betroffenen
Interaktionen wieder mit der Herstellung eines Verbinders.
Abruf der Modellierungshistorie
Der Abruf der Modellierungshistorie wird mit dem runden Kontroll-Token ausgelöst und
kontrolliert. Hinsichtlich der Darstellung ist die Modellierungshistorie die erste der hier
beschriebenen Zustands- und Ereignismeldungen, bei der keine kohärente Darstellung
möglich ist. Auf der Tischoberfläche befinden sich zum Zeitpunkt der Aktivierung des
Historienmodus alle Tokens, die im Elemente im aktuellen Modellzustand repräsentieren.
Da der Historienmodus als Referenz dient, in der die Entstehung des Models rekapituliert
werden kann, die gespeicherten Modellzustände aber im Allgemeinen nicht den aktuellen
Zustand ersetzen sollen, verbleiben diese Tokens auch auf der Oberfläche. Damit kann
nach Deaktivierung des Historienmodus der Modellierungsvorgang unmittelbar fortge-
setzt werden. Die auf der Oberfläche befindlichen Tokens stören aber die Darstellung
gespeicherter Modellzustände, da sie Teile verdecken und keinen Bezug zum projizierten
historischen Modell haben.
Die Information des Historienmodus wird deshalb ausschließlich auf dem sekundären
Ausgabekanal – dem Bildschirm – dargestellt (die Kontrolle verbleibt mit dem runden
Kontroll-Token auf der Tischoberfläche). Die gespeicherten Modellzustände ersetzen da-
260
8.3. Ausgabe von Information
bei den aktuellen Modellzustand, der im Normalbetrieb synchron zur Tischoberfläche
dargestellt wird. Ist das System so konfiguriert, dass der sekundäre Ausgabekanal nicht
synchron betrieben wird, so wird er bei Erkennung des Historienmodus aktiviert.
Abbildung 8.9.: Darstellung der Modellierungshistorie
Zusätzlich zur graphischen Darstellung des gespeicherten Modellzustandes wird ein
Zeitstempel in der linken oberen Ecke eingeblendet, der den Zeitpunkt der Speicherung
angibt. Am unteren Rand des Bildes wird ein Balken eingeblendet, der auf den relati-
ven Zeitpunkt der Aufnahme (bezogen auf die Gesamtzahl der gespeicherten Zustände)
angibt (siehe Abbildung 8.9). Die Schrittweite (also die Verlängerung des Balken, die
durch das Umschalten auf einen unmittelbar folgenden Zustand verursacht wird) wird
dazu dynamisch an die Anzahl der gespeicherten Modellzustände angepasst.
Ist der erste bzw. letzte Modellzustand erreicht, werden weitere entsprechende Kom-
mandos durch Drehen des Kontroll-Tokens ignoriert. Die Benutzer werden durch einen
vollständig leeren bzw. ausgefüllten Balken auf das Erreichen des jeweiligen Endpunktes
hingewiesen. Wird das Kontroll-Token von der Tischoberfläche entfernt, so wird der His-
torienmodus deaktiviert. Die Darstellung auf dem sekundären Ausgabekanal wird wieder
auf die synchrone Darstellung des aktuellen Modellzustandes geschaltet bzw. wird diese
deaktiviert, falls das System dementsprechend konfiguriert ist.
Wiederherstellungsunterstützung
Im Rahmen des Abrufs der Modellierungshistorie kann von den Benutzern die Wie-
derherstellungsunterstützung aktiviert werden. Im Rahmen der Wiederherstellungsun-
terstützung leitet das System die Benutzer bei der Rekonstruktion eines gespeicherten
Modellzustandes an. Dazu werden auf der Tischoberfläche und am Bildschirm (sofern
aktiviert) – also auf beiden Ausgabekanälen – Hinweise angezeigt, wie der aktuelle Mo-
dellzustand verändert werden muss, um den gespeicherten Zustand wieder herzustellen.
261
8.3. Ausgabe von Information
Da der aktuelle Modellzustand als Ausgangspunkt dient, kann eine kohärente Visuali-
sierung zum Einsatz kommen.
Bei der Aktivierung der Wiederherstellungsunterstützung werden die im Modell be-
findlichen Verbinder ausgeblendet, da diese nicht manuell verändert werden müssen. Die
notwendige manuelle Intervention der Benutzer zur Wiederherstellung beschränkt sich
auf die Platzierung der Modellierungstokens an die dem gespeicherten Modellzustand
entsprechenden Orte. In der ersten Phase werden vom System schrittweise alle Tokens
markiert, die im aktuellen Modell enthalten sind und im gespeicherten Modellzustand
nicht vorhanden sind, also entfernt werden müssen. Schrittweise heißt in diesem Zu-
sammenhang, dass immer nur ein Token markiert wird, sobald dieses entfernt wurde,
wird das nächste Token zur Entfernung markiert. Die Markierung ist als rote, ovale
Hinterlegung des Tokens umgesetzt.
In der zweiten Phase werden jene Tokens behandelt, die sowohl im aktuellen als auch
im gespeicherten Modellzustand enthalten sind, sich aber jeweils an unterschiedlichen
Positionen befinden, also verschoben werden müssen. Dazu wird wiederum schrittweise
eine Markierung an der Zielposition des Tokens eingeblendet und diese mit einem Pfeil
mit der aktuellen Position des betroffenen Tokens verbunden (siehe Abbildung 8.10).
In der letzten Phase werden alle Tokens hinzugefügt, die im aktuellen Modell nicht
vorhanden sind, es im gespeicherten Modellzustand aber waren. Diese werden schritt-
weise durch grüne, ovale Markierungen an den jeweiligen Positionen angezeigt, wobei
die Benennung des Tokens in die Markierung eingeblendet wird, um das jeweilige zu
platzierende Element identifizieren zu können.
Abbildung 8.10.: Unterstützung der Wiederherstellung von Modellzuständen
Die zur Rekonstruktions des Modellzustandes notwendigen Schritte sind nicht vor-
berechnet sondern werden vielmehr Schritt für Schritt aus der aktuell auf der Tisch-
oberfläche befindlichen Token-Konstellation extrahiert. Dadurch ist es möglich, auch
irrtümlicherweise während der Wiederherstellung entfernte, hinzugefügte oder vor allem
262
8.4. Umsetzung der Ausgabe mit Software
verschobene Tokens zu korrigieren, auch wenn die Rekonstruktion grundsätzlich schon
in eine spätere Phase getreten wäre. So greift das System beispielsweise nach Abschluss
eines Schrittes in der dritten Phase (Elemente hinzufügen) auf eine Anweisung in der
zweiten Phase (Verschieben) zurück, wenn durch das Hinzufügen ein anderes, bereits an
der korrekten Position befindliches Element verschoben worden wäre.
Sobald sich die Positionen der Tokens mit jenen des gespeicherten Modellzustandes de-
cken, ist die notwendige Benutzerintervention zur Wiederherstellung abgeschlossen. Die
Benutzer werden nun aufgefordert, das Historien-Kontroll-Token und dasWiederherstellungs-
Token zu entfernen (sofern sich diese noch auf der Oberfläche befinden). Dieser Schritt
schließt die Wiederherstellungsunterstützung ab. Das System blendet die Verbinder (nun
aus dem gespeicherten Modellzustand) wieder ein und zeigt damit den (neuen) aktuellen
Modellzustand an.
8.4. Umsetzung der Ausgabe mit Software
Wie in Abschnitt 8.3.1 bereits beschrieben, basiert die Implementierung der Ausgabe-
kanäle auf dem JHotDraw-Framework. Die Implementierung erfolgt dabei in Modulen,
die die Art und Anzahl der Ausgabekanäle flexibel erweiterbar macht. Die Anforderun-
gen an die Ausgabekanäle unterscheiden sich zwar durchaus im Detail, im Allgemeinen
ähneln sie sich aber stark. Dies legt die Verwendung einer gemeinsamen Basisklasse na-
he, die alle verallgemeinerbaren Aufgaben der Ausgabekanäle umfasst. Von ihr werden
die konkreten Implementierungen der Ausgabekanäle mit ihren spezifischen Funktionen
abgeleitet werden. So müssen auf dem bildschirmbasierten Ausgabekanal unter anderem
die Modellelemente graphisch dargestellt werden, wohingegen diese auf der Tischoberflä-
che in Form der physischen Modellierungstokens bereits vorhanden sind. Beiden Kanälen
gemein ist hingegen zum Beispiel die Behandlung der Verbinder, die hier wie dort darge-
stellt bzw. projiziert werden müssen. Durch das nur partiell unterschiedliche Verhalten
der beiden Ausgabekanäle ist es möglich, diese von einer gemeinsamen Basisklasse ab-
zuleiten und die Spezifika in Subklassen zu implementieren. Dies reduziert auch den
Wartungsaufwand der Codebasis und vermindert die Gefahr von Inkonsistenzen.
Konkret wurde die Architektur wie in 8.11 dargestellt auf Klassen abgebildet. Zentrale
Schnittstelle zu den informationsliefernden Modulen ist das Interface DispatcherListener,
das eine Reihe von Methoden definiert, die Ausgabekanäle implementieren müssen, falls
sie an die Informationeingabe- und -interpretations-Infrastruktur angebunden werden
sollen. Das Interface ist allgemein einsetzbar, kann also auch durch Ausgabekanäle an-
derer technologischer Ansätze implementiert werden. Als zentrales Element implemen-
tiert die Klasse zur Ausgabe von Information auf dem sekundären Ausgabekanal (dem
Bildschirm) dieses Interface. Diese Klasse wurde deswegen als zentraler Knotenpunkt
gewählt, weil sie im Vergleich mit den anderen Ausgabekanälen den größten Anteil an
263
8.4. Umsetzung der Ausgabe mit Software
Abbildung 8.11.: Zusammenhänge der Klassen zur Ausgabebehandlung
264
8.4. Umsetzung der Ausgabe mit Software
auszugegebender Information besitzt. Die Klasse zur Ausgabe von Information auf der
Tischoberfläche implementiert lediglich ein Subset an Visualisierungs-Methoden (so müs-
sen z.B. die Elemente selbst nicht ausgegeben werden) und wird deshalb von jener zur
Behandlung des sekundären Ausgabekanals abgeleitet. Die nicht benötigten Methoden
werden mit leeren Methoden überschrieben. Die zur Ausgabe benötigten Methoden wer-
den unverändert übernommen, unterschiedliche Darstellungsformen (etwa die Stichstär-
ke bei Verbindungen) werden durch Parametrisierung der Datenklassen realisiert, die die
darzustellende Information kapseln.
Beide lokale Ausgabekanäle betten die eigentliche Visualisierungs-Klasse in einen JHotDraw-
Rahmen ein, der die Applikationsinfrastruktur zur Verfügung stellt. In diesem Fall ist
dies die Klasse DrawApplication, die eine direkt ausführbare Java-Applikation erzeugt.
Die Einbindung der eigentlichen Ausgabekanäle erfolgt über die Klasse DrawingView,
die als Basisklasse für die die Ausgabekanäle bedienenden Klassen fungiert. Zur Anzeige
auf der Tischoberfläche wird die JHotDraw-Applikation in den Vollbild-Modus geschal-
ten und mit schwarzem Hintergrund versehen. Auf der Tischoberfläche ist dadurch keine
Projektion zu erkennen, wenn sich keine Modellelemente auf ihr befinden. Die Anzeige
am sekundären Ausgabekanal erfolgt in einem regulären Fenster.
Die Ausgabe auf entfernten (visuellen) Kanälen basiert ebenfalls auf der Klasse, die den
sekundären Ausgabekanal bedient. Tatsächlich ist die Form der Visualisierung identisch
mit einem im Modus synchroner Darstellung betriebenen sekundären Ausgabekanal.
Die Implementierung von entfernten Kanälen unterscheidet sich ausschließlich in der
Übermittlung der darzustellenden Information über eine Netzwerkverbindung.
8.4.1. Ausgabe des Modellzustands
Die Zustand des Modells, also Art und Parameter der auf der Oberfläche befindlichen
Elemente und Verbindungen sind in Objekten der Klassen BasicBuildingBlock bzw.
Connector abgebildet. Diese Klassen kapseln sämtliche Information, die zur Beschrei-
bung des Elementzustandes notwendig ist. Diese Objekte sind außerdem in der Lage, sich
durch ihre clone-Methode selbst vollständig zu reproduzieren. ”Vollständig” bedeutet in
diesem Zusammenhang, dass im Duplikat keine Referenzen mehr auf die Attribute des
Originalobjekts vorhanden sind – das Objekt wird im Sinne einer ”Deep-Copy” vollstän-
dig reproduziert. Dies ist notwendig um gespeicherte Modellzustände vollständig vom
aktuellen Modellzustand zu entkoppeln und persistent abzulegen. Die Ausgabe erfolgt
mittels einer CompositeFigure (eine Komponente des JHotDraw-Frameworks), in die
die graphische Repräsentation des Elements, dessen Benennung sowie ggf. die eingebet-
teten Elemente geschrieben werden. Eventuell vorhandene Markierungen (wie jene, die
durch das Auswahltoken verursacht werden oder die im Rahmen der Wiederherstellungs-
unterstützung als Hinweis zum Entfernen eines Elements hinzugefügt werden) werden
ebenfalls direkt in die CompositeFigure aufgenommen. Die hat den Vorteil, dass Mar-
265
8.4. Umsetzung der Ausgabe mit Software
kierungen an das Element gebunden bleiben und mit diesem bewegt werden, wenn das
betreffende Token verschoben wird.
Eingebettete Elemente enthalten neben ihrer graphischen Repräsentation und ihrer
Benennung auch eine Referenz auf die Ressource, die durch sie repräsentiert wird. Ist
diese Ressoruce ein Teilmodell, so wird dieses als gespeicherter Modellzustand referen-
ziert und beim Abruf entsprechend am sekundären Ausgabekanal dargestellt. Sind ex-
terne Ressourcen (im Sinne von Dateien im Filesystem) angebunden, so werden die-
se beim Abruf mittels der durch die Java-Plattform zur Verfügung gestellten Metho-
de Desktop.open geöffnet. Diese Methode greift dazu auf die Plattform-spezifischen
Dateitypen-Bindungen zu und öffnet die jeweilige Datei mit der zugeordneten Standard-
Applikation.
Assoziationen sind von der durch JHotDraw zur Verfügung gestellten Klasse LineConnection
abgeleitet und werden durch deren Eigenschaften bei der Erstellung explizit an den End-
punkten an zwei Figures (in diesem Fall an BasicBuildingBlocks) gebunden. Der Ver-
binder wird dadurch mit jeder Bewegung eines der Elemente mitgeführt und muss nicht
manuell an den neuen Endpunkt verlegt werden. Methoden zur Anzeige Pfeilspitzen und
Benennung können ebenfalls von der Klasse LineConnection übernommen werden.
Kalibrierung der Ausgabe
Der Projektor, der die Information auf die Tischoberfläche projiziert, ist aus Gründen
der Transportierbarkeit nicht fix im Boden des Tisches eingebaut. Deswegen ist nach
dem Aufbau des Systems im Allgemeinen die projizierte Version des Modells nicht de-
ckungsgleich mit der Position der physischen Tokens. Es kann eine Verschiebung entlang
beider Achsen auftreten, die alle zu den physischen Tokens ausgegebene Information von
diesen absetzt. Dadurch kann die Information unter Umständen nicht mehr eindeutig
zugeordnet werden.
Aus diesem Grund ist die Position der projizierten Modellversion einstellbar, die Ka-
librierung muss einmalig nach dem Aufbau des Werkzeugs vorgenommen werden. Auf-
grund der Verwendung des Umlenkspiegels kann es nicht nur zu einer Verschiebung der
Information auf der X- oder Y-Achse kommen, es können auch Spreizungen oder Stau-
chungen auftreten, welche den Projektions-Fehler von links nach rechts bzw. von oben
nach unten zunehmen lassen. Auch diese Spreizungen oder Stauchungen sind software-
seitig im Rahmen der Kalibrierung korrigierbar.
8.4.2. Ausgabe der Modellierungshistorie
Wird die Modellierungshistorie abgerufen, so wird am sekundären Ausgabekanal der
zuletzt gespeicherte Modellzustand angezeigt. Am primären Ausgabekanal kommt wei-
terhin der aktuelle Modellzustand zur Anzeige. Die Modellierungshistorie wird in Form
266
8.4. Umsetzung der Ausgabe mit Software
von Snapshot-Objekten in einem History-Objekt gespeichert. Das Objekt der Klasse
History dient dabei der Verwaltung der gesamten Historie (also aller Snapshots) und
ermöglicht die Ablage neuer Snapshots und Navigation durch diese sowie den Abruf der
bereits gespeicherten Modellzustände. In den Snapshot-Objekten selbst ist neben dem
eigentlichen Modellzustand ein Zeitstempel abgelegt, der den Zeitpunkt der Speiche-
rung kennzeichnet. Außerdem gibt ein Flag an, ob die Speicherung automatisch erfolgte
oder explizit ausgelöst wurde. Der eigentliche Modellzustand wird als Collection von
Figures gespeichert. Da sowohl BasicBuildingBlocks als auch Connections von der
Klasse Figure abgeleitet sind, können diese hier einheitlich verwaltet werden. Auch bei
der Darstellung muss nicht zwischen den beiden Klassen unterschieden werden, da dem
DrawingView (also der Zeichenoberfläche) zur Darstellung auch lediglich Figures über-
geben werden müssen.
Bei der Navigation durch die Modellierungshistorie wird entsprechend der Drehbe-
wegung des Kontroll-Tokens aus dem History-Objekt der vorhergehende bzw. nachfol-
gende Snapshot abgerufen. Der aktuell auf dem sekundären Ausgabekanal dargestellte
Modellzustand wird gelöscht und durch die im Snapshot gespeicherten Modellelemen-
te und Verbinder ersetzt. Zusätzlich wird der Zeitstempel als Text dargestellt und am
unteren Bildschirmrand der Fortschrittsbalken ausgegeben. Dieser zeigt an, wo in der ge-
samten Historie der aktuell angezeigte Modellzustand zu verorten ist und gibt Feedback
darüber, ob eine weitere Navigation nach vor oder zurück möglich ist.
8.4.3. Umsetzung der Wiederherstellungsunterstützung
Wenn die Wiederherstellungsunterstützung ausgelöst wird, werden vor dem Start der
Ausgabe der Wiederherstellungsanweisungen alle Verbinder ausgeblendet. Da die Be-
nutzer lediglich die Element (bzw. die diese repräsentierenden Tokens) manipulieren
muss, ist die Anzeige der Verbinder nicht notwendig bzw. sogar störend, da sich diese
mit den auf der Oberfläche angezeigten Anweisungen zur Wiederherstellung überlappen
können.
Die eigentliche Wiederherstellungsunterstützung beginnt mit der Berechnung des ers-
ten Schrittes, der von den Benutzern zu setzen ist. Dabei wird geprüft, ob im aktuell auf
der Oberfläche befindlichen Modell ein Element enthalten ist, das im wiederherzustel-
lenden Zustand fehlt. Ist dies der Fall, wird dieses Element markiert und die Benutzer
damit aufgefordert, es zu entfernen. Die so gestellte Aufgabe wird in einem Objekt
der Klasse Task gespeichert. Bei jeder eintreffenden Meldung über Änderungen auf der
Modellierungsoberfläche wird nun mit Hilfe der completed-Methode der Task-Objekts
überprüft, ob der erste Schritt damit ausgeführt wurde (ob im konkreten Fall also das
Element entfernt wurde). Ist dies der Fall, so wird die Methode zur Berechnung des nächs-
ten Schrittes erneut aufgerufen und ein neues Task-Objekt erzeugt, das bei Änderung
auf der Oberfläche wiederum zur Prüfung der Durchführung des Schrittes herangezogen
267
8.4. Umsetzung der Ausgabe mit Software
wird. Sind noch Elemente vorhanden, die im Zielzustand nicht enthalten sind, ist der
nächste Schritt wiederum eine „Entfernen“-Aufgabe.
Befinden sich keine überflüssigen Elemente mehr auf der Oberfläche, so wird die nächs-
te Aufgaben-Kategorie – „Bewegen“ – geprüft. Hier werden all jene Elemente behandelt,
die sowohl im Ausgangs- als auch im Zielzustand enthalten sind, sich jedoch auf unter-
schiedlichen Positionen befinden. Zur Anzeige dieser Art von Aufgaben wird ein Vektor
berechnet, der auf den Ausgabekanälen angezeigt wird und von der aktuellen Position
des zu bewegenden Elements auf die Zielposition weißt, die zusätzlich mit einer Mar-
kierung gekennzeichnet wird. Auch in dieser Kategorie wird bei jeder Änderung auf der
Modellierungsoberfläche geprüft, ob die Aufgabe bereits erfüllt ist.
Wurden auch alle verschobenen Elemente an die korrekte Position bewegt, wird die
Prüfung der letzten Kategorie von Aufgaben – „Hinzufügen“ – durchgeführt. Hier wer-
den Aufgaben für all jene Elemente definiert, die im Zielzustand enthalten sind, im Aus-
gangszustand aber fehlen. Die Zielposition des hinzuzufügenden Tokens wird auf den
Ausgabekanälen mittels einer Markierung und der Benennung des Elements angezeigt.
Sind auch die Aufgaben dieser Kategorie abgeschlossen, werden die Verbinder des Zielzu-
standes eingeblendet (indem die gespeicherten Connector-Objekte der Zeichenoberfläch
einfach hinzugefügt werden) und das System wieder in den Modellierungs-Modus ver-
setzt.
Implementierungstechnisch ist hier noch auf die Entkopplung zwischen Identifikation
des nächsten Schrittes und der Prüfung dessen Durchführung mittels Objekten der Klas-
se Task hinzuweisen. Dies ist notwendig, weil Wiederherstellungsaufgaben über mehrere
Ereignisse auf der Modellierungsoberfläche (also das Verschieben, Hinzufügen oder Weg-
nehmen von Elementen) aktuell bleiben können und so der die Erfüllung der Aufgabe
unabhängig von deren Erstellung geprüft werden muss. Dies hat mehrere Implikationen
für die Implementierung.
Zum einen bringt die Klasse Task eine eigene Methode zur Prüfung der Erfüllung
der in ihr gekapselten Aufgabe mit – Objekte von Task kennen also die Kriterien ihrer
Erfüllung und können diese auch überprüfen. Zum anderen ist es nicht sinnvoll bzw.
in machen Fällen nicht möglich, die durchzuführenden Aufgaben bei der Aktivierung
des Wiederherstellungsmodus vorzuberechnen. Durch den Ablauf der Wiederherstellung
kann der Ausgangszustand auch außerhalb der durch die Aufgaben vorgegebenen Modi-
fikation verändert werden. Dadurch können vorberechnete Aufgaben obsolet bzw. falsch
sein und können deshalb nicht sinnvoll zur Rekonstruktion eingesetzt werden. Tatsäch-
lich wird nach jeder abgeschlossenen Aufgabe der nächste Schritt so bestimmt, als wäre
der Wiederherstellungsmodus eben aktiviert worden. Der aktuelle Zustand auf der Mo-
dellierungsoberfläche wird als Ausgangspunkt herangezogen und wie ober beschrieben
mit dem Zielzustand verglichen. So ist es auch möglich, dass auf eine Aufgabe der zweiten
Kategorie (”Verschieben”) wieder ein Aufgabe der ersten Kategorie (”Entfernen”) folgt,
falls das Modell im vorhergehenden Schritt entsprechend verändert wurde (also etwa ein
268
8.5. Zusammenfassung
nicht benötigtes Element hinzugefügt wurde. Erst wenn in allen drei Kategorien keine
Differenzen zwischen aktuellem Zustand und Zielzustand mehr festgestellt werden, ist
die Wiederherstellungsunterstützung abgeschlossen.
8.5. Zusammenfassung
In diesem Kapitel wurden alle Aspekte dargestellt, die in Zusammenhang mit der Aus-
gabe von Information durch das hier entwickelte Werkzeug stehen. Die Struktur des
Kapitels wurde dabei analog zu jener des vorhergehenden Kapitels erstellt um eine kon-
sistente Darstellung der technischen Aspekte des Systems zu gewährleisten. Im ersten
Teil wurde auf Basis der in Kapitel 5 definierten Anforderungen abgeleitet, welche Ar-
ten von Information den Benutzern zur Unterstützung der Modellierung zur Verfügung
gestellt werden müssen. Die dort identifizierten Aspekte bilden die Grundlage der Tech-
nologieentscheidung und der konkreten Umsetzung des Systems.
Im zweiten Abschnitt wurden die technologischen Grundlagen der Informationsausga-
be behandelt. Nach der Identifikation der Kohärenz von Ein- und Ausgabekanälen als
wesentliches Designkriterium bei Tangible User Interfaces wurden unterschiedliche tech-
nische Lösungen für kohärente und nicht kohärente Informationsausgabe beschrieben.
Die Klassifikation der Ansätze erfolgt dabei auf Basis der von (Fishkin, 2004) vorgeschla-
genen Taxonomie. Auf Basis der bereits vorhandenen technologischen Einschränkungen
durch die Technologie-Entscheidung in Kapitel 7 wurde in der Folge für jede auszu-
gebende Informationsart eine Zuordnung zu kohärenten oder nicht-kohärenten Ausga-
beformen getroffen. Daraus resultiert die Entscheidung, mehr als einen Ausgabekanal
zu verwenden, da eine durchgängig kohärente Ausgabe nicht möglich ist. Für die Um-
setzung der Ausgabekanäle, die auf visuellem Weg realisiert werden, wurden geeignete
Software-Frameworks beschrieben und einander gegenübergestellt. Auf Basis der fest-
gelegten funktionalen und nicht-funktionalen Anforderungen kommen die Frameworks
JHotDraw (Gamma und Eggenschwiler, 1996) und GEF (Moore et al., 2004) in Frage,
von denen für die Erstellung des Prototypen JHotDraw als das System mit der fokus-
sierteren Funktionalität und geringerem Einarbeitungsaufwand ausgewählt wurde. Im
Rahmen einer Diplomarbeit (Feiner, 2008) wurde jedoch daneben ein auf GEF basieren-
der Ausgabekanal implementiert.
Der dritte Abschnitt widmet sich auf Basis der auszugebenden Information und der
zuvor getroffenen Technologieentscheidung der konzeptuellen Architektur der Ausgabe-
kanäle. Hier wurde festgelegt, welche Information in welcher Form auf welchem Ausga-
bekanal dargestellt wird. Dabei wurde zur besseren Strukturierung in Ausgaben unter-
schieden, die dem Modell selbst zuzuordnen sind und in solche, die der Unterstützung
der Modellbildung dienen.
269
8.5. Zusammenfassung
Die Beschreibung der konkreten Umsetzung der Ausgabekanäle ist Gegenstand des
vierten Abschnitts. Anhand eines Klassendiagramms der konkreten Umsetzung wurden
die Zusammenhänge zwischen den Implementierungen der Ausgabekanäle gezeigt, die so
ausgelegt sind, dass Änderungen mit minimalem Aufwand an nur einer Stelle für beide
Ausgabekanäle durchgeführt werden können. Außerdem wurde beschrieben, wie die An-
bindung entfernter Ausgabekanäle realisiert wurde. Für jede Art von auszugebender In-
formation (Modellzustand, Modellierungshistorie und Wiederherstellungsunterstützung)
ist außerdem angeführt, welche Abläufe innerhalb des Systems letztendlich zur Ausgabe
der korrekten Visualisierung führt.
8.5.1. Beitrag zur globalen Zielsetzung
In diesem Kapitel wird die konkrete Umsetzung des Werkzeugs behandelt. Hinsichtlich
der globalen Zielsetzung tragen die hier dargestellten Inhalte also zur Beantwortung der
Fragestellung 4 bei.
8.5.2. Weitere Verwendung der Ergebnisse
Mit der Beschreibung der Softwarekomponenten, die für die Ausgabe der Information
sorgen, ist die eigentliche Benutzungsschnittstelle vollständig definiert. Auf Basis dieses
und des vorhergehenden Kapitels wird in Kapitel 10 das System in die in Kapitel 6
beschriebenen Erklärungs- und Strukturierungsansätze für Tangible Interfaces eingeord-
net. Ein weiterer Aspekt der Implementierung, der in dieser Arbeit zu berücksichtigen
ist, ist die Persistierung der Modell-Information in einer Form, die eine vollständige Ab-
bildung der Semantik der Modelle und eine Weiterverarbeitung durch externe System
erlaubt. Dieser Aspekt ist Gegenstand des folgenden Kapitels.
270
9. Persistierung
In den beiden vorangegangen Kapiteln wurde die Umsetzung der Benutzungsschnittstel-
le des Werkzeugs beschrieben. Neben der Unterstützung des Modellierungsvorgangs ist
aber auch die Speicherung der erstellten Modelle zum Zwecke der Weiterverarbeitung ei-
ne Anforderung an das Werkzeug. Dieser Themenbereich ist der Betrachtungsgegenstand
in diesem Kapitel. Abbildung 9.1 stellt dieses Kapitel und dessen Aufbau im Kontext
der anderen inhaltlich vor- und nachgelagerten Kapitel dar.
Abbildung 9.1.: Kapitel „Persistierung“ im Gesamtzusammenhang
Auf die Persistierung wirken vor allem zwei der in Kapitel 5 identifzierten Anforde-
rungen ein. Zum Ersten ist die Nachvollziehbarkeit des Modellierungsvorganges sicher-
zustellen – dies gilt nicht nur während des Vorgangs selbst, sondern auch danach. Dem-
entsprechend ist sämtliche Information zu persistieren, die zur Wiederherstellung nicht
nur des Modells selbst, sondern auch der gesamten Modellierungshistorie notwendig ist.
Zum Zweiten hat die Forderung nach semantischer Offenheit bei der Modellierung auch
unmittelbare Auswirkungen auf die Persistierung. Neben dem Modell selbst muss auf-
271
9.1. Topic Maps
grund dieser Anforderung auch die Bedeutung der verwendeten Modellierungselemente
miterfasst und persistiert werden, so dass diese bei der Weiterverarbeitung der Modelle
verwendet werden kann.
Die Frage nach einem für diese Anforderungen geeigneten Datenformat kann nicht
ausschließlich auf Ebene der syntaktischen Strukturierung der Daten behandelt werden.
Vielmehr ist es notwendig, Datenformate zu identifizieren, die explizit eine Flexibilisie-
rung und dynamische Festlegung der Semantik der Repräsentation erlauben. Konkret
bedeutet dies, dass hier nicht vorrangig die Codierung der Daten (z.B. in einer rela-
tionalen Datenbank, in XML1 oder anderen, proprietären Datenformaten) von Interes-
se ist, sondern Technologien betrachtet werden müssen, die konzeptuell einen Umgang
mit semantisch angereicherten Daten erlauben. Aktuell dafür verfügbare Ansätze sind
RDF2/OWL3 sowie ISO Topic Maps. Bei RDF/OWL steht die Angabe von semanti-
schen Metadaten zu einzelnen Informationseinheiten im Zentrum, die Verknüpfung der
Information ist implizit in diese Metadaten codiert. Topic Maps behandeln Informati-
onseinheiten und Verknüpfungen gleichrangig und legen stärkeren Fokus auf den Ver-
netzungsaspekt des gesamten Modells. Sie sind deshalb für die in dieser Arbeit erzeugte
Art von Information besser geeignet und werden in der Folge für die Persisitierung her-
angezogen. Eine umfassende Darstellung sowohl von RDF/OWL als auch Topic Maps
sowie eine tiefergehende Beschreibung der jeweiligen Vor- und Nachteile im Kontext des
hier verfolgten Verwendungszwecks ist in (Oppl, 2007a) verfügbar.
In diesem Kapitel werden nun zu Beginn Topic Maps auf konzeptueller Ebene be-
schrieben. Die Abbildung der Modelle und der ebenfalls zu persistierenden zusätzlichen
Information in ein geeignetes Datenmodell ist Gegenstand des darauf folgenden Ab-
schnitts. Schließlich wird die konkrete technische Umsetzung der Persistierung dargelegt
und die dazu notwendigen Software-Infrastruktur im Detail beschrieben.
9.1. Topic Maps
Topic Maps (ISO JTC1/SC34/WG3, 2008) sind wie bereits beschrieben ein Mittel zur
Abbildung von semantischen Netzen. In Topic Maps können beliebige Daten strukutriert
aufbereitet und zueinander in Beziehung gesetzt werden. Die Art der zu repräsentieren-
den Daten ist dabei irrelvant, eine Topic Map trifft keine Aussage über ein den reprä-
sentierten Daten zugrundeliegendes Begriffsystem (sie ist „ontology-agnostic“ (Vatant,
2004)).
Historisch stammen Topic Maps aus dem Bereich der technischen Repräsentation von
Thesauri und Indizes (Pepper, 2000) (Rath, 2003). Aus diesen Bereichen motivieren
1Extensible Markup Language
2Ressource Description Framework
3Ontology Web Language
272
9.1. Topic Maps
sich auch die Bausteine einer Topic Map, wenngleich deren Verwendung durch diesen
Ursprung nicht eingeschränkt wird. Die grundlegenden Elemente einer Topic Map sind
„Topics“, „Associations“ und „Occurrences“ (siehe Abbildung 9.2).
Abbildung 9.2.: Grundlegende Elemente einer Topic Map
„Topics“ stellen Begriffe dar und bilden die Knoten des semantischen Netzes. Ein To-
pic kann beliebige Information darstellen, repräsentiert aber immer genau ein Phänomen
der realen Welt (d.h. zu einem Topic muss es eine Entsprechung außerhalb der Topic
Maps geben, die beobachtbar oder beschreibbar ist und auf die die modellierende Per-
son Bezug nehmen will 4). Eine Topic Map ist damit im Sinne von Stachowiak (1973)
ein diagrammatisches Modell, das einen bestimmten, für den Modellersteller relevanten
Ausschnitt der Realität abbildet.
„Associations“ bilden die Beziehungen zwischen Topics ab und stellen damit die Kan-
ten des semantischen Netzes dar. Eine Association verknüpft Topics semantisch mitein-
ander und kann frei mit Bedeutung belegt werden. Die Art der Beziehungen ist also
nicht festgelegt und kann wie die Bedeutung der Topics frei gewählt werden. Topics und
Associations decken historisch den Bereich der Darstellung von Thesauri ab, in denen
Begriffe definiert und zueinanden in Beziehung gesetzt werden.
Der zweite historische Ursprung von Topic Maps, die Indizes, werden durch das Kon-
strukt der „Occurences“ abgedeckt. Occurences (“Auftreten“) sind Referenzen aus der
Topic Map in die reale Welt. Sie setzen die Topics einer Topic Map in Bezug zu beliebiger
4„A subject can be anything whatsoever, regardless of whether it exists or has any other specific charac-
teristics, about which anything whatsoever may be asserted by any means whatsoever. In particular,
it is anything about which the creator of a topic map chooses to discourse.“ (ISO JTC1/SC34/WG3,
2008, S.8)
273
9.1. Topic Maps
referenzierbarer Information (z.B. Dokumente). Im Kontext der eben genannten Indizes
kann eine Topic Map als der mit Querverweisen versehene Index eines Buches verstanden
werden, in dem durch die Angabe von Seitenzahlen auf den Text des Buches verwiesen
wird. Diese Verweise durch Angabe der Seitenzahlen werden in diesem Zusammenhang
durch Occurrences dargestellt.
Die Ansammlung von durch Associations verknüpften und mit Occurrences versehe-
nen Topics bilden eine Topic Map. Darüber hinaus kann in Topic Maps jedoch noch
weiterführende Information repräsentiert werden (siehe Abbildung 9.3), die Gegenstand
der folgenden Abschnitte sein werden.
Abbildung 9.3.: Umfassende Darstellung der Elemente einer Topic Map
274
9.1. Topic Maps
9.1.1. Topics, Subjects, Topic Names und Variants
Wie oben bereits beschrieben, repräsentiert ein Topic ein Phänomen der realen Welt in
einer Topic Map. Dieses Phänomen der realen Welt, das durch das Topic repräsentiert
wird, wird als „Subject“ bezeichnet. In einer Topic Map darf es zu einem Subject nur
exakt ein Topic geben, umgekehrt kann ein Topic auch nicht mehrere Subjects reprä-
sentieren, die Zuordnung zwischen Subject und Topic ist also eineindeutig (bijektiv).
Im Topic wird dazu exakt ein „Subject Identifier“ registriert, der auf eine Informations-
ressource verweist, die das Subject für Menschen eindeutig identifizierbar macht (diese
Ressource wird als „Subject Indicator“ bezeichnet). Zusätzlich kann ein „Subject Loca-
tor“ angegeben werden, der auf das tatsächlich in der realen Welt vorhandene Subject
verweist. In Abgrenzung dazu kann es bei der anderen Brücke zwischen realer Welt und
Topic Map, den Occurrences, für jeder Topic beliebig viele Zuordnungen geben. Eine Oc-
currence referenziert auch auf die reale Welt, zeigt aber dort nicht auf das Subject selbst,
sondern auf ein dieses Subject beschreibendes Objekt in der realen Welt. Beispielhaft
ist dazu in Abbildung 9.4 dieser Zusammenhang anhand des Topics „Tasse“ dargestellt.
Ein anderes Beispiel ist ein Topic „London“, das als Subject die reale Stadt London re-
präsentiert und dem eine Occurrence zugeordnet werden könnte, die auf eine Landkarte
(als in der Realität vorhandene Beschreibung der realen Stadt London) referenziert.
Abbildung 9.4.: Abgrenzung zwischen Subject und Occurrence in Topic Maps
275
9.1. Topic Maps
Bislang wurde vereinfacht ein Topic immer mit einem direkt zugeordneten Namen
dargestellt. In einer Topic Map besitzt ein Topic jedoch keinen eindeutigen Namen. Es
wird vielmehr durch seinen Subject Identifier eindeutig gekennzeichnet. Dieser ist jedoch
nicht unbedingt für Menschen les- und/oder interpretierbar – der Subject Identifier hat
das Ziel, ein Subject für die Verarbeitung durch Software eindeutig zuordnenbar zu ma-
chen. Für die Bezeichnung eines Topics in einer für Menschen interpretierbaren Form
ist die Verwendung von „Topic Names“ vorgesehen (siehe Abbildung 9.5). Topic Names
werden immer textuell angegeben und beschreiben das Subject, das durch das betref-
fende Topic referenziert wird. Durch einen Topic Name soll das Subject für Menschen
erkennbar sein, wobei die Zuordnung nicht notwendigerweise eindeutig sein muss (Bei-
spiel: der Topic Name „Jaguar“ kann ein Fahrzeug oder eine Großkatze bezeichnen und
ist dementsprechend ein zulässiger Name für zwei unterschiedliche Topics). Einem Topic
können beliebig viele Topic Names zugewiesen werden – es ist so zum Beispiel möglich,
eine Topic Map zu realisieren, in der zu jedem Topic Synonyme als eigene Topic Names
angegeben werden.
Abbildung 9.5.: Benennung von Topics
Als weitere Detaillierungsstufe können zu jedem Topic Name „Variants“ angegeben
werden. Wie durch den Namen angedeutet, handelt es sich dabei um Varianten eines
Topic Names, die in bestimmten Zusammenhängen oder für gewisse Anwendungszwecke
besser geeignet sein können als der eigentlich Topic Name. Ein Beispiel für eine mögli-
che Variante ist die Angabe einer gesprochenen Version des Topic Names. Ein weiteres
Anwendungsgebiet für Varianten ist die im Standard explizit vorgesehene Angabe eines
„Sort Name“ (ISO JTC1/SC34/WG3, 2008, S. 18), der es erlauben soll, Topic Maps
in eine durch diesen Namen vorgegebene Ordnung bringen zu können. Varianten wer-
den durch die Angabe eines dezidiert dafür gewidmeten Topics in deren Scope (siehe
Abschnitt 9.1.5) als Sort Names gekennzeichnet.
276
9.1. Topic Maps
9.1.2. Associations und Roles
„Associations“ stellen Verbindungen zwischen den einzelnen Topics einer Topic Map her.
Associations haben beliebig viele Endpunkte, mindestens jedoch einen (sind also nicht
von vorneherein immer binär sondern können auch unär sein oder mehr als zwei Topics
verknüpfen). Eine Association enthält wie ein Topic nicht unmittelbar einen für Men-
schen lesbaren Namen. Diese wird durch ein Topic festgelegt, das die Kategorie festlegt,
der die Association zuzuordnen sind (siehe Abschnitt 9.1.4). Diesem Topic kann wieder-
um mindestens ein Topic Name zugeordnet werden, welcher letzendlich die Benennung
der Association festlegt.
Associations werden jedoch nicht direkt mit Topics verknüpft. Um ausdrucksstärkere
Verknüpfungen realisieren zu können, agieren „Roles“ als Verknüpfung zwischen Asso-
ciations und den betreffenden Topics. Roles legen die „Rolle“ – also die Bedeutung –
eines Topics in exakt der betrachteten Association fest. Diese Bedeutung kann generisch
sein und zum Beispiel dazu verwendet werden, die per se ungerichteten Associations un-
abhängig von ihrer konkreten Bedeutung mit einer Richtung zu versehen (zum Beispiel
durch die Zuordnung von Roles „Anfang“ und „Ende“) aber auch um die Beziehung
semantisch anzureichern (zum Beispiel durch die Zuordnung von Roles „Veranwortli-
cher“, „Ausführender“ und „Prozessschritt“ in einer Association „durchzuführen“). Die
Anzahl der in einer Association referenzierten Roles gibt damit auch die Kardinalität
der Association (also die Anzahl ihrer Endpunkte) an. Aus den konkreten Roles wird
dann auf die Topics verwiesen, die diese Roles einnehmen bzw. „spielen“ (tatsächlich
heißt die betreffende Eigenschaft einer Role „player“). Wie Associations werden Roles
nicht direkt benannt, sondern über ein Topic, das ihre Kategorie bestimmt, mit einer
Benennung versehen (Details dazu sind wiederum in Abschnitt 9.1.4 angeführt).
9.1.3. Occurrences und Datatypes
Wie zu Beginn dieses Abschnitts bereits beschrieben und in den Erläuterungen zur The-
matik der Subjects (siehe Abschnitt 9.1.1) angedeutet, bilden „Occurrences“ die Brücke
aus der Topic Map in die reale Welt, indem sie auf Ressourcen referenzieren, die in einem
beliebigen Zusammenhang mit den jeweiligen Topics stehen. Ein Topic kann beliebig vie-
le Occurrences haben. Anders als bei Associations existieren für Occurrences keine Roles
(was auch nur bedingt sinnvoll wäre, da jede Occurrence nur zu exakt einem Topic gehö-
ren kann). Die Bedeutung der Occurrence für das Topic kann wie bei Associations über
die Kategorie der Occurrence festgelegt werden, die wiederum durch ein separates Topic
repräsentiert wird (siehe dazu auch Abschnitt 9.1.4). Beispielsweise kann eine Occur-
rence zur Kategorie „Karte“ gehören und so angeben, dass die derart gekennzeichnete
Occurrence zum Topic „London“ auf eine Karte des Stadtgebiets verweist.
Zusätzlich zu der Kategorie wird in einer Occurrence auch der Datentyp der Informa-
tion angegeben, in dem die referenzierte Information vorliegt. Dabei können beliebige
277
9.1. Topic Maps
URIs56) verwendet werden. Da URIs beliebigen Inhalt haben können, wäre es in obi-
gen Beispiel möglich, durch den Datentyp einer Occurrence festzulegen, ob es sich bei
der Karte um eine Rastergrafik oder eine Vektorgrafik handelt und so Information über
deren möglich Einsatzgebiete einzubetten.
9.1.4. Metamodellierung in Topic Maps
Wie oben bereits mehrmals angedeutet, kann in einer Topic Map neben den eigentlichen
zu repräsentierenden Informationen (Topics, Associations, Roles und Occurrences) auch
Information über die Topic Map selbst eingebettet werden (neben dem Model kann also
auch das Meta-Modell abgebildet werden). Die Information umfasst Angaben über die
in der jeweiligen Topic Map existierenen Kategorien von Topics, Topic Names, Associa-
tions, Roles und Occurrences. Hinsichtlich der Repräsentation dieser Information sind
zwei Ansätze zu unterscheiden, von denen der erste bei Kategorieangaben von Topics
zum Einsatz kommt, der andere bei Kategorieangaben jeder anderen Art von Infor-
mation. Allen Kategorien ist gemein, dass sie selbst wiederum als Topics repräsentiert
werden und auch als solche verwendet werden können. Es ist also möglich, zu einem
Topic, das als Kategorie verwendet wird, selbst wiederum eine Kategorie anzugeben,
wodurch die Einführung beliebig vieler Meta-Ebenen möglich ist. Außerdem können als
Kategorien verwendete Topics ebenfalls wieder mit Associations verknüpft und mit Oc-
currences versehen werden. Hinsichtlich der Nomenklatur ist noch darauf hinzuweisen,
dass Kategorien im Allgemeinen als „Types“ bezeichnet werden, man also von „Topic
Types“, „Topic Name Types“, „Association Types“, „Role Types“ und „Occurrence Ty-
pes“ spricht.
Topic Types
Topic Types werden in einer Topic Map durch ein spezielle, im Standard festgelegte
Association definiert. Soll einem Topic ein Type zugewiesen werden, muss eine Associa-
tion der Kategorie „type-instance“ eingefügt werden, bei der das Topic selbst die Role
„instance“ einnimmt und dem Topic, das die Kategorie repräsentiert, die Role „type“
zugewiesen wird. Diese Beziehung entspricht einer Konkretisierung einer (abstrakten)
Kategorie oder Klasse von Topics auf eine bestimmte Instanz, die die Merkmale dieser
Klasse trägt. In Abbildung 9.6 besteht eine type-instance-Beziehung (dort als „instance-
of“ bezeichnet) zwischen der Kategorie „VW Golf“ und der konkreten Instanz „SR-174
AU“ (also einem Topic, bei dem das amtliche Kennzeichen als Topic Name verwendet
wurde). „VW Golf“ fungiert hier also als Topic Type, wobei es selbst ein Topic ist, das
sich durch nichts als die eingenommene „type“-Rolle von einem anderen Topic unter-
scheidet und dementsprechend behandelt werden kann.
5Uniform Resource Identifiers
6wie in RFC 3986 definiert und unter http://www.ietf.org/rfc/rfc3986.txt abzurufen
278
9.1. Topic Maps
Einem Topic können beliebig viele Topic Types zugewiesen werden, indem es in mehr
als einer Association die Role „instance“ einnimmt. Es wird so als mehreren Kategorien
zugehörig gekennzeichnet. Umgekehrt kann ein Topic Type mehr als einem Topic zuge-
wiesen werden, indem das betreffende den Topic Type repräsentierende Topic die Role
„type“ mehrfach einnimmt.
Abbildung 9.6.: Beziehungen in der Metamodellbildung in Topic Maps
Auch ist es möglich, Hierarchien von Types zu bilden, indem einem Topic, das als Topic
Type fungiert, selbst wieder ein Topic Type zugewiesen wird. Diese Möglichkeit ist jedoch
mit Vorsicht zu gebrauchen, da zur Abbildung der Struktur einer Domäne ein seman-
tisch ähnliches, bei näherer Betrachtung aber eine unterschiedliche Bedeutung tragendes
Konstrukt zum Einsatz kommt. Grundsätzlich muss unterschieden werden, ob ein Topic
eine konkrete Instanz eines anderen ist oder lediglich eine Spezialisierung darstellt. Im
ersteren Fall kommt eine „type-instance“ zum Einsatz, das übergeordnete Topic befindet
sich semantisch auf einer anderen, abstrakteren Ebene und stellt eine Kategorie (also
einen Topic Type) dar. Im Falle einer Spezialisierung kommt eine „supertype-subtype“-
Association zum Einsatz, deren Rollen „supertype“ vom übergeordneten, allgemeineren
bzw. „subtype“ vom untergeordneten, spezielleren Topic eingenommen wird. Hier befin-
den sich beide Topics semantisch auf einer Ebene, keines ist abstrakter als das andere.
Der Unterschied liegt vielmehr in der mehr oder weniger konkreten Festlegung der durch
die Topics repräsentierten Subjects. So ist – wie in Abbildung 9.6 dargestellt – das To-
pic „VW Golf“ ein Subtype des Topics „Automobil“ welches wiederum ein Subtype des
Topics „Fahrzeug“ ist. Hier ist erkennbar, dass „Automobil“ insofern eine Spezialisie-
rung von „Fahrzeug“ ist, als dass es im Allgemeinen motorisiert ist und vier Räder
besitzt. „VW Golf“ ist wiederum eine Spezialisierung von Fahrzeug, die hinsichtlich der
Form der Karosserie, der Anzahl der Türen und anderen Merkmalen mehr spezialisiert.
Zwischen keinem der Topics findet jedoch eine Konkretisierung in dem Sinne statt, als
dass auf der untergeordneten Seite von einem konkreten, real existierenden Fahrzeug
die Rede wäre – dazu ist die „type-instance“-Beziehung zu verwenden. Die „subtype-
supertype“-Beziehung ist transitiv, d.h. dass ein „VW Golf“ nicht nur ein „Automobil“
279
9.1. Topic Maps
ist, sondern auch ein „Fahrzeug“. Für „type-instance“-Beziehungen ist diese Eigenschaft
nicht gegeben.
Andere Types
Bei allen anderen Types (konkret also Topic Name Types, Association Types, Role Ty-
pes und Occurrence Types) wird die Kategorie nicht durch eine separate Association
abgebildet, sondern durch eine im jeweiligen Informationselement enthaltene Referenz
auf ein Topic, das als Type fungiert. Die Darstellung der Kategorie-Information ist damit
nicht so explizit wie bei Topic Types, wo sich direkt in der Repräsentation der eigentli-
chen Nutzinformation niederschlägt. Auch semantisch sind die hier behandelten Types
gegenüber Topic Types insofern eingeschränkt, als dass jedem Element exakt ein Type
zugeordnet sein muss (der Type kann also nicht leer sein, auch können nicht mehrere
Types zugeordnet werden). Wie oben bereits erwähnt, sind Topic Types hier flexibler,
einem Topic können beliebig viele oder auch keine Topic Types zugeordnet werden. Dies
ist aber nur vordergründig eine Einschränkung. Topics dürfen wie oben beschrieben für
jedes Subjekt nur einmal existieren. Hat aber ein Subject und damit ein Topic in un-
terschiedlichen Domänen unterschiedliche Bedeutungen, muss dies über mehrere Topic
Types (in Verbindung mit Scopes, siehe Abschnitt 9.1.5) abgebildet werden. Alle anderen
Informationskategorien in der Topic Map unterliegen nicht dieser Eineindeutigkeitsre-
gel und können bzw. müssen, sollten sie unterschiedlichen Kategorien zuzuordnen sein,
auch mehrfach vorhanden sein. Eine Assoziation, die einen anderen Namen trägt (also
einer anderen Kategorie angehört) ist beispielsweise nicht identisch mit der ursprüngli-
chen Assoziation, deren Name ebenfalls bereits durch die Zuordnung zu einer Kategorie
festgelegt wurde.
Modellieren von Einschränkungen
Der Topic Map Standard erlaubt zwar die Angabe von Metamodellelementen (Types),
ermöglicht es aber nicht, Regeln anzugeben, anhand derer der semantisch korrekte Auf-
bau einer Topic Map geprüft werden. Es ist beispielsweise möglich, einen Association-
Type „hat Mitglieder“ zu definieren, der mittels den Roles „Organisationseinheit“ und
„Mitarbeiter“ die Zuordnung von Mitarbeitern zu den Organisationseinheiten eines Un-
ternehmens zuzuordnen. Es ist jedoch in der Topic Map nicht möglich zu spezifizieren,
dass beispielsweise mindestens drei Mitarbeiter zugeordnet werden müssen oder dass es
in dieser Beziehung nur eine Organisationseinheit geben darf. Weiters kann nicht spe-
zifiziert werden, durch Topics welchen Types die jeweiligen Roles eingenommen werden
dürfen – beispielsweise ist eine Zuordnung von Produktionsmitteln in der Role „Mitar-
beiter“ zulässig bzw. kann sie nicht als unzulässig gekennzeichnet werden.
Ist eine derartige semantische Einschränkung bei der Topic Map Erstellung und die
Einführung verbindlicher Strukturvorgaben notwendig, so muss dies außerhalb der To-
280
9.1. Topic Maps
pic Map oder durch externe Interpretation spezifischer Topic Map Elemente geschehen.
In ersterem Fall kann die noch nicht in finalem Zustand vorliegende TMCL (Topic
Map Constraint Language, (ISO JTC1/SC34, 2008)), eine Regelsprache zur Einschrän-
kung der Repräsentationsmöglichkeiten in einer Topic Map, verwendet werden (vgl. dazu
Mayrhauser (2010)). Im zweiten Fall können die Metamodell-Elemente (also alle Topics,
die als Types verwendet werden) durch zusätzliche Associations verknüpft werden, die
semantisch so interpretiert werden, dass sie eine zulässige Kombination von Topics der
jeweiligen Kategorie anzeigen (vgl. dazu (Oppl, 2007a) und (Neubauer, 2008)).
9.1.5. Statements und Scopes
Topic Maps bieten die Möglichkeit, Gültigkeitsbereiche für die in ihnen abgebildeten In-
formationen zu spezifizieren. Ein Gültigkeitsbereich definiert, in welchem Kontext eine
Information gültig ist. Außerhalb dieses Kontextes kann über die Gültigkeit keine Aus-
sage getroffen werden. Der Gültigkeitsbereich wird als „Scope“ bezeichnet. Ein Scope
kann für jedes „Statement“ in der Topic Map gesetzt werden. Statements sind alle „Aus-
sagen“ über Topics, die in der Topic Map abgebildet werden, nicht aber Topics selbst.
Als Statement werden Topic Names, Associations und Occurrences betrachtet. Roles
und Variants besitzen keinen Scope, da sie keine direkte Aussage über Topics treffen,
sondern nur im Zusammenhang mit Associations bzw. Topic Names existieren, deren
Scope sich quasi auf sie vererbt.
Ein Scope für ein Statement wird durch die Angabe eines oder mehrerer Topics festge-
legt. Wird kein Topic angegeben, so gilt der „unconstrainted scope“, das Statement ist
unbeschränkt gültig. Topics zur Abbildung von Scopes können explizit angelegt werden
(z.B. Topics „Deutsch“ und „Englisch“, die Sprach-Scopes ermöglichen, Topics „Zoolo-
gie“ und „Sozialverhalten“ zur Domänenabgrenzung – siehe Abbildung 9.7), es ist jedoch
grundsätzlich auch möglich, die Gesamtheit der Topics einer Domäne zur Definition ei-
nes betreffenden Scopes heranzuziehen (also alle in der Topic Map vorhandenen Topics,
die Tiere repräsentieren, als Scope zu verwenden, um den Gültigkeitsbereich „Zoolo-
gie“ abzubilden). Obwohl der Topic Map Standard hier explizit offen bleibt, ist jedoch
erstere Variante wegen der einfacheren Verwaltbarkeit aber auch der semantischen Voll-
ständigkeit wegen besser geeignet (das Konzept „Zoologie“ käme ansonsten z.B. nicht
notwendigerweise vor, sondern ist nur implizit vorhanden, was eine Auswertung schwierig
macht).
Wird mehr als ein Topic angegeben, so bilden alle Topics gemeinsam den Kontext,
indem das Statement gültig ist. Bei der Auswertung des Gültigkeitsbereichs müssen also
alle angegebenen Topics relevant sein, damit ein Statement gültig ist. Ein Statement
dessen Scope die Topics „Zoologie“ und „Deutsch“ enthält, ist also nur gültig, wenn
beide Topics zutreffen (also z.B. zur Filterung ausgewählt wurden). Die gültigen State-
ments sind also die Schnittmenge jener der Statements, die im Scope „Zoologie“ und im
281
9.1. Topic Maps
Abbildung 9.7.: Abbildung von Gültigkeitsbereichen durch Scopes
Scope „Deutsch“ gültig sind (siehe Abbildung 9.7). Die Angabe eines Scopes zu einem
Statement, das in beiden Scopes (unabhängig voneinander gesehen) gültig sein soll, ist
nicht direkt möglich. In diesem Fall muss das Statement zweimal jeweils unter Angabe
eines der beiden Scopes eingefügt werden.
Für Topics selbst kann kein Scope angegeben werden. Das ist hinsichtlich des Topic
Maps zugrunde liegenden Konzepts auch nicht sinnvoll, da Topics immer ein Phänomen
der realen Welt, das Subject, repräsentieren, das selbst immer vorhanden ist und dessen
Gültigkeit bzw. Existenz nicht von anderen Rahmenbedingungen, wie anderen Subjects,
abhängt. Dementsprechend existiert ein Topic immer, lediglich seine Bezeichnung, die
Beziehungen zu anderen Topics oder seine Occurrences können abhängig vom einem
Scope unterschiedlich sein.
9.1.6. Reification
Wie bereits zu Beginn angeführt, können in einer Topic Map beliebige Inhalte abgebildet
werden, jegliche Phänomene der realen Welt können durch Topics repräsentiert werden.
Konsequenterweise können nun auch Elemente der Topic Map selbst oder sogar die Topic
Map an sich durch ein Topic dargestellt werden. Eine derartige selbstbezügliche Abbil-
dung wird als „Reification“ bezeichnet. Der Ausgangspunkt für eine Reification kann
ein Statement sein oder eine Topic Map selbst. Topics können nicht verwendet werden,
da ein sie repräsentierendes Topic semantisch äquivalent mit dem Ausgangspunkt wäre
und damit zwei Topics vorhanden wären, die das gleiche Subject referenzieren. Nach-
282
9.2. Abbildung von Modellen auf Topic Maps
dem die Abbildung zwischen Subject und Topic eineindeutig sein muss, ist ein derartiges
Konstrukt nicht erlaubt.
In Abgrenzung zur Types (Association Types, Occurrence Types, . . . ) repräsentiert ein
reifizierendes Topic nicht die Kategorie eines Elements, sondern das konkrete Element
selbst. Es ist so möglich, einem konkreten Element wie einer Association zusätzliche
Information hinzuzufügen (etwa eine Occurrence) oder auch eine bestehende Topic Map
als Ganzes zu kapseln und durch das sie reifizierende Topic Bezug zu nehmen.
9.1.7. Merging
Unter „Merging“ versteht man die Vereinigung zweier voneinander getrennter Topic
Maps zu einer gemeinsamen Map. Dabei ist vor allem die Eineindeutigkeitsregel zu be-
achten, für ein Subject darf also in der resultierenden Topic Map nur ein Topic existieren.
Strukturell nicht kritisch, jedoch die Verwendbarkeit einschränkend, sind mehrfach auf-
tretende semantisch identische Statements. Soweit möglich, sollten auch diese Duplikate
im Merging-Prozess entfernt werden.
Der Topic Map Standard definiert für jede Art von Element Regeln, anhand der festge-
stellt werden kann, ob zwei Elemente dieser Art identisch sind oder nicht. Ausgangspunkt
sind immer die Topics, wobei beim Vergleich ausschließlich vom abgebildeten Subject
ausgegangen werden muss. Sind die Subjects identisch, sind im Wesentlichen auch die
beiden Topics identisch und können durch ein gemeinsames Topic ersetzt werden. Auf
Basis der vereinigten Topic Menge werden nun die enthaltenen Statements verglichen.
Damit Statements als identisch erkannt werden, müssen nicht nur ihr eigentlicher Inhalt,
sondern auch ihre Kategorie (Type), ihr Gültigkeitsbereich (Scope) und das/die ihnen
zugeordnete(n) anderen Element(e) identisch sein. Eine Role ist also nur dann mit ei-
ner anderen Role identisch, wenn ihr Type, ihr Scope, die Association, der sie angehört
und das referenzierte Topic identisch ist. Daraus folgt, dass in der Merging-Reihenfolge
zuerst die Topics, dann die eigenständigen Statements wie Topic Names, Associations
und Occurrences und letztendlich die abhängigen Statements wie Roles und Variants
behandelt werden müssen.
9.2. Abbildung von Modellen auf Topic Maps
Diagrammatische Modelle (siehe etwa Oppl und Stary, 2005) können direkt ohne zusätz-
liche Transformationen auf Topic Maps abgebildet werden. Derartige Modelle bestehen
aus Knoten und Kanten, die Verwendung dieser im konkreten Anwendungskontext ist
durch die Modellierungssprache festgelegt. In den folgenden Abschnitten wird nun be-
schrieben, wie die einzelnen Aspekte eines diagrammatischen Modells auf eine Topic
Map abgebildet werden können.
283
9.2. Abbildung von Modellen auf Topic Maps
9.2.1. Grundlegende Abbildung
Ein Ansatz, um diagrammatische Modelle auf Topic Maps abzubilden, ist, die Knoten
auf Topics, die Kanten auf Associations abzubilden (siehe Abbildung 9.8, Variante 1).
Ist in den Kanten mehr Information als die bloße Anzeige der Verbindung von zwei
Knoten abgebildet (wie z.B. in UML7 State Charts (Rumbaugh et al., 2004), bei denen
die zu einem Zustandsübergang führenden Ereignisse inkl. Bedingungen und ablaufende
Aktionen in den Kanten repräsentiert werden), so kann es sinnvoll sein, auch die Kanten
auf Topics abzubilden, da diesen auf dem Wege der Occurrences zusätzliche Informati-
on zugewiesen werden kann (siehe Abbildung 9.8, Variante 2). Associations können in
diesem Fall verwendet werden, um die Knoten und Kanten des Modells zu verbinden,
spielen also in der Repräsentation der Information nur noch ein untergeordnete Rolle.
Ein Weg, die direkte Abbildung beizubehalten (indem Knoten auf Topics und Kanten
auf Associations abgebildet werden) ist, zur Repräsentation der zusätzlich in den Kan-
ten liegenden Information die Möglichkeit der Reification zu nutzen, den Associations
also Topics zuzuweisen, die genutzt werden können, um diese zusätzliche Information zu
verwalten (siehe Abbildung 9.8, Variante 3).
Abbildung 9.8.: Abbildung von Modellinformation in Topic Maps
Die Bedeutung der Knoten des abzubildenden Modells im Kontext einer bestimmten
Kante muss in den direkt abbildenden Varianten (in denen Kanten auf Associations
7Unified Modelling Language
284
9.2. Abbildung von Modellen auf Topic Maps
abgebildet werden) durch Roles dargestellt werden. In der indirekten Abbildung (bei
der Kanten auf Topics abgebildet werden) kann diese Information auch in den Associa-
tions repräsentiert werden, die die Topics, die Knoten darstellen und jene, die Kanten
darstellen, miteinander verbinden.
9.2.2. Abbildung des Metamodells
Da Topic Maps von vorneherein nicht auf eine bestimmte semantische Bedeutung der
Topics und Associations festgelegt sind, muss auch das Meta-Model der abgebildeten
Modellierungssprache mit eingebettet werden. Dies wird in Topic Maps durch die Ein-
bindung von Types ermöglicht. In den nun folgenden Ausführungen wird nur noch auf die
direkt abbildende Variante Bezug genommen, da deren Ausdrucksstärke durch die Mög-
lichkeit zur Reification gegenüber dem indirekt abbildenden Ansatz nicht eingeschränkt
ist und die unmittelbare Abbildung zu insgesamt kleineren, einfacher zu verwaltenden
Topic Maps führt (für eine Kante wird nur eine Association benötigt, im Gegensatz
dazu benötigt der alternative Ansatz ein Topic und mindestens zwei Associations zu
Abbildung einer Kante).
Die in der Modellierungssprache festgelegten Arten von Knotentypen (also den eigent-
lichen Modellierungselementen) werden auf Topic Types abgebildet. Durch die Referen-
zierung eines einen Knoten repräsentierenden Topics auf diesen Topic Type wird die
Bedeutung zugewiesen.
Ebenso wird mit Kanten verfahren. Durch die Einführung von Topics, die als Associa-
tion Types und Role Types fungieren, kann die Bedeutung einer Kante im abzubildenden
Modell definiert werden. Dazu wird ein Association Type festgelegt, der die eigentliche
Bedeutung der Kante festlegt, die zugehörigen Role Types definieren, wie viele End-
punkte existieren und welche Bedeutung diese haben. Für eine konkrete Kante wird
dann eine Association und eine der Anzahl der Endpunkte entsprechende Nummer an
Roles erstellt, denen der jeweilige Association bzw. Role Type zugewiesen wird.
Die Verwendung von Occurrences und dementsprechend die Erstellung von Occurrence
Types ist zur reinen Abbildung von diagrammatischen Modellen nicht notwendig. Die
Verwendung von Occurrences kann aber sinnvoll sein, wenn aus dem ursprünglichen
Modell ebenfalls Ressourcen referenziert werden, die für die weitere Verarbeitung des
Modells notwendig sind. Occurrences werden dann im Sinne der Topic Map zur Referen-
zierung dieser Ressourcen verwendet, wobei sich die zu verwendenden Occurrence Types
an der Bedeutung der Ressourcen im abzubildenden Modell orientieren.
Wie in Abschnitt 9.1.4 bereits beschrieben, bietet die Topic Map selbst keine Mög-
lichkeit, eine explizite Zuordnung zwischen Topic Types, Association Types und Role
Types zu definieren, so dass ein in einer Topic Map repräsentiertes Modell auf semanti-
sche Korrektheit hin überprüft werden könnte. Die einzige ohne zusätzliche Information
285
9.2. Abbildung von Modellen auf Topic Maps
überprüfbaren Bedingungen ist die Prüfung, ob alle Knoten und Kanten (also Topics,
Associations und Roles) einer Kategorie (also einem Type) zugewiesen wurden.
Es muss also zusätzlich eine externe Möglichkeit geschaffen werden, semantische Korrektheits-
Bedingungen zu formulieren und zu überprüfen. Dies umfasst im Einzelnen:
1. Zulässige Kategorien von Knoten (Topic Types)
2. Zulässige Kategorien von Kanten (Association Types, Role Types und eine Zu-
ordnung zwischen diesen, die eine Aussage über die Anzahl und Bedeutung der
Endpunkte der Kante zulässt)
3. Zulässige Verbindungen zwischen Knoten und Kanten (Zuordnung zwischen End-
punkten einer Kantenkategorie und den Knotenkategorien, die diese Endpunkte
belegen dürfen – also eine Zuordnung zwischen Role Types und Topic Types)
Wie bereits oben beschrieben, können derartige Bedingungen innerhalb oder außerhalb
der Topic Map formuliert werden. Die Interpretation der formulierten Bedingungen und
deren Anwendung auf konkrete Anwendungsfälle muss immer von außerhalb der Topic
Map durchgeführt werden. In dieser Arbeit wird der Ansatz der Repräsentation der
Bedingungen innerhalb der Topic Map verfolgt, um durch die Übermittlung einer Topic
Map nicht nur ein Modell an sich zu übertragen, sondern auch jene Information zu
liefern, die zur Interpretation derselben notwendig ist.
Die Formulierung der Bedingungen erfolgt auf Ebene der als Types eingesetzten Topics
und vervollständigt so das in der Topic Map enthaltene Meta-Modell der Sprache, in der
das zu repräsentierende Modell erstellt wurde. Die Information über zulässige Knoten
und Kanten wird über die Festlegung von entsprechenden Types definiert. Für jeden
Typen wird ein Topic eingeführt, das aus dem auf die Topic Map abgebildeten Modell
referenziert werden kann. Alle oben notwendigen Zuordnungen zwischen diesen Types
werden über Associations abgebildet, die die als Types verwendeten Topics verbinden
(siehe Abbildung 9.9).
Die Definition der Kantentypen erfolgt über eine Association mit mindestens drei
Roles. Eine dieser Roles referenziert den Association Type, die anderen Roles verweisen
auf die zu verwendenden Role Types, die zur Beschreibung der Endpunkte der Kante
verwendet werden (wovon mindestens zwei vorhanden sein müssen). Die Angabe der
Kardinaliät (d.h. wie oft ein bestimmter Endpunkt im konkreten Modell auftreten darf)
wird durch ein die jeweilige Role reifizierendes Topic festgelegt.
Ähnlich wird die Zuordnung zwischen Endpunkten und Knotenkategorien realisiert.
Zwischen den entsprechenden Topic Types und Role Types werden Associations erstellt,
die festlegen, ob eine bestimmte Knotenkategorie einen Endpunkt einnehmen darf oder
nicht. Dazu enthält die betreffende Association mindestens zwei Roles, von denen eine auf
den Role Type verweist, der den Endpunkt realisiert und eine entsprechende Anzahl von
Roles, an die die zulässigen Topic Types (also Knotenkategorien) angebunden werden.
286
9.2. Abbildung von Modellen auf Topic Maps
Abbildung 9.9.: Definition des Meta-Models (ohne Kardinalitäten)
287
9.2. Abbildung von Modellen auf Topic Maps
Die eben beschriebenen Abbildungsvorschriften selbst werden ebenfalls in der Topic
Map abgebildet. Die Topic Map enthält damit auch das Meta-Meta-Modell, das die
Elemente festlegt, die zur Festlegung eines Meta-Models und deren Zusammenspiel not-
wendig sind. Eine so definierte Topic Map ist also semantisch vollständig definiert und
ermöglicht eine Rekonstruktion eines Modells, das in einer im Vorfeld unbekannten Spra-
che modelliert wurde, sofern lediglich das Meta-Meta-Modell bekannt ist, das zur Inter-
pretation der Sprachbeschreibung (Meta-Modell) notwendig ist (siehe Abbildung 9.10).
9.2.3. Abgrenzung von Submodellen
In einem Modell kann es sinnvoll oder notwendig sein, unterschiedliche Modellbereiche
voneinander abzugrenzen. Der Grund für die Abgrenzung kann ein inhaltlicher sein (z.B.
eine Partitionierung nach Akteuren bei Aktivitätsdiagrammen (Rumbaugh et al., 2004))
oder aus dem Modellierungsvorgang heraus motiviert sein (etwa bei der Abgrenzung
von Teilmodellen, die durch verschiedene Personen erstellt wurden). Außerdem ist es
möglich, in einer Topic Map mehrere Modelle zu repräsentieren, die ebenfalls voneinander
abgrenzt werden müssen.
Für diese Abgrenzung bietet sich die Verwendung von Scopes an. Scopes haben zwar
keinen Einfluss auf die vorhandenen Topics, wirken jedoch auf die Statements und – hier
relevant – vor allem auf die die Topics verbindenden Associations. Werden also Scopes
eingesetzt, um Teilmodelle voneinander zu unterscheiden bzw. zu trennen, so können die
im Moment nicht relevanten Teilmodelle zwar nicht „ausgeblendet“ werden (im Sinne von
„temporär vollkommen entfernt“), durch die Entfernung der nicht relevanten Statements
sind jedoch nur noch jene Topics untereinander verbunden, die dem aktuell betrachteten
Submodell angehören. Ausgehend von einer beliebigen, im Scope gültigen Association
oder einem Topic, das bekannterweise dem aktuellen Teilmodell angehört, kann so der
gesamte relevante Teil der Topic Map erschlossen werden.
Die Realisierung der Trennung zwischen Teilmodellen durch das Ausblenden irrele-
vanter Verbindungen zwischen Topics birgt einen weiteren potentiellen Vorteil. Werden
in einer Topic Map mehrere untereinander zusammenhängende Modelle abgebildet, so
wird – der Grundforderung einer Topic Map nach Eineindeutigkeit entsprechend – jedes
Element nur einmal abgebildet, egal ob es in nur einem Modell verwendet wird oder in
mehreren. Durch den Einsatz von Scopes bilden in mehreren Modellen verwendete Ele-
mente automatisch eine Schnittstelle, an der zwischen den Modellen navigiert werden
kann. Dieser Vorteil muss in herkömmlichen Modellierungsansätzen, die wie die UML
(Rumbaugh et al., 2004) oder ARIS (Scheer, 2003) mit mehreren untereinander ver-
knüpften Modellen arbeiten, technisch durch explizite Verknüpfung bzw. Referenzierung
der äquivalenten Modellelemente in den unterschiedlichen Modellen erzeugt werden.
288
9.2. Abbildung von Modellen auf Topic Maps
Abbildung 9.10.: Einbindung des Meta-Meta-Modells
289
9.3. Technische Umsetzung der Persistierung von Modellen
Zur Kennzeichnung des Scopes muss zumindest ein Topic verwendet werden. Im Meta-
Modell muss festgelegt werden, ob dazu ein Topic eines bestehenden Types verwendet
wird oder ein neuer Type eingeführt werden, dessen Topics ausschließlich zum Aufspan-
nen eines Scopes verwendet werden. Dazu wird im Meta-Meta-Modell ein Type „Parti-
tion“ eingeführt, der für alle Elemente des Meta-Modells verwendet werden muss, deren
konkrete Instanzen einen Scope im Modell kennzeichnen sollen.
9.2.4. Flexibilisierung der Abbildung
Wie in Kapitel 5 beschrieben, ist das Meta-Modell von Modellen, die im vorgestellten
Ansatz entstehen, nicht im vorhinein festgelegt. Die Modellierungssprache – also das
Meta-Modell – wird während der Modellbildung semantisch definiert und ist damit erst
zur Modellierungszeit bekannt. Das Metamodell kann außerdem während der Modellie-
rung erweitert werden, es ist auch möglich, dass sich die Bedeutung bereits existierender
Meta-Modell-Elemente ändert.
Für die Persistierung bedeutet dies, dass das Meta-Modell nicht im Vorhinein, sondern
erst zum Zeitpunkt der Speicherung festgeschrieben werden kann. Außerdem kann die
Prüfung auf semantische Korrektheit des Modells ebenfalls nur durchgeführt werden,
sobald das Modell definiert ist.
Um die geforderte Flexibilität bei der Sprachdefinition in Form und Zeitpunkt zu
gewährleisten, wurde von Neubauer (2008) ein System entwickelt, das es erlaubt, dy-
namisch zur Laufzeit Modellelemente zu definieren, die Regeln zu deren Verwendung
festzulegen und diese ohne Unterbrechung des Modellierungsvorgangs unmittelbar zu
verwenden (wobei auch die Prüfung der semantischen Korrektheit zur Laufzeit adaptiert
wird). Die technische Umsetzung dieses Ansatzes wird in Abschnitt 9.3.2 beschrieben.
9.3. Technische Umsetzung der Persistierung von
Modellen
Die oben beschriebenen Konzepte zur Persisitierung von Modellen wurden wie die übri-
gen Software-Komponenten des Systems in Java implementiert. Die Basis der Persistenz-
Komponente bildet eine Topic Map Engine, die im Rahmen einer Arbeit über flexible
Content-Repräsentation vom Autor entwickelt wurde (Oppl, 2007a). Das von Neubauer
(2008) entwickelte System zur Generierung und Verwendung dynamischer Metamodelle,
das bereits in Abschnitt 9.2.4 konzeptuell beschrieben wurde, wird in der Folge hinsicht-
lich seiner technischen Umsetzung betrachtet. Basierend auf diesen beiden Komponenten
wurde die eigentlichen Persistierung implementiert. Der dort verfolgte Ansatz ist Thema
des letzten Teils dieses Abschnitts.
290
9.3. Technische Umsetzung der Persistierung von Modellen
9.3.1. Topic Map Engine
Als Topic Map Engine bezeichnet man ein Software-Modul, mit dessen Hilfe Topic Maps
verwaltet werden können und das oft auch Funktionalität zur Persistierung der Topic
Map anbietet. Für den Topic Map Standard (ISO JTC1/SC34/WG3, 2008), der dieser
Arbeit zugrunde liegt, war zum Zeitpunkt der Erstellung der Software nur eine derarti-
ge Engine vertrieben, die von Ontopia8 kommerziell vertrieben wurde und keine offenen
Schnittstellen bot9. Zu diesem Zeitpunkt noch nicht für den verwendeten Topic Map
Standard verfügbar war die Open-Source-Engine TinyTIM10, die auf Basis der ebenfalls
erst seit einigen Monaten verfügbaren Topic Map API eine offene Schnittstelle zur Ver-
waltung von Topic Maps in Java anbietet und unterschiedliche Formate zur Persistierung
und zum Import unterstützt.
Für diese Arbeit wurde mangels verfügbarer Alternativen eine eigene Topic Map En-
gine erstellt. Deren Funktionalität hier nur kurz umrissen werden soll. Die detaillierte
Beschreibung der Implementierung und die allgemeine Verwendung der Engine sind in
(Oppl, 2007a) beschrieben.
Die Topic Map Engine bildet die Komponenten einer Topic Map direkt auf Java Klas-
sen ab. Zusätzlich zu den Klassen, die Topics und Statements repräsentieren, wird eine
Management-Klasse verwendet, deren Instanzen jeweils für die Verwaltung einer abge-
schlossenen Topic Map zuständig sind. Diese Management-Klasse ermöglicht das Hinzu-
fügen und Entfernen von Topics und Statements sowie die Suche nach einzelnen Topics
oder definierten Teilstrukturen (z.B. alle Topics die mittels einer bestimmten Assoziation
mit einem gegebenen Topic in Beziehung stehen). Um die Suche zu beschleunigen, ver-
walten Management-Objekte Indizies bestimmter speziell verwendeter Topics, wie etwa
Topics, die als Topic Types oder Association Types verwendet wurden.
Die Topic Map Engine bietet zur Persistierung ein Interface an, über welches Topic
Maps auf der Engine exportiert werden können bzw. in die Engine geladen werden. Das
Interface abstrahiert dabei von der konkreten Persistierungs-Technologie und erlaubt die
Einbindung unterschiedlicher Ansätze zur Speicherung von Topic Maps.
Konkret wurden drei Implementierungen des Persistenz-Interfaces erstellt. Die ers-
te Implementierung liest und schreibt Topic Maps von bzw. in im XTM11-Format (ISO
JTC1/SC34/WG3, 2006) spezifizierte XML-Dateien. So wird ein standardkonformer Da-
tenaustausch zwischen Topic Map Engines ermöglicht. Die zweite Implementierung bin-
det die Topic Map Engine via Hibernate (Red Hat Middleware, 2007) an eine relationale
Datenbank an. Im Gegensatz zur Speicherung in XML-Files ermöglicht die Ablage der
8http://www.ontopia.com
9mittlerweile wurde Ontopia als Open-Source-Software veröffentlich, was jedoch für diese Arbeit keine
Berücksichtigung mehr fand.
10http://tinytim.sourceforge.net/
11XML Topic Map
291
9.3. Technische Umsetzung der Persistierung von Modellen
Daten in einem RDBMS12 einen effizienteren, selektiven Zugriff, sodass nicht unter allen
Umständen die gesamte Datenbasis einer Topic Map im Arbeitsspeicher gehalten werden
muss.
Die dritte Implementierung des Persistenz-Interfaces ermöglicht lediglich den Export
einer Topic Map in ein von GraphViz (Ellson et al., 2002) interpretierbares Format,
das eine graphische Darstellung der Topic Map mit automatische Anordnung der Topics
ermöglicht. Da das GraphViz-Format jedoch nicht so ausdrucksstark ist wie der Topic
Map Ansatz, geht beim Export Information verloren. Dadurch ist es nicht möglich, eine
Topic Map aus einem GraphViz-File zu rekonstrieren, der Import in die Engine ist also
nicht möglich.
Abbildung 9.11.: Ausschitt einer mittels GraphViz visualisierten Topic Map
Zusätzlich zur Ausgabe der gesamten Topic Map ist das GraphViz-Export-Modul auch
in der Lage, eine mittels HTML Imagemaps navigierbare Version der Topic Map zu
exportieren, in der jeweils immer nur ein Topic mit dessen Kontext (also allen Topics,
die mit dem zentralen Topic verbunden sind) dargestellt wird (siehe Abbildung 9.11).
Durch die Imagemap werden die Kontext-Topics mit jenen an sichten verknüpft, wo
12Relationales Datenbank Management System
292
9.3. Technische Umsetzung der Persistierung von Modellen
jeweils diese im Fokus der Betrachtung stehen. Damit ist eine schrittweise Navigation
durch die Topic Map möglich.
9.3.2. Dynamische Metamodelle
Wie oben bereits beschrieben, ermöglichen Topic Maps die Einführung und Erweiterung
von Meta-Modellen ohne besonders dafür ausgezeichnete Elemente. Dies ist einerseits
hinsichtlich der Flexibilität der Verwendung ein Vorteil, andererseits ist die Handhab-
barkeit von Topic Maps mit integrierten Metamodellen bereits auf Ebene der Software-
entwicklung nur bedingt gegeben, auf Ebene der Benutzer ist die Struktur kaum zu
vermitteln.
Aus diesem Grund wurde bereits von (Oppl, 2007a) eine Abstraktionsschicht einge-
führt, in der die Elemente des Metamodells auf Java-Klassen abgebildet wurden. Diese
Klassen abstrahieren von der darunter liegenden Topic Map und zeigen zum Benutzer
hin eine vom Metamodell abhängige, domänenspezifische Schnittstelle (und inkludie-
ren z.B. Methoden, die zur Verknüpfung zweier Konzepte verwendet werden können,
die im Metamodell festgelegt wurden). Auch auf dieser Ebene wurde wiederum eine
Management-Klasse zur Verwaltung der (nun) domänenspezifischen Modelle eingeführt.
In der vorliegenden Arbeit ist jedoch aufgrund der dynamischen Herausbildung des
Metamodells während des Modellierungsvorgangs die Verwendung von statischen Meta-
Modellen bzw. deren Java-Repräsentationen nicht möglich. Von Neubauer (2008) wurde
das zugrundeliegende System deshalb so erweitert, dass eine Veränderung der Meta-
Modelle zur Laufzeit vorgenommen werden kann, wobei die Änderungen direkt und
unmittelbar auf die verfügbaren Java-Klassen wirken. Zu diesem Zwecke wurde eine
XML-basierte Beschreibungssprache definiert, mit der Meta-Modelle spezifiziert werden
können. In einer weiteren Ausbaustufe ist angedacht, diese Repräsentation so in eine
graphische Benutzungsschnittstelle zu kapseln, dass sie auch von Endanwendern benutzt
werden kann. Aus diese XML-Repräsentation werden mittels Code-Generierung Java-
Klassen erzeugt, die jenen entsprechen, die in der zugrunde liegenden Implementierung
die Abstraktion auf Metamodell-Elemente abbilden. Diese Klassen werden wiederum
zur Laufzeit mittels einem dafür implementierten Java-Classloader geladen und stehen
damit der verwendenden Applikation zur Verfügung. Die Managmentklassen wurden
dementsprechend so erweitert und angepasst, dass sie mit dynamischen Metamodellen
betrieben werden können und die zur Verwendung notwendige Meta-Information an
höher liegende Software-Module weitergeben können.
293
9.4. Export graphischer Repräsentationen
9.4. Export graphischer Repräsentationen
Neben der Persistierung der Modelle in Form einer Topic Map ist es auch sinnvoll, die
Modelle in deren graphischer Form als Referenz abzulegen. Das hier entwickelte Werk-
zeug bedient sich der graphischen Ausgabefunktionalitäten, die der Java Klassenbiblio-
thek mit der Version 1.4 hinzugefügt wurden, um das aktuelle Modell in unterschiedlichen
Formen als Grafik auszugeben und zur späteren Referenz zu speichern.
9.4.1. Ausgabeformen
Zur Speicherung der graphischen Repräsentation eines Modells wird grundsätzlich die
Visualisierung verwendet, die auf dem sekundären Ausgabekanal (also dem Bildschirm)
zur Anwendung kommt. Beim Export sind nun unterschiedliche Modellaspekte zu be-
rücksichtigen, die je nach intendiertem Verwendungszweck einzeln oder in Kombination
in die Ausgabe eingehen können. Diese Aspekte sind im Einzelnen
• der aktuell auf der Oberfläche befindliche Modellzustand
• die hierarchisch in diesen eingebetteten Submodelle
• die Modellierungshistorie, also die Entwicklung des Modells über die Zeit
Die Darstellung dieser Aspekte in einer graphischen Repräsentation ist (außer im erst-
genannten Fall) insofern komplex, als dass eine beliebig lange zeitliche Abfolge bzw. eine
beliebig tief verschachtelte Hierarchie in den zweidimensionalen Raum abgebildet wer-
den muss. Im Falle einer Kombination des zweit- und drittgenannten Aspektes müssen
zwei Dimensionen zugleich abgebildet werden, was die Darstellung zusätzlich erschwert.
Der aktuell auf der Oberfläche befindliche Modellzustand wird exakt wie am sekun-
dären Ausgabekanal (Bildschirm) dargestellt in eine Grafik transformiert und als Bild
abgespeichert. Zur Abbildung der Modellierungshistorie bietet sich an, die einzelnen ge-
speicherten Modellzustände chronologisch anzuordnen. Der sich so ergebende Zeitstrahl
beginnt links oben und setzt sich von links nach recht und oben nach unten bis in die
rechte untere Ecke fort, wo wiederum der aktuelle Modellzustand dargestellt wird. Die
zweidimensionale Abbildung des Zeitstrahls erfolgt dabei derart, dass sowohl die hori-
zontale als auch die vertikale Ausdehnung des resultierenden Bildes minimal sind (siehe
Abbildung 9.12).
Bei der Darstellung eines Modells mit hierarchisch geschachtelten Teilmodellen bietet
sich eine baumartige Darstellung mit dem aktuellen Modellzustand als Wurzelknoten
an. Diese ist aufgrund der notwendigen Detaildarstellung der einzelnen Modelle jedoch
platzintensiv und kann nur schwer als physisches Dokument abgelegt werden. Deshalb
wurde alternativ die hierarchische Struktur auf eine der Darstellung der zeitlichen Mo-
dellentwicklung ähnliche Darstellungsform abgebildet. Dabei wird die Hierarchie flach
294
9.4. Export graphischer Repräsentationen
Abbildung 9.12.: Modellierungshistorie als exportierte Grafik
295
9.4. Export graphischer Repräsentationen
ausgerollt, die Einbettungen zeigen sich durch einen graduell dunkler werdenden Mo-
dellhintergrund für tiefere verschachtelte Ebenen. Zusätzlich wird in jedes Submodell
farblich abgesetzt auch das jeweilige Containerelement eingeblendet. Die Abfolge der
einzelnen Modelle startet mit dem aktuellen Modellzustand als erstem Knoten. Da-
hinter wird das erste im aktuellen Modell eingebettete Teilmodell angezeigt. Besitzt
dieses Teilmodell wiederum eingebettete Teilmodelle, so werden diese in der Folge mit
erneut abgedunkeltem Hintergrund dargestellt. Diese Form der Darstellung wird fort-
gesetzt bis keine weiteren eingebetteten Modelle mehr vorhanden sind. Es folgt (sofern
vorhanden) das zweite Submodelle des aktuellen Modellzustandes (mit dem abgedunkel-
ten Hintergrund der ersten Einbettungsebene). Diese Hierarchie wird wiederum bis zu
den Endpunkten nach unten verfolgt, es folgt ggf. das dritte Submodell auf der ersten
Einbettungsebene. Die sich so ergebende Linie an Modellzuständen wird wie der chro-
nologischen Darstellung der Modellierungshistorie so umgebrochen, dass sich sowohl in
horizontaler als auch in vertikaler Richtung eine minimale Ausdehnung ergibt (siehe
Abbildung 9.13).
In der komplexesten Ausprägung der Darstellung eines Modells als graphische Reprä-
sentation werden sowohl die Historie der Modellentstehung als auch die Hierarchie der
eingebetteten Submodelle zugleich dargestellt. Dies erfolgt hier durch die Kombination
der beiden eben beschriebenen Ansätze. Die Darstellung der Modellierungshistorie bil-
det die oberste Ebene der Modelldarstellung. Beginnend mit dem ältesten gespeicherten
Modellzustand werden die einzelnen Modelle in der Reihenfolge ihrer Entstehung abgebil-
det, wobei zu jedemModellzustand unmittelbar folgend dessen eingebetteten Submodelle
ausgegeben werden (deren Entstehung nicht mehr separat dargestellt wird). So ergibt
sich eine kombinierte Linie aus chronologischer Modellentwicklung und eingebetteten
Teilmodellen. Diese wird wie schon oben mit minimaler Ausdehnung in horizontaler wie
vertikaler Richtung auf eine Grafik abgebildet. Die Entwicklung des Modells ist dabei
wie gehabt von links oben nach rechts unten zu verfolgen, wobei nur jene Modellzustän-
de mit weißem Hintergrund auf oberster Ebene der Zeitlinie angehören. Alle dunkler
hinterlegten Modelle sind Teilmodelle und sind dem nach vorne nächstgelegenen weiß
hinterlegten Modell zuzuordnen.
9.4.2. Technische Umsetzung des graphischen Exports
Zur Umsetzung des graphischen Exports wird auf die mit der Java Plattform in der Ver-
sion 1.4 eingeführten Klassen zu Verarbeitung von Grafikformaten zurückgegriffen. Diese
unterstützen standardmäßig gängige Grafikformate wie JPEG13, GIF14 oder PNG15. Im
konkreten Fall wurde ein verlustfrei komprimierendes Format gewählt, verlustbehaftete
13Joint Photographic Experts Group (File Interchange Format)
14Graphics Interchange Format
15Portable Network Graphics
296
9.4. Export graphischer Repräsentationen
Abbildung 9.13.: Modell-Hierarchie als exportierte Grafik
297
9.5. Zusammenfassung
Verfahren wie JPEG sind für die hier abzubildenden feinen Strukturen nicht geeignet, da
es durch Kompressionsartefakte zu Qualitätsminderungen in der Darstellung von Details
kommt.
Die Ausgabe einer Datei im gewählten Grafikformat wird vollständig von der Klasse
ImageIO übernommen. Der Schnittstellen-Methode write sind als Parmeter der Datei-
name, das Grafikformat sowie ein Objekt der Klasse BufferedImage (allgemeiner: einer
Klasse, die das Interface RenderedImage implementiert) zu übergeben, das die eigentli-
chen Bilddaten enthält.
Das BufferedImage-Objekt kann durch einen Methoden-Aufruf mit der graphischen
Repräsentation einer Klasse, die von der Java AWT16-Klasse Component abgeleitet ist,
befüllt werden. Da alle graphischen Komponenten des JHotDraw-Frameworks Subklas-
sen eben dieser Klasse sind (inklusive der Zeichenoberfläche selbst), können diese durch
einen Aufruf ihrer paint-Methode in ein ausreichend großes BufferedImage (bzw. des-
sen Graphics-Objekt) geschrieben werden.
In den aus mehr als einem Teilmodell bestehenden Ausgaben (also der Historie, der
hierarchischen Darstellung der Teilmodelle oder der Kombination dieser beiden Fälle)
muss das Bild aus den graphischen Repräsentationen der einzelnen Teilmodelle zusam-
mengesetzt werden. Dazu werden (im Falle der hierarchischen Teilmodelle rekursiv) die
logischen Modelle erzeugt und bereits in der korrekten linearisierten Darstellungsform
in einem Vektor gespeichert. Die einzelnen logischen Modelle werden dann in graphi-
sche Repräsentationen umgewandelt und in je einem BufferedImage gespeichert. Diese
werden in der Folge so zusammengesetzt, dass die horizontale und vertikale Ausdehnung
der Gesamtfläche minimal ist.
9.5. Zusammenfassung
In diesem Abschnitt wurde auf die Umsetzung der Forderung nach persistenter Ablage
der erstellten Modelle eingegangen. Um eine vollständige Abbildung der flexibel struk-
turierten Information gewährleisten zu können, wurde eine auf ISO Topic Maps basie-
rende Speicherung verwendet. Da sich deren Handhabung bereits bei wenig komplexen
Modell-Strukturen als sehr aufwändig erweist, wurden zusätzlich Werkzeuge zur Generie-
rung und Verwaltung implementiert. Diese gehen auch speziell auf die Herausforderung
der dynamisch veränderlichen Meta-Modelle ein und lösen diese durch den Einsatz von
Codegenerierung und -deployment zur Laufzeit der Modellierungsapplikation.
Zusätzlich zu der vollständigen und automatisiert weiterverarbeitbaren Repräsentation
durch Topic Maps kann auch eine graphische, für Anwender erfassbare Darstellung des
erstellten Modells bzw. wahlweise auch dessen Entstehungsgeschichte erstellt werden.
16Abstract Window Toolkit
298
9.5. Zusammenfassung
Diese entspricht im Wesentlichen der Darstellung auf der sekundären Oberfläche und
wird als Grafikdatei ausgegeben.
Mittels dieser beiden Werkzeuge ist die weitere Verarbeitbarkeit der erstellten Modelle
inklusive der Entstehungsgeschichte und aller zusätzlich festgelegter semantische Infor-
mation gewährleistet, während gleichzeitig eine unmittelbare Dokumentation des Mo-
dellierungsergebnisses und -prozesses für Benutzer erfassbar ausgegeben werden kann.
9.5.1. Beitrag zur globalen Zielsetzung
In diesem Kapitel wird die konkrete Umsetzung des Werkzeugs behandelt. Hinsichtlich
der globalen Zielsetzung tragen die hier dargestellten Inhalte also zur Beantwortung der
Fragestellung 4 bei.
9.5.2. Weitere Verwendung der Ergebnisse
Die Inhalte dieses Kapitels werden erst in den Schlussbetrachtungen (Kapitel 15) wieder
aufgegriffen. Die Persistierung selbst ist eine Anforderung an das Werkzeug, die erfüllt
sein muss, deren Erfüllung aber nicht im Rahmen von Benutzertests, die Gegenstand
von Teil III dieser Arbeit sind, geprüft werden muss.
299
Teil III.
Evaluierung des Instruments
300
Einleitung
Nach der nun erfolgten Beschreibung der Umsetzung des Werkzeugs wird in diesem Teil
die Überprüfung der Verwendbarkeit des entwickelten Instruments und seiner Effekte
behandelt. Ziel dieser Arbeit ist es, die effektive Durchführung explizite „Articulation
Work“ zu unterstützen. Ziel dieses Teils ist, diese Anforderung hinsichtlich ihrer Erfül-
lung oder Nicht-Erfüllung zu überprüfen und damit die Beantwortung zweite in Kapitel
1 formulierte Forschungsfrage zu vervollständigen.
Wie in Kapitel 3 argumentiert, führt ein möglicher Weg zur Unterstützung expliziter
„Articulation Work“ über die (kollaborative) Externalisierung mentaler Modelle. Die
aus dieser Externalisierung resultierenden Strukturen sind ihrerseits diagrammatische
Modelle. Die Qualität dieser Modelle ist vielschichtig bewertbar, im Kontext des hier
verfolgten Verwendungszwecks sind aber einige Bewertungsdimensionen identifizierbar,
die bei der Unterstützung von „Articulation Work“ relevant sind. Diese Dimensionen
werden ebenfalls hinsichtlich ihrer Ausprägung im hier vorgestellten Werkzeug zu be-
werten sein.
Letztendlich wird die Externalisierung mentaler Modelle technisch durch ein Table-
top Interface unterstützt. Auch die technische Umsetzung bzw. deren Verständlichkeit
und Verwendbarkeit hat Auswirkungen auf den Erfolg der Externalisierung und damit
der durchgeführten „Articulation Work“. Das Werkzeug selbst und seine Nutzung muss
also ebenfalls untersucht und im Kontext der Anforderungen in dieser Arbeit bewertet
werden.
Entsprechend dieser Ausführungen wurde die hier beschriebenen Untersuchung durch-
geführt. Sie gliedert sich in drei Teile, die sich mit dem Werkzeug selbst, den erstellten
Modellen und den Auswirkungen durchgeführten expliziten „Articulation Work“ aus-
einandersetzen. Die Struktur dieses Teiles spiegelt diese Aufteilung wieder. In Kapitel
10 wird das Werkzeug aus Sicht seiner Eigenschaften als Tabletop Interface theoretisch-
konzeptuell betrachtet und aus den in diesen Bereich verfügbaren Analyse- und Beschrei-
bungsframeworks mögliches Verbesserungspotential identifiziert. Kapitel 11 beschreibt
die Grundlagen der empirischen Untersuchung, in der das hier entwickelte Werkzeug
hinsichtlich seiner Verwendbarkeit und Wirkung untersucht wurde. In Kapitel 12 wer-
den Design und Umsetzung jener Tests beschrieben, in denen die Benutzbarkeit und
Verständlichkeit des Werkzeugs überprüft wurden. Die Überprüfung der Effekte des
Werkzeugs beginnt im darauf folgenden Kapitel 13, in dem die erstellten Modelle und
deren Entstehungsprozess Gegenstand der Betrachtung sind. Letztendlich wird in Kapi-
tel 14 auf die Wirkung des Werkzeugs auf „Articulation Work“ und damit letztendlich
auf die im jeweiligen Anwendungsfall zu erzielenden Effekte eingegangen.
10. Konzeptuelle Einordnung des
Werkzeugs
An dieser Stelle erfolgt ein Rückgriff auf die in Abschnitt 6.4 beschriebenen konzeptuel-
len Beschreibungs-Ansätze für Tangible User Interfaces. Das in den letzten drei Kapiteln
beschriebene Werkzeug wird hier im Lichte eben dieser Ansätze betrachtet und wo mög-
lich mittels der vorgeschlagenen Schemata beschrieben. Damit werden zwei Ziele ver-
folgt. Einerseits soll die Praxistauglichkeit der konzeptuellen Ansätze überprüft werden,
indem sie auf ein aktuelles, im Vergleich zu den beispielhaft in den Artikeln angege-
benen Systemen komplexes und funktional umfangreiches System angewandt werden.
Andererseits soll durch die konzeptuelle Betrachtung des Werkzeugs dessen Design und
die Umsetzung auf Inkonsistenzen geprüft werden und Potential für Verbesserungen
des Werkzeugs identifiziert werden. Die hier abgeleiteten Potentiale werden in Kapitel
15 den Erkenntnissen aus der praktischen Evaluierung des Systems gegenübergestellt.
So wird es möglich, auch die potentiellen Auswirkungen der Anwendung eines der hier
vorgestellten konzeptuellen Ansätze bei der Konzeption und Umsetzung eines TUI zu
betrachten. Abbildung 10.1 stellt dieses Kapitel und dessen Aufbau im Kontext der
anderen inhaltlich vor- und nachgelagerten Kapitel dar.
Dieses Kapitel folgt im Aufbau der Struktur des Abschnitts 6.4 und betrachtet in der
Folge jeden der vorgestellten Ansätze in einem separaten Abschnitt. Dabei werden jeweils
die Konzepte des Ansatzes auf das Werkzeug angewandt (Unterabschnitt „Abbildung“)
und in der Folge die Erkenntnisse über die Eignung des Ansatzes und mögliches Verbes-
serungspotential des Werkzeugs angeführt (Unterabschnitt „Bewertung“). Abschließend
erfolgt eine zusammenfassende Betrachtung der Ergebnisse hinsichtlich der beiden oben
formulierten Ziele.
10.1. Einordnung in den Bricks-Designraum
Grundlage der Betrachtungen in diesem Abschnitt ist das Konzept der Tangible Bits
(Fitzmaurice et al., 1995), der in Abschnitt 6.4.1 beschrieben wird.
302
10.1. Einordnung in den Bricks-Designraum
Abbildung 10.1.: Kapitel „Konzeptuelle Einordnung“ im Gesamtzusammenhang
Abbildung
Aus den Erfahrungen mit der Erstellung des „Bricks“-Systems leiten Fitzmaurice et al.
(1995) einen „Design Space“ ab, der 13 Merkmale definiert, die bei der Konzeption
eines TUI beachtet werden sollten bzw. die sich zum strukturierten Vergleich von TUIs
eignen. Neben den Merkmalen geben die Autoren auch mögliche Ausprägungen an, die
gemeinsam den Design Raum abstecken. Für das hier vorgestellte Werkzeug ergibt sich
folgende Zuordnung:
In der Kategorie Brick’s internal ability ist das System bzw. die eingesetzten Tokens
als „inert“ zu klassifizieren, da die physischen Objekte keine Elektronik aufweisen und
somit kein aktives Verhalten zeigen können. Bezieht man die unmittelbare Umgebung
der Elemente, auf die Information projiziert werden kann, in die Beurteilung mit ein, so
ist die Einstufung „simple expressions“ zu rechtfertigen.
In der Kategorie Input & Output werden eingabeseitig in unterschiedlichen Interak-
tionen folgende Parameter kontinuierlich oder ereignisgesteuert erfasst: X-Y-Position
(kont.) , Rotation (kont.) , Tastatureingabe (ereignisgest.) und Kamerabild (ereignis-
gest.). Ausgabeseitig werden folgende Parameter eingesetzt: Zustand auf der physischen
Oberfläche, Projektion und Bildschirm.
In der Kategorie Spatially aware ist (bezogen auf die Tokens) die Ausprägung „un-
aware“ zu wählen, da die physischen Elemente selbst keine Möglichkeit zur Feststellung
der Konfiguration ihrer Umgebung haben. Bezogen auf das Gesamtsystem ist die Aus-
prägung „mutual awareness“ zu wählen, da den softwareseitigen Repräsentationen der
303
10.1. Einordnung in den Bricks-Designraum
Elemente durch das im Hintergrund arbeitende Lokalisierungssystem durchaus bekannt
ist, wo sie sich befinden und welche Elemente sich in ihrer Nähe befinden.
In der Kategorie Communication ist keine Einordnung möglich, da die physischen
Elemente des Systems nicht untereinander kommunizieren.
In der Kategorie Interaction time span sind die Ausprägungen „quick“ und „interaction
cache“ zu wählen. Die meisten Interaktionen laufen ereignisbasiert ab und sind mit der
Auslösung wieder abgeschlossen („quick“). Manche Interaktionen (z.B. Herstellung einer
Verbindung, Kontrolle der Modellierungshistorie, . . . ) benötigen jedoch längere Zeit bzw.
die Manipulation mehrerer Tokens („interaction cache“).
In der Kategorie Bricks in use at same time ist bei Betrachtung des gesamten Systems
die Ausprägung (Größenordnung) „5-10“ zu wählen, da potentiell so viele Modellierungs-
elemente gleichzeitig (auch durch mehrere Personen) benutzt werden. Bezogen auf die
Werkzeug-Tokens (also die unmittelbar funktionsauslösenden physischen Elemente, die
eigentlich von diesem Ansatz eigentlich betrachtet werden) sind die Ausprägungen „1“
oder „2“ (je nach Interaktion) zu wählen.
In der Kategorie Function assignment ist bezogen auf die Werkzeug-Tokens die Ausprä-
gung „permanent“ zu wählen, da diesen die durch sie ausgelöste Funktion fix zugeordnet
ist.
In der Kategorie Interaction representations ist die Ausprägung „balanced“ insofern
für das vorliegende Werkzeug passend, als dass die physischen und digitalen Elemente
einander in der Repräsentation des Systemzustandes gleichberechtigt ergänzen.
In der Kategorie Physical & virtual layers erfüllt das System durch die beiden Aus-
gabekanäle beide Ausprägungen („direct“ für die Tischoberfläche, „indirect“ für den
sekundären Ausgabekanal).
In der Kategorie Bond between physical & virtual layers sind physische und virtuel-
le Ebene im hier vorgestellten System „tightly coupled“, da die Repräsentationen auf
beiden Ebenen stets synchron sind.
In der Kategorie Operating granularity ist aufgrund der physischen Natur des Systems
(Tisch) die Ausprägung „Desktop“ zu wählen, wobei dies auch mit der vorgesehenen
Auflösung des Tracking („fraction of inches accuracy“) korreliert.
In der Kategorie Operating surface type erfüllt das System die Anforderungen der
Ausprägung „dynamic“, da sich die Oberfläche durch die Projektion von Information
zur Laufzeit ändert.
In der Kategorie Operating surface texture ist die Ausprägung „continuous“ auszuwäh-
len, da die Elemente frei auf der Oberfläche platziert werden können.
304
10.2. Bestimmung der Eigenschaften des Graspable User Interfaces Ansatz
Bewertung
Der von Fitzmaurice et al. (1995) aufgespannte Design Raum für Graspable User Inter-
faces ist aus dem von den Autoren entwickelten System abgeleitet und weist mangels
zum Zeitpunkt der Erstellung vorhandenen Alternativen starke Spezifika auf, die den
Ansatz zur Einordnung anderer Systeme nur bedingt geeignet machen. Insbesondere die
Ableitung mehrerer Eigenschaften aus der Tatsache, dass die physischen Elemente des
Systems (die „Bricks“) aktive Bausteine sind und auf einer Oberfläche bewegt werden,
schränkt die Verwendbarkeit einiger Kategorien für die Einordnung beliebiger TUIs ein
(z.B. Communication oder Spatially aware). Außerdem ist der Design Raum auf Systeme
ausgerichtet, die physische Elemente als Eingabewerkzeuge verwenden und berücksich-
tigt keine Elemente, die ausschließlich zur Informationsrepräsentation verwendet werden.
Das hier vorgestellte Werkzeug konnte weitgehend in den Design Raum eingeordnet
werden, wenn auch die Verwendung passiver Tokens nicht vorgesehen ist und damit
einige Kategorien nicht sinnvoll belegt werden können. Ansätze zur Verbesserung des
Werkzeugs können nicht abgeleitet werden, da der Designraum für Detailbetrachtungen
zu unspezifisch bleibt und seine generelle Ausrichtung nicht vollständig auf die Eigen-
schaften des Werkzeugs abgebildet werden können.
10.2. Bestimmung der Eigenschaften des Graspable
User Interfaces Ansatz
Grundlage der Betrachtungen in diesem Abschnitt ist das Konzept der Tangible Bits
(Fitzmaurice, 1996), der in Abschnitt 6.4.2 beschrieben wird.
Abbildung
Fitzmaurice (1996) definiert fünf Eigenschaften, die ein „Graspable User Interface“ aus-
machen und legt mögliche Ausprägungen fest, deren Werte für ein konkretes System eine
Aussage über dessen „Graspabiltity“ zulässt. Für das hier vorgestellte Werkzeug können
folgende Einstufungen getroffen werden:
In der Kategorie Space-multiplexing ist die höchste Ausprägung „permanent, never
reassign“ auszuwählen. Dies ist der Fall, weil sämtlichen Werkzeugtokens des Systems
eine vorgegebene Funktion zugewiesen ist, die sich während der Laufzeit nicht ändert.
In der Kategorie Concurrency ist hinsichtlich der Verwendung von Werkzeugen die
Ausprägung „occasionally 2“ zu wählen. Die Eigenschaften beziehen sich ausschließlich
auf Werkzeuge zur Manipulation digitaler Information, so dass die Modellierungsto-
kens, die den Systemzustand repräsentieren, außer acht gelassen werden. „Occasionally
2“ trifft dann deswegen zu, weil sowohl bei der Verbindungsherstellung als auch zum
305
10.3. Betrachtung im Lichte des Tangible Bits Ansatzes
Auslösen der Wiederherstellungsunterstützung jeweils zwei Werkzeugtokens gleichzeitig
eingesetzt werden müssen, in allen anderen Fällen aber nur ein Werkzeug zum Einsatz
kommt. Berücksichtigt man die Modellierungstokens (als Werkzeuge zur Manipulation
des Systemzustandes), ist die höchste Ausprägung „more than 3“ zu wählen.
In der Kategorie Physical form ist die höhere Ausprägung „specific“ auszuwählen, da
für jede Funktionalität ein spezifisches Werkzeug-Token existiert.
In der Kategorie Spatially aware ist hinsichtlich der Werkzeugtokens eine Mischform
zwischen „unaware“ und „aware“ zu wählen. Bei einem Teil der Werkzeugtokens ist die
konkret ausgeführte Funktion von dessen Position bzw. Nähe zu Modellierungstokens ab-
hängig (bei Markierungstokens) oder wird durch dessen Orientierung beeinflusst (beim
Historien-Kontroll-Token). Die übrigen Werkzeug-Tokens sind jedoch insofern „spatial-
ly unaware“, als dass ihre Positionierung auf der Oberfläche keinen Einfluss auf deren
Funktionalität hat. Die Modellierungstokens und die einbettbaren Tokens sind bei Be-
rücksichtigung als „spatially aware“ zu klassifizieren.
In der Kategorie Spatial reconfiguarability ist das System in die Ausprägung „track“
einzuordnen, da die einzelnen Werkzeuge nicht unabhängig von der Oberfläche und der
in ihr integrierten optischen Tracking-Funktion verwendet werden können.
Bewertung
Die Eigenschaften von Graspable User Interfaces erlauben eine allgemeine Bewertung
eines TUI. Sie sind nicht geeignet um eine detailliert Analyse oder Spezifikation durch-
zuführen. Dieser Aspekt – die Eigenschaften des Gesamtsystems – wird jedoch bei den
meisten anderen Frameworks außer acht gelassen, so dass eine Einordnung in das vor-
geschlagene Schema durchaus sinnvoll sein kann.
Für das hier vorgestellte Werkzeug wurden durchwegs Ausprägungen identifiziert, die
auf eher hohe „Graspability“ hinweisen. Ein Nachteil des Ansatzes liegt in der Fokussie-
rung auf reine „Steuerungs“-TUIs, die zur Kontrolle oder Manipulation digitaler Infor-
mation verwendet werden. Verbesserungspotential kann ob der allgemeinen und relativ
abstrakten Beschreibung des Werkzeugs mit diesem Ansatz nicht abgeleitet werden.
10.3. Betrachtung im Lichte des Tangible Bits Ansatzes
Grundlage der Betrachtungen in diesem Abschnitt ist das Konzept der Tangible Bits
(Ishii und Ullmer, 1997), der in Abschnitt 6.4.3 beschrieben wird.
306
10.3. Betrachtung im Lichte des Tangible Bits Ansatzes
Abbildung
Das hier vorgestellte Werkzeug kann hinsichtlich seiner Funktion als eine Instanz des
Konzepts „Interactive Surface“ betrachtet werden. Die „Surface“ ist hierbei eine Tisch-
oberfläche, auf der interagiert wird. Die im Rahmen der Beschreibung des „metaDESK“
(Ullmer und Ishii, 1997) als Beispiel für eine „Interactive Surface“ eingeführten TUI-
Elemente finden zum Teil auch im hier vorgestellten Werkzeug Anwendung.
Die Modellierungstokens und einbettbaren Tokens des Werkzeugs sind Phicons, al-
so passive Träger von digitaler Information. Die Werkzeugtokens zur Manipulation des
Modells entsprechen Phandles, also Elementen, die dazu verwendet werden, digitale In-
formation zu verändern bzw. festzulegen. Jene Werkzeugtokens, die der Steuerung der
Systemfunktionen dienen, sind hingegen als Instruments zu klassifizieren. Lenses und
Trays kommen im Werkzeug nicht zum Einsatz.
Hinsichtlich der Metaphorik unterscheiden Ullmer und Ishii (1997) zwischen unter-
schiedlichen Abstraktionsebenen von Phicons (generic – symbolic – model), wobei im
vorliegenden System ob der offenen Semantik die Modellierungstokens ausschließlich ge-
neric Phicons sind bzw. sein können. Die Werkzeugtokens sind zumeist als symbolic
Phicons und im Falle des Löschtokens – dem Radiergummi – eher als model Phyicon zu
klassifizieren.
Bewertung
Für die Bewertung des Werkzeugs ist vor allem dessen Gegenüberstellung zu den vorge-
schlagenen Elementen einer „Interactive Surface“ von Interesse. Hier zeigt sich, dass die
unterschiedlichen Arten von Tokens, die im Werkzeug eingeführt wurden, feingranular
auf die unterschiedlichen Element-Arten von Ishii und Ullmer (1997) abbildbar sind.
Insbesondere die explizite Unterscheidung zwischen Phandles und Instruments ist ein
Alleinstellungsmerkmal der hier vorgeschlagenen Systematik.
Eine mögliche Lücke, die Erweiterungspotential für das Werkzeug anzeigen könnte, ist
die Abwesenheit von TUI-Elementen, die als Lenses oder Trays zu klassifizieren sind.
Insbesondere Trays sind für die explizite Interaktion mit einzelnen Tokens – etwa der
Benennung oder der Einbettung von Zusatzinformation – geeignet. Bei entsprechen-
der Spezifikation bilden die dazu notwendigen Interaktionsabläufe den Vorgang der Zu-
ordnung von Information explizit ab und unterscheiden sich dann stärker von anderen
Interaktionen, die anderen Zwecken, z.B. der Herstellung von Verbindungen zwischen
Modellierungstokens, dienen.
307
10.4. Einordnung in das Ordnungssystem von Holmquist et al.
10.4. Einordnung in das Ordnungssystem von Holmquist
et al.
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Holmquist et al.
(1999), der in Abschnitt 6.4.4 beschrieben wurde.
Abbildung
Die von Holmquist et al. verwendete Terminologie ist direkt auf jene abbildbar, die
in dieser Arbeit verwendet wurde. Die Modellierungstokens und einbettbaren Tokens
entsprechen im Wesentlichen Tokens. Dies ist dadurch begründbar, dass die Art eines
Modellierungstokens in einem Modell immer im gleichen Zusammenhang mit der Art
der Information steht, die durch dieses repräsentiert wird. Eine Eigenschaft, die eher
Containern zuzuordnen ist, ist jedoch die dynamische Festlegbarkeit der Bedeutung
einer Art von Modellierungstokens - die physischen Elemente an sich sind vor Beginn
der Modellbildung generisch (also Container), werden aber im Zuge der Modellierung
mit Bedeutung belegt (die dann für alle Instanzen dieser Art von Modellierungstokens
gilt) und sind dann eher als Tokens zu klassifizieren.
Die Werkzeugtokens des hier vorgestellten Systems entsprechen in ihrer Konzeption
den Tools. Sie manipulieren digitale Information, lösen Aktionen aus oder versetzten das
System in einen anderen Zustand und entsprechen damit exakt der Definition von Tools,
die von den Autoren gegeben wird.
Information Faucets sind im Kontext des hier vorgestellten Systems einerseits die
Tischoberfläche, über die Information zu Modellierungstokens abgerufen werden kann,
andererseits ist die Registrierungskamera ein klassisches Faucet im Sinne der Definition,
da sie dem Abruf oder der Assoziation von Information an ein Token dient, sobald dieses
in den Erfassungsbereich der Kamera gerät.
Bewertung
Die konzeptuellen Elemente des hier vorgestellten Systems sind also auf das Ordnungs-
system von Holmquist et al. (1999) abbildbar. Die Problematik der nicht eindeutigen
Zuordnung von Modellierungstokens zur Kategorie Tokens oder Constraints ist einerseits
auf eine der grundlegenden Design-Paradigmen des hier entwickelten Werkzeugs – der
Flexibilität der Abbildung – zurückzuführen, weist aber andererseits auch auf mögliches
Verbesserungspotential hin.
Durch die Flexibilisierung nicht nur der Bindung zwischen physischen Elementen und
digitaler Repräsentation, sondern auch der Verwendung von unterschiedlichen physi-
schen Elementen selbst könnten Modellierungstokens eher Token-artiger werden. Indem
Modellierende eigene physische Elemente (auf ihrem Arbeitskontext) einbringen können,
308
10.5. Einordnung in das Object-Meaning-Kontinuum
könnte die Erfassbarkeit der Bedeutung der physischen Repräsentation unter Umständen
verbessert werden.
10.5. Einordnung in das Object-Meaning-Kontinuum
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Underkoffler und Ishii
(1999), der in Abschnitt 6.4.5 beschrieben wurde.
Abbildung
Das Object-Meaning-Kontinuum ist einer der ersten Ansätze, die die physischen Objekte
eines TUI nicht strikten Kategorien zuordnen, sondern auf einer kontinuierlichen Skala
anordnen. Dabei wird kein kategorischer Unterschied zwischen informationsrepräsentie-
renden Objekten und Werkzeug-Objekten gemacht – sowohl in der Mitte des Kontinu-
ums als auch an den Enden verschwimmen die Grenzen zwischen dem Verständnis eines
Objektes als reine Repräsentation und reinem Werkzeug.
In der Folge werden die Elemente des Werkzeugs in das Kontinuum eingeordnet, wobei
zur einfacheren Anwendbarkeit die entlang des Kontinuums von den Autoren definierten
Ausprägungen verwendet werden.
Die Ausprägung object as noun kommt im Werkzeug nicht zum Einsatz. Keines der
physischen Elemente hat eine direkte Entsprechung in der realen Welt – durch die ge-
forderte Flexibilität der Abbildung ist das auch nicht sinnvoll.
Die Elemente, die zur Modellbildung verwendet werden – also Modellierungstokens
und einbettbare Tokens – sind der Ausprägung object as attribute zuzuordnen, da in die
Farbe bzw. Form der Tokens Bedeutung (nämlich die Semantik des jeweiligen Art von
Tokens) codiert ist. Bei Modellierungstokens ist zu beachten, dass die Zuordnung der
Bedeutung dynamisch zu Laufzeit erfolgt, der physischen Eigenschaft des Objekts also
erst durch die Benutzer konkret Bedeutung zugewiesen wird.
Keinem der Objekte des Werkzeugs ist aufgrund seines Designs die Ausprägung ob-
ject as pure object zuzuweisen. Diese Zuordnung kann jedoch dynamisch bei der Mo-
dellbildung für Modellierungstokens eintreten, wenn die Benutzer den unterschiedlichen
Objektarten keine Bedeutung zuordnen und diese beliebig mit Information belegen.
Die Tokens, die im Werkzeug nicht unmittelbar zur Modellbildung verwendet werden,
verteilen sich zwischen den beiden funktional abstrahierten Ausprägungen des Konti-
nuums. Der Ausprägung Object as Verb sind das Historiensteuerungs-Token und das
Markierungstoken zur Herstellung einer gerichteten Verbindung zuzuordnen. Für das
Historiensteuerungs-Token gilt dies, da dessen Drehbewegung zur zeitliche Navigation
auf die Bewegungen eines Uhrzeigers abbildbar ist. Das Markierungstoken zur Herstel-
lung einer gerichteten Verbindung weist eine Pfeilspitze als Grundfläche auf, wodurch
309
10.6. Betrachtung im Lichte des MCRpd-Modells
eine physische Eigenschaft Hinweise auf die Funktion des Tokens gibt (hier allerdings
grenzwertig, da die dreieckige Grundfläche nicht eindeutig als Pfeilspitze zu erkennen
ist). Die übrigen Tokens sind eher im Bereich des object as reconfigurable tool anzusie-
deln, da ihrer äußere Form oder andere physische Eigenschaften keine Hinweise auf deren
Funktionalität geben. Dies gilt für die allgemeinen Markierungstokens, das Snaphshot-
Token und das Wiederherstellungs-Token.
Einen Spezialfall bildet das Löschtoken, das mit dem Radiergummi als Repräsentati-
on eine object as verb-Einordnung suggeriert (Radiergummi zum direkten „Ausradieren“
von Verbindungen), tatsächlich das System aber lediglich in einen Löschmodus versetzt,
in dem Verbindungen mittels anderer Interaktionsabläufe gelöscht werden können. Hin-
sichtlich seiner tatsächlichen Verwendung ist das Löschtoken also als object as reconfi-
gurable tool zu klassifizieren.
Bewertung
Das von den Autoren vorgeschlagene Kontinuum eignet sich um die Elemente eines TUI
hinsichtlich deren Bedeutung und Verwendung einzuordnen. Diese Einordnung kann
nützlich sein um Elemente zu identifizieren, deren tatsächliche Verwendung im TUI
nicht mit der wahrgenommenen Bedeutung übereinstimmt. Dazu müssen die Elemente
unabhängig von der konkreten Implementierung klassifiziert werden (ggf. von nicht am
Design und der Entwicklung beteiligten Personen) und das Ergebnis der umgesetzten
Funktionalität gegenübergestellt werden.
Für das hier vorgestellte Werkzeug ist eine derartige Diskrepanz wie oben bereits
beschrieben am Löschtoken zu erkennen. Dieses suggeriert eine Verwendbarkeit im Sinne
von object as verb, setzt aber tatsächlich die augenscheinliche Funktion (Löschen) nicht
um (bzw. ist auf eine andere Funktion – Löschmodus aktivieren – abgebildet) und ist
deshalb lediglich als object as reconfigurable tool einzuordnen. Eine „Aufwertung“ des
Löschtokens im Sinne einer Hinterlegung mit der tatsächlichen Lösch-Funkton trägt
eine erwartungskonforme Verwendbarkeit eher sicherstellen und so zur Verbesserung des
Gesamtsystems bei.
10.6. Betrachtung im Lichte des MCRpd-Modells
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Ullmer und Ishii
(2000), der in Abschnitt 6.4.6 beschrieben wurde.
310
10.6. Betrachtung im Lichte des MCRpd-Modells
Abbildung
Wird das erstellte Werkzeug in seiner Gesamtheit dem MCRpd-Modell gegenüberge-
stellt, so ist erkennbar, dass die Eigenschaften des Werkzeugs nicht den Anforderungen
des MCRpd-Modells an ein Tangible User Interface genügen. Das Werkzeug verfügt über
einen Ausgabekanal – den Bildschirm – der nicht an die physische Repräsentation gekop-
pelt ist. Bei differenzierter Betrachtung ist eine vollständige Einordnung jedoch möglich.
All jene Interaktionen, die mit der eigentlichen Modellierung zusammenhängen, genügen
den Anforderungen des MCRpd-Modells ohne Einschränkungen. Die Manipulation des
Model (im MCRpd-Modell) erfolgt über die Tischoberfläche, die gleichzeitig dazu ver-
wendet wird, den Systemzustand zu manifestieren. Dem MCRpd-Modell laufen offenbar
jene Interaktionsabläufe entgegen, die den sekundären Ausgabekanal einbeziehen. Dabei
sind zwei Fälle zu unterscheiden. Bei der Einbettung von Information in Modellelemente
wird die sekundäre Oberfläche zur Auswahl der anzubindenden Ressource und damit als
GUI benutzt. Eine Einordnung in das MCRpd-Modell ist hier damit nicht möglich. Bei
der Betrachtung der Modellierungshistorie wird die sekundäre Oberfläche als alleiniges
Ausgabemedium benutzt, der Systemzustand wird durch das runde Navigationstoken auf
der Oberfläche beeinflusst. Dies verletzt grundsätzlich den Aufbau des MCRpd-Modells.
Betrachtet man jedoch die daraus abgeleiteten Kern-Charakteristika von TUIs, so
kann festgestellt werden, dass diese dennoch nicht verletzt sind. Das in Frage zu stellende
Charakteristikum ist jenes mit der Forderung nach Koppelung zwischen der physischen
Repräsentation des Models (REP-P) und der intangiblen, digitalen Manifestation von
Modellaspekten in der realen Welt (REP-D). Die Autoren fordern von dem Zusammen-
hang zwischen REP-P und REP-D jedoch ausschließlich, dass er „perceptually coupled“
sein müsse, die Koppelung also von den Benutzern als solche wahrgenommen werden
müsse. Betrachtet man das runde Navigationstoken als REP-P und die Ausgabe am se-
kundären Ausgabekanal als REP-D, so ist diese Koppelung feststellbar, da sich REP-D
immer in direkter Abhängigkeit von REP-P verändert. Insofern ist das MCRpd-Modell
nicht verletzt, das Werkzeug weist die von den Autoren als Kern-Charakteristika von
Tangible User Interfaces bezeichneten Eigenschaften auf.
Hinsichtlich der Kategorien von TUIs, die von den Autoren festgelegt werden, ist
das System der Kategorie relational zuzuordnen. Das hier vorgestellte Werkzeug ist
nicht spatial, da die Position der verwendeten Tokens relativ zum Referenzrahmen (der
Tischoberfläche) keine spezifische Bedeutung haben. Die Bedeutung ist viel mehr in den
Beziehungen der Tokens untereinander codiert, was wiederum für ein relationales System
spricht. Gleichzeitig kann damit die Kategorie associative ausgeschlossen werden, da in
Systemen dieser Art keine Beziehungen zwischen Tokens berücksichtigt werden. Da die
Beziehungen zwischen Tokens nur digital und nicht physisch abgebildet werden, ist die
Bedingung für ein konstruierendes System nicht erfüllt. Constructive ist das Werkzeug
dann, wenn der Modellzustand vollständig durch physische Elemente und Verbindungen
abgebildet ist.
311
10.7. Einordnung in den Tokens+Constraints Kontext
Bewertung
Das MCRpd-Modell ist ein im Vergleich zu anderen Ansätzen eher abstraktes, konzep-
tuelles Modell zur Beschreibung eines Tangible User Interfaces. Trotzdem – oder auch
deswegen – eignet es sich gut zur Reflexion der Eigenschaften eines TUIs bzw. zur Prü-
fung der Konsistenz der vorgesehenen Benutzerinteraktionen.
Das Werkzeug konnte in die Logik des Modells eingeordnet werden, wobei bei der
Beschreibung der Interaktion zur Steuerung der Modellierungshistorie verstärkter Argu-
mentationsbedarf herrschte. Dies kann auf eine möglicherweise zu schwache Kopplung
zwischen REP-P und REP-D hinweisen. Tatsächlich wird bei der Kontrolle der Model-
lierungshistorie auf der Tischoberfläche kein Feedback ausgegeben, ob das Steuerungs-
Token erkannt wurde und in welchem Zustand es sich aktuell befindet. Die Kopplung
kann etwa in Form einer Darstellung des aktuell dargestellten Zeitpunkts in der Model-
lierungshistorie rund um das Kontroll-Token angezeigt werden. Dies würde die Kopplung
zwischen den beiden Komponenten der Repräsentation verstärken.
10.7. Einordnung in den Tokens+Constraints Kontext
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Ullmer et al. (2005),
der in Abschnitt 6.4.7 beschrieben wurde.
Einordnung
Eine unmittelbare Einordnung des hier vorgestelltenWerkzeugs in den Tokens+Constraints-
Ansatz ist nicht möglich, da einerseits kein allgemeines Schema zur Betrachtung vorge-
schlagen wird und das Werkzeug seiner Konzeption nach nicht dem Verständnis eines
Tokens+Constraints-System nach Ullmer et al. (2005) entspricht. Dazu müsste es physi-
sche Constraints aufweisen, die den Interaktionsraum der informationstragenden Tokens
physisch einschränken. Das einzige nach dieser Definition identifizierbare Constraint des
Werkzeugs ist der aktive Bereich der Tischoberfläche, die den Modellierungsraum be-
schränkt. Diese Einschränkung ist aber im Vergleich zu den Beispielen für Constraints,
die die Autoren angeben, eher wenig strikt und lässt viel Interaktionsraum.
Am ehesten ist das vorliegende System als eine „interactive surface“ mit Aspekten ei-
ner „constructive assembly“ zu klassifizieren. Die Qualifikation als „interactive surface“
ist ob der Interaktion mit physischen Blöcken auf einer digital augmentierten Oberfläche
naheliegend. „Constructive assembly“-Aspekte sind im Bereich der Einbettung von infor-
mationstragenden Tokens in Modellierungs-Tokens zu finden. Die Zuordnung wird dabei
durch das Hineinlegen eines Tokens in ein anderes ausgedrückt, wodurch die konkrete
Semantik in der Beziehung zwischen den beiden Tokens abgebildet ist. Generell wird
die Semantik des abzubildenden Modells in der räumlichen und logischen Konfigurati-
312
10.7. Einordnung in den Tokens+Constraints Kontext
on der Modellierungs-Tokens zueinander abgebildet, was ebenfalls einem „constructive
assembly“-Aspekt entspricht.
Nicht unmittelbar in Zusammenhang mit dem Tokens+Constraints-Ansatz stehen die
fünf Fragen von Bellotti et al. (2002), die beim Design einer Benutzungsschnittstelle
berücksichtigt werden sollten. In Ullmer et al. (2005) werden diese Fragen für den dort
vorgestellten Ansatz beantwortet, an dieser Stelle sollen sie im Lichte des hier vorge-
stellten Systems betrachtet werden.
Address Das System interpretiert alle Interaktionen, die mit Modellierungs- oder Werk-
zeugtokens unmittelbar auf der Tischoberfläche ausgeführt werden, als an es ge-
richtet. Andere Interaktionen werden ignoriert und können auch technisch nicht
erfasst werden.
Attention Der Einsatz jedes Tokens löst unmittelbar eine Reaktion auf den Ausgabe-
kanälen des Systems aus. Benutzer erhalten also direktes Feedback auf erkannte
Interaktionen. Eine Verzögerung zwischen Ein- und Ausgabe tritt lediglich bei der
Markierung von Elementen auf, die zur Robustheit gegen Fehlerkennungen erst
erfasst wird, wenn das Eingabe-Token länger als 500 ms vorhanden ist.
Action Befehle an das System können generell an einem beliebigen Punkt der Ober-
fläche abgesetzt werden, sofern es sich um allgemeine Kommandos handelt, die
das Gesamtsystem betreffen. Befehle, die einem bestimmten Objekt zuzuordnen
sind (z.B. Auswahl oder Verbindungsherstellung) werden durch räumliche Nähe
zugeordnet.
Alignment Nach Ausführung einer Aktion befindet sich das System immer in einem
stabilen Zustand, anhand dessen Visualisierung die Benutzer erkennen können, ob
die intendierte Aktion korrekt erkannt und ausgeführt wurde.
Accident Missverständnisse zwischen System und Benutzern können auf unterschiedli-
che Arten aufgelöst werden. Die erste Möglichkeit ist, Missverständnisse explizit
durch die gegenteilige Interaktion rückgängig gemacht werden (z.B. Löschen ei-
ner versehentlich hergestellten Verbindung). Mittels der Wiederherstellung eines
gespeicherten Systemzustandes kann ein Missverständnis ebenfalls korrigiert wer-
den.
Bewertung
Der Tokens+Constraints-Ansatz ermöglicht in der vorliegenden Form keine direkte Ab-
bildung des Werkzeugs auf seine Konzepte. Wertvoller für die Betrachtung sind an dieser
Stelle die Ordnungsschemata und Fragestellungen, die von Ullmer et al. (2005) im Kon-
text des Ansatzes erarbeitet bzw. beantwortet werden.
Von Interesse sind insbesondere die fünf Fragen für das Design von Benutzungsschnitt-
stellen, die von (Bellotti et al., 2002) gestellt werden. Bei der Beantwortung dieser Fragen
313
10.8. Einordnung in das Framework nach Koleva et al.
für das vorliegende System ist durchaus Verbesserungspotential zu identifizieren. Am of-
fensichtlichsten zeigt sich das am Beispiel des Feedbacks des Systems an Benutzer über
einen erkannten Interaktionswunsch. Hier kommt es beim Einsatz des Markierungsto-
kens technisch bedingt zu Verzögerungen, die – ob der ansonsten unmittelbaren Reak-
tion des Systems – Unsicherheit bei den Benutzern erzeugen kann. Auch die Auflösung
von Missverständnissen ist im Moment sub-optimal gelöst, da in jedem Fall entweder
Zeitverlust auftritt oder mindestens zwei Interaktionsschritte zur Korrektur einer Fehl-
interpretation notwendig sind. Hier ist unter Umständen die Einführung einer expliziten
„Undo“-Funktionalität sinnvoll.
10.8. Einordnung in das Framework nach Koleva et al.
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Koleva et al. (2003),
der in Abschnitt 6.4.8 beschrieben wurde.
Abbildung
Das Framework eignet sich zur Einordnung einzelner Aspekte eines Tangible User Inter-
faces. Aufgrund seiner Ausrichtung auf die Brücke zwischen realer und digitaler Welt ist
es insbesondere für die Betrachtung der eingesetzten Tokens und deren Verwendung zur
Repräsentation und Manipulation des Systemzustandes geeignet. In Tabelle 10.1 wer-
den die Tokens in die Kategorien entlang des Kohärenz-Kontinuums eingeordnet und
hinsichtlich der Eigenschaften ihrer Brückenfunktion in die digitale Welt betrachtet.
Die Kardinalität wurde hier nicht gesondert betrachtet, da diese im vorliegenden Sys-
tem immer 1:1 ist, also eine eindeutige Zuordnung zwischen realem Objekt und digitaler
Repräsentation gegeben ist. Im Übrigen verzichten auch Koleva et al. (2003) auf die Ein-
ordnung in diese Kategorie, da sie generell nur geringe Unterscheidungskraft aufweist.
Hinsichtlich der „Source of Link“, die in der Tabelle ebenfalls nicht angegeben ist (und
von den Autoren ebenfalls nicht verwendet wird), ist anzumerken, dass das Werkzeug
durchaus einen Aspekt aufweist, bei dem der „Source of Link“ die digitale Welt ist. Im
Rahmen der Wiederherstellungsunterstützung gibt das System Anweisungen zur Mani-
pulation der realen Welt, wodurch sich der Informationsfluss umkehrt. Da jedoch kein
physisches Element direkt manipuliert wird, ist eine Einordnung in das oben angeführte
Schema nicht möglich (der Link ist lediglich indirekt vorhanden).
Bewertung
Das von Koleva et al. (2003) vorgeschlagene Framework ermöglicht die Klassifikation ei-
nes Tangible Interface durch die Beurteilung der Stärke der Bindung zwischen digitaler
314
10.8. Einordnung in das Framework nach Koleva et al.
Tabelle 10.1.: Beurteilung des Werkzeugs hinsichtlich des Degree of Coherence
Element Kategorie Trans-
for-
mation
Sensing of
Interaction
Konfig-
urierbar-
keit
Lebens-
dauer
Auto-
nomie
Modell-
ierungs-
token
Proxy lit. X-Y-Position
und Rotation,
Öffnungssta-
tus
fixiert temp. abh.
einbett-
bares
Token
Identifier transf. Präsenz, Con-
tainer
fixiert temp. unabh.
Mark-
ierungs-
token
Specialized
Tool
transf. X-Y-Position fixiert temp. unabh.
Löschtoken Projection transf. Präsenz fixiert perm. unabh.
Snapshot-
token
Specialized
Tool
transf. Präsenz fixiert perm. unabh.
Historien-
navigations-
token
Specialized
Tool
transf. Rotation fixiert perm. unabh.
Wieder-
herstellungs-
token
Specialized
Tool
transf. Präsenz fixiert perm. unabh.
lit. . . . literally, transf. . . . transformed, konfig. . . . konfigurierbar, temp. . . . temporär,
perm. . . . permanent, abh. . . . abhängig, unabh. . . . unabhängig
315
10.9. Spezifikation des TAC-Schemas nach Shaer et al.
und realer Welt. Die Autoren nehmen damit eine zum Zeitpunkt der Publikation neue
Perspektive ein, der bis dato noch keine große Aufmerksamkeit geschenkt wurde. Durch
die Vernachlässigung der Interaktion am Tangible User Interface bildet eine Analyse
unter Einsatz der im Framework vorgeschlagenen Kategorien nur einen Teilaspekt des
Gesamtsystems ab. Trotz dieser Einschränkung bietet das Framework ob seiner detail-
lierten Betrachtung der Eigenschaften der Verknüpfung von physischen Objekten mit
digitaler Information potentiell einen Mehrwert dar beim Design oder der Analyse von
TUIs.
Insbesondere ermöglicht das Framework nicht ausgeschöpftes Kohärenz-Potential zu
identifizieren. Im konkreten Fall des hier vorgestellten Werkzeugs lässt sich das am Bei-
spiel des Löschtokens zeigen. Dieses physisch durch einen Radiergummi repräsentierte
Token wird im Moment lediglich als Schalter verwendet. Das System wird in den Lösch-
modus versetzt, sobald das Token auf der Oberfläche erkannt wird. Das Token ist als
Projection einzuordnen, die das Token mit der Information des aktivierten oder deakti-
vierten Löschmodus verbindet. Obwohl hoch kohärent, ist das Token trotzdem subopti-
mal eingesetzt, da es in der Praxis als Werkzeug wahrgenommen wird, das zum Löschen
einer spezifischen Verbindung verwendet werden kann (Specialized Tool). An diesem
Beispiel lassen sich zwei Aspekte zeigen, die bei der Verwendung des Frameworks be-
achtet werden müssen. Zum einen ist hohe Kohärenz nicht für jeden Anwendungsfall
erstrebenswert, da bei Werkzeugen im Allgemeinen eine nicht permanente Bindung ver-
wendet wird. Zum anderen zeigt sich die Unvollständigkeit der Analyse mittels dem
Framework, da die Metaphorik des physischen Elements, also seine Bedeutung in der
Interaktion, nicht berücksichtigt wird. Beide Aspekte – Kohärenz und Metaphorik – be-
rücksichtigt erst Fishkin (2004) in der von ihm vorgeschlagenen Taxonomie (siehe dazu
die Abschnitte 6.4.11 und 10.11).
10.9. Spezifikation des TAC-Schemas nach Shaer et al.
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Shaer et al. (2004),
der in Abschnitt 6.4.9 beschrieben wurde.
Abbildung
Das „Token and Constraints“-Schema (TAC) erlaubt es, ein Tangible Interface sowohl
hinsichtliche dessen Struktur als auch dessen Verwendung zu beschreiben. In den Tabel-
len 10.2 und 10.3 wird das Schema auf das hier vorgestellte Werkzeug angewandt.
Jene Interaktionsabläufe, bei denen das System die Aktionen der Benutzer anleitet
(z.B. bei der Unterstützung der Wiederherstellung) können in diesem Schema nicht ab-
316
10.9. Spezifikation des TAC-Schemas nach Shaer et al.
Tabelle 10.2.: Spezifikation des Werkzeug mittels TAC-Schema – Teil 1
TAC Struktur Verhalten
Token Constraint Variable Aktion Feedback
1
Modell-
ierungs-
Oberfläche Modell-
element
Auflegen Modellelement
anzeigen
token Bewegen Modellelement
bewegen
Entfernen Modellelement
entfernen
2 einbett-
bares Token
Modell-
ierungs-
Modell-
element
Hinein-
legen
Daten einbetten
token Heraus-
nehmen
Container-
Kopplung
aufheben
3 einbett-
bares Token
Regist-
rierungs-
kamera
einbett-
bares
Modell-
element
Vor die
Kamera
halten
ungebunden:
Datenbindung
auslösen; gebun-
den: Gebundene
Daten anzeigen
4 Markierungs-
token
Modell-
ierungs-
token
Modell-
element
Neben
Modell-
ierungs-
token
platzieren
Markierung an-
zeigen
5 Markierungs-
token
Modell-
ierungs-
token,
markiertes
Modell-
ierungs-
token
Verbindung Neben
unmar-
kiertem
Modell-
ierungs-
token
platzieren
Verbindung her-
stellen und an-
zeigen
6 Tastatur markiertes
Modell-
ierungs-
token
Modell-
element
Tastatur-
eingabe
Benennung des
markierten Mo-
dellelements
317
10.9. Spezifikation des TAC-Schemas nach Shaer et al.
Tabelle 10.3.: Spezifikation des Werkzeug mittels TAC-Schema – Teil 2
TAC Struktur Verhalten
Token Constraint Variable Aktion Feedback
7 Tastatur Verbind-
ungen,
kein mar-
kiertes
Modell-
ierungs-
token
zuletzt
herge-
stellte
Verbin-
dung
Tastatur-
eingabe
Benennung
der zuletzt
hergestellten
Verbindung
8 Löschtoken Oberfläche Modell-
element
Auflegen Löschmodus ak-
tivieren
Entfernen Löschmodus de-
aktivieren
9 Snapshot-
token
Oberfläche Modell-
ierungs-
historie
Auflegen Aktuellen Mo-
dellzustand
sichern, Blitz
anzeigen
10
Historien-
kontroll-
token
Oberfläche Modell-
ierungs-
historie
Auflegen Letzten ge-
speicherten
Snapshot anzei-
gen
Drehen Durch die ge-
speicherten
Snapshots navi-
gieren
Entfernen Aktuelles Modell
anzeigen
11 Wieder-
herstellungs-
token
Oberfläche,
vorhan-
denes
Historien-
kontroll-
token
Modell-
zustand
Auflegen Aktuell ange-
zeigten Snap-
shot wiederher-
stellen
318
10.10. Einordnung in die Kategorien von TUI-Anwendungen
gebildet werden, da die Constraints keine physischen Objekte sondern lediglich projizierte
Information sind.
Bewertung
Das TAC-Schema eignet sich für eine umfassende Spezifikation der Struktur und des
Verhaltens eines Tangible User Interfaces. Das vorgeschlagene Schema geht jedoch (wie
die meisten anderen Ansätze auch) davon aus, dass das TUI vor allem zur Informati-
onseingabe verwendet wird und dass sich der Systemzustand und dessen Manifestierung
am Interface in Abhängigkeit dieser Eingaben ändern. Nicht abbildbar sind Interaktio-
nen, die vom System ausgelöst bzw. kontrolliert werden, bei denen also die Variable das
aktive und nicht das manipulierte Element ist (im Gegensatz zum zuvor vorgestellten
Degree of Coherence-Ansatz der mit der Source of Link-Eigenschaft explizit auf diesen
Aspekt eingeht – siehe Abschnitt 6.4.8).
Mit Ausnahme dieser Einschränkung eignet sich das TAC-Schema weitgehend für die
Spezifikation des hier vorgeschlagenen Werkzeuges. Lediglich die Wiederherstellungs-
unterstützung kann nicht abgebildet werden, da sie vom System gesteuert wird. Beim
Einsatz zur Spezifikation eines TUI oder bei der Untersuchung desselben hinsichtlich
möglichem Verbesserungspotential ist vor allem auf die möglichen Constraints eines
Tokens zu achten. Dabei ist es hilfreich, unterschiedliche Constraints bezüglich der von
ihnen vorgegebenen oder durch sie ermöglichten Aktionen zu betrachten. Als Beispiel im
konkreten System kann wiederum das Löschtoken verwendet werden. Dieses wird in der
aktuellen Implementierung mit dem Constraint „Oberfläche“ verwendet, um den Lösch-
modus zu aktivieren (wenn es aufgelegt wird) bzw. zu deaktivieren (wenn es entfernt
wird). Setzt man das Löschtoken nun in ein TAC mit dem Constraint „Verbindung“,
ergeben sich neue Möglichkeiten der Interaktion. Ein Aufsetzen des Löschtokens auf eine
Verbindung könnte diese unmittelbar löschen und würde so den notwendigen Interakti-
onsablauf vereinfachen. Das mit diesem Constraint auch die Metapher des verwendeten
Radiergummis sinnbringend verwendet wird, ist ein Nebeneffekt, der jedoch im TAC-
Schema nicht repräsentiert wird. Vielmehr ist die Metaphorik Ausgangspunkt für eine
sinnvolle und verständliche Auswahl möglicher Constraints für ein Token.
10.10. Einordnung in die Kategorien von
TUI-Anwendungen
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Klemmer et al. (2004),
der in Abschnitt 6.4.10 beschrieben wurde.
319
10.11. Einordnung in die Taxonomie von Fishkin
Abbildung
Das Werkzeug weist Aspekte einer spatial application auf, da es die Platzierung von phy-
sischen Elementen auf einer Oberfläche als Grundlage der Interaktion mit dem System
heranzieht. Da aber die Beziehung zwischen den Elementen sowohl für die Informati-
onsrepräsentation als auch für die Steuerung des Systems wesentlich ist, ist auch eine
Einordnung in die Kategorie topological application möglich. Letzendlich referenzieren
manche physische Elemente auch auf digitale Information, was das Kriterium für die
Einordnung in die Kategorie associative application ist. Lediglich die Kategorie Forms
trifft nicht auf das hier vorgestellte Werkzeug zu.
Bewertung
Das hier vorgestellte Werkzeug lässt sich nicht eindeutig einer der von Klemmer et al.
(2004) identifizierten Applikations-Kategorien zuordnen. Die (von den Autoren als sol-
che bezeichnete) „Taxonomie“ eignet sich demnach nicht, um komplexere Systeme zu
klassifizieren, die sowohl Informationsrepräsentation als auch Systemsteuerung durch
physische Elemente abwickeln.
10.11. Einordnung in die Taxonomie von Fishkin
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Fishkin (2004), der
in Abschnitt 6.4.11 beschrieben wurde.
Abbildung
Das in dieser Arbeit entwickelte Werkzeug überspannt aufgrund seiner vielfältigen In-
teraktionsmöglichkeiten mehrere Ausprägungen in beiden von Fishkin vorgeschlagenen
Dimensionen zur Klassifikation von Tangible Interfaces. Um eine umfassende und ins
Detail gehende Einordnung vornehmen zu können, werden deshalb an dieser Stelle die
Einzelaspekte des Systems betrachtet und eingeordnet. Während die Dimension „Em-
bodiment“ bereits in Kapitel 8 betrachtet wurde um eine strukturierte Zuordnung der
Ausgabekanäle vornehmen zu können, werden hier die einzelnen Funktionalitäten des
Systems (siehe Abschnitt 7.3) jeweils beiden Dimensionen zugeordnet (siehe Tabelle
10.4)
Beim Platzieren und Benennen von Modellelementen ist die Benennung auf zwei Ar-
ten möglich, die unterschiedlich in die Taxonomie einzuordnen sind. Bei Benennung
mittels Auswahl und Tastatur ist durch die Projektion der Benennung die Embodiment-
Ausprägung „nearby“ zu wählen. Der Vorgang der Auswahl und Benennung kann als
320
10.11. Einordnung in die Taxonomie von Fishkin
Tabelle 10.4.: Einordnung des Systems in die Taxonomie nach Fishkin
Embodiment Metaphor
Platzieren und Benennen von Mo-
dellelementen
distant, nearby
(Tastatur), full
(Haftnotiz)
verb (Tastatur),
verb + noun
(Haftnotiz)
Erstellen von Verbindern nearby verb bis
noun+verb
(Werkzeug-
tokens), verb
(räumliche
Nähe)
Löschen von Verbindern environmental
bis nearby
noun
Einbetten von Information full noun + verb
Abrufen von Information distant verb
Erstellen von Snapshots environmental
bis nearby
none
Navigation in der Modell-Historie distant verb
Wiederherstellen eines Modell-
Zustandes
nearby noun + verb
321
10.11. Einordnung in die Taxonomie von Fishkin
analog zur realen Welt gesehen werden, die eingesetzten Werkzeuge sind aber generi-
scher Natur – Metaphor ist also als „verb“ zu klassifizieren. Bei der Benennung mittels
Haftnotiz ist durch die unmittelbar auf den Tokens angebrachten Benennungen Embo-
diment „full“. Der Vorgang des Beschriftens wird analog zur realen Welt durchgeführt,
auch die Informationsträger (Haftnotizen) entsprechen jenen der realen Welt, Metaphor
ist also „verb + noun“, wobei der notwendige Vorgang der expliziten Erfassung einer
Beschriftung durch das System eine Klassifikation „full“ verhindert und sogar die Ein-
stufung „noun + verb“ etwas abschwächt (keine Analogie des Vorgangs zur realen Welt).
Zur Herstellung von Verbindern existieren ebenfalls zwei Möglichkeiten. In beiden Fäl-
len ist durch die Projektion der Verbindung die Ausprägung in Embodiment „nearby“,
sie unterscheiden sich jedoch hinsichtlich „Metaphor“. Bei der Verwendung von Werk-
zeugtokens ist der Vorgang der Auswahl der Endpunkte analog zur realen Welt zu sehen
und somit als „verb“ einzustufen. Die Verwendung von spezifischen Werkzeugtokens zur
Herstellung gerichteter Verbinder zeigt sogar Züge von „noun + verb“, da die durch das
Token dargestellte Pfeilspitze eine Analogie zur realen Welt bildet.
Das Löschen von Verbindern wird durch das Lösch-Token vorgenommen. Dieses ist
durch einen Radiergummi symbolisiert, der jedoch nicht als solche eingesetzt wird, son-
dern das System nur in einen Löschmodus versetzt. Die Klassifikation in Metaphor ist
demnach „noun“. Die Visualisierung des Löschzustandes erfolgt unspezifisch durch die
Umfärbung der gesamten Tischoberfläche, womit ein Embodiment von „nearby“ oder
„environmental“ (aufgrund der Unspezifität) gerechtfertigt ist.
Einbetten von Information erfolgt durch die Verwendung der Modellierungstokens als
Container und Hineinlegen von kleineren Tokens. Embodiment ist in diesem Fall „full“,
da die Einbettung physisch nachvollzogen wird. Metaphor ist durch die Analogie des
„Hineinlegens“ von Information in „Container“ in die Ausprägung „noun + verb“ ein-
zuordnen.
Das Abrufen von Information wird über den sekundären Ausgabekanal abgewickelt und
ist daher in Embodiment als „distant“ einzuordnen. Der Vorgang des Herausnehmens
von Information aus einem Container existiert analog zur realen Welt, das bei diesem
Vorgang im Zentrum stehende Objekt, das einbettbare Token, ist jedoch generisch und
weist nicht auf die Art der eingebetteten Information hin. Die Interaktion ist daher als
„verb“ in Metaphor einzuordnen.
Beim Erstellen von Snapshots wird die gesamte Tischoberfläche als Feedbackkanal
genutzt. Insofern ist Embodiment wie im Falle des Löschens von Verbindern im Bereich
„environmental“ bis „nearby“ anzusiedeln. Das Snapshot-Token selbst ist ein generisches
Objekt, das keine Analogie zur realen Welt aufweist. Metaphor ist daher „none“.
Die Navigation in der Modell-Hierarchie erfolgt mit dem runden Navigations-Token.
Zur Ausgabe der gespeicherten Modell-Zustände wird der sekundäre Ausgabekanal ver-
wendet. Embodiment ist deshalb „distant“. Metaphor beschränkt sich auf „verb“, da der
322
10.11. Einordnung in die Taxonomie von Fishkin
Drehvorgang zur Navigation analog zum Einstellen einer Uhr erfolgt, das Token selbst
aber bis auf seine runde Form generisch ist.
Das Wiederherstellen eines Modellzustandes erfolgt durch spezifische Anweisungen auf
der Modellierungsoberfläche. Embodiment ist also als „nearby“ einzustufen. Der Vor-
gang der Wiederherstellung erfolgt durch Verschieben der Modellierungstokens, was im
Wesentlichen analog zur realen Welt abläuft. Da unmittelbar die Objekte manipuliert
werden, kann Metaphor als „noun + verb“ eingestuft werden.
Bewertung
Die Taxonomie nach Fishkin ermöglicht eine strukturierte Erfassung einzelner Aspekte
eines Tangible User Interfaces. Die aussagekräftige Einordnung eines Gesamtsystems ist
nur bei einfachen TUIs möglich, komplexe, mit vielen Interaktionsmöglichkeiten ausge-
stattete Systeme tendieren dazu, einen großen Bereich der Taxonomie abzudecken. Für
die detaillierte Betrachtung eines komplexen Gesamtsystems ist die Taxonomie dennoch
geeignet, da aus den einzelnen Teileinordnungen für den jeweiligen Anwendungsfall ggf.
Verbesserungspotentiale abgeleitet werden können. Zudem zeigt die Betrachtung des hier
entwickelten Systems, dass ein die Taxonomie breit abdeckendes Gesamtsystem potenti-
ell Inkonsistenzen im Interaktionsdesign aufweist bzw. dass in derartigen Fällen mehrere
unterschiedliche Interaktionsparadigmen vermischt wurden. Vor allem „Ausreißer“ aus
einem vorwiegend einheitlichen Gesamtbild weisen auf die Notwendigkeit der Betrach-
tung hinsichtlich eines möglichen Redesigns wert.
Konkret können diese Vermutungen im vorliegenden System vor allem an der Kon-
zeption des Lösch-Tokens und des Snapshot-Tokens festgemacht werden. Der Großteil
der Interaktionen mit dem System beinhaltet in der Dimension Metaphor den „verb“-
Aspekt (zu etwa gleichen Teilen ausschließlich und in der Kombination mit „noun“). Die
Funktionalitäten, die die beiden erwähnten Tokens einbeziehen, laufen diesem Trend
entgegen und zeigen in Metaphor die Ausprägung „noun“ bzw. „none“. Tatsächlich zeigt
sich in der Praxis, dass die Anwendbarkeit dieser Tokens von Benutzern missverstan-
den bzw. nicht verstanden wird. Ein Redesign dieser Tokens mit expliziterer bzw. eher
aktivitätsorientierter Metaphor ist deshalb untersuchenswert.
Zusammenfassend ist die Taxonomie vor allem im Zusammenhang mit der Sicherung
von konsistenter Interaktion an der Benutzungsschnittstelle sinnvoll anwendbar. Der
Mehrwert des Ansatzes zeigt sich hier nicht so sehr in den absoluten Ausprägungen auf
den beiden Dimensionen, sondern vielmehr in den relativen Unterschieden, die zwischen
den einzelnen Teilen des Tangible User Interfaces auftreten.
323
10.12. Betrachtung im Lichte der Retrospektive von Ishii
10.12. Betrachtung im Lichte der Retrospektive von
Ishii
Grundlage der Einordnung in diesem Abschnitt ist der Ansatz von Ishii (2008), der in
Abschnitt 6.4.12 beschrieben wurde.
Einordnung
Ishii (2008) spricht in seiner umfassenden Darstellung der Entwicklung des Forschungsge-
biets „Tangible User Interfaces“ eine Vielzahl von Aspekten an, die der Konzeptbildung
im Gebiet dienlich sind. Er spart jedoch Ansätze aus, die analytisch oder von Seiten der
Spezifikation an TUIs herangehen. Trotzdem ist eine Einordnung in die unterschiedlichen
angesprochenen Aspekte zum Teil möglich. Ein Großteil der Ergebnisse wurden ob des
zusammenfassenden Charakters des Artikels bereits in früheren Abschnitten bearbeitet
und argumentiert. Diese werden hier nur noch zusammenfassen erwähnt.
Für die Einordnung des Systems in das MCRit-Framework sei an dieser Stelle auf die
bis auf die veränderte Nomenklatur identische Betrachtung des MCRpd-Frameworks in
Abschnitt 10.6 verwiesen.
Hinsichtlich der Kategorisierung von TUIs ist das System identisch zu den in Abschnitt
10.7 Kategorien einzuordnen. Die bei Ishii (2008) angegebenen Kategorien stellen ledig-
lich eine Erweiterung (bzw. Verbreiterung des Betrachtungsbereichs) der von Ullmer
et al. (2005) identifizierten Kategorien dar. Die zusätzlichen Kategorien haben jedoch
für das hier vorgestellte Werkzeug keine Relevanz, so dass eine weiterführende Neube-
wertung unterbleiben kann.
Die von Ishii angeführten grundlegenden Eigenschaften und Merkmale eines TUI er-
möglichen in Ermangelung der Angabe von konkreten Merkmalsausprägungen oder Be-
urteilungskriterien keine Einordnung des Werkzeugs. Die angegebenen Aspekte über-
schneiden sich jedoch stark mit den Eigenschaften und Merkmalen der in Abschnitt 10.1
und 10.2 betrachteten Ansätze von Fitzmaurice et al. (1995) und Fitzmaurice (1996).
Bewertung
Die umfassende Retrospektive der Entwicklung des Forschungsgebiets der „Tangible User
Interfaces“, die von (Ishii, 2008) vorgenommen wird, ermöglicht einen breiten Blick auf
das aktuelle Feld und identifiziert außerdem nach wie vor offene Forschungs-Punkte. Für
die Beurteilung eines TUI ist die Arbeit so wie die Ansätze, auf denen sie aufbaut und
die sie integriert, nur bedingt geeignet. Dies liegt in der abstrakt-konzeptuell bleibenden
Beschreibung der einzelnen Aspekte begründet, die eine Einordnung nicht ermöglicht.
Detailaspekte eines Systems bleiben unberücksichtigt, Ziel des Artikels ist es nicht, eine
324
10.13. Zusammenfassung
Analyse- oder Spezifikationsframework einzuführen (tatsächlich wird dies als einer der
offenen Forschungspunkte genannt).
Für das Werkzeug können aus oben genannten Gründen aus der Betrachtung im Lichte
dieses Ansatzes keinerlei Potentiale für Verbesserungen abgeleitet werden. Die mögliche
globale Einordnung des Gesamtsystems wurde bereits in anderen Abschnitten auf Basis
der diesem Ansatz zugrunde liegenden Arbeiten vorgenommen und bringt an dieser Stelle
keine neuen Erkenntnisse.
10.13. Zusammenfassung
In diesem Kapitel wurde das hier vorgestellte Werkzeug in die in Abschnitt 6.4 beschrie-
benen Ansätze zur konzeptuellen Betrachtung eines Tangible User Interface eingeordnet.
Damit wurden zwei Zielsetzungen verfolgt. Einerseits sollten die vorgestellten Ansätze
hinsichtlich ihrer grundsätzlichen Eignung zur und Ausdrucksstärke bei der Beschreibung
eines Tangible User Interfaces überprüft werden. Andererseits sollte aus der strukturier-
ten konzeptuellen Betrachtung des Werkzeugs mögliche Inkonsistenzen in Design und
Implementierung identifiziert werden und ggf. daraus Maßnahmen zur Verbesserung des
Werkzeugs abgeleitet werden. Diese beiden Aspekte werden in den folgenden beiden
Abschnitten getrennt betrachtet.
10.13.1. Eignung der konzeptuellen Ansätze zur Beschreibung von
TUIs
Ergänzend zu den in Abschnitt 6.4.13 beschriebenen Ausdrucksstärke der vorgestellten
konzeptuellen Ansätze wird an dieser Stelle auf deren Eignung zur Beschreibung bzw.
Spezifikation von Tangible Interfaces im praktischen Einsatz eingegangen. Auf das Ein-
satzgebiet des strukturieren Vergleichs von TUIs wird hier nicht eingegangen, da dieser
hier mangels verfügbarer Alternativsysteme nicht durchgeführt wurde.
Jene Arbeiten, die in Abschnitt 6.4.13 als „auf das Gesamtsystem fokussierend“ einge-
ordnet wurden, sind für die Beschreibung bzw. Spezifikation von TUIs nur bedingt geeig-
net. Sie sind im Allgemeinen nicht dazu geeignet, auf Spezifika des Systems einzugehen
und bleiben damit zu abstrakt um konkrete Aussagen hinsichtlich der Implementierung
abzuleiten bzw. Verbesserungspotential identifizieren zu können. Einige Arbeiten weisen
darüber hinaus aufgrund ihres Alters eine eher eingeschränktes Verständnis von TUIs
auf und sind deshalb zur Beschreibung von aktuellen Systemen nur mit Einschränkungen
geeignet (z.B. (Fitzmaurice, 1996)).
Manche Arbeiten legen sich hinsichtlich des Referenzrahmens nicht explizit fest, so
dass sie sowohl zu Beschreibung eines Gesamtsystems als auch für die Beschreibung
325
10.13. Zusammenfassung
von Teilaspekten komplexerer Systeme eingesetzt werden können. Zu diesen zählen etwa
(Koleva et al., 2003) und Fishkin (2004).
Die übrigen betrachteten Arbeiten wählen die einzelnen Elemente eines TUI als Be-
zugspunkt und beschreiben das Gesamtsystem als Ensemble von Teilaspekten. Diese
Sichtweise nehmen explizit lediglich (Ullmer et al., 2005) (Abschnitt 10.7) und (Shaer
et al., 2004) (Abschnitt 10.9) ein. Dabei eignet sich der erstgenannte Ansatz nur bedingt
zur detaillieren Beschreibung von TUIs, da die vorgeschlagenen Beschreibungsdimensio-
nen zu abstrakt bzw. wenig detailliert ausfallen.
Für die Spezifikation von TUIs ist retrospektiv der TAC-Ansatz von Shaer et al. (2004)
am besten geeignet. Dieser vereint die Beschreibung von Struktur und Verhalten des
Systems und erlaubt so eine umfassende Spezifikation in einem vorgegebenen Schema.
Zur Beschreibung eines TUI auf Ebene des konzeptuellen Designs bietet sich die Ta-
xonomie für Tangible Interfaces nach Fishkin (2004) an, da diese – basierend auf einem
breiten Verständnis von TUIs – umfassend die grundlegend notwendigen Designent-
scheidungen für TUIs („Embodiment“ und „Metaphor“) anspricht. Die Anwendung der
Taxonomie kann so den Designprozess strukturieren und die Erkennung etwaige Inkon-
sistenzen in der Konzeption bereits vor der Umsetzung ermöglichen (siehe dazu auch
Abschnitt 8 bzw. (Oppl, 2009b)).
10.13.2. Verbesserungspotential für das Werkzeug
Für das Werkzeug selbst konnten im Rahmen der konzeptuellen Einordnung mehrere
Aspekte identifiziert werden, die einer Verbesserung bedürfen oder mögliche Erweite-
rungspunkte aufzeigen. Die konzeptuell begründbaren Schwachpunkte sind:
• die Diskrepanz zwischen durch das verwendete physische Objekt suggerierte Ver-
wendung des Lösch-Tokens und seiner tatsächlichen Funktionalität (begründbar
aus (Underkoffler und Ishii, 1999) – siehe Abschnitt 10.5 –, (Koleva et al., 2003) –
siehe Abschnitt 10.8) –, (Shaer et al., 2004) – siehe Abschnitt 10.9) – und (Fishkin,
2004) – siehe Abschnitt 10.11)
• die schwache Kopplung zwischen physischem Werkzeug und digitaler Repräsenta-
tion bei der Navigation durch die Modellierungshistorie – auf der Oberfläche wird
kein Feedback zur physisch durchgeführten Aktion dargestellt, lediglich der sekun-
däre Ausgabekanal zeigt den Zustand an (aus (Ullmer und Ishii, 2000) – siehe
Abschnitt 10.6)
• das Auftreten von Verzögerungen zwischen physischer Aktion und digitalem Feed-
back (aus (Bellotti et al., 2002) – siehe Abschnitt 10.7)
• das Fehlen einer expliziten, funktional ungebundenen und mittels einer einfachen
Interaktion auszulösenden Undo-Funktion (aus (Bellotti et al., 2002) – siehe Ab-
schnitt 10.7)
326
10.13. Zusammenfassung
• die fehlende Verständlichkeit des Snapshot-Tokens, dessen physische Form keinen
Hinweis auf dessen Funktion liefert (aus (Fishkin, 2004) – siehe Abschnitt 10.11)
Zusätzlich wurden folgende Erweiterungsmöglichkeiten wurden identifiziert:
• eine Erweiterung um funktional explizit belegte physische Interaktionsbereiche am
Werkzeug (trays) um etwa das Anbinden von Information komfortabler zu gestal-
ten („trays“ im Sinne von (Ishii und Ullmer, 1997) – siehe Abschnitt 10.3)
• die Verwendbarkeit frei wählbarer Tokens auch aus der Domäne der Benutzer zu-
sätzlich zu den vorhandenen abstrakten Modellierungs-Tokens (aus (Holmquist
et al., 1999) – siehe Abschnitt 10.4)
Die identifizierten Schwachpunkte wurden auch im Rahmen der in den folgenden Ab-
schnitten beschriebenen empirischen Evaluierung berücksichtigt und hinsichtlich ihres
tatsächliches Auftretens überprüft. Tatsächlich auftretende Schwachstellen wurden zum
Teil auch überarbeitet und einer erneuten Evaluierung unterzogen. Bei diesen Überar-
beitungen wurden jeweils die aus den konzeptuellen Arbeiten ableitbaren Verbesserungs-
maßnahmen als Grundlage herangezogen, so dass auch deren Eignung für die Spezifika-
tion von TUIs einer Beurteilung unterzogen werden kann.
10.13.3. Beitrag zur globalen Zielsetzung
Dieses Kapitel stellt den ersten Schritt zur Prüfung der Effektivität der Unterstützung
von „Articulation Work“ dar und trägt somit zur Beantwortung der Fragestellung 6 („Er-
möglicht das Instrument die effektive Durchführung von expliziter Articulation Work?“)
bei, indem es die zu erwartende Verwendbarkeit des Werkzeugs zur Umsetzung der Me-
thodik im Kontext von „Articulation Work“ auf Basis konzeptueller Überlegungen aus
der Literatur prüft. Die konzeptuelle Basis wurde im Rahmen der Bearbeitung von Fra-
gestellung 5 bereits in Kapitel 6 erfasst.
10.13.4. Weitere Verwendung der Ergebnisse
Die identifizierten Schwachstellen wurden auch im Rahmen der in den folgenden Ab-
schnitten beschriebenen empirischen Evaluierung berücksichtigt und hinsichtlich ihres
tatsächliches Auftretens überprüft. Tatsächlich auftretende Schwachstellen wurden zum
Teil auch überarbeitet und einer erneuten Evaluierung unterzogen. Bei diesen Über-
arbeitungen wurden jeweils die aus den konzeptuellen Arbeiten ableitbaren Verbesse-
rungsmaßnahmen als Grundlage herangezogen. Diese werden in Schlussbetrachtungen
nochmals den empirisch identifizierten verbesserungswürdigen Aspekten des Werkzeugs
gegenüber gestellt. Neben einem Beitrag zur Prüfung der Effizienz ermöglicht diese Ar-
beit dadurch auch eine Einschätzung der Eignung der erfassten konzeptuellen Ansätze
zur Spezifikation bzw. Prüfung von Tangible Interfaces.
327
11. Überblick über die empirische
Untersuchung
In diesem Kapitel wird ein Überblick über die in dieser Arbeit durchgeführte empirische
Untersuchung gegeben. Dabei wird auf die einzelnen zu untersuchenden Aspekte, deren
theoretische Grundlagen und die Durchführung der Untersuchung eingegangen. Abbil-
dung 11.1 stellt dieses Kapitel und dessen Aufbau im Kontext der anderen inhaltlich
vor- und nachgelagerten Kapitel dar.
Abbildung 11.1.: Kapitel „Überblick über die empirische Untersuchung“ im Gesamtzu-
sammenhang
Die im Rahmen der empirischen Evaluierung zu untersuchenden Aspekte sind Gegen-
stand des ersten Abschnitts. Neben einer wiederholenden grundlegenden Betrachtung
werden hier die jeweiligen Untersuchungsfragen festgelegt. Eine nähere Betrachtung der
einzelnen Aspekte, die Festlegung der Methodik und deren Operationalisierung im Rah-
men des konkreten Untersuchungsdesigns erfolgt im Rahmen der übrigen Kapitel in
diesem Teil der Arbeit.
328
11.1. Zu untersuchende Aspekte
Im zweiten Abschnitt wird ein Überblick über das globale Untersuchungsdesign gege-
ben. Auf Basis der zu evaluierenden Aspekte werden die konkret durchgeführten Teile
der Evaluation (im Folgenden: „Evaluierungsblöcke“) beschrieben und den Aspekten zu-
geordnet. Diese Evaluierungsblöcke werden überblicksweise hinsichtlich der intendierten
Ziele, der Aufgabenstellung und der jeweiligen Anzahl der Teilnehmer beschrieben. Die
Beschreibung bildet die Grundlage für die Beschreibung der Evaluierung der zu prüfen-
den Aspekte in den folgenden Kapiteln.
11.1. Zu untersuchende Aspekte
Die Untersuchung der effektiven Unterstützung von expliziter „Articulation Work“ be-
dingt die Konkretisierung des Effektivitäts-Begriff. Grundsätzlich wird ArticulationWork
immer im Zusammenhang mit einem konkreten Arbeitsprozess (der „Production Work“)
bzw. mit einer in diesem aufgetretenen problematischen Situation durchgeführt. Die Wir-
kung von „Articulation Work“ zeigt sich an damit unmittelbar an der „ProductionWork“
und an den in diesem beteiligten Individuen. „Articulation Work“ ist dann effektiv, wenn
die beteiligten Personen die Situation nicht mehr als problematisch wahrnehmen und die
„Production Work“ (wieder) ohne Hindernisse durchgeführt werden kann. Eine Voraus-
setzung zur Durchführung effektiver expliziter „Articulation Work“ ist aus methodischer
Sicht die Durchführung der kooperativen Modellbildung, die zur Abstimmung der indi-
viduellen mentalen Modelle über die Production Work verwendet wird. Hinsichtlich der
kooperativen Modellbildung ist als Voraussetzung der effektiven Unterstützung explizi-
ter „Articulation Work“ die Fähigkeit des Instruments zu sehen, die zur Durchführung
der Modellbildung notwendigen Schritte für die beteiligten Individuen verständlich und
benutzbar zu unterstützen.
An dieser Konkretisierung des Begriffs der Effektivität zeigt sich, dass zur Bestätigung
der effektiven Wirkung des Instruments an mehreren Stellen erfolgen muss. Im Zuge der
Evaluation der Ergebnisse dieser Arbeit müssen einerseits die Erfüllung der Vorausset-
zungen zur effektiven Unterstützung expliziter „Articulation Work“ einzeln betrachtet
werden; andererseits muss die Effektivität anhand der Wirkung der „Articulation Work“
selbst bestätigt werden. Die drei zu untersuchenden Aspekte werden durch folgende Un-
tersuchungsfragen abgedeckt:
• Sind das Werkzeug und dessen Komponenten verständlich und wie intendiert ein-
setzbar? (Aspekt: Verwendbarkeit des Instruments)
• Unterstützt das Instrument die kooperative Modellbildung? (Aspekt: Kooperative
Modellbildung)
• Unterstützt das Instrument Articulation Work? (Aspekt: Wirkung)
329
11.1. Zu untersuchende Aspekte
Die Detaillierung der Fragestellungen ist in den folgenden Abschnitten beschrieben.
Die Beschreibung der zu prüfenden Hypothesen sowie die Operationalisierung der Un-
tersuchungsfragen erfolgt in den Kapitel 12 bis 14.
11.1.1. Evaluierung der Verwendbarkeit des Werkzeugs
Die Evaluierung des Werkzeugs an sich beschäftigt sich mit der Beantwortung der ersten
Untersuchungsfrage. Diese zielt auf die Verständlichkeit des Werkzeugs im weiteren Sinn
ab. Unter „Verständlichkeit im weiteren Sinn“ ist hier zu verstehen, dass einerseits ge-
prüft werden muss, ob die Bedeutung und grundlegende Verwendung der Komponenten
des Werkzeugs von Benutzern erfasst und verstanden werden und ob andererseits die
Interaktionsabläufe, die zur Auslösung bzw. Abwicklung einer Funktion des Werkzeugs
führen, für Benutzer verständlich und nachvollziehbar sind.
Neben der quantitativen Bewertung anhand dieser Metriken ist bei der Untersuchung
dieses Aspektes vor allem auch das qualitative Feedback der Benutzer notwendig, um
Ansatzpunkte zur Verbesserung der Verwendbarkeit des Werkzeugs zu erhalten. Die-
se Anregungen können im Sinne eines iterativen Designprozesses umgesetzt und deren
Auswirkungen erneut einer Evaluierung unterzogen werden. Neben der Erhebung dieser
zusätzlich funktionalen Anforderungen für einen iterativen Designprozess sind in diesem
Zusammenhang auch Hinweise hinsichtlich nicht-funktionaler Aspekte des Systems zu
berücksichtigen, die der Verwendbarkeit negativ beeinflussen bzw. auch unkritisch sein
können.
Die Verwendbarkeit des Werkzeugs kann nicht entkoppelt von der Anwendungsdomäne
betrachtet werden, muss also im Kontext der Aufgabe, für die es eingesetzt wird, gesehen
werden. Das Werkzeug ist zwar grundsätzlich für die Repräsentation beliebiger diagram-
matischer Modelle ausgelegt, eignet sich aufgrund der unterschiedlichen Anforderungen
jedoch nicht gleich gut für alle möglichen Anwendungsfälle (so sind z.B. ausschließlich
Verbindungen mit zwei Endpunkten erstellbar, Verbindungen mit mehr Endpunkten
werden nicht unterstützt). Die Prüfung der Verwendbarkeit des Werkzeugs kann hier fo-
kussiert auf die in dieser Arbeit verfolgten Anwendungsfälle durchgeführt werden, die im
Bereich der konzeptuellen Netze (im Wesentlichen Varianten von Concept Maps) und im
Bereich der Abbildung von Arbeitsvorgängen (im Wesentlichen kausale Zusammenhänge
mit Kontextinformation) zu finden sind. Die Unterstützung anderer Anwendungsfälle ist
möglich und unter Umständen erstrebenswert, stellt jedoch kein Beurteilungskriterium
dar.
11.1.2. Evaluierung der Modellbildung
Der zweite zu evaluierende Aspekt sind die mit dem Werkzeug erstellten Modelle, die
als Mittel zur Durchführung expliziter „Articulation Work“ dienen. Die Untersuchung
330
11.1. Zu untersuchende Aspekte
dieser Frage trägt damit unmittelbar zur Klärung der in der Detaillierung der Zielsetzung
(siehe Abschnitt 1.1) formulierten Frage „Welche Auswirkungen hat die Verwendung des
Werkzeugs während der Durchführung der Articulation Work?“ bei.
Eine wesentliche Eigenschaft, die Modelle als Mittel zur Durchführung expliziter „Ar-
ticulation Work“ aufweisen müssen, ist die Adäquatheit der Modellierungssprache hin-
sichtlich der durch die Benutzer zu repräsentierenden Information. Diese Eigenschaft
wird in der vorliegenden Arbeit durch die in Kapitel 3 beschriebene Anforderung der
semantischen Offenheit abgedeckt, der jedoch vor allem hinsichtlich der intersubjektiven
Verständlichkeit der Modelle und deren Eindeutigkeit nicht nur Vorteile bringt. Grund-
legend ist in dieser Phase zu evaluieren, ob die erstellten Modelle den im Rahmen des
Einsatzes zur Unterstützung von „Articulation Work“ intendierten Zweck erfüllen. Dabei
sind sowohl das Modell als auch das (hier von den Benutzern festgelegte) Metamodell zu
betrachten. Anhaltspunkte zur Identifikation der zu evaluierenden Objekte sowie zum
Vorgehen bieten hier der Ansatz der „Interactive Process Models“ (Jørgensen, 2004)
und die „Grundsätze der ordnungsgemäßen Modellierung“ (Becker et al., 2000) sowie
von diesen Arbeiten abgeleitete Ansätze.
Die eben beschriebenen Ansatzpunkte erlauben eine Evaluierung der erstellten Model-
le hinsichtlich der Abbildbarkeit der Kernaspekte von „Articulation Work“ im engeren
Sinne (Strauss’ „salient dimensions“: „who, where, when, what and how“ (Fjuk et al.,
1997)), decken also im Wesentlichen eine an organisationalen Abläufen orientierten Sicht
auf Modelle ab. Im Sinne der Offenheit der Abbildung müssen aber auch Modelle berück-
sichtigt werden, die nicht diese „salient dimensions“ zur Grundlage haben, also „Concept
Maps“ (Novak und Cañas, 2006) im allgemeinen Sinn sind und damit die Abbildung
mentaler Modelle nicht nur über unmittelbare Arbeitsaspekte sondern über beliebige
Sachverhalte erlauben (Ifenthaler, 2006). Dabei sind Metriken notwendig, die die erstell-
ten Modelle selbst betrachten und deren Eigenschaften und Verwendung beim Concept
Mapping bzw. im Rahmen von Strukturlegetechniken berücksichtigen.
Wie bereits im letzten Abschnitt angeführt, ist auch bei diesem Aspekt der Evaluierung
der in dieser Arbeit verfolgte Anwendungszweck des Werkzeugs (bzw. hier: der Modelle)
zu berücksichtigen. Dies ist insofern ein einschränkender Faktor, als dass hier Model-
le lediglich im Kontext der Externalisierung mentaler Modelle und zur Unterstützung
von „Articulation Work“ berücksichtigt werden. Das Werkzeug selbst erlaubt auch die
Erstellung von Modellen zu anderen Anwendungszwecken, die jedoch hier nicht weiter
berücksichtigt werden.
11.1.3. Evaluierung der Effekte der Articulation Work
Letztendlich muss auch die durchgeführte „Articulation Work“ selbst beurteilt werden.
Dabei wird entsprechend der in Abschnitt 1.1 formulierten Frage „Welche Auswirkun-
gen hat die Verwendung des Werkzeugs auf die beteiligten Personen in der Production
331
11.2. Globales Untersuchungsdesign
Work?“ die Wirkung der durchgeführten „Articulation Work“ auf die beteiligten Perso-
nen im Kontext ihrer Arbeitstätigkeit untersucht.
In der Literatur zum Thema „Articulation Work“ werden zumeist lediglich das Phäno-
men „Articulation Work“ und dessen konkrete Ausprägungen beschrieben (siehe Kapitel
2), Ansätze zur Bewertung des Erfolgs von „Articulation Work“ sind jedoch selten zu
finden. Aus der Verschränkung zwischen „Articulation Work“ und „Production Work“,
also jenem Anteil der Arbeit, der unmittelbar der Zielerreichung dient, die von mehreren
Autoren, unter anderem Fujimura (1987) und Strauss (1993), erwähnt wird, lassen sich
jedoch Ansatzpunkte ableiten.
„Articulation Work“ tritt immer dann auf, wenn eine Zielerreichung in der „Production
Work“ aufgrund von Unklarheiten oder Problemen zwischen den beteiligen Individuen
nicht möglich ist. Ein erfolgreicher Abschuss der „Production Work“ bei am Beginn oder
während der Arbeit bestehenden Unklarheiten weist also auf erfolgreich durchgeführte
„Articulation Work“ hin. „Articulation Work“ manifestiert sich im Arbeitsprozess auf
unterschiedliche Arten, so dass bei der Evaluierung hinsichtlich der Auswirkungen des
Werkzeugs diese von den übrigen Einflussfaktoren (also auf anderen Wegen durchge-
führte „Articulation Work“) getrennt werden muss. Dazu ist eine Betrachtung des ge-
samten Arbeitsablaufs unter Berücksichtigung von Production und „Articulation Work“
notwendig. Metriken, die bei der Bewertung des Erfolgs von „Articulation Work“ zu
berücksichtigen sind, sind also einerseits im Ergebnis des Arbeitsprozesses, andererseits
auch im Arbeitsprozess selbst zu finden.
Ein zweiter Ansatzpunkt zur Bewertung des Erfolgs von „Articulation Work“ liegt in
den Aussagen von Strauss (1993) hinsichtlich der wahrgenommenen ”Problematik” einer
Arbeitssituation, die „Articulation Work“ notwendig macht. Diese Wahrnehmung ist in-
dividueller Natur, d.h. „Articulation Work“ ist dann notwendig, wenn zumindest einer
am Arbeitsablauf beteiligten Person Aspekte der Arbeit unklar sind oder als proble-
matisch wahrgenommen werden. Im Gegenzug ist keine „Articulation Work“ notwendig
bzw. diese abgeschlossen, wenn alle beteiligten Personen die Situation als unproblema-
tisch empfinden bzw. mit den im Rahmen der (expliziten) „Articulation Work“ erzielten
Ergebnissen zufrieden sind. Hier liegt der Ansatzpunkt für eine Evaluierung des Erfolgs
der durchgeführten „Articulation Work“, der diese auf Basis der individuellen Wahrneh-
mungen der beteiligten Personen beurteilt.
11.2. Globales Untersuchungsdesign
Die oben beschriebenen Aspekte müssen nun im Rahmen einer empirischen Untersu-
chung geprüft werden. Während das detaillierte Untersuchungsdesigns in den folgenden
Kapiteln, die sich jeweils einem der drei zu evaluierenden Aspekte widmen, beschrieben
332
11.2. Globales Untersuchungsdesign
wird, wird an dieser Stelle ein Überblick über das globale Untersuchungsdesign und die
im Rahmen der Evaluierung durchgeführten Anwendungen des Werkzeugs gegeben.
Im ursprünglichen globalen Untersuchungsdesign war vorgesehen, jedem der zu un-
tersuchenden Aspekte einen Block an Anwendungen des Werkzeugs mit einer auf den
jeweiligen Aspekt abgestimmten Aufgabenstellung zuzuordnen. Nach Durchführung der
ersten beiden Blöcke wurde offensichtlich, dass sich aus der Anwendung des Werkzeugs
heraus zusätzliche Hypothesen ableiten ließen, die – um sie in der Evaluierung berück-
sichtigen zu können – in einem späteren Block geprüft werden mussten. Außerdem wurde
offensichtlich, dass vor allem zur Evaluierung des Werkzeugs in allen Blöcken Verbesse-
rungspotential identifiziert werden konnte bzw. Anregungen der Anwender rückgemeldet
wurden, die zum Teil im Rahmen des iterativen Entwicklungsprozesses in das Werkzeug
einflossen und deren Wirkung in einem späteren Block erneut geprüft werden musste.
Letztendlich wurden die Blöcke für die Evaluierung mehrerer bzw. aller Aspekte her-
angezogen, sofern die jeweilige Aufgabenstellung geeignet war. Bei der nun folgenden
Beschreibung der Anwendungs-Blöcke wird deshalb jeweils angegeben und begründet,
inwieweit diese in die Evaluierung welcher Aspekte einfließen. Ein Überblick über das
globale Untersuchungsdesign mit einer überblicksweisen Zuordnung zwischen den zu
evaluierenden Aspekten und den Anwendungsblöcken wird in Abschnitt 11.4 gegeben.
11.2.1. Block 1: Technische Evaluierung
Die Intention von Block 1 war die grundlegende Verständlichkeit und Verwendbarkeit
des Werkzeugs zu prüfen. Fokus dieses Blocks an Anwendungen des Werkzeugs war
also die Untersuchung der Eigenschaften des Werkzeugs selbst. Zusätzlich wurde hier
explorativ die Wirkung des Werkzeugs auf die Modellierungstätigkeit und Kooperation
der Anwender untersucht.
Kontext
Die Untersuchung wurde im Rahmen einer Diplomarbeit durchgeführt (Bohninger (2010)),
wobei die Untersuchungen in keinen einheitlichen realen Arbeitskontext eingebettet wa-
ren. Allerdings war die Aufgabenstellung so formuliert, dass die erstellten Modelle aus
den Arbeitskontexten der jeweiligen Teilnehmer stammten.
Aufgabenstellung und Ablauf
Den modellierenden Teilnehmern wurde mitgeteilt, dass sie einen Aspekt aus ihrem
täglichen Arbeits- oder Privatleben abbilden sollten, der regelmäßig auftritt oder bereits
mehrmals für Probleme sorgte. Die bewusste Offenheit der Aufgabenstellung sollte dabei
bewirken, dass sich die Teilnehmer nicht zu sehr auf den abzubildenden Sachverhalt,
333
11.2. Globales Untersuchungsdesign
sondern eher auf den Abbildungsprozess selbst fokussierten. Die Modellbildung erfolgte
jeweils individuell.
Nur die Hälfte der Teilnehmer erstellte tatsächlich Modelle. Die zweite Hälfte wurde
zur Überprüfung der Verständlichkeit der Modelle sowie der Verwendbarkeit des Werk-
zeugs zur kooperativen Modellierung herangezogen. Dazu wurde nach Abschluss einer
Modellbildung jeweils ein nicht modellierender Teilnehmer an die Modellierungsober-
fläche gebeten und aufgefordert, die Abbildung zu interpretieren. Die Beurteilung der
Adäquatheit dieser Interpretation erfolgte durch den ursprünglich modellierenden Teil-
nehmer.
In einer dritten Phase wurden beide Teilnehmer aufgefordert, das Modell gemeinsam
zu reflektieren und gegebenenfalls zu verändern, um es den Ergebnissen der Reflexion
anzupassen. In dieser Phase war das vorrangige Ziel, die Verwendung des Werkzeugs bei
der Veränderung von Modellen und dessen kollaborativer Anwendung zu testen.
Entsprechend dieser Beschreibung ist die Phase 1 dieses Blocks dem Anwendungssze-
nario „Verfeinerung mentaler Modelle“ (siehe Abschnitt 4.3.1) zuzuordnen. Die Phasen
2 und 3 sind dem Anwendungsszenario „Wissenstransfer“ (siehe Abschnitt 4.3.2) zuzu-
ordnen.
Anwendungen und Teilnehmer
Insgesamt wurden neun Anwendungen des Werkzeugs wie oben beschrieben durchge-
führt. Zusätzlich wurde das Untersuchungsdesign im Rahmen von drei Anwendungen
getestet (Pretest), woraus hinsichtlich der technischen Eigenschaften des Werkzeugs
ebenfalls bereits Erkenntnisse gewonnen werden konnten. Insgesamt nahmen also 24
Personen an diesem Block von Anwendungen teil, 6 davon in der Pretest-Phase.
Die Teilnehmer (exkl. Pretest) stammten aus unterschiedlichen beruflichen Hinter-
gründen und unterschieden sich auch in der Art der höchsten abgeschlossenen Ausbil-
dung (7 Universität/FH, 7 Matura, 4 Lehrabschluss). Die Altersspanne lag zwischen 19
und 43 Jahren, 13 Teilnehmer waren weiblich, 11 männlich.
Die Modellierungsphasen (exkl. Pretest) dauerten im Schnitt 8 Minuten (SD = 2m13s),
die kürzeste Modellbildung dauerte 5 Minuten, die längste 12 Minuten. Die Interpretations-
und Reflexionsphasen (nicht separat aufschlüsselbar, da zum Großteil ineinander über-
gehend) dauerten im Schnitt 5 Minuten (SD = 1m45s).
Verwendung der Ergebnisse
Die Ergebnisse dieses Blocks flossen in die Evaluierung des Werkzeugs und in die Hypo-
thesenbildung hinsichtlich der erstellten Modelle ein. Für die Evaluierung der Modelle
konnten erste Erkenntnisse hinsichtlich der Verständlichkeit der mit offener Semantik
334
11.2. Globales Untersuchungsdesign
gewonnen werden. Keine Ergebnisse brachte dieser Block für die Evaluierung der durch-
geführten „Articulation Work“.
11.2.2. Block 2: Aushandlung von Zusammenarbeit 1
In Block 2 lag der Fokus der Evaluation erstmals auf der Unterstützung von „Articu-
lation Work“. In diesem Rahmen wurden auch die Verwendbarkeit des Werkzeugs im
praktischen Anwendungskontext und die Eigenschaften der erstellten Modelle sowie de-
ren Rolle im Prozess der expliziten „Articulation Work“ untersucht.
Kontext
Block 2 wurde im Rahmen eines Seminars aus Wirtschaftsinformatik mit Studierenden
dieser Studienrichtung durchgeführt. Die im Seminar zu erstellenden wissenschaftlichen
Arbeiten wurden von den Studierenden in Gruppen zu 2-3 Personen ausgearbeitet. Die
Gruppen wurden so gebildet, dass sich die Teilnehmer nicht persönlich kannten oder
zumindest nicht bereits in anderen Kontexten zusammengearbeitet hatten. Ziel dieser
Maßnahme war die Vermeidung der Verfälschung der Untersuchungsergebnissse durch
bereits eingespielte Gruppen (Erfahrungen in Seminaren der Vorjahre zeigen tendentiell
schlechtere Ergebnisse bei der Zusammenarbeit von einander nicht persönlich bekannten
bzw. nicht eingespielten Teilnehmern).
Im Rahmen des Seminars wurden sechs Forschungsgebiete ausgewählt, die in Zusam-
menhang mit der Erstellung und Verwendung sozio-technischer Systeme stehen (konkret:
Organisationales Lernen, eLearning, CSCW, Mentale Modelle, „Articulation Work“ und
semantische Contentanreicherung). Den Gruppen wurden jeweils zufällig zwei dieser
Themen zugewiesen, die Aufgabe für die wissenschaftliche Arbeit war das Finden und
Beschreiben einer möglichen Verknüpfung oder eines möglichen Zusammenhanges zwi-
schen diesen Themen. Dieser Zusammenhang sollte im Zentrum der Seminararbeit stehen
und aus beiden Grundlagen-Themen argumentiert sein. Ziel dieser Maßnahme war es,
die Seminararbeit so offen wie möglich zu gestalten und einen Themenfindungs- bzw.
Konkretisierungsprozess in den Ablauf zu integrieren. Außerdem wurde so ein Szenario
geschaffen, in dem sich eine strikte Arbeitsteilung der Gruppenteilnehmer ohne weitere
Zusammenarbeit während der Ausarbeitung der Inhalte („Production Work“) potentiell
auf das Ergebnis auswirkt und sich konkret der fehlenden oder schwachen Verknüpfung
der Grundlagen-Themen zeigt.
Aufgabenstellung und Ablauf
Das Werkzeug wurde im Rahmen des Seminars für jede Gruppe zweimal eingesetzt. Die
erste Anwendung fand zu Beginn des Seminars nach der Themenzuteilung statt. Die Auf-
335
11.2. Globales Untersuchungsdesign
gabe war die Aushandlung der Modalitäten der Zusammenarbeit mit der Zielsetzung,
dass an der resultierenden wissenschaftlichen Arbeit die Ko-Autorenschaft nicht mehr
zu erkennen sein sollte (etwa durch plötzlich wechselnde Schreibstile oder Brüche in der
Argumentationskette). Den Teilnehmern wurde das Werkzeug und dessen Funktionen
vorgestellt und ohne weitere Vorgaben zur Verfügung gestellt (insbesondere wurden we-
der Vorgaben hinsichtlich der Topologie des zu erstellenden Modells oder der Bedeutung
der Modellierungselemente gemacht).
In der zweiten Anwendung wurde der Zusammenarbeitsprozess reflektiert und gege-
benenfalls eine Adaption vereinbart. Die zweite Anwendung fand in der Mitte des Se-
mesters nach Abschluss der Literaturrecherche und der Grobkonzeption, aber vor der
Erstellung der eigentlichen wissenschaftlichen Arbeit statt. Konkrete Zielsetzung für die
Teilnehmer war hier, auf Basis der bisherigen Erfahrungen die weitere Zusammenarbeit
zu vereinbaren. Das Werkzeug wurde ohne neuerliche Vorstellung und ohne Vorgaben
hinsichtlich der Verwendung zur Verfügung gestellt.
Entsprechend dieser Beschreibung ist die erste Anwendung des Werkzeugs in die-
sem Block dem Anwendungsszenario „Aushandlung mentaler Modelle“ (siehe Abschnitt
4.3.4) zuzuordnen. Die zweite Anwendung ist in das Anwendungsszenario „Abstimmung
mentaler Modelle“ (siehe Abschnitt 4.3.3) einzuordnen.
Anwendungen und Teilnehmer
Insgesamt nahmen an diesem Block 19 Personen in 9 Gruppen zu 2 bzw. einmalig 3
Personen teil. Jede der Gruppen setzte das Werkzeug zweimal ein, wodurch insgesamt
18 Anwendungen die Grundlage für die Auswertung der Ergebnisse bilden.
Die Teilnehmer waren allesamt Studierende der Wirtschaftsinformatik im zweiten Stu-
dienabschnitt. 18 Personen waren männlich, eine weiblich. Vier Personen hatten inso-
fern Erfahrung mit wissenschaftlichen Arbeiten bzw. den konkreten Anforderungen in
der betreffenden Lehrveranstaltungen, als dass sie bereits zuvor eine Lehrveranstaltung
gleichen Typs besucht hatten.
In der ersten Runde dauerten die Anwendungen durchschnittlich 20 Minuten 50 Sekun-
den (SD = 4 : 18), in der zweiten Runde lediglich 9 Minuten 49 Sekunden (SD = 5 : 20).
Verwendung der Ergebnisse
Die in diesem Block erhobenen Daten fließen in die Auswertung aller drei zu evaluie-
renden Aspekte ein. Zur Auswertung hinsichtlich des Erfolgs von „Articulation Work“
liegen neben den Aufnahmen der Modellierungsvorgänge und den erstellten Modellen
selbst auch Prozessreflexionen der Teilnehmer über den Erstellungsprozess der Semi-
nararbeiten sowie die Seminararbeit an sich vor. Die Auswirkungen von „Articulation
Work“ können also am Ergebnis (im Vergleich zu Ergebnissen auf Lehrveranstaltungen
336
11.2. Globales Untersuchungsdesign
mit identischem Konzept) und am subjektiv wahrgenommenen Verlauf des Erstellungs-
prozesses der Arbeit bewertet werden.
Hinsichtlich der Auswertung des Modell-Aspektes wird durch diesen Block die Betrach-
tung von Modellen ermöglicht, die im Kontext der Arbeitsabstimmung erstellt wurden,
also im Wesentlichen der Definition von Vorgehen und Schnittstellen dienen. Untersucht
werden hier Aufbau und Inhalt der Modelle, wobei besonderes Augenmerk auf dem Pro-
zess und Ergebnis der Bedeutungszuweisung zu den Modellelementen liegt.
Im Rahmen der Werkzeug-Evaluation bringt dieser Block die ersten Hinweise auf die
Anforderungen an das Werkzeug bei der Verwendung desselben im Rahmen einer realen
Aufgabenstellung. Außerdem wurde in diesem Block erstmals ein durchgängig kollabo-
ratives Szenario eingesetzt, bei dem immer mindestens zwei Personen gleichzeitig das
Werkzeug verwenden.
11.2.3. Block 3: Concept Mapping 1
Der Fokus von Block 3 lag auf der Erstellung von semantisch vernetzten Strukturen
im Allgemeinen, wobei das Konzept der Concept Maps als ein etabliertes Werkzeug
zur Externalisierung mentaler Modelle eingesetzt wurde. Inhaltlich fokussierte dieser
Block nicht auf die Unterstützung von „Articulation Work“ im engeren Sinne, wohl
aber auf die Externalisierung und Abstimmung mentaler Modelle, was wie in Kapitel 3
beschrieben ein Mittel zur Unterstützung expliziter „Articulation Work“ ist. Im Zentrum
der Aufmerksamkeit steht in diesem Block also die Evaluierung der erstellten Modelle
und der Nutzen des Werkzeugs zur Aushandlung einer einheitlichen auf einen gegebenen
Sachverhalt.
Kontext
Der dritte Block wurde im Rahmen einer Lehrveranstaltung zur Schulung von Methoden
der Prozess- und Kommunikationsmodellierung durchgeführt. Diese Lehrveranstaltung
ist Teil der im Curriculum definierten Basiskompetenz Wirtschaftsinformatik und wird
von Studierenden im zweiten bis dritten Studiensemester besucht.
Im Rahmen der Lehrveranstaltung wurden drei unterschiedliche Prozessmodellierungs-
sprachen (SeeMe (Herrmann et al., 2004a), Subjekt-orientierte Modellierung mittels
JPass (Fleischmann, 2007) und EPK1s aus dem ARIS-Konzept (Scheer und Nuettgens,
2000)) eingeführt und praktisch an einem durchgängigen Beispiel angewandt. Diese Spra-
chen unterscheiden sich sowohl im Anwendungsgebiet, in den abgebildeten Aspekten des
realen Prozesses sowie in der Darstellungsform des Modells. Ziel der letzten Teilaufgabe,
die unter Einsatz des hier vorgestellten Werkzeugs durchgeführt wurde, war bei den Stu-
1Ereignisgesteuerte Prozesskette
337
11.2. Globales Untersuchungsdesign
dierenden ein Verständnis für die Unterschiede und Gemeinsamkeiten zwischen diesen
Sprachen zu erzeugen und sie in die Lage zu versetzen, für einen gegebenen Anwen-
dungsfall eine adäquate Sprache auszuwählen.
Aufgabenstellung und Ablauf
Die Aufgabe zur Erstellung der Concept Map umfasste zwei Teile, wobei im zweiten Teil
das Tabletop Interface eingesetzt wurde. Die Aufgabenstellung lautete in beiden Teilen,
eine Concept Map zu erstellen, die die als wesentlich wahrgenommenen Eigenschaften
der vorgestellten Sprachen sowie deren Gemeinsamkeiten und Unterschiede darstellt. In
der ersten Phase war diese Aufgabe von den Studierenden individuell zu lösen, wobei
die Concept Map auf Papier oder mit Hilfe des Werkzeugs CMapTools2 (Cañas et al.,
2004) am Rechner erstellt werden konnte.
In der zweiten Phase wurden Gruppen zu je drei Teilnehmern gebildet, die nun ihre
individuellen Sichten konsolidieren und jeweils eine gemeinsame Concept Map zur glei-
chen Aufgabenstellung unter Einsatz des hier vorgestellten Werkzeugs erstellen sollten.
Die Gruppen wurden zufällig zusammengesetzt, den Teilnehmern war während der indi-
viduellen Phase die Zuteilung nicht bekannt, so dass eine Abstimmung vor Anwendung
des Werkzeugs weitgehend ausgeschlossen werden kann.
Der zweite Teil der Aufgabenstellung in diesem Block, in dem das Werkzeug zur An-
wendung gebracht wurde, entspricht damit einer Ausprägung des Anwendungsszenarios
„Abstimmung mentaler Modelle“ (siehe Abschnitt 4.3.3).
Anwendungen und Teilnehmer
An den Anwendungen, die in diesem Block durchgeführt wurden, nahmen insgesamt 54
Personen teil, die in 18 Gruppen einmalig mit demWerkzeug arbeiteten. Alle Teilnehmer
waren Studierende der Wirtschaftsinformatik im ersten Studienabschnitt (1-4 Semester),
8 waren weiblich, 46 männlich. Keinem der Teilnehmer war der Ansatz des Concept
Mapping vor Beginn der betreffenden Aufgabe bekannt, Erfahrungen mit Prozessmodel-
lierungssprachen (also dem Gegenstand der Concept Map) sammelten alle Teilnehmer
erstmals im Rahmen der Lehrveranstaltung, in der dieser Evaluierungs-Block durchge-
führt wurde.
Den Teilnehmern wurde das Werkzeug vor Beginn der Anwendung demonstriert und
in sämtlichen Anwendungsaspekten erklärt. Die Anwendungen selbst dauerten durch-
schnittlich 32 Minuten 32 Sekunden (SD = 10 : 07), wobei die kürzeste Anwendung 14
Minuten, die längste 45 Minuten dauerte.
2http://cmap.ihmc.us
338
11.2. Globales Untersuchungsdesign
Verwendung der Ergebnisse
Die Daten, die aus diesem Block gewonnen werden konnten, gehen in die Evaluierung des
Modell-Aspekts ein. Hier können einerseits wiederum die erstellten Modelle hinsichtlich
Struktur, Inhalt und semantischen Zuweisungen untersucht werden. Der Modellierungs-
gegenstand ist in diesem Fall jedoch anders gelagert als im vorhergehenden Fall, anstelle
eines Arbeitsabstimmung ist hier ein Vergleich von Konzepten durchzuführen. Anderer-
seits können hier die Abstimmungsprozesse der individuellen mentalen Modelle insofern
betrachtet werden, als dass für jede Gruppe neben dem kooperativ erstellten Ergebnis
auch noch die individuellen Concept Maps vorliegen und ausgewertet werden können.
Wie bereits in den zuvor beschriebenen Blöcken können auch hier wieder Erkenntnisse
hinsichtlich der Verwendung des Werkzeugs gewonnen werden. Aufgrund der der Aufga-
be innewohnenden Relevanz der Verbindungen zwischen Konzepten ist vor allem deren
Verwendung bzw. der Vorgang deren Erstellung zu betrachten.
Der Aspekt „Articulation Work“ bleibt in diesem Block insofern außen vor, als dass
kein Arbeitskontext vorliegt, keine aufzulösende Problematik vorliegt und keine Zusam-
menarbeit auszuhandeln ist. Insofern wird dieser Aspekt in diesem Block nicht explizit
behandelt. Aufgrund der Durchführung sämtlicher Schritte, die zur Unterstützung ex-
pliziter „Articulation Work“ notwendig sind (Externalisierung, Abstimmung) können
aber die einzelnen Anwendungen zur Hypothesenbildung für den Evaluierungs-Aspekt
„Articulation Work“ herangezogen werden.
11.2.4. Block 4: Aushandlung von Zusammenarbeit 2
Block 4 deckt die erste Anwendung des Werkzeugs im realen Unternehmenskontext ab.
Im Rahmen einer Diplomarbeit (Wahlmüller, 2010) wurde das Werkzeug zur Offenlegung
unmittelbar relevanter bzw. urgenter Fragestellungen eingesetzt, die im Rahmen eines
Workshops zu den Abläufen in und zur Struktur der IT-Abteilung einer Unternehmens-
gruppe aus dem Bildungsbereich auftraten. Fokus dieses Blocks war die Untersuchung
der Einsetzbarkeit des Werkzeugs im praktischen Kontext und dessen tatsächlicher Un-
terstützungsleistung für „Articulation Work“. Dazu wurde neben der Begleitung der
eigentlichen Modellierungssession in zeitlichem Abstand auch eine Erhebung der wahr-
genommenen Wirkungen auf die Arbeitspraxis durchgeführt.
Kontext
Das Werkzeug wird im Kontext einer österreichweit tätigen Unternehmensgruppe im
Aus- und Weiterbildungsbereich eingesetzt. Konkret kam das Werkzeug bei einem Work-
shop zum Einsatz, der von der Abteilung für technisches Produkt- und Service-Management
in der konzernweiten IT-Abteilung abgehalten wurde. Die Abteilung hat rund 30 Mitar-
339
11.2. Globales Untersuchungsdesign
beiter, die sich in insgesamt 5 Unterabteilungen gliedern. Zusätzlich ist ein Mitarbeiter
abteilungsweit für die Qualitätssicherung der Arbeitsabläufe verantwortlich. Dieser leite-
te die Workshops, bei denen das Werkzeug zum Einsatz kam und führte in Abstimmung
mit den jeweils betroffenen Kollegen die Themenauswahl durch.
Aufgabenstellung und Ablauf
In unterschiedlichen Konstellationen mit Gruppengrößen von 2 bis 6 Personen wurden an
zwei Workshop-Terminen Themen aus dem täglichen Arbeitskontext behandelt. Dabei
wurden zum Einen Unterabteilungs-interne oder -übergreifende Arbeitsabläufe abgebil-
det und ausgehandelt, die als potentiell problematisch oder neu einzurichten wahrgenom-
men wurden. Zum Anderen wurde die wahrgenommene Struktur einer Unterabteilung
selbst und deren Außenbeziehungen abgebildet, reflektiert und zwischen den Mitgliedern
derselben abgestimmt.
Bei Aufgaben der ersten Kategorie begann die Bearbeitung jeweils mit der kooperati-
ven Repräsentation des Ist-Standes und damit einem Abgleich der individuellen Sichten
auf den aktuellen Arbeitsablauf. In weiterer Folge wurde anhand des Modells mögliches
Optimierungspotential diskutiert und das Modell ggf. dementsprechend adaptiert.
Bei der Darstellung der Struktur einer Unterabteilung wurden im ersten Schritt die
relevanten organisationalen Einheiten und Rollen gesammelt und auf der Oberfläche
platziert. In weiterer Folge war die Aufgabe die Zusammenhänge innerhalb der Unterab-
teilung und deren Beziehungen nach außen durch räumliche Anordnung der definierten
Einheiten sowie deren Kommunikationskanäle explizit durch Assoziationen darzustel-
len. Ziel war eine Repräsentation des Ist-Zustands der Abteilung, die soweit abgestimmt
wurde, dass alle Teilnehmer ihre individuelle Sicht auf das Modell abbilden konnten.
Die unterschiedlichen Anwendungen in diesem Block sind entsprechend der obigen
Beschreibung als Ausprägungen des Anwendungsszenarios „Abstimmung mentaler Mo-
delle“ (siehe Abschnitt 4.3.3) zu betrachten.
Anwendungen und Teilnehmer
Am ersten Workshop-Tag nahmen insgesamt 6 Teilnehmer an 5 Modellierungsdurchgän-
gen in Gruppen von 2 bis 5 Personen teil. Beim zweiten Workshop nahmen insgesamt 8
Teilnehmer an ebenfalls 5 Modellierungsdurchgängen teil. Insgesamt beschäftigten sich
8 Aufgaben mit konkreten Arbeitsabläufen, 2 Aufgaben widmeten sich der Struktur von
Unterabteilungen. Die Gruppengröße variierte zwischen 3 und 6 Personen. 10 Teilneh-
mer nahmen an mehr als einem Modellierungsdurchgang teil, eine Person war an beiden
Workshop-Tagen beteiligt.
Durch die Einbindung aller Unterabteilungen kamen Teilnehmer mit unterschiedlichem
fachlichen Hintergrund zu Einsatz. Etwa die Hälfte der Teilnehmer war der Gruppe
340
11.2. Globales Untersuchungsdesign
der Techniker oder Softwareentwickler zuzuordnen. Die andere Hälfte setzte sich aus
Mitarbeiter im Support, Verkauf, Einkauf sowie der internen Verrechnung zusammen.
Eine Teilnehmerin war weiblich, alle anderen Teilnehmer waren männlich.
Allen Teilnehmern wurde einmalig das Werkzeug und dessen Bedienung vorgestellt.
Die Modellierungsdurchgänge dauerten zwischen 25 Minuten und etwa 1,5 Stunden.
Sämtliche Teilnehmer wurden nach ihrer letzten Teilnahme an einem Durchgang mit-
tels einem Fragebogen sowohl nach der Nützlichkeit des Werkzeugs, als auch nach dem
wahrgenommenen Nutzen des inhaltlichen Ergebnisses befragt. Um die mittelfristigen
Auswirkungen der durchgeführten Modellierungsdurchgänge beurteilen zu können, wur-
de acht Wochen nach dem zweiten Workshop erneut eine Befragung durchgeführt, in der
die wahrgenommene Auswirkungen thematisiert wurden.
Verwendung der Ergebnisse
Die Daten, die das Ergebnis dieses Blocks bilden, werden zur Evaluierung des Aspekts
„Articulation Work“ eingesetzt. Betrachtet werden dabei die wahrgenommenen und be-
obachtbaren Veränderungen am Arbeitsprozess, der unter Einsatz des Werkzeugs reflek-
tiert wurde.
Neben diesem Aspekt werden auch die erstellten Modelle, die in diesem Fall wieder
aus der Domäne der Arbeitsabstimmung stammen, betrachtet und hinsichtlich ihrer
Struktur und Semantik ausgewertet.
Der Werkzeug-Aspekt wird in diesem Teil der Untersuchung nicht gesondert betrach-
tet, Verbesserungs- und Erweiterungspotential wird nur bei Erwähnung oder offensicht-
lichen Bedienungsfehlern bzw. Verständnisschwierigkeiten explizit identifiziert.
11.2.5. Block 5: Concept Mapping 2
In Block 5 wird im Wesentlichen der Evaluierungs-Blocks 3 (siehe Abschnitt 11.2.3) in-
haltlich erneut durchgeführt (die Modellierungsaufgabe ist identisch). Im Gegensatz zu
Block 3, wo die grundlegende Eignung des Werkzeugs zum Concept Mapping im Mittel-
punkt stand, wird in Block 5 eine vergleichende Studie durchgeführt, die die Eignung des
Tabletop Interfaces zum kollaborativen Concept Mapping mit jener der rechner-basierten
CMapTools (Cañas et al., 2004) vergleicht.
Kontext
Die Anwendungssituation ist in diesem Block identisch mit dem in Abschnitt 11.2.3 be-
schriebenen Kontext (Lehrveranstaltung im CurriculumWirtschaftsinformatik zur Schu-
lung von Ansätzen in der Prozess- und Kommunikationsmodellierung).
341
11.2. Globales Untersuchungsdesign
Der Ablauf der Lehrveranstaltung unterschied sich nur insofern von jenem in Block 3,
als dass für jede Modellierungssprache separat eine Reflexion in Gruppen zu zwei Stu-
dierenden durchgeführt wurde. In diesen Reflexionen wurden die eigenen Anwendungen
der jeweiligen Sprache mit einer Musterlösung gegenübergestellt und hinsichtlich ihrer
Korrektheit und dem Vorgehen bei der Modellierung betrachtet.
Aufgabenstellung und Ablauf
Die Aufgabenstellung ist identisch mit jener in Block 3. Ziel ist es, drei in der Lehrver-
anstaltung vorgestellte Prozessmodellierungssprachen hinsichtlich ihrer als wesentlich
empfundenen Eigenschaften und deren Gemeinsamkeiten und Unterschiede zu betrach-
ten und in einer Concept Map abzubilden. Das Vorgehen unterscheiden sich jedoch wegen
der unterschiedlichen Zielsetzung der Untersuchung von jenem in Block 3.
Nach Abschluss der letzten Reflexionsphase (also nach drei Modellierungsphasen und
drei Reflexionsphasen) wurde eine Gruppeneinteilung für die kollaborative Erstellung
der Concept Map vorgenommen. Die Gruppen wurden aus jeweils zwei zufällig ausge-
wählten Studierenden gebildet. In der Untersuchung erhielt die Hälfte der Gruppen den
Aufgabe, die Aufgabenstellung unter Verwendung des Tabletop Interfaces durchzufüh-
ren, die andere Hälfte verwendete das rechner-basierte Werkzeug CMapTools (Cañas
et al., 2004), um die Concept Map zu erstellen. Die Gruppen wurden zufällig einem
Werkzeug zugeordnet und führten die Aufgabenstellung in beiden Fällen kollaborativ in
einer kontrollierten Umgebung durch. Im Gegensatz zu Block 3 entfiel hier die explizit
geforderte individuelle Vorbereitungsphase, um eine stärkere inhaltliche Auseinanderset-
zung mit den Inhalten während der Modellierung zu fördern.
Wie bereits in Block 3 ist diese Aufgabenstellung eine Ausprägung des Anwendungs-
szenarios „Abstimmung mentaler Modelle“ (siehe Abschnitt 4.3.3).
Anwendungen und Teilnehmer
An der Untersuchung nahmen 49 Studierende in 23 Gruppen teil, wobei 11 Gruppen die
Aufgabenstellung unter Verwendung des hier vorgestellen Werkzeugs und 12 Gruppen
unter Verwendung der CMapTools durchführten. Die Teilnehmer waren allesamt Studie-
rende der Wirtschaftsinformatik in der ersten Phase des Bakkelauratsstudiums (erstes
bis drittes Semester), 40 Teilnehmer waren männlich, 9 weiblich. Keiner der Teilnehmer
hatte Vorkenntnisse in der Prozessmodellierung oder im Concept Mapping.
Den Teilnehmern wurde das Werkzeug vor Beginn der Anwendung demonstriert und
in sämtlichen Anwendungsaspekten erklärt. Die Anwendungen selbst dauerten im Fall
der Durchführung mittels CMapTools durchschnittlich 41 Minuten 10 Sekunden (SD =
8 : 34), wobei die kürzeste Anwendung 30 Minuten 16 Sekunden, die längste 54 Minuten
dauerte. Im Fall der Durchführung am hier vorgestellten System betrug die Modellie-
342
11.3. Eingesetzte Werkzeuge und Verfahren
rungsdauer im Schnitt 34 Minuten 18 Sekunden (SD = 9 : 11), wobei die kürzeste
Anwendung 21 Minuten, die längster 54 Minuten dauerte.
Verwendung der Ergebnisse
Die in diesem Block erhobenen Daten fließen vorrangig in den Modell-Aspekt der Eva-
luierung ein. Hier wird eine vergleichende Studie durchgeführt, die das Ziel hat, die
Eignung der beiden verwendeten Ansätze für die Externalisierung von mentalen Model-
len gegenüberzustellen. Grundlage dieser Beurteilung ist das erstellte Modell, außerdem
wird der auch Modellierungsprozess in der Auswertung berücksichtigt.
Hinsichtlich des Werkzeug-Aspekts wird in diesem Block neben der Identifikation von
Verbesserungspotential und Verständnisschwierigkeiten auch die Zufriedenheit mit dem
Werkzeug bzw. dessen Akzeptanz bei den Benutzern explizit erhoben.
Der Aspekt „Articulation Work“ wird hier wie schon in Block 3 und aus den dort
angeführten Gründen (siehe Abschnitt 11.2.3) nicht weiter berücksichtigt.
11.3. Eingesetzte Werkzeuge und Verfahren
Für die Erfassung und Auswertung der erhobenen Daten kamen unterschiedliche Werk-
zeuge zum Einsatz. Grundsätzlich wurden sämtliche Anwendungen des Tabletop Inter-
face auf Video erfasst, um eine nachträgliche quantitative und qualitative Auswertung
zu ermöglichen. In den Evaluierungsblöcken 1, 4 und 5 kamen aufgrund der Fragestel-
lung außerdem Fragebögen zur Erhebung des Vorwissens bzw. der Erfahrungen bei der
Benutzung des Werkzeugs zum Einsatz. Die Auswahl bzw. das Design dieser Fragebö-
gen ist abhängig von den jeweils zu testenden Hypothesen und wird dementsprechend
im Rahmen der Beschreibung des Untersuchungsdesigns in den folgenden Kapiteln be-
schrieben. In allen Anwendungen wurden zudem die Modellierungsergebnisse graphisch
festgehalten.
Sämtliche erfassten Daten wurden vor der Auswertung digital aufbereitet. Videos wur-
den als Mediendateien im MPEG4-Format abgelegt, Fragebögen wurden gescannt und
im PDF-Format abgelegt, die graphischen Repräsentationen der Modellierungsergebnis-
se liegen als Bilddateien im PNG- bzw. JPEG-Format vor.
Die Rohdaten wurden einer quantitativen sowie qualitativen Auswertung unterzogen.
Die dazu eingesetzten technischen Werkzeuge und methodischen Ansätze werden in den
folgenden Abschnitten näher betrachtet.
343
11.3. Eingesetzte Werkzeuge und Verfahren
11.3.1. Werkzeuge
Zur Erfassung der quantitativen Daten wurde Microsoft Excel 20073 verwendet. Die
deskriptiven statistischen Parameter wurden ebenfalls mit Microsoft Excel sowie mit
dem Statistik-Paket R4 in der Version 2.9.0 berechnet. Die Parameter der schließenden
Statistik wurden ebenfalls mit R berechnet. Die im Bereich der schließenden Statistik
eingesetzten Methoden sind Gegenstand der folgenden Abschnitte. Zur Visualisierung
der deskriptiven Parameter wurde neben R auch die Software OmniGraphSketcher5 ein-
gesetzt.
Im Bereich der qualitativen Auswertung war vor allem die Benutzung des Tabletop
Interface und die Interaktion der Modellierenden untereinander von Interesse. Zur Aus-
wertung kam dabei einerseits offene Fragen in den eingesetzten Fragebögen und ande-
rerseits die von Hornecker (2004) vorgeschlagene Variante der Interaktionsanalyse nach
Jordan und Henderson (1995) zum Einsatz (siehe Abschnitt 11.3.5). Die im Zuge der
Durchführung zu erstellenden Transkripte der Interkationsabläufe wurden ohne spezifi-
sche Werkzeugunterstützung in einem Texteditor erstellt.
11.3.2. Signifikanztests
Signifikanztests werden verwendet, um zu ermitteln, ob die Unterschiede zwischen zwei
Stichproben tatsächlich signifikant sind, d.h. ob sich mit einer gegebenen Irrtumswahr-
scheinlichkeit (etwa p < 0.05) auch die beiden den Stichproben zugrunde liegenden
Grundgesamtheiten unterscheiden (Bortz und Döring, 2003, S. 496). Signifikanztests
sind deshalb ein zentraler Bestandteil der quantitativen Hypothesenprüfung.
Je nach Eigenschaften der zugrunde liegenden Grundgesamtheiten und Umfang der
Stichprobe müssen unterschiedliche Verfahren zur Signifikanzprüfung eingesetzt werden.
In den folgenden Unterabschnitten werden die hier verwendeten Tests kurz beschrieben
und die Voraussetzungen für deren Einsatz angeführt. Als Grundlage für die Auswahl
dienten in dieser Arbeit das einführende Werke von Bortz und Döring (2003) und Duller
(2008) sowie die Website „Using R for statistical analyses“6. Für eine umfassendere
Beschreibung der Methoden sei hier auf diese Quellen verwiesen.
t-Test
Der t-Test nach Student prüft in der Grundvariante anhand einer Stichprobe, ob der
erwartete Mittelwert der entsprechenden Grundgesamtheit gleich, kleiner oder größer
3http://office.microsoft.com/excel
4http://www.r-project.org/
5http://www.omnigroup.com/applications/omnigraphsketcher
6http://gardenersown.co.uk/Education/Lectures/R
344
11.3. Eingesetzte Werkzeuge und Verfahren
einem gegebenen Wert ist. In der – hier eingesetzten – Variante für zwei Stichproben
prüft der Test, ob der erwartete Mittelwert der der ersten Stichprobe zugrunde liegenden
Grundgesamtheit gleich, kleiner oder größer ist als jener der Grundgesamtheit zur zwei-
ten Stichprobe. Für mehr als zwei Stichproben kann der t-Test nicht eingesetzt werden,
alternativ kann der Kruskal-Wallis-Test (siehe unten) zur Anwendung gebracht werden.
Der t-Test geht von einer intervallskalierten, normalverteilten Grundgesamtheit aus.
Bei Grundgesamtheiten, deren Verteilung unbekannt ist, kann bei ausreichender Stich-
probengröße (häufig: n > 30) auf Grund des zentralen Grenzwertsatzes von einer Nor-
malverteilung ausgegangen werden und der t-Test wiederum eingesetzt werden. Bei klei-
neren Stichproben kann der t-Test nur dann verwendet werden, wenn eine Normalver-
teilung der Grundgesamtheit zu erwarten ist. Dies kann auch für kleine Stichproben mit
dem Sharpiro-Wilk-Test (siehe unten) überprüft werden. Eine weitere Bedingung für den
Einsatz des t-Tests ist, dass die Varianz der Grundgesamtheiten der beiden Stichproben
identisch ist. Dies kann mit dem F-Test (siehe unten) festgestellt werden. Bortz und
Döring (2003)
Wilcoxon-Test
Der Wilcoxon-Rangsummentest (oder alternativ: Mann-Whitney-U-Test) ist ein Verfah-
ren zur Überprüfung, ob zwei Verteilungen signifikant übereinstimmen. Die Verteilungen
müssen im Gegensatz zum t-Test nicht normalverteilt sein, sollten aber eine ähnliche
Form aufweisen. Der Wilcoxon-Test ist auch für kleine Stichproben geeignet. (Duller,
2008)
Aufgrund der Stichprobengrößen in den vorliegenden Untersuchungen ist der Wilcoxon-
Test dem t-Test hier im Allgemeinen vorzuziehen.
Sharpiro-Wilk-Test
Der Sharpiro-Wilk-Test (Shapiro und Wilk, 1965) testet eine Verteilung auf „Nicht-
Normaliät“ (d.h. die Nullhypothese ist, dass die Verteilung nicht normalverteilt ist). Mit
einer Irrtumswahrscheinlichkeit von p < 0.05 kann daher bei Ablehnung der Nullhypo-
these davon ausgegangen werden, dass die geprüfte Verteilung nicht normalverteilt ist.
Dieser Test eignet sich auch für kleine Stichproben (ab n > 3). (Duller, 2008)
Er wird hier eingesetzt, um zu prüfen, ob der t-Test eingesetzt werden kann oder nicht
(da dieser eine Normalverteilung der Parameter voraussetzt).
F-Test
Der F-Test (oder: Varianzquotienten-Test) überprüft, ob die Varianzen zweier normal-
verteilter Grundgesamtheiten signifikant übereinstimmen. Er wird hier eingesetzt, um
345
11.3. Eingesetzte Werkzeuge und Verfahren
die entsprechende Voraussetzung für den Einsatz des t-Tests zu überprüfen. Muss die
Nullhypothese verworfen werden, so muss anstelle des t-Tests der Welch-Test eingesetzt
werden, auf den hier nicht näher eingegangen wird. (Duller, 2008)
Kruskal-Wallis-Test
Der Kruskal-Wallis-Test ist wie der Wilcoxon-Test ein Verfahren, mit dem die Überein-
stimmung von Verteilungen auf Signifikanz überprüft werden kann. Wie dieser setzt er
keine Normalverteilung voraus und eignet sich auch für kleine Stichproben.
Der Kruskal-Wallis-Test kann jedoch Gegensatz zu den anderen Verfahren auch für die
Überprüfung von mehr als zwei Verteilungen gleichzeitig eingesetzt werden. Die Null-
hypothese ist, dass sich die Verteilungen nicht unterscheiden. Werden detailliertere Hy-
pothesen benötigt, so muss eine paarweise Überprüfung der Verteilungen mit einem der
oben beschriebenen Verfahren vorgenommen werden. (Duller, 2008)
Der Kruskal-Wallis-Test kann ab drei Verteilungen mit einer Stichprobengröße von
jeweils mindestens 6 sinnvoll eingesetzt werden. In dieser Arbeit kommt er nur selten zum
Einsatz, da großteils lediglich die Signifikanz der Übereinstimmung zweier Verteilungen
überprüft werden muss.
11.3.3. Korrelationstest
Mit Korrelationstests wird geprüft, ob zwischen zwei Merkmalen ein Zusammenhang
besteht oder nicht. Je höher der Betrag des positiven oder negativen Wert des be-
rechneten Korrelationskoeffizienten ist, desto stärker ausgeprägt ist der positive bzw.
negative Zusammenhang zwischen den geprüften Stichproben. Um auf eine Korrelation
in der Grundgesamtheit schließen zu können, muss wiederum ein Signifikanztest (siehe
Abschnitt 11.3.2) verwendet werden, um zu prüfen, ob der berechnete Korrelationskoef-
fizient signifikant unterschiedlich von 0 ist.
Pearson-Test
Der Pearsonsche Korrelationskoeffizient kann verwendet werden, um den Zusammenhang
zwischen zwei metrischen Merkmalen zu berechnen. Zur Berechnung wird die Kovarianz
herangezogen, die als Maß für die Streuung der beiden Merkmale interpretiert werden
kann. Ist die Kovarianz gleich 0, so besteht kein Zusammenhang zwischen den beiden
Merkmalen. Das Vorzeichen der Kovarianz beschreibt, ob ein gleich- oder gegensinniger
Zusammenhang vorliegt. Je näher der Betrag des Korrelationskoeffizienten (Kovarianz
in Bezug zum Produkt der Standardabweichungen der Merkmale) bei 1 liegt, desto
stärker ist der Zusammenhang der beiden Merkmale. Der Korrelationskoeffizient misst
lediglich linear Zusammenhänge. Voraussetzung der Anwendung des Pearson-Tests ist
346
11.3. Eingesetzte Werkzeuge und Verfahren
eine annähernde Normalverteilung der Merkmale. Ist diese nicht gegeben, muss auf die
ordinalen Korrelationskoeffizienten nach Spearman oder Kendall zurückgegriffen werden,
wobei letzterer hier nicht näher betrachtet wird. (Duller, 2008)
Spearman-Test
Der Spearmansche Rangkorrelationskoeffizient kann verwendet werden, um den Zusam-
menhang zwischen zwei ordinalen Merkmalen zu berechnen. Wiederum zeigt das Vorzei-
chen des Koeffizienten an, ob ein gleich- oder gegensinniger Zusammenhang gegeben ist,
der betragsmäßige Wert des Koeffizienten gibt die Stärke der Korrelation an (wobei 0
keinen Zusammenhang anzeigt und gegen 1 gehende Werte einen starken Zusammengang
indizieren). Für den Test nach Spearman gelten die Voraussetzungen des Pearson-Test
nicht, insbesondere muss keine Normalverteilung der Merkmale vorliegen.
11.3.4. Fragebögen
Die in dieser Arbeit verwendeten Fragebögen (siehe Anhang B.3) beninhalten immer
geschlossenen und offenen Fragestellungen. Die geschlossenen Fragestellungen werden
jeweils auf einer 7-teiligen Likert-Skala bewertet. Die offenen Fragestellungen werden
zum Teil mit der Frage nach einer dichotomen Gesamt-Einschätzung gekoppelt (etwa
”zufrieden / nicht zufrieden”).
Durch den Einsatz der Likert-Skala sind die geschlossenen Items grundsätzlich als or-
dinale Merkmale zu sehen. Dies hat Auswirkungen auf die anwendbaren deskriptiven
Parameter und schließenden Tests. So kann unter anderem kein Mittelwert berechnet
werden, zur Hypothesen-Prüfung kann der t-Test nicht angewandt werden, da er metri-
sche Merkmale voraussetzt. Ist die Skala allerdings ausreichend differenziert (mehr als
fünf Ausprägungen) und sind die einzelnen Ausprägungen symmetrisch und äquidistant
formuliert (z.B: „sehr positiv – positiv – eher positiv – neutral – eher negativ – negativ –
sehr negativ“), so kann die Likert-Skala auch als (metrische) Intervallskala interpretiert
werden (Bortz und Döring, 2003, S. 222f), was eine Berechnung der oben genannten
Parameter und Tests ermöglicht. Diese Voraussetzungen sind in den verwendeten Frage-
bögen erfüllt, weswegen Mittelwert und Standardabweichung auch zur Beschreibung der
Fragebogenergebnisse verwendet werden. Bei Erfüllung der übrigen Anforderungen kann
deshalb auch der t-Test zur Hypothesen-Prüfung eingesetzt werden. Der Wilcoxon-Test
setzt ohnehin lediglich ordinal skalierte Merkmale voraus, so dass dieser ohne weitere
Annahmen angewendet werden kann.
347
11.3. Eingesetzte Werkzeuge und Verfahren
11.3.5. Interaktionsanalyse
Die Interaktionsanalyse nach Jordan und Henderson (1995) dient der qualitativen Aus-
wertung von Interaktionsabläufen zwischen unterschiedlichen Individuen und den dazu
eingesetzten Hilfsmitteln. Grundsätzlich wird die Interaktion aufgezeichnet und transkri-
piert. Das Transkipt enthält dabei nicht nur die verbale Interaktion, sondern auch eine
exakte Beschreibung der non-verbalen Aktivitäten der Beteiligten. Insbesondere wurde
hier auf die Erfassung der Verwendung der verfügbaren Hilfsmittel geachtet. Die Inter-
aktionsanalyse wurde von Hornecker (2004) zur Beschreibung der Wirkung von Tangible
Interfaces auf Kooperation zwischen Individuen eingesetzt. Die in diesem Kontext vor-
geschlagenen vereinfachte Variation der ursprünglichen Methode (v.a. der Verzicht auf
interdisziplinär zusammengesetzte Analysegruppen) wurde in dieser Arbeit übernom-
men.
Der Fokus der Analyse lag auf der Nutzung und Wirkung des eingesetzten Werkzeugs,
weshalb zur Transkription jene Szenen ausgewählt wurden, in denen diese sichtbar wird.
Transkripiert wurde jene Szenen, aus denen im Sinne der festgelegten Auswertungsebe-
nen Schlüsse auf die Verwendung des Werkzeugs, die Wirkung bei der Modellbildung
oder den Einfluss auf die Interaktion zwischen den Beteiligten gezogen werden können.
Dies umfasst Szenen, in denen
• das Werkzeug nicht in der in der Beschreibung des Interaktionsdesigns (siehe Ab-
schnitt 7.3) festgelegten Art verwendet wurde,
• die Funktionalität oder Bedienung des Werkzeugs missverstanden wurde,
• das Modell als Referenz verwendet wurde, um Sachverhalte individuell zu reflek-
tieren,
• das Modell von einem Teilnehmer als Referenz verwendet wurde, um anderen Teil-
nehmern Sachverhalte zu erklären,
• das Modell als Mittel zur Fokussierung der inhaltlichen Diskussion zwischen den
Teilnehmern verwendet wurde.
Bei der Transkription kam das von Hornecker (2004) vorgeschlagene Codierungssche-
ma zum Einsatz, das im Folgenden wiedergegeben ist: „Zeilenweise Transkription nach
einfachem, sequentiellem Schema. Zeitlicher Ablauf wird durch die Nummerierung vorne
wiedergegeben. Fehlt eine Zeilennummer, so findet das Beschriebene mehr oder minder
parallel mit dem Geschehen der darüberstehenden Zeile statt. Zusätzlich alle zehn Sekun-
den Zeitstempel in eigener Zeile. Sprünge in Zeilennummern zeigen Auslassungen in der
Transkription an. Nur angedeutet werden Betonung und Zeitverhalten des Sprechens.
Die Zeitdauer von Gestik und manueller Handlung ergibt sich aus den Beschreibungen.“
In der Darstellung werden dieses Codierungsschema wiefolgt dargestellt (ebenfalls an-
gelehnt an Hornecker (2004)):
348
11.4. Zusammenfassung
Zusammenhang, Auslöser der Situation
Teilnehmer: Aussage
Teilnehmer: Aussage bzw. Handlung
Teilnehmer: Aussage (gleichzeitig mit der Aussage ausgeführte Tätigkeit,
eingefügt an jener Stelle, an der die Aktivität beginnt) Aussage
(Fortsetzung)
Interaktion zwischen Teilnehmern oder der Teilnehmer mit dem System
Teilnehmer: Aussage Teil der Interaktion bzw. Aussage, der für die
Prüfung der jeweiligen Hypothese relevant ist Aussage (Fortsetzung)
Beispielhaft dargestellt kann ein Transkript wiefolgt aussehen:
Teilnehmer versuchen mit dem Radiergummi und nur einem anderen Marker
einen Verbinder zu entfernen.
B: Können wir die nicht so auch einfach löschen?
C: Ja, mit dem Radiergummi.
B: Muss ich den jetzt zuerst so (Hält den Radiergummi zur Kamera)
hinhalten?
A: Nein, ich glaube, den musst du einfach da (zeigt auf den Verbinder)
drauf legen.
B legt den Radiergummi auf den vom System automatisch erstellten
Verbinder.
A: Und jetzt muss man (legt ein Markierungtoken auf den Verbinder)
Nein.
Der Verbinder lässt sich auf diese Art nicht löschen und die Teilnehmer
entscheiden sich, den Fehler mittels der Wiederherstellungsfunktion
zu beseitigen.
11.4. Zusammenfassung
In diesem Kapitel wurde das globale Untersuchungsdesign zur Evaluierung der hier vor-
gestellten Arbeit beschrieben. In den ersten Abschnitten wurden die zu evaluierenden
Aspekte identifiziert und beschrieben. Im Rahmen dieser Beschreibungen wurden auch
mögliche Ansatzpunkte für die konkrete Untersuchung angeführt, die die Basis für die
detaillierte Konzeption der Evaluierung dieser Aspekte in den Kapiteln 12 bis 14 bildet.
Im folgenden Abschnitt wurden die einzelnen im Rahmen der Evaluierung durchge-
führten Untersuchungen angeführt. Diese Untersuchungen fokussieren jeweils auf einen
der zu evaluierenden Aspekte. Ihnen liegt jeweils ein konkretes Szenario zugrunde, das
in einer Reihe von Anwendungen des Werkzeugs durch verschiedene Benutzer in Modelle
umgesetzt wird. Je nach Fokus der Untersuchung werden vor- und nachgelagerte bzw.
parallel ablaufende Aktivitäten in die Untersuchung mit einbezogen.
349
11.4. Zusammenfassung
Die ursprüngliche Zuordnung zwischen den zu evaluierenden Aspekten und den ein-
zelnen Evaluierungs-Blöcken ist in Tabelle 11.1 nochmals überblicksweise angeführt. Die
Zuordnung hatte jeweils Einfluss auf das Szenario, in dem das Werkzeug angewandt
wurde sowie auf das Untersuchungsdesign.
Tabelle 11.1.: Ursprüngliches globales Untersuchungsdesign
Werkzeug Modell Articulation
Work
Block 1 x
Block 2 x
Block 3 x
Block 4 x
Block 5 x
Im Zuge der Durchführung der Evaluierung erwies sich die strikte Zuordnung eines
Blocks zu genau einem zu evaluierenden Aspekt als nicht durchführbar. Tatsächlich
liefern Untersuchungen zu einem (im Sinne der Zielhierarchie) übergeordneten Aspekte
(von „unten“ nach „oben“: Werkzeug – Modell – „Articulation Work“) immer auch
Erkenntnisse zu den untergeordneten zu evaluierenden Aspekten. Die Zuordnung der
Evaluierungs-Blöcke zu den Aspekten verändert sich also wie in Tabelle 11.2 angegeben.
Diese Zuordnung liegt auch den oben angeführten Beschreibungen der Blöcke zugrunde,
in denen jeweils die Beiträge eines Blocks zu den zu evaluierenden Aspekten angegeben
wurden.
Tabelle 11.2.: Einfluss der Untersuchungen auf die zu evaluierenden Aspekte
Werkzeug Modell Articulation
Work
Block 1 x
Block 2 x x x
Block 3 x x
Block 4 x x x
Block 5 x x
11.4.1. Beitrag zur globalen Zielsetzung
Dieses Kapitel stellt die Konzeption der empirischen Untersuchung zur Prüfung der
Effektivität der Unterstützung von „Articulation Work“ dar. Dazu werden die in den
350
11.4. Zusammenfassung
Kapiteln 2, 3, 4 und 5 identifizierten Messkriterien zusammengefasst und hinsichtlich de-
ren Beitrag zur Effektivitätsprüfung beschrieben. Dies und die Entwicklung des globalen
Untersuchungsdesigns sowie die Beschreibung der notwendigen statistischen Methoden
führen zur abschließenden Beantwortung der Fragestellung 5 („Wie kann die Effektivität
der Unterstützung von expliziter Articulation Work beurteilt werden?“).
11.4.2. Weitere Verwendung der Ergebnisse
In den folgenden Kapiteln wird nun die Evaluierung der einzelnen Aspekte über die
Evaluierungsblöcke hinweg im Detail beschrieben. Dabei werden die Hypothesenbildung
bzw. die Entwicklung der Hypothesen über die Zeit, die möglichen Ansätze zur Evalu-
ierung der jeweiligen Hypothesen sowie das Untersuchungsdesign, das die Prüfung der
Hypothesen ermöglicht, beschrieben. Die Kapitel schließen jeweils mit einer Zusammen-
fassung der Ergebnisse der Hypothesenprüfung und einer Bewertung dieser Ergebnisse
im Kontext der globalen Zielsetzung, also der Unterstützung von expliziter „Articulation
Work“.
351
12. Evaluierung der Verwendbarkeit
des Werkzeugs
Im ersten Teil der empirischen Untersuchung wird die grundlegende Verständlichkeit
und Verwendbarkeit des Werkzeug geprüft. Ziel ist es hier, konzeptuelle und technische
Eigenschaften bzw. Verhaltensweisen des Werkzeugs zu identifizieren, die den Modellie-
rungsprozess behindern oder unterbrechen. Darunter fällt grundsätzlich jede Eigenschaft
und jede Verhaltensweise, die die Benutzer zwingt, sich mit dem technischen System an
sich zu beschäftigen und von der Erfüllung der eigentlichen Aufgabe ablenkt bzw. diese
unterbricht. Abbildung 12.1 stellt dieses Kapitel und dessen Aufbau im Kontext der
anderen inhaltlich vor- und nachgelagerten Kapitel dar.
Abbildung 12.1.: Kapitel „Evaluierung der Verwendbarkeit des Werkzeugs“ im Gesamt-
zusammenhang
Die Untersuchung wird daneben auch genutzt, um explorativ die inhaltliche Verwen-
dung des Systems zu untersuchen (d.h. wie es für seinen eigentlichen Verwendungszweck
– die Modellierung – eingesetzt wurde) und aus diesen Beobachtungen Hypothesen ab-
zuleiten, die in weiteren Schritten getestet werden.
352
12.1. Hypothesen
12.1. Hypothesen
In diesem Abschnitt werden die Hypothesen angeführt und begründet, die in diesem Teil
der empirischen Untersuchung geprüft werden. Die hier angegebenen Hypothesen gehen
auf die Eigenschaften des Werkzeugs in der Verwendung durch die Benutzer ein. Bei
der Hypothesenbildung wird auf den Verwendungszweck des Werkzeugs – die Unterstüt-
zung der Bildung diagrammatischer Modelle – zwar Rücksicht genommen, die Modelle
selbst sind jedoch nicht Gegenstand der Betrachtung und werden erst im nächsten Ka-
pitel behandelt. Nicht berücksichtigt wird außerdem die Verwendung des Werkzeugs zur
Unterstützung von „Articulation Work“ – diese ist Gegenstand von Kapitel 14.
12.1.1. Konzeptuell begründete Hypothesen
Die folgenden Hypothesen wurden aus der Aufgabenstellung (siehe Kapitel 1) sowie den
Anforderungen an das Werkzeug (siehe Kapitel 5) abgeleitet. Neben der Formulierung
der Hypothese ist jeweils die Begründung aus der Konzeption des Werkzeugs angeführt.
Der grundlegende Anspruch des Werkzeugs ist es, explizite „Articulation Work“ zu un-
terstützen. Wie in Teil I dieser Arbeit beschrieben, wird dies durch die Externalisierung
und Abstimmung von mentalen Modellen realisiert. Ein gängiges Mittel, um mentale
Modelle zu repräsentieren, ist die Verwendung von diagrammatischen Modellen, wozu
Methoden zur Externalisierung – wie Concept Mapping und Strukturlegetechniken –
genutzt werden. Das Werkzeug muss also die Repräsentation diagrammatischer Modelle
unterstützen. Die Prüfung der ersten Hypothese ermöglicht damit die Beurteilung der
Erfüllung der Anforderung 1 (siehe Seite 116).
Hypothese 1 Das Werkzeug ermöglicht die Repräsentation diagrammatische Modelle.
„Articulation Work“ ist immer in einen kooperativen Arbeitszusammenhang einge-
bettet. Die Kollaboration findet dabei nicht nur im produktiven Teil der Arbeit statt,
sondern hat immer auch Auswirkungen auf die „Articulation Work“. Jede Unterstüt-
zung von „Articulation Work“ muss damit auch in kooperativen Szenarien einsetzbar
sein. Dies gilt auch für das hier vorgestellte Werkzeug, das die kooperative Bearbeitung
einer Aufgaben (hier: der Externalisierung und Abstimmung mentaler Modelle) ermög-
lichen muss. Die Hypothese ist deshalb aus Anforderung 7 (siehe Seite 117) abgeleitet
und ermöglicht die Beurteilung deren Erfüllung.
Hypothese 2 Das Werkzeug ermöglicht kooperatives Arbeiten an einer Aufgabe.
Die Aspekte von Arbeit, die im Rahmen von „Articulation Work“ abzustimmen sind,
sind unterschiedlicher Natur. Naheliegend ist eine Abstimmung der Abläufe und Schnitt-
stellen zwischen Personen, aber auch nicht-prozedurale Information, wie das Verständnis
353
12.1. Hypothesen
der Struktur und Elemente eines Arbeitszusammenhangs kann Gegenstand von „Arti-
culation Work“ sein. Gleiches gilt für die im Rahmen der „Articulation Work“ abzustim-
menden mentalen Modelle – diese bilden die Basis für Handlungsentscheidungen, um-
fassen aber im Allgemeinen (in Abgrenzung zu Schemata) nicht nur handlungsleitende
Information, sondern auch Kontextinformation, die die Bewertung der wahrgenomme-
nen Situation ermöglicht. Dementsprechend muss ein Werkzeug zur Unterstützung von
expliziter „Articulation Work“ und damit der Externalisierung von mentalen Modellen
die Verwendung in unterschiedlichen Kontexten, d.h. für unterschiedliche zu externalisie-
renden Informationsstrukturen, die in mentalen Modellen abgebildet sind, ermöglichen.
Die Prüfung der unten formulierten Hypothese ermöglicht die Beurteilung der Erfüllung
der Anforderung 4 (siehe Seite 116).
Hypothese 3 Das Werkzeug ist gleichwertig für Modellierungsaufgaben in unterschied-
lichen Kontexten einsetzbar.
Die ersten drei hier formulierten Hypothesen sind unmittelbar aus der globalen Ziel-
setzung abgeleitet und bilden die grundlegenden Anforderungen an das Werkzeug bei
der Unterstützung von „Articulation Work“ ab. Die nun folgenden Hypothesen sind kon-
zeptuell nicht mehr direkt auf die globale Zielsetzung ausgerichtet, sondern prüfen die
Funktionalität des Werkzeugs, die den Modellbildungsprozess unterstützen soll.
Auf Basis der Möglichkeit zur Navigation durch die Entstehungsgeschichte des Mo-
dells besteht auch die Möglichkeit, vergangene Modellzustände wiederherzustellen. Das
Werkzeug unterstützt dabei die Benutzer durch die Ausgabe von schrittweisen Anwei-
sungen, die den aktuellen Modellzustand in den wiederherzustellenden Zustand überfüh-
ren. Allgemein bietet diese Funktionalität die Möglichkeit, erkannte Fehler im Modell
zu korrigieren, ohne dabei bereits repräsentierte Information zu verlieren. Im kollabora-
tiven Einsatz ermöglicht diese Funktionalität, alternative, individuelle Sichten auf den
abzustimmenden Sachverhalt zu repräsentieren und bietet dabei die Möglichkeit, einen
für alle Beteiligten akzeptablen Ausgangspunkt wiederherzustellen. Dies sollte die Be-
reitschaft zur experimentellen Veränderung von Modellen erhöhen. Die Prüfung dieser
Hypothese ermöglicht in der Folge die Beurteilung der Erfüllung der Anforderung 3
(siehe Seite 116).
Hypothese 4 Die Möglichkeit der Wiederherstellung vergangener Modellzustände för-
dert die Bereitschaft alternative Repräsentationen auszuprobieren.
Die letzten beiden Hypothesen dieses Abschnitts sind ausschließlich auf die Verwen-
dung des Werkzeugs an sich ausgerichtet und stehen nicht im Kontext von „Articulation
Work“ oder der Unterstützung der Externalisierung mentaler Modelle. Hypothese 5 steht
für den in der Zielsetzung formulierten Anspruch, dass das Werkzeug in den Hintergrund
treten muss und die Beschäftigung mit der eigentlichen Aufgabe nicht behindern darf.
Dabei wird hier nicht auf den konkreten Anwendungsfall – die Erstellung von Modellen
354
12.1. Hypothesen
– eingegangen, sondern lediglich die allgemeine Funktionsfähigkeit und Bedienbarkeit
des Werkzeugs betrachtet. Ersteres ist Gegenstand der Evaluierung der erstellten Mo-
delle, die in Kapitel 13 beschrieben werden. Die Prüfung dieser Hypothese ermöglicht
die Beurteilung der Erfüllung der Anforderung 1 (siehe Seite 116).
Hypothese 5 Das Werkzeug behindert die Modellbildung nicht.
Hypothese 6 geht davon aus, dass bei wiederholter Verwendung des Werkzeugs Lern-
und Gewöhnungseffekte auftreten, die die Verwendung erleichtern, beschleunigen und zu
weniger Fehlbedienung führen. Dies ist ein Effekt, der bei jedem Werkzeug zu erwarten
ist, dessen zugrunde liegenden Konzepte den Benutzern bewusst und verständlich sind.
Von dieser Voraussetzung kann durch die inhaltliche Einführung der Benutzer in die
das Werkzeug prägenden und motivierenden Ideen ausgegangen werden. Damit ist zu
erwarten, dass das Werkzeug bei wiederholtem Einsatz in den späteren Anwendungen ef-
fizienter (im Sinne von „schneller“ und „Fehlbedienungen vermeidend“) verwendet wird.
Die Prüfung dieser Hypothese ermöglicht die Beurteilung der Erfüllung der Anforderung
1 (siehe Seite 116).
Hypothese 6 Wiederholte Verwendung des Werkzeugs führt zu schnellerer Modellbil-
dung und weniger Fehlbedienungen.
Hinsichtlich der in Kapitel 5 formulierten Anforderungen können die hier formulierten
Hypothesen zusammenfassend wie in Tabelle 12.1 dargestellt eingeordnet werden. Die
Untersuchung der Hypothesen ist dabei der erste Schritt zur Prüfung der effektiven
Unterstützung von „Articulation Work“, für die eine Verwendbarkeit des Werkzeugs für
die Durchführung der vorgeschlagenen Methodik eine Voraussetzung ist.
Tabelle 12.1.: Hypothesen zur Benutzbarkeit des Werkzeugs und deren Bezug zu den
Anforderungen an das Werkzeug
Hypothese Anforderung
1 1
2 7
3 4
4 3
5 1
6 1
12.1.2. Explorativ gebildete Hypothesen
Neben den aus der Aufgabenstellung abgeleiteten Hypothesen wurden einige Hypothesen
auch während der Durchführung der einzelnen Evaluierungs-Blöcke gebildet. Diese Hy-
355
12.1. Hypothesen
pothesen sind spezifischer auf einzelne Aspekte des Werkzeugs ausgerichtet und decken
beobachtete Auffälligkeiten und Missverständnisse in der Verwendung des Werkzeugs
ab.
Die erste in diesem Zusammenhang beobachtete Auffälligkeit betrifft die Herstellung
von Verbindern zwischen einzelnen Modellelementen. Wie in Abschnitt 7.3.3 beschrieben,
existieren zwei Möglichkeiten, diese Funktion auszuführen. Einerseits können die beiden
Modellelemente, die verbunden werden sollen, mit Markierungs-Tokens ausgewählt wer-
den, woraufhin eine Verbindung hergestellt wird. Andererseits können Verbinder auch
durch das Zusammenführen der zu verbindenden Blöcke (bis sich deren Breitseiten be-
rühren) hergestellt werden. In der ersten Implementierung des Werkzeugs, die im Evalu-
ierungsblock 1 und im ersten Teil des zweiten Blocks verwendet wurde, war lediglich die
erste Variante verfügbar. Die Möglichkeit zur Herstellung von Verbindern wurde in den
in diesen Blöcken durchgeführten Anwendungen kaum eingesetzt. Dies führte einerseits
zur Bildung der Hypothese 13 (siehe Abschnitt 13.1.2), andererseits wurde bei ersten
Auswertungen der Beobachtungen der im Verhältnis zum übrigen Modellierungs-Prozess
hohe Zeit-Aufwand bei der Herstellung von Verbindern offensichtlich. Dieser Aufwand
ist den Maßnahmen zur Stabilisierung der Erkennungsleistung des Werkzeugs geschul-
det und kann mit dem eingesetzten Interaktionsablauf nicht reduziert werden. Aufgrund
einer Anregung eines Untersuchungsteilnehmers wurde deshalb die oben beschriebene
zusätzliche Möglichkeit zur Herstellung von Verbindungen implementiert. Zu untersu-
chen ist nun, ob diese Maßnahme die Nutzung von Verbindern bei der Modellbildung
tatsächlich erhöht.
Hypothese 7 Die Einführung der alternativen Möglichkeit zur Verbindungsherstellung
erhöht die Nutzung von Verbindern bei der Modellerstellung.
Die zweite hier aufgestellte Hypothese betrifft eine Auffälligkeit bei der Verwendung
des Löschtokens. Das Löschtoken wird verwendet, um das Werkzeug in einen Modus zu
versetzen, in dem Verbinder gelöscht werden können. Schon die konzeptuelle Einordnung
des Werkzeugs in Kapitel 10 zeigte Potential für Missverständnisse in der Verwendung
dieses Tokens (siehe z.B. die Abschnitte 10.9 und 10.11). Zusammengefasst liegt die aus
der Theorie ableitbare Problematik darin, dass durch die äußere Form des Tokens –
einem Radiergummi – eine Metapher für dessen Verwendung („ausradieren“ von Ele-
menten) suggeriert wird, die in dieser Form im Werkzeug nicht umgesetzt ist, da das
Token lediglich als Schalter fungiert. Erste Beobachtungen deuteten darauf hin, dass die
Verwendung des Löschtokens in dessen erster Implementierung tatsächlich unverständ-
lich oder missverständlich ist. Das Werkzeug wurde auf Basis dieser Beobachtungen
reimplementiert. Die Hypothese ist deshalb für beide Varianten zu prüfen.
Hypothese 8 Das Löschtoken ermöglicht intuitives Löschen von Modellelementen.
356
12.2. Untersuchungsdesign und Durchführung
12.2. Untersuchungsdesign und Durchführung
In diesem Abschnitt wird auf Basis der oben formulierten Hypothesen das Untersu-
chungsdesign abgeleitet und die Durchführung der Untersuchung beschrieben. Der erste
Teil des Abschnitts beschreibt die Operationalisierung der Hypothesen und damit die
Festlegung, wie diese konkret geprüft werden können. Im zweiten Teil des Abschnitts
wird die Durchführung der Prüfung beschrieben. Hier erfolgt neben der Zuordnung der
einzelnen Evaluierungsblöcke (siehe Abschnitt 11.2) auch die Darstellung rein beschrei-
bender Parameter der Werkzeugverwendung, die nicht unmittelbar in die Prüfung der
Hypothesen eingehen.
12.2.1. Operationalisierung
In diesem Abschnitt wird für jede Hypothese identifiziert, in welcher Form sie geprüft
werden kann. Dies umfasst die Festlegung der Messpunkte sowie der jeweiligen Mess-
und Auswertungsmethode (letztere bezugnehmend auf den in Abschnitt 11.3 beschrie-
benen Verfahren). Zudem werden jene Evaluationsblöcke festgelegt, die für die jeweilige
Untersuchung herangezogen wurden.
Für jede Hypothese wird also spezifiziert, anhand welcher Aspekte diese geprüft wer-
den kann (= abhängige Variablen). Zudem wird festgelegt welche Ausgangssituation
bei der Anwendung gewählt werden muss, um die Prüfung durchführen zu können (=
unabhängige Variable) und welche Faktoren die Beurteilung ggf. ungewollt beeinflussen
können (= Störvariablen).
Repräsentation diagrammatischer Modelle
Gegenstand dieses Abschnitts ist die Prüfung der Hypothese 1. Diese bezieht sich auf
die Eignung des Werkzeugs für die Repräsentation diagrammatischer Modelle.
Voraussetzung für die Prüfung der Hypothese ist der Einsatz von Modellierungsaufga-
ben, die so formuliert sind, dass es grundsätzlich möglich ist, sie durch die Beschreibung
in einem diagrammatischen Modell zu erfüllen. Keinen Einfluss auf die Untersuchung ha-
ben die eingesetzte Methodik sowie eventuell vorhandene Modellierungsvorkenntnisse,
da die grundsätzlich Möglichkeit der Erstellung diagrammatischer Modelle unabhängig
von der Art der Verwendung und von der Kompetenz der Benutzer ist.
Geprüft wird die Hypothese hier an der Repräsentation, die mit Hilfe des Werkzeugs er-
stellt wurde. Ein diagrammatisches Modell zeichnet nach (Larkin und Simon, 1987) aus,
dass in ihm Konzepte und deren Zusammenhänge visuell-graphisch dargestellt werden
können (in Abgrenzung zu textuellen Beschreibungen). Zur Bewertung der Hypothese
werden deshalb die erstellten Repräsentationen herangezogen und überprüft, ob sie den
357
12.2. Untersuchungsdesign und Durchführung
Anforderungen an ein diagrammatisches Modell – das Vorhandensein von Konzepten
und Beziehungen zwischen diesen – erfüllen.
Kooperatives Arbeiten
Gegenstand dieses Abschnitts ist die Prüfung der Hypothese 2. Dabei wird überprüft,
ob das Werkzeug kooperatives Arbeiten an einer Modellierungsaufgabe erlaubt.
Dazu muss eine Modellierungsaufgabe gewählt werden, in der die kooperatives Er-
stellung des Modells vorgesehen ist. Etwaige Modellierungsvorkenntnisse haben keinen
Einfluss auf die Beurteilung der hier betrachteten Hypothese.
Zur Beurteilung eignen sich in diesem Fall die Zeitverteilung der Beteiligung der ein-
zelnen Benutzer am Modellierungsvorgang, das Verhalten der Benutzer bei simultaner
Manipulation eines Modells auf der Modellierungsoberfläche sowie der subjektive Ein-
druck der Benutzer über deren Kooperation untereinander. Der erstgenannte Aspekt
kann quantitativ gemessen werden, wobei eine tendenziell zeitlich gleichverteilte Ein-
bindung der Beteiligten in die Modellbildung für die Annahme der Hypothese spricht.
Zusätzlich kann mittels dem zweiten und dritten Aspekt qualitativ beurteilt werden, ob
und wie eine kooperative Manipulation des Modells durch mehrere Benutzer gleichzeitig
möglich ist.
Einsetzbarkeit in unterschiedlichen Kontexten
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 3. Diese Hypo-
these zielt dabei auf die Eignung des Werkzeugs zur Modellbildung in unterschiedlichen
Kontexten, d.h. für unterschiedliche Modellierungsaufgaben ab.
Zur Beurteilung dieser Hypothese muss die Modellierungsaufgabe entsprechend den
unterschiedlichen Einsatzkontexten variiert werden. Etwaige Modellierungsvorkenntnisse
können die individuelle Beurteilung insofern beeinflussen, als dass Werkzeuge für eine
bestimmte Aufgabe als besser oder schlechter geeignet wahrgenommen werden.
Zur Prüfung der Hypothese bieten sich in diesem Fall die Wahrnehmung der Eig-
nung durch die Benutzer, die qualitativ beurteilt wird und die Korrelation der Größe
der erstellten Modelle mit der benötigten Modellierungsdauer an. Korrelliert die Modell-
größe positiv mit der Modellierungsdauer, so ist der Zeitanteil, der zu Beschäftigung mit
dem Werkzeug selbst (und nicht mit der Modellierungsaufgabe) tendenziell stabil. Dar-
aus kann abgeleitet werden, dass das Werkzeug die verglichenen Modellierungsaufgaben
gleich gut (oder schlecht) unterstützt.
358
12.2. Untersuchungsdesign und Durchführung
Wiederherstellung vergangener Modellzustände
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 4. Gegenstand
der Überprüfung ist die Verwendung der Wiederherstellungsfunktionalität zum Zwecke
der versuchsweisen Veränderung des Modells.
Zur Prüfung dieser Hypothese muss die Modellierungsaufgabe so gestaltet sein, dass
sinnvoll unterschiedliche Repräsentationen gebildet werden können. Modellierungsvor-
kenntnisse haben keine Auswirkungen auf diese Untersuchung.
Zur Beurteilung dieser Hypothese wird die Anzahl der Verwendungen der Wieder-
herstellungsfunktionalität zur Korrektur inhaltlich verworfener Repräsentationen heran-
gezogen. Höhere Werte deuten hier tendenziell auf eine Annahme der Hypothese hin.
Zusätzlich können qualitative Aussagen zur Nutzung dieser Funktionalität und deren
wahrgenommenen Nutzen zur Beurteilung verwendet werden.
Nicht-Behinderung
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 5. Dabei wird
überprüft, ob bei der Verwendung des Werkzeugs dieses in den Aufmerksamkeitsfokus
der Benutzer tritt oder sich diese auf die eigentliche Modellierungsaufgabe konzentrieren
können.
Die Modellierungsaufgabe hat keinen Einfluss auf die Überprüfung dieser Hypothese,
lediglich etwaig vorhandene Modellierungsvorkenntnisse können die Beurteilung beein-
trächtigen, da sie Einfluss auf die erwartete Funktionalität des Werkzeugs haben kann.
Zur Beurteilung, ob bzw. inwieweit das Werkzeug die Modellbildung behindert, werden
sowohl quantitativ als auch qualitativ beurteilbare Metriken herangezogen. Die Anzahl
von Fehlfunktionen des Werkzeugs bzw. das Auftreten von Systemabstürzen kann als
Indikator für eine behindernde Wirkung des Werkzeugs herangezogen werden. Das Auf-
treten von Missverständnissen und daraus resultierende Fehlbedienungen können eben-
falls eine Behinderung des Modellierungsvorgangs interpretiert werden. Zudem werden
Aussagen der Benutzer hinsichtlich hinderlicher Faktoren bei der Werkzeugbenutzung
als Maß für die wahrgenommene Behinderung durch das Werkzeug herangezogen.
Gewöhnung an das Werkzeug
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 6. Dabei wird
überprüft, ob wiederholte Benutzung des Werkzeugs Auswirkung auf die Qualität der
Interaktion hat. Eine Erhöhung der Qualität äußert sich in schnellerer Modellbildung
und weniger Fehlbedienung.
Bei der Prüfung der Hypothese muss eine etwaige veränderte Funktionalität des Werk-
zeugs zwischen den verglichenen Evaluierungsblöcken berücksichtigt werden, die die In-
359
12.2. Untersuchungsdesign und Durchführung
teraktion einerseits erleichtern kann, andererseits aber auch zu Fehlbedienung aufgrund
von unbekannten Interaktionsmustern führen kann. Auch unterschiedliche Modellie-
rungsaufgaben, die ein Individuum in den aufeinander folgenden Anwendungen bear-
beitet, können die Beurteilung erschweren, weil potentiell andere (noch unbekannte)
Funktionen des Werkzeugs zum Einsatz kommen können.
Zur Beurteilung der Qualität der Interaktion sind einerseits die Anzahl der Fehlbe-
dienungen des Werkzeugs pro Zeiteinheit und andererseits die Arbeitsdauer am Werk-
zeug1 in Abhängigkeit der Modellgröße heranzuziehen. Die Normierung der Arbeitsdauer
ist notwendig, um vergleichbare Werte für unterschiedliche Werkzeug-Anwendungen zu
erhalten. Sinken beide Werte zwischen zwei Evaluierungsblöcken, die auf der gleichen
Stichprobe aufbauen, signifikant, so kann die Hypothese bestätigt werden. Um eine Ver-
gleichbarkeit zwischen den Anwendungen herzustellen, ist es sinnvoll, in beiden Blöcken
eine identische Modellierungsaufgabe zu stellen und die Funktionalität des Werkzeugs
nicht zu verändern. Identische Modellierungsaufgaben können durch die wiederholte in-
haltliche Beschäftigung mit der Aufgabe zu schnellerer Arbeit bzw. zu kompakteren
Modellen führen. Dies kann wiederum durch die Berücksichtigung der reinen Arbeits-
zeit am Werkzeug sowie der Normierung derselben in Abhängigkeit der Modellgröße
kompensiert werden.
Herstellung von Verbindern
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 7. Mit Hilfe
dieser Hypothese soll überprüft werden, ob die Einführung der alternativen Möglichkeit
zur Herstellung von Verbindern deren Verwendung signifikant gesteigert hat.
Bei der Messung muss der Einfluss der Modellierungsaufgabe (da sie die Anzahl der
benötigten Verbinder beeinflussen kann) und eventuell vorhandene Modellierungsvor-
kenntnisse (da diese Einfluss auf die Struktur des Modells haben können) berücksich-
tigt werden. Um den Einfluss dieser Aspekte zu reduzieren, wird die Beurteilung in
zwei Evaluierungsblöcken vorgenommen, in denen die gleiche Stichprobe mit der glei-
chen Aufgabenstellung das Werkzeug mit der gleichen Methodik verwendet. Lediglich
die Funktionalität des Werkzeugs wurde zwischen den beiden Anwendungen um den
alternativen Weg zur Herstellung von Verbindern erweitert.
Zur Beurteilung des Ausmaßes der Verwendung von Verbindern kann die Connected-
ness des Modells herangezogen werden. Die Connectedness ist das Verhältnis zwischen
der Anzahl der im Modell verwendeten Verbinder und der Anzahl der verwendeten
Knoten (Modellierungselemente). Hier ist zu prüfen, ob die Connectedness in jenem
Evaluierungs-Block, in dem der alternative Weg zur Herstellung von Verbindungen ver-
fügbar war, signifikant höher ist als in jenem Block, in dem sie nicht verfügbar war.
1Die Arbeitsdauer am Werkzeug ist im Gegensatz zur gesamten Modellierungsdauer um jenen Zeitan-
teil reduziert, in dem die Teilnehmer interagieren, ohne am Werkzeug zu arbeiten.
360
12.2. Untersuchungsdesign und Durchführung
Verwendung des Löschtokens
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 8. Dabei wird
überprüft, ob das Löschtoken intuitiv korrekt verwendet wird oder ob es zu Fehlinter-
pretationen kommt.
Die Verwendbarkeit des Löschtokens ist unabhängig von der Modellierungsaufgabe, der
angewandten Methodik und auch von eventuell vorhandenen Modellierungsvorkenntnis-
sen. Hinsichtlich des Anwendungskontextes des Werkzeugs sind also keine Voraussetzun-
gen zu beachten.
Zur Beurteilung der intuitiven Verwendbarkeit werden quantitative und qualitative
Merkmale der Werkzeugverwendung herangezogen. Quantitativ beurteilbar ist der Anteil
der Fehlbedienungen des Löschtokens in Bezug auf alle Anwendungen des Werkzeugs, in
denen es grundsätzlich verwendet wurde. Qualitativ wird die Art des Missverständnisses,
das zu den jeweiligen Fehlbedienungen führt, beurteilt.
Zur Messung der quantitativen Variablen wird für jede Anwendung die Anzahl der
Fehlbedienungen erhoben, die durch das Löschtoken verursacht wurden. Diese Anzahl
wird ins Verhältnis zur Gesamtzahl der Anwendungen des Löschtokens bzw. zur gesam-
ten Anzahl der Löschvorgänge gesetzt. Zu letzterer zählen neben den Anwendungen des
Löschtokens auch Fehlerkorrekturen durch Verwendung der Wiederherstellungsfunkion.
Da die zweite Möglichkeit sowohl zeit- als auch ressourcenaufwändiger zu verwenden ist
als der Einsatz der Löschtokens deutet ein hoher Anteil der Verwendung dieser Funkti-
on auf funktionale Probleme oder Verständnisprobleme der eigentlichen Löschfunktion
mittels dem Löschtoken hin.
Qualitativ werden Modellierungssituationen betrachtet, in denen das Löschtoken zum
Einsatz kommt. Auf Basis von Transkripten der Interaktion zwischen den Benutzern
und dem Werkzeug, bei denen es zu Fehlbedierungen kam, werden die aufgetretenen
Missverständnisse explizit identifziert.
12.2.2. Durchführung
In diesem Abschnitt werden die für diesen Evaluierungs-Teil relevanten deskriptiven Pa-
rameter der berücksichtigten Anwendungs-Blöcke angeführt. Als Grundlage der Über-
prüfung der Hypothesen werden hier die Evaluierungsblöcke 1 bis 5 verwendet. Dabei
wurden für die quantitativ zu prüfenden Variablen die Blöcke 2, 3 und 5 herangezogen,
da in diesen die größten Stichproben zur Verfügung standen. In die qualitative Auswer-
tung der Ergebnisse wurden hingegen alle Blöcke (1-5) mit einbezogen.
361
12.2. Untersuchungsdesign und Durchführung
Stichprobe
Für die Untersuchung der Hypothesen in diesem Kapitel wurden die Evaluierungsblöcke
1 bis 5 herangezogen. Die Stichprobe setzt sich wie in Tabelle 12.2 beschrieben zusam-
men.
Tabelle 12.2.: Stichproben der Evaluierung zur Werkzeugverwendung
Evaluierungsblock nAnwendungen nTeilnehmende
1 technische Evaluierung 9 18
2a Aushandlung 1 (1. Durchgang) 9 19
2b Aushandlung 1 (2. Durchgang) 9 18
3 Concept Mapping 1 18 54
4 Aushandlung 2 10 13
5 Concept Mapping 2 (Tisch) 11 24
Gesamt 66 146
Dauer der Werkzeugverwendung
Die Dauer der Werkzeug-Verwendung wurde in allen Evaluierungsblöcken erhoben. Die
Bearbeitungszeit ist wie in Tabelle 12.3 dargestellt verteilt (siehe auch Abbildung 12.22):
Die erhobene Dauer der Werkzeug-Verwendung teilt sich ein einen Anteil, an dem tat-
sächlich mit dem Werkzeug interagiert wird und einen Anteil, der anderen Tätigkeiten
(wie inhaltlicher Diskussion, Bedeutungsaushandlung, . . . ) gewidmet ist. Diese beiden
Anteile sind in den Evaluierungsblöcken 2 und 3 wie in den Abbildungen 12.3 und
12.4 dargestellt verteilt. Diese beiden Evaluierungblöcke wurden prototypisch als Reprä-
sentanten unterschiedlicher Aufgabentypen („ablauforientierte Strukturen“ in Evaluie-
rungblock 2 und „konzeptuelle Strukturen“ in Evaluierungsblock 3) ausgewählt, die auch
2In allen Boxplots gilt folgende Notation:
• dicke Linie bzw. Box: Bereich zwischen 25%- und 75%-Quantil
• breite Linie quer zur Hauptachse: Median (in horizontalen Boxen) bzw. Mittelwert (in vertikalen
Boxen)
• linke bzw. untere schmale Linie: Bereich zwischen 2,5%- und 25%-Quantil
• rechte bzw. obere schmale Linie: Bereich zwischen 75%- und 97,5%-Quantil
• Kreuze bzw. Kreise: Ausreißer (außerhalb 2,5%- und 97,5%-Quantil)
362
12.2. Untersuchungsdesign und Durchführung
Tabelle 12.3.: Dauer der Werkzeugverwendung
Evaluierungsblock tmin t sd(t) tmax
technische Evaluierung 5:00 07:49 2:13 12:00
Aushandlung 1 (1. Durchgang) 11:54 20:53 4:18 27:30
Aushandlung 1 (2. Durchgang) 2:05 9:49 5:20 19:29
Concept Mapping 1 14:01 32:32 10:07 45:00
Aushandlung 2 15:09 36:25 13:29 60:12
Concept Mapping 2 (Tisch) 21:08 34:18 9:11 54:00
Format der Zeitangaben: mm:ss
Abbildung 12.2.: Dauer der Werkzeugverwendung – Überblick
363
12.3. Ergebnisse
in den übrigen Evaluierungsblöcken zu identifizieren sind (in Evaluierungsblock 4 traten
beide Typen auf, Evaluierungblock 5 erfordert die Abbildung konzeptueller Strukturen).
Abbildung 12.3.: Dauer der Werkzeugverwendung – Evaluierungblock 3
12.3. Ergebnisse
In diesem Abschnitt werden die Ergebnisse der Untersuchung gegliedert nach den oben
formulierten Hypothesen dargestellt. Zu jeder Hypothese wird die Auswertung der em-
pirischen Daten dargestellt, die Bedeutung der empirischen Belege für die Prüfung der
jeweiligen Hypothese diskutiert und letztendlich das Ergebnis zusammenfassend darge-
stellt.
12.3.1. Repräsentation diagrammatischer Modelle
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 1 („Das Werkzeug er-
möglicht die Repräsentation diagrammatischer Modelle.“). Als Grundlage dieser Unter-
suchung dienen die Ergebnisse aller Evaluierungsblöcke, da die Aufgaben in allen Fällen
auf die Erstellung einer Repräsentation in Form eines diagrammatischen Modells gefor-
dert war.
Ausgewertet wird hier, ob die Ergebnisse der Modellierung jeweils als diagramma-
tisches Modell zu klassifizieren sind. Ein diagrammatisches Modell zeichnet sich nach
(Larkin und Simon, 1987) dadurch aus, dass in ihm Konzepte und deren Zusammenhän-
ge visuell-graphisch dargestellt werden. Eine Darstellung von Beziehungen kann durch
364
12.3. Ergebnisse
Abbildung 12.4.: Dauer der Werkzeugverwendung – Evaluierungblock 2
die explizite Darstellung von Verbindungen zwischen Konzepten oder durch andere gra-
phische Mittel wie Gruppierung von Konzepten in räumlicher Nähe erfolgen. Um eine
eindeutige Auswertbarkeit gewährleisten zu können, wird hier auf die explizite Darstel-
lung von Verbindungen eingeschränkt.
Auswertung
In allen vorliegenden Modellen wurden Konzepte als Grundelemente des diagrammati-
schen Modells verwendet. Das Kriterium zur Klassifizierung als diagrammatisches Modell
ist im Folgenden also das Vorhandensein von Verbindungen. Bei der Auswertung ergab
sich die in Tabelle 12.4 dargestellte Verteilung.
Tabelle 12.4.: Anzahl der Modelle mit Verbindern
Block Modelle gesamt Modelle mit Verbindern
1 9 0
2 18 9
3 18 17
4 10 10
5 11 11
Gesamt 66 47
365
12.3. Ergebnisse
Insgesamt sind in 66 Modellen, die als Ergebnis vorliegen, 47 Modelle zu identifizieren,
in denen explizit Verbindungen zur Darstellung von Beziehungen zwischen Konzepten
verwendet werden (71, 2%). Eine implizite Darstellung von Beziehungen ist jedoch in
allen vorliegenden Modellen zu erkennen. Nicht explizit durch Verbindungen abgebildete
Beziehungen werden in allen Fällen durch die räumliche Konfiguration der Konzepte
zueinander dargestellt.
Diskussion
Legt man das Kriterium des Vorhandenseins von Verbindungen zwischen Konzepten
an, so sind 71, 2% der betrachteten Modelle als diagrammatische Modelle zu klassifizie-
ren. Dies ist vordergründig ein geringer Wert, die gegen die allgemeine Gültigkeit der
Hypothese spricht. Allerdings sind in allen Modellen implizite Verbindungen zwischen
Konzepten eindeutig zu identifizieren. Außerdem ist zu erkennen, dass der Anteil an dia-
gramatischen Modellen über die Evaluierungsblöcke (und damit die Weiterentwicklung
des Werkzeugs über die Zeit) hinweg stetig ansteigt, bis er in den letzten beiden Blöcken
jeweils 100% erreicht. Dies ist durch technische Fehlfunktionen zu erklären, die es in ers-
ten Evaluierungsblöcken schwer bzw. teilweise unmöglich machten, intentional explizite
Verbindungen zu erstellen. Unter Anbetracht dieser Erkenntnisse ist die Annahme der
Hypothese 1 gerechtfertigt.
Die Abbildung von Verbindungen durch räumliche Konfiguration ist Gegenstand der
Prüfung von Hypothese 13 in Kapitel 13 und wird dort einer näheren Betrachtung un-
terzogen.
Ergebnis
Hypothese 1 kann auf Basis der Untersuchung bestätigt werden. Die Abbildung
von Konzepten und Beziehungen zwischen diesen wurde in allen vorliegenden Modellen
erfolgreich umgesetzt, wenngleich die Modellierung von expliziten Verbindungen in den
ersten beiden Evaluierungsblöcken aufgrund von technischen Unzulänglichkeiten nicht
durchgeführt wurde.
12.3.2. Kooperatives Arbeiten
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 2 („Das Werkzeug er-
möglicht kooperatives Arbeiten an einer Aufgabe.“). Zur Untersuchung der quantitativ
beurteilbaren Aspekte wurden die Werkzeuganwendungen aus den Evaluierungsblöcken
2 (n = 18), 3 (n = 18) und 5 (n = 11) herangezogen, wobei in Block 2 und 5 in Gruppen
zu zwei Personen modelliert wurde (in insgesamt drei Fällen drei Personen), in Block 3
366
12.3. Ergebnisse
in Gruppen zu drei Personen (in drei Fällen nur zwei Personen). Zusätzlich wurden zur
qualitative Beurteilung Daten aus den Blöcken 4 und 5 verwendet.
In den Evaluierungsblöcken 4 und 5 wurde hinsichtlich der subjektiven Wahrnehmung
der Kooperation eine Befragung der Teilnehmer mittels eines Fragebogens durchgeführt
(diese umfasste auch weitere Aspekte, die in späteren Abschnitten besprochen werden).
Die Fragestellungen zur Kooperation wurde in geschlossenen Items codiert, die auf einer
7-teiligen Likert-Skala zu beantworten waren (zu den konkreten Fragebogen-Items siehe
weiter unten sowie Anhang B). Zusätzlich wurden offene Fragen hinsichtlich der Nütz-
lichkeit der Werkzeugs eingesetzt, die an dieser Stelle ebenfalls hinsichtlich Aussagen zur
Kooperation zwischen den Teilnehmern ausgewertet werden.
Zur Auswertung dieser Hypothese wurden außerdem die Interaktionsanalyse berück-
sichtigt, die in den Evaluierungsblöcken 2 bis 5 durchgeführt wurden. Herangezogen
wurden dabei jene Szenen, in denen die Kooperation zwischen den jeweiligen Teilneh-
mern im Vordergrund stand.
Auswertung
Grundlage des ersten Teils der Auswertung ist die Verteilung der Modellierungsdauer
zwischen den Teilnehmern. Um die unterschiedliche Gesamt-Modellierungsdauer in den
einzelnen Anwendungen zu kompensieren, wurden die Berechnungen auf Basis der pro-
zentuellen Zeitanteile der einzelnen Teilnehmer durchgeführt. Die einzelnen Datensätze
wurden so sortiert, dass die anteilsmäßige Modellierungsdauer von Teilnehmer A bis
Teilnehmer C (bzw. B) abnimmt. In den einzelnen Evaluierungsblöcken ergeben sich die
in Abbildung 12.5 dargestellten Verteilungen.
Abbildung 12.5.: Zeitverteilung zwischen den Teilnehmern (1 .. TN A, 2 .. TN B, 3 ..
TN C)
367
12.3. Ergebnisse
Zu prüfen ist hier, ob die Zeit-Anteile der einzelnen Teilnehmer signifikant unterschied-
lich sind. Dazu wird für über die Evaluierungsblöcke hinweg die Signifikanz zwischen den
Verteilungen der einzelnen Teilnehmerklassen berechnet (eine Teilnehmerklasse setzt sich
aus all jenen Teilnehmern zusammen, die am längsten, am zweitlängsten bzw. am dritt-
längsten aktiv waren).
Für jene Anwendungen, an denen 2 Teilnehmer beteiligt waren (n = 28) lag der durch-
schnittliche Zeitanteil an der Modellierung für Teilnehmer A bei 65.4% (SD = 12.2%),
jener von Teilnehmer B lag bei 34.6% (SD = 12.2%). Die Zeitanteile unterscheiden
sich damit signifikant voneinander, es ist keine Gleichverteilung der Modellierungszeiten
gegeben (zweiseitiger Wilcoxon-Test für gepaarte Stichproben: V = 351, p < 0.0053).
Für jene Anwendungen, an denen 3 Teilnehmer beteiligt waren (n = 19) lag der durch-
schnittliche Zeitanteil an der Modellierung für Teilnehmer A bei 49.3% (SD = 7.2%),
jener von Teilnehmer B lag bei 33.1% (SD = 5.9%) und jener von Teilnehmer C bei
17.6% (SD = 8.2%). Die Zeitanteile unterscheiden sich damit signifikant voneinander,
es ist keine Gleichverteilung der Modellierungszeiten gegeben (Kruskal-Wallis-Test für
mehr als zwei Stichproben: χ2 = 43.65, df = 2, p < 0.0054).
In den Evaluierungsblöcken 4 und 5 wurden die Teilnehmer quantitativ und qualitativ
nach dem Einfluss des Werkzeugs auf die Kooperation befragt. In der quantitativen
Auswertung wurden 4 Items (Abschnitt „Kollaboration beim Modellieren“ in Block 4
– siehe Anhang B.3.2 – und Abschnitt „Kollaboratives Modellieren“ in Block 5 – siehe
Anhang B.3.3) betrachtet. Die Items lauten im Einzelnen:
1. Die Zusammenarbeit als Team empfand ich als angenehm.
2. Die Zusammenarbeit als Team fand ich als nützlich.
3. Ich konnte meine persönliche Meinung und Ideen ausreichend einbringen.
4. Das Werkzeug hat die Zusammenarbeit als Team erleichtert.
Insgesamt wurden n = 37 Teilnehmer befragt. Die Ergebnisse sind in Tabelle 12.5
und Abbildung 12.6 zusammengefasst dargestellt. Neben dem Mittelwert und der Stan-
dardabweichung wurde für jedes Item auch geprüft, ob die Einschätzung als signifikant
positiv zu bezeichnen ist. Dazu wurde ein einseitiger Wilcoxon-Test für die Stichprobe
gegenüber dem Skalenmittelwert 4 durchgeführt Der Wilcoxon-Test muss angewandt
werden, da die Stichprobe in allen vier Fällen nicht normalverteilt ist (Shapiro-Wilk-
3Der t-Test kann nicht angewandt werden, da beide Stichproben nicht normalverteilt sind (Shaprio-
Wilk-Test: WTNA = 0.826, pTNA < 0.005, WTNB = 0.820, pTNB < 0.005).
4Der t-Test könnte grundsätzlich für die paarweise Testung ebenfalls angewandt werden, da für alle drei
Stichproben nicht davon ausgegangen werden kann, dass sie nicht normalverteilt sind (Shaprio-Wilk-
Test: WTNA = 0.9075, pTNA = 0.078, WTNB = 0.9523, pTNB = 0.463, WTNC = 0.9523, pTNC =
0.463) und auch der Test der Varianzen eine Gleichheit derselben vermuten lässt (paarweiser F-Test:
FAB = 1.47, pAB = 0.434, FAC = 0.778, pAC = 0.610, FBC = 0.528, pBC = 0.199). Die errechneten
paarweisen Werte für t weisen ebenfalls jeweils einen signifikanten Unterschied der Zeitanteile hin
(tAB = 7.32, tAC = 12.30, tBC = 6.49, p jeweils < 0.005)
368
12.3. Ergebnisse
Test: W1 = 0.723, p1 < 0.005, W2 = 0.494, p2 < 0.005, W3 = 0.751, p3 < 0.005,
W4 = 0.853, p4 < 0.005)).
Tabelle 12.5.: Befragung Kooperative Modellierung – Itemauswertung
Item M SD VM<4 pM<4
1 1.51 0.61 0 <0.005
2 1.62 1.04 27.5 <0.005
3 1.62 0.79 0 <0.005
4 2.16 1.14 4 <0.005
Abbildung 12.6.: Verteilung der Benutzereinschätzungen zum kooperativen Modellieren
In der qualitativen Befragung begründeten insgesamt 29 Teilnehmer ihren Eindruck
(Fragestellung: „Sind Sie zufrieden mit ihrem Beitrag zum Modellierungsprozess? Geben
Sie bitte auch eine kurze Begründung an.“). Die Ergebnisse sind im Folgenden inhaltlich
gruppiert dargestellt:
• pos: alle Teilnehmer haben Ideen eingebracht (6x)
• pos: gute Teamarbeit (5x)
• pos: konnte meine Ideen einbringen (5x)
• pos: Konsens gefunden (4x)
• pos: gute Kommunikation (3x)
• pos: alle Teilnehmer gleichgestellt (2x)
• neg: Werkzeug an Grenzen gestoßen (2x)
369
12.3. Ergebnisse
• neg: hatte zuwenig Wissen (1x)
• neg: Arbeit am Werkzeug war zu zeitaufwändig (1x)
Zudem konnten in der Videoanalyse der Evaluierungsblöcke 2, 3, 4 und 5 vielfach
Situationen identifiziert werden, in denen das Modell auf der Tischoberfläche von den
Teilnehmern als Referenz für den Austausch über die abgebildeten Inhalte herangezogen
wurden oder in denen mehrere Teilnehmer gleichzeitig das Modell manipulierten. In der
Folge werden prototypisch einige Situationen dargestellt, die derartige Interaktionsab-
läufe zeigen5:
Beispiel für gleichzeitige Manipulation
A: Sollen wir die beiden auch verbinden?
C: Sicher. (greift zu rotem Block)
A: OK. (greift zu blauem Block)
A und C schieben die Blöcke zusammen und anschließend wieder in die
ursprüngliche Position. Anschließend setzt B den nächsten blauen Block
auf die Arbeitsfläche, und verbindet ihn mit dem roten Block.
Beispiel für Referenzierung des Modells
B: Die Übung (deutet auf roten Block) ist eigentlich nicht notwendig.
A: Naja, es ist halt unter einem schönen Knoten.
C: Nennen wir das (tippt auf roten Block) Ziele.
A: Nein, wieso? Ich kann ja mehrere Bedeutungen für das (deutet auf
roten Block) verwenden. Das ist doch egal. Das sagt ja nichts aus.
C: Aber wir können das (deutet auf roten Block) weggeben und sagen,
das sind die Ziele. Was ist das Ziel.
A: Das können wir machen, oder wir legen einfach einen roten dazu
(deutet an, wo der rote Block liegen würde) und schreiben es hin.
A verschiebt den roten Block, um Platz für einen neuen Block zu
schaffen.
Beispiel für gleichzeitige Manipulation
Die Teilnehmer haben zuvor alle Blöcke beschriftet und wollen sie nun
verbinden bzw. in die richtige Position bringen.
B: So und jetzt müssen wir eigentlich . . . (greift zum ersten Block
und schiebt ihn zum Knotenpunkt, um ihn zu verbinden, danach bringt
er den Block wieder in seine ursprüngliche Position)
5Die ausgewählten Transkripte stammen aus Evaluierungsblock 3. Sämtliche Transkripte sind unter
den in Anhang B angeführten Quellen zu beziehen.
370
12.3. Ergebnisse
C: Jawohl.
Teilnehmer B wiederholt Vorgang mit dem zweiten Block. Teilnehmer C
greift inzwischen zum dritten Block, um es B nachzumachen. B nimmt
anschließend den nächsten Block und verbindet ihn. Den letzten Block
verbindet wieder C. Beim Zurückschieben verschwindet die Verbindung
von der Arbeitsfläche.
A: Das erkennt er nicht. (schiebt den Block wieder ein Stück zurück)
System zeigt Verbindung wieder an.
C: Passt. Schiebt Block wieder zurück.
A: So, und jetzt noch schön anordnen.
A greift die unteren Blöcke und richtet sie in einer Linie aus, während
C den ober Block zentriert. System reagiert etwas verzögert. B lacht.
A: Ok. Passt.
In der Folge beraten die Teilnehmer über die weitere Vorgangsweise.
Beispiel für Referenzierung des Modells
Teilnehmer diskutieren über die beiden Modellierungssprachen.
A: In der Softwareentwicklung würde man das Analyse (deutet auf oberen
Teil der Arbeitsfläche) und das Design (deutet auf unteren Teil der
Arbeitsfläche) nennen.
B: Genau.
A: Und dann hinterlegst du es mit deinen mathematischen Modellen
(deutet Modelle mit Handbewegung an) in der Implementierung und dann
kann ich es ausführen.
B: Ja. Alles ablauforientiert das Ganze.
A: (deutet auf blauen Baustein) Genau, von der Sicht her. Die Sicht,
die es einnimmt (deutet auf gelbe Blöcke) ist genau dieselbe, aber
der Scope vom Zeitpunkt ist genau.
B: unterschiedlich
A: Genau, SeeMe, ARIS (deutet Modelle an) und dann Workflow Systeme
im Wesentlichen.
Diskussion
In der Verteilung der Zeitanteile der Beteiligung an der Modellierung zeigt sich, dass der
Anteil von Teilnehmer A (dem Teilnehmer mit dem jeweils höchsten Zeitanteil) signi-
fikant höher ist als jener von Teilnehmer B. In jenen Fällen, in denen drei Teilnehmer
beteiligt sind, ist der Zeitanteil des am kürzesten beteiligten Teilnehmers signifikant
geringer als jener der anderen beiden. Dieses Ergebnis zeigt, dass für Anwendungssitua-
tionen mit mehreren Teilnehmern eine Beteiligung im gleichen Ausmaß nicht erwartet
371
12.3. Ergebnisse
werden kann. Insgesamt spricht dieses Ergebnis also gegen die Bestätigung der Hypo-
these.
Dies ist aber insofern zu relativieren, als dass eine statistisch signifikante Gleichver-
teilung nicht erwartet werden kann. Betrachtet man die Mittelwerte der Zeitanteile der
Teilnehmer, so zeigt sich, dass – zumindest für Anwendungen mit zwei Teilnehmern –
eine Beteiligung jeweils durch alle Teilnehmer gegeben ist. Der höhere Zeitanteil von Teil-
nehmer A ist unter Umständen auch auf den exklusiven Zugriff auf die zur Benennung
von Modellierungsblöcken notwendige Tastatur zu erklären. Die Bedienung der Tastatur
wurde nur in wenigen Fällen geteilt, so dass ein Teilnehmer durch die Durchführung der
Benennungstätigkeit naturgemäß einen stärkeren Anteil an der Arbeitszeit in Anspruch
nimmt. Bei drei Teilnehmern zeigt sich jedoch eine deutliche Abnahme des Zeitanteils
für jenen Teilnehmer, der den geringsten Zeitanteil in Anspruch nahm. Dieser Effekt
verstärkt sich – wie aus Beobachtungen der Anwendungen in Evaluierungsblock 4 zu
erkennen (siehe (Wahlmüller, 2010)) – für Anwendungen mit mehr als drei Teilnehmern.
Hier sind jeweils tendenziell zwei Beteiligte zu identifizieren, die zusammen mehr als
zwei Drittel der Modellierungszeit für sich in Anspruch nehmen.
In der Befragung der Benutzer hinsichtlich der wahrgenommenen Möglichkeit zur Ko-
operation wird deutlich, dass diese durchwegs als hoch eingeschätzt wird (dies gilt sowohl
für die Anwendungen mit zwei Teilnehmern in Block 5 als auch für die Anwendungen
mit drei und mehr Teilnehmern in Block 4). Auch in den qualitativen Rückmeldungen
zur Kooperation wird das Werkzeug hinsichtlich seiner Wirkung positiv beurteilt. Die
Antworten auf die offenen Fragestellungen zeigen ebenfalls eine vorwiegend positive Ein-
schätzung der Wirkung des Werkzeugs auf die Kooperation zwischen den Teilnehmern.
Das Ergebnis der Befragung spricht also insgesamt für die Bestätigung der Hypothese.
Auch die Ergebnisse der Videoanalyse deuten auf eine kooperationsunterstützende
Wirkung des Werkzeugs hin. Zu nennen ist hierbei vor allem die vielfache Verwendung
der Modellelemente als physischer Ankerpunkt, an dem Diskussionbeiträge durch Zeigen
oder Deuten festgemacht werden und so den anderen Teilnehmern der Bezugsgegenstand
verdeutlicht wird. Dieses Verhalten bei der Modellbildung war in der vergleichenden
Anwendung der rein rechnerbasierten CMapTools in Evaluierungsblock 5 in weitaus ge-
ringerem Ausmaß zu beobachten. Auch die simultane Manipulation am Modell durch
mehrere Teilnehmer trat wiederholt auf. Dabei handelte es sich selten um vollstän-
dig voneinander entkoppelte Aktivitäten, in den meisten Fällen wurde simultan jener
Modellteil manipuliert, der aktuell Gegenstand der Diskussion war. Durch die bei rein
rechner-gestützten Modellierungswerkzeugen exklusiven Interaktionsmöglichkeit durch
die Maus ist dieses Verhalten dort nicht zu beobachten und deutet auf einen auf das
Werkzeug zurückzuführenden Effekt hin.
Insgesamt kann die hier untersuchte Hypothese auf Basis der durchgeführten Unter-
suchungen deshalb bestätigt werden.
372
12.3. Ergebnisse
Ergebnis
Hypothese 2 kann auf Basis der Untersuchung bestätigt werden. Der Zeitanteil
an der Modellbildung zeigt bei Anwendungen mit zwei Modellierenden eine wesentliche
Beteiligung jeweils beider Teilnehmer. Bei mehr als zwei Anwendern ist die Beteili-
gung aller Teilnehmer nicht mehr gegeben, die Teilnehmer haben dennoch durchwegs
(unabhängig von der Anzahl der Teilnehmer bei einer Anwendung) den Eindruck, sich
einbringen zu können und gut zusammenarbeiten zu können.
12.3.3. Einsetzbarkeit in unterschiedlichen Kontexten
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 3 („Das Werkzeug ist
gleichwertig für Modellierungsaufgaben in unterschiedlichen Kontexten einsetzbar.“). Als
Grundlage dieser Untersuchung dienen die Ergebnisse der Evaluierungsblöcke 2, 3, 4 und
5. Die Anwendungskontexte unterscheiden sich weitgehend zwischen den Blöcken. In
Block 2 werden Ablaufplanungen im universitären Lern-Kontext behandelt, die Blöcke
3 und 5 bilden Aufgaben zur Reflexion von Lerninhalten ab. Block 4 zeigt den Einsatz
des Werkzeugs im organisationalen Kontext, wobei hier sowohl die Aufbau- als auch
die Ablauforganisation (zumeist nicht trennbar) behandelt wurden. Zur Auswertung
werden also drei Kontexte (Block 2, Blöcke 3 und 5 sowie Block 4) betrachtet. In den
Blöcken 4 und 5 wurden die Teilnehmer zusätzlich hinsichtlich der Zufriedenheit mit der
Abbildung ihrer mentalen Modelle befragt. Auch diese Ergebnisse dienen der Prüfung
dieser Hypothese.
Auswertung
Im quantitativen Teil der hier durchgeführten Auswertung wurde die Korrelation zwi-
schen der Modellierungszeit und der Modellgröße in den unterschiedlichen Evaluierungs-
blöcken berechnet. Abbildung 12.7 zeigt den Zusammenhang graphisch.
Über alle Evaluierungsblöcke hinweg (n = 57) ergibt sich mit einem Korrelationsko-
effizient nach Spearman6 von 0.60019 ein signifikant positiver Zusammenhang zwischen
den beiden Messgrößen (Test auf positive Korrelation: S = 11082.87, p < 0.005).
Bei der Befragung der Benutzer in den Blöcken 4 (n = 13) und 5 (n = 24) wurde unter
anderem deren Zufriedenheit mit dem Modellierungsergebnis sowie der Anwendung der
Werkzeugs zur Lösung der Aufgabenstellung qualitativ erhoben. In Evaluierungsblock 4
gaben 11 Teilnehmer an, mit dem Modellierungsergebnis zufrieden gewesen zu sein. Ein
Teilnehmer war unzufrieden, einer beantwortete die Frage nicht. Insgesamt wurden von 9
6Der Korrelationskoeffizient nach Pearson kann nicht angewandt werden, da beide Stichproben nicht
normalverteilt sind (Shapiro-Wilk-Test: WZeit = 0.880, pZeit < 0.005, WGre = 0.829, pGre < 0.005)
373
12.3. Ergebnisse
Abbildung 12.7.: Zusammenhang zwischen Modellgröße und Modellierungsdauer
Teilnehmern Begründungen angegeben, die im Folgenden inhaltlich gruppiert dargestellt
sind:
• pos: kooperatives Arbeiten möglich (3x)
• pos: neue Erkenntnisse gewonnen (2x)
• pos: Ergebnis entspricht den Vorstellungen (2x)
• neg: zu große Teile, zu kleine Oberfläche (2x)
11 Teilnehmer gaben an, mit dem Modellierungsverlauf zufrieden gewesen zu sein,
ein Teilnehmer war nicht zufrieden, ein Teilnehmer beantwortete die Frage nicht. Insge-
samt wurden von 8 Teilnehmern Begründungen angegeben, die im Folgenden inhaltlich
gruppiert dargestellt sind:
• pos: kooperatives Arbeiten möglich (3x)
• pos: Kommunikation gefördert, gemeinsame Sichtweise entwickelt (2x)
• pos: Experimentieren ist möglich (1x)
• pos: spielerisches Modellieren möglich (1x)
• neg: zu große Teile, zu kleine Oberfläche (1x)
• neg: Werkzeug ist umständlich (1x)
• neg: Werkzeug technisch instabil (1x)
374
12.3. Ergebnisse
In Evaluierungsblock 5 gaben 18 Teilnehmer an, mit dem Modellierungsergebnis zu-
frieden gewesen zu sein. 6 Teilnehmer waren unzufrieden. 23 Teilnehmer begründeten
ihre Entscheidung. Die Begründungen sind im Folgenden inhaltlich gruppiert dargestellt:
• pos: Modell war vollständig (5x)
• pos: Aufgabe gut gelöst (5x)
• pos: Modell war verständlich (2x)
• pos: Ergebnis entspricht den Vorstellungen (2x)
• pos: rasche Modellierung war möglich (1x)
• neg: Werkzeug technisch instabil (4x)
• neg: Modell war zu ungenau (3x)
• neg: Modell war unübersichtlich (2x)
20 Teilnehmer gaben an, mit dem Modellierungsverlauf zufrieden gewesen zu sein, 4
Teilnehmer waren nicht zufrieden. Alle 24 Teilnehmer begründeten ihre Entscheidung.
Die Begründungen sind im Folgenden inhaltlich gruppiert dargestellt:
• pos: kooperatives Arbeiten möglich (11x)
• pos: Kommunikation gefördert (7x)
• pos: Werkzeug einfach zu bedienen (5x)
• pos: Verwendung unterhaltsam (3x)
• pos: zügiges Arbeiten möglich (3x)
• pos: gute Aufgabenteilung (1x)
• neg: Werkzeug technisch instabil (3x)
• neg: Werkzeug ist umständlich (1x)
• neg: unstrukturiertes Vorgehen (1x)
Diskussion
Der Korrelationskoeffizient zwischen Modellgröße und Modellierungsdauer deutet bei
einer Berechnung über alle Evaluierungsblöcke hinweg mit einem Wert von 0.600 auf
eine signifikant positive Korrelation zwischen diesen beiden Parametern hin. Da damit
unabhängig von der Modellierungsaufgabe offensichtlich ein Zusammenhang zwischen
den geprüften Parametern besteht, stützt dies die Hypothese, dass sich das Werkzeug
für den Einsatz in unterschiedlichen Kontexten eignet. Auch die in Abschnitt 12.3.6
verwendeten „normierten“ Modellierungszeiten (Modellierungdauer im Verhältnis zur
Modellgröße, also im Wesentlichen Zeitaufwand pro Block) zeigen für die dort gegen-
übergestellten Blöcke 2 und 3 keinen signifikanten Unterschied im Aufwand bei der
Modellierung, obwohl die Anwendungen aus unterschiedlichen Kontexten stammen.
375
12.3. Ergebnisse
Bei der qualitativen Betrachtung der Rückmeldungen der Benutzer hinsichtlich der
Zufriedenheit mit dem Modellierungsverlauf und Ergebnis zeigen sich unabhängig von
jeweiligen Anwendungskontext überwiegend positiv zu wertende Rückmeldungen. Be-
trachtet man die mehrfach genannten Begründungen der Einschätzungen, gleichen sich
sowohl die positiven als auch die negativen Rückmeldungen in den beiden Anwendungs-
kontexten. Dies spricht für die Bestätigung der untersuchten Hypothese.
Zusammenfassend kann Hypothese 3 also auf Basis der Ergebnisse der durchgeführten
Untersuchungen bestätigt werden.
Ergebnis
Hypothese 3 kann auf Basis der Untersuchung bestätigt werden. Die quantita-
tive Untersuchung der Korrelation zwischen Modellgröße und Modellierungsdauer zeigt
unabhängig vom Anwendungskontext eine signifikant positive, relativ stark ausgeprägte
Korrelation, was darauf hinweist, dass der Aufwand zur Modellerstellung unabhängig
von Aufgabenstellung und Anwendungskontext relativ stabil bleibt. Auch die qualitati-
ven Rückmeldungen der Teilnehmer aus unterschiedlichen Anwendungskontexten glei-
chen sich im Wesentlichen, so dass das Werkzeug unabhängig vom Anwendungskontext
immer ähnliche positive bzw. negative Effekte hat.
12.3.4. Wiederherstellung vergangener Modellzustände
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 4 („Die Möglichkeit der
Wiederherstellung vergangener Modellzustände fördert die Bereitschaft alternative Re-
präsentationen auszuprobieren.“). Als Grundlage dieser Untersuchung dienen die Ergeb-
nisse der Evaluierungsblöcke 2 bis 5, da die Funktion zur Wiederherstellung vergangener
Modellzustände erst in diesen Blöcken funktionsfähig zur Verfügung stand.
Auswertung
Für alle Anwendungen des Werkzeugs in den Evaluierungsblöcken 2 bis 5 wurde hier un-
tersucht, wie oft die Möglichkeit zur Wiederherstellung vergangener Modellzustände ein-
gesetzt wurde, um alternative Modellierungswege auszuprobieren. Nicht berücksichtigt
wurden Einsätze derselben Funktion, die zur Korrektur von Modellierungsfehlern durch
Fehl-Erkennungen des Systems verwenden wurden (verstärkt in den Evaluierungsblö-
cken 2 und 3 aufgetreten, in 4 und 5 durch Stabilisierung der Erkennungsleistung nicht
mehr relevant – siehe Abschnitt 12.3.8). Die Verteilung des Einsatzes der Funkion ist in
absoluten Zahlen in Tabelle 12.6 für jeden Evaluierungsblock angeführt
376
12.3. Ergebnisse
Tabelle 12.6.: Anzahl des Einsatzes der Wiederherstellungsfunkion
EB 0 E. 1 E. 2 E. 3+ E.
2 18 0 0 0
3 14 4 0 0
4 10 0 0 0
5 10 1 0 0
Ges. 52 5 0 0
EB . . . Evaluierungsblock, x E.. . . x Einsätze der Wiederherstellungsfunktion
Die Wiederherstellungsfunktion wurde also insgesamt in 8.77% der Fälle (n = 57) ein-
gesetzt und kam maximal einmal je Anwendung zum Einsatz. Aus den Videoanalysen
ist außerdem erkennbar, dass die Wiederherstellungsfunktion – falls ihre Verwendung
überhaupt in Betracht gezogen wird – in den meisten Fällen lediglich zur Fehlerkor-
rektur eingesetzt wird (in 52 Anwendungen wurde die Wiederherstellungsfunkion in 37
Fällen – 71.2% – mindestens einmal zur Korrektur von Erkennungsfehlern und 5 mal
zur Korrektur von inhaltlich verworfenen Modellierungswegen verwendet).
Bei der in den Blöcken 1, 4 und 5 durchgeführten Befragung der Teilnehmer hinsichtlich
der Erfahrungen mit dem Werkzeug wurde unter anderem nach als besonders nützlich
empfundenen Funktionen bzw. Eigenschaften des Werkzeugs gefragt. Die Wiederher-
stellungsfunktion wurde in diesem Zusammenhang von keinem Teilnehmer (n = 55)
erwähnt.
Diskussion
Die Ergebnisse der Auswertung der Untersuchung zu dieser Hypothese zeigt ein gerin-
ges Ausmaß der Verwendung der Wiederherstellungsfunktion zum Zwecke der Erstellung
von Modellalternativen. Die Funktion an sich wurde in 71.2% der Anwendungen verwen-
det, was für ein hohes Bewusstsein über deren Existenz spricht. Lediglich in 8.77% der
Anwendungen wurde die Funktion zur Verfolgung alternativer Modellierungswege ein-
gesetzt, in 61.5% der Anwendungen wurde sie lediglich zur Fehlerkorrektur verwendet.
Auch in der qualitativen Erhebung der als nützlich wahrgenommenen Werkzeugfunktio-
nalitäten wurde die Wiederherstellungsfunktion in keinem Fall genannt. Auf Basis dieser
Ergebnisse kann die Hypothese nicht bestätigt werden.
Ergebnis
Hypothese 4 kann auf Basis der Untersuchung nicht bestätigt werden. Die
Wiederherstellungsfunktion wird nur in unter 10% der untersuchten Anwendungen zur
Verfolgung alternativer Modellierungswege genutzt. Die Funktion wird außerdem von
377
12.3. Ergebnisse
den Anwendern bei der Frage nach den als nützlich wahrgenommene Funktionen nicht
genannt.
12.3.5. Nicht-Behinderung
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 5 („Das Werkzeug be-
hindert die Modellbildung nicht.“). Als Grundlage dieser Untersuchung dienen die Er-
gebnisse der Evaluierungsblöcke 2 bis 5, da sich das Werkzeug erst in diesen Blöcken hin-
sichtlich der Funktionalität in vollständigem Zustand befand. Zu berücksichtigen ist bei
der Auswertung, dass im Laufe der Evaluierungsblöcken 4 und 5 eine Überarbeitung der
Implementierung vorgenommen wurde, mittels der das Auftreten von Fehl-Erkennungen
verringert werden konnte und deren Korrektur weniger aufwändig wurde. Befragungen
der Modellierenden hinsichtlich einer etwaigen Behinderung durch das Werkzeug wurden
in den Blöcken 1, 4 und 5 durchgeführt, wobei lediglich die Anmerkungen aus den letzen
beiden Blöcken für den aktuellen Entwicklungsstand des Werkzeugs relevant sind.
Auswertung
In Tabelle 12.7 wird gegliedert nach Evaluierungsblöcken dargestellt, wie oft es in einer
einzelnen Anwendung zu Fehlfunktionen in der Erkennung kam, die den Modellierungs-
fluss unterbrachen. Als Fehl-Erkennungen wurde das Verschwinden von Blöcken oder
Fehlzuordnungen von Benennungen sowie die unbeabsichtigte oder von System eigen-
ständig vorgenommene Erstellung oder Entfernung von Verbindern bzw. Richtungspfei-
len eingeordnet. Zusätzlich wurden Systemabstürze als massive Unterbrechung, die zum
Gesamtverlust des bis zum Zeitpunkt des Absturzes erstellten Modells führten, separat
ausgewertet.
Tabelle 12.7.: Fehlfunktionen und Abstürze des Werkzeugs
EB Anw. 0 Ff. 1-3 Ff. 4-6 Ff. 7+ Ff. Systemabstürze
2 18 0 8 5 5 4
3 18 1 10 4 3 5
4 10 0 2 2 5 1
5 11 0 3 3 4 5
Ges. 57 1 23 14 17 15
EB . . . Evaluierungsblock, Anw. . . . Anzahl der Anwendungen, x Ff.. . . x Fehlfunktionen
In der Gesamtheit der betrachteten Anwendungen (n = 57) ergibt sich die in Tabelle
12.7 dargestellte Verteilung der Anzahl der Fehlerkennungen je Anwendung, die auch in
Abbildung 12.8 graphisch abgebildet ist. In 1.75% der Fälle trat keine Fehlerkennung
während der Anwendung auf (n0 = 1). In 40.35% der Fälle traten zwischen 1 und 3
378
12.3. Ergebnisse
Fehlerkennungen auf (n1−3 = 23). 4-6 Fehlerkennungen konnten in 24.56% der Fälle
festgestellt werden (n4−6 = 14). 7 oder mehr Fehlerkennungen traten in 29.82% der
Fälle auf (n7+ = 17). In 26.32% der Fälle kam es zu Systemabstürzen (nAbsturz = 15),
wobei diese in 10 Fällen nach Ende des eigentlichen Modellierungsvorgangs auftraten.
Abbildung 12.8.: Verteilung der Anzahl der Fehlerkennungen je Anwendung – Übersicht
In der Benutzerbefragung in den Evaluierungsblöcken 4 und 5 wurde in offenen und
geschlossenen Fragen nach der Wirkung des Werkzeugs bei der Modellbildung befragt
(Abschnitte „Nutzerfreundlichkeit“ und „Zufriedenheit des Modellierers“ in Block 4 –
siehe Anhang B.3.2 – und Abschnitte „wahrgenommene Einfachheit der Benutzung des
Werkzeugs“ und „Zufriedenheit des Modellierers“ in Block 5 – siehe Anhang B.3.3).
Die für die Prüfung der hier betrachteten Hypothese sind folgende geschlossene Items
relevant:
1. Die Anwendung des Werkzeugs ist frustrierend (Skala gedreht).
2. Die Anwendung des Werkzeugs fällt mir leicht.
3. Die Anwendung des Werkzeugs ist anstrengend (Skala gedreht).
4. Um mit dem Werkzeug gut zurecht zu kommen, hätte ich intensivere Vorbereitung
benötigt (Skala gedreht).
5. Die Bedienung des Werkzeugs ist intuitiv.
6. Das Werkzeug ist einfach zu bedienen.
7. Die benötigte Zeit um das Modell zu erstellen empfand ich als angemessen.
Insgesamt wurden n = 37 Teilnehmer befragt. Die Ergebnisse sind in Tabelle 12.8
und Abbildung 12.9 zusammengefasst dargestellt. Neben dem Mittelwert und der Stan-
dardabweichung wurde für jedes Item auch geprüft, ob die Einschätzung als signifikant
379
12.3. Ergebnisse
positiv zu bezeichnen ist. Dazu wurde ein einseitiger Wilcoxon-Test für die Stichprobe
gegenüber dem Skalenmittelwert 4 durchgeführt7.
Tabelle 12.8.: Befragung über die Wirkung des Werkzeugs – Itemauswertung
Item M SD VM<4 pM<4
1* 2.89 1.76 100 < 0.005
2 2.19 1.29 20 < 0.005
3* 2.65 1.49 49 < 0.005
4* 2.08 1.28 33.5 < 0.005
5 2.78 1.49 70.5 < 0.005
6 2.32 1.21 27 < 0.005
7 2.16 1.35 20.5 < 0.005
* . . . Item gedreht
Abbildung 12.9.: Verteilung der Benutzereinschätzungen zur Wirkung des Werkzeugs
In der qualitativen Befragung gaben insgesamt 34 Teilnehmer Rückmeldungen zur
Bedienung des Werkzeugs ab (Fragestellung: „Wie zufrieden waren sie im Allgemeinen
mit dem Werkzeug?“). Die Ergebnisse sind im Folgenden inhaltlich gruppiert dargestellt:
7Der Wilcoxon-Test muss angewandt werden, da die Stichprobe in allen sieben Fällen nicht nor-
malverteilt ist (Shapiro-Wilk-Test: W1 = 0.877, p1 < 0.005, W2 = 0.798, p2 < 0.005, W3 =
0.871, p3 < 0.005, W4 = 0.764, p4 < 0.005, W5 = 0.862, p5 < 0.005, W6 = 0.833, p6 < 0.005,
W7 = 0.844, p7 < 0.005)
380
12.3. Ergebnisse
• pos: Prototypen-Probleme nicht überbewerten, trotzdem verwendbar (7x)
• pos: intuitive Herstellung von Verbindern möglich (2x)
• pos: Benutzung war spannend und nützlich (2x)
• pos: Hinweise zum Wiederherstellen eines Zustandes (2x)
• pos: ermöglicht das spielerische Nachdenken über Prozesse (1x)
• pos: Interaktion mit dem Werkzeug einfach möglich (1x)
• pos: Anfassbarkeit verstärkt die Beziehung zum Thema (1x)
• neg: Objekte zu groß / Oberfläche zu klein (9x)
• neg: System zu instabil (8x)
• neg: System zieht tw. selbständig Verbindungen (4x)
• neg: Erkennungsleistung in Teilbereichen mangelhaft (3x)
• neg: zu wenig Verbinder-Varianten (3x)
• neg: zu wenig Baustein-Varianten (2x)
• neg: Beschriftung unterbricht den Modellierungsfluss (1x)
• neg: Tisch zu hoch (1x)
• neg: System umständlich zu bedienen (1x)
• neg: zu träge Reaktion (1x)
In der Videoanalyse der Evaluierungsblöcke 2, 3, 4 und 5 konnten Situationen iden-
tifiziert werden, die die am häufigsten genannten negativen Wirkungen des Werkzeugs
bestätigen. In der Folge werden prototypisch einige Situationen dargestellt, die derartige
Interaktionsabläufe zeigen, in denen die Bedienung des Werkzeugs behindert wird8:
Oberfläche zu klein
Teilnehmer A will einen neuen Block hinzufügen, hat aber wenig Platz.
A setzt gelben Block an den unteren Rand der Arbeitsfläche.
B: Geben wir ihn hier rauf. (schiebt Blöcke zur Seite) Sonst können
wir sie nicht verbinden.
C: Stimmt.
A setzt Block auf die freigelegte Fläche. B und C schieben inzwischen
die anderen Blöcke auseinander, um noch mehr Platz zu schaffen. C setzt
den Marker zum neuen Baustein. A beschriftet. C nimmt den Marker weg.
Die Teilnehmer setzen mit dem verbinden der Blöcke ihre Arbeit fort.
8Die ausgewählten Transkripte stammen aus Evaluierungsblock 3. Sämtliche Transkripte sind unter
den in Anhang B angeführten Quellen zu beziehen.
381
12.3. Ergebnisse
System zu instabil - Fall 1
B stellt blauen Block auf die Arbeitsfläche und schiebt ihn zum roten
Block. System erstellt jedoch keine Verbindung.
A: Egal, dann fahren wir mit dem Roten weiter rauf. (Nimmt roten
Block und schiebt ihn in Richtung blauen Block den TLN B auf der
Arbeitsfläche bewegt) Jetzt erkennt er das auch nicht mehr (meint
Verbindung, die kurz verschwindet).
Die beiden schieben die Blöcke gleichzeitig wieder in Richtung der
Ausgansposition.
Verschwundene Verbindung wird wieder angezeigt. Neue Verbindung wird
nicht erkannt.
A: Egal. (schiebt roten Block nach links oben, während B den blauen
Block nach rechts unten hebt)
A: Versuchen wir es hier einmal.
B schiebt den blauen Block nach links oben zum roten Block zurück.
System erkennt die Verbindung. B schiebt den Block nach rechts unten
zurück und A verschiebt den roten Block, weil die Verbindungen kurz
verschwunden sind. Teilnehmer setzen mit der Modellierung fort.
System zu instabil - Fall 2
Das System hat einen ungewollten Verbinder erstellt.
B stellt das Glas auf die Oberfläche und dreht es
A: jetzt ist es weg!
B hebt das Glas von der Oberfläche, ohne das Wiederherstellungskärtchen
zu verwenden
Beide Teilnehmer verharren kurz ohne zu sprechen
B: nein, he, hallo
B setzt das Glas wieder auf die Oberfläche
A murmelt unverständlich, das letzte Wort scheint „vielleicht“ zu
sein
B dreht das Glas, nimmt die Hand vom Glas und tippt kurz mit den
Fingern auf die Oberfläche
B: OK, und jetzt?
A: Wenn du es weg tust, ist es wieder
B greift zu einem Marker
B: commiten!
B setzt den Marker zweimal kurz auf die Tischoberfläche und nimmt ihn
danach vom Tisch
B: nein
A murmelt unverständlich und zeigt auf den ungewollten Verbinder, der
noch immer besteht
B hebt das Glas kurz an und stellt es wieder auf die Oberfläche
B: ah geh, ich frage ihn gleich
382
12.3. Ergebnisse
B verlässt den den Raum und ruft den Seminarleiter herbei, um ihnen
bei dem Problem behilflich zu sein
System zu instabil - Fall 3
Das System hat einen ungewollten Verbinder erstellt. Die Teilnehmer
wollen diesen mit dem Glas entfernen.
B nimmt das Glas und das Kärtchen gleichzeitig vom Tisch
B: geh nein, nicht das weg tun
Das System hat einen blauen Block am linken unteren Ende der Oberfläche
verloren
B: wah (frustriert)
B: gibt es ja nicht
B nimmt den nicht mehr erkannten blauen Block von der Oberfläche
B: OK, weg tun
B: Was ist jetzt da verkehrt?
B greift zu einem roten Block, das System zeigt mit einer grünen
gefüllten Ellipse an, er solle den Block etwas verschieben, er berührt
den Block leicht und verschiebt ihn minimal, das System erkennt dies
und fordert die Teilnehmer auf, einen weiteren Block zu verschieben.
Die Teilnehmer können dies nicht deuten. B nimmt den Block der
verschoben werden sollte von der Oberfläche und stellt ihn wieder ab,
allerdings neben der markierten Zielposition. B greift zu dem zuvor
entfernten blauen Block und legt ihn wieder an seine ursprüngliche
Position, das System reagiert nicht darauf.
A: vielleicht einmal die
A greift zu dem obersten roten Block und verschiebt diesen weiter nach
oben, er verschiebt auch weitere rote Blöcke, einen dieser Blöcke
verschiebt er auf die grün gefüllte Ellipse. Es handelt sich dabei
jedoch um den falschen Block.
Das System hat einen ungewollten Verbinder erstellt
A: jetzt hat er da wieder eine Verbindung gemacht
B: warte, drehen wir nochmal zurück
B greift zu dem Glas (außerhalb des Bildbereichs)
B: Da bist du mit den Nerven fertig, bevor du irgendetwas zusammengebracht
hast, was passt
Die Teilnehmer setzen die Modellierung fort, das System verlangt noch
immer, dass die Teilnehmer einen roten Block an seinen richtigen Platz
schieben und zeigt die von den Teilnehmern durchgeführten Änderung
nicht an.
System zieht selbständig Verbindungen
383
12.3. Ergebnisse
Das System hat eine unerwünschte Verbindung erstellt.
B schiebt die beiden Blöcke mit der ungewollten Verbindung aneinander
B: OK, jetzt haben wir wirklich eine Verbindung, die müssen wir wieder
löschen
A: hm?
B: oder?
A: Was willst du denn löschen?
B: ja die Verbindung
A: wieso?
B: zeigt auf die Verbindung – brauchen wir da eine?
A: ja, wieso? Sicher
B: (unverständlich)
A: Jam wieso machst du es dann, wenn du sagst, dass du es wieder
löschst?
B: das hat er automatisch gemacht
A: ja, du bist ja zusammengefahren, das ist
B: ja, das vorher schon, ich habe mir gedacht, wenn man zusammenfährt,
dann kann man es
B nimmt das Glas
B: Das ist der Weg? (teilweise unverständlich)
B setzt das Glas auf die Oberfläche
A: (unverständlich)
B dreht das Glas
B: passt!
Diskussion
Die Daten der quantitativen Auswertung der Modellierungsvorgänge zeigen, dass es in
annähernd allen betrachteten Fällen zu zumindest einer Fehlerkennung kam. Es ist da-
von auszugehen, dass jede Fehlerkennung den Modellierungsfluss unterbricht, da das
dann inkorrekte Modelle korrigiert werden muss. Insofern ist von einer Behinderung des
Modellierungsflusses durch die Verwendung des Werkzeugs auszugehen.
Auch die qualtitativ erhobenen Daten weisen darauf hin, dass das Werkzeug zum
Teil behindernd oder beschränkend bei der Durchführung der Modellierung wirkt. Vor
allem die beschränkte Größe der Modellierungsoberfläche (siehe dazu auch die Unter-
suchung der Hypothese 10 in Abschnitt 13.3.2) sowie die auftretenden Instabilitäten
bei der Modellerkennung wurden als negativ für die Modellbildung wahrgenommen. In
der quantitativen Beurteilung der Wirkung des Werkzeugs wird dieses jedoch vornehm-
lich positiv eingeschätzt, so dass die tatsächliche Wahrnehmung des Werkzeugs besser
(bzw. die wahrgenommene Behinderung insgesamt geringer) ist, als es die Daten der Vi-
384
12.3. Ergebnisse
deoauswertung sowie die individuell genannten Probleme bei der Bedienung vermuten
lassen.
Der hohe Anteil von Systemabstürzen ist insofern zu relativieren, als dass diese in zwei
Drittel der Fälle nach Abschluss der eigentlichen Modellierungstätigkeit auftraten und
somit die Modellerstellung selbst nicht mehr unterbrachen. Abstürze traten durchgängig
vor allem in langen Modellierungsdurchgängen etwa ab Minute 40 auf, da ab diesem
Zeitpunkt der Speicherbedarf der Historie tendenziell an die Grenzen des verfügbaren
Arbeitsspeichers stößt. Alternativ kam es an Tagen mit starker Modellierungstätigkeit ab
etwa 5 Stunden durchgängiger Betriebsdauer zu Überhitzungen des Rechners, auf dem
die Software ausgeführt wurde, was zum Gesamtabsturz des Betriebssystems führte. Le-
diglich in 5 Fällen war der Absturz auf fehlerhaftes Programmverhalten (abgesehen von
der Speicherproblematik) zurückzuführen. Diese Fälle traten in den Evaluierungsblöcken
2 und 3 auf. Trotzdem sind auch Systemabstürze in der Endphase der Anwendung nach
der Modellierung durch den auftretenden Datenverlust nicht akzeptabel und sprechen
somit gegen die Annahme der Hypothese.
Insgesamt kann die hier geprüfte Hypothese aus den angeführten Gründen nicht be-
stätigt werden. Trotz der weitgehend positiven Wahrnehmung des Werkzeugs durch die
Benutzter zeigen sich doch Bedienungsprobleme in einem Umfang, bei dem von einer
Behinderung des Modellierungsprozesses ausgegangen werden muss.
Ergebnis
Hypothese 5 kann auf Basis der Untersuchung nicht bestätigt werden. Bei
der Benutzung des Werkzeugs traten vor allem in den ersten Evaluierungsblöcken Fehl-
funktionen auf, die die Modellbildung massiv behinderten oder teilweise verhinderten.
Durch Stabilisierung und Überarbeitung der technischen Plattform konnten diese Fehl-
funktionen zwar minimiert werden, insgesamt können die Verbesserungen die gemesse-
nen Werte nicht soweit verbessern, dass die Hypothese statistisch signifikant bestätigt
werden könnte. Diese erhobenen Aspekte können auch durch die überwiegend positive
Benutzereinschätzung des Werkzeuges nicht kompensiert werden.
12.3.6. Gewöhnung an das Werkzeug
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 6 („Wiederholte Ver-
wendung des Werkzeugs führt zu schnellerer Modellbildung und weniger Fehlbedienun-
gen.“). Als Grundlage dieser Untersuchung dienen die Ergebnisse des Evaluierungsblocks
2, da in diesem für jede Teilnehmerzusammenstellung jeweils zwei Anwendungen des
Werkzeugs durchgeführt wurden.
385
12.3. Ergebnisse
Auswertung
Zur Auswertung der Modellierungsgeschwindigkeit (hinsichlich des Hypothesenteils „schnel-
lere Modellbildung“) wurde die reine Modellierungszeit jeder Anwendung (ohne Diskus-
sionszeit) mit der jeweiligen Modellgröße normiert. In Tabelle 12.9 sind die Anwen-
dungszeiten und Modellgrößen sowie die daraus errechneten normierten Werte für beide
Anwendungen der Gruppen in Evaluierungsblock 2 angegeben.
Tabelle 12.9.: Modellierungszeiten in Abhängigkeit der Modellgröße in Evaluierungs-
block 2
Gruppe t1 n1 t′1 t2 n2 t′2
1 620 20 31.0 300 6 50.0
2 450 13 34.6 420 7 60.0
3 240 12 20.0 285 6 47.5
4 215 10 21.5 420 13 32.3
5 577 12 48.1 270 7 38.6
6 339 10 33.9 330 8 41.3
7 348 8 43.5 110 5 22.0
8 855 16 53.4 510 12 42.5
9 735 8 91.9 195 12 16.3
tx . . .Modellierungsdauer in Sekunden, nx . . . Anzahl der Elemente, t′1 . . . normierte
Modellierungdauer in Sekunden
Zwischen der ersten Anwendung (normierte Modellierungsdauer: M = 42.0, SD =
21.8, n = 9) und der zweiten Anwendung (normierte Modellierungsdauer:M = 38.9, SD =
13.7, n = 9) ist keine signifikante Verringerung der normierten Modellierungsdauer zu
erkennen (einseitiger Wilcoxon-Test für gepaarte Stichproben: V = 21, p = 0.5909).
Die Anzahl der Fehlbedienungen ist die Anwendungen in beiden Modellierungsdurch-
gängen in Evalierungsblock 2 in Tabelle 12.10 angegeben. Als Fehlbedienungen wurden
all jene Interaktionen mit dem Werkzeug eingestuft, in denen die Bedienung nicht dem
intendierten Interaktionsdesign folgte. Fehlfunktionen des Werkzeugs wurden nicht be-
rücksichtigt.
Zusammenfassend kann hier gezeigt werden, dass die Anzahl der Fehlbedienungen zwi-
schen Anwendung 1 (M = 2.89, SD = 2.32, n = 9) und Anwendung 2 (M = 0.78, SD =
9Aufgrund nicht bestätigten Nicht-Normalverteilung der beiden Stichproben (Shapiro-Wilk-Test 1.
Anwendungsdurchgang: W = 0.853, p = 0.081, 2. Anwendungsdurchgang: W = 0.972, p = 0.910)
und dem nicht signifikanten Unterschied der Varianz der Stichproben (F-Test: F = 2.53, p = 0.211)
könnte der t-Test (t = 0.286, df = 8, p = 0.391) ebenfalls angewandt werden und liefert das gleiche
Ergebnis wie der aufgrund der geringen Stichprobengröße durchgeführte Wilcoxon-Test.
386
12.3. Ergebnisse
Tabelle 12.10.: Anzahl der Fehlbedienungen in Evaluierungsblock 2
Gruppe FB1 FB2
1 1 0
2 4 1
3 2 1
4 0 0
5 0 0
6 6 1
7 3 1
8 6 1
9 4 2
FBx . . . Anzahl der Fehlbedienungen
0.67, n = 9) signifikant geringer geworden ist (einseitiger Wilcoxon-Test für gepaarte
Stichproben: V = 28, p = 0.010910).
Diskussion
Eine signifikante Beschleunigung der Modellierungsgeschwindigkeit konnte in obiger Un-
tersuchung nicht festgestellt werden. Die mit der Modellgröße normierte Modellierungs-
zeit verringerte sich zwischen den beiden Anwendungen im Schnitt nur geringfügig. Die-
ses Ergebnis kann somit nicht als Indikator für die Bestätigung der Hypothese gesehen
werden. In den anderen Evaluierungsblöcken (3, 4 und 5) liegt die durchschnittliche nor-
mierte Modellierungsdauer in ähnlichen Bereichen wie in den beiden Durchgängen von
Evaluierungsblock 2. Bei Anwendung des Werkzeugs durch den Entwickler selbst ist die
normierte Modellierungsdauer hingegen auf ungefähr den halben Wert reduziert. Benut-
zer ohne tiefgehende und mehrfach wiederholte Anwendungserfahrungen zeigen jedoch
keinen messbar signifikanten Beschleunigungseffekt bei der Bedienung des Werkzeugs.
Hingegen ist die Anzahl der Fehlbedienungen in den jeweils zweiten Anwendungen
des Werkzeugs im Vergleich zur jeweils ersten Anwendung signifikant gesunken. Dies
spricht für die Bestätigung der hier geprüften Hypothese. Betrachtet man die Fehlbe-
dienungen detaillierter, so ist ein Großteil der aufgetretenen Fälle sowohl in der ersten
als auch in der zweiten Anwendung auf Verständnisschwierigkeiten bei der Bedienung
des Löschtokens (zum Zeitpunkt der Evaluierung noch mit dem zustandsbehafteten In-
teraktionsdesign implementiert, siehe Abschnitt 12.3.8) und der Verwendung der Wie-
derherstellungsfunktion zurückzuführen. Das Interaktionsdesign beider Aspekte ist also
10Aufgrund der beiden kleinen Stichproben und der Nicht-Normalverteilung der zweiten Stichprobe
(Shapiro-Wilk-Test 1. Anwendungsdurchgang: W = 0.9144, p = 0.348, 2. Anwendungsdurchgang:
W = 0.813, p = 0.0284) sowie der unterschiedlichen Varianz der Stichproben (F-Test: F = 12.06, p =
0.00199) kann der t-Test nicht angewandt werden.
387
12.3. Ergebnisse
zu hinterfragen (bzw. wurde im Falle des Löschtokens hinterfragt). Zwischen den bei-
den Modellierungsdurchgängen kam es zu einer Überarbeitung der Funktionalität und
der Interaktionsabläufe zur Herstellung von Verbinderns (siehe Abschnitt 12.3.7). Das
Ausmaß der Fehlbedienungen, die auf diese Funktionalität zurückzuführen sind, blieb
jedoch in beiden Abschnitten gleich niedrig (FBV erbinder = 2). Durch die Überarbeitung
wurde lediglich das Ausmaß der Verwendung von Verbindern signifikant gesteigert (siehe
Abschnitt 12.3.7).
Insgesamt kann die hier untersuchte Hypothese nur zum Teil bestätigt werden, da der
vermutete Beschleunigungseffekt nicht nachzuweisen war.
Ergebnis
Hypothese 6 kann auf Basis der vorliegenden Daten teilweise bestätigt wer-
den. Während kein signifikanter Beschleunigungseffekt bei wiederholter Verwendung des
Werkzeugs festgestellt werden konnte, war eine signifikante Verringerung der Anzahl der
Fehlbedienungen des Werkzeugs bei wiederholtem Einsatz feststellbar.
12.3.7. Herstellung von Verbindern
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 7 („Die Einführung der
alternativen Möglichkeit zur Verbindungsherstellung erhöht die Nutzung von Verbindern
bei der Modellerstellung.“). Zur Untersuchung wurden die Werkzeuganwendungen aus
Evaluierungsblock 2 (n = 18) herangezogen. Dieser Block wurde gewählt, da dort alle
Teilnehmer das Werkzeug zweimal mit der gleichen Aufgabenstellung anwandten, wobei
in der ersten Anwendungsrunde lediglich die ursprüngliche Funktionalität zur Herstel-
lung von Verbindern verfügbar war, in der zweiten Runde aber bereits der alternati-
ve Funktionalität implementiert war. Zur weiteren Überprüfung der Ergebnisse werden
außerdem die Ergebnisse aus Block 3 (n = 18) herangezogen, bei dessen Durchführung
ebenfalls bereits die alternative Funktionalität verfügbar war.
Auswertung
Grundlage der Auswertung ist das Modellmerkmal „Connectedness“, worunter hier das
Verhältnis zwischen der Anzahl der in einem Modell verwendeten Verbindern und den
verwendeten Modellelementen zu verstehen ist. In den einzelnen betrachteten Evaluie-
rungsblöcken verteilt sich die Connectedness wie in den Abbildungen 12.10 dargestellt.
Zu prüfen ist, ob die Connectedness in jenem Evaluierungs-Blöcken bzw. -Durchgängen,
in denen die alternative Funktionalität zur Verbindungs-Herstellung verfügbar war, si-
gnifikant höher ist, als in jenen, in denen dies nicht der Fall war. Berechnet wird die
388
12.3. Ergebnisse
Abbildung 12.10.: Connectedness in den Evaluierungsblöcken 2 und 3
Signifikanz zwischen den Ergebnissen der beiden Durchgänge von Block 2 (conn2−1:
M = 0.480, SD = 0.544 und conn2−2: M = 0.804, SD = 0.308) sowie zwischen den
Ergebnissen des ersten Durchgangs von Block 2 und den Ergebnissen von Block 3
(conn3: M = 0.876, SD = 0.435). Im zweiten Fall ist zu beachten, dass die Aufga-
benstellung nicht identisch war und diese Einfluss auf die Connectedness des Modells
haben kann. Aufgrund der bestätigten Nicht-Normalverteilung der Stichprobe conn2−2
(Sharpiro-Wilk-Test: W2−1 = 0.854, p2−1 = 0.0823, W2−2 = 0.586, p2−2 < 0.005, W3 =
0.913, p3 = 0.114) kommt zur Prüfung der Signifikanz der t-Test nicht in Frage, es wird
der Wilcoxon-Test herangezogen.
Der einseitige Wilcoxon-Test für gepaarte Stichproben ergibt für conn2−1 und conn2−2
in der zweiten Stichprobe (jene mit Einsatz der alternativen Funktionalität der Verbin-
dungsherstellung) eine signifikant höhere Connectedness (V = 5, p = 0.0400) als in der
erste Stichprobe (ohne diese Funktionalität).
Für conn2−1 und conn3 ergibt der einseitige Wilcoxon-Test für ungepaarte Stichproben
ein ähnliches Ergebnis – auch hier ist im der zweiten Stichprobe bei Einsatz der alterna-
tiven Funktionalität zur Verbiundungsherstellung eine signifikant höhere Connectedness
festzustellen (W = 39, p = 0.0227).
Für conn2−2 und conn3 zeigt der zweiseitige Wilcoxon-Test für ungepaarte Stichproben
dahingegen keine signifikant unterschiedliche Connectedness (W = 64.5, p = 0.535) für
den zweitgenannten Block – in diesem Fall kam in beiden Stichproben die alternative
Möglichkeit zur Herstellung von Verbindungen zum Einsatz.
389
12.3. Ergebnisse
Diskussion
Aufgrund der Ergebnisse der berechneten Signifikanztests ist die Hypothese anzuneh-
men. Mit der Einführung der alternativen Möglichkeit zur Herstellung von Verbindungen
war in den einzelnen Anwendungen des Werkzeugs eine Zunahme der Verwendung von
Verbindern zu beobachten. Während die Benutzer bei der ursprünglichen Funktion zur
Herstellung von Verbindungen zum Großteil auf diese verzichteten (dieses Verhalten ist
auch in Evaluierungsblock 1 zu beobachten), wurden Verbinder unabhängig von der Auf-
gabenstellung mit der Einführung der alternativen Funktionalität verstärkt eingesetzt.
Die Connectedness eignet sich als Parameter zur vergleichenden Beurteilung des Aus-
maßes der Verwendung von Verbindern, da durch die Einbeziehung der Größe des Mo-
dells (repräsentiert durch die Anzahl der verwendeten Modellelemente) in die Berech-
nung den Wert für unterschiedliche Modelle vergleichbar gemacht wird.
Einfluss auf die Höhe der Connectedness kann aber die Aufgabenstellung haben, die
zur Bildung des Modells führt. Unterschiedliche Modellierungsaufgaben können zu un-
terschiedlichen Modell-Topologien führen, die sich wiederum in der Anzahl der verwen-
deten Verbinder auswirkt. Concept-Mapping-Aufgaben, die conn3 zugrunde liegen, füh-
ren eher zu stärker verbundenen Modellen als Arbeitsabstimmungs-Aufgaben, auf denen
conn2−2 basiert und die zu eher ablauforientierten Modellen führen. Während bei Con-
cept Mapping beliebige Konzepte in Beziehung stehen können, stehen Elemente bei
ablauf-orientierten Modellen vor allem mit ihren kausalen Vorgängern und Nachfolgern
in Beziehung, was die Anzahl der Verbinder einschränkt.
Dies ist am Ergebnis des Wilcoxon-Tests für conn2−2 und conn3 allerdings nicht zu
erkennen – in beiden Fällen stand die alternative Möglichkeit zur Verbindungsherstellung
zur Verfügung. conn3 unterscheidet sich nicht signifikant von conn2−2. Die überarbeitete
Möglichkeit zur Herstellung von Verbindern übertrifft bzw. kompensiert die Auswirkung
der unterschiedlichen Aufgabenstellung.
Das Resultat der durgeführten Wilcoxon-Tests zwischen conn2−1 und conn2−2, conn2−1
und conn3 sowie conn2−2 und conn3 spricht für die Annahme der Hypothese 7. Zu
berücksichtigen ist hier jedoch die geringe Stichprobengröße, die die Aussagekraft des
Ergebnisses schmälert.
Ergebnis
Die Auswertung zeigt eine signifikant höhere Verwendung von Verbindern bei Verfüg-
barkeit der alternativen Funktionalität zur Verbindungs-Herstellung unabhängig von der
Aufgabenstellung (siehe dazu auch die Diskussion von Hypothese 13 in Abschnitt 13.3.5).
Hypothese 7 kann auf Basis der vorliegenden Daten bestätigt werden.
390
12.3. Ergebnisse
12.3.8. Verwendung des Löschtokens
In diesem Abschnitt werden die Ergebnisse der Überprüfung der Hypothese 8 („Das
Löschtoken ermöglicht intuitives Löschen von Modellelementen.“) vorgestellt. Die Aus-
wertung basiert auf den Ergebnissen der Modellierungsblöcke 2, 3, 4 und 5, wobei zwi-
schen Evaluierungsblöcken 3 und 4 die Funktionaliät und Verwendungsweise des Tokens
überarbeitet wurde.
Auswertung
Zur Auswertung wurde erhoben, in welchem Ausmaß das Löschtoken zum Entfernen
unerwünschter Verbinder im Gegensatz zur alternativen Möglichkeit – dem Einsatz der
Wiederherstellungsfunktion – verwendet wurde. Zusätzlich wurde erhoben, in wie vielen
Fällen die Verwendung des Löschtokens scheiterte, weil die Benutzer dessen Einsatzmög-
lichkeit inkorrekt interpretierten. Tabelle 12.11 zeigt diese Daten für die Evaluierungs-
blöcke 2 bis 5.
Tabelle 12.11.: Verwendung des Löschtokens
EB Anw. Lges LToken FIToken LWH
2 18 55 11 10 44
3 18 68 8 7 60
4 10 35 20 0 15
5 11 95 83 0 12
Ges. 57 253 122 17 131
EB . . . Evaluierungsblock, Lges . . . Gesamtanzahl der Löschvorgänge, LToken . . . Löschvorgänge mit
Löschtoken, FIToken . . . Fehlinterpretationen bei der Verwendung des Löschtokens, LWH
. . . Löschvorgänge mit Wiederherstellungsfunktion
Die Art der Fehlinterpretationen der Verwendung des Löschtokens kann durch nähere
Betrachtung mittels der durchgeführten Interaktionsanalyse exakter bestimmt werden.
Ausgewählt wurden hier Beispiele aus den Modellierungsblöcken 2 und 3. Die gesammel-
ten Transkripte sind in den in Anhang B genannten Quellen verfügbar.
In der ersten hier angeführten Szene versuchen die Teilnehmer, die Beschriftung ei-
nes Blocks mit dem Löschtoken auszuradieren. Dies scheitert, da das Löschtoken als
Zustandsschalter fungiert und das eigentliche Löschen separat ausgelöst werden muss.
Außerdem wirkt das Löschtoken nur auf Verbindungen.
Die Teilnehmer möchten einen Block umbenennen.
A: Wie haben wir jetzt gesagt (markiert den roten Baustein) keine
Modellierungsvorgabe (gibt Bezeichnung ein)
System übernimmt die neue Beschriftung für den Baustein nicht.
391
12.3. Ergebnisse
A: Wo wurde das hingeschrieben? (Pause) Radiergummi? Glaubst du, kann
man das wegradieren?
B: Probiere es aus.
A legt Radiergummi zum Block mit der Absicht die Beschriftung zu
löschen
B: Nein! Du löscht alles. Hör auf!
A: Ok, wie war das zuerst? Lassen wir das mal weg. (legt Baustein zur
Seite)
A legt den Block zur Seite.
Ein ähnliches Missverständnis zeigt sich auch in der im Folgenden angegebenen Situati-
on. Hier sollte eine Verbindung gelöscht werden, das Löschtoken wurde jedoch wiederum
nicht als Zustandsschalter, sondern für den Vorgang des Löschens selbst verwendet.
TLN A und B stellen jeweils ihren Marker zu den Blöcken, die verbunden
werden sollen. Dabei wird eine gerichtete Verbindung erstellt.
C: Jetzt haben wir aber einen Pfeil gebastelt.
B: Ja stimmt. Interessant.
A: Wie war das mit dem Radiergummi? (nimmt Radiergummi und legt ihn
auf die Verbindung)
B: Nein
C: Nein, mit dem Glas! Du löscht alles!
A: Nein, nur die Verbindung. (Macht Radierbewegungen auf der Verbindung)
C: Ich glaube, dass wir das Glas nehmen müssen.
A schiebt die Blöcke, zwischen denen die Verbindung gelöscht werden
soll, zusammen.
A: Da es funktioniert. (schiebt die Blöcke weiter auseinander und
bemerkt, dass die Verbindung nicht gelöscht wurde) Nein.
B: Ich glaube, der Radiergummi vernichtet alles.
A: Nein, der Radiergummi vernichtet nur Verbindungen. Nur welche?
(schiebt beide Blöcke wieder zusammen – nimmt Radiergummi weg und
schiebt Blöcke in die Ausgangsposition)
In der folgenden Szene zeigen sich wiederum die Fehlinterpretationen der am Beginn
angeführten Interaktion. Wieder wird das Token zum Radieren verwendet, Zielobjekt ist
in diesem Fall die Beschriftung einer Verbindung.
Es wird eine falsche Beschriftung eingefügt. Die Teilnehmer wollen
diese löschen, verwenden den Radiergummi allerdings falsch.
B: Aber irgendwie steht jetzt Ereignisse nicht bei dem Ding (zeigt
auf gelben Block), sondern dort (zeigt auf beschriftete Verbindung).
A verrückt den gelben Block ein wenig.
B: Normal ist das nicht, oder?
C: Nein.
A nimmt den Radiergummi.
A: Ich glaube das. (setzt den Radiergummi auf die Arbeitsfläche)
392
12.3. Ergebnisse
C: Aber nicht alles!
A nimmt Radiergummi wieder weg. System erstellt eine Verbindung
zwischen zwei roten Blöcken. Teilnehmer lachen. A legt Radiergummi
auf die erstellte Verbindung, und nimmt ihn wieder weg. A nimmt die
beiden verbundenen Blöcke und verschiebt sie.
A: Vielleicht so. (führt die Blöcke zusammen)
In der folgenden Szene sind die Teilnehmer durch den Farbwechsel der Oberfläche
beim Aufsetzen des Löschtokens (zur Indikation des Zustandswechsels) irritiert, da sie
ebenfalls versuchen, das Token zum Radieren zu verwenden.
In der Szene erstellt das System einen ungewollten Verbinder, die
Teilnehmer versuchen auf verschiedene Arten den Verbinder zu löschen.
B: Und wie kann ich die Verbindungen löschen?
B: Warte einmal, da gibt es irgendwo das mit dem Radiergummi.
A: murmelt zustimmend
B nimmt den Radiergummi und platziert ihn direkt auf dem Verbinder
Das System färbt den Tisch rot
A: Nein, warte. Da löscht du alles!
B verschiebt den Radiergummi auf dem Tisch, hebt ihn an und platziert
ihn direkt auf einem Block.
Sobald der Radiergummi von der Oberfläche auf den Block gelegt wurde,
entfernt das System die rote Färbung.
A: Ich glaube, da löscht du alles.
B legt den Radiergummi an mehreren Stellen trotz der Warnung von TN
A auf die Oberfläche
B: Nein, es will eh nicht.
Die nachstehende Interaktion zeigt wiederum die in den anderen Szenen bereits be-
schriebene Fehlinterpretation in der Verwendung des Löschtokens. Zusätzlich verwirrt
eine Fehlfunktion des Werkzeugs, das anstelle eines Löschvorgangs einen Verbinder hin-
zufügt.
C versucht die Benennung eines Verbinders mittels Radiergummi zu
entfernen.
B: Aber irgendwie steht jetzt Ereignisse nicht bei dem Ding (deutet
auf einen Block), sondern dort (deutet auf einen Verbinder). Das
wollen wir nicht oder?
A: Nein.
C: Ich glaube das. (nimmt den Radiergummi und legt ihn auf den
Verbinder, den die Teilnehmer entfernen wollen.)
A: Aber nicht alles.
C entfernt den Radiergummi wieder von der Modellierungsoberfläche.
In diesem Moment erstellt das System durch Fehlerkennungen automatisch
einen neuen Verbinder. C versucht, den neuen Verbinder mittels Radiergummi
393
12.3. Ergebnisse
zu entfernen.
A: Oh Gott.
C: Vielleicht so (schiebt die beiden betroffenen Blöcke zusammen),
nein.
B: Nein.
A: Oh Gott, oh Gott, oh Gott.
B: Gehen wir einen Prozessschritt zurück.
C: Genau.
In der letzten hier angeführten Szene interagieren die Teilnehmer beinahe wie im
Interaktionsdesign ursprünglich intendiert mit dem System. Sie scheitern letztendlich
trotzdem und greifen zu alternativen Möglichkeit der Fehlerkorrektur, der Wiederher-
stellungsfunktion.
Teilnehmer versuchen mit dem Radiergummi und nur einem anderen Marker
einen Verbinder zu entfernen.
B: Können wir die nicht so auch einfach löschen?
C: Ja, mit dem Radiergummi.
B: Muss ich den jetzt zuerst so (Hält den Radiergummi zur Kamera)
hinhalten?
A: Nein, ich glaube, den musst du einfach da (zeigt auf den Verbinder)
drauf legen.
B legt den Radiergummi auf den vom System automatisch erstellten
Verbinder.
A: Und jetzt muss man (legt ein Markierungtoken auf den Verbinder)
Nein.
Der Verbinder lässt sich auf diese Art nicht löschen und die Teilnehmer
entscheiden sich, den Fehler mittels der Wiederherstellungsfunktion
zu beseitigen.
Diskussion
In der quantitativen Auswertung ist klar zu erkennen, dass die ursprüngliche Imple-
mentierung der Löschfunktion, in der das Löschtoken als Zustandsumschalter fungierte,
von den Benutzern kaum verwendet wurde und in jenen Fällen, in denen es zum Ein-
satz kam, falsch interpretiert wurde, was letztendlich zum Scheitern des Löschvorgangs
führte. Beginnend mit Block 4 wurde die Löschfunktion in einer vollständig erneuerten
Implementierung eingesetzt, in der das Löschtoken tatsächlich zum „Ausradieren“ einer
Verbindung verwendet werden konnte. Damit wurde der vorherrschenden Interpretation
der Funktionalität durch die Benutzer Rechnung getragen, was sich dadurch äußert, dass
die Anzahl der Fehlinterpretationen auf 0 sank und das Löschtoken in weitaus höherem
Ausmaß als die Wiederherstellungsfunktion zur Fehlerkorrektur verwendet wurde.
394
12.4. Zusammenfassung
Bei der Betrachtung der Hypothese muss also zwischen der ursprünglichen Implemen-
tierung und deren neuen Umsetzung unterschieden werden. Für die ursprüngliche Im-
plementierung kann die Hypothese nicht bestätigt werden, das Werkzeug war in der vor-
liegenden Form für die Benutzer nicht verständlich. In der Neuimplementierung wurden
die ursprünglichen Fehlinterpretationen berücksichtigt und das Werkzeug so modifiziert,
dass es entsprechend der beobachteten Benutzerinterpretation verwendet werden konnte.
In dieser Variante sprechen die erhobenen Daten für eine Bestätigung der Hypothese.
Ergebnis
Hypothese 8 muss für die ursprüngliche Umsetzung der Löschfunktion abge-
lehnt werden, kann aber für die neu konzipierte und implementierte Variante
bestätigt werden. In der ursprünglichen Umsetzung war die Verwendung des Werk-
zeugs für die Benutzer nicht verständlich, die eigentlich aufwändigere Alternativfunktion
zur Fehlerkorrektur wurde außerdem weitaus häufiger verwendet. Nach der Neukonzep-
tion kam es zu keinen Fehlinterpretationen mehr, das Löschtoken wurde außerdem in
weitaus höherem Ausmaß verwendet.
12.4. Zusammenfassung
In diesem Kapitel wurde die Evaluierung der Verwendbarkeit des Werkzeugs beschrieben.
Die hier formulierten Hypothesen beschäftigen sich dementsprechend mit den grundle-
genden Funktionen des Werkzeugs und den Interaktionsmöglichkeiten der Benutzer mit
diesen. Nicht Gegenstand dieses Kapitels waren die im Kontext der Durchführung von
„Articulation Work“ erstellten Modelle (siehe Kapitel 14) sowie die Auswirkungen der
Durchführung in der „Production Work“ (siehe Kapitel 14).
In diesem Kapitel wurden sechs Hypothesen zur Werkzeugbenutzung getestet, die un-
mittelbar aus den Anforderungen an das Werkzeug (siehe 5) abgeleitet waren. Zwei
weitere Hypothesen zur Werkzeugverwendung wurden im Verlauf der ersten Evaluie-
rungsblöcke explorativ gebildet und in den späteren Evaluierungsblöcken getestet. Die
sechs aus den Anforderungen abgeleiteten Hypothesen bilden im Wesentlichen die Kern-
funktionen des bzw. Interaktionsmöglichkeiten mit demWerkzeug ab. Durch die Prüfung
dieser Hypothesen wird so das gesamte Werkzeug einer Überprüfung hinsichtlich dessen
praktischer Verwendbarkeit unterzogen.
Hypothese 1 („Repräsentation diagrammatischer Modelle“) bildet den grundlegenden
Anspruch des Werkzeugs ab, die Abbildung von diagrammatischen Modellen zu ermög-
lichen. Diese werden als Repräsentation für externalisierte mentale Modelle verwendet
und bilden so die Grundlage für die Durchführung von expliziter „Articulation Work“.
Diese Hypothese konnte im Rahmen der Untersuchung bestätigt werden. Die Abbildung
von Konzepten und Beziehungen zwischen diesen wurde in allen vorliegenden Modellen
395
12.4. Zusammenfassung
erfolgreich umgesetzt, wenngleich die Modellierung von expliziten Verbindungen in den
ersten beiden Evaluierungsblöcken aufgrund von technischen Unzulänglichkeiten nicht
durchgeführt wurde.
Hypothese 2 („Kooperatives Arbeiten“) prüft, ob die kooperative Verwendung des
Werkzeugs möglich ist. Für die Durchführugn von „Articulation Work“ ist der kooperati-
ve Einsatz notwendig, da nur so die dabei ablaufenden synchronen Abstimmungsprozesse
ermöglicht bzw. unterstützt werden können. Die Hypothese konnte in der Untersuchung
bestätigt werden. Der Zeitanteil an der Modellbildung ist für Anwendungen mit zwei
Teilnehmern weitgehend gleichverteilt, beide Teilnehmer beteiligen sich also an der Mo-
dellierung. Bei mehr als zwei Anwendern ist die Gleichverteilung nicht mehr gegeben, die
Teilnehmer haben dennoch durchwegs (unabhängig von der Anzahl der Teilnehmer bei
einer Anwendung) den Eindruck, sich einbringen zu können und gut zusammenarbeiten
zu können.
Hypothese 3 („Einsetzbarkeit in unterschiedlichen Kontexten“) legt den Anspruch an
das Werkzeug fest, dass dessen Anwendung unabhängig von der konkreten Anwendungs-
domäne möglich ist. Wesentlich ist hierbei, dass das Werkzeug von Teilnehmer mit unter-
schiedlichen beruflichen bzw. Ausbildungs-Hintergründen gleich gut verwendet werden
kann und dass die Modellbildung durch das Werkzeug nicht spezifisch für bestimmte
Aufgabenstellungen erschwert wird. Die Hypothese konnte im Rahmen der Untersu-
chung bestätigt werden. Die Untersuchung der Korrelation zwischen Modellgröße und
Modellierungsdauer zeigt unabhängig vom Anwendungskontext eine positive Korrelati-
on, was darauf hinweist, dass der Aufwand zur Modellerstellung unabhängig von Auf-
gabenstellung und Anwendungskontext relativ stabil bleibt. Auch die Rückmeldungen
der Teilnehmer mit unterschiedlichen beruflichen Hintergründen sind im Wesentlichen
identisch, so dass das Werkzeug unabhängig vom Anwendungskontext immer ähnliche
Wirkungen auf die Modellbildung hat.
Hypothese 4 („Wiederherstellung vergangener Modellzustände“) prüft, ob die Bereit-
schaft zur Erstellung unterschiedlicher Modellvarianten im Verlauf der Modellbildung
durch die Möglichkeit zur Wiederherstellung vergangener Modellzustände gefördert wird.
Diese Hypothese kann auf Basis der Untersuchung nicht bestätigt werden. Die Wieder-
herstellungsfunktion wird nur in unter 10% der untersuchten Anwendungen zur Ver-
folgung alternativer Modellierungswege genutzt. Die Funktion wird außerdem von den
Anwendern bei der Frage nach den als nützlich wahrgenommene Funktionen in keinem
der betrachten Fälle genannt, so dass davon ausgegangen werden muss, das sie nicht als
relevant für die Durchführung der Modellbildung erachtet wird.
Hypothese 5 („Nicht-Behinderung“) geht auf die Gesamtwirkung des Werkzeugs bei
der Modellbildung ein und untersucht, ob diese durch das Werkzeug behindert wird. Im
Wesentlichen sind Bedienungsprobleme und technische Fehlfunktionen des Werkzeugs
zu betrachten, die einen negativen Effekt auf die Ausführung der eigentlichen Aufga-
be haben können. Die Hypothese konnte im Rahmen der Untersuchung nicht bestätigt
396
12.4. Zusammenfassung
werden. Bei der Benutzung des Werkzeugs traten vor allem in den ersten Evaluierungs-
blöcken Fehlfunktionen auf, die die Modellbildung massiv behinderten oder teilweise
verhinderten. Durch Stabilisierung und Überarbeitung der technischen Plattform konn-
ten diese Fehlfunktionen zwar minimiert werden, insgesamt können die Verbesserungen
die gemessenen Werte nicht soweit verbessern, dass die Hypothese statistisch signifikant
bestätigt werden könnte. Diese erhobenen Aspekte sind auch durch die überwiegend
positive Benutzereinschätzung des Werkzeuges nicht als kompensiert anzusehen.
Hypothese 6 („Gewöhnung an das Werkzeug“) prüft, ob die wiederholte Verwendung
des Werkzeugs dessen Bedienbarkeit durch die Benutzer verbessert. Betrachtet wurde
hier einerseits die Modellierungsdauer im Verhältnis zur Modellgröße, was ein Maß für
die Geschwindigkeit der Modellierung darstellt. Andererseits wurde die Anzahl der Fehl-
bedienungen des Werkzeugs betrachtet, die bei besserer Bedienbarkeit in wiederholten
Anwendungen geringer ausfallen sollte. Die Hypothese kann auf Basis der vorliegenden
Daten nur teilweise bestätigt werden. Während kein signifikanter Beschleunigungseffekt
bei wiederholter Verwendung des Werkzeugs festgestellt werden konnte, war eine signi-
fikante Verringerung der Anzahl der Fehlbedienungen des Werkzeugs bei wiederholtem
Einsatz feststellbar.
Hypothese 13 („Herstellung von Verbindern“) wurde explorativ aus Beobachtungen
in den Evaluierungsblöcken 2 und 3 abgeleitet. In diesen Blöcken stieg die Verwendung
von Verbindern im Modell sprunghaft an. Geprüft wurde nun, ob dies – wie vermu-
tet wurde – auf die überarbeiteten und erweiterten Möglichkeiten zur Herstellung von
Verbindern im Modell zurückzuführen war. Die Hypothese konnte in der Untersuchung
bestätigt werden. Die Auswertung zeigt eine signifikant höhere Verwendung von Verbin-
dern bei Verfügbarkeit der überarbeiteten Funktionalität zur Verbindungs-Herstellung.
Allerdings zeigt sich, dass auch die Natur der Aufgabenstellung hohen Einfluss auf die
Verwendung von Verbindern. Diese Beobachtung wurde in Hypothese 13 nochmals auf-
gegriffen und dort genauer untersucht (siehe dazu Abschnitt 13.3.5).
Hypothese 8 („Verwendung des Löschtokens“) betrachtet ebenfalls eine Funktionalität
des Werkzeugs, die auf Basis von Beobachtungen der Benutzerinteraktionen überarbei-
tet wurde. Die Funktion zur Entfernung von Verbindern wurde in den ersten Evaluie-
rungblöcken kaum verwendet und zeigte im Falle der Verwendung hohes Potential für
Missverständnisse hinsichtlich der Art der Benutzung. Die zur Verwendung notwendigen
Interaktionsabläufe wurden daraufhin an die offensichtlich vorherrschende Interpretation
der Benutzter, wie das entsprechende Werkzeug zu verwenden ist, angepasst. Untersucht
wurde nun, ob diese Anpassung die Entfernung von Elementen aus dem Modell erlei-
cherte bzw. intuitiv gestaltete. Die Hypothese konnte für die überarbeitete Variante des
Löschtokens bestätigt werden. In der ursprünglichen Umsetzung war die Verwendung
des Werkzeugs für die Benutzer nicht verständlich, die eigentlich aufwändigere Alterna-
tivfunktion zur Fehlerkorrektur mittels der Wiederherstellungsfunktion wurde außerdem
weitaus häufiger verwendet. Nach der Neukonzeption kam es zu keinen Fehlinterpreta-
tionen mehr, das Löschtoken wurde außerdem in weitaus höherem Ausmaß verwendet.
397
12.4. Zusammenfassung
Insgesamt zeigt sich, dass das Werkzeug in der vorliegenden Form weitgehend verständ-
lich ist und als nützlich sowie zum Teil benutzbar wahrgenommen wird. Das Werkzeug
erfüllt die Grundanforderungen hinsichtlich der Abbildbarkeit diagrammatischer Modelle
und der Ermöglichung kooperativen Arbeitens. Die Einsetzbarkeit in beliebigen Kontex-
ten ist gegeben, wobei aufgrund von technischen Instabilitäten die Verwendbarkeit vor
allem in den frühen Phasen der Evaluierung eingeschränkt war. Jene Hypothesen, die
auf die Verwendung spezifischer Funktionalitäten eingehen, zeigen eine gute Verständ-
lichkeit und hohes Ausmaß an Verwendung der Basisfunktionalitäten der Modellierung
(etwa Platzierung und Benennung von Blöcken, Herstellung von Verbindern, Löschen
von Verbindern), offenbaren aber Schwächen in der Verständlichkeit und Akzeptanz der
komplexeren Funktionen, wie etwa der Wiederherstellungsunterstützung für gespeicherte
Modellzustände. Zusammenfassend wird das Werkzeug den grundlegenden Anforderun-
gen also gerecht, bietet aber Raum für Verbesserungen hinsichtlich der Verwendung der
komplexeren Funktionen und der technischen Stabilität. Im folgenden Kapitel wird nun
auf die Verwendung des Werkzeugs zur kooperativen Abbildung von Modellen eingegan-
gen.
12.4.1. Beitrag zur globalen Zielsetzung
Dieses Kapitel stellt die Untersuchung der Verwendbarkeit des entwickelten Werkzeugs
dar und trägt so hinsichtlich der in Kapitel 1 argumentieren und in Kapitel 5 näher
ausgeführten zu untersuchenden Aspekte zur Beantwortung der Fragestellung 6 („Er-
möglicht das Instrument die effektive Durchführung von expliziter Articulation Work?“)
bei. Die Ergebnisse zeigen die erwartete Verwendbarkeit des Werkzeugs zur Unterstüt-
zung der entwickelten Methodik und bestätigen so die grundlegende Voraussetzung für
die effektive Unterstützung expliziter „Articulation Work“ durch das hier vorgestellte
Instrument.
12.4.2. Weitere Verwendung der Ergebnisse
Die Ergebnisse dieses Kapitels werden in ihrer Gesamtheit erst in den Schlussbetrach-
tungen (Kapitel 15) wieder aufgegriffen. Einzelne Hypothesen, vor allem jene, die sich
mit der kooperativen Verwendbarkeit des Werkzeugs beschäftigen, werden aber bereits
in den folgenden beiden Kapiteln wieder aufgegriffen und dienen dort als Grundlage der
Evaluierung der Methodik bzw. der Wirkung der durchgeführten „Articulation Work“.
398
13. Evaluierung der Anwendung des
Instruments
Im zweiten Teil der Evaluierung wird nicht der Umgang mit dem Werkzeug betrachtet
(siehe dazu Kapitel 12), sondern auf die Anwendung des Werkzeugs im Sinne der Me-
thodik und auf deren unmittelbares Resultat, also auf das erstellte Modell, eingegangen.
Ebenfalls nicht Gegenstand der Untersuchung ist in diesem Abschnitt die Wirkung der
Modellbildung auf die operative Arbeit („Production Work“), die in Kapitel 14 betrach-
tet wird. Abbildung 13.1 stellt dieses Kapitel und dessen Aufbau im Kontext der anderen
inhaltlich vor- und nachgelagerten Kapitel dar.
Abbildung 13.1.: Kapitel „Evaluierung der erstellten Modelle“ im Gesamtzusammen-
hang
Ausgehend von den erstellten Modellen und deren Entstehungsprozess wird in diesem
Kapitel untersucht, wie das Werkzeug auf die in dieser Arbeit gewählte Form der Un-
terstützung expliziter „Articulation Work“, nämliche der kooperativen Externalisierung
und Abstimmung mentaler Modelle, wirkt. Dementsprechend sind die im folgenden Ab-
399
13.1. Hypothesen
schnitt beschrieben Hypothesen aus den Ausführungen der Kapitel über mentale Modelle
(Kapitel 3) und der Methodik zur Externalisierung derselben (Kapitel 4) abgeleitet.
Zusätzlich wird eine explorativ gebildete Hypothese untersucht, die sich auf inhaltli-
cher Ebene mit dem Phänomen der Abbildung von Zusammenhängen durch räumliche
Konfiguration der Konzepte in einem Modell beschäftigt. Dieses Phänomen wurde in
Kapitel 12 bereits aus Sicht der Werkzeugverwendung in Hypothese 7 beschrieben.
13.1. Hypothesen
In diesem Abschnitt werden die Hypothesen abgeleitet, die in diesem Kapitel geprüft
werden. Wie in Kapitel 12 ist zwischen Hypothesen zu unterscheiden, die konzeptuell aus
der Aufgabenstellung bzw. der entwickelten Methodik abgeleitet wurden und solchen,
die explorativ während der Evaluierung selbst gebildet wurden.
13.1.1. Konzeptuell begründete Hypothesen
Die folgenden Hypothesen sind aus der Aufgabenstellung bzw. den Ausführungen zur
Modellierungs-Methodik abgeleitet. Auf die entsprechenden Ausführungen in den Kapi-
teln 3 bzw. 4 wird jeweils bei der Begründung der Hypothesen verwiesen.
Ein wesentlicher Aspekt bei der Externalisierung mentaler Modelle ist die Offenheit
der Repräsentationssprache. Diese ist aus den Ausführungen in Abschnitt 3.4.3 („Con-
cept Mapping“) begründbar und in Anforderung 4 abgebildet. Unter „Offenheit“ ist
in diesem Zusammenhang die Eigenschaft der Repräsentationssprache gemeint, keine
vordefinierte Semantik der Modellelemente vorzugeben, sondern diese von den Model-
lierenden festlegen zu lassen. Dies umfasst im vorliegenden Fall sowohl die Bedeutung
der unterschiedlichen Konzepttypen als auch die Bedeutung der Verbindungen zwischen
Konzepten. Das Werkzeug darf also in diesem Zusammenhang die Benutzer nicht bei
der Wahl der Repräsentationskonzepte und damit bei der Externalisierung selbst ein-
schränken. Die Prüfung dieser Hypothese ermöglicht die Beurteilung der Erfüllung der
Anforderung 4 (siehe Seite 116).
Hypothese 9 Das Werkzeug schränkt Benutzer semantisch nicht bei der Externalisie-
rung ihrer mentalen Modelle ein.
Das Argument der Nicht-Beschränkung der Benutzer bei der Externalisierung hat ne-
ben der eben beschriebenen Sprach-Dimension auch eine konkrete Modell-Dimension.
Während sich obige Hypothese auf semantische Einschränkungen der Externalisieungs-
möglichkeiten bezieht, sind auch konkrete, strukturelle Einschränkungen bei der Ver-
wendung des Werkzeugs zur Externalisierung eines bestimmten mentalen Modells zu
400
13.1. Hypothesen
berücksichtigen. Die Externalisierung muss – um nicht beschränkend zu wirken – belie-
big umfangreiche Modelle ermöglichen. „Umfangreich“ bedeutet hier, dass das Modell
beliebig viele Elemente enthalten können muss und diese beliebig untereinander in Bezie-
hung gesetzt werden können. Die Prüfung dieser Hypothese ermöglicht die Beurteilung
der Erfüllung der Anforderung 6 (siehe Seite 117).
Hypothese 10 Das Werkzeug ermöglicht die Repräsentation beliebig umfangreicher
Modelle.
Die Möglichkeit durch die Entstehungsgeschichte des erstellten Modells zu navigie-
ren ist eine Funktion, die ebenfalls hinsichtlich ihrer Wirkung auf die Externalisierung
mentaler Modelle untersucht werden muss. In der dieser Funktionalität zugrunde lie-
genden Literatur ((Shipman und Hsieh, 2000), (Klemmer et al., 2002)) wird diese als
wesentlich bezeichnet, wenn Externalisierungsprozesse unterbrochen werden, kooperativ
durchgeführt werden oder Dritten die Möglichkeit gegeben werden soll, die Entstehung
des Modells nachzuvollziehen. Allen drei Aspekten liegt die Annahme zugrunde, dass in
der Historie des Externalisierungsprozesses die dem Ergebnis zugrunde liegenden Ide-
en und Annahmen zu erkennen sind. Im Kontext dieser Arbeit bedeutet dies, dass aus
der Nachverfolgung der Historie des externalisierten Modells die diesem zugrunde lie-
genden mentalen Modelle verständlich und nachvollziehbar werden. Die Prüfung dieser
Hypothese ermöglicht die Beurteilung der Erfüllung der Anforderung 8 (siehe Seite 117).
Hypothese 11 Die Reflexion des Modellierungsverlaufs ermöglicht das Verständnis der
im dem Modell repräsentierten Inhalte.
Die Externalisierung mentaler Modelle mit Hilfe von computer-gestützten Werkzeu-
gen ist keine originäre Idee dieser Arbeit. Computerunterstützung existiert vor allem
im Bereich des „Concept Mapping“ (siehe Abschnitt 3.4.3), das methodisch maßgeblich
in das vorgeschlagene Vorgehen des hier vorgestellten Ansatzes einfließt (siehe Kapi-
tel 4). In den existierenden Werkzeugen werden jedoch die kooperative Erstellung und
kommunikative Validierung und Abstimmung der externalisierten Modelle nicht explizit
berücksichtigt. Beide Aspekte sind jedoch – wie bei der Beschreibung der Strukturle-
getechniken 3.4.2 ausgeführt – wichtig für den Abgleich mentaler Modelle und damit
für die erfolgreiche Durchführung von „Articulation Work“. Die Ermöglichung und Stär-
kung der Kooperation der Beteiligten untereinander ist also ein wesentlicher Teilaspekt
der Anforderung 7 an das Werkzeug („Kooperative und unmittelbare Manipulierbarkeit
des Modells“). Die Prüfung der folgenden Hypothese ermöglicht so die Beurteilung der
Erfüllung der Anforderung 7 (siehe Seite 117).
Hypothese 12 Die Verwendung des Werkzeugs führt zu stärkerer Kooperation bei der
Modellerstellung als die Verwendung von bildschirm-basierten Werkzeugen.
Hinsichtlich der in Kapitel 5 formulierten Anforderungen können die hier formulierten
Hypothesen zusammenfassend wie in Tabelle 13.1 dargestellt eingeordnet werden. Die
401
13.2. Untersuchungsdesign und Durchführung
Untersuchung der Hypothesen stellt dabei den zweiten Schritt zur Prüfung der effektiven
Unterstützung von „Articulation Work“ dar. Neben dem Werkzeug selbst wird nun auch
die Methodik in die Untersuchung mit einbezogen und so die Anwendung des gesamten
Instruments im Kontext der Durchführung von „Articulation Work“ untersucht.
Tabelle 13.1.: Hypothesen zur Anwendung des Instruments und deren Bezug zu den
Anforderungen an das Werkzeug
Hypothese Anforderung
9 4
10 6
11 8
12 7
13.1.2. Explorativ gebildete Hypothesen
Im Verlauf der Durchführung der Anwendungen in den Evaluierungsblöcken 1 und 2 war
die Herstellung von Verbindungen zwischen Modellelementen aus technischen Gründen
schwierig zu benutzen und sehr anfällig für Fehlfunktionen. Dies führte dazu, dass Ver-
binder nahezu nicht verwendet wurden (siehe dazu die Auswertungen zu Hypothese 1 in
Abschnitt 12.3.1 sowie die Auswertungen zu Hypothese 7 in Abschnitt 12.3.7). In dieser
Situation wurden Beziehungen zwischen Modellelementen von den Benutzern durch die
räumliche Anordnung der Elemente ausgedrückt. Diese implizite Darstellung von relatio-
naler Information erfolgte in allen Fällen spontan und ohne Anleitung oder Instruktion.
Dies führte zu der Vermutung, dass die Verwendung von Verbindern zur Abbildung von
Beziehungen bzw. Zusammenhängen zwischen Elementen nicht notwendig ist. Um diese
Vermutung zu prüfen, wurde sie formal als Hypothese 13 in die Untersuchung aufge-
nommen.
Hypothese 13 Zur Abbildung von Zusammenhängen ist die Verwendung von Verbin-
dern nicht notwendig.
13.2. Untersuchungsdesign und Durchführung
In diesem Abschnitt wird auf Basis der oben formulierten Hypothesen das Untersu-
chungsdesign abgeleitet und die Durchführung der Untersuchung beschrieben. Der erste
Teil des Abschnitts beschreibt die Operationalisierung der Hypothesen und damit die
Festlegung wie diese konkret geprüft werden können. Im zweiten Teil des Abschnitts wird
402
13.2. Untersuchungsdesign und Durchführung
die Durchführung der Prüfung beschrieben. Hier erfolgt neben der Zuordnung der einzel-
nen Evaluierungsblöcke (siehe Abschnitt 11.2) auch die Darstellung rein beschreibender
Modell-Parameter, die nicht unmittelbar in die Prüfung der Hypothesen eingehen.
13.2.1. Operationalisierung
In diesem Abschnitt wird für jede Hypothese identifiziert, in welcher Form sie geprüft
werden kann. Dies umfasst die Festlegung der Messpunkte sowie der jeweiligen Mess-
und Auswertungsmethode (letzte bezugnehmend auf den in Abschnitt 11.3 beschriebe-
nen Verfahren). Zudem werden jene Evaluationsblöcke festgelegt, die für die jeweilige
Untersuchung herangezogen wurden.
Für jede Hypothese wird also spezifiziert, anhand welcher Aspekte diese geprüft wer-
den kann (= abhängige Variablen). Zudem wird festgelegt, welche Ausgangssituation
bei der Anwendung gewählt werden muss, um die Prüfung durchführen zu können (=
unabhängige Variable) und welche Faktoren die Beurteilung ggf. ungewollt beeinflussen
können (= Störvariablen).
Keine semantische Einschränkung der Externalisierung
Gegenstand dieses Abschnitts ist die Prüfung der Hypothese 9. Diese bezieht sich auf
die geforderte Eigenschaft des Werkzeugs, die Benutzer bei der Modellierung semantisch
nicht einzuschränken.
Voraussetzung für die Prüfung dieser Hypothese ist die Verwendung des Werkzeugs zur
Modellbildung bei einer Aufgabe, die die semantischen Kategorien der Strukturierung
nicht vorgibt. In der eingesetzten Methodik wird die Festlegung von Elementtypen expli-
zit gefordert (Vorgehen und Zeitpunkt dafür werden jedoch nicht vorgegeben). Etwaige
Modellierungsvorkenntnisse können diese Festlegung insofern beeinflussen, als dass die
Konzepte bekannter Sprachen bevorzugt eingesetzt werden könnten. Im Sinne der Hy-
pothese ist dies jedoch keine Störvariable, da die Forderung nach nicht einschränkender
Struktur auch die Verwendung existierender Modellierungssprachen umfassen muss.
Die nicht einschränkende Wirkung kann qualitativ anhand von Benutzeraussagen und
dem Prozess und Ergebnis der Modellentstehung beurteilt werden. Im ersten Fall bie-
ten sich neben der direkten Frage nach der Abbildbarkeit der gewünschten Information
auch Teilaspekte des PMS1-Framework (Sedera et al., 2002) an, das unter anderem die
subjektiv wahrgenommene Qualität des Modellierungsergebnisses und die Abbildbarkeit
der subjektiv wichtigen Information im Modell abbildet (siehe (Wahlmüller, 2010) zur
Eignung des PMS-Frameworks im Kontext dieser Arbeit). Am Prozess und Ergebnis
der Modellentstehung selbst kann beurteilt werden, ob und inwieweit die zur Verfügung
1Process Modelling Success
403
13.2. Untersuchungsdesign und Durchführung
gestellten semantisch nicht vorbelegten Modellierungselemente für die Abbildung der ge-
wünschten Information ausreichend bzw. geeignet waren. Dazu kann betrachtet werden,
ob die beschränkte Anzahl von Elementen im Verlauf der Modellierung zu verändertem
Vorgehen in der Abbildung oder zur Nichtabbildung bestimmter Modellaspekte führte
und ob durch semantische Mehrfachbelegung bzw. die Einführung von nicht als Mo-
dellierungselement vorgesehenen Bausteinen der Sprachumfang über das ursprünglich
intendierte Maß hinaus erweitert wurde.
Vergleichend können zusätzlich Modelle herangezogen werden, die aus identischen Fra-
gestellungen wie jene mit dem Werkzeug erstellten resultieren, bei denen jedoch ein in
der Anzahl und Semantik der Modellierungselemente frei erweiterbares Werkzeug zum
Einsatz kommt. Hier ist von Interesse, ob die erstellten Modelle semantisch vielfältiger
sind als jene, die mit dem hier vorgestellten Werkzeug erstellt wurden.
Repräsentation beliebig umfangreicher Modelle
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 10. Dabei wird
überprüft, ob das Werkzeug die Abbildung beliebig umfangreicher Modellierungsaufga-
ben ermöglicht.
Voraussetzung zur Prüfung dieser Hypothese ist die Verwendung von Modellierungs-
aufgaben, die zu umfangreichen Modellen führen. Umfangreiche Modellierungsaufgaben
sind Aufgaben, die bei detaillierter Modellierung >15 Modellelemente benötigen2. Dies
ist deshalb notwendig, weil der wesentliche beschränkende Faktor des Umfangs eines
Modells am hier vorgestellten Werkzeug die physisch eingeschränkte Größe der Model-
lierungsoberfläche ist. Etwaige Modellierungsvorkenntnisse der Benutzer sind bei der
Prüfung dieser Hypothese nicht von Relevanz.
Um Schlussfolgerungen auf eine etwaig einschränkende Wirkung des Werkzeugs auf
den Umfang der Modelle treffen zu können, muss eine entsprechende Aufgabenstellung
einerseits mittels des hier vorgestellten Werkzeugs („Experimentalgruppe“) und anderer-
seits mit einem Werkzeug, das den Umfang der Modellierungsoberfläche nicht begrenzt
(„Kontrollgruppe“), abgebildet werden. Die Ergebnisse der beiden Gruppen werden in
der Folge gegenübergestellt. Falls bei identischer Fragestellung der Umfang der Modelle
in der Kontrollgruppe signifikant höher ist als jener der Experimentalgruppe, kann von
einer einschränkenden Wirkung ausgegangen werden und die Hypothese müsste abge-
lehnt werden.
Daneben sind wiederum Aussagen der Benutzer über die Abbildbarkeit umfangreicher
Modelle zur Prüfung der Hypothese heranzuziehen. Entsprechende Fragen wurden in
den Evaluierungsblöcken 2, 3, 4 und 5 gestellt, wobei die Fragestellungen in den Blöcken
2 und teilweise 4 eher nicht zu umfangreichen Modellen führten. Diese fanden außer
215 wurde als Grenze gewählt, weil diese Anzahl die Obergrenze an gleichzeitig am Werkzeug ver-
wendbaren Elementen darstellt.
404
13.2. Untersuchungsdesign und Durchführung
in Ausnahmefällen auf der Oberfläche ausreichend Platz und werden deshalb hier nicht
berücksichtigt.
Reflexion des Modellierungsverlaufs
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 11. Dabei wird
überprüft, ob die Möglichkeit zur Reflexion des Modellierungsverlaufs das Verständnis
der zugrundeliegenen mentalen Modelle ermöglicht bzw. verbessert.
Zur Prüfung dieser Hypothese müssen Modellierungsaufgaben durchgeführt werden,
in deren Rahmen die Interpretation eines Modells durch an der Modellbildung nicht
beteiligte Personen durchgeführt werden. Wenn diese Interpretation den ursprünglich
vom Modellierer repräsentierten Inhalten entspricht, ist die Interpretation als erfolg-
reich zu bezeichnen. Zu beurteilen ist nun, inwieweit die Möglichkeit zur Wiedergabe
des Modellierungsverlaufs bei der Interpretation genutzt wurde und ob diese Nutzung
Auswirkungen auf die Interpretation hatte.
Zur Beurteilung wird eine Modellierungssituation geschaffen, in der das Werkzeug zur
Externalisierung eines mentalen Modells benutzt wird. In einem zweiten Schritt wird
eine weitere, zuvor nicht beteiligte Person aufgefordert, den Inhalt der auf der Modellie-
rungsoberfläche vorhandenen Repräsentation zu interpretieren, wobei der Modellierungs-
verlauf herangezogen werden darf, eine Interaktion mit dem ursprünglichen Modellierer
jedoch nicht gestattet ist. Im dritten Schritt beurteilt der ursprüngliche Modellierer die
Adäquatheit der Interpretation und trifft so eine Aussage über den Erfolg des Trans-
fers des mentalen Modells. In Kombination lässt sich eine qualitative Aussage über die
Effekte der Historienfunktion treffen.
Wirkung auf die Kooperation bei der Modellerstellung
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 12. Gegenstand
der Untersuchung ist hier, ob die Verwendung des Werkzeugs bei der Modellbildung zu
stärkerer Kooperation zwischen den Beteiligten führt als der Einsatz von bildschirmba-
sierten Werkzeugen.
Die Prüfung der Wirkung des Werkzeugs auf die kooperative Abbildung von Modellen
bedingt Fragestellungen, die Kooperation explizit einfordern. Etwaige Modellierungsvor-
kenntnisse beeinflussen die Prüfung der Hypothese nicht. Bei der Beurteilung zu berück-
sichtigen sind aber bestehende persönliche Bekanntschaften oder etablierte Gruppen, die
bereits gefestigte Formen der Zusammenarbeit entwickelt haben. Um den Einfluss der-
artiger Faktoren möglichst auszuschließen, müssen die Gruppen bei der Modellbildung
zufällig gebildet werden und etwaige Bekanntschaften innerhalb der gebildeten Gruppen
explizit im Vorfeld der Untersuchung erhoben werden.
405
13.2. Untersuchungsdesign und Durchführung
Die hier zu prüfende Hypothese baut auf Hypothese 2 auf. Dort war zu prüfen, ob das
Werkzeug kooperatives Arbeiten grundsätzlich ermöglicht. In diesem Abschnitt wird
geprüft, ob der Einsatz des Werkzeugs hinsichtlich der Kooperation der Beteiligten tat-
sächlich einen messbaren Vorteil gegenüber einem traditionellen, bildschirmbasierten
Werkzeug hat. Dazu ist es notwendig, eine vergleichende Untersuchung durchzuführen.
Evaluierungsblock 5 wurde dementspechend geplant und umfasste die kooperative Abbil-
dung eines Modells sowohl am Modellierungstisch als auch mittels des bildschirmbasier-
ten Werkzeugs „CMapTools“. Die Aufgabenstellung wurde so gewählt, dass das resultie-
rende Modell grundsätzlich in beiden Werkzeugen abgebildet werden konnte. Untersucht
wurde, in welchem Ausmaß Kooperation zwischen den beteiligten Personen auftrat. Als
Metriken dienen dabei die Zeitverteilung der Beteiligung am Modellierungsvorgang, der
Zeitanteil an Diskussion während der Modellbildung sowie die Anzahl der Initiativwech-
sel („Turn-Taking“) während eines Durchgangs. Zusätzlich werden die Benutzer hinsicht-
lich des subjektiv empfundenen Ausmaßes der Kooperation sowie der Zufriedenheit mit
den im Modell sichtbaren von ihnen selbst eingebrachten Inhalten befragt werden.
Zur Berechnung der Zeitverteilung wird nicht der Zeitanteil der physischen, sondern
jener der inhaltlichen Initiative herangezogen. Wo kein die Initiative führender Teilneh-
mer identifizierbar ist, wird der betreffende Zeitabschnitt zu gleichen Teilen zwischen
den Teilnehmern aufgeteilt. Die Zeitverteilung zwischen den Teilnehmern kann dann
insofern in die Prüfung einfließen, als dass sehr niedrige oder sehr hohe Zeit-Anteile ein-
zelner Teilnehmer auf eine unausgewogene Modellierungsbeteiligung hinweisen. Dieses
Indiz muss jedoch durch Benutzeraussagen verifiziert werden, da geringe Beteiligung an
der Modellierung nicht notwendigerweise auf eine als mangelhaft empfundene Koopera-
tion hinweist.
Der Zeitanteil an Diskussion während des Modellierungsvorgangs betrifft nur jenen
Anteil an der Modellierungsdauer, in dem ein inhaltlicher Austausch zwischen den Teil-
nehmern im Sinne der Aufgabenstellung stattfindet. Nicht berücksichtigt werden jene
Zeiten, in denen das Modell erstellt wird oder in denen nicht im Sinne der Aufgaben-
stellung gearbeitet wird (etwa bei Fehlfunktionen).
Der Wechsel der Initiative („Turn-Taking“ (Sacks et al., 1974)) bei der Modellierung
bezieht sich im Gegensatz zu der Berechnung der Zeitverteilung zwischen den Teilneh-
mern auf die physische Initiative bei der Erstellung des Modells. Während in der von
Sacks et al. (1974) vorgeschlagenen Methodik zur Identifikation von Initiativwechsel
auf Konversationen eingegangen wird und damit auf Sprecherwechsel Bezug genommen
wird, wird in diesem Fall die Übernahme der physischen Initiative als „Turn“ bezeich-
net. Dies ist insofern eine für die Untersuchung der Modellierung sinnvolle Festlegung,
als dass jener Teilnehmer, der die physische Kontrolle über die Eingabemedien besitzt
auch exklusiven Zugriff auf die Interaktionsmöglichkeiten mit dem System besitzt und
damit potentiell als „Filter“ zwischen den Eingaben der anderen Teilnehmer und der im
System repräsentierten Information wirkt.
406
13.2. Untersuchungsdesign und Durchführung
Abbildung von Zusammenhängen ohne Verbinder
Gegenstand dieses Abschnitts ist die Operationalisierung der Hypothese 13. Gegenstand
der Untersuchung ist die Beobachtung, dass zur Abbildung von Zusammenhängen die
Verwendung von explizit dargestellten Verbindern nicht notwendig ist.
Die Prüfung dieser Hypothese stellt keine Vorbedingungen an die Modellierungsauf-
gabe oder die Modellierungsvorkenntnisse der Benutzer. Auch können individuelle An-
wendungen der Werkzeugs (d.h. nicht nur in kooperativen Szenarien) zur Untersuchung
verwendet werden.
Bei der Prüfung der Hypothese ist die Notwendigkeit von explizit dargestellten Verbin-
dern in zwei Fälle zu unterscheiden. Zum einen ist die Notwendigkeit bei der kooperativen
Erstellung eines Modells zu prüfen, bei der sämtliche Beteiligte zu einer einheitlichen In-
terpretation des dargestellten Modells kommen sollen. Zum anderen muss auch der Fall
einer zeitlich nachgelagerten Interpretation durch Dritte untersucht werden. Hier ist zu
erheben, ob die Interpretation des Modellinhalts dem ursprünglichen Verständnis des
bzw. der Modellierenden entspricht.
Zur Untersuchung muss dem ursprünglichen Modellierer jeweils eine inhaltliche Inter-
pretation des Modellierungsergebnisses rückgespiegelt werden. Diese Form der kommu-
nikativen Validierung kommt methodisch im Rahmen der Anwendung von Strukturlege-
techniken (siehe Abschnitt 3.4.2) zum Einsatz und ist deshalb ohnehin Teil der in dieser
Arbeit vorgeschlagenen Methodik bei der kooperativen Anwendung des Werkzeugs. Zur
zeitlich nachgelagerten Interpretation bedarf es einem separaten Schritt, in dem das
Modellierungsergebnis von einer dritten, an der Modellierung nicht beteiligten Person
interpretiert und rückgespiegelt wird.
13.2.2. Durchführung
In diesem Abschnitt werden die für diesen Evaluierungs-Teil relevanten deskriptiven Pa-
rameter der berücksichtigten Anwendungs-Blöcke angeführt. Als Grundlage der Über-
prüfung der Hypothesen werden hier die Evaluierungs-Blöcke 1 bis 5 verwendet. Dabei
wurden für die quantitativ zu prüfenden Variablen die Blöcke 2, 3 und 5 herangezogen,
da in diesen die größten Stichproben zur Verfügung standen. In die qualitative Auswer-
tung der Ergebnisse wurden hingegen alle Blöcke (1-5) mit einbezogen.
Stichprobe
Für die Untersuchung der Hypothesen in diesem Kapitel wurden die Evaluierungsblöcke
1 bis 5 herangezogen. Die Stichprobe setzt sich wie in Tabelle 13.2 beschrieben zusam-
men.
407
13.2. Untersuchungsdesign und Durchführung
Tabelle 13.2.: Stichproben der Evaluierung zur Modellbildung
Evaluierungsblock nAnwendungen nTeilnehmende
1 technische Evaluierung 9 18
2a Aushandlung 1 (1. Durchgang) 9 19
2b Aushandlung 1 (2. Durchgang) 9 18
3 Concept Mapping 1 18 54
4 Aushandlung 2 10 13
5a Concept Mapping 2 (Tisch) 11 24
5b Concept Mapping 2 (CMapTools) 12 25
Gesamt 78 171
Modellgröße
Die Verteilung der Modellgröße wurde hier anhand der Anzahl der verwendeten Elemente
(siehe Abbildung 13.2) und der Anzahl der verwendeten Verbindungen (siehe Abbildung
13.3) dargestellt. Berücksichtigt wurden dabei die Ergebnisse der Evaluierungsblöcke 2
(„Aushandlung“) und 3 („Concept Mapping“). Die Modelle der Evaluierungsblöcke 1 und
4 sind aufgrund der uneinheitlichen Aufgabenstellungen nicht aussagekräftig zusammen-
fassbar, jener Teil des Evaluierungsblocks 5, der mit dem hier vorgestellten Werkzeug
durchgeführt wurden, weist ob der identischen Aufgabenstellung hohe Ähnlichkeit mit
den Ergebnissen von Block 3 auf.
Abbildung 13.2.: Anzahl der verwendeten Elemente – Übersicht
408
13.2. Untersuchungsdesign und Durchführung
In Abbildung 13.2 ist zu erkennen, dass der Median der Anzahl der verwendeten Ele-
mente zwischen 7 und 12 liegt, wobei die Concept Mapping Aufgabe wegen des nicht
explizit vorgegebenen Detaillierungsgrades der Modellierung eine höhere Schwankungs-
breite (mit starker Tendenz zu größeren Modellen) aufweist. Zwar war der Detaillie-
rungsgrad der Aushandlungsaufgaben ebenfalls nicht explizit vorgegeben, hier ist jedoch
eine höhere Überstimmung hinsichtlich des angemessenen Detaillierungsgrades gegeben.
Auffällig ist außerdem, dass zwischen den beiden Durchgängen des Evaluierungsblocks-
blocks ein (statistisch allerdings wegen der geringen Stichprobengröße nicht signifikanter)
Unterschied in der Größe der Modelle (gemessen an der Anzahl der Elemente) gegeben
ist (zweiseitiger t-Test für gepaarte Stichproben: t = 1.548, p = 0.1603)). Dies ist nach
Betrachtung der qualitativ erhobenen Daten aus den entsprechenden Videoaufzeichnun-
gen einerseits darauf zurückzuführen, dass der zweite Durchgang in einer späteren Phase
des produktiven Arbeitsprozesses durchgeführt wurde, in dem weniger offene Schritte zu
behandeln waren, andererseits war durch die bereits etablierte Zusammenarbeitsprozes-
se generell weniger Abstimmungsbedarf gegeben. Dieser Eindruck wird auch durch die
generell geringere Modellierungdauer in Durchgang 2 (siehe Abbildung 12.4) bestärkt.
Abbildung 13.3.: Anzahl der verwendeten Verbindungen – Übersicht
Eine ähnliche Verteilung wie im Falle der Elemente ergibt sich bei Betrachtung der
Anzahl der Verbindungen (siehe Abbildung 13.3). Auffällig ist jedoch die gegenüber
Durchgang 2 des Evaluierungsblocks geringere Anzahl von Verbindungen in Durchgang
1 während sich die Anzahl der Blöcke zwischen den beiden Modellierungsdurchgängen
umgekehrt verhält. Wie in der Überprüfung der Hypothese 7 in Abschnitt 12.3.7 be-
stätigt, ist dieses Phänomen auf die Fehlfunktionen und Instabilität der ursprünglichen
3Des t-Test kann angewandt werden, da für beide Stichproben die Nicht-Normalverteilung nicht bestä-
tigt werden kann (Shapiro-Wilk-Test: WDG1 = 0.949, pDG1 = 0.675, WDG2 = 58.5, pDG2 = 0.120)
und sich auch die Varianzen nicht signifikant unterscheiden (F-Test: F = 2.051, p = 0.330).
409
13.2. Untersuchungsdesign und Durchführung
Funktion zur Herstellung von Verbindungen zurückzuführen, die in Durchgang 1 aus-
schließlich zur Verfügung stand, während in Durchgang 2 (und auch im Block „Concept
Mapping“) bereits die zusätzliche Funktion zur Verbindungsherstellung verfügbar war.
Vernetzungsgrad
Der Vernetzungsgrad der Modelle („Connectedness“) wurde bereits zur Überprüfung der
Hypothese 7 in Abschnitt 12.3.7 betrachtet, ist jedoch eine Eigenschaft der erstellten
Modelle an sich und wird hier deshalb nochmals als deskriptiver Parameter beschrieben.
Abbildung 13.4.: Vernetzungsgrad (Verbindungen / Blöcke) – Übersicht
Abbildung 13.4 zeigt die Verteilung des Verhältnisses der Anzahl von Verbindun-
gen und Blöcken in den Evaluierungsblöcken 2 bis 5. Zu erkennen ist der oben und
in Abschnitt 12.3.7 bereits beschriebene geringere Vernetzungsgrad im ersten Durch-
gang von Evaluierungsblock 2, der auf die Instabilität und schwierige Verwendbarkeit
der ursprünglichen Funktion zur Herstellung von Verbindungen zurückzuführen ist.
Seit der Verfügbarkeit der neuen Funktion zur Herstellung von Verbindungen (also im
zweiten Teil von Block 2 sowie in den Blöcken 3, 4 und 5) liegt der Vernetzungsgrad im
Mittel immer um oder höher 1, wobei in den letzten Blöcken (4 und 5) tendenziell noch
410
13.3. Ergebnisse
höhere Vernetzungsgrade auftreten (Bock 4 im Mittel 1.384 - SD = 0.617, Block 5 im
Mittel 1.101 - SD = 0.337). Im Falle von Block 4 kann dies teilweise auf die Aufgaben-
stellungen zurückgeführt werden, die zum Teil starken Fokus auf die Repräsentation von
Beziehungen legte (maximaler Vernetzungsgrad: 24/8 = 3). Bei beiden Blöcken wurden
außerdem weitere Stabilisierungsmaßnahmen in der Interaktions-Erkennungsleistung des
Systems vorgenommen, weshalb der gestiegene Vernetzungsgrad zum Teil auch auf die
einfachere Herstellbarkeit von Verbindungen zurückgeführt werden kann (siehe wieder-
um 12.3.7).
13.3. Ergebnisse
In diesem Abschnitt werden die Ergebnisse der Untersuchung gegliedert nach den oben
formulierten Hypothesen dargestellt. Zu jeder Hypothese wird die Auswertung der em-
pirischen Daten dargestellt, die Bedeutung der empirischen Belege für die Prüfung der
jeweiligen Hypothese diskutiert und letztendlich das Ergebnis zusammenfassend darge-
stellt.
13.3.1. Keine semantische Einschränkung der Externalisierung
Gegenstand der hier beschriebenen Untersuchung Hypothese 9 („Das Werkzeug schränkt
Benutzer semantisch nicht bei der Externalisierung ihrer mentalen Modelle ein.“). Als
Grundlage dieser Untersuchung dienen die Ergebnisse der Evaluierungsblöcke 2 bis 5, da
in diesen die den einzelnen Modellelementen zugewiesene Semantik explizit untersucht
wurde. Die Daten hinsichtlich der empfundenen Einschränkung bei der Modellbildung
stammen aus der Befragung, die im Rahmen des Evaluierungsblocks 4 durchgeführt wur-
de. Zusätzlich wurde das Videomaterial aller fünf Evaluierungsblöcke zur Auswertung
herangezogen.
Auswertung
Die „Nicht-Einschränkung“ der Benutzer bei der Externalisierung kann, wie in Abschnitt
13.2.1 beschrieben, anhand des Modellierungsverhaltens der Benutzer beurteilt werden.
Von Interesse ist hier die Zuweisung von Bedeutung (also semantischer Information) zu
den (semantisch nicht vorbelegten) Modellierungselementen. Davon stehen grundsätzlich
drei Arten von Blöcken („rot“, „gelb“, „blau“) sowie drei Arten von Verbindern („unge-
richtet“, „gerichtet“, „bidirektional“). Erhoben wurde, wie viele Elemente im Verlauf der
Modellierung mit Bedeutung belegt wurden, ob die Teilnehmenden mehr als die zur Ver-
fügung stehenden Elemente benötigt hätten und ob ein Element im Modellierungsverlauf
mit mehr als einer Bedeutung belegt wurde.
411
13.3. Ergebnisse
Zu beachten ist hier, dass die Bedeutungsbelegung immer Ergebnis eines Aushand-
lungsprozesses zwischen mindestens zwei Beteiligten ist. Aus dieser Teiluntersuchung
kann also kein Rückschluss auf die individuell empfundene Einschränkung der Exter-
nalisierung getroffen werden. Nachdem der Prozess der Bedeutungsfestlegung aber in-
härenter Bestandteil der kooperativen Modellbildung ist und die Zielsetzung derselben
die Herstellung eines gemeinsamen Verständnisses ist, ist dies im Falle einer tatsächlich
kooperativ vorgenommenen Festlegung der Bedeutung nicht als Einschränkung zu se-
hen. Eine individuell als einschränkend wahrgenommene Situation kann vielmehr dann
auftreten, wenn die Bedeutungsfestlegung nicht kooperativ durchgeführt wurde, sondern
die Bedeutungen von einem Teilnehmenden vorgegeben wurde. Die individuell empfun-
dene Einschränkung wurde im zweiten Teil der hier beschriebenen Untersuchung mittels
einem auf dem PMS basierenden Fragebogen sowie einer Auswertung der offenen Fragen
zur Eignung des Werkzeugs zur Modellbildung erhoben.
In Tabelle 13.3 ist für jeden Evaluierungsblock ausgeführt, in wie vielen Fällen eine
bestimmte Anzahl von Blöcken mit Bedeutung belegt wurde und wie viele Arten von
Verbindern benutzt wurden. Unterschiedliche Bedeutungen auf unterschiedlichen Mo-
dellebenen (also in eingebetteten Teilmodellen) wurden ohne separate Unterscheidung
mitgezählt.
Tabelle 13.3.: Anzahl der bedeutungstragenden Elemente je Modell
EB 1 E. 2 E. 3 E. 4+ E. 1 V. 2 V. 3 V. 4+ V.
2 - 1 0 2 9 0 4 1 0 0
2 - 2 1 0 8 0 6 1 0 1
3 0 3 14 0 6 4 0 6
4 0 2 7 2 3 4 2 1
5 0 1 7 3 11 0 0 0
Ges. 1 8 45 5 30 10 2 8
EB . . . Evaluierungsblock, x E.. . . x Elemente mit Bedeutung belegt, x V. . . . x Arten von
Verbindungen verwendet
In jenen beiden Fällen in Evaluierungsblock 4 und den drei Fällen in Evaluierungs-
block 5, in denen 4 oder mehr bedeutungstragende Elemente verwendet wurden, wurden
zweimal 4, und je einmal 6, 7 und 9 Elementtypen festgelegt. Beide Modelle enthiel-
ten jedoch ineinander verschachtelte Teilmodelle, von denen keines mehr als drei Typen
beinhaltete. Jene Fälle, in denen 4 oder mehr verschiedene Arten von Verbindern ver-
wendet wurden, kamen durch den Einsatz benannter Verbinder zustande, mittels derer
die Bedeutung der Verbindungen beliebig differenziert werden kann.
Im zweiten Teil der Untersuchung zu dieser Hypothese wurden qualitativ einerseits
die expliziten Aussagen der Teilnehmenden (nges = 139) hinsichtlich einer eventuellen
einschränkenden Wirkung des Werkzeugs gesammelt, andererseits wurden die Video-
412
13.3. Ergebnisse
aufnahmen der Werkzeuganwendungen diesbezüglich ausgewertet. Folgende Punkte mit
einschränkender Wirkung konnten hier identifiziert werden (in Klammern jeweils die
Quellen sowie die Anzahl des Auftretens der jeweiligen Aussage, sortiert nach der Häu-
figkeit der Nennung):
• Drei unterschiedliche Elementtypen sind zu wenig (verbales Feedback von Per-
sonen mit praktischen Prozessmodellierungskenntnissen4 in den Blöcken 2 und 4
sowie in nicht formal dokumentieren Modellierungssitzungen mit Prozessmodellie-
rungsexperten5 im Rahmen von Demonstrationen auf mehreren Konferenzen, 7x
genannt)
• Dezidierte Elemente zur Modellierung von Verzweigungen und Parallelisierungen
im Kontrollfluss wären wünschenswert (verbales Feedback von Personen mit Pro-
zessmodellierungskenntnissen in den Blöcken 2 und 4 sowie in nicht formal doku-
mentieren Modellierungssitzungen mit Prozessmodellierungsexperten im Rahmen
von Demonstrationen auf mehreren Konferenzen, 5x genannt)
• Selbst festlegbare Formen, Farben und/oder Größen von Modellelementen wären
wünschenswert (verbales Feedback von Personen in Block 4 sowie in nicht for-
mal dokumentieren Modellierungssitzungen mit Strukturaufstellungsexperten6 im
Rahmen von Demonstrationen auf mehreren Konferenzen, 3x genannt)
• Unterschiedliche Farben von Verbindern wären wünschenswert (Befragung in Block
4, 2x genannt)
Explizite Aussagen zu einer dezidiert „nicht-einschränkenden“ Wirkung bzw. der se-
mantischen Offenheit des Werkzeugs konnten nur in Fällen identifiziert werden, in denen
explizit nach diesem Aspekt gefragt wurde. In diesen Fällen wurde der Umfang der Aus-
drucksmöglichkeiten durchwegs als ausreichend erachtet. Personen ohne Vorkenntnisse
in der Prozessmodellierung empfanden die Anzahl der zur Verfügung stehenden Elemen-
te im Allgemeinen als ausreichend, jene Fälle in denen dies nicht der Fall war, sind oben
dokumentiert.
Lediglich in einem der dokumentierten Fälle7 (n = 66) waren die Teilnehmenden mit
der eigenständigen Wahl der Bedeutung der Elementtypen überfordert und begannen
nicht eigenständig zu modellieren. Erst nach einer teilweisen bzw. beispielhaften Vorga-
be von 2 Elementtypen durch den Untersuchungsleiter konnten die Teilnehmenden die
Modellierung selbständig fortführen.
Vergleichend ist festzustellen, dass beim Einsatz der Werkzeugs „CMapTools“, das
die Anzahl der Elementtypen nicht einschränkt, in Evaluierungsblock 5 (n = 12) zwi-
4Nach diesen Kenntnissen wurde im Rahmen einer Selbsteinschätzung explizit gefragt
5jeweils nach Eigendeklaration bzw. aus dem professionellen Umfeld der Personen geschlossen
6das Werkzeug scheint sich zur Unterstützung von Strukturaufstellungen (Sparrer, 2002) zu eignen
(siehe Abschnitt 15.5.3), dies wurde jedoch im Rahmen dieser Arbeit weder als Anwendungsfall
vorgesehen, noch formal getestet
7in Evaluierungsblock 3
413
13.3. Ergebnisse
schen 1 und 8 Elementtypen verwendet wurden, wobei der Median bei 3 liegt (M =
3.5, SD = 2.11). In je einem Fall wurden 1, 7 und 8 Elementtypen verwendet, in zwei
Fällen wurden 3 Elementtypen eingesetzt, in drei Fällen kamen 4 Typen und in vier
Fällen 2 Elementtypen zum Einsatz.
Diskussion
Betrachtet man die Ergebnisse der quantitativen Auswertung der Einsätze des Werk-
zeugs in den Evaluierungsblöcken 2 bis 5, so ist die gegebene Ausdrucksstärke für die
Modellierung weitgehend ausreichend. Dieser Eindruck relativiert sich bei einer ver-
gleichenden Betrachtung mit einem computerbasierten, semantisch vollständig offenen
Werkzeug sowie bei Betrachtung der qualitativen Auswertung der Benutzeraussagen so-
wie der Videoaufnahmen.
In der vergleichend durchgeführten Studie in Evaluierungsblock 5 zeigt sich, dass bei
keiner Einschränkung der Anzahl der Modellelementtypen in mehr als der Hälfte der
Fälle mehr als die im hier betrachteten Werkzeug zur Verfügung stehenden drei Ele-
menttypen verwendet werden. Dies deutet darauf hin, dass sich die Teilnehmenden an
der beschränkten Anzahl der zur Verfügung stehenden Elemente orientieren, auch wenn
dies – wie aus den Aussagen der Teilnehmenden bei der ex-post-Befragung ersichtlich –
bis auf einige Ausnahmen nicht als Einschränkung wahrgenommen wird.
Aus den qualitativen Rückmeldungen zur Modellierung zeigt sich außerdem, dass Per-
sonen, die in ihrer täglichen Arbeit aktiv mit Prozessmodellierung beschäftigt sind, bei
Aufgabenstellungen, die aufgrund ihrer Fragestellung zu Ablaufbeschreibungen führen,
eher die Verwendung von mehr als drei Elementtypen bevorzugen. Personen, denen Pro-
zessmodellierung fremd ist oder deren Erfahrung damit sich auf eine einmalige, län-
ger zurückliegende Ausbildung beschränkt, konnten ihre Modelle zu ablauforientierten
Fragestellungen ohne Ausnahme mit maximal drei Elementtypen abbilden. Bei nicht
ablauforientierten Fragestellungen ist dieser Unterschied nicht zu beobachten.
In Einzelfällen wurden außerdem weitere Wünsche zur Steigerung der Ausdrucksmög-
lichkeiten im Modell geäußert. Neben dem Wunsch nach unterschiedlich einfärbbaren
Verbindungen zwischen Elementen wurde vor allem der Wunsch nach der Verwendung
beliebiger Gegenstände als Modellelemente mehrfach geäußert, was das Einbringen von
Repräsentation aus der alltäglichen Arbeitspraxis anstelle der abstrakten Modellelemen-
te erlaubt.
Unter Berücksichtigung dieser Einschränkungen kann die hier betrachtete Hypothe-
se mit Vorbehalten bestätigt werden. Tatsächlich wird das Werkzeug bis auf wenige
Ausnahmen nicht als semantisch einschränkend wahrgenommen, die Ergebnisse der ver-
gleichenden Studie zeigen aber auf eine einschränkende Wirkung durch die auf drei
beschränkte Anzahl von Elementtypen.
414
13.3. Ergebnisse
Ergebnis
Die Hypothese 9 kann in der Untersuchung mit Vorbehalten angenommen
werden. Die Verwendung des Werkzeugs zur Modellierung wird (bis auf wenige Aus-
nahmen) nicht als semantisch einschränkend wahrgenommen. Die vergleichende Studie
aus Evaluierungsblock 5 deutet allerdings auf eine einschränkende Wirkung durch die
auf drei beschränkte Anzahl von Elementtypen hin.
13.3.2. Repräsentation beliebig umfangreicher Modelle
Gegenstand der hier beschriebenen Untersuchung Hypothese 10 („Das Werkzeug er-
möglicht die Repräsentation beliebig umfangreicher Modelle.“). Als Grundlage dieser
Untersuchung dienen die Ergebnisse der Modellbildung in Evaluierungsblock 3 und 5
sowie die Befragungen in den Evaluierungsblöcken 1 bis 5.
Auswertung
Von Interesse ist bei der Prüfung dieser Hypothese der Vergleich des Umfangs von Mo-
dellen, die mit dem hier vorgestellten Werkzeug erstellt wurden, mit Modellen, die mit ei-
nem bezogen auf die Größe der Arbeitsfläche unbeschränkten Werkzeug erstellt wurden.
Diese vergleichende Studie wurde im Rahmen der Untersuchungen in Block 5 durchge-
führt. Als Metrik zum Vergleich der Modellgrößen wurde die Anzahl der Modellelemente
verwendet. Abbildung 13.5 zeigt eine Gegenüberstellung der Modellgrößen bei Verwen-
dung der „CMapTools“ als die Größe nicht beschränkendes Werkzeug und dem hier
vorgestellten System8.
Die Betrachtung der Ergebnisse zeigt, dass die Modelle, die mittels der „CMapTools“
erstellt wurden (M = 25.92, SD = 7.04, n = 12), signifikant umfangreicher waren (ein-
seitiger Wilcoxon-Test für ungepaarte Stichproben:W = 8, p < 0.0019), als jene Modelle,
8In allen Boxplots gilt folgende Notation:
• dicke Linie bzw. Box: Bereich zwischen 25%- und 75%-Quantil
• breite Linie quer zur Hauptachse: Median (in horizontalen Boxen) bzw. Mittelwert (in vertikalen
Boxen)
• linke bzw. untere schmale Linie: Bereich zwischen 2,5%- und 25%-Quantil
• rechte bzw. obere schmale Linie: Bereich zwischen 75%- und 97,5%-Quantil
• Kreuze bzw. Kreise: Ausreißer (außerhalb 2,5%- und 97,5%-Quantil)
9Der Wilcoxon-Test muss angewandt werden, da die zweite Stichprobe nicht normalverteilt ist
(Shaprio-Wilk-Test: WCMap = 0.9136, pCMap = 0.2372, WTisch = 0.5786, pTisch < 0.005)
415
13.3. Ergebnisse
Abbildung 13.5.: Gegenüberstellung der Modellgrößen in Evaluierungsblock 5
die mittels dem hier vorgestellten System erstellt wurden (M = 12.18, SD = 6.84, n =
11).
In den Evaluierungsblöcken 3 und 5 wurden insgesamt 30 Modellierungsdurchgänge
durchgeführt, deren Ergebnis aufgrund der Aufgabenstellung bei detaillierte Modellie-
rung mehr als 15 Modellierungselement enthalten müsste (siehe vergleichende Ergeb-
nisse aus Block 5). In insgesamt 7 Fällen wurden mehr als 15 Elemente verwendet
(15 < x <= 20 : 1; 20 < x <= 25 : 2; 25 < x <= 30 : 2; x > 30 : 2), der Me-
dian der Anzahl der Elemente liegt bei Berücksichtigung aller Anwendungen bei 11
(M = 14.68, SD = 7.90, n = 30). Die Möglichkeit der Einbettung von Teilmodellen
wurde insgesamt in 8 Modellierungsdurchgängen genutzt, davon war in drei Fällen die
Gesamtanzahl der Elemente geringer als 15 (womit eine rein semantische Strukturierung
vorliegt und keine Steigerung der Modellumfangs vorgenommen wurde).
Neben der vergleichenden Studie wurde in allen Evaluierungsblöcken nach Abschluss
der Modellbildung nach dem subjektive Eindruck der Teilnehmenden einer etwaig ein-
schränkenden Wirkung hinsichtlich des Umfangs der Modelle gefragt (nges = 139). Ins-
gesamt 43 Teilnehmende empfanden die Modellierungsoberfläche als zu klein um die
gewünschten Sachverhalte abzubilden. Von insgesamt 9 Teilnehmenden wurde explizit
der Wunsch nach kleineren Elementen geäußert, um umfangreichere Modelle abbilden
zu können. Von 23 Teilnehmenden wurde die Visualisierung der Verbindungen kritisiert
(„unübersichtlich“, „nur eine Verbindung zwischen zwei Blöcken möglich“), was dazu
geführt hätte, dass die Modelle nicht wie ursprünglich intendiert aussähen.
Diskussion
Sowohl die quantitativen Ergebnisse auf Evaluierungsblock 5 als auch die qualitativen
Ergebnisse weisen darauf hin, dass die physische Realisierung der Modells, die mit eine
Beschränkung der Modellierungsoberfläche einher geht, die Abbildung beliebig umfang-
reicher Modelle nicht erlaubt.
416
13.3. Ergebnisse
Bei der Gegenüberstellung des quantitativen Teils der Studie mit den qualitativen
Aussagen der Teilnehmenden fällt auf, dass – wie bereits bei der Diskussion der Hypo-
these 9 in Abschnitt 13.3.1 – die subjektive Wahrnehmung der Einschränkung weniger
stark ausgeprägt ist als die vermutete tatsächliche Einschränkung, auf die aufgrund der
quantitativen Daten geschlossen werden kann. Tatsächlich ist jedoch der Anteil der Teil-
nehmer, die das Modell nicht so umfangreich wie intendiert abbilden konnten, höher als
jener, die sich in der semantischen Ausdrucksstärke eingeschränkt fühlten.
Aus den qualitativen Aussagen ist zu erkennen, dass der vorrangige Grund der Be-
schränkung des Modellumfangs die eingeschränkte Größe der Modellierungsoberfläche
ist. Die Möglichkeit zur Einbettung von Teilmodellen zur Steigerung des Umfangs wur-
de nur in einem Sechstel der Fälle verwendet, was darauf hindeutet, dass diese Funktion
keinen Ersatz für eine unbeschränkt große Modellierungsoberfläche (auf einer Abstrak-
tionsebene) darstellt.
Insgesamt kann aufgrund der Ergebnisse der Untersuchung die Hypothese 10 nicht
bestätigt werden.
Ergebnis
Die Hypothese 10 kann in der Untersuchung nicht bestätigt werden. Modelle,
die mit dem hier vorgestellten Werkzeug erstellt wurden, weisen bei identischer Aufga-
benstellung einen signifikant geringeren Umfang auf als Modelle, die mit einemWerkzeug
mit nicht beschränkter Arbeitsfläche erstellt wurden. Auch das qualitative Feedback der
Benutzer deutet darauf hin, dass eine vollständige Abbildung eines Modells (und damit
die Erstellung eines Modells mit größerem Umfang) nicht bzw. nur umständlich möglich
ist.
13.3.3. Reflexion des Modellierungsverlaufs
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 11 („Die Reflexion des
Modellierungsverlaufs ermöglicht das Verständnis der dem Modell abgebildeten Inhal-
te.“). Als Grundlage dieser Untersuchung dienen die Ergebnisse der Evaluierungsblöcke
4 und 5, da die Erfassung und Persistierung der gesamten Modellierungshistorie erst in
diesen Blöcken zuverlässig arbeitete.
Auswertung
Zur Prüfung dieser Hypothese wurden die Modelle aus den Evaluierungsblöcken 4 (Ein-
satz im Unternehmenskontext) und 5 (Concept Mapping 2 – lediglich jene Anwendungen,
die mit dem Modellierungstisch durchgeführt wurden) herangezogen. Die Interpretation
der erstellten Modelle wurde jeweils von einer Person vorgenommen, die an der eigentli-
417
13.3. Ergebnisse
chen Modellierung nicht beteiligt war. Die Beurteilung der Korrektheit und Vollständig-
keit der Interpretation hinsichtlich der von den Modellierungsteilnehmern ausgedrückten
Inhalte erfolgte durch den jeweiligen Untersuchungsleiter, da die Modellierer selbst nicht
mehr zur Verfügung standen.
Interpretiert wurde jeweils einerseits das eigentliche Endergebnis und andererseits das
Endergebnis inklusive aller erfassten Zwischenzustände des Modells während der Mo-
dellentstehung. Beide Interpretationen wurden gegenübergestellt und hinsichtlich ihrer
Korrektheit und Vollständigkeit auf einer vierteiligen Likert-Skala beurteilt („korrekt“
– „eher korrekt“ – „eher nicht korrekt“ – „nicht korrekt“). Zusätzlich wurden qualitativ
etwaige Auffälligkeiten bei abweichenden Interpretationen erhoben.
Im Falle des Evaluierungsblocks 4 wurden 10 Modelle interpretiert. Bei der Interpre-
tation ergab sich die in Tabelle 13.4 dargestellte Verteilung.
Tabelle 13.4.: Korrektheit der Modellinterpretation in Evaluierungsblock 4
korrekt eher korrekt eher nicht korrekt nicht korrekt
nur Ergebnis 0 3 5 2
inkl. Historie 0 8 2 0
Im Falle des Evaluierungsblocks 5 wurden 11 Modelle interpretiert. Bei der Interpre-
tation ergab sich die in Tabelle 13.5 dargestellte Verteilung.
Tabelle 13.5.: Korrektheit der Modellinterpretation in Evaluierungsblock 5
korrekt eher korrekt eher nicht korrekt nicht korrekt
nur Ergebnis 6 4 1 0
inkl. Historie 6 4 1 0
Für die Untersuchung des Unterschiedes zwischen den beiden Interpretationsarten
wurde der Wilcoxon-Test herangezogen. Dies war notwendig, da der Shapiro-Wilk-Test
zeigte, dass beide Stichproben bei Berücksichtigung der beiden Evaluierungsblöcke 4
und 5 nicht normalverteilt waren (WErgebnis = 0.874, pErgebnis = 0.012,WHistorie =
0.792, pHistorie < 0.005).
Entsprechend dieser Testergebnisse wurde ein einseitiger Wilcoxon-Test für gepaarte
Stichproben durchgeführt. Dieser ergab für die Interpretationen unter Einbeziehung der
Historie (n = 21,M = 1.86, SD = 0.655) eine signifikant „korrektere“ Bewertung (V =
28, p = 0.00537) als für die Interpretationen auf Basis des Modellierungsergebnisses
(n = 21,M = 2.19, SD = 0.981).
Trennt man beide Untersuchungen auf, so ergibt sich unter Einsatz der gleichen Test-
Verfahren für die Untersuchung in Evaluierungsblock 4 ein signifikant „korrekteres“ Er-
418
13.3. Ergebnisse
gebnis (V = 28, p = 0.00537) für die Interpretation unter Einbeziehung der Historie
(n = 10,M = 2.2, SD = 0.422) gegenüber der Interpretation auf Basis des Model-
lierungsergebnisses (n = 10,M = 2.90, SD = 0.738). In Evaluierungsblock sind die
Verteilungen der Korrektheitsbeurteilung in beiden Interpretationsvarianten identisch
(n = 11,M = 1.55, SD = 0.688), so dass sich kein signifikanter Unterschied ergeben
kann.
Diskussion
Aus den Untersuchungsergebnissen ist zu erkennen, dass die Interpretation auf Basis der
Modellierungshistorien signifikant besser (d.h. vollständiger und korrekter) ist als die
Interpretation ausschließlich auf Basis des Modellierungsergebnisses. Vor allem ablauf-
orientierte Modelle (wie in Block 4 vorherrschend) sind auf Basis der Modellierungs-
historie besser zu interpretieren (wenn auch auf generell eher niedrigem Niveau – siehe
oben). Im Falle von Modellen, in denen eher konzeptuelle Strukturen abgebildet wurden
(wie die Modelle in Block 5) ist eine Interpretation generell einfacher möglich – hier zeigt
sich allerdings kein Mehrwert bei der Interpretation der Modellierungshistorie. Die hier
geprüfte Hypothese kann auf Basis der beschriebenen Untersuchung bestätigt werden.
Generell ist die eher niedrige Einschätzung von Korrektheit und Vollständigkeit bei
Interpretation der Ergebnisse rein auf Basis von dokumentierten Modellen (sei es das
Endergebnis oder die Historie). Diese fällt weitaus geringer aus als eine Interpretation
auf Basis der ebenfalls vorliegenden Videoaufnahmen der Modellierungen (diese wurde
jedoch nicht formal evaluiert und deshalb nicht in die obige Gegenüberstellung aufge-
nommen). Fraglich bleibt an dieser Stelle, ob die Nachvollziehbarkeit der mit dem hier
vorgestellten System abgebildeten Inhalte ausschließlich auf Basis der gelegten Struk-
turen gegeben ist. Die kompaktere Modelldarstellung (gegenüber bildschirmbasierten
Werkzeugen, siehe Abschnitt 13.3.2) und der eher auf Diskussion denn auf Abbildung
fokussierte Modellierungprozess (siehe Abschnitt 13.3.4) entfalten hier eine einschrän-
kende Wirkung.
Ergebnis
Die Hypothese 11 kann auf Basis der Untersuchung bestätigt werden. Die
Korrektheit und Vollständigkeit der Interpretation von Modellen kann durch die Einbe-
ziehung der Modellierungshistorie signifikant gesteigert werden, ist aber vor allem bei
Modellen, die aus ablauforientierten Fragestellungen entstanden sind, als eher gering
einzuschätzen.
419
13.3. Ergebnisse
13.3.4. Wirkung auf die Kooperation bei der Modellerstellung
Gegenstand der hier beschriebenen Untersuchung Hypothese 12 („Die Verwendung des
Werkzeugs führt zu stärkerer Kooperation bei der Modellerstellung als die Verwendung
von bildschirm-basierten Werkzeugen.“). Als Grundlage dieser Untersuchung dienen die
Videoaufnahmen sowie die Ergebnisse der Teilnehmerbefragung des Evaluierungsblocks
5.
Auswertung
Das Ausmaß der Kooperation lässt sich aus dem Prozess der Modellbildung heraus an
der Verteilung der Modellierungszeit zwischen den Teilnehmern, den Anzahl der In-
itiativwechsel sowie dem Anteil von Diskussionszeit an der Gesamtmodellierungsdauer
messen.
Die Zeitverteilung zwischen den Teilnehmern betrug bei der Durchführung mittels
CMapTools bei einer Gruppengröße von 2 Personen für Teilnehmer A im Schnitt 19 Mi-
nuten 21 Sekunden (SD = 8m11s, n = 11) und für Teilnehmer B im Schnitt 14 Minuten
44 Sekunden (SD = 5m54s, n = 11). Setzt man diese Werte zueinander ins Verhältnis,
ergibt sich ein Anteil von 56.88% für Teilnehmer A und 43.12% für Teilnehmer B. Bei
jener Anwendung, die von drei Personen durchgeführt wurde ergab sich die Verteilung
20 min - 12 min - 8 min (50% - 30% - 20%).
Bei der Durchführung am Modellierungstisch ergab sich bei einer Gruppengröße von 2
Personen für Teilnehmer A im Schnitt 17 Minuten und 18 Sekunden (SD = 6m59s, n =
9) und für Teilnehmer B im Schnitt 13 Minuten 12 Sekunden (SD = 6m01s, n = 9).
Setzt man diese Werte zueinander ins Verhältnis ergibt sich ein Anteil von 57.52% für
Teilnehmer A und 42.48% für Teilnehmer B. Bei den beiden Anwendungen, an denen
drei Personen beteiligt waren, ergab sich eine Verteilung von 5 min - 2.5 min - 2.5 min
(50% - 25% - 25%) bzw. 20 min - 10 min - 3 min (61% - 30% - 9%).
Der Unterschied zwischen den Anteilen im Verhältnis zur gesamten Modellierungsdau-
er (tTNA − tTNB/tges
10, lediglich Anwendungen mit 2 Beteiligten wurden berücksichtigt)
beträgt bei der Anwendung der CMapTools im Schnitt 0.138 (SD = 0.086, n = 11) und
am Modellierungstisch im Schnitt 0.151 (SD = 0.087, n = 9). Zwischen diesen beiden
Werten kann kein signifikanter Unterschied festgestellt werden (zweiseitiger Wilcoxon-
Test11: W = 51, p = 0.8588, n = 20).
Hinsichtlich der Wechsel der Initiative waren bei der Durchführung der Modellierung
mittels CMapTools (n = 12) 8 Fälle zu beobachten, in denen ein Teilnehmer exklusiven
10Als Teilnehmer A wird immer jener Teilnehmer bezeichnet, der den höheren Zeitanteil in der Model-
lierung in Anspruch nahm.
11Die Durchführung des Wilcoxon-Test ist aufgrund der Nicht-Normalverteilung beider Stichproben
notwendig (Shapiro-Wilk-Test: WCMap = 0.9083, pCMap = 0.2032, WTisch = 0.9642, pTisch =
0.8408)
420
13.3. Ergebnisse
Zugriff auf die Eingabemedien über den gesamten Verlauf der Modellierung hatte. In
2 Fällen fanden zwei Initiativ-Wechsel statt, in jeweils 1 einem Fall fanden 4 bzw. 8
Initiativ-Wechsel statt. Bei der Durchführung der Modellierung in dem hier vorgestellten
System (n = 11) wurde in 7 Fällen simultan an der Benutzungsschnittstelle gearbeitet,
es konnten keine Initiativ-Wechsel im Sinne obiger Definition festgestellt werden. In 2
Fällen wurden je 2 Wechsel der Initiative festgestellt, in zwei Fällen kam es zu keinem
Initiativ-Wechsel.
Der Anteil von Diskussionszeit an der Gesamtmodellierungsdauer betrug bei der Durch-
führung mittels CMapTools im Schnitt 57.15% (SD = 7.49%, n = 12) und war da-
mit signifikant niedriger (einseitiger Wilcoxon-Test: W = 120, p < 0.001, n = 23)
als der Diskussionsanteil bei der Arbeit am Modellierungstisch mit im Schnitt 76.08%
(SD = 8.84%, n = 11).
In Evaluierungsblock 5 wurden die Teilnehmer außerdem quantitativ und qualitativ
nach dem Einfluss des Werkzeugs auf die Kooperation befragt. In der quantitativen Aus-
wertung wurden 2 Items (Abschnitt „Kollaboratives Modellieren“ in Block 5 – siehe An-
hang B.3.3) betrachtet, deren Gegenüberstellung einen Vergleich der wahrgenommenen
Wirkung der beiden eingesetzten Werkzeuge ermöglicht. Die Items lauten im Einzelnen:
1. Ich konnte meine persönliche Meinung und Ideen ausreichend einbringen.
2. Das Werkzeug hat die Zusammenarbeit als Team erleichtert.
Insgesamt wurden nCMap = 25 Teilnehmer befragt, die an der Modellierung mit den
CMapTools beteiligt waren. nTisch = 24 Teilnehmer waren an der Modellierung am hier
vorgestellten System beteiligt. Die Ergebnisse sind in Tabelle 13.6 und Abbildung 13.6
zusammengefasst dargestellt. Neben dem Mittelwert und der Standardabweichung wur-
de für jedes Item auch geprüft, ob die Einschätzung als signifikant positiv zu bezeichnen
ist. Dazu wurde ein einseitiger Wilcoxon-Test für die Stichprobe gegenüber dem Skalen-
mittelwert 4 durchgeführt 12.
Tabelle 13.6.: Befragung Kooperative Modellierung im Werkzeugvergleich – Itemauswer-
tung
Item M SD VM<4 pM<4
1CMap 1.52 0.823 0 <0.005
1T isch 1.50 0.659 0 <0.005
2CMap 2.72 1.49 12 <0.005
2T isch 2.33 1.31 3 <0.005
12Der Wilcoxon-Test muss angewandt werden, da die Stichprobe in allen vier Fällen nicht normalverteilt
ist (Shapiro-Wilk-Test: W1C = 0.680, p1C < 0.005, W1T = 0.716, p1T < 0.005, W2C = 0.882, p2C =
0.00742, W2T = 0.852, p2T < 0.005)
421
13.3. Ergebnisse
Abbildung 13.6.: Verteilung der Benutzereinschätzungen zum kooperativen Modellieren
In der Gegenüberstellung der Ergebnisse aus den beiden Teilstichproben für jedes
Item zeigt sich in keinem der Fälle ein statistisch signifikanter Unterschied zwischen
den beiden Stichproben (zweiseitiger Wilcoxon-Test für ungepaarte Stichproben: WI1 =
310, pI1 = 0.826, WI2 = 258.5, pI2 = 0.396).
In der qualitativen Befragung begründeten insgesamt 48 Teilnehmer (25 an den CMap-
Tools, 23 am Modellierungstisch) ihren Eindruck (Fragestellung: „Wie würden Sie Ih-
re Beziehung im Team beschreiben? (Gesprächsablauf, Meinungsverschiedenheiten, ge-
meinsames Arbeiten mit dem Werkzeug)“). Die Ergebnisse sind im Folgenden für jeder
Teilnehmergruppe inhaltlich gruppiert dargestellt.
Die Teilnehmer, die mit den CMapTools gearbeitet hatten, gaben folgende Antworten:
• pos: konstruktive Arbeitsbeziehung (10x)
• pos: Konsens war leicht herzustellen (6x)
• pos: Kooperation war möglich (2x)
• pos: für alle zufriedenstellendes Ergebnis erreicht (2x)
• pos: Werkzeug ermöglicht Übersicht (1x)
• neutral: zu kurze Zusammenarbeit (2x)
• neg: ein Teilnehmer hat dominiert (2x)
Am Modellierungstisch wurden folgende Antworten gegeben:
• pos: konstruktive Arbeitsbeziehung (14x)
• pos: Konsens war leicht herzustellen (2x)
• pos: jeder konnte sich einbringen (2x)
• pos: Team war okay (1x)
422
13.3. Ergebnisse
• pos: schnelle Einigung (1x)
• pos: Kooperation war möglich (1x)
• neg: etwas planlos (2x)
Diskussion
Die Verteilung der Modellierungsdauer zwischen den Teilnehmern als erstgenannter Indi-
kator für funktionierende Kooperation zwischen den Teilnehmern zeigt keine signifikan-
ten Unterschiede zwischen den beiden eingesetzten Werkzeugen. In beiden Fällen zeigt
sich eine im Schnitt annähernde Gleichverteilung der Modellierungsdauer zwischen den
Teilnehmern, was darauf hinweist, dass eine kooperative Modellierung sowohl mit dem
Werkzeug CMapTools als auch mit dem hier vorgestellten Modellierungstisch möglich
ist.
Betrachtet man jedoch die Anzahl der physischen Initiativwechsel, zeigt sich, dass
die Möglichkeit des nicht-exklusiven Zugriffs auf die Benutzungsoberfläche des Modellie-
rungtisches von den Teilnehmern genutzt wird und dazu führt, dass das die Manipulation
des externalisierten Modells unmittelbar von mehr als einem Teilnehmer durchgeführt
wird. Im Falle der mit der Maus und Tastatur bedienten CMapTools führt in den meis-
ten Anwendungen ein Teilnehmer exklusiv die Manipulation des Modells durch. Durch
den Wegfall des inhaltlichen „Filters“, den der manipulierende Teilnehmer bewusst oder
unbewusst potentiell einführen kann, ist am Modellierungstisch eine unmittelbarere Ko-
operation bei der Modellerstellung möglich.
Auch die Verteilung zwischen der zur eigentlichen Modellerstellung benötigten Zeit
und jener Zeit, die zum inhaltlichen Austausch über den Modellierungsgegenstand auf-
gewendet wird, weist darauf hin, dass die Kooperation durch den Einsatz des Modellie-
rungstisches im Vergleich zu den bildschirmbasierten CMapTools gestärkt wird.
Die Befragung der Benutzer zeigt jedoch keine signifikant bessere Wahrnehmung des
hier vorgestellten Werkzeugs gegenüber den im Vergleich eingesetzten CMapTools. Wäh-
rend die Möglichkeit zur Einbringung der eigenen Sichtweise quasi identisch positiv ge-
sehen wurde, zeigt die Einschätzung der Wirkung des Werkzeugs auf die Kooperation
eine tendenziell positivere Ausprägung bei den am Modellierungstisch arbeitenden Teil-
nehmern. Diese Verbesserung ist jedoch nicht statistisch signifikant. Auch die qualita-
tive Betrachtung der Benutzerantworten in den offenen Items ergibt keine wesentlichen
Unterschiede in der Wahrnehmung des Werkzeugs. Lediglich hinsichtlich der negativen
Auffälligkeiten wurde im Falle der CMapTools die exklusive Modellbildung durch einen
Teilnehmer zweimal genannt, wohingegen die kooperative Modellbildung am Modellie-
rungtisch von zwei Teilnehmern (die zusammengearbeitet hatten) als „etwa planlos“ be-
zeichnet wurde. Die Ergebnisse der Benutzerbefragung stärken die Hypothese also nicht,
widersprechen ihr aber auch nicht. Insgesamt kann so die Hypothese als bestätigt ange-
sehen werden. Zur Bestätigung aus Benutzersicht ist eine weitere vergleichende Studie
423
13.3. Ergebnisse
anzudenken, in der die gleichen Teilnehmer anhand verschiedener Aufgaben die Wir-
kung der unterschiedlichen Werkzeuge auf die Kooperation beurteilen. Die Reihenfolge
der Werkzeuganwendung müsste dazu variiert werden, um Lern- bzw. Gewöhnungsef-
fekte kompensieren zu können.
Ergebnis
Die Hypothese 12 kann auf Basis der Untersuchung bestätigt werden. Wäh-
rend die Verteilung des Zeitanteils zwischen den Modellierungsteilnehmern keinen signi-
fikanten Unterschied zwischen den beiden verglichenen Systemen aufweist, zeigt sowohl
der Vergleich der Initiativ-Wechsel als auch der Anteil an zum inhaltlichen Austausch
aufgewandter Zeit einen signifikanten Vorteil hinsichtlich der Kooperationsförderung für
den Modellierungstisch. Die Daten aus der Befragung der Teilnehmer stärken die Hypo-
these zwar nicht signifikant, zeigen aber eine leichte Tendenz zu deren Bestätigung.
13.3.5. Abbildung von Zusammenhängen ohne Verbinder
Gegenstand der hier beschriebenen Untersuchung Hypothese 13 („Zur Abbildung von
Zusammenhängen ist die Verwendung von Verbindern nicht notwendig.“). Als Grundla-
ge dieser Untersuchung dienen die Befragungen sowie die Videoaufnahmen der Evaluie-
rungsblöcke 1 bis 5.
Auswertung
In insgesamt 18 von den in allen 5 Evaluierungsblöcken 66 erstellten Modellen (für eine
detaillierte Aufstellung siehe Abschnitt 12.3.1) wurden keine Verbinder zur Darstellung
von Zusammenhängen zwischen Elementen verwendet. Von diesen 18 Modellen wurden
9 Modelle (in den Evaluierungsblöcken 2 und 3) während der Modellierung von allen
Beteiligten kommunikativ interpretiert. Die Teilnehmenden wurden unmittelbar nach
Abschluss der Modellbildung über ihre subjektive Wahrnehmung der Übereinstimmung
des Verständnisses über den abgebildeten Sachverhalt befragt. Alle Teilnehmer (nges =
21) gaben an, subjektiv ein gemeinsames Verständnis erreicht zu haben. Diese Angaben
decken sich mit den Auswertungen der Modellierungsverläufe in diesen Durchgängen, in
denen in 3 von 9 Fällen während der Modellierung der Eindruck entstand, dass Teile der
Modelle unterschiedlich interpretiert wurden. Diese unterschiedlichen Interpretationen
wurden jedoch in allen Fällen im weiteren Verlauf der Modellierung erkannt und so
abgestimmt, dass ein übereinstimmendes Verständnis hergestellt werden konnte.
Jene 9 Modelle, die in Evaluierungsblock 1 erstellt wurden, wurden von Dritten in-
terpretiert. Die Interpretation wurde dabei den ursprünglichen Modellerstellern rück-
gespiegelt, die wiederum zu beurteilen hatten, ob die Interpretation den ursprünglich
424
13.3. Ergebnisse
repräsentierten Sachverhalt korrekt wiedergibt. Dies war in allen 9 Modellierungsdurch-
gängen der Fall (Befragung mittels einer 4-teiligen Likertskala, 6 mal „gut verstanden“,
3 mal „eher verstanden“, kein „eher nicht verstanden“ oder „nicht verstanden“). Die
Abbildungen 13.7 und 13.8 zeigen Beispiele für Modelle, in denen die korrekte Interpre-
tation auch ohne die Darstellung von Verbindern möglich war.
Abbildung 13.7.: Korrekt intepretierbares Modell ohne Verbinder (hierarchisch)
Die übrigen 46 Modelle, in denen Verbinder verwendet wurden, wurden einer nachge-
lagerten Interpretation durch den Leiter der Studiendurchführung13 unterzogen, der an
der Durchführung von 17 Modellierungsdurchgängen als Untersuchungsleiter beteiligt
war (die übrigen 29 Modellierungsdurchgänge wurden im Rahmen von Diplomarbeiten
erfasst, wobei die jeweiligen Diplomanden als Untersuchungsleiter auftraten). Bei dieser
Interpretation wurden im ersten Schritt für jedes Modell die verwendeten Verbinder ent-
fernt und versucht, den Modellinhalt zu interpretieren. In einem zweiten Schritt wurden
die Verbinder wieder eingeblendet und die Interpretation mit dem nun vollständigen
Modell verglichen. Dabei ergaben sich in 15 Fällen Unterschiede in der Interpretation,
die ausschließlich auf die Verwendung von Verbindern zurückzuführen war. In den üb-
rigen 36 Fällen explizierten bzw. bestätigten die erstellten Verbindungen die durch die
räumliche Anordnung der Modellierungselemente implizit ausgedrückten Zusammenhän-
ge. Dabei ist zu anzuführen, dass in 13 der insgesamt 46 Modelle benannte Verbinder
verwendet wurden (die übrigen 33 Modelle enthielten lediglich unbenannte Verbinder).
Von diesen 13 Modellen konnten 4 auch ohne die Darstellung der Verbinder korrekt (im
13dem Verfasser dieser Arbeit
425
13.3. Ergebnisse
Abbildung 13.8.: Korrekt intepretierbares Modell ohne Verbinder (ablauforientiert)
Sinne der obigen Ausführungen) interpretiert werden. Demnach führte die Entfernung
der Verbinder in 6 der 33 Modelle mit unbenannten Verbindern zu unvollständigen bzw.
fehlerhaften Interpretationen. Abbildung 13.9 zeigt ein Beispiel für ein Modell, in dem
die Entfernung der Verbinder zu einer unvollständigen Interpretation des abgebildeten
Inhalts führte. Im konkreten Fall repräsentieren die Verbinder Kommunikationsflüsse
zwischen Personen. Diese Information geht bei ausschließlicher Darstellung der Model-
lierungselemente verloren.
Diskussion
Das weitgehende Fehlen von Verbindern ist in den ersten beiden Evaluierungsblöcken
sowie Teilen des Evaluierungsblocks 3 auf die mangelhafte Funktion der Verbindungs-
herstellung durch Benutzer zurückzuführen (siehe Prüfung der Hypothese 1 in Abschnitt
12.3.1). Trotzdem war es den Teilnehmenden möglich, ein gemeinsames Verständnis über
die abgebildeten Zusammenhänge zu entwickeln. Auch bei der Interpretation durch Drit-
te, die am Entstehungsprozess des Modells nicht beteiligt waren, traten keine Missver-
ständnisse auf. Dies gilt sowohl für ablauf-orientierte Modelle (in Evaluierungsblock 1
und 2) als auch für Concept-Map-artige Modelle (in Evaluierungsblock 3).
Auf Basis dieser Ergebnisse kann die Hypothese bestätigt werden. Die Bestätigung
ist insofern zu relativieren, als dass den Evaluierungsblöcken 3, 4 und 5 insgesamt 15
Modellierungsdurchgänge identifiziert werden konnten, in denen die Verwendung von
Verbindungen den Modellen Bedeutung hinzufügt, die ohne diese auch implizit nicht
426
13.3. Ergebnisse
Abbildung 13.9.: Bei Vernachlässigung der Verbinder nur unvollständig interpretierbares
Modell
vorhanden war. Eine vorbehaltslose Annahme der Hypothese ist deshalb nicht rechtfer-
tigbar.
Hypothese 13 kann unter Berücksichtigung der obigen Ausführungen damit nicht be-
stätigt werden. Während in vielen Fällen die ausschließliche räumliche Anordnung von
Modellierungselementen ausreichend ist, um die beabsichtigte Bedeutung zu kommuni-
zieren, konnten Fälle identifiziert werden, in denen dies nicht möglich war.
Ergebnis
Die Hypothese 13 kann auf Basis der Untersuchung nicht bestätigt werden.
Während zu Bildung eines einheitlichen Verständnisses in vielen Fällen die implizite
Abbildung von Zusammenhängen durch räumliche Konfiguration der Modellierungsele-
mente ausreichend ist, konnten Fälle identifiziert werden, in denen die explizite Re-
präsentation von Verbindern dem Modell Bedeutung hinzufügte, die ohne Darstellung
derselben nicht kommunizierbar war.
427
13.4. Zusammenfassung
13.4. Zusammenfassung
In diesem Kapitel wurde die Evaluierung des Aspektes der Modellierung mit dem hier
vorgestellten Werkzeug beschrieben. Die hier betrachteten Hypothesen beschäftigen sich
mit dem Modellierungsergebnis an sich sowie dem Prozess der Modellerstellung. In Ab-
grenzung dazu wurde in Kapitel 12 die Verwendung des Werkzeugs im Allgemeinen sowie
dessen Verständlichkeit geprüft. Kapitel 14 beschäftigt sich hingegen mit der Rückwir-
kung der Modellierung bzw. der Modelle auf die eigentlichen Betrachtungsgegenstände
(also etwa operative Arbeitsabläufe).
Im Rahmen dieses Kapitels wurden vier aus der Aufgabenstellung begründbare Hypo-
thesen und eine explorativ während der Evaluierung gebildete Hypothese getestet. Die
ersten beiden Hypothesen beschäftigen sich mit einer eventuell einschränkendenWirkung
des Werkzeugs auf die Modellbildung. Wie in den Anforderungen 4 und 6 formuliert,
muss das Werkzeug zur Unterstützung von „Articulation Work“ einerseits semantische
Offenheit bei der Modellierung bieten (d.h. die Modellierenden nicht bei der Abbildung
der eigenen Konzeptualisierung des abzubildenden Sachverhaltes einschränken) und an-
dererseits die Abbildung beliebig umfangreicher Modelle erlauben.
Hypothese 9 („Semantische Offenheit“) konnte dabei insofern bestätigt werden, als
dass die Teilnehmenden das Werkzeug nur in Einzelfällen als semantisch einschränkend
empfanden. Der Vergleich mit einem semantisch vollständig offenen Werkzeug, dass die
Anzahl der Elementtypen im Gegensatz zum vorliegenden Werkzeug nicht beschränkt,
deutet jedoch darauf hin, dass in manchen Anwendungsfällen tatsächlich mehr als die
drei im Werkzeug semantisch belegbaren Elementtypen zum Einsatz kommen sollten.
Hypothese 10 („Beliebiger Modellumfang“) konnte im Rahmen der Untersuchung nicht
bestätigt werden. Die beschränkte Größe der Modellierungsoberfläche wird einschrän-
kend auf den Modellumfang, die Möglichkeit der Einbettung von Teilmodellen stellt
dabei keinen adäquaten Ersatz dar. In einer vergleichenden Studie mit einem die Ar-
beitsfläche nicht beschränkenden Werkzeug wurden bei identischer Aufgabenstellung
im Durchschnitt Modelle mit doppelten Umfang als mit dem hier vorgestellten Werk-
zeug erstellt. Auch die Rückmeldungen der Teilnehmenden deuten darauf hin, dass die
Beschränkung der Modellierungsoberfläche in vielen Fällen als einschränkender Faktor
wahrgenommen wird.
Hypothese 11 („Reflexion des Modellierungsverlaufs“) untersucht, ob die Verfügbar-
keit der Modellierungshistorie einen positiven Einfluss auf die Nachvollziehbarkeit des
Modellinhaltes hat. Diese Hypothese konnte im Rahmen der Untersuchung bestätigt
werden. Einschränkend ist jedoch anzumerken, dass die Korrektheit der Interpretation
vor allem in Fragestellungen, die zu ablauforientierten Modellen führen, in vielen Fällen
eher gering ist. Es ist daher fraglich, ob eine Interpretation ausschließlich auf Basis der
gespeicherten Repräsentationen des Modells ausreichend ist bzw. zu qualitativ zufrieden
stellenden Ergebnissen führt.
428
13.4. Zusammenfassung
Hypothese 12 („Stärkere Kooperation“) untersucht, ob die Verwendung des Werkzeugs
zu stärkerer Kooperation führt als die Verwendung eines bildschirmbasierten Werkzeugs.
Diese Hypothese konnte im Rahmen der Untersuchung bestätigt werden. Die Verwen-
dung des Werkzeugs führt im Vergleich zur Anwendung eines bildschirm-basierten Werk-
zeugs zu einem signifikant höheren Anteil an Diskussion während der Modellbildung und
zu ausgeglichenerer physischer Beteiligung am Modellierungsvorgang zwischen den Teil-
nehmern. Die Daten aus der Befragung der Teilnehmer stärken die Hypothese zwar nicht
signifikant, zeigen aber eine leichte Tendenz zu deren Bestätigung.
Die letzte in diesem Kapitel untersuchte Hypothese (Hypothese 13, „Verbinder nicht
notwendig“) betraf die explorativ gebildete Vermutung, dass zur Repräsentation von
Zusammenhängen in Modellen die explizite Darstellung von Verbindern nicht notwendig
sind sondern die ausschließliche räumliche Konfiguration der Modellierungselemente zu-
einander ausreicht, um die Zusammenhänge erfassbar zu machen. Während dies im über-
wiegenden Teil der Anwendungsfälle möglich war, konnten Modelle identifiziert werden,
in denen die Verbinder Information codierten, die rein durch die räumliche Anordnung
der Modellelemente nicht ableitbar gewesen waren (in etwa 25% der Fälle). Hypothese
13 konnte im Rahmen der Untersuchung damit nicht bestätigt werden.
Insgesamt zeigt sich damit, dass das Werkzeug nur eingeschränkt zur Abbildung dia-
grammatische Modelle geeignet ist. Im Sinne der Zielsetzung dieser Arbeit – der Unter-
stützung von „Articulation Work“ – ist dies jedoch nur von eingeschränkter Wichtigkeit.
Vielmehr steht die Unterstützung der Kommunikation zwischen den beteiligten Indivi-
duen und der Abgleich derer mentaler Modelle im Vordergrund. Die Ergebnisse deuten
darauf hin, dass das Werkzeug diesen Ansprüchen gerecht wird. Im nächsten Kapitel
wird nun untersucht, inwieweit der Abgleich tatsächlich stattfindet (also „Articulation
Work“ erfolgreich durchgeführt werden konnte) und welche Auswirkungen dies auf die
Arbeitsrealität hat.
13.4.1. Beitrag zur globalen Zielsetzung
Dieses Kapitel stellt die Untersuchung der Eignung des vorgeschlagenen Instruments zur
Unterstützung von „Articulation Work“ dar und trägt so hinsichtlich der in Kapitel 1
argumentieren und in Kapitel 4 näher ausgeführten zu untersuchenden Aspekte zur Be-
antwortung der Fragestellung 6 („Ermöglicht das Instrument die effektive Durchführung
von expliziter Articulation Work?“) bei. Die Ergebnisse zeigen die erwartete Wirkung
des Instruments auf die Kooperation zwischen den beteiligten Individuen und bestäti-
gen so eine weitere Voraussetzung für die effektive Unterstützung expliziter „Articulation
Work“ durch das hier vorgestellte Instrument.
429
13.4. Zusammenfassung
13.4.2. Weitere Verwendung der Ergebnisse
Die Ergebnisse dieses Kapitels werden in ihrer Gesamtheit erst in den Schlussbetrach-
tungen (Kapitel 15) wieder aufgegriffen. Einzelne Hypothesen, vor allem jene, die sich
mit der kooperativen Verwendbarkeit des Werkzeugs beschäftigen, werden aber im fol-
genden Kapitel nochmals aufgegriffen und dienen dort als Grundlage der Evaluierung
der Wirkung der durchgeführten „Articulation Work“.
430
14. Evaluierung der durchgeführten
Articulation Work
Die Evaluierung der durchgeführten „Articulation Work“ bildet den letzten Teil der
empirischen Untersuchung und prüft letztendlich die Eignung des Werkzeugs für den
intendierten Verwendungszweck im Sinne der Zielsetzung. Abbildung 14.1 stellt dieses
Kapitel und dessen Aufbau im Kontext der anderen inhaltlich vor- und nachgelagerten
Kapitel dar.
Abbildung 14.1.: Kapitel „Evaluierung der durchgeführten Articulation Work“ im Ge-
samtzusammenhang
Die in diesem Kapitel formulierten Hypothese basieren unmittelbar auf der Zielsetzung
dieser Arbeit und den in Kapitel 2 identifizierten Merkmalen erfolgreich durchgeführter
„Articulation Work“. Es wird nicht mehr auf die Verwendung der Werkzeugs selbst (siehe
Kapitel 12) und nicht mehr auf die Rolle von externalisierten Modellen im Kontext dieser
Arbeit (siehe Kapitel 13) eingegangen.
431
14.1. Hypothesen
14.1. Hypothesen
In diesem Abschnitt werden die Hypothesen angeführt und begründet, die in diesem
Teil der empirischen Untersuchung geprüft werden. Die im Folgenden beschriebenen
Hypothesen gehen aber auf die Wirkung von „Articulation Work“ auf die reale Welt ein.
Nicht Gegenstand der Untersuchung ist die Verwendung diagrammatischer Modelle zum
Zwecke der Durchführung von „Articulation Work“ (siehe Kapitel 13) und die Wirkung
des Werkzeugs bei der Durchführung (siehe Kapitel 12).
14.1.1. Konzeptuell begründete Hypothesen
Die folgenden Hypothesen sind unmittelbar aus der globalen Zielsetzung dieser Arbeit
abgeleitet. Die Wirkung von „Articulation Work“ zeigt sich in der organisationalen Rea-
lität an der Durchführung der „Production Work“ Fujimura (1987). Um die Wirkung der
mit dem Werkzeug durchgeführten „Articulation Work“ zeigen zu können, muss deshalb
neben dieser auch die „Production Work“ betrachtet werden. Die Überprüfung erfolgt
dabei in zwei Schritten.
Im ersten Schritt wird die Durchführung der „Articulation Work“ selbst betrachtet.
Im Rahmen der Verwendung der Externalisierung von mentalen Modellen zum Zwecke
der Durchführung von „Articulation Work“ ist es – wie in Kapitel 4 ausgeführt und
in Anforderung 7 abgebildet – notwendig, eine kooperative Nutzung des unterstützen-
den Werkzeugs zu ermöglichen. Ein wesentlicher Schritt zur erfolgreichen Durchführung
von „Articulation Work“ ist neben der eigentlichen Externalisierung (die in den ersten
beiden Hypothesen des vorhergehenden Kapitels 13 abgebildet wurde) die Abstimmung
der indviduellen mentalen Modelle der Beteiligten. „Abstimmung“ bedeutet hier einen
Abgleich der indviduellen Verständnisse jener Arbeitsaspekte, die im Sinne von Kapitel
2 „problematisch“ sind bzw. enge Kooperation der Beteiligten in der „Production Work“
bedingen. Die Prüfung dieser Hypothese ermöglicht die Beurteilung der Erfüllung der
Anforderung 2 (siehe Seite 116).
Hypothese 14 Das Werkzeug unterstützt den Prozess der Abstimmung der individuel-
len Modelle zwischen Personen.
Der zweite Schritt der Untersuchung in diesem Teil der Evaluierung betrachtet letzt-
endlich die durchgeführte Arbeit selbst. Das globale Ziel des hier vorgestellten Ansatzes
ist die Unterstützung von „Articulation Work“. Ob diese tatsächlich erfolgreich durch-
geführt wurde, zeigt sich an der Wirkung auf die zugehörige kooperativer Arbeit (die
„Production Work“). Es ist also zu beurteilen, ob die Anwendung des Werkzeuges tat-
sächlich auf die jeweils betrachteten Arbeitsabläufe wirkt und welcher Natur diese Aus-
wirkungen sind. Die Prüfung dieser Hypothese trägt zur Beurteilung der Erfüllung der
globalen Zielsetzung (siehe Seite 5) bei.
432
14.2. Untersuchungsdesign und Durchführung
Hypothese 15 Die Anwendung des Werkzeugs hat Auswirkungen auf die Ergebnisse
kooperativer Arbeit.
Hinsichtlich der in Kapitel 5 formulierten Anforderungen können die hier formulierten
Hypothesen zusammenfassend wie in Tabelle 14.1 dargestellt eingeordnet werden. Die
Untersuchung dieser Hypothesen stellt den finalen Schritt in der Prüfung der effektiven
Unterstützung der Durchführung von „Articulation Work“ dar. Hier wird die Wirkung
der Anwendung des Instruments sowohl auf die beteiligten Individuen als auch auf die
betroffenen Arbeitsabläufe untersucht und so die Effektivität der Unterstützung an sich
anhand ihrer Wirkung geprüft.
Tabelle 14.1.: Hypothesen zur Wirkung des Instruments auf die Articulation Work und
deren Bezug zu den Anforderungen an das Werkzeug
Hypothese Anforderung
14 2
15 globale Zielsetzung
14.2. Untersuchungsdesign und Durchführung
In diesem Abschnitt wird auf Basis der oben formulierten Hypothesen das Untersu-
chungsdesign abgeleitet und die Durchführung der Untersuchung beschrieben. Der erste
Teil des Abschnitts beschreibt die Operationalisierung der Hypothesen und damit die
Festlegung, wie diese konkret geprüft werden können. Im zweiten Teil des Abschnitts
wird die Durchführung der Prüfung beschrieben. Hier erfolgt neben der Zuordnung der
einzelnen Evaluierungsblöcke (siehe Abschnitt 11.2) auch die Darstellung rein beschrei-
bender Modell-Parameter, die nicht unmittelbar in die Prüfung der Hypothesen einge-
hen.
14.2.1. Operationalisierung
In diesem Abschnitt wird für jede Hypothese identifiziert, in welcher Form sie geprüft
werden kann. Dies umfasst die Festlegung der Messpunkte sowie der jeweiligen Mess-
und Auswertungsmethode (letztere bezugnehmend auf den in Abschnitt 11.3 beschrie-
benen Verfahren). Zudem werden jene Evaluierungsblöcke festgelegt, die für die jeweilige
Untersuchung herangezogen wurden.
Für jede Hypothese wird also spezifiziert, anhand welcher Aspekte diese geprüft wer-
den kann (= abhängige Variablen). Zudem wird festgelegt, welche Ausgangssituation
433
14.2. Untersuchungsdesign und Durchführung
bei der Anwendung gewählt werden muss, um die Prüfung durchführen zu können (=
unabhängige Variable) und welche Faktoren die Beurteilung ggf. ungewollt beeinflussen
können (= Störvariablen).
Abstimmung individueller Modelle
Gegenstand dieses Abschnitts ist die Prüfung der Hypothese 14. Diese bezieht sich auf
die geforderte Eigenschaft des Werkzeugs, den Prozess der Abstimmung der individuellen
Modelle zwischen den beteiligten Personen zu unterstützen.
Voraussetzung zur Prüfung dieser Hypothese ist, dass die Aufgabenstellung einem der
beiden kooperativen Anwendungsszenarien zuzuordnen ist (siehe Abschnitt 4.3.3 bzw.
4.3.4), in denen alle Teilnehmenden ihre individuellen mentalen Modelle einbringen. Die
Zielsetzung muss so formuliert sein, dass eine gemeinsame Sicht auf den behandelten
Sachverhalt angestrebt wird. Weitere Voraussetzungen etwa hinsichtlich der Auswahl
der beteiligten Individuen bestehen nicht.
Zur Prüfung, ob eine Abstimmung der individuellen Modelle der beteiligten Perso-
nen erreicht wurde, kann auf qualitative Beurteilung durch die Teilnehmenden zurück-
gegriffen werden. Zur Beurteilung bieten sich hier neben der direkten Frage nach der
subjektiv wahrgenommene Abstimmung des Verständnisses auch Teilaspekte des PMS-
Frameworks (Sedera et al., 2002) an, das unter anderem die Wirkung der Modellbildung
auf die beteiligten Personen und die Arbeitsrealität abbildet (siehe (Wahlmüller, 2010)
zur Eignung des PMS-Frameworks im Kontext dieser Arbeit).
Zusätzlich könnte zur Prüfung der Hypothese eine Diagnose der mentalen Modelle
der Beteiligten etwa im Sinne von (Ifenthaler, 2006) durchgeführt werden. Hier müssten
dann jeweils die externalisierten mentalen Modelle aller Beteiligten jeweils vor und nach
dem Abstimmungsprozess gegenübergestellt werden. Die Anwendung dieses Vorgehens
übersteigt jedoch den methodischen Fokus dieser Arbeit und wurde in der vorliegenden
Untersuchung aus Ressourcengründen nicht durchgeführt.
Auswirkungen auf die Ergebnisse kooperativer Arbeit
Gegenstand dieses Abschnitts ist die Prüfung der Hypothese 15. Diese bezieht sich letzt-
endlich auf die Rückwirkung der mit Hilfe des Werkzeugs durchgeführten Aktivitäten
auf die Realität.
Voraussetzung zur Prüfung dieser Hypothese ist, dass die Aufgabenstellung einen Sach-
verhalt zum Gegenstand hat, der eine unmittelbare Entsprechung in der realen (Arbeits-
)Welt der Teilnehmenden hat. Weitere Voraussetzungen etwa hinsichtlich der Auswahl
der beteiligten Individuen bestehen nicht.
Zur Prüfung dieser Hypothese kann wiederum auf eine qualitative Beurteilung der ein-
getretenen Veränderungen durch die beteiligten Personen zurückgegriffen werden. Auch
434
14.2. Untersuchungsdesign und Durchführung
hier liefert das PMS-Framework (Sedera et al., 2002) wieder Ansatzpunkte zur Erhebung.
Wichtig ist in diesem Zusammenhang die Einhaltung eines angemessenen zeitlichen Ab-
standes zwischen Modellbildung und Befragung, so dass etwaige Veränderungen in Kraft
gesetzt bzw. beobachtet werden können.
Neben der Befragung der teilnehmenden Individuen können auch die Arbeitsabläu-
fe, die Gegenstand der „Articulation Work“ waren, selbst beobachtet werden. Bei be-
reits etablierten Arbeitsabläufen bietet sich eine Gegenüberstellung der Durchführung
der Arbeit vor und nach der Modellbildung an. Bei neu einzurichtenden Arbeitsabläu-
fen steht die Möglichkeit der Gegenüberstellung nicht zur Verfügung. Dementsprechend
kann lediglich beurteilt werden, ob die Aushandlung eines gemeinsamen Arbeitsablaufs
möglich war. Vergleichend können im zweiten Fall dazu identische Arbeitsabläufe ohne
dezidierten Abstimmungsschritt herangezogen werden, wobei als Maß für die Güte der
Abstimmung die Anzahl der aufgetretenen Probleme in der Zusammenarbeit während
der Durchführung der „Articulation Work“ herangezogen werden kann.
14.2.2. Durchführung
Die Durchführung der Untersuchungen zu diesem Teil der Evaluierung wurde in den
Evaluierungsblöcken 2 und 4 durchgeführt. In Block 2 waren die Teilnehmenden auf-
gefordert, ein gemeinsames Vorgehen zur Erstellung einer Seminararbeit auszuhandeln
und in einem zweiten, während der laufenden Zusammenarbeit durchgeführten Schritt
zu reflektieren und ggf. anzupassen. Diese Schritte waren in den Verlauf der Erstel-
lung der Seminararbeit eingebettet, begleiteten also die „Production Work“, an der der
Erfolg der „Articulation Work“ zu messen war. Zur Beurteilung des Erfolgs wurden
die Teilnehmenden aufgefordert, den Verlauf der Erstellung der Seminararbeit in einem
Prozess-Tagebuch zu dokumentieren und dabei besonders auf die Zusammenarbeit mit
dem jeweiligen Partner einzugehen. Die Ergebnisse flossen in die Prüfung der Hypothese
15 ein.
In Block 4 wurden die Teilnehmer unmittelbar nach der Modellbildung und in ei-
nem Abstand von 8 Wochen zu den erwarteten bzw. tatsächlich eingetretenen Ände-
rungen der Arbeitspraxis befragt. Die Befragung wurde mittels einem auf Basis des
PMS-Frameworks erstellten Fragebogen (siehe Anhang B) durchgeführt. Die Ergebnisse
flossen in die Prüfung der Hypothesen 14 und 15 ein.
In diesem Teil der Evaluierung wurden keine deskriptiven Parameter erhoben, weshalb
die in den Kapiteln 12 und 13 an dieser Stelle vorgenommene Beschreibung derselben
hier entfällt.
435
14.3. Ergebnisse
Stichprobe
Für die Untersuchung der Hypothesen in diesem Kapitel wurden die Evaluierungsblöcke
2 und 4 herangezogen. In diesen war die Aufgabenstellung im Gegensatz zu den übri-
gen Evaluierungsblöcken stärker auf eine unmittelbare Abbildung konkreten Abläufen
in der „Production Work“ ausgerichtet, was eine Prüfung der Hypothesen erleichterte.
Für die Prüfung der Hypothese 14 wären grundsätzlich auch die Evaluierungsblöcke 3
und 5 geeignet gewesen, die entsprechenden Untersuchungen konnten jedoch aus Res-
sourcengründen nicht durchgeführt werden. Die Stichprobe setzt sich wie in Tabelle 14.2
beschrieben zusammen.
Tabelle 14.2.: Stichproben der Evaluierung zur Articulation Work
Evaluierungsblock nAnwendungen nTeilnehmende
2a Aushandlung 1 (1. Durchgang) 9 19
2b Aushandlung 1 (2. Durchgang) 9 18
4 Aushandlung 2 10 13
Gesamt 28 50
14.3. Ergebnisse
In diesem Abschnitt werden die Ergebnisse der Untersuchung gegliedert nach den oben
formulierten Hypothesen dargestellt. Zu jeder Hypothese wird die Auswertung der em-
pirischen Daten dargestellt, die Bedeutung der empirischen Belege für die Prüfung der
jeweiligen Hypothese diskutiert und letztendlich das Ergebnis zusammenfassend darge-
stellt.
14.3.1. Abstimmung individueller Modelle
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 14 („Das Werkzeug
unterstützt den Prozess der Abstimmung der individuellen Modelle zwischen Personen.“).
Als Grundlage dieser Untersuchung dienen die Ergebnisse der Evaluierungsblöcke 2 und
4.
Auswertung
In Evaluierungsblock 4 wurden die Teilnehmer hinsichtlich der eigenen Einschätzung
eines individuellen Erkenntnisgewinns bzw. der Entwicklung eines gemeinsamen Ver-
ständnisses befragt (Abschnitt „Auswirkungen der Modellierung“ im ersten und zweiten
436
14.3. Ergebnisse
Fragebogen von Block 4 – siehe Anhang B.3.2). Die für die Prüfung der hier betrachteten
Hypothese sind folgende geschlossene Items relevant:
1. Die Modellierungstätigkeit hat mein Verständnis des Modellierungsinhalts erhöht.
2. Die Modellierung hat Verbesserungen für bisherige Tätigkeiten aufgezeigt.
3. Die Modellierung hat einen Beitrag zur Zielerreichung geleistet.
Alle Fragen wurden sowohl in der unmittelbar nach der Modellbildung durchgeführten
Befragung als auch in der in einem Abstand von 3 Monaten durchgeführten Befragung
gestellt.
Insgesamt wurden in der unmittelbar nach der Modellbildung durchgeführten Be-
fragung n = 14 Teilnehmer befragt (1 Teilnehmer beantwortete die Fragestellungen
nicht). Die Ergebnisse sind in Tabelle 14.3 und Abbildung 14.2 zusammengefasst dar-
gestellt. Neben dem Mittelwert und der Standardabweichung wurde für jedes Item
auch geprüft, ob die Einschätzung als signifikant positiv zu bezeichnen ist. Dazu wur-
de ein einseitiger Signifikanz-Test für die Stichprobe gegenüber dem Skalenmittelwert
4 durchgeführt. Für die Items 1 und 2 konnte der t-Test angewandt werden, da die
Stichprobe nicht signifikant von einer Normalverteilung abweicht (Shapiro-Wilk-Test:
W1 = 0.894, p1 = 0.1103, W2 = 0.8884, p2 = 0.0927). Für Item 3 muss der Wilcoxon-Test
angewandt werden, da die Stichprobe hier nicht normalverteilt ist (Shapiro-Wilk-Test:
W3 = 0.6743, p3 < 0.005).
Tabelle 14.3.: Befragung über die Verständnisbildung bei der Modellierung – Itemaus-
wertung Teil 1
Item M SD tM<4 VM<4 pM<4
1 2.615 1.446 −3.45 – < 0.005
2 2.308 1.032 −5.92 – < 0.005
3 2.417 0.669 – 0 < 0.005
Bei der drei Monate nach der Modellbildung durchgeführten Befragung beantworteten
n = 11 Teilnehmer die Fragestellungen. Die Ergebnisse sind in Tabelle 14.4 und Ab-
bildung 14.3 zusammengefasst dargestellt. Für die Signifikanzprüfung der Items konnte
der t-Test angewandt werden, da die Stichprobe in allen drei Fällen nicht signifikant
von einer Normalverteilung abweicht (Shapiro-Wilk-Test: W1 = 0.854, p1 = 0.0486,
W2 = 0.924, p2 = 0.353, W3 = 0.893, p3 = 0.150).
Vergleicht man die Antworten in den beiden Fragebögen, so ergibt sich für keines
der Items ein signifikanter Unterschied in der Bewertung (zweiseitiger Signifikanztest
437
14.3. Ergebnisse
Abbildung 14.2.: Verteilung der Benutzereinschätzungen zur Verständnisbildung durch
das Werkzeug – Teil 1
Tabelle 14.4.: Befragung über die Verständnisbildung bei der Modellierung – Itemaus-
wertung Teil 2
Item M SD tM<4 pM<4
1 2.818 1.168 −3.36 < 0.005
2 2.909 1.221 −2.96 < 0.005
3 2.455 0.820 −6.25 < 0.005
Abbildung 14.3.: Verteilung der Benutzereinschätzungen zur Verständnisbildung durch
das Werkzeug – Teil 2
438
14.3. Ergebnisse
für ungepaarte Stichproben: t1 = −0.380, p1 = 0.708, t2 = −1.29, p2 = 0.212, W3 =
62.5, p3 = 0.8361).
In den Evaluierungsblöcken 4 und 5 wurden die Teilnehmer (n = 37) außerdem in
offenen Fragen nach der Zusammenarbeit im Team befragt (Fragestellung: „Wie würden
Sie Ihre Beziehung im Team beschreiben?“ sowie „Sind Sie zufrieden mit ihrem Beitrag
zum Modellierungsprozess? Geben Sie bitte auch eine kurze Begründung an!“) – siehe
dazu auch die Auswertungen in Abschnitt 13.3.4). Während diese nicht unmittelbar auf
die hier betrachtete Hypothese eingehen, gaben doch 12 Teilnehmer explizit an, dass ein
Konsens über die abzubildenden Inhalte gefunden werden konnte. 7 dieser 12 Teilneh-
mer führten außerdem an, dass während der Modellierung Meinungsverschiedenheiten
geherrscht hätten, die aufgelöst werden konnten.
In der Auswertung der Videoaufnahmen der Evaluierungsblöcke 2 bis 5 (in denen
kooperative Modellbildungen durchgeführt wurden, n = 69) waren insgesamt 53 Situa-
tionen zu identifizieren, in denen die Teilnehmer bei der Abbildung eines Sachverhaltes
offensichtlich unterschiedlicher Meinung waren. Vier unterschiedliche Reaktionen waren
als Konsequenz zu beobachten:
1. Eine unterschiedliche Meinung wurde übergangen, lediglich die andere Meinung
fand sich im Modell wieder. (10x)
2. Die unterschiedlichen Meinungen wurden nicht explizit aufgelöst, fanden sich je-
doch beide im Modell wieder. (5x)
3. Der Sachverhalt, in dem unterschiedliche Meinungen herrschten, wurde im Modell
nicht abgebildet. (17x)
4. Die Teilnehmer fanden zu einer gemeinsamen Sichtweise und bildeten diese im
Modell ab. (21x)
Diskussion
In den dezidierten Fragestellungen etwaigen Auswirkungen der Werkzeugverwendung
auf das Verständnis der Teilnehmer in Evaluierungsblock 4 zeigte sich durchgängig ei-
ne signifikant positive Einschätzung der Veränderungen. Die Frage nach der „Erhöhung
des indiviuduellen Verständnisses des modellierten Sachverhalts“ ist dabei bei der Beur-
teilung der hier betrachteten Hypothese als am relevantesten einzuschätzen. Auch das
„Aufzeigen von Verbesserungspotential in der Modellierung“ impliziert die Zusammen-
führung der individuell wahrgenommenen Aspekte des modellierten Sachverhalts, eine
positive Einschätzung dieser Fragestellung stützt also ebenfalls die Hypothese. Auch
die Frage, ob die Modellbildung einen „Beitrag zur Zielerreichung“ geleistet hätte, ist
1Bei Item 3 musste aufgrund der Nicht-Normalverteilung der Stichprobe aus dem ersten Fragebogen
der Wilcoxon-Test angewandt werden, für die anderen beiden Items konnte ein t-Test durchgeführt
werden
439
14.3. Ergebnisse
unter der Annahme relevant, dass die Zielsetzung explizit die Forderung nach dem Sicht-
barmachen der eignen Sichtweise sowie der Entwicklung einer gemeinsamen Sichtweise
enthielt (wie in Block 4 gegeben). In der mittelfristigen Betrachtung drei Monate nach
der Modellbildung zeigt sich keine signifikante Änderung der Einschätzung und bleibt
für alle drei Fragen signifikant positiv. Die Ergebnisse der betrachteten geschlossenen
Fragen stützen also die oben formulierte Hypothese.
In den relevanten offenen Fragen wurde von den Teilnehmern der Evaluierungsblö-
cke 4 und 5 in etwa einem Drittel der Antworten auf die Konsensbildung als einen
wichtigen Aspekt der Werkzeugverwendung verwiesen. Dies ist relevant für die Unter-
stützung der hier formulierten Hypothese, da die Fragen vollständig offen formuliert
waren und keine andere Wirkung des Werkzeugs in diesem Ausmaß erwähnt wurde.
Einschränkend ist zu bemerken, dass bei den Werkzeuganwendungen durchgängig nicht
hoch kontroversielle Themen behandelt wurden. Etwa ein Fünftel aller Teilnehmer (bzw.
die Hälfte der Teilnehmer, die konsensbildende Wirkung genannt hatten) führte an, dass
Meinungsverschiedenheiten in unterschiedlichem Ausmaß bestanden hätten, die ausge-
räumt werden konnten. Im Falle der Modellbildung mit dem Werkzeug CMapTools in
Evaluierungsblock 5 wurde bei insgesamt 24 befragten Teilnehmern hingegen zweimal
explizit angeführt, dass ein Teilnehmer inhaltlich dominiert hätte und der andere sich
nicht einbringen konnte (siehe Abschnitt 13.3.4), dessen Sichtweise also auch nicht in
eine gemeinsame Sichtweise hätte einfließen können.
In den Auswertungen der Videoaufnahmen konnten ebenfalls Situationen identifiziert
werden, in denen offenbar Meinungsverschiedenheiten in unterschiedlichem Ausmaß hin-
sichtlich der Abbildung herrschten. In etwa 40% der identifizierten Fälle fanden die
Teilnehmer zu einer gemeinsamen Sichtweise, die im Modell abgebildet wurde (Fall 4).
In etwa einem Drittel der Fälle wurde die Meinungsverschiedenheit ignoriert und im
Modell nicht abgebildet (Fall 3). In einem Fünftel der Fälle wurden konfliktionierende
Sichtweisen übergangen und nur eine Variante fand ohne weitere Diskussion den Weg in
das Modell (Fall 1). Ein weiteres Zehntel der Meinungsverschiedenheiten wurde eben-
falls nicht explizit angesprochen, die Sichtweisen wurden jedoch gleichberechtigt in das
Modell aufgenommen (Fall 2). Fall 4 und Fall 2 stützen die Hypothese, während Fall 3
und Fall 1 eher für deren Ablehnung sprechen. Insgesamt zeigen also etwa 50% der Fälle
Ausprägungen, die die Hypothese unterstützen.
Insgesamt überwiegen also jene Untersuchungsergebnisse, die die Annahme der Hypo-
these unterstützen. Sie kann also auf Basis der durchgeführten Untersuchung bestätigt
werden, bedarf aber weiterführender Untersuchungen hinsichtlich des auffällig häufig
auftretenden Benutzerverhaltens des Aussparens unterschiedlicher Sichtweisen in der
Diskussion.
440
14.3. Ergebnisse
Ergebnis
Die Hypothese 14 kann auf Basis der Untersuchung bestätigt werden. So-
wohl die quantitativen als auch die qualitativen Daten der Benutzerbefragung stützen
die Hypothese und sprechen für deren Annahme. In der Auswertung der durchgeführten
Modellbildungen zeigte sich keine signifikante Häufung von die Hypothese stützendem
Umgang mit unterschiedlichen Sichtweisen. Auffällig häufig wurden die Aspekte, in de-
nen unterschiedliche Sichtweisen herrschten, nicht weiter angesprochen und im Modell
ausgespart. Dieses Verhalten bedarf weiterführenden Untersuchungen bzw. der Entwick-
lung von methodischen Ansätzen, die die Auflösung von derartigen Situationen erleich-
tern bzw. bestärken.
14.3.2. Auswirkungen auf die Ergebnisse kooperativer Arbeit
Gegenstand der hier beschriebenen Untersuchung ist Hypothese 15 („Die Anwendung des
Werkzeugs hat Auswirkungen auf die Ergebnisse kooperativer Arbeit.“). Als Grundlage
dieser Untersuchung dienen die Ergebnisse der Evaluierungsblöcke 2 und 4.
Auswertung
In Evaluierungsblock 4 wurden die Teilnehmer hinsichtlich der eigenen Einschätzung der
Auswirkungen der Modellbildung auf die reale Arbeitswelt („Production Work“) drei
Monate nach der Durchführung der Modellbildung befragt (Abschnitt „Auswirkungen
auf die Prozesse“ im zweiten Fragebogen von Block 4 sowie Abschnitt – siehe Anhang
B.3.2). Die für die Prüfung der hier betrachteten Hypothese sind folgende geschlossene
Items relevant:
1. Umsetzung
a) Das Modellierungsergebnis oder Teile davon wurden bereits umgesetzt.
b) Das Modellierungsergebnis oder Teile davon werden in Kürze umgesetzt.
c) Es ist geplant, die Modellierungsergebnisse oder Teile davon umzusetzen.
2. Der Alltag hat sich im Umfeld des modellierten Themas geändert.
3. Unmittelbar nach der Modellierung war klar, dass die Ergebnisse umgesetzt wer-
den.
Insgesamt wurden in der drei Monate nach der Modellbildung durchgeführten Befra-
gung 11 Teilnehmer befragt (5 Teilnehmer beantworteten alle Fragestellungen nicht, 5
Teilnehmer beantworteten alle Fragestellungen, 1 Teilnehmer beantwortete nur die drei
Items der Fragestellung 1). Die Ergebnisse sind in Tabelle 14.5 und Abbildung 14.4 zu-
sammengefasst dargestellt. Für die drei unter Punkte 1 gruppierten Items wird einerseits
eine Einzelauswertung vorgenommen, andererseits werden diese Items so gruppiert, dass
441
14.3. Ergebnisse
jeweils der geringste Wert (also die „beste“ Einschätzung) verwendet wird. So ist es
möglich, ein Maß für die generelle Wahrnehmung der Umsetzung des Modellierungser-
gebnisses zu bestimmen.
Neben dem Mittelwert und der Standardabweichung wurde für jedes Item auch ge-
prüft, ob die Einschätzung als signifikant unterschiedlich von Skalenmittelwert 4 zu be-
zeichnen ist. Dazu wurde ein zweiseitiger Signifikanz-Test für die Stichprobe gegenüber
dem Skalenmittelwert 4 durchgeführt. Aufgrund der geringen Stichprobengröße wurde
der Wilcoxon-Test zur Signifkanzprüfung verwendet.
Tabelle 14.5.: Befragung über die Wirkung der Modellbildung auf die Arbeitsprozesse –
Itemauswertung
Item n M SD VM=4 pM=4
1a 6 3.83 1.941 2.5 1
1b 6 3.33 2.066 4.5 0.496
1c 6 3.50 2.074 3.5 0.713
1ges 6 3.33 2.066 4.5 0.496
2 5 4.40 1.673 4 0.773
3 5 3.40 0.548 0 0.149
Abbildung 14.4.: Verteilung der Benutzereinschätzungen zur Wirkung der Modellbil-
dung auf die Arbeitsprozesse
In keinem der Items konnte eine signifikante Abweichung vom Skalenmittelwert 4 ge-
messen werden, was einer neutralen Antwort entspricht (Skala: 1 . . . „stimme zu“, 7
. . . „stimme nicht zu“). 5 bzw. 6 Teilnehmer gaben explizit keine Antwort (Antwortmög-
lichkeit „keine Antwort“).
442
14.3. Ergebnisse
In den offenen Fragen des Fragebogenteils nutzten 4 Teilnehmer die Gelegenheit zu
weiteren Kommentaren. Aufgrund des geringen Rücklaufs wird auf eine Codierung der
Antworten verzichtet, es werden für jede offene Frage die Antworten im Volltext ange-
führt, um eine Zuordnung von Mehrfachantworten zu ermöglichen (in Klammern sind
die Quellfragebögen der Antworten angeführt):
• „Welche Ergebnisse hatte die Modellierung?“
1. Erarbeitung / Verbesserung von Prozessen & Dokumentationen (FB2)
2. klare Definition des systemischen Soll‐Zustandes (FB2)
3. generell mehr Klarheit bei den Beteiligten zum Thema (FB2)
4. Darstellung der kritischen Punkte im Prozess (FB4)
5. wir kamen leider nicht so weit, ein Ergebnis festzuhalten bzw. ein Ziel zu
formulieren (FB5)
6. Erhöhtes Verständnis der hohen Komplexität des Systems. (FB11)
• „Welche Auswirkungen konnten Sie persönlich feststellen?“
1. Diskussion / Neue Wege (FB4)
2. Es war nett, ein solches Tool kennen zu lernen, es hatte aber keine Auswir-
kungen für mich persönlich (FB5)
3. Mehr Verständnis bei Umsetzungen, die Komplexität wurde durch das Tool
transparenter (FB11)
• „Welche Auswirkungen erwarten Sie?“
1. zu den bisherigen Umsetzungsmaßnahmen die weitere operative Umsetzung
der gewonnenen Erkenntnisse (FB2)
2. Verbesserung im Prozess: kürzere Wege, Nachvollziehbarkeit (FB4)
In Evaluierungsblock 2 wurde versucht, die Wirkung des Werkzeugs unmittelbar an
der „Production Work“ zu messen. Dazu wurde zum Ersten der Ablauf der „Produc-
tion Work“ von den Teilnehmern dokumentiert. Zum Zweiten wurden die Ergebnisse der
„Production Work“, im Fall dieses Evaluierungsblocks, also die erstellten Seminararbei-
ten, ausgewertet. Dabei wurde neben der inhaltlichen Beurteilung vor allem auch auf
die Konsistenz der erstellten Arbeit geachtet. Ist diese auch bei der Beteiligung meh-
rerer Autoren gegeben, so ist dies ein Indikator für die erfolgreiche Durchführung von
„Articulation Work“. Die Arbeiten, die im Rahmen des Evaluierungsblocks 2 erstellt
wurden, wurden zudem den Arbeiten eines Seminars gegenüber gestellt, in dem eine
identische Aufgaben- und Themenstellung ohne Einsatz einer expliziten Unterstützung
von „Articulation Work“ bearbeitet wurde.
Insgesamt wurden in Evaluierungsblock 2 10 Arbeiten erstellt, an denen 20 Teilnehmer
beteiligt waren. In 8 Fällen arbeiteten jeweils 2 Teilnehmer zusammen, in je einem Fall
arbeiteten 3 Personen bzw. 1 Person an der Arbeit.
443
14.3. Ergebnisse
Zur Auswertung der Ergebnisse der „Production Work“ wird einerseits die Gesamtbe-
urteilung der Arbeit auf einer Notenskala von 1 („sehr gut“) bis 5 („nicht genügend“)
angegeben2. Andererseits wird explizit eine Einschätzung der Qualität der Konsistenz
ebenfalls auf einer Skala von 1 bis 5 angeführt. Beide Werte wurden durch den Lehrver-
anstaltungsleiter festgelegt, der gleichzeitig auch der Autor dieser Arbeit ist. In Tabelle
14.6 ist das Ergebnis der Beurteilung für die Durchführung in Evaluierungblock 2 (unter
Einsatz des hier vorgestellten Werkzeugs) dargestellt. In Tabelle 14.7 ist das Ergeb-
nis eines inhaltlich identischen Seminars dargestellt, in dem der Ablauf nur durch den
fehlenden Einsatz des Werkzeugs von dem in der ersten Tabelle dargestellten Seminar
abwich.
Tabelle 14.6.: Ergebnis der „Production Work“ in Evaluierungsblock 2
Arbeit Teilnehmer Noteges NoteKonsistenz
1 2 2 2
2 2 3 4
3 2 1 1
4 1 2 1
5 2 2 2
6 2 2 3
7 2 1 1
8 3 1 1
9 2 2 3
10 2 2 2
Insgesamt konnte hinsichtlich der Konsistenz der Arbeiten bei der Durchführung des
Seminars mit Unterstützung der durchgeführten „Articulation Work“ (M = 2.0, SD =
1.05) gegenüber jener ohne Unterstützung (M = 2.6, SD = 1.43) keine statistisch si-
gnifikante Verbesserung des Ergebnisses festgestellt werden (einseitiger Wilcoxon-Test
für ungepaarte Stichproben: W = 38, p = 0.1813). Auch das Gesamtergebnis ist bei
Unterstützung der „Articulation Work“ (M = 1.8, SD = 0.63) nicht signifikant besser
(einseitiger Wilcoxon-Test für ungepaarte Stichproben: W = 47.5, p = 0.435) als jenes
ohne Unterstützung (M = 1.9, SD = 0.87). In dem Seminar, das ohne Unterstützung
des Werkzeugs durchführt wurde, zerbrach eine Gruppe aufgrund von unüberbrückbaren
Meinungsverschiedenheiten. Dies war durchgängig auch in insgesamt 6 in vorhergehen-
den Semestern bzw. parallel durchgeführten Seminaren in jeweils 1 bis 2 von 10 bis 12
2In die Gesamtbeurteilung fließen die inhaltliche Qualität der Arbeit, deren Konsistenz („roter Fa-
den“) sowie die Aufbereitung der Inhalte (inkl. Formulierungen und Korrektheit der Quellen-
Referenzierung) ein.
3Der Wilcoxon-Test musste angewandt werden, da die Stichprobe der Durchführung ohne Werkzeug-
unterstützung nicht normalverteilt ist (Shaprio-Wilk-Test: W = 0.752, p < 0.005)
444
14.3. Ergebnisse
Tabelle 14.7.: Ergebnis der „Production Work“ ohne Unterstützung der „Articulation
Work“
Arbeit Teilnehmer Noteges NoteKonsistenz
1 2 1 1
2 2 2 3
3 2 2 3
4 2 1 1
5 2 2 4
6 2 3 4
7 1 1 1
8 1 3 4
9 2 3 4
10 2 1 1
Gruppen der Fall. In dem mit Unterstützung des hier vorgestellten Werkzeugs durchge-
führten Seminar wurde keine Gruppe aufgelöst, alle Gruppen bestanden bis zum Ende
des Seminars. In den 6 Seminaren ohne Werkzeugunterstützung hatten die Teilnehmer
Wahlfreiheit bei der Gruppenbildung und konnten in etablierten Gruppen zusammen-
arbeiten. In dem Seminar mit Werkzeugunterstützung wurden die Gruppen gelost.
In der Dokumention der „Production Work“ durch die Teilnehmer des Evaluierungs-
blocks 2 wird untersucht, welche Vorgehensweise bei der Zusammenarbeit bei der Erstel-
lung der Seminararbeit gewählt wurde. Diese wird den erstellten Modellen gegenüber-
gestellt. Dabei wird untersucht ob die tatsächliche Vorgehensweise dem bei der Durch-
führung der „Articulation Work“ vereinbarten Prozedere entspricht. Zusätzlich werden
etwaige Anmerkungen hinsichlich problematischer Kooperation und Referenzen auf die
Auswirkungen der „Articulation Work“ angeführt.
Arbeit 1 (Beurteilung der Konsistenz: 2) Die Teilnehmer teilten die inhaltliche Arbeit
unter sich auf und arbeiten die einzelnen Blöcke eigenständig aus. Die einzelnen Tei-
le wurden zu zwei Zeitpunkten (nach der Literaturrechereche und nach der Erstellung
der Draft Version) gemeinsam konsolidiert. An die Draft-Version schloss sich eine ko-
operative Bearbeitung des Gesamtdokuments an, in der die Gesamtdurchgängigkeit der
Arbeit sichergestellt wurde. Dieses Vorgehen stimmt mit dem in der Modellbildung ver-
einbarten Vorgehen überein. Hinsichtlich der Durchführung wurden keine Probleme oder
Auffälligkeiten angeführt. Resümierend merken beide Teilnehmer an, dass der Großteil
der inhaltlichen Arbeit individuell erfolgte und die Druchgängigkeit der Inhalte darunter
litt.
445
14.3. Ergebnisse
Arbeit 2 (Beurteilung der Konsistenz: 4) Die Teilnehmer treffen in der Dokumentation
keine explizite Aussage zur Arbeitsteilung, aus der Dokumentation des Arbeitsverlaufs
geht jedoch hervor, dass das Thema inhaltlich aufgeteilt und jeweils separat bearbeitet
wurde. Aus den erstellen Modellen ist grundsätzlich ein Vorgehen zu erkennen, das indi-
viduelle Teilarbeiten mit regelmäßigen Abgleichsaktivitäten spezifiziert. Eine Umsetzung
dieses Vorgehensmodells konnte in der Verlaufdokumentation jedoch nicht identifiziert
werden. Ein Teilnehmer beschreibt Uneinigkeiten in der Ablaufplanung, die noch aufge-
löst werden müssten. Der andere Teilnehmer führt retrospektiv an, dass die Arbeit von
zu hoher Arbeitslast in anderen Fächern des Studiums negativ beeinflusst war.
Arbeit 3 (Beurteilung der Konsistenz: 1) Die Teilnehmer dokumentieren ein ab dem
Beginn des Schreibprozessen eher separiertes Vorgehen bei der Erstellung der Seminar-
arbeit. Die Literaturrecherche wurde inhaltlich noch nicht abgrenzt, wurde aber von
beiden Teilnehmern individuell durchgeführt. In der Modellierung wurde die Aushand-
lung eines konkreten Vorgehens ausgespart, vielmehr berichtete ein Teilnehmer über das
Vorgehen bei einem ähnlichen Seminar im Vorjahr. Dieses Modell schien jedoch bei der
konkreten Durchführung nicht mehr berücksichtigt zu werden. Bei der Erstellung über-
nahm ein Teilnehmer die Führung in der Zusammenstellung der einzelnen Teile. Dieser
Teilnehmer dokumentiert auch eine positive Wahrnehmung der Zusammenarbeit, wäh-
rend der andere Teilnehmer von Kommunikationsproblemen und als ungerechtfertigt
wahrgenommenen Kürzungen seiner Beiträge in der Gesamtarbeit berichtet.
Arbeit 4 (Beurteilung der Konsistenz: 1) Diese Arbeit wurde individuell von nur ei-
nem Teilnehmer erstellt. In der Dokumentation nimmt der Ersteller keinen Bezug auf
das erstellte Modell, das dokumentierte Vorgehen ist jedoch kohärent mit dem bei der
Modellerstellung geplanten Vorgehen.
Arbeit 5 (Beurteilung der Konsistenz: 2) Die Teilnehmer kennen einander von früheren
Projekten und haben bereits zusammengearbeitet. Die Kooperation wird als problemlos
bezeichnet, den inhaltlich aufgeteilten eigenständigen Arbeitsphasen folgen regelmäßig
gemeinsame Konsolidierungsschritte, die Teilnehmer halten sich gegenseitig über den
aktuellen Stand der Arbeit am Laufenden. Die dokumentierte Zusammenarbeit lässt auf
eine stärkere Interaktion als ursprünglich in der Modellierung geplant schließen.
Arbeit 6 (Beurteilung der Konsistenz: 3) Die Teilnehmer teilten die Arbeit inhaltlich
in zwei Teile und bearbeiteten diese individuell. Die Integration wurde zweimal durch-
geführt (Draft Version, Finale Version), dies wurde jeweils abwechselnd von einem der
Teilnehmer durchgeführt. Vor der Abgabe wurde eine gemeinsame Konsolidierung mit
web-basierten Werkzeugen synchron durchgeführt. Das erstellte Modell zeigt keinen Ab-
laufplan, sondern gibt die inhaltliche Aufteilung der Arbeit wieder. Diese entspricht der
446
14.3. Ergebnisse
in der Realität vorgenommenen Aufteilung. Die Teilnehmer führen keine Auffälligkeiten
in der Kooperation oder Schwierigkeiten in der Abstimmung an.
Arbeit 7 (Beurteilung der Konsistenz: 1) Die Teilnehmer teilten die Arbeit inhaltlich
in zwei Teile und kommunizierten zwischen den Abstimmungsterminen ausschließlich via
eMail. Dies wurde von beiden Teilnehmern als sehr produktiv wahrgenommen. Durch
den häufigen Austausch war der jeweilige Status des anderen immer transparent, so
dass die eigene Arbeit angepasst werden konnte und Redundanzen vermieden wurden.
Bei der Modellbildung wurden die einzelnen Arbeitsschritte und eine hohe Anzahl von
Meilensteinen festgelegt, die Arbeitsaufteilung wurde angesprochen, aber nicht explizit
abgebildet. Interessant ist, dass die Teilnehmer die hohe Zufriedenheit mit der Zusam-
menarbeit und auch die hohe Qualität der Arbeit durch die seltenen Präsenztreffen und
die ausführliche Kommunikation via eMail begründen.
Arbeit 8 (Beurteilung der Konsistenz: 1) Diese Gruppe bestand aus drei Teilnehmern,
die zuvor noch nicht zusammengearbeitet hatten, allerdings eine parallele, wöchentli-
che Lehrveranstaltung gemeinsam besuchten. Aus der Dokumentation geht hervor, dass
diese zu wöchentlichen Kurztreffen genutzt wurden, die der Abstimmung des Arbeits-
fortschritts und der nächsten Schritte diente. Die Arbeit wurde inhaltlich aufgeteilt und
weitgehend individuell ausgearbeitet. Das Modell enthielt einen Ablaufplan ohne dezi-
dierte Zuteilung der Zuständigkeiten, die Umsetzung des Ablaufplans konnte aus der
Verlaufsdokumentation jedoch nicht bestätigt werden. Zum inhaltlichen Austausch wur-
de eMail in hoher Frequenz verwendet. Die finale Konsolidierung erfolgte sequentiell
durch die einzelnen Teilnehmer. Die Zusammenarbeit wurde als äußerst professionell
und produktiv empfunden. Auftretenden Unklarheiten wurden unmittelbar und rasch
aufgelöst, es wurden keine Meinungsverschiedenheiten dokumentiert.
Arbeit 9 (Beurteilung der Konsistenz: 3) Die Arbeit wurde von den beiden Teilneh-
mern wiederum inhaltlich in zwei Teile geteilt, die getrennt voneinander individuell be-
arbeitet wurden. Die Teilnehmer dokumentierten intensiven Mailkontakt während der
Phase der Draft-Erstellung, in dem das weitere Vorgehen abgestimmt wurde. Die Zu-
sammenführung der Inhalte wurde von jeweils einem der Teilnehmer durchgeführt. Das
während der Aushandlung erstellte Prozessmodell dokumentierte ein Vorgehensmodell,
in dem parallele individuelle Arbeitsphasen durch kooperative Abstimmungsschritte er-
gänzt wurden. Dieses Vorgehen kann im dokumentierten Arbeitsprozess nicht identifi-
ziert werden, vielmehr wurde ad-hoc via eMail abgestimmt, die expliziten gemeinsamen
Konsolidierungsphasen entfielen. Insgesamt wurde die Zusammenarbeit von beiden Teil-
nehmern als angenehm bezeichnet, wenngleich das Endergebnis als nicht vollkommen
zufriedenstellend empfunden wurde.
447
14.3. Ergebnisse
Arbeit 10 (Beurteilung der Konsistenz: 2) Die Teilnehmer versuchten, die Arbeit wäh-
rend der Literaturrecherche inhaltlich getrennt zu bearbeiten. Sie erkannten, dass dies
aufgrund der starken gegenseitigen Abhänigkeiten in ihrer Themenstellung nicht mög-
lich war und erstellten die folgenden Inhalte weitgehend kooperativ. Die einzelnen Teile
wurden zwar individuell erstellt, jedoch erfolgte eine eher feingranulare Aufteilung und
ein kontinuierliches gegenseitiges Korrigieren der Beiträge des jeweils anderen Teilneh-
mers. Das Modell enthielt in der ersten Phase eine strikte Aufteilung nach inhaltlichen
Kriterien mit Konsolidierungsphasen vor den Meilensteinen (Draft Version und Finale
Version). In der zweiten Anwendung des Werkzeugs wurde das Vorgehen von den Teil-
nehmer modifiziert und an eine vorwiegend kooperative Vorgehensweise angepasst. Die
Zusammenarbeit wurde von beiden Teilnehmern als angenehm und produktiv wahrge-
nommen, wobei ein Teilnehmer dies explizt als „möglicherweise auf die Anwendung des
Werkzeugs zurückzuführen“ bezeichnete.
Diskussion
Die Ergebnisse der Benutzerbefragung in Evaluierungsblock 4 zeigen keinen signifikanten
Hinweis auf eine positive oder negative Wirkung des Werkzeugs auf die jeweils behandel-
ten Arbeitsprozesse. Durch den fehlenden Vergleich mit Abstimmungsprozessen, die ohne
Einsatz des Werkzeugs durchgeführt wurden, kann nicht entschieden werden, ob dies an
den behandelten Problemstellungen bzw. Arbeitsumfeld oder am Werkzeug liegt. Eine
vergleichende Studie konnte aufgrund der geringen Anzahl an zur Verfügung stehenden
Teilnehmern nicht durchgeführt werden.
In der Auswertung der offenen Fragen zeigt sich, dass Wirkungen des Werkzeugs eher
auf die individuelle Verständnisbildung wahrgenommen wurden (siehe auch Abschnitt
14.3.2), Veränderung in den Arbeitsprozessen selbst aber nicht als Konsequenz der Werk-
zeuganwendung festgestellt wurden. Beide Untersuchungsteile aus Evaluierungsblock 4
stützen damit die Hypothese nicht.
Auch die in Evaluierungsblock 2 durchgeführte Auswertungen der „Production Work“
und deren Ergebnisse konnte keine signifikante Verbesserung durch den Einsatz des
Werkzeugs identifizieren. Zwar konnte ein tendenziel besseres Ergebnis bei der Konsis-
tenz der untersuchten Arbeiten gegenüber einer Kontrollgruppe ohne Einsatz des Werk-
zeugs festgestellt werden, aufgrund der geringen Stichprobe ist der Unterschied jedoch
nicht statistisch signifikant. Auch die höhere Stabilität der Gruppen bei Einsatz des
Werkzeugs gegenüber Kontrollgruppen ohne Einsatz des Werkzeugs kann zwar qualita-
tiv festgestellt werden, ist jedoch wiederum nicht statistisch signifikant.
In der Auswertung der dokumentierten Arbeitsprozesse ist zu erkennen, dass ein gutes
Ergebnis der Zusammenarbeit hauptsächlich auf starke Interaktion während der Ausar-
beitung zurückzuführen ist, die Anwendung des Werkzeugs jedoch keine nennenswerten
Auswirkung hatte. Lediglich ein Teilnehmer führte die erfolgreiche Zusammenarbeit auf
448
14.4. Zusammenfassung
die Anwendung des Werkzeugs zurück. Auch dieser Untersuchungsteil stützt die Hypo-
these nicht, wenngleich auch hier wieder Indikationen für eine Wirkung des Werkzeugs
in Einzelfällen zu identifizieren sind.
Insgesamt kann die Hypothese auf Basis der durchgeführten Untersuchungen nicht
bestätigt werden. Einige Indikatoren in den durchgeführten Untersuchungen deuten auf
eine positive Wirkung des Werkzeugs hin, diese sind jedoch nicht statistisch signifikant
oder in einem Ausmaß aufgetreten, in dem von einem systematisch erkennbaren Nut-
zen gesprochen werden kann. Es sind jedoch in keinem Fall negative Auswirkungen des
Einsatzes des Werkzeugs zu identifizieren. Zu hinterfragen ist, ob die eingesetzten Unter-
suchungsansätze in der durchgeführten Form geeignet sind, die Hypothese zu prüfen. Die
gewählten konkreten Anwendungsszenarien hatten zwar jeweils Relevanz im konkreten
Arbeitsumfeld, in keinem Fall war aber eine als urgent wahrgenommene problematische
Situation der Auslöser der Situation. Vielmehr wurden latent problematische Situatio-
nen behandelt, deren Auflösung durch die Durchführung expliziter „Articulation Work“
bei erfolgreicher Durchführung nur beschränkte Auswirkungen auf das konkrete Arbeits-
umfeld hätte haben können. Es wird in weiteren, langfristigeren Studien mit größeren
Stichproben zu untersuchen sein, in wie weit das Werkzeug bei der Auflösung konkreter,
als urgent wahrgenommenen Situationen zum Einsatz gebracht werden kann und ob in
diesen eine Wirkung festgestellt werden kann.
Ergebnis
Die Hypothese 15 kann auf Basis der durchgeführten Untersuchung nicht
bestätigt werden. Sowohl die Ergebnisse der Benutzerbefragung in Evaluierungsblock
4 als auch die Auswertung der durchgeführten „Articulation Work“ in Evaluierungsblock
2 zeigen keine signifikanten (positiven oder negativen) Auswirkungen auf die Arbeits-
prozesse, die Gegenstand der „Articulation Work“ waren. Zwar sind einige Kommentare
zu identifizieren, die auf eine unterstützende Wirkung hinweisen, für eine endgültige
Aussage ist aber eine weiterführende Untersuchung mit größeren Stichproben und um-
fangreicherer Dokumentation des Durchführungskontext notwendig.
14.4. Zusammenfassung
In diesem Kapitel wurde die Evaluierung der „Articulation Work“, die durch das Werk-
zeug unterstützt wurde, beschrieben. Dazu wurden zwei Hypothesen aus der globalen
Zielsetzung abgeleitet, die die unmittelbare Wirkung von „Articulation Work“ auf die
beteiligten Individuen sowie die „Production Work“, die jeweils Gegenstand der „Articu-
lation Work“ war, beschreiben. Das Werkzeug selbst sowie die am Werkzeug eingesetzte
Methodik wurden in den voran gegangenen Kapiteln 12 und 13 beschrieben.
449
14.4. Zusammenfassung
Die erste in diesem Kapitel betrachtete Hypothese (Hypothese 14) bildet die grundle-
gendeWirkung der Durchführung von „ArticulationWork“ auf die beteiligten Individuen
ab. Zu erwarten ist eine Abstimmung der individuellen Sichtweisen auf die „Production
Work“ und die Bildung eines gemeinsamen Verständnisses, das die Kooperation im Ar-
beitsprozess ermöglicht bzw. erleichtert. Die Wirkung des Werkzeugs auf eben diese
Arbeitsprozesse ist Gegenstand der zweiten betrachteten Hypothese (Hypothese 15). Zu
erwarten ist, dass die Durchführung von expliziter „Articulation Work“ wahrnehmbare
Auswirkungen auf die Durchführung der „Production Work“, also den Arbeitsablauf hat.
Zur Untersuchung wurden lediglich die Evaluierungsblöcke 2 und 4 herangezogen. In
diesen war die Aufgabenstellung im Gegensatz zu den übrigen Evaluierungsblöcken stär-
ker auf eine unmittelbare Abbildung konkreten Abläufen in der „Production Work“ aus-
gerichtet, was eine Prüfung der Hypothesen erleichterte. Für die Prüfung der Hypothese
14 wären grundsätzlich auch die Evaluierungsblöcke 3 und 5 geeignet gewesen, die ent-
sprechenden Untersuchungen konnten jedoch aus Ressourcengründen nicht durchgeführt
werden.
Hypothese 14 kann auf Basis der Untersuchung bestätigt werden. Sowohl die quantita-
tiven als auch die qualitativen Daten der Benutzerbefragung stützen die Hypothese und
sprechen für deren Annahme. In der Auswertung der durchgeführten Modellbildungen
zeigte sich keine signifikante Häufung von die Hypothese stützendem Umgang mit unter-
schiedlichen Sichtweisen. Auffällig häufig wurden die Aspekte, in denen unterschiedliche
Sichtweisen herrschten, nicht weiter angesprochen und im Modell ausgespart. Dieses Ver-
halten bedarf weiterführenden Untersuchungen bzw. der Entwicklung von methodischen
Ansätzen, die die Auflösung von derartigen Situationen erleichtern bzw. bestärken.
Die Hypothese 15 kann auf Basis der durchgeführten Untersuchung hingegen nicht
bestätigt werden. Sowohl die Ergebnisse der Benutzerbefragung in Evaluierungsblock 4
als auch die Auswertung der durchgeführten „Articulation Work“ in Evaluierungsblock
2 zeigen keine signifikanten (positiven oder negativen) Auswirkungen auf die Arbeits-
prozesse, die Gegenstand der „Articulation Work“ waren. Zwar sind einige Kommentare
zu identifzieren, die auf eine unterstützende Wirkung hinweisen, für eine endgültige
Aussage ist aber eine weiterführende Untersuchung mit größeren Stichproben und um-
fangreicherer Dokumentation des Durchführungskontext notwendig.
Insgesamt konnte damit in diesem Kapitel gezeigt werden, dass das Werkzeug sei-
ne Zielsetzung im Sinne der Durchführung von „Articulation Work“, nämlich die Ab-
stimmung der individuellen Sichtweisen auf einen Arbeitsablauf erreichen konnte. Dass
trotzdem keine messbare Wirkung auf die eigentliche „Production Work“ zu identifizie-
ren war, schränkt die positive Beurteilung der Wirksamkeit des Werkzeugs teilweise ein.
Die Gründe dafür können einerseits in der in dieser Arbeit vorgeschlagenen Methodik
und dem zugehörigen Werkzeug zu finden sein, andererseits kann auch die Durchführung
der empirischen Untersuchung selbst – und dabei vor allem die Wahl der Anwendungs-
fälle – die Messbarkeit der Wirkung wie oben beschrieben negativ beeinflusst haben. In
450
14.4. Zusammenfassung
weiteren Untersuchungen wird diese Vermutung zu klären und die tatsächliche Wirkung
des Werkzeugs auf die betrachteten Arbeitsabläufe zu zeigen sein.
14.4.1. Beitrag zur globalen Zielsetzung
Dieses Kapitel stellt die Untersuchung der Wirkung der unter Einsatz des Instruments
durchgeführten „Articulation Work“ dar und trägt so hinsichtlich der in Kapitel 1 argu-
mentieren und in den Kapiteln 2 und 3 näher ausgeführten zu untersuchenden Aspekte
zur Beantwortung der Fragestellung 6 („Ermöglicht das Instrument die effektive Durch-
führung von expliziter Articulation Work?“) bei. Die Ergebnisse zeigen eine Wirkung
des Instruments auf die Abstimmung der mentalen Modelle zwischen den beteiligten In-
dividuen, konnten aber keine signifikante Wirkung auf die behandelten Arbeitsabläufe
nachweisen. Die Ergebnisse bestätigen so teilweise die effektive Unterstützung expliziter
„Articulation Work“ durch das hier vorgestellte Instrument.
14.4.2. Weitere Verwendung der Ergebnisse
Die Ergebnisse dieses Kapitels werden in ihrer Gesamtheit erst in den Schlussbetrach-
tungen (Kapitel 15) wieder aufgegriffen und dienen dort der abschließenden Beurteilung
der Erreichung der globalen Zielsetzung.
451
15. Schlussbetrachtungen
In diesem Kapitel werden die Inhalte der gesamten Arbeit zusammengefasst, die Er-
gebnisse zusammengeführt und einander gegenübergestellt. Ziel dieses Kapitels ist es,
letztendlich zu einer Beurteilung der Arbeit hinsichtlich Erfüllung der globalen Zielset-
zung zu gelangen. Die Darstellung von weiterem Entwicklungspotential des Werkzeugs
schließt die Arbeit ab.
Abbildung 15.1.: Kapitel „Schussbetrachtungen“ im Gesamtzusammenhang
Abbildung 15.1 zeigt die Kapitel, deren Ergebnisse in dieses Kapitel einfließen. Die
einzelnen Inhalte werden schrittweise einander strukturiert gegenüber gestellt, was eine
Beurteilung der Zielerreichung auf jeder Betrachtungsebene der Arbeit (Fragestellun-
gen der empirischen Untersuchung, Anforderungen an das Werkzeug, Globale Zielset-
zung) ermöglicht. Nach einer Darstellung der gesamten dieser Arbeit zugrundeliegen-
den Konzepte und deren Zusammenhang in der Arbeit in Abschnitt 15.1 werden die
einzelnen oben genannten Betrachtungsebenen in umgekehrter Reihenfolge als in der
452
15.1. Zusammenfassung der Argumentation
Arbeit dargestellt (also vom Konkreten zum Allgemeinen) einzeln beschrieben. Nach ei-
ner Zusammenfassung der Evaluierungsergebnisse und einer Gegenüberstellung mit den
Ergebnissen der konzeptuellen Einordnung in Abschnitt 15.2 werden diese in Abschnitt
15.3 den in Kapitel 5 angeführten Anforderungen an das Werkzeug gegenübergestellt.
Im letzten Schritt werden die erreichten Ergebnisse hinsichtlich der globalen Zielsetzung
bewertet (siehe Abschnitt 15.4). Auf Basis dieser Ausführungen ist es in Abschnitt 15.5
möglich, die noch offenen Aspekte dieser Arbeit und weiteres Entwicklungspotential zu
identifizieren.
15.1. Zusammenfassung der Argumentation
In Kapitel 1 wurde in Abbildung 2.2 die dieser Arbeit zugrunde liegende Konzeptualisie-
rung von Arbeit in „Production Work“ und „Articulation Work“ dargestellt. Auf Basis
der Ausführungen in den dazwischen liegenden Kapiteln kann diese Abbildung wie in
Abbildung 15.2 dargestellt erweitert werden und stellt so die gesamten konzeptuellen
Grundbegriffe im Zusammenhang dieser Arbeit dar. Eine detailliertere Betrachtung der
Ergebnisse unter Einbeziehung der tatsächlich umgesetzten technischen Unterstützung
und den Ergebnissen der empirischen Evaluierung wird in Abschnitt 15.4 durchgeführt.
Abbildung 15.2.: Gesamtzusammenhang der verwendeten Konzepte
453
15.1. Zusammenfassung der Argumentation
Das Ziel dieser Arbeit ist die Unterstützung der Auflösung von Situationen, in denen
produktive Arbeit nicht (mehr) möglich ist. Dies ist dann der Fall, wenn den beteiligten
Individuen unklar ist, wie die Zielerreichung gewährleistet werden kann. Diese Arbeit
basiert auf der Annahme, dass Interaktion zwischen Individuen immer ein wesentlicher
Aspekt bei der Durchführung von Arbeit ist. Arbeit enthält deshalb auch immer Akti-
vitäten, die mit der Herstellung und Aufrechterhaltung der Interaktion der beteiligten
bzw. betroffenen Individuen beschäftigt sind. Dieser Arbeitsanteil wird als „Articulation
Work“ bezeichnet.
Jedes beteiligte Individuum entwickelt auf Basis früherer Erfahrungen oder Lernpro-
zessen Erklärungsmodelle (oder „Mentale Modelle“) für adäquate Aktivitäten bzw. Re-
aktionen im betreffenden Arbeitsablauf. Wesentlich für die erfolgreiche Interaktion meh-
rerer Individuen in einem Arbeitsablauf ist die Abstimmung dieser Erklärungsmodelle
und die Entwicklung einer gemeinsamen Sichtweise auf jenen Teil des Arbeitsablaufs, in
dem zusammengearbeitet werden muss. Diese Abstimmungsprozesse laufen unbewusst
immer ab, wenn Individuen interagieren. In bestimmten, als komplex oder problematisch
wahrgenommenen Arbeitssituationen reicht die implizite Abstimmung nicht mehr aus –
es ist notwendig, „Articulation Work“ explizit anzustoßen und den Abstimmungsvorgang
bewusst zu unterstützen.
Ein wesentlicher Schritt zur Abstimmung mentaler Modelle ist deren Externalisierung,
also deren Abbildung in einer kommunizierbaren Form. Dazu werden unterschiedliche
Methoden vorgeschlagen, denen gemein ist, dass die Abbildung in Form diagrammati-
scher Modelle erfolgt. In der konkreten Umsetzung unterscheiden sich die beiden hier be-
trachteten Methoden „Strukturlegetechnik“ und „Concept Mapping“ voneinander, bie-
ten aber beide Vorteile bei der Unterstützung der für „Articulation Work“ wichtigen
Kommunizierbarkeit mentaler Modelle. In dieser Arbeit werden deshalb diese beiden
Ansätze in einer Methodik zusammengeführt, die an die im Rahmen von Strukturle-
getechniken vorgeschlagene „Dialog-Konsens-Methodik“ angelehnt ist, in der konkreten
Ausführung aber eher der in Concept Mapping vorgeschlagenen Offenheit sowohl des
Inhalts als auch der Ausgestaltung des Vorgehens folgt.
Generell hat bei der Konzeption der Werkzeugunterstützung der bei Strukturlegetech-
niken vorgeschlagene Ansatz das Primat, weil in ihm die kooperative Durchführung der
Modellbildung explizit vorgesehen ist, was der Abstimmung mentaler Modelle eher ent-
gegenkommt, als der grundsätzlich eher individuell orientierte Concept-Mapping-Ansatz.
Letztendlich wird also in dieser Arbeit der durch Strukturlegetechniken vorgeschlagene
Ansatz der physischen, kooperativen Abbildung von Modellen verfolgt, weshalb die Ab-
bildung der Modelle im physischen Raum, konkret auf eine kooperativ zugreifbare Tisch-
oberfläche, erfolgt. Die Berücksichtigung der Anforderungen des Concept Mapping be-
gründet letztendlich die Notwendigkeit der Hinterlegung der physischen Modellierungs-
möglichkeit mit computergestützten Werkzeugen. Um den Anspruch der physischen,
kooperativen Modellbildung mit den computergestützten Unterstützungswerkzeugen zu
454
15.2. Zusammenfassung der Evaluierung
vereinen, wird zur technologischen Umsetzung des Werkzeugs ein „Tabletop Interface“
verwendet, in dem beide Aspekte berücksichtigt und verknüpft werden können.
15.2. Zusammenfassung der Evaluierung
In diesem Abschnitt wird die in den Kapiteln 11, 12, 13 und 14 beschriebene empirische
Untersuchung zusammengefasst und den Ergebnissen der konzeptuellen Einordnung in
Kapitel 10 gegenübergestellt.
15.2.1. Empirische Untersuchung
In der empirischen Untersuchung waren folgende in Kapitel 11 formulierte Untersu-
chungsfragen zu beantworten:
• Sind das Werkzeug und dessen Komponenten verständlich und wie intendiert ein-
setzbar? (Untersuchungsgegenstand: Verwendbarkeit des Instruments)
• Unterstützt das Instrument die kooperative Modellbildung? (Untersuchungsgegen-
stand: Kooperative Modellbildung)
• Unterstützt das Instrument „ArticulationWork“? (Untersuchungsgegenstand: Wir-
kung der „Articulation Work“)
Jede dieser Fragen wurde in einem separaten Kapitel bearbeitet. Die Untersuchungs-
fragen wurden in Hypothesen konkretisiert, die den jeweiligen Untersuchungsgegenstand
in Bezug zu den aus den konzeptuellen Grundlagen abgeleiteten Anforderungen an die
Unterstützung von „Articulation Work“ stellen.
Verwendbarkeit des Instruments Bei der Betrachtung der ersten Untersuchungsfrage
wurden 8 Hypothesen geprüft, die die grundlegenden Anforderungen an das Werkzeug
abdecken bzw. die Verständlichkeit und Verwendbarkeit der implementierten Funktio-
nen testen. Insgesamt ist das Werkzeug für den intendierten Verwendungszweck – der
kooperativen Erstellung von diagrammatischen Modellen – in unterschiedlichen Anwen-
dungsgebieten einsetzbar. Stabilitätsprobleme in der technischen Umsetzung führten in
den ersten Phasen der Evaluierung zu Behinderungen bei der Modellbildung, was je-
doch durch nachträglich durchgeführte Verbesserungen weitgehend kompensiert werden
konnte. Herausforderungen zeigten sich im Interaktionsdesign der über die Kernfunk-
tionalität hinausgehenden Funktionen zur Unterstützung des Modellbildungsprozesses.
Die aus der Literatur begründbare Funktion zur Verfolgung der Modellierungshistorie
und der Wiederherstellung vergangener Modellzustände wurde kaum genutzt. Auch die
Verwendung der Funktion zur Entfernung von unerwünschten Verbindern im Modell
war den Benutzern in der ersten Version unverständlich. Dieses Problem konnte durch
455
15.2. Zusammenfassung der Evaluierung
ein Redesign des entsprechenden Teilwerkzeugs und dessen Bedienung beseitigt werden.
Generell ist das Werkzeug schnell erlernbar, so dass die Anzahl der Fehlbedienungen
durch Missverständnisse bereits bei der zweiten Anwendung des Werkzeugs durch die
Benutzer massiv reduziert bzw. nicht mehr vorhanden war. Die oben formulierte Frage
kann also mit Vorbehalten positiv beantwortet werden. Generell ist das Werkzeug wie
intendiert einsetzbar und zum Großteil verständlich, einige Komponenten weisen jedoch
Defizite in der Verständlichkeit auf.
Kooperative Modellbildung Für die zweite Untersuchungsfrage wurden 5 Hypothesen
geprüft, die sich auf die Verwendung der Werkzeugs zur Modellbildung im Sinne der vor-
geschlagenen Methodik zur Unterstützung von „Articulation Work“ beziehen. Insgesamt
ist das Werkzeug zwar nur eingeschränkt für die allgemeine Abbildung von Modellen be-
liebigen Inhalts und beliebiger Semantik geeignet. Seinem Verwendungszweck für die
auf Modellen basierende Kommunikation und Abstimmung von individuellen Sichtweise
genügt das Werkzeug jedoch. Die eingeschränkte Eignung für die Abbildung beliebiger
Modelle liegt vor allem in der beschränkten Größe der Modellierungsoberfläche begrün-
det, für die die Möglichkeit zur Einbettung von Teilmodellen keinen adäquaten Ersatz
darstellt. Zudem wurde in Einzelfällen die in der aktuellen Hardware-Implementierung
vorhandene Beschränkung auf drei semantisch unterschiedliche Modellelementtypen ein-
schränkend wahrgenommen, was ebenfalls dem Anspruch eines semantisch vollständig
offen Modellierungswerkzeugs widerspricht. Dies ist insofern zu relativieren, als dass die
Anzahl der Elementtypen in den meisten Fällen zur Kommunikation der individuellen
Sichtweisen ausreichend war und lediglich in Fällen zu gering wahrgenommen wird, wo
eine „vollständige“ Abbildung eines Sachverhaltes angestrebt wurde. Generell ist das
Werkzeug deshalb bei der Modellierung für den intendierten Verwendungszweck in ei-
nem Großteil der Anwendungsfälle geeignet.
Wirkung der Articulation Work In der dritten Untersuchungsfrage wurde letztend-
lich geprüft, ob das Werkzeug im Sinne der globalen Zielsetzung tatsächlich „Articula-
tion Work“ unterstützt. Dazu wurden 2 Hypothesen gebildet, die die zu erwartenden
Wirkungen erfolgreicher „Articulation Work“ abdecken. Die unmittelbare Wirkung der
Durchführung von „Articulation Work“ ist die Bildung eines gemeinsamen Verständnis-
ses über den betrachteten Arbeitsgegenstand. Diese Wirkung konnte in der Untersu-
chung nachgewiesen werden, das Werkzeug erfüllt also diesen Teil der Anforderungen.
Mittelbar sollte die Durchführung von „Articulation Work“ auch Auswirkungen auf die
betrachteten Arbeitsabläufe selbst haben und die Interaktion im Idealfall verbessern.
Derartige Wirkungen konnten jedoch in der Untersuchung nicht nachgewiesen werden.
Einige Beobachtungen in Einzelfällen weisen auf eine entsprechende Wirkung hin, insge-
samt können diese aber nicht generalisiert werden. Ob die nicht nachweisbare Wirkung
am Werkzeug selbst festzumachen ist oder die in der Untersuchung betrachteten Ar-
456
15.2. Zusammenfassung der Evaluierung
beitsabläufe nicht optimal gewählt wurden, wird in weiteren Untersuchung zu prüfen
sein.
15.2.2. Gegenüberstellung der empirischen und konzeptuellen
Untersuchung
In diesem Abschnitt werden die Ergebnisse der empirischen Untersuchung den in in
Abschnitt 10.13.2 angeführten Konsequenzen für die Werkzeuggestaltung aus dessen
konzeptueller Untersuchung gegenübergestellt.
In Kapitel 10 wurde das Werkzeug im Vorfeld der praktischen Untersuchung in die
in Abschnitt 6.4 beschriebenen Frameworks zur Beschreibung von Tangible Interfaces
eingeordnet. Daraus konnte in jenen Fällen Verbesserungpotential für das Werkzeug ab-
geleitet werden, in denen die tatsächliche Umsetzung einer Funktionalität des Werkzeugs
nicht mit den konzeptuell begründbaren Designentscheidung übereinstimmte. In diesem
Abschnitt wird nun angeführt, in welchen Fällen das Verbesserungpotential, d.h. im
Umkehrschluss eine Schwäche der aktuellen Implementierung, in der empirischen Unter-
suchung bestätigt werden konnte. Die Ergebnisse erlauben eine qualitative Aussage über
die Eignung der betrachteten Frameworks für die Konzeption von Tangible Interfaces.
Missverständlichkeit des Löschtokens
Die ursprüngliche Konzeption des Löschtokens zeigte eine Diskrepanz zwischen dessen
wahrgenommener Verwendung und dem tatsächlichen Vorgehen bei dessen Einsatz. Die-
se Schwäche konnte aus mehreren Frameworks abgeleitet werden, da bei konsistenter
Anwendung derselben das Interaktionsdesign anders als tatsächlich umgesetzt hätte aus-
fallen müssen.
Tatsächlich konnte die Mißverständlichkeit der Löschtokens in der empirischen Unter-
suchung bestätigt werden (siehe Abschnitt 12.3.8). Nach einem Redesign der Verwen-
dung des Löschtokens unter Berücksichtigung der konzeptuell indizierten Gestaltungs-
Kriterien traten keine Missverständnisse mehr auf, das Ausmaß des Einsatzes stieg si-
gnifikant an.
Schwache Ein-Ausgabe-Kopplung bei der Modellierungshistorie
Nach der Aktivierung der Modellierungshistorie wird diese ausschließlich durch ein Werk-
zeug auf der Modellierungsoberfläche kontrolliert. Die Ausgabe erfolgt jedoch ausschließ-
lich auf dem sekundären Ausgabekanal, auf der Tischoberfläche erfolgt kein visuelles
Feedback, weder über die Aktivierung des Historienmodus noch über deren aktuellen
Zustand (konkret die aktuelle Position in der Zeitlinie). Nach Ullmer und Ishii (2000)
ist diese schwache Kopplung zu hinterfragen.
457
15.2. Zusammenfassung der Evaluierung
In der empirischen Untersuchung konnte dieser Aspekt nicht als Schwachstelle bestä-
tigt werden. Die Entkopplung von Kontrolle und Ausgabe in diesem Anwendungsfall
wurde von keinem Teilnehmer als missverständlich wahrgenommen und führte auch nie
zu Fehlbedienungen. Dies mag daran liegen, dass der sekundäre Ausgabekanal räum-
lich nahe an der Tischoberfläche angeordnet war und von vielen Teilnehmern bei der
Modellerstellung ohnehin als primäre Informationsquelle – noch vor der Tischoberfläche
selbst – genutzt wurde. Erst bei der Diskussion verlagerte sich der Fokus der Aufmerk-
samkeit hin zu dem auf der Tischoberfläche gelegten Modell. Die von der herkömlichen
Interaktionsform mit Maus und Tastatur vertraute entkoppelte Ein- und Ausgabe hat
in diesem Fall Bedienungsprobleme vermieden. Dass keine Desorientierung der Benutzer
beimWechsel in den Historienmodus auftrat, ist damit zu begründen, dass der sekundäre
Ausgabekanal permanent aktiv war, den Modellzustand immer synchron darstellte und
deshalb, wie oben erwähnt, oft ohnehin als primärer Informationskanal genutzt wurde.
Lange Antwortzeiten auf Interaktionen
In der ersten Implementierung des Systems kam es vor allem bei der Interaktion zur
Herstellung von Verbindern zu Verzögerungen in der Reaktion des Systems. Diese Ver-
zögerungen sollten nach Bellotti et al. (2002) vermieden werden, um den Benutzern
adäquat Rückmeldung über deren Interaktionswunsch geben zu können.
In der empirischen Untersuchung konnte diese Schwachstelle bestätigt werden. Die
Möglichkeit zur Herstellung von Verbindern wurde in der ursprünglichen Implementie-
rung kaum genutzt. Erst als eine weitere Möglichkeit zur Herstellung von Verbindern
implementiert wurde, deren wahrgenommener Reaktionszeit geringer war, wurde diese
Möglichkeit in signifikant höherem Ausmaß genutzt (siehe Abschnitt 12.3.7).
Fehlende einfache Undo-Funktion
Die Möglichkeit zur Wiederherstellung von vergangenen Modellzuständen (”Undo”) ist
in der aktuellen Implementierung zwar gegeben, bedingt aber eine zeitaufwändige und
in mehreren Schritten durchzuführende Interaktion mit dem System. Dies sollte nach
Bellotti et al. (2002) vermieden werden, auch das Schema von Shaer et al. (2004) lässt
hier Inkonsistenzen mit den den ansonsten ausschließlich in einem Bedienungsschritt
ausführbaren Interaktionen mit dem Werkzeug erkennen.
In der empirischen Untersuchung wurde die Möglichkeit zur Wiederherstellung zwar
verwendet, das Ausmaß des Einsatzes sank aber signifikant, als das Löschtoken neu
gestaltet wurde und so eine einschrittige Interaktion zur Korrektur von fehlerhaften
Verbindungen (dem häufigsten Grund des Einsatz der Undo-Funktion) geschaffen wurde.
Die Gestaltung der Wiederherstellungsfunktion kann damit als Schwachstelle bestätigt
werden.
458
15.2. Zusammenfassung der Evaluierung
Mangelnde Verständlichkeit des Snapshot-Tokens
Das Design des Snapshot-Tokens weist in der derzeitigen Umsetzung nicht auf dessen
Funktion hin, was bei einer Einordnung in die Taxonomie nach Fishkin (2004) gegen-
über den anderen Werkzeugen inkonsistent ist. Das Token suggeriert zwar nicht wie im
Fall des Löschtoken eine andere Funktionalität, gibt aber den Benutzern durch sein Er-
scheinungsbild keinen Hinweis auf die Verwendung (mangelhafte Affordances (Norman,
1990)).
Tatsächlich zeigt sich in der empirischen Untersuchung, dass die Funktion zur explizi-
ten Erfassung von Snapshots kaum bzw. in den meisten Anwendungen nicht verwendet
wird. Trotz einer erklärenden Einführung in das Werkzeug vor der Modellbildung be-
stehen häufig Unklarheiten zur Verwendung des Tokens, sobald Benutzer während der
Anwendung damit konfrontiert werden. Auch diese Designentscheidung ist damit als
Schwachstelle zu bestätigen.
Funktional belegte Bereich der Modellierungsoberfläche
Der hier beschriebene Aspekt ist keine Schwachstelle des Werkzeugs sondern eine Erwei-
terungsmöglichkeit, die auf Basis der Ausführungen von Ishii und Ullmer (1997) identi-
fiziert wurde. Die Autoren schlagen vor, Teile der Interaktionsoberfläche („Trays“) mit
Funktionen zu belegen, die eine bestimmte Operation auf einem auf ihm platzierten
Token ausführen (etwa: „Details anzeigen“). Bei der Umsetzung des Werkzeugs wurde
diese Möglichkeit nicht berücksichtigt, es sind jedoch sinnvolle Anwendungsmöglichkei-
ten denkbar.
In der empirischen Untersuchung wurden derartige Funktionen von keinen Benutzern
erwartet oder gefordert. Da diese Form der Interaktion aber nicht der gängigen Desktop-
Metapher entspricht, ist dies auch nur eingeschränkt zu erwarten. Es kann damit auf
Basis der Untersuchung keine Aussage über die Notwendigkeit oder Sinnhaftigkeit einer
derartigen Erweiterung getroffen werden.
Verwendbarkeit frei wählbarer Tokens
Zur Anpassung des Modellierungswerkzeugs an die jeweilige Anwendungsdomäne führt
Holmquist et al. (1999) als Möglichkeit die Verwendung von domänenspezifischen Token
an. Diese Forderung ist grundsätzlich mit den Ansprüchen der semantischen Offenheit
des Werkzeugs und der domänenübergreifenden Anwendbarkeit des Ansatzes vereinbar
und stützt diese. In der derzeitigen Implementierung ist die Zahl der unterschiedlichen
Modellelementtypen auf drei begrenzt. Diese Elementtypen sind in generischen Formen
ausgeführt und per se nicht intuitiv domänenspezifisch interpretierbar.
459
15.3. Erfüllung der Anforderungen an das Werkzeug
In der empirischen Untersuchung wurde mehrfach die Forderung nach einer höheren
Anzahl von unterschiedlichen Elementtypen geäußert, was aber die hier betrachtete Er-
weiterungsmöglichkeit nur am Rande betrifft (die Verwendung beliebiger Elementtypen
erhöht zwar deren Anzahl, umgekehrt impliziert die Forderung nach mehr Element-
typen nicht jene nach beliebigen Ausprägungen derselben). Tatsächlich wurde aber in
einigen Anwendungen explizit der Wunsch geäußert, Objekt aus dem spezifischen An-
wendungsfall (etwa Dokumente oder Werkzeuge) als Tokens verwenden zu können. Dies
entspricht im Wesentlichen der oben beschriebenen Erweiterungsmöglichkeit, weshalb
diese als sinnvoll erachtet werden kann.
Zusammenfassung
Die in der konzeptuellen Einordnung des Werkzeugs identifizierten Inkonsistenzen im
Design und Verbesserungspotentiale konnten in der empirischen Untersuchung großteils
bestätigt werden. In jenen Fällen, in denen die konzeptuell identifizierten Lösungsmög-
lichkeiten in der Praxis umgesetzt wurden, zeigte sich auch jeweils eine Verbesserung
der Verständlichkeit bzw. der Bedienbarkeit des Werkzeugs.
Insgesamt erschienen die Ansätze von Bellotti et al. (2002), Shaer et al. (2004) und
Fishkin (2004) als geeignet für den Einsatz im Design von begreifbaren Benutzungs-
schnittstellen. Während Bellotti et al. (2002) allgemeine Richtlinie für die Gestaltung
von Benutzungsschnittstellen vorschlägt, ohne konkret auf Tangible Interfaces einzu-
gehen, fokussieren Shaer et al. (2004) und Fishkin (2004) explizit auf dieses Gebiet.
Dabei eignet sich die Arbeit von Shaer et al. (2004) insbesondere für die Gestaltung der
Interaktionsabläufe an der Benutzungsschnittstelle und deren konkrete Werkzeugunter-
stützung zu eignen. Die Arbeit von Fishkin (2004) erlaubt hingegegen die Beurteilung
der Konsistenz der Bedienkonzepte und ermöglicht so die Identifikation von möglicher-
weise missverständlichen Aspekten bei der Bedienung der Schnittstelle (siehe dazu auch
(Oppl, 2009b)).
15.3. Erfüllung der Anforderungen an das Werkzeug
In diesem Abschnitt werden die in Kapitel 5 formulierten Anforderungen an das Werk-
zeug hinsichtlich ihrer Erfüllung betrachtet. Die Beurteilung der Erfüllung erfolgt anhand
der empirischen Ergebnisse, die in den Kapiteln 12, 13 und 14 beschrieben wurden.
Anforderung 1
Anforderung 1 („Physische Abbildung beliebiger diagrammatischer Modelle“) wurde in
den Hypothesen 1, 5 und 6 untersucht. Die grundlegende Abbildung diagrammatischer
Modelle mit dem Werkzeug ist ohne Einschränkung der Anwendungsdomäne möglich.
460
15.3. Erfüllung der Anforderungen an das Werkzeug
Bei der Untersuchung des Prozesses der physischen Abbildung der Modelle konnten in
den ersten durchgeführten Evaluierungsblöcken behindernde Aspekte identifiziert wer-
den. Diese hatten Einfluss auf die Abbildung der Modelle, insbesondere die Möglichkeit
des Einsatzes von Verbindern im Modell wurde nur eingeschränkt wahrgenommen.
Nach Überarbeitungen des Interaktionsdesigns und der Implementierung mehrerer
Maßnahmen zur Steigerung der Robustheit gegenüber Fehlerkennungen von Benutzer-
eingaben konnten die als behindernd wahrgenommenen Faktoren reduziert werden. Bei
mehrmaliger Verwendung des Werkzeugs zeigt sich eine Verbesserung des Umgangs mit
den zur Verfügung gestellten Ausdrucksmöglichkeiten und eine stärke Fokussierung auf
den zu repräsentierenden Sachverhalt. Insgesamt kann diese Anforderung als erfüllt an-
gesehen werden.
Anforderung 2
Anforderung 2 („Unterstützung der iterativen Aushandlung des Modells“) wurde in Hy-
pothese 14 untersucht. Ziel der Unterstützung von Aushandlungsprozessen ist die Bil-
dung einer gemeinsamen Sichtweise auf das betrachtete Problem. Die kooperative Mo-
dellierung ist durch das Design von Hard- und Software grundsätzlich möglich, durch
die Verwendung eines Tabletop Interface wird die kooperative Modellbildung und der
Austausch über den Modellierungsgegenstand (also das betrachtete Problem) ermög-
licht. Die beabsichtigte Wirkung der Abstimmung der individuellen Sichtweisen konnte
in der empirischen Untersuchung bestätigt werden. Insgesamt kann diese Anforderung
also bestätigt werden.
Anforderung 3
Anforderung 3 („Ermöglichung experimenteller Veränderungen am Modell“) wurde in
Hypothese 4 untersucht. Experimentelle Veränderungen am Modell werden durch die
Unterstützung der Wiederherstellung von vergangenen Modellzuständen realisiert. Die-
se Funktion wurde technisch implementiert und hinsichtlich ihrer Funktionsfähigkeit
getestet. Diese ist vollständig gegeben.
In der empirischen Untersuchung wurde die Funktionalität von den Teilnehmern jedoch
nicht genutzt, so dass die Erfüllung der Anforderung empirisch nicht bestätigt werden
kann. Aus den Ergebnissen der Untersuchung ist vielmehr zu hinterfragen, ob diese aus
der Theorie der Externalisierung mentaler Modelle abgeleitete Anforderung in der Praxis
tatsächlich relevant ist.
461
15.3. Erfüllung der Anforderungen an das Werkzeug
Anforderung 4
Anforderung 4 („Nicht vorgegebene Semantik der Modellierungselemente“) wurde in den
Hypothesen 3 und 9 untersucht. Durch die nicht vorgegebene Semantik der Modellie-
rungselemente wird einerseits der Einsatz des Werkzeugs in unterschiedlichen Anwen-
dungskontexten ermöglicht, andererseits werden Benutzer nicht gezwungen, ein vorge-
gebenes Abbildungsschema für die von ihnen auzudrückende Information zu verwenden.
Dies ermöglicht ein Fokussierung auf die Modellierungsinhalte und die Kommunikation
derselben und vermeidet einen zusätzlichen – potentiell kognitiv belastenden – Über-
setzungsschritt. Die Wahl der Bedeutung der Modellierungselemente ergibt sich aus der
ohnehin ablaufenden Interaktion verursacht und keine Probleme.
Technisch wurde diese Anforderung durch die Verwendung generischer (also semantisch
nicht vorbelegter) Modellierungsbausteine in Kombination mit dem Einsatz von Topic
Maps zur Repräsentation der Modelle umgesetzt. Das Werkzeug erlaubt grundsätzlich
die Verwendung von beliebigen und beliebig vielen unterschiedlichen Modellierungsbau-
steinen, diese Möglichkeit wurde jedoch im vorliegenden Prototypen nicht eingesetzt.
Die empirische Untersuchung konnte die Einsetzbarkeit in unterschiedlichen Anwen-
dungskontexten ohne Einschränkung bestätigen. Die Modellierung selbst wurde jedoch
durch die im Prototypen auf drei unterschiedliche Modellierungselemente eingeschränkte
Ausdrucksstärke des Werkzeugs teilweise als einschränkend empfunden. Da dies jedoch
keine konzeptuelle Einschränkung ist, sondern ausschließlich dem aktuellen Entwick-
lungsstand der Werkzeug-Hardware geschuldet ist, kann diese Anforderung insgesamt
als erfüllt angesehen werden.
Anforderung 5
Die Erfüllung von Anforderung 5 („Verknüpfung mit digitalen Ressourcen“) wurde im
Rahmen der durchgeführten Studien nicht untersucht. Die Verknüpfung mit digitalen
Ressourcen wurde analog zur Funktion zur Einbettung von Teilmodellen implementiert.
Digitale Dokumente können an einbettbare Tokens gebunden werden und in einem Con-
tainer durch Hineinlegen zugewiesen werden. Diese Funktionalität wurde technisch im-
plementiert und hinsichtlich ihrer Funktionsfähigkeit getestet.
Im Rahmen der Evaluierung wurde das Werkzeug ausschließlich mit einem Rechner
betrieben, auf dem keine fallspezifischen bzw. anwendungsrelevanten digitalen Doku-
mente vorhanden waren. Die Einbindung von Dokumenten in Modelle konnte deswegen
nicht vorgenommen werden. Die Anforderung ist also technisch erfüllt, konnte jedoch
empirisch nicht überprüft werden.
462
15.3. Erfüllung der Anforderungen an das Werkzeug
Anforderung 6
Anforderung 6 („Bearbeitung von beliebig umfangreicher Modellen“) wurde in Hypothe-
se 10 untersucht. Durch die physisch beschränkte Größe der Modellierungsfläche kann
die Erweiterung der Modellgröße lediglich durch die Erstellung von Teilmodellen er-
reicht werden, wobei deren Zusammenhang durch die Einbettung der Teilmodelle in
Überblicksmodelle ausgedrückt wird. Die Einbettung von Teilmodellen wird mittels der
Verwendung von Modellierungsblöcken als Container realisiert, in die Tokens als Re-
präsentaten der Teilmodelle gelegt werden können. Die dazu notwendigen Funktionen
wurden technisch implementiert und hinsichtlich ihrer Funktionsfähigkeit erfolgreich ge-
testet.
Auch in der empirischen Untersuchen wurde die Erweiterung der Modellgröße durch
Einbettung von Teilmodellen erfolgreich eingesetzt. Im Vergleich der erstellten Model-
le mit Modellen, die mit einem Werkzeug mit nicht beschränkter Modellierungsfläche
erstellt wurden, zeigte sich jedoch eine signifikant geringere Modellgröße bei der Erstel-
lung mit dem hier vorgestellten System. Die Erstellung beliebig großer Modelle ist somit
technisch grundsätzlich möglich und auch verwendbar, empirisch konnte die Erfüllung
der Anforderung dennoch nicht nachgewiesen werden.
Anforderung 7
Anforderung 7 („Kooperative und unmittelbare Manipulierbarkeit des Modells“) wurde
in den Hypothesen 2 und 12 untersucht. Die Möglichkeit, Modelle kooperativ zu erstellen
und zu manipulieren, ist grundsätzlich gegeben, die Möglichkeit der Durchführung eines
kooperativen Modellierungsprozesses konnte empirisch belegt werden. Im Vergleich zu
einem bildschirmbasierten System zeigt sich außerdem ein signifikant höherer Anteil an
Interaktion zwischen den Teilnehmern bei der Durchführung der Modellierung mit dem
hier vorgestellten System. Die Anforderung kann somit als erfüllt angesehen werden.
Anforderung 8
Anforderung 8 („Persistente Ablage des Modells und Möglichkeit zur Rekonstruktion“)
wurde in Hypothese 11 untersucht. Die Persistente Ablage der erstellten Modelle wur-
de mittels XML-Topic Maps realisiert. Die Funktionsfähigkeit der Persistierung wurde
insofern technisch nachgewiesen, als dass die exportierten Modellrepräsentationen va-
lide XTM-Dateien waren und sämtliche auf der Modellierungsoberfläche repräsentierte
Information in der Datei abgebildet war.
Hinsichtlich der Ermöglichung der Rekonstruktion und der Nachvollziehbarkeit des
Modellierungsprozesses konnte gezeigt werden, dass die bei der Persistierung inkludierte
Entstehungshistorie des Modells die Nachvollziehbarkeit der im Modell repräsentierten
Information zwar tendenziell erleichterte, aber nicht in allen Fällen ermöglichte. Die An-
463
15.3. Erfüllung der Anforderungen an das Werkzeug
forderung kann damit technisch als erfüllt angesehen werden, die positive Wirkung der
eingebetteten Entstehungshistorie des Modells konnte ebenfalls bestätigt werden. Insge-
samt ist die Nachvollziehbarkeit der Modelle ausschließlich auf Basis der gespeicherten
Repräsentationen aber in Frage zu stellen.
Zusammenfassung
Zusammenfassend ergibt sich hinsichtlich der Erfüllung der Anforderungen die in Tabelle
15.1 dargestellte Übersicht. In ihr sind die Anforderungen jenen Kapiteln und Abschnit-
ten des Implementierungsteils (Impl.) zugewiesen, in denen ihre technische Umsetzung
beschrieben wird, sowie den Hypothesen (Hyp.) zugeordnet, in denen die tatsächliche
Überprüfung der Erfüllung durchgeführt wird.
464
15.4. Bewertung hinsichtlich der globalen Zielsetzung
Tabelle 15.1.: Erfüllung der Anforderungen
Anforderung Impl. Hyp. Beurteilung
1 Physische Abbildung be-
liebiger diagrammatischer
Modelle
7.4.3,
7.4.5,
8.3.3
1, 5, 6 technisch möglich,
empirisch teilweise
bestätigt
2 Unterstützung der iterati-
ven Aushandlung des Mo-
dells
8.3.4 14 technisch möglich,
empirisch bestätigt
3 Ermöglichung experimen-
teller Veränderungen am
Modell
7.4.7,
8.3.4
4 technisch möglich,
empirisch nicht bestä-
tigt
4 Nicht vorgegebene Seman-
tik der Modellierungsele-
mente
7.4.6,
9.2.2
3, 9 technisch möglich,
empirisch teilweise
bestätigt
5 Verknüpfung mit digitalen
Ressourcen 7.4.4,
8.3.3
— technisch möglich,
empirisch nicht ge-
prüft
6 Bearbeitung von beliebig
umfangreicher Modellen 7.4.4 10 technisch möglich,
empirisch nicht bestä-
tigt
7 Kooperative und unmittel-
bare Manipulierbarkeit des
Modells
7.4.8,
8.4.1
2, 12 technisch möglich,
empirisch bestätigt
8 Persistente Ablage des Mo-
dells und Möglichkeit zur
Rekonstruktion
7.4.7,
8.3.4,
9.2.1
11 technisch möglich,
empirisch bestätigt
15.4. Bewertung hinsichtlich der globalen Zielsetzung
In diesem Abschnitt wird die Arbeit hinsichtlich der globalen Zielsetzung zusammen-
gefasst, reflektiert und beurteilt. In Kapitel 1 wurde die globale Zielsetzung wie folgt
formuliert:
465
15.4. Bewertung hinsichtlich der globalen Zielsetzung
In der vorliegenden Arbeit sind die Möglichkeiten zur methodischen Unter-
stützung von expliziter Articulation Work unter Berücksichtigung relevanter
Theoriebildungen zur Rolle der beteiligten Individuen zu erfassen, auf Ba-
sis dieser Erkenntnisse geeignete Methoden auszuwählen, diese in einem
Instrument umzusetzen und dessen Effektivität im Kontext der Production
Work zu prüfen.
Zur Detaillierung dieser Zielsetzung wurden zwei Forschungsfragen formuliert, die im
Folgenden in die Betrachtung einfließen:
1. Wie kann die Durchführung und Wirkung von „Articulation Work“ charakterisiert
werden?
2. Wie kann explizite „Articulation Work“ effektiv unterstützt werden?
Bei der Reflexion der Ergebnisse dieser Arbeit hinsichtlich der Forschungsfragen wird
jeweils auch auf den Kontext der Arbeit, aus dem die Ableitung der Zielsetzung heraus
durchgeführt wurde, Bezug genommen.
15.4.1. Wie kann die Durchführung und Wirkung von „Articulation
Work“ charakterisiert werden?
Die globale Zielsetzung stellt den Anspruch, die methodischen Möglichkeiten der Un-
terstützung expliziter „Articulation Work“ zu untersuchen. Die Festlegung bzw. Ein-
schränkung auf explizite „Articulation Work“ dient der Abgrenzung der Arbeit zu exis-
tierenden Ansätzen, die sozial und/oder technologisch in Arbeitsabläufe intervenieren
und dem Auftreten von Unklarheiten vorbeugen bzw. diese durch unmittelbare Unter-
stützungmaßnahmen auflösen. All diese Ansätze sind in den Bereich der Unterstützung
impliziter „Articulation Work“ einzuordnen, die Durchführung derselben ist den han-
delnden Personen also nicht unbedingt bewusst.
Treten Situationen auf, die von den Beteiligten als so problematisch wahrgenommen
werden, dass eine Aufrechterhaltung des Arbeitsablaufs nicht mehr gewährleistet ist,
muss die Handlungsfähigkeit durch explizite Beschäftigung mit der problematischen Si-
tuation (wieder) hergestellt werden. Dieser Fall wird als explizite „Articulation Work“
bezeichnet. Das Erfolgskriterium für explizite „Articulation Work“ ist das Erreichen ei-
nes Zustandes, in dem gegenseitiges Verständnis soweit (wieder-)hergestellt ist, dass die
produktiven Arbeitsabläufe durch implizite „Articulation Work“ aufrecht erhalten wer-
den können. Es müssen somit die methodischen und technischen Voraussetzungen zur
466
15.4. Bewertung hinsichtlich der globalen Zielsetzung
erfolgreichen (Wieder-)Erlangung einer gemeinsamen Sichtweise aller Beteiligten auf den
als problematisch wahrgenommenen Betrachtungsgegenstand geschaffen werden.
Ein Erklärungsansatz, mit dem das Phänomen von unterschiedlichen Sichtweisen auf
den gleichen realen Arbeitsablauf oder -gegenstand erklärt werden kann, sind mentale
Modelle. Mentale Modelle beschreiben, wie Individuen aus wahrgenommenen Situatio-
nen Handlungsalternativen ableiten und sich letztendlich für die Durchführung bestimm-
ter Aktivitäten entscheiden. Bei kooperativen Arbeitsprozessen ist es notwendig, dass
von den Individuen zumindest eine gemeinsame Sichtweise auf die Schnittstellen, an
denen diese kooperieren, erreicht wird – die individuellen mentalen Modelle über diese
Schnittstellen müssen also abgestimmt werden. Diese Abstimmung ist eine Ausprägung
der Durchführung expliziter „Articulation Work“ – auch hier gilt, dass nicht sämtliche
mentale Modelle, die den jeweiligen Arbeitsablauf betreffen, abgestimmt werden müssen.
Es ist vielmehr ausreichend, lediglich jene Aspekte abzustimmen, die für die Kooperation
untereinander relevant sind.
Zur Abstimmung mentaler Modelle ist deren Kommunizierbarkeit eine notwendige
Vorbedingung. Diese Kommunizierbarkeit wird durch Externalisierung der mentalen Mo-
delle ermöglicht. Als vorteilhaft für die Kommunikation komplexer Sachverhalte wird in
der Literatur die Repräsentation derselben in der Form von diagrammatischen Modellen
bezeichnet. Während zur Repräsentation diagrammatischer Modelle grundsätzlich unter-
schiedliche Möglichkeiten bestehen, werden Strukturlegetechniken und Concept Mapping
im Bereich der Externalisierung mentaler Modelle grundsätzlich als geeignet bezeichnet.
15.4.2. Wie kann explizite „Articulation Work“ effektiv unterstützt
werden?
Im Kontext des Einsatzes zur Abstimmung mentaler Modelle sind besonders Struk-
turlegetechniken als relevant zu betrachten. Deren methodische Hinterlegung durch die
Dialog-Konsens-Methodik zielt explizit auf die Bildung eines gemeinsamen Verständ-
nisses ab und eignet sich deshalb für die Unterstützung expliziter „Articulation Work“.
In Einzelaspekten, etwa der semantischen Offenheit der Modellierungselemente, bringt
aber auch der Ansatz der Concept Maps Konzepte ein, die im Kontext der Durchfüh-
rung expliziter „Articulation Work“ relevant sind (Jørgensen, 2004). In dieser Arbeit
wird deshalb versucht, eine Variante von Strukturlegetechniken zu entwickeln, die die
für „Articulation Work“ relevanten Aspekte von Concept Mapping berücksichtigt und
so die Abstimmung mentaler Modelle aus beliebigen Arbeitskontexten ermöglicht.
Die in dieser Arbeit vorgeschlagene Methodik, die auf den Ansätzen von Strukturle-
getechniken und Concept Mapping basiert, bedingt eine Unterstützung durch ein Werk-
zeug, das die Abbildung der dazu notwendigen diagrammatischen Modelle unterstützt.
Die aus der Methodik abgeleiteten Anforderungen implizieren, dass die Modellierung
selbst im physischen Raum durchgeführt wird, diese aber dennoch durch rechnerbasier-
467
15.4. Bewertung hinsichtlich der globalen Zielsetzung
te Funktionen unterstützt und ergänzt wird. Die Zusammenführung der physischen und
digitalen Repräsentation und Interaktonsmechanismen wird durch ein Tangible Tabletop
Interface realisiert.
Dieses Werkzeug ermöglicht es, auf einer Tischoberfläche mit physischen Elementen
(Bausteinen) diagrammatische Modelle zu erstellen. Die Bausteine werden dazu auf der
Tischoberfläche platziert und mittels unterschiedlicher Interaktionen mit dem System
untereinander in Beziehung gesetzt. Die Darstellung der Beziehungen erfolgt dabei durch
Projektion auf die Tischoberfläche, um eine einfache Manipulierbarkeit des Modells ge-
währleisten zu können. Um dem Anspruch der semantischen Offenheit des Modells und
damit der Anpassbarkeit der Modelle an die individuellen Sichtweisen der Teilnehmer ge-
währleisten zu können, werden die Modellelemente semantisch nicht vorbelegt, sondern
während der Modellbildung durch die Teilnehmer spezifiziert.
Die Gesamtheit der abgebildeten Modelle inklusive der Festlegung der Bedeutung der
Modellelemente wird als semantisches Netzwerk in Form einer Topic Map digital reprä-
sentiert. Dies gewährleistet die Nachvollziehbarkeit und Weiterverwendbarkeit der Mo-
delle auch über einzelne Anwendungen des Werkzeugs hinweg. Zur Unterstützung des
Modellierungs- und Abstimmungsprozesses wurden Funktionen entwickelt, die vor allem
die einfache und konsequenzlose Veränderbarkeit des Modells gewährleisten sollen. Dazu
zählen unter anderem die Verfolgung des Modellierungsprozesses durch das System, die
Erfassung stabiler Modellzustände und die Möglichkeit, durch die Entstehungshistorie
des Modells zu navigieren und vergangene Modellzustände wieder herzustellen.
Konkret wurde das Werkzeug hardwareseitig als Tisch mit transparenter Oberfläche
ausgeführt. Die Modellierungsoberfläche ist 80 x 100 cm groß und erlaubt die gleichzei-
tige Verwendung von etwa 15 Modellierungselementen. Die Modellierungselemente sind
in drei unterschiedlichen Formen und Farben in Acrylglas ausgeführt und können ge-
öffnet werden. Diese Funktion als Container ermöglicht die Einbettung von zusätzlicher
Information in das Modell durch Hineinlegen kleiner informationstragender Elemente.
Auch die Einbettung von Teilmodellen und damit einhergehend die Erweiterung der
Modellgröße ist möglich.
Unter der Tischoberfläche ist ein Videoprojektor angebracht, die die Verbindungen
im Modell, die Benennung der Modellelemente sowie zusätzliche Information zur Mo-
dellierungsunterstützung auf die Oberfläche projiziert. Zusätzlich ist eine zweite Ausga-
beoberfläche in Form eines Bildschirms (oder alternativ einer Leinwand mit Projektor)
vorhanden, auf der der aktuelle Modellzustand synchron mitgeführt wird und auf dem
nicht kohärent auf der Tischoberfläche darstellbare Information, wie etwa die Model-
lierungshistorie, dargestellt wird. Sämtliche Interaktion mit dem System wird über die
Tischoberfläche durchgeführt, lediglich die Benennung der Modellelemente erfolgt alter-
nativ mittels Tastatur, da der auf Bilderkennung basierende primäre Benennungsmecha-
nismus nicht ausreichend stabil für eine komfortable Bedienung arbeitete.
468
15.4. Bewertung hinsichtlich der globalen Zielsetzung
Das Werkzeug kann von mehreren Personen simultan bedient werden und erfasst den
Modellierungsverlauf selbstständig im Hintergrund. Dies wird einerseits genutzt wer-
den, um Modellvarianten zu erproben und einfach zu einem stabilen, akzeptierten Zu-
stand zurückzukehren und bietet andererseits die Möglichkeit, die gesamte Historie der
Modellentstehung persistent abzulegen und zu einem späteren Zeitpunkt wieder abzu-
rufen. In beiden Fällen bietet das Werkzeug Unterstützung bei der Wiederherstellung
eines gespeicherten Modellzustandes, indem schrittweise Anweisungen zur Platzierung
der entsprechenden Modellelemente auf die Tischoberfläche projiziert werden.
Das Werkzeug wurde in mehreren Revisionen technisch stabilisiert und ermöglicht in
seinem derzeitigen Zustand die Durchführung beliebig umfangreicher Modellbildungen
mit beliebiger zeitlicher Ausdehnung. Die Softwarekomponenten sind außerdem für eine
etwaige Kopplung mehrerer physischer oder digitaler Modellbildungs-Werkzeugs (etwa
weiterer Modellierungtische) vorbereitet, um auch räumlich entfernte Kooperation zu
ermöglichen.
Die Untersuchung der effektiven Unterstützung von expliziter „Articulation Work“
bedingt die Konkretisierung des Effektivitäts-Begriff. Grundsätzlich wird „Articulation
Work“ immer im Zusammenhang mit einem konkreten Arbeitsprozess (der „Production
Work“) bzw. mit einer in diesem aufgetretenen problematischen Situation durchgeführt.
Die Wirkung von „Articulation Work“ zeigt sich an damit unmittelbar an der „Produc-
tion Work“ und an den in diesem beteiligten Individuen. „Articulation Work“ ist dann
effektiv, wenn die beteiligten Personen die Situation nicht mehr als problematisch wahr-
nehmen und die „Production Work“ (wieder) ohne Hindernisse durchgeführt werden
kann. Eine Voraussetzung zur Durchführung effektiver expliziter „Articulation Work“
ist aus methodischer Sicht die Durchführung der kooperativen Modellbildung, die zur
Abstimmung der individuellen mentalen Modelle über die „Production Work“ verwendet
wird. Hinsichtlich der kooperativen Modellbildung ist als Voraussetzung der effektiven
Unterstützung expliziter „Articulation Work“ die Fähigkeit des Instruments zu sehen,
die zur Durchführung der Modellbildung notwendigen Schritte für die beteiligten Indi-
viduen verständlich und benutzbar zu unterstützen.
Hinsichtlich des letztgenannten Aspektes wurden bereits während der Implementie-
rung des Werkzeugs begleitend Benutzertests durchgeführt, um dessen Benutzbarkeit
zu überprüfen. Die Ergebnisse dieser Tests flossen in die Überarbeitung des Werkzeugs
und dessen unterstützte Interaktionsabläufe ein. Nach Abschluss der Implementierung
der grundlegenden Funktionalität wurde mit der Prüfung der Wirkung des Werkzeugs
im Sinne der Aufgabenstellung begonnen. Diese wurde wie oben beschrieben einerseits
auf Ebene der „Articulation Work“ selbst durchgeführt, andererseits wurde auch die
Voraussetzung dafür, also die Unterstützung der Repräsentation und Kommunikation
mentaler Modelle, geprüft.
Hinsichtlich der Repräsentation und Kommunikation mentaler Modelle wurde geprüft,
ob beliebiger Modelle abgebildet werden können und ob diese Abbildung ohne wahrge-
469
15.4. Bewertung hinsichtlich der globalen Zielsetzung
nommene Einschränkungen der Benutzer möglich ist. Als zweiter Aspekt wurde über-
prüft, ob die Modelle bzw. Modellbildung der Kommunikation und Interaktion zwischen
den Benutzern zuträglich sind, ob also jene Aktivitäten, die im Rahmen von „Articula-
tion Work“ durchgeführt werden müssen, ermöglicht und unterstützt werden. Während
die Abbildbarkeit beliebiger Modelle vor allem durch die beschränkte Größe der Model-
lierungsfläche und die Einschränkung auf drei unterschiedliche Modellierungselement-
typen in der derzeitigen Implementierung nicht gegeben ist, werden Kommunikation
und Interaktion am Werkzeug bei der Modellbildung unterstützt. Die Interaktion bei
kooperativer Modellbildung ist bei der Durchführung am Modellierungstisch signifikant
höher als bei der Verwendung herkömmlicher bildschirmbasierter Werkzeuge gleicher
oder höherer Flexibilität.
Bei der Überprüfung der Wirkung des Werkzeugs auf die durchgeführte „Articula-
tion Work“ wurde wie oben beschrieben auf zwei Aspekte eingegangen, an denen die
Effektivität der Durchführung zu erkennen ist. Zum einen wurden die unmittelbaren
Auswirkungen, d.h. die Bildung eines gemeinsamen Verständnisses, und zum anderen
die Auswirkungen auf den behandelten Arbeitsablauf, also die „Production Work“, un-
tersucht. Die unmittelbare Wirkung des Werkzeugs auf die Bildung eines gemeinsamen
Verständnisses über den betrachteten Arbeitsaspekt konnte in der Untersuchung be-
stätigt werden. Zur Generalisierbarkeit der Bestätigung sind aber aufgrund der kleinen
Stichprobe in lediglich einem Anwendungsfall weitere Untersuchungen notwendig (siehe
Abschnitt 15.5.2). Eine Wirkung der anhand des Werkzeugs durchgeführten „Articula-
tion Work“ auf die eigentlichen Arbeitsprozesse konnte hingegen in der Untersuchung
nur in Einzelfällen beobachtet werden und kann nicht im Allgemeinen bestätigt wer-
den. Auch hier gilt, dass weitere Untersuchungen zur Verbreiterung der Datengrundlage
notwendig sein werden.
15.4.3. Globale Zielsetzung
Insgesamt konnte die globale Zielsetzung in dieser Arbeit erreicht werden.
In Teil I wurde der erste in der Zielsetzung angesprochene Forschungsgegenstand („In
der vorliegenden Arbeit sind die Möglichkeiten zur methodischen Unterstützung von ex-
pliziter Articulation Work unter Berücksichtigung relevanter Theoriebildungen zur Rolle
der beteiligten Individuen zu erfassen, . . . “) behandelt. Als Lücke in der Unterstützung
von „Articulation Work“, wie sie sich vor der Durchführung dieser Arbeit darstellte,
konnte die mangelnde Beachtung der Aktivitäten und Bedürfnisse der beteiligten Indi-
viduen identifiziert werden. Diesem Mangel wurde konzeptuell mit der Einbindung des
Ansatzes der „mentalen Modelle“ und deren Veränderung begegnet, der eine Möglichkeit
zur Erklärung eben dieser individuellen Aktivitäten darstellt.
Der zweite in der Zielsetzung angeführte Forschungsgegenstand („. . . auf Basis dieser
Erkenntnisse geeignete Methoden auszuwählen, diese in einem Instrument umzusetzen
470
15.5. Offene Aspekte und Entwicklungspotential
. . . “) wurde am Ende von Teil I und vor allem in Teil II betrachtet. Auf Basis der Theo-
rie der mentalen Modelle wurden methodische Möglichkeiten zur Abstimmung derselben
betrachtet, was letztendlich zur Identifikation von Anforderungen an eine mögliche tech-
nische Unterstützung führte. Auf Basis dieser Anforderungen wurde die Verwendung von
„Tabletop Interfaces“ als geeignetes Mittel zur Unterstützung der Abstimmung mentaler
Modelle gewählt. Die Zusammenführung der in diesem Forschungsgebiet vorhandenen
Ansätze und theoretischen Arbeiten mit den Anforderungen zur Unterstützung von „Ar-
ticulation Work“ ermöglichte die Konzeption eines interaktiven Systems, dessen Eigen-
schaften auf die Anwendung der entwickelten Methodik abgestimmt waren. Die konkre-
ten zur Umsetzung notwendigen Designentscheidungen wurden auf Basis des aktuellen
Stands der Technik getroffen, während der Umsetzung wurden begleitende Benutzer-
tests durchgeführt, um die Verwendbarkeit der intendierten Werkzeuge sicherzustellen.
Das Werkzeug konnte sowohl hardwareseitig als auch softwareseitig bis zu einem Zu-
stand entwickelt werden, der einen praktischen, produktiven Einsatz in kontrollierten
Umgebungen möglich macht.
Die Behandlung des letzten in der Zielsetzung genannten Forschungsgegenstandes
(„. . . und dessen Effektivität im Kontext der Production Work zu prüfen.“) wurde in
Teil III beschrieben. Die positive Wirkung auf die Interaktion zwischen den Teilneh-
mern bei Einsatz des Werkzeugs zur Durchführung von „Articulation Work“ konnte in
der Untersuchung empirisch bestätigt werden. Die auf Basis dieser Ergebnisse erwarteten
Verbesserungen in der „Production Work“ konnten jedoch nicht nachgewiesen werden.
Ob dies in der Konzeption des Werkzeugs begründet liegt oder die Studie selbst nicht
ideal auf die Prüfung dieses Aspektes abgestimmt war, bleibt an dieser Stelle Gegenstand
zukünftiger Untersuchungen.
15.5. Offene Aspekte und Entwicklungspotential
Das entwickelte Instrument, also die Methodik sowie das Werkzeug, hat in der vorliegen-
den Umsetzung einen Reifegrad erreicht, das es für den prototypischen Einsatz im rea-
len Arbeitskontext qualifiziert. Trotzdem konnten im Rahmen der Durchführung dieser
Arbeit in mehreren Fällen Potentiale und Schwächen identifiziert werden, die im Rah-
men der Arbeit selbst nicht mehr gehoben bzw. kompensiert werden konnten und einer
Umsetzung im Rahmen weiterer Forschungsaktivitäten bedürfen. In diesem Abschnitt
werden diese offene Aspekte und Entwicklungspotentiale auf drei Ebenen beschrieben:
• Das Werkzeug zeigt in der vorliegenden Form wie oben bereits beschrieben Poten-
tial Verbesserungen seiner Anwendbarkeit im Sinne der Unterstützung von Arti-
culation Work. Diese Potentiale werden in Abschnitt 15.5.1 beschrieben.
• Die Prüfung des Werkzeugs ließ für manche Teilaspekte keine endgültige Entschei-
dung hinsichtlich deren Wirksamkeit zu. Dies ist einerseits auf die Natur der zur
471
15.5. Offene Aspekte und Entwicklungspotential
Prüfung herangezogenen Anwendungen des Werkzeugs, andererseits aber auch auf
methodische Schwachstellen zurückzuführen. Beide Faktoren werden in Abschnitt
15.5.2 behandelt.
• Letztendlich konnten im Rahmen der Entwicklung und Evaluierung des Werkzeugs
Anwendungsgebiete identifiziert werden, die in dieser Form in der vorliegenden
Arbeit nicht explizit berücksichtigt wurden. Diese Anwendungsgebiete zeigen Ent-
wicklungspotential für das Werkzeug auf und werden deshalb in Abschnitt 15.5.3
umrissen.
15.5.1. Entwicklungspotential des Werkzeugs
Wie bereits in Abschnitt 15.2.2 beschrieben, konnten sowohl in der empirischen Unter-
suchung als auch bei der konzeptuellen Einordnung des Werkzeugs mehrere Funktionen
identifiziert werden, in denen Verbesserungen bzw. Erweiterungen vorgenommen werden
können.
Vorrangig zu betrachten ist die Erweiterung und Flexibilisierung der Modellelement-
typen. Die Anzahl der Elementtypen ist in der derzeitigen Implementierung auf drei be-
schränkt, was in einigen Fällen einschränkend auf die Modellbildung wirkt. Softwareseitig
ist das Werkzeug bereits für eine Erweiterung vorbereitet, es sind jedoch Interaktions-
mechanismen zur Registrierung und Bedeutungsspezifikation neuer, unter Umständen
physisch beliebig ausgeprägter Elementtypen zu entwickeln.
Eine ähnliche, in der praktischen Anwendung mehrmals geforderte Funktion ist die
Möglichkeit zur Verwendung unterschiedlicher Arten von Verbindern. Aktuell können
Verbinder ungerichtet sein oder mit Pfeilspitzen versehen werden. Gefordert wurde et-
wa die Möglichkeit zum Einsatz unterschiedlich gefärbter Verbindungen. Wiederum ist
die Umsetzung dieser Funktion software-seitig ohne hohen Aufwand zu realisieren, wie
zuvor muss jedoch ein Interaktionsmechanismus entwickelt werden, um die Arten der
verwendeten Verbinder zu konfigurieren und mit Bedeutung zu belegen.
Die mangelnde Möglichkeit, Änderungen am Modell einfach und in einem Interaktions-
schritt rückgängig zu machen, hemmt die Bereitschaft zur Erstellung von hypothetischen
Modellvarianten. Die Implementierung einer einschrittigen Undo-Funktion könnte hier
zu Verbesserungen führen und die Interaktion mit dem Werkzeug vereinfachen.
Technologisch einschränkend wirkt nach wie vor der zu den Rändern hin das Bild stark
verzerrende Erfassungsbereich der verwendeten Kamera, der die Modellierungsoberfläche
in den Randbereichen unverwendbar macht, da Modellelemente dort nicht identifiziert
werden können. Die weitere Stabilisierung der Erkennungsleistung kann diesen Mangel
zum Teil kompensieren, letztendlich wird nur eine Neukonzeption und Reimplementie-
rung der Hardwarekomponenten zu einer endgültigen Lösung des Problems führen.
472
15.5. Offene Aspekte und Entwicklungspotential
Weiteres Verbesserungspotential konnte in Detailbereichen einzelner verwendeter Werk-
zeuge identifiziert werden (siehe Abschnitt 15.2.2). Diese werden an dieser Stelle nicht
mehr im Einzelnen aufgeführt, zumal deren Umsetzung großteils ohne hohen Aufwand
durchgeführt werden kann.
15.5.2. Prüfung der effektiven Unterstützung
Bei der Durchführung der empirischen Untersuchung konnten Schwächen im Untersu-
chungsdesign festgestellt werden, die aufgrund mangelnder Möglichkeiten zur erneuten
Prüfung nicht kompensiert werden konnten. Diese Schwächen betrafen generell (a) das
geringe Ausmaß der Durchführung vergleichender Studien, (b) die nur in Einzelfällen
ausführlich durchgeführte inhaltliche Reflexion durch die Untersuchungteilnehmer sowie
(c) die teilweise suboptimale Auswahl der abzustimmenden Arbeitsaspekte, die Gegen-
stand der „Articulation Work“ waren. Alle drei Punkte sind in erster Linie auf die nicht
frei wählbare zur Verfügung stehende Stichprobe an Teilnehmern, deren beschränkte
Anzahl sowie die zeitlich beschränkte Möglichkeit deren Inanspruchnahme zurückzufüh-
ren. Würden diese einschränkenden Faktoren nicht bestehen, könnten die im Folgenden
beschriebenen Untersuchungen die Wirksamkeit des Werkzeugs umfangreicher und zu-
verlässiger prüfen, als dies in der vorliegenden Arbeit der Fall war.
Bei der Prüfung der Bildung eines gemeinsamen Verständnisses wurde in dieser Ar-
beit auf die subjektive Einschätzung der Untersuchungsteilnehmer zurückgegriffen. Die-
ses Vorgehen kann durch Untersuchungsmethoden ergänzt werden, die das Verständnis
explizit messen. Zur Untersuchung der Veränderung der individuellen mentalen Modelle
und deren mögliche Übereinstimmung hinsichtlich des Untersuchungsaspektes bietet sich
die von (Ifenthaler, 2006) vorgeschlagenen Untersuchungsmethode an. Auch der Einsatz
der etablierten Varianten von Strukturlegetechniken und der Dialog-Konsens-Methodik
ist hier eine Möglichkeit, die potentiellen Veränderungen zu externalisieren und damit
gegenüberstellen zu können.
Bei der Prüfung der effektiven Unterstützung der „Articulation Work“ durch das ent-
wickelte Instrument war in der vorliegenden Arbeit die Stichprobe sowohl hinsichtlich
ihres Umfangs als auch hinsichtlich der behandelten Thematiken retrospektiv betrach-
tet suboptimal gewählt. Auch die vorrangige Bezugnahme auf die Einschätzungen der
Teilnehmer zur Diagnose etwaiger Veränderungen bzw. positiver Auswirkungen im Ar-
beitsprozess ist zu hinterfragen. Bei weiterführenden Studien ist darauf zu achten, dass
Arbeitsabläufe als Gegenstände der „Articulation Work“ gewählt werden, in denen die
Durchführung von expliziter „Articulation Work“ tatsächlich unmittelbar angezeigt ist.
Dies war in den hier durchgeführten Untersuchungen nur teilweise der Fall, weshalb
unmittelbare Auswirkungen auf den Arbeitsablauf mangels der Notwendigkeit von Ver-
änderungen nur in Einzelfällen erwartete werden konnten. Weiters ist zur Fundierung
einer generalisierbaren Aussage über die Wirkung des Werkzeugs der Prüfung eine brei-
473
15.5. Offene Aspekte und Entwicklungspotential
tere Datenbasis zugrunde zu legen. Im vorliegenden Fall wurden etwa 20 Anwendungen
aus 2 unterschiedlichen Anwendungskontexten untersucht – vor allem die Anzahl der
Anwendungskontexte muss bei einer weiteren Untersuchung gesteigert werden, um die
Wirkung des Werkzeugs über spezifische Situationen hinweg beurteilen zu können.
15.5.3. Alternative Anwendungsfelder
Im Zuge der Durchführung dieser Arbeit wurde das entwickelte Werkzeug auch mehrfach
experimentell in anderen als dem ursprünglich intendierten Kontext eingesetzt oder bei
Gelegenheiten vorgestellt, bei denen mit der Durchführung von „Articulation Work“
nicht befasste Personen das Werkzeug im Sinne ihrer Fachexpertise interpretierten und
unterschiedliche Einsatzszenarien aufzeigten. Die beiden am häufigsten genannten und
in der Praxis bereits erfolgreich durchgeführten Anwendungsfelder werden im Folgenden
beschrieben.
Der Einsatz des Werkzeugs zur Unterstützung von individuellen und vor allem ko-
operativen Lernprozessen ist auf Grund der methodischen Grundlage aus der Theorie
der Veränderung mentaler Modelle (Seel, 2003a) naheliegend. Der zur Motivation dieser
Arbeit verwendete Ansatz der mentalen Modelle wird auch zur Erklärung und zur Kon-
zeption von Lernprozessen verwendet (Seel, 2003b), Methoden wie Concept Mapping
wurden dezidiert für den Lehr- und Lernkontext entwickelt (Novak und Cañas, 2006).
Das Werkzeug hat das Potential, die Anwendung meta-kognitive Kompetenzen wie Re-
flexion von Lerninhalten oder Planung von Lernschritten zu unterstützen (siehe dazu
auch (Oppl et al., 2010) für Erörterungen auf konzeptueller Ebene sowie die Ergebnis-
se der Evaluierungsblöcke 3 und 5 auf praktischer Ebene). Vor allem die Verknüpfung
des Werkzeugs mit technologisch unterstützten Lernplattformen auf Basis der digitalen
Repräsentation in Form der als Topic Maps abgelegten Modelle kann Lernprozesse auf
individuelle und kooperativer Ebene unterstützen. Erste Ideen dazu wurden in (Oppl
und Stary, 2009), (Oppl, 2009a), (Oppl, 2009b) und (Neubauer et al., 2009) publiziert.
Im Rahmen der Durchführung von Vorstellungen des Werkzeugs im Umfeld von Kon-
ferenzen im Wissensmanagement und (Fort-)Bildungsbereich wurde dieses mehrfach von
Personen, die „Aufstellungsarbeit“ (Sparrer, 2002) praktizieren, als geeignetes Werkzeug
zur Unterstützung der dort ablaufenden Prozesse identifiziert. Tatsächlich wurde in Eva-
luierungsblock 4 in einem Fall eine durch einen fachkundigen Teilnehmer moderierter an
Aufstellungsarbeit angelehnte Modellbildung durchgeführt und von allen Teilnehmern
als fruchtbar empfunden. Das Werkzeug diente dabei als Mediator der einzelnen Sicht-
weisen, auf dem die Modellierungsblöcke so lange neu positioniert und rotiert wurden,
bis alle Teilnehmer mit der dargestellten „Aufstellung“ der betrachteten Organisations-
einheit zufrieden waren. Das Ergebnis dieser Anwendung wurde generell als neue, bislang
nicht explizit gemachte Aspekte der Zusammenarbeit innerhalb der Organisation und
deren Schnittstellen nach außen wahrgenommen. Das Werkzeug hat also Potential, im
474
15.6. Schluss
Kontext von „Aufstellungsarbeit“ sinnvoll zum Einsatz gebracht zu werden. Für einen et-
waigen Produktiv-Einsatz ist nach Rückmeldung mehrere Fachexperten jedoch die oben
angeführte Erweiterung und Flexibilisierung der Anzahl und Art der Modellelementty-
pen zwingend notwendig.
15.6. Schluss
In dieser Arbeit wurde ein Instrument zur Unterstützung expliziter „Articulation Work“
vorgestellt. Sowohl Methode als auch Werkzeug wurde im Rahmen der Arbeit konzipiert,
umgesetzt und erfolgreich zur Anwendung gebracht. Eine Arbeit wie diese ist nie abge-
schlossen – jeder erreichte Meilenstein eröffnet eine Vielzahl von möglichen Alternativen
zur Weiterentwicklung.
Die vorliegenden Ergebnisse repräsentieren in diesem Sinne lediglich einen möglichen
Weg durch das weite Feld an Möglichkeiten zur Unterstützung von „Articulation Work“.
Gleichzeitig bilden sie einen Startpunkt für weitere Forschung, deren Ergebnis und deren
Verlauf nicht abgeschätzt werden kann.
Wenn nur eine Meta-Erkenntnis aus dieser Arbeit zurückbleibt, so ist es die, dass
es genau diese Unsicherheit und das vergebliche Streben, sie durch Wissenschaft unter
Kontrolle zu bringen, ist, die das Betreiben von Forschung zu einem lohnenden und
erfüllenden Lebensinhalt machen.
Ich hoffe, mit dieser Arbeit ein Stück weit dazu beigetragen zu haben, die Vorausset-
zungen zu schaffen, dass Menschen einfacher, effizienter, effektiver und vor allem für sie
zufriedenstellender zusammenarbeiten und die gesteckten Ziele erreichen können.
Steyr, am 28. Juni 2010
475
Anhang
476
A. Literatur zum Themengebiet
Articulation Work
Dieser Anhang stellt die Literatur zu „Articulation Work“ umfassend dar. Er dient
als Ergänzung zu den in Kapitel 2 eingeführten Konzepten und Inhalten. Insbesondere
wurden die hier beschriebenen Arbeiten hinsichtlich ihrer Relevanz für die Begriffsbe-
stimmung zu „Articulation Work“ und deren Unterstützung beurteilt. Die als relevant
identifizierten Arbeiten wurden in den Abschnitten 2.1, 2.2 und 2.4 umfassender darge-
stellt.
A.1. Literaturquellen
In der Literatursuche wurden Datenbanken aus den Bereichen Informatik, Psycholo-
gie, Soziologie, den Wirtschaftswissenschaften sowie der Organisationslehre durchsucht.
Nach der initialen Suche wurde jeweils auch die in den gefundenen Arbeiten referenzierte
Sekundärliteratur aufgearbeitet. Des weiteren wurden mit Hilfe von rückwärts verlinken-
den Datenbanken (wo vorhanden) Publikationen erfasst, die auf die bislang gefundenen
Arbeiten referenzieren. Die so identifizierten Publikationen wurden ebenfalls hinsichtlich
ihrer Relevanz überprüft.
Die in der Suche berücksichtigten Datenbanken bzw. Meta-Suchmaschinen sind:
Domänenspezifische Datenbanken
• INSPEC1 (Naturwissenschaften)
• Business Source Premier2 (Wirtschaftswissenschaften)
• PsycINFO3 (Psychologie)
• PSYNDEXplus4 (Psychologie)
• SocINDEX5 (Soziologie)
1via http://ovidsp.ovid.com
2via http://search.ebscohost.com/
3via http://ovidsp.ovid.com
4via http://ovidsp.ovid.com
5via http://search.ebscohost.com/
477
A.2. Relevante Literatur
• ERIC6 (Pädagogik)
• ACM Guide7 (Informatik)
Verlags-Datenbanken
• ACM Digital Library8 (Informatik)
• IEEE XPlore9 (Informatik)
• SpringerLink10 (fächerübergreifend)
• ScienceDirect11 (fächerübergreifend)
• Emerald12 (Wirtschaftswissenschaften)
• Wiley Interscience13 (fächerübergreifend)
Meta-Suchmaschinen
• Google Scholar14 (fächerübergreifend)
• CiteSeerX15 (Naturwissenschaften und Informatik)
A.2. Relevante Literatur
Die im Folgenden genannten Arbeiten beziehen sich in unterschiedlicher Weise auf das
Themengebiet „Articulation Work“. Es konnten vier Kategorien von Arbeiten identifi-
ziert werden, die sich hinsichtlich ihres inhaltlichen Fokus unterscheiden:
(I) Arbeiten, die sich mit der grundlegenden Konzeption von „Articulation Work“
beschäftigen und keine Aussage zu deren Unterstützung machen.
(II) Arbeiten, in denen „Articulation Work“ als erklärendes Rahmenwerk für beob-
achtete Phänomene verwendet wird, und in der Folge das Hauptaugenmerk auf
diese Phänomene gelegt wird, ohne nochmals näher auf „Articulation Work“ ein-
zugehen.
(III) Arbeiten, die auf die Unterstützung von „Articulation Work“ eingehen.
(IV) Arbeiten, in denen „Articulation Work“ lediglich erwähnt wird, allerdings nicht
näher darauf Bezug genommen wird.
6http://www.eric.ed.gov/
7http://portal.acm.org/guide.cfm
8http://portal.acm.org/dl.cfm
9http://ieeexplore.ieee.org
10http://www.springerlink.de
11http://www.sciencedirect.com
12http://www.emeraldinsight.com
13http://www3.interscience.wiley.com
14http://scholar.google.com/
15http://citeseerx.ist.psu.edu/
478
A.2. Relevante Literatur
In chronologischer Reihenfolge des Erscheinens sind die folgenden Arbeiten einer oder
mehreren der genannten Kategorien zuzuordnen (Kategorie jeweils in Klammer ange-
führt):
Strauss (1985) (I) prägt in dieser Arbeit den Begriff „Articulation Work“ und be-
schreibt dieses auf konzeptueller Ebene ohne eine unmittelbaren Praxis- bzw. Um-
setzungsbezug herzustellen.
Gasser (1986) (I) beschreibt die Integration von Computerunterstützung in alltägliche
Arbeitsabläufe und die Anpassungsleistung der arbeitenden Individuen, wenn die
aktuelle Arbeitssituation nicht mehr mit dem der Computerunterstützung zugrun-
de liegenden Modell übereinstimmt. Er identifiziert dabei spezifische Aktivitäten,
die im Rahmen der ablaufenden „Articulation Work“ auftreten können.
Gerson und Star (1986) (I, II) zeigen die konkrete Manifestation von „Articulation
Work“ in einer Fallstudie aus einem Versicherungskonzern und identifizieren dar-
aus die organisationalen Rahmenbedingungen, die zu jenen Problemen führen, die
„Articulation Work“ notwendig machen.
Bendifallah und Scacchi (1987) (II) untersuchen bezugnehmend auf Gasser (1986)
„Articulation Work“ im Kontext von IT-Support-Arbeit in Unternehmen anhand
von zwei Fallstudien und identifizieren dabei zwei unterschiedliche Strategien bei
der Durchführung derselben. Im Detail gehen sie jedoch nicht auf die konkret zu
setzenden Maßnahmen ein.
Fujimura (1987) (I) leitet die grundlegende Unterscheidung zwischen „ProductionWork“
und „ArticulationWork“ anhand einer Fallstudie aus dem wissenschaftlich-medizinischen
Forschungsbetrieb ab. Sie bleibt dabei auf konzeptueller Ebene und beschreibt die
auftretenden Phänomene, geht jedoch nicht auf unterstützende Maßnahmen ein.
Strauss (1988) (I) detailliert und erweitert seine Konzepte und setzt diese in den Kon-
text organisationaler Projektarbeit (im dort beschrieben Verständnis im Wesentli-
chen identisch mit „non-routine collective activity“). Anhand einer Fallstudie aus
dem Krankenhaus-Organisations-Bereich zeigt er das Auftreten von „Articulation
Work“ in der Praxis, beschäftigt sich jedoch nicht mit möglicherweise unterstüt-
zenden Interventionen.
Schmidt (1990) (I) beschreibt ein Framework für die Analyse kooperativer Arbeit und
erwähnt dabei „Articulation Work“ als ein zu berücksichtigendes Konzept. Diese
Arbeit bildet die Grundlage für die im Hinblick auf die Unterstützung von „Arti-
culation Work“ relevantere Arbeit von Schmidt und Bannon (1992).
Mi und Scacchi (1991) (III) betrachten „Articulation Work“ im Kontext der Software-
entwicklung und argumentieren für deren explizite Berücksichtigung in Software
Engineering Prozessen. Sie schlagen einen formalisierten Prozess zur Durchführung
von „Articulation Work“ vor und führen einen Satz von regelbasierten Heuristiken
479
A.2. Relevante Literatur
zur konkreten Durchführung ein. Sie sind damit die ersten, die sich explizit mit
der Unterstützung von „Articulation Work“ beschäftigen.
Schmidt und Bannon (1992) (I, III) begründen mit dieser Arbeit eine Entwicklungs-
richtung der CSCW, die neben der Unterstützung der eigentlichen produktiven
Arbeit auch auf die Unterstützung von „Articulation Work“ fokussiert. Sie be-
schreiben damit erstmals Anforderungen an die technische Unterstützung von „Ar-
ticulation Work“ und Möglichkeiten zu deren Umsetzung.
Bannon und Schmidt (1993) (II) zeigen in diesem Sammelwerk die ersten Ergebnisse
des COMIC-Projektes (Rodden, 1995) und erwähnen dabei in einzelnen Beiträgen
„Articulation Work“ als ein im Bereich der CSCW zu berücksichtigendes Konzept.
Corbin und Strauss (1993) (I) beschäftigen sich mit der Festlegung von Interaktions-
modalitäten in kooperativer Arbeit durch „Articulation Work“ und detaillieren
dabei das Verständnis von expliziter „Articulation Work“, indem sie mögliche Zeit-
punkte des Auftretens sowie Schritte bei deren Durchführung nennen.
Strauss (1993) (I) fasst im Rahmen einer umfassenderen Arbeit zur Entwicklung einer
„Theory of Action“ seine Überlegungen zur Rolle und Ausgestaltung von „Arti-
culation Work“ zusammen und würdigt diese kritisch. Konkrete Maßnahmen zur
Unterstützung oder Ermöglichung von „Articulation Work“ sind aber auch hier
nicht vorhanden.
Bowers (1994) (III) ist Editor eines COMIC-Deliverables (Rodden, 1995), in dem zum
ersten Mal auf die in (Schmidt und Simone, 1996) ausformulierten Anforderungen
zur technischen Unterstützung von „Articulation Work“ eingegangen wird.
Lenoir (1994) (IV) erwähnt „Articulation Work“ (konkret die Arbeit von Fujimura
(1987)) als Beispiel der Verknüpfung unterschiedlicher wissenschaftlicher Arbeits-
kontexte, geht aber dann nicht näher auf „Articulation Work“ ein.
Schmidt (1994) (III) rephrasiert im Wesentlichen (Schmidt, 1990) mit Fokus auf den
Aspekt der kooperativen Arbeit (und nicht der Computerunterstützung derselben).
Er detailliert darin die Artikulationsnotwendigkeiten bei kooperativer Arbeit, führt
jedoch hinsichtlich der Unterstützung von „Articulation Work“ keine zusätzlichen
Anforderungen ein.
Schmidt et al. (1995) (III) basiert wie (Schmidt, 1994) auf (Schmidt, 1990), leitet je-
doch inhaltlich bereits zu der oben im Detail behandelten Arbeit von Schmidt und
Simone (1996) über.
Grinter (1995) (II) beschreibt die Verwendung von Konfigurations-Management-Systemen
zur Koordination von Softwareentwicklungs-Prozessen. Sie bezieht sich dabei am
Rand auf „Articulation Work“ (via (Schmidt und Bannon, 1992)), führt diesen
Aspekt aber nicht näher aus. Diese Arbeit bildet jedoch die Grundlage für die hin-
sichtlich der Unterstützung von „Articulation Work“ relevantere Arbeit derselben
Autorin (Grinter, 1996).
480
A.2. Relevante Literatur
Simone et al. (1995) (III) konkretisieren die in Schmidt und Simone (1996) beschrie-
bene Notation zur Spezifikation von Koordinationsmechanismen in CSCW-Systemen
und bereiten damit den Weg zur technischen Unterstützung von „coordinating pre-
defined work“, die in (Divitini und Simone, 2000) umfassend beschrieben ist.
Grinter (1996) (III) betrachtet die Rolle von „Articulation Work“ im Kontext der Soft-
wareentwicklung und zeigt anhand zweier qualitativer empirischer Studien die Aus-
wirkungen eines computerbasierten Configuration Management Systems bei der
kooperativen Erstellung von Software.
Schmidt und Simone (1996) (I, III) entwickeln in ihrer Arbeit ein generisches Vorge-
hen zur Konzeption von technischer Unterstützung von „Articulation Work“. Auf-
bauend auf früheren Arbeiten der Autoren (z.B. (Schmidt, 1990) und (Schmidt
und Bannon, 1992)) formulieren die Autoren eine Notation zur Spezifikation von
CSCW-Systemen, die auf der Unterstützung von „Articulation Work“ aufbauen.
Bannon und Bødker (1997) (II) beschreiben die Verwendung von „Common Informa-
tion Spaces“ im Kontext von CSCW und identifizieren die Artikulations-Bedürfnisse,
die im Rahmen der Verwendung derselben auftreten können. Die Autoren gehen
nicht näher auf die Umsetzung oder Unterstützung dieser konkreten Ausprägungen
von „Articulation Work“ ein.
Fjuk et al. (1997) (I, III) versuchen, die Konzepte von „Articulation Work“ durch eine
Abbildung auf die Konzepte der „Activity Theory“ zu konkretisieren. Die Autoren
geben dabei neben der Erweiterung der konzeptuellen Grundlagen auch mögliche
Ansatzpunkte für die Unterstützung durch rechnerbasierte Werkzeuge an.
Fjuk und Dirckinck-Holmfeld (1997) (II) verwendet die Ansätze von Strauss (1993),
um die Interaktion in computerbasierten kooperativen Lernumgebungen (also in
CSCL16-Systemen) zu betrachten. Sie verwendet dabei „Articulation Work“ als
Analysedimension (als jener Teil des Arbeitsablaufs, in dem Interaktion zwischen
den Lernenden vorrangig auftritt), gehen jedoch nicht näher auf deren Unterstüt-
zung ein.
Simone und Bandini (1997) (IV) beschreiben ein System zur Generierung von Awa-
reness in kooperativen Anwendungen und erwähnen dabei am Rande „Articulation
Work“, als einen Aspekt, bei dessen Unterstützung das System interessant sein
könnte.
Simone und Divitini (1997) (III) berichten über den aktuellen Stand der Entwick-
lung bei der technischen Unterstützung von Koordinationsmechanismen in CSCW-
Systemen. Sämtliche hier enthaltenen Ergebnisse werden umfassender in (Divitini
und Simone, 2000) dargestellt.
Kling und Star (1998) (II) beschreiben „Articulation Work“ als einen Aspekt, dessen
Unterstützung bei der Gestaltung von „human centered (computer) systems“ zu
16Computer Supported Cooperative Learning
481
A.2. Relevante Literatur
berücksichtigen ist. Sie gehen jedoch nicht unmittelbar auf die mögliche Form der
Unterstützung ein.
Carstensen und Schmidt (1999) (III) führen Aspekte von (Schmidt und Simone, 1996)
genauer oder aus einem anderen Betrachtungswinkel aus, fügen aber dem Ver-
ständnis von „Articulation Work“ bzw. deren Unterstützung keine neuen Aspekte
hinzu.
Schmidt und Simone (1999) (III) betonen basierend auf (Schmidt und Simone, 1996)
den dynamischen Charakter von „Articulation Work“, die in einem Arbeitsablauf
je nach Kontext unterschiedliche Ausprägungen annehmen kann. Sie fordern eine
Berücksichtigung dieser Dynamik in technischen Werkzeugen zur Unterstützung
von „Articulation Work“, fügen aber den Ausführungen von (Schmidt und Simone,
1996) keine fundamental neuen Anforderungen hinzu. Die Autoren leiten mit die-
ser Arbeit über zu der erstmals in Simone et al. (1999) vorgestellten technischen
Implementierung des in den vorgegangenen Publikationen konzipierten Werkzeugs.
Simone et al. (1999) (III) stellen als Umsetzung der in (Schmidt und Simone, 1996)
aufgestellten Forderungen zur Unterstützung von „ArticulationWork“ durch CSCW-
Systeme den „Reconciler“ vor, ein auf auf Java und CORBA17 basierendes Software-
Modul, das den globalen Kontext und Zustand eines (digitalen) Arbeitsobjektes
bei dessen Bearbeitung durch ein Individuum offenlegt und dadurch die Entwick-
lung einer gemeinsamen Sicht auf geteilt benutzte Objekte ermöglicht und die
Vermeidung von Konflikten unterstützt. Der „Reconciler“ ist damit ein techni-
sches Werkzeug zur Unterstützung von „situated Articulation Work“, die Arbeit
detailliert jedoch lediglich die in (Schmidt und Simone, 1996) genannten Unter-
stützungsaspekte um diese technisch implementierbar zu machen.
Suchman (1999) (II) beschäftigt sich mit „invisible work“ in denen Arbeitsartefakte
an die tatsächlichen Erfordernisse des jeweiligen Arbeitskontext angepasst werden
(„design-for-use“). Sie argumentiert für die Anerkennung (also Sichtbarmachung)
dieser Arbeit durch die Entwicklung expliziter Design-Praktiken, geht aber nicht
näher auf deren Ausgestaltung ein.
Star und Strauss (1999) (III) verfassen die einzige Arbeit, in der Strauss selbst Stel-
lung zur Unterstützung von „Articulation Work“ im Generellen und der Unterstüt-
zung durch Computersysteme im Speziellen Stellung nimmt. Die Autoren würdi-
gen die Argumente und Forderungen aus (Schmidt und Simone, 1996) kritisch
und argumentieren gegen „Sichtbarkeit von Arbeit um jeden Preis“. „Articulati-
on Work“ bedingt nicht notwendigerweise die vollständige Offenlegung aller Ar-
beitsaspekte sondern geht immer nur soweit wie für eine Wiederaufnahme bzw.
Aufrechterhaltung der produktiven Arbeit notwendig. Als Konsequenz fordern sie
CSCW-Systeme, die – zusätzlich zu den von Schmidt und Simone (1996) formu-
lierten Anforderungen – die Kontrolle über die Sichtbarkeit der eigenen Arbeit bei
17Common Object Request Broker Architecture
482
A.2. Relevante Literatur
den arbeitenden Individuen belassen (und stärken damit die Anforderung, die be-
reits von Schmidt und Bannon (1992) aufgestellt wurde, von Schmidt und Simone
(1996) jedoch nicht explizit berücksichtigt wurde).
Berg und Timmermans (2000) (II) beschreiben „Articulation Work“ im Kontext von
„order and disorder“ in kooperativen Arbeitssituationen (konkret im medizinischen
Sektor). „Articulation Work“ ist dabei eine Ausprägung von „disordered work“,
im dem Sinne, dass sie nicht vorgegebenen Regeln gehorcht bzw. zur Anwendung
kommt, wenn spezifizierte, routinierte Arbeit („ordered work“) nicht mehr funk-
tioniert. Die Autoren gehen jedoch nicht auf eine mögliche Unterstützung von
„Articulation Work“ oder „ordered work“ ein.
Divitini und Simone (2000) (III) stellen ein System zur Unterstützung von etablierter
kooperativer Arbeit in Form eines adaptiven Workflow-Systems vor, dessen Ver-
halten durch die Durchführung von „Articulation Work“ beeinflusst werden kann
bzw. die Durchführung derselben unterstützt.
Schmidt und Simone (2000) (III) führen im Kontext von CSCW die bereits in (Schmidt
und Simone, 1996) entwickelten Konzepte nochmals weiter und zeigen, dass bei
„Articulation Work“ die Grenze zwischen der Herstellung von „mutual awareness“
(als Bezeichnung einer ad-hoc durchgeführten Abstimmung) und der Verwendung
„coordinative artifacts and protocols“ (als Ausprägung eine Koordination von eta-
blierten Arbeitsprozessen) fließend ist. Sie fordern als Folge, dass eine technische
Unterstützung beide Arten von „Articulation Work“ unterstützen muss, detaillie-
ren oder verändern aber die konkreten Anforderungen aus (Schmidt und Simone,
1996) nicht weiter.
Simone (2000) (II) beschreibt die Rolle von „classification schemes“ für CSCW, die
der Klassifikation von Domänenkonzepten zugrunde liegen. Anhand mehrerer Fall-
studien beschreibt die Autorin die lokale, informelle und emergente Bildung von
Klassifikations-Schemata in Gruppen. Sie argumentiert letztlich dafür, dass diese
Schema-Bildung Teil von „Articulation Work“ ist und unterstützt werden muss,
um eventuell auftretende Inkonsistenzen zwischen den Schemata einzelner Grup-
pen oder Individuen zu vermeiden. Letztlich beschreibt die Autorin, dass das in
(Simone et al., 1999) vorgestellte System diese Anforderung erfüllen kann.
Christensen (2001) (II) beschäftigt sich mit „Articulation Work“ in Arbeitssituatio-
nen, in die mobil arbeitende Individuen involviert sind und konzentriert sich auf
jene Arbeits-Aspekte, die spezifisch für derartige Situationen zusätzlich zu artiku-
lieren sind. Er identifiziert diese Aspekte im Rahmen einer Studie und beschreibt
ausschließlich den Status quo ohne konkrete Unterstützung-Maßnahmen anzufüh-
ren. Weiterführende Arbeiten zu diesem Ansatz sind nicht publiziert.
Fuchs et al. (2001) beschreiben die technische Unterstützung von „Articulation Work“
in (verteilten) Gruppen mittels CSCW-Technologie. Die Autoren präsentieren ein
483
A.2. Relevante Literatur
konkret umgesetztes System, das eine Reihe von Werkzeugen zur Unterstützung
von „Articulation Work“ bietet.
Raposo et al. (2001) (III) stellen ein konzeptuelles Framework vor, das die Koordina-
tion von voneinander abhängigen Aufgaben in Gruppen erlauben soll und damit
„Articulation Work“ mit dem Ziel „coordination of predefined work“ unterstüt-
zen soll. Dabei schlagen die Autoren eine Struktur vor, die es erlaubt, für eine
Abhängigkeit zwischen Aufgaben unterschiedliche Koordinationsstrategien festzu-
legen, die dann kontextabhängig ausgewählt werden können. Das Framework wird
in (Raposo und Hugo, 2002) weiter konkretisiert und dessen Umsetzung in einem
technischen System beschrieben.
Simone und Sarini (2001) (II, III) entwickeln die Ansätze hinsichtlich der Unterstüt-
zung der Bildung von „classification schemes“ aus (Simone, 2000) weiter und kon-
zentrieren sich dabei auf deren Adaptierung an konkrete Arbeitssituationen. Sie
führen dabei aber keine neuen Aspeke hinsichtlich der Unterstützung von „Arti-
culation Work“ ein.
Bossen (2002) (II) baut auf der Arbeit von (Bannon und Bødker, 1997) zu „Com-
mon Information Spaces“ auf und identifiziert im Rahmen einer Fallstudie im
medizinischen Bereich Gestaltungsparameter, in deren Rahmen auch „Articulati-
on Work“ als in unterschiedlichen Ausprägungen zu unterstützendes Phänomen
genannt wird, ohne näher auf die Implikationen dieser Forderung einzugehen.
Davenport (2002) (II, III) beschreibt „Articulation Work“ als eine Form von „alltägli-
chem Wissensmanagment“, mit Hilfe dessen beteiligte Individuen im Arbeitspro-
zess lernen und ihre Kompetenzen erweitern („situated learning“). Anhand einer
Fallstudie zeigt sie, dass das Konzept der „Communities of Practice“ (Wenger,
1998) und deren Methoden geeignet sind, diese Form von „Articulation Work“
zu unterstützen. Die Autorin deutet die Möglichkeit einer Unterstützung durch
rechnerbasierte Werkzeuge an, führt diese Idee aber nur am Rande aus.
Herrmann et al. (2002) (II, III) beschäftigen sich mit Modellen von soziotechnischen
Arbeitsprozessen und zeigen auf, dass zu deren (kooperativen Erstellung) „Articu-
lation Work“ notwendig ist.
Mark et al. (2002b) (II) stellen eine Kurzfassung des in (Mark et al., 2002a) ausführ-
lich beschriebenen Tests des „Reconciler“-Systems vor.
Mark et al. (2002a) (II) beschreiben einen ersten Test des „Reconciler“-Systems und
zeigen, dass das Werkzeug tatsächlich bei der Entwicklung eines gemeinsamen
Sichtweise über die Arbeitsdomäne betragen kann.
Raposo und Hugo (2002) beschäftigen sich aufbauend auf (Raposo et al., 2001) mit
der Konkretisierung des Frameworks zur Unterstützung der Koordination von Auf-
gaben, die in gegenseitiger Abhängigkeit stehen. Die Autoren bereiten damit das
484
A.2. Relevante Literatur
Feld für die technische Umsetzung des Frameworks, die in (Raposo et al., 2004)
beschrieben wird.
Sarini und Simone (2002a) (III) beschäftigen sich mit „recursive Articulation Work“,
also jener Form, deren Gegenstand selbst wiederum „Articulation Work“ ist. Die
Autoren leiten Anforderungen an die Unterstützung dieser Form von „Articulation
Work“ ab und zeigen die konkrete Umsetzung als Teil des „Reconciler“-Systems.
Sarini und Simone (2002b) beschreiben in Form einer Kurzfassung die wesentlichen
Konzepte und Implementierungsansätze des „Reconciler“-Systems.
Schmidt (2002) (IV) beschäftigt sich konzeptuell mit der Unterstützung von Awareness
in CSCW-Systemen und erwähnt dabei am Rande, dass Awareness oft ein wichtiger
Aspekt von „Articulation Work“ ist.
Simone (2002) (IV) beschreibt die im Rahmen des „Reconciler“-Projektes durchge-
führte Arbeit im Kontext von Wissensmanagement und „Organizational Memo-
ries“18. Sie zeigt, in welchen Aspekten Berührungspunkte zwischen Wissensma-
nagment und CSCW bestehen und weist auf mögliche Unterstützungsleistungen
hin. Auf „Articulation Work“ wird nur im Zusammenhang mit dem im Wissens-
management relevanten Abgleich von Ontologien verwiesen, der als „Articulation
Work“ gesehen werden kann.
Eschenfelder (2003) (II) beschreibt eine qualitative Studie über das Management von
content-zentrierten Websites und zieht „Articulation Work“ (in Bezugnahme auf
das von Corbin und Strauss (1993) beschriebene Verständnis) als das der Analyse
zugrundeliegende Framework heran. Die Autorin zeigt im zweiten Teil der Arbeit
auf, wie Content Management Systeme den Verwaltungsprozess unterstützen kön-
nen, geht aber nicht weiter auf „Articulation Work“ ein.
Olesen und Markussen (2003) (IV) beschreiben die Veränderung des Arbeitsablaufs
der Rezeptausstellung in einem Krankenhaus durch Einführung eines technischen
Systems, das die elektronische Verschreibung von Medikamenten erlaubt. Die Au-
toren verfolgen dabei einen kulturwissenschaftlichen Ansatz und weisen lediglich
in der Einleitung auf „Articulation Work“ als eine bei der Umstellung des Arbeits-
ablaufs notwendige Tätigkeit hin.
Sarini (2003) (III) fasst die konzeptuellen Grundlagen, die Implementierung und den
Test des „Reconciler“-Systems in Form seiner Dissertation zusammen. Er führt
dabei jedoch keine nicht bereits in früheren Publikationen veröffentlichten Argu-
mente oder Anforderungen ein.
Gerson (2004) (III) beschreibt die Verwendung von „Reconciliation Mechanisms“ zur
Auflösung von Problemen in der Zusammenarbeit bei räumlich verteilt durchge-
führter Arbeit. Diese „Reconciliation Mechanisms“ sind vorrangig organisationale
oder soziale Maßnahmen, die die Zusammenarbeit verbessern bzw. wieder möglich
18für einen Überblick zu diesem Themengebiet siehe (Maier, 2008)
485
A.2. Relevante Literatur
machen. Ein expliziter Bezug zu „Articulation Work“ wird nicht hergestellt, aus-
gehend von der Beschreibung sind „Reconciliation Mechanisms“ aber ein Mittel
zur Durchführung von „Articulation Work“. Gerson gibt exemplarisch vier dieser
Mechanismen an (z.B. „shared ressource pools“ oder „participant review“), ohne
jedoch deren detaillierte Ausgestaltung einzugehen.
Jørgensen (2004) (III) beschreibt die Verwendung von „interaktiven“ Prozessmodellen
in organisationalen Arbeitsprozessen und die Veränderung dieser Prozesse durch
Modellierungsvorgänge. Dabei bezeichnet er den Modellierungsvorgang als „Arti-
culation Work“. „Interaktive“ Prozesse sind dabei solche, die wissensintensiv sind,
im Vorhinein spezifiziert werden können und deren konkreter Ablauf erst zum Zeit-
punkt der Ausführung festgelegt wird (was jenen Arbeitsabläufen entspricht, die
als „problematic“ oder „non-routine“ bezeichnet werden). Der Autor entwickelt
im Rahmen der Arbeit eine Methodik zur Modellierung derartiger Prozesse und
ein technisches Werkzeug, dass die Erstellung und Instanzierung dieser Modelle
unterstützt bzw. ermöglicht.
Raposo et al. (2004) decken in ihrer Arbeit zur (technischen) Unterstützung koope-
rativer Arbeit explizit alle Zeitpunkte ab, in denen „Articulation Work“ auftre-
ten kann („pre-articulation“, „coordination“, „post-articulation“). Sie schlagen zur
Koordination formalisiert festgeschriebene „Commitments“ vor, die in der „pre-
articulation“-Phase definiert werden und während der „post-articulation“ evalu-
iert werden. Damit decken die Autoren auch „recursive Articulation Work“ (Sarini
und Simone, 2002a) ab. In der Arbeit wird im wesentlichen der vorgeschlagene
Formalismus und dessen konzeptuelle Anwendung dargestellt.
Færgemann et al. (2005) (I, II) beschreiben „Articulation Work“ in Arbeitsprozessen,
die unterschiedlich große Personenkreise umfassen, die verschieden stark mitein-
ander vertraut sind. Die Autoren leiten auf ihren empirischen Beobachtungen vier
unterschiedliche Arten von „Articulation Work“ ab, die sich jeweils in der Größe
ihres Durchführungskontexts (d.h. des Teilnehmerkreises) unterscheiden. Sie be-
schreiben die Charakteristika dieser Arten von „Articulation Work“, gehen aber
nicht auf deren Unterstützung ein (wobei sie andeuten, dass eine technische Un-
terstützung jeweils unterschiedlich ausfallen muss, bezeichnen dies jedoch als eine
offene Forschungsfrage).
Hasu (2005) (II, IV) beschreibt die Einbindung neuer (computer-basierter) Werkzeuge
in Arbeitsabläufe durch technische Laien (konkret die Verwendung eines neuen,
komplexen medizinischen Gerätes durch Neurologen). Sie klassifiziert die im Zuge
dessen anfallenden Aktivitäten als „invisible Articulation Work“. Sie geht im Üb-
rigen darauf ein, wie derartige Prozesse durch ethnogaphische Forschung erfasst
werden können, die Unterstützung von „Articulation Work“ selbst wird aber nicht
weiter thematisiert.
486
A.2. Relevante Literatur
Hampson und Junor (2005) (II) beschreiben die Arbeit im interaktiven (d.h. hier te-
lemediengestützten) Kundenservice als „Articulation Work“. Die Autoren führen
eine Klassifikation von unterschiedlichen Arten von Arbeitsabläufen ein, um ihren
Fokus abzugrenzen. In der Folge beschreiben sie die im Rahmen des „interactive
customer service“ auftretende Phänomene, deren konkrete Ausprägunen und die
Reaktionen der Kundenbetreuer. Sie legen dar, welche Rolle „Articulation Work“
in diesem Kontext spielt, gehen dabei aber nicht darauf ein, wie diese Abläufe
unterstützt werden können.
Cabitza et al. (2006) (III) entwickeln den „Reconciler“-Ansatz weiter und wenden ihn
unter Bezugnahme auf Færgemann et al. (2005) auf „globale Articulation Work“
an. Sie entwickeln dabei ein konzeptuelles Framework, das (wie im Falle des „Reconciler“-
Ansatzes) auf Artefakten als Artikulations-Objekten beruht und geben eine Me-
thodik an, wie derartige Artefakte entwickelt werden können (im Sinne der „recur-
sive Articulation Work“). Die vollständige Umsetzung sowie eine Evaluierung des
Konzepts stand zum Zeitpunkt der Publikation der Arbeit noch aus.
Crabtree et al. (2006) (II, III) zeigen die Relevanz von „Articulation Work“ in Situa-
tionen, in denen Personen einander Hilfestellungen geben. Die Autoren beschreiben
dabei Situationen, in denen die Hilfestellung „remote“ (d.h. aus der Entfernung)
erfolgt. Sie zeigen, welche Artikulationsprozesse dabei regelmäßig auftreten und
leiten Anforderungen an eine mögliche Unterstützung für derartige Arbeitspro-
zesse ab. Obwohl grundsätzlich relevant für die Unterstützung von „Articulation
Work“, bleibt diese Arbeit hinsichtlich der Anforderungen jedoch relativ abstrakt
und unspezifisch.
Kaghan und Lounsbury (2006) (II, III) (bzw. der ebenfalls vorliegende ausführliche-
re Preprint (Kaghan und Lounsbury, 2004)) zeigen mit kulturwissenschaftlichem
Hintergrund, wie organisationale Artefakte (also Ergebnisse bzw. Gegenstände von
Arbeit) kooperativ erstellt, verwendet und angepasst werden und in der Folge die
mit ihnen verbundene Arbeit widerspiegeln. Die Autoren bedienen sich dabei einer
Fallstudie aus dem Bereich des Technologietransfers zwischen Universitäten und
Wirtschaft, wo Verträge als Artefakte bzw. die Vertragsverhandlung als relevanter
Arbeitsablauf im Detail betrachtet werden. „Articulation Work“ kommt dabei im
Rahmen der Vertragsanbahnung („arranging deals“) zum Einsatz. Allgemein hat
„Articulation Work“ hier das Ziel, ein erreichtes gemeinsames Verständnis so in
einem Artefakt abzubilden, dass dieses von den Beteiligten als Repräsentant der
vereinbarten Zusammenarbeit akzeptiert wird. Die Autoren nehmen wie Daven-
port (2002) Bezug auf „Communities of Practice“ als wesentliches Konzept bei der
Entwicklung dieser Artefakte.
Baker und Millerand (2007) (I, II) beschreiben, wie „Articulation Work“ im Rahmen
des Designs von „information infrastructure“ (als Bezeichnung von Systemen, die
Verwaltung und strukturierte Manipulation von Information erlauben) zur An-
487
A.2. Relevante Literatur
wendung kommt. Die Autoren beziehen sich auf eine von ihnen durchgeführte em-
pirische Studie und fassen aufgrund ihrer Erkenntnisse den Begriff „Articulation
Work“ so breit, dass er nicht nur die Abstimmung der eigentlichen Arbeitsabläu-
fe umfasst, sondern etwa auch die Aushandlung eines gemeinsamen Verständnisse
über den Aufbau der Arbeitsdomäne.
Cabitza und Sarini (2007) (IV) beschreiben die Verwendung von „dokumentatischen
Artefakten“ und deren Computer-Unterstützung im medizinischen Bereich. Die
Autoren gehen dabei nur in einem Nebensatz explizit auf „Articulation Work“
ein, die Arbeit dient aber gemeinsam mit Cabitza et al. (2006) als Grundlage
der weiteren Entwicklungen zur Unterstützung von „Articulation Work“, die in
(Cabitza und Simone, 2009a) beschrieben wird.
Convertino et al. (2008) (IV) beschreiben, wie in kooperativen Arbeitsprozessen ein
gemeinsames Verständnis der Arbeitsdomäne („common ground“) entwickelt wer-
den kann und in weiterer Folge eine einfachere Zusammenarbeit zwischen den
beteiligten Individuen ermöglicht. Die Autoren beziehen sich aber nur im Rahmen
der in der Arbeit beschriebenen empirischen Studie am Rande auf „Articulation
Work“.
Larsen und Bardram (2008) (II) beschreiben, wie in kooperativen Arbeitsprozessen
Information über die Kompetenzen und Verantwortlichkeiten der beteiligten In-
dividuen ausgetauscht wird. Aus der vorgestellten empirischen Studie leiten die
Autoren ab, dass – trotz fortgeschrittener technischer Möglichkeiten – die Ab-
stimmung von Kompetenzen und Verantwortlichkeiten in kooperativer Arbeit in
synchronen Anwendungsszenarien zu einem besseren Ergebnis führt als in asyn-
chronen Settings.
Cabitza et al. (2008) (IV) betrachtet die Ausführungen aus Cabitza und Sarini (2007)
aus Perspektive des Wissensmanagement und bildet damit ebenso die Grundlage
für die in (Cabitza und Simone, 2009a) vorgestellte technische Lösung vor. „Arti-
culation Work“ als Konzept wird hier nicht explizit angesprochen.
Cabitza und Simone (2009a) (III) schlagen „active artifacts“ als Mittel zur Unter-
stützung von „Articulation Work“ zwischen „Communities“ im Arbeitsablauf (im
Sinne von „coordinating predefined work“) vor. „Active artifacts“ können dabei
nicht nur Information tragen, sondern auch auf ihren aktuellen Kontext reagie-
ren und selbständig aktiv Information vermitteln. Dabei führen die Autoren auch
ein Konzept an, wie das Verhalten derartiger „active artifacts“ spezifiziert werden
können. Hinsichtlich der Unterstützung von „Articulation Work“ ist die Arbeit
als technische Detaillierung und Verfeinerung der in Cabitza et al. (2006) bereits
vorgestellten Konzepte zu sehen.
Cabitza und Simone (2009b) (III) stellen die in Cabitza et al. (2006) vorgeschlagene
und in (Cabitza und Simone, 2009a) eingesetzte Sprache zur Spezifikation von
Koordinations-Artefakten in „global Articulation Work“ im Detail vor. Diese ba-
488
A.2. Relevante Literatur
siert im Wesentlichen auf der Formulierung von ECA-Regeln, die im operativen
Betrieb die Grundlage der Koordinations-Unterstützung bilden.
Cabitza et al. (2009) (II) stellen eine empirische Studie zur Motivation des in (Cabitza
und Simone, 2009a) vorgestellten Systems vor und zeigen dessen unterstützende
Wirkung bei der Durchführung von „Articulation Work“.
Betrachtet man diese Arbeiten in ihrer Gesamtheit, so zeigt sich die historische Ent-
wicklung der Forschung zum Thema „Articulation Work“ oder unter Verwendung der-
selben. Vor allem wird ein starker Bezug zur Konzeption von CSCW-Systemen sichtbar,
in deren Kontext ein Großteil der verfügbaren Arbeiten verfasst wurden. Zudem sind
auch Gruppen von Publikationen zu erkennen, die im gleichen Kontext publiziert wur-
den und sich nur in Einzelaspekten unterscheiden. Abbildung A.1 auf Seite 490 zeigt
diese Zusammenhänge.
Beginnend mit den Arbeiten von Strauss in der linken oberen Ecke ist vertikal die
zeitliche Dimension der Publikation von Arbeiten zu Artikulation Work aufgetragen.
Die Seitenbreite wird zur thematischen Gruppierung der Publikationen verwendet. Die
Pfeile zwischen Publikationen bzw. Publikationsgruppen stellen einen inhaltlichen Bezug
dar. Die Publikationen am Endpunkt des Pfeils nehmen dabei Bezug auf jene, die sich
am Ausgangspunkt des Pfeils befinden.
Am linken Rand der Darstellung sind die Arbeiten zu finden, die im soziologischen
Kontext verfasst wurden. Die meisten der dort angesiedelten Publikationen sind Grund-
lagenarbeiten, die den Begriff „Articulation Work“ und dessen konzeptuellen Kontext
erörtern oder anhand von Fallstudien das Auftreten von „Articulation Work“ zeigen.
Im Zentrum der Darstellung steht die größte Gruppe von Arbeiten, die im Kontext
von CSCW verfasst wurde. Die Arbeiten, die sich auf CSCW beziehen, haben dabei zum
Teil die Ableitung für Anforderungen an eine technische Unterstützung von „Articula-
tion Work“ zum Ziel, der Rest der Arbeiten beschäftigt sich eher mit der technischen
Umsetzung der Unterstützung. Jene Publikationen, die eher ersterer Gruppe zuzuord-
nen sind, sind eher links angeordnet, die technisch orientierten Publikationen befinden
sich eher rechts. Die Entfernung zur Mittelachse hat dabei keine Aussagekraft, sondern
ist nur einer übersichtlichen Anordnung geschuldet.
Innerhalb der CSCW-Gruppe gibt es zwei bedeutende Sub-Gruppen, die untereinan-
der in Beziehung stehen. Einerseits ist die Gruppe von Publikationen zu nennen, die im
Rahmen des COMIC-Projektes 1992-1995 entstanden sind (Rodden, 1995). In diesem
Projekt wurde die Grundlage der Berücksichtigung von „Articulation Work“ als The-
ma von CSCW gelegt. Bereits im Rahmen des COMIC-Projektes beginnend, publiziert
die Gruppe um Simone Arbeiten zur konkreten technischen Umsetzung der Unterstüt-
zung durch computerbasierte Werkzeuge. Die Implementierungen, auf die dabei immer
wieder Bezug genommen wird, werden als „Ariadne“ (für den Koordinierungsaspekt von
489
A.2. Relevante Literatur
Abbildung A.1.: Literatur zu Articulation Work im Kontext
490
A.2. Relevante Literatur
„Articulation Work“) „Reconciler“ (für den Awareness-Aspekt von „Articulation Work“)
bezeichnet, was auch als Namensgeber dieser Gruppe von Arbeiten herangezogen wurde.
Weiter rechts am oberen Rand der Abbildung befinden sich Arbeiten, die „Articulation
Work“ im Kontext der Software-Entwicklung betrachten. Dies sind die ersten Arbeiten,
die eine konkrete Anwendung der Konzepte um „Articulation Work“ außerhalb der So-
ziologie bzw. der Community um Strauss zeigen. Die Unterstützung von „Articulation
Work“ ist hier nur teilweise Gegenstand der Betrachtung, wo sie aber angesprochen wird,
ist sie entsprechend der Anwendungsdomäne eher technisch orientiert.
Ganz rechts sind jene Arbeiten zu finden, die auf „Articulation Work“ Bezug neh-
men, jedoch nicht einer der bisher beschriebenen Gruppen zuzuordnen sind. Hier fin-
den sich Publikationen, die vor philosophischem, organsationswissenschaftlichem Hin-
tergrund oder mit Bezug zum Wissensmanagement verfasst wurden. Herauszugreifen ist
hier die Arbeit von Jørgensen (2004), der die Rolle von Modellen (konkret konzeptuellen
Modellen von Arbeit) bei der Durchführung von „Articulation Work“ betrachtet und da-
mit erstmals einen konkreten Unterstützungsbezug zwischen „Artikulation Work“ und
der Domäne der Organisationswissenschaften herstellt (was wiederum für die Betrach-
tung von „Articulation Work“ im organisationalen Kontext von Interesse ist).
Insgesamt ist in der Abbildung ein starker Schwerpunkt auf die technische Unterstüt-
zung von Arbeit, konkret „Articulation Work“, zu erkennen. Dieser Schwerpunkt wurde
sowohl konzeptuell als auch technisch ab Beginn der 90er-Jahre des 20. Jahrhunderts
bis etwa 2005 ausführlich bearbeitet. In den letzten Jahren treten verstärkt Fallstudien
auf, die einen Bezug zu „Articulation Work“ herstellen, jedoch nur bedingt auf deren
Unterstützung eingehen.
491
B. Daten der empirischen
Untersuchung
Die Darstellung der erhobenen Rohdaten der empirischen Untersuchung und deren de-
taillierte Auswertung würden an dieser Stelle den Rahmen der Arbeit sprengen. Durch
die große Anzahl an Videoaufnahmen, die insgesamt etwa 23 GB1 an Speicherplatz ein-
nehmen, ist auch die Beilage eines Datenträgers nicht möglich.
Die Rohdaten, die durchgeführten Auswertungen und Transkripte sowie die Skripte
der statistischen Tests mit der Software R können via eMail unter
stefan@oppl.info
angefordert werden.
B.1. Verfügbare Rohdaten
Zu den Untersuchungen stehen im Einzelnen folgende Rohdaten zur Verfügung:
• Evaluierungsblock 1 (siehe auch (Bohninger, 2010))
– Videoaufnahmen der Modellbildung (Detailansicht der Modellierungsoberflä-
che)
– Fotos der finalen Versionen der erstellten Modelle
– Fragebögen der Befragungen der modellierenden Teilnehmer
– Fragebögen der Befragungen der interpretierenden Teilnehmer
– Fragebögen zur Korrektheit der Interpretation
• Evaluierungsblock 2
– Videoaufnahmen der Modellbildung (Detailansicht der Modellierungsoberflä-
che inkl. Personen)
– Fotos bzw. graphische Abbildungen der finalen Versionen der erstellten Mo-
delle
1Gigabyte
492
B.2. Durchgeführte Auswertungen
– Tagebücher über den Erstellungsprozess der Seminararbeit (= „Production
Work“) aller Teilnehmer
– Seminararbeiten (= Ergebnis der „Production Work“) bei Einsatz des hier
vorgestelltenWerkzeugs und aus Lehrveranstaltungen mit identischer Aufgaben-
und Themenstellung ohne Einsatz von unterstützenden Maßnahmen bei der
Durchführung von „Articulation Work“
• Evaluierungsblock 3
– Videoaufnahmen der Modellbildung aus jeweils 2 Perspektiven (Gesamtüber-
sicht inkl. Personen sowie Detailansicht der Modellierungsoberfläche)
– Graphische Abbildungen der finalen Versionen der erstellten Modelle
• Evaluierungsblock 4 (siehe auch (Wahlmüller, 2010))
– Videoaufnahmen der Modellbildung können aus Gründen der Schutzes unter-
nehmensinterner Information auf diesem Wege nicht weitergegeben werden.
Etwaige Anfragen sind an Patrick Wahlmüller (Kontaktdaten in (Wahlmüller,
2010)) zu richten.
– Graphische Abbildungen der finalen Versionen der erstellten Modelle
– Fragebögen zur Arbeit mit dem Werkzeug
– Fragebögen zu den Auswirkungen der Durchführung von „Articulation Work“
• Evaluierungsblock 5 (siehe auch (Bindreiter, 2010))
– Videoaufnahmen der Modellbildung mittels CMapTools und am Modellie-
rungstisch aus jeweils 2 Perspektiven (Gesamtübersicht inkl. Personen sowie
Detailansicht der Modellierungsoberfläche)
– Graphische Abbildungen der finalen Versionen der erstellten Modelle
– Als XML exportierte Repräsentationen der mit CMapTools erstellten Modelle
(inkl. Modellierungshistorie)
– Fragebögen zur Arbeit mit dem Werkzeug
B.2. Durchgeführte Auswertungen
Zu den Untersuchungen wurden folgende Auswertungen durchgeführt und archiviert.
Die einzelnen Auswertungsmethoden sind auf den folgenden Seiten näher beschrieben.
• Evaluierungsblock 1 (siehe auch (Bohninger, 2010))
– Überblicksauswertung aller Anwendungen und Modelle
– Deskriptive Parameter aller quantitativ erhobenen Merkmale
• Evaluierungsblock 2
493
B.2. Durchgeführte Auswertungen
– Überblicksauswertung aller Anwendungen und Modelle
– Interaktionsanalyse aller Anwendungen
– Deskriptive Parameter aller quantitativ erhobenen Merkmale
– Signifikanztests der zur Hypothesenprüfung verwendeten Merkmale
• Evaluierungsblock 3
– Überblicksauswertung aller Anwendungen und Modelle
– Interaktionsanalyse aller Anwendungen
– Deskriptive Parameter aller quantitativ erhobenen Merkmale
– Signifikanztests der zur Hypothesenprüfung verwendeten Merkmale
• Evaluierungsblock 4 (siehe auch (Wahlmüller, 2010))
– Überblicksauswertung aller Anwendungen und Modelle
– Interaktionsanalyse aller Anwendungen
– Deskriptive Parameter aller quantitativ erhobenen Merkmale
– Deskriptive Parameter der Items der Benutzerbefragung
– Signifikanztests der zur Hypothesenprüfung verwendeten Merkmale und Be-
fragungsitems
– Codierung der zur Hypothesenprüfung verwendeten offenen Items der Benut-
zerbefragung
• Evaluierungsblock 5 (siehe auch (Bindreiter, 2010))
– Überblicksauswertung aller Anwendungen und Modelle
– Interaktionsanalyse aller Anwendungen
– Deskriptive Parameter aller quantitativ erhobenen Merkmale
– Deskriptive Parameter der Items der Benutzerbefragung
– Signifikanztests der zur Hypothesenprüfung verwendeten Merkmale und Be-
fragungsitems
– Codierung der zur Hypothesenprüfung verwendeten offenen Items der Benut-
zerbefragung
B.2.1. Überblicksauswertung
Die Überblicksauswertung fasst die wesentlichen Eigenschaften des in einer Anwendung
erstellten Modells sowie die während der Erstellung aufgetretenen Ereignisse zusam-
men. Die Daten wurden in Form einer Openoffice-Tabelle aufbereitet und stehen als
494
B.2. Durchgeführte Auswertungen
ODF2-Dateien zur Verfügung. Sie dienen als Grundlage aller weiteren deskriptiven und
schließenden statistischen Auswertungen.
Die konkrete Ausgestaltung der Tabelle variiert je nach Evaluierungsblock (abhängig
von der durchgeführten Modellierungsaufgabe und der im Werkzeug implementierten
Funktionalität) leicht, in Abbildung B.1 ist der Raster aus Evaluierungsblock 5 darge-
stellt, in dem die höchste Anzahl von Merkmalen erhoben wurden.
Die Befüllung der Raster erfolgte auf Basis der angefertigten Video-Aufnahmen der
Werkzeuganwendungen. In den Blöcken 3 und 5 wurden die Raster redundant unabhän-
gig voneinander von jeweils zwei Personen befüllt. Sofern Abweichungen bei der Aus-
wertung der quantitativen Parameter festgestellt wurden, wurde das jeweilige Merkmal
durch eine dritte Person geprüft und ggf. entsprechend korrigiert. In den Blöcken 1, 2
und 4 standen nicht ausreichend personelle Ressourcen für eine redundante Auswertung
zur Verfügung.
B.2.2. Interaktionsanalyse
Die Interaktionsanalyse wurde wie in Abschnitt 11.3.5 beschrieben durchgeführt und
dokumentiert. Die Dokumentation erfolgte in Textdokumenten, die als ODF-Dateien
zur Verfügung stehen.
In den Evaluierungsblöcken 3 und 5 wurde die Interaktionsanalyse für jede Werkzeug-
anwendung von zwei Personen redundant durchgeführt. In den Blöcken 2 und 4 standen
die personellen Ressourcen für eine redundante Auswertung nicht zur Verfügung. In den
Fällen, in denen redundant ausgewertet wurde, wurden Transkripte, die nur von einer
der auswertenden Personen als relevant identifiziert wurden, von einer dritten Person
geprüft und bestätigt bzw. verworfen.
B.2.3. Deskriptive Parameter
Zur deskriptiven Beschreibung der erhobenen metrischen und ordinalen Merkmale in
der Modellbildung und bei der Benutzerbefragung wurden im Wesentlichen folgende
Parameter herangezogen:
• Stichprobengröße
• Mittelwert
• Standardabweichung
• Boxplot, dieser codiert:
– 2.5%-Quantil
2Open Document Format
495
B.2. Durchgeführte Auswertungen

 	







	





 
			



































 
 !

"



#
$#





!%
&#'

(
)*

$+
)*

$+
	




,-

,-

,-
.

/

0
"

1
2


1
2


1
2



1



'
2
"
-




3



4
3
5








3


#


*
*




6


1

$
#7


2




6


1

8+

2

*




,

8	

















"'



9



-










"'







	
:%








"#






(





"#




,


7

#




/
*


##'





#
"









48
#3





;

)*
<

$"


"'


,




*






*
*'




=





;
#


#



$+







*

*







#









*
*







#
Abbildung B.1.: Raster der Überblicksauswertung
496
B.3. Verwendete Fragebögen
– 25%-Quantil
– Median
– 75%-Quantil
– 97.5%-Quantil
– Ausreißer (Werte unterhalb des 2.5% und oberhalb des 97.5%-Quantils)
Diese Parameter wurden für die Merkmale aller fünf Evaluierungsblöcke berechnet.
Teilweise wurden einzelne Merkmale zueinander in Beziehung gesetzt, um eine Nor-
mierung bzw. Vergleichbarkeit der Werte über Anwendungen bzw. Evaluierungsblöcke
hinweg gewährleisten zu können.
B.2.4. Signifikanztests
Signifikanztests wurden lediglich für jene Merkmale durchgeführt, die zur Hypothesen-
prüfung verwendet wurden. Da die Untersuchungen teilweise Bestandteil von für sich
genommen umfangreicher angelegter Untersuchungen im Rahmen von Masterarbeiten
waren, sind nicht aller erhobenen Merkmale (vor allem in der Benutzerbefragung) für
diese Arbeit von Relevanz. Auswahlkriterien für Signifikanztests und Anmerkungen zu
deren Durchführung wurden in Abschnitt 11.3.2 angegeben. Signifikanztests wurden in
den Evaluierungsblöcken 2 bis 5 durchgeführt.
B.2.5. Codierung offener Items
Bei der Auswertung der für die Hypothesenprüfung relevanten offenen Items in der Be-
nutzerbefragung der Evaluierungsblöcke 4 und 5 wurde jeweils ein Codierungsschema
entwickelt, um inhaltlich identische Antworten zusammenzufassen. Dies wurde wieder-
um nicht für alle in den Fragebögen angeführten offenen Items durchgeführt, die diese
teilweise Bestandteil von für sich genommen umfangreicher angelegter Untersuchungen
im Rahmen von Masterarbeiten waren.
B.3. Verwendete Fragebögen
Bei der Durchführung der Evaluierungsblöcke 1, 4 und 5 wurden zusätzlich zu den direkt
aus der Modellbildung erhobenen Daten auch Benutzerbefragungen mittels Fragebögen
durchgeführt. Im Folgenden sind für jeden Evaluierungsblock die verwendeten Frage-
bögen angeführt. Zusätzlich werden die Fragebögen hinsichtlich ihrer Relevanz für die
untersuchten Hypothesen (siehe Kapitel 12 bis 14) eingeordnet. Die Auswertungen der
ausgefüllten Fragebögen sind detailliert (siehe Abschnitt B.1) bzw. aggregiert (siehe Ab-
schnitt B.2) in digitaler Form verfügbar.
497
B.3. Verwendete Fragebögen
B.3.1. Fragebögen aus Evaluierungsblock 1
Die Abbildungen B.2 bis B.4 zeigen den in Evaluierungsblock 1 verwendeten Fragebogen
für die Modellierenden. Die Abbildungen B.5 bis B.6 zeigen den in Evaluierungsblock 1
verwendeten Fragebogen für die interpretierenden Teilnehmer. Abbildung B.7 zeigt den
Fragebogen bezüglich der Korrektheit der Interpretation, der durch die Modellierenden
ausgefüllt wurde. Abbildung B.8 zeigt den Fragebogen zur Erhebung der Modellierungs-
vorkenntnisse. Dieser Fragebogen wurde von allen Teilnehmern ausgefüllt. Der Aufbau
der Fragebögen wurde von Bohninger (2010) detailliert beschrieben und begründet.
498
B.3. Verwendete Fragebögen
Abbildung B.2.: Erster Fragebogen für Modellierer in Evaluierungsblock 1 - Seite 1
499
B.3. Verwendete Fragebögen
Abbildung B.3.: Erster Fragebogen für Modellierer in Evaluierungsblock 1 - Seite 2
500
B.3. Verwendete Fragebögen
Abbildung B.4.: Erster Fragebogen für Modellierer in Evaluierungsblock 1 - Seite 3
501
B.3. Verwendete Fragebögen
Abbildung B.5.: Fragebogen für Interpretierer in Evaluierungsblock 1 - Seite 1
502
B.3. Verwendete Fragebögen
Abbildung B.6.: Fragebogen für Interpretierer in Evaluierungsblock 1 - Seite 2
503
B.3. Verwendete Fragebögen
Abbildung B.7.: Fragebogen bezüglich der Korrektheit der Interpretation in Evaluie-
rungsblock 1
504
B.3. Verwendete Fragebögen
Abbildung B.8.: Fragebogen bezüglich Modellierungsvorkenntnissen in Evaluierungs-
block 1
505
B.3. Verwendete Fragebögen
B.3.2. Fragebögen aus Evaluierungsblock 4
Die Abbildungen B.9 bis B.16 zeigen den ersten in Evaluierungsblock 4 verwendeten
Fragebogen. Die Abbildungen B.17 bis B.24 zeigen den zweiten in Evaluierungsblock
4 verwendeten Fragebogen. Der Aufbau der Fragebögen wurde von Wahlmüller (2010)
detailliert beschrieben und begründet.
506
B.3. Verwendete Fragebögen
Abbildung B.9.: Erster Fragebogen für Evaluierungsblock 4 - Seite 1
507
B.3. Verwendete Fragebögen
Abbildung B.10.: Erster Fragebogen für Evaluierungsblock 4 - Seite 2
508
B.3. Verwendete Fragebögen
Abbildung B.11.: Erster Fragebogen für Evaluierungsblock 4 - Seite 3
509
B.3. Verwendete Fragebögen
Abbildung B.12.: Erster Fragebogen für Evaluierungsblock 4 - Seite 4
510
B.3. Verwendete Fragebögen
Abbildung B.13.: Erster Fragebogen für Evaluierungsblock 4 - Seite 5
511
B.3. Verwendete Fragebögen
Abbildung B.14.: Erster Fragebogen für Evaluierungsblock 4 - Seite 6
512
B.3. Verwendete Fragebögen
Abbildung B.15.: Erster Fragebogen für Evaluierungsblock 4 - Seite 7
513
B.3. Verwendete Fragebögen
Abbildung B.16.: Erster Fragebogen für Evaluierungsblock 4 - Seite 8
514
B.3. Verwendete Fragebögen
Abbildung B.17.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 1
515
B.3. Verwendete Fragebögen
Abbildung B.18.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 2
516
B.3. Verwendete Fragebögen
Abbildung B.19.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 3
517
B.3. Verwendete Fragebögen
Abbildung B.20.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 4
518
B.3. Verwendete Fragebögen
Abbildung B.21.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 5
519
B.3. Verwendete Fragebögen
Abbildung B.22.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 6
520
B.3. Verwendete Fragebögen
Abbildung B.23.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 7
521
B.3. Verwendete Fragebögen
Abbildung B.24.: Zweiter Fragebogen für Evaluierungsblock 4 - Seite 8
522
B.3. Verwendete Fragebögen
B.3.3. Fragebögen aus Evaluierungsblock 5
Die Abbildungen B.25 bis B.31 zeigen den in Evaluierungsblock 5 verwendeten Frage-
bogen. Der Aufbau des Fragebogens wurde von Bindreiter (2010) detailliert beschrieben
und begründet.
523
B.3. Verwendete Fragebögen
Abbildung B.25.: Fragebogen für Evaluierungsblock 5 - Seite 1
524
B.3. Verwendete Fragebögen
Abbildung B.26.: Fragebogen für Evaluierungsblock 5 - Seite 2
525
B.3. Verwendete Fragebögen
Abbildung B.27.: Fragebogen für Evaluierungsblock 5 - Seite 3
526
B.3. Verwendete Fragebögen
Abbildung B.28.: Fragebogen für Evaluierungsblock 5 - Seite 4
527
B.3. Verwendete Fragebögen
Abbildung B.29.: Fragebogen für Evaluierungsblock 5 - Seite 5
528
B.3. Verwendete Fragebögen
Abbildung B.30.: Fragebogen für Evaluierungsblock 5 - Seite 6
529
B.3. Verwendete Fragebögen
Abbildung B.31.: Fragebogen für Evaluierungsblock 5 - Seite 7
530
Verzeichnisse
531
Abbildungsverzeichnis
1.1. Forschungsfragen und Fragestellungen . . . . . . . . . . . . . . . . . . . 9
1.2. Zusammenhänge zwischen den Kapiteln der Arbeit . . . . . . . . . . . . 12
1.3. Zusammenhang zwischen Zielsetzung und Struktur der Arbeit . . . . . . 18
2.1. Kapitel „Articulation Work“ im Gesamtzusammenhang . . . . . . . . . . 22
2.2. Konzeptualisierung von Arbeitsabläufen . . . . . . . . . . . . . . . . . . 24
2.3. Articulation Work im Durchführungskontext . . . . . . . . . . . . . . . . 38
2.4. Abzustimmende Arbeitsaspekte . . . . . . . . . . . . . . . . . . . . . . . 42
2.5. Zusammenhänge zwischen Arbeitsaspekten . . . . . . . . . . . . . . . . . 43
2.6. Artikulations-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.7. Mentale Modelle im Kontext der Arbeitsmodellierung . . . . . . . . . . . 62
3.1. Kapitel „Mentale Modelle“ im Gesamtzusammenhang . . . . . . . . . . . 76
3.2. Schemata und mentale Modelle . . . . . . . . . . . . . . . . . . . . . . . 79
3.3. Externalisierung mentaler Modelle . . . . . . . . . . . . . . . . . . . . . 85
3.4. Struktur einer Concept Map . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.5. Mentale Modelle und Articulation Work im Gesamtzusammenhang . . . 96
4.1. Kapitel „Methodik und Anwendungsszenarien“ im Gesamtzusammenhang 98
4.2. Externalisierung mentaler Modelle mittels Strukturlegetechniken und Con-
cept Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.1. Kapitel „Anforderungen an ein Werkzeug“ im Gesamtzusammenhang . . 115
6.1. Kapitel „Grundlagen der Realisierung und verwandte Arbeiten“ im Ge-
samtzusammenhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.2. Tangible Interfaces in Lernprozessen . . . . . . . . . . . . . . . . . . . . 124
6.3. Bedeutung von Objekten in TUIs . . . . . . . . . . . . . . . . . . . . . . 139
6.4. Interaktionsmodelle für GUI und TUI . . . . . . . . . . . . . . . . . . . . 141
6.5. Arten von Tangible User Interfaces . . . . . . . . . . . . . . . . . . . . . 143
6.6. Überblick über das MCRit-Modell . . . . . . . . . . . . . . . . . . . . . . 153
7.1. Kapitel „Eingabe und Interpretation“ im Gesamtzusammenhang . . . . . 173
7.2. Architektur des TUIpist-Framework . . . . . . . . . . . . . . . . . . . . . 185
7.3. Zusammenspiel der Komponenten in TUIpist . . . . . . . . . . . . . . . . 186
532
Abbildungsverzeichnis
7.4. AR Toolkit Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
7.5. Visual Codes – Aufbau und Features . . . . . . . . . . . . . . . . . . . . 188
7.6. ReacTIVision Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.7. Überblick über den Aufbau des Werkzeugs – Eingabekomponenten . . . . 197
7.8. An Tokens angebrachte ReacTIVision-Codes zur Identifikation . . . . . . 199
7.9. Arten von Modellierungstokens . . . . . . . . . . . . . . . . . . . . . . . 199
7.10. Rückwand von Container Tokens . . . . . . . . . . . . . . . . . . . . . . 200
7.11. Geöffnetes Container Token . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.12. Modellelemente – Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . 202
7.13. Einbettbare Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
7.14. Markierung-Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.15. Lösch-Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.16. Registrierungstoken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7.17. Snapshot-Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.18. History-Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.19. Softwarearchitektur zur Erkennung von Benutzerinteraktion . . . . . . . 220
8.1. Kapitel „Ausgabe“ im Gesamtzusammenhang . . . . . . . . . . . . . . . 238
8.2. Überblick über den Aufbau des Werkzeugs – Ausgabekomponenten . . . 247
8.3. Softwarearchitektur zur Verwaltung der Ausgabekanäle . . . . . . . . . . 254
8.4. Darstellung von Modellelementen . . . . . . . . . . . . . . . . . . . . . . 255
8.5. Darstellung von Verbindern . . . . . . . . . . . . . . . . . . . . . . . . . 256
8.6. Darstellung gerichteter Verbinder . . . . . . . . . . . . . . . . . . . . . . 257
8.7. Darstellung von Containern und eingebetteten Elementen . . . . . . . . . 258
8.8. Markierung von Modellelementen . . . . . . . . . . . . . . . . . . . . . . 259
8.9. Darstellung der Modellierungshistorie . . . . . . . . . . . . . . . . . . . . 261
8.10. Unterstützung der Wiederherstellung von Modellzuständen . . . . . . . . 262
8.11. Zusammenhänge der Klassen zur Ausgabebehandlung . . . . . . . . . . . 264
9.1. Kapitel „Persistierung“ im Gesamtzusammenhang . . . . . . . . . . . . . 271
9.2. Grundlegende Elemente einer Topic Map . . . . . . . . . . . . . . . . . . 273
9.3. Umfassende Darstellung der Elemente einer Topic Map . . . . . . . . . . 274
9.4. Abgrenzung zwischen Subject und Occurrence in Topic Maps . . . . . . . 275
9.5. Benennung von Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.6. Beziehungen in der Metamodellbildung in Topic Maps . . . . . . . . . . 279
9.7. Abbildung von Gültigkeitsbereichen durch Scopes . . . . . . . . . . . . . 282
9.8. Abbildung von Modellinformation in Topic Maps . . . . . . . . . . . . . 284
9.9. Definition des Meta-Models (ohne Kardinalitäten) . . . . . . . . . . . . . 287
9.10. Einbindung des Meta-Meta-Modells . . . . . . . . . . . . . . . . . . . . . 289
9.11. Ausschitt einer mittels GraphViz visualisierten Topic Map . . . . . . . . 292
9.12. Modellierungshistorie als exportierte Grafik . . . . . . . . . . . . . . . . 295
9.13. Modell-Hierarchie als exportierte Grafik . . . . . . . . . . . . . . . . . . 297
533
Abbildungsverzeichnis
10.1. Kapitel „Konzeptuelle Einordnung“ im Gesamtzusammenhang . . . . . . 303
11.1. Kapitel „Überblick über die empirische Untersuchung“ im Gesamtzusam-
menhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
12.1. Kapitel „Evaluierung der Verwendbarkeit des Werkzeugs“ im Gesamtzu-
sammenhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
12.2. Dauer der Werkzeugverwendung – Überblick . . . . . . . . . . . . . . . . 363
12.3. Dauer der Werkzeugverwendung – Evaluierungblock 3 . . . . . . . . . . . 364
12.4. Dauer der Werkzeugverwendung – Evaluierungblock 2 . . . . . . . . . . . 365
12.5. Zeitverteilung zwischen den Teilnehmern . . . . . . . . . . . . . . . . . . 367
12.6. Verteilung der Benutzereinschätzungen zum kooperativen Modellieren . . 369
12.7. Zusammenhang zwischen Modellgröße und Modellierungsdauer . . . . . . 374
12.8. Verteilung der Anzahl der Fehlerkennungen je Anwendung – Übersicht . 379
12.9. Verteilung der Benutzereinschätzungen zur Wirkung des Werkzeugs . . . 380
12.10.Connectedness in den Evaluierungsblöcken 2 und 3 . . . . . . . . . . . . 389
13.1. Kapitel „Evaluierung der erstellten Modelle“ im Gesamtzusammenhang . 399
13.2. Anzahl der verwendeten Elemente – Übersicht . . . . . . . . . . . . . . . 408
13.3. Anzahl der verwendeten Verbindungen – Übersicht . . . . . . . . . . . . 409
13.4. Vernetzungsgrad (Verbindungen / Blöcke) – Übersicht . . . . . . . . . . 410
13.5. Gegenüberstellung der Modellgrößen in Evaluierungsblock 5 . . . . . . . 416
13.6. Verteilung der Benutzereinschätzungen zum kooperativen Modellieren . . 422
13.7. Korrekt intepretierbares Modell ohne Verbinder (hierarchisch) . . . . . . 425
13.8. Korrekt intepretierbares Modell ohne Verbinder (ablauforientiert) . . . . 426
13.9. Bei Vernachlässigung der Verbinder nur unvollständig interpretierbares
Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
14.1. Kapitel „Evaluierung der durchgeführten Articulation Work“ im Gesamt-
zusammenhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
14.2. Verteilung der Benutzereinschätzungen zur Verständnisbildung durch das
Werkzeug – Teil 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
14.3. Verteilung der Benutzereinschätzungen zur Verständnisbildung durch das
Werkzeug – Teil 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
14.4. Verteilung der Benutzereinschätzungen zur Wirkung der Modellbildung
auf die Arbeitsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
15.1. Kapitel „Schussbetrachtungen“ im Gesamtzusammenhang . . . . . . . . 452
15.2. Gesamtzusammenhang der verwendeten Konzepte . . . . . . . . . . . . . 453
A.1. Literatur zu Articulation Work im Kontext . . . . . . . . . . . . . . . . . 490
B.1. Raster der Überblicksauswertung . . . . . . . . . . . . . . . . . . . . . . 496
B.2. Erster Fragebogen für Modellierer in Evaluierungsblock 1 - Seite 1 . . . . 499
534
Abbildungsverzeichnis
B.3. Erster Fragebogen für Modellierer in Evaluierungsblock 1 - Seite 2 . . . . 500
B.4. Erster Fragebogen für Modellierer in Evaluierungsblock 1 - Seite 3 . . . . 501
B.5. Fragebogen für Interpretierer in Evaluierungsblock 1 - Seite 1 . . . . . . 502
B.6. Fragebogen für Interpretierer in Evaluierungsblock 1 - Seite 2 . . . . . . 503
B.7. Fragebogen bezüglich der Korrektheit der Interpretation in Evaluierungs-
block 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
B.8. Fragebogen bezüglich Modellierungsvorkenntnissen in Evaluierungsblock 1 505
B.9. Erster Fragebogen für Evaluierungsblock 4 - Seite 1 . . . . . . . . . . . . 507
B.10.Erster Fragebogen für Evaluierungsblock 4 - Seite 2 . . . . . . . . . . . . 508
B.11.Erster Fragebogen für Evaluierungsblock 4 - Seite 3 . . . . . . . . . . . . 509
B.12.Erster Fragebogen für Evaluierungsblock 4 - Seite 4 . . . . . . . . . . . . 510
B.13.Erster Fragebogen für Evaluierungsblock 4 - Seite 5 . . . . . . . . . . . . 511
B.14.Erster Fragebogen für Evaluierungsblock 4 - Seite 6 . . . . . . . . . . . . 512
B.15.Erster Fragebogen für Evaluierungsblock 4 - Seite 7 . . . . . . . . . . . . 513
B.16.Erster Fragebogen für Evaluierungsblock 4 - Seite 8 . . . . . . . . . . . . 514
B.17.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 1 . . . . . . . . . . . 515
B.18.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 2 . . . . . . . . . . . 516
B.19.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 3 . . . . . . . . . . . 517
B.20.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 4 . . . . . . . . . . . 518
B.21.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 5 . . . . . . . . . . . 519
B.22.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 6 . . . . . . . . . . . 520
B.23.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 7 . . . . . . . . . . . 521
B.24.Zweiter Fragebogen für Evaluierungsblock 4 - Seite 8 . . . . . . . . . . . 522
B.25.Fragebogen für Evaluierungsblock 5 - Seite 1 . . . . . . . . . . . . . . . . 524
B.26.Fragebogen für Evaluierungsblock 5 - Seite 2 . . . . . . . . . . . . . . . . 525
B.27.Fragebogen für Evaluierungsblock 5 - Seite 3 . . . . . . . . . . . . . . . . 526
B.28.Fragebogen für Evaluierungsblock 5 - Seite 4 . . . . . . . . . . . . . . . . 527
B.29.Fragebogen für Evaluierungsblock 5 - Seite 5 . . . . . . . . . . . . . . . . 528
B.30.Fragebogen für Evaluierungsblock 5 - Seite 6 . . . . . . . . . . . . . . . . 529
B.31.Fragebogen für Evaluierungsblock 5 - Seite 7 . . . . . . . . . . . . . . . . 530
535
Tabellenverzeichnis
6.1. Kategorien von konzeptuellen Arbeiten im Gebiet Tangible User Interfaces157
6.2. Gegenüberstellung der Nomenklatur zur Beschreibung der Elemente eines
TUI – Teil 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.3. Gegenüberstellung der Nomenklatur zur Beschreibung der Elemente eines
TUI – Teil 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.1. Gegenüberstellung der Frameworks für video-basierten Input . . . . . . . 192
7.2. Gegenüberstellung der generischen Frameworks . . . . . . . . . . . . . . 195
10.1. Beurteilung des Werkzeugs hinsichtlich des Degree of Coherence . . . . . 315
10.2. Spezifikation des Werkzeug mittels TAC-Schema – Teil 1 . . . . . . . . . 317
10.3. Spezifikation des Werkzeug mittels TAC-Schema – Teil 2 . . . . . . . . . 318
10.4. Einordnung des Systems in die Taxonomie nach Fishkin . . . . . . . . . 321
11.1. Ursprüngliches globales Untersuchungsdesign . . . . . . . . . . . . . . . . 350
11.2. Einfluss der Untersuchungen auf die zu evaluierenden Aspekte . . . . . . 350
12.1. Hypothesen zur Benutzbarkeit des Werkzeugs und deren Bezug zu den
Anforderungen an das Werkzeug . . . . . . . . . . . . . . . . . . . . . . 355
12.2. Stichproben der Evaluierung zur Werkzeugverwendung . . . . . . . . . . 362
12.3. Dauer der Werkzeugverwendung . . . . . . . . . . . . . . . . . . . . . . . 363
12.4. Anzahl der Modelle mit Verbindern . . . . . . . . . . . . . . . . . . . . . 365
12.5. Befragung Kooperative Modellierung – Itemauswertung . . . . . . . . . . 369
12.6. Anzahl des Einsatzes der Wiederherstellungsfunkion . . . . . . . . . . . . 377
12.7. Fehlfunktionen und Abstürze des Werkzeugs . . . . . . . . . . . . . . . . 378
12.8. Befragung über die Wirkung des Werkzeugs – Itemauswertung . . . . . . 380
12.9. Modellierungszeiten in Abhängigkeit der Modellgröße in Evaluierungs-
block 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
12.10.Anzahl der Fehlbedienungen in Evaluierungsblock 2 . . . . . . . . . . . . 387
12.11.Verwendung des Löschtokens . . . . . . . . . . . . . . . . . . . . . . . . . 391
13.1. Hypothesen zur Anwendung des Instruments und deren Bezug zu den
Anforderungen an das Werkzeug . . . . . . . . . . . . . . . . . . . . . . 402
13.2. Stichproben der Evaluierung zur Modellbildung . . . . . . . . . . . . . . 408
13.3. Anzahl der bedeutungstragenden Elemente je Modell . . . . . . . . . . . 412
536
Tabellenverzeichnis
13.4. Korrektheit der Modellinterpretation in Evaluierungsblock 4 . . . . . . . 418
13.5. Korrektheit der Modellinterpretation in Evaluierungsblock 5 . . . . . . . 418
13.6. Befragung Kooperative Modellierung im Werkzeugvergleich – Itemaus-
wertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
14.1. Hypothesen zur Wirkung des Instruments auf die Articulation Work und
deren Bezug zu den Anforderungen an das Werkzeug . . . . . . . . . . . 433
14.2. Stichproben der Evaluierung zur Articulation Work . . . . . . . . . . . . 436
14.3. Befragung über die Verständnisbildung bei der Modellierung – Itemaus-
wertung Teil 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
14.4. Befragung über die Verständnisbildung bei der Modellierung – Itemaus-
wertung Teil 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
14.5. Befragung über die Wirkung der Modellbildung auf die Arbeitsprozesse
– Itemauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
14.6. Ergebnis der „Production Work“ in Evaluierungsblock 2 . . . . . . . . . 444
14.7. Ergebnis der „Production Work“ ohne Unterstützung der „Articulation
Work“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
15.1. Erfüllung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 465
537
Abkürzungsverzeichnis
API Application Interface
AWT Abstract Window Toolkit
CORBA Common Object Request Broker Architecture
CSCL Computer Supported Cooperative Learning
CSCW Computer Supported Cooperative Work
EAN European Article Number
ECA Event-Condition-Action
EMF Eclipse Modeling Framework
EPK Ereignisgesteuerte Prozesskette
GB Gigabyte
GEF Graphical Editing Framework (Eclipse-Komponente)
GIF Graphics Interchange Format
GMF Graphical Modeling Framework (Eclipse-Komponente)
GPS Global Positioning System
GUI Graphical User Interface
HCI Human Computer Interaction
HSLT Heidelberger Strukturlegetechnik
HTTP Hypertext Transfer Protocol
IP Internet Protocol
JPEG Joint Photographic Experts Group (File Interchange Format)
JRE Java Runtime Environment
LCD Liquid Crystal Display (Flüssigkristallanzeige)
LED Light Emitting Diode (Leuchtdiode)
MaNET Mannheimer Netzwerk-Elaborations-Technik
MCRit Model-Control-Representation (intangible and tangible)
MCRpd Model-Control-Representation (physical and digital)
538
Abbildungsquellen
MVC Model-View-Controller
OADI Observe – Assess – Design – Implement
OCR Optical Character Recognition
ODF Open Document Format
OLED Organic Light Emitting Diode
OWL Ontology Web Language
PMS Process Modelling Success
PNG Portable Network Graphics
RDBMS Relationales Datenbank Management System
RDF Ressource Description Framework
RFID Radio Frequency Identification
RMI Remote Methode Invocation
TAC Token and Constraint
TCP Transport Control Protocol
TEL Technology Enhanced Learning
TUI Tangible User Interface
UDP User Datagram Protocol
UML Unified Modelling Language
URI Uniform Resource Identifier
WfMS Workflow-Management-System
XML Extensible Markup Language
XTM XML Topic Map
539
Abbildungsquellen
Dieser Anhang enthält Quellenangaben für alle in dieser Arbeit verwendeten Abbildun-
gen, sofern sie nicht vom Autor erstellt wurden. Sofern nicht anders angegeben, sind alle
Abbildungen und Fotos Werke des Autors und dürfen nicht ohne ausdrückliche Zustim-
mung verwendet werden.
Abbildung 2.4 Tabelle über abzustimmende Arbeitsaspekte übernommen von (Schmidt
und Simone, 1996)
Abbildung 2.5 Abbildung über Zusammenhänge zwischen Arbeitsaspekte übernommen
von (Divitini und Simone, 2000)
Abbildung 2.6 Abbildung des Artikulations-Prozesses nach (Mi und Scacchi, 1991) über-
nommen von ebenda
Abbildung 2.7 Abbildung über Mentale Modelle im Kontext der Arbeitsmodellierung
übernommen von (Herrmann et al., 2002)
Abbildung 3.2 Abbildung über den Zusammenhang zwischen Schemata und Mentalen
Modellen übernommen von (Ifenthaler, 2006)
Abbildung 3.3 Abbildung über die Externalisierung mentaler Modelle übernommen von
(Ifenthaler, 2006)
Abbildung 3.4 Abbildung über die Struktur einer Concept Map übernommen von (No-
vak und Cañas, 2006)
Abbildung 6.2 Taxonomie von Tangible Interfaces im Kontext von Lernprozessen über-
nommen von (Marshall, 2007)
Abbildung 6.4 Abbildung des MVC- und MCRpd-Modells übernommen von (Ullmer
und Ishii, 2000)
Abbildung 6.5 Abbildung unterschiedlicher Arten von Tangible User Interfaces über-
nommen von (Ullmer et al., 2005)
Abbildung 6.6 Abbildung des MCRit-Modells übernommen von (Ishii, 2008)
Abbildung 7.4 Bild des AR Toolkit Markers entnommen von www.hitl.washington.edu/
artoolkit/ (Website der Entwickler)
Abbildung 7.5 Bild des Visual Code Markers übernommen von (Rohs und Gfeller, 2004)
540
Abbildungsquellen
Abbildung 9.4 Foto der Tasse lizenzfrei unter http://www.oldskoolman.de/bilder/
freigestellte-bilder/essen-trinken/kaffee-tasse-freigestellt/, übrige Abbildung eige-
ne Darstellung
Abbildungen B.2 bis B.31 Abbildungen der verwendeten Fragebögen übernommen von
(Bohninger, 2010), (Wahlmüller, 2010) und (Bindreiter, 2010)
541
Publikationen im Kontext dieser Arbeit
Oppl und Stary (2005) „Towards Human-Centered Design of Diagrammatic Represen-
tation Schemes“: Konferenz-Beitrag (8 Seiten ACM), in der erstmals der Ansatz
der semantischen Offenheit in der Prozessmodellierung auf einer Fallstudie heraus
argumentiert wird und als Mittel der Abbildung individueller Erklärungsmuster
oder mentaler Modelle in Prozessmodellen bezeichnet wird.
Oppl (2006) „Towards Intuitive Work Modeling with a Tangible Collaboration Inter-
face Approach“: Workshop-Paper (6 Seiten IEEE), das die technologischen Fragen
bei der Konzeption eines tangiblen Modellierungswerkzeugs beschreibt und die bei
der technischen Umsetzung zu lösenden Probleme aufzeigt.
Oppl et al. (2006) „Towards Tangible Work Modeling“: Konferenz-Beitrag (6 Seiten
Oldenburg-Verlag), in der die erste Umsetzung des tangiblen Modellierungswerk-
zeugs beschrieben wird. Die Argumentation erfolg aus den Arbeiten zur digital
augementierem Montessori-Material heraus, welche auf das Anwendungsgebiet der
Aufgabenmodellierung abgebildet werden. Der erste Prototyp des Systems und
eine Möglichkeit zur digitalen Repräsentation der individuell eingebrachten Infor-
mation werden aus technischer Sicht beschrieben.
Oppl (2007b) „Spielen Sie noch? – Bausteine im Unternehmenskontext“: Workshop-
Paper (4 Seiten Oldenburg-Verlag), dass erstmalig den Gegenstands der Modellbil-
dung von Geschäftsprozessen hin zu Arbeitswissen verallgemeinert und den Ansatz
aus dem Forschungsgebiet des Organisationalen Lernen heraus argumentiert.
Oppl (2007a) „Flexibility of Content for Organisational Learning - A Topic Map Ap-
proach“: Master-Arbeit (270 Seiten A4), in der die Repräsentation der Modelle
mittels Topic Maps eingeführt wird und deren Notwendigkeit zur erfolgreichen
Durchführung von organisationalen Lernprozessen argumentiert wird. Konzeption
und Beschreibung der auch in dieser Arbeit zum Einsatz gebrachten Topic-Map-
Engine.
Oppl und Peherstorfer (2007) „Human Intervention in cross-organizational Process
Development“: Konferenz-Beitrag (10 Seiten, A4), der aus einem durchgeführten
Projekt heraus für eine humanzentrierte Sichtweise bei der organisationsübergrei-
fenden Festlegung von Arbeitsprozessen argumentiert und darin einen Beitrag zur
Fundierung dieser Arbeit liefert.
542
Publikationen im Kontext dieser Arbeit
Furtmüller und Oppl (2007) „A Tuple-Space based Middleware for Collaborative Tan-
gible User Interfaces“: Workshop-Paper (6 Seiten IEEE), in dem eine Middleware
zur flexiblen und dynamischen Kopplung der Informationserfassungs-, -interpretations-
und -ausgabemöglicheiten am Tabletop Interface beschrieben wird und deren Ein-
satz im konkreten Werkzeug umrissen wird.
Oppl (2008b) „Graspable Work Modeling“: Konferenz-Beitrag (4 Seiten Oldenburg-
Verlag), in dem erstmals die aktuelle Implementierung des Werkzeugs und die
Umsetzung des zweiten Hardware-Prototypen beschrieben wird. Dabei wird erst-
malig auf die Fundierung des Ansatzes durch „Articulation Work“ verwiesen.
Oppl (2008a) „Begreifbare Modellierung von Arbeit“: Workshop-Beitrag (3 Seiten GI
LNI), der ebenfalls auf die aktuelle Implementierung des Werkzeugs eingeht und
den Mehrwert der tangiblen Interaktionsmöglichkeiten im konkreten Anwendungs-
fall argumentiert.
Oppl und Stary (2009) „Tabletop Concept Mapping“: Konferenz-Beitrag (8 Seiten ACM),
in dem die Verwendung des Werkzeugs zur Durchführung von Concept Mapping
beschrieben wird und in dem erstmal empirische Ergebnisse der Werkzeugverwen-
dung angeführt sind. Fokus dieser Arbeit war die Modellbildung mit dem Werk-
zeug, nicht dessen Einsatz zur Durchführung von „Articulation Work“.
Oppl (2009c) „Unterstützung expliziter Articulation Work“: Workshop-Beitrag (4 Sei-
ten A4), in der die Wirkung des Werkzeugs im Kontext von techologiegestütztem
Lernen (TEL3) betrachtet wird.
Oppl (2009a) „A Tabletop Interface to support Concept Mapping“: Workshop-Paper
(3 Seiten A4), in dem eine Kurzübersicht über das Werkzeug zum Einsatz im
universitären Lern-Kontext gegeben wird.
Oppl (2009b) „Konsistente Verwendung von Metaphern als Erfolgskriterium für kom-
plexe Tangible User Interfaces“: Workshop-Paper (4 Seiten GI LNI), in dem die
Einflussfaktoren auf die Verständlichkeit von Werkzeugen zur Interaktion mit Tan-
gible Interfaces an einem konkreten Beispiel konzeptuell erörtert und empirisch
belegt werden.
Oppl (2009d) „Using a Tangible Tabletop Interface to facilitate Articulation Work“:
Workshop-Paper (2 Seiten A4), in dem eine Kurzübersicht über das Werkzeug zum
Einsatz in der Unterstützung von „Articulation Work“ wiederum in Lernszenarien
gegeben wird.
Oppl (2010) „Unterstützung expliziter Articulation Work durch Externalisierung von
Arbeitswissen“: Buchbeitrag (25 Seiten A4), in dem das gesamte Forschungsprojekt
konzeptuell wie in dieser Arbeit beschrieben argumentiert wird und die Umsetzung
des Werkzeugs sowie die ersten empirischen Ergebnisse ausführlich dargestellt wer-
den.
3Technology Enhanced Learning
543
Publikationen im Kontext dieser Arbeit
Oppl et al. (2010) „Supporting Self-regulated Learning with Tabletop Concept Map-
ping“: Buchbeitrag (15 Seiten A4, noch nicht erschienen), in dem das Konzept
des hier vorgestellten Werkzeugs mit Ansätzen zur Unterstützung von selbst-
gesteuertem Lernen und automatisierten, kontextsensitiven Interventionen in den
Lernprozess in Zusammenhang gebracht wird und mögliche Anküpfungspunkte
identifiziert werden.
544
Literaturverzeichnis
Abecker, A., Bernardi, A., Hinkelmann, K., Kühn, O., und Sintek, M. (1998). Toward
a Technology for Organizational Memories. IEEE Intelligent Systems, 13(3):40–48.
Referenziert auf S. 83
Allied Vision Technologies GmbH (2008). AVT Guppy. Technical Manual V6.2.0, Allied
Vision Technologies GmbH, Stadtroda, Germany. Referenziert auf S. 208
Argyris, C. (1976). Single-loop and double-loop models in research on decision making.
Administrative Science Quarterly, Seiten 363–375. Referenziert auf S. 106
Argyris, C. und Schön, D. (1978). Organizational Learning: A Theory Of Action Per-
spective. Addison-Wesley. Referenziert auf S. 2, 37, 79
Arnold, K., Scheifler, R., Waldo, J., O’Sullivan, B., und Wollrath, A. (1999). Jini Spe-
cification. Addison-Wesley Longman Publishing, Boston, MA, USA. Referenziert auf S.
186, 193
Azuma, R. (1997). A survey of augmented reality. Presence-Teleoperators and Virtual
Environments, 6(4):355–385. Referenziert auf S. 123
Baker, K. und Millerand, F. (2007). Articulation work supporting information infrastruc-
ture design: Coordination, categorization, and assessment in practice. Proceedings of
HICSS 2007, Seite 242a. Referenziert auf S. 4, 27, 487
Bannon, L. und Bødker, S. (1997). Constructing common information spaces. In Procee-
dings of the fifth conference on European Conference on Computer-Supported Coopera-
tive Work, Seiten 81–96. Kluwer Academic Publishers Norwell, MA, USA. Referenziert
auf S. 481, 484
Bannon, L. und Schmidt, K. (1993). Issues of Supporting Organizational Context in
CSCW Systems. Deliverable D1.1, The COMIC Project (Esprit Basic Research Action
6225). Referenziert auf S. 480
Becker, J., Rosemann, M., und von Uthmann, C. (2000). Guidelines of business process
modeling. In van der Aalst, W., Sedel, J., und Oberweis, A., editors, Business Process
Management: Models, Techniques, and Empirical Studies, number 1806 in LNCS,
Seiten 241–262. Springer. Referenziert auf S. 331
545
Literaturverzeichnis
Bederson, B., Grosjean, J., und Meyer, J. (2004). Toolkit design for interactive structured
graphics. IEEE Transactions on Software Engineering, 30(8):535–546. Referenziert auf
S. 248
Beer, W., Christian, V., Ferscha, A., und Mehrmann, L. (2003). Modeling Context-aware
Behavior by Interpreted ECA Rules. In Proceedings of the International Conference on
Parallel and Distributed Computing (EUROPAR ’03), volume 2790 of LNCS, Seiten
1064–1073. Springer. Referenziert auf S. 183
Bellotti, V., Back, M., Edwards, W., Grinter, R., Henderson, A., und Lopes, C. (2002).
Making sense of sensing systems: five questions for designers and researchers. In Pro-
ceedings of the SIGCHI conference on Human factors in computing systems: Changing
our world, changing ourselves, Seiten 415–422. ACM New York, NY, USA. Referenziert
auf S. 144, 313, 326, 458, 460
Bendifallah, S. und Scacchi, W. (1987). Understanding software maintenance work.
IEEE Transactions on Software Engineering, 13(3):311–323. Referenziert auf S. 26, 27,
50, 479
Berg, M. und Timmermans, S. (2000). Order and their others: On the constitution of
universalities in medical work. Configurations, 8(1):31–61. Referenziert auf S. 483
Bindreiter, D. (2010). Kooperative Modellierung von Konzeptwissen – Eine vergleichende
Studie. Technical report, University of Linz. Referenziert auf S. 493, 494, 523, 541
Bloks, R. H. J. (1996). The IEEE-1394 high speed serial bus. Philips Journal of Research,
50(1-2):209–216. Referenziert auf S. 209
Bluetooth SIG (2007). Bluetooth Specification Version 2.1 + EDR. Specification, Blue-
tooth SIG. Referenziert auf S. 180
Bohninger, J. (2010). Untersuchung der Benutzbarkeit eines Tabletop Interfaces zur
kooperativen Modellbildung. Technical report, University of Linz. Referenziert auf S.
333, 492, 493, 498, 541
Bortz, J. und Döring, N. (2003). Forschungsmethoden und Evaluation für Human- und
Sozialwissenschaftler. Springer, 3rd edition. Referenziert auf S. 344, 345, 347
Bossen, C. (2002). The parameters of common information spaces: the heterogeneity
of cooperative work at a hospital ward. In Proceedings of the 2002 ACM conference
on Computer supported cooperative work, Seiten 176–185. ACM Press New York, NY,
USA. Referenziert auf S. 484
Bowers, J. (1994). A Conceptual Framework for Describing Organizations. Deliverable
D1.2, The COMIC Project (Esprit Basic Research Action 6225). Referenziert auf S. 480
546
Literaturverzeichnis
Brant, J. M. (1995). HotDraw. Master’s thesis, University of Illinois at Urbana Cham-
paign. Referenziert auf S. 249
Budinsky, F., Brodsky, S., und Merks, E. (2003). Eclipse modeling framework. Pearson
Education. Referenziert auf S. 248
Cabitza, F. und Sarini, M. (2007). On the pathway towards ICT-support for a better and
sustainable healthcare. In Proceedings of the second European Conference on eHealth
(ECEH07), Seiten 89–100. Springer. Referenziert auf S. 488
Cabitza, F., Sarini, M., Simone, C., und Telaro, M. (2006). Torres, a Conceptual Frame-
work for Articulation Work across Boundaries. In Hassanaly, P., Herrmann, T., Ku-
nau, G., und Zacklad, M., editors, Cooperative Systems Design: Seamless Integration
of Artifacts and Conversations: Enhanced Concepts of Infrastructure for Commu-
nication, volume 137 of Frontiers in Artificial Intelligence and Applications, Seiten
102–119. IOS Press. Referenziert auf S. 2, 69, 102, 487, 488
Cabitza, F. und Simone, C. (2009a). Active artifacts as bridges between context and
community knowledge sources. In C&#38;T ’09: Proceedings of the fourth interna-
tional conference on Communities and technologies, Seiten 115–124, New York, NY,
USA. ACM. Referenziert auf S. 488, 489
Cabitza, F. und Simone, C. (2009b). LWOAD: A Specification Language to Enable the
End-User Develoment of Coordinative Functionalities. In Proceedings of End User
Development: 2nd International Symposium, IS-EUD 2009, Siegen, Germany, March
2-4, 2009. Proceedings, Seite 146. Springer. Referenziert auf S. 488
Cabitza, F., Simone, C., und Sarini, M. (2008). Knowledge Artifacts as Bridges bet-
ween Theory and Practice: The Clinical Pathway Case. In Proceedings of IFIP 20th
World Computer Congress, Conference on Knowledge Management in Action, Seite 37.
Springer. Referenziert auf S. 488
Cabitza, F., Simone, C., und Sarini, M. (2009). Leveraging Coordinative Conventions to
Promote Collaboration Awareness. Computer Supported Cooperative Work (CSCW),
18(4):301–330. Referenziert auf S. 70, 489
Cañas, A., Hill, G., Carff, R., Suri, N., Lott, J., Eskridge, T., Gómez, G., Arroyo, M., und
Carvajal, R. (2004). Cmaptools: A knowledge modeling and sharing environment. In
Concept Maps: Theory, Methodology, Technology, Proceedings of the 1st International
Conference on Concept Mapping. Pamplona, Spain: Universidad Pública de Navarra.
Referenziert auf S. 95, 170, 338, 341, 342
Carriero, N. und Gelernter, D. (1989). Linda in context. Communications of the ACM,
32(4):444–458. Referenziert auf S. 184
547
Literaturverzeichnis
Carstensen, P. und Schmidt, K. (1999). Computer supported cooperative work: new
challenges to systems design. preprint, to appear in: Itoh, k. (ed.): Handbook of human
factors, Center for Tele-Information, Danmarks Tekniske Universite. Referenziert auf S.
39, 482
Christensen, U. (2001). Conventions and articulation work in a mobile workplace. ACM
SIGGROUP Bulletin, 22(3):16–21. Referenziert auf S. 483
Comiskey, B., Albert, J., Yoshizawa, H., Jacobson, J., by Michaels, C., et al. (1998). An
electrophoretic ink for all-printed reflective electronic displays. Nature, 394:253–255.
Referenziert auf S. 242
Convertino, G., Mentis, H. M., Rosson, M. B., Carroll, J. M., Slavkovic, A., und Ganoe,
C. H. (2008). Articulating common ground in cooperative work: content and process.
In CHI ’08: Proceeding of the twenty-sixth annual SIGCHI conference on Human fac-
tors in computing systems, Seiten 1637–1646, New York, NY, USA. ACM. Referenziert
auf S. 488
Corbin, J. und Strauss, A. (1993). The Articulation of Work through Interaction. The
Sociological Quarterly, 34(1):71–83. Referenziert auf S. 27, 34, 38, 39, 47, 102, 109, 480, 485
Crabtree, A., O’Neill, J., Tolmie, P., Castellani, S., Colombino, T., und Grasso, A.
(2006). The practical indispensability of articulation work to immediate and remote
help-giving. In CSCW ’06: Proceedings of the 2006 20th anniversary conference on
Computer supported cooperative work, Seiten 219–228, New York, NY, USA. ACM.
Referenziert auf S. 487
Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N., und Weerawarana, S. (2002).
Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI. IEEE
Internet Computing, 6(2):86–93. Referenziert auf S. 194
Dahme, C. und Raeithel, A. (1997). Ein tätigkeitstheoretischer Ansatz zur Entwicklung
von brauchbarer Software. Informatik-Spektrum, 20:5–12. Referenziert auf S. 29
Dann, H.-D. (1992). Variation von Lege-Strukturen zur Wissensrepräsentation. In Schee-
le, B., editor, Struktur-Lege-Verfahren als Dialog-Konsens-Methodik. Ein Zwischenfazit
zur Forschungsentwicklung bei der rekonstruktiven Erhebung subjektiver Theorien, vo-
lume 25 of Arbeiten zur sozialwissenschaftlichen Psychologie, Seiten 2–41. Aschendorff.
Referenziert auf S. 13, 89, 90
Davenport, E. (2002). Mundane knowledge management and microlevel organizational
learning: An ethological approach. Journal of the American Society for Information
Science and Technology, 53(12):1038–1046. Referenziert auf S. 2, 60, 71, 73, 484, 487
548
Literaturverzeichnis
de Kleer, J. und Brown, J. (1981). Mental models of physical mechanisms and their
acquisition. In Anderson, J., editor, Cognitive skills and their acquisition, Seiten
285–309. Erlbaum. Referenziert auf S. 78
Dey, A. K., Salber, D., und Abowd, G. D. (2001). A conceptual framework and a toolkit
for supporting the rapid prototyping of context-aware applications. Human-Computer
Interaction (HCI) Journal, 16(2-4):97–166. Referenziert auf S. 182, 184
Diefenbruch, M., Goesmann, T., Herrmann, T., und Hoffmann, M. (2002). KontextNa-
vigator und ExperKnowledge - Zwei Wege zur Unterstützung des Prozesswissens in
Unternehmen. In Abecker, A., Hinkelmann, K., Maus, H., und Müller, H., editors,
Geschäftsprozessorientiertes Wissensmanagement, Seiten 275–292. Springer. Referen-
ziert auf S. 83
Dietz, P. und Leigh, D. (2001). DiamondTouch: a multi-user touch technology. In Procee-
dings of the 14th annual ACM symposium on User interface software and technology,
Seite 226. ACM. Referenziert auf S. 165
Divitini, M. und Simone, C. (2000). Supporting different dimensions of adaptability in
workflow modeling. Computer Supported Cooperative Work (CSCW), 9(3):365–397.
Referenziert auf S. 43, 54, 58, 59, 64, 65, 71, 83, 481, 483, 540
Do-Lenh, S., Kaplan, F., Sharma, A., und Dillenbourg, P. (2009). Multi-finger inter-
actions with papers on augmented tabletops. In TEI ’09: Proceedings of the 3rd In-
ternational Conference on Tangible and Embedded Interaction, Seiten 267–274, New
York, NY, USA. ACM. Referenziert auf S. 91, 169
Dourish, P. und Bellotti, V. (1992). Awareness and coordination in shared workspaces.
In CSCW ’92: Proceedings of the 1992 ACM conference on Computer-supported co-
operative work, Seiten 107–114, New York, NY, USA. ACM. Referenziert auf S. 128
Downing, T. (1998). Java RMI: remote method invocation. IDG Books Worldwide, Inc.,
Foster City, CA, USA. Referenziert auf S. 194
Duller, C. (2008). Einführung in die nichtparametrische Statistik mit SAS und R.
Physica-Verlag, Heidelberg. Referenziert auf S. 344, 345, 346, 347
Eckert, A. (1998). Kognition und Wissensdiagnose. Die Entwicklung und empiri-
sche Überprüfung des computerunterstützten wissensdiagnostischen Instrumentariums
Netzwerk-Elaborierungs-Technik (NET). Pabst Science Publishers. Referenziert auf S.
91
Eclipse Foundation (2009). GMF Documentation. online reference manual
(http://wiki.eclipse.org/gmfdocumentation), EclipseFoundation.ReferenziertaufS. 248
549
Literaturverzeichnis
Ellson, J., Gansner, E., Koutsofios, L., North, S., und Woodhull, G. (2002). Graphviz-open
source graph drawing tools. In Graph Drawing, Lecture Notes in Computer Science,
Seiten 483–484. Springer. Referenziert auf S. 292
Emery, F. und Trist, E. (1960). Socio-technical systems. Management science, models and
techniques, 2:83–97. Referenziert auf S. 28
Engeström, Y. (1987). Learning by expanding. Orienta-konsultit, Helsinki. Referenziert auf
S. 29
Engeström, Y. (2000). Activity theory as a framework for analyzing and redesigning work.
Ergonomics, 43(7):940–974. Referenziert auf S. 55
Eschenfelder, K. R. (2003). The importance of articulation work to agency content ma-
nagement: Balancing publication and control. In Proceedings of the Hawaii International
Conference on System Sciences, volume 5, Seite 135b, Los Alamitos, CA, USA. IEEE
Computer Society. Referenziert auf S. 485
Færgemann, L., Schilder-Knudsen, T., und Carstensen, P. H. (2005). The duality of ar-
ticulation work in large heterogenous settings - a study in health care. In Schmidt,
K., Gellersen, H., Mackay, W., und Beaudouin-Lafon, M., editors, Proceedings of the
9th European Conference on Computer-Supported Cooperative Work, Seiten 163–183.
Springer. Referenziert auf S. 28, 33, 34, 40, 69, 71, 486, 487
Feiner, T. (2008). Modelleditor auf Basis dynamischer Metamodelle zur Unterstützung
partizipativer Modellerfassung und -reflexion. Master’s thesis, University of Linz. Refe-
renziert auf S. 248, 250, 269
Ferscha, A., Vogl, S., Emsenhuber, B., und Wally, B. (2008). Physical shortcuts for media
remote controls. In Proceedings of the 2nd international conference on INtelligent TEch-
nologies for interactive enterTAINment table of contents. ICST (Institute for Computer
Sciences, Social-Informatics and Telecommunications Engineering) ICST, Brussels, Bel-
gium, Belgium. Referenziert auf S. 180
Firestone, J. und McElroy, M. (2003). Key Issues in the new Knowledge Management.
Butterworth-Heinemann. Referenziert auf S. 2
Fishkin, K. P. (2004). A taxonomy for and analysis of tangible interfaces. Personal and
Ubiquitous Computing, 8(5):347–358. Referenziert auf S. 131, 147, 150, 151, 152, 157, 158, 159,
171, 238, 240, 243, 246, 269, 316, 320, 323, 326, 327, 459, 460
Fitzmaurice, G. (1996). Graspable User Interfaces. Phd-thesis, University of Toronto.
Referenziert auf S. 122, 131, 132, 134, 158, 163, 305, 324, 325
550
Literaturverzeichnis
Fitzmaurice, G., Ishii, H., und Buxton, W. (1995). Bricks: laying the foundations for
graspable user interfaces. In Proceedings of the SIGCHI conference on Human factors in
computing systems (CHI), Seiten 442–449. ACM Press/Addison-Wesley Publishing Co.
New York, NY, USA. Referenziert auf S. 122, 131, 132, 134, 158, 167, 302, 303, 305, 324
Fjeld, M. (2001). Designing for tangible interaction. PhD thesis, Swiss Federal Institute
of Technology. Referenziert auf S. 163
Fjeld, M., Bichsel, M., und Rauterberg, M. (1997). BUILD-IT: An Intuitive Design Tool
Based on Direct Object Manipulation. In Proceedings of the International Gesture Work-
shop on Gesture and Sign Language in Human-Computer Interaction, Seiten 297–308.
Springer-Verlag London, UK. Referenziert auf S. 163
Fjuk, A. und Dirckinck-Holmfeld, L. (1997). Articulation of Actions in Distributed Colla-
borative Learning. Scandinavian Journal of Information Systems, 9(2):3–24. Referenziert
auf S. 481
Fjuk, A., Nurminen, M., und Smørdal, O. (1997). Taking Articulation Work Seriously:
An Activity Theoretical Approach. Technical Report TUCS TR 120, Turku Centre for
Computer Science. Referenziert auf S. 3, 26, 28, 29, 30, 31, 34, 35, 40, 55, 56, 71, 103, 106, 331, 481
Fleischmann, A. (2007). Subjektorientiertes geschäftsprozessmanagement. White paper,
jCOM1 AG„ Rohrbach. Referenziert auf S. 337
Fuchs, L., Poltrock, S., und Wetzel, I. (2001). TeamSpace: an environment for team arti-
culation work and virtual meetings. In Proceedings of the 12th International Workshop
on Database and Expert Systems Applications, Seiten 527–531. IEEE Press. Referenziert
auf S. 57, 71, 83, 483
Fujimura, J. (1987). Constructing ’Do-Able’ Problems in Cancer Research: Articulating
Alignment. Social Studies of Science, 17(2):257–293. Referenziert auf S. 2, 23, 24, 25, 36, 332,
432, 479, 480
Furtmüller, F. und Oppl, S. (2007). A Tuple-Space based Middleware for Collaborative
Tangible User Interfaces. In Proceedings of WETICE ’07. IEEE Press. Referenziert auf S.
184, 185, 186, 236, 543
Furtmüller, F. G. (2007). Implementierung eines Frameworks für berührbare Benutzungs-
schnittstellen. Master’s thesis, University of Linz. Referenziert auf S. 184
Gamma, E. und Eggenschwiler, T. (1996). The JHotDraw-Framework. online
http://www.jhotdraw.org/. Referenziert auf S. 15, 248, 249, 269
Gamma, E., Helm, R., Johnson, R., und Vlissides, J. (1995). Design patterns: elements
of reusable object-oriented software. Addison-wesley Reading, MA. Referenziert auf S. 219,
232, 236
551
Literaturverzeichnis
Gasser, L. (1986). The integration of computing and routine work. ACM Transactions on
Office Information Systems, 4(3):205–225. Referenziert auf S. 26, 28, 479
Gellersen, H., Kortuem, G., Schmidt, A., und Beigl, M. (2004). Physical prototyping with
smart-its. IEEE Pervasive Computing, 3(3):74–82. Referenziert auf S. 180
Gerson, E. (2004). The organization of reconciliation in distributed work. position paper
for workshop ”Distributed Collective Practices” at CSCW 04. Referenziert auf S. 485, 486
Gerson, E. und Star, S. (1986). Analyzing due process in the workplace. ACM Transactions
on Information Systems (TOIS), 4(3):257–270. Referenziert auf S. 3, 13, 23, 25, 28, 34, 35, 43,
479
Goguen, J. (1993). On Notation. Revised version of a paper in TOOLS 10: Technology of
Object-Oriented Languages and Systems, edited by Boris Magnusson, Bertrand Meyer
and Jean-Francois Perrot (Prentice-Hall, 1993), Department of Computer Science and
Engineering, University of California at San Diego. Referenziert auf S. 92
Griffin, A. und Hauser, J. (1992). Patterns of communication among marketing, enginee-
ring and manufacturing - a comparison between two new product teams. Management
Science, 38(3):360–373. Referenziert auf S. 1
Grinter, R. (1995). Using a configuration management tool to coordinate software de-
velopment. In Proceedings of conference on Organizational computing systems, Seiten
168–177. ACM Press. Referenziert auf S. 480
Grinter, R. (1996). Supporting articulation work using software configuration management
systems. Computer Supported Cooperative Work (CSCW), 5(4):447–465. Referenziert auf
S. 35, 50, 51, 52, 71, 83, 480, 481
Groeben, N. und Scheele, B. (2000). Dialog-Konsens-Methodik im Forschungsprogramm
Subjektive Theorien. Forum Qualitative Sozialforschung, 1(2). Referenziert auf S. 13
Gross, T. (2003). Ambient Interfaces: Design Challenges and Recommendations. Human
Factors and Ergonomics, Seite 68. Referenziert auf S. 123, 243
Grudin, J. (1988). Why CSCW applications fail: problems in the design and evaluationof
organizational interfaces. In Proceedings of the 1988 ACM conference on Computer-
supported cooperative work, Seiten 85–93. ACM. Referenziert auf S. 2, 4, 74, 96
Grudin, J. (1994). Computer-supported cooperative work: history and focus. Computer,
27(5):19 – 26. Referenziert auf S. 2
GS1 (2008). Introduction to GS1 DataMatrix. Guideline, GS1. Referenziert auf S. 187
552
Literaturverzeichnis
Hampson, I. und Junor, A. (2005). Invisible work, invisible skills: interactive customer
service as articulation work. New Technology, Work & Employment, 20(2):166 – 181.
Referenziert auf S. 26, 28, 31, 34, 35, 107, 487
Hanke, U. (2006). Externale Modellbildung als Hilfe bei der Informationsverarbeitung und
beim Lernen. PhD thesis, University of Freiburg. Referenziert auf S. 73, 78, 83, 84, 85
Hasu, M. (2005). In search of sensitive ethnography of change: Tracing the invisible hand-
offs from technology developers to users. Mind, Culture, and Activity, 12(2):90 – 112.
Referenziert auf S. 486
Helmberger, P. und Hoos, S. (1962). Cooperative enterprise and organization theory.
American Journal of Agricultural Economics, 44(2):275. Referenziert auf S. 1
Herrmann, T., Hoffmann, M., Kunau, G., und Loser, K. (2002). Modelling cooperative
work: Chances and risks of structuring. In Cooperative Systems Design, A Challenge of
the Mobility Age. Proceedings of COOP 2002, Seiten 53–70. IOS press. Referenziert auf S.
4, 61, 62, 63, 71, 72, 73, 83, 98, 102, 117, 484, 540
Herrmann, T., Hoffmann, M., Kunau, G., und Loser, K. (2004a). A modelling method
for the development of groupware applications as socio-technical systems. Behaviour &
Information Technology, 23(2):119–135. Referenziert auf S. 62, 337
Herrmann, T., Hoffmann, M., Loser, K., und Moysich, K. (2000). Semistructured models
are surprisingly useful for user-centered design. In Dieng, R., Giboin, A., Karsenty,
L., und De Michelis, G., editors, Designing Cooperative Systems. Proceedings of COOP
2000, Seiten 159–174, Amsterdam. IOS press. Referenziert auf S. 63
Herrmann, T., Kunau, G., Loser, K., und Menold, N. (2004b). Socio-technical walkthrough:
designing technology along work processes. In Artful integration: interweaving media,
materials and practices. Proceedings of the eighth Conference on Participatory design.,
Seiten 132–141. ACM Press New York, NY, USA. Referenziert auf S. 62
Holmquist, L., Redström, J., und Ljungstrand, P. (1999). Token-Based Acces to Digital
Information. In Proceedings of the 1st international Symposium on Handheld and Ubi-
quitous Computing, Seiten 234–245. Springer-Verlag London, UK. Referenziert auf S. 131,
137, 152, 158, 308, 327, 459
Holzner, S. (2004). Eclipse. O’Reilly Germany. Referenziert auf S. 248
Hornecker, E. (2001). Graspable interfaces as tool for cooperative modelling. In Proceedings
of IRIS, volume 24, Seiten 215–228. Referenziert auf S. 125
Hornecker, E. (2004). Tangible User Interfaces als kooperationsunterstützendes Medium.
Phd-Thesis, University of Bremen. Dept. of Computing. Referenziert auf S. 125, 126, 127,
129, 344, 348
553
Literaturverzeichnis
Hughes, F. (1971). The Sociological Eye. Aldine de Gruyter. Referenziert auf S. 3, 24, 26
Huss, J. (2003). Diagnose und Unterstützung mentaler Wissensrepräsentationen in Pro-
jektteams - Eine Fallstudie. Master’s thesis, Technical University of Berlin. Referenziert
auf S. 86, 89, 91
Ifenthaler, D. (2006). Diagnose lernabhängiger Veränderung mentaler Modelle - Entwick-
lung der SMD-Technologie als methodologisches Verfahren zur relationalen, strukturellen
und semantischen Analyse individueller Modellkonstruktionen. PhD thesis, University
of Freiburg. Referenziert auf S. 13, 78, 79, 81, 82, 83, 85, 88, 89, 90, 91, 92, 95, 98, 331, 434, 473, 540
Ishii, H. (2008). Tangible bits: beyond pixels. In Proceedings of the 2nd international
conference on Tangible and embedded interaction. ACM New York, NY, USA. Referenziert
auf S. 131, 152, 153, 154, 155, 156, 158, 159, 324, 540
Ishii, H. und Ullmer, B. (1997). Tangible bits: towards seamless interfaces between people,
bits and atoms. In Proceedings of the SIGCHI conference on Human factors in computing
systems (CHI), Seiten 234–241. ACM Press New York, NY, USA. Referenziert auf S. 123,
131, 135, 158, 162, 163, 306, 307, 327, 459
ISO JTC1/SC31 (2006). Information technology – automatic identification and data cap-
ture techniques – qr code 2005 bar code symbology specification. International Standard
18004:2006, ISO/IEC. Referenziert auf S. 176, 187
ISO JTC1/SC34 (2008). Topic Maps Constraint Language. draft standard, ISO/IEC.
Referenziert auf S. 281
ISO JTC1/SC34/WG3 (2006). Information Technology - Topic Maps - Part 3: XML
Syntax. International standard, ISO. Referenziert auf S. 291
ISO JTC1/SC34/WG3 (2008). Information Technology - Topic Maps - Part 2: Data Model.
International Standard 13250-2, ISO/IEC. Referenziert auf S. 15, 272, 273, 276, 291
James, M. (1997). Microcontroller Cookbook - PIC & 8051. Butterworth-Heinemann.
Referenziert auf S. 180
Johnson-Laird, P. N. (1981). Mental models in cognitive science. Cognitive Science,
4(1):71–115. Referenziert auf S. 13, 78
Jordan, B. und Henderson, A. (1995). Interaction Analysis: Foundations and Practice.
The Journal of the Learning Sciences, 4(1):39–103. Referenziert auf S. 344, 348
Jørgensen, H. (2004). Interactive Process Models. PhD thesis, Department of Computer
and Information Sciences, Norwegian University of Science and Technology Trondheim.
Referenziert auf S. 4, 67, 68, 71, 72, 73, 83, 92, 98, 102, 117, 331, 467, 486, 491
554
Literaturverzeichnis
Kaghan, W. und Lounsbury, M. (2004). Articulation Work and the Institutional Elements
of Organizational Artifacts: The Case of Contracts and Contracting. preprint, to appear
in: Rafaeli, a. & pratt, m.: Artifacts and organizations, Cornell University. Referenziert
auf S. 487
Kaghan, W. N. und Lounsbury, M. (2006). Artifacts, articulation work, and institutional
residue. In Rafaeli, A. und Pratt, M. G., editors, Artifacts and organizations: Beyond
mere symbolism., Seiten 259 – 275. Lawrence Erlbaum Associates Publishers. Referenziert
auf S. 487
Kaltenbrunner, M. und Bencina, R. (2007). reacTIVision: a computer-vision framework
for table-based tangible interaction. In TEI ’07: Proceedings of the 1st international
conference on Tangible and embedded interaction, Seiten 69–74, New York, NY, USA.
ACM Press. Referenziert auf S. 15, 188, 236
Kaltenbrunner, M., Jorda, S., Alonso, M., und Geiger, G. (2006). The reactable*: A col-
laborative musical instrument. In Proceedings of WETICE ’06. IEEE Press. Referenziert
auf S. 164, 243, 245
Kato, H., Billinghurst, M., Poupyrev, I., Imamoto, K., und Tachibana, K. (2000). Virtual
object manipulation on a table-top AR environment. In IEEE and ACM Internatio-
nal Symposium on Augmented Reality, 2000.(ISAR 2000). Proceedings, Seiten 111–119.
Referenziert auf S. 176, 187
Kim, D. (1993). A Framework and Methodology for Linked Individual and Organisational
Learning: Applications in TQM and Product Development. PhD thesis, Sloan School of
Managment, Massachusetts Institute of Technology. Referenziert auf S. 2, 84, 107
Klemmer, S., Li, J., Lin, J., und Landay, J. (2004). Papier-mâché: Toolkit support for
tangible input. CHI Letters, Human Factors in Computing Systems: CHI2004., 6(1).
Referenziert auf S. 131, 149, 183, 319, 320
Klemmer, S., Newman, M., Farrell, R., Bilezikjian, M., und Landay, J. (2001). The desi-
gners’ outpost: a tangible interface for collaborative web site. In Proceedings of the 14th
annual ACM symposium on User interface software and technology, Seiten 1–10. ACM
Press New York, NY, USA. Referenziert auf S. 167
Klemmer, S., Thomsen, M., Phelps-Goodman, E., Lee, R., und Landay, J. (2002). Where
do web sites come from? capturing and interacting with design history. Human Factors
in Computing Systems, CHI Letters, 4(1). Referenziert auf S. 126, 167, 401
Kling, R. und Star, S. (1998). Human centered systems in the perspective of organizational
and social informatics. ACM SIGCAS Computers and Society, 28(1):22–29. Referenziert
auf S. 481
555
Literaturverzeichnis
Kluwe, R. H. (1990). Wissen. In Sarges, W., editor, Management-Diagnostik, Seiten
174–181. Hogrefe, Göttingen. Referenziert auf S. 89
Koleva, B., Benford, S., Ng, K., und Rodden, T. (2003). A Framework for Tangible User
Interfaces. In Workshop-Proceedings on Real World User Interfaces, Mobile HCI Confe-
rence 03, Seiten 257–264. Referenziert auf S. 131, 145, 158, 314, 326
Krasner, G. und Pope, S. (1988). A cookbook for using the model-view controller user
interface paradigm in Smalltalk-80. Journal of Object-oriented programming, 1(3):26–49.
Referenziert auf S. 248
Kumar, K. und Van Dissel, H. (1996). Sustainable collaboration: managing conflict and
cooperation in interorganizational systems. MIS Quarterly, 20(3):279–300. Referenziert
auf S. 1
Larkin, J. und Simon, H. (1987). Why a diagram is (sometimes) worth ten thousand words.
Cognitive science, 11(1):65–100. Referenziert auf S. 357, 364
Larsen, S. B. und Bardram, J. E. (2008). Competence articulation: alignment of competen-
ces and responsibilities in synchronous telemedical collaboration. In CHI ’08: Proceeding
of the twenty-sixth annual SIGCHI conference on Human factors in computing systems,
Seiten 553–562, New York, NY, USA. ACM. Referenziert auf S. 488
Lave, J. und Wenger, E. (1991). Situated learning: Legitimate peripheral participation.
Cambridge University Press. Referenziert auf S. 60
Lenoir, T. (1994). Was the last turn the right turn? the semiotic turn and a. j. greimas.
Configurations, 2(1):119–136. Referenziert auf S. 480
Leont’ev, A. (1972). The Problem of Activity in Psychology. Voprosy filosofii (english
translation), (9):95–108. Referenziert auf S. 29, 55
Leont’ev, A. (1978). Activity, Consciousness, and Personality. Prentice-Hall. Referenziert
auf S. 28, 86
Maier, M. (2008). Organizational Memories - Konzepte und Realisierungen. Master’s
thesis, University of Linz. Referenziert auf S. 83, 485
Mandl, H. und Fischer, F. (2000). Mapping-Techniken und Begriffsnetze in Lern-und
Kooperationsprozessen. In Mandl, H. und Fischer, F., editors, Wissen sichbar machen.
Hogrefe. Referenziert auf S. 91
Mark, G., Gonzalez, V. M., Sarini, M., und Simone, C. (2002a). Reconciling Different
Perspectives: An Experiment on Technology Support for Articulation. In Blay-Fornarino,
M., Pinna-Dery, A., Schmidt, K., und Zaraté, P., editors, Proceedings of COOP 2002:
Cooperative Systems Design: A Challenge of the Mobility Age, Fontiers in Artificial
Intelligence and Applications, Seiten 23–37. IOS Press. Referenziert auf S. 65, 484
556
Literaturverzeichnis
Mark, G., Gonzalez, V. M., Sarini, M., und Simone, C. (2002b). Supporting articulation
with the reconciler. In CHI Extended Abstracts 2002, Seiten 814–815. Referenziert auf S.
484
Marshall, P. (2007). Do tangible interfaces enhance learning? In TEI ’07: Proceedings of
the 1st international conference on Tangible and embedded interaction, Seiten 163–170,
New York, NY, USA. ACM Press. Referenziert auf S. 124, 540
Mayrhauser, G. (2010). Abbildung der Content Struktur einer eLearning-Plattform auf
Semantische Netze. Master’s thesis, University of Linz. Referenziert auf S. 281
McAffer, J. und Lemieux, J. (2005). Eclipse Rich Client Platform: Designing, Coding, and
Packaging Java (TM) Applications. Addison-Wesley Professional. Referenziert auf S. 250
Mi, P. und Scacchi, W. (1991). Modeling Articulation Work in Software Engineering
Processes. In Proceedings of the First International Conference on the Software Process,
Seiten 188–201. IEEE Press. Referenziert auf S. 45, 46, 479, 540
Montessori, M. (2005). The Montessori Method. Kessinger Publishing. Referenziert auf S.
123, 168
Moore, B., Dean, D., Gerber, A., Wagenknecht, G., und Vanderheyden, P. (2004). Eclipse
Development using the Graphical Editing Framework and the Eclipse Modeling Frame-
work. Ibm redbooks, IBM. Referenziert auf S. 248, 269
Mori, R., Toda, N., Wada, Y., Ogawa, T., Kenmotsu, A., Nakamura, M., Eguchi, M.,
Yamamoto, T., Kobayashi, K., Narita, A., Hirano, M., Nakanishi, H., Tanaka, K., Ka-
se, I., und Ishii, H. (2004). Tangible business process analyzer. project description.
Referenziert auf S. 167
Nardi, B. und Kaptelinin, V. (2006). Acting with Technology - Activity Theory and Inter-
action Design. MIT Press. Referenziert auf S. 29
Neubauer, M. (2008). Abbildung generischer Modelle auf Topic Maps. Master’s thesis,
University of Linz. Referenziert auf S. 281, 290, 293
Neubauer, M., Stary, C., und Oppl, S. (2009). Towards topic map-based e-learning envi-
ronments (poster). In Proceedings of TMRA 2009. Referenziert auf S. 474
Nonaka, I. und Takeuchi, H. (1995). The Knowledge-Creating Company: How Japanese
Companies Create the Dynamics of Innovation. Oxford University Press. Referenziert auf
S. 26, 94
Norman, D. (1983). Some observations on mental models. In Gentner, D. und Stevens,
A., editors, Mental models, Seiten 7–14. Lawrence Erlbaum Associates. Referenziert auf S.
80, 81, 252
557
Literaturverzeichnis
Norman, D. (1990). The design of everyday things. Doubleday/Currency. Referenziert auf S.
459
Novak, J. und Cañas, A. J. (2006). The theory underlying concept maps and how to con-
struct them. Technical Report IHMC CmapTools 2006-01, Florida Institute for Human
and Machine Cognition. Referenziert auf S. 13, 91, 92, 93, 94, 95, 100, 331, 474, 540
Olesen, F. und Markussen, R. (2003). Reconfigured medication: Writing medicine in a
sociotechnical practice. Configurations, 11(3):351–381. Referenziert auf S. 485
Oppl, S. (2004). Context-aware Group-Interaction. Master’s thesis, University of Linz,
Department for Pervasive Computing. Referenziert auf S. 183
Oppl, S. (2006). Towards Intuitive Work Modeling with a Tangible Collaboration Interface
Approach. In Proceedings of WETICE ’06. IEEE Press. Referenziert auf S. 542
Oppl, S. (2007a). Flexibility of Content for Organisational Learning - A Topic Map Ap-
proach. Master’s thesis, University of Linz. Referenziert auf S. 272, 281, 290, 291, 293, 542
Oppl, S. (2007b). Spielen Sie noch? - Bausteine im Unternehmenskontext. In Paul-Stueve,
T., editor, Workshop-Proceedings der 7. fachübergreifenden Konferenz Mensch und Com-
puter 2007. Verlag der Bauhaus-Universität Weimar. Referenziert auf S. 542
Oppl, S. (2008a). Begreifbare Modellierung von Arbeit. In Workshop-Proceedings der 8.
fachübergreifenden Konferenz Mensch und Computer 2008. logos Verlag. Referenziert auf
S. 543
Oppl, S. (2008b). Graspable work modeling. In Proceedings of Mensch und Computer
2008. Oldenbourg Verlag. Referenziert auf S. 543
Oppl, S. (2009a). A Tabletop Interface to support Concept Mapping. In Proceedings of
EduMedia 2009. Salzburg Research. Referenziert auf S. 474, 543
Oppl, S. (2009b). Konsistente Verwendung von Metaphern als Erfolgskriterium für kom-
plexe Tangible User Interfaces. In Workshop-Proceedings der 9. fachübergreifenden Kon-
ferenz Mensch und Computer 2009. Referenziert auf S. 159, 326, 460, 474, 543
Oppl, S. (2009c). Unterstützung expliziter Articulation Work – Statement of Interest for
Participation in the Session on disruptive or seamless HCI in eLearning. In Proceedings of
IATEL (Interdisciplinary approaches to technology-enhanced learning). TU Darmstadt.
Referenziert auf S. 543
Oppl, S. (2009d). Using a Tangible Tabletop Interface to facilitate Articulation Work. In
Dillenbourg, P. und Shen, C., editors, Proceedings of the STELLAR Alpine Rendez-Vous
Workshop on Tabletops for Education and Training. STELLAR. Referenziert auf S. 543
558
Literaturverzeichnis
Oppl, S. (2010). Unterstützung expliziter Articulation Work durch Externalisierung von
Arbeitswissen. In Peschl, M. und Risku, H., editors, Kognition und Technologie im
kooperativen Lernen, Vienna University Press, Seiten 33–56. Vandenhoeck & Ruprecht.
Referenziert auf S. 543
Oppl, S. und Peherstorfer, P. (2007). Human Intervention in cross-organizational Pro-
cess Development. In Proceedings of the 4th International Conference on Knowledge
Management (ICKM 2007). Referenziert auf S. 542
Oppl, S. und Stary, C. (2005). Towards Human-Centered Design of Diagrammatic Repre-
sentation Schemes. In Dix, A. und Dittmar, A., editors, Proceedings of the 4th Interna-
tional Workshop on Task Models and Diagrams for User Interface Design (TAMODIA
2005), Seiten 55–62. ACM Press New York, NY, USA. Referenziert auf S. 283, 542
Oppl, S. und Stary, C. (2009). Tabletop concept mapping. In Proceedings of the 3rd
International Conference on Tangible and Embedded Interaction (TEI ’09). ACM Press.
Referenziert auf S. 474, 543
Oppl, S., Stary, C., und Auinger, A. (2006). Towards Tangible Work Modeling. In Procee-
dings of Mensch und Computer 2006, Seiten 400–405. Oldenburg Wissenschaftsverlag.
Referenziert auf S. 542
Oppl, S., Steiner, C., und Albert, D. (2010). Supporting Self-regulated Learning with Table-
top Concept Mapping. In Interdisciplinary approaches to technology-enhanced learning.
Waxmann Verlag. Referenziert auf S. 474, 544
Oppl, S. und Weichhart, G. (2005). Requirements for Collaborative Process Design. In
Auinger, A., editor, Workshop-Proceedings der 5. fachuebergreifenden Konferenz Mensch
und Computer 2005, volume 197 of books@ocg.at, Seiten 15–22. OCG. Referenziert auf S.
104
Papert, S. (2000). What’s the Big Idea: Towards a Pedagogy of Idea Power. IBM Systems
Journal, 39(3-4):720–729. Referenziert auf S. 123
Patten, J. und Ishii, H. (2007). Mechanical constraints as computational constraints in
tabletop tangible interfaces. In Proceedings of the SIGCHI conference on Human factors
in computing systems (CHI ’07), Seiten 809–818, New York, NY, USA. ACM. Referenziert
auf S. 123
Patten, J., Ishii, H., Hines, J., und Pangaro, G. (2001). Sensetable: a wireless object
tracking platform for tangible interfaces. In Proceedings of the ACM Conference on
Human Factors in Computing Systems 2001 (CHI ’01). Referenziert auf S. 163, 167
Pedersen, E. W. und Hornb, K. (2009). mixitui: a tangible sequencer for electronic live
performances. In TEI ’09: Proceedings of the 3rd International Conference on Tangible
559
Literaturverzeichnis
and Embedded Interaction, Seiten 223–230, New York, NY, USA. ACM. Referenziert auf
S. 243, 245
Pepper, S. (2000). The tao of topic maps. In Proceedings of XML Europe. Referenziert auf
S. 272
Phua, F. und Rowlinson, S. (2004). How important is cooperation to construction project
success? A grounded empirical quantification. Engineering Construction and Architec-
tural Management, 11(1):45–54. Referenziert auf S. 1
Piaget, J. (1976). Die Äquilibration der kognitiven Strukturen. Klett-Cotta. Referenziert auf
S. 79, 123
Pirnay-Dummer, P. N. (2006). Expertise und Modellbildung - MITOCAR. PhD thesis,
University of Freiburg. Referenziert auf S. 78, 83
Price, S., Rogers, Y., Scaife, M., Stanton, D., und Neale, H. (2003). Using ‘tangibles’ to
promote novel forms of playful learning. Interacting with Computers, 15(2):169–185.
Referenziert auf S. 124
Raposo, A., Gerosa, M., und Fuks, H. (2004). Combining Communication and Coordi-
nation Toward Articulation of Collaborative Activities. In Proceedings of Groupware:
Design, Implementation, and Use: 10th International Workshop, CRIWG 2004. Springer.
Referenziert auf S. 2, 25, 66, 71, 98, 485, 486
Raposo, A. und Hugo, F. (2002). Defining task interdependencies and coordination me-
chanisms for collaborative systems. In Proceedings of COOP 2002, Seiten 88–113. IOS
Press. Referenziert auf S. 484
Raposo, A., Magalhães, L., Ricarte, I., und Fuks, H. (2001). Coordination of collaborative
activities: A framework for the definition of tasks interdependencies. In Proceeding of
the 7th International Workshop on Groupware-CRIWG. Referenziert auf S. 71, 484
Rath, H. (2003). The Topic Maps Handbook. empolis GmbH. Referenziert auf S. 272
Red Hat Middleware (2007). Hibernate Reference Documentation. Reference documenta-
tion, Red Hat Middleware. Referenziert auf S. 291
Resnick, M., Martin, F., Berg, R., Borovoy, R., Colella, V., Kramer, K., und Silverman,
B. (1998). Digital manipulatives: new toys to think with. In Proceedings of the SIGCHI
conference on Human factors in computing systems, Seiten 281–287, New York, NY,
USA. ACM Press. Referenziert auf S. 123
Rodden, T. (1995). The COMIC Project - Computer-based
Mechanisms of Interaction in Cooperative Work. online:
http://www.comp.lancs.ac.uk/computing/research/softeng/comic/, ESPRITBasicresearchProject622S.ReferenziertaufS. 480, 489
560
Literaturverzeichnis
Rohs, M. (2005). Visual code widgets for marker-based interaction. In 25th IEEE Interna-
tional Conference on Distributed Computing Systems Workshops, 2005, Seiten 506–513.
IEEE Press. Referenziert auf S. 187
Rohs, M. und Gfeller, B. (2004). Using camera-equipped mobile phones for interacting
with real-world objects. In Advances in Pervasive Computing, Seiten 265–271. Austrian
Computer Society (OCG). Referenziert auf S. 188, 540
Roy, M. (2001). Small group communication and performance: do cognitive flexibility and
context matter? Management Decision, 39(4):323–330. Referenziert auf S. 1, 2
Rumbaugh, J., Jacobson, I., und Booch, G. (2004). Unified Modeling Language Reference
Manual, The. Pearson Higher Education. Referenziert auf S. 284, 288
Rumelhart, D. und Norman, D. (1978). Accretion, tuning, and restructuring: Three modes
of learning. In Cotton, J. und Klatzky, R., editors, Semantic factors in cognition, Seiten
37–53. Erlbaum, Hillsdale, N.J. Referenziert auf S. 73
Sachs, P. (1995). Transforming work: collaboration, learning, and design. Communications
of the ACM, 38(9):36–44. Referenziert auf S. 37
Sacks, H., Schegloff, E., und Jefferson, G. (1974). A simplest systematics for the orga-
nization of turn-taking for conversation. Language, 50(4):696–735. Referenziert auf S.
406
Sarini, M. (2003). Alignment of meanings and of protocols as a form of articulation work
in cooperation. PhD thesis, University of Torino. Referenziert auf S. 54, 485
Sarini, M. und Simone, C. (2002a). Recursive articulation work in ariadne: The alignment
of meanings. In Proceedings of COOP 2002, Seiten 191–206. Referenziert auf S. 4, 27, 34,
64, 65, 69, 70, 71, 72, 83, 95, 98, 103, 485, 486
Sarini, M. und Simone, C. (2002b). The Reconciler: supporting actors in meaning negotia-
tion. In Proceedings of the Workshop on Meaning Negotiation (MeaN-02) at AAAI-02.
Referenziert auf S. 71, 485
Scheele, B. und Groeben, N. (1988). Dialog-Konsens-Methoden zur Rekonstruktion Sub-
jektiver Theorien Die Heidelberger Struktur-Lege-Technik (SLT), konsensuale Ziel-
Mittel-Argumentation und kommunikative Flussdiagramm-Beschreibung von Handlun-
gen. Francke, Tuebingen. Referenziert auf S. 89, 90, 99, 100
Scheer, A. und Nuettgens, M. (2000). Aris architecture and reference models for business
process management. Business Process Management: Models, Techniques, and Empirical
Studies, Seiten 376–389. Referenziert auf S. 337
561
Literaturverzeichnis
Scheer, A.-W. (2003). ARIS – Business Process Modeling. Springer, 3 edition. Referenziert
auf S. 288
Schilit, B., Adams, N., und Want, R. (1994). Context-aware computing applications. In
Proceedings of the Workshop on Mobile Computing Systems and Applications, Seiten
85–90. Referenziert auf S. 182
Schmidt, K. (1990). Analysis of Cooperative Work. A Conceptual Framework. Technical
Report Risø-M-2890, Risø National Laboratory. Referenziert auf S. 26, 52, 479, 480, 481
Schmidt, K. (1994). Cooperative Work and its Articulation. Travail Humain,
57(4):345–366. Referenziert auf S. 1, 23, 24, 71, 480
Schmidt, K. (2002). The problem with ‘awareness’. Computer Supported Cooperative Work,
11(3):285–298. Referenziert auf S. 485
Schmidt, K. und Bannon, L. (1992). Taking CSCW seriously: Supporting Articulation
Work. Computer Supported Cooperative Work (CSCW), 1(1):7–40. Referenziert auf S. 2, 4,
35, 48, 49, 50, 52, 58, 62, 64, 479, 480, 481, 483
Schmidt, K. und Simone, C. (1996). Coordination mechanisms: Towards a concep-
tual foundation of CSCW systems design. Computer Supported Cooperative Work,
5(2/3):155–200. Referenziert auf S. 41, 42, 52, 53, 54, 56, 58, 480, 481, 482, 483, 540
Schmidt, K. und Simone, C. (1999). Cooperative work is seamless: Integrating the sup-
port of the many modalities of articulation work. Working paper 52, Center for Tele-
Information. Referenziert auf S. 482
Schmidt, K. und Simone, C. (2000). Mind the Gap!: Towards a unified view of CSCW.
In Proceedings of COOP2000: The Fourth International Conference on the Design of
Cooperative Systems, Sophia Antipolis, France. INRIA. Referenziert auf S. 30, 34, 40, 71, 92,
483
Schmidt, K., Simone, C., Divitini, M., Carstensen, P., und Sørensen, C. (1995). A ‘contrat
sociale’ for cscw systems. Working paper, Roskilde University. Referenziert auf S. 480
Schön, D. (1984). The Reflective Practitioner: How Professionals Think In Action. Basic
Books. Referenziert auf S. 124
Sedera, W., Rosemann, M., und Gable, G. (2002). Measuring process modelling success.
In Proceedings of the 10th European Conference of Information Systems, Seiten 331–341.
Referenziert auf S. 403, 434, 435
Seel, N. (2003a). Model-centered learning and instruction. Technology, Instruction, Co-
gnition and Learning, 1(1):59–85. Referenziert auf S. 474
562
Literaturverzeichnis
Seel, N. (2003b). Psychologie des Lernens. Ernst Reinhardt Verlag, München Basel, 2nd
edition. Referenziert auf S. 78, 474
Seel, N. M. (1991). Weltwissen und mentale Modelle. Hogrefe, Göttingen u.a. Referenziert
auf S. 13, 20, 73, 77, 78, 80, 83, 84, 85, 94, 116
Seiringer, G. (2008). Entwicklung eines Editors für die Erstellung und Visualisierung von
Topic Maps. Master’s thesis, University of Linz. Referenziert auf S. 248
Semmer, N. und Udris, I. (2004). Bedeutung und Wirkung von Arbeit. In Schuler, H.,
editor, Lehrbuch Organisationspsychologie, Seiten 157–195. Huber, Bern, 3rd edition.
Referenziert auf S. 1, 23
Senge, P. (1990). The Fifth Discipline: The Art and Practice of the Learning Organization.
Doubleday/Currency. Referenziert auf S. 84, 88
Senge, P., Kleiner, A., Roberts, C., und Smith, B. (1994). The fifth discipline fieldbook:
Strategies and tools for building a learning organization. Broadway Business. Referenziert
auf S. 88
Shaer, O., Leland, N., Calvillo-Gamez, E., und Jacob, R. (2004). The TAC paradigm:
specifying tangible user interfaces. Personal and Ubiquitous Computing, 8(5):359–369.
Referenziert auf S. 131, 147, 157, 158, 159, 316, 326, 458, 460
Shapiro, S. und Wilk, M. (1965). An analysis of variance test for normality. Biometrika,
52(3):591–599. Referenziert auf S. 345
Shinar, J. (2004). Organic light-emitting devices: a survey. Springer. Referenziert auf S. 242
Shipman, F. und Hsieh, H. (2000). Navigable history: a reader’s view of writer’s time. New
review of hypermedia and multimedia, 6(1):147–167. Referenziert auf S. 117, 118, 401
Simone, C. (2000). Making classification schemes a first class notion in cscw. In Proceedings
of the 1st CISCPH workshop on Cooperative Organization of Common Information
Spaces. Referenziert auf S. 483, 484, 489
Simone, C. (2002). Unifying or reconciling when constructing organizational memory? some
open issues. In Knowledge management and organizational memories, Seiten 137–143.
Kluwer Academic Publishers. Referenziert auf S. 485
Simone, C. und Bandini, S. (1997). Compositional features for promoting awareness within
and across cooperative applications. In Proceedings of GROUP ’97, Seiten 358–367, New
York, NY, USA. ACM. Referenziert auf S. 481
Simone, C. und Divitini, M. (1997). Ariadne: Supporting Coordination through a Flexible
Use of the Knowledge on Work Processes. Journal of Universal Computer Science,
3(8):865–898. Referenziert auf S. 481
563
Literaturverzeichnis
Simone, C., Divitini, M., und Schmidt, K. (1995). A notation for malleable and inter-
operable coordination mechanisms for CSCW systems. In Proceedings of conference on
Organizational computing systems, Seiten 44–54. ACM New York, NY, USA. Referenziert
auf S. 481
Simone, C., Mark, G., und Giubbilei, D. (1999). Interoperability as a means of articulation
work. ACM SIGSOFT Software Engineering Notes, 24(2):39–48. Referenziert auf S. 4, 482,
483
Simone, C. und Sarini, M. (2001). Adaptability of classification schemes in cooperati-
on: what does it mean? In Proceedings of the 2nd CISCPH workshop on Cooperative
Organization of Common Information Spaces. Referenziert auf S. 484
Sparrer, I. (2002). Wunder, Lösung und System. Carl-Auer-Systeme Verl. Referenziert auf
S. 413, 474
Stachowiak, H. (1973). Allgemeine Modelltheorie. Springer Wien. Referenziert auf S. 84, 90,
273
Star, S. L. (1989). The structure of ill-structured solutions: boundary objects and hetero-
geneous distributed problem solving. Seiten 37–54. Referenziert auf S. 129
Star, S. L. und Strauss, A. (1999). Layers of silence, arenas of voice: The ecology of visible
and invisible work. Computer Supported Cooperative Work: The Journal of Collaborative
Computing, 8(1/2):9 – 30. Referenziert auf S. 25, 27, 32, 34, 35, 482
Stary, C. (1994). Interaktive Systeme: Softwareentwicklung und Softwareergonomie. Vieweg.
Referenziert auf S. 186
Strauss, A. (1985). Work and the Division of Labor. The Sociological Quarterly, 26(1):1–19.
Referenziert auf S. 1, 2, 3, 22, 23, 25, 34, 35, 77, 110, 479
Strauss, A. (1988). The Articulation of Project Work: An Organizational Process. The
Sociological Quarterly, 29(2):163–178. Referenziert auf S. 3, 25, 26, 34, 41, 77, 479
Strauss, A. (1993). Continual Permutations of Action. Aldine de Gruyter, New York.
Referenziert auf S. 2, 3, 4, 6, 13, 20, 25, 26, 29, 30, 32, 34, 35, 36, 72, 73, 77, 332, 480, 481
Suchman, L. (1987). Plans and Situated Actions: The Problem of Human-Machine Com-
munication. Cambridge University Press. Referenziert auf S. 53
Suchman, L. (1995). Making work visible. Communications of the ACM, 38(9):56–64.
Referenziert auf S. 2, 35
564
Literaturverzeichnis
Suchman, L. (1999). Supporting articulation work: Aspects of a feminist practice of office
technology production. In Kling, R., editor, Computerization and Controversy - value
conflicts and social choices, Seiten 407–423. Academic Press, Inc. Orlando, FL, USA.
Referenziert auf S. 35, 482
Suzuki, H. und Kato, H. (1995). Interaction-level support for collaborative learning: Algo-
Block—an open programming language. In Proceedings of the first international confe-
rence on Computer support for collaborative learning table of contents, Seiten 349–355,
Hillsdale, NJ, USA. L. Erlbaum Associates Inc. Referenziert auf S. 122
Tanenbaum, K. und Antle, A. N. (2009). A tangible approach to concept mapping. In Ao,
S.-I., editor, IAENG TRANSACTIONS ON ENGINEERING TECHNOLOGIES VO-
LUME 2: Special Edition of the World Congress on Engineering and Computer Science,
volume 1127, Seiten 121–132. AIP. Referenziert auf S. 91, 168
The LEGO Group (2002). Die Wissenschaft von LEGO SERIOUS PLAY. brochure, The
LEGO Group. Referenziert auf S. 124
Tsai, W. (2002). Social structure of ”coopetition” within a multiunit organization: Coordi-
nation, competition, and intraorganizational knowledge sharing. Organization Science,
13(2):179–190. Referenziert auf S. 1
Tyre, M. und Von Hippel, E. (1997). The situated nature of adaptive learning in organiza-
tions. Organization Science, 8(1):71–83. Referenziert auf S. 1
Ullmer, B. (2002). Tangible interfaces for manipulating aggregates of digital information.
PhD thesis, Massachusetts Institute of Technology. Referenziert auf S. 131, 143, 147, 157, 158,
159
Ullmer, B. und Ishii, H. (1997). The metaDESK: models and prototypes for tangible user
interfaces. In Proceedings of the 10th annual ACM symposium on User interface software
and technology, Seiten 223–232, New York. ACM Press. Referenziert auf S. 136, 142, 307
Ullmer, B. und Ishii, H. (2000). Emerging frameworks for tangible user interfaces. IBM
Systems Journal, 39(3):915–931. Referenziert auf S. 131, 140, 141, 145, 152, 158, 159, 163, 238,
310, 326, 457, 540
Ullmer, B., Ishii, H., und Jacob, R. (2005). Token + constraint systems for tangible in-
teraction with digital information. ACM Transactions on Computer-Human Interaction
(TOCHI), 12(1):81–118. Referenziert auf S. 143, 144, 152, 154, 312, 313, 324, 326, 540
Underkoffler, J. und Ishii, H. (1999). Urp: A luminous-tangible workbench for urban
planning and design. In Proceedings of the SIGCHI conference on Human factors in
computing systems: the CHI is the limit, Seiten 386–393. ACM New York, NY, USA.
Referenziert auf S. 131, 139, 152, 158, 166, 309, 326
565
Literaturverzeichnis
Van Laerhoven, K., Villar, N., Schmidt, A., Gellersen, H., Hakansson, M., und Holmquist,
L. (2003). Pin&Play: the surface as network medium. IEEE Communications Magazine,
41(4):90–95. Referenziert auf S. 180
Van Someren, M., Barnard, Y., und Sandberg, J. (1994). The think aloud method: A
practical guide to modelling cognitive processes. Academic Press. Referenziert auf S. 86, 87,
88
Vatant, B. (2004). Ontology-driven Topic Maps. In Proceedings of XML Europe 2004,
Amsterdam. Referenziert auf S. 272
Wagner, D. und Schmalstieg, D. (2003). ARToolKit on the PocketPC platform. In IEEE
International Augmented Reality Toolkit Workshop, 2003, Seiten 14–15. IEEE Press.
Referenziert auf S. 191
Wahlmüller, P. (2010). Evaluation eines Werkzeugs zur Unterstützung von Articulation
Work in der Praxis. Master’s thesis, University of Linz. Referenziert auf S. 105, 339, 372,
403, 434, 493, 494, 506, 541
Weiser, M. (1991). The computer for the 21st century. Scientific American, 265. Referenziert
auf S. 123, 135, 182
Wellner, P. (1993). Interacting with paper on the DigitalDesk. Communications of the
ACM, 36:87–96. Referenziert auf S. 121, 162
Wellner, P., Mackay, W., und Gold, R. (1993). Computer-augmented environments. back
to the real world. Communications of the ACM, 36(7):24–26. Referenziert auf S. 162
Wenger, E. (1998). Communities of practice - learning as a social system. The Systems
Thinker, 9(5). Referenziert auf S. 484
Wenger, E. (1999). Communities of Practice: Learning, Meaning, and Identity. Cambridge
University Press. Referenziert auf S. 60, 61, 71, 82
ZigBee Alliance (2007). Zigbee Specification. Specification r17, ZigBee Alliance. Referenziert
auf S. 180
Zuckerman, O., Arida, S., und Resnick, M. (2005). Extending tangible interfaces for educa-
tion: digital montessori-inspired manipulatives. In Proceedings of the SIGCHI conference
on Human factors in computing systems (CHI), Seiten 859–868. ACM Press New York,
NY, USA. Referenziert auf S. 124, 168, 242
566
Stefan Oppl
Curriculum Vitae
Reithoffergasse 2d
4400 Steyr
H +43 660 44 32 616
B stefan@oppl.info
Persönliches
Geburtsdatum 10. August 1980
Familienstand verheiratet mit Sabrina
1 Sohn (Felix, geb. 2008)
Staats-
bürgerschaft
Österreich
Eltern Walter Oppl, Politiker
Ursula Oppl, Lehrerin
Ausbildung
seit 2006 Doktoratsstudium der technischen Wissenschaften in Informatik, Technische
Universität Wien, Interactive Media Systems Group, Wien.
2005 – 2007 MBA-Aufbaustudium für Angewandtes Wissensmanagement, Johannes Kepler
Universität, Linz.
2000 – 2004 Diplomstudium der Informatik, Johannes Kepler Universität, Linz.
1994 – 1999 BHS, HTL-Steyr, Abteilung für Elektronik – Ausbildungszweig Technische Informatik,
Steyr.
1990 – 1994 AHS Unterstufe, Bundesgymnasium Werndlpark, Steyr.
1986 – 1990 Volksschule, Volksschule 2 Ennsleite, Steyr.
Abschlüsse & Auszeichnungen
2007 Abschluss des Aufbaustudium für Angewandtes Wissensmanagement an der Johannes
Kepler Universität Linz mit ausgezeichnetem Erfolg
Masterarbeit: Flexibility of Content for Organisational Learning – A Topic Map Ap-
proach
Akad. Grad: Master of Business Administration (MBA)
2005 Würdigungspreis der Bundesministerin für Bildung, Wissenschaft und Kultur für her-
vorragende Studienleistungen
2004 Abschluss des Diplomstudiums Informatik an der Johannes Kepler Universität Linz
mit ausgezeichnetem Erfolg
Diplomarbeit: Context-aware Group-Interaction, Institut für Pervasive Computing
Akad. Grad: Diplom-Ingenieur (Dipl.-Ing)
2002 – 2004 Dreimaliger Empfänger eines Leistungsstipendiums der Johannes Kepler Universität
Linz
1999 Reifeprüfung an der HTL Steyr (Abteilung für Elektronik - Ausbildungszweig Tech-
nische Informatik) mit ausgezeichnetem Erfolg
Berufliche Erfahrungen
seit 2005 wissenschaftlicher Mitarbeiter, Institut für Wirtschaftsinformatik - Communica-
tions Engineering, Johannes Kepler Universität Linz.
Forschung und Lehre im Bereich der Modellierung, Gestaltung und Implementierung interak-
tiver Systeme
seit 2007 externer Lehrbeauftragter, FH Campus Steyr, FH OÖ Studienbetriebs GmbH.
Lehre in den Gebieten „Einführung IT“, „Mobile Computing“ und „Wissenschaftliches Ar-
beiten“
2003 – 2005 Projektassistent, Institut für Pervasive Computing, Johannes Kepler Universität Linz.
Arbeitsgebiete: mobiles Lernen, kontextsensitive Anwendungen für mobile Endgeräte
2003 – 2004 Tutor für die Lehrveranstaltung „Telekooperation“, Institut für Pervasive Com-
puting, Johannes Kepler Universität Linz.
Studierendenbetreuung, Übungs-Korrektur
Sommer
2000 – 2004
2x Rettungssanitäter, OÖ Rotes Kreuz, Bezirksstelle Steyr-Stadt.
Sanitäter, Einsatzfahrer
Sommer
2000 – 2004
2x Jugendbetreuer, Kinderfreunde OÖ, in Zusammenarbeit in der Jugendwohlfahrt
OÖ.
Betreuer bei Erholungsferien für Kinder aus schwierigen Verhätnissen
Juli – August
1998
Ferialarbeit, Steyr Daimler Puch Engineering Centre – Abteilung für Akustik und
Schwingungstechnik, Steyr Daimler Puch (heute: Magna Powertrain).
Juli 1997 Ferialpraktikum, Ennskraftwerke AG, Steyr.
Juli 1996 Ferialpraktikum, BMD Computer Systemhaus, Steyr.
Präsenzdienst
September 1999
- April 2000
Sanitätsgehilfe, Salzburg and Kirchdorf.
Projekte
MobiLearn Projektmitarbeiter, nationales Projekt in der NML-Initiative – www.mobilearn.at,
Institut für Pervasive Computing – JKU Linz, 2003-2004.
Entwicklung von mobil einsetzbaren Lernunterlagen zum Thema „Pervasive Computing“, As-
sistenz der Projektleitung
ONE
SmartSpace
Projektmitarbeiter, Industrie-Kooperation mit Fa. One (Mobilfunk-Anbieter), 2004-
2005, Institut für Pervasive Computing – JKU Linz.
Entwicklung und Implementierung von „smart living“- Szenarien im persönlichen Wohnumfeld
SiLiCon CON Projektmitarbeiter, Industrie-Kooperation mit Siemens Corporate Technology
München, 2003-2005, Institut für Pervasive Computing – JKU Linz.
Entwicklung und Implementierung von Anwendungsszenarien für kontext-sensitive Applikatio-
nen, Vorbereitung und Durchführung von Technologietransfer-Workshops
CrossWork Projektmitarbeiter, EU-Projekt (FP6 IST) – www.crosswork.info, 2005-2006, Insti-
tut für Wirtschaftsinformatik – Communications Engineering – JKU Linz.
operative Leitung der lokalen Arbeitsgruppe, Erhebung der Beschaffungs- und Vernet-
zungsprozesse der Industriepartner
SUddEN Projektmitarbeiter, EU-Projekt (FP6 IST) – www.sudden.biz, 2006-2008, Institut
für Wirtschaftsinformatik – Communications Engineering – JKU Linz.
Erhebung der Beschaffungs- und Vernetzungsprozesse und der Industriepartner, Mitarbeit an
der Entwicklung von Ansätzen zum Profiling und zur Entwicklung von Netzwerk-Kompetenzen
bei SMEs.
Sprachkenntnisse
Deutsch Fließend Muttersprache
Englisch Fließend in Wort und Schrift
IT-Kenntnisse
Betriebssysteme Windows, GNU/Linux, Mac OS X
System-
administration
GNU/Linux (Debian, Ubuntu)
Bürosoftware MS Office (Word, Excel, Powerpoint, Access), Openoffice (gesamte Suite), iWork
(gesamt Suite), LaTeX
Software-
entwicklung
Detailkenntnisse: Java, C, C++,
Grundkenntnisse: PHP, Bash Scripting, Objective C
Verteilte
Systeme
Apache Webserver,
Kryptographisch gesicherte Kommunikationskanäle (SSH, OpenPGP, . . . ),
CMS- und CSCW-Werkzeuge (Nuxeo, Typo3, CalDAV, MediaWiki, Wordpress, . . . )
Geschäfts-
prozess-
management
ARIS Business Architect (Modellierung, Simulation),
JCOM1 Suite (Modellierung, Simulation, Ausführung),
BPMN (Modellierung)
Publikationen
Abschlussarbeiten
S. Oppl. Context-aware Group-Interaction. Master’s thesis, University of Linz, Department for
Pervasive Computing, September 2004.
S. Oppl. Flexibility of Content for Organisational Learning - A Topic Map Approach. Master’s
thesis, University of Linz, May 2007.
Zeitschriftenbeiträge
C. Stary and S. Oppl. Konsistente Navigation in stationären und mobilen web-basierten Lehr-
& Lern-Umgebungen. Zeitschift für e-learning, 2(4), November 2007.
Buchbeiträge
S. Oppl. Unterstützung expliziter Articulation Work durch Externalisierung von Arbeitswissen.
In M.F. Peschl and H. Risku, editors, Kognition und Technologie im kooperativen Lernen, Vienna
University Press, pages 33–56. Vandenhoeck & Ruprecht, May 2010.
S. Oppl, P. Peherstorfer, and C. Stary. The User Perspective, Automotive Industry Use Cases. In
N. Mehandjiev and P. Grefen, editors, Dynamic Business Process Formation for Instant Virtual
Enterprises, Advanced Information and Knowledge Processing, chapter 9, 11. Springer, 2010.
S. Oppl, C. Steiner, and D. Albert. Supporting Self-regulated Learning with Tabletop Concept
Mapping. In Interdisciplinary approaches to technology-enhanced learning. to appear, 2010.
Konferenzbeiträge
A. Ferscha, C. Holzmann, and S. Oppl. Context awareness for Group Interaction Support. In
Proceedings of the 2nd International Workshop on Mobility Management and Wireless Access
Protocols (MobiWAC ’04), pages 88–97. ACM Press New York, NY, USA, September 2004.
A. Ferscha, C. Holzmann, and S. Oppl. Team Awareness in Personalized Learning Environments.
In Proceedings of MLearn 2004, July 2004.
S. Oppl and C. Stary. Towards Human-Centered Design of Diagrammatic Representation
Schemes. In A. Dix and A. Dittmar, editors, Proceedings of the 4th International Workshop on
Task Models and Diagrams for User Interface Design (TAMODIA 2005), pages 55–62. ACM
Press New York, NY, USA, September 2005.
S. Oppl and G. Weichhart. Requirements for Collaborative Process Design. In Andreas Auinger,
editor, Workshop-Proceedings der 5. fachuebergreifenden Konferenz Mensch und Computer
2005, volume 197 of books@ocg.at, pages 15–22. OCG, September 2005.
S. Oppl. Towards Intuitive Work Modeling with a Tangible Collaboration Interface Approach.
In Proceedings of WETICE ’06. IEEE Press, June 2006.
S. Oppl, C. Stary, and A. Auinger. Towards Tangible Work Modeling. In Proceedings of Mensch
und Computer 2006, pages 400–405. Oldenburg Wissenschaftsverlag, September 2006.
C. Stary, E. Stary, and S. Oppl. Inclusive Design of Ambient Knowledge Transfer. In Proceedings
of 9th ERCIM Workshop ’User Interfaces For All’. Springer, September 2006.
G. Weichhart, C. Stary, and S. Oppl. Modelling of Complex Supply Networks. In Proceedings
of WETICE ’06, pages 265–268. IEEE Press, June 2006.
F.G. Furtmüller and S. Oppl. A Tuple-Space based Middleware for Collaborative Tangible User
Interfaces. In Proceedings of WETICE ’07. IEEE Press, June 2007.
S. Oppl. Spielen Sie noch? - Bausteine im Unternehmenskontext. In T. Paul-Stueve, edi-
tor, Workshop-Proceedings der 7. fachübergreifenden Konferenz Mensch und Computer 2007.
Verlag der Bauhaus-Universität Weimar, September 2007.
S. Oppl and P. Peherstorfer. Human Intervention in cross-organizational Process Development.
In Proceedings of the 4th International Conference on Knowledge Management (ICKM 2007),
August 2007.
S. Oppl. Begreifbare Modellierung von Arbeit. In Workshop-Proceedings der 8. fachüber-
greifenden Konferenz Mensch und Computer 2008. logos Verlag, 2008.
S. Oppl. Graspable work modeling. In Proceedings of Mensch und Computer 2008. Oldenbourg
Verlag, 2008.
M. Neubauer, S. Oppl, and C. Stary. Towards Intuitive Modeling of Business Processes:
Prospects for Flow- and Natural-Language-Orientation. In Proceedings of Tamodia 2009.
Springer, September 2009.
S. Oppl. Konsistente Verwendung von Metaphern als Erfolgskriterium für komplexe Tangible
User Interfaces. In Workshop-Proceedings der 9. fachübergreifenden Konferenz Mensch und
Computer 2009, September 2009.
S. Oppl. Using a Tangible Tabletop Interface to facilitate Articulation Work. In Pierre
Dillenbourg and Chia Shen, editors, Proceedings of the STELLAR Alpine Rendez-Vous Workshop
on Tabletops for Education and Training. STELLAR, December 2009.
S. Oppl and C. Stary. Tabletop concept mapping. In Proceedings of the 3rd International
Conference on Tangible and Embedded Interaction (TEI ’09). ACM Press, February 2009.
Sonstiges
G. Weichhart, S. Oppl, and T. Waefler. Flexible and responsive cross-organisational Interoper-
ability. In M. Taisch and K.D. Thoben, editors, Advanced Manufacturing - an ICT and Systems
Perspective, pages 158–170. Network of Excellence on Intelligent Manufacturing Systems, Oc-
tober 2005.
M. Neubauer, C. Stary, and S. Oppl. Towards topic map-based e-learning environments (poster).
In Proceedings of TMRA 2009, November 2009.
S. Oppl. A Tabletop Interface to support Concept Mapping. In Proceedings of EduMedia 2009.
Salzburg Research, May 2009.
S. Oppl. Unterstützung expliziter Articulation Work – Statement of Interest for Participation
in the Session on disruptive or seamless HCI in eLearning. In Proceedings of IATEL (Interdisci-
plinary approaches to technology-enhanced learning). TU Darmstadt, June 2009.
Lehre
Johannes Kepler Universität Linz
WS 2005/06 Übung Prozess- und Kommunikationsmodellierung (2 SWS)
Kompetenztraining Communications Engineering (2 SWS)
SS 2006 Übung Communications Engineering (2 SWS)
Seminar Communications Engineering (2 SWS)
WS 2006/07 Übung Prozess- und Kommunikationsmodellierung (2 SWS)
Seminar Communications Engineering (2 SWS)
SS 2007 Übung Communications Engineering (2 SWS)
Seminar Communications Engineering (2 SWS)
WS 2007/08 Übung Prozess- und Kommunikationsmodellierung (2 SWS)
Seminar Communications Engineering (2 SWS)
SS 2008 Übung Communications Engineering (2 SWS)
Seminar Communications Engineering (2 SWS)
WS 2008/09 Übung Prozess- und Kommunikationsmodellierung (2 SWS)
Seminar Communications Engineering (2 SWS)
SS 2009 Übung Prozess- und Kommunikationsmodellierung (2 SWS)
Übung Communications Engineering (2 SWS)
Seminar Wissensmanagement (2 SWS)
SS 20010 Übung Prozess- und Kommunikationsmodellierung (2 SWS)
Seminar Communications Engineering (2 SWS)
FH OÖ – Campus Steyr
SS 2007 Vorlesung Einführung in das wissenschaftliche Arbeiten (1 SWS)
2x Übung IT Introduction 2 - Software Development (2 SWS) – Unterricht in Englisch
WS 2007/08 Vorlesung Mobile Computing (1 SWS)
Übung IT Introduction 1 (2 SWS) – Unterricht in Englisch
SS 2008 2x Übung IT Introduction 2 - Software Development (2 SWS) – Unterricht in Englisch
WS 2007/08 Vorlesung Mobile Computing (1 SWS)
Vorlesung Mobile Computing (1 SWS) – Unterricht in Englisch
Übung IT Introduction 1 (2 SWS) – Unterricht in Englisch
SS 2009 Übung IT Introduction 2 - Software Development (2 SWS) – Unterricht in Englisch
WS 2007/08 Vorlesung Mobile Computing (1 SWS)
Vorlesung Mobile Computing (1 SWS) – Unterricht in Englisch
Vorlesung IT Introduction 1 (1 SWS) – Unterricht in Englisch
Übung IT Introduction 1 (2 SWS) – Unterricht in Englisch
SS 2009 Übung IT Introduction 2 - Software Development (2 SWS) – Unterricht in Englisch
Diplom- und Masterarbeiten (Mitbetreuung)
Stefan Berger-Schützender and Gernot Hammerle. Konzeption und Implementierung eines Infor-
mationsportals anhand der Communications Engineering Webseite. Master’s thesis, University
of Linz, April 2007.
Eva Doppelhammer. Prototypische Integration von Semantic Web-Technologien in einem Wiki.
Master’s thesis, University of Linz, June 2007.
Florian Georg Furtmüller. Implementierung eines Frameworks für berührbare Benutzungss-
chnittstellen. Master’s thesis, University of Linz, February 2007.
Sara Bartos. Inquiry-based learning in virtuellen Lernumgebungen. Master’s thesis, University
of Linz, October 2008.
Thomas Feiner. Modelleditor auf Basis dynamischer Metamodelle zur Unterstützung partizipa-
tiver Modellerfassung und -reflexion. Master’s thesis, University of Linz, April 2008.
Manuela Maier. Organizational Memories - Konzepte und Realisierungen. Master’s thesis,
University of Linz, June 2008.
Matthias Neubauer. Abbildung generischer Modelle auf Topic Maps. Master’s thesis, University
of Linz, March 2008.
Armin Sanders. Ein Portalentwicklungszyklus dargestellt anhand der Neukonstruktion der Seiten
"Aufbaustudium Angewandtes Wissensmanagement" und "Zentrum für Wissensmanagement".
Master’s thesis, University of Linz, October 2008.
Günter Seiringer. Entwicklung eines Editors für die Erstellung und Visualisierung von Topic
Maps. Master’s thesis, University of Linz, March 2008.
Georg Mayrhauser. Abbildung der Content Struktur einer eLearning-Plattform auf Semantische
Netze. Master’s thesis, University of Linz, 2010.
Patrick Wahlmüller. Evaluation eines Werkzeugs zur Unterstützung von Articulation Work in
der Praxis. Master’s thesis, University of Linz, May 2010.
Bachelorarbeiten
Christoph Rampetsreiter. Potential der elektronischen Datenübertragung mittels XML im B2B
Laborbereich. bachelor thesis, FH OÖ - Campus Steyr, 2009.
Nicole Reitmayr. Dezentrales Dokumentenmanagement mittels ECM. bachelor thesis, FH OÖ
- Campus Steyr, 2009.
Interessen
Sonstige Ausbildungen und Befähigungsnachweise
• Lenkerberechtigung Klasse A und B
• Amateurfunklizenz CEPT 1
• Sanitätsgehilfe (Rettungssanitäter mit Berufsberechtigung)
• Einsatzfahrerberechtigung
• Hochschuldidaktischer Lehrgang an der Johannes Kepler Universität Linz
• Lehrgang „Gruppen führen und leiten“, Fa. OE-263
• Lehrgang für Führungskräfte in Non-Profit-Organisationen, Kinderfreunde OÖ, u.a.
Ausbildung in Projektmanagement, Rhetorik, Führungskompetenz
• Segelschein Klasse A
Ehrenamtliche Tätigkeiten
seit 2009 Kindergruppenarbeit, Eltern-Kind-Zentrum Bärentreff, Steyr.
Leitung einer Vater-Kind-Gruppe
seit 1999 Rettungssanitäter, OÖ Rotes Kreuz – Bezirksstelle Steyr Stadt.
Sanitäter, Einsatzfahrer
1996 – 2004 Jugendgruppenarbeit, Kinderfreunde Bezirk Steyr und Land OÖ.
Landesvorsitzender der Roten Falken OÖ, Mitglied im Landesvorstand der Kinderfreunde OÖ
1994 – 1999 Schülervertreter, HTL Steyr.
u.a. Schulsprecher-Stv.
Sonstige Freizeitaktivitäten
• Landschafts- und Makrofotografie
• Nordic Walking
• Skilauf
Der eine fragt: Was kommt danach?
Der andre fragt nur: Ist es recht?
Und also unterscheidet sich
der Freie von dem Knecht.
Theodor Storm