<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.

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.

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.

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.

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).

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.

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.

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.

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).

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.

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.

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.

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 .

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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