<Thesis>

 

4 CoCuSe - Collaborative Cure Search

Im vorangehenden Kapitel sind verschiedene bereits existierende Systeme präsentiert worden, welche sich mehr oder weniger vielen Teilaspekten einer kooperativen Recherche mit Hilfe des Internets widmen. Man kann aus den Funktionsumfängen schließen, dass es keine fertige Lösung gibt, welche die gestellte Aufgabe gemäß unseren Vorstellungen vollständig umsetzt.

Es kommt erschwerend hinzu, dass sich z.B. populäre Online-Dienste unseren Anpassungswünschen vollkommen entziehen, da weder entsprechende Quellprogramme vorliegen, noch anwendungsspezifische Anpassungen in größerem Ausmaß angeboten werden. In der Regel sind die Freiheiten der Gestaltungen eher begrenzt und beziehen sich auf Art und Weise der Anordnung von Lesezeichen bzw. (gemeinsamen) Artefakten im Allgemeinen.

Bei den Systemen, welche auf eigenen Servern installiert werden können, unterscheidet man zwischen den sog. Binärdistributionen, also unveränderlichen Programmen, und den Distributionen, die Quellprogramme mitliefern. Bei Ersteren gilt erneut, dass deren Unveränderlichkeit weitergehende Anpassungen unmöglich macht. Lediglich im Falle von vorliegenden Quellen ist eine direkte Manipulation des Programmcodes möglich, falls der zugrunde liegende Lizenzvertrag dies erlaubt. Jedoch erfordert dies eine meist sehr zeitaufwendige Einarbeitung in die Programmstruktur und ein bestehendes System ist nicht in allen Fällen problemlos erweiterbar. So stellt sich in diesem Zusammenhang immer die Frage, ob es bei vertretbarem Aufwand lohnt derlei Zeit und Arbeit zu investieren - meist sollten bei dem zu erweiternden bzw. zu modifizierenden System bereits eine Reihe von Funktionen vorhanden sein, da ansonsten auch gleich eine eigenständige Lösung angestrebt werden kann.

Diese Grundvoraussetzungen liegen aus unserer Sicht im Falle von CURE, dem CSCL-Portal der FernUniversität in Hagen, weitestgehend vor. Der Leistungsumfang besitzt eine Reihe von Funktionen, welche benötigt werden. Des weiteren liegt das System im Quelltext vor und da es sich um ein von der FernUni selbst entwickeltes System handelt, gibt es auch für unseren Anwendungsfall keine Komplikationen bzgl. der lizenzrechtlichen Seite. Deshalb wird eine Lösung vorgeschlagen, welche auf CURE basiert, sprich CURE um Komponenten erweitert, welche den Gruppenprozess einer kooperativen Web-Recherche unterstützen.

Das vorgeschlagene System trägt den Namen CoCuSe (ausgesprochen ähnlich dem berühmten französischen Koch Paul Bocuse), der sich aus dem umschreibenden Begriff Collaborative Cure Search, d.h. kooperative CURE-Suche, zusammensetzt. CoCuSe bezeichnet somit in sich die kooperative Recherche in CURE.

In den folgenden Abschnitten wird zunächst auf entscheidende Kriterien von CURE näher eingegangen. Darauf folgt eine umfassende Beschreibung der Ideen hinter CoCuSe an Hand von Entwurfsmustern.

4.1 CURE - Ideen und Konzepte

Die grundlegenden Ideen und Konzepte von Collaborative Universal Remote Education (CURE) sind bereits in Kapitel 3.3.2 angesprochen worden. An dieser Stelle soll es nun etwas konkreter um die Aspekte gehen, die eine besondere Bedeutung in Bezug auf CoCuSe haben.

In Tabelle 3.5 lässt sich für CURE ein interessanter Funktionsumfang ablesen. Als CSCL-Portal oder allgemeiner als CSCW-System bietet CURE eine Arbeitsumgebung für Gruppen und natürlich auch für Einzelpersonen. Insbesondere steht den Gruppenmitgliedern ein gemeinsamer Arbeitsbereich zur Verfügung, welcher universell strukturierbar ist, d.h. flexibel auf die individuellen Bedürfnisse, sowohl der Gruppe selbst als auch deren gemeinsamer Aufgabe, angepasst werden kann. Die im Gruppenbereich hinterlegten Dokumente, usw. werden dabei von den einzelnen Teilnehmern als gemeinsame Artefakte aufgefasst. CURE erfüllt damit die in Kapitel 2.1.4 angesprochenen Kriterien eines CSCW-Systems.

Eine kooperative Web-Recherche zur Unterstützung des Gruppenprozesses benötigt nicht zuletzt aus Sicht des Anwenders drei wesentliche Aspekte, nämlich einen gemeinsamen Arbeitsbereich und gemeinsame Artefakte, des weiteren Mechanismen, die den Zugang zu den Daten und den Verbund des Gruppengefüges verwalten, sowie vereinheitlichte Mittel und Wege, welche jedem einzelnen Teilnehmer den Umgang mit diesen Daten und die Interaktion mit der Gruppe ermöglichen. Genau diese drei Aspekte werden in den nun folgenden Abschnitten besprochen. Der Funktionsumfang von CURE ist gut - CoCuSe nutzt und erweitert diesen, so dass CURE noch besser, sprich leistungsfähiger, wird.

4.1.1 Räume und Seiten

CURE unterscheidet zwischen Räumen und Seiten. Die gesamte Struktur folgt dieser Vorstellung. Einen Raum kann man sich dabei ganz allgemein als ein Behältnis vor Auge führen, das mit Inhalt gefüllt werden kann. Der Inhalt eines Raumes sind dazu passend die Seiten. Es ist festzuhalten, dass es kein Behältnis ohne füllenden Inhalt und keinen Inhalt ohne ein ihn umgebendes Behältnis gibt. Mit anderen Worten hat jeder Raum wenigstens eine ihm zugehörige Seite und eine Seite befindet sich immer innerhalb eines Raumes. In einem CURE-System existiert mindestens ein Raum, die sog. Hall (Eingangshalle), und eine Seite, die sog. Homepage (Startseite) des Raumes. Innerhalb eines Raumes kann der Anwender weitere Seiten anlegen oder auch Nachbarräume erzeugen (Abbildung 4.1.1.a). Die Seiten stellen die kleinste zusammenhängende Informationseinheit dar, während ein Raum eine Sammlung der enthaltenen Seiten repräsentiert.

Abbildung 4.1.1.a : CURE - Raumverzeichnis

Abbildung 4.1.1.a : CURE - Raumverzeichnis

Welche Information in einer Seite letztlich steckt, hängt unter anderem vom Typ der Seite ab. Der einfache Seitentyp ist zugleich Standard in CURE und kann Texte aufnehmen, welche zusätzlich durch spezielle Wiki-Steuerbefehle angereichert werden können, wodurch z.B. Attribute wie fett, kursiv, usw. auf den Text angewendet werden.

Da es sich bei CURE um eine Web-Applikation handelt, welche entsprechende Internettechnologien verwendet und innerhalb eines Web-Browsers auf dem Client-Computer dargestellt wird, findet sich natürlich auch die Möglichkeit Links von einer Seite zur nächsten zu setzen. Dies geschieht im Normalfall durch eine spezielle Wiki-Syntax, welche bei der Darstellung interpretiert und als Link angezeigt wird (Abbildung 4.1.1.b).

Einfache Links beziehen sich ohne weitere Angaben auf andere Seiten innerhalb des gleichen Raumes, wie von der Seite, die den Link enthält. Erweiterte Wiki-Befehle ermöglichen zudem auch die Verlinkung unter Angabe eines Raumes und einer Seite darin. Hierdurch können Verbindungen zwischen den Räumen hergestellt werden - auch zu Räumen, die nicht nebeneinander liegen.

Abbildung 4.1.1.b : CURE - Homepage eines Raumes

Abbildung 4.1.1.b : CURE - Homepage eines Raumes

Eine besondere Form stellen die externen Links dar, hierdurch kann direkt aus der CURE-Umgebung auf Seiten außerhalb von CURE verwiesen werden. Die Darstellung der externen Inhalte erfolgt dabei grundsätzlich in einem neuen Browser-Fenster. Dies ist insofern praktisch und sinnvoll, da man auch beim Zugriff auf externe Inhalte weiterhin direkten Zugriff auf CURE behält und nicht manuell zurückblättern oder gar CURE neu aufrufen muss. Nachteilig mag hier jedoch sein, dass externe Inhalte nicht innerhalb der CURE-Umgebung angezeigt werden und man zwischen den verschiedenen Browser-Fenstern hin und her wechseln muss. Es gibt zwar in CURE auch die Option Inhalte des Linkzieles auf einer Seite innerhalb eines sog. iFrame anzuzeigen, jedoch handelt es sich hierbei nicht mehr im eigentlichen Sinn um einen Link und außerdem werden die Inhalte immer geholt und angezeigt, auch wenn man nicht daran interessiert ist. Ein iFrame ist ein Rahmen innerhalb des Inhaltbereiches einer Seite, in dem eine andere Seite dargestellt werden kann. Diese andere Seite kann sowohl intern als auch extern gelagert sein. Im Gegensatz zu einem Link muss der Anwender nichts anklicken, um den Inhalt zu sehen, auch entfällt die Handhabung weiterer Browser-Fenster. Letzteres wird allerdings durch einige damit verbundene Einschränkungen erkauft, denn es entfallen die verschiedenen Möglichkeiten, die ein separates Browser-Fenster bietet, wie etwa Anpassung der Größenausmaße.

Abschließend sollen aus Gründen der Vollständigkeit die anderen Seitentypen von CURE nicht unerwähnt bleiben. Vieles innerhalb von CURE wird als Seite verarbeitet, auch wenn es dem Anwender nicht unbedingt immer bewusst sein sollte. Jede Nachricht innerhalb des in CURE integrierten Mail-Systems wird beispielsweise als Mail-Seite gespeichert (Abbildung 4.1.1.c). Der Benutzer merkt dies normalerweise nicht, außer eventuell dadurch, dass ihm die weiter oben erwähnten Wiki-Steuerbefehle auch innerhalb des Textes einer Mail zur Verfügung stehen.

Abbildung 4.1.1.c : CURE - Mail-Seite

Abbildung 4.1.1.c : CURE - Mail-Seite

Explizit wählbar sind bei der Seitenerstellung hingegen die kooperativen Seitentypen und der Dateiseitentyp. Zu den kooperativen DyCE-Seitentypen sei an dieser Stelle nur soviel gesagt, dass es sich hierbei um spezielle Dokumentarten handelt, welche es mehreren Gruppenmitgliedern zeitgleich ermöglichen gemeinsam an einem Dokument zu arbeiten - die Gruppe kann z.B. gemeinsam einen Text verfassen oder eine Zeichnung anfertigen.

Abbildung 4.1.1.d : CURE - Datei-Seite

Abbildung 4.1.1.d : CURE - Datei-Seite

Der Dateiseitentyp (Abbildung 4.1.1.d) ist recht universell einsetzbar, da es sich hierbei quasi um einen Umschlag handelt, der ganz allgemein eine (Binär-)Datei aufnehmen kann. Dieser spezielle Seitentyp schafft somit die nötigen Voraussetzungen, um beliebige Dateien, wie z.B. aus Microsoft Word oder Adobe Acrobat, aufzunehmen und innerhalb eines Raumes zu hinterlegen. Handelt es sich um einen Raum der Gruppe, so steht eine Datei allen Mitgliedern zur Verfügung. Da im Grunde jede Art von Datei verarbeitet werden kann, sind vielfältige Nutzungsmöglichkeiten denkbar - neben Software o.ä. können auch multimediale Inhalte abgelegt werden. Ein besonders praktischer Effekt findet sich im Falle von bekannten Bildformaten, so kann der Benutzer innerhalb einer normalen CURE-Seite einen Link auf eine Dateiseite einbetten, wo jedoch nicht wie üblich nur der Link selbst angezeigt wird, sondern automatisch das in der Dateiseite enthaltene Bild zur Darstellung kommt. Hierdurch wird es dem Anwender möglich innerhalb einer Textseite auch Abbildungen einfließen zu lassen.

Das universelle und erweiterbare Konzept der Räume und Seiten wird auch von CoCuSe verwendet. CoCuSe selbst befindet sich aus Sicht des Anwenders innerhalb eines Raumes und zwar in Form von speziellen CoCuSe-Seitentypen. Diese CoCuSe-Seiten basieren auf grundlegenden CURE-Basisseitentypen, so dass alle bekannten Konzepte und Zugriffsarten darauf angewendet werden können - CoCuSe-Seiten können also wie andere Seiten auch z.B. erzeugt oder gelöscht werden. Das Anlegen eines neuen CoCuSe, also einer kooperativen Web-Recherche zu einem anderen Thema, fügt sich harmonisch in die Auswahl des anzulegenden Seitentyps ein - dem Benutzer bietet sich schlicht eine weitere Option der CoCuSe-Seite, neben den bereits bekannten anderen Seitentypen wie z.B. der Datei-Seite (Abbildung 4.1.1.e).

Abbildung 4.1.1.e : CURE - Erstellung einer Seite

Abbildung 4.1.1.e : CURE - Erstellung einer Seite

4.1.2 Benutzer- und Zugriffsverwaltung

Zur Abbildung einer Gruppe als Verbund von Personen, die an einer gemeinsamen Aufgabe zusammenarbeiten, müssen bestimmte Verwaltungsfunktionen existieren, welche auch in CURE enthalten sind. Prinzipiell wird der Benutzer über ein zugehöriges Konto identifiziert. Die Authentifizierung erfolgt über einen Benutzernamen und passendes Kennwort. Der Benutzername kann, soweit nicht bereits vorhanden, frei gewählt werden und sowohl ein Pseudonym als auch Realname sein - in jedem Fall kann und sollte zu jedem Benutzernamen zusätzlich auch der Realname angegeben werden. Bei eingetragenem Realnamen zeigt CURE diesen an, auch wenn die Benutzerkennung anders lautet (Abbildung 4.1.2.a). In der Praxis schafft dies die Möglichkeit einen kurzen einprägsamen Benutzernamen zu verwenden, während andere Personen innerhalb von CURE dennoch den kompletten Namen zu sehen bekommen - dies schafft ein persönlicheres Arbeitsklima als wenn man nur mit kryptischen Pseudonymen arbeiten würde.

Abbildung 4.1.2.a : CURE - Persönliche Benutzungsdaten

Abbildung 4.1.2.a : CURE - Persönliche Benutzungsdaten

Was der einzelne Anwender in CURE tun darf, richtet sich nach den Schlüsseln, die er besitzt. Das Konzept der Schlüssel wird konsequent verwendet, um Zugangsrechte zu realisieren und fügt sich in das Bild der Räume ein. Die mit einem Schlüssel verbundenen Rechte unterteilen sich dabei auf drei Anwendungsbereiche (Abbildung 4.1.2.b). Die Schlüsselrechte regeln, was der Anwender mit dem Schlüssel selbst tun darf. Die Raumrechte definieren, was dem Nutzer mit dem Raum erlaubt ist. Die Interaktionsrechte kontrollieren schließlich, welche Aktivitäten der Benutzer innerhalb eines Raumes mit den Inhalten machen darf. Die Schlüsselrechte betreffen im Einzelnen, das Zurückgeben, Vernichten, Weitergeben und Kopieren eines Schlüssels. Die Raumrechte beziehen sich auf das Betreten, Kopieren und Löschen eines Raumes, sowie auf das Erzeugen eines Nachbarraumes. Die Interaktionsrechte erlauben je nach Grad das Lesen von Inhalten, Kommunizieren mit anderen Teilnehmern, Verfassen von Anmerkungen und Bearbeiten von Inhalten.

Abbildung 4.1.2.b : CURE - Verbundene Rechte eines Schlüssels

Abbildung 4.1.2.b : CURE - Verbundene Rechte eines Schlüssels

Ein Nutzer kommt auf unterschiedlichen Wegen in den Besitz eines Schlüssels. Dies kann z.B. durch das Erzeugen eines Nachbarraumes geschehen, der Eigentümer erhält dabei grundsätzlich alle Rechte. Ein Schlüssel kann aber auch außen an einem Raum hängen, so dass man diesen frei betreten kann. Befindet sich außen kein freier Schlüssel und verfügt der Anwender nicht über das Recht den Raum zu betreten, so kann beim Eigentümer mit Hilfe eines Türklopfers ein neuer Schlüssel erbeten werden. Der Besitzer kann die Rechte selbst festlegen und den neuen Schlüssel an den Anwender übergeben. Mitglieder mit entsprechenden Rechten können aber auch einen vorhandenen Schlüssel an ein anderes Mitglied weitergeben oder eine Kopie anfertigen. Darüber hinaus gibt es noch einen besonderen Weg, wie ein Anwender zu bestimmten Rechten gelangen kann. Normalerweise wird ein Schlüssel einer Person zugeordnet. In manchen besonderen Fällen, etwa einem Kurs innerhalb des Semesters an der FernUni, kann durch die Anmeldungen über die LVU eine Benutzergruppe aus allen Teilnehmern entstehen, welcher als Ganzes ein Schlüssel zugewiesen wird. Ein Benutzer, der Mitglied dieser Benutzergruppe ist, erhält so die mit dem Schlüssel verbundenen Rechte zugeteilt, ohne einen persönlichen Schlüssel explizit erhalten zu haben. Für den Besitzer des Schlüssels vereinfacht dies die Verwaltung, da nicht jeder Einzelperson ein Schlüssel übergeben werden muss, sondern ein zentraler Schlüssel für alle gilt. Änderungen an den Rechten müssen dann nur an einer Stelle geändert werden und gelten sogleich für alle - auch kann etwa am Ende des Semesters sehr einfach der Zugriff reduziert oder gar der Schlüssel komplett zurückgenommen werden.

Abbildung 4.1.2.c : CURE - Gruppenmitglieder

Abbildung 4.1.2.c : CURE - Gruppenmitglieder

Die Zuordnung eines Nutzers zu einer Gruppe von Nutzern (Abbildung 4.1.2.c) erfolgt in der Regel indirekt über Räume und Schlüssel. Zum Beispiel kann man eine Arbeitsgruppe dadurch in CURE abbilden, dass man einen Raum für diese Arbeitsgruppe anlegt. Anschließend bekommt jeder Gruppenteilnehmer einen Schlüssel für den Raum. Den Raum betreten können dann nur die Mitglieder, d.h. der Zugriff auf die Inhalte werden auf die Arbeitsgruppe beschränkt. Die Teilnehmer können als Gruppe zusammenarbeiten und sind dennoch unter sich - Anwender außerhalb der Gruppe haben keinen Zugang, während innerhalb freies Arbeiten möglich ist (Abbildung 4.1.2.d).

Abbildung 4.1.2.d : CURE - Gemeinsame Artefakte

Abbildung 4.1.2.d : CURE - Gemeinsame Artefakte

Da CoCuSe vereinfacht gesprochen dem bestehenden CURE-System eine Recherchekomponente hinzufügt, wird es auch nahtlos in die Nutzung der Rechteverwaltung integriert bzw. kann deren Dienste nutzen. Dementsprechend wird der Zugriff auf CoCuSe indirekt über die Raumrechte und direkt über die Interaktionsrechte gesteuert. Mit anderen Worten erhalten die Anwender Zugang zu CoCuSe, falls ihnen der Zugang zum Raum an sich gewährt ist. Das Erzeugen eines neuen CoCuSe darf z.B. nur ein Benutzer, der über dazu nötige Rechte innerhalb des Raumes verfügt. Die Funktionen von CoCuSe, die in der einen oder anderen Art und Weise die Gruppe bzw. ihre Mitglieder berücksichtigen, orientieren sich zudem an den in CURE hinterlegten Daten über Benutzer, Gruppen und ihren Zugriffrechten.

4.1.3 Benutzeroberfläche

Die graphische Benutzeroberfläche von CURE bildet die Schnittstelle zwischen System und Anwender. Die Darstellung erfolgt innerhalb eines Web-Browsers und verfügt daher auch über die übliche Kombination aus Text- und Bildelementen. Inhalte und Bedienflächen werden gemeinsam dargestellt, wobei sich der Kontext aus den Inhalten einerseits und aus Begrenzungen durch Farbbereiche oder Linien andererseits ergibt. Was der Anwender zu sehen bekommt, hängt also davon ab, worum es gerade geht und auch z.B. von seinen Rechten in Bezug auf die aktuelle Situation.

Abbildung 4.1.3.a : CURE - Raumbezogene Schaltflächen

Abbildung 4.1.3.a : CURE - Raumbezogene Schaltflächen

In der obersten Zeile des Fensters (Abbildung 4.1.3.a) finden sich auf der linken Seite optional Awareness-Informationen in Form von Bildern im Raum anwesender Personen. Daneben gibt es in Form des eigenen Bildes die Schaltfläche zum Erreichen des eigenen Nutzerprofils, wo persönliche Einstellungen angepasst werden können. In der Mitte wird ein Navigationsblock angezeigt, mit dem man zur Homepage des aktuellen Raumes oder zu anderen Räumen gelangt, auch das Abmelden vom Arbeitsbereich ist möglich. Auf der rechten Seite sind Schalflächen erkennbar, die sich auf den aktuellen Raum beziehen. Je nach individueller Verfügbarkeit gibt es hier Schaltflächen um eine neue Seite anzulegen, eine Liste mit letzten Änderungen zu betrachten, die Raum-Mailbox oder den Kalender anzusteuern, den Inhalt des Raumes aufzulisten, nach Inhalten oder Benutzern innerhalb von CURE zu suchen, zu den Eigenschaften des Raumes zu gelangen oder die Bedienungsunterstützung (Hilfe) zu erreichen. Darunter folgt der Inhaltsbereich, welcher entweder den Inhalt einer Seite anzeigt oder auch sonstige Steuerungselemente enthalten kann. Letzteres können Eingabefelder, Listen, usw. sein. Dieser Inhaltsbereich hat oben links je nach Verfügbarkeit Schaltflächen zur Versionsverwaltung der Seite, Navigation durch die Mailbox oder ähnliches. Auf der rechten Seite findet der Nutzer typischerweise Optionen eine Seite zu ändern, löschen, drucken und so weiter. Unterhalb des Inhaltsbereiches erscheint erneut das aus der obersten Zeile bekannte Navigationselement zum Wechsel des Raumes. Je nach Verfügbarkeit kann dann noch ein Chat-Bereich folgen, in dem beteiligte Benutzer, ein Protokoll der Sitzung und das Eingabefeld zu sehen sind. Den Abschluss einer Seite bildet schließlich der Hinweis auf Nutzungsbedingungen und Impressum.

Abbildung 4.1.3.b : CURE - Aktivierte Funktionen eines Raumes

Abbildung 4.1.3.b : CURE - Aktivierte Funktionen eines Raumes

Wie bereits erwähnt ist das Vorhandensein einiger Elemente abhängig vom aktuellen Kontext (Abbildung 4.1.3.b). Falls bei einem Raum z.B. Chat oder Mailbox deaktiviert sind, so werden die zugehörigen Schaltflächen und Bereiche nicht angezeigt. Ebenso fehlt die Schaltfläche zum Bearbeiten der aktuellen Seite, falls der Nutzer nicht über ausreichende Rechte verfügt. Hierdurch wird ein intuitiveres Arbeiten ermöglicht, da der Anwender gar nicht erst mit Möglichkeiten konfrontiert wird, die aktuell für ihn nicht verfügbar sind - die Frage nach neuen Nachrichten in der Mailbox stellt sich gar nicht erst, falls der Raum beispielsweise keine Mailbox hat.

Die Aufteilung der Fensteroberfläche in raum- und seitenbezogene Bereiche, sowie optionale Elemente, kommt auch CoCuSe zugute. Insbesondere der Inhaltsbereich einer Darstellungsseite ist hier von besonderem Interesse, da dieser die optische Verbindung zum Anwender darstellt. Von CoCuSe verwaltete Daten können hier angezeigt und bei Bedarf dem Benutzer über entsprechende Werkzeuge zur Modifikation oder grundsätzlichen Eingabe zugeführt werden.

Die Flexibilität von CURE und das Gesamtkonzept der Seiten ermöglicht CoCuSe einerseits die in die CURE-Umgebung harmonisch integrierte Darstellung und Aufbereitung der Daten. Andererseits kann der Inhaltsbereich einer Seite frei gemäß der individuellen Bedürfnisse von CoCuSe angepasst werden.

Als besonders nützlich erweist sich in diesem Zusammenhang eine technische Gegebenheit von CURE, welche bisher noch nicht erwähnt worden ist. Es geht dabei um die Art und Weise, wie eine Seite intern aufgebaut ist. CURE trennt dabei Darstellung und Daten derart voneinander, so dass ein und der selbe Datenbestand in verschiedenen Arten optisch aufbereitet werden kann. Möglich wird dies durch sog. Templates, dies sind quasi Schablonen, welche grundlegend festlegen, welche Elemente, wo angeordnet werden. Dazu gehören u.a. Schaltflächen oder Eingabefelder. Im weitesten Sinn kann mit dieser Technik eine Darstellung für unterschiedliche Ausgabegeräte erstellt werden, etwa Web-Browser und Handy. Im Falle von CoCuSe bedeutet dies, dass eine neue Anwendung wie die kooperative Web-Recherche in CURE integriert werden kann. Es erfordert dazu lediglich die Erstellung der neuen Seitentypen, während CURE die weiteren Schritte, wie z.B. die Einbettung der Seiteninhaltsbereiche in die Gesamtansicht, übernimmt. Vorhandene Technologie kann somit wieder verwendet und darüber hinaus um neue Aspekte angereichert werden.

Für die Entwicklung von CoCuSe bedeutet dies eine homogene Lösung und für den Anwender ein minimaler Einarbeitungsaufwand, da größtenteils bekannte Elemente verwendet werden und lediglich die neu hinzugekommenen Funktionen erlernt werden müssen - die komplette Einfindung in ein völlig anderes Programmpaket entfällt damit vollständig, was letztlich die Akzeptanz neuer Dienste wie CoCuSe erhöht.

4.2 Design Patterns - Entwurfsmuster

Bei Entwurfsmustern (engl. Design Patterns) handelt es sich um ein allgemeines Verfahren aus dem Bereich der objekt-orientierten Softwareentwicklung. Die grundlegenden Ideen kommen ursprünglich von Christopher Alexander [Alexander 2000], einem in Österreich geborenen und in Amerika lebenden Architekten. Neben seinem Abschluss in Mathematik besitzt er eine Professur in Architektur und hat vor rund drei Jahrzehnten Muster - genauer gesagt eine Mustersprache - zum Entwurf von Gebäuden und Städten entwickelt. Später hatte die mittlerweile auf den Softwareentwurf übernommene Idee der Entwurfsmuster ihren Durchbruch, nach dem Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides - besser bekannt unter dem Namen "Gang of Four" (GoF) - in ihrem 1995 im englischen Original [Gamma 1995] bzw. 1996 in deutsch veröffentlichten Buch "Entwurfsmuster - Elemente wiederverwendbarer objekt-orientierter Software" [Gamma 1996] einen Katalog von Entwurfsmustern vorgestellt haben.

Als Entwurfsmuster werden standardisierte Entwurfsvorschläge für die Softwareentwicklung bezeichnet, die sich auf hohem Abstraktionsniveau der Lösung eines Programmierproblems widmen. Sie beschreiben also eine vordefinierte Lösung, in dem quasi wie bei einem Rezept Anleitungen gegeben werden, wie man schrittweise von einem Problem zu einem konkreten Lösungsansatz kommt - dies geschieht jedoch in Form abstrakter Umschreibungen. Abgesehen davon, dass jedes Muster einen Namen besitzt und somit die Kommunikation über Muster eindeutiger wird, liegt der eigentliche Erfolg darin begründet, dass auf Grund der Abstraktionsebene der Entwurfsmuster keine Festlegung auf bestimmte Programmiersprachen oder Systeme erfolgt. Sie sind also universell anwendbar und sprachunabhängig. Welche Ausmaße dies annehmen kann beschreibt ein Zitat von Christopher Alexander "Jedes Muster beschreibt ein in unserer Umwelt beständig wiederkehrendes Problem und erläutert den Kern der Lösung für dieses Problem, so dass Sie diese Lösung beliebig oft anwenden können, ohne sie jemals ein zweites Mal gleich auszuführen" [Alexander 1977].

Auf weitere Details der Entwurfsmuster und deren Definition und Anwendung soll an dieser Stelle verzichtet werden, da dies im Zusammenhang der kooperativen Web-Recherche im Allgemeinen und CoCuSe im Besonderen nicht unbedingt erforderlich ist.

Von Bedeutung sind Entwurfsmuster in Bezug auf CoCuSe jedoch in der Art, als dass auch bei der Entstehung von CoCuSe verschiedene Entwurfsmuster den Entwicklungsprozess unterstützt haben. Es handelt sich dabei um eine Auswahl von Design Patterns aus dem Katalog von Till Schümmer und Stephan Lukosch [Schümmer 2004]. Der Katalog beinhaltet Entwurfsmuster, die sich speziell auf das Gebiet der Zusammenarbeit von Menschen mit Hilfe von Computern beziehen und daher auch für das Design von CoCuSe interessantes Material vorhalten.

In den nächsten Abschnitten werden die berücksichtigten Entwurfsmuster näher betrachtet. Es geht dabei nicht um eine Besprechung der Muster selbst - dies kann der Katalog ausführlicher leisten - sondern um die Art und Weise, wie das jeweilige Muster bei der Lösung der zugrunde liegenden Aufgabe zum Einsatz gekommen ist. Nicht jedes Muster wird unbedingt vollständig oder in der im Original beschriebenen Variante übernommen, vielmehr werden die Patterns zur Inspiration oder auch als Leitfaden verwendet. Dieser Effekt begründet sich auf der Interpretation der jeweils vorgeschlagenen Lösungsidee, die eine sehr flexible Umsetzung möglich macht - wie oben erwähnt handelt es sich hierbei um einen grundlegenden Aspekt von Design Patterns, welcher den Entwickler nicht einengen, sondern mehr Raum geben soll.

4.2.1 Awareness Proxy

Bei CURE handelt es sich um ein Client/Server-System, d.h. auf dem CURE-Server werden gewisse Dienste angeboten und die Darstellung der Daten und Interaktion mit dem Anwender erfolgt an dessen Client-Computer. Es kommt also während einer CURE-Arbeitssitzung zur Kommunikation zwischen beiden Teilsystemen. Ähnlich verhält es sich beim Zugriff auf Internetseiten, auch hier erfolgt der Zugriff über den Client, den Web-Browser, auf den (Web-)Server. Prinzipiell sind dies zunächst zwei voneinander unabhängige Vorgänge - CURE erfährt nichts von den Kommunikationsphasen mit dem Web-Server, letzterer weiß nichts von CURE.

Eine wesentliche Aufgabe von CoCuSe besteht darin, mit Hilfe von CURE den Zugang zum Internet zur Verfügung zu stellen. CoCuSe muss somit eine Erweiterung des Funktionsumfanges bereitstellen, so dass einerseits Inhalte aus dem Internet beschafft werden können und andererseits CURE über diese Vorgänge informiert wird.

An dieser Stelle kommt nun der sog. Awareness Proxy (Bewusstseinsvermittler) an die Reihe. Die eigentliche Idee dieses Entwurfsmusters [Schümmer 2004, Kapitel 6.3.1] besteht darin, dass eine vermittelnde Komponente, ein Proxy, zwischen Client und Server positioniert wird und die Kommunikationsdaten entsprechend aufbereitet, ohne dass Client oder Server verändert werden müssten. Im Standardfall, also ein Client und ein Server, ist die Position, an welcher der Proxy hinzugefügt wird, klar definiert. Jedoch gibt es in unserer konkreten Anwendung der kooperativen Web-Recherche aus Sicht des Anwenders vereinfacht gesprochen einen Client und zwei Server - in der Praxis ist es ein CURE-Server und zu jeder Internetdomäne (z.B. computer.org) wenigstens ein Web-Server.

Um diese Sicht zu vereinfachen sprechen wir vom Zugriff auf das Internet und abstrahieren so von den einzelnen Servern. Hierdurch ergibt sich quasi zwangsläufig ein klareres Bild vom Aufbau und eine einfachere Struktur unseres neuen Systems. Insofern interpretieren wir den Proxy als einen Mittler zwischen dem Client und dem Internet, welcher jedoch auch den Datenbestand von CURE kontextbezogen berücksichtigt.

Konkret bedeutet dies, dass der Anwender mit CURE arbeitet und auf einer CoCuSe-Seite eine Zieladresse eingeben kann, welche sich auf Inhalte des Internets bezieht. Dies geschieht in einem speziellen Eingabefeld, ähnlich der Adresszeile im Web-Browser. Doch im Gegensatz zum normalen Surfen im Internet werden die Inhalte nicht einfach nur angefordert und nach Erhalt im Browser angezeigt. Die neue Destination wird dem CURE-Server mitgeteilt, damit alles weitere auch innerhalb der CURE-Benutzerumgebung verbleibt. CoCuSe generiert eine entsprechende Darstellung und bettet darin die Internetinhalte ein. Um die Internetdaten an die Situation anzupassen, werden sie vom Proxy bearbeitet. Dieser überprüft die jeweilige Quelldatei aus dem Internet auf ihren Dateityp. Von diesem Typ hängt entscheidend ab, welche weiteren Verarbeitungsschritte erfolgen. Alles, was nicht vom Typ HTML ist, wird dabei unverändert weitergegeben, da z.B. ein Bild keine zusätzlichen Informationen bekommen braucht. Lediglich Inhaltsseiten, die im HTML-Quellformat übertragen werden, müssen modifiziert werden, um z.B. Links derart anzupassen, so dass beim späteren Klicken erneut die Kontrolle bei CURE verbleibt - nur auf diesem Wege bleibt CURE auf dem Laufenden, was die Kommunikation zwischen Client und Internet angeht. Eine Teilaufgabe in Bezug auf Awareness im weitesten Sinn betrifft u.a. die Protokollierung der Anforderungen von Inhalten aus dem Internet eines jeden Benutzers. Diese Daten dienen als Basis für eventuelle Berechnungen wie zum Beispiel ob und wann ein Benutzer eine Internetseite besucht hat. Die Speicherung der Daten erfolgt mit Hilfe des im nächsten Abschnitt beschriebenen Elephant’s Brain.

Die Aktivitäten des Proxy oder gar dessen Existenz bleibt für den Nutzer transparent, d.h. im Verborgenen - während der Nutzung von CoCuSe arbeitet er einfach nur mit CURE. Auf der Client-Seite ist keinerlei Konfiguration des Web-Browsers erforderlich, da der Proxy vom CURE-Server angesprochen wird.

4.2.2 Elephant's Brain

Im vorhergehenden Abschnitt wird beschrieben, wie der Awareness Proxy u.a. Daten über das Nutzungsverhalten des Anwenders erhält. Um Informationen über diese aktuellen Aktivitäten auch jenseits des Momentes nutzen zu können, müssen diese längerfristig abrufbar gespeichert werden.

Einen Lösungsvorschlag für diese Aufgabe liefert das Entwurfsmuster Elephant’s Brain (Langzeitgedächtnis) [Schümmer 2004, Kapitel 6.4.6]. Im Gegensatz zu einer klassischen Änderungsverfolgung werden hier nicht nur Modifikationen an gemeinsamen Artefakten festgehalten, sondern auch z.B. lesende Zugriffe. Die Aktivitäten der Nutzer eines Systems können auf die Art und Weise umfassender berücksichtigt werden.

Abbildung 4.2.2.a : CURE - Änderungsübersicht des gemeinsamen Arbeitsbereiches

Abbildung 4.2.2.a : CURE - Änderungsübersicht des gemeinsamen Arbeitsbereiches

Der unterschiedliche Effekt wird schnell klar am Beispiel zweier Nutzer, wo der Eine häufig Änderungen an Artefakten vornimmt, während der Andere lediglich Inhalte liest - Ersterer würde normalerweise entsprechend oft in der Liste der Aktivitäten erscheinen, jedoch käme Letzterer überhaupt nicht darin vor (Abbildung 4.2.2.a). Im besonderen Falle eines Mehrbenutzersystems, welches die Zusammenarbeit von Gruppenmitgliedern unterstützen möchte, ist dies offensichtlich ein unzureichender Ansatz.

Elephant’s Brain schlägt daher die umfassende Erfassung sämtlicher Zugriffsarten in Verbindung mit Informationen wie Artefakt-, Benutzerkennung und Datum vor. Aspekte von Awareness werden erst durch eine weitgehende Unterstützung vieler Zugriffinformationen möglich bzw. sinnvoll anwendbar - CoCuSe zeigt zu einer Internetseite etwa an, wann und welcher Benutzer die Seite zuletzt besucht hat.

CURE verfügt bereits über grundlegende Funktionalitäten gemäß der Idee eines Langzeitgedächtnisses. Eine große Zahl an Zugriffsinformationen werden hierbei erfasst und persistent in der CURE-eigenen Datenbank hinterlegt. CoCuSe nutzt die existierenden Datenstrukturen und erweitert diese um für die kooperative Web-Recherche relevante Daten, wie z.B. die Adresse einer Internetseite. Diese Erweiterung der Datenbasis erspart bzw. umgeht die doppelte Erfassung und Speicherung der Daten und schafft außerdem ein CURE-konformes Datenformat.

4.2.3 Remember To Forget

Die Möglichkeiten bzw. Fähigkeiten eines Systems wie CURE hängen unter anderem nicht zuletzt von der Zahl der zur Verfügung stehenden Informationen ab. Konkret bedeutet dies, dass etwa die Besuchszeit einer Internetseite nur ermittelt werden kann, wenn diese auch irgendwann zuvor einmal notiert worden ist. Als Entwickler ist man hierdurch immer geneigt möglichst viele Daten dauerhaft vorzuhalten. Allerdings treten hierdurch zwangsläufig neue Probleme zutage, mit welchen das System im Betrieb konfrontiert wird - es müssen immer wieder neue Daten dem bisherigen Datenbestand hinzugefügt oder vorhandene gepflegt werden. Hier kommen dem Einem oder Anderen unter Umständen Assoziationen zum Dachboden, wo man immer wieder irgendwelche Gegenstände unterbringen möchte, jedes Ding seinen Platz in Anspruch nimmt und mit der Zeit der Durchblick in der Sammlung verloren geht, was wiederum ein gelegentliches Aufräumen und Aussortieren nicht weiter benötigter Teile unumgänglich macht.

Um den Aspekt des Aufräumens und Aussortierens geht es bei dem Entwurfsmuster Remember To Forget (Erinnere zu vergessen) [Schümmer 2004, Kapitel 6.4.7]. Bei der Benutzung von Elephant’s Brain fallen ständig neue Daten an, jedoch kann es je nach Kontext vorkommen, dass die gespeicherten Daten für den Benutzer ab einem bestimmten Zeitpunkt keinen Nutzen mehr bringen. Beispielsweise kann im Juli 2006 die bloße Information darüber, dass man an einem Dokument im Februar 1992 eine Änderung vorgenommen hat, im Normalfall als höchstwahrscheinlich vollkommen irrelevant erachtet werden. Selbst wenn einem die zusätzliche Information darüber gegeben wird, was man geändert hat, so bleibt die Frage nach dem Grund für die Modifikation vermutlich offen. In einem solchen Fall ist es nicht sinnvoll entsprechende Aktivitäten weiterhin zu beachten und persistent zu halten. Aus diesem Grund muss der Datenbestand regelmäßig gemäß festzulegender Kriterien durchgesehen und bereinigt werden. Natürlich erfolgt diese Konsolidierung nicht durch eine Person, sondern automatisch durch entsprechende Bereinigungsfunktionen des Systems. Je nach Art der Anwendung müssen dazu praktikable Kriterien gewählt werden, z.B. Art und Länge einer Interaktion mit einem Artefakt.

Für CoCuSe ist dieses Entwurfsmuster in der hier vorgestellten Lösungsvariante von geringerer Relevanz. Die grundlegende Handhabung des Datenbestandes innerhalb des Elephant’s Brain obliegt in erster Linie CURE. Innerhalb des Systems sind dementsprechend die Kriterien anderweitig festgelegt. CURE unterscheidet allgemein zwischen aktiven und gelöschten Objekten, wobei die sog. gelöschten Objekte weiterhin in der Datenbank gespeichert bleiben und lediglich den Status gelöscht erhalten. Hierfür gibt es zwei wesentliche Gründe, zum Einen sind die Kosten für (Festplatten-)Speicherplatz kontinuierlich gesunken und zum Anderen ist diese Vorgehensweise insofern erforderlich, weil CURE u.a. auch das Wiederherstellen gelöschter Objekte zulässt - das System kann natürlich nur Informationen wiederherstellen, die noch vorhanden sind. Es gibt darüber hinaus noch einen weiteren Aspekt, welcher auf Grund der besonderen Situation von CURE an der FernUniversität in Hagen zustande kommt, nämlich dass die Daten zu Forschungszwecken bzgl. des Benutzer- und Systemverhaltens weiterverwendet werden.

Im Falle der kooperativen Web-Recherche kommt ein weiterer Effekt erschwerend hinzu, welcher die (starre) Festlegung von Löschkriterien kompliziert macht. In der Praxis lässt sich nicht vorhersagen, ob z.B. der letzte Besuch einer Internetseite durch einen Benutzer innerhalb der letzten 9 Tage oder aber 6 Monate als bedeutungsvoll erachtet wird. Dies liegt zum Einen daran, dass aus Sicht des Systems lediglich eine Adresse einer Internetseite gespeichert wird, während aus Sicht des Anwenders vielmehr der Inhalt einer Internetseite über den Grad der Bedeutung entscheidet. Beispielsweise ist die Seite einer Tageszeitung mit den Nachrichten des 2. Oktober 2004 normalerweise im Alltag schnell bedeutungslos, wohingegen eine Seite über den grundlegenden Aufbau von Informationssystemen auch nach Jahren noch für einen Informatikstudenten von Nutzen sein kann. Aus den genannten Gründen beschränkt sich CoCuSe auf die von CURE vorgesehenen Vorgehensweisen.

4.2.4 Gaze Over The Shoulder

Das Design Pattern Gaze Over The Shoulder (Blick über die Schulter) [Schümmer 2004, Kapitel 6.3.2] regt in seiner eigentlichen Fassung an, die Aktivitäten der Benutzer im Zusammenhang mit gemeinsamen Artefakten aufzuzeichnen. Dabei geht es um die Art und Weise, wie dies im Falle von proprietären Werkzeugen geschehen kann, ohne die Anwendung an sich zu modifizieren. Im Falle der Kommunikation zwischen Web-Browser und Internet kann beispielsweise ein Proxy zwischengeschaltet werden. Web-Client und -Server werden dabei unangetastet gelassen, jedoch die Kommunikation zwischen den beiden beobachtet und z.B. Awareness-Informationen daraus gewonnen.

Die Umsetzung dieses Musters innerhalb von CoCuSe beschränkt sich auf Grund der andersartigen Umstände auf die grundlegende Idee der Kommunikationsbeobachtung. CoCuSe ist eine Erweiterung von CURE und in diesem Fall liegt der Quellcode vollständig vor bzw. wird passend dazu entwickelt. Insofern ist das Bild des proprietären Werkzeuges auf CURE/CoCuSe nicht zutreffend. Dennoch lässt sich auch in unserer Situation eine Kommunikation zwischen Client und Server bzw. Internet erkennen und beobachten. Allerdings ist es dazu nicht erforderlich den Kommunikationskanal zu betrachten, da CoCuSe derartige Kommunikation bereits per Definition verinnerlicht. CoCuSe ist in die Kommunikation bzw. deren Kontrolle involviert und von daher nicht auf andere Ebenen oder Arten der Kommunikationsüberwachung angewiesen. Der Aspekt des Protokollierens von Aktivitäten des Benutzer auf gemeinsamen Artefakten ist ein elementarer Bestandteil von CoCuSe und wird mit Hilfe von Awareness Proxy und Elephant’s Brain realisiert.

4.2.5 Local Awareness

Local Awareness (örtliches Bewusstsein) [Schümmer 2004, Kapitel 5.3.5] beschreibt einen Weg, um die gefühlte Isoliertheit des Anwenders zu reduzieren. Die Situation kennen viele Menschen, die z.B. im Internet unterwegs sind. Man betritt einen Online-Shop, etwa eine Buchhandlung, und durchstöbert das Regal der aktuellen Bestseller. Scheinbar ist niemand da. Im richtigen Leben könnte man wahrscheinlich weitere Interessenten innerhalb des Geschäftes entdecken. Unter Umständen trifft man sogar an dem eigenen Standort auf eine andere Person, die sich ebenfalls für einen aktuellen Kassenschlager wie z.B. Harry Potter interessiert und man könnte darüber ins Gespräch kommen. In der Online-Welt blicken vielleicht hunderte Menschen in ein und dasselbe Buch, ohne dass der Eine vom Anderen weiß.

Abbildung 4.2.5.a : CoCuSe - Liste der Anwesenden auf der Seite

Abbildung 4.2.5.a : CoCuSe - Liste der Anwesenden auf der Seite

CURE unterstützt die Anzeige von Awareness-Information z.B. in der Art, dass Personen innerhalb desselben Raumes gegenseitig über deren Gegenwart in Kenntnis gesetzt werden können. CoCuSe schafft darüber hinaus ein örtliches Bewusstsein unter den Gruppenmitgliedern, in dem bei der kooperativen Web-Recherche die lokal betrachtete Seite bzw. das zugehörige Lesezeichen Informationen über eventuell anwesende Personen und frühere Besucher auf der gleichen Seite anzeigt (Abbildung 4.2.5.a). Dies bietet bei Bedarf den Anstoß zu einer spontanen synchronen Kommunikation über den in CURE integrierten Chat. Auch weitere Kommunikationsarten sind denkbar, um den Anderen bzgl. des Interesses an der gleichen Seite anzusprechen - allgemein wird die Basis für neue Kontakte geschaffen.

4.2.6 Semantic Net

Durch das Entwurfsmuster Semantic Net (semantisches Netz) [Schümmer 2004, Kapitel 6.2.15] wird die semantische Struktur, also die Beziehungen zwischen den Artefakten, modelliert. Im Allgemeinen stehen Artefakte in Beziehung, wenn Gemeinsamkeiten vorliegen. Im Falle des World Wide Web kann man eine Gemeinsamkeit zwischen zwei Internetseiten z.B. dadurch ableiten, dass es einen Link zwischen ihnen gibt, so dass man von der einen zur anderen Seite gelangen kann - in der Praxis wird z.B. eine Seite über Mäusefallen eher selten eine Verbindung zu einer Seite über Leichtmetallfelgen aufweisen - natürlich ist diese Annahme nicht pauschal gültig für alle existierenden Seiten, Beispiel Suchmaschine. Es gibt bei einem Link per Definition eine Richtung von Seite A nach Seite B. Des weiteren kann eine Gemeinsamkeit auch dann abgeleitet werden, falls es zwar keinen direkten Link von A nach B gibt, jedoch über weitere Seiten dazwischen. Ein solches Netz kann man sich leicht als einen gerichteten Graphen aus Knoten, den Internetseiten, und Kanten, den Links, bestehend vorstellen.

Für CoCuSe erstreckt sich das semantische Netz prinziptheoretisch über alle Seiten und Links des WWW. Die Komplexität des entstehenden Modells wäre sehr groß - bis vor einigen Jahren zeigte die Suchmaschine Google auf ihrer Startseite die Zahl der im Index verzeichneten Internetseiten an, es waren mehrere Millionen. Im Gegensatz zu einem Index liegt der Sinn und Zweck von CoCuSe jedoch nicht in der Erfassung sämtlicher erreichbarer Internetseiten, sondern lediglich in der Beschränkung auf einen von den Gruppenmitgliedern besuchten Teil des WWW. Welche Seiten von den Nutzern in der praktischen Anwendung besucht werden lässt sich jedoch nicht vorhersagen. Allerdings kann CoCuSe beobachten, welche einzelne Seite der Anwender besucht. Ein solche Seite verfügt u.U. über darin enthaltene Links zu anderen Seiten. Genau diese Daten sammelt CoCuSe zur Repräsentation des Ausschnitts.

4.2.7 Semantic Distance

Mit dem Design Pattern Semantic Distance (semantischer Abstand) [Schümmer 2004, Kapitel 6.2.14] geht es um den speziellen Aspekt der Messbarkeit von Gemeinschaft bzw. dem Grad der Beziehung im Hinblick auf das semantische Netz, welches im vorigen Abschnitt beschrieben wird. Im Kontext des Internets ist für den Anwender nicht jede Seite, die über Links erreicht werden kann auch automatisch von Bedeutung. Das semantische Netz enthält jedoch in der Regel sehr viele Seiten und Links, wovon den Nutzer zum Zeitpunkt des Besuches einer speziellen Seite die wenigsten interessieren. Die semantische Distanz dient nun als Maßstab, d.h. als Kriterium zur Abbildung der semantischen Bedeutung innerhalb des semantischen Netzes. Mit anderen Worten ist der Abstand ein Werkzeug, um dem Benutzer eine vereinfachte Sicht auf relevante Seiten zu geben - bildlich gesprochen soll verhindert werden, dass der Anwender den Wald vor lauter Bäumen nicht mehr sieht. Im Modell werden dazu die Kanten zwischen Knoten gewichtet, so dass zwei Knoten mit intensiverer Beziehung ein höheres Gewicht erhalten. Auf das WWW übertragen heißt dies, dass direkte Links zwischen zwei Seiten ein höheres Gewicht erhalten als Verbindungen, die über mehrere Link-Schritte zustande kommen. Den Abstand kann man sodann als Zahl der Schritte interpretieren - beispielsweise hat ein direkter Link den Abstand eins zwischen zwei Seiten A und B, liegt zwischen A und B noch eine Zwischenseite C so beträgt der Abstand zwei und so weiter.

Bei dem dieser Arbeit zugrunde liegenden Vorschlag eines Prototypen von CoCuSe beschränkt sich dieser auf die Berücksichtigung semantischer Abstände der Länge eins. Für eine prinzipielle Demonstration der Machbarkeit reicht die Einbeziehung direkter Links vorerst aus. Um jedoch mehr Freiheiten bei der Interpretation der erfassten Daten zu erreichen, belässt es CoCuSe nicht einfach bei der Speicherung der Link-Information, wie sie in der vorhandenen Struktur vorliegt. Vielmehr werden zur Unterstützung des semantischen Netzes nicht nur die von einer Seite wegführenden Links notiert, sondern auch soweit möglich die eingehenden, d.h. auf die Seite zeigenden, Links - es lässt sich leicht nachvollziehen, dass diese Art der Erfassung schneller Verknüpfungen zwischen Seiten zusammenstellen kann, als es im Falle der unidirektionalen Verfolgung der wegführenden Links gegeben wäre. Wechselt der Benutzer von einer Seite A über einen Link zur Seite B, so erfasst CoCuSe z.B. die Link-Information von A nach B im Sinne eines von A ausgehenden Links zu B - auf Seite B angekommen ist es mit Hilfe der Verfolgung des Navigationspfades trivialerweise möglich A als Startpunkt des Links mit Zielpunkt B zu vermerken, also A als eingehenden Link in B.

4.2.8 Active Neighbours

Durch das Entwurfsmuster Active Neighbours (aktive Nachbarn) [Schümmer 2004, Kapitel 5.3.2] wird die Reichweite der Awareness-Information erweitert. Während sich Local Awareness (siehe Kapitel 4.2.5) um die verschiedenen Nutzer eines gemeinsamen aktuell betrachteten Artefaktes kümmert, geht es hier um den Blick in die Umgebung. Es wird davon ausgegangen, dass es in der Praxis nicht sehr häufig vorkommt, dass sich mehrere Personen bei der Verwendung des gleichen Artefaktes begegnen. Vielmehr kommt es zu der Annahme, dass Benutzer auf benachbarten Artefakten häufiger anzutreffen sind und es daher auch eher zu einer Zusammenarbeit kommen könnte. Die Nachbarschaft zweier Artefakte meint in diesem Sinne nicht zwangsläufig eine räumliche, sondern eine semantische Nachbarschaft. Semantische Aspekte kommen in den beiden vorangegangenen Pattern zum Tragen und Active Neighbours steht auch in diesem Zusammenhang. Die Relevanz von Aktivitäten anderer Nutzer auf benachbarten Artefakten wird mit Hilfe des semantischen Abstandes bemessen. Die Bedeutung der aktiven Nachbarn für den lokalen Benutzer wird umso größer eingeschätzt, je geringer die semantische Distanz ist. Im Ergebnis soll der Anwender also nur auf andere Personen aufmerksam gemacht werden, die möglicherweise in seinem Kontext von Bedeutung sind - im Beispiel der Buchhandlung wird der Leser von Science Fiction Büchern vermutlich auf einen Kontakt mit einem anderen Leser von Kindermärchen verzichten wollen.

Abbildung 4.2.8.a : CoCuSe - Aktive Nachbarn auf Seite mit Link von hier nach dort

Abbildung 4.2.8.a : CoCuSe - Aktive Nachbarn auf Seite mit Link von hier nach dort

Bezogen auf das zuvor beschriebene Design Pattern ergibt sich bei der Übertragung auf die Lage im Internet die Interpretation, dass der Besucher einer Internetseite nur auf Besucher anderer Internetseiten aufmerksam gemacht wird, falls diese Seiten untereinander in enger Beziehung stehen. Gemäß der gemachten Definition liegt eine enge Beziehung vor, wenn direkte Links die Seiten verbinden. Normalerweise würde die Berechnung des Beziehungsgrades, sprich der semantischen Distanz, wie erwähnt nur in eine Richtung gehen, also nur Seiten erfassen, welche von der aktuellen Seite aus per Link erreichbar sind (Abbildung 4.2.8.a). Durch die Erweiterung in CoCuSe auf bidirektionale Links im weitesten Sinne kommen jedoch auch noch die Seiten hinzu, welche einen Link auf die vom Anwender aktuell betrachtete Seite besitzen (Abbildung 4.2.8.b). Unter Umständen entsteht somit Nachbarschaft auch zwischen zwei Personen, selbst wenn der lokale Anwender auf der besuchten Seite keinen direkten Link zur anderen Seite besitzt. Da der andere Anwender jedoch über einen direkten Link verfügt, existiert diese Nachbarschaft in der Tat und kann somit beiden Nutzern signalisiert werden. Man beachte den Unterschied, dass normalerweise nur Einer der Beiden in einer Nachbarschaftsbeziehung zum Anderen stehen würde - in der realen Welt wäre dies ein unrealistisches Bild, da zwei Personen vor dem Käseregal im Supermarkt offensichtlich ein gemeinsames Interesse haben.

Abbildung 4.2.8.b : CoCuSe - Aktiver Nachbar auf Seite mit Link von dort hierher

Abbildung 4.2.8.b : CoCuSe - Aktiver Nachbar auf Seite mit Link von dort hierher

4.2.9 Presence Indicator

Mit dem Entwurfsmuster Presence Indicator (Anwesenheitsanzeige) [Schümmer 2004, Kapitel 5.3.16] folgt erstmalig eine Problemlösungsbeschreibung, welche sich auf die Art und Weise der Visualisierung von (Awareness-)Informationen bezieht.

Bei der genauen Betrachtung einer Benutzeroberfläche im Allgemeinen und einer Internetseite innerhalb eines Browser-Fensters im Besonderen fällt auf, dass vielfach die vorhandene Fläche weitestgehend genutzt wird. Die Darstellung von Aktivitäten anderer Benutzer stellt eine Herausforderung dar, da dem Anwender einerseits die Anwesenheit anderer Benutzer auf dem gleichen oder benachbarten Artefakt mitgeteilt werden, jedoch andererseits die betrachtete Seite möglichst unverändert bleiben soll - die Arbeit an den gemeinsamen Artefakten darf nicht unnötig gestört oder gar behindert werden. Der Vorschlag ist folgerichtig dahingehend, dass die Zusatzinformation räumlich begrenzt wird. In einer Arbeitsgruppe mit 10 aktiven Teilnehmern nimmt beispielsweise die Auflistung der neun Anderen auf der aktuell vom Anwender betrachteten Seite viel mehr Raum ein, falls dies in Form eines Textes oder einer Tabelle geschieht. Deutlich weniger Platz beansprucht hingegen die Visualisierung durch ein Symbol (engl. Icon), welches einen oder mehr Benutzer repräsentiert.

Abbildung 4.2.9.a : CoCuSe - Anzeigesymbole für Anwesende und Nachbarn

Abbildung 4.2.9.a : CoCuSe - Anzeigesymbole für Anwesende und Nachbarn

In der kooperativen Web-Recherche mit CoCuSe trifft dieser Aspekt unterschiedlich intensiv zu. Im Falle der CoCuSe-Seitentypen handelt es sich um die eigene Benutzeroberfläche von CoCuSe. Dies bedeutet, dass diese ohnehin gemäß den Bedürfnissen von CoCuSe gestaltet ist und angezeigte Informationen jedweder Art essentieller Bestandteil von CoCuSe sind. Eine Störung im eigentlichen Sinne kommt somit nicht direkt zustande. Die optische Darstellung der Internetseite erfolgt auf den Lesezeichen bzw. der Navigation innerhalb eines iFrame, wodurch die Umgebung gänzlich CoCuSe zur Verfügung steht. Sollen bestimmte Informationen innerhalb des iFrame zusätzlich angezeigt werden, so erfolgt dies sodann über geeignete Repräsentationen, um Irritationen bei der Differenzierung zwischen Inhalten und Zusätzen seitens des Benutzers gering zu halten. Konkret bedeutet dies, dass aktive Nachbarn innerhalb des iFrame durch grüne Icons rechts vom Link repräsentiert werden. Erweiterte Informationen zu dem Link und seinen Besuchern erhält der Anwender durch ein kleines JavaScript-basiertes PopUp-Fensterchen, sobald sich der Mauszeiger über dem Symbol befindet - das Fenster schließt sich entweder implizit durch Ansteuern eines anderen Icons oder explizit durch Betätigen einer Schaltfläche. Zusätzlich kann am Ende der Seite ein Icon auf Nachbarn hinweisen, welche sich auf Seiten befinden, welche einen Link zur aktuellen Seite aufweisen - diese Darstellungsform ist erforderlich, da eingehende Links naturgemäß nicht sichtbar sind und somit als Bezugspunkt wegfallen. Anwesende auf der gleichen aktuell angezeigten Seite werden durch blaue Icons direkt unterhalb des iFrame visualisiert (Abbildung 4.2.9.a).

4.2.10 Swarm And Collect

Bei Swarm And Collect (Ausschwärmen und Sammeln) [Schümmer 2004, Kapitel 5.2.7] beschreibt das Entwurfsmuster weder eine technische Lösung, noch die optische Aufbereitung von Daten. Es handelt sich um einen Arbeitsvorschlag für eine Gruppe. Genauer gesagt geht es um die Aufgabe einer Recherche in großen Datenmengen. Für diese Vorstellung wird angenommen, dass die Menge an Informationen viel zu umfangreich ist, als dass eine Person allein diese vollständig durchqueren könnte. Um dieses Problem mit den vorhandenen Teilnehmern innerhalb des gegebenen Zeitraumes zu umgehen, machen sich die Teilnehmer unabhängig voneinander auf und sammeln relevant erachtete Informationen in einem gemeinsamen Arbeitsbereich. Zu einem späteren Zeitpunkt können dann die Teilergebnisse diskutiert und konsolidiert werden.

CoCuSe besitzt die Idee des Ausschwärmens und Sammelns als grundlegendes Konzept. Einzelne Teilnehmer können im World Wide Web für eine Gruppenaufgabe relevante Internetseiten mit einem Lesezeichen markieren, wodurch diese unmittelbar im gemeinsamen Arbeitsbereich der Gruppe zur Verfügung stehen. Damit sich die Teilgebiete möglichst geringfügig überschneiden, unterstützt CoCuSe u.a. durch Anzeige vorheriger Besucher einer Seite. Über im weiteren Verlauf des Kapitels näher erläuterte Werkzeuge kann die Gruppe das zusammengetragene Material konsolidieren und auf ein gemeinsames Ergebnis reduzieren.

4.2.11 Distinct Awareness Info

Die Distinct Awareness Info (Unterscheidende Bewusstseinsinformation) [Schümmer 2004, Kapitel 5.3.12] gibt einen Hinweis auf die Art und Weise der Präsentation von Awareness-Information. Es geht schlichtweg darum, dass sich die Awareness-Information klar von den anderen Inhalten abheben, sprich unterscheiden, sollte. Gleichzeitig wird angeregt, dies in einer weniger aufdringlichen Weise zu realisieren. Man stelle sich vor, dass die Awareness-Information in leuchtenden Neonfarben, gelb und grün blinkend, dargestellt würde - der Anwender würde sie sicherlich bemerken, jedoch wäre die Ablenkung vom eigentlichen Inhalt vermutlich derart groß, dass die Arbeitskonzentration stark reduziert wäre.

CoCuSe verzichtet bei der Visualisierung grundsätzlich auf übertriebene Effekte und ist des weiteren um eine adäquate Darstellung, welche den Benutzer informiert und nicht irritiert, bemüht. Sowohl die Positionierung als auch die Farben der Icons erleichtern ein intuitives Wahrnehmen und Verstehen der zusätzlichen Informationen und sind dennoch unaufdringlich (Abbildung 4.2.11.a). Das dezente Blau der Symbole für Local Awareness passt sich harmonisch in die CURE-Oberfläche ein, während sich das angenehme Grün der Symbole für Active Neighbours vorteilhaft vom Hintergrund einer durchschnittlichen Internetseite abhebt.

Abbildung 4.2.11.a : CoCuSe - Harmonisch eingebettete Symbole

Abbildung 4.2.11.a : CoCuSe - Harmonisch eingebettete Symbole

4.2.12 In-Place Awareness View

Das Pattern In-Place Awareness View (Unmittelbare Bewusstseinsansicht) [Schümmer 2004, Kapitel 5.3.15] beschäftigt sich erneut mit der Darstellung von Informationen. Zum Beispiel ist es im Falle von Awareness-Informationen aus Sicht des Anwenders von Bedeutung, an welcher Stelle die Daten angeordnet sind. Ist die Anordnung nicht eindeutig, so fällt es dem Nutzer schwerer eine Zuordnung zwischen der Zusatzinformation und dem bezogenen Objekt herzustellen. Deshalb sollte eine Darstellung in unmittelbarer Nähe zu dem Objekt erfolgen, auf welches sich die Information bezieht.

Abbildung 4.2.12.a : CoCuSe - Informationen in der Zusammenfassung

Abbildung 4.2.12.a : CoCuSe - Informationen in der Zusammenfassung

CoCuSe folgt diesem Gedanken und platziert beispielsweise den Hinweis auf andere Anwesende auf der aktuellen Internetseite unmittelbar am unteren Rand des iFrame, welcher die eigentliche Inhaltsseite darstellt. Im Allgemeinen lässt sich die grundlegende Idee des Entwurfsmusters jedoch nicht immer konsequent umsetzen. Falls sich gleich mehrere Informationen auf ein und dasselbe Objekt beziehen, so können in der Praxis nicht immer alle Informationen am Nächsten am Objekt sein. Hier wird zwangsläufig eine Priorisierung der einzelnen Informationen notwendig, wodurch der optische Abstand der unterschiedlichen Daten zum Objekt variieren wird. Dies hängt jedoch vom Einzelfall ab und muss entsprechend separat abgewogen werden. Je nach Anwendung ist auch eine Reduzierung auf ein Symbol denkbar, worunter die objekt-bezogenen Informationen gebündelt zusammengefasst werden.

Konkret wird dies für CoCuSe am Beispiel der Informationsblöcke unterhalb des iFrame, welche zunächst lediglich eine kurze Zusammenfassung (Abbildung 4.2.12.a) oder bei Bedarf erweiterte Informationen anzeigen. Im Falle eines Lesezeichens sind es maximal drei Blöcke, wobei erst die aktuell Anwesenden, dann die früheren Besucher und letztlich die Bewertungen an der Reihe sind - die Reihenfolge orientiert sich an der Bedeutung für den Anwender. Wie in 4.2.9 bereits beschrieben erfolgt die Positionierung der Symbole für aktive Nachbarn immer unmittelbar am Objekt, d.h. neben dem Link.

4.2.13 Letter Of Recommendation

Der Letter Of Recommendation (Empfehlungsschreiben) [Schümmer 2004, Kapitel 4.2.4] spricht quasi den Transfer von Wissen bzw. den Erfahrungsaustausch in besonderer Form an. In der originalen Definition dieses Musters geht es um ein spezielles Problem bei der Zusammenarbeit in virtuellen Umgebungen. Benutzer kennen sich untereinander nicht oder nicht sonderlich gut und wie im richtigen Leben kann es daraufhin zu einem gewissen Maß an Misstrauen unter den Teilnehmern kommen, was die Vertrauenswürdigkeit des Teilnehmers oder seiner Äußerungen angeht. Um dem entgegenzuwirken wird ein Bewertungsverfahren vorgeschlagen, so dass Benutzer sich gegenseitig bewerten. Der eine Benutzer kann dann in dem Bewertungsprofil eines anderen Nutzers die Erfahrungen anderer Anwender mit dieser Person nachlesen.

Ein prominentes Beispiel für die Anwendung dieses Design Patterns ist das Online-Auktionshaus eBay [Ebay 1995]. Jeder Benutzer besitzt zu seinem Benutzerkonto ein zugehöriges Bewertungsprofil, welches die Anzahl seiner erhaltenen Bewertungen, sowie eine genaue Aufstellung über die drei möglichen unterschiedlichen Bewertungsarten samt Kommentaren anzeigt (Abbildung 4.2.13.a). Zwei Geschäftspartner eines Handels bewerten sich gegenseitig und berichten auf diese Weise der Gemeinschaft der eBay-Nutzer, welche Erfahrungen bei diesem Handel mit diesem Nutzer gemacht worden sind. Nach Einsichtnahme in das Bewertungsprofil kann man also selbst entscheiden, ob man einen unbekannten potentiellen Handelspartner als vertrauenswürdig einstuft oder nicht.

Abbildung 4.2.13.a : eBay - Bewertungsprofil

Abbildung 4.2.13.a : eBay - Bewertungsprofil

Die Idee der Bewertungen ist in CoCuSe aufgegriffen worden, um eine Unterstützung der gemeinsamen Recherche anzubieten. Allerdings macht die gegenseitige Bewertung der Gruppenteilnehmer in unserem Kontext nur bedingt Sinn, da sich eine (kleine) Arbeitsgruppe in vielen Fällen nicht gänzlich zufällig bildet und sich die Teilnehmer gegenseitig mehr oder weniger kennen bzw. vertrauen müssen. Im Beispiel einer Seminargruppe, welche zu einem Thema gemeinsam Literatur sammelt, ist es eher nebensächlich, welche Charaktereigenschaften ein Teilnehmer besitzt. Vielmehr arbeiten die Teilnehmer an einer gemeinsamen Aufgabe und diese besteht bei der kooperativen Web-Recherche konkret in der Ansammlung von Lesezeichen.

In diesem Sinne ist es nur konsequent ein Bewertungsprofil auf Lesezeichen zu beziehen (Abbildung 4.2.13.b), denn es geht letztlich darum, die guten von den schlechten Lesezeichen zu trennen. Demzufolge bietet CoCuSe jedem Gruppenteilnehmer die Möglichkeit ein Lesezeichen zu bewerten. Eine Bewertung besteht aus zwei Teilen, einer Note und einem Kommentar. Die Bewertungszahl oder -note kann entweder negativ, neutral oder positiv ausfallen. Der Bewertungskommentar gewährt eine freie Formulierung bzw. Beschreibung einer Meinung oder Erfahrung. Abgegebene Bewertungen zusammen mit Information über Autor und Datum der Bewertung werden dem Betrachter eines Lesezeichens angezeigt.

Abbildung 4.2.13.b : CoCuSe - Bewertungen in erweiterter Darstellung

Abbildung 4.2.13.b : CoCuSe - Bewertungen in erweiterter Darstellung

Eine zusätzliche Unterstützung erfährt der Gruppenprozess durch eine Auswertung der Bewertungen. Die Lesezeichen werden an einer Stelle zentral gesammelt. Da die Gruppe aus diesen Daten durch Konsolidierung am Ende zu einem gemeinsamen Gruppenergebnis kommen soll, hilft CoCuSe automatisch bei der Ermittlung der Ergebnismenge. Sobald die Hälfte der Gruppenmitglieder ein Lesezeichen positiv, also für das Ergebnis relevant, bewertet hat, überführt CoCuSe das Lesezeichen aus dem Sammelbereich in den Ergebnisbereich. Hierdurch wird die Ergebnisfindung aktiv unterstützt und die Entwicklung der Zusammenarbeit für alle Mitglieder transparenter.

4.2.14 From Shared Data To Shared Work

Zum Abschluss der Betrachtung der Entwurfsmuster betrifft From Shared Data To Shared Work (Von gemeinsamen Daten zu gemeinsamer Arbeit) [Schümmer 2004, Kapitel 4.1.7] die Situation während der Arbeit an gemeinsamen Artefakten. Es geht vor allem um einen Effekt, dass Benutzer zwar an gemeinsamen Artefakten arbeiten, jedoch die Aktivitäten anderer Benutzer nicht hinreichend berücksichtigt werden. Durch dieses Unwissen über andere stattfindende Arbeiten von Gruppenmitgliedern kann es zu gleichzeitigen, mehrfachen oder auch sich gegenseitig behindernden Aktivitäten kommen. Durch den Einsatz geeigneter Hilfsmittel kann dies frühzeitig erkannt oder bestenfalls verhindert werden, indem die Teilnehmer darüber informiert werden.

Ursprünglich ist dieses Entwurfsmuster in das Beispielszenario einer Groupware-Lösung eingebettet, wo mehrere Mitarbeiter ein und dasselbe Artefakt bearbeiten, dies jedoch erst nach getaner Arbeit bemerken. CoCuSe wendet diese Problematik konsequent auf Lesezeichen bzw. Internetseiten an und bietet dem Anwender geeignete Maßnahmen zur Vermeidung von unnötiger Mehrfachbearbeitung. Konkret bedeutet dies, dass CoCuSe z.B. zu einer Internetseite Informationen über die letzten Besuchszeiten der Teilnehmer bereitstellt (Abbildung 4.2.14.a). Beim Betrachten einer Seite erfährt der Anwender, welches Teammitglied zeitnah mit dieser Seite gearbeitet hat. An Hand der Bewertungsliste kann er sich tiefergehend über Erfahrungen anderer erkundigen. Eine Internetseite, die zwar zuvor von einem anderen Gruppenteilnehmer besucht, jedoch nicht als Lesezeichen markiert worden ist, kann den Anwender unter Umständen motivieren zu diesem Mitglied Kontakt aufzunehmen und zu der Seite zu befragen, falls dies notwendig erscheint. Auch können sich zwei gleichzeitig auf einer Seite verweilende Teilnehmer über das weitere Vorgehen abstimmen. Die vorhandenen Kommunikationswerkzeuge stehen zu diesem Zwecke bereit.

Abbildung 4.2.14.a : CoCuSe - Besucherliste einer Internetseite

Abbildung 4.2.14.a : CoCuSe - Besucherliste einer Internetseite

CoCuSe kann durch die Erkennung solcher Überschneidungen und Weitergabe entsprechender Hinweise an den Benutzer zur Verbesserung der Gruppeneffizienz einen Beitrag leisten.

4.3 Index-Seiten

Nach dem nun CoCuSe in Bezug auf Entwurfsmuster und deren Grad an Einbeziehung in die Entwicklung und Konzepte ausführlich beleuchtet worden ist, steht noch eine genaue Betrachtung der von CoCuSe bereitgestellten Seitentypen aus. Die Seiten stellen aus Sicht des Anwenders letztlich auch die Benutzeroberfläche dar, sind also der Teil, über welchen die Repräsentation der Inhalte und die Interaktion während einer Arbeitssitzung erfolgt.

Im Verlauf dieser Arbeit ist CURE als Basissystem beschrieben und unter anderem das darin umgesetzte Seitenkonzept erläutert worden. CoCuSe erweitert den Bestand an vorhandenen Seitentypen um neue Typen, welche speziell auf die Bedürfnisse der kooperativen Web-Recherche zugeschnitten sind.

Ein wichtiger Typ ist die Index-Seite von CoCuSe. Sie stellt quasi die Zentrale aus Sicht des Anwenders dar. Die Index-Seite, kurz Index, ist nach dem Erzeugen einer CoCuSe-Instanz innerhalb eines Raumes das Erste, was der Nutzer erblickt. Zunächst ist der Index noch leer, jedoch befindet sich ein Eingabefeld im oberen Bereich. Durch Eingabe einer Internetadresse kann der entsprechende Inhalt angefordert und angezeigt werden.

Hat ein Anwender eine interessante Seite gefunden und ein Lesezeichen gesetzt, so erscheint dieses Lesezeichen im Index (Abbildung 4.3.a). Über den zugehörigen Eintrag kann das Lesezeichen erneut aufgerufen werden.

Abbildung 4.3.a : CoCuSe - Index einer kooperativen Web-Recherche

Abbildung 4.3.a : CoCuSe - Index einer kooperativen Web-Recherche

Die Liste der Lesezeichen auf der Index-Seite gliedert sich in zwei separate Bereiche. Im oberen Bereich befinden sich die gesammelten Lesezeichen, welche nicht der Ergebnismenge angehören. Wie bereits erwähnt entsteht die Ergebnismenge durch die positiven Bewertungen der Gruppenmitglieder und wird im unteren Bereich angezeigt. Der Benutzer kann klar ersehen, welche Lesezeichen bereits über hinreichend viele positive Meinungen verfügen und welche von der Gruppe bisher nicht als ausreichend relevant erachtet werden.

4.3.1 Kategorien

Der Begriff der Kategorie wird mitunter auch als Rubrik oder Klasse interpretiert und gemeint ist hier einfach nur die Klassifikation von Lesezeichen zu einem gemeinsamen Themenkomplex.

Um die Übersichtlichkeit der Index-Seite im Verlauf des Gesamtprozesses nicht unnötig zu strapazieren, ist ganz bewusst auf die Nutzung von Kategorien verzichtet worden. Des weiteren widerspricht das Einbringen unterschiedlicher Themenklassen innerhalb einer Instanz von CoCuSe auch dem Verständnis der kooperativen Web-Recherche, wie es bei CoCuSe zugrunde liegt. Durch die Erzeugung eines CoCuSe unter einem bestimmten Namen wird ja gerade eine Klasse (oder Kategorie) von Lesezeichen generiert. Die Anwendergruppe wird ermuntert zu jeweils einem gemeinsamen Thema jeweils ein separates CoCuSe zu verwenden. Folgt man dieser Ideologie, so ergeben sich die Kategorien von selbst und ein weiterer Bedarf innerhalb des Index wird hinfällig. In der Praxis wird eine thematische Trennung von Lesezeichen auch insofern empfohlen, da ein Lesezeichen durchaus im Zusammenhang des einen Themas relevant, jedoch für ein anderes Thema unbedeutend sein kann. Auch entstehen dem Nutzer keinerlei Nachteile hierdurch, da mehrere CoCuSe-Einheiten innerhalb desselben Raumes unterstützt werden - es entfällt so auch etwa die Notwendigkeit einen weiteren Raum zu erzeugen oder die Gruppe neu zu formieren.

4.4 Navigator-Seiten

Der zweite wichtige Seitentyp von CoCuSe ist die Navigator-Seite. Es existiert immer genau eine Navigator-Seite, kurz Navigator, zu einem CoCuSe-Index. Wie der Name bereits vermuten lässt, dient der Navigator der Navigation durch das World Wide Web. Normalerweise benutzt man zum Surfen im Internet einfach nur den Web-Browser. Da es für die Nutzung von CoCuSe jedoch erforderlich ist innerhalb der CURE-Umgebung zu verbleiben, wird eine gemeinsame Schnittstelle zwischen CURE und WWW benötigt, die aus Benutzersicht beide Welten miteinander verbindet.

Abbildung 4.4.a : CoCuSe - Navigator auf Wikipedia Portal Wissenschaft

Abbildung 4.4.a : CoCuSe - Navigator auf Wikipedia Portal Wissenschaft

Entsprechend werden dem Nutzer während der kooperativen Web-Recherche die besuchten Internetseiten innerhalb eines iFrame auf der Navigator-Seite (Abbildung 4.4.a) präsentiert.

Auf Grund der diversen im Hintergrund stattfindenden Verarbeitungsschritte kann der Anwender innerhalb des iFrame die Internetseite normal verwenden - beispielsweise kann nach unten oder oben geblättert und auch darin enthaltene Links angeklickt werden, der Navigator folgt dem Seitenwechsel.

Die gewohnten Schaltflächen zum Erreichen von CURE-Funktionen bilden einerseits den üblichen Rahmen, andererseits kommen neue Schaltflächen und Bereiche hinzu, welche die zusätzlichen CoCuSe-Funktionen bereitstellen. Der Anwender erfährt zum Einen den Kontext seiner Recherche durch den Namen dieser CoCuSe-Einheit. Im oberen Bereich findet sich die Index-Schaltfläche, wodurch ein Wechsel zur Übersicht der Lesezeichen, dem Index, eingeleitet werden kann, sowie daneben das Eingabefeld für ein neues Internetziel wieder, welches von der Index-Seite bekannt ist. Ist die angezeigte Internetseite noch nicht mit einem Lesezeichen markiert, so kann dies durch Eingabe eines Namens für das Lesezeichen und Betätigen einer entsprechenden Schaltfläche erfolgen. Darunter wird die aktuell betrachtete Seitenadresse in Form der URL angezeigt. Unterhalb des iFrame mit dem Seiteninhalt kann z.B. ein Hinweis auf andere Anwesende oder frühere Besucher angezeigt werden.

4.5 Bookmark-Seiten

Die Bookmark-Seiten, kurz Bookmarks, bilden die Basis für abgelegte Lesezeichen und sind ein weiterer Seitentyp in CoCuSe. Im Gegensatz zu den beiden anderen Seitentypen ist die Zahl der Bookmarks pro CoCuSe-Einheit nicht begrenzt. Der optische Aufbau (Abbildung 4.5.a) lehnt sich an Darstellung und Funktion einer Navigator-Seite an, bietet jedoch darüber hinaus weitere Elemente, welche im Folgenden beschrieben werden.

Abbildung 4.5.a : CoCuSe - Bookmark für Photo von Konrad Zuse

Abbildung 4.5.a : CoCuSe - Bookmark für Photo von Konrad Zuse

Der Eingabebereich für die Anlage eines neuen Lesezeichens ist natürlich auf der Bookmark-Seite nicht vorhanden, da es sich bereits um ein Bookmark handelt und nicht mehr erzeugt werden braucht. Stattdessen wird die Art des Lesezeichens angezeigt. Wie weiter oben dargelegt, unterscheidet CoCuSe zwischen gesammelten Lesezeichen, sog. Favoriten (engl. Favourites), und Lesezeichen der Ergebnismenge, sog. Ergebnisse (engl. Results). Der Benutzer erhält auf diese Art und Weise eine zusätzliche Information über den aktuellen Status des Lesezeichens.

4.5.1 Bewertungskommentare

Unterhalb des iFrame gibt es zusätzlich Informationen zu den abgegebenen Bewertungskommentaren, so dass der Anwender auf einen Blick nicht nur die bloße Existenz wahrnehmen, sondern auch konkret die Meinungen anderer Gruppenmitglieder nachlesen kann. Neben der erweiterten Information in Form einer tabellarischen Auflistung der Bewertungsnoten und -texte, sowie Angaben über Autor und Datum des Eintrages, wird grundsätzlich auch ein Bewertungsprofil angezeigt. Dieses informiert übersichtlich, wie viele Gruppenteilnehmer eine Bewertung abgegeben haben und auf welchem Stand die aktuelle Bewertungsquote steht. Diese Quote vermittelt den prozentualen Anteil der positiven Bewertungen seitens der Gruppe für das Lesezeichen. In Kapitel 4.2.13 ist der Zusammenhang dieses Wertes und der Art des Lesezeichens bereits näher erläutert worden.

Abbildung 4.5.1.a : CoCuSe - Formular zur Erstellung eines Bewertungskommentars

Abbildung 4.5.1.a : CoCuSe - Formular zur Erstellung eines Bewertungskommentars

Hat der Nutzer selber bisher noch keine Bewertung für das aktuelle Bookmark hinterlassen, so wird zusätzlich eine entsprechende Schaltfläche angezeigt, über welche dieser Schritt eingeleitet werden kann.

Zum Erzeugen eines neuen Bewertungskommentars (engl. Rating) wird der Anwender auf eine Eingabeseite (Abbildung 4.5.1.a) geführt. Dort kann ein Bewertungstext eingegeben und eine Bewertungsnote angewählt werden. Die drei zur Auswahl stehenden Notenwerte werden dazu, wie auch innerhalb der Bewertungstabelle, durch kleine graphische Symbole für eine positive, neutrale oder negative Bewertung repräsentiert. Zusätzlich wird auf der Eingabeseite dieser Notenwert in Textform beschrieben.

Nach Abgabe der Bewertung wird erneut die Bookmark-Seite angezeigt, welche nun die neue Bewertung enthält.

4.6 Ergebnis-Seiten

Die Ergebnis-Seite ist aus Sicht von CoCuSe ein Spezialfall, da es sich hierbei nicht um einen CoCuSe-Seitentyp handelt. Vielmehr handelt es sich um eine CURE-Standardseite, welche jedoch im Zusammenhang mit CoCuSe eine nicht unbedeutende Rolle spielt.

Abbildung 4.6.a : CoCuSe - Ergebnis-Seite mit einem Lesezeichen

Abbildung 4.6.a : CoCuSe - Ergebnis-Seite mit einem Lesezeichen

Bei der Arbeit mit CoCuSe wird die Ergebnis-Seite im Hintergrund mit Lesezeichen aus der Ergebnismenge gefüllt - daher auch der Name. Sobald durch Abgabe eines Bewertungskommentars ein Lesezeichen von der Menge der gesammelten Lesezeichen in die Ergebnismenge überführt wird, erfolgt eine Aktualisierung der Ergebnis-Seite. Da es sich um eine normale CURE-Seite handelt, werden jeweils neue Versionen angelegt und sie kann frei bearbeitet werden.

Die Seite steht unabhängig von CoCuSe zur Verfügung - sogar nach dem Löschen von CoCuSe - und dient der weiteren Verarbeitung der Ergebnisse nach Abschluss der Recherche. Auf der Seite findet der Anwender den Namen der Recherche, die Beschreibung, sowie alle Ergebnislesezeichen in Form von Link, optionaler Beschreibung und Internetadresse (Abbildung 4.6.a).



Start

0 Inhaltsverzeichnis

1 Einführung in die Aufgabenthematik

2 Analyse des Themenbereichs

3 Betrachtung von bestehenden Systemen

4 CoCuSe - Collaborative Cure Search

5 Implementierung in Java

6 Zusammenfassung und Ausblick

Anhang A: Verzeichnis der Abbildungen

Anhang B: Verzeichnis der Tabellen

Anhang C: Verzeichnis der Quellen und Referenzen

Anhang D: Softwaretechnische Anbindung an CURE

Anhang E: Inhalt der Begleit-CD

</Thesis>
Diplomarbeit "Kooperative Web-Recherche in CURE"
(CoCuSe - Collaborative Cure Search)
http://CoCuSe.ALEGROIT.de/
Copyright © 2006 Alexander M. Gross/ALEGRO

Copyright © 1999-2015 CoCuSe.ALEGROIT.de All rights reserved.