PDF der Diplomarbeit - Professur Mediengestaltung

Transcription

Fakultät Informatik
Institut für Software- und Multimediatechnik
Professur für Mediengestaltung
Prof. Dr.-Ing. habil. Rainer Groh
Diplomarbeit
im Studiengang Medieninformatik
Konzeption eines grafischen Multi-Meeting
Protokoll-Browsers
Bettina Kirchner
Dresden, 14.02.2014
Betreuer:
Dipl.-Medieninf. Mirko de Almeida Madeira Clemente
Dipl.-Medieninf. Hannes Leitner
Hiermit erkläre ich, Bettina Kirchner, die vorliegende Diplomarbeit zum
Thema
selbständig und ausschließlich unter Verwendung der im Literaturverzeichnis aufgeführten Informationsquellen verfasst zu haben. Diese Arbeit wurde noch keiner Prüfungsbehörde in gleicher oder ähnlicher Form
vorgelegt.
Dresden, 14.02.2014
Bettina Kirchner
Matrikelnummer: 3338705
An dieser Stelle möchte ich mich bei allen bedanken, die mich auf dem Weg
hierher begleitet und unterstützt haben.
Mein Dank gilt zunächst Prof. Dr.-Ing. habil. Rainer Groh und meinen wissenschaftlichen Betreuern Mirko de Almeida Madeira Clemente und Hannes
Leitner für die konstruktive Kritik und Motivation sowie die Zeit, die sie investiert haben. Ohne ihre fachliche Unterstützung wäre die Arbeit in dieser
Form nicht möglich gewesen.
Besonders bedanken möchte ich mich weiterhin bei meinen Eltern, die mir
stets unterstützend zur Seite standen. Ohne meine Eltern wären meine
Ausbildung und alles, was dazu gehörte, nicht möglich gewesen. Ein Dankeschön geht auch an meine Schwester, dir mir in dieser Zeit immer ein
Vorbild und Motivation war.
Ebenso möchte ich mich bei meinen Kommilitonen bedanken, die teilweise
bereits vom ersten Tag an mit mir die schönen und stressigen Momente
des Studiums erlebt haben und mir während der ganzen Zeit seelisch und
moralisch beistanden. Ihre Begleitung hat meinen akademischen Werdegang maßgeblich beeinflusst und ich bin dankbar für die Umstände, die uns
alle über die Jahre hinweg zusammengebracht haben. Nicht zuletzt gilt ein
besonderes Dankeschön auch meinen Freunden, die mich mit zahlreichen
Anmerkungen unterstützt haben und immer ein offenes Ohr für mich hatten.
1
2
3
4
5
6
Einleitung..................................................................................................1
1.1
Motivation ........................................................................................1
1.2
Zielstellung ......................................................................................2
1.3
Gliederung .......................................................................................3
Grundlagen ...............................................................................................5
2.1
Meetings und Meeting-Aufzeichnungen .........................................5
2.2
Visual Text Mining .........................................................................14
2.3
Grundlagen Dokument- und Textstruktur ......................................20
2.4
Zusammenfassung ........................................................................22
Verwandte Arbeiten ...............................................................................25
3.1
Meeting-Browser...........................................................................25
3.2
Visualisierung zeitbasierter Textkollektionen ................................30
3.3
Anforderungsanalyse .............................................................................37
4.1
Problemanalyse .............................................................................37
4.2
Datenanalyse .................................................................................43
4.3
Bewertung der verwandten Arbeiten ............................................47
4.4
Anforderungen an das Konzept .....................................................53
Synthese und Konzeption ......................................................................59
5.1
Visualisierungskonzept ..................................................................59
5.2
Interaktionskonzept .......................................................................66
5.3
Umsetzung der Anwendungsfälle .................................................72
5.4
Kritische Betrachtung ....................................................................75
5.5
Technische Umsetzung ..........................................................................83
6.1
Technologie ...................................................................................83
6.2
Implementierung der GUI ..............................................................85
6.3
Implementierung der Interaktion ...................................................92
6.4
7
Zusammenfassung ....................................................................... 97
Zusammenfassung .............................................................................. 101
7.1
Fazit ............................................................................................ 101
7.2
Ausblick ...................................................................................... 102
Anhang........................................................................................................ 105
Literaturverzeichnis .................................................................................... 109
Webquellen................................................................................................. 115
Abbildungsverzeichnis ................................................................................ 117
Tabellenverzeichnis .................................................................................... 121
Quellcodeverzeichnis .................................................................................. 123
Meetings dienen dem umfangreichen Austausch projektbezogener Informationen und der Organisation von Teamarbeit, wobei neue projektbezogene
Informationen entstehen (vgl. [Banerjee et al. 05] und [Pallotta et al. 07]).
Aufgaben werden verteilt, Termine festgelegt und Beschlüsse gefasst. Die
Bedeutung von Meetings als Kollaborationsmethode ist heutzutage größer
denn je [S. Yu et al. 10]. Dabei sollten sie als eine Reihe von Ereignissen
betrachtet werden, die aufeinander aufbauen und deren Inhalte in Zusammenhang stehen (vgl. [Post et al. 04]). Umso wichtiger werden die Aufzeichnungen eines Meetings. Sie realisieren die Arbeit, die in einem Meeting bewältigt wurde, und protokollieren die gesamte Projektarbeit (vgl.
[Tinnirello 02]). Die vorliegende Arbeit beschreibt die Konzeption eines grafischen Browsers, der Inhalte einer Reihe von aufeinanderfolgenden Meetings sowie bestehende Meeting-übergreifende Zusammenhänge visualisiert. Weiterhin wird ein spezielles Interaktionskonzept erarbeitet, das Projekt-Informationen über die Visualisierung zugänglich macht. Eine Anwendung des konzipierten Werkzeugs ist insbesondere für Projekt-Meetings
vorgesehen.
“Capture is meaningless without access.” [Abowd 99]
Das heißt: Die Sicherung von Informationen ist bedeutungslos, wenn der
Zugang zu den Informationen nicht in geeigneter Weise bereitgestellt wird
(vgl. [Abowd 99] , S. 526). Damit weist ABOWD auf eine grundlegende Problemstellung hin, die im Rahmen dieser Arbeit auf den Abruf von MeetingInhalten übertragen wird.
Im Bereich der Informationssicherung von Meeting-Inhalten werden seit
Jahrzehnten Forschung und Entwicklung vorangetrieben, wobei der
Schwerpunkt existierender Systeme auf dem Ausgleich der kognitiven Belastung der Teilnehmer beim Notieren und der vollständigen Sicherung der
Inhalte liegt (vgl. [Z. Yu et al. 10]). Dabei herrschen Technologien zur automatischen Informationssicherung mittels Audio- und Videoaufnahmen vor
(vgl. [Geyer et al. 05]), [Z. Yu et al. 10]). Während es keine großen Schwierigkeiten bereitet, automatische Audio- und Videoaufzeichnungen abzuspielen, stellt die gezielte Suche nach Informationen für den Nutzer einen Mehr-
2
1.2. Zielstellung
aufwand gegenüber der Verwendung eigener Notizen oder MeetingProtokolle dar (vgl. [Wellner et al. 05]). Aus diesem und anderen Gründen1
werden solche Systeme noch immer kaum verwendet [Whittaker et al. 12],
und persönliche Notizen und Textprotokolle zählen mit Abstand zu den am
häufigsten genutzten Meeting-Aufzeichnungen [Whittaker et al. 07]. Halbautomatische2 Ansätze wie Audio-Annotationswerkzeuge (siehe Abschnitt
2.1.4) oder das elektronische Notizbuch NiCEBook [Brandl et al. 10] versuchen bestehende Probleme automatischer Ansätze zu lösen und zeigen
vielversprechende Ergebnisse in ihren Nutzerstudien. Der Bereich der Informationssicherung von Meeting-Inhalten ist somit weitgehend abgedeckt.
Bei der Unterstützung des Informationsabrufs fokussieren sich sowohl automatische, als auch halbautomatische Systeme jedoch hauptsächlich auf
einzelne Meetings. Sie vernachlässigen dabei die Tatsache, dass MeetingInhalte und -Ergebnisse als Ausgangspunkt für die weitere Projektarbeit
sowie weitere Meetings dienen (vgl. [Pallotta et al. 07]). An dieser Stelle
setzt die vorliegende Arbeit an.
Die Themenstellung dieser Arbeit geht aus dem Forschungsprojekt Vizamp
hervor, welches an der TU Dresden in Zusammenarbeit mit der queo GmbH
durchgeführt wird. Vizamp widmet sich der Thematik des Projektmanagements in mittelständischen Unternehmen in der Wissensgesellschaft 3 und
bislang verfügbare Projektmanagement-Software. Schwerpunkt des Forschungsprojektes ist die Konzeption eines interaktiven Systems für agiles
Multi-Projektmanagement, „das innovative Visualisierungs- und Interaktionskonzepte für die Arbeit von Projektmanagern und das kollaborative Arbeiten der Projektteams verbessern soll.“
In diesem Kontext wird in der vorliegenden Arbeit ein Werkzeug konzipiert,
das den Zugang zu Meeting-Inhalten über eine Folge von Projekt-Meetings
hinweg bereitstellt. Ziel des Konzepts ist es, durch eine Meetingübergreifende Darstellung der Inhalte konkrete Anwendungsfälle beim Informationsabruf zu unterstützen. Der Schwerpunkt der Arbeit liegt auf der
Visualisierung von Meeting-Inhalten und Meeting-übergreifenden Zusammenhängen.
Zu diesem Zweck sind einerseits grundlegende Strukturen von MeetingInhalten zu analysieren. Anhand der Erkenntnisse wird die inhaltliche Grundlage des Konzepts definiert. Andererseits findet eine Untersuchung ausge1
Beispielsweise erhöhter technologischer Aufwand oder Bedenken hinsichtlich dem Schutz
der Privatsphäre (vgl. [Z. Yu et al. 10]).
2
Der Begriff „halbautomatisch“ bezeichnet hier die Kombination automatischer Aufzeichnung
mit Mechanismen zur manuellen Bearbeitung und Annotation
3
Werbebranche, IT-Sektor, und Individual-Softwareentwicklung
EINLEITUNG
3
wählter Visualisierungsansätze aus dem Bereich des Text Mining statt. Einzelne Aspekte der Visualisierungsformen werden auf Meeting-Inhalte übertragen. Darauf basierend schließt sich die Erarbeitung des Visualisierungsund Interaktionskonzepts an. Abschließend wird ein Prototyp entwickelt, der
das Konzept praktisch umsetzt.
Die Arbeit ist in sieben Kapitel gegliedert. Im Anschluss an die Einleitung
behandelt Kapitel 2 zunächst wichtige Grundlagen zu Meetings und Meeting-Aufzeichnungen. Weiterhin erfolgt eine Einführung in das Gebiet des
Text Mining und die Vorstellung grundlegender Visualisierungsansätze aus
diesem Bereich. Der letzte Abschnitt legt Grundlagen zu Dokument- und
Textstrukturen dar.
Kapitel 3 betrachtet verwandte Arbeiten aus zwei Bereichen. Der erste Teil
beschreibt existierende Systeme zur Unterstützung des Informationsabrufs
von Meeting-Inhalten und dient der Abbildung des aktuellen Forschungsund Entwicklungsstands in diesem Bereich. Der zweite Teil beleuchtet Ansätze zur Visualisierung großer Textsammlungen mit Zeitbezug.
Kapitel 4 stellt Anforderungen an das Konzept auf. In diesem Zusammenhang werden Anwendungsfälle untersucht, die sich beim Informationsabruf
von Meeting-Inhalten ergeben. Die detaillierte Analyse von Meeting-Inhalten
und ihren Meeting-übergreifenden Zusammenhägen resultiert in der Definition der Datengrundlage. Aufbauend darauf werden die verwandten Arbeiten aus Kapitel 3 hinsichtlich ihrer Eignung für den Meeting-übergreifenden
Informationsabruf untersucht und bewertet.
Kapitel 1 stellt das auf Basis der Anforderungen erarbeitete Visualisierungsund Interaktionskonzept vor. Zum einen wird die visuelle Repräsentation der
Datengrundlage erläutert. Zum anderen wird der Funktionsumfang des Interaktionskonzepts veranschaulicht. Mögliche Vorgehensweisen zur Umsetzung der zuvor definierten Anwendungsfälle runden den konzeptionellen Teil
dieser Arbeit ab. Die kritische Betrachtung des Konzepts bildet den Abschluss dieses Kapitels.
Der im Rahmen dieser Arbeit entstandene Prototyp setzt ausgewählte Aspekte des Visualisierungs- und Interaktionskonzepts um, deren Implementierung Kapitel 6 erläutert. Eine Vorstellung grundlegender Bestandteile der
gewählten Technologie geht der Beschreibung der Implementierung voraus.
Kapitel 7 zieht ein Fazit aus den erreichten Ergebnissen und fasst die Arbeit
abschließend zusammen. Das Kapitel gibt außerdem einen Ausblick auf eine
mögliche Weiterentwicklung des Konzepts und nennt potentielle Forschungsfragen, die aus den Erkenntnissen der Arbeit hervorgehen.
Dieses Kapitel betrachtet Grundlagen aus drei Bereichen, die Voraussetzung
zum wesentlichen Verständnis der Arbeit sind. Der erste Abschnitt vermittelt einen Überblick zu Meetings und Meeting-Aufzeichnungen und behandelt insbesondere strukturelle Merkmale, die einen essentiellen Teil der
Datengrundlage des Konzepts bilden. Zur Vermittlung der gestalterischen
Grundlage der konzeptionellen Arbeit werden anschließend ausgewählte
Visualisierungsansätze und ihre Verwendung im Bereich Text Mining beleuchtet. Der letzte Abschnitt stellt ein Modell allgemeiner Dokumentstrukturen sowie organisatorische Textstrukturen vor.
Meetings können je nach ihrem Kontext sehr unterschiedlich ausfallen und
aufgefasst werden - sie sind einzigartig [Romano et al. 01]. Dennoch lassen
sich allgemeingültige Meeting-Strukturen und -Inhalte definieren, die in diesem Abschnitt dargelegt werden. Weiterhin wird erläutert, welche Formen
von Meeting-Aufzeichnungen es gibt, und welche Anhaltspunkte sie zum
Informationsabruf bereitstellen. Der letzte Abschnitt dieses Kapitels beschreibt schließlich den Zyklus, den aufeinanderfolgende Meetings und ihre
Aufzeichnungen bilden.
Im Hinblick auf die Themenstellung dieser Arbeit werden Meetings speziell
im Kontext des Projektmanagements betrachtet, wozu es einer detaillierteren Definition bedarf. Folgende allgemeine Meeting-Definitionen finden
sich in der Literatur:
„Ein Meeting ist die strukturierte Kommunikation zwischen zwei oder
mehr zusammenarbeitenden Personen“, wobei sowohl formale Vorstandssitzungen als auch spontane Mitarbeiterversammlungen dazu gezählt werden, welche zeit- und ortsunabhängig stattfinden können [Cook
et al. 87].
ROMANO ET AL. beschreiben Meetings als „zielgerichtete Interaktion
kognitiver Aufmerksamkeit, geplant oder zufällig, wenn Personen ein
Zusammenkommen zu einem gemeinsamen Zweck vereinbaren – un-
Gesamtheit aller Funktionen zur
Planung, Steuerung und Kontrolle bei der Durchführung
zeitlich begrenzter Aufgaben
(vgl. [Wytrzens 10], S. 22)
6
2.1. Meetings und Meeting-Aufzeichnungen
abhängig davon, ob sie zur gleichen Zeit am gleichen Ort oder zu unterschiedlichen Zeiten an unterschiedlichen Orten zusammenkommen“
[Romano et al. 01].
Der Meeting-Begriff wird durch die Autoren vom örtlich und zeitlich gleichen
Zusammenkommen von Personen erweitert auf örtlich verteilte Telekommunikation bis hin zum ungleichzeitigen Bearbeiten gemeinsam genutzter
Aufzeichnungen
(analog
oder
digital,
Dokumente,
WhiteboardAufzeichnungen). Im Kontext dieser Arbeit spielen solche zeitlich verteilten
Meetings jedoch keine Rolle, und Meetings werden definiert als:
Das (möglicherweise örtlich verteilte) gleichzeitige Zusammenkommen
zweier oder mehrerer Personen zum gezielten Informationsaustausch.
Anhand verschiedener Eigenschaften eines Meetings lässt sich ein Klassifikationsschema definieren, das Romano et al. mit dem Begriff der MeetingDimensionen belegen [Romano et al. 01]. Basierend auf dieser und ähnlichen Beschreibungen aus der Literatur (vgl. [Mannering 11] und [Tinnirello
02]) werden Meetings im Folgenden nach Zeit und Ort ihrer Durchführung,
Zweck des Meetings und ihrem wesentlichen Ablauf klassifiziert und erläutert.
Aufgrund der Globalisierung arbeiten Teams heutzutage zum Teil über die
ganze Welt verstreut, und Unternehmen müssen regelmäßig in Kontakt mit
Kooperationspartnern oder Kunden aus anderen Ländern und Kontinenten
treten (vgl. [Plaue 09]). Telekommunikation ermöglicht es, Meetings im virtuellen Raum abzuhalten und damit Reisekosten und Zeitaufwand zu minimieren. Aus der zeitlichen und örtlichen Verteilung von MeetingTeilnehmern lassen sich verschiedene Meeting-Arten ableiten. In Anlehnung
an die Raum/Zeit-Matrix für CSCW-Systeme4 [Johnson 07] ordnet Tabelle
2.1 diese Meeting-Arten hinsichtlich Zeit und Ort ihrer Durchführung ein.
 Face-To-Face Meeting
 Telefonkonferenz
 Videokonferenz
 Datenkonferenz (Whiteboard, Texteditoren)
 Chat
 Whiteboard
 File Sharing
 E-Mail
 File Sharing
Face-To-Face Meetings beschreiben solche Meetings, bei denen sich eine
variable Anzahl von Personen zur gleichen Zeit in einem Raum zusammenfindet, um gemeinsame Belange zu besprechen. Telekonferenzen sind Mee4
CSCW: Computer Supported Collaborative Work – Systeme zur Kollaborations-Unterstützung
GRUNDLAGEN
7
tings mit Audioübertragung, Videokonferenzen beinhalten Audio- und Videodaten und Datenkonferenzen bezeichnen Meetings, bei denen an allen
Kommunikationsenden Daten wie Whiteboard-Aufzeichnungen zugänglich
sind, oder das gemeinsame Bearbeiten von Textdokumenten möglich ist.
Chats umfassen das Senden von Nachrichten per Instant Messaging Systemen. Nach den Meeting-Definitionen von Cook et al. und Romano et al.
(siehe Abschnitt 2.1.1) gelten auch das gemeinsame, zeitunabhängige Bearbeiten von Dateien (analog oder digital) sowie die Kommunikation per E-Mail
zu einem bestimmten Thema als Meeting.
Die Bestimmung des Meeting-Zwecks im Vorfeld hilft den Teilnehmern,
einheitliche Erwartungen an das Ergebnis des Meetings aufzubauen. Damit
wird ein gemeinsames Ziel gesetzt, was sich meist positiv auf das Meeting
selbst auswirkt, da die Teilnehmer im Hinblick auf das Erreichen dieses Ziels
agieren und weniger vom Thema abschweifen. (vgl. [Tinnirello 02], S. 84)
Bezüglich der Arten von Meetings in Hinsicht auf ihren Zweck gibt es keine
einheitliche Aufstellung in der Literatur. Die meisten Überschneidungen
finden sich bei TINNIRELLO, COOK ET AL. und HENKEL. Die Autoren definieren
folgende Meeting-Arten (vgl. [Tinnirello 02], [Cook et al. 87] und [Henkel 07]):





Problemlösung
Entscheidungsfindung
Informationsaustausch (Präsentation, Report)
Brainstorming
Planung
COOK ET AL. und HENKEL weisen außerdem darauf hin, dass diese Unterscheidung nicht ausschließlich ist. Sie dient zunächst nur der Bestimmung
des Hauptziels eines Meetings – die meisten Meetings beinhalten Komponenten mehrerer dieser Arten [Cook et al. 87].
In der Literatur wird bezüglich des Ablaufs zwischen formellen (strukturierten) und informellen (unstrukturierten) Meetings unterschieden. Formelle
Meetings haben einen fest vorgegebenen Ablauf, während informelle Meetings freier in ihrer Durchführung sind. Zu informellen Meetings zählen beispielsweise spontane Mitarbeiterversammlungen, während Vorstandssitzungen formell ablaufen (vgl. Meeting-Definition nach COOK ET AL., Abschnitt
2.1.1) Ihre Eigenschaften sind in Tabelle 2.2 gegenübergestellt. So gibt es
bei strukturierten Meetings eine Rollenverteilung mit festem Protokollanten
und Moderator, sowie eine vorgegebene Sprecherreihenfolge, und die
Agenda dient als fest einzuhaltender Leitfaden des Meetings. Unstrukturierte Meetings haben dagegen im Vorfeld nicht immer eine Agenda, oder sie
ergibt sich oft erst im Meeting und ist flexibler und allgemeiner gehalten.
Beispiele formeller und informeller Meeting-Protokolle finden sich in Abbildung A.1 und Abbildung A.2 (siehe Anhang). (vgl. [Mannering 11] und
[Jaimes et al. 05])
8
Dedizierter Protokollant
Protokollierung durch
Teilnehmer
Geleitet durch Moderator,
vorgegebene Sprecherreihenfolge
Frei, diskussionsartig
Strikt einzuhalten, vorher
festgelegt
Flexibel, erweiterbar
Jede dieser Dimensionen beeinflusst das Meeting: Eine Telefonkonferenz
dient einem Zweck und wird formell oder informell abgehalten, ein Meeting
zur Problemlösung kann formellen oder informellen Charakter haben und ist
in seinem Zweck unabhängig von Zeit und Ort der Durchführung (vgl. Meeting-Definition nach ROMANO ET AL., Abschnitt 2.1.1). Abbildung 2.1 zeigt die
Meeting-Arten im Überblick.
Meeting-Aufzeichnungen stellen eine wichtige Informationsquelle dar. Sie
dienen als Referenz zu Inhalten und Ergebnissen eines Meetings, welche
einen direkten Einfluss auf die Effizienz und Organisation eines Unternehmens oder eines Teams haben. Damit bilden sie das kollektive Gedächtnis
eines Teams und werden häufig in späteren Meetings als Diskussionsgrundlage herangezogen. [Pallotta et al. 07]
Eine Unterscheidung verschiedener Formen von Meeting-Aufzeichnungen
erfolgt einerseits anhand der Art ihrer Anlegung, die manuell oder automatisch abläuft, andererseits danach, ob ihre Nutzung privat oder für die Öffentlichkeit im Sinne aller Projekt-Beteiligten bestimmt ist.
Notizen werden mit Stift und Papier oder mittels Laptop, Tablet, Smartphone oder digitalem Stift5 angefertigt. Handschriftliche Notizen werden dabei
häufig im Anschluss an ein Meeting digitalisiert [Brandl et al. 10]. Sie können
von Teilnehmer zu Teilnehmer für das gleiche Meeting höchst unterschiedlich ausfallen und präsentieren oft nur einen kleinen Ausschnitt aus dem
5
Beispielsweise der Anoto Pen (siehe www.anoto.com, aufgerufen am 12.02.2014)
GRUNDLAGEN
9
Meeting (vgl. [Whittaker et al. 06]). Weiterhin beinhalten Notizen die wichtigsten Informationen und eine persönliche Zusammenfassung für den Autor
selbst, und sind durch ihren subjektiven Charakter für andere Personen nur
eingeschränkt nützlich [Geyer et al. 05].
Trotz der allgemein verbreiteten Gewohnheit des Notierens von MeetingInhalten verlassen sich die Teilnehmer häufig auf das Meeting-Protokoll als
öffentliche Informationsquelle, die für alle Beteiligten gleichermaßen zur
Verfügung steht. Das Protokoll wird meist von einem ausgewählten Protokollanten angefertigt und im Anschluss an das Meeting verbreitet. Es dient
als öffentliche Aufzeichnung vergangener Ereignisse, der Erinnerung an zu
erledigende Aufgaben und dem Überprüfen des Projekt-Fortschritts und
bildet eine allgemeine Zusammenfassung der Meeting-Inhalte. Gleichzeitig
hat das Meeting-Protokoll eine vertragsähnliche Funktion zwischen den
Teilnehmern, indem es von der Gruppe gemeinsam getroffene Entscheidungen festhält. [Whittaker et al. 07]
Audio- und Videoaufzeichnungen eines Meetings dienen der vollständigen
Informationserfassung bei gleichzeitiger Entlastung der Teilnehmer, die sich
durch die automatische Informationssicherung auf ihre aktive Beteiligung an
der Besprechung konzentrieren können. Kameras und Mikrofone sind dabei
oft an mehreren Stellen im Raum verteilt und Teil sogenannter „Smart Meeting Environments“ oder Räumen, die speziell auf diese Art der Informationssicherung ausgelegt sind (vgl. [Z. Yu et al. 10]). Heutzutage ist das automatische Aufzeichnen von Audio und Video mit einfacheren Mitteln möglich,
da fast jeder Laptop über eine integrierte Kamera verfügt, und Audioaufzeichnungen ohne Probleme mit dem Tablet oder Smartphone gemacht
werden können.
Technisch hoch aufwändige Smart Meeting Environments (SME) oder
Rooms (SMR), wie der IDIAP SMR [Moore 02], erfassen Meeting-Inhalte,
die über einfache Audio- und Video-Aufzeichnungen hinausgehen. Dazu
zählen neben dem automatisch generierten Transkript der AudioAufzeichnungen auch Emotionen oder Sprechererkennung. Abbildung 2.2
zeigt den allgemeinen Aufbau eines solchen Systems.
10
Zu den multimedialen Aufzeichnungen zählen ebenfalls annotierte AudioAufzeichnungen. Sie zählen zu den halbautomatischen Ansätzen (vgl. Abschnitt 1.1). Bei Systemen wie Filochat [Whittaker et al. 94] und Dynomite
[Wilcox et al. 97] können Aufnahmen beispielsweise mit Notizen angereichert werden. Andere Werkzeuge ermöglichen das Markieren relevanter
Abschnitte der Audio-Aufzeichnung auf dem Smartphone (vgl. [Kalnikaitė et
al. 12]).
Eine Zusammenfassung der wichtigsten Eigenschaften der verschiedenen
Meeting-Aufzeichnungen stellt abschließend Abbildung 2.3 dar.
Die Erinnerung der Teilnehmer verblasst mit der Zeit, und beim späteren
Informationsabruf bedarf es verschiedener Anhaltspunkte, um das Gesuchte
GRUNDLAGEN
11
in den Aufzeichnungen zu finden. Der Informationsabruf gestaltet sich je
nach Art der Meeting-Aufzeichnungen unterschiedlich.
Dabei ist bei allen Formen von Aufzeichnungen die Zeit ein wichtiges Kriterium für den Zugang zu Meeting-Inhalten [Geyer et al. 01]. Besonders bei
der Verwendung von Notizen und Protokollen wird zunächst abgeschätzt, in
welchem Zeitrahmen eine Information festgehalten wurde, und die betreffenden Aufzeichnungen durchsucht. Listen, Überschriften und andere Strukturierungen der Inhalte dienen als visuelle Unterstützung bei der Informationssuche in Protokollen und Notizen. Notizen werden zudem häufig mit
Hervorhebungen und Markierungen versehen, wie das Einkreisen oder Unterstreichen von Informationen oder das farbliche Hervorheben mit Textmarkern (vgl. [Wilcox et al. 97]). Die Protokoll-Struktur folgt weiterhin der
Agenda des Meetings, welche die Inhalte thematisch getrennt auflistet und
damit als Leitfaden des Dokuments fungiert (vgl. [Mannering 11]). Zusätzlich
bilden Protokolle Zusammenhänge mithilfe von Einrückungen oder Tabellen
ab.
Dem Informationsabruf von Audio- und Video- sowie multimedialen Aufzeichnungen dienen spezielle Meeting Browser. Sie sind meist Teil eines
Smart Meeting Environments und im Bereich „Semantic Processing“ eingeordnet (siehe Abbildung 2.2, vgl. [Z. Yu et al. 10]). Mittels verschiedener
Methoden zur Indexierung und Annotation der Aufzeichnungen wird der
gezielte Zugang zu Inhalten unterstützt. Es existieren verschiedene Arten
von Meeting Browsern, klassifiziert nach den Inhaltsformaten, die den
Schwerpunkt beim Informationsabruf bilden [Whittaker et al. 12]. Neben
Audio- und Video-Browsern gibt es sogenannte „Artifact Browser“, die
Elemente (Artefakte) wie Whiteboard-Aufzeichnungen, Notizen des Meetings, Präsentationsfolien, die Agenda oder sonstige Dokumente einbeziehen und als Index zum entsprechenden Abschnitt in den Aufnahmen dienen. Sogenannte „Discourse Browser“ bieten zur Informationssuche hauptsächlich Daten, die aus den Aufzeichnungen abgeleitet wurden. Dazu zählen
das ASR Transcript6 und die Sprechererkennung. Abbildung 2.4 stellt eine
Übersicht zu den Anhaltspunkten beim Informationsabruf dar.
6
ASR Transcript: ASR steht für Spracherkennung (automatic speech recognition); ASR
Transcript bezeichnet die Mitschrift der Spracherkennung
12
In einem Projekt wird kontinuierlich Information generiert und verarbeitet.
Meetings dienen dem Austausch dieser Information, und dürfen dabei nicht
als alleinstehende Ereignisse aufgefasst werden [Post et al. 04]. Besprochene Inhalte sind mit dem Ende des Meetings oftmals nicht abgeschlossen, sondern werden bearbeitet und in folgenden Meetings wieder aufgegriffen (vgl. [Handford 10], S. 75). Dem Informationsaustausch im Meeting
folgt die Verarbeitung und Generierung neuer Informationen, und schließlich
das nächste Meeting. Meeting-Aufzeichnungen dokumentieren diesen Fortschritt und machen ihn rekonstruierbar. Es ergibt sich ein Meeting-Zyklus,
der unendlich sein kann (wie im Beispiel von Vorstandssitzungen eines Unternehmens). Bei der Durchführung eines Projekts endet der Zyklus hingegen mit dem Projektabschluss. (vgl. [Post et al. 04])
In der Literatur (vgl. [Mannering 11] und [Jain et al. 03]) wird der MeetingZyklus häufig als das Abarbeiten verschiedener Schritte auf dem Weg von
einem zum nächsten Meeting beschrieben. Dazu gehören das Verbreiten
von Meeting-Aufzeichnungen und die Vorbereitung des nächsten Meetings.
JAIN ET AL. teilen den Zyklus anhand von Meeting-bezogenen Zeitpunkten
und zugehörigen Aufgaben in vier Phasen ein [Jain et al. 03]. Man beachte,
dass sich die Punkte 1 bis 4 in dieser Reihenfolge stets wiederholen:
1. Vor dem Meeting:
a. Betrachten vorhergehender Meetings
b. Meeting-Ziele beschreiben
c. Agenda erstellen
d. Dokumente zusammentragen
e. Teilnehmer benachrichtigen
2. Im Meeting:
a. Agenda überprüfen und ergänzen
b. Meeting halten
c. Zusammenfassung der Inhalte
GRUNDLAGEN
13
3. Nach dem Meeting:
a. Dokumente erstellen und verteilen
b. Meeting analysieren
c. Nächste Schritte einleiten
4. Zwischen Meetings
a. Festgelegte Schritte ausführen
b. Dokumente aktualisieren
COOK ET AL. legen den Meeting-Zyklus als verschiedene Phasen der Informationsverarbeitung aus (vgl. [Cook et al. 87]). Durch das Zusammenkommen
von Personen und deren Informationsaustausch (entspricht Punkt 2 nach
JAIN ET AL.) entsteht neue Information, welche im Meeting sowie im Anschluss an das Meeting festgehalten (3.a), analysiert (3.b) und abgerufen
wird. Der Informationsabruf findet in allen vier Phasen des Meeting-Zyklus
statt: zwischen Meetings, um das Projekt voranzutreiben (3.b-4.b), in Vorbereitung auf das nächste Meeting (1.), und im Meeting selbst, wo neu entstandene Information präsentiert und in Verbindung mit bereits festgehaltenen Inhalten vorheriger Meetings zu neuer Information verknüpft wird (vgl.
[Geyer et al. 05]). Diese wird ebenfalls festgehalten, und so schließt sich der
Meeting-Zyklus (siehe Abbildung 2.5). Dabei beeinflussen Informationen aus
der Vergangenheit die der Gegenwart, und somit auch zukünftige Informationen.
14
2.2. Visual Text Mining
Dieses Kapitel liefert eine kurze Einführung zu Text Mining Systemen mit
besonderem Augenmerk auf der Visualisierungskomponente. Darauf aufbauend werden grundlegende Visualisierungsformen vorgestellt und ihre
Bedeutung in diesem Bereich erläutert. Eine Vorstellung der Visualisierungsansätze ausgewählter Text Mining Systeme demonstriert beispielhaft
ihre Verwendung. Bei der Beschreibung der Visualisierungsformen werden
teilweise ihre englischen Bezeichnungen beibehalten, wenn eine eindeutige
deutsche Übersetzung nicht existiert oder der englische Begriff sich im
deutschen Sprachraum etabliert hat.
Prozess der nichttrivialen Extraktion von impliziter und möglicherweise wertvoller Information aus Daten-beständen (vgl.
[Perner 02])
Dienen der Transformation von
Datenobjekten (Entitäten) in
grafische Objekte, indem ihre
Eigenschaften (Attribute) in
visuelle Variablen wie Form,
Größe, Position, Farbe etc.
übersetzt werden (vgl. [Bertin
83] und [Ware 04])
Text Mining7 stellt eine spezifische Form des Data Mining dar, bei der große Dokumentkollektionen die Datengrundlage stellen. Durch die Identifikation und Exploration von Mustern in unstrukturierten Textsammlungen wird
wertvolle Information gewonnen. Text Mining Architekturen bestehen aus
einer Komponente zur Vorverarbeitung der Daten, Muster-ErkennungsAlgorithmen und einer Präsentationsschicht, die das Browsen der Daten
mithilfe von Visualisierungswerkzeugen unterstützt (Abbildung 2.6). (vgl.
[Feldman et al. 07], S. 1)
Die Visualisierungswerkzeuge ermöglichen es, neben der semantischen
Struktur der Dokumentkollektion auch weitere Eigenschaften der Textsammlungen sowie eine visuelle Zusammenfassung ihrer Inhalte zu präsentieren [Risch et al. 08]. Üblicherweise werden zu diesem Zweck die Eigenschaften, die dargestellt werden, auf sogenannte visuelle Variablen wie
Farbe oder Form projiziert. Visualisierungsformen reichen von einfachen
Listen und Tabellen über Baumgraphen bis hin zu komplexeren Graphen. Für
einen Großteil der Anfragen an das System können Checkboxen oder
Dropdown-Listen eingesetzt werden. Die Analyse von und Interaktion auf
besonders großen Textsammlungen erfordert jedoch anspruchsvollere Visualisierungen [Feldman et al. 07]. Diese genügen jedoch nur dann den Anfor7
Auch bezeichnet als Text Analytics oder Text Data Mining (vgl. [Aggarwal et al. 12])
GRUNDLAGEN
15
derungen, solange sie nicht zu komplex und dadurch unübersichtlich wirken,
was die Datenexploration erschweren oder gänzlich verhindern kann. Zu den
Vorteilen, die ein an die Datengrundlage angepasster, individueller Visualisierungsansatz gegenüber Zeichen-orientierten Darstellungsformen hat, zählen
die Autoren (vgl. [Feldman et al. 07], S. 191):
Prägnanz: Die Fähigkeit, eine große Menge an Daten verschiedener
Typen gleichzeitig abzubilden.
Verhältnismäßigkeit und Ähnlichkeit: Die Fähigkeit, Cluster, die relative Größe von Gruppierungen, Ähnlichkeiten und Verschiedenartigkeiten sowie Ausreißer bei den Ergebnissen zu zeigen.
Fokus mit Kontext: Die Möglichkeit der Interaktion mit einem hervorgehobenen Ausschnitt der Datenmenge bei gleichzeitiger Betrachtung
des relationalen Kontexts.
Zoomfunktion: Die Möglichkeit der schnellen Bewegung von Mikrozu Makroansichten in einem oder mehreren inkrementellen Schritten.
Stimulation der rechten Gehirnhälfte: Aufforderung des Nutzers zur
Interaktion mit den Text-Daten nicht nur aufgrund einer vorsätzlichen
Suchintention, sondern zusätzlich durch die Anregung intuitiver, reaktiver oder räumlich orientierter kognitiver Prozesse zur Identifikation interessanter Muster.
Dabei liegt der Wert der Systeme nicht nur in der grafischen Repräsentation
der Analyseergebnisse, sondern ebenso in den bereitgestellten Interaktionsarten. Dazu gehören häufig eine Reihe von Such- und Filtermöglichkeiten, die die Komplexität der Darstellung reduzieren und damit einerseits die
Interpretation der Information unterstützen, andererseits das Auffinden der
für den Nutzer interessanten Information vorantreiben sollen [Risch et al.
08]. Diese Interaktionsmöglichkeiten sind meist speziell auf spezifische Entitäten des Systems ausgerichtet, zum Beispiel auf die Dokumente selbst.
Die grafische Benutzeroberfläche (GUI) zur Interaktion auf der Visualisierung
bezeichnen FELDMAN ET AL. als Browser (vgl. [Feldman et al. 07], S.189 ff).
Topic Evolution Mining beschäftigt sich mit der Beobachtung von zeitbasierten Textströmen, wobei Themen und ihre Entwicklungen über einen längeren Zeitraum hinweg aus Dokumentkollektionen extrahiert werden (vgl. [Cui
et al. 11]). Es ist ein Teilgebiet des Text Mining, spezieller des Text Stream
Mining, das besonders bei der Analyse von Textströmen in sozialen Netzwerken oder auf Nachrichtenportalen zur Anwendung kommt (siehe
[Aggarwal et al. 12], S. 297). Topic Evolution Mining bietet dem Nutzer Möglichkeiten zur Unterscheidung und Untersuchung individueller Themen und
ihrer Entwicklung im Laufe der Zeit. Darüber hinaus sollen Nutzer solcher
16
Systeme in der Lage sein, wichtige Ereignisse und ihre Ursachen zu identifizieren. CUI ET AL. unterscheiden diesbezüglich das Entstehen neuer Themen
(topic birth), die Entwicklung und das Verschwinden von Themen (topic
death), das sukzessive Aufteilen eines Themas in verschiedene Themen
(topic splitting) sowie das Verschmelzen von Themen zu einem neuen Thema (topic merging).
Konzeptgraphen (engl. concept graphs) dienen der semantischen Beschreibung von Ontologien8, deren Datenstrukturen mithilfe der Graphen auf Knoten (Entitäten) und Kanten (Relationen) abgebildet werden. Ausprägungsformen von Konzeptgraphen reichen von hierarchischen Baumdarstellungen
mit Wurzel- und Blätterknoten (siehe Abbildung 2.7, a) über gerichtete azyklische Graphen9 (DAG, b) hin zu Assoziationsgraphen (c). DAGs verfügen
über die Fähigkeit komplexere Ontologien als strikt hierarchische Ordnungen
zu beschreiben. Aus diesem Grund bilden sie oftmals die Basis für anspruchsvollere Relationsabbildungen in Text Mining Anwendungen. Assoziationsgraphen erweitern DAGs um die Darstellung ungerichteter Beziehungen verschiedener Konzepte im Hinblick auf eine oder mehrere Kategorien.
Zu den üblichen Interaktionsarten, die Konzeptgraphen bieten, gehören Sortier-, Filter- und Zoomfunktionen und die Möglichkeit des Ein- und Ausblendens von Teilgraphen. (vgl. [Feldman et al. 07] S. 195 ff)
Histogramme und Liniendiagramme (eng. line-graphs) dienen im Bereich
von Text Mining Systemen hauptsächlich der Abbildung der Häufigkeitsverteilung von Suchergebnissen. Histogramme (siehe Abbildung 2.8) erlauben
den Vergleich individueller Konzepte, wie das Vorkommen verschiedener
Themen, innerhalb einer Dokumentkollektion. Liniendiagramme (Abbildung
2.9) bieten die Möglichkeit, Ergebnisse verschiedener Suchanfragen miteinander in Vergleich zu setzen, mehrere Dokumentkollektionen im Hinblick
auf eine Suchanfrage gegenüberzustellen oder die Änderung weiterer Parameter und ihre Auswirkung auf die Suchergebnisse zu vergleichen. (vgl.
[Feldman et al. 07] S. 205 ff)
Ein Beispiel der Anwendung eines Histogramms zur Visualisierung in einem
Text Mining System zeigt Abbildung 2.10. Diese Visualisierung stellt die
Menge an Beiträgen dar, die der Nutzer eines Forums zu seinen eigenen
8
Ontologie: explizite Spezifizierung einer vereinfacht abstrakten Sicht auf die Welt oder einen
Ausschnitt daraus (Konzeptualisierung) [Gruber 93]
9
Engl. DAG: directed acyclic graph
GRUNDLAGEN
17
Threads (oben) und zu anderen Threads des Forums (unten) im Verlauf eines
Jahres erstellt hat.
Ein Circle Graph bildet Elemente (Entitäten) auf seinem Umkreis ab, deren
Relationen sich als Kanten durch das Kreisinnere ziehen (Abbildung 2.11).
Dieser Visualisierungsansatz ist in der Lage, große Datenmengen übersichtlich abzubilden. Visuelle Variablen wie Farbe oder Stärke der Linie können
zur Repräsentation verschiedener Eigenschaften der Relationen genutzt
werden, oder Farbverläufe die Verbindungsrichtung anzeigen. Circle Graphs
sind eine geeignete Methode, um Assoziationsregeln 10 innerhalb der Ergebnismenge einer Suchanfrage darzustellen oder Konzepte in Bezug auf spezifische Kategorien miteinander zu verlinken. Interaktionsansätze beziehen die
Elemente auf dem Umkreis sowie die Relationen selbst mit ein. Durch Anklicken oder Mouseover werden Relationen oder die zugehörigen Elemente
hervorgehoben, und zusätzliche Information präsentiert. Eine Implementation dieses Visualisierungs- und Interaktionsansatzes existiert beispielsweise
in „Naming Names“ [@Corum et al.], einer Web-Anwendung der New York
Times (siehe Abbildung 2.12). Die Visualisierung bildet Reden von USPräsidenten auf dem Kreisumfang ab und stellt mithilfe der Linien dar, welche anderen Präsidenten in der Rede namentlich erwähnt wurden (vgl.
[Feldman et al. 07], S. 208 ff)
10
Assoziationsregeln: Beschreiben Zusammenhänge und Abhängigkeiten in einer Datenbasis
[Mann 13]
18
Das Gestaltungsprinzip von Tag
Clouds lässt sich bis auf den
Stil des Konstruktivismus Anfang des 20. Jh. zurückführen.
Das erste Anwendungsbeispiel
zur Textvisualisierung stellt die
Abbildung der Umfrageergebnisse des Psychologen Stanley
Milgram aus dem Jahr 1976 dar
(siehe
Abbildung A.3, S. 107). [Viégas
et al. 08]
Konzeptionell gesehen ähneln Text Clouds, oder auch Word Clouds, Histogrammen insofern, dass sie die Häufigkeitsverteilung von Worten innerhalb
von Dokumentkollektionen visualisieren. Dabei bieten sie jedoch durch die
Variation der Schriftgröße und -farbe sowie der Textorientierung (horizontal
oder vertikal) und der Nähe einzelner Tags zueinander eine größere Flexibilität in der Darstellung des relativen Stellenwerts eines Tags. WebAnwendungen wie Wordle [@Feinberg] generieren individuelle Tag Clouds
auf Basis von Nutzertexten (siehe Abbildung 2.13). [Berry et al. 10]
Zeitbasierte Tag Clouds erlauben die sequentielle Untersuchung chronologisch aufeinanderfolgender Dokumente [Viégas et al. 08]. Ein Beispiel dafür
stellt die Website chir.ag11 zur Verfügung, die dieses Prinzip auf die Reden
US-amerikanischer Präsidenten von 1776 bis 2007 anwendet. Im Bereich
des Topic Evolution Mining nutzen CUI ET AL. Tag Clouds zum Vergleich der
Inhalte mehrerer Themen (siehe Abbildung 2.14).
11
http://chir.ag/projects/preztags/, aufgerufen am 29.01.2014
GRUNDLAGEN
19
20
2.3. Grundlagen Dokument- und Textstruktur
Stacked Graphs bilden individuelle Zeitverläufe und ihre Summe ab und
lassen sich auf das Prinzip von gestapelten Säulendiagrammen (engl.
Stacked bar chart) zurückführen (siehe Abbildung 2.15). Im Bereich des Text
Mining eignen sie sich zur Visualisierung zeitbasierter Dokumentkollektionen
[Aigner et al. 11]. Sie addieren zu jedem Zeitpunkt die Höhe der einzelnen
Schichten – die Schichten werden so übereinander „gestapelt“. Dabei beeinflussen sich die einzelnen Zeitverläufe gegenseitig, und die Wahrnehmung der individuellen Daten kann dadurch getrübt werden [Byron et al. 08].
Eine Variante der Stacked Graphs sind die Streamgraphs, die die Daten um
eine zentrale Achse „fließen“ lassen, anstatt sie ausgehend von einer
Grundlinie nach oben aufzustapeln [Byron et al. 08]. Im Bereich des Topic
Evolution Mining stellen Stacked Graphs und Streamgraphs die am weitesten verbreitete Visualisierungsmethode dar [Cui et al. 11]. Jede Schicht repräsentiert ein Thema, und der Fluss von rechts nach links bildet die Entwicklung des Themas im Laufe der Zeit ab. ThemeRiver [Havre et al. 00] ist
die Anwendung eines Streamgraphs auf die Visualisierung der Themenentwicklung einer Dokumentkollektion und wird in der Literatur gleichzeitig als
ein selbstständiger Visualisierungsansatz mit Stacked Graphs und Streamgraphs verglichen (siehe Abbildung 2.16). Die Farbgebung signalisiert thematische Veränderungen innerhalb der Dokumente, die Höhe der einzelnen
„Flüsse“ repräsentiert ihre Relevanz zum jeweiligen Zeitpunkt (vgl. [Aigner
et al. 11], S.197).
Dieser Abschnitt gibt einen Überblick zu Grundlagen von Dokument- und
organisatorischen Textstrukturen. Zunächst wird ein Modell allgemeiner
Dokumentstrukturen vorgestellt. Im Anschluss daran werden ausgewählte
Textstrukturen aufgezeigt, die relevant zum Verständnis eines Textes sind.
Dokumente beinhalten Fließtext, der beispielsweise durch Überschriften,
Listen oder Tabellen strukturiert wird. Diese Strukturierungen stellen eine
semantische Gliederung des Textes dar und dienen als erste Anhaltspunkte
beim Lesen eines Dokuments. KLINK ET AL. bezeichnen diese semantische
Gliederung als logische Struktur eines Dokuments [Klink et al. 00]. Daneben
definieren sie die geometrische Struktur beziehungsweise das DokumentLayout als zweite Art der Strukturierung.
GRUNDLAGEN
21
Zusammen sind die geometrische und logische Dokumentstruktur essentiell
für die Dokumentverarbeitung, die KLINK ET AL. in zwei Phasen gliedern:
1. Analyse
2. Verständnis
Die Extraktion der geometrischen Struktur eines Dokuments ist Teil der
Analyse. Das Verständnis eines Dokuments bezeichnet die Abbildung der
geometrischen auf die logische Struktur. [Klink et al. 00]
Allgemein besteht ein Dokument aus einer oder mehreren Seiten, die jeweils in Blöcke eingeteilt sind. Diese Blöcke bestehen aus Zeilen, die sich
aus einzelnen Wörtern zusammensetzen. Von jedem Layout-Objekt enthält
ein Dokument mindestens eins. Der Aufbau aus den einzelnen LayoutObjekten stellt die geometrische Struktur eines Dokuments dar. Die logische Struktur basiert auf diesen Objekten. Blöcke, Zeilen und Worte werden
durch Überschriften, Tabellen, Listen oder andere sogenannte Label zu logischen Einheiten zusammengefasst. Abbildung 2.17 zeigt das Dokumentmodell, gegliedert in logische Struktur und Layout.
Organisatorische Textstrukturen sind Muster, die Informationen einzelne
Teile zerlegen, welche für den Leser leicht verständlich sind (vgl. [Cameron
et al. 13], S.4). Besonders im Bereich der Didaktik 12 werden solche Muster
verwendet, um den Aufbau eines Textes zu gliedern und damit das Verständnis von Zusammenhängen zu erleichtern. CAMERON ET AL. unterscheiden die folgenden Arten von Textstrukturen (siehe [Cameron et al. 13], S. 4):



12
Ursache und Wirkung
Sequentielle Ordnung
Beschreibung
Didaktik: bezeichnet „die Wissenschaft und Praxis vom Lehren und Lernen“ [Riedl 04], S. 8
22
2.4. Zusammenfassung



Vergleich und Gegenüberstellung
Chronologische Ordnung
Konzept und Detail
Die Textstruktur „Ursache und Wirkung“ wird auch bezeichnet als „Problem-Lösung“-Struktur und beschreibt die kausale Beziehung von Elementen.
„Vergleich und Gegenüberstellung“ ist ein grundlegendes Muster, das dem
Erkennen und Beibehalten von Information dient. (vgl. [Johnson 09], S. 56
ff).
Chronologische und sequentielle Ordnungen werden oft gleichbedeutend
verwendet. Sie beschreiben eine Folge von Ereignissen, Ideen oder Schritten, die in zeitlicher Reihenfolge ablaufen. (vgl. [Medina 08], S. 147)
„Konzept und Detail“-Strukturen bestehen aus einem Konzept, dessen
Kernaussage durch zusätzlicher Informationen unterstützt wird (vgl.
[Cameron et al. 13], S. 4).
In diesem Kapitel wurden inhaltliche Grundlagen zu Meetings und MeetingAufzeichnungen sowie gestalterische Grundlagen zu Visualisierungsansätzen im Bereich Text Mining vorgestellt. Zunächst wurden Meetings definiert, wobei der Schwerpunkt bei den Projekt-Meetings lag, da die Themenstellung der Arbeit den Bereich des Projektmanagements betrachtet. Die
Klassifikation von Meetings (vgl. Abschnitt 2.1.2) hat gezeigt, dass Meetings
anhand von verschiedenen Dimensionen Meeting-Arten zugeordnet werden
können, deren Eigenschaften im Zusammenspiel das Meeting beschreiben.
Abschnitt 2.1.3 erläuterte unterschiedliche Formen von MeetingAufzeichnungen. Sie stellen ebenso unterschiedliche Anhaltspunkte für den
Informationsabruf bereit (vgl. Abschnitt 2.1.4). Diese Anhaltspunkte werden
bei der Analyse der Anforderungen an das Konzept (siehe Kapitel 4) aufgegriffen. Der Meeting-Zyklus verdeutlichte abschließend zu diesem ersten
Grundlagen-Bereich die Existenz von Zusammenhängen zwischen aufeinanderfolgenden Meetings und ihren Inhalten, was schließlich den Ausgangspunkt für den Visualisierungsansatz bildet (siehe Kapitel 1).
Der Abschnitt zu Visual Text Mining führte zunächst die Begriffe Text Mining
und Topic Evolution Mining ein, deren Grundgedanken sich auf die Visualisierung von Meeting-Inhalten übertragen lassen. Verschiedene Visualisierungsformen aus diesen Bereichen vermittelten anschließend einen Überblick zur grafischen Abbildung Inhalten umfangreicher Dokumentkollektionen. Die Auswahl dieser Visualisierungsansätze wurde hinsichtlich der Abgrenzung des Konzepts auf die Visualisierung von Meeting-Protokollen (siehe Abschnitt 4.1.4) getroffen, die in Bezug auf eine Folge von Meetings
ebenfalls eine Dokumentkollektion darstellen. Die vorgestellten Visualisie-
GRUNDLAGEN
23
rungsansätze umfassen die Abbildung von Wissensdomänen (Ontologien)
mittels Konzeptgraphen, die Repräsentation der Häufigkeitsverteilung von
Suchergebnissen mittels Histogrammen und Line Graphs, sowie die Darstellung der Relationen verschiedener Textdaten mithilfe von Circle Graphs. Tag
Clouds dienen der visuellen Zusammenfassung von Textsammlungen. In
abgewandelter Form sind sie außerdem in der Lage, die Entwicklung von
Dokumenten über einen längeren Zeitraum hinweg zu verdeutlichen. Weiterhin wurden Stacked Graphs und darauf aufbauende Visualisierungsformen zur Abbildung zeitbasierter Dokumente erläutert.
Text- und Dokumentstrukturen spielen eine Rolle bei der Informationsstrukturierung des Konzepts. Zu diesem Zweck wurde in Abschnitt 2.3.1 das
Modell der Dokumentstruktur beschrieben, welches den Grundaufbau von
Dokumenten abbildet und semantische Einheiten definiert, die zur Auslegung des Inhalts relevant sind. Abschnitt 2.3.2 stellte ausgewählte
Textstrukturen vor, deren Prinzipien bei der Informationsstruktur des Konzepts berücksichtigt werden (vgl. Abschnitt 5.1.1).
Im nächsten Kapitel werden verwandte Arbeiten zu den Bereichen der inhaltlichen und gestalterischen Grundlagen näher erläutert.
Dieses Kapitel stellt verwandte wissenschaftliche Arbeiten aus zwei Bereichen vor, die für die vorliegende Arbeit von Bedeutung sind. Der erste Abschnitt beleuchtet die Unterstützung beim Informationsabruf von MeetingInhalten in Form von Meeting-Browsern. Der zweite Abschnitt behandelt
Arbeiten zur zeitbezogenen Visualisierung von Inhalten aus großen Textsammlungen. Die hier vorgestellten Arbeiten wurden ausgewählt, da sie
den aktuellen Stand13 in beiden Bereichen darstellen. Außerdem weisen die
Ansätze viele Gemeinsamkeiten zur Zielstellung der vorliegenden Arbeit auf,
die in der Unterstützung beim Informationsabruf über eine Folge von Meetings liegt. Unter diesem Gesichtspunkt werden die Arbeiten in den folgenden zwei Abschnitten beschrieben.
Meeting-Browser unterstützen den Abruf von Meeting-Inhalten aus multimedialen Aufzeichnungen (siehe Abschnitt 2.1.4). Durch Annotation und
Indexierung digitaler Aufzeichnungen dienen sie dem gezielten Informationszugang. TeamSpace [Richter et al. 01] und ARCHIVUS [Lisowska et al.
05] werden hier als Beispiele solcher Meeting-Browser vorgestellt, da sie
das Browsen mehrerer Meetings anbieten. Gleichzeitig legen sie den Fokus
auf Meeting-Aufzeichnungen selbst, und nicht, wie andere Browser, auf
multimediale Aufzeichnungen im Allgemeinen (vgl. Meeting-BrowserÜbersicht in [Lalanne et al. 05]).
TeamSpace [Richter et al. 01] ist ein aufgabenorientiertes Kollaborationswerkzeug, welches örtlich verteilte Arbeitsprozesse und gemeinsam genutzte Dokumente verwaltet. Ein Teil des Systems ist der Unterstützung virtueller Meetings gewidmet, die aufgezeichnet und mit Meeting-Aktivitäten (automatisch) sowie mit Dokumenten und anderen Inhalten (manuell) angereichert werden können. (vgl. [Geyer et al. 01])
Abbildung 3.1 zeigt einen Screenshot der Anwendungsoberfläche mit
geöffnetem Meeting-Tab. Der obere Teil des Fensters beinhaltet eine Übersicht aller Meetings, ein Eingabefeld zur Schlüsselwortsuche, Filterfunktio13
Zur Aktualität der vorgestellten Meeting Browser siehe [Popescu-Belis et al. 12]
26
3.1. Meeting-Browser
nen zur Einschränkung des Zeitraumes der dargestellten Meetings sowie
die Möglichkeit zur Anzeige einzig der Meetings, an denen der Nutzer selbst
teilgenommen hat. Der untere Teil bildet weitere Details des aktuell ausgewählten Meetings ab. Hier wird der eigentliche Meeting Browser, der
MeetingViewer, aufgerufen. (vgl. [Richter et al. 01])
Zunächst wird zur Meeting-Aufzeichnung der sogenannte MeetingClient
verwendet. Diese Komponente stellt neben der Audio- und Videoaufzeichnung auch die Interaktion der Teilnehmer mit dem System bereit. Interaktionsmöglichkeiten bestehen im Erstellen, Ansehen und Abhaken von Aufgaben und Agendapunkten, dem Hochladen und Ansehen von Präsentationen,
Annotieren von Folien sowie Kennzeichnen hinzukommender oder hinausgehender Teilnehmer. Jede Interaktion mit dem System wird gleichzeitig als
Ereignis festgehalten. Solche Ereignisse werden als Indizes zur Aufzeichnung gespeichert und fungieren beim Durchsuchen der Inhalte mit MeetingViewer als Navigationspunkte. (vgl. [Richter et al. 01])
MeetingViewer (siehe Abbildung 3.2) dient dem eigentlichen Durchsuchen
der Meeting-Inhalte anhand einer zweiteiligen Zeitachse. Die obere Zeitachse spannt sich über den gesamten Meetingverlauf, während die untere Zeitachse zur feingranularen Navigation nur einen Ausschnitt aus dem Meeting
VERWANDTE ARBEITEN
27
zeigt. Die Position des Ausschnitts wird dabei auf der oberen Zeitachse
mittels eines schwarzen Rechtecks gekennzeichnet. Die Ereignisse, die als
Indizes auf den Zeitachsen angeordnet sind, werden nach Agendapunkten,
Präsentationen, Aufgaben, Personen und Schlüsselwörtern unterschieden,
wobei jeder dieser fünf Kategorien eine Farbe zugewiesen ist. Einerseits soll
damit eine visuelle Zusammenfassung des Meetings geliefert werden, andererseits dient es der Navigation, da der Nutzer durch Anklicken der Indizes
direkt zum zugehörigen Aufnahmeteil springen kann und dieser anschließend abgespielt wird. Zusammen mit der Aufnahme werden ebenfalls die
entsprechenden Ereignisse abgespielt – beispielsweise die zu dem Zeitpunkt angezeigten Folien einer Präsentation. Das vorhandene Material ist
über Tabs zugänglich. Es kann außerdem in separaten Fenstern geöffnet
und dadurch gleichzeitig gesichtet werden. Der Nutzer kann weiterhin über
Checkboxen filtern, welche der Kategorien auf der Zeitachse angezeigt werden sollen. (vgl. [Richter et al. 01])
In der kurzfristigen Evaluation (siehe [Richter et al. 01] und [Geyer et al. 01])
hat sich das System bei Brainstorming Meetings und zur Besprechung von
Präsentationen als nützlich erwiesen. Die Langzeitstudie [Lipford et al. 08]
untersuchte hauptsächlich, wie die Teilnehmer Meeting-Aufzeichnungen
durchsuchen und welche Artefakte zur Navigation verwendet werden. Anhand der Ergebnisse wurde ein Navigationsmuster aufgestellt, das in dieser
Form der Durchführung am häufigsten zum erfolgreichen Informationsabruf
geführt hat:
28
3.1. Meeting-Browser
1. Öffnen der Agenda.
2. Anklicken des Themas, das zum gesuchten Inhalt gehört.
3. Durchsicht der Präsentationsfolien und Annotationen ab Themenbeginn.
4. Anschließend, falls die gesuchte Information noch nicht gefunden
wurde, Abspielen der Audioaufzeichnung.
Damit konnte gezeigt werden, dass die Einbindung von Artefakten als Indizes die Suche gegenüber dem unkoordinierten Abspielen der Aufzeichnungen vereinfacht und beschleunigt. Für den Langzeiteinsatz wurde die Navigation über große Sets von Meeting-Aufzeichnungen nicht nur chronologisch, sondern auch sortiert nach Themen, in Aussicht gestellt. In der Langzeitevaluierung [Lipford et al. 08] findet sich dazu jedoch keine Information.
ARCHIVUS [Lisowska et al. 05] ist ein multimodaler Meeting Browser für
den Informationsabruf gespeicherter und annotierter MeetingAufzeichnungen. Im Gegensatz zu TeamSpace bietet ARCHIVUS keine
Funktionalität zur Informationssicherung, konzentriert sich also allein auf den
Informationsabruf.
Ein Hauptbestandteil des Prototyps ist die multimodale Interaktion mit dem
System. Sprache, Zeiger (Maus und Touch) und Tastatur dienen als aktive,
Emotionserkennung als passive Eingabemethode. Grafiken, Audio und Text
gehören zu den Ausgabemodalitäten. Der ARCHIVUS Prototyp unterstützt
zunächst folgende Daten: Audio- und Videoaufzeichnungen, ASR Transcript
des Meetings inklusive Annotationen, sowie Präsentationsfolien, Whiteboard Aktivitäten und Notizen der Teilnehmer.
Um dem Nutzer die Verwendung des Systems zu erleichtern, bedient sich
ARCHIVUS einer Bibliotheksmetapher, auf der die gesamte Interaktion und
Navigation aufbaut. Dabei wird eine Sammlung an Meeting-Aufzeichnungen
in den Kontext einer Bibliothek übertragen, wobei beispielsweise jedes
Buch einem Meeting entspricht, das Inhaltsverzeichnis der Agenda, und die
im Meeting verwendeten Dokumente als Anhang an das Buch dargestellt
werden (siehe [Lisowska et al. 05]). Abbildung 3.3 zeigt einen Screenshot
der Anwendungsoberfläche.
VERWANDTE ARBEITEN
29
Bereich 1 in Abbildung 3.3 listet alle Meetings in Form von Büchern auf. Hier
können einzelne Meetings direkt ausgewählt und die zugehörigen Aufzeichnungen damit geöffnet werden. Über die Bereiche 2 und 5 erfolgt die Eingabe von Suchbegriffen zur Schlüsselwortsuche, wobei Bereich 2 die Tastatureingabe und Bereich 5 die Spracheingabe unterstützt. Alternativ oder
auch zusätzlich zur Schlüsselwortsuche stellt Bereich 6 Funktionen zum
Filtern nach Ort, Person, Datum, Thema, Ereignis, Dokument und verschiedenen Dialogelementen (Schlussfolgerungen, Fragen, Entscheidungen, etc.)
bereit. Ein Verlauf der ausgewählten Suchkriterien in chronologischer Reihenfolge wird in Bereich 7 angezeigt. Die Hauptinteraktion findet schließlich
in Bereich 4 statt. Hier werden Suchkriterien spezifiziert (beispielsweise
beim Filtern nach Daten mithilfe eines Kalenders), Dokumente geöffnet,
Video- und Audioaufzeichnungen abgespielt sowie konkrete Meeting-Inhalte
angezeigt. Abbildung 3.4 zeigt exemplarisch ein Meeting, welches über die
Suchfunktion aufgerufen wurde. Die oberste Zeile beinhaltet den Namen
des Meetings sowie das aktuelle Kapitel, also den jeweiligen Agendapunkt.
Der Buchtext ist das Sprachtranskript des Meetings, wobei die verschiedenen Sprecher jeweils farblich gekennzeichnet sind und ihre Namen am Seitenrand stehen. Dokumente, die zu den Abschnitten gehören, erscheinen
als Icon ebenfalls am Rand der Seite. Die Pfeile in den unteren Ecken dienen
der Navigation zur vorherigen oder nächsten Seite und über das Audio- und
Video-Icon unterhalb der Seite lassen sich die Audio- und Videoaufzeichnungen zum aktuell gewählten Abschnitt abspielen. Für einen schnellen Wechsel zwischen Suchergebnissen dienen die Register am Buchrand. Die Register auf der rechten Seite stellen dabei die Suchergebnisse innerhalb des
Buches in der Form „x/y“ dar, wobei „x“ die Nummer des Ergebnisses und
30
3.2. Visualisierung zeitbasierter Textkollektionen
„y“ die Gesamtzahl der Suchergebnisse bezeichnet. Innerhalb der aktuellen
Seite wird das Ergebnis zusätzlich hervorgehoben, je nach Länge des betreffenden Abschnittes auch über mehrere Seiten.
Die folgenden beiden Arbeiten stellen zeitabhängige Visualisierungen großer
Textsammlungen und der in ihnen behandelten Themen vor. Ziel der Ansätze ist es, mittels expliziter Darstellung von Zusammenhängen die Informationserschließung zu fördern. Den Schwerpunkt der Visualisierung legen beide Arbeiten auf die Themen, die aus den Dokumenten extrahiert werden,
und deren Entwicklung im Laufe der Zeit. Sie folgen damit den Prinzipien
des Topic Evolution Mining (vgl. Abschnitt 2.2.2).
Die Story Flow Visualisierung [Rose et al. 09] ist Teil eines Systems zur visuellen Verknüpfung von Inhalten aus dynamischen Informationsquellen,
wie beispielsweise Nachrichtenportalen, die kontinuierlich über Themen des
aktuellen Zeitgeschehens informieren. Diese Themen entwickeln sich durch
die Verknüpfung zu neu aufkommender Information nach und nach zu Geschichten (engl. stories) und bilden damit den Story Flow. Ziel des Systems
ist es, diese Geschichten zu visualisieren und den Zugang zu länger zurückliegender Information zu erleichtern. Damit soll das Auffinden von Ursachen,
Beobachten von Entwicklungen sowie die Interaktion mit der Information
unterstützt werden.
VERWANDTE ARBEITEN
31
Abbildung 3.5 zeigt die Story Flow Visualisierung. Sie bildet die Themen auf
einer Zeitachse von links nach rechts ab und ordnet ihnen Dokumente zu,
die diese Themen behandeln. Je nach Anzahl der zugehörigen Dokumente
erfolgt die vertikale Anordnung der Themen. Die Namen der Themen stehen
in Kursivschrift, darunter sind jeweils die Titel der zugehörigen Dokumente
aufgelistet, die außerdem durch einzelne Linien repräsentiert werden. Die
Gesamt-Linienstärke ist dabei direkt proportional zur Anzahl an Dokumenten.
Abbildung 3.6 zeigt die Visualisierung für einen Zeitraum von zwei Wochen.
Jede Linie zieht sich solange nach rechts fort, wie das jeweilige Dokument
einem Thema zugeordnet ist. Aus einzelnen Themen entstehen Geschichten, wenn sie durch die Dokumentlinien miteinander verbunden sind. Verzweigungen zwischen Linien bedeuten, dass einige Dokumente zunächst
dem gleichen Thema, später verschiedenen Themen zugewiesen werden,
sich also aus einem Thema verschiedene Geschichten entwickeln. So wird
die Entwicklung einer Geschichte letztendlich anhand der Linienführung
dargestellt.
32
3.2. Visualisierung zeitbasierter Textkollektionen
EventRiver [Luo et al. 12] visualisiert reale Ereignisse anhand ihres zeitlichen
Auftretens und ihrer Auswirkungen auf andere Ereignisse, ähnlich wie Story
Flow. Ziel ist gleichermaßen die Unterstützung bei der Analyse und Informationssuche von Inhalten aus großen Textsammlungen, wobei hier neben
Nachrichtensammlungen auch Blogs oder E-Mail-Archive als mögliche Quellen genannt werden. Die Visualisierung soll dabei sowohl dem freien Durchsuchen der Daten zum Entdecken semantischer und zeitlicher Zusammenhänge, als auch dem gezielten Verfolgen von Entwicklungen dienen.
Jedes Ereignis wird durch eine farbige Blase repräsentiert (siehe Abbildung
3.7). Die horizontale Ausbreitung einer solchen Ereignisblase gibt die Zeitspanne an, in der das Ereignis Aufmerksamkeit auf sich gezogen hat. Die
vertikale Ausdehnung der Blase ist direkt proportional zur Bedeutung (beziehungsweise dem Einfluss) des Ereignisses zu einem Zeitpunkt, festgelegt
durch die Anzahl an Dokumenten, in denen es auftritt. Damit ist die Signifikanz eines Ereignisses über den Vergleich zur Blasengröße anderer Ereignisse ersichtlich. Die Farbe liefert die Zuordnung zu einer Reihe verwandter
Ereignisse, also einer Geschichte.
Abbildung 3.8 zeigt die Visualisierung einer realen Textsammlung. Die einzelnen Ereignisblasen sind je nach dem Zeitpunkt ihres Auftretens anhand
einer Zeitachse (oberer Bildrand) horizontal eingeordnet, wobei länger zurückliegende Ereignisse weiter links im Bild positioniert sind und aktuellere
Ereignisse weiter rechts. Die vertikale Anordnung ergibt sich aus der Einhaltung folgender Regeln:
1. Verwandte Ereignisse werden in ähnlicher Höhe positioniert.
2. Geschichten werden höher angeordnet je wichtiger sie sind. Die
Wichtigkeit wird aus verschiedenen Kriterien berechnet.
3. Innerhalb einer Geschichte werden Ereignisse zunächst nach Startzeitpunkt, anschließend nach höchster Bedeutung und schließlich
nach ihrer Dauer priorisiert. Je höher die Priorität, desto höher die
Position.
4. Es gibt keine Überschneidungen von Blasen.
Verwandte Ereignisse spannen somit Geschichten über einen längeren Zeitraum auf, wobei gegenseitige Einflüsse der Ereignisse einer Geschichte
offenbart werden.
VERWANDTE ARBEITEN
33
Dem Nutzer bieten sich verschiedene Interaktionsmöglichkeiten. Er kann
zum Beispiel einen Ausschnitt auf der Zeitachse festlegen, sodass nur Ereignisse des gewählten Zeitraums angezeigt werden. Eine Filterung der
Ereignisse nach ihrer Wichtigkeit ist ebenfalls möglich. Außerdem kann eine
Neuberechnung der Wichtigkeit der Geschichten durch Änderung der Kriterien erfolgen. Beim Hineinzoomen in die Visualisierung erscheinen Beschriftungen, die nähere Informationen zu den Ereignissen und Geschichten liefern (siehe Abbildung 3.9). Ereignisse können verschoben oder ausgeblendet werden, um Überlappungen der Beschriftungen aufzuheben. Weiterhin
kann eine Schlüsselwortsuche über den Ereignissen und den ihnen zugehörigen Dokumenten durchgeführt werden.
Durch Anklicken eines Ereignisses öffnet sich schließlich ein neues Fenster,
welches eine Liste der zugehörigen Dokumente beinhaltet und das jeweils
ausgewählte Dokument vollständig darstellt (vgl. Abbildung 3.10). Mehrere
Ereignisse können damit durch gleichzeitige Auswahl im Detail untersucht
und verglichen werden.
34
Dieses Kapitel stellt vier Forschungsarbeiten vor, deren Schwerpunkte in
zwei verschiedenen Bereichen liegen. Die beiden Meeting Browser
TeamSpace [Richter et al. 01] und ARCHIVUS [Lisowska et al. 05] spezialisieren sich auf die Darstellung multimedialer Meeting-Aufzeichnungen unter
Einbeziehung weiterer Meeting-Inhalte, wobei sie verschiedene Interaktionsansätze verfolgen. Die Visualisierungsansätze von Story Flow [Rose et al.
09] und EventRiver [Luo et al. 12] dienen vor allem der Darstellung großer
Textsammlungen mit Zeitbezug, und weichen damit sowohl in ihrer Datengrundlage, als auch in der Zielstellung, von den beiden Meeting Browsern
ab.
Alle diese Arbeiten weisen jedoch Gemeinsamkeiten auf. Sowohl die hier
vorgestellten Meeting Browser, als auch die Systeme zur Visualisierung,
haben die Unterstützung des Informationsabrufs zum Ziel und legen den
Schwerpunkt dabei auf Themen. Der Zeitbezug ist zwar bei beiden Visualisierungen deutlicher ausgeprägt als bei den Meeting Browsern, doch auch
bei diesen wird er berücksichtigt – bei TeamSpace mit der Zeitleiste für ein
einzelnes Meeting, bei ARCHIVUS anhand der Filterfunktionen für die Meeting-Daten. Alle Systeme stellen außerdem den Zugriff auf inhaltlich relevante Dokumente bereit. Im Rahmen der Analyse im nächsten Kapitel bewertet
Abschnitt 4.3 die hier vorgestellten Systeme im Hinblick auf die Zielstellung
der vorliegenden Arbeit.
Dieses Kapitel ist in vier Bereiche gegliedert. Der erste Abschnitt dient der
Problemanalyse und umfasst die Beschreibung der Anwendungsfälle, die
mit dem Konzept umzusetzen sind. Darauf aufbauend definiert der zweite
Teil der Analyse die Datengrundlage für das Konzept. Die Untersuchung und
Bewertung der in Kapitel 3 vorgestellten verwandten Arbeiten hinsichtlich
ausgewählter Aspekte erfolgt in Abschnitt 4.3. Aus den Ergebnissen und
Erkenntnissen dieser drei Bereiche werden im letzten Abschnitt die Anforderungen an das eigene Konzept abgeleitet.
Im Hinblick auf den Forschungsschwerpunkt von Vizamp (vgl. Kapitel 1)
konzentriert sich die vorliegende Arbeit auf einen Bereich aus dem umfassenden Gebiet des Projektmanagements: die Projektmeetings. Sie nehmen
einen signifikanten Teil der Arbeitszeit ein [Romano et al. 01] und sind heutzutage mehr denn je als Kollaborationsmethode gefragt [S. Yu et al. 10].
Meetings dienen der Kommunikation zwischen Projektmitgliedern, der Koordination von Prozessen und der kollaborativen Projektplanung (siehe Abschnitt 2.1). Die dabei ausgetauschten sowie neu entstehenden Informationen sind essentiell für den Projektfortschritt und müssen gesichert werden
(engl. capture), um einen späteren Informationsabruf (engl. retrieval) zu ermöglichen:
“However, without suitable capture and retrieval mechanisms, these
important information are prone to being interpreted incorrectly or differently by different people, in addition to fading in memory over time.”
[S. Yu et al. 10]
In diesem Kontext fokussiert sich die vorliegende Arbeit auf das Szenario
des Informationsabrufs. Meeting-Aufzeichnungen werden in allen Phasen
des Meeting-Zyklus verwendet (siehe Abschnitt 2.1.5): vor dem Meeting, im
Meeting und nach dem Meeting, was üblicherweise wiederum vor dem
nächsten Meeting ist. Der Informationsabruf dient dabei vorrangig einem
der beiden folgenden Zwecke (vgl. [Whittaker et al. 06]):
38
4.1. Problemanalyse
1. Suche: Das Auffinden von Informationen
2. Analyse: Die Beschaffung eines Überblicks über Themen- oder Projektstatus
Zur Untersuchung spezifischer Anwendungsfälle haben sich verschiedene
Studien (siehe [Lisowska 03], [Pallotta et al. 07] und [Banerjee et al. 05]) mit
Nutzeranfragen an Meeting-Aufzeichnungen beschäftigt. Einige Fragestellungen, die die Autoren in ihren Studien herausgestellt haben, profitieren in
vielen Fällen von der Unterstützung eines Meeting-übergreifenden Informationsabrufs und spielen im weiteren Verlauf der vorliegenden Arbeit eine
gesonderte Rolle. Diese Fragestellungen
lassen sich drei HauptAnwendungsfällen zuordnen, welche entweder der Suche oder der Analyse
dienen:
Auffinden von Informationen (SUCHE)






Was wurde besprochen?
Was wurde zu einem Thema besprochen?
Wie lautete eine Entscheidung genau?
Wie lautete eine Aussage zum Thema?
Warum wurde eine bestimmte Entscheidung getroffen?
Welche Aufgaben wurden deklariert?









Was wurde besprochen?
Was wurde zu einem Thema besprochen?
Wie lautete das Ergebnis genau?
Warum wurde eine bestimmte Entscheidung getroffen?
Welche Aufgaben wurden deklariert?
Wurde das Thema weitergeführt?
Gab es Entscheidungen zu Diskussionen vorheriger Meetings?
Was ist aus Aufgabe „xy“ geworden?
Welche Dokumente wurden betrachtet?
Überblick zu Projekt- oder Themenstand (ANALYSE)






Wo besteht noch Gesprächsbedarf?
Welche Themen wurden noch nicht abgeschlossen und warum?
Welche Aufgaben wurden erledigt, welche nicht?
Weshalb wurden Aufgaben noch nicht erledigt?
Gibt es Ideen oder Lösungsvorschläge, die noch nicht umgesetzt
wurden?
Bedarf es einer Entscheidung, zu welchen Punkten?
Die beiden Anwendungsfälle des ersten Szenarios unterscheiden sich hinsichtlich der Fragestellungen nur wenig. Die Differenz besteht im Bezugs-
ANFORDERUNGSANALYSE
39
rahmen: Beim Anwendungsfall 1 weiß der Nutzer, in welcher Form und in
welchem Umfang das Ergebnis seiner Suche ausfallen wird. Bei Anwendungsfall 2 dagegen hat der Nutzer keine oder kaum Informationen zum
Kontext des Gesuchten.
Die folgenden schematischen Darstellungen demonstrieren, inwiefern sich
die Anwendungsfälle bei Meeting-übergreifendem Informationsabruf von
der Verwendung einzelner Aufzeichnungen unterscheiden. Abbildung 4.1
stellt das Vorgehen beim Ausführen einer Suchanfrage (Anwendungsfall 1)
gegenüber. Die Nummern 1-4 bezeichnen die einzelnen Meetings. Die
Buchstaben A-G stehen für verschiedene Themen, wobei gleiche Buchstaben das gleiche Thema repräsentieren. Die Stellen, an denen Ergebnisse der
Suchanfrage auftreten, sind mit einem „x“ gekennzeichnet. Einzelne Meeting-Aufzeichnungen müssen separat durchsucht und geöffnet werden (siehe Abbildung 4.1, links). Eine zusammenhängende Abbildung der Suchergebnisse, wie von EventRiver [Luo et al. 12] umgesetzt, beschleunigt unter
Umständen das Auffinden der gesuchten Information erheblich. Dabei werden aus den Meeting-Aufzeichnungen die Stellen extrahiert, die den Suchbegriff beinhalten, und gleichzeitig dargestellt (siehe Abbildung 4.1, links).
Anwendungsfall 2 betrifft häufig einen Zeitraum, in dem ein oder mehrere
Meetings verpasst wurden. In diesem Fall werden üblicherweise die entsprechenden Aufzeichnungen ebenfalls separat geöffnet. Bestehen Zusammenhänge zu vorherigen oder nachfolgenden Meetings, sind diese nicht
ersichtlich. In diesem Fall werden möglicherweise relevante Informationen
außer Acht gelassen. Eine Meeting-übergreifende Darstellung bietet auch
hier den Vorteil, dass die Inhalte der verpassten Meetings im Kontext aller
relevanten Informationen ersichtlich sind. Außerdem kann man sich auf die
Themen der Reihenfolge nach konzentrieren (siehe Abbildung 4.2).
40
4.1. Problemanalyse
Beim Erstellen der Agenda (Anwendungsfall 3) wird üblicherweise die Aufzeichnung des letzten Meetings betrachtet und daraus Gesprächsbedarf zu
offenen Sachverhalten entnommen. Dabei gehen unter Umständen Inhalte
verloren, die das letzte Meeting beeinflusst haben oder in vorhergehenden
Meetings Fragen offen gelassen haben. Die gleichzeitige Anzeige der Inhalte mehrerer Meetings gewährleistet, dass alle relevanten Informationen
ersichtlich sind (siehe Abbildung 4.3).
Projekte haben Laufzeiten von mehreren Wochen, Monaten oder auch Jahren, während Meetings zur Projekt-Besprechung meist in regelmäßigen
Abständen stattfinden und unterschiedlich umfassend sind. Das bedeutet,
dass keine allgemeingültigen Aussagen zum Umfang der MeetingAufzeichnungen eines Projekts getroffen werden können. Je mehr Zeit im
Anschluss an ein Meeting vergeht, desto mehr verblassen Erinnerungen
daran und umso schwieriger wird es besonders bei langen Projektlaufzeiten,
Inhalte von Interesse aufzufinden. Um den Informationsabruf effizienter zu
gestalten, bieten Meeting-Aufzeichnungen daher einige Anhaltspunkte, wie
zum Beispiel eine Strukturierung der Inhalte mittels Listen, oder eine Übersicht der Themen in Form der Agenda (siehe Abschnitt 2.1.4). Bis auf den
Hinweis der zeitlichen Einordnung beziehen sich diese jedoch nur auf ein
einzelnes Meeting - der Meeting-Zyklus (Abschnitt 2.1.5) und seine Implikationen auf Meeting-Inhalte werden derzeit größtenteils vernachlässigt.
In Abschnitt 2.1.5 wurde bereits darauf eingegangen, dass Themen häufig in
mehreren Meetings besprochen werden. Es bestehen also inhaltliche Zusammenhänge zwischen den Meetings, die auch in Hinsicht auf die Anwendungsfälle und Fragestellungen aus Abschnitt 4.1.1 berücksichtigt werden
müssen. Die dem Meeting Browser ARCHIVUS zugrunde liegende Studie
ANFORDERUNGSANALYSE
41
[Lisowska 03] stellte heraus, dass zur Beantwortung der Hälfte aller Fragen
zu Meeting-Inhalten die Aufzeichnungen mehrerer Meetings betrachtet
werden müssen. Forderungen nach Meeting-übergreifender Darstellung von
Inhalten wurden bisher dennoch von keinem System umgesetzt.
Die herkömmliche Vorgehensweise beim Informationsabruf anhand mehrerer Meeting-Aufzeichnungen besteht in einer Suchanfrage über alle Aufzeichnungen, aus der einzelne Meetings als Ergebnis hervorgehen. Die zugehörigen Aufzeichnungen werden anschließend einzeln betrachtet (vgl.
Abschnitt 4.1.1). Allein die Fragestellung zum Inhalt eines Themas kann sich
dann als zeitintensive Angelegenheit erweisen, und das Erkennen von Zusammenhängen wird erschwert. Weitere Anwendungsfälle, wie die Fortschrittsverfolgung einer Aufgabe, die in einem Meeting zugewiesen wurde
[Whittaker et al. 06], ergeben sich sogar erst aus einer Meetingübergreifenden Darstellung der Inhalte. Es ist also stark anzunehmen, dass
ein Werkzeug zur Analyse einer Reihe von Meetings („Multi-Meeting Analysis Tool“) einen Mehrwert gegenüber existierenden Ansätzen bietet [Tucker
et al. 05]. Daraus leitet sich die Zielstellung der vorliegenden Arbeit ab.
Ziel dieser Arbeit ist die Konzeption eines Werkzeugs zur Unterstützung des
Informationsabrufs von Meeting-Inhalten über eine Folge von Meetings
hinweg. Der Schwerpunkt liegt auf der Visualisierung der Inhalte einer Reihe
von Meetings und ihren Zusammenhängen. Zur Bearbeitung der Anwendungsfälle (siehe Abschnitt 4.1.1) wird weiterhin ein Interaktionskonzept
entwickelt. Dabei werden besonders solche Fragestellungen berücksichtigt,
deren Beantwortung durch die Meeting-übergreifende Darstellung von Inhalten einen Mehrwert erfährt.
Trotz jahrzehntelanger Forschung und Entwicklung im Bereich automatischer und halbautomatischer14 Informationssicherung werden weiterhin
hauptsächlich Notizen und Protokolle zu diesem Zweck genutzt und dominieren somit auch beim Informationsabruf (vgl. [Whittaker et al. 06]). Eine
Ursache für diesen Umstand sehen WHITTAKER ET AL. in der fehlenden Abstraktion der Systeme:
“The main failings of meeting browsers seem to be that they are largely only able to offer a view of a single meeting, that there is not layer of
abstraction between the user and the underlying data and annotations
[…]”[Whittaker et al. 06]
14
Smartphone-basierte Anwendungen wie Mobileessence [Johnson 07], MarkUp As You Talk
[Kalnikaitė et al. 12] oder das elektronische Notizbuch NiCEBook [Brandl et al. 10]
42
4.1. Problemanalyse
Sie erachten eine Abstraktion der Meeting-Inhalte als notwendig für ein
Multi-Meeting Analyse-Werkzeug. Textprotokolle und Notizen liefern eine
solche Abstraktion: Die Zuordnung von Inhalten zu Themen sowie die Kategorisierung in Aufgaben, Entscheidungen oder andere Dialogelemente stellt
eine Zusammenfassung der wichtigsten Inhalte dar (vgl. [Whittaker et al.
07]). Während Notizen als persönliche Aufzeichnungsform meist nur für den
Notierenden selbst bestimmt und daher eine subjektive Zusammenfassung
liefern, stellen Protokolle eine öffentliche15, objektive Informationsquelle dar
(vgl. Abschnitt 2.1.3). Aus diesem Grund orientiert sich das Konzept dieser
Arbeit an Struktur und Aufbau von Meeting-Protokollen.
Abbildung 4.4 zeigt die Einordnung der Zielstellung in den Gesamtablauf
bestehend aus Informationssicherung, Informationsabruf und Informationsaustausch. Zunächst erfolgt im Anschluss an ein Meeting die Informationssicherung, welche sich in Digitalisierung und semantische Anreicherung
gliedert. Unter der Annahme, dass die Inhalte mehrerer aufeinanderfolgender Meetings bereits semantisch angereichert vorliegen, schließt sich das
Visualisierungs- und Interaktionskonzept mit dem Ziel der Unterstützung des
Informationsabrufs an. Beim Informationsaustausch werden die Informationen in weiteren Prozessen verwertet und unter Umständen mit anderen
Inhalten verknüpft. Wie in Abschnitt 4.1.1 erläutert, spezialisiert sich die
vorliegende Arbeit auf das Szenario des Informationsabrufs.
15
Für alle Berechtigten, am Projekt beteiligten Personen zugänglich
ANFORDERUNGSANALYSE
43
Ziel dieses Analyseteils ist es, eine fundierte Datengrundlage für das Visualisierungs- und Interaktionskonzept zu erarbeiten. Deshalb wird an dieser
Stelle das Meeting anhand grundlegender Strukturen betrachtet. Zur Erleichterung der Lesbarkeit werden im Folgenden alle inhaltlich relevanten Daten
eines Meetings, wie Dokumente, Themen, Agenda, Datum, etc., unter dem
Begriff „Meeting-Inhalte“ zusammengefasst. Der Begriff „Inhalte“ alleinstehend bezeichnet hingegen die Gesprächsgegenstände eines Meetings,
also die Informationen zu den Themen.
Im Rahmen der Studie zu TeamSpace [Lipford et al. 08] wurde die Heterogenität vieler Meetings in Bezug auf ihre Ziele und den Ablauf festgestellt
(vgl. Abschnitt 2.1.2). Gleichzeitig wurde erkannt, dass die meisten Meetings dennoch eine ähnliche inhaltliche Struktur aufweisen. Um möglichst
viele Meetings unterstützen zu können, haben LIPFORD ET AL. solch einen
allgemeinen Meeting-Aufbau definiert, wobei sie sich zumindest auf den
Kontext des Projektmanagements festlegen. Nach LIPFORD ET AL. gelten
folgende Aussagen: Meetings basieren auf einer Agenda, enthalten Präsentationen und sonstige Dokumente zum Informationsaustausch. Weiterhin
gehört jedes Meeting einem Projekt an und wird innerhalb dieses Projekts
anhand des Meeting-Datums definiert. Eine Folge von Meetings ergibt sich
somit aus chronologisch aufeinanderfolgenden Zeitpunkten, zu denen Projekt-Inhalte besprochen werden. Diese Inhalte werden in MeetingProtokollen festgehalten. Dabei sind die Themen eines Meetings die wichtigsten Anhaltspunkte zur Strukturierung (vgl. [Lisowska et al. 04]): Sie fassen Inhalte unter einem aussagekräftigen Titel zu einer Einheit zusammen
und bilden in ihrer Gesamtheit pro Meeting die Agenda 16.
Es wurde bereits beschrieben, dass Notizen und Textprotokolle eine abstrakte Repräsentation von Meeting-Inhalten darstellen, indem Inhalte Themen zugeordnet und in verschiedene Dialogelemente kategorisiert werden
(vgl. Abschnitt 4.1.4). Welche Kategorien mit dem Konzept dieser Arbeit
unterstützt werden sollen, wird anhand der Ergebnisse aus vier Studien zu
Meeting-Aufzeichnungen ([Brandl et al. 10], [Ispas et al. 10], [Khan 93] und
[Lisowska et al. 04]) untersucht. ISPAS ET AL., BRANDL ET AL. und KHAN analysierten den Inhalt von Meeting-Notizen mit dem Ziel, das Notieren selbst zu
unterstützen. LISOWSKA ET AL. zeigen hingegen, welche Arten von Informati16
Einen ähnlichen Meeting-Aufbau beschreibt auch MARCHAND-MAILLET in seinem Modell für
Meeting-Aufzeichnungen [Marchand-Maillet 03]
44
4.2. Datenanalyse
onen Nutzer mithilfe von Meeting-Aufzeichnungen abrufen. Obwohl die
Studien verschiedenen Zielen dienen, geben alle einen Überblick über die
Inhalte, die in Meetings besprochen werden, und benennen verschiedene
Inhaltskategorien. Tabelle 4.1 listet alle genannten Kategorien und ihre Nennung in den vier Studien auf.




































Folgende Kategorien gehen aus Tabelle 4.1 mit drei oder vier Nennungen als
besonders wichtig hervor: „Aufgabe“, „Kontakt“, „Termin“, „Idee“ und
„Entscheidung“, wobei „Entscheidung“ in der vorliegenden Arbeit allgemeiner als „Beschluss“ bezeichnet wird. Die Kategorie „Kontakt“ wird vernachlässigt, da die Suche nach Kontaktdaten keinen Anwendungsfall im
Sinne der Zielstellung darstellt. Weiterhin wird die Kategorie „Gesprächspunkt“ zur Repräsentation der weniger häufig genannten Kategorien hinzugefügt. Zusammen mit den Feststellungen zum allgemeinen MeetingAufbau aus Abschnitt 4.2.1 ergibt sich damit die in Abbildung 4.5 dargestellte Meeting-Struktur.
ANFORDERUNGSANALYSE
45
Im Rahmen der Literaturrecherche fanden sich zwei Arbeiten, die das Thema Meeting-übergreifender Zusammenhänge aufgreifen: zum einen ein
Modell für Meeting-Aufzeichnungen [Marchand-Maillet 03], zum anderen die
zuvor genannte Studie von LISOWSKA [LISOWSKA 03]. Tabelle 4.2 stellt die
Relationen zwischen Meeting-Inhalten und -Dokumenten aus beiden genannten Arbeiten gegenüber, wobei nur solche Relationen berücksichtigt
werden, die die zuvor beschriebene Datengrundlage betreffen.
A.
C.
D.
E.
F.
Themen über mehrere Meetings hinweg
B. Inhalt und Thema
Entscheidung und Thema
Gesprächspunkt und Thema
Aufgabe und Projekt
Dokument und Projekt
G.
Dokument und Thema
Angelehnt daran werden die Relationen R1 bis R6 aufgestellt, welche für
das Konzept relevant sind. Bei den Punkten „Inhalt und Thema“ (B), „Entscheidung und Thema“ (C) und „Gesprächspunkt und Thema“ (D) handelt
es sich bezüglich der hier definierten Datengrundlage jeweils um die Relation Inhalt – Thema. Aus diesem Grund werden die drei Punkte in Relation R3
zusammengefasst. Der Punkt „Aufgabe und Projekt“ (E) fließt ebenfalls R3
zu, da „Aufgaben“ in dieser Arbeit nicht dem Projekt, sondern einem Thema
angehören. Die Relation R6 vereinigt die Punkte „Dokument und Projekt“
(F) sowie „Dokument und Thema“ (G) in sich. Im Sinne der Zielstellung
werden mit R2, R3 und R4 drei weitere Relationen eingeführt, welche nicht
direkt aus der Tabelle hervorgehen. Sie dienen der zusätzlichen semantischen Trennung von Thema und Inhalt, die einer noch detailliertere Verknüpfung von Inhalten ermöglicht.
46
4.2. Datenanalyse
Im Folgenden werden die Relationen R1 bis R6 definiert und beispielhaft
beschrieben. Zu diesem Zweck werden Fragestellungen aus Abschnitt 4.1.1
aufgegriffen. Abbildung 4.6 bildet die Relationen anhand der zuvor definierten Meeting-Struktur ab.
Ein Thema kann mehreren Meetings zugeordnet sein, das heißt es wird in
diesem Fall im Projektverlauf über einen längeren Zeitraum besprochen.
Frage: Was wurde zu einem Thema besprochen? (Anwendungsfall 1
und 2)
Ist ein Inhalt mehreren Meetings zugeordnet, bedeutet das, dass er nicht
innerhalb eines Meetings abgeschlossen wurde. Im Speziellen lässt sich
diese Relation auf Aufgaben oder Ideen übertragen, welche noch „offen“
sind – das heißt, sie wurden in einem Meeting benannt, und in einem späteren Meeting aufgegriffen, ohne dass Veränderungen am Inhalt erkennbar
sind.
Frage: Welche Aufgaben wurden erledigt, welche nicht? Weshalb wurden Aufgaben noch nicht erledigt? Gibt es Ideen oder Lösungsvorschläge, die noch nicht umgesetzt wurden? (Anwendungsfall 3)
Ein Inhalt gehört immer einem Thema an. Bei der Meeting-übergreifenden
Darstellung wird der komplette Inhalt zu einem Thema auf einen Blick ersichtlich, und damit der gesuchte Inhalt möglicherweise schneller gefunden.
ANFORDERUNGSANALYSE
47
Frage: Wie lautete ein Beschluss? (Anwendungsfall 1) Weshalb wurde
ein Thema noch nicht abgeschlossen? Gibt es offene Aufgaben? (Anwendungsfall 3)
Ein Inhalt kann weiterhin mit einem anderen Thema verknüpft werden. Ein
Beispiel dafür ist das Ableiten eines eigenständigen Themas aus einer Idee
oder einer Aufgabe, die innerhalb eines anderen Themas entstand.
Frage: Was wurde aus Aufgabe „xy“? (Anwendungsfall 3)
Inhalte der gleichen Kategorie oder verschiedener Kategorien können verknüpft sein. Wird beispielsweise eine Aufgabe aus einem vorherigen Meeting ausgewertet, entsteht neuer Inhalt (z. B. ein Gesprächspunkt). Eine
Verknüpfung ist auch dann relevant, wenn die Gründe für eine getroffene
Entscheidung gesucht werden.
Frage: Weshalb wurde ein Beschluss getroffen? (Anwendungsfall 1)
Weshalb wurde die Aufgabe noch nicht erledigt? (Anwendungsfall 3)
Zwei Themen können zusammenhängen, wenn sie ähnliche Inhalte behandeln, jedoch verschiedene Schwerpunkte betrachten, oder wenn sie inhaltlich aufeinander aufbauen. Beispielsweise kann ein Thema, welches Probleme im Projekt behandelt, von möglichen Lösungsansätzen gefolgt werden. Dann heißen die Themen „Problem“ und „Lösung“, werden also vom
System aufgrund der verschiedenen Namen getrennt voneinander behandelt, bauen jedoch aufeinander auf.
Frage: Was wurde zu einem Thema besprochen? (Anwendungsfall 1)
Wurde das Thema weitergeführt? (Anwendungsfall 2)
Dokumente können einem Thema zugeordnet sein. Bei der Suche nach
einem Dokument, welches in einem Meeting besprochen wurde, ist über
einen längeren Zeitraum das Thema der markantere Anhaltspunkt. Deshalb
profitiert auch folgende Fragestellung von der Verknüpfung von MeetingInhalten:
Frage: Was sagte Dokument „xy“ dazu aus? (Anwendungsfall 1)
Die verwandten Arbeiten aus Kapitel 3 werden in diesem Abschnitt im Hinblick auf ihre Visualisierungsansätze und vorhandenen Interaktionsmöglich17
R6 stellt im Sinne der Abgrenzung der Arbeit eine zusätzliche Relation dar.
48
4.3. Bewertung der verwandten Arbeiten
keiten untersucht und bewertet. Den Betrachtungen liegen die Ergebnisse
der zuvor erfolgten Datenanalyse (Abschnitt 4.2) zugrunde. Dieser Analyseteil stellt die Einsatzpotentiale der Arbeiten hinsichtlich der Zielstellung der
vorliegenden Arbeit heraus und zeigt gleichzeitig Schwachpunkte auf, die
mit dem eigenen Konzept (siehe Kapitel 1) auszugleichen sind.
Die Meeting Browser, die in Abschnitt 3.1 vorgestellt wurden, bedienen sich
hauptsächlich Listen und Tabs zur Darstellung der Informationen, wobei
ARCHIVUS [Lisowska et al. 05] diese mit einer Buchmetapher kombiniert.
TeamSpace [Richter et al. 01] liefert mit der Zeitachse darüber hinaus eine
visuelle Zusammenfassung für jedes Meeting. Hier kommen die visuellen
Variablen Farbe und Position zur Anwendung. Die gleichzeitige Betrachtung
mehrerer Meetings ist möglich, Zusammenhänge werden dabei jedoch nicht
explizit dargestellt. Beide Meeting Browser gehen nicht über die herkömmliche Suchfunktion über alle Aufzeichnungen hinaus (vgl. Abschnitt 4.1.2)
und bieten keine Visualisierung Meeting-übergreifender Zusammenhänge.
Eingehender untersucht werden an dieser Stelle die Visualisierungsansätze
von EventRiver [Luo et al. 12] und Story Flow [Rose et al. 09]. Beide Systeme fokussieren sich auf die Repräsentation von Zusammenhängen textlicher Inhalte, womit sie eine ähnliche Zielstellung verfolgen wie die vorliegende Arbeit. Dazu werden Inhalte an eine Zeitachse projiziert und die Relationen zwischen ihnen visualisiert. Weitere visuelle Hilfsmittel werden eingesetzt, um die Leserichtung zu beeinflussen. Damit sollen sich Zusammenhänge schneller und einfacher erschließen, als es beim Lesen der Dokumente allein möglich wäre. Die Relationsvisualisierung beider Arbeiten
trägt maßgeblich zur Beeinflussung der Leserichtung und damit zur Erschließung von Zusammenhängen bei, weshalb die Arbeiten in dieser Hinsicht bewertet werden.
Zur Bewertung der Visualisierungsansätze im Hinblick auf die Zielstellung
der vorliegenden Arbeit muss zunächst die eigene Datengrundlage auf
EventRiver und Story Flow übertragen werden (siehe Tabelle 4.3), wobei
einige Kompromisse notwendig sind. So wird bei beiden Arbeiten das Meeting sehr frei als Zeitraum ausgelegt. Diese Herleitung ergibt sich aus der
Unterscheidung von Meetings anhand ihres Datums. Inhaltskategorien und
die Agenda lassen sich nicht übersetzen, was zur Bewertung der Relationsvisualisierung allerdings ohnehin vernachlässigt werden kann. Dokumente
im Sinne der beiden Arbeiten repräsentieren die visualisierten Inhalte, weshalb auch die Dokumente im Sinne der vorliegenden Arbeit vernachlässigt
werden.
ANFORDERUNGSANALYSE
49
Zeitpunkt, diskret
Position
Zeitraum, kontinuierlich
Position
Thema
Position
Thema – Gesamtheit der
Ereignisse
Farbe, Position
Dokumenttitel
Position, Linienstärke (Größe)
Ereignisblase
Form, Größe, Position
Ereignisse werden bei EventRiver über einen Zeitraum hinweg visualisiert,
bei Story Flow jedoch nur zu einem festen Zeitpunkt. Die diskrete Zeitachse
bei Story Flow lässt sich besser auf die Meeting-Daten anwenden, als die
kontinuierliche Zeitachse bei EventRiver, da Meeting-Inhalte den Stand zum
Zeitpunkt des Meetings repräsentieren und zwischen Meetings nicht in
diesem Kontext betrachtet werden. Das hat einen unmittelbaren Effekt auf
die Visualisierung der Inhalte, welche bei EventRiver in Form der Ereignisblasen eine horizontale Ausdehnung besitzen, die nur in einem Zeitbereich,
nicht aber auf einem Zeitpunkt abgebildet werden kann. Aus diesem Grund
ist die Form keine geeignete visuelle Variable zur Repräsentation von Meeting-Inhalten. Die Größe spielt bei beiden Arbeiten eine Rolle zur Repräsentation der Inhalte und steht in Relation zu ihrem Umfang 18, der auch bei der
Abbildung von Meeting-Inhalten relevant ist. So nehmen unter Umständen
die Inhalte von Themen, die ausführlicher besprochen wurden, mehr Platz
im Protokoll ein. Für eine Kategorisierung der Inhalte, wie sie die Datengrundlage der vorliegenden Arbeit vornimmt, bietet sich keine der beiden
Darstellungsformen an.
Tabelle 4.4 stellt gegenüber, welche der in Abschnitt 4.2.3 definierten Relationen die Visualisierungen darzustellen vermögen und mithilfe welcher
visuellen Variablen dies geschieht.
Position am Zeitstrahl
Position am Zeitstrahl
Farbe
Linie - Richtung, Position
am Zeitstrahl
Farbe und Position der
Ereignisblasen
zeitliche Abfolge – Position
Linienführung (Form), Position am Zeitstrahl
18
EventRiver übersetzt die Menge an Dokumenten in die horizontale Ausdehnung, Story Flow
in die Linienstärke. Je mehr Dokumente es gibt, desto mehr Inhalte, desto größer die Blase /
stärker die Linie
50
Story Flow unterscheidet Themen nur anhand ihrer Namen, weshalb auf den
ersten Blick besonders bei der Anzeige eines längeren Zeitraums nicht erfasst werden kann, wo ein Thema anfängt und aufhört und wo sich ein neues Thema daraus entwickelt. Die Farbkodierung der Themen bei EventRiver
ist visuell schneller erfassbar, und damit auch ihre Zuordnung zu (Meeting-)
Zeiträumen (R1, vgl. Abbildung 4.8). Allerdings muss die Farbkodierung der
Themen insofern kritisch betrachtet werden, dass es keine maximale Anzahl
an Themen gibt, der Unterscheidbarkeit von Farben beim Auge jedoch eine
Grenze gesetzt ist. Innerhalb der Themen sind die Inhalte bei EventRiver
über ihre Position in zeitlichen Zusammenhang gesetzt. Jedoch lassen sich
durch die alleinige Nutzung von Farbe und Position zur Relationsvisualisierung keine Zusammenhänge zwischen verschiedenen Themen oder Inhalten
verschiedener Themen darstellen (R3, R4). Die Storyboard-Funktion (Ansicht
der Detailfenster mehrerer Ereignisse in chronologischer Reihenfolge) bietet
keine ausreichende Alternative, da die Inhalts-Details in separaten Fenstern
angezeigt werden, wodurch der Zusammenhang zwischen ihnen verloren
geht. Story Flow hingegen realisiert diese Zusammenhänge mithilfe von
Linien. Ein Ziel der Story Flow Visualisierung ist es, Ursachen und Entwicklungen der „Geschichten“ darzustellen. Dazu werden Verknüpfungen zwischen verschiedenen Themen unterstützt, was der Relation R4 entspricht.
Da die Linien sich jedoch nicht eindeutig zu den Inhalten zuordnen lassen,
ist eine Relation verschiedener Inhalte nicht herauszulesen. Weiterhin überdecken die Linien den Text, wenn Inhalte verknüpft werden, zwischen denen ein oder mehr erfasste Zeitpunkte liegen (vgl. Abbildung 4.7).
Die Interaktion der verwandten Arbeiten wird anhand von Suchstrategien
erläutert und bewertet, da das Werkzeug hauptsächlich dem Informationsabruf dienen soll. Drei Suchstrategien sollten von einem Werkzeug zum
Informationsabruf bereitgestellt werden (vgl. [Marchionini 06] und [Pallotta
et al. 07]): browsing, querying und filtering – Browsen, Suchen und Filtern.
Browsen: Bezeichnet einerseits das „Schauen ohne Intention“, andererseits das Interagieren mit und Navigieren durch eine Anwendung
(vgl. [Jansen 02]). Dazu gehören das Auswählen von Elementen, Zoomfunktionen und Scrollen.
Suchen: In diesem Zusammenhang speziell das Ausführen von Suchanfragen in Form (mehrerer) Schlüsselwörter. Liefert Ergebnisse, auf
Basis derer wiederum Suchstrategien ausgeführt werden können.
Filtern: Filterfunktionen bestehen in der Auswahl (und Abwahl) oder
Eingrenzung von Werten vorgegebener Konzepte. Schränkt eine Menge an Elementen ein, auf der dann weitere Suchstrategien ausgeführt
werden können.
ANFORDERUNGSANALYSE
51
Während das Browsen dazu dient, sich einen Überblick zu verschaffen, und
Inhalte aufzufinden, deren Kontext unklar oder unbekannt ist, dienen Filterfunktionen und Suchanfragen meist der gezielten Informationssuche. Der
Nutzer weiß, was er sucht, jedoch nicht, wo es zu finden ist.
Bei den beiden Meeting Browsern TeamSpace und ARCHIVUS findet das
Browsen hauptsächlich anhand Listen und Tabs statt. TeamSpace bietet
zusätzlich mit der Möglichkeit zur gleichzeitigen Anzeige mehrerer Meetings
in separaten Fenstern einen Vorteil gegenüber ARCHIVUS, dessen Anwendungsoberfläche in feste Bereiche eingeteilt ist. Weiterhin stellt die Projektion der Meeting-Inhalte auf die Zeitleiste in Form von farblich unterschiedenen Indizes eine Navigationshilfe dar. Der Nutzer kann in den Aufzeichnungen schnell und gezielt zu Aufgaben, Dokumenten oder Themen der Agenda
springen (Abbildung 4.9). EventRiver bietet mit der zeitlichen Zoomfunktion
(Einschränkung oder Vergrößerung des angezeigten Zeitbereichs) eine Form
des semantischen Zooms: die Ansicht wird dem neuen Ausschnitt angepasst, wobei Ereignisse beim Verkleinern des Zeitbereichs vergrößert und
weitere Details angezeigt werden (Abbildung 4.10). Damit folgt EventRiver
dem Interaktionsparadigma von SHNEIDERMAN: „Overview first, zoom and
filter, then details on demand“ [Shneiderman 96] (Überblick, Zoom und Filter, Details auf Anfrage).
Konkrete Suchanfragen unterstützen TeamSpace und ARCHIVUS sowohl
auf der Meeting-Liste, als auch innerhalb der Aufzeichnungen zu einem
Meeting. In beiden Fällen erfolgt die Eingabe eines Suchwortes über ein
Textfeld. Bei ARCHIVUS besteht zusätzlich die Möglichkeit der Spracheingabe. Bei EventRiver kann der Nutzer neben der freien SchlüsselwortEingabe ein gesuchtes Wort auch aus einer vorgegebenen Liste auswählen.
Außerdem bietet das System eine sogenannte Beispiel-Suche an, bei der
ein Ereignis als Beispiel ausgewählt wird. Das Ergebnis ist eine Menge von
Ereignissen, die dem Beispiel-Ereignis ähnlich sind. Während die Suchergebnisse bei den Meeting Browsern in Listenform präsentiert werden, entspricht das Ergebnis bei EventRiver einer semantischen Zoomfunktion 19:
Ereignisse außerhalb des Ergebnisbereichs werden ausgeblendet, und die
Ansicht wird auf verbleibenden Ereignisse angepasst, analog zur Einschränkung des Zeitbereichs.
19
Semantischer Zoom: Anpassen der Datenpräsentation abhängig von verschiedenen Skalierungsebenen (vgl. [Cockburn et al. 08], S. 8)
52
Die meisten Filterfunktionen bietet ARCHIVUS (siehe Abbildung 4.11). Neben dem Filtern der Meetings nach Datum, Ort und Teilnehmern unterstützt
der Meeting Browser das Filtern nach Themen, Dokumenten, Ereignissen
sowie den Dialogelementen (Schlussfolgerung, Frage, Entscheidung), was
zu sehr detaillierten Ergebnissen führt. Das An- und Abwählen von Ereignissen bei EventRiver sowie die Möglichkeit, Themen nach ihrer Wichtigkeit
anhand verschiedener Kriterien zu filtern, werden in Form eines semantischen Zooms ausgeführt. Die Gewichtung der Themen findet jedoch keine
Anwendung in der vorliegenden Arbeit, weshalb Filter nach der Wichtigkeit
für das Konzept unerheblich ist.
Die Interaktionsmöglichkeiten von Story Flow werden bis auf mögliches
Hineinzoomen nicht beschrieben. Besonders bei der Abbildung eines längeren Zeitraums lassen sich hier ohne Vergrößerung keine Details mehr erkennen (vergleiche Abschnitt 3.2.1, Abbildung 3.6), und Themen mit kurzfristiger Zeitspanne sowie Themen ohne Verbindungen treten in den Hintergrund. Aus einer Nutzerumfrage (vgl. [Rose et al. 09]) ging diesbezüglich
auch der Wunsch nach Filtermechanismen, sowie nach einer möglichen
Spezifizierung der Visualisierung in verschiedene Inhaltsbereiche, hervor.
Die Interaktions- und Visualisierungsmethoden der verwandten Arbeiten
wurden eingehend betrachtet. Die Relationsvisualisierung von Story Flow
basiert auf der Linienführung, welche ein geeignetes Mittel zum Leiten der
Leserichtung darstellt und außerdem Zusammenhänge zwischen Inhalten
auch über einen längeren Zeitraum hinweg abbildet. Die einseitige Farbgebung und eingeschränkte visuelle Unterscheidung von Themen führt jedoch
zu Unübersichtlichkeit. EventRiver wirkt dem mit der Nutzung der visuellen
Variablen Form und Farbe entgegen. Themen können klar voneinander getrennt werden und die schnittlinienartige Formgebung der Inhalte sowie die
horizontale Anordnung an der Zeitachse dienen ebenfalls der Führung des
Leseflusses. EventRiver bietet außerdem vielfältige Suchstrategien, deren
Ergebnisse mittels semantischem Zoom angezeigt werden, wodurch dem
Nutzer der Kontext erhalten bleibt. Im Vergleich dazu ist die Listendarstellung bei TeamSpace und ARCHIVUS weniger geeignet, um Zusammenhängen darzustellen. TeamSpace bietet mit der Zeitleiste und den Indizes eine
visuelle Zusammenfassung für jedes Meeting, hält jedoch kaum Filtermechanismen bereit, die nur ausgewählte Inhalte berücksichtigen. ARCHIVUS
stellt hingegen zahlreiche Filterfunktionen zur Verfügung. Die Ergebnisse
werden dabei allerdings nur für jedes Meeting einzeln im Detail ersichtlich.
Tabelle 4.5 bewertet die verwandten Arbeiten abschließend. Die Punkteverteilung gibt eine Einschätzung der Autorin zur Eignung bezüglich der Zielstellung der vorliegenden Arbeit wieder. Punkte wurden von 0 (ungeeignet) bis
ANFORDERUNGSANALYSE
53
5 (geeignet) vergeben. Die höchste Punktzahl bedeutet, dass keine Verbesserung hinsichtlich der bewerteten Kategorie notwendig ist. Diese Punktzahl
wurde nicht vergeben. Bei der Punktevergabe zu den Suchstrategien wurde
die Darstellung der Suchergebnisse berücksichtigt.




















Die Bewertung der Meeting Browser entspricht der in Abschnitt 4.1.2 beschriebenen Problemstellung, die die fehlende Unterstützung für Meetingübergreifenden Informationsabruf thematisiert. Meeting Browser sind derzeit kaum geeignet, Informationen Meeting-übergreifend abzurufen. Im Zusammenspiel von Visualisierung und Interaktion schneidet EventRiver am
besten ab, zur Meeting-übergreifenden Relationsvisualisierung eignet sich
jedoch der Ansatz von Story Flow besser. Allerdings muss ein Weg gefunden werden, Zusammenhänge auch in der Detailansicht darzustellen.
EventRiver gelingt das mit der Storyboard-Funktion nicht vollständig. Keiner
der beiden Visualisierungsansätze lässt sich ohne weiteres auf die vorliegende Datengrundlage übertragen. Allerdings ist zu erwarten, dass eine
Kombination der Visualisierungsansätze einen geeigneten Ausgangspunkt
für das Konzept der vorliegenden Arbeit bietet.
Aus der vorangegangenen Analyse ergeben sich verschiedene Anforderungen an das Konzept. Sie werden im Folgenden im Hinblick auf die drei Bereiche Visualisierung, Interaktion und technische Umsetzung spezifiziert.
Dabei wird zwischen Muss- und Kann-Kriterien unterschieden. KannKriterien dienen als Ausblick auf eine Erweiterung des Konzepts und ergeben sich aus der Abgrenzung der Arbeit (siehe Abschnitt 4.1.4). Sie werden
mit einem Stern (*) gekennzeichnet.
Der Schwerpunkt des Konzepts liegt auf der Visualisierung, die einen besonderen Stellenwert bei der Anforderungsspezifikation einnimmt.
54
4.4. Anforderungen an das Konzept
Zur Visualisierung von Meeting-Aufzeichnungen muss eine geeignete visuelle Repräsentation der in der Datengrundlage spezifizierten Elemente erfolgen. Diese sind:
A1.1
A1.2
A1.3
A1.4
Meeting-Datum
Themen
Inhalte
Inhaltskategorien
Weiterhin ergeben sich aus Fragestellungen zu Anwendungsfall 3 (Analyse /
Erstellen der Agenda) die folgenden zu visualisierenden Daten:
A1.5
A1.6
A1.7
Themenstatus
Aufgabenstatus
Ideenstatus
Zur Darstellung von Zusammenhängen zwischen Meeting-Inhalten müssen
die folgenden Meeting-übergreifenden Relationen visualisiert werden:
A2.1a
A2.1b
A2.1c
A2.1d
A2.1e
*A1.2f
Thema – Meeting
Inhalt – Meeting
Thema – Inhalt
Inhalt – Inhalt
Thema – Thema
Dokument – Thema
Aufgrund des zunächst unbegrenzten Umfangs von MeetingAufzeichnungen innerhalb eines Projekts sind zwei oder mehr Abstraktionsstufen umzusetzen, die eine Darstellung der Inhalte im Überblick sowie die
Darstellung von Details ermöglichen.
Textprotokolle bedienen sich Listen und anderer Strukturierungsmethoden,
welche als Anhaltspunkte beim Informationsabruf dienen. Diese MetaInformationen sind visuell auf die Daten abzubilden.
Zur Erfassung von Zusammenhängen wird der Lesefluss des Nutzers in der
Übersicht anhand der Relationsvisualisierung geleitet. Zur Steuerung des
Leseflusses in der Detailansicht ist darüber hinaus eine Umsortierung der
Inhalte anhand ihrer Beziehungen zu realisieren, um eine Darstellung der
Zusammenhänge auch im Detail zu erhalten.
ANFORDERUNGSANALYSE
55
Weiterhin bedarf es geeigneter Interaktionsmethoden, die eine Anpassung
der Visualisierung zur Bearbeitung spezieller Anwendungsfälle ermöglichen.
Insbesondere soll das Interaktionsparadigma „Overview first, zoom and
filter, then details on demand“ [Shneiderman 96] berücksichtigt werden.
Bei der Suche nach unbekanntem Inhalt (Anwendungsfall 2) oder dem Versuch, sich einen allgemeinen Überblick über die Inhalte zu verschaffen,
müssen dem Nutzer freie Interaktionsmöglichkeiten geboten werden. Wie
diese genau aussehen, ist abhängig von der Visualisierung. Wichtig ist die
Bereitstellung folgender Funktionalitäten:
B1.1
B1.2
Interaktion zum Ansichtswechsel zwischen Überblick und Detail für Themen und Inhalte
Interaktion zur Einschränkung oder Erweiterung der Anzahl dargestellter Meetings
Die Möglichkeit zur Eingabe von Suchworten muss bereitgestellt werden,
wobei eine Abbildung der Suchergebnisse anhand der Visualisierung angestrebt wird. Dadurch soll der zeitliche und semantische Kontext der Ergebnisse erhalten bleiben.
Zur Unterstützung der Suche sind folgende Filtermechanismen umzusetzen:
B3.1
B3.2
B3.3
Inhaltskategorie
Themen
Zeitraum
Zur Unterstützung der Analyse sind weitere Filterfunktionen nötig.
B3.4
B3.5
B3.6
Aufgabenstatus
Ideenstatus
Themenstatus
Der Wechsel zwischen den Abstraktionsstufen soll stets auf eine Weise
erfolgen, die den Gesamtkontext zwischen Überblick und Detail wahrt.
Diese Anforderung gilt bezüglich aller unterstützten Interaktionsmethoden.
56
4.4. Anforderungen an das Konzept
Die Manipulation der Inhalte stellt insgesamt ein Kann-Kriterium dar, da sie
über den Informationsabruf hinausgeht und die Informationssicherung und
den Informationsaustausch betrifft.
*B5.1
*B5.2
*B5.3
*B5.4
*B5.5
Einbindung der Inhalte neuer Meeting-Protokolle mithilfe von
Eingabemasken
Editieren der Themen, Aufgaben und Ideenstatus‘
Erstellung von Verknüpfungen
Einbindung von Dokumenten
Export von Inhalten wie Terminen, Aufgaben in andere Anwendungen (Kalender, E-Mail, Sonstige)
Das Szenario schließt alle Phasen des Meeting-Zyklus mit ein. Die Unterstützung des Informationsabrufs muss damit sowohl zwischen Meetings,
als auch im Meeting selbst gewährleistet werden. Aus diesem Anspruch
lassen sich einige Anforderungen an die technische Umsetzung des Konzepts ableiten.
Da im Meeting-Szenario nicht gewährleistet ist, dass Arbeitsplatzrechner
oder Laptops vorhanden sind, und immer häufiger Tablets als Geräte zum
Informationsabruf eingesetzt werden, ist die Wahl der Technologie zur Umsetzung der Anwendung so zu treffen, dass sie auf Tablets ausgeführt werden kann. Das schließt Smartphones mit ein, deren kleinere Bildschirmdiagonale die Abbildung großer Datenmengen allerdings erschwert. Eine Nutzung des Werkzeugs auf Smartphones wird daher nicht explizit unterstützt.
Die Anwendung des Werkzeugs soll nicht auf Tablets eingeschränkt werden. Eine Umsetzung als Desktopanwendung und damit implizierte Anforderungen an das System und Interaktionskonzept, wie die zeigerbasierte
Steuerung der Anwendung, sind bei der Implementierung zu berücksichtigen.
Die Anwendung soll plattformunabhängig sein. Damit soll es allen MeetingTeilnehmern unabhängig von der Plattform, die sie verwenden, möglich
sein, das Werkzeug zu nutzen.
Basierend auf den zuvor aufgestellten Anforderungen stellt dieses Kapitel
das Visualisierungs- und Interaktionskonzept vor. Erarbeitet wurde das Konzept zur Umsetzung der Anwendungsfälle im Hinblick auf die Zielstellung
der vorliegenden Arbeit. Im Folgenden wird der Begriff „Meeting“ zur besseren Lesbarkeit verallgemeinert und gleichbedeutend mit „MeetingAufzeichnung“ oder „Meeting-Protokoll“ verwendet, da das Meeting im
Rahmen des Konzepts durch seine Inhalte repräsentiert wird.
Dieser Abschnitt beschreibt die visuelle Repräsentation der Datengrundlage,
die in Abschnitt 4.2 definiert wurde. Zunächst wird die Abbildung der einzelnen Elemente der Datengrundlage erläutert. Abschließend setzt Abschnitt
5.1.5 diese Teilvisualisierungen anhand einer realen Datengrundlage beispielhaft zusammen.
Die Inhalte der Meetings liegen im Allgemeinen in einzelnen Textdokumenten vor, die Teil einer Ordnerstruktur sind. Diese Trennung der Meetings
durch die Dokumentgrenzen wird mit dem Visualisierungskonzept aufgehoben. Im übertragenen Sinne werden dazu die einzelnen Textdokumente in
semantisch zusammengehörige Textblöcke (vgl. Abschnitt 2.3.1) zerlegt, die
im Anschluss unter Beachtung der chronologischen Abfolge der Meetings
neu zusammengesetzt werden. Bestehende Zusammenhänge zwischen
den Textblöcken können dann losgelöst von den einzelnen Dokumenten
Meeting-übergreifend dargestellt werden. Abbildung 5.1 schematisiert diesen Prozess.
60
5.1. Visualisierungskonzept
Die Textblöcke stellen im Fall von Meeting-Aufzeichnungen Themen und
ihre Inhalte dar, wobei Themen eine Überschrift und Inhalte in Form von
Fließtext, Listen, oder sonstigen Textbausteinen als Zeilen vorliegen und
durch ihre Anordnung unter einer Überschrift semantisch zugeordnet sind.
Diese Anordnung entspricht der „Konzept und Detail“-Struktur (vgl. Abschnitt 2.3.2). Es ergibt sich eine hierarchische Gliederung der MeetingElemente. Ein Inhalt gehört zu einem Thema, welches wiederum einem
Meeting zugeordnet ist. Einzelne Themen eines Meetings sind in Bezug
zueinander gleichrangig, ebenso wie einzelne Inhalte eines Themas gleichrangig sind (siehe Abbildung 5.2). Eine Ausnahme bilden Inhalte in Listen mit
mehreren Ebenen. Hier werden Inhalte einer niedrigeren Ebene Inhalten
höherer Ebenen zugeordnet, wodurch auch zwischen Inhaltselementen eine
Rangordnung existieren kann. Diese Hierarchie der Elemente hat Auswirkungen auf die Visualisierung, welche sich in der Positionierung der Elemente an zwei Zeitachsen äußert.
Zur Neuanordnung der Meeting-Inhalte nach der Auftrennung der Dokumente wird einerseits die Tatsache beachtet, dass die Zeit in Form des MeetingDatums das wichtigste Kriterium zum Informationsabruf von MeetingInhalten ausmacht (vgl. Abschnitt 2.1.4). Aufgrund dessen und in Anlehnung
an die Visualisierungsansätze von Story Flow [Rose et al. 09] und EventRiver
[Luo et al. 12] wird das Meeting-Datum als Ausgangspunkt für die gesamte
Visualisierung gewählt. Zur Abbildung wird eine horizontale Zeitachse gewählt, die sich über alle Meeting-Daten erstreckt. Sie wird als globale Zeitachse bezeichnet. Die lokale Zeitachse ergibt sich implizit aus der Reihenfolge der Themen innerhalb eines Meetings und wird nicht explizit dargestellt. Während bei den Visualisierungsansätzen von Story Flow und
EventRiver die vertikale Anordnung der Themen ihre Relevanz widerspiegelt, bietet die Gewichtung der Themen und Inhalte für die beschriebenen
Anwendungsfälle keinen Mehrwert. Die Positionierung der Themen und
ihrer Inhalte repräsentiert die in Abschnitt 5.1.1 beschriebene Hierarchie und
den Dokumentaufbau. Die Themen und Inhalte werden in chronologischer
Reihenfolge ihrer Abhandlung im Meeting von oben nach unten unter dem
entsprechenden Meeting-Datum positioniert, wobei die chronologische
Ordnung erhalten bleibt (vgl. Abschnitt 2.3.2). Dabei folgen auf das Thema
seine Inhalte und anschließend das nächste Thema mit dessen Inhalten,
wobei Listenstrukturen mit Einrückung der jeweiligen Inhalte berücksichtigt
werden (Abbildung 5.4).
SYNTHESE UND KONZEPTION
61
Die zu visualisierenden Entitäten sind das Meeting sowie die Themen und
Inhalte des Meetings. Zur grafischen Repräsentation der Datenobjekte werden die Attribute dieser Entitäten in visuelle Variablen transformiert (vgl.
Abschnitt 2.2.1). Das Meeting selbst wird durch sein Attribut „MeetingDatum“ repräsentiert, welches auf die horizontale, globale Zeitachse projiziert wird. Diese ist linear, kontinuierlich und bildet die Meeting-Daten als
diskrete Zeitpunkte ab. Der Wertebereich der Zeitachse beginnt mit dem
Datum des ersten Projektmeetings und endet mit dem letzten. Anhand dieser Abbildung lassen sich Aussagen zu Regelmäßigkeit von und Zeitintervallen zwischen Meetings treffen (siehe Abbildung 5.5). Zu beachten ist dabei,
dass der kleinste Zeitintervall, der zwischen zwei Meetings des Projekts
vorkommt, als Ausgangsbasis für die Skalierung der Visualisierung herangezogen wird. Dieser Umstand beruht auf der Tatsache, dass jedem Meeting
zur Darstellung seiner Themen und Inhalte die gleiche horizontale Ausdehnung auf dem Bildschirm zugewiesen wird und gleichzeitig ein Mindestabstand zwischen den Meeting-Inhalten einzuhalten ist, um Überdeckungen zu
vermeiden.
Das für das Konzept relevante Attribut der Entität Thema ist einzig sein
„Name“, dessen Datentyp nominal ist. Da es eine unbegrenzte Anzahl an
Themen innerhalb der Meetings zu einem Projekt geben kann, und somit
eine unbegrenzte Anzahl an Namen, ist ihre Abbildung auf visuelle Variablen,
die in der Anzahl ihrer Ausprägungsformen begrenzt sind, nicht sinnvoll (vgl.
[Ware 04], S.183). Zur Unterscheidung von Themen werden aus diesem
Grund ihre Namen in Textform abgebildet.
Lineare Zeit ist die chronologische Anordnung ab festem
Startzeitpunkt. Diskrete Zeitpunkte besitzen keine Dauer.
Kontinuierliche Zeit lässt quantitative Aussagen zu Abständen
zwischen Zeitpunkten zu.
[Müller et al. 03]
62
Für die visuelle Repräsentation der Entität Inhalt wird in Anlehnung an die
Dokumentstruktur eine rechteckige Fläche als Abstraktion der Zeile gewählt
(vgl. Abschnitt 5.1.1). Diese Fläche soll die Inhalte so abbilden, dass Aussagen zum Umfang verschiedener Inhalte im Vergleich zueinander getroffen
werden können. Der Umfang eines Inhalts, abgeleitet von seiner „Textlänge“ als quantitativer Datentyp, wird durch die Größe repräsentiert und somit
über den Flächeninhalt des Rechtecks wahrgenommen (siehe Abbildung
5.6). Die Breite ist für alle Inhalte zunächst gleich, und entspricht der horizontalen Ausdehnung des Meetings, die durch den Minimalintervall der
Meetings berechnet wird. Zur Variation des Flächeninhalts wird deshalb die
Höhe entsprechend der Textlänge angepasst.
Zur Abbildung des Attributs „Inhaltskategorie“ auf die Fläche wird die visuelle Variable Farbe eingesetzt (Abbildung 5.7). Die Inhaltskategorie kann fünf
verschiedene Werte annehmen, die der nominalen Datenklasse angehören,
und in der Datenanalyse (Abschnitt 4.2.2) definiert wurden. Aufgrund dessen eignet sich zur visuellen Repräsentation die Farbkodierung 20. Bei der
Auswahl der Farben spielte hauptsächlich die Unterscheidbarkeit der Farben
durch Luminanz und Farbton eine Rolle.
Die Positionierung der rechteckigen Form in der Farbe der jeweiligen Inhaltskategorie definiert schließlich die Zugehörigkeit zu einem Thema und
einem Meeting. Eine mögliche Verschachtelung der Inhalte durch Listenebenen, wie in Abschnitt 5.1.1 beschrieben, wird durch „Einrücken“ vermittelt. Abbildung 5.8 zeigt das Gesamtbild eines Meetings mit einem Thema,
Inhalten der verschiedenen Kategorien und einem Gesprächspunkt zweiter
Ebene.
Neben der Darstellung hierarchischer und quantitativer Relationen durch die
Abbildung an den beiden Zeitachsen ist die Visualisierung Meetingübergreifender Relationen Schwerpunkt des Konzepts. Story Flow [Rose et
al. 09] verwendet zu diesem Zweck Linien. Jedoch ist nicht ohne Lesen der
Texte zu erkennen, ob es sich um die Verbindung unterschiedlicher oder
gleicher Themen und Inhalte handelt. Aus diesem Grund werden bei der
Abbildung der Relationen mit dem eigenen Konzept zwei Arten von Relationen unterschieden. Zum einen beschreiben Relationen die Verknüpfung des
gleichen Themas oder Inhalts, wenn Thema oder Inhalt Gegenstand mehrerer Meetings sind (R1 und R2). Diese Relation wird als Fortführung bezeichnet. Die Metapher, die bei der Visualisierung einer Fortführungsrelation zur
Anwendung kommt, ist die eines Weges, den die Information „beschreitet“
20 Farbkodierung oder -kennzeichnung: Kodierung nominaler Information über die Farbgebung
des Objekts (vgl. [Ware 04], S.123)
63
– ein Pfad, der es von einem zum nächsten Meeting führt (siehe Abbildung
5.9).
Die zweite Relationsart ist komplexer, da sie verschiedene Informationen
verbindet (R3, R4, R5). Je nach Leserichtung lautet die Bezeichnung „führt
zu“ (von rechts nach links, Ursache – Wirkung) oder „geht hervor aus“ (von
links nach rechts, Wirkung – Ursache, siehe Abschnitt 2.3.2). Durch die
chronologische Abfolge der Meetings ist eindeutig, welches der verbundenen Elemente die Quelle und welche das Ziel der Verbindung ist. Zur exakten visuellen Zuordnung der Relation zu den verbundenen Elementen Inhalt
und Thema und bei eventuell auftretender Überlagerung von Linien werden
zwei Relationsenden eingeführt (siehe Abbildung 5.10). Die vertikale Linie
steht für die Verbindung eines Themas, der Punkt für Inhalt.
Zusätzlich weist die Färbung des Relationsendes auf die Art des verknüpften
Inhalts hin. Damit soll es möglich sein, die Art der Quelle oder des Ziels der
Relation auch dann zu erkennen, wenn das verbundene Element sich nicht
im Bildschirmausschnitt befindet. Dem Thema wird zu diesem Zweck die
Farbe Grau zugewiesen. Abbildung 5.11 zeigt beispielhaft die Verbindung
zweier Themen, eine Aufgabe, die zu einem Gesprächspunkt führt, sowie
ein Thema, welches aus einer Idee hervorgeht.
Eine zusätzliche Hervorhebung der Relation von Inhalten wird durch die
Ausdehnung der Breite der Inhalte erwirkt (siehe Abbildung 5.12). Im Folgenden Abschnitt werden alle Aspekte des Visualisierungskonzepts im Zusammenspiel dargestellt.
Abbildung 5.13 stellt das Visualisierungskonzept in der Gesamtansicht dar.
Sie basiert auf Beispiel-Daten und dient allein der Veranschaulichung des
Visualisierungskonzepts. Die Einordnung der Meeting-Daten auf der Zeitachse zeigt einerseits an, dass insgesamt fünf Meetings im Zeitraum vom
31. Mai bis 09. Oktober eines Jahres betrachtet werden. Andererseits verdeutlicht diese Darstellungsform die Zeitintervalle, die zwischen den Meetings liegen. Ersichtlich sind sowohl die Verbindung einzelner Themen über
ein oder mehrere aufeinanderfolgende Meetings, als auch Verbindungen,
die einige Meetings überspringen. Alle Relationen werden in Form geschwungener Linien gezeichnet, die im Vergleich zu geraden, eckigen Linien
64
leichter zu verfolgen sind21. Die Fortführungsrelationen werden weiterhin
halbtransparent gezeichnet, um im Falle von Überschneidungen eine eindeutige Zuordnung der Relationen auch bei Überschneidungen zu gewährleisten. Eine Anwendung des Konzepts auf reale Meeting-Daten erfolgt in
Abschnitt 5.4.1.
Die Visualisierung greift die Prinzipien des Topic Evolution Mining (Abschnitt
2.2.2) auf. Das Entstehen neuer Themen (topic birth) findet oftmals ohne
vorhergehende Ereignisse statt (vgl. Abbildung 5.13, zum Beispiel Thema J,
Thema M). In diesem Fall bestehen keine Relationen des Themas zu vorangegangenen Meetings. Eine andere Variante ist das Entstehen eines Themas aus einem anderen Thema oder einem Inhalt eines anderen Themas
(zum Beispiel Thema aus Beschluss zu Thema E). Die Entwicklung eines
Themas im Laufe der Zeit lässt sich ebenfalls anhand der Relationen verfolgen. Die Abbildung der Fortführungsrelation spezifiziert das Weiterführen
eines Themas über mehrere Meetings (zum Beispiel Thema E, Thema L)
sowie eines Inhalts (zum Beispiel Aufgabe zu Thema E). Das Verschwinden
von Themen (topic death) beziehungsweise ihr Abschluss innerhalb der
Meetings ist durch das Fehlen ebendieser Relationen gekennzeichnet
(Thema E wird nach dem 18. Juli nicht mehr besprochen). Das sukzessive
Aufteilen eines Themas in verschiedene Themen (topic splitting) veranschaulicht in der Abbildung beispielsweise das Hervorgehen von Inhalten
der Themen H, Q und R aus Inhalten zu Thema G. Ein Verschmelzen von
21
[Ware 04], S. 193: “It is much easier to perceive connections when contours occur smoothly”
65
Themen (topic merging) wird durch die Relation mehrerer verschiedener
Themen dargestellt. Thema P entsteht zum Beispiel durch Thema O, welches bereits aus Teilen der Themen K hervorgeht, das wiederum aus Thema
E abgeleitet wurde.
Der Abbildung ist weiterhin zu entnehmen, dass im Juli zwei Meetings abgehalten wurden, während im September kein einziges stattfand. Der gewählte Ausschnitt deutet außerdem an, dass der erste Gesprächspunkt zu
Thema F aus einem Termin hervorgeht. Thema K beinhaltet mehrere Gesprächspunkte, von denen einer größeren Umfangs ist als die übrigen.
Überdies beschreibt die „Einrückung“ der Aufgaben in Thema K den Umstand, dass die Aufgaben zum darüber stehenden Gesprächspunkt gehören.
Es lassen sich weitere Zusammenhänge und Fakten entnehmen – die getroffene Auswahl zur beispielhaften Erläuterung der zuvor definierten Visualisierungselemente und ihrer Bedeutung soll an dieser Stelle genügen.
Einzelne Aspekte der Visualisierung lassen sich auf die in Abschnitt 2.2 erläuterten Visualisierungsformen zurückführen, deren Prinzipien die Erarbeitung des Visualisierungskonzepts beeinflusst haben. Dazu gehört der relative Umfang eines Themas, welcher sich von der Repräsentation der Inhalte
entnehmen lässt. Je mehr Inhalte ein Thema umfasst, desto mehr farbige
Flächen sind dem Thema zugordnet und desto mehr vertikale Ausdehnung
besitzt es. Ein quantitativer Vergleich der Themen miteinander ist damit
möglich22. In ihrer Gesamtheit bilden die Themen zu einem Meeting schließlich den Umfang des Meetings ab23, wodurch ebenfalls ein Vergleich der
Meetings diesbezüglich möglich ist. Diese Darstellungsform lässt sich in
ihrer Grundform auf das Histogramm zurückführen, welches sich mit dem
Prinzip der Stacked Bar Charts vermischt (siehe Abschnitte 2.2.4 und 2.2.7).
Weiterhin stellt die Abbildung der Relationen als Linien, die zusammengehörige Inhalte verbinden, eine Form von Konzeptgraphen dar (siehe Abschnitt
2.2.3). Im Speziellen wird hier ein gerichteter Konzeptgraph verwendet, da
die Themen und Inhalte als Knoten des Graphen untereinander gleichgestellt
sind, also keine Hierarchie vorliegt, und durch die chronologische Abfolge
der Meetings ungerichtete, zyklische Relationen ausgeschlossen sind. Weiterhin fassen Themen die Inhalte eines Meetings in einem Begriff zusammen und bilden in ihrer Gesamtheit die Agenda des Meetings. Die Abbil22
Auf die semantische Relevanz der Themen und Inhalte lassen sich keine Rückschlüsse
ziehen, was im Sinne der Zielstellung jedoch vernachlässigt werden kann
23
Der abgebildete Meeting-Umfang entspricht dabei den vorliegenden Inhalten der Protokolle.
Auch hier ist keine Aussage zur semantischen Relevanz möglich, da verschiedene Faktoren wie
der Schreibstil des Protokollanten bezüglich Detailliertheit und Ausdruck den Umfang der Inhalte maßgeblich beeinflussen.
66
5.2. Interaktionskonzept
dung der Themen in ihrer textlichen Form kann damit als eine sehr einfache
Variante der Tag Cloud (siehe Abschnitt 2.2.6) aufgefasst werden, die einen
Überblick über die Meeting-Inhalte liefert.
Neben den Anforderungen an die Interaktion selbst (siehe Abschnitt 4.4.2)
ist zu beachten, dass das Werkzeug sowohl auf zeiger- als auch auf gestenbasierten Geräten ausführbar sein soll (siehe Abschnitt 4.4.3). Grundlegende
Eigenschaften der Geräte sind dabei zu berücksichtigen. Unterschiede, die
die Geräte bei der Interaktion aufweisen, erläutert der nächste Abschnitt.
Anschließend wird das Interaktionskonzept anhand der Anwendungsoberfläche beschrieben.
Die Mouseover-Interaktion bei Desktopanwendungen dient in der Regel der
Einblendung zusätzlicher Informationen. Besteht diese aus Text, wird sie
meist mithilfe von Tool Tips eingeblendet. Grafische Objekte werden bei
Mouseover häufig anwendungsabhängig in verschiedenster Weise in den
Fokus gerückt. Gestenbasierte Geräte unterstützen diese Form der Interaktion nicht. Ein weiterer Unterschied liegt darin, dass gestenbasierte Geräte
Pan- und Zoom-Gesten bereitstellen, die das Scrollen sowie Hinein- und
Hinauszoomen direkt auf der Oberfläche ermöglichen. Bei zeigerbasierten
Geräten finden solche Navigationsarten mithilfe von Scrollleisten oder anderen Interaktionselementen24 statt, oder werden unter Verwendung von
Shortcuts25 realisiert. Diese Unterschiede werden berücksichtigt, indem
Zoomfunktionen bei zeigerbasierten Geräten mithilfe von zusätzlichen Navigationselementen bereitgestellt werden und auf eine explizite Belegung der
Mouseover-Interaktion verzichtet wird.
Weiterhin unterscheiden sich die Bezeichnungen für die Gesten. Die
„Klick“-Interaktion zeigerbasierter Systeme entspricht dem „Tab“ bei gestenbasierten Systemen. Der Einfachheit halber wird diese Interaktionsform
im Folgenden allgemein als „Auswahl“ bezeichnet.
24
Zum Beispiel Lupen-Werkzeug bei Grafikanwendungen, Buttons zum Hinein- und Hinauszoomen wie bei Google Maps (maps.google.com)
25
Beispielsweise gleichzeitiges Betätigen der Tasten „STRG“ und “+“ auf der Tastatur zum
Hineinzoomen
67
Die Anwendungsoberfläche besteht aus drei getrennten Bereichen
(Abbildung 5.14). Der größte Bereich (1) beinhaltet einerseits die Visualisierung selbst (siehe Abschnitt 5.1). Zusätzlich befindet sich oberhalb der Zeitachse ein grauer Balken (1a) zur Darstellung und Veränderung des angezeigten Zeitbereichs. Bei Bereich 2 handelt es sich um ein ausklappbares Menü,
das Such- und Filterfunktionen bereitstellt. Bereich 3 ist immer sichtbar und
hält Browser-Funktionen sowie einen Interaktionsverlauf bereit.
Die Zeitachse bildet stets nur den gewählten Zeitbereich ab. Der Balken
oberhalb der Zeitachse zeigt dem Nutzer deshalb, wo sich der Ausschnitt
innerhalb der gesamten Projektlaufzeit befindet. Das dient der Orientierung
in der Anwendung und vermittelt einen Eindruck über die Länge der
Projektlaufzeit. Gleichzeitig hält er Zoom- und Scrollfunktionen zur
Erweiterung, Einschränkung und Verschiebung des Bereichs bei der
Desktopanwendung bereit. Beim Auseinanderziehen des Balkens wird der
dargestellte Zeitbereich erweitert. Mehr Meetings werden angezeigt, was
einem
Herauszoomen
aus
der
Visualisierung
gleicht.
Beim
68
Zusammenschieben des Balkens verkleinert sich der gewählte Zeitausschnitt (Abbildung 5.15).Das Verschieben des Balkens nach rechts
entspricht dem Verschieben des Zeitausschnittes zu neueren Daten hin.
Beim Verschieben nach links werden ältere Daten angezeigt (Abbildung
5.16). Gestenbasierte Geräte erfüllen diese Funktionen durch die
Bereitstellung nativer Pan- und Zoomgesten.
Die Suche nach einem Schlüsselwort hat alle Inhalte und Themen zum Ergebnis, die dieses Schlüsselwort enthalten. Die entsprechenden Elemente
werden „aufgeklappt“ und das Schlüsselwort hervorgehoben. Eine Besonderheit des vorliegenden Konzepts liegt darin, dass alle mit den Ergebnissen
verknüpften Elemente ebenfalls angezeigt werden. Elemente, die weder
das Schlüsselwort enthalten, noch mit den Suchergebnissen verknüpft sind,
werden ausgeblendet. Der Zeitbereich wird entsprechend auf alle verbliebenen Elemente angepasst, ebenso der Themenfilter – ausgeblendete Themen werden ausgegraut. Abbildung 5.17 stellt die angepasste Visualisierung
nach Ausführen der Suche für den Begriff „Beispiel“ dar.
Inhalte können mithilfe des Inhaltsfilters nach ihren Kategorien gefiltert werden. Durch An- und Abwählen der farbigen Checkboxen kann der Nutzer die
entsprechenden Inhalte ein- oder ausblenden. Die Visualisierung passt sich
dem Filter an. Bestehende Relationen zu Inhalten nicht gewählter Kategorien werden weiterhin durch die Relationsenden verdeutlicht (Abbildung
5.18).
69
70
Der Themenfilter listet alle Themen der Projektmeetings auf. Themen, die
nicht in der aktuellen Ansicht der Visualisierung enthalten sind, werden dabei ausgegraut. Bei Auswahl eines Themas aus der Liste bleiben, ähnlich zur
Suchfunktion, neben dem gewählten Thema alle mit ihm verbundenen Elemente sowie deren Verknüpfungen im Bild. Sonstige Elemente werden
ausgeblendet. In der Liste ausgegraute Themen können ebenfalls ausgewählt werden. So ist eine Detailansicht oder ein Vergleich zu anderen Inhalten gezielt möglich, auch wenn diese nicht der bisher getroffenen Auswahl
entsprechen. Weiterhin können mehrere Themen zugleich selektiert werden. Die Liste kann mithilfe der beiden Tabs „1-n“ und „a-z“ außerdem
sowohl chronologisch nach Aufkommen der Themen in den Meetings, als
auch alphabetisch, sortiert werden (siehe Abbildung 5.19).
Die Browser-Leiste wird so bezeichnet, weil sie übliche Browserfunktionen
bereitstellt. Der „Reset“-Button (Abbildung 5.20, 1) macht alle getroffenen
Filter- und Sucheingaben rückgängig und setzt damit die Visualisierung in
den Ausgangszustand zurück, analog zum Home-Button eines Browsers,
der die Startseite lädt. Ebenfalls analog zu Standard-Browserfunktionen lassen sich über die beiden Pfeile, den Vor- und Zurück-Button (Abbildung 5.20,
2), einzelne Schritte rückgängig machen oder wiederholen.
Die Verlaufsanzeige (Abbildung 5.21) listet alle getroffenen Filter- und Sucheingaben auf. Mithilfe der Browserfunktionen soll dem Nutzer die Orientierung in besonders großen Datenmengen erleichtert werden. Die Notwendigkeit dazu zeigt sich besonders in der direkten Interaktion mit den Elementen, die im nächsten Abschnitt beschrieben wird.
Bei Auswahl der Visualisierungselemente wird die Detailansicht aufgerufen.
Die Visualisierungselemente sind einerseits die Entitäten, andererseits die
Relationen, die durch Verbindungslinien und die Relationsenden repräsentiert werden.
Durch Auswahl eines Meeting-Datums werden alle entsprechenden Themen „aufgeklappt“, beim Thema werden alle Inhalte und beim Inhalt der
dazugehörige Text eingeblendet. Analog zur Such- und Filterfunktion (siehe
Abschnitt 5.2.3) bleiben alle Relationen und die zugehörigen Elemente erhalten. Der Zeitausschnitt passt sich der Darstellung an. Die Verlaufsanzeige in
der Browser-Leiste am unteren Bildschirmrand bildet die einzelnen Interaktionsschritte ab. (siehe Abbildung 5.22)
71
Die Auswahl einer Relationslinie rückt die zugehörigen Elemente in den
Fokus des Bildausschnitts. Die Bewegung wird animiert, wobei die Relationen selbst im Mittelpunkt der Interaktion stehen – die Entitäten ordnen sich
um die Relation. Die Zeitachse passt sich dem Bildausschnitt wiederum so
an, dass die Zuordnung der Inhalte zum Meeting-Datum bestehen bleibt.
Details werden durch die Interaktion mit den Entitäten selbst angezeigt.
Bei der Auswahl eines Relationsendes wird, analog zur animierten Bewegung bei der Auswahl einer Relation, das zugehörige Element „herangeholt“. Mittelpunkt dieser Interaktion ist dabei jedoch die Entität, der das
Relationsende „anhängt“. Auch hier passt sich der Zeitausschnitt entsprechend an.
Zur Erhöhung der Übersichtlichkeit werden bei Aufruf einer Detailansicht alle
Elemente ausgeblendet, die nicht mit der Auswahl zusammenhängen. Falls
das Ergebnis nicht die gesuchte Information enthält, oder der Nutzer von der
vorherigen Ansicht aus weitere Detailinformationen abrufen möchte, kann
die Auswahl mithilfe des „Zurück“-Buttons (siehe Abschnitt 5.2.3) rückgängig gemacht werden. Damit wird gewährleistet, dass der Nutzer seine Suche nicht vorn beginnen muss, sondern von einem Punkt aus verschiedene
voneinander unabhängige Informationsstränge untersuchen kann.
72
5.3. Umsetzung der Anwendungsfälle
In Abschnitt 2.1.4 wurde dargelegt, welche Anhaltspunkte die verschiedenen Formen von Meeting-Aufzeichnungen zur Unterstützung des Informationsabrufs bereitstellen. Abhängig von der Erinnerung des Nutzers kommen
solche Anhaltspunkte zum Einsatz. Dieser Abschnitt legt dar, wie das zuvor
beschriebene Visualisierungs- und Interaktionskonzept die in Abschnitt 4.1.1
aufgeführten Anwendungsfälle unterstützt, und welche Anhaltspunkte es
dazu bereithält. Mögliche Vorgehensweisen, um ausgewählte Fragestellungen zu beantworten, werden vorgeschlagen.
Dieser Anwendungsfall konzentriert sich auf die Suche nach Information, die
zuvor bekannt war, jedoch im Laufe der Zeit vergessen oder verfälscht wurde. Wie der Nutzer bei der Informationssuche in diesem Fall vorgehen kann,
hängt stark von seiner Erinnerung ab. Der Nutzer kennt den Kontext des
gesuchten Inhalts. Er weiß beispielsweise, in welchen Zeitraum eine Aussage gefasst wurde, oder er kennt die Art des relevanten Inhalts. Bei der
Umsetzung dieses Anwendungsfalls kommen hauptsächlich Such- und Filterinteraktionen zum Einsatz.
Wie in Abschnitt 2.1.4 erläutert, stellt die Zeit das Hauptkriterium für die
Suche dar. Aus diesem Grund wurde die globale Zeitachse zur Abbildung
der Meeting-Daten im Projektzeitraum gewählt. Sie formt als grundlegender
Visualisierungsbestandteil das Gesamtbild der Anwendung. Dem Nutzer
stehen die in Abschnitt 5.2.3 beschriebenen Interaktionsfunktionen zur Verfügung. Mithilfe der Zeitleiste oder durch Pan- und Zoomgesten bei gestenbasierter Verwendung des Werkzeugs kann er den gewünschten Zeitbereich einstellen. Anschließend werden ihm nur die Meetings mit entsprechenden Themen und Inhalten angezeigt, die in diesem Zeitbereich liegen.
Die Abstraktion der Inhalte hebt dabei die Themennamen hervor, welche als
Text gegenüber den Flächen in den Vordergrund treten. Damit wird ein
Überblick über die besprochenen Inhalte gewonnen. Fragestellungen, die
sich so beantworten lassen, heißen beispielsweise „Wie lautete eine Aussage zum Thema?“ oder allgemein, „Was wurde besprochen?“.
Sucht der Nutzer nach spezifischen Inhalten, wie einem bestimmten Termin, der in einem früheren Meeting festgehalten wurde, oder einer Aufgabe, die er erledigen musste, dient der Inhaltsfilter als Unterstützung. Inhalte
nicht ausgewählter Kategorien werden ausgeblendet, womit die Abbildung
übersichtlicher wird und das Gesuchte schneller entdeckt werden kann. Die
Fragestellungen „Wie lautete eine Entscheidung genau?“ oder „Welche
Aufgaben wurden deklariert?“ können auf diese Weise schnell beantwortet
werden.
73
Die Beantwortung der Frage „Warum wurde eine bestimmte Entscheidung
getroffen?“ ist mithilfe der Relationen möglich. Wurde die gesuchte Entscheidung aufgefunden, werden alle zugehörigen Relationen angezeigt,
sowie der restliche Inhalt des Themas.
Erinnert sich der Nutzer an Begriffe, die mit dem Gesuchten in Zusammenhang stehen, kann er diese Begriffe im Suchfeld eingeben (vgl. Abschnitt
5.2.3, Abbildung 5.17). Er erhält anschließend eine Übersicht der Themen,
die diesen Begriff beinhalten. Die Visualisierung passt sich dementsprechend an: Themen, die weder in der Ergebnismenge liegen, noch mit einem
der Ergebnisse über eine Relation verbunden sind, werden ausgeblendet.
Die Menge an Inhalten, die der Nutzer weiter durchsuchen muss, wird somit eingeschränkt.
Ein weiterer Anhaltspunkt ist der Umfang eines Themas. „Kleine“ Themen
heben sich von „großen“ Themen durch die Anzahl an Inhalten ab. Sucht
der Nutzer Information zu einem Thema, von dem er weiß, dass es ausgiebig oder nur sehr kurz behandelt wurde, stellt die histogrammartige Abbildung der Inhalte ebenfalls einen Anhaltspunkt zum Auffinden der Inhalte
dar.
Die einzelnen Schritte können in beliebiger Reihenfolge ausgeführt werden,
wobei die Ergebnismenge immer weiter eingeschränkt wird. Die Suche
könnte beispielsweise so ablaufen:
1. Einschränkung des Zeitbereichs
2. Filtern der Inhalte nach relevanter Kategorie
3. Eingabe eines Suchbegriffes, welcher im gesuchten Inhalt vermutet
wird oder an das sich der Nutzer im Zusammenhang erinnert
Anschließend werden Details zum gesuchten Inhalt, Thema oder Meeting
mittels Auswahl der jeweiligen Entität abgerufen (vgl. Abschnitt 5.2.4, Abbildung 5.22).
Dieser Anwendungsfall beschreibt ebenfalls die Suche nach Information. Er
grenzt sich insofern von Anwendungsfall 1 ab, dass dem Nutzer der Kontext
relevanter Inhalte nicht bekannt ist. Das Vorgehen bei diesem Anwendungsfall lässt sich als Browsen in Kombination mit Filterinteraktionen beschreiben.
Der Abruf verpasster Informationen bezieht sich oftmals auf einen beschränkten Zeitraum, wie ein einzelnes, oder eine Reihe aufeinanderfolgender Meetings. In diesem Fall kann der Nutzer zunächst den relevanten Zeitraum auswählen. Die Detailansicht der besprochenen Meetings, Themen
und Inhalte ist anschließend durch Auswahl der jeweiligen Visualisierungselemente möglich (vgl. Abschnitt 5.2.4, Abbildung 5.22).
74
5.3. Umsetzung der Anwendungsfälle
Bei der Einschränkung des Zeitraums werden Relationen auch dann weiterhin angezeigt, wenn die zugehörigen Inhalte außerhalb des gewählten Ausschnittes liegen. Damit wird dem Nutzer signalisiert, welche weiteren Inhalte in Zusammenhang zu dem stehen, was er verpasst hat. Er kann durch
Auswahl einer Relation den dazugehörigen Inhalt aufrufen und sich diesen
im Detail ansehen. Mithilfe des Zurück-Buttons kehrt er danach zu seiner
Ausgangsposition zurück, um weitere Informationen zu suchen. Auf diese
Weise lassen sich Fragestellungen wie „Gab es Entscheidungen zu Diskussionen vorheriger Meetings?“ und „Was ist aus Aufgabe „xy“ geworden?“
beantworten.
Handelt es sich um mehrere Meetings, an denen der Nutzer nicht teilgenommen hat und zu deren Inhalten er sich einen Überblick verschaffen
möchte, wirkt die Abstraktion der Inhalte als visuelle Zusammenfassung, die
durch die Anzeige der Themennamen semantisch belegt ist. In diesem Kontext nennt LISOWSKA das Hinzukommen eines neuen Mitarbeiters zum Projekt, der sich über den bisherigen Projektverlauf informieren möchte
[Lisowska 03]. Das Konzept ermöglicht dem neuen Mitarbeiter, sowohl den
chronologischen, als auch den semantischen Kontext der Meetings im
Überblick zu erfassen. Die allgemeine Fragestellung „Was wurde besprochen?“ wird damit beantwortet.
Zusätzlich kann sich der Nutzer mithilfe des Themenfilters einen Überblick
über alle Themen, in chronologischer oder alphabetischer Reihenfolge, verschaffen (siehe Abschnitt 5.2.3, Abbildung 5.19). Gleichzeitig dient der Themenfilter der Auswahl eines Themas, zu dem der Nutzer Informationen
abrufen möchte. Die Auswahl eines Themas in der Liste bewirkt, dass nur
dieses Thema und die Inhalte, die über eine Relation damit verknüpft sind,
angezeigt werden. Der Nutzer erfährt, welche Ereignisse dem Thema vorweg gingen oder was sich aus dem Thema entwickelt hat (vgl. Abschnitt
5.1.5). Fragestellungen, die sich so unter anderem beantworten lassen, sind:
„Was wurde zu einem Thema besprochen?“ und „Wurde das Thema weitergeführt?“.
Beim Aufstellen der Agenda wird üblicherweise das Protokoll des letzten
Meetings betrachtet und anhand der Inhalte entschieden, welche Themen
weiteren Gesprächsbedarf erfordern und welche abgeschlossen sind (vgl.
[Mannering 11], S. 109). Eine These des Konzepts ist es, dass zur Entscheidung dieses Sachverhalts häufig das letzte Protokoll nicht ausreicht (vgl.
[Lisowska 03]). Das Aufstellen der Agenda soll mit dem vorliegenden Konzept unterstützt werden, indem Zusammenhänge zu vorherigen Meetings
visualisiert werden (siehe Abschnitt 5.1). Dabei wird nicht explizit abgebildet,
75
welche Themen oder Inhalte noch „offen“ sind. Allerdings stellt das Konzept dem Nutzer einen Zugang zu allen benötigten Informationen bereit.
Anhand der Fortführungsrelation (vgl. Abschnitt 5.1.4) wird einerseits angezeigt, wie lange ein Thema schon besprochen wird. Falls ein Abschluss des
Themas von Bedeutung ist, kann dieses Thema durch Auswahl genauer
betrachtet werden. Auch seine Zusammenhänge zu weiteren Themen sind
anhand der Relationsabbildung ersichtlich (vgl. Abschnitt 5.1.5, Abbildung
5.13). Außerdem erhält der Nutzer durch die Meeting-übergreifende Darstellung alle Informationen zu einem Thema, egal in wie vielen Meetings es
bereits besprochen wurde. Damit wird der Zugang zu allen möglichen Gründen der Themenweiterführung gewährleistet. Es lassen sich die Fragestellungen „Wo besteht noch Gesprächsbedarf?“ und „Welche Themen wurden noch nicht abgeschlossen und warum?“ beantworten.
Weitere Anhaltspunkte dafür, dass zu einem Thema Gesprächsbedarf besteht, sind offene Aufgaben und Ideen innerhalb des Themas. Hier kommen
der Themen- und Inhaltsfilter zum Einsatz. Wie in Abschnitt 5.2.3 beschrieben, kann ein relevantes Thema mithilfe des Themenfilter oder auch durch
direkte Auswahl des Themas in der Visualisierung selektiert werden. Anschließend ist es möglich, die Inhalte nach Aufgaben und / oder Ideen zu
filtern (vgl. Abschnitt 5.2.3, Abbildung 5.18). Diese können im Detail betrachtet werden, während ihre Relationen zu weiteren Inhalten ebenfalls abgebildet werden. Es ist ersichtlich, welche Aufgaben oder Ideen weitere Gesprächspunkte oder sonstige Inhalte nach sich gezogen haben, und welche
nicht. Aufgaben und Ideen ohne Verknüpfung zu einem nachfolgenden Element sind im Sinne des Konzepts noch offen und sollten damit in die Agenda übernommen werden. Speziell die Fragen „Welche Aufgaben wurden
erledigt, welche nicht?“, „Weshalb wurden Aufgaben noch nicht erledigt?“
und „Gibt es Ideen oder Lösungsvorschläge, die noch nicht umgesetzt wurden?“ lassen sich so beantworten.
Nachdem das Visualisierungs- und Interaktionskonzept umfassend erläutert
wurde, und mögliche Vorgehensweisen zur Umsetzung der Anwendungsfälle dargelegt wurden, bewertet dieser Abschnitt das Konzept. Grundlage
dazu sind die Anforderungen, die in Abschnitt 4.4 aufgestellt wurden. Zusätzlich wird die Anwendung des Visualisierungskonzepts auf reale Meetings aus dem Projekt Vizamp beschrieben.
76
5.4. Kritische Betrachtung
Die Abbildung auf Seite 80 zeigt die Anwendung des beschriebenen Visualisierungskonzepts auf alle Vizamp Meeting-Protokolle im Zeitraum März
2012 bis September 2013. Insgesamt wurden in dieser Zeit 20 Meetings
abgehalten und circa 100 Themen besprochen, von denen viele in Zusammenhang stehen. Zu beachten ist, dass die semantische Belegung der Inhalte mit den Relationen und Kategorien durch die Autorin ohne Anspruch auf
absolute Korrektheit vorgenommen wurde.
Positiv zu werten ist, dass das in der Analyse aufgestellte Datenschema fast
vollständig mit den realen Meeting-Inhalten übereinstimmt. So traf die
grundlegende hierarchische Struktur Meeting-Thema-Inhalt vollständig zu,
und die zeitliche Abbildung der Meetings war ebenfalls ohne Einschränkung
möglich.
Eine Kategorisierung der Inhalte wurde durch die Autorin ohne Vorkenntnisse zu den Meeting-Inhalten vorgenommen. Dabei fanden sich alle Kategorien in den Protokollen wieder, wobei sich einige Inhalte nicht eindeutig nur
einer Kategorie zuordnen ließen. Besonders die Unterscheidung von Gesprächspunkten und Beschlüssen gestaltete sich schwierig. Ein direkt an
den Meetings beteiligter Nutzer könnte solch eine Zuordnung unter Umständen genauer treffen. Weiterhin war festzustellen, dass eine zusätzliche
Kategorie „Offene Fragen“ zumindest im Falle der Vizamp-Meetings von
großem Nutzen wäre. Strukturierungen innerhalb der Themen, wie die Einrückung von Zeilen, wurden ebenfalls übernommen, wobei Zugehörigkeiten
verschiedener Kategorien, beispielsweise eines Beschlusses zu einem Gesprächspunkt, sichtbar wurden.
Eine Problematik, die sich ergab, betrifft Themen ohne Inhalt. Die Protokolle
umfassten einige Überschriften, also Themen, zu denen kein Fließtext vorhanden war. In diesem Fall besteht die Visualisierung des Themas nur in der
Abbildung des Namens als Text, was das Zeichnen eventuell vorhandener
Relationen mit dem beschriebenen Visualisierungskonzept nicht abdeckt, da
die Relationen in ihrer visuellen Form unmittelbar den Inhalten zufließen.
Bezüglich der Relationen wurde festgestellt, dass die häufigsten Vorkommnisse bei den „Führt zu“ / „Geht hervor aus“ – Relationen zu finden sind
(siehe Abschnitt 5.1.4). Besonders die Inhalt-Inhalt-Relation taucht sehr oft
auf, ebenso die Inhalt-Thema-Relation. Selten führte ein Thema zu einem
neuen Inhalt. Themenfortführungen gibt es ebenfalls einige, die sich bis auf
die Themen ohne zugehörige Inhalte ohne Probleme visualisieren ließen. Bei
den Fortführungen von Inhalten existieren im Falle von Vizamp nur Aufgaben
und Termine, die mehrfach erwähnt wurden. Weitere Inhaltskategorien
wurden nicht mit der Fortführungsrelation belegt. Die Relation eines The-
77
mas mit einem neuen Thema existiert bei der Visualisierung der VizampMeetings nicht.
Zusätzlich wurden Termine, die in den Meetings festgelegt wurden und ein
Ereignis im Projektkalender darstellen, auf die Zeitachse projiziert. Sie werden in Form von Kreisen in der Farbe der Kategorie „Termin“ abgebildet.
Das Visualisierungskonzept konnte erfolgreich anhand der realen Datengrundlage der Vizamp-Meetings getestet werden. Insbesondere die Informationsstruktur, als auch die Entitäten und in den meisten Fällen die Relationen, ließen sich eindeutig darstellen.
Kann-Kriterien wurden mithilfe des beschriebenen Konzepts nicht umgesetzt und sind Teil des Ausblicks (Abschnitt 7.2). Einige Anforderungen wurden nicht explizit mit dem Konzept beschrieben. Auf diese wird im Folgenden näher eingegangen.
Die Visualisierung des Themen-, Aufgaben- und Ideenstatus (A1.5 – A1.7)
erfolgt nicht explizit. Implizit ist der Status jedoch anhand (nicht) vorhandener Relationen abzulesen (vgl. Abschnitt 5.3.3).
Mehrere Anforderungen betreffen die Abbildung der Inhalte in Überblick und
Detail bei gleichzeitiger Darstellung des Kontexts. Die Abbildung der Inhalte
als farbige Flächen bildet zu diesem Zweck eine Abstraktionsstufe (A3).
Zusammengefasst zu den jeweiligen Themen und verbunden durch die Relationen stellen die Inhalte eine visuelle Zusammenfassung der Meetings
dar. Die globale Zeitachse gewährleistet zusammen mit dem Zeitbalken,
dass der zeitliche Kontext stets ersichtlich ist. Beim zeitlich bedingten Hineinzoomen in die Visualisierung kann es vorkommen, dass Relationen über
den gewählten Abschnitt hinaus verlaufen. In diesem Fall bilden die Relationsenden einen Hinweis auf die zugehörigen Inhalte (vgl. Abschnitt 5.1.4),
und gewährleisten somit, dass der semantische Kontext auch im Detail
ersichtlich ist. Sie bleiben auch dann erhalten, wenn Inhalte aufgeklappt und
der zugehörige Text sichtbar wird. Die Einführung der Browser-Leiste ermöglicht es, einzelne Schritte jederzeit rückgängig zu machen oder nochmals auszuführen. Die Anzeige der ausgeführten Schritte stellt dabei einen
weiteren Hinweis auf den Kontext dar. Das Konzept folgt damit ähnlich wie
EventRiver [Luo et al. 12] dem Interaktionsparadigma nach [Shneiderman
96]. Auf diese Weise werden gleichzeitig die Anforderungen an Überblick
und Detail (B4) sowie die Funktionen zum Browsen (B1) umgesetzt.
Die globale Zeitachse ermöglicht es, Zusammenhänge über die Meetings
hinweg nachzuverfolgen. Die Anordnung der Daten in chronologischer Reihenfolge führt dazu, dass kausale Zusammenhänge ohne weitere visuelle
Hilfsmittel eindeutig erkennbar sind. Folgt man einer Relation entgegen der
78
Zeitachse von rechts nach links, gelangt man vom Ziel zur Quelle oder von
der Auswirkung zur Ursache (vgl. Abschnitt 2.3.2). Eine Sortierung der Inhalte zur Steuerung des Leseflusses (A5) ist insofern initial vorhanden, dass die
Informationen innerhalb eines Themas vertikal untereinander angeordnet
werden, was durch die lokale Zeitachse erreicht wird. Die Interaktion (vgl.
Abschnitte 5.2.3 und 5.2.4) führt zu verschiedenen Neusortierungen der
Visualisierungselemente. Das Konzept stellt sicher, dass auch dabei der
zeitliche und semantische Kontext erhalten bleibt. Anhand dessen wird der
Lesefluss auch im Detail gesteuert.
Die Muss-Kriterien, die in Abschnitt 4.4 spezifiziert wurden, wurden mithilfe
des beschrieben Interaktions- und Visualisierungskonzepts umgesetzt. Eine
Ausnahme stellen die Anforderungen B3.4 – B3.6 zum Filtern der Elemente
nach Aufgaben-, Ideen- und Themenstatus dar. Wie bereits beschrieben
erfolgt die Visualisierung des Status nur implizit, weshalb eine explizite Filterfunktion nicht möglich ist. Die Funktion zum Filtern nach Inhaltskategorie
ist dennoch als erster Schritt dazu anzusehen. Die explizite Abbildung von
Zusammenhängen anhand der Relationsvisualisierung bietet weiterhin eine
visuelle Filtermöglichkeit. So lassen sich offene Aufgaben und Ideen anhand
der Fortführungsrelation von abgeschlossenen Aufgaben und Ideen unterscheiden, denen durch die „Führt-zu“-Relation ein abschließender Inhalt
zugeordnet ist. Kritisch zu betrachten ist die Überschneidung von Relationen
und Text in der Detailansicht. Anhand der verwendeten Daten lässt sich
schwer einschätzen, wie sehr die Textlesbarkeit unter Umständen beeinträchtigt werden kann. Eine mögliche Lösung für dieses Problem stellt die
Einbindung einer halbtransparenten Fläche zwischen Text und Hintergrund
dar. Eine andere Lösung könnte ebenfalls in der Umstrukturierung der Texte, oder aber in der manuellen Umsortierung der Elemente bestehen. Dieser
Punkt wird im Ausblick thematisiert (siehe Abschnitt 7.2).
In diesem Kapitel wurde das Visualisierungs- und Interaktionskonzept beschrieben. Ein Grundlegendes Element der Visualisierung ist die Abbildung
der Informationsstruktur auf die globalen und lokalen Zeitachsen. Die Anordnung der Entitäten und Relationen, die zusammen die Datengrundlage
bilden, baut darauf auf. Es folgte eine Einordnung der verwendeten Visualisierungsprinzipien.
Das Interaktionskonzept wurde anschließend anhand der Anwendungsoberfläche und ihrer Funktionalitäten erläutert. Neben Funktionen zum Browsen,
Filtern und Durchsuchen der Meetings wurde beschrieben, welche Auswirkungen die Auswahl der verschiedenen Visualisierungselemente hat.
79
Abschnitt 5.3 legte dar, wie das Konzept zur Umsetzung der Anwendungsfälle genutzt werden kann. Es lässt sich feststellen, dass sich die grundlegenden Fragestellungen der Anwendungsfälle beantworten lassen.
Eine kritische Betrachtung des Konzepts umfasste zum einen die Anwendung der Visualisierung auf die Meeting-Daten des Vizamp-Projekts. Es
konnte gezeigt werden, dass das Visualisierungskonzept umfassendes Potential zur Meeting-übergreifenden Darstellung von Inhalten birgt. Zum anderen erfolgte eine Bewertung des Konzepts anhand der in Kapitel 4 aufgestellten Anforderungen, die fast vollständig umgesetzt werden konnten.
MÄRZ
APRIL
MAI
JUNI
JULI
AUGUST
04
09
31
04
18
Inhalt und Ziele
im Projekt
Vizamp
Vizamp
Vizamp
Vorstellung
Dana Henkens
Begriffsklärung
und Abgrenzung
Anforderungskatalog
Status qou bei
queo
Zwischenbericht
Aktueller Stand
Web-Demonstrator
Phaseneinteilung,
siehe Termine
Termine
Vorstellung
neuer Themen
04
18
JULI
Anforderungskatalog
Vorstellung/Diskussion
bestehender Szenarien
Verständigung auf
ein Szenario
Sonstiges
Termin nächstes
Treffen
Besprechung
Vizamp-Logo
Termin nächstes
Treffen
Termine
Arbeitspakete
Abwesenheiten in
nächster Zeit
Begriffsklärung
und Abgrenzung
Termin nächstes
Treffen
Konflikte im
Projektmanagement
ToDos
Termine
Anwendungsszenario:
Mailverkehr in Projektplanung
Weiteres Vorgehen
Wofür Visualisierung
Todos
Arbeitspakete
Aufgaben
Sonifikation
Vorstellung der
Prototypen
Zwischenbericht
Anwendungsszenario:
Interaktive
Protokollführung
Vorstellung der ersten
Konzepte von Mirko
für die Planungssichten
der Demonstratoren
Vorstellung des
Werkzeugkastens (AB)
und Konzept zur
Verwaltung von Ideen
Arbeitspakete
Termin nächstes
Treffen
JUNI
ToDos
Aufgaben
sonstiges
Arbeitspakete
Interview
Ergebnisse (RG)
Thema
Termine
TODO
Konflikte
Pressetext
Diskussion
Konfliktdefinitionen
Termin nächstes
Treffen
Termin nächstes
Treffen
Sonifikation
Urlaub/Abwesenh.
Konfliktbewertung
(kritisch, ... , unkritisch)
TODO
Thema
Termin nächstes
Treffen
Besprechung der
View Konzepte
Konfliktzyklus
Folge Projekt
Zwischenbericht
Diverses
Konfliktbeziehungen
Agile Schätzmethoden
Ansprechpartner WiWi
aufsuchen
Backend-Aufgabenverteilung
22
Website
Eigenschaften von
Aufgaben
Konfliktarten
Sonstiges
Begriffsdefinitionen
Diskussion
Konfliktbeziehungen
Artikel ERP-Systeme
und Usability
Agilität Definition
Arbeitspakete
Termin nächstes
Treffen
Termine
Kontext
Agilität
Konfliktdefinition
Projektplanung (details)
Aufgabenverteilung
Sonstiges
16
Meetings
Fragen zu
Hauptszenarien
06
Aktueller Stand Einführung Severin
ToDos
Zwischenbericht
AUGUST
25
31
Besprechung der
Anwendungsszenarien
unter Einbeziehung
von Anregungen durch AP
Aufgaben-BeziehungenAnwendungsszenarien
Termin nächstes
Treffen
JULI
13
Arbeitspaket
Besprechung
Vizamp-Logo
Besprechung
Vizamp-Logo
Besprechung
Vizamp-Logo und
Website
JUNI
23
Arbeitspakete
Phase 2
Anwendungsszenario:
Interaktive
Protokollführung
MAI
Status quo bei MG
Situationsskizzen
Arbeitspakete
APRIL
Termin nächstes
Treffen
Diskussion zum
weiteren Vorgehen
Verständigung auf
ein Szenario
MÄRZ
07
09
Besprechung
Anwendungsszenarien Diskussion zum
weiteren Vorgehen
FEBRUAR
28
Vorstellung
Dana Henkens
Arbeitspaket
Arbeitspakete
Phase 2
JANUAR
Urlaub/Abwesenh.
Anwendungsszenario:
Nächste Termine
Termine
Bewertun der Ideen Zwischenpräsentation
des Brainstormings
DEZEMBER
26
Vizamp
Konflikte im
Projektmanagement
Meetings
24
Szenarien
Todos
Todos
NOVEMBER
09
Situationsskizzen
Pressetext
Website
Termine
Vorstellung aktueller Vorstellung aktueller
Ansätze durch Axel Ansätze durch Mirko
OKTOBER
Todos
Neue
Anwendungen
06
Termine
ToDos
Neue
Anwendungen
SEPTEMBER
22
MAI
21
Neue
Anwendungen
06
AUGUST
Web-Demonstrator
Arbeitspaket
Anwendungsszenario:
Interaktive
Protokollführung
Besprechung
Vizamp-Logo
Besprechung
Vizamp-Logo
Arbeitspakete
Besprechung
Vizamp-Logo und
Website
Phaseneinteilung,
siehe Termine
Fragen zu
Hauptszenarien
Aufgabenverteilung
Termin nächstes
Treffen
aufsuchen
TODO
Konfliktzyklus
TODO
Konfliktbewertung
Diskussion
Termine
Konflikte
Interview
Ergebnisse (RG)
ToDos
Thema
Aufgaben
Konzepte von Mirko
der Demonstratoren
Aufgaben
Vorstellung
neuer Themen
Vorstellung der
Prototypen
07
FEBRUAR
ToDos
Termine
Termin nächstes
Treffen
28
Termine
Zwischenbericht
Abwesenheiten in
nächster Zeit
Status qou bei
queo
Termin nächstes
Treffen
Zwischenbericht
Termine
Aufgabenverteilung
sonstiges
Termin nächstes
Treffen
ToDos
Weiteres Vorgehen
Status quo bei MG
Arbeitspakete
2013
Todos
Besprechung der
View Konzepte
Konfliktbeziehungen
Zwischenbericht
Arbeitspakete
Diverses
Termine
sonstiges
Vorstellung des
und Konzept zur
22
JANUAR
Termin nächstes
Treffen
Termin nächstes
Treffen
Sonifikation
Urlaub/Abwesenh.
Artikel ERP-Systeme
und Usability
Diskussion
Konfliktbeziehungen
Thema
Zwischenbericht
Konfliktarten
Sonstiges
Termine
Kontext
Agilität
Konfliktdefinition
Folge Projekt
Arbeitspakete
Termin nächstes
Treffen
Eigenschaften von
Aufgaben
Sonstiges
Zwischenbericht
16
DEZEMBER
Diskussion zum
weiteren Vorgehen
Situationsskizzen
06
26
Verständigung auf
ein Szenario
Besprechung
weiteren Vorgehen
ToDos
Status quo bei MG
81
Aktueller Stand
NOVEMBER
Zwischenbericht
24
Status qou bei
queo
09
Besprechung der
Anwendungsszenarien
unter Einbeziehung
25
OKTOBER
13
Phaseneinteilung,
siehe Termine
Anwendungsszenario:
Nächste Termine
Arbeitspakete
Phase 2
23
Zwischenbericht
Todos
Termine
07
Szenarien
Konflikte im
Projektmanagement
Meetings
28
AUGUST
Todos
Todos
des Brainstormings
26
Situationsskizzen
Pressetext
Website
Termine
24
JULI
Termine
ToDos
Neue
Anwendungen
Neue
Anwendungen
06
Anforderungskatalog
SEPTEMBER
Begriffsklärung
und Abgrenzung
22
Vorstellung
Dana Henkens
09
JUNI
des Brainstormings
Vizamp
Vizamp
06
MAI
Besprechung der
Anwendungsszenarien
unter Einbeziehung
Vizamp
22
APRIL
Situationsskizzen
Inhalt und Ziele
im Projekt
Szenarien
18
MÄRZ
Situationsskizzen
04
FEBRUAR
Fragen zu
Hauptszenarien
31
JANUAR
09
DEZEMBER
04
NOVEMBER
Arbeitspakete
Termin nächstes
Treffen
21
OKTOBER
Vorstellung des
und Konzept zur
06
SEPTEMBER
Eigenschaften von
Aufgaben
AUGUST
Konfliktarten
JULI
Zwischenbericht
JUNI
Weiteres Vorgehen
MAI
Abwesenheiten in
nächster Zeit
Termin nächstes
Treffen
2013
2012
APRIL
Besprechung
weiteren Vorgehen
81
Vizamp Meeting Protokolle
MÄRZ
Diskussion zum
weiteren Vorgehen
Besprechung
Vizamp-Logo und
Website
Sonstiges
Termin nächstes
Treffen
Besprechung
Vizamp-Logo
Arbeitspakete
Termin nächstes
Treffen
80
80
04
APRIL
Vizamp
Neue
Anwendungen
Todos
2013
2012
21
2012
06
ToDos
Termine
Nächste Termine
MÄRZ
81
Vizamp
Inhalt und Ziele
im Projekt
80
MÄRZ
APRIL
MAI
23
Aktueller Stand
Artikel ERP-Systeme
und Usability
aufsuchen
Folge Projekt
TODO
JUNI
13
Web-Demonstrator
Konfliktdefinition
TODO
Termine
JULI
25
06
AUGUST
Diskussion
Thema
Diskussion
Konfliktbeziehungen
Konfliktzyklus
Konfliktbewertung
Thema
Aufgaben
Konzepte von Mirko
der Demonstratoren
Aufgaben
16
Diverses
22
Besprechung der
View Konzepte
Konfliktbeziehungen
Interview
Ergebnisse (RG)
Kontext
Agilität
Konflikte
ToDos
Termine
Vorstellung
neuer Themen
Vorstellung der
Prototypen
ToDos
Termine
81
2013
AUGUST
18
Anforderungskatalog
SEPTEMBER
22
06
OKTOBER
09
NOVEMBER
24
des Brainstormings
DEZEMBER
Verständigung auf
ein Szenario
Besprechung
Vizamp-Logo
Diskussion zum
weiteren Vorgehen
Besprechung
Vizamp-Logo
Situationsskizzen
Arbeitspakete
Besprechung
Vizamp-Logo und
Website
JUNI
JULI
Besprechung der
Anwendungsszenarien
unter Einbeziehung
Status qou bei
queo
Zwischenbericht
Aktueller Stand
Web-Demonstrator
ToDos
Status quo bei MG
Fragen zu
Hauptszenarien
Zwischenbericht
Aufgabenverteilung
Artikel ERP-Systeme
und Usability
aufsuchen
Konfliktarten
Arbeitspakete
Weiteres Vorgehen
Diverses
Besprechung der
View Konzepte
Konfliktbeziehungen
Konfliktzyklus
TODO
Konfliktbewertung
Diskussion
Termine
Konflikte
Interview
Ergebnisse (RG)
ToDos
Thema
Aufgaben
Konzepte von Mirko
der Demonstratoren
Zwischenbericht
Todos
22
Termine
sonstiges
Vorstellung des
und Konzept zur
Kontext
Diskussion
Konfliktbeziehungen
Thema
TODO
16
Agilität
Konfliktdefinition
Folge Projekt
Zwischenbericht
Termin nächstes
Treffen
06
Termine
AUGUST
25
Eigenschaften von
Aufgaben
Arbeitspakete
Termin nächstes
Treffen
MAI
13
Phaseneinteilung,
siehe Termine
Sonstiges
Sonstiges
APRIL
23
Termin nächstes
Treffen
MÄRZ
07
Szenarien
Besprechung
weiteren Vorgehen
FEBRUAR
28
Situationsskizzen
JANUAR
26
Aufgaben
Vorstellung
neuer Themen
Vorstellung der
Prototypen
ToDos
Termine
Termin nächstes
Treffen
Abwesenheiten in
nächster Zeit
Termin nächstes
Treffen
Termine
Das zuvor beschriebene Konzept wurde im Rahmen dieser Arbeit prototypisch umgesetzt. Der Prototyp greift die wichtigsten konzeptionellen Aspekte auf, um die technische Realisierbarkeit des Visualisierungs- und Interaktionskonzepts zu demonstrieren. Im Anschluss an die Beschreibung der verwendeten Technologie erläutert dieses Kapitel den Aufbau und die Generierung der grafischen Benutzeroberfläche sowie die Umsetzung ausgewählter
Interaktionsfunktionen. Schwerpunkt dabei liegt analog zur Konzeption (vgl.
Kapitel 1) auf der Umsetzung der Visualisierung, die die Grundlage für die
Interaktion bildet.
Die Wahl der Technologie fand unter Berücksichtigung der Anforderungen
an die technische Umsetzung (siehe Abschnitt 4.4.3) statt. Die Kombination
der Anforderungen (C1) – Nutzung des Werkzeugs als Tablet-Anwendung –
und (C2) – Nutzung des Werkzeugs als Desktopanwendung – resultiert in
der Umsetzung des Prototyps als Webanwendung auf Basis gängiger und
zukünftiger Webstandards (siehe [@W3C_standards]). Damit wird die Ausführbarkeit der Anwendung auf unterschiedlichsten Geräten und Plattformen gewährleistet. Eine Trennung von Struktur, Layout und Funktionalität
der Anwendung erwirkt die Verwendung von Hypertext Markup Language
Version 5 (HTML5), Cascading Style Sheets Version 3 (CSS3) und JavaScript. Die Einbindung der Inhalte erfolgt mittels JSON. Zur Erleichterung
der Implementierung kam die JavaScript Bibliothek D3.js [@D3] zum Einsatz.
Die Visualisierung basiert auf Scalable Vector Graphics (SVG), die im folgenden Abschnitt erläutert werden.
Scalable Vector Graphics (SVG) dienen der Generierung zweidimensionaler
vektorbasierter Grafiken. Ein großer Vorteil von SVG gegenüber anderen
Bildformaten, wie JPEG oder GIF (vgl. [@W3schools_svg]), besteht in der
unbegrenzten Skalierbarkeit innerhalb des zugrunde liegenden Koordinatensystems. Eine weitere Besonderheit ist, dass SVG vom World Wide Web
84
6.1. Technologie
Consortium (W3C26) als gängiger Webstandard definiert wurde. (vgl. [Dailey
et al. 12])
SVG unterstützt neben vektorbasierten Grafiken (sogenannte Shapes, siehe
Abbildung 6.1) ebenfalls Bilder und Text als grafische Objekte. Grafische
Objekte können gruppiert und transformiert und innerhalb von zuvor gerenderten Objekten, wie HTML DIV-Tags, angeordnet werden. Weiterhin besitzt SVG als Webstandard sein eigenes Document Object Model (DOM).
Dieses ermöglicht es, direkt auf SVG-Elemente sowie deren Attribute und
Eigenschaften zuzugreifen. Eventhandler wie
können den Elementen zugewiesen werden. Dadurch wird eine Vielfalt an Interaktions- und
Animationsmöglichkeiten zur Erstellung dynamischer Webanwendungen
geschaffen. (vgl. [Dahlström et al. 11])
D3.js [@D3] ist eine JavaScript-Bibliothek, die seit 2011 entwickelt wird (vgl.
[Teller 13], S. 7). Der Name D3 steht für Data Driven Documents – Datengetriebene Dokumente. Mithilfe dieser Bibliothek lassen sich Elemente einer
Website in Abhängigkeit eines zugrundeliegenden Datensatzes anlegen,
manipulieren und entfernen. Damit stellt D3 ein mächtiges Werkzeug zur
Datenvisualisierung dar. Die Bibliothek erlaubt sowohl die Manipulation von
HTML-, als auch von SVG- und CSS-Elementen. (vgl. [Dewar 12])
Mithilfe von Selektionen (engl. selections) stellt D3 vielfältige Möglichkeiten
zur direkten Auswahl von Elementen des DOM zur Verfügung. Elemente
können mittels Übergabe ihrer ID, ausgewählter Attributwerte oder des
Element-Tags an die
Funktion von D3 ausgewählt werden, ohne
notwendigerweise über die gesamte Dokumentstruktur zu iterieren (vgl
[Teller 13], S. 21). Beispiel einer solchen Selektion ist
"
" ,
die alle SVGRectElemente eines Dokuments zurückgibt. Die Ergebnisse der
Selektion, die in Form eines Arrays vorliegen, können anschließend nach
spezifischen Eigenschaften gefiltert, oder ihre Attribute manipuliert werden
(vgl. [@D3]).
Eigenschaften wie das Aussehen eines Elements, oder Positionskoordinaten, können als Funktionen spezifiziert werden. Damit wird die Möglichkeit
einer dynamischen, datenabhängigen Belegung der Attribute bereitgestellt.
(vgl. [@D3])
Ein Datensatz wird einer Selektion dazu als Array übergeben. Jeder Wert
des Arrays wird dem Element der Selektion bei Ausführen einer Funktion
nach dem Prinzip „join-by-index“ übergeben – das erste Element der Selektion erhält den Wert zum ersten Index des Arrays, und so weiter. Aufgerufen werden die Werte des Datensatzes über die anonyme Funktion
26
www.w3.org, aufgerufen am 12.02.2014
TECHNISCHE UMSETZUNG
85
Dabei beinhaltet
den Wert und den Index der Selektion,
dessen Übergabe optional ist – Die Funktion kann ebenfalls als
ohne Übergabe des Indexes aufgerufen werden. Das dynamische Anlegen
von Elementen erfolgt durch die
Selektion. Falls eine Selektion weniger Elemente zurückgibt, als der angebundene Datensatz enthält, sorgt
diese Selektion dafür, dass weitere Elemente generiert werden. (vgl. [@D3])
Die Anbindung der Daten erfolgt clientseitig mittels JSON (JavaScript Object
Notation). Das erleichtert die Datenanbindung im Vergleich zu XML, da die
JavaScript Engine des Browsers das Parsen von JSON übernimmt. Obwohl
JSON der Objekt-Notation von JavaScript sehr stark ähnelt, ist es unabhängig von JavaScript und wird auch von anderen Programmiersprachen wie
C#, PHP und Java unterstützt. Die Notation erfolgt in Schlüssel-WertePaaren (engl. key and value pairs), die jeweils von doppelten Anführungszeichen umschlossen werden und in der Form
notiert. Der
Wert eines Schlüssels kann sechs verschiedene Datentypen annehmen:
Strings, Numbers, Booleans, Arrays, Objects und Null. (vgl. [Sriparasa 13],
S.16)
Dieser Abschnitt beschreibt zunächst das Datenschema sowie den Aufbau
der Anwendung. Als zentraler Teil der Implementierung der grafischen Benutzeroberfläche (GUI) wird anschließend die Generierung der Zeitachse
näher erläutert. Sie ist die Basis für die Positionsberechnung aller weiteren
SVG-Elemente.
Die Meeting-Inhalte liegen als JSON-Objekte in den Dateien
und
vor. Die Datei
besteht aus einer Reihe von Objekten
und Arrays und folgt der Datenhierarchie, die in Abschnitt 5.1.2 erläutert
wurde. Die Datei
js beinhaltet die Relationen zu den Entitäten.
Quellcode 6.1 zeigt beispielhaft den Aufbau der Entitäten-Datenstruktur. Das
abgebildete JSON-Objekt enthält ein Meeting mit dem Meeting-Datum
. Der Array
beinhaltet alle Themen zum Meeting, in diesem
Falle nur „Thema A“. Dem Thema ist schließlich der Array
zugeordnet, der zu jedem Inhalt die zugehörige Kategorie speichert. Bei den Kategorie-Werten handelt es sich um Daten eines Enum
,
wobei für Aufgabe, für Gesprächspunkt, für Beschluss, für Idee und
für Termin steht.
86
6.2. Implementierung der GUI
Mit dem Start der Anwendung erfolgt die Verarbeitung der Daten in
. Dabei werden allen Elementen IDs zugewiesen, die
neben der eindeutigen Identifikation der Entität auch einen Rückschluss auf
das übergeordnete Element zulassen. Die Meeting-ID
ist ein String der
Länge drei, der die Nummer des Meetings im Projekt angibt. Die ThemenID
besteht aus der
, die mit einem weiteren dreistelligen String
verknüpft wird. Der zweite Teil der
bestimmt die Position des Themas
im Meeting. Analog setzt sich die
aus
verknüpft mit
und dem
Index des Inhalts im Thema zusammen. So identifiziert beispielsweise
den zwölften Inhaltspunkt des neunten Themas in Meeting
Nummer 3. Diese Art und Weise, die IDs zu vergeben, kommt unter anderem beim Zeichnen der Relationen (siehe Abschnitt 6.2.6), sowie beim Aufruf der Detailansichten (siehe Abschnitt 0) zum Tragen. Die Unterscheidbarkeit der ID eines Themas von der eines Inhalts anhand der ID-Länge spielt
außerdem beim Zeichnen der Relationsenden eine Rolle.
Die Relationen werden in JSON als Objekt mit drei Attributen gespeichert.
Zum einen definieren die Schlüssel
und
die beiden verbundenen
Elemente durch die Übergabe der entsprechenden ID. Zusätzlich wird die
Relationsart durch die Belegung des Schlüssels
mit dem Wert
oder
old unterschieden. Der Wert
repräsentiert eine „Führt zu“-,
eine
Fortführungsrelation. Bei der initialen Datenverarbeitung werden die Relationen anhand ihrer Arten in zwei getrennten Arrays gespeichert. Das erleichtert die Datenanbindung beim Zeichnen der Relationen als SVG-Elemente,
die dem Visualisierungskonzept nach unterschiedlich aussehen und damit
auf unterschiedliche Weise generiert werden müssen (siehe Abschnitt
6.2.6). Beispiel eines Relations-Objekts ist in Quellcode 6.2 dargestellt. Es
handelt sich um die Relation eines Inhalts, der im nächsten Meeting zu einem Thema führt.
87
Die Anwendungsoberfläche enthält, ähnlich zur Beschreibung in Abschnitt
5.2.2, drei Bereiche. Auf eine Umsetzung der Browserleiste wurde im Rahmen der Arbeit verzichtet. Den dritten Bereich der Anwendungsoberfläche
stellt die Zeitleiste dar (siehe Abschnitt 5.2.3), die damit von der eigentlichen
Datenvisualisierung abgegrenzt wird.
Abbildung 6.2 zeigt den Aufbau. Die DIV-Elemente sind mit „#“ gekennzeichnet. Das grundlegende SVGElement der Visualisierung stellt
dar. Es umfasst die gesamte Datenvisualisierung und ist in
die SVGGroupElements
und
unterteilt. Die
Gruppierung beinhaltet die Zeitachse,
die Darstellung der MeetingInhalte. Das Visualisierungskonzept sieht vor, dass Relationen in der Visualisierung unter den eigentlichen Meeting-Inhalten liegen, die Relationsenden
von Inhalten jedoch darüber. Zu diesem Zweck werden
,
sowie
als Untergruppen von
angelegt.
Alle Relationspfade sowie die Relationsenden von Themen liegen in
. Das SVGGroupElement
beinhaltet neben den
Meeting-Daten (siehe Abbildung 6.4, Abschnitt 6.2.3) die Themennamen in
Form von SVGTextElements, sowie die Inhalte als SVGRectElements. Die
Gruppe
umschließt die Relationsenden, die zu Inhalten gehören, und wird als letzte der Gruppen gerendert (vgl. [@W3C_render]).
Innerhalb des SVGGroupElements
befinden sich für jedes Meeting ein weiteres SVGGroupElement, dem die ID des zugehörigen Meetings
übergeben wird. Zusätzlich fassen innerhalb eines Meeting weitere
SVGGroupElements jedes Thema mit dessen Inhalten zusammen. Diese
88
Gruppierungen ermöglichen eine erleichterte Implementierung der ZoomFunktionalität und Detail-Ansicht, die in Abschnitt 6.3 beschrieben werden.
Zur Implementierung der globalen Zeitachse (siehe Abschnitt 5.1.2) wurde
genutzt. Diese Funktion stellt eine Erweiterung der Linearen Achse
dar [@D3_timescales]. Sie gibt eine Zeitachse
zurück, deren Definitionsbereich (
beim vorliegenden Prototyp den
gesamten Projektzeitraum abdeckt. Dazu werden bei der Initialisierung der
Zeitachse die Daten des ersten und letzten Meetings übergeben. Die
Reichweite der Zeitachse, bezeichnet als
, definiert die horizontale
Skalierung. Sie wird bei der Implementierung der Zoom-Funktionalität dynamisch verändert (siehe Abschnitt 6.3.1). Initial erhält sie den Wert zugewiesen, der für die Breite der Visualisierung unter Berücksichtigung des
kleinsten Abstandes zwischen zwei Meetings berechnet wird. Quellcode 6.3
verdeutlicht die Implementierung der Zeitachse. Die sogenannten
bezeichnen die Markierungen der Zeitbereiche.
Dieser Code generiert eine Zeitachse, die zunächst nur den Wertebereich
der Meeting-Daten abbildet. Durch Aufruf der Funktion
mit
Übergabe des Datums wird die Position an der Zeitachse berechnet. Dieses Prinzip findet Anwendung beim Zeichnen aller SVG-Elemente der Visualisierung, das in Abschnitt 6.2.5 erläutert wird.
89
Die Zeitleiste bildet den aktuellen Ausschnitt der sichtbaren Meetings bezüglich der gesamten Projektlaufzeit ab. Zur Berechnung werden die aktuelle Fensterbreite und die Gesamtbreite der Visualisierung benötigt (siehe
Abbildung 6.3). Zunächst erfolgt die Berechnung des prozentualen Anteils,
den der aktuelle Ausschnitt in der Gesamtvisualisierung einnimmt. Dieser
wird anschließend wiederum mit der aktuellen Fensterbreite des Browsers
multipliziert. Das Ergebnis stellt die Breite der
dar. (vgl Abbildung
6.4).
Entsprechend dem Entwurf des Visualisierungskonzepts (siehe Abschnitt
5.1) erfolgt Darstellung der Meeting-Daten auf der Zeitachse mittels
SVGCircleElement und SVGTextElement, welches den Tag des MeetingDatums repräsentiert. Quellcode 6.4 zeigt die Implementierung der
SVGCircleElements. Das cx-Attribut des Kreises wird durch Aufruf der
Funktion berechnet, die beim Anlegen der Zeitachse definiert wurde
(siehe Abschnitt 6.2.3). Dem SVGGroupElement
, das die
SVGCircleElements beinhaltet, wurden zuvor die Meeting-Daten als Array
übergeben. Der Datensatz wird allen
übergeben – in diesem Fall
.
Abbildung 6.4 veranschaulicht das Ergebnis, das diese Implementierung
unter Anbindung der Vizamp Meeting-Daten generiert.
Die horizontale Anordnung der Entitäten erfolgt analog zu den MeetingDaten durch Aufruf der
Funktion (vgl. Abschnitt 6.2.3). Komplexer gestaltet sich die vertikale Positionierung. Die y-Position der Themen ist
sowohl von der Anzahl der Inhalte des vorausgehenden Themas, als auch
von deren einzelnen Längen abhängig (vgl. Abschnitt 5.1.3). Es wurde darauf
verzichtet, diese im Vorfeld zu berechnen. Stattdessen werden die zuerst
die Inhalte gezeichnet und im Prozess die y-Positionen für die Themen abhängig von der generierten Höhe der einzelnen Inhalte und ihrer Gesamtan-
90
zahl berechnet. Aus diesem Grund erfolgte das Speichern der berechneten
y-Position für die Themen in einem globalen Array
, dessen Werte
beim Zeichnen der SVGTextElemente für die Themen dynamisch abgerufen
werden.
Wie in Abschnitt 6.2.2 beschrieben, werden Inhalte und Themen einem
SVGGroupElement zugeordnet, das als
bezeichnet wird. Bei Initialisierung dieser Gruppe erfolgt die Anbindung der Meeting-Daten für jedes
Thema einzeln. Auf die Daten kann durch Aufruf der anonymen Datenfunktion
zugegriffen werden. Der Index
wird dabei für jedes
neue Thema auf 0 zurückgesetzt, was eine spezielle Handhabung der Positionsbestimmung nach sich zieht, die innerhalb eines Meetings von der
Höhe und Position des vorhergehenden SVGRectElements abhängt. Da der
Index der Iteration für jedes neue Thema zurückgesetzt wird, kann auf das
vorhergehende SVGRectElement bei Beginn eines neuen Themas nicht
dynamisch zugegriffen werden. Aus diesem Grund findet hier analog zur
Berechnung der y-Position der Themen eine Speicherung der Werte im externen Array
statt. Die globale Variable y_pos speichert weiterhin die
y-Position eines jeden Inhalts als Ausgangsgrundlage für das nächste zu
generierende Element. Hier genügt es, eine einzige Variable zu verwenden,
die bei jeder Iteration neu gesetzt wird. Abbildung 6.5 schematisiert die
beschriebenen Abhängigkeiten und die Ausführung der Berechnungen.
In jedem Iterationsschritt wird geprüft, ob der Inhalt sich im selben Thema
und Meeting befindet, wie der vorherige. Treffen diese Bedingungen zu,
berechnet sich die y-Positon wie folgt:
.
Handelt es sich um das nächste Thema, jedoch nicht das nächste Meeting,
wird der Abstand t_distance dazu addiert. Gleichzeitig wird der y-Wert des
vorhergehenden Inhalts an
übergeben. Für jedes neue Meeting
wird
auf den initialen Wert zurückgesetzt und dieser in
gespeichert. Die Höhe des letzten Inhalts eines Meetings geht somit nicht in
die Berechnung für das nächste Element ein.
91
Zum Zeichnen der Relationslinien und -Enden spielen folgende Attribute der
entsprechenden Entitäten eine Rolle:



x- und y-Position,
Höhe und Breite
Inhaltskategorie
D3 erlaubt den direkten Zugriff auf die SVG-Elemente durch Selektion der
jeweiligen ID, die beim Zeichnen den Entitäten übergeben wurden und sich
in den
und
Werten der Relation wiederfinden. Beim Abruf der
Attribute muss beachtet werden, dass diese von CSS als String zurückgegeben werden. Zur Berechnung der endgültigen Attribute der Relation anhand der Werte muss daher zunächst
ausgeführt werden.
Die Relationslinien werden durch kubische Bezierkurven repräsentiert. Bei
Relationen des Typs
handelt es sich um SVGPathElements, die aus
zwei Bezierkurven bestehen, welche durch einfache Linienpfade verbunden
werden. Sie werden für die Zeichnung der Fortführungsrelationen als Folge
von neun Punkten repräsentiert. Jeder Punkt enthält eine Bezeichnung, die
die Verbindungslinie zum nächsten Punkt beschreibt. Der Startpunkt wird
mit dem Buchstaben M bezeichnet, was „Move To“ bedeutet und die Bewegung des Zeigers zu diesem Punkt hin verdeutlicht. Die nächsten drei
Punkte sind Kontrollpunkte der Bezierkurve und werden mit C gekennzeichnet. Anschließend erfolgt das Zeichnen einer Linie anhand des Kennbuchstabens L. Zur Rückkehr zum Startpunkt und Abschließen der Fläche wird
der Startpunkt als neunter Punkt nochmals übergeben. Abbildung 6.6 zeigt
einen solchen Pfad und seine Punkte. (vgl. [@W3schools_bezier])
Die Enden einer Relation werden abhängig von der Art der Entität als Kreis
(Inhalt) oder vertikale Linie (Thema) repräsentiert (vgl. Abschnitt 5.1.4). Die
Art der Entität wird anhand der ID der
und
-Werte der Relation
erkannt. Eine Filterfunktion entscheidet, ob das Zeichnen eines Kreises oder
eines Rechtecks stattfindet. Quellcode 6.5 verdeutlicht die Anwendung der
Filterfunktion beim Zeichnen eines Kreises als Relationsende für Inhalte.
Falls die übergebene ID nicht die Länge 9 hat, und damit keinem Inhalt entspricht, bricht der Vorgang ab.
Ein Problem, das sich bei der Implementierung der Relationen ergab, liegt in
Themenelementen, die keine Inhalte umfassen (vgl. Abschnitt 5.4.1). Solche
Themen existieren innerhalb der Datengrundlage und sind auch über Relationen mit anderen Themen verknüpft. Da zum Zeichnen der Relationselemente die Höhe der Inhalte des SVGGroupElements bestimmt wird, die bei
92
6.3. Implementierung der Interaktion
einem alleinstehenden SVGTextElement nicht gegeben ist, wird als momentane Lösung ein Platzhalter-Inhalt eingefügt.
Abbildung 6.7 zeigt abschließend einen Ausschnitt aus der Anwendungsoberfläche des beschriebenen Prototyps, ausgeführt im Google Chrome
Browser. Der Anwendung liegen die Daten der Vizamp-Meetings zugrunde,
die zuvor bereits zur Veranschaulichung des Visualisierungskonzepts verwendet wurden (siehe Abschnitt 5.4.1). Die
am oberen Fensterrand zeigt das Verhältnis des abgebildeten Ausschnitts zur gesamten Projektlaufzeit an.
Die grundlegenden Interaktionsfunktionalitäten stellen die zeitspezifische
Zoomfunktion sowie die Auswahl der Visualisierungselemente zur Detailansicht dar. Weiterhin beschreibt dieser Abschnitt das Anpassen der Vsiualisierung bei Auswahl einer Relation.
93
Die Zoomfunktionalität, die in einer Stauchung oder Streckung der Zeitachse
resultiert, wurde unter Verwendung von
implementiert
[@D3_drag]. Diese Funktion erlaubt den automatischen Abruf der Ausführung eines Drag-Events auf SVGElementen. Zu diesem Zweck erfolgt die
Einführung der beiden SVGRectElements
und
, welche die Enden der
repräsentieren. Ihnen wird
mittels
ein zuvor spezifiziertes Drag-Verhalten
zugewiesen.
Abhängig davon, ob der Nutzer den rechten oder linken Teil der
bewegt, muss zur Neuberechnung der Reichweite der
(vgl. Abschnitt 6.2.3) die Veränderung Zeigerposition von der aktuellen Reichweite
subtrahiert oder dazu addiert werden. Der Aufruf von
gibt diese Veränderung aus. Bei der Bewegung nach rechts entspricht
einem positiven, bei der Bewegung nach links einem negativen Wert. Quellcode 6.6 zeigt einen Ausschnitt des als
definierten
Verhaltens, welches dem
Element zugewiesen wurde. Abgebildet ist die Implementierung der Neuberechnung der
Breite, die dem
Attribut der
übergeben wird.
Neben der Stauchung oder Streckung der Zeitachse bewirkt die implementierte Zoomfunktion das Verschieben der Meeting-Elemente. Eine Iteration
über alle Meeting-Daten beinhaltet die Selektion der zugehörigen
SVGGroupElements
. Die Zuweisung des
Attributs zu
jeder Gruppe löst eine Verschiebung aller zugehörigen Elemente um den
Wert
aus. Dieser berechnet sich aus der Differenz der aktuellen xPosition zur der x-Position des Meetings an der neuen
(siehe
Quellcode 6.7).
94
Beim Verschieben der Elemente kommt es insbesondere dann zu Überlagerungen, wenn Meetings dicht zusammenliegen. Eine Skalierung der Elemente ist nur bedingt geeignet, da die Textlesbarkeit mit geringer werdender Schriftgröße darunter leidet.
Bei Auswahl eines einzelnen SVGRectElements, welches einen zugehörigen
Inhalt repräsentiert, wird das Rechteck eingeklappt. Der entsprechende
Inhalt wird anschließend als SVGTextElement der jeweiligen SVGGroup
angehangen (siehe Abbildung 6.8). Zu diesem Zweck erfolgt die
Übergabe eines
Eventhandlers wie folgt:
Die Funktion
erhält den konkreten Inhalt (
) sowie
dessen ID (
) als Parameter. Mithilfe dieser Werte erfolgt die Positionsberechnung und Textzuweisung für das SVGTextElement (siehe Quellcode 6.9).
95
Die Auswahl eines Themas, ebenso wie die Auswahl eines Meetings, zeigt
die Details aller zugehörigen Inhalte an (vgl. Abschnitt 5.2.4). Die Umsetzung
dieser Funktionalität erfordert die Zuweisung weiterer
Eventhandler an das SVGTextElement des Themas, sowie an das SVGCircleElement
und das SVGTextElement des Meeting-Datums. Die Logik der Funktionen
und
ist die gleiche. Unterschied ist, dass bei
alle SVGRectElements einer
Gruppierung, beim
alle SVGRectElements der
Gruppe selektiert werden. Während D3 die Aktualisierung ausgewählter Attribute einer ganzen
Selektion übernimmt, ist zum Aufruf von
Eventhandlern der direkte Zugriff auf die SVGElements nötig. Diese liegen innerhalb der Selektion in
einem zweidimensionalen Array vor (vgl. [@D3_selection]). Der Aufruf der
Funktionen der einzelen SVGRectElements erfolgt aus diesem
Grund mittels zweifacher
Funktion (siehe Quellcode 6.10). Zunächst muss das auszuführende Event definiert werden, was mittels
geschieht.
Umgesetzt wurde die Anpassung der Visualisierung nur für die Auswahl
einer Relation. Das Ausblenden nichtzugehöriger Themen, Inhalte und Meetings bei Auswahl einer Entität weist eine ähnliche Anwendungslogik auf,
auf deren Implementierung im Rahmen dieser Arbeit verzichtet wurde.
Im ersten Iterationsschritt, der auf die Auswahl einer Relation folgt, werden
die
und
Werte der Relation ausgewertet. Dazu wird über die Relationsdaten
iteriert und nach Relationen gesucht, die als
oder
Wert ebenfalls eine der beiden IDs besitzen (siehe Quellcode 6.11).
96
Aus den Inhalts-IDs werden im Anschluss alle zugehörigen Themen-IDs
generiert, die als Substring in den Inhalts-ID enthalten sind (vgl. Abschnitt
6.2.1). Dieser Schritt wird ausgeführt, da ein Inhalt dem Konzept nach nicht
ohne sein zugehöriges Thema abgebildet wird. Damit soll der semantische
Kontext jederzeit erhalten bleiben. Anhand der Themen-IDs werden im Folgenden Iterationsschritt die in
verbliebenen Relationsobjekte auf
Übereinstimmung mit der Liste der IDs überprüft. Dadurch werden Relationen entdeckt, die von Inhalten und Themen ausgehen, die im ersten Iterationsschritt nicht berücksichtigt wurden. Diese Iteration wird solange ausgeführt, bis keine neuen IDs mehr hinzukommen oder bis der Array mit den
tmp_rels die Länge 0 hat. Das würde bedeuten, dass die Meeting-Inhalte ein
Netz repräsentieren, bei dem alle Knoten über mehrere Kanten miteinander
verbunden sind, und die Visualisierung würde sich bei Auswahl einer Relation nicht ändern. Dieser Fall ist unwahrscheinlich, nimmt man die VizampMeetings als Beispiel. Dennoch könnte eine manuelle Festlegung der Anzahl an Iterationsschritten, die das System beim Erkennen von Relationen
ausführen soll, als zusätzliche Funktionalität für den Nutzer bereitgestellt
werden.
Zu den auf diese Weise extrahierten IDs werden im Anschluss an die Iteration die eigentlichen Datenobjekte aus den Datenarrays
und
ausgelesen. Sie stellen die neue Datengrundlage für das Update der Visualisierung
dar.
Letztendlich erfolgt das Update der Visualisierung mithilfe der
und
Funktionen, die D3 zur Verfügung stellt [@D3]. Während die
Funktion Elemente generiert (vgl. Abschnitt 6.1.2), gibt die
Funktion überschüssige Elemente frei, die anschließend mit
entfernt werden. Im vorliegenden Anwendungsfall bedeutet das, dass alle
Themen, die nicht in der Ergebnismenge der zuvor ausgeführten Iteration
liegen, ausgeblendet werden. Dazu werden die vorhandenen
SVGGroupElements und ihre childNodes mit den neuen Daten befüllt, und
die restlichen Elemente aus der Visualisierung gelöscht (siehe .
97
Dieses Kapitel beschrieb die Implementierung des Visualisierungskonzepts,
das auf Basis von SVG und D3.js als Webanwendung implementiert wurde.
Weiterhin wurden ausgewählte Aspekte bei der Umsetzung der Interaktion
unter Nutzung der vielfältigen Funktionen der D3.js-Bibliothek erläutert. Damit wurde ein Überblick über die Anwendungslogik des Prototyps gegeben.
Die Such- und Filterfunktionen wurden im Rahmen dieser Arbeit nicht implementiert. Zur Umsetzung benötigte Grundlagen, wie das Anpassen der
Visualisierung an eine Auswahl (vgl. Abschnitt 6.3.3) sind jedoch vorhanden
und würden im Falle einer Weiterentwicklung die Implementierung dieser
Funktionen stark erleichtern. Nicht umgesetzt wurden außerdem die Browserfunktionalitäten. Zu diesem Zweck müsste eine Zwischenspeicherung
der Datensätze erfolgen, die als Stack im System abgelegt und bei Betätigen der Zurück- und Vor-Buttons aufgerufen werden. Ein anschließendes
Update der Visualisierung ist ebenfalls bereits in Form der in Abschnitt 6.3.3
beschriebenen Anwendungslogik vorhanden.
In der Detailansicht fehlt weiterhin ein Umschließen der Textelemente durch
eine Textbox, die die Breite der SVGTextElements eingrenzt und längere
Inhalte über mehrere Zeilen laufen lässt. SVG unterstützt zum Zeitpunkt der
Implementierung keine Wrap-Funktionalität für SVGTextElements. Eine solche Funktionalität ist jedoch für SVG2 geplant (vgl. [@W3C_svg2] und
[@W3C_text]). Die abhängig von der Textlänge berechnete Höhe der SVGRectElements (siehe Abschnitt 6.2.5) stellt bereits den nötigen Platz zur
Verfügung, um Texte auch über mehrere Zeilen einzubinden.
Nicht berücksichtigt wurden beim Anlegen der JSON-Daten die Strukturen
zwischen den Inhalten. Vernachlässigt wurde daher das Einrücken von Inhalten, die anderen Inhalten zugeordnet sind.
Ein Problem stellt die Überlagerung von Visualisierungselementen beim
Stauchen der Zeitachse dar. Im Rahmen dieser Arbeit was es nicht möglich,
98
dieses Problem eingehender zu untersuchen und mögliche Lösungen vorzustellen. Abschnitt 7.2 greift diesen Umstand bei der Beschreibung wissenschaftlicher Fragestellungen, die sich aus der Arbeit ergeben haben, auf.
Ein Test der Anwendung erfolgte mit den aktuell gängigen Browsern Google
Chrome, Apple Safari, Mozilla Firefox, Opera und Microsoft Internet Explorer
(vgl. [Lunn 13]). Weiterhin wurde die Anwendung auf einem iPad 3 Tablet
getestet. Sowohl die Visualisierung, als auch die Interaktion funktionierten
bei allen Testumgebungen korrekt. Damit sind die Anforderungen an die
technische Umsetzung (siehe Abschnitt 4.4.3) als erfüllt zu betrachten.
Dieses Kapitel beschreibt die Erkenntnisse der Arbeit und fasst die Ergebnisse abschließend zusammen. Eine mögliche Weiterentwicklung des Konzepts in verschiedene Richtungen wird näher betrachtet. Weiterhin werden
Forschungsfragen genannt, die sich aus Problemstellungen bei der Konzeption und technischen Umsetzung ergaben und die sich im Rahmen dieser
Arbeit nicht beantworten ließen.
Die vorliegende Arbeit beschrieb die Konzeption eines grafischen Browsers
für Protokolle mehrerer Meetings. Im weiteren Sinne stellt das Konzept eine
Anwendung im Bereich der Informationsvisualisierung dar. Die MeetingInhalte waren dabei die zu visualisierende Information. Die Vorteile, die eine
Datenvisualisierung bei der Informationsverarbeitung bietet (siehe Abschnitt
2.2.1), ließen sich auf das Konzept übertragen.
Trotz der vielfältigen Ausprägung verschiedener Meeting-Eigenschaften, die
in Abschnitt 2.1.2 bei der Klassifikation von Meeting-Arten beschrieben
wurden, konnte im Rahmen der Datenanalyse ein Modell für allgemeine
Meeting-Strukturen aufgestellt werden. Dieses Modell stellt die Grundlage
für das Konzept dieser Arbeit, sowie für die prototypische Umsetzung dar.
Die Eignung des Visualisierungskonzepts zur Abbildung reeller MeetingInhalte ließ sich durch die Anwendung auf die Vizamp-Protokolle feststellen
(siehe Abschnitt 5.4.1). Der Test des Prototyps erfolgte ebenfalls auf Basis
dieser Daten. Probleme stellten dabei nur Themen ohne Inhalte dar, die
bereits bei der Bewertung des Visualisierungskonzepts kritisch zu betrachten waren. Eine mögliche und hier angewendete Lösung liegt im Hinzufügen eines leeren Inhaltselements als Platzhalter (vgl. Abschnitt 6.2.6).
Die Realisierbarkeit des Visualisierungs- und Interaktionskonzepts konnte
anhand der Implementierung ausgewählter Funktionalitäten als Webanwendung nachgewiesen werden. Im Speziellen wurde die technische Umsetzung des Visualisierungskonzepts demonstriert. Zum Einsatz kamen insbesondere SVG und JavaScript unter Nutzung der Bibliothek D3.js. Die zugrunde liegende Technologie folgt aktuellen Webstandards und wird von
allen gängigen Browsers unterstützt. Die Anwendung ist somit plattformunabhängig.
102
Ausblick
Grundlegendes Ziel dieser Arbeit bestand darin, den Informationsabruf von
Meeting-Inhalten für eine Folge von Meetings zu unterstützen. Damit sollten
konkrete Anwendungsfälle im Vergleich zur Verwendung einzelner MeetingAufzeichnungen erleichtert und effizienter gestaltet werden. Abschnitt 5.3
beschreibt die Anwendung des konzipierten Werkzeugs zur Umsetzung der
Anwendungsfälle. Dabei wurden die Potentiale aufgezeigt, die das Konzept
beim Szenario „Informationsabruf“ aufweist. Bei Betrachtung eines einzelnen Protokolls lässt sich ohne vertiefte Kenntnisse zu vorangegangenen
Meetings und deren Protokollen nicht abschätzen, ob alle relevanten oder
gesuchten Informationen vorliegen oder weitere Protokolle aufgerufen werden müssen. Das vorgestellte Visualisierungskonzept löst dieses Problem
mithilfe einer detailreichen Visualisierung der Inhalte und bestehender Zusammenhänge, die gleichzeitig einen Überblick über die Inhalte zulässt.
Weiterhin wird die zugrunde liegende Information mithilfe des beschriebenen Interaktionskonzepts zugänglich gemacht und der Wechsel zwischen
Überblick und Detail ermöglicht.
Bei der Erarbeitung des Konzepts ergaben sich zahlreiche Ideen zur Weiterentwicklung und -Nutzung des konzipierten Werkzeugs. Einige Probleme,
die im Zuge der Konzeption und Entwicklung auftraten, ließen sich im Rahmen dieses Konzepts nicht beantworten. Sie werden als wissenschaftliche
Fragestellungen vorgestellt, die sich an diese Arbeit anschließen.
Einen kritischen Punkt des Konzepts stellte die Abbildung offener Themen
und Inhalte dar, die mit der beschriebenen Visualisierung nicht explizit gegeben ist. Dieser Umstand beruht unter anderem auf der Tatsache, dass das
Konzept keine Manipulation der Daten umfasst. Die Abgrenzung des Konzepts als reine Anwendung zum Informationsabruf und die damit einhergehende Konzentration auf die Informationssuche begründen das Fehlen dieser Funktionalität. Eine lückenlose Visualisierung offener Themen und Inhalte wäre nur dann möglich, wenn das Interaktionskonzept um die beschriebenen Manipulationsfunktionalitäten (siehe Abschnitt 4.3.2) erweitert würde. Die Nutzung der Anwendung beim Vorbereiten des nächsten Meetings
könnte dann um die Funktion der expliziten Weiterführung von Themen und
Inhalten ergänzt werden. Vorstellbar wäre eine Umsetzung als Drag and
Drop Interaktion, bei der offene Themen und Inhalte des letzten Meetings in
einem speziellen Bereich der Anwendung abgelegt würden. Bei Aufruf der
Anwendung zum Erstellen der nächsten Agenda könnten diese Themen
dann problemlos gesichtet und in die Agenda übernommen werden.
In diesem Kontext wäre ebenfalls die direkte Eingabe der Meeting-Inhalte
während oder im Anschluss an das Meeting denkbar. Neue Information
könnte durch Auswahl vorliegender Inhalte gleichzeitig mit diesen verknüpft
ZUSAMMENFASSUNG
103
werden. Eine Eingabemaske zur Erstellung wäre auf Basis des existierenden
Prototyps bereits realisierbar. Die neuen Daten würden in diesem Fall in die
JSON-Datei geschrieben werden. Die Idee einer solchen Eingabemaske
setzt aktuell das Online-Werkzeug minutes.io27 um. Dabei werden, ähnlich
zur hier beschriebenen Datenstruktur, Inhalte zu einem Thema als eine von
vier vorgegebenen Kategorien getagged.
Die zugrunde liegende Datenstruktur weist eine Allgemeingültigkeit für Projekt-Meetings auf. Eine mögliche Übertragung des vorliegenden auf andere
Arten von Meeting-Aufzeichnungen als Protokolle wäre zu untersuchen.
Dabei kämen insbesondere die unterschiedlichen Datenformate zum Tragen, die beispielsweise multimediale Aufzeichnungen bereitstellen. Interessant wäre ebenfalls die Anwendung des Konzepts bei der Verwaltung eigener Notizen.
Liegen die Meeting-Inhalte in Form von Audio- oder Video-Aufzeichnungen
vor, wäre in Zukunft eine Vollautomatisierung von der Informationssicherung
hin zum Informationsabruf denkbar. Entsprechende Software zur inhaltlichen
Zusammenfassung und Kategorisierung von Meeting-Aufzeichnungen wird
bereits entwickelt28, ebenso wie die Verknüpfung von Inhalten mittels
Schlüsselwortextraktion in Text Mining Systemen verwendet wird. Beispiele
dafür stellen EventRiver und Story Flow dar (siehe Abschnitt 3.1).
Ein anderer Gedanke ist die direkte Einbindung des Konzepts in bestehende
Meeting-Prozesse in Form einer kollaborativen Anwendung. Themen könnten von allen Beteiligten angelegt und mit Inhalten aufgefüllt werden. Eine
Nutzung der Anwendung zum Teilen von Notizen ist in diesem Sinne denkbar.
Aufbauend auf der Visualisierung und Interaktion mit dem konzipierten
Werkzeug könnten weiterhin Inhalte exportiert und importiert werden. Der
Export von Aufgaben und Terminen sowie allgemeinen Informationen hin zu
verwendeter Projektplanungssoftware wäre beispielsweise sinnvoll. Andere
Exportfunktionen könnten eine Zusammenfassung des Projektstatus liefern.
Termine, die sich in den Protokollen finden, könnten mit Kalenderanwendungen verlinkt werden. Die Einbindung externer Dokumente über eine
Importfunktion wäre ebenfalls denkbar. So könnten inhaltlich relevante Dateien nach Einbinden mit einem Klick aus der Anwendung heraus aufgerufen
und gesichtet werden.
Die Einbeziehung weiterer Informationen, wie die Namen und Kontaktdaten
der Teilnehmer eines Meetings, könnte umgesetzt werden. Ebenso stellt
die Markierung persönlich relevanter Inhalte, wie beispielsweise zugewiesener Aufgaben, eine nützliche Erweiterung des Konzepts dar. Eine personalisierte Ansicht der Meeting-Daten könnte implementiert werden.
27
www.miutes.io (aufgerufen am 12.02.2014)
28
Literaturhinweis: [Gaussier et al. 12]
104
Ausblick
Als Problemstellung bei der Implementierung besonders hervorzuheben ist
die Überschneidung der Texte mit anderen Visualisierungselementen in der
Detailansicht. Speziell beim Hineinzoomen mittels Stauchung der Zeitachse
kam es zu Überlagerungen, die zu Unübersichtlichkeiten führten. Zu untersuchen wäre eine geeignete Anpassung der Visualisierung in einer Weise,
die sowohl die Textlesbarkeit, als auch die Ersichtlichkeit semantischer Zusammenhänge erhält. Vorstellbar wäre die dynamische Anpassung der Zeitachse selbst durch Aufhebung der Kontiunierlichkeit. Im Zuge dessen könnte die Abbildung der Meeting-Daten in Abhängigkeit von den Elementen und
ihrem Platzbedarf erfolgen, wobei eine Visualisierung der zeitlichen Zusammenhänge beziehungsweise der Verzerrung dieser weiterhin gewährleistet
werden sollte.
Die Erkenntnisse, die mit der vorliegenden Arbeit gewonnen wurden, lassen
auf eine Eignung des konzipierten Werkzeugs bei der Anwendung in realen
Projekten schließen. Zur Verifizierung dieser Aussage wäre jedoch eine Nutzerstudie nötig, die zuvor eine vollständige Implementierung des Konzepts
erfordern würde. Interessant wäre außerdem die Beobachtung der Nutzung
über einen längeren Zeitraum hinweg sowie die Untersuchung, ob die Anwendung einen Einfluss auf die Projektarbeit und insbesondere die ProjektMeetings hätte und wenn ja, wie sich dieser Einfluss äußern würde.
106
ANHANG
107
Abowd, G.D.: „Classroom 2000: An Experiment with the Instrumentation of a Living
Educational Environment“. IBM systems journal, Vol. 38, Nr. 4, S.508–530. 1999.
Aggarwal, C.C. & Zhai, C.: Mining Text Data, Springer. 2012.
Aigner, W. et al.: Visualization of Time-Oriented Data, Springer Verlag London. 2011.
Banerjee, S.; Rose, C. & Rudnicky, A.I.: „The Necessity of a Meeting Recording and Playback
System , and the Benefit of Topic-Level Annotations to Meeting Browsing“. HumanComputer Interaction - INTERACT 2005, Vol. 3585, S.643–656. 2005.
Berry, M.W. & Kogan, J.: Text Mining: Applications and Theory, John Wiley & Sons Ltd. 2010.
Bertin, J.: Semiology of Graphics, University of Wisconsin Press, Madison. 1983.
Brandl, P.; Richter, C. & Haller, M.: „NiCEBook – Supporting Natural Note Taking“. In
Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. F.
Editorone & F. Editor2 (Hrsg.), ACM, Atlanta, Georgia, USA, S. 599–608. 2010.
Byron, L. & Wattenberg, M.: „Stacked graphs--geometry & aesthetics.“. IEEE transactions on
visualization and computer graphics, Vol. 14, Nr. 6, S.1245–52. 2008. URL
http://www.ncbi.nlm.nih.gov/pubmed/18988970.
Cameron, S. & Craig, C.: Understanding Informational Text Features: Instruction, Practice,
Assessment. M. Dieterich & S. M. Anderson (Hrsg.),, Marc Twain Media, Inc. 2013.
Cockburn, A.; Karlson, A. & Bederson, B.B.: „A review of overview+detail, zooming, and
focus+context interfaces“. ACM Computing Surveys, Vol. 41, Nr. 1, S.1–31. 2008. URL
http://portal.acm.org/citation.cfm?doid=1456650.1456652 (Aufgerufen January 23, 2014).
Cook, P. et al.: „Project Nick: Meetings Augmentation and Analysis“. ACM Transactions on
Office Information Systems (TOIS), Vol. 5, Nr. 2, S.132–146. 1987. URL
http://portal.acm.org/citation.cfm?doid=27636.27638.
Cui, W. et al.: „TextFlow: towards better understanding of evolving topics in text.“. IEEE
transactions on visualization and computer graphics, Vol. 17, Nr. 12, S.2412–2421. 2011.
URL http://www.ncbi.nlm.nih.gov/pubmed/22034362.
Dahlström, E. et al.: „Scalable Vector Graphics (SVG) 1.1 ( Second Edition )“. , Vol. 1, Nr.
February 2007. 2011.
110
Dailey, D.; Frost, J. & Strazzullo, D.: Building Web Applications with SVG, Microsoft Press.
2012.
Dewar, M.: Getting Started with D3, O’Reilly Media, Inc. 2012.
Feldman, R. & Sanger, J.: The Text Mining Handbook: Advanced Approaches in Analyzing
Unstructured Data, Cambridge University Press. 2007.
Gaussier, E. & Yvon, F.: Textual Information Access: Statistical Models, Wiley-ISTE. 2012. URL
http://slub.eblib.com/patron/FullRecord.aspx?p=1124642.
Geyer, W. et al.: „A Team Collaboration Space Supporting Capture and Access of Virtual
Meetings“. In Proceedings of the 2001 International ACM SIGGROUP Conference on
Supporting Group Work. ACM, Boulder, Colorado, USA, S. 188–196. 2001. URL
http://doi.acm.org/10.1145/500286.500315.
Geyer, W.; Richter, H. & Abowd, G.D.: „Towards a Smarter Meeting Record—Capture and
Access of Meetings Revisited“. Multimedia Tools and Applications, Vol. 27, Nr. 3, S.393–
410. 2005.
Gruber, T.R.: A Translation Approach to Portable Ontology Specifications, 1993.
Handford, M.: The Language of Business Meetings, Cambridge University Press. 2010.
Havre, S.; Hetzler, B. & Nowell, L.: „ThemeRiver: visualizing theme changes over time“. IEEE
Symposium on Information Visualization 2000. INFOVIS 2000. Proceedings, S.115–123.
2000. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=885098.
Henkel, S.L.: Successful Meetings: How to Plan, Prepare and Execute Top-Notch Business
Meetings, Atlantic Publishing Company, Ocala, Florida. 2007.
Ispas, A.; Signer, B. & Norrie, M.C.: „A Study of Incidental Notetaking to Inform Digital Pen and
Paper Solutions“. In Proceedings of the 24th BCS Interaction Specialist Group
Conference. British Computer Society, Dundee, United Kingdom, S. 374–383. 2010.
Jaimes, A. & Miyazaki, J.: „Building a Smart Meeting Room: From Infrastructure To the Video
Gap (Research and Open Issues)“. 21st International Conference on Data Engineering
Workshops
(ICDEW’05),
S.1173–1173.
2005.
URL
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1647779.
Jain, R.; Kim, P. & Li, Z.: „Experiential Meeting System“. In Proceedings of the 2003 ACM
SIGMM workshop on Experiential telepresence - ETP ’03. ACM Press, New York, New
York, USA, S. 1–12. 2003. URL http://portal.acm.org/citation.cfm?doid=982484.982486.
Jansen, E.: NetLingo. The Internet Dictionary, NetLingo Inc., Ojai, California. 2002.
Johnson, A.M.: Mobileessence: A Mobile Non-Invasive Platform for Meeting Notes Capture.
Massachusetts Institute of Technology. 2007.
LITERATURVERZEICHNIS
111
Johnson, E.R.: Academic Language! Academic Literacy! - A Guide for K-12 Educators, Corwin.
2009.
Kalnikaitė, V.; Ehlen, P. & Whittaker, S.: „Markup As You Talk: Establishing Effective Memory
Cues While Still Contributing to a Meeting“. In Proceedings of the ACM 2012 Conference
on Computer Supported Cooperative Work. ACM, New York, NY, USA, S. 349–358. 2012.
URL http://doi.acm.org/10.1145/2145204.2145260.
Khan, F.: A Survey of Note-Taking Practices, Hewlett-Packard Laboratories. 1993.
Klink, S.; Dengel, A. & Kieninger, T.: „Document Structure Analysis Based on Layout and
Textual Features“. In Proc. of International Workshop on Document Analysis Systems,
DAS2000. 2000.
Lalanne, D. et al.: „The IM2 Multimodal Meeting Browser Family“. Interactive Multimodal
Information Management Tech. Report, Margtiny, Switzerland. 2005.
Lipford, H.R. & Abowd, G.D.: „Reviewing Meetings in TeamSpace“. Human-Computer
Interaction, Vol. 23, Nr. 4, S.406–432. 2008.
Lisowska, A.: „Multimodal Interface Design for the Multimodal Meeting Domain: Preliminary
Indications from a Query Analysis Study“. Report IM2. MDM-11. 2003.
Lisowska, A.; Popescu-belis, A. & Armstrong, S.: „User Query Analysis for the Specification
and Evaluation of a Dialogue Processing and Retrieval System“. In Proceedings of the 4th
International Conference on Language Resources and Evaluation. S. 993–996. 2004.
Lisowska, A.; Rajman, M. & Bui, T.H.: „ARCHIVUS: A System for Accessing the Content of
Recorded Multimodal Meetings“. In Machine Learning for Multimodal Interaction. S.
Bengio & H. Bourlard (Hrsg.), Springer Berlin Heidelberg, S. 291–304. 2005. URL
http://dx.doi.org/10.1007/978-3-540-30568-2_25.
Luo, D. et al.: „EventRiver: visually exploring text collections with temporal references.“. IEEE
transactions on visualization and computer graphics, Vol. 18, Nr. 1, S.93–105. 2012. URL
http://www.ncbi.nlm.nih.gov/pubmed/22076487.
Mann, M.: Assoziationsanalyse - eine Einführung, Grin Verlag. 2013.
Mannering, K.: Make Meetings Work: Teach Yourself, Hodder Education. 2011.
Marchand-Maillet, S.: Meeting Record Modelling for Enhanced Browsing, Genf. 2003.
Marchionini, G.: „From finding to understanding“. Communications of the ACM, Vol. 49, Nr. 4,
S.41–46. 2006.
Medina, C.: Successful Strategies for Reading in the Content Areas 2nd ed., Shell Education.
2008.
Moore, C.D.: „The IDIAP Smart Meeting Room“. 2002.
112
Müller, W. & Schumann, H.: „Visualization Methods for Time Dependent Data - An Overview“.
In Proceedings of the 2003 Winter Simulation Conference. S. Chick et al. (Hrsg.), S. 737–
745. 2003.
Pallotta, V.; Seretan, V. & Ailomaa, M.: „User Requirements Analysis for Meeting Information
Retrieval Based on Query Elicitation“. In ANNUAL MEETING-ASSOCIATION FOR
COMPUTATIONAL LINGUISTICS. S. 1008–1015. 2007.
Perner, P.: Data Mining on Multimedia Data, Springer Verlag Berlin Heidelberg. 2002.
Plaue, C.M.: Exploring and Visualizing the Impact of Multiple Shared Displays on Collocated
Meeting Practices. Georgia Institute of Technology. 2009.
Popescu-Belis, A.; Lalanne, D. & Bourlard, H.: „Finding Information in Multimedia Meeting
Records“. Multimedia, IEEE, Vol. 19, Nr. 2, S.48–57. 2012.
Post, W.M.; Cremers, A.H.M. & Henkemans, O.B.: „A research environment for meeting
behavior“. In Proceedings of the 3rd workshop on social intelligence design. A. Nijholt &
T. Nishida (Hrsg.), S. 159–165. 2004.
Richter, H. et al.: „Integrating Meeting Capture within a Collaborative Team Environment“. In
Ubicomp 2001: Ubiquitous Computing. Springer, S. 123–138. 2001.
Riedl, A.: Grundlagen der Didaktik, Steiner (Franz). 2004.
Risch, J. et al.: „Text Visualization for Visual Text Analytics“. In Visual Data Mining: Theory,
Techniques and Tools for Visual Analytics. S. J. Simoff, M. H.Böhlen, & A. Mazeika
(Hrsg.), Springer Verlag Berlin Heidelberg, S. 154–171. 2008.
Romano, N.C. & Nunamaker, J.F.: „Meeting Analysis: Findings from Research and Practice“. In
Proceedings of the 34th Annual Hawaii International Conference on System Sciences.
IEEE. 2001.
Rose, S. et al.: „Describing story evolution from dynamic information streams“. 2009 IEEE
Symposium on Visual Analytics Science and Technology, S.99–106. 2009. URL
Shneiderman, B.: „The Eyes Have It: A Task by Data Type Taxonomy for Information
Visualizations“. In Proceedings 1996 IEEE Symposium on Visual Languages. IEEE
Comput.
Soc.
Press,
S.
336–343.
1996.
URL
Sriparasa, S.S.: JavaScript and JSON Essentials, Packt Publishing. 2013.
Teller, S.: Data Visualization with d3.js, Packt Publishing. 2013.
Tinnirello, P.C.: New Directions in Project Management, CRC Press. 2002.
LITERATURVERZEICHNIS
113
Tucker, S. & Whittaker, S.: „Reviewing Multimedia Meeting Records: Current Approaches“. In
Proceedings of the 2005 (ICMI) International Workshop on Multimodal Multiparty Meeting
Processing. S. 33–38. 2005.
Viégas, F.B. & Smith, M.: „Newsgroup Crowds and Author Lines: Visualizing the Activity of
Individuals in Conversational Cyberspaces“. In Proceedings of the 37th Hawaii
International Conference on System Sciences. S. 1–10. 2004.
Viégas, F.B. & Wattenberg, M.: „TIMELINES: Tag Clouds and the Case for Vernacular
Visualization“.
interactions,
Vol.
15,
Nr.
4,
S.49–52.
2008.
URL
http://doi.acm.org/10.1145/1374489.1374501.
Ware, C.: Information Visualization: Perception for Design 2nd ed., Elsevier Inc. 2004.
Whittaker, S. et al.: „Design and evaluation of systems to support interaction capture and
retrieval“. Personal and Ubiquitous Computing, Vol. 12, Nr. 3, S.197–221. 2007. URL
http://link.springer.com/10.1007/s00779-007-0146-3 (Aufgerufen April 26, 2013).
Whittaker, S.; Hyland, P. & Wiley, M.: „FILOCHAT: Handwritten Notes Provide Access to
Recorded Conversations“. In Proceedings of the SIGCHI Conference on Human Factors in
Computing Systems Celebrating Interdependence - CHI ’94. ACM Press, S. 271–277.
1994.
Whittaker, S.; Laban, R. & Tucker, S.: „Analysing Meeting Records: An Ethnographic Study and
Technological Implications“. In Machine Learning for Multimodal Interaction. S. Renals &
S. Bengio (Hrsg.), Springer Verlag, Berlin, S. 103–113. 2006.
Whittaker, S.; Tucker, S. & Lalanne, D.: „Meeting browsers and meeting assistants“. In
Multimodal Signal Processing: Human Interactions in Meetings. S. Renals et al. (Hrsg.),
Cambridge University Press, S. 204–217. 2012.
Wilcox, L.D.; Schilit, B.N. & Sawhney, N.N.: „Dynomite: A Dynamically Organized Ink and Audio
Notebook“. In Proceedings of the ACM SIGCHI Conference on Human Factors in
Computing Systems. ACM, Atlanta, Georgia, USA, S. 186–193. 1997. URL
http://doi.acm.org/10.1145/258549.258700.
Wytrzens, H.K.: Projektmanagement: Der erfolgreiche Einstieg 2nd ed., Facultas Verlags- und
Buchhandels AG, Wien. 2010.
Yu, S. & Selker, T.: „Who Said What When? Capturing the Important Moments of a Meeting“.
In CHI ’10 Extended Abstracts on Human Factors in Computing Systems. ACM, Atlanta,
Georgia, USA, S. 1–6. 2010.
Yu, Z. & Nakamura, Y.: „Smart meeting systems: A Survey of the State-of-the-Art and Open
Issues“. ACM Computing Surveys, Vol. 42, Nr. 2, S.1–20. 2010. URL
http://portal.acm.org/citation.cfm?doid=1667062.1667065 (Aufgerufen April 4, 2013).
[@D3]
Bostock, M.: „D3 - Data-Driven Documents“.
[@D3_drag]
Bostock,
M.:
„Drag
Behavior“.
https://github.com/mbostock/d3/wiki/Drag-Behavior (Aufgerufen February 12, 2014).
URL
[@D3_selection]
Bostock,
M.:
„Selections“.
https://github.com/mbostock/d3/wiki/Selections (Aufgerufen February 12, 2014).
URL
[@D3_timescales]
Bostock,
M.:
„Time
Scales“.
GitHub
Wiki.
https://github.com/mbostock/d3/wiki/Time-Scales (Aufgerufen February 12, 2014).
URL
[@Corum et al.] Corum, J. & Hossain, F.: „Naming Names“. The New York Times. URL
http://www.nytimes.com/interactive/2007/12/15/us/politics/DEBATE.html (Aufgerufen January
29, 2014).
[@Feinberg]
January 29, 2014).
Feinberg, J.: „Wordle“. 2013. URL http://www.wordle.net/ (Aufgerufen
[@Vizamp]
Vizamp:
„Vizamp“.
URL
dresden.de/forschung/projekte/vizamp-0 (Aufgerufen November 22, 2013).
[@W3C_text]
W3C:
„Chapter
http://www.w3.org/TR/SVG2/text.html#TextLayoutAuto.
10:
http://mg.inf.tu-
Text.“.
URL
[@W3C_standards]
W3C:
„HTML
Current
Status“.
2014.
http://www.w3.org/standards/techs/html#w3c_all (Aufgerufen February 12, 2014).
URL
[@W3C_svg2] W3C: „Scalable Vector Graphics (SVG) 2. W3C Working Draft 11 February
2014“. URL http://www.w3.org/TR/2014/WD-SVG2-20140211/.
[@W3C_render]
W3C: „SVG Rendering Order 1.0, Part 2: Language“. URL
http://dev.w3.org/SVG/modules/renderorder/SVGRenderOrder.html (Aufgerufen February 12,
2014).
[@W3schools_bezier] W3schools: „HTML canvas bezierCurveTo() Method“. URL
http://www.w3schools.com/TAGs/canvas_beziercurveto.asp (Aufgerufen February 12, 2014).
[@W3Schools_svg]
W3Schools: „HTML5 Inline SVG“. Refsnes Data.
http://www.w3schools.com/html/html5_svg.asp (Aufgerufen February 12, 1014).
2014.
URL
Abbildung 2.1: Klassifikation von Meetings und Meeting-Arten in der Übersicht ........................ 8
Abbildung 2.2: Aufbau eines Smart Meeting Systems, Quelle: [Z. Yu et al. 10] ........................ 10
Abbildung 2.3: Einordnung der verschiedenen Arten von Meeting-Aufzeichnungen ................. 10
Abbildung 2.4: Übersicht zum Informationsabruf mittels Meeting-Aufzeichnungen .................. 12
Abbildung 2.5: Phasen der Informationsverarbeitung im Meeting-Zyklus frei nach [Cook et al.
87] ................................................................................................................................................ 13
Abbildung 2.6: Komponenten eines Text Mining Systems mit Einordnung der
Präsentationsschicht, Quelle: [Feldman et al. 07], S. 192 ........................................................... 14
Abbildung 2.7: Ausprägungen von Konzeptgraphen ................................................................... 16
Abbildung 2.8: Histogramm ......................................................................................................... 16
Abbildung 2.9: Liniendiagramm ................................................................................................... 16
Abbildung 2.10: Author Lines Visualisierung, Quelle: [Viégas et al. 04] ..................................... 17
Abbildung 2.11: Circle Graph ....................................................................................................... 17
Abbildung 2.12: Naming Names - Visualisierung der gegenseitigen Nennung von US-Politikern,
Quelle: [@Corum et al.] ................................................................................................................ 18
Abbildung 2.13: Tag Cloud der vorliegenden Arbeit, erstellt mit wordle.net [@Feinberg] .......... 19
Abbildung 2.14: Tag Clouds zum Vergleich zweier Themen, Quelle: [Cui et al. 11] ................... 19
Abbildung 2.15: Stacked Bar Chart.............................................................................................. 20
Abbildung 2.16: Visualisierung zeitbasierter Daten mittels Stacked Graph (unten), ThemeRiver
(Mitte) und Streamgraph (oben), Quelle: [Aigner et al. 11], S. 199 ............................................. 20
Abbildung 2.17: Modell der Dokumentstruktur ........................................................................... 21
Abbildung 3.1: TeamSpace Anwendungsoberfläche, Quelle: [Richter et al. 01] ........................ 26
Abbildung 3.2: MeetingViewer in Single-Meeting-Ansicht, Quelle: [Richter et al. 01] ................ 27
Abbildung 3.3: ARCHIVUS Anwendungsoberfläche, Quelle: [Lisowska et al. 05] ...................... 29
Abbildung 3.4: Repräsentation des Meeting-Inhalts in einem „Buch“, Quelle: [Lisowska et al.
05] ................................................................................................................................................ 30
Abbildung 3.5: Story Flow Visualisierung, Quelle: [Rose et al. 09] ............................................. 31
118
Abbildung 3.6: Story Flow Visualisierung über einen Zeitraum von zwei Wochen, Quelle: (Rose
et al. 2009) ................................................................................................................................... 31
Abbildung 3.7: Ereignisblase, nach [Luo et al. 12] ....................................................................... 32
Abbildung 3.8: EventRiver einer Nachrichtensammlung, Quelle: [Luo et al. 12] ........................ 33
Abbildung 3.9: Ereignis-Beschriftungen, Quelle: [Luo et al. 12] .................................................. 33
Abbildung 3.10: Detailansicht der Inhalte .................................................................................... 34
Abbildung 4.1: Vorgehen Anwendungsfall 1 – einzelne Aufzeichnungen (li.) und Meetingübergreifende Darstellung (re.).................................................................................................... 39
Abbildung 4.2: Vorgehen Anwendungsfall 2 - einzelne Aufzeichnungen (li.) und Meetingübergreifende Darstellung (re.).................................................................................................... 40
Abbildung 4.3: Vorgehen Anwendungsfall 3 - einzelne Aufzeichnungen (li.) und Meetingübergreifende Darstellung (re.).................................................................................................... 40
Abbildung 4.4: Einordnung und Abgrenzung des Konzepts ........................................................ 42
Abbildung 4.5: Meeting-Struktur ................................................................................................. 45
Abbildung 4.6: Relationen zwischen Meeting-Inhalten ............................................................... 46
Abbildung 4.7: Ausschnitt Story Flow, Quelle: [Rose et al. 09] .................................................. 50
Abbildung 4.8: Ausschnitt EventRiver, Quelle: [Luo et al. 12] .................................................... 50
Abbildung 4.9: TeamSpace Zeitleiste, Quelle: [Richter et al. 01] ................................................ 51
Abbildung 4.10: EventRiver Zeit-Zoom, Quelle: [Luo et al. 12] ................................................... 51
Abbildung 4.11: ARCHIVUS Filterfunktionen .............................................................................. 52
Abbildung 5.1: Auflösen der Dokumentgrenzen ......................................................................... 59
Abbildung 5.2: Hierarchische Gliederung der Meeting-Elemente ............................................... 60
Abbildung 5.3: Globale und lokale Zeitachsen ............................................................................. 60
Abbildung 5.4: Beispielhafte Abbildung der Informationsstruktur .............................................. 60
Abbildung 5.5: Vergleich zeitlicher Abstände zwischen Meeting-Daten auf kontinuierlicher
Zeitachse ..................................................................................................................................... 61
Abbildung 5.6: Abbildung der Entität Inhalt mit Vergleich der Textlänge .................................... 62
Abbildung 5.7: Farbkodierung der Inhaltskategorien ................................................................... 62
Abbildung 5.8: Datenrepräsentation im Überblick ....................................................................... 62
Abbildung 5.9: Visualisierung von R1 Thema – Meeting ............................................................. 62
Abbildung 5.10: Abbildung der Relationen R3, R4 und R5 .......................................................... 63
Abbildung 5.11: Färbung der Relationsenden ............................................................................. 63
Abbildung 5.12: Relation zwischen Aufgabe und Gesprächspunkt ............................................. 63
ABBILDUNGSVERZEICHNIS
119
Abbildung 5.13: Visualisierungskonzept in der Übersicht ........................................................... 64
Abbildung 5.14: Anwendungsoberfläche .................................................................................... 67
Abbildung 5.15: Herauszoomen durch Erweiterung des Zeitbereichs ........................................ 68
Abbildung 5.16: Verschieben des Zeitausschnitts hin zu älteren Daten ..................................... 68
Abbildung 5.17: Ansicht nach Ausführen der Suchfunktion mit dem Begriff „Beispiel“ ............ 69
Abbildung 5.18: Filterfunktion angewendet auf Aufgaben und Beschlüsse ............................... 69
Abbildung 5.19. Themenfilter ...................................................................................................... 70
Abbildung 5.20: Funktions-buttons der Browser-Leiste .............................................................. 70
Abbildung 5.21: Verlaufsanzeige ................................................................................................. 70
Abbildung 5.22: Detailansicht Meeting (1), Thema (2) und Inhalt (3) .......................................... 71
Abbildung 6.1: Grundlegende SVGShapes und Attribute: SVGCircle-, SVGRect- und
SVGLineElement ......................................................................................................................... 84
Abbildung 6.2: Komponenten der Anwendung ........................................................................... 87
Abbildung 6.3: Berechnung der Breite der time_bar ................................................................... 89
Abbildung 6.4: Darstellung der Zeitleiste und der Zeitachse mit Meeting-Daten ....................... 89
Abbildung 6.5: Schema zur Berechnung der y-Positionen. Hervorgehobene y-Werte werden in
t_yposs gespeichert. ................................................................................................................... 90
Abbildung 6.6: Zeichnen der Fortführungsrelation ...................................................................... 91
Abbildung 6.7: Implementierung der grafischen Benutzeroberfläche, Ausschnitt (Screenshot) 92
Abbildung 6.8: Detailansicht eines Inhalts zum Thema Vizamp, Screenshot.............................. 94
Abbildung A.7.1: Beispiel eines informellen Meeting-Protokolls, Quelle: [Mannering 11] ....... 105
Abbildung A.7.2: Beispiel eines formalen Meeting-Protokolls, Quelle: [Mannering 11] ........... 106
Abbildung A.7.3: Stanley Milgrams Mentale Karte der Sehenswürdigkeiten in Paris, Quelle:
[Viégas et al. 08] ........................................................................................................................ 107
Tabelle 2.1: Meeting-Arten geordnet nach der Zeit/Ort-Dimension .............................................. 6
Tabelle 2.2: Eigenschaften strukturierter und unstrukturierter Meeting-Arten, nach [Mannering
11] .................................................................................................................................................. 8
Tabelle 4.1: Inhaltskategorien und ihr Vorkommen in den Studienergebnissen ......................... 44
Tabelle 4.2: Relationen zwischen Meeting-Elementen nach [Marchand-Maillet 03] und
[Lisowska 03]............................................................................................................................... 45
Tabelle 4.3: Datenrepräsentation EventRiver und Story Flow .................................................... 49
Tabelle 4.4: Analyse der Relationsvisualisierung von EventRiver und Story Flow ..................... 49
Tabelle 4.5: Abschließende Bewertung der verwandten Arbeiten ............................................. 53
Quellcode 6.1: Datenstruktur der Entitäten in JSON-Format ...................................................... 86
Quellcode 6.2: Beispiel eines Relationsobjekts .......................................................................... 86
Quellcode 6.3: Generierung und Zeichnen der globalen Zeitachse mit d3.time.scale().............. 88
Quellcode 6.4: Zeichnen der SVGCircleElements zur Abbildung der Meeting-Daten auf der
Zeitachse ..................................................................................................................................... 89
Quellcode 6.5: Filterfunktion zum Zeichnen der Relationsenden ............................................... 91
Quellcode 6.6: Neuberechnung der Zeitachse ............................................................................ 93
Quellcode 6.7: Verschieben der Visualisierungselemente abhängig von der Stauchung oder
Streckung der Zeitachse .............................................................................................................. 93
Quellcode 6.8: Zuweisen des Eventhandlers .............................................................................. 94
Quellcode 6.9: Aufruf der Detailansicht ...................................................................................... 94
Quellcode 6.10: Implementierung der view_meeting() Funktion zur Detailansicht eines
gesamten Meetings .................................................................................................................... 95
Quellcode 6.11: Auswerten der ausgewählten Relation, Schritt 1 ............................................. 96
Quellcode 6.12: Update der Visualisierung ................................................................................. 97

PDF der Diplomarbeit - Professur Mediengestaltung

Transcription

Similar documents

Unterlagen in einem PDF - Fakultät für Mathematik

Artikel, pdf - Ein Literarischer Atlas Europas

Empfehlungsschreiben der DVGW

Mindjet® MindManager® 6

Konstruktiver Umgang mit Konflikten

- transversal texts

Einführung in Präventives Konfliktmanagement

Crowdsourcing Plattform