Alternative Visualisierung von Chat-Beiträgen zur ... Paper... · Chat (von engl. to chat...

FernUniversität in HagenFakultät für Mathematik und Informatik

Alternative Visualisierung von Chat-Beiträgen

zur Verringerung des Co-Text-Verlustes

als Bachelorarbeitvorgelegt von

Verena Kunzxxxxxxxxxxxxxxxxxxxxxxxxxxx

angefertigt an derJuniorprofessur für

- Verteilte Systeme für kooperative Arbeits- / Lernumgebungen -der FernUniversität in Hagen

Betreuer:Prof. Dr. Stephan Lukosch

- Juni 2007 -

II

Hiermit versichere ich, dass ich diese Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlich gemacht habe. Alle zitierten Internetseiten waren zum Zeitpunkt derAbgabe dieser Arbeit erreichbar.

Karlsruhe, den 28.06.2007 Verena Kunz

III

Danksagung

An dieser Stelle möchte ich ich bei allen bedanken, die zum Gelingen dieserAbschlussarbeit beigetragen haben, insbesondere

Herrn Prof. Dr. Stephan Lukosch und Herrn Dipl.-Psych. Torsten Hol-mer für das interessante Thema dieser Arbeit sowie für viele wertvolleHinweise und Ideen

sowie

(...)

Inhaltsverzeichnis IV

Inhaltsverzeichnis1 Einleitung............................................................................................................................12 Inhaltsübersicht...................................................................................................................33 Analyse der Aufgabenstellung.............................................................................................4

3.1 Standard-Chat-Programme..........................................................................................43.2 Beschreibung der Schwächen......................................................................................4

3.2.1 Mangel an Bezug zwischen Personen und deren Nachrichten............................53.2.2 Keine Sichtbarkeit des Zuhörers..........................................................................53.2.3 Kein wahrnehmbarer Antwortprozess..................................................................63.2.4 Mangel an Kontrolle über die Positionierung der Nachrichten (Co-Text-Verlust).......................................................................................................................................73.2.5 Mangel an brauchbaren Aufzeichnungen.............................................................83.2.6 Weitere Probleme bei der Chat-Kommunikation.................................................8

3.3 Anforderungen an das zu entwickelte Chat-System....................................................94 Verwandte Arbeiten...........................................................................................................11

4.1 Klassifizierung von Chat-Systemen...........................................................................114.1.1 Internet Relay Chat............................................................................................114.1.2 Web-Chat............................................................................................................114.1.3 Instant Messaging..............................................................................................124.1.4 Mehrbenutzer-Online-Rollenspiele und Virtuelle Welten..................................12

4.2 Generelle Lösungsansätze.........................................................................................124.2.1 Mangel an Bezug zwischen Personen und deren Nachrichten..........................124.2.2 Keine Sichtbarkeit des Zuhörers........................................................................134.2.3 Kein wahrnehmbarer Antwortprozess................................................................144.2.4 Mangel an Kontrolle über die Positionierung der Nachrichten (Co-Text-Verlust).....................................................................................................................................154.2.5 Mangel an brauchbaren Aufzeichnungen...........................................................15

4.3 Spezielle Chat-Systeme.............................................................................................164.3.1 Status Client.......................................................................................................164.3.2 Flow Client.........................................................................................................174.3.3 Fugue..................................................................................................................174.3.4 Chat Circles........................................................................................................184.3.5 Babble................................................................................................................194.3.6 HyperDialog und Mediated Chat.......................................................................204.3.7 Threaded Chat....................................................................................................234.3.8 ConcertChat.......................................................................................................244.3.9 factchat...............................................................................................................254.3.10 ThreadChat.......................................................................................................264.3.11 MMChat...........................................................................................................274.3.12 Nutzung von synchronen Mehrbenutzereditoren als Chat-System..................28

4.4 Übersicht ...................................................................................................................294.5 Konsequenzen hinsichtlich des zu entwickelnden Systems......................................29

5 Beschreibung der Lösungsidee..........................................................................................315.1 Referenzierung von anderen Beiträgen.....................................................................315.2 Nutzung von Baumstrukturen zur Visualisierung......................................................32

5.2.1 Möglichkeiten der Visualisierung von Bäumen.................................................325.2.2 Anforderungen an die Baumdarstellungen.........................................................335.2.3 Berücksichtigung des Faktors Zeit.....................................................................34

5.3 Analyse der Anforderungen.......................................................................................345.3.1 Akteure...............................................................................................................35

Inhaltsverzeichnis V

5.3.2 Anwendungsfälle................................................................................................355.3.3 Domänen-Klassenmodell...................................................................................375.3.4 Benutzeroberfläche............................................................................................38

5.3.4.1 Hauptfenster...............................................................................................385.3.4.2 Dialoge.......................................................................................................395.3.4.3 Chat-Fenster...............................................................................................41

5.4 Visualisierungsalternativen........................................................................................425.4.1 Klassische Visualisierung..................................................................................425.4.2 Listenansicht mit Hervorhebung........................................................................425.4.3 Baumansichten...................................................................................................43

5.4.3.1 Einfache Baumdarstellung ........................................................................445.4.3.2 Baumdarstellung mit Visualisierung der Zeit durch hellere Farben...........455.4.3.3 Baumdarstellung mit Visualisierung der Zeit durch das Layout................465.4.3.4 Sequenzielle Baumdarstellung...................................................................46

6 Beschreibung der Implementierung..................................................................................486.1 Eingesetzte Technologien..........................................................................................48

6.1.1 Systemarchitektur..............................................................................................486.1.2 Jabber.................................................................................................................496.1.3 Progammiersprache............................................................................................516.1.4 Verwendete Programmbibliotheken...................................................................526.1.5 Smack.................................................................................................................526.1.6 prefuse................................................................................................................52

6.2 Lösung bestimmter Problemfelder............................................................................536.2.1 Zeit.....................................................................................................................536.2.2 Eindeutige Identifikation der Beiträge für die Referenzierung..........................536.2.3 Nutzer mit anderen Clients im gleichen Raum..................................................54

6.3 Paketstruktur..............................................................................................................566.3.1 Netzwerkkommunikation...................................................................................566.3.2 Anwendungslogik..............................................................................................586.3.3 Graphische Benutzeroberfläche.........................................................................60

6.3.3.1 Hauptfenster und Dialoge...........................................................................616.3.3.2 Bestandteile des Chat-Fensters...................................................................616.3.3.3 Visualisierungseigenschaften.....................................................................626.3.3.4 Plugin-Konzept für Visualisierungen.........................................................626.3.3.5 Basiskomponenten für die Visualisierung mit prefuse...............................636.3.3.6 Aktualisierung der Visualisierungen beim Eintreffen neuer Nachrichten..646.3.3.7 Visualisierungs-Plugins..............................................................................66

6.4 Deployment und Nutzung von MuVi-Chat................................................................676.5 Ergänzung um weitere Visualisierungen...................................................................67

7 Zusammenfassung und Ausblick.......................................................................................698 Literaturverzeichnis...........................................................................................................71

Inhaltsverzeichnis VI

AbbildungsverzeichnisAbbildung 1: Benutzeroberfläche eines Standard-Chats........................................................4Abbildung 2: Mögliche Reaktionen auf Co-Text-Verlust [PFdL03] .....................................7Abbildung 3: Chat-System Flow Client...............................................................................17Abbildung 4: Chat-System Fugue........................................................................................18Abbildung 5: Chat-System Chat Circles..............................................................................19Abbildung 6: Chat-System Babble.......................................................................................20Abbildung 7: Funktionen von Mediated Chat und HyperDialog.........................................20Abbildung 8: Chat-System HyperDialog.............................................................................21Abbildung 9: Chat-System Mediated Chat 6.0....................................................................23Abbildung 10: Chat-System Threaded Chat.........................................................................24Abbildung 11: Chat-System Concert-Chat...........................................................................25Abbildung 12: Chat-System factchat...................................................................................26Abbildung 13: Chat-System Thread Chat............................................................................26Abbildung 14: Chat-System MMChat.................................................................................27Abbildung 15: Visualisierungen für Baumstrukturen...........................................................32Abbildung 16: Anwendungsfalldiagramm...........................................................................36Abbildung 17: Domänen-Klassendiagramm........................................................................38Abbildung 18: Hauptfenster des MuVi-Chat........................................................................39Abbildung 19: Menüpunkte im Hauptfenster des MuVi-Chat.............................................39Abbildung 20: Dialogfenster Verbindungseinstellungen......................................................40Abbildung 21: Dialogfenster Chat-Raum-Einstellungen.....................................................40Abbildung 22: Varianten des Chat-Fensters.........................................................................41Abbildung 23: Replay-Steuerung.........................................................................................42Abbildung 24: Benutzeroberfläche der Listenansicht mit Hervorhebung............................43Abbildung 25: Benutzeroberfläche der einfachen Baumdarstellung...................................44Abbildung 26: Benutzeroberfläche der Baumdarstellung mit Visualisierung der Zeit durchhellere Farben.......................................................................................................................45Abbildung 27: Benutzeroberfläche der Baumdarstellung mit Visualisierung der Zeit durchdas Layout............................................................................................................................46Abbildung 28: Sequenzielle Baumdarstellung.....................................................................47Abbildung 29: Darstellung von Benutzern anderer Client-Software...................................55Abbildung 30: Drei-Schichten-Architektur..........................................................................56Abbildung 31: Beobachter-Entwurfsmuster zwischen Netzwerkkommunikation und An-wendungslogik......................................................................................................................57Abbildung 32: Klassendiagramm applicationLogicP...........................................................58Abbildung 33: Übersicht über das Paket guiComponentsP.................................................60Abbildung 34: Klassendiagramm Chat-Fenster...................................................................61Abbildung 35: Klassendiagramm Aktualisierung der GUI..................................................65

TabellenverzeichnisTabelle 1: Verfügbarkeitsstati in Jabber...............................................................................14Tabelle 2: Übersicht über die von den Chat-Systemen behandelten Problemfelder............29Tabelle 3: Typische Einsatzbereiche bestimmter Baumvisualisierungen.............................33

Einleitung 1

1 EinleitungChat (von engl. to chat „plaudern, unterhalten“) bezeichnet elektronische Kommunikationzwischen Personen in Echtzeit, meist über das Internet (vgl. [Wikipedia07a]). Die erstenMöglichkeiten einer elektronischen Echtzeit-Kommunikation bot das Programm talk be-reits in den 70er Jahren (vgl. [Wikipedia07b]).

Die Idee eines Chat-Netzwerkes entstand im BITNET, einem Rechnernetz von Großrech-nern unter dem Namen Relay Chat. Dieses System wurde vom finnischen Studenten Jark-ko Oikarinen 1988 auf das Internet übertragen (vgl. [Wikipedia07c]). Damit entstand dieInternetanwendung Internet Relay Chat (IRC) bereits vor dem World Wide Web (WWW),das 1989 von Tim Berners-Lee am CERN in Genf entwickelt wurde. Zwischenzeitlichwird auch das WWW häufig als Basistechnologie für Chat-Kommunikation verwendet.

Mit der Verbreitung des Internet hat auch Chat als Kommunikationsmedium einen hohenVerbreitungsgrad erlangt. So zeigen Statistiken über die IRC-Nutzung unter http://irc.-netsplit.de bei den meisten Netzen bis zum Jahr 2005 eine kontinuierliche Steigerung derNutzerzahlen. Seit 2005 ist eine Stagnation eingetreten bzw. teilweise sogar ein leichterRückgang der Nutzerzahlen zu verzeichnen.

Nachdem Chat zunächst vorwiegend im Bereich der Freizeit-Kommunikation sowie zumfachlichen Austausch insbesondere zu Computerthemen genutzt wurde, bildeten sich imLaufe der Zeit weitere Einsatzbereiche heraus. Heutzutage gibt es Chats zu allen erdenkli-chen Themen. Das Medium Chat ist zwischenzeitlich auch im beruflichen Umfeld, zumBeispiel im Bereich der Unternehmenskommunikation oder bei virtuellen Projektgruppen-sitzungen sowie in der Aus- und Weiterbildung (E-Learning) zu finden. Ein weiterer Ein-satzbereich ist die Online-Beratung, vor allem im psycho-sozialen Bereich. Daneben gibtes noch die meist moderierten Politiker- und Prominenten-Chats bzw. Chats als öffentlicherRückkanal zu Rundfunk und Fernsehen [Sto01a].

Als ein Medium synchroner computervermittelter Kommunikation ist Chat Gegenstand desinterdisziplinären Forschungsfeldes der computergestützten Gruppenarbeit (Computer Sup-ported Cooperative Work, CSCW) sowie des computergestützten kooperativen Lernens(Computer Supported Cooperative Learning, CSCL).

Die Chat-Kommunikation ist also nicht nur ein Thema der Informatik sondern auch ver-schiedener Sozialwissenschaften. Dabei sind insbesondere die Medien- und Kommunikati-onswissenschaft sowie die Sprachwissenschaft (Linguistik) zu erwähnen.

So gibt es mehrere Untersuchungen, die sich mit den sprachlichen Besonderheiten derChat-Kommunikation und der besonderen Stellung der Chat-Kommunikation zwischenSchriftlichkeit und Mündlichkeit beschäftigen (vgl. z. B. [Sto01b], [Bei00]).

Die Vorteile der Chat-Kommunikation sind vielschichtig: So ist Chat eine ortsunabhängigeund kostengünstige Kommunikationsform. Anders als bei der Face-to-Face-Kommunikati-on ist es beim Chat nicht unhöflich, sich gleichzeitig noch mit anderen Dingen zu beschäf-tigen. Auch eine gleichzeitige Teilnahme an mehreren Unterhaltungen ist möglich. Zudemmachen die Möglichkeiten des humorvollen Austauschs und der spielerische Umgang mitder Sprache für viele Benutzer den Reiz der Kommunikationsform Chat aus. Zudem hatman bei der Chat-Kommunikation die Möglichkeit, frühere Aussagen nochmals nachzule-sen (vgl. Herring [Her99]).

Die Chat-Kommunikation hat aber auch einige Nachteile. So listen Smith et al. [SCB00]fünf wesentliche Schwächen der Chat-Kommunikation auf:

● Mangel an Bezug zwischen Personen und deren Nachrichten

http://irc.netsplit.de/

http://irc.netsplit.de/

Einleitung 2

● keine Sichtbarkeit des Zuhörers

● kein wahrnehmbarer Antwortprozess

● Mangel an Kontrolle über die Positionierung der Nachrichten (Co-Text-Verlust)

● Mangel an brauchbaren Aufzeichnungen

In welchem Umfang diese Schwächen auftreten hängt maßgeblich von den Eigenschaftenund dem Funktionsumfang der jeweils eingesetzten Software ab.

In dieser Arbeit sollen zum einen aktuelle Chat-Systeme daraufhin untersucht werden, obund wenn ja wie sie die oben aufgeführten Probleme lösen. In einem zweiten Schritt solldann z. B. auf Basis des Jabber Messaging-Protokolls (http://www.jabber.org) bzw. desExtensible Messaging and Presence Protocol (XMPP) (http://www.xmpp.org) ein Chat-System entwickelt werden, das alternative Visualisierungen von Chat-Beiträgen zur Verfü-gung stellt. Dadurch soll im speziellen das Problem des Co-Text-Verlusts angegangen wer-den.

Da das System mehrere Visualisierungen bereitstellen soll, werden wir es MuVi-Chat(multiple visualization chat) nennen.

http://www.xmpp.org/

http://www.jabber.org/

Inhaltsübersicht 3

2 InhaltsübersichtIn Kapitel 3 werden wir zunächst die Aufgabenstellung analysieren und beschreiben, wasgenau die Probleme der Chat-Kommunikation sind und wodurch diese verursacht werden.Neben eigener Erfahrungen bei der Nutzung von Chat-Systemen werden wir dabei Er-kenntnisse aus wissenschaftlichen Untersuchungen zum Einsatz der Chat-Technologie inunterschiedlichen Anwendungsbereichen berücksichtigen. Aus den Ergebnissen dieserAnalyse erstellen wir eine Liste von Anforderungen an das zu erstellende Chat-System.

Kapitel 4 zeigt, wie aktuelle Chat-Systeme die Probleme lösen. Dazu verschaffen wir unszunächst einen Überblick über die aktuell eingesetzten Chat-Programme und -Technologi-en. Danach zeigen wir, welche generellen Lösungsansätze denkbar sind und beschreiben,welche Lösungsideen in aktuellen Chat-Systemen umgesetzt sind. Dabei betrachten wir,neben Chat-Systemen mit hohem Verbreitungsgrad, auch Systeme, die im Rahmen wissen-schaftlicher Forschungsarbeiten entstanden sind. Nach einem tabellarischen Überblickdarüber, welches System sich um welchen Problembereich kümmert, überlegen wir, wel-che Konsequenzen wir aus dem aktuellen Stand der Forschung hinsichtlich des von uns zuentwickelnden System ziehen können.

In Kapitel 5 konkretisieren wir die Anforderungen an das zu entwickelnde Chat-System.Zunächst widmen wir uns der Frage, welche Möglichkeiten der Referenzierung dem Be-nutzer zur Verfügung gestellt werden sollen, und welche Auswirkung dies auf die demChat-Verlauf zugrunde liegende Datenstruktur hat. Anschließend zeigen wir auf, welcheMöglichkeiten es zur Visualisierung von Baumstrukturen gibt und welche für das zu entwi-ckelnde Chat-System am besten geeignet sind. Aus den konkretisierten Anforderungen for-mulieren wir die Anwendungsfälle und stellen die Zusammenhänge des Problembereichs ineinem Domänen-Klassenmodell dar. Weiter beschreiben wir in diesem Kapitel die Benut-zeroberfläche inklusive der verschiedenen Visualisierungen, die dem Benutzer zur Verfü-gung stehen sollen.

Kapitel 6 schildert die Implementierung von MuVi-Chat in der Programmiersprache Java.Dabei stellen wir zunächst die gewählte Software-Architektur dar und beschreiben das fürdie Chat-Kommunikation zum Einsatz kommende Jabber-Protokoll sowie die bei der Im-plementierung verwendeten Programmbibliotheken Smack und prefuse. Die einzelnen Pro-grammbestandteile werden dann anhand der Paketstruktur erläutert.

Kapitel 7 fasst die Ergebnisse der Arbeit zusammen und zeigt Möglichkeiten zur Verbesse-rung und Weiterentwicklung von MuVi-Chat auf.

Analyse der Aufgabenstellung 4

3 Analyse der Aufgabenstellung

3.1 Standard-Chat-ProgrammeEin Großteil der heute verbreiteten Chat-Programme sind in ihrem Basis-Funktionsumfangsowie in ihrer Benutzerschnittstelle relativ ähnlich. In der Minimalausstattung verfügen Sieüber folgende Funktionen:

(M1) Auswahl eines Benutzernamens (sog. Nickname) unter dem eigene Nach-richten erscheinen

(M2) Möglichkeit der Eingabe von Textnachrichten in einem Texteingabefeld

(M3) Übermittlung eingegebener Textnachrichten an alle Teilnehmer

(M4) Anzeige von eingehenden Textnachrichten in chronologischer Reihenfolge

(M5) Anzeige einer Liste der Chat-Teilnehmer

Die Benutzerschnittstelle ist meist so organisiert, dass eingehende Textnachrichten obenlinks erscheinen. Die Teilnehmerliste wird oben rechts angezeigt und das Eingabefeld fürneue Textnachrichten befindet sich unten. Folgende Abbildung zeigt diese verbreitete An-ordnung der Bedienelemente.

Da die Chat-Nachrichten in ihrer zeitlichen Abfolge aufgelistet werden, bezeichnen Har-noncourt et al. [HHSM05] diese Chat-Form auch als seriellen Chat.

3.2 Beschreibung der SchwächenDie am häufigsten genutzten Chat-Programme weisen nur wenig mehr, als den oben be-schriebenen Standardfunktionsumfang auf. Aufgrund des hohen Verbreitungsgrads könnteman daraus schließen, dass dieser Funktionsumfang im wesentlichen die Anforderungender Benutzer an ein Chat-System erfüllt. Chat-Programme in der geschilderten Mini-

Abbildung 1: Benutzeroberfläche eines Standard-Chats


malausstattung haben trotzdem einige Nachteile: Smith et al. [SCB00] zeigen die folgen-den fünf Schwächen auf:

(P1) Mangel an Bezug zwischen Personen und deren Nachrichten

(P2) keine Sichtbarkeit des Zuhörers

(P3) kein wahrnehmbarer Antwortprozess

(P4) Mangel an Kontrolle über die Positionierung der Nachrichten (Co-Text-Verlust)

(P5) Mangel an brauchbaren Aufzeichnungen

Wir werden nachfolgend diese fünf Schwächen näher beschreiben und noch weitere Pro-bleme der Chat-Kommunikation aufzeigen.

3.2.1 Mangel an Bezug zwischen Personen und deren Nachrichten

Während beim direkten Gespräch eindeutig klar ist, welche Person spricht, ist die Zuord-nung einzelner Beiträge zu bestimmten Personen bei der Chat-Kommunikation schwieri-ger. Im Standard-Chat wird der Bezug zwischen Personen und Nachrichten dadurch her-gestellt, dass der Nickname des Autors der jeweiligen Nachricht vorangestellt wird.

Trotzdem ist es bei vielen Gesprächspartnern, häufigem Teilnehmerwechsel oder einer ho-hen Anzahl von Chat-Beitragen oft schwierig, die Absender zu unterscheiden. Insbesonde-re wenn sich die Gesprächsteilnehmer noch nicht kennen, fällt es schwer, einen Nicknamenmit früheren Aussagen dieses Gesprächsteilnehmers in Verbindung zu bringen. Vronay etal. [VSD99] bezeichnen diese Zuordnungsschwierigkeit als "Lack of recognition" (niedri-ger Wiedererkennungswert).

3.2.2 Keine Sichtbarkeit des Zuhörers

Beim Standard-Chat gibt es keine Informationen darüber, ob ein Chat-Teilnehmer tatsäch-lich den Gesprächsverlauf verfolgt. Selbst wenn er in der Liste der Chat-Teilnehmer ange-zeigt wird, können die Gesprächspartner nicht sicher sein, ob er nicht beispielsweise gera-de in einem anderen Fenster der Benutzeroberfläche im Internet surft oder seinen Compu-ter gerade verlassen hat.

Im direkten Gespräch merkt der Sprecher anhand der Reaktionen der Gesprächsteilnehmer,ob diese ihm zuhören, ob sie an seiner Aussage interessiert sind, ob sie seine Aussage ver-stehen, dieser zustimmen oder diese ablehnen. Diese Rückmeldungen (sog. Back-Channel-Behavior) können sowohl verbaler als auch non-verbaler Art (z.B. Kopfnicken) sein. Beider Chat-Kommunikation fehlen diese unmittelbaren Rückmeldungen während ein Chat-Teilnehmer einen Beitrag verfasst. Damit gibt es beim Chat auch nicht die Möglichkeit,dass ein Verfasser seine Äußerung, entsprechend der Reaktionen der Zuhörer, direkt anpas-sen kann, um beispielsweise das Auftreten von Missverständnissen zu verhindern.

Wirklich sichtbar wird ein Zuhörer im Chat erst dann, wenn er selbst eine Nachricht ver-fasst. Das Verfassen von Nachrichten wird daher oft auch dazu genutzt, den anderen Teil-nehmern zu signalisieren, dass man dem Kommunikationsverlauf weiterhin folgt. Dies istvergleichbar mit entsprechenden Äußerungen beim Telefonieren, mit denen man dem Ge-sprächspartner regelmäßig signalisiert, dass man noch miteinander verbunden ist.


3.2.3 Kein wahrnehmbarer Antwortprozess

Beim Standard-Chat wird nicht jedes Zeichen einzeln, sondern immer ein kompletter Chat-Beitrag an die anderen Chat-Teilnehmer übermittelt. Der Verfasser gibt dazu zunächst denText in einem Texteingabefeld ein, kann diesen bei Bedarf auch korrigieren, und erst wenner die Eingabetaste drückt, wird der Beitrag versandt.

Die Eingabe eines Gesprächsbeitrags dauert immer eine gewisse Zeit und ist für die ande-ren Gesprächsteilnehmer unsichtbar. Damit ist den Gesprächspartnern nicht bekannt, obgerade jemand gerade eine Nachricht verfasst und wenn ja wer.

Im obigen Beispiel führt das dazu, dass die beiden Gesprächspartner zeitgleich den glei-chen Text eingeben. Oftmals empfinden die Gesprächspartner jedoch die durch den nichtsichtbaren Eingabeprozess entstehenden Verzögerungen und das Warten auf Antwort alsunangenehm. Das kann dazu führen, dass Gesprächsteilnehmer nicht auf eine Antwortwarten, bevor sie ihren nächsten Beitrag versenden. Insbesondere langsamere Schreiberwerden dadurch verunsichert und die Situation führt möglicherweise zu mehrdeutigen Bei-trägen (vgl. auch [VSD99]).

Da Beiträge nicht während, sondern erst nach ihrem Entstehen angezeigt werden, bestehtauch nicht die Möglichkeit, einen anderen Gesprächsteilnehmer zu unterbrechen oder sichsimultan zu äußern [SCB00].

Wenn ein Benutzer auf eine Frage keine Antwort bekommt, kann es dafür mehrere Ursa-chen geben. Entweder will bzw. kann keiner die Frage beantworten, die Frage wurde vonden anderen Gesprächsteilnehmern zwischen den anderen Nachrichten übersehen oder dieAntwort wird gerade erst verfasst. Je nach dem, wie lange das dauert und wie ungeduldigder Fragesteller ist, wird er die Frage möglicherweise nochmals stellen, was dann zu Red-undanzen führt.

21:57 <biene> schlaf gut und träum süß

21:57 <honk> Schlaf gut und traeum suess.

21:58 <biene> lol

21:58 <honk> lol

21:58 <honk> Zwei doofe, ein Gedanke. :)

21:58 <biene> zwei doofe ein gedanke :)

21:59 <biene> ^^

21:59 <honk> blubb

21:59 <biene> spalter ;)

22:00 <honk> Wir chatten zu viel miteinander. ;)

Text 1: Beispiel von http://german-bash.org/8449

http://german-bash.org/8449


3.2.4 Mangel an Kontrolle über die Positionierung der Nachrichten(Co-Text-Verlust)

Standard-Chat-Systeme stellen eingehende Nachrichten in der Reihenfolge dar, in der sieauf dem Server eintreffen. Alle Chat-Teilnehmer können gleichzeitig Nachrichten verfas-sen; es haben also alle Teilnehmer gleichzeitig das Rederecht. Die Reihenfolge, in der dieNachrichten später beim einzelnen Benutzer auf dem Bildschirm erscheinen, wird vomServer nach dem sog. Mühlenprinzip "wer zuerst kommt, mahlt zuerst" festgelegt (vgl.[Bei00]). Chat-Systeme, bei denen nicht jedes Zeichen einzeln übertragen wird, werdendeshalb auch oftmals als "quasi-synchron" bezeichnet [Hes06].

Dies hat zur Folge, dass der angezeigte Gesprächsverlauf nicht linear ist: Nicht jeder Bei-trag bezieht sich jeweils auf den vorherigen Beitrag. Es entstehen mehrere parallele inein-ander verflochtene gleichzeitige Gesprächsstränge, bei denen oftmals auch mehrere The-men parallel diskutiert werden.

Deshalb kann es passieren, dass ein Leser nicht weiß, welcher der vorherigen Beiträge dieInformationen enthält, die notwendig sind, um die aktuelle Nachricht zu verstehen. DieseSituation wird von Pimentel et al. [PFdL03] als Co-Text-Verlust bezeichnet. Unter "Co-Text" wird in der Linguistik der Text verstanden, der jeweils vor und nach einer Nachrichtgeschrieben wurde und dessen Inhalt zum Verstehen einer Nachricht hilfreich ist. Pimentelet al. [PFdL03] stellen die möglichen Konsequenzen des Co-Text-Verlusts in folgenderGrafik dar:

Insbesondere bei vielen Gesprächsteilnehmern benötigen die Chat-Nutzer ein hohes Maßan Konzentrationsfähigkeit und Reaktionsgeschwindigkeit, um die verschiedenen Ge-sprächsstränge zu entwirren, auftretenden Co-Text-Verlust zu beseitigen und somit derKonversation folgen zu können. Dabei wird es umso schwieriger die Zuordnung zu finden,

Schwarz: Hast Du schon den neuen Mel Gibson Film gesehen: erheißt Payback?

Rosa: Ich habe die Oskar-Verleihung gesehen, Du auch?

Rosa: Ja, genau.

Rosa: Etwas brutal, aber lustig.

Schwarz: Du hast sie gesehen, war sie gut?

Schwarz: Wie ging es aus, wer hat gewonnen?

Rot: Soll gut sein, habe ich gehört.

Rosa: War OK. Titanic hat zum Glück nicht alles abgeräumt

Text 2: Beispiel entnommen aus [VSD99]

Abbildung 2: Mögliche Reaktionen auf Co-Text-Verlust [PFdL03]


je größer der Abstand zwischen den zusammengehörenden Nachrichten ist.

Durch den Co-Text-Verlust können Mehrdeutigkeiten entstehen, wenn nicht klar ist, wel-che Nachricht sich auf welche andere bezieht. Dabei sind insbesondere kurze Antworten,wie "ja" oder "nein" problematisch.

Neben dem Begriff des Co-Text-Verlusts finden sich in der Literatur noch weitere Bezeich-nungen für die durch das Mühlenprinzip verursachten Probleme der Chat-Kommunikation.

So bezeichnen Vronay et al. [VSD99] das Problem, dass oft nicht eindeutig festgestelltwerden kann, ob ein Sprecher seinen Beitrag an einen bestimmten Gesprächspartner ge-richtet hat oder er sich auf einen früheren Beitrag bezieht, als "intention confusion" und dasProblem der Mehrdeutigkeiten aufgrund unterschiedlicher Tippgeschwindigkeit und zeit-gleicher Eingabe als "thread confusion".

Weitere Bezeichnungen für das Problem sind "chat confusion" [PFdL06] und "interactionalincoherence" [Her99].

3.2.5 Mangel an brauchbaren Aufzeichnungen

Ein Vorteil der Chat-Kommunikation ist, dass die Gesprächsinhalte grundsätzlich in elek-tronischer Form vorhanden sind und zumindest die Möglichkeit besteht, diese Daten dauer-haft zu speichern. Im Gegensatz dazu müssen Gesprächsprotokolle beim direkten Ge-spräch, wie beispielsweise in Besprechungen, extra angefertigt werden. (vgl Harnoncourtet al. [HHSM05]).

Die meisten Chat-Räume sind nicht persistent und auch die Gesprächsinhalte werden nichtdauerhaft auf dem Server gespeichert. Damit gibt es für die meisten Chat-Räume keine do-kumentarischen Aufzeichnungen früherer Gesprächsverläufe. Selbst wenn die Gesprächeaufgezeichnet werden, sind die so entstehenden Gesprächsprotokolle oft unverständlich.Dies trifft insbesondere dann zu, wenn die Aufzeichnungen keine Zeitangaben enthalten.Die durch den Co-Text-Verlust entstehenden Zuordnungsprobleme und Mehrdeutigkeitenlassen sich aus einem gespeicherten Chat-Transskript oft gar nicht mehr auflösen. Währenddes Gesprächs hätte es zumindest noch die Möglichkeit gegeben, die Zuordnung durchRückfragen zu klären.

Aufgrund dieser Probleme haben Chat-Protokolle nicht die Qualität und die Verbindlich-keit, die vor allem im geschäftlichen Umfeld wünschenswert wären.

Bei den meisten Chat-Programmen gibt es während des Chats zwar die Möglichkeit, auffrühere Beiträge zurückzublättern, diese Möglichkeit wird aber in der Praxis nur seltengenutzt: Statt lange zu suchen, stellen die Benutzer eine Frage lieber noch einmal. Diesauch deswegen, weil während des Zurückblätterns möglicherweise neue Nachrichten ver-passt werden. (vgl. Vronay et al. [VSD99]).

3.2.6 Weitere Probleme bei der Chat-Kommunikation

Neben den fünf genannten Schwächen können noch weitere Probleme identifiziert werden,die teilweise auch mit den bereits genannten zusammenhängen.

So gibt es einen relativ hohen Grad an Beiträgen, die inhaltlich nicht zum Gesprächsver-lauf beitragen, beispielsweise umfangreiche Begrüßungsphrasen oder Rückfragen, ob einbestimmter Teilnehmer noch anwesend ist. Dieses Problem wird von Vronay et al.[VSD99] als hoher Störgeräuschanteil (signal-to-noise-ratio) bezeichnet.

Neu hinzugekommene Gesprächsteilnehmer stehen oft vor dem Problem, zu verstehen,worüber gerade gesprochen wird. Sie bekommen beim Standard-Chat Nachrichten erst ab


dem Zeitpunkt angezeigt, zu dem sie den Raum betreten haben. Der frühere Gesprächsver-lauf ist für sie nicht sichtbar und kann daher auch nicht für das Verständnis des gerade Ge-sprochenen herangezogen werden. Das Problem der Späteinsteiger gibt es zwar auch beider gesprochenen Unterhaltung, es wird aber bei der Chat-Kommunikation besondersdeutlich, weil die Gesprächsteilnehmer häufig wechseln und zusätzliche Beiträge nötigsind, um Neueinsteiger in das laufende Gespräch zu integrieren. Vronay et al. [VSD99] be-zeichnen das Problem der Späteinsteiger als "Lack of context".

Ein weiteres Problem bei der Chat-Kommunikation sind die eingeschränkten Möglichkei-ten einer Fehlerkorrektur. Bereits erstellte Beiträge können nicht mehr geändert werden.Selbst wenn ein Fehler durch einen zusätzlichen Beitrag korrigiert wird, bleibt die ur-sprüngliche fehlerhafte Nachricht weiterhin für alle sichtbar (vgl. [HHSM05]).

Insbesondere bei vielen Chat-Teilnehmern kann die Situation auftreten, dass es für die Teil-nehmer gar nicht mehr möglich ist, die Vielzahl der Nachrichten einer Diskussion zu lesen,insbesondere wenn innerhalb eines kurzen Zeitraums sehr viele Nachrichten eintreffen.Dieses Phänomen wird auch Nachrichten-Überflutung (Message Overload) genannt[PFdL06].

3.3 Anforderungen an das zu entwickelte Chat-SystemDas zu entwickelnde Chat-System soll in erster Linie das Problem des Co-Text-Verlusts(P4) lösen oder zumindest verringern. Aber auch die anderen Problemfelder sollen dabeinicht außer Acht bleiben. Auf dieser Basis entwickeln wir nun eine erste Liste von Anfor-derungen an das System.

Zunächst muss das Chat-System den Funktionsumfang eines Standard-Chat-Systems be-reitstellen. Eingegebene Textnachrichten müssen an alle Chat-Teilnehmer weitergeleitetund dort angezeigt werden. Daneben werden die Teilnehmer des Chats in einer Liste ange-zeigt. Diese Minimalausstattung mit den Anforderungen (M1) bis (M5) wurde bereits inKapitel 3.1 beschrieben. Die Minimalausstattung fassen wir in der Anforderung (A1) zu-sammen:

(A1) Basis-Chat-Funktionalität

Der Co-Text-Verlust (siehe Kapitel 3.2.4) entsteht vor allem dadurch, dass oft nicht alleinaus dem Inhalt einer Nachricht klar ist, auf welche vorherige Nachricht sich eine Nachrichtbezieht. Das zu entwickelnde Chat-System soll den Benutzer dabei helfen, Bezüge einesGesprächsbeitrags zu anderen Gesprächsbeiträgen schnell zu erkennen und so dem Ge-sprächsverlauf zu folgen. Das System muss daher dem Benutzer die Möglichkeit bieten,Referenzen auf frühere Chat-Beiträge zu setzen. So muss es bei der Eingabe einer Nach-richt möglich sein, eine Nachricht auszuwählen, auf die sich der aktuelle Beitrag bezieht.Die Möglichkeit der Referenzierung beschreibt die Anforderung (A2):

(A2) Herstellung von Bezügen zwischen Beiträgen

Die Chat-Beiträge und die dazwischen gesetzten Beziehungen müssen allen Chat-Teilneh-mern in geeigneter Weise angezeigt werden. Vorrangig soll die Darstellung dazu dienen,den Co-Text-Verlust (P4) zu minimieren (siehe Kapitel 3.2.4). Allerdings sollte auch daraufgeachtet werden, dass der Bezug zwischen Personen und ihren Nachrichten (vgl. Kapitel3.2.1) übersichtlich dargestellt wird (P1).

Dem Benutzer sollen mehrere Visualisierungsalternativen zur Verfügung stehen. Im Rah-men von Benutzertests kann dann geprüft werden, welche davon den Benutzer am bestendabei unterstützt, Zusammenhänge zwischen den Beiträgen zu erkennen und welcheNachteile, insbesondere hinsichtlich der Benutzerfreundlichkeit, einzelne Visualisierungenaufweisen. Dies führt uns zur Anforderung (A3):


(A3) Visualisierung der Beiträge sowie der Bezüge zwischen den Beiträgen

Das zu entwickelnde Chat-System soll sich auch dem Thema der Aufzeichnungen (vgl. Ka-pitel 3.2.5) widmen. Der Benutzer sollte den Gesprächsverlauf speichern und zu einemspäteren Zeitpunkt nochmals ansehen können. Bei der Anzeige der gespeicherten Gesprä-che sollen alle Visualisierungsalternativen zur Verfügung stehen, und es soll die Möglich-keit geben, das Gespräch in seinem zeitlichen Verlauf wiederzugeben (Replay-Modus).Dadurch, dass der zeitliche Ablauf sowie die Bezüge zwischen den Nachrichten auch imProtokoll im Chat-Protokoll noch nachvollziehbar sind, kann dem Problem des Mangels anbrauchbaren Aufzeichnungen (P5) entgegengewirkt werden.

Für die Speicherung sollte ein vom Benutzer lesbares Format verwendet werden, das auchals Importformat für auf anderem Wege aufgezeichnete oder fiktive Gesprächsverläufe ver-wendet werden kann. So kommen wir zu den Anforderungen (A4) und (A5):

(A4) Speicherung des Gesprächsverlaufs

(A5) Replay-Modus

Das System soll von einem möglichst großen Nutzerkreis verwendet werden können. Ausdiesem Grund sollte das System plattformunabhängig sein. Die Benutzeroberfläche solltesowohl in Deutsch als auch in Englisch verfügbar sein und leicht um weitere Sprachen er-gänzt werden können. Diese Eigenschaften beschreiben die Anforderungen (A6) und (A7):

(A6) Plattformunabhängigkeit

(A7) Mehrsprachigkeit

Ein modularer Aufbau der Software und die Veröffentlichung des Quellcodes ermöglicheneine einfache Weiterentwicklung des Systems, insbesondere das Hinzufügen weiterer undoptimierter Visualisierungen. Dies führt uns zu den Anforderungen (A8) und (A9):

(A8) Modularer Aufbau

(A9) Open Source

Bevor wir diese neun Anforderungen in Kapitel 5 weiter konkretisieren, betrachten wir zu-nächst verschiedene andere Chat-Systeme.

Verwandte Arbeiten 11

4 Verwandte ArbeitenIn diesem Kapitel werden vorhandene Chat-Systeme daraufhin untersucht, ob und wenn jawie die von Smith et al. identifizierten Probleme gelöst werden.

Aufgrund der Vielzahl der aktuell verfügbaren Chat-Systeme beginnen wir mit einer Klas-sifizierung von Chat-Systemen. Danach schildern wir prinzipielle Lösungsansätze für diegenannten Probleme und untersuchen ob und ggf. wie diese bei typischen Vertretern dieserKlassen von Chat-Systemen umgesetzt wurden. Danach werden einige alternative Chat-Systeme vorgestellt, die sich jeweils speziell einem oder mehreren der genannten Problem-bereiche widmen.

4.1 Klassifizierung von Chat-SystemenDie meisten Chat-Systeme kann man in die Kategorien Internet Relay Chat, Web-Chat, In-stant Messaging sowie Mehrbenutzer-Online-Rollenspiele und Virtuelle Welten einteilen.

4.1.1 Internet Relay Chat

Internet Relay Chat (IRC) ist ein Chat-System, das aus einem Netzwerk mehrerer mitein-ander verbundener Servern besteht. Die Benutzer können in sog. Channels miteinanderkommunizieren. Auch eine direkte Kommunikation mit einem anderen Benutzer ist mög-lich. Für IRC wird in der Regel auf dem Client ein separates Programm (sog. IRC-Client)benötigt. Die Kommunikation zwischen IRC-Client und dem IRC-Server sowie der IRC-Server untereinander ist im Protokoll-Standard RFC 1459 [OR93] geregelt. Das textorien-tierte IRC-Protokoll ermöglicht es dem Benutzer, dem Server direkt Steuerungsbefehle zuübermitteln. Daneben können mit geringem Aufwand kleine Programme (sog. Bots) erstelltwerden, um bestimmte Aufgaben, wie das Verwalten eines Kanals, zu automatisieren.

Die Server eines IRC-Netzwerks tauschen laufend Informationen über die vorhanden Be-nutzer, Channels sowie die Gesprächsinhalte aus. Dadurch liegen die Informationen verteiltauf allen Systemen vor und ein Benutzer kann sich mit seinem Client mit jedem beliebigenServer des IRC-Netzwerks verbinden. Diese verteilte Architektur ermöglicht eine guteLastverteilung und ist daher für hohe Nutzerzahlen geeignet.

4.1.2 Web-Chat

Mit Aufkommen des World Wide Web (WWW) wurden web-basierte Chats populär. Vor-teil der Web-Chats ist, dass der Benutzer als Software nur den Browser und kein speziellesChat-Programm benötigt.

Bei einem Web-Chat findet die Kommunikation zwischen den Clients und dem Server überdas HTTP-Protokoll statt. Um die zeitnahe Anzeige von neuen Beiträgen anderer Clientszu ermöglichen, ist die Nutzung von Techniken für aktive Inhalte, wie beispielsweise Ja-vaScript oder Java-Applets nötig.

Funktionsumfang und Benutzerschnittstelle sind bei den Web-Chats zwar oft ähnlich, esgibt jedoch keine Standardisierung.

4.1.3 Instant Messaging

Instant-Messaging (IM) ist ein Sammelbegriff für verschiedene Dienste, die Textnachrich-ten in Echtzeit über ein Netzwerk zu anderen Benutzern übermitteln. IM kann als synchro-ne E-Mail-Variante betrachtet werden [Luk05]. IM wird insbesondere von Personen, die


sich bereits kennen, zur Kommunikation genutzt. So kann man beim IM Kontaktlisten(sog. Buddy-Listen) verwalten und sich über die Erreichbarkeit und Kommunikationsbe-reitschaft bestimmter anderer Benutzer informieren lassen. Die bekanntesten IM-Dienstesind ICQ, AIM, Yahoo Messenger und MSN. Die Kommunikation läuft dabei über einenoder mehrere Server des jeweiligen Dienstanbieters. Die Protokolle sind zumeist proprietärund eine Kommunikation ist nur dann möglich, wenn die Teilnehmer den gleichen IM-Dienst nutzen. Es gibt aber auch sog. Multi-Protokoll-Clients, mit denen man mehrere IM-Dienste gleichzeitig nutzen kann. Daneben gibt es zwischen einigen IM-Diensten auchSchnittstellen, über die eine anbieterübergreifende Kommunikation möglich ist.

Neben den von den o. g. Anbietern verwendeten proprietären Protokolle gibt es auch einenInternetstandard für Instant Messaging: Das Extensible Messaging and Presence Protocol(XMPP) ist im RFC 3920–3923 [Sa04] definiert. Als Erweiterungen gibt es sog. XMPPExtension Protocols (XEP), wie beispielsweise das Protokoll XEP-0045, das die Funktio-nen eines Mehrbenutzer-Chats (Multi-User-Chat, MUC) beschreibt. XMPP und seine Er-weiterungen gehören zur Jabber-Protokollfamilie. Auch MuVi-Chat wird das Jabber-Pro-tokoll verwenden (siehe Kapitel 6.1.2).

4.1.4 Mehrbenutzer-Online-Rollenspiele und Virtuelle Welten

Mehrbenutzer-Online-Rollenspiele und Virtuelle Welten sind ebenfalls eine spezielle Formvon Chat-Systemen. Der Austausch von (Text-)Nachrichten ist dort in das Umfeld einervirtuellen Welt oder eine Spielhandlung eingebettet. Der Benutzer oder Spieler tritt mit ei-ner von ihm gewählten Figur (Avatar) in der virtuellen Welt auf, und kann dort mit anderenTeilnehmern interagieren und kommunizieren. Bei einigen Systemen steht das Spiel, beianderen die Kommunikation im Vordergrund. Man unterscheidet auch zwischen den text-basierten Multi-User-Dungeons (MUD) sowie den graphischen Massively Multiplayer On-line Role-Playing Games (MMORPG).

4.2 Generelle LösungsansätzeBei den Lösungsansätzen für die fünf Schwächen der Standard-Chat-Kommunikation gibtes zwei Kategorien. Bei der einen Kategorie werden die technischen Voraussetzungen alsgegeben angesehen und es wird versucht, die Nachteile der Technik durch die Vereinba-rung von Regeln zwischen den Chat-Teilnehmern auszugleichen. Das so vereinbarte sozia-le Protokoll kann dann in eine Chatiquette, also eine Richtlinie für die Umgangsformen indiesem Chat aufgenommen werden.

Bei der anderen Kategorie versucht man, die Mängel durch Anpassungen der Technik, ins-besondere durch Optimierung der Benutzeroberfläche, zu lösen.

4.2.1 Mangel an Bezug zwischen Personen und deren Nachrichten

Für die Problematik des Bezugs zwischen Personen und deren Nachrichten finden sichmehrere Lösungsansätze.


Eine Möglichkeit ist, die Nicknamen oder Nachrichten verschiedener Benutzer in unter-schiedlichen Farben darzustellen. Dabei gibt es mehrere Varianten:

● Jeder Benutzer legt selbst fest, in welcher Farbe er im Chat dargestellt wird.

● Das System vergibt die Farben automatisch.

● Jeder Nutzer wählt für seine Programmoberfläche eigene Farbeinstellungen.

Neben unterschiedlicher Farben können auch verschiedene Schriftarten oder Schriftstileverwendet werden.

Insbesondere beim IM gibt es auch die Möglichkeit, dass Benutzer bei ihren eigenen Kon-taktdaten eine Bilddatei hinterlegen, die den Gesprächsteilnehmern neben dem Nicknamenangezeigt wird.

Einen Schritt weiter gehen die graphischen Mehrbenutzer-Online-Rollenspiele sowie dieVirtuellen Welten. Dort können je nach System entweder vorgegebene Avatare gewähltoder eigene Charaktere gestaltet und so virtuelle Identitäten geschaffen werden. Ein derzeitsehr populäres Beispiel dafür ist das System Second Live.

Zur Zuordnung von Beiträgen zu einzelnen Personen werden bei den graphischen Chatsoftmals Sprechblasen verwendet, die den Text oberhalb des Avatars anzeigen.

Um eine Nachricht direkt an eine Person zu adressieren, kann der Absender den Namendes Empfängers vor die Nachricht schreiben. Manche Chat-Clients unterstützen die Aus-wahl des Namens durch Anklicken mit der Maus.

4.2.2 Keine Sichtbarkeit des Zuhörers

Zur Lösung dieses Problems ist es erforderlich, dass jeder Chat-Teilnehmer Informationenüber die Anwesenheit, den Status und die Aktionen anderer Chat-Teilnehmer hat (sog.Awareness).

Eine direkte Möglichkeit, die Gesprächsteilnehmer sichtbar zu machen, wäre der Einsatzvon Videokonferenztechnologien, die auch in Kombination mit dem textbasierten Chat ver-wendet werden können. Dazu ist jedoch zusätzliche Hardware (Webcam) nötig.

Aber auch im rein textbasierten Chat-System lassen sich Awareness-Informationen bereit-stellen. Grundsätzlich kann man unterscheiden zwischen Awareness-Informationen, die derBenutzer selbst eingeben kann und Awareness-Informationen, die das System automatischgeneriert.

Im Standard-Chat-System wird die Anwesenheit der Teilnehmer im Chat-Raum in einerTeilnehmerliste angezeigt. Sobald ein Teilnehmer in den Chat-Raum eintritt und er damitgrundsätzlich dazu in der Lage ist, die Gesprächsbeiträge zu verfolgen, wird sein Name derTeilnehmerliste hinzugefügt. Wenn er den Raum verlässt, wird er wieder aus der Teilneh-merliste entfernt. Darüber, ob ein Teilnehmer dem Gesprächsverlauf tatsächlich folgt, sagtdiese automatisch generierte Teilnehmerliste jedoch nichts aus.

Verschiedene Instant-Messaging-Clients ermöglichen den Benutzern, den Status, mit demsie in der Teilnehmerliste angezeigt werden, selbst zu bestimmen. Jabber beispielsweiseunterscheidet fünf verschiedene Werte für den Grad der Verfügbarkeit. Tabelle 1 zeigt diedem Benutzer zur Verfügung stehenden Möglichkeiten.


away Benutzer ist kurzfristig abwesend

chat Benutzer ist an einem Chat interessiert

dnd Benutzer will nicht gestört werden ("do not disturb")

normal Benutzer ist anwesend

xa Benutzer ist längerfristig abwesend ("extended away")

Tabelle 1: Verfügbarkeitsstati in Jabber

Daneben können die Benutzer einen Text eingeben, der den anderen Benutzern zusammenmit der Verfügbarkeitsinformation angezeigt wird, wie z. B. "Bin gerade beim Mittages-sen". Problem bei der manuell gesetzten Awareness-Information ist, dass der Benutzermöglicherweise vergisst, diese zu setzen bzw. wieder zurückzusetzen.

Ein weiterer Lösungsansatz für automatisch generierte Awareness-Information ist, denGrad der Interaktion einzelner Benutzer mit dem System zu messen und darzustellen.Mögliche Indikatoren für den Grad der Interaktion sind beispielsweise die Häufigkeit vonTexteingaben durch den Benutzer sowie die Anzahl der Mausklicks und -bewegungen indem zum Chat gehörenden Anwendungsfenster. Bei diesem Lösungsansatz muss jedoch si-chergestellt sein, dass die gewählten Messgrößen auch tatsächlich mit dem Grad der Ver-fügbarkeit des Benutzers korrelieren. Ein Beispiel für eine derartige indikatorbasierte Vi-sualisierung wird im System Babble (siehe Kap. 4.3.5) gezeigt.

4.2.3 Kein wahrnehmbarer Antwortprozess

Chat-Systeme, bei denen jedes Zeichen einzeln übertragen wird, machen auch den Ant-wortprozess sichtbar. Beim Urvater der synchronen computerbasierten Kommunikation,dem Unix-Programm talk, gibt es für jeden Benutzer einen eigenen Anzeigebereich, in demgenau nachvollziehbar ist, was der Benutzer gerade eintippt. Nachteil dabei ist jedoch, dassder Verlauf der Diskussion nur schwer nachvollziehbar ist, da die Inhalte auf die verschie-denen Anzeigebereiche der Benutzer verteilt sind.

Neben dieser Möglichkeit der zeichenweisen Übermittlung und Darstellung, kann der Ant-wortprozess auch dadurch wahrnehmbar gemacht werden, dass nur die Tatsache, dass einBenutzer eine Eingabe macht, den anderen Benutzern angezeigt wird.

Hier müssen Indikatoren für den Beginn und das Ende des Eingabevorgangs gefunden wer-den. Für den Beginn könnte dies beispielsweise die Eingabe des ersten Zeichens im Tex-teingabefeld des Chat-Clients sein, für das Ende entweder das Absenden des Chat-Beitragsoder eine gewisse Zeitdauer, in der keine Eingaben mehr vorgenommen werden. Beginnund Ende des Eingabevorgangs werden dann an die anderen Gesprächsteilnehmer übermit-telt und in deren Benutzeroberfläche in geeigneter Weise angezeigt.

Diese Darstellung kann beispielsweise so aussehen, dass der Benutzername desjenigen, dergerade einen Beitrag verfasst, farblich hervorgehoben wird, oder dass ein dem Benutzerzugeordneter Avatar entsprechende (animierte) Aktionen durchführt. Letzteres ist beispiels-weise in Second Live der Fall. Dort führt der Avatar des tippenden Benutzers ebenfallsTippbewegungen aus.

Ein System, das sich speziell dem Problem des nicht wahrnehmbaren Antwortprozessesannimmt, ist Status Client [VSD99], das wir in Kapitel 4.3.1 beschreiben.


4.2.4 Mangel an Kontrolle über die Positionierung der Nachrichten(Co-Text-Verlust)

Durch die "Zwangsserialisierung" im Standard-Chat ist die Reihenfolge der Chat-Beiträgezum Teil dem Zufall unterworfen. Der daraus resultierende Co-Text-Verlust kann durchfolgende Maßnahmen optimiert werden:

Die Benutzer können beispielsweise vereinbaren, den Bezugsbeitrag oder Teile davon demneu verfassten Beitrag voranzustellen (vgl. [HHSM05]).

Ein technischer Lösungsansatz ist, einem Chat-Benutzer eine besondere Rolle zuzuteilen,die ihn dazu befähigt, die Reihenfolge der Beiträge der anderen Benutzer festzulegen. Die-se besondere Rolle wird Moderator, die spezielle Chat-Form moderierter Chat genannt.Wenn ein Chat-Teilnehmer einen neuen Beitrag verfasst und diesen absendet, wird er nichtdirekt an alle anderen Chat-Teilnehmer versandt, sondern zunächst in der Benutzeroberflä-che des Moderators angezeigt. Dieser kann dann aus der Liste der an ihn übermitteltenChat-Beiträge denjenigen auswählen, der als nächstes an alle Teilnehmer versandt wird.Daneben kann er aber auch jederzeit selbst Beiträge erstellen.

Durch die Moderation wird der Gesprächsverlauf allerdings stark formalisiert. Insbesonde-re bei Prominenten-Chats, die in der Regel als moderierte Chats durchgeführt werden, istder Chat meist eine Abfolge von Fragen der Chat-Teilnehmer an den Prominenten und des-sen Antworten.

Eine weitere Möglichkeit ist, für das Rederecht eine fest vorgegebene Reihenfolge festzu-legen, beispielsweise in der Form, dass jeder Teilnehmer reihum jeweils einen Beitrag ver-fassen darf. Diese vorgegebenen Gesprächsstrukturen führen ebenfalls zu einem sehr for-malen Ablauf des Gesprächs, sind aber für bestimmte Einsatzbereiche, wie z. B. für E-Learning durchaus von Vorteil. Die vorgegebene Reihenfolge kann entweder vom Systemtechnisch vorgegeben sein oder als soziales Protokoll zwischen den Gesprächsteilnehmernvereinbart werden.

Eine andere Lösung zur Reduzierung des Co-Text-Verlusts ist, logisch zusammengehören-de Beiträge zu verknüpfen und die Verknüpfungen zu visualisieren. Dabei könnten die Be-züge entweder durch den Verfasser der Nachricht manuell oder aufgrund einer Analyse derInhalte durch das System gesetzt werden. Für letzteres wären hochkomplexe Analysetech-niken erforderlich (vgl. [Her99]).

Als Darstellungsvarianten der Referenzierungen sind insbesondere Baumstrukturen denk-bar. In einer Listenansicht könnten zusammengehörige Beiträge durch bestimmte farblicheoder sonstige Markierungen gekennzeichnet werden. Herring [Her99] regt an, parallel zurnicht-linearen Darstellung auch die lineare Darstellung anzuzeigen.

Daneben gibt es noch die Möglichkeit, die Positionierung der Beiträge dem Beitragserstel-ler zu überlassen.

4.2.5 Mangel an brauchbaren Aufzeichnungen

Für die Aufzeichnung von Chat-Unterhaltungen (sog. Chat-Transskripte) sind als Varianteneinerseits eine serverseitige Speicherung und andererseits eine lokale Speicherung beimBenutzer denkbar.

Eng mit der Frage der Speicherung verbunden ist die Frage nach der Persistenz der Chat-Räume bzw. Channels. Beim IRC ist ein Channel nur so lange vorhanden wie mindestensein Benutzer mit diesem Channel verbunden ist. In vielen IRC-Netzen gibt es allerdingssog. Services oder Bots, die die Verwaltung der Channels übernehmen können. Eine ser-verseitige Speicherung der Chat-Unterhaltungen ist beim IRC nicht vorgesehen. Die meis-


ten IRC-Clients können aber die eintreffenden Chat-Beiträge entweder laufend oder nachAufforderung durch den Benutzer lokal in einer Datei abspeichern. Daneben besteht beimIRC die Möglichkeit, Bots einzusetzen, die die Gespräche mitschreiben.

Bei den proprietären IM-Diensten weiß der Benutzer nicht, ob der Dienste-Anbieter dieNachrichten auf dem Server mitloggt. Die Nutzungsbestimmungen der Dienste enthaltendiesbezüglich oftmals nur vage Aussagen. Die Möglichkeit einer lokalen Speicherung gibtes zumindest über "Copy & Paste" in eine zu speichernde Textdatei.

Die MUC-Erweiterung von Jabber sieht das serverseitige Mitloggen der Diskussionen op-tional vor, fordert aber, dass die Serverimplementierung den Benutzer durch eine Status-meldung mitteilt, dass seine Diskussionsbeiträge mitgeloggt werden. In welcher Art undWeise bei Jabber lokal mitgeloggt werden kann, ist von Client zu Client unterschiedlich.

Beim Web-Chat und bei den Mehrbenutzer-Rollenspielen sowie den Virtuellen Weltenhängt es stark vom jeweiligen System ab, ob und in welcher Weise die Gespräche aufge-zeichnet werden.

Ein reiner Textmitschnitt gibt die Dynamik eines Gesprächsverlaufs nur sehr beschränktwieder, da dabei die zeitliche Dimension nicht berücksichtigt wird. Ein Lösungsansatz da-für wäre, die Möglichkeit zu bieten, frühere Diskussionen wie einen Film nochmals abzu-spielen, entweder in Echtzeit oder auch in Zeitlupe oder Zeitraffer. Dabei sollte der Benut-zer den Abspielvorgang per Stopp-Taste unterbrechen und mit einer Bildlaufleiste einenbestimmten Zeitpunkt der Diskussion direkt ansteuern können (vgl. auch [Her99]).

4.3 Spezielle Chat-Systeme

4.3.1 Status Client

Vronay et al. [VSD99] haben mit Status Client ein Chat-System entwickelt, das den Statuseines Benutzers auf Basis seiner Tastatureingaben ermittelt und darstellt.

Auf der dem Standard-Chat-Client vergleichbaren Benutzeroberfläche kann sich der Be-nutzer zusätzlich folgende Statusinformationen anzeigen lassen:

● Keyboard activity fader: Der Benutzername leuchtet für fünf Sekunden auf, wennder Benutzer eine Nachricht eingibt.

● Last line indicator: Der letzte Beitrag wird neben dem Namen des Benutzers ange-zeigt.

● Intermediate text indicator: Wenn der Benutzer bei der Eingabe eines neuen Bei-trags eine Taste drückt, erscheint die Eingabe neben seinem Namen in der Benut-zerliste. Dabei wird eine andere Farbe verwendet, als für den letzten Beitrag.

● Last line fader: Der Text des letzten Beitrags neben dem Benutzernamen wird nach10 Sekunden ausgeblendet.

Mit diesen Funktionalitäten macht Status Client den Antwortprozess für den Benutzersichtbar und zeigt damit einen Lösungsansatz für das Problem des nicht wahrnehmbarenAntwortprozesses (P3).

Benutzertests des Prototyps zeigten, dass die Benutzer es zwar schätzten, den Eingabepro-zess der anderen Benutzer zu verfolgen, dass es ihnen selbst aber unangenehm war, bei derEingabe "beobachtet" zu werden. Dies führte dazu, dass sich die Benutzer bemühten ihreBeiträge schneller zu verfassen und bei der Eingabe weniger Tippfehler machten.

Weiter zeigte sich, dass durch die Sichtbarkeit des Eingabeprozesses die Anzahl von ausdem Zusammenhang gerissenen Beiträgen geringer wurde.


4.3.2 Flow Client

Um den zeitlichen Zusammenhang der Nachrichten untereinander besser darzustellen, ha-ben Vronay et al. [VSD99] den Flow Client entwickelt (vgl. Abbildung 3).

Beim Flow Client ist jedem Benutzer eine horizontale Spur zugeordnet, in der seine Beiträ-ge im zeitlichen Verlauf angezeigt werden. Im Laufe der Zeit wandern die Beiträge vonrechts nach links. Der Eingabevorgang wird den anderen Benutzern durch ein sich über derZeitleiste ausdehnendes farbiges Rechteck angezeigt. Der eingegebene Text selbst er-scheint während des Eingabevorgangs zeichenweise in blauer Farbe neben dem Benutzer-namen in der Spalte rechts. Erst wenn der Verfasser die Eingabetaste drückt, wird der Textin das Rechteck auf der Zeitleiste übernommen.

Über Ziehen der Maus mit gedrückter Maustaste kann der Benutzer die Zeitleiste ver-schieben, um frühere Beiträge nochmals anzusehen.

Flow Client zeigt also einerseits eine Möglichkeit auf, wie der Bezug zwischen Personenund ihren Nachrichten besser hergestellt werden kann (P1), andererseits macht Flow Clientauch den Eingabevorgang für andere Benutzer sichtbar (P3).

Benutzertests zeigten jedoch, dass viele Anwender mit der Darstellung der Nachrichten imFlow Client nicht zufrieden waren. Die Benutzer empfanden die Benutzeroberfläche alsungewohnt und hätten lieber vertikal als horizontal zu den früheren Nachrichten geblättert.Weiter fanden sie, dass die Nachrichten zu schnell vom Bildschirm verschwinden und dasses schwierig sei, die Eingabefelder aller Benutzer zu beobachten.

4.3.3 Fugue

Das Chat-System Fugue [RVVS00] zeigt Parallelen zum Flow Client. Auch bei Fugue wirdjedem Benutzer eine horizontale Spur zugeteilt. Die Darstellung (vgl. Abbildung 4) ähneltsomit einer Partitur, in der alle Einzelstimmen untereinander angeordnet sind. Der von denGesprächsteilnehmern eingegebene Text fließt als Laufschrift von rechts nach links. DieGeschwindigkeit der Laufschrift hängt davon ab, in welcher Geschwindigkeit der schnells-te Chat-Teilnehmer auf seiner Tastatur tippt und nicht davon, wie viel Zeit tatsächlich fürdie Eingabe der Nachricht benötigt wurde. Dies hat zur Konsequenz, dass die Laufschriftstehen bleibt, sobald keiner der Teilnehmer mehr weitere Chat-Beiträge verfasst. Insofernunterscheidet sich Fugue auch von dem oben beschriebenen Flow Client.

Abbildung 3: Chat-System Flow Client


Eine weitere Funktion von Fugue ist, dass neben dem aktuellen Gesprächsausschnitt aucheine Übersicht mit dem gesamten Gesprächsverlauf angezeigt wird. Aus dieser Übersicht,in der die einzelnen Gesprächsbeiträge als feine Linien angezeigt werden, kann man denjeweils aktuellen Gesprächsausschnitt auswählen. Die Namen der Benutzer, die in der letz-ten Zeit aktiv waren, werden in Fugue in einer größeren Schrift angezeigt. Daneben bietetFugue auch die Möglichkeit, frühere Beiträge mit Kommentaren zu versehen, was insbe-sondere für die spätere Lesbarkeit der Aufzeichnungen hilfreich ist.

Auch Fugue versucht, das Problem des Bezuges zwischen Personen und ihren Nachrichten(P1) zu lösen und macht ebenfalls den Antwortprozess sichtbar (P2). Mit der Kommentar-möglichkeit widmet sich Fugue zudem dem Problem des Mangels an brauchbaren Auf-zeichnungen (P5).

4.3.4 Chat Circles

Im System Chat Circles [VD99] wird jeder Teilnehmer durch einen farbigen Kreis auf demBildschirm repräsentiert. Die Nachrichten dieses Teilnehmers erscheinen innerhalb desKreises. Mit jeder eingegebenen Nachricht wächst der Kreis und wird heller. Bei Inaktivi-tät schrumpft der Kreis und wird dunkler. Erst wenn der der Benutzer den Chat verlässt,verschwindet der Kreis komplett.

Auch die räumliche Nähe wird in Chat Circles als Merkmal verwendet: Nur die Beiträgevon Teilnehmern in "Hörweite" werden angezeigt. Von den Teilnehmern außerhalb der"Hörweite" ist nur der Außenrand ihres Kreises zu sehen. Auf diese Weise wird die Nach-richtenflut für den einzelnen Benutzer reduziert.

Neben der interaktiven Sicht gibt es bei Chat Circles auch eine Sicht namens "Conversati-on Landscape", in der sich der Benutzer den bisherigen Diskussionsverlauf ansehen kann.Die Chat-Beiträge werden dabei zweidimensional räumlich angeordnet. Die y-Achse ent-spricht dabei der Zeit, auf der x-Achse wird jedem Teilnehmer ein fester Bereich zugeord-net.

Abbildung 4: Chat-System Fugue


Mit der Methode, die Nachrichten eines Benutzers direkt in "seinem" Kreis darzustellen,zeigt Chat Circles ebenfalls eine Möglichkeit auf, den Bezug zwischen Personen und derenNachrichten herzustellen (P1). Die Wiedergabe des Aktivitätsgrads durch die Größe undHelligkeit des Kreises eines Benutzers macht in gewisser Weise den Zuhörer sichtbar (P2).Mit der "Conversation Landscape" stellt ChatCircles zudem für das Problemfeld der Auf-zeichnungen (P5) eine Lösung bereit.

Chat Circles ist web-basiert und kann unter http://chatcircles.media.mit.edu getestet wer-den.

4.3.5 Babble

Das von Erickson et al. [ESK+99] beschriebene System Babble widmet sich dem Problemder fehlenden Sichtbarkeit des Zuhörers (P2). Mit einer einfachen graphischen Darstellungder Benutzer, dem sog. Social proxy wird der Interaktionsgrad der Benutzer mit dem Chat-System visualisiert. Die Benutzer werden dabei durch farbige Punkte in einem Kreis darge-stellt. Punkte innerhalb des Kreises stehen für Benutzer, die an der aktuellen Diskussionteilnehmen, Punkte außerhalb des Kreises repräsentieren Benutzer, die zwar am System an-gemeldet sind, aber an anderen Diskussionen teilnehmen. Je stärker ein Benutzer mit demSystem interagiert, desto weiter befindet sich der zu ihm gehörende Punkt in der Mitte desKreises. Der Grad der Interaktion wird entweder durch das Verfassen eigener Beiträge oderdurch Klicks und Mausbewegungen im Anwendungsfenster erkannt ("aktives Zuhören").

Neben dem Social proxy (Abbildung 6, oben Mitte) wird in Babble eine Benutzerliste an-gezeigt (links oben). Oben rechts sieht man die Themenliste, in der das Thema der aktuel-len Diskussion markiert ist. Durch Klicken auf ein anderes Thema wechselt der Benutzerin den zum anderen Thema gehörenden Raum und der ihm zugeordnete Punkt bewegt sichbei den anderen Diskussionsteilnehmern aus dem Kreis heraus.

Abbildung 5: Chat-System Chat Circles

http://chatcircles.media.mit.edu/


Konversationen bleiben bei Babble über die Sitzung hinaus bestehen, d.h. das System kannsowohl für synchrone, als auch für asynchrone Kommunikation eingesetzt werden. Damitsind bei Babble Aufzeichnungen des Gesprächs automatisch vorhanden (P5).

4.3.6 HyperDialog und Mediated Chat

Die Chat-Systeme HyperDialog und Mediated Chat sind als Bestandteil der CSCL-Softwa-re AulaNet entwickelt worden. Pimentel et al. beschreiben in [PFdL03] und [PFdL06] denEntwicklungsprozess der Werkzeuge. Während sich HyperDialog und Mediated Chat inden Versionen 2.0 bis 5.0 jeweils bestimmten Problembereichen der Chat-Kommunikationwidmen, wurden die einzelnen Lösungsansätze in der Version 6.0 von Mediated Chat zu-sammengeführt.

Abbildung 7: Funktionen von Mediated Chat und HyperDialog

Abbildung 6: Chat-System Babble


HyperDialog (vgl. Abbildung 8) strukturiert den Gesprächsverlauf als hierarchisch organi-sierte Folge von Diskussionsbeiträgen und ähnelt damit der bei asynchronen virtuellen Dis-kussionen üblichen Thread-Darstellung. Bei dieser Visualisierung werden Bezüge derNachrichten untereinander deutlich. Damit zeigt HyperDialog einen Lösungsansatz für dasProblem des Co-Text-Verlusts (P4) auf. Im Rahmen einer Evaluierung wurde überprüft, obHyperDialog im Vergleich zu einem Standard-Chat-System tatsächlich das Problem desCo-Text-Verlusts reduziert. Entgegen den Erwartungen kam es aber auch bei der Nutzungvon HyperDialog zum Co-Text-Verlust. Bei Auswertung des Versuchs erkannte man, dassdie Ursache fehlende oder falsch gesetzte Bezüge waren. Diese führten zu Verwirrung undfalschen Interpretationen bei den Lesern. Der Anteil der falsch gesetzten Bezüge lag bei8%.

Pimentel et al. [PFdL03] stellen fest, dass die Nutzung von Threads hilft, den Co-Text-Ver-lust zu verringern, sofern die Verbindungen zwischen den Nachrichten korrekt eingegebenwerden. Andererseits erkannten sie, dass die Threads den Chat umständlicher machen undden Gesprächsfluss verringern. Daher sei die Strukturierung mit Threads vor allem dannsinnvoll, wenn das Verständnis der Konversation als wichtig erachtet wird. Für zwangloseFreizeit-Chats, bei denen eher ein lockerer Gesprächsfluss im Vordergrund steht, sei dieNutzung von Threads weniger geeignet.

Eine anderer Ansatz für die Reduzierung des Co-Text-Verlusts (P4) ist der Einsatz sog. Ge-sprächstechniken. Das Chat-Tool Mediated Chat 2.0 bietet vier verschiedene Techniken da-für an, wer zu einem bestimmten Zeitpunkt einen Beitrag erstellen kann:

● Free Contribution: Alle Teilnehmer können jederzeit Nachrichten versenden.

● Circular Contribition: Die Teilnehmer sind in einer kreisförmigen Warteschlangeorganisiert und können reihum immer jeweils eine Nachricht versenden.

Abbildung 8: Chat-System HyperDialog


● Single Contribution: Jeder Teilnehmer kann genau eine Nachricht versenden, wobeies keine bestimmte Reihenfolge gibt.

● Blocked / Mediated Contribution: Nur ein bestimmter Teilnehmer (Mediator / Mo-derator) kann Nachrichten versenden.

Es wird empfohlen, die Techniken wie folgt zu kombinieren: Der Moderator stellt das The-ma vor (mediated contribution). Danach gibt jeder Teilnehmer einen ersten Kommentar zuThemenstellung ab (circular contribution). Anschließend wird ausgewählt (single contri-bution) welcher der Kommentare in offener Diskussion (free contribution) diskutiert wird.Dieser Zyklus - Thema, Kommentare, Abstimmung und offene Diskussion - sollte dreimalwiederholt werden.

Die Hypothese war, dass durch die Einteilung der Konversation in bestimmte Phasen, derCo-Text-Verlust verringert wird. Bei der Evaluierung des Tools wurde festgestellt, dass Co-Text-Verlust ausschließlich während der Phase der freien Diskussion auftrat. Insgesamtwurde die Häufigkeit des Co-Text-Verlusts auf etwa die Hälfte reduziert.

Mediated Chat 3.0 widmet sich dem Problem der Nachrichtenüberflutung (vgl. Kapitel3.2.6). Nach Veröffentlichung einer Nachricht wartet der Chat-Server eine gewisse Zeit biser die nächste Nachricht veröffentlicht, so dass die Teilnehmer die erste Nachricht in Ruhelesen können. Der Verzögerungszeitraum wird dabei aus der Anzahl der Zeichen der Nach-richt berechnet. Die zwischenzeitlich beim Server eintreffenden Nachrichten werden ineine Warteschlange eingestellt. In der Teilnehmerliste zeigt ein pulsierender grauer Kreisneben dem Namen eines Teilnehmers an, dass dieser gerade eine Nachricht verfasst. Nach-dem der Teilnehmer die Nachricht versandt hat, wird der Kreis schwarz und zeigt damit an,dass eine Nachricht des Teilnehmers in der Warteschlange steht. Solange noch eine seinerNachrichten in der Warteschlange steht, ist der Eingabebereich des Benutzers blockiert. Ersieht, an welcher Position der Warteschlange sich seine Nachricht befindet und hat bis zurVeröffentlichung die Möglichkeit, die Nachricht wieder zurückzuziehen. Wird die Nach-richt dann veröffentlicht, blinkt der Kreis neben dem Name des Teilnehmers kurz auf umso anzuzeigen, dass der Teilnehmer nun "spricht". Damit zeigt auch Mediated Chat einenLösungsansatz zur Herstellung des Bezugs zwischen Personen und ihren Nachrichten (P1)- das Blinken - und zur Visualisierung des Antwortprozesses (P3) - das Pulsieren -.

Bei den Tests von Mediated Chat 3.0 stellte sich heraus, dass der Verzögerungsmechanis-mus für die Benutzer teilweise irritierend war, woraufhin das System so geändert wurde,dass die Teilnehmerliste nach der Reihenfolge der Benutzerbeiträge in der Warteschlangesortiert wurde, mit dem Ziel, auf diesem Wege die Warteschlange sichtbar zu machen. DieVisualisierung des Eingabevorgangs durch den pulsierenden Kreis wurde von den Benut-zern als sehr hilfreich empfunden.

In Mediated Chat 4.0 wurden einige Anpassungen an der Benutzeroberfläche vorgenom-men, mit denen der Eingabevorgang und die Lesbarkeit der Beiträge verbessert wordensind.

Das Problem der Späteinsteiger (vgl. Kapitel 3.2.6) wurde in Mediated Chat 5.0 angegan-gen. Bei dem gewählten Lösungsansatz startet der Diskussionsleiter (Mediator) die Diskus-sion und damit auch die Aufzeichnung der Beiträge auf dem Server. Ein später hinzukom-mender Teilnehmer bekommt alle gespeicherten Nachrichten angezeigt. Sobald der Dis-kussionsleiter die Diskussion beendet, wird die Aufzeichnung gestoppt. Benutzer, die sichdanach einloggen, bekommen die Historie nicht mehr angezeigt. Bei der Überprüfung derFunktionalität im Benutzertest zeigte sich allerdings, dass es bezüglich des Zeitpunkts, abdem ein Späteinsteiger aktiv in die Diskussion einsteigt, keine Unterschiede zwischen Be-nutzern gibt, die den bisherigen Verlauf angezeigt bekommen und denen, die ihn nicht an-gezeigt bekommen.


Mediated Chat 6.0 (vgl. Abbildung 9) führt die Einzellösungen der früheren Versionen zu-sammen und bietet damit Lösungsansätze für die Problemfelder (P1), (P3) und (P4). DieThreads zur Verringerung des Co-Text-Verlusts werden in Mediated Chat 6.0 durch Pfeilezwischen den Nachrichten visualisiert.

4.3.7 Threaded Chat

Threaded Chat wurde von Smith et. al [SCB00] entwickelt. Die Benutzerschnittstelle (sie-he Abbildung 10) ähnelt dabei dem Explorer von Microsoft Windows; die Nachrichten sindin einer Baumstruktur angeordnet. Zur Eingabe eines neuen Beitrags wird zunächst dieNachricht ausgewählt, auf die geantwortet werden soll. Der eingegebene Text erscheint alsneuer "Kindknoten" unterhalb der ausgewählten Nachricht. Bereits während des Eingabe-vorgangs bekommen die anderen Benutzer einen Platzhalter angezeigt und werden so überden Antwortprozess informiert. Neue Nachrichten erscheinen in Fettschrift und die Schriftverblasst mit der Zeit von schwarz nach grau. Sobald der Benutzer eine Nachricht an-geklickt hat, wird diese als gelesen markiert und erscheint nun nicht mehr in Fettschrift.

Der Benutzer hat die Möglichkeit, für ihn uninteressant gewordene Diskussionszweigeauszublenden. Im unteren Bereich von Threaded Chat werden Informationen über die an-deren Chat-Teilnehmer angezeigt.

Beiträge können im Threaded Chat verändert, gelöscht oder an andere Stellen der Strukturverschoben werden. Um Missbrauch zu verhindern, kann der Autor eines Beitrags festle-gen, wer solche Änderungen an seinem Beitrag vornehmen darf.

Threaded Chat stellt in erster Linie einen Lösungsansatz für das Problem des Co-Text-Ver-lusts zur Verfügung (P4). Durch die Art des Eingabevorgangs wird auch der Antwortpro-zess visualisiert (P3).

In Studien zur Benutzerfreundlichkeit wurde der Threaded Chat schlechter als die her-kömmlichen Chat-Systeme bewertet. In Interviews klagten die Nutzer insbesondere dar-über, dass neue Beiträge überall auf dem Bildschirm erscheinen und es keinen Fokuspunktgibt, auf den man sich als Benutzer konzentrieren kann, um keine Nachricht zu verpassen.

Abbildung 9: Chat-System Mediated Chat 6.0


4.3.8 ConcertChat

Das am Fraunhofer-Institut für Integrierte Publikations- und Informationssysteme entwi-ckelte ConcertChat ist ein System für textbasierte Kommunikation im Kontext, wobei mitgemeinsamem Material gearbeitet werden kann. ConcertChat ist in Abbildung 11 zu sehen.

Beim ConcertChat steht ein Whiteboard als gemeinsamer Arbeitsbereich im Mittelpunkt.Dort kann jeder Chat-Teilnehmer Objekte erstellen. Oben rechts werden die gerade anwe-senden Teilnehmer, darunter die Chat-Nachrichten angezeigt. Beiträge können auf Objekteauf dem Whiteboard oder auf andere Textbeiträge verweisen. Die erstellten Beiträge undObjekte auf dem Whiteboard werden archiviert. Dies erlaubt asynchrone Diskussionen, dasSuchen in Beiträgen und die einfache Nachbereitung von Sitzungen.

Mit der Möglichkeit auf andere Textbeiträge zu verweisen, kümmert sich ConcertChatauch um das Problem des Co-Text-Verlusts (P3). Daneben beinhaltet ConcertChat mit derArchivierungsfunktion ebenfalls einen Lösungsansatz für das Problemfeld der Aufzeich-nungen (P5).

Abbildung 10: Chat-System Threaded Chat


Weitere Informationen, Software zum Download sowie eine Testmöglichkeit sind unterhttp://www.ipsi.fraunhofer.de/concert/index_de.shtml?projects/chat zu finden.

4.3.9 factchat

Im Gegensatz zum ConcertChat werden beim factchat (vgl. [HHSM05]) nicht beliebigeObjekte, sondern die Chat-Beiträge selbst in einem gemeinsamen Arbeitsbereich darge-stellt (siehe Abbildung 12). Jeder Chat-Teilnehmer kann dort seine Nachrichten frei plat-zieren. Sobald er die Nachricht mit der Eingabetaste bestätigt, wird diese auch bei den an-deren Chat-Teilnehmern angezeigt, und zwar mit der dem Verfasser zugeordneten Hinter-grundfarbe. Während des Eingabevorgangs sehen die anderen Chat-Teilnehmer an der ent-sprechenden Stelle eine leere "Chatblase".

Ältere Nachrichten verblassen im Laufe der Zeit, die neueste ist immer am deutlichsten zusehen. Wie viele Nachrichten gleichzeitig angezeigt werden, kann über einen Regler ge-steuert werden. Vergangene Chat-Gespräche kann man wie auf einem Videoband abspielensowie vor- und zurückspulen.

Der Bezug zwischen Nachrichten kann einerseits durch die vom Verfasser gewählte Positi-on sichtbar gemacht werden, andererseits gibt es aber auch die Möglichkeit, Chat-Nach-richten mittels Verbindungslinien direkt zueinander in Bezug zu setzen.

Bei factchat hat der Benutzer selbst die Kontrolle über die Positionierung der Nachrichten(P4). Daneben macht factchat den Antwortprozess sichtbar (P3). Die Möglichkeiten zur er-neuten Wiedergabe des Gesprächsverlaufs sind eine Lösung für das Problem der Aufzeich-nungen (P5). Zudem wird über die Farbe ein Bezug zwischen Personen und deren Nach-richten geschaffen (P1).

Abbildung 11: Chat-System Concert-Chat

http://www.ipsi.fraunhofer.de/concert/index_de.shtml?projects/chat


Factchat kann unter http://www.factchat.com getestet werden.

4.3.10 ThreadChat

ThreadChat [HoWe05] wurde als Werkzeug für das kooperative Lernen in kleinen Grup-pen entwickelt. Dabei ermöglicht die Persistenz der Chat-Räume, ähnlich wie bei dem Sys-tem Babble, sowohl synchrone als auch asynchrone Kommunikation. Der aktuelle Statusder Teilnehmer wird über verschiedene Symbole angezeigt, die den Grad der Aktivität desBenutzers widerspiegeln. So wird beispielsweise ein Benutzer, der gerade einen Beitragverfasst, mit dem Symbol "Schreibend" gekennzeichnet.

Der Benutzer hat beim Verfassen eines Beitrags die Möglichkeit einen Bezugsbeitrag aus-zuwählen. Für die Anzeige der Nachrichten kann er zwischen zwei Ansichten wählen: Inder Listenansicht werden die Beiträge in chronologischer Reihenfolge angezeigt. In derBaumansicht werden die Bezüge zwischen den Beiträgen visualisiert. Abbildung 13 zeigtdie Baumansicht.

Um die Probleme der Baumdarstellung, insbesondere hinsichtlich des fehlenden Fokus-punktes für neue Nachrichten zu mindern, empfehlen Holmer und Wessner für die synchro-ne Diskussion die Listenansicht zu verwenden. Für den Einstieg in eine laufende Diskussi-

Abbildung 13: Chat-System Thread Chat

Abbildung 12: Chat-System factchat

http://www.factchat.com/


on und zur asynchronen Diskussion wird die Verwendung der Baumansicht empfohlen.

ThreadChat bietet die Möglichkeit eines Exports in das Datenformat ChatML. Mit Hilfedes Werkzeugs ChatLine können aus den Exporten weitere Visualisierungen erstellt wer-den.

Mit der Anzeige von Aktivität und Status zeigt ThreadChat Lösungsansätze für die Sicht-barkeit des Zuhörers (P2) und macht den Antwortprozess sichtbar (P3). Außerdem widmetsich ThreadChat dem Problem des Co-Text-Verlusts (P4) sowie dem Thema der Aufzeich-nungen (P5).

4.3.11 MMChat

Zur Verbesserung der unübersichtlichen Struktur von ThreadedChat (vgl. Kapitel 4.3.7)schlägt Hesse [Hes06] ein Mindmap- oder Baumlayout vor. Die Verwendung von Raumund Farbe bei der Darstellung soll dem Benutzer erleichtern, der Diskussion zu folgen undsich die Inhalte einzuprägen. Durch die Anordnung der Beiträge und die graphische Dar-stellung von Bezügen zwischen den Nachrichten soll der Gesprächsteilnehmer leicht einenÜberblick über die entstehende Diskussion bekommen.

Hesse stellt dabei verschiedene Visualisierungsvarianten vor. Neben Baumdarstellungenmit der Wurzel oben bzw. links, zeigt er auch eine kreisförmige Anordnung mit der Wurzelin der Mitte, wie sie auch bei der Kreativitäts- und Strukturierungstechnik des Mindmap-ping verwendet wird. Das mindmap-artige Layout hat Hesse gewählt, weil diese Darstel-lungsart den Benutzer dabei unterstützt, ein gedankliches Modell von etwas Abstraktem -wie einer textbasierten Unterhaltung zu - bekommen. Die Redensart, eine Diskussion gehein die eine oder andere Richtung, zeigt ebenfalls, dass Menschen dazu neigen, abstraktenBegriffen räumliche Eigenschaften zuzuordnen. Die Gültigkeit dieser Annahmen und dieGebrauchstauglichkeit (Usability) des gewählten Layouts müssen - so Hesse - noch in derPraxis getestet werden.

Der von Hesse erstellte Prototyp hat einen Hauptanzeigebereich, in dem die Nachrichten

Abbildung 14: Chat-System MMChat


zu sehen sind. Wenn der Gesprächsverlauf nicht mehr komplett in diesen Anzeigebereichpasst, erscheint zusätzlich ein Überblickbereich, in dem immer die komplette Unterhaltunganzeigt wird. Der im Hauptanzeigebereich aktuell dargestellte Ausschnitt wird im Über-blickbereich durch ein rotes Rechteck markiert.

Der aktuelle Ausschnitt kann durch Ziehen mit der Maus oder Klicken im Übersichtsbe-reich verändert sowie durch Scrollen mit der Maus verkleinert oder vergrößert werden. Umneuere Nachrichten hervorzuheben und den zeitlichen Verlauf darzustellen, werden zeitab-hängig verschiedene Rot-Schattierungen für den Hintergrundbereich der Nachrichten ver-wendet.

Neben der Fertigstellung der Mehrbenutzerversion schlägt Hesse folgende Erweiterungenvor:

● Die derzeit realisierte Funktion, dass die Anwendung automatisch neue Nachrichtenfokussiert, könnte im Mehrbenutzermodus als störend und verwirrend empfundenwerden. Es sollten daher Methoden entwickelt werden, die dem Benutzer zwarmehr Steuerungsmöglichkeiten geben, den manuellen Steuerungsaufwand jedochtrotzdem möglichst gering halten.

● Aktive Threads könnten im Überblickbereich besonders kennzeichnet werden(Heatmap).

● Neben der Baumdarstellung könnte der Gesprächsverlauf parallel in einer listenba-sierten Darstellung angezeigt werden. Durch Auswahl einer Nachricht in der Lis-tenansicht, könnte der Fokus in der Baumansicht auf diese Nachricht positioniertwerden.

● Der Abstand der Nachrichten könnte an den Faktor Zeit geknüpft werden.

Beim MMChat steht die Lösung des Problems des Co-Text-Verlusts (P4) im Vordergrund.

4.3.12 Nutzung von synchronen Mehrbenutzereditoren als Chat-System

Chen und Sun [ChSu02] schlagen vor, synchrone Mehrbenutzereditoren als Chat-Systemzu nutzen. Sie stellen fest, dass es eine Vielzahl von Ähnlichkeiten zwischen Mehrbenutze-reditoren und Standard-Chat-Systemen gibt. Dabei entspricht das Chat-Protokoll dem ge-meinsam zu bearbeitenden Textdokument beim Mehrbenutzereditor. Während jedoch beimChat neue Beiträge immer nur am Ende angehängt werden, können beim Mehrbenutzeredi-tor beliebige Einfüge- und Löschoperationen durchgeführt werden.

Da bei synchronen Mehrbenutzereditoren jedes Zeichen einzeln übertragen wird, erscheintauch der Antwortprozess für die anderen Chat-Teilnehmer (P3). Da die Stelle, an der eineEingabe erscheint, vom Verfasser selbst gewählt werden kann, kann das Problem einesmöglichen Co-Text-Verlusts (P4) reduziert werden. Desweiteren besteht die Möglichkeit,fehlerhafte Eingaben zu korrigieren, so dass das Gesprächsprotokoll insgesamt übersichtli-cher wird (P5).

Aber es gibt auch Nachteile. Dadurch, dass die Benutzer jederzeit überall im DokumentÄnderungen vornehmen können, besteht die Gefahr, dass ein Benutzer absichtlich oder un-absichtlich Nachrichten anderer Benutzer löscht. Um diese Gefahr zu vermeiden, regenChen und Sun die Einführung eines Sperrmechanismus an, der sicherstellt, dass jeder Be-nutzer nur die eigenen Nachrichten löschen bzw. verändern kann.

Ein weiteres Problem bei der Nutzung von synchronen Mehrbenutzereditoren als Chat-System besteht darin, dass es keinen festen Fokuspunkt gibt, an dem neue Nachrichten an-gezeigt werden.


4.4 Übersicht In nachfolgender Tabelle wird nochmals übersichtlich dargestellt, welches der untersuchtenChat-Systeme sich welchem der fünf Problembereichen widmet. Gleichzeitig stellen wirdem gegenüber, für welche der Problembereiche das zu entwickelnde Chat-System MuVi-Chat Lösungen bereitstellen sollte.

BezugPersonen - Nachrichten

(P1)

Sichtbarkeit Zuhörer

(P2)

Sichtbarkeit Antwort-prozess

(P3)

Co-Text-Verlust

(P4)

Aufzeich-nungen

(P5)

Status Client x

Flow Client x x

Fugue x x x

Chat Circles x x x

Babble x x

Mediated Chat x x x

Hyper Dialog x

Threaded Chat x x

Concert Chat x x

factchat x x x x

Thread Chat x x x x

MMChat x

Mehrbenutzereditor x x x

MuVi-Chat x x x

Tabelle 2: Übersicht über die von den Chat-Systemen behandelten Problemfelder

Vor allem factchat deckt die gleichen Problembereiche ab, wie das geplante System MuVi-Chat. Im nächsten Kapitel werden wir uns deshalb einerseits der Frage widmen, ob für dieUmsetzung der Anforderungen an das MuVi-Chat-System (vgl. Kapitel 3.3) auf Konzepteaus den vorgestellten Lösungen zurückgegriffen werden kann. Andererseits prüfen wir,welche Aspekte die bisher existierenden Lösungen nur unzureichend erfüllen.

4.5 Konsequenzen hinsichtlich des zu entwickelnden Sys-temsFür das im Rahmen dieser Arbeit schwerpunktmäßig zu behandelnde Problem des Co-Text-Verlusts (P4) finden sich in den untersuchten Systemen vier verschiedene Lösungs-ansätze:

● Die Positionierung der Nachrichten wird dem Benutzer überlassen. Diese Möglich-keit wurde im factchat gewählt und wird auch beim Einsatz synchroner Mehrbe-nutzereditoren als Chat-System genutzt.

● Die chronologische Reihenfolge der Chat-Beiträge wird beibehalten und die Refe-renzen zwischen den Beiträgen durch Pfeile dargestellt. Die Systeme Concert Chatund Mediated Chat 6.0 nutzen diese Vorgehensweise.


● Einige Systeme (Hyper Dialog, Threaded Chat, ThreadChat) stellen die Beiträge inForm von Threads dar, nutzen also eine horizontale Baumdarstellung. Diese Dar-stellungsform stammt aus dem Bereich der asynchronen computerunterstütztenKommunikation und wird sowohl im Usenet und bei Web-Foren aber auch für E-Mail eingesetzt.

● MMChat zeigt eine Lösung, die wie die Thread-Darstellung auf der baumartigen lo-gischen Struktur eines Gesprächsverlaufs basiert, sich aber schwerpunktmäßig derräumlichen Darstellung der Baumstruktur widmet.

MuVi-Chat soll laut Anforderung (A3) mehrere Visualisierungsalternativen bereitstellen.Die in Kapitel 4.3 vorgestellten Systeme bieten entweder nur eine Art der Visualisierung anoder stellen lediglich eine zusätzliche Visualisierung neben der klassischen Darstellung zurVerfügung. Die Bereitstellung verschiedener Visualisierungen setzt aber voraus, dass diePosition vom System und nicht vom Benutzer festgelegt wird. Dies hat zudem den Vorteil,dass der Benutzer sich nicht darum kümmern muss, wo und wie seine Nachricht dargestelltwird, sondern sich ganz auf die Inhalte konzentrieren kann.

Abgesehen vom ersten Lösungsansatz, bei dem die Chat-Beiträge durch den Benutzer posi-tioniert werden, könnte MuVi-Chat also auch Visualisierungen beinhalten, die den obendargestellten weiteren drei Lösungsansätzen zur Beseitigung des Problems des Co-Text-Verlusts (P4) entsprechen. Der Unterschied zu den bereits existierenden Systemen liegt vorallem darin, dass mehrere Visualisierungsalternativen bereitstehen sollten, aus denen derBenutzer diejenige auswählen kann, mit der er am besten zurecht kommt.

Nach den Anforderungen (A4) und (A5) soll MuVi-Chat auch die Möglichkeit bieten, Ge-sprächsverläufe zu speichern und später nochmals anzusehen und abzuspielen. Bei den un-tersuchten Lösungen wird das Problem der Aufzeichnungen (P5) in erster Linie dadurchgelöst, dass Chat-Beiträge auch über die Dauer der Sitzung hinweg zur Verfügung stehen(Persistenz des Chat-Raumes). Damit können frühere Chat-Beiträge in gleicher Weise an-gezeigt werden, wie die des aktiven Chats. Factchat bietet zwar auch Abspielmöglichkei-ten, der Benutzer muss dazu aber einen Schieberegler über eine Zeitskala bewegen. Im Ge-gensatz dazu sollte die Wiedergabe beim MuVi-Chat nach dem Klicken einer Schaltflächeautomatisch ablaufen (Replay-Modus).

Die Erfahrungen mit den verschiedenen alternativen Chat-Systemen zeigen, dass der Usa-bility der Systeme ein hoher Stellenwert einzuräumen ist. Dabei ist die Art der Darstellungneuer Chat-Nachrichten wichtig, insbesondere dann, wenn neue Chat-Nachrichten nichtimmer an der gleichen Stelle angezeigt werden. Einerseits sollte der Benutzer keinenNachrichteneingang verpassen, andererseits nicht durch die Art der Darstellung verwirrtwerden.

Beschreibung der Lösungsidee 31

5 Beschreibung der LösungsideeDas zu entwickelnde Chat-System soll Lösungen für das Problem des Co-Text-Verlustsaufzeigen. Es sind daher, neben den Standard-Chat-Funktionalitäten, Mechanismen zuimplementieren, die es zunächst ermöglichen, den Bezug zwischen einzelnen Gesprächs-beiträgen herzustellen, um diesen dann in geeigneter Form zu visualisieren.

Bevor wir die Anforderungen an das zu entwickelnde System analysieren und konkretisie-ren, stellen wir einige Vorüberlegungen zur Referenzierung von Beiträgen und zur Nutzungvon Baumstrukturen zur Visualisierung an.

5.1 Referenzierung von anderen BeiträgenEin Chat-Beitrag kann sich inhaltlich

● auf keinen anderen Beitrag ,

● auf genau einen früheren Beitrag

● oder auf mehrere frühere Beiträge

beziehen.

Ein Gesprächsbeitrag hätte beispielsweise dann keinen Bezugsbeitrag, wenn der Verfasserein vollkommen neues Thema anspricht. Genau ein Bezugsbeitrag wäre typisch bei derAntwort auf eine Frage. Mehrere Bezugsbeiträge wären zum Beispiel dann vorhanden,wenn ein Gesprächsteilnehmer mehrere Beiträge zusammenfasst, ein Fazit zieht oder ver-sucht, abschweifende Diskussionszweige wieder zum Hauptthema zurückzuführen.

Zu überlegen ist nun, ob das zu entwickelnde System all diese Möglichkeiten abbildensollte.

Eine Frage dabei ist, ob es möglicherweise sinnvoll ist, einen Referenzierungszwang ein-zuführen und das Absenden einer Nachricht nur dann zuzulassen, wenn eine Referenz zueiner Bezugsnachricht gesetzt ist. Die Erfahrungen bei der Nutzung des Chat-Systems Hy-perDialog (vgl. Kapitel 4.3.6) haben gezeigt, dass fehlende und falsch gesetzte Bezüge dieHauptursache dafür waren, dass das Problem des Co-Text-Verlusts durch die Verwendungvon Referenzierungen nicht beseitigt werden konnte.

Vorteil bei einem Referenzierungszwang wäre, dass die Referenzierung nicht vergessenwird. Allerdings würden durch die Pflicht, sich auf einen anderen Beitrag beziehen zumüssen, die inhaltlichen Freiräume des Gesprächs stark eingeschränkt. Dies könnte für be-stimmte Einsatzszenarien zwar gewünscht sein. Es besteht aber die Gefahr, dass die Akzep-tanz des Systems darunter leidet und möglicherweise Bezugsbeiträge nicht aufgrund desinhaltlichen Zusammenhangs gesetzt werden, sondern nur um das System zu "überlisten".

Aus diesem Grund entscheiden wir uns dafür, die Referenzierung nicht zwingend vorzu-schreiben.

Eine weitere Überlegung ist, ob das System die Möglichkeit bieten soll, mehrere frühereBeiträge auszuwählen. Betrachtet man alle tatsächlich möglichen Zusammenhänge zwi-schen den Gesprächsbeiträgen, wäre es sicher sinnvoll eine Mehrfachreferenzierung zu-zulassen. Durch diese Möglichkeit würde sich aber die Anzahl der maximal möglichen Be-ziehungen zwischen den Beiträgen stark erhöhen.

Wenn man bei n Gesprächsbeiträgen nur die Einfachreferenzierung zulässt, entsteht eineBaumstruktur mit maximal n-1 Beziehungen zwischen den Gesprächsbeiträgen. Erlaubtman eine Mehrfachreferenzierung, erhält man einen gerichteten Graphen, mit bis zu


n⋅n−1/2 möglichen Beziehungen.

Im Gegensatz zu allgemeinen Graphen können Baumstrukturen immer überschneidungs-frei gezeichnet werden [Wikipedia07e]. Aus diesem Grund sind Baumstrukturen leichterdarzustellen als allgemeine Graphen.

Wir entscheiden uns deshalb dafür, bei dem zu entwickelnden Chat-System keine Mehr-fachreferenzierung zuzulassen.

Im folgenden Kapitel untersuchen wir, welche Möglichkeiten es zur Visualisierung vonBaumstrukturen gibt.

5.2 Nutzung von Baumstrukturen zur VisualisierungBäume sind meist dann das Visualisierungsmittel der Wahl, wenn es darum geht, hierarchi-sche Zusammenhänge oder Beziehungen darzustellen. Beispiele hierfür sind Stammbäume,Organigramme oder auch Verzeichnisstrukturen.

Durch die Verwendung einer Baumstruktur bei der Visualisierung eines Chats können Be-ziehungen der Nachrichten untereinander sichtbar gemacht werden. Der manchmal ver-wendete Ausdruck der "sich verzweigenden Diskussionen" ist ein Hinweis darauf, dassBaumstrukturen für die Visualisierung von Diskussionen gut geeignet sind. Wenn wir beider Chat-Visualisierung pro Beitrag maximal einen Bezugsbeitrag zulassen, erhalten wireine Baumstruktur. Dabei sind die einzelnen Chat-Beiträge die Knoten, die Bezüge zwi-schen den Beiträgen die Kanten. Da nicht unbedingt zu jedem Beitrag ein Bezugsbeitragexistiert - beispielsweise wenn ein neues Thema angesprochen wird -, können mehrereBäume, also ein sog. Wald entstehen.

5.2.1 Möglichkeiten der Visualisierung von Bäumen

Es gibt verschiedene Möglichkeiten, Baumstrukturen graphisch darzustellen. Die nahelie-gendste Möglichkeit ist, die Knoten durch geometrische Formen (z. B. Rechtecke) und dieKanten als Linien zwischen diesen Formen darzustellen.

Weitere Visualisierungen von Baumstrukturen sind Treemaps, Icicle Trees und Tree Rings(vgl. [BaNe01]). Abbildung 15 zeigt diese Visualisierungstypen.

Bei der Visualisierung der Chat-Kommunikation sollte der Text jedes Chat-Beitrags im di-rekten Zusammenhang mit dem zugehörigen Knoten angezeigt werden. Dies ist beim TreeRing aufgrund der kreisförmigen Anordnung nur schwer möglich. Beim Icicle Tree werdendie Kindknoten immer kleiner und bieten daher ebenfalls nicht ausreichend Platz für denNachrichtentext. Auch bei der Treemap gibt es keine übersichtliche Möglichkeit, den Textanzuzeigen.

Abbildung 15: Visualisierungen für Baumstrukturen


Bei den Baumdarstellungen mit geometrischen Formen und dazwischenliegenden Linienkann der Text des Chat-Beitrags innerhalb der jeweiligen geometrischen Form angezeigtwerden. Sie sind daher für die Visualisierung der Chat-Kommunikation besser geeignet.

Die Visualisierung ist von folgenden Parametern abhängig:

● Position der Wurzel

● Position der Knoten bezüglich Eltern und Geschwisterknoten

● Möglichkeit des Ein- und Ausblendens von Zweigen

● Gestaltung der Knoten

● Gestaltung der Kanten

Für bestimmte Einsatzbereiche haben sich typische Visualisierungen von Baumstrukturendurchgesetzt, einige davon führen wir in Tabelle 3 auf:

Beispiele Position derWurzel

Position der Knoten Kanten Zweige ein- und aus-blendbar

Dateibaum links oben rechts von Elternknotenunter/über Geschwister-knoten

Verbindungslinie mit rechten Win-keln

ja

Mindmap Mitte kreisförmig um den Wur-zelknoten

Kurve ja

Organigramm oben unter dem Elternknotenneben oder unter/über dem Geschwisterknoten

Verbindungslinie mit rechten Win-keln

nein

Tabelle 3: Typische Einsatzbereiche bestimmter Baumvisualisierungen

5.2.2 Anforderungen an die Baumdarstellungen

Für die ansprechende Darstellung von Bäumen gibt es einige grundlegende Anforderungenund ästhetische Regeln. So nennen Buchheim et al. [BJL02] die folgenden Regeln:

(R1) Die y-Koordinate eines Knotens entspricht der Ebene des Knotens.

(R2) Die Kanten kreuzen sich nicht und Knoten auf dem selben Level haben einen vorgegebenen horizontalen Minimalabstand.

(R3) Unterbäume, die strukturgleich sind, werden bis auf Verschiebung gleich gezeichnet.

(R4) Die Reihenfolge der Kinder eines Knotens wird in der Zeichnung darge-stellt.

(R5) Der Zeichenalgorithmus arbeitet symmetrisch, das heißt, dass die Zeichnungder Spiegelung des Baumes gleich der Spiegelung des gezeichneten Baumesist.

Setzen wir Baumstrukturen für die Visualisierung eines Chats ein, müssen wir zusätzlichbeachten, dass der Baum erst nach und nach durch das Eintreffen der einzelnen Chat-Bei-träge wächst. Für die Darstellung solcher wachsenden Baumstrukturen können weitere An-forderungen bezüglich des Layouts definiert werden:

(R6) Wenn neue Knoten zum Baum hinzukommen, sollte sich die Position der


bereits vorhandenen Knoten möglichst nicht ändern.

(R7) Die Darstellung sollte möglichst kompakt sein, d. h. es sollte möglichst we-nig Platz ungenutzt bleiben.

Inwieweit diese Regeln eingehalten werden, ist vom jeweiligen Layoutalgorithmus abhän-gig. So erfüllen der Algorithmus von Walker und seine Verbesserung durch Buchheim et al.[BJL02] die Anforderungen (R1) bis (R5).

5.2.3 Berücksichtigung des Faktors Zeit

Durch die Verwendung von Baumstrukturen bei der Chat-Visualisierung werden die Refe-renzen zwischen den Beiträgen sichtbar, allerdings mit der Folge, dass die beim Standard-Chat übliche chronologische Reihenfolge der Nachrichten nicht mehr erkennbar ist. Nebenden Bezügen zwischen den Nachrichten ist aber gerade der Zeitpunkt der Nachricht einewichtige Information, die dazu beiträgt, dass die Chat-Teilnehmer dem Gesprächsverlauffolgen können.

Wir müssen also nach Lösungen suchen, den Faktor Zeit bei der Baumdarstellung zu be-rücksichtigen. Eine Möglichkeit ist, eine der Achsen der zweidimensionalen Baumdarstel-lung als Zeitachse zu verwenden, eine andere Möglichkeit ist, die älteren Nachrichten lang-sam auszublenden. Auch unter den in Kapitel 4 untersuchten Systemen gibt es Beispielefür diese Wege der Zeitdarstellung. Flow Client und Fugue nutzen eine Zeitachse, ChatCircles, factchat und MMChat unterschiedliche zeitabhängige Farbabstufungen.

Wird die Zeit bei der Darstellung berücksichtigt, gibt es zwei Alternativen hinsichtlich derAktualisierung der Darstellung. Einerseits könnte man die Darstellung fortlaufend aktuali-sieren, andererseits könnte das System auch so eingerichtet werden, dass die Ansicht im-mer nur beim Eintreffen einer neuen Nachricht aktualisiert wird.

5.3 Analyse der AnforderungenAuf Basis der Anforderungen aus Kapitel 3.3 erstellen wir nun eine Anforderungsspezifi-kation, bestehend aus dem Anwendungsfallmodell und dem Domänen-Klassenmodell. DieAnforderungsspezifikation wird um eine grobe Beschreibung der Benutzeroberfläche er-gänzt.

Zunächst listen wir hier nochmals die Anforderungen aus Kapitel 3.3 auf:

(A1) Basis-Chat-Funktionalität

(A2) Herstellung von Bezügen zwischen Beiträgen

(A3) Visualisierung der Beiträge sowie der Bezüge zwischen den Beiträgen

(A4) Speicherung des Gesprächsverlaufs

(A5) Replay-Modus




(A9) Open Source

Bei der Anforderungsanalyse stehen die funktionalen Anforderungen im Vordergrund. DieAnforderungen (A6) bis (A9) müssen vor allem bei der Implementierung berücksichtigtwerden.


5.3.1 Akteure

Akteure sind die Benutzer des Systems. Für unser zu entwickelndes Chat-System habenalle Teilnehmer die gleichen Nutzungsmöglichkeiten, so dass es nicht erforderlich ist, zwi-schen mehreren Akteuren zu unterscheiden. Den nutzenden Akteur des Systems bezeich-nen wir als Chat-Teilnehmer.

5.3.2 Anwendungsfälle

Für die geforderten Basis-Chat-Funktionalität (A1) lassen sich Anwendungsfälle für dieAccountverwaltung, die Raumverwaltung und die Erstellung von Chat-Beiträgen ermitteln:

(AF1) Account erstellen

(AF2) Account löschen

(AF3) Passwort ändern

(AF4) Systemanmeldung

(AF5) Systemabmeldung

(AF6) Chat-Raum betreten

(AF7) Chat-Raum erstellen

(AF8) Chat-Raum verlassen

(AF9) Beitrag erstellen.

Aus der Anforderung der Herstellung von Bezügen zwischen den Beiträgen (A2) ergibtsich ein weiterer Anwendungsfall:

(AF10) Bezugsbeitrag auswählen

Weitere Anwendungsfälle erhält man aus den Anforderungen zur Speicherung des Ge-sprächsverlaufs (A4) und für den Replay-Modus (A5).

(AF11) Chat-Protokoll speichern

(AF12) Chat-Protokoll laden

(AF13) Chat-Protokoll abspielen

Nachfolgend stellen wir die wichtigsten Beziehungen zwischen den Anwendungsfällendar. Falls bei der Systemanmeldung noch auf keine gespeicherten Zugangsdaten zugegrif-fen werden kann, wird der Benutzer aufgefordert, einen neuen Account zu erstellen. DerAnwendungsfall (AF1) "Account erstellen" erweitert daher den Anwendungsfall "Sys-temanmeldung" (AF4). Wenn der Chat-Teilnehmer bei der Systemabmeldung noch mit ei-nem oder mehreren Chat-Räumen verbunden ist, soll er diese automatisch verlassen. Dahererweitert der Anwendungsfall (AF8) "Chat-Raum verlassen" den Anwendungsfall (AF5)"Systemabmeldung". Falls ein Benutzer einen Chat-Raum betreten will, der noch nichtexistiert, wird dieser automatisch erstellt. Der Anwendungsfall (AF7) "Chat-Raum erstel-len" erweitert also den Anwendungsfall (AF6) "Chat-Raum betreten". Beim Erstellen einesBeitrags kann der Benutzer optional einen Bezugsbeitrag auswählen. Damit erweitert derAnwendungsfall (AF10) "Bezugsbeitrag auswählen" den Anwendungsfall (AF9) "Beitragerstellen". Schließlich hat der Benutzer die Möglichkeit, ein geladenes Chat-Protokoll ab-zuspielen, d. h. der Anwendungsfall (AF13) "Chat-Protokoll abspielen" erweitert den An-wendungsfall (AF12) "Chat-Protokoll laden".

Abbildung 16 zeigt die Anwendungsfälle im Überblick :


Für die Anwendungsfälle wurden textuelle Spezifikationen erstellt. Beispielhaft führen wirnachfolgend die Spezifikation für den Anwendungsfall (AF9) "Beitrag erstellen" auf.

Abbildung 16: Anwendungsfalldiagramm


5.3.3 Domänen-Klassenmodell

Nachfolgend werden Gegenstände und Sachverhalte aus der Problemwelt identifiziert undim Domänen-Klassenmodell modelliert. Bei dem zu entwickelnden Chat-Systems gibt esChat-Teilnehmer mit ihren Zugangsinformationen, Chat-Räume, Chat-Beiträge sowie ge-speicherte Chat-Protokolle.

Jeder Chat-Teilnehmer hat einen Nicknamen und ein Passwort, mit dem er sich am Systemanmeldet. Wir können somit eine Klasse "Chat-Teilnehmer" mit entsprechenden Attributenmodellieren. Als weitere Klasse können wir den Chat-Raum mit dem Raumnamen als At-tribut festlegen. Ein Chat-Teilnehmer kann sich in mehren Chat-Räumen aufhalten. Umge-kehrt können sich in einem Chat-Raum auch mehrere Benutzer aufhalten. GespeicherteChat-Protokolle enthalten die Konversation eines Chat-Raumes. Ein Chat-Protokoll hat alsAttribut den Namen der Datei, in der es gespeichert ist. Die Konversation aus einem Chat-Raum kann in mehreren Chat-Protokollen gespeichert werden (z. B. zu verschiedenenZeitpunkten). Die Chat-Teilnehmer verfassen Chat-Beiträge, die jeweils einem Chat-Raumzugeordnet sind. Zu einem Chat-Beitrag gehören Uhrzeit und Text als Attribute. EinemChat-Raum können mehrere Chat-Beiträge zugeordnet sein. Ein Chat-Beitrag kann sichauf einen anderen Chat-Beitrag beziehen.

Die so identifizierten Klassen mit ihren Attributen und Assoziationen sind im Domänen-Klassendiagramm in Abbildung 17 dargestellt:

use case Beitrag erstellenactors

Chat-Teilnehmerprecondition

Der Chat-Teilnehmer ist am System angemel-det und hat einen Chat-Raum betreten.

main flowDer Chat-Teilnehmer gibt seinen Chat-Bei-trag ein und gibt diesen frei.

alternative flow Bezugsbeitrag angebenDer Chat-Teilnehmer wählt vor der Eingabe/Freigabe seines Chat-Beitrags einen Bezugs-beitrag aus (extension point: "Bezugbeitragauswählen")

postconditionDer Beitrag wurde an alle Chat-Teilnehmerin diesem Raum übermittelt. Der Zusammen-hang zwischen Beitrag und Bezugsbeitragwird in geeigneter Visualisierung ange-zeigt.

end Beitrag erstellen


5.3.4 Benutzeroberfläche

Wie im Domänen-Klassenmodell festgelegt, soll sich ein Benutzer in mehreren Chat-Räu-men gleichzeitig aufhalten können. Damit ist für jeden Chat-Raum ein eigener Anzeigebe-reich erforderlich. Wir entscheiden uns dafür, jeden Chat-Raum in einem eigenen Fensterdarzustellen. So kann der Benutzer die Größe und Anordnung der einzelnen Chat-Fensternach seinen Wünschen individuell verändern.

Das Gesamtsystem wird über ein Hauptfenster gesteuert. Aus diesem können auch dieKonfigurationsdialoge für die Systemeinstellungen aufgerufen werden.

Wir erläutern nachfolgend die einzelnen Komponenten der Benutzeroberfläche. Währendder Anforderungsanalyse wurden zunächst handschriftliche Skizzen der Benutzeroberflä-che (sog. Mock-ups) erstellt. Nachfolgend zeigen wir aus Gründen der Übersichtlichkeitkeine Skizzen, sondern Teile der fertigen Benutzeroberfläche.

5.3.4.1 Hauptfenster

Im Hauptfenster (Abbildung 18) werden in einer Liste die Chat-Räume angezeigt, zu de-nen aktuell eine Verbindung besteht. Eine weitere Liste enthält die Chat-Protokolle, die ge-rade geöffnet sind. Wenn man auf einen der Einträge der beiden Listen klickt, wird das zu-gehörige Chat-Fenster in den Vordergrund geholt.

Im unteren Bereich des Hauptfensters sieht man den aktuellen Verbindungsstatus zumChat-Server. Durch Klicken der Schaltfläche links oben kann die Verbindung zum Chat-Server auf- bzw. abgebaut werden. Beim Abbau der Verbindung werden sämtliche aktivenChat-Fenster geschlossen.

Abbildung 17: Domänen-Klassendiagramm


Das Hauptfenster enthält die Menüs Datei und Hilfe. Über das Menü Datei erreicht mandie Menüpunkte zum Betreten bzw. Erstellen eines neuen Chat-Raums, zum Laden eineszuvor abgespeicherten Chat-Protokolls sowie Menüpunkte zur Verwaltung der Zugangsda-ten. Bei Aufruf dieser Menüpunkte werden weitere Dialogfenster erzeugt, die in Kapitel5.3.4.2 beschrieben werden.

Das Hauptfenster kann über den Menüpunkt Beenden geschlossen werden. Mit Schließendes Hauptfensters werden auch alle anderen Fenster geschlossen.

5.3.4.2 Dialoge

Der Menüpunkt Zugangsdaten ändern führt zu m Dialogfenster in Abbildung 19, in demDaten zum Chat-Server und zum Benutzer eingegeben werden können.

Abbildung 19: Menüpunkte im Hauptfenster des MuVi-Chat

Abbildung 18: Hauptfenster des MuVi-Chat


Dabei sind die zuletzt verwendeten Benutzerdaten voreingestellt. Im Feld Servernamekann entweder ein Server aus der Liste gewählt oder ein neuer eingegeben werden. Wirddas Feld Neuer Benutzer anlegen ausgewählt, wird ein neuer Benutzer mit den angegebe-nen Daten angelegt.

Über den Menüpunkt Raum betreten / erstellen im Hauptfenster gelangt man zu folgendemDialogfenster:

In der Liste Vorhandene Räume werden die auf dem Server vorhandenen Räume angezeigt.Wählt man einen dieser Räume aus und bestätigt mit der Schaltfläche Betreten, so gelangtman in diesen Raum und erscheint dort unter dem angegebenen Nicknamen. In einem neu-en Fenster wird die Unterhaltung in diesem Raum angezeigt (vgl. Kapitel 5.3.4.3). Gibtman einen Namen ein, der nicht in der Liste auftaucht, wird ein neuer Raum angelegt.

Der Menüpunkt Chat-Protokoll laden öffnet einen Standarddialog zum Öffnen von Datei-en. Das gespeicherte Protokoll wird daraufhin in einem neuen Chat-Fenster angezeigt.

Weitere Dialoge dienen der Eingabe eines neuen Passworts bzw. dem Löschen eines Be-nutzeraccounts.

5.3.4.3 Chat-Fenster

Das Fenster zur Darstellung des Gesprächsverlaufs gibt es in zwei unterschiedlichen Vari-

Abbildung 20: Dialogfenster Verbindungsein-stellungen

Abbildung 21: Dialogfenster Chat-Raum-Einstel-lungen


anten. Die eine Variante wird für die Teilnahme eines Benutzers an einem Chat verwendet(Live Chat), die andere Variante dient dazu, abgespeicherte Protokolle früherer Chats anzu-zeigen (Replay Chat). Abbildung 22 zeigt die beiden Varianten in einer schematischen Dar-stellung.

Die Anordnung der Bedienelemente beim Live Chat wurde so gewählt, dass sie der demBenutzer vertrauten Anordnung der Standard-Chat-Programme (vgl. Kapitel 3.1) möglichstähnlich ist.

Beide Varianten haben einen Anzeigebereich, in dem beim Live Chat die über das Netz-werk eingehenden Nachrichten, beim Replay Chat die Inhalte des gespeicherten Gesprächsangezeigt werden. Bei der Darstellung und Anordnung der Nachrichten können prinzipiellfolgende Attribute berücksichtigt werden:

● der Verfasser der Nachricht

● der Zeitpunkt der Nachricht

● der referenzierte Beitrag (falls vorhanden)

● der Nachrichtentext

Auf die verschiedenen Visualisierungen, die im Anzeigebereich dargestellt werden, gehenwir in Kapitel 5.4 näher ein.

Beim Live Chat wird zudem ein Eingabereich benötigt, in dem der Benutzer seine Chat-Beiträge verfassen kann. Da beim MuVi-Chat die Position der Beiträge vom System undnicht vom Benutzer festgelegt wird, befindet sich das Eingabefeld - wie im Standard-Chat -an einer festen Stelle unterhalb des Anzeigebereichs.

Vor dem Verfassen, spätestens jedoch vor Versand eines Beitrags muss die Möglichkeitbestehen, einen Chat-Beitrag aus dem Anzeigebereich als Bezugsnachricht auszuwählen.Der Referenzbeitrag sollte durch Klicken mit der Maus auf die entsprechende Stelle imAnzeigebereich ausgewählt werden können.

Ein weiteres Element der Benutzeroberfläche des Live Chat ist die Teilnehmerliste, in derdie im Raum anwesenden Chat-Teilnehmer angezeigt werden.

Abbildung 22: Varianten des Chat-Fensters

AnzeigebereichTeilnehmer-

liste

Eingabebereich

Live-Chat-Fenster

Anzeigebereich

Replay-Steuerung

Replay-Chat-Fenster


Bei der Anzeige von gespeicherten Chat-Protokollen wird weder ein Eingabebereich, nocheine Teilnehmerliste benötigt. Das Fenster des Replay Chat enthält stattdessen einen Be-reich für die Steuerung der Wiedergabe der abgespeicherten Chat-Protokolle (siehe Abbil-dung 23).

In diesem Steuerungsbereich hat der Benutzer die Möglichkeit, ähnlich wie bei einemMedia Player die Wiedergabe des Chat-Protokolls in seinem zeitlichen Verlauf zu starten,zu pausieren oder zu beenden. Daneben hat er die Möglichkeit, die Geschwindigkeit derWiedergabe zu verändern.

5.4 VisualisierungsalternativenDas System soll so gestaltet werden, dass mehrere Visualisierungsalternativen ausgewähltwerden können. Dadurch kann jeder Benutzer, unabhängig von anderen Benutzern, die vonihm favorisierte Alternative verwenden.

Alle Visualisierungsalternativen bieten in einem Konfigurationsbereich weitere visualisie-rungsspezifische Einstellmöglichkeiten.

5.4.1 Klassische Visualisierung

Die klassische Visualisierung entspricht dem Standard-Chat-Client, wie er in Kapitel 3.1beschrieben wurde. Das System stellt diese neben den experimentellen neuen Visualisie-rungen zur Verfügung, damit eine schnelle Vergleichsmöglichkeit besteht.

In der klassischen Visualisierung werden dem Benutzer folgende Konfigurationsmöglich-keiten angeboten:

● Schriftgröße

● Schriftfarbe

● Hintergrundfarbe

5.4.2 Listenansicht mit Hervorhebung

Die Idee zur Listenansicht mit Hervorhebung (Highlight List) entstand aus der Überlegungheraus, dem Benutzer eine möglichst vertraute Benutzeroberfläche zur Verfügung zu stel-len und diese um die Möglichkeit der Referenzierung und deren Darstellung zu erweitern.

Bei dieser Ansicht werden die eingehenden Chat-Nachrichten chronologisch in einer Listeangezeigt. Die neueste Nachricht wird fett formatiert. Falls die Nachricht einer Bezugs-nachricht zugeordnet ist, wird auch diese fett dargestellt. Falls diese wiederum eine Be-zugsnachricht hat, wird diese ebenfalls fett markiert usw. Es werden also alle Bezugsnach-richten auf dem Pfad von der aktuellen Nachricht bis zur Wurzel hervorgehoben.

Selektiert der Benutzer mit der Maus eine andere Nachricht, werden zu dieser die Vorgän-ger-Bezugsnachrichten hervorgehoben. Durch die Selektion mit der Maus kann der Benut-zer einen Beitrag auswählen, auf den sein Beitrag Bezug nehmen wird.

Abbildung 23: Replay-Steuerung


Der Benutzer kann folgende Einstellungen nach seinen Wünschen verändern:

● Schriftgröße

● Schriftfarbe

● Hintergrundfarbe

● Hervorhebung für Bezugsnachrichten (fett oder kursiv)

● Hervorhebung für selektierte Nachricht (Schriftfarbe, Hintergrundfarbe)

5.4.3 Baumansichten

Bereits bei unseren Vorüberlegungen haben wir gesehen, dass die Möglichkeiten baumarti-ger Darstellungen vielfältig sind. Wir entscheiden uns, zunächst vier verschiedene Varian-ten bereitzustellen.

Allen gemeinsam ist, dass

● die Chat-Beiträge als farbige Rechtecke und die Bezüge als Linien zwischen diesenRechtecken dargestellt werden,

● jeder Benutzer durch eine bestimmte Farbe repräsentiert wird,

● Beiträge durch Klicken mit der linken Maustaste als Bezugsbeitrag ausgewähltwerden können und danach eine spezielle Auswahlkennzeichnung haben,

● die Größe des Chat-Fensters nach Belieben verändert werden kann.

Der Benutzer kann selbst festlegen, ob die Ansicht beim Eintreffen einer neuen Nachrichtauf diese neue Nachricht positioniert werden soll (Autofokus). Sofern die Autofokus-Funk-tion aktiv ist, wird die Ansicht so verschoben, dass die neue Nachricht in der Mitte des An-zeigebereichs zu sehen ist. Der Verschiebevorgang wird animiert durchgeführt und ist da-

Abbildung 24: Benutzeroberfläche der Listenansicht mit Hervorhebung


mit für den Benutzer gut nachvollziehbar.

Durch Ziehen mit gedrückter linker Maustaste kann der Benutzer den Diskussionsbaum imAnzeigebereich verschieben, durch Ziehen mit gedrückter rechter Maustaste vergrößernund verkleinern. Wenn ein Benutzer auf diesem Wege die Darstellung im Anzeigebereichverändert, kann man davon ausgehen, dass er sich mit früheren Diskussionsbeiträgen be-schäftigten und diese beispielsweise nochmal in Ruhe nachlesen möchte. Damit der Benut-zer dabei nicht gestört wird, sollte in dieser Situation die Ansicht beim Eintreffen neuerNachrichten nicht verschoben werden. Aus diesem Grund wird die Autofokus-Funktion au-tomatisch deaktiviert, sobald der Benutzer die Anzeige durch Verschieben oder Zoom ver-ändert. Durch Klicken der Schaltfläche "Zurücksetzen" wird die Ansicht wieder so posi-tioniert, dass die neueste Nachricht in der Mitte zu sehen ist. Auch eine Veränderung derZoom-Einstellung wird dadurch zurückgesetzt.

Da die Baumansichten einen gewissen Platzbedarf haben, kann eine entstehende Diskussi-on relativ schnell nicht mehr komplett im Anzeigebereich dargestellt werden. Wir greifendeshalb in unserer Lösung einen Vorschlag von Hesse [Hes06] auf und ergänzen die Benut-zeroberfläche um einen Überblickbereich, in dem immer der komplette Gesprächsverlaufzu sehen ist. In diesem Überblickbereich ist der aktuell sichtbare Ausschnitt des Hauptan-zeigebereichs mit einem dunkelgrauen Rechteck unterlegt. Durch Klicken auf eine be-stimmte Position im Überblickbereich wird der Ausschnitt des Hauptanzeigebereichs soverschoben, dass diese Position in der Mitte des Hauptanzeigebereichs dargestellt wird.

Der Benutzer kann die Größe des Überblickbereichs selbst verändern, indem er die Trenn-linie zwischen dem Hauptanzeigebereich und dem Überblickbereich verschiebt.

5.4.3.1 Einfache Baumdarstellung

Die erste Baumvisualisierung verzichtet auf eine Darstellung des Parameters "Zeit". Abbil-dung 25 zeigt die einfache Baumansicht:

Abbildung 25: Benutzeroberfläche der einfachen Baumdarstellung


Der Benutzer kann folgende Einstellungen der Baumdarstellung ändern:

● die Ausrichtung der Baumstruktur (von oben nach unten, von unten nach oben, vonlinks nach rechts oder von rechts nach links)

● die maximale Breite eines Nachrichtenknotens in Pixel

● den Abstand zwischen den Ebenen des Baumes in Pixel

● den Abstand zwischen benachbarten Nachrichten, die auf die gleiche Nachricht ver-weisen

● den Abstand zwischen benachbarten Nachrichten, die auf unterschiedliche Nach-richten verweisen.

5.4.3.2 Baumdarstellung mit Visualisierung der Zeit durch hellere Farben

In einer weiteren Visualisierung wird die Zeit dadurch berücksichtigt, dass ältere Nachrich-ten in helleren Farben und neuere Nachrichten in dunkleren Farben dargestellt werden. Da-mit greift diese Lösungsvariante einen Ansatz auf, der beispielsweise auch im factchat (sie-he Kapitel 4.3.9) verwendet wird. Diese Visualisierung ist in Abbildung 26 zu sehen:

Neben den Einstellungen der einfachen Baumdarstellung kann der Benutzer bei dieser Vi-sualisierung zusätzlich die Zeitspanne bis zum Erblassen einer Nachricht verändern.

Abbildung 26: Benutzeroberfläche der Baumdarstellung mit Visualisierung der Zeitdurch hellere Farben


5.4.3.3 Baumdarstellung mit Visualisierung der Zeit durch das Layout

Die Zeit kann sich auch durch die Position der Nachrichten widerspiegeln. Auch das Chat-System Flow-Client (vgl. Kapitel 4.3.2) positioniert die Chat-Beiträge in Abhängigkeit derZeit.

Bei unserer Baumdarstellung mit Visualisierung der Zeit durch das Layout entspricht die y-Achse der Darstellung der Zeitachse. Diese Visualisierungsvariante ist in Abbildung 27 zusehen.

Dabei kann der Benutzer festlegen, durch wie viele Pixel die Zeitspanne von einer Sekundedargestellt wird.

5.4.3.4 Sequenzielle Baumdarstellung

Bildet man die Zeit linear auf der y-Achse der zweidimensionalen Darstellung ab, wirdsehr schnell klar, dass durch größere Zeitabstände im Gesprächsverlauf viel Platz bei derDarstellung verschwendet wird. Aufgrund dieser Tatsache wurde eine weitere Visualisie-rung erstellt, bei der auf der y-Achse nicht die Zeit, sondern die Reihenfolge der Beiträgedargestellt ist. Der Abstand zwischen den Nachrichten kann vom Benutzer festgelegt wer-den. Diese sequenzielle Baumdarstellung ist in Abbildung 28 zu sehen:

Abbildung 27: Benutzeroberfläche der Baumdarstellung mit Visualisierung der Zeit durchdas Layout


Abbildung 28: Sequenzielle Baumdarstellung

Beschreibung der Implementierung 48

6 Beschreibung der Implementierung

6.1 Eingesetzte Technologien

6.1.1 Systemarchitektur

Für die technische Realisierung des MuVi-Chat kommen folgende Systemarchitekturen undProtokolle in Frage:

● web-basierte Architektur

● Client-Server-Lösung auf Basis des IRC-Protokolls

● Client-Server-Lösung auf Basis des Jabber / XMPP-Protokolls

● proprietäre Client-Server-Lösung

Bei einer web-basierten Systemarchitektur findet die Kommunikation zwischen den Cli-ents und dem Server über das HTTP-Protokoll statt. Um die zeitnahe Anzeige von neuenBeiträgen anderer Clients zu ermöglichen, ist die Nutzung von Techniken für aktive Inhal-te, wie beispielsweise Javascript oder Java-Applets bzw. Java-Servlets nötig. Vorteil einerweb-basierten Lösung ist, dass auf dem PC des Benutzers neben dem Webbrowser keineweitere Software installiert werden muss. Dafür muss aber ein Webserver zur Verfügungstehen, der die Webseiten mit entsprechenden Funktionalitäten bereitstellt.

Bei einer Client-Server-Lösung auf Basis standardisierter Protokolle, wie IRC undJabber / XMPP, kommunizieren Client und Server auf Basis des standardisierten Proto-kolls. Bei beiden Protokollen kann man auf bereits existierende, öffentlich zugänglicheServer bzw. auf vorhandene Open-Source-Serversoftware zurückgreifen und sich auf dieErstellung der Client-Software beschränken.

Bei einer proprietären Client-Sever-Lösung wäre sowohl die Programmierung der Cli-ent-Software als auch die Programmierung der Server-Software erforderlich. Zudem wäredas System nicht zu anderen kompatibel.

Nach den in Kapitel 3.3 definierten Anforderungen soll das System von möglichst vielenNutzern verwendet werden können. Das spricht zunächst für eine web-basierte Systemar-chitektur, da der Benutzer auf seinem Client keine Software installieren muss. Allerdingswird für eine web-basierte Systemarchitektur ein Server benötigt, der den Dienst dauerhaftzur Verfügung stellt, was allerdings mit Kosten verbunden ist.

Aus diesem Grund nehmen wir zunächst die Client-Server-Lösungen mit IRC und Jabberin die engere Wahl. Bei MuVi-Chat ist es erforderlich, dass die Clients neben dem Nach-richtentext Informationen über die Bezugsnachricht übermitteln.

Der Befehlsumfang und die Nachrichtenstruktur sind beim IRC durch das Protokoll bzw.als serverspezifische Erweiterung fest vordefiniert. So sieht eine Nachricht an einen Chan-nel im IRC beispielsweise folgendermaßen aus.

PRIVMSG #testchannel :Das ist der Nachrichtentext.

Zusatzinformationen zu einer Nachricht können beim IRC ausschließlich im Textfeld derNachricht übertragen werden. Würde man man IRC für den MuVi-Chat nutzen, müsste dersendende Client die Informationen über die Bezugsnachricht vor der Übertragung in co-dierter Form in das Nachrichtenfeld einfügen. Der empfangende Client müsste diese wie-derum aus dem Nachrichtenfeld extrahieren. Ein Chat-Teilnehmer mit einem normalenIRC-Client würde die zusätzliche Steuerungsinformation zusammen mit dem Nachrichten-


text angezeigt bekommen.

Im Gegensatz zu IRC ist Jabber mit seiner XML-basierten Nachrichtenstruktur leicht er-weiterbar, so dass die Informationen zur Bezugsnachricht in spezielle XML-Elemente auf-genommen werden können. Jabber-Clients, die diese Erweiterungen nicht verstehen, zei-gen diese gar nicht an.

Aufgrund seiner Flexibilität entscheiden wir uns, wie in der Aufgabenstellung vorge-schlagen, das Jabber-Protokoll zu verwenden.

6.1.2 Jabber

Jabber (englisch für "plaudern", "quasseln") ist eine Sammlung XML-basierter Netzwerk-protokolle für den Austausch von Nachrichten, Statusmeldungen und anderer strukturierterInformation über das Internet nahezu in Echtzeit. Die Grundlage von Jabber bildet dasProtokoll Extensible Messaging and Presence Protocol (XMPP). Jabber wurde 1999 vonJeremie Miller entwickelt. Die IETF hat XMPP 2004 als offiziellen Standard veröffentlicht[Sa04].

Neben Instant-Messaging-Funktionen bietet Jabber Erweiterungen, mit denen Chats meh-rerer Benutzer möglich sind. Das dafür ursprünglich eingesetzte Groupchat 1.0-Protokollwurde zwischenzeitlich durch das Multi-User-Chat- (MUC-)Protokoll ersetzt. MUC ist zuGroupchat 1.0 abwärtskompatibel und bietet hinsichtlich der Vergabe von Rollen undRechten in Räumen zusätzliche Möglichkeiten. Definiert ist MUC in der Protokollerweite-rung XEP-0045.

Die Netz-Architektur von Jabber erinnert an das Simple Mail Transfer Protocol (SMTP):Jeder an das Internet angebundene Jabber-Server kann Nachrichten mit anderen Servernaustauschen. So sind Verbindungen über Anbieter-Grenzen hinweg möglich. Nachrichtenwerden vom Nutzer zum eigenen Server, von dort zum fremden Server und dann zumEmpfänger weitergeleitet. Auch sind isolierte Netzwerke möglich, beispielsweise in Fir-men-Intranets [Wikipedia07d].

Benutzer werden in Jabber über den sog. Jabber Identifier (JID) adressiert, der folgender-maßen aufgebaut ist:

username@hostname/resource

Die Ressource ist dabei eine frei wählbare Zeichenkette. Der JID für einen Chat-Raum istwie folgt aufgebaut:

[email protected]/nickname

Der Jabber-Client baut eine TCP-Verbindung zum Jabber-Server auf. Standardmäßig wirddie Portnummer 5222 genutzt. Über den so entstehenden virtuellen Kanal zwischen beidenEndpunkten sendet dann der Client ein XML-Dokument zum Server und umgekehrt derServer ein XML-Dokument an den Client. Innerhalb dieser XML-Dokumente werden danndie einzelnen Nachrichten, Meldungen, Anfragen und Antworten transportiert. Dieses Ver-fahren nennt man auch XML-Streaming. Wie nachfolgend vereinfacht dargestellt, bildetder XML-Stream einen Umschlag für die versendeten Nachrichten, die auch als XML-Stanzas (englisch für Absatz, Strophe) bezeichnet werden.


|--------------------|| <stream> ||--------------------|| <presence> || <show/> || </presence> ||--------------------|| <message to='foo'> || <body/> || </message> ||--------------------|| <iq to='bar'> || <query/> || </iq> ||--------------------|| ... ||--------------------|| </stream> ||--------------------|

Es werden drei Nachrichtentypen unterschieden, die über den XML-Stream versandt wer-den können:

<message/> Für den Benutzer bestimmte Mitteilungen.

<presence/> Meldungen über die Verfügbarkeit von Teilnehmern

<iq/> Anfrage/Antwort-Mechanismus ("iq" steht für "info/query")

Nachfolgend beschreiben wir beispielhaft einige Nachrichten, wie sie bei einem Multi-User-Chat verwendet werden:

Raum betreten:

<presence to="[email protected]/jabbertester">

</presence>

Diese Nachricht meldet an den Server, dass der aktuell angemeldete Benutzer den Raummit der Bezeichnung "raum" und dem Nickname "jabbertester" betritt. Falls der Raumnicht existiert, wird er auf dem Server angelegt (sofern dies die Konfiguration des Serverszulässt).

Mitteilung versenden und empfangen:

<message to="[email protected]" type="groupchat"><body>

Hallo zusammen.</body>

</message>

Diese Nachricht versendet der Client, wenn der aktuell angemeldete Benutzer eine Nach-richt mit dem Text "Hallo zusammen" an den Chat-Raum übermitteln will.


Der Jabber-Server sendet die Nachricht auch an den versendenden Client zurück. Als ein-gehende Nachricht auf dem Client sieht sie dann folgendermaßen aus:

<message to="[email protected]/Smack" type="groupchat" from="[email protected]/jabbertester">

<body>Hallo zusammen.

</body></message>

Der Name des Chat-Raums sowie der verwendete Nickname stehen jetzt im "from"-Attri-but. Die ankommende Nachricht eines anderen Chat-Teilnehmers sieht wie folgt aus:

<message to="[email protected]/Smack" type="groupchat" from="[email protected]/nocheinjabbertester">

<body>Hallo jabbertester.

</body></message>

Vorhandene Räume auf dem Server ermitteln:

<iq to="conference.127.0.0.1" type="get"><query xmlns="http://jabber.org/protocol/disco#items"></query>

</iq>

Mit dieser Nachricht erfragt der Client vom Server die Inhalte im Dienst "conference". Dadieser Dienst für die Bereitstellung der Chat-Räume verantwortlich ist, kann auf diesemWege eine Liste der auf dem Server vorhandenen Räume abgefragt werden.

<iq to="[email protected]/Smack" from="conference.127.0.0.1" type="result">

<query xmlns="http://jabber.org/protocol/disco#items"><item jid="[email protected]" name="raum1"/><item jid="[email protected]" name="raum2"/>

</query></iq>

In dieser Antwort werden die Räume mit ihrem JID und ihrem Namen als "items" aufgelis-tet.

Neben dieser kurzen Übersicht über Jabber werden wir später noch auf einige für unsereImplementierung wichtige Details von Jabber eingehen.

6.1.3 Progammiersprache

Für die Auswahl der Programmiersprache für das zu entwickelnde System legen wir zu-nächst die Anforderungen fest:

Plattformunabhängigkeit: Die Anwendung sollte ohne Zusatzaufwand auf allen gängigenSystemplattformen (verschiedene Windows-Versionen, verschiedene Unix-Derivate, Li-nux, MacOS) lauffähig sein:

Lizenzkostenfreie Verfügbarkeit: Die Programmiersprache sowie eine entsprechendeEntwicklungsumgebung sollen ohne die Zahlung von Lizenzkosten eingesetzt werden kön-nen.

Objektorientierung: Da für die Erstellung des Programms Konzepte der objektorientier-ten Analyse (OOA), des objektorientierten Entwurfs (OOD) und der objektorientierten


Programmierung angewendet werden sollen, sollte die Programmiersprache ebenfalls ob-jektorientiert sein.

Verfügbarkeit einer geeigneten GUI-Bibliothek: Um die Visualisierungsalternativen zurealisieren, sollte für die Programmiersprache eine Bibliothek verfügbar sein, mit der einegraphische Benutzeroberfläche (GUI) einfach realisiert werden kann.

Verfügbarkeit einer Bibliothek zur Realisierung des Jabber-Protokolls: Um den Da-tentransfer über das Jabber Protokoll möglichst einfach realisieren zu können, wäre dieVerfügbarkeit einer Bibliothek für die Jabber-Funktionen hilfreich.

Aufgrund dieser Anforderungen kamen hauptsächlich Java, C# und Python als möglicheProgrammiersprachen in Frage. Aufgrund der Vorkenntnisse und des Verbreitungsgrads fieldie Entscheidung auf Java.

6.1.4 Verwendete Programmbibliotheken

Objektorientierte Softwareentwicklung zeichnet sich auch durch die Wiederverwendbarkeitvon Komponenten aus. Es wurde daher geprüft, ob es freie Programmbibliotheken gibt, diebei der Entwicklung des Chat-Systems von Nutzen sein könnten. Dabei waren vor allemdie Bereiche der Datenkommunikation mit Jabber sowie die Visualisierung von Graph-Strukturen von Interesse.

6.1.5 Smack

Auf der Jabber-Webseite (http://www.jabber.org) sind Programmbibliotheken für die Ent-wicklung von Jabber-Software aufgelistet. Die Programmbibliothek Smack ist gut doku-mentiert und deckt auch die Protokollerweiterung für den Multi-User-Chat ab. Durch ihrenEinsatz kann die Kommunikation mit dem Jabber-Server über die Nutzung entsprechenderBilbliotheksroutinen realisiert werden. Smack ist Open-Source-Software und wird vonignite realtime (http://www.igniterealtime.org) zur Verfügung gestellt. Zur Anwendungkam die Version 2.2.1.

6.1.6 prefuse

Für die Visualisierung von Graphen bietet das Visualisierungs-Toolkit prefuse Unterstüt-zung. Prefuse ist ein Werkzeug zur Entwicklung interaktiver Anwendungen im Bereich derInformationsvisualisierung; es ist in Java geschrieben und benutzt die Java2D Grafik-Bibliothek [HCL05]. Die zentrale Datenstruktur von prefuse ist ein Graph, also eine Men-ge von Knoten und Kanten zwischen den Knoten. Dieser Datenstruktur wird eine Visuali-sierungsdatenstruktur (Visualization) zugeordnet, in der Informationen zur graphischenDarstellung gespeichert werden. Über die Visualisierungsdatenstruktur wird beispielsweisefestgelegt, wie Knoten und Kanten dargestellt werden (LabelRenderer und EdgeRen-derer), welche Farben die einzelnen Komponenten haben (ColorAction) und in wel-chem Layout (Layout) diese angeordnet werden. Der Visualisierungsdatenstruktur werdendann eine oder mehrere Benutzerschnittstellen (Display) zugeordnet, in der die Elementedargestellt werden und über die der Benutzer mit dem System interagieren kann. Prefuseist ebenfalls Open-Source-Software; verwendet wurde die Version prefuse beta, Release2006.07.15.

6.2 Lösung bestimmter ProblemfelderBevor wir im nächsten Kapitel die Implementierung anhand der Paketstruktur erläutern,zeigen wir zunächst einige der Problemfelder und die dafür gewählten Lösungen auf.

http://www.igniterealtime.org/

http://www.jabber.org/


6.2.1 Zeit

Während bei einigen Chat-Systemen der Server alle Chat-Nachrichten mit Zeitstempelversieht, ist dies bei Jabber im Allgemeinen nicht der Fall. Eine Ausnahme bildet die ver-zögerte Nachrichtenauslieferung. Diese ist für den Multi-User-Chat nach XEP-0045 optio-nal vorgesehen, dabei werden die Nachrichten nach XEP-0203 oder XEP-0091 gekenn-zeichnet und mit einem Zeitstempel versehen.

Bei eingehenden Nachrichten muss der Client prüfen, ob diese eine solche Verzögerungs-kennzeichnung haben. Falls ja, sollte der Client die Zeit aus dem Zeitstempel darstellen,falls nein, die Nachricht selbst mit einem Zeitstempel versehen. Damit würde der Client al-lerdings bei den verzögert ausgelieferten Nachrichten die von der Uhr des Servers angege-bene Zeit, bei anderen Nachrichten die von seiner eigenen Uhr gelieferte Zeit anzeigen.Falls jedoch die Uhren von Server und Client nicht synchron laufen, würde dies zu inkon-sistenten und damit für den Benutzer möglicherweise verwirrenden Zeitangaben führen.

Die zwei möglichen Lösungsalternativen wären also, dass entweder alle Clients die Zeitvom Server verwenden oder dass jeder Client seine eigene Zeit verwendet. Die jeweils an-dere Zeitangabe müsste dann umgerechnet werden. Dazu kann der Client die aktuelle Zeitdes Servers mit einem Jabber-IQ-Paket erfragen und daraus die Zeitdifferenz für die Um-rechnung ermitteln.

Wir entscheiden uns für die Alternative, die lokale Zeit zu verwenden. Damit wird der Be-nutzer nicht dadurch verwirrt, dass sein Chat-Client eine andere Zeit anzeigt als sein Be-triebssystem. Ein weiterer Vorteil ist, dass die Umrechnung nur für verzögert ausgelieferteNachrichten durchgeführt werden muss. Zu beachten ist bei dieser Vorgehensweise aller-dings, dass die Chat-Teilnehmer die gleichen Nachrichten möglicherweise mit unterschied-lichen Zeitstempeln angezeigt bekommen.

Neben möglicher Zeitdifferenzen der Uhren von Server und Client wäre es bei genauer Be-trachtung auch erforderlich, die für die Nachrichtenübertragung zwischen Client und Ser-ver benötigte Zeit in die Berechnung mit einzubeziehen. Da sich diese Verzögerungen inder Regel im Millisekundenbereich bewegen, und die vom Server mitgeteilte Uhrzeit jenach Protokollumsetzung auf Sekunden gerundet ist, werden wir diese vernachlässigen,denn nach dem Protokoll XEP-0082 sind Sekundenbruchteile nur optional .

6.2.2 Eindeutige Identifikation der Beiträge für die Referenzierung

Für die Referenzierung der Bezugsbeiträge ist es erforderlich, dass jeder Beitrag innerhalbeines Chat-Raums über einen Schlüssel eindeutig zu identifizieren ist.

Das XMPP-Protokoll sieht für alle Nachrichtentypen ein optionales Attribut id vor. BeiVerwendung der Programmbibliothek Smack kann das id-Attribut einer Nachricht gezieltmit bestimmten Werten versehen werden. Falls bei einer neu erzeugten Nachricht kein id-Attribut gesetzt ist, wird von Smack automatisch eine id vergeben, die aus einer fünfstelli-gen per Zufallsgenerator sitzungsbezogen erzeugten Zeichenkette sowie einer fortlaufen-den Nummer besteht.

Würde man ausschließlich diese automatisch generierte id verwenden, um Beiträge zuidentifizieren, ist es zwar unwahrscheinlich, aber nicht ausgeschlossen, dass zwei Chat-Teilnehmer eine gleiche id generieren. Nimmt man den Nicknamen als weiteren Bestand-teil des Schlüssels hinzu, könnte nur noch folgende Situation zu einem mehrdeutigenSchlüssel führen: Ein Benutzer schließt sein Chat-Programm, startet es (auf dem gleichenoder einem anderen PC) erneut und betritt den gleichen Chat-Raum unter Nutzung desgleichen Nicknamens. Wenn nun der Zufallsgenerator die gleiche Zeichenkette wie bei derersten Nutzung generiert, könnte es zu Mehrdeutigkeiten kommen.


Um die Mehrdeutigkeiten ganz auszuschließen, könnte für die eindeutige Identifikation derBeiträge auch die Zeit mit einfließen. Dafür wären jedoch zusätzliche Datenpakete zur Ab-frage der Uhrzeit vom Server erforderlich.

Wir beschränken uns deshalb darauf, eine Kombination aus id und Nicknamen als Schlüs-sel zu verwenden.

Nachfolgend zeigen wir beispielhaft zwei Nachrichten, von denen die zweite die erste re-ferenziert:

<message id="yobu2-67" to="[email protected]/muvi" type="groupchat" from="[email protected]/rot">

<body>Hallo wie gehts ?

</body></message>

<message id="k2fum-68" to="[email protected]/muvi" type="groupchat" from="[email protected]/gruen">

<body>gut, und Dir ?

</body><properties xmlns="http://www.jivesoftware.com/xmlns/xmpp/properties">

<property><name>parent_id</name><value type="string">yobu2-67</value>

</property><property>

<name>parent_nick</name><value type="string">rot</value>

</property>

</properties></message>

Für die zusätzlichen Datenfelder nutzen wir eine Protokoll-Erweiterung aus der Smack-Bibliothek. Diese legt die Erweiterungsdaten in einem XML-Element namens propertiesab, in dem wiederum die einzelnen Datenfelder jeweils mit Name und Wert enthalten sind.

6.2.3 Nutzer mit anderen Clients im gleichen Raum

Der MuVi-Chat kann auch mit öffentlich zugänglichen Jabber-Servern kommunizieren.Dabei kann die Situation eintreten, dass sich in einem Raum sowohl Chat-Teilnehmer be-finden, die MuVi-Chat als Client benutzen als auch Chat-Teilnehmer, die einen beliebigenanderen Jabber-Client verwenden.

Mit einem normalen Jabber-Client können keine Referenzierungen auf frühere Beiträge er-stellt werden, und die von einem MuVi-Chat-Client übermittelten Referenzierungen kön-nen von einem normalen Jabber-Client nicht angezeigt werden.

Wir müssen also einen Mechanismus finden, wie man die Anwesenheit von Chat-Teilneh-mern erkennen kann, die nicht den MuVi-Chat-Client nutzen. Weiter ist zu überlegen, wasin einer solchen Situation passieren soll.

Über die Belegung des frei definierbaren Ressourcenfeld des JID mit dem Wert "muvi"können wir dafür sorgen, dass aus dem JID ersichtlich ist, ob ein Benutzer einen MuVi-Chat-Client benutzt oder nicht.


Wenn ein Raum nicht speziell als anonymer Raum konfiguriert ist, können Teilnehmernicht nur die Nicknamen der anderen Benutzer, sondern auch deren JID, unter dem sie anihrem Jabber-Server angemeldet sind, abfragen. Aus dem Ressourcenfeld des JID kanndann festgestellt werden, ob der Benutzer einen MuVi-Chat-Client oder einen anderenChat-Client verwendet. Die mit MuVi-Chat generierten Räume werden automatisch alsnicht anonyme Räume eingerichtet.

Benutzer mit anderen Clients werden in der Teilnehmerliste des MuVi-Chat besonders ge-kennzeichnet (vgl. Abbildung 29). So können die Benutzer des MuVi-Chat-Clients die Be-nutzer anderer Clients bei Bedarf auf die Besonderheiten des MuVi-Chat-Clients hinwei-sen.

Alternativ wäre auch denkbar, dass der MuVi-Chat-Client nur die klassische Visualisierungzulässt, wenn sich auch Benutzer anderer Chat-Clients im Raum aufhalten oder dass dieBenutzer anderer Clients automatisch eine bestimmte Informationsnachricht erhalten.

Abbildung 29: Darstellung von Benutzern anderer Client-Software


6.3 PaketstrukturBei der Implementierung des Systems wurde eine Drei-Schichten-Architektur gewählt, dieaus folgenden Schichten besteht:

● Graphische Benutzeroberfläche

● Anwendungslogik

● Netzwerkkommunikation

Die Schicht der graphischen Benutzeroberfläche stellt die Eingabedialoge sowie die Fens-ter zu Verfügung, über die der Benutzer mit dem System interagieren kann. Die Schicht derAnwendungslogik enthält neben den Anwendungsfunktionalitäten auch die Datenmodelle.Da keine laufende Datenspeicherung (z.B. in einer Datenbank) vorgesehen ist, wurde aufeine separate Datenhaltungsschicht verzichtet. Als dritte Schicht wurde stattdessen dieNetzwerkkommunikation definiert, die für den Datenaustausch zwischen Chat-Client undChat-Server zuständig ist.

Diese Drei-Schichten-Architektur spiegelt sich in der Paketstruktur wieder. Abbildung 30zeigt die Zusammenhänge.

Über die Benutzeroberfläche eingegebene Chat-Beiträge durchlaufen alle Schichten, umdann über das Netzwerk an den Server und danach an die anderen Empfänger weitergelei-tet zu werden. Über das Netzwerk eingehende Chat-Beiträge durchlaufen die Schichten inumgekehrter Reihenfolge und werden dann auf der Benutzeroberfläche angezeigt.

Wir werden nachfolgend die Implementierung der einzelnen Schichten beschreiben.

6.3.1 Netzwerkkommunikation

Die Netzwerkkommunikation wird durch die Klassen des Pakets de.feu.cv.transportPrealisiert.

Von der Klasse ChatConnection existiert jeweils nur eine Instanz. Sie wurde daher mitdem Singleton-Entwurfsmuster realisiert. ChatConnection repräsentiert die Verbindungzum Jabber-Server. Als Attribut hat die Klasse ein Objekt der Klasse XMPPConnection ausder Smack-Bibliothek. ChatConnection stellt Methoden für den Verbindungsauf- und

Abbildung 30: Drei-Schichten-Architektur


-abbau, zum Prüfen des Verbindungsstatus, zum Anlegen und Löschen von Benutzerac-counts und zum Erzeugen neuer Chat-Räume zur Verfügung. Über die Klasse Chat-Connection kann man auch den Namen des MUC-Dienstes (meist conference) sowie eineListe der vorhandenen Chat-Räume vom Server abfragen. Daneben ermittelt ChatConnec-tion die Zeitdifferenzen im Falle der verzögerten Nachrichtenauslieferung (vgl. Kapitel6.2.1).

Objekte der Klasse ConnectionConfiguration beinhalten die Konfigurationsdaten zumAufbau einer Verbindung zum Jabber-Server, also Servername, Portnummer, Benutzerna-me und Passwort.

Für jede Verbindung zu einem Chat-Raum existiert ein Objekt der Klasse RoomConnecti-on. Erzeugt werden diese Objekte durch das Singleton ChatConnection. Die Klasse Room-Connection hat ein Objekt der Klasse MultiUserChat aus der Smack-Bibliothek als Attri-but. Mit Hilfe von Methoden der Smack-Bibliothek werden die zu diesem Chat-Raum ge-hörenden Daten-Pakete aus dem XML-Stream der Verbindung zum Server extrahiert. Übereingehende Chat-Nachrichten und Veränderungen des Anwesenheitsstatus informiertRoomConnection die Objekte der Daten Participants und Conversation. Dazu wird dasBeobachter-Entwurfsmuster verwendet (vgl. Abbildung 31).

Dabei übergibt RoomConnection an Participants ein Objekt vom Typ Participant-sChange mit den Änderungsinformationen und an Conversation ein Objekt vom TypThreadedMessage, das die Daten der neu eingetroffenen Nachricht enthält. Die Verbin-dung zum Chat-Raum wird erst hergestellt, nachdem sich die Beobachter registriert haben,da sofort nach dem Verbindungsaufbau Nachrichten eingehen können, über die der Beob-achter informiert werden muss. RoomConnection ist zudem für das Versenden von Nach-richten in einen Chat-Raum verantwortlich.

Die Klasse ErrorTextGenerator unterstützt die Fehlerbehandlung der aus der Smack-

Abbildung 31: Beobachter-Entwurfsmuster zwischen Netzwerkkommunikation undAnwendungslogik


Bibliothek generierten XMPPExceptions. Solche Ausnahmen treten beispielsweise dannauf, wenn der Server nicht erreichbar ist oder bestimmte Aktionen aufgrund fehlenderRechte nicht durchgeführt werden können. Die Klasse ErrorTextGenerator fügt den Feh-lercodes Beschreibungen hinzu und übersetzt diese, wenn nötig.

6.3.2 Anwendungslogik

Ein Überblick über das Paket applicationLogicP zeigt Abbildung 32.

Dreh- und Angelpunkt der Anwendungslogik ist die Klasse ChatAdministration. Gespei-cherte Chat-Protokolle werden durch Objekte der Klasse ChatFile repräsentiert, Chat-Räume, in denen sich der Benutzer aufhält, durch Objekte der Klasse ChatRoom. Die vor-handenen Instanzen von ChatFile und ChatRoom verwaltet ChatAdministration jeweilsin einer Liste. Dazu werden die Klassen ChatFileTableModel und ChatRoomTableModelgenutzt.

Einem ChatRoom ist sowohl ein Objekt der Klasse Conversation für den Gesprächsver-lauf, als auch ein Objekt der Klasse Participants, das die Teilnehmerliste enthält, zuge-ordnet. Zu einem gespeicherten Chat-Protokoll gibt es keine Teilnehmerliste, so dass demChatFile nur ein Objekt der Klasse Conversation zugeordnet ist.

Die Klasse MuViChatConstants wird für systemweite Konstanten, die Klasse Resourcesfür die Internationalisierung verwendet.

Die Klasse ChatAdministration ist als Singleton realisiert. Sie übernimmt folgendeAufgaben:

● Starten und Beenden der Anwendung

● Erzeugen von neuen Objekten der Klasse ChatRoom und ChatFile und Verwalten

Abbildung 32: Klassendiagramm applicationLogicP


der zugehörigen Listen

● Koordination des Auf- und Abbaus von Verbindungen zum Chat-Server und Weiter-gabe des Verbindungsstatus an die Benutzeroberfläche

● Speichern der Verbindungseinstellungen in einer Datei sowie Laden der zuletzt be-nutzten Verbindungseinstellungen.

● Beauftragen der Netzwerkkommunikationsschicht mit dem Anlegen und Löschenvon Benutzern

● Weiterleitung von Fehlermeldungen aus der Netzwerkkommunikationsschicht andie Benutzeroberfläche

Aus den vom Chat-Server übermittelten Beiträgen erzeugt die Netzwerkkommunikations-schicht Objekte vom Typ ThreadedMessage und benachrichtigt die zum jeweiligen Chat-Raum gehörende Instanz der Klasse Conversation. Die Klasse Conversation ist diezentrale Datenstruktur für den Gesprächsverlauf.

Da für die Visualisierung teilweise unterschiedliche Datenmodelle benötigt werden, spei-chert Conversation den Gesprächsverlauf in drei verschiedenen Datenmodellen:Transscript, ChatListModel und MessageTree. Alle drei implementieren das InterfaceChatDataModel. Trifft eine neue Nachricht ein, wird sie in alle drei Datenmodelle einge-fügt.

Wird eine Nachricht über die Benutzeroberfläche als Bezugsnachricht gekennzeichnet, sowird sie auch in der Datenstruktur Conversation selektiert. Beim Senden einer Nachrichtdurch ChatRoom wird über die Datenstruktur Conversation die mögliche Bezugsnachrichtermittelt.

Für die Steuerung eines einzelnen Chat-Raums ist die Klasse ChatRoom zuständig. Das vonChatAdministration erzeugte ChatRoom-Objekt

● sorgt für den Verbindungsauf- und -abbau über die Klasse RoomConnection

● erzeugt ein Objekt der Klasse Conversation als Datenmodell

● erstellt das Chat-Fenster

● reicht über die Benutzeroberfläche erstellte Chat-Nachrichten an die Netzwerkkom-munikationsschicht weiter

● kann den Gesprächsverlauf in einer Datei speichern.

Für das Speichern des Gesprächsverlaufs werden Funktionen der Programmbibliothek pre-fuse verwendet. Mit einer TreeMLWriter-Instanz können Baumstrukturen im FormatTreeML gespeichert werden. TreeML ist ein XML-Format zur Speicherung von Baum-strukturen, das für den InfoVis Contest 2003 der IEEE entwickelt wurde. Die DocumentType Definition (DTD) für TreeML ist unter der folgenden Webadresse zu finden:http://www.nomencurator.org/InfoVis2003/download/treeml.dtd

Zuvor gespeicherte Chat-Protokolle im TreeML-Format werden durch Instanzen der KlasseChatFile geöffnet und in einem Chat-Fenster dargestellt, das auch die Möglichkeiten bie-tet, die Diskussion in ihrem zeitlichen Verlauf wiederzugeben.

Für diese Wiedergabesteuerung ist die Klasse ReplayThread zuständig. Ein Objekt dieserKlasse wird erzeugt, sobald in der Benutzeroberfläche der Wiedergabe-Button gedrücktwird. Der ReplayThread verändert bei der Wiedergabe die Conversation-Instanz. Con-versation verwaltet von allen drei Datenmodellen jeweils zwei Objekte. Eines davonbeinhaltet den gesamten Gesprächsverlauf, das andere nur den aktuell angezeigten Teil.

http://www.nomencurator.org/InfoVis2003/download/treeml.dtd


Normalerweise sind beide Objekte inhaltsgleich, im Replay-Modus passiert folgendes:

1. Der ReplayThread setzt in Conversation den Replay-Modus auf aktiv.

2. Der ReplayThread holt sich aus Conversation das Listenmodell des Gesprächs-verlaufs.

3. Der ReplayThread ruft in Conversation die Methode clearConversation() auf,wodurch die für die Anzeige verantwortlichen drei Datenmodelle geleert werden.

4. Der ReplayThread durchläuft die Liste der Chat-Beiträge und fügt jeden einzelnenBeitrag wieder in die für die Anzeige zuständigen Datenmodelle ein. Zwischen deneinzelnen Beiträgen wartet der Thread die entsprechende Zeitdifferenz ab.

Nach der Anforderung (A7) aus Kapitel 3.3 soll die Softwarelösung mehrsprachig sein. ZurRealisierung der Mehrsprachigkeit werden im Quellcode für die zu übersetzenden Zei-chenketten symbolische Namen verwendet. Die Zuordnung der symbolischen Namen zuden Zeichenketten der jeweiligen Sprache kann in Java mit Hilfe der Klasse Resource-Bundle durchgeführt werden. Dafür wurde im Paket applicationLogicP eine Klasse Re-sources mit der statischen Methode getString(String key) erstellt, die aus dem Re-sourceBundle mit dem Basisnamen muvi die Übersetzung ermittelt.

Für jede Sprache gibt es eine Datei namens muvi_<countrycode>.properties, in der dietatsächlich zu verwendenden Zeichenketten zu diesen symbolischen Namen abgelegt sind.Derzeit sind Sprachdateien für Deutsch und Englisch verfügbar.

6.3.3 Graphische Benutzeroberfläche

Die Komponenten der graphischen Benutzeroberfläche befinden sich im Paket de.-feu.cv.guiComponentsP. Abbildung 33 gibt einen Überblick.

Ein Teil der Klassen der Benutzeroberfläche wurde in Unterpakete strukturiert. Alle Benut-

Abbildung 33: Übersicht über das Paket guiComponentsP


zerdialog-Fenster sind im Paket dialogP enthalten. Das Paket chatWindowComponentsPenthält die Klassen für die einzelnen Bestandteile eines Chat-Fensters, sowie abstrakteKlassen und Schnittstellen, die von den einzelnen Visualisierungen implementiert werden.

Die einzelnen Visualisierungen sind im Paket pluginsP zu finden. Dabei sind die zu einerVisualisierung gehörenden Klassen jeweils in einem Unterpaket mit dem Namen der Vi-sualisierung untergebracht. Ein Teil der Visualisierungen bedient sich der Funktionalitätender prefuse-Bibiliothek. Im Paket prefuseP befinden sich Klassen für eine Basisvisualisie-rung mit prefuse, die von den konkreten Visualisierungen verwendet werden können.

6.3.3.1 Hauptfenster und Dialoge

Das Hauptfenster kann maximal einmal im System existieren, die Klasse MainWindowwurde daher als Singleton realisiert.

Inhalt des Hauptfensters sind vor allem zwei Objekte der Swing-Klasse JTable, in denendie Daten zu den verbundenen Chat-Räumen bzw. zu den geöffneten Chat-Protokoll-Datei-en angezeigt werden. Die in den Tabellen angezeigten Daten erfragt MainWindow vomSingleton ChatAdministration.

Über die Menüpunkte des Hauptfensters werden die verschiedenen Dialogfenster erzeugt,wie beispielsweise das Dialogfenster zum Ändern der Zugangsdaten oder das Dialogfens-ter zum Betreten eines Chat-Raums. Die über den Dialog gelesenen Benutzereingaben wer-den größtenteils an das ChatAdministration-Objekt weitergeleitet, welches die Anwen-dungslogik steuert.

6.3.3.2 Bestandteile des Chat-Fensters

Das Klassendiagramm der zu einem Chat-Fenster gehörenden Klassen ist in Abbildung 34dargestellt, wobei beispielhaft die Visualisierung ClassicChat gezeigt wird.

Abhängig davon, ob das Fenster für einen Online-Chat oder zur Wiedergabe eines abge-

Abbildung 34: Klassendiagramm Chat-Fenster


speicherten Chats genutzt wird, besteht es aus unterschiedlichen Komponenten. Für jedendieser beiden Fenstertypen existiert eine eigene Klasse, wobei jede der Klassen ChatLive-Window und ChatReplayWindow gemeinsame Funktionalitäten von der abstrakten KlasseChatWindow erbt.

Ein ChatLiveWindow besteht aus den Komponenten Teilnehmerliste (ParticipantPane),Texteingabebereich (ChatTextInputPane) sowie dem Anzeigebereich (ChatVisuali-zationPane). Ein ChatReplayWindow besteht aus dem Anzeigebereich sowie einem Be-reich zur Wiedergabesteuerung (ReplayPanel).

Die einzelnen GUI-Komponenten sind größtenteils von der Swing-Klasse JPanel abgelei-tet. Zur Positionierung der Komponenten im Fenster werden mehrere Objekte der Swing-Klasse JSplitPane verwendet. Diese ermöglicht horizontale und vertikale Unterteilungendes Fensters in Teilbereiche, deren Größe vom Benutzer verändert werden kann.

Jede einzelne Visualisierung muss eine Klasse VisualizationPane bereitstellen, die vonder abstrakten Klasse ChatVisualizationPane abgeleitet ist. Als konkreter Beobachterim Observer-Entwurfsmuster muss VisualizationPane insbesondere die Methode up-date() zur Verfügung stellen, die beim Eintreffen neuer Nachrichten aufgerufen wird, undzur Aktualisierung der Anzeige dient.

6.3.3.3 Visualisierungseigenschaften

Zu einer Visualisierung können optional Visualisierungseigenschaften wie z.B. die Hinter-grundfarbe festgelegt werden. Zur Änderung dieser Eigenschaften kann der Benutzer überden Menüpunkt Extras - Optionen des Chat-Fensters ein Dialogfenster öffnen. Dieses Dia-logfenster ChatWindowPropertyDialog enthält ein visualisierungsabhängiges PanelPropertyContentPane sowie eine Schaltfläche zum Wiederherstellen der Standardeinstel-lungen.

Die Eigenschaften selbst werden pro Visualisierung in einem Objekt der Klasse Visuali-zationProperties abgelegt, die von der abstrakten Klasse VisualProperties abgeleitetwird. Die Visualisierung selbst registriert einen Beobachter bei den VisualizationPro-perties, der sie über Änderungen der Konfigurationseinstellungen informiert. So wirdsichergestellt, dass geänderte Konfigurationseinstellungen sofort in der Anzeige sichtbarwerden.

6.3.3.4 Plugin-Konzept für Visualisierungen

Nach der Anforderung (A8) aus Kapitel 3.3 soll die Software modular aufgebaut und leichterweiterbar sein. Da der Schwerpunkt der Softwarelösung bei der Bereitstellung verschie-dener Visualisierungen liegt, muss es möglich sein, neue Visualisierungen ohne großenAufwand hinzuzufügen. Hierzu nutzt MuVi-Chat ein Plugin-Konzept.

Die dem Benutzer zur Verfügung stehenden Visualisierungen werden bei Instanzierung vonUnterklassen der Klasse ChatWindow erzeugt. Die MethodecreateVisualizationPanes(Conversation conversation) liest dazu zunächst aus derKlasse MuViChatConstants die Liste der Namen der registrierten Plugins. Für jedes derPlugins existiert ein Unterpaket im Paket pluginsP. In jedem der Unterpakete wiederumbefindet sich eine Klasse namens VisualizationPane, die den visualisierungsabhängigenInhalt des Chat-Fensters bereitstellt. Da die Namen der Unterpakete erst zur Laufzeit be-kannt sind, bedienen wir uns bei der Erzeugung der Objekte der Java-Reflection-API.

Welche Schritte erforderlich sind, um weitere Visualisierungen hinzuzufügen, werden wirin Kapitel 6.5 beschreiben.


6.3.3.5 Basiskomponenten für die Visualisierung mit prefuse

Das Paket prefuseP enthält die für eine graphische Baumdarstellung der Chat-Kommuni-kation benötigten Basiskomponenten.

Zentrale Klasse ist die abstrakte Klasse ChatVisualizationPanePrefuse, die wiederumdie abstrakte Klasse ChatVisualizationPane erweitert.

ChatVisualizationPanePrefuse benutzt als Datenstruktur ein von der Datenhaltungs-klasse Conversation bereitgestelltes Objekt der Klasse MessageTree, einer Unterklasseder Klasse Tree aus der prefuse-Bibliothek.

Bei Instanzierung eines von ChatVisualizationPanePrefuse abgeleiteten Objekts wirdzunächst ein Objekt der prefuse-Klasse Visualization erzeugt. Der Visualization wer-den dann zugeordnet:

● eine RendererFactory, die dafür verantwortlich ist wie die Knoten und Kanten ge-zeichnet werden

● mehrere ActionLists, die für Farbe, Layout und die Aktualisierung der Darstel-lung zuständig sind und in einem separaten Thread, dem sog. ActivityManagerablaufen

Für einen Teil der Funktionalitäten konnten Klassen aus dem prefuse-Framework direktverwendet werden, beim übrigen Teil war es nötig die prefuse-Klassen zu erweitern.

Zur Darstellung der Kanten wird die prefuse-Klasse EdgeRenderer verwendet. Für dieDarstellung der Knoten wurde die Klasse ChatLabelRenderer von der prefuse-Klasse La-belRenderer abgeleitet. ChatLabelRenderer sorgt beispielsweise dafür, dass in den Kno-ten nicht nur der Text der Chat-Nachricht, sondern auch der Nickname erscheint und dassautomatische Zeilenumbrüche eingefügt werden.

Die Anordnung der Knoten wird mit Hilfe der prefuse-Klasse NodeLinkTreeLayout vor-genommen. Diese nutzt den Algorithmus von Buchheim et al. [BJL02] für die Berechnungder Knotenpositionen.

Zur Farbgestaltung werden vier ColorAction-Objekte erzeugt und zwar jeweils für:

● die Farbe der Knoten

● die Textfarbe

● die Farbe der Knotenränder

● die Farbe der Kanten

Für die Farbe der Knoten wurde eine spezielle Klasse ChatDataColorAction von der pre-fuse-Klasse DataColorAction abgeleitet, um die Farbe der Knoten, abhängig vom Nick-namen des Chat-Teilnehmers, aus einer vorgegebenen Farbpalette zu bestimmen. Die Kno-tenränder sind im Normalfall durchsichtig, ausgewählte Knoten werden mit einem schwar-zen Rand angezeigt. Die ColorActions werden in eine ColorActionList eingefügt.

Weitere Action-Klassen wurden erstellt, um die gesamte Baumdarstellung an die ge-wünschte Position verschieben zu können. Die Klasse PanAction kommt zum Einsatz,wenn die Autofokus-Einstellung aktiviert ist. Sie sorgt dafür, dass - abhängig von der Ori-entierung der Baumdarstellung - der neuste Beitrag entweder oben, unten, rechts oder linksin der Mitte angezeigt wird. Wenn die Autofokus-Einstellung deaktiviert ist, ermittelt Pre-LayoutAction beim Eintreffen einer neuen Nachricht zunächst die Nachricht, die momen-tan der Fenstermitte am nächsten ist und merkt sich deren Position. Dann berechnet dieLayout-Action die Position aller Knoten neu. Danach verschiebt PostLayoutAction die


gesamte Baumdarstellung so, dass die Position der Nachricht in der Fenstermitte gleichbleibt. Dadurch wird sichergestellt, dass der Benutzer beim Lesen früherer Chat-Beiträgenicht den Fokus verliert, sobald neue Nachrichten eintreffen.

Nachdem Renderer und Actions der Visualization zugeordnet sind, wird ein Objekt derKlasse Display erzeugt. Display ist von der Swing-Klasse JComponent abgeleitet und fürdie Darstellung der Visualisierung zuständig. Diesem Display-Objekt werden dann ver-schiedene Listener zugeordnet, die auf bestimmte Eingaben des Benutzers reagieren:

● ChatControl dient dazu, dass der Benutzer einzelne Chat-Beiträge per Mausklickfür die Referenzierung auswählen kann.

● PanControl ist dafür verantwortlich, dass der Benutzer durch Ziehen mit gedrück-ter linker Maustaste die Ansicht verschieben kann.

● Durch die ZoomControl ist es möglich, durch Ziehen mit gedrückter rechterMaustaste die Ansicht zu vergrößern oder zu verkleinern.

● AutofocusOffControl stellt sicher, dass, sobald die Ansicht gezoomt oder ver-schoben wurde, die Autofokus-Einstellung auf "Aus" gestellt wird.

Für den rechten Slot des Chat-Fensters stellen die prefuse-Visualisierungen ein Panel zurVerfügung, in dem die gesamte Chat-Kommunikation dargestellt ist. Der aktuell im Haupt-fenster gezeigte Ausschnitt wird im Überblickbereich dunkelgrau hinterlegt. Daneben zeigtdas Panel, ob die Autofokus-Funktion aktiv ist und bietet die Möglichkeit diese an- undwieder abzuschalten. Das Panel wird über die Klasse OverviewAndControlPanel reali-siert. Für den darin enthaltenen Überblickbereich wird eine weitere Instanz der KlasseDisplay erzeugt, die ebenfalls dem Visualization-Objekt zugeordnet ist. Auch diesemDisplay-Objekt werden verschiedene Listener zugeordnet:

● ein ComponentListener, der verantwortlich dafür ist, dass die Inhalte neu berech-net und dargestellt werden, wenn sich die Größe des Übersichts-Displays ändert,z.B. wenn der Benutzer den Trennbalken der JSplitPane verschiebt.

● ein ItemBoundsListener, der die Aktualisierung des Übersichts-Displays veran-lasst, wenn neue Nachrichten dazukommen.

● ein PaintListener, der immer nach dem Neuzeichnen des Übersichts-Displaysdafür sorgt, dass auch das Rechteck, das den aktuellen Bildschirmausschnitt reprä-sentiert, neu gezeichnet wird.

Mittels einem beim Haupt-Display registrierten PaintListner wird das Übersichts-Dis-play informiert und sofort neu gezeichnet, wenn die Inhalte im Haupt-Display verschobenoder gezoomt wurden.

6.3.3.6 Aktualisierung der Visualisierungen beim Eintreffen neuer Nachrich-ten

MuVi-Chat nutzt ein kombiniertes Verfahren, um die Visualisierungen beim Eintreffen neu-er Nachrichten zu aktualisieren.

Dabei wurde berücksichtigt, dass Swing eine modifizierte Form des ArchitekturmustersMVC (Model-View-Controller) verwendet, bei dem View und Controller zu einer Kompo-nente verschmolzen sind (vgl. [Fo07]). Bei einer Liste übernimmt die Klasse JList bei-spielsweise die Aufgaben von View und Controller, also die Anzeige und die Reaktion aufEingaben des Benutzers. Als Datenmodell ist eine Klasse erforderlich, die das InterfaceListModel implementiert. Änderungen am Datenmodell werden dabei automatisch in derGUI-Komponente sichtbar.


Verwenden die Chat-Visualisierungen solche Swing-Komponenten, müssen diese GUI-spe-zifischen Datenmodelle an geeigneter Stelle abgelegt werden. Grundsätzlich wäre es mög-lich, diese Datenmodelle im Paket der jeweiligen Visualisierung zu platzieren. Dies hätteallerdings den Nachteil, dass das Datenmodell nicht von anderen Visualisierungen, die diegleichen Swing-Komponenten verwenden, mitbenutzt werden kann. Um eine Wiederver-wendung möglich zu machen, wurden die von den Datenmodell-Klassen der verwendetenSwing-GUI-Komponenten abgeleiteten Klassen als Teilklassen der "Hauptmodellklasse"Conversation realisiert. Details können nachfolgender Abbildung 35 entnommen werden.

Änderungen am Datenmodell, wie beispielsweise das Eintreffen neuer Chat-Nachrichten,werden so automatisch in den Swing-GUI-Komponenten sichtbar. Da es allerdings mögli-cherweise noch weitere Bestandteile der GUI gibt, die über Änderungen am Datenmodellinformiert werden sollen, verwenden wir noch ein weiteres Beobachter-Entwurfsmuster,das die Visualisierungen, unabhängig von den GUI-Komponenten, über Änderungen amDatenmodell informiert.

Für die prefuse-basierenden Visualisierungen wird dieses Verfahren analog angewandt.

Abbildung 35: Klassendiagramm Aktualisierung der GUI


6.3.3.7 Visualisierungs-Plugins

MuVi-Chat hat derzeit sechs Visualisierungs-Plugins, davon basieren vier auf den in Kapi-tel 6.3.3.5 beschriebenen Basiskomponenten.

ClassicChat:

ClassicChat ist eine Visualisierung, die dem Standard-Chat-Client entspricht. Die Chat-Beiträge werden in einer JTextArea dargestellt, die mit einem Objekt der Klasse Transs-cript als Datenmodell verbunden ist. Transscript erweitert die Swing-Klasse PlainDo-cument.

HighlightList:

Bei der Visualisierung HightlightList werden die Chat-Beiträge als Listeineinträge einerJList dargestellt. Für die Hervorhebung der Bezugsnachrichten und der aktuell ausge-wählten Nachrichten wird die Klasse VisualisationPaneRenderer verwendet, die vonder Swing-Klasse JListRenderer abgeleitet ist.

SimpleTree:

Die Visualisierung SimpleTree verwendet die vom Paket prefuseP bereitgestellten Basis-funktionen ohne Änderung.

TimeByColorTree:

Die Visualisierung TimeByColorTree lässt die Farbe der Knoten im Laufe der Zeit verblas-sen. Dazu wurde in der Klasse VisualizationPane die Methode createFillColorAc-tion() überschrieben. Diese erzeugt die ColorAction für die Farbe der Knoten. In derüberschriebenen Methode wird ein Objekt der Klasse TimeChatDataColorAction erzeugt.In dieser Klasse wird die Hintergrundfarbe für eine Nachricht in Abhängigkeit vom Zeit-raum zwischen dem Zeitstempel dieser Nachricht und dem Zeitstempel der neuesten Nach-richt berechnet.

TimeByLayoutTree:

Um den Faktor Zeit bei der Baumdarstellung zu berücksichtigen, wurde bei der Visualisie-rung TimeByLayoutTree ein anderer Layout-Algorithmus verwendet. Der folgende rekur-sive Algorithmus berechnet die x-und y-Koordinaten für einen Knoten p, wobei bei der Be-rechnung der y-Koordinate die Zeit einfließt:

walk(p): p.ypos = (zeitstempel(p)- startzeit) * faktor wenn Blatt: p.xpos = gibNächsteFreieXPosition() sonst: für jeden Kindknoten c: walk(c) p.xpos = findeMitteZwischenDenKindKnoten()

Dieser Algorithmus wurde in der Klasse TimeTreeLayout umgesetzt.

SequenceByLayoutTree:

Bei der Visualisierung SequenzByLayoutTree wird für die Positionierung des Knotens aufder y-Achse statt des Zeitstempels die laufende Nummer des Knotens verwendet. Hier derangepasste Layout-Algorithmus:

walk(p): p.ypos = laufendeNummerDesKnotens()*faktor wenn Blatt: p.xpos = gibNächsteFreieXPosition() sonst:


für jeden Kindknoten c: walk(c) p.xpos = findeMitteZwischenDenKindKnoten()

Er wird von der Klasse SequenzialTreeLayout verwendet.

6.4 Deployment und Nutzung von MuVi-ChatDamit der Nutzer die verwendeten Programmbibliotheken Smack und prefuse nicht separatbeschaffen und installieren muss, wurde mit Hilfe des Deployment-Tools Fat Jar ein jar-Archiv erzeugt, das auch die die benötigten Teile der Programmbibliotheken enthält. FatJar ist ein Plugin der Entwicklungsumgebung Eclipse und unter http://fjep.sourceforge.neterhältlich.

Zur Nutzung von MuVi-Chat benötigt man einen PC mit installiertem Java Runtime Envi-roment sowie die Datei MuViChat_x.x.jar (x.x steht dabei für die Versionsnummer).

Gestartet wird MuVi-Chat durch Doppelklick auf die Datei MuViChat_x.x.jar oder überdie Kommandozeile durch Eingabe des folgenden Befehls:

java -jar MuViChat_x.x.jar

MuVi-Chat erstellt im Home-Verzeichnis des Users ein Unterverzeichnis .muvi in dem dieKonfigurationsdateien abgespeichert werden.

Sofern ein Internetzugang zur Verfügung steht, können öffentliche Jabber-Server, wie bei-spielsweise jabber.ccc.de für die Kommunikation verwendet werden. Eine Liste öffentli-cher Jabber-Server steht unter https://www.xmpp.net/servers zur Verfügung. Bei Einsatzeiner Firewall ist es erforderlich, dass Verbindungen zwischen dem Client und dem ge-wählten Server auf Port 5222 erlaubt sind.

Für Testzwecke oder den Einsatz von MuVi-Chat in einem Intranet kann man auch eineneigenen Jabber-Server installieren.

6.5 Ergänzung um weitere VisualisierungenMuVi-Chat kann durch die Bereitstellung von Plugins um weitere Visualisierungen ergänztwerden. Zur Erstellung und Einbindung eines solchen Plugins sind folgende Schritte er-forderlich:

1. Festlegung eines Namens für die neue Visualisierung

2. Anlegen eines neuen Pakets mit dem Namen der neuen Visualisierung unterhalbvon de.feu.cv.guiComponentsP.plugins

3. Erstellen einer Klasse namens VisualizationPane, die die abstrakten Klasse de.-feu.guiComponentsP.ChatVisualizationPane oder die Klasse de.feu.cv.-guiComponentsP.prefuse.ChatVisualizationPanePrefuse erweitert.

4. Implementierung der in ChatVisualizationPane bzw. in ChatVisualization-PanePrefuse abstrakt definierten Methoden.

5. Registrieren des Plugins durch Ergänzen des Arrays visualizationPlugins in derKlasse de.feu.cv.applicationLogicP.MuViChatConstants um den Namen derneuen Visualisierung.

Danach erscheint die neue Visualisierung automatisch im Menü Ansicht.

https://www.xmpp.net/servers

http://fjep.sourceforge.net/

Zusammenfassung und Ausblick 69

7 Zusammenfassung und AusblickMit MuVi-Chat wurde eine Software-Lösung entwickelt, die alternative Visualisierungenfür die Chat-Kommunikation bereitstellt und durch die Darstellung der Beziehungen zwi-schen den Chat-Beiträgen das Problem des Co-Text-Verlusts reduziert.

Die in Kapitel 3.3 definierten Anforderungen an das System (A1) bis (A8) werden folgen-dermaßen erfüllt:

(A1) Basis-Chat-Funktionalität:

Der Benutzer kann Beiträge im Eingabefeld verfassen und an die anderen Chat-Teilnehmerversenden. Die Übermittlung der Nachrichten an die Chat-Teilnehmer wurde mit dem Jab-ber-Protokoll umgesetzt. Eine Teilnehmerliste zeigt die aktuell im Raum befindlichenChat-Teilnehmer an.

(A2) Herstellung von Bezügen zwischen Beiträgen:

Der Benutzer kann vor dem Versenden einer Nachricht durch Mausklick eine Bezugsnach-richt auswählen.

(A3) Visualisierung der Beiträge sowie der Bezüge zwischen den Beiträgen:

Neben der klassischen Visualisierung bietet MuVi-Chat dem Benutzer fünf alternative Vi-sualisierungen zur Auswahl an, bei denen auch die Bezüge zwischen den Beiträgen ange-zeigt werden. Zudem hat der Benutzer die Möglichkeit, bestimmte Einstellungen der Vi-sualisierungen selbst zu verändern.

(A4) Speicherung des Gesprächsverlaufs:

Der Benutzer kann eine Konversation im XML-basierten Format TreeML speichern.

(A5) Replay-Modus:

Zuvor gespeicherte Konversationen können vom Benutzer geöffnet und abgespielt werden.


Durch die Verwendung von Java als Programmiersprache sowie dem Jabber-Protokoll fürdie Netzwerkkommunikation kann MuVi-Chat plattformunabhängig eingesetzt werden.


MuVi-Chat steht zunächst mit deutscher und englischer Benutzeroberfläche zur Verfügung.Weitere Sprachen können ohne Programmieraufwand hinzufügt werden.


MuVi-Chat verwendet ein Plugin-Konzept, mit dem weitere Visualisierungen einfach hin-zugefügt werden können.

(A9) Open Source

MuVi-Chat baut ausschließlich auf Open-Source-Software auf. Es ist geplant, auch MuVi-Chat unter einer Open-Source-Lizenz zu veröffentlichen.

Inwieweit sich die Visualisierungen in der Praxis bewähren, muss noch evaluiert werden.Dabei sollte untersucht werden, ob das Problem des Co-Text-Verlusts auch bei Verwen-dung der alternativen Visualisierungen auftritt. Wenn ja, wäre es interessant zu wissen, obes dabei Unterschiede zwischen den einzelnen Visualisierungen gibt und der Co-Text-Ver-lust bei bestimmten Visualisierungen häufiger auftritt als bei anderen. Weiter sollte analy-siert werden, welche Art, die Zeit zu visualisieren, von den Benutzern bevorzugt wird.

Zusammenfassung und Ausblick 70

Untersucht werden könnte auch, welche Auswirkungen die verschiedenen Visualisierungenauf den Gesprächsverlauf haben. Möglicherweise ergeben sich durch die Nutzung der al-ternativen Visualisierungen andere Gesprächsstrukturen wie bei einem seriellen Chat.

Bei der Evaluierung sollte auch die Gebrauchstauglichkeit (Usability) der Visualisierungenund der gesamten Anwendung überprüft und Verbesserungspotentiale identifiziert werden.

Auf Basis der so gewonnenen Ergebnisse können die vorhanden Visualisierungen optimiertoder weitere Visualisierungen neu entwickelt werden.

Nachfolgend führen wir einige Vorschläge zur Weiterentwicklung von MuVi-Chat auf:

● Wie in Kapitel 5.1 erläutert, ist es in einem Gesprächsverlauf grundsätzlich auchmöglich, dass sich ein Beitrag auf mehrere Beiträge bezieht. Eine Weiterentwick-lung von MuVi-Chat könnte auch solche Mehrfachreferenzierungen zulassen unddafür geeignete Visualisierungen anbieten.

● Viele Nutzer bevorzugen Benutzerschnittstellen, die ausschließlich per Tastatur be-dient werden können. Die Auswahl des Bezugsbeitrages mittels Tastatur kann unterergonomischen Gesichtspunkten günstiger sein, da beim Chatten der Text ohnehinüber die Tastatur eingegeben wird. Eine Idee hierzu wäre, den Auswahlmodus übereine bestimmte Taste zu aktivieren, um danach ein Navigieren durch den Baum mitden Pfeiltasten zu ermöglichen.

● Die Liste der Chat-Teilnehmer im MuVi-Chat könnte um weitere Funktionen erwei-tert werden. So könnten, ähnlich wie beim Status-Client, Informationen über Statusund Aktivität des einzelnen Benutzers sowie weitere Informationen zum Benutzerangezeigt werden.

● Der Replay-Modus könnte auch für noch laufende Diskussionen zur Verfügung ge-stellt werden. So könnten sich insbesondere Späteinsteiger den bisherigen Verlaufder Diskussion nochmal im Schnelldurchlauf ansehen.

● Es könnten Funktionen zur Verfügung gestellt werden, die es ermöglichen, die Vi-sualisierungen auszudrucken oder als Grafikdatei zu exportieren.

Da für die Kommunikation das Jabber-Protokoll verwendet wird, könnten MuVi-Chat soerweitert werden, dass weitere Teile der Jabber-Spezifikation implementiert werden. Dasbedeutet insbesondere:

● Kanäle zum Austausch privater Nachrichten bereitzustellen,

● eine Kontaktliste zur Verfügung zu stellen, in denen der Nutzer über den Status an-derer Jabber-Nutzer informiert wird,

● die Möglichkeit, Räume mit bestimmten Zugriffsbeschränkungen zu erstellen,

● die Verschlüsselung der Verbindung zwischen Client und Server zu ermöglichen.

Es ist auch denkbar, für Jabber eine Protokollerweiterung anzustreben, die für die Referen-zierung anderer Nachrichten einen einheitlichen Standard definiert, der auch von anderenChat-Clients verwendet werden könnte. Auf diesem Wege könnten referenzierte Chatseinen größeren Verbreitungsgrad erlangen.

Literaturverzeichnis 71

8 Literaturverzeichnis

[BaNe01] Barlow, Todd und Padraic Neville: A Comparison of 2-D Visualizationsof Hierarchies. Proc. of IEEE Symposium on Information Visualization,S. 131-138, San Diego, USA, 2001

[Bei00] Beißwenger, Michael: Kommunikation in virtuellen Welten: Sprache,Text und Wirklichkeit. Eine Untersuchung zur Konzeptionalität vonKommunikationsvollzügen und zur textuellen Konstruktion von Welt insynchroner Internet-Kommunikation, exemplifiziert am Beispiel einesWebchats. ibidem-Verlag, Stuttgart, 2000

[BJL02] Buchheim, Christoph, Michael Jünger und Sebastian Leipert: ImprovingWalker's algorithm to run in linear time. In: Goodrich, Michael T. andKobourov, Stephen G. (Hrsg): Proceedings Graph Drawing, S. 344-353,Irvine, CA, USA, 2002

[ChSu02] Chen, David und Sun, Chengzheng: Real-time text chat via collaborati-ve editing systems. In: Proc. of the ACM CSCW 2002 Workshop on Col-laborative Editing, New Orleans, USA, 2002

[ESK+99] Erickson, Thomas, David N. Smith, Wendy A. Kellogg, Mark Laff, JohnT. Richards und Erin Bradner: Socially translucent systems: social pro-xies, persistent conversation and the design of "babble". In: Proceedingsof the SIGCHI conference on Human factors in computing systems, S.72-79, Pittsburgh, Pennsylvania, USA, 1999

[Fo07] Fowler, Amy: A Swing Architecture Overview. URL:http://java.sun.com/products/jfc/tsc/articles/architecture (Abgerufen: 20.Juni 2007)

[HCL05] Jeffrey Heer, Stuart K. Card, James A. Landay, prefuse: A Toolkit for In-teractive Information Visualization. In: Proceedings of the SIGCHI con-ference on Human factors in computing systems, S. 421 - 430, ACMPress, New York, 2005

[Her99] Herring, Susan C.: Interactional Coherence in CMC. In: Journal ofComputer-Mediated Communication 4 (4), 1999

[Hes06] Hesse, Hannes: A Mindmap-Like Chat Interface. 2006, URL:http://www.ischool.berkeley.edu/~hannes/mmchat/mmchat.pdf (Abge-rufen: 20. Juni 2007)

[HHSM05] Harnoncourt, Max, Holzhauser, Astrid, Seethaler, Ursula & Meinl, Paul:Referenzierbarkeit als Schlüssel zum effizienten Chat. In: Beißwenger,Michael & Storrer, Angelika (Hrsg.): Chat-Kommunikation in Beruf,Bildung und Medien: Konzepte - Werkzeuge - Anwendungsfelder,S.161-179, 2005

[HoWe05] Holmer, Torsten und Martin Wessner: Gestaltung von Chat-Werkzeugenzur Verringerung der Inkohärenz. In: Beißwenger, Michael & Storrer,Angelika (Hrsg.): Chat-Kommunikation in Beruf, Bildung und Medien:Konzepte - Werkzeuge - Anwendungsfelder, S.181-199, 2005

[Luk05] Lukosch, Stephan: Kurs 1880, Computerunterstütztes kooperatives Ar-beiten - CSCW, Kurseinheit 2: Kommunikation und gemeinsame Infor-

http://www.ischool.berkeley.edu/~hannes/mmchat/mmchat.pdf%20

http://java.sun.com/products/jfc/tsc/articles/architecture


mationsräume. Fernuniversität in Hagen, S. 75, 2005

[OR93] Oikarinen, J. und D. Reed: Internet Relay Chat, Request for Comments1459. IETF, 1993

[PFdL03] Pimentel, Mariano Gomes, Hugo Fuks und Carlos José Pereira de Lu-cena: Co-text Loss in Textual Chat Tools. In: Proceedings of Fourth In-ternational and Interdisciplinary Conference on Modeling and UsingContext (CONTEXT 2003), LNAI 2680, S. 483-490, Berlin Heidelberg,2003

[PFdL06] Pimentel, Mariano Gomes, Hugo Fuks und Carlos José Pereira de Lu-cena: R-U-Typing-2-Me? Evolving a chat tool to increase understandingin learning activities. In: International Journal of Computer-SupportedCollaborative Learning, Volume 1, Number 1 , S. 117-142, SpringerNew York, 2006

[RVVS00] Rosenberger Shankar, Tara, VanKleek, Max, Vicente, Antonio & Smith,Brian K.: Fugue: A Computer Mediated Coversational System that Sup-ports Turn Negotiation. In: Proceedings of the 33rd Hawaii InternationalConference on System Sciences, 2000

[Sa04] Saint-Andre, P.: Extensible Messaging and Presence Protocol (XMPP),Request for Comments 3920 bis 3923. IETF, 2004

[SCB00] Smith, Marc, J.J. Cadiz und Byron Burkhalter: Conversation trees andthreaded chats. In: Proceedings of the 2000 ACM conference on Com-puter supported cooperative work, S. 97-105, ACM Press, Philadelphia,Pennsylvania, USA, 2000

[Sto01a] Storer, Angelika: Sprachliche Besonderheiten getippter Gespräche:Sprecherwechsel und sprachliches Zeigen in der Chat-Kommunikation.In: Beißwenger, Michael (Hrsg.): Chat-Kommunikation, Sprache, Inter-aktion, Sozialität & Identität in synchroner computervermittelter Kom-munikation, S. 3-24, 2001

[Sto01b] Storrer, Angelika: Getippte Gespräche oder dialogische Texte? Zur kom-munikationstheoretischen Einordnung der Chat-Kommunikation. In:Lehr, Andrea, Kammerer, Matthias, Konerding, Klaus-Peter, Storrer,Angelika, Thimm, Caja & Wolski, Werner (Ed.): Sprache im Alltag. Bei-träge zu neuen Perspektiven in der Linguistik. Herbert Ernst Wiegandzum 65. Geburtstag gewidmet. Berlin.

[VD99] Viegas, Fernanda B. & Donath, Judith S.: Chat Circles. In: Proceedingsof the 1999 ACM Conference on Human Factors in Computing (CHI99), S. 9-16, ACM Press, Pittsburgh, Pennsylvania, USA, 1999

[VSD99] Vronay, David, Smith, Marc & Drucker, Steven M.: Alternative Interfa-ces for Chat. In: Proceedings of the ACM Symposium on User InterfaceSoftware and Technology, S.19-26, ACM Press, Asheville, North Caro-lina, USA, 1999

[Wikipedia07a] Artikel Chat. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand:17. Juni 2007, 13:21 UTC. URL:http://de.wikipedia.org/w/index.php?title=Chat&oldid=33268817 (Ab-gerufen: 20. Juni 2007, 17:27 UTC)

[Wikipedia07b] Artikel Talk (Software). In: Wikipedia, the free encyclopedia. Bearbei-tungsstand: 10. Juni 2007, 15:47 UTC. URL:

http://de.wikipedia.org/w/index.php?title=Chat&oldid=33268817


http://en.wikipedia.org/wiki/Talk_%28software%29 (Abgerufen: 20.Juni 2007, 17:30 UTC)

[Wikipedia07c] Artikel Internet Relay Chat. In: Wikipedia, Die freie Enzyklopädie. Be-arbeitungsstand: 18. Juni 2007, 20:35 UTC. URL:http://de.wikipedia.org/w/index.php?title=Internet_Relay_Chat&oldid=33331918 (Abgerufen: 26. Juni 2007,08:26 UTC)

[Wikipedia07d] Artikel Jabber. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungs-stand: 15. Juni 2007, 20:32 UTC. URL:http://de.wikipedia.org/w/index.php?title=Jabber&oldid=33206483 (Abgerufen: 20. Juni 2007, 17:09 UTC)

[Wikipedia07e] Artikel Baum (Graphentheorie). In: Wikipedia, Die freie Enzyklopädie.Bearbeitungsstand: 12. Juni 2007, 11:38 UTC. URL:http://de.wikipedia.org/w/index.php?title=Baum_%28Graphentheorie%29&oldid=33062340 (Abgerufen: 20. Juni 2007, 20:32 UTC)

http://de.wikipedia.org/w/index.php?title=Baum_(Graphentheorie)&oldid=33062340

http://de.wikipedia.org/w/index.php?title=Baum_(Graphentheorie)&oldid=33062340

http://de.wikipedia.org/w/index.php?title=Jabber&oldid=33206483

http://de.wikipedia.org/w/index.php?title=Internet_Relay_Chat&oldid=33331918

http://de.wikipedia.org/w/index.php?title=Internet_Relay_Chat&oldid=33331918

http://en.wikipedia.org/wiki/Talk_(software)

Alternative Visualisierung von Chat-Beiträgen zur ... Paper... · Chat (von engl. to chat...

Documents

Transcript of Alternative Visualisierung von Chat-Beiträgen zur ... Paper... · Chat (von engl. to chat...