Verschränkung von Perspektiven durch Aushandlung

Thomas Herrmann*, Gerry Stahl**

*Universität Dortmund, Informatik und Gesellschaft,

** University of Colorado, Boulder, Center of LifeLongLearning and Design


Abstract:

To foster collaborative learning a system should support perspectival viewing and negotiation in a natural way. WebGuide supports teams of students conducting research on the web; it lets them share bookmarks, queries, notes and summaries that arise in the research. The shared information space is viewed through various perspectives so that all students can construct their own personal view of the materials, rearranging them under different categories and generating new summaries or annotations. All information can be modified within a personal perspective.

Students can view the work of other students, copy items to their personal workspace, and propose that items they have created be incorporated in the team's shared perspective. For a proposed item to be accepted in the team perspective, team members must deliberate and agree to accept it. Therefore, a negotiation mechanism is provided.

  1. Einleitung
  2. Zielsetzung

Das WWW ist ein naheliegendes Instrument zur Unterstützung von kooperativer Arbeit. Insbesondere stellt es eine vielfältige und entsprechend unüberschaubare Informationsbasis dar, auf die sich kooperative Arbeit beziehen kann. In Kooperationsbeziehungen hat jeder einzelne Akteur seine eigene Perspektive, unter der er diese Informationsbasis nutzt. Mit Perspektive ist hier gemeint, daß ein eingeschränkter Ausschnitt der Informationsbasis betrachtet wird, der festgehalten, kategorisiert, kommentiert und modifiziert werden kann. Im Rahmen kooperativer Arbeit ist es erforderlich, daß diese Perspektiven miteinander verschränkt werden. Das kann bedeuten, daß man die Perspektiven anderer zur Kenntnis nimmt, daß man einen Teil von anderen Perspektiven in die eigene übernimmt etc. Eine besondere Herausforderung stellt es dar, verschiedene Perspektiven zu einer gemeinsamen Perspektive zusammenzufügen. Im Falle einer wissenschaftlichen Arbeitsgruppe oder auch für ein aus Schülern oder Studenten gebildetes Team können wir uns vorstellen, daß zunächt in Einzelarbeit zu einem Thema Informationen mit Hilfe des WWW gesammelt und bearbeitet werden. Zu einem gegebenen Zeitpunkt wird es darauf ankommen, diese Informationen miteinander zu verbinden, das heißt zu entscheiden, welche Informationen dem weiteren Arbeiten des gesamten Teams als gemeinsame Grundlagen dienen soll. Ein solcher Entscheidungsprozeß bedarf in der Regel mehrerer Verständigungs- und Aushandlungsschritte. Ein Teil dieser Schritte kann durch geeignete Groupware-Konzepte selbst unterstützt werden. Sofern sich die Aushandlung auf Perspektiven bezieht, die mit dem WWW verbunden sind, ist es sinnvoll, die Unterstützung der Aushandlung ebenfalls auf das WWW aufzubauen.

Wir schlagen im folgenden ein Konzept vor, mit dem man auf Basis des WorldWideWeb Informationssammlungen einzelner Mitglieder eines Teams miteinander verschränken kann und sowohl inidividuell als auch kollektiv bearbeitet kann.

  1. Eigene Vorarbeiten

Wir kombinieren zwei Ansätze: Zum einen Collaboration with Perspectives von Stahl (1993, Kapitel 9) und zum anderen Aushandelbarkeit von Herrmann (1994, 1995).

Etwas vereinfacht lassen sich die wesentlichen Eigenschaften des Perspektiven-Ansatzes von Stahl wie folgt beschreiben:

  1. Einzelne Teammitglieder verfügen jeweils über eine eigene Informationsbasis, Perspektive genannt, die aus einzelnen Informationseinheiten besteht, welche mittels einer Hyperstruktur miteinander verknüpft sind. Die Informationseinheiten können also als Knoten aufgefaßt werden, die durch gerichtete Kanten, hier Links genannt, miteinander verbunden werden und ein Netz aufbauen. Die Richtung kann im Sinne einer Vererbung verstanden werden. Perspektiven sind durch Sub-Netze repräsentiert.
  2. Teammitglied A(ndrea) kann den Inhalt eines Knotens X der Perspektive von B(ert) in ihrer eigenen Perspektive mittels eines Hyperlinks zugänglich machen. Wenn B den Inhalt des Knotens ändert, ändert sich auch der für A zugängliche Inhalt. Wenn A den Inhalt des in ihrer Perspektive dargestellten Knotens ändert, wird der Link zu B unterbrochen und ein neuer Knoten mit einem neuen Link zu Andreas Perspektive erzeugt. A kann also den Inhalt von X ändern, löschen, umstellen oder auch in X enthaltenen Links umhängen, ohne daß sich in Bs Perspektive etwas ändert. Ob sich in der Perspektive anderer Teammitglieder etwas ändert, hängt davon ab, ob sie X von A oder von B geerbt haben.
  3. Teammitglied A(ndrea) kann den Inhalt eines Knotens X der Perspektive von B(ert) in ihre eigene Perspektive direkt kopieren. Es besteht kein Link zwischen den Perspektiven, sonern nur ein Link, der den neuen Knoten X' zu As Perpsektive zuordnet.
  4. A kann entscheiden, ob sie mit einem Link zu einem Knoten auch das dazugehörige Sub-Netz übernimmt oder ob sie ein eigenes Sub-Netz aufbauen will.
  5. Knoten und Links können auch gelöscht werden.
  6. Die Möglichkeit der Vererbung zwischen Perpektiven erlaubt es einer Gruppe, die Verschränkung ihres Wissens zu strukturieren. Aus zwei oder mehreren individuellen Perspektiven lassen sich (Sub-)Team-Perspektiven bilden. Es entsteht eine Hierarchie von Perspektiven, die sich in einem Baum repräsentieren lassen. Dieser Baum stellt dann die Beziehungen des Informationsaustauschs zwischen Individuen bzw. zwischen (Sub­)Teams mittels einer Vererbungshierarchie dar. Ein solcher Baum kann dann so ausgewertet werden, daß die untergeordnete Perspektive immer automatisch die Knoten der übergeordneten Perspektive erbt.

Es ist ein wesentlicher Vorteil diese Konzeptes, daß Teammitglieder Inhalte der Teamperspektive ererben können, ohne sie neu generieren zu müssen und daß sie mit diesen Inhalten experimentieren können, ohne die Sicht der anderen Teammitglieder auf die Teamperspektive dadurch zu beeinträchtigen. Dieser Vorteil ist solange wirksam, solange Teammitglieder die Perspektiven der anderen nur zu Anreicherung der eigenen Perspektive nutzen wollen. Sobald es aber für eine Teammitglied von Interesse ist, welche Inhalte in der Perspektive eines anderen Mitglieds enthalten sind, stößt das Konzept an Grenzen, da es nicht möglich ist, die Inhalte anderer zu ändern oder zu fixieren. Für kooperatives Arbeiten ist es jedoch ausschlaggebend, daß sich die zugrundeliegenden Perspektiven zumindest partiell überlappen, um eine erfolgreiche Verständigung und Koordination zu erreichen (s. z.B. Boland et. al. 1992). Die zugrundeliegenden subjektiven Auffassungen werden zu Gunsten einer Intersubjektivität verschränkt (Habermas, 1981, S. 28). Im Kontext der Informatik und Software-Entwicklung wurde an verschiedenen Stellen verdeutlich, daß die beteiligten Entwickler und Nutzer ein System immer unter unterschiedlichen Perspektiven betrachten und beurteilen und daß diese Unterschiede zu berücksichtigen sind (Floyd,1992, S. 91).

Das Konzept systemgestützter Aushandlung sieht vor, daß man Veränderungen von Systemeigenschaften oder von Informationen auch dann vornehmen kann, wenn sie die Interessensphäre anderer beeinflussen. Eine solche Änderung wird zunächst vorgeschlagen. Mit Hilfe des gleichen Systems, mit dem diese Änderung vorbereitet und durchgeführt wird, werden auch die von dieser Änderung Betroffenen informiert und in die Lage versetzt, auf den Vorschlag zu reagieren. Folgende Reaktionsmöglichkeiten sind nach Herrmann (1995) vorgesehen:

  1. Abbruch der systemgestützten Verhandlung mit dem Vorschlag, die Kommunikation auf direkterem Wege zu führen,
  2. Modifikation des Vorschlages,
  3. der Vorschlag wird akzeptiert,
  4. der Vorschlag wird auf Widerruf akzeptiert,
  5. der Vorschlag wird abgelehnt,
  6. Jede der vorangegangenen Reaktionsmöglichkeiten kann zusätzlich kommentiert werden.

Dieses Konzept wurde für Situationen entwickelt, in denen zwei Systembenutzer darüber verhandeln, ob eine Systemanpassung erfolgen darf oder nicht. Dieser Ansatz hat den Zweck, Individualisierbarkeit und Steuerbarkeit (im Sinne von ISO 9241, Teil 10) auch für Groupware umsetzbar zu machen. Die Aushandlung kann in mehreren Zyklen stattfinden, indem der Vorschlagende wiederum auf die Reaktion des Betroffenen reagiert. Es sind Aushandlungsregelungen festzulegen, die bestimmen, wieviele Aushandlungszyklen stattfinden können, wieviel Zeit bis zu einer Reaktion verstreichen kann, was passiert, wenn das Zeitlimit überschritten ist etc. Zweck dieses Aushandlungskonzeptes ist es, möglichst schnell die Routinefälle von Ablehnung, Zustimmung oder einfachen Modifikationen der Vorschläge zu erledigen und gezielt herauszufinden, zu welchen Vorschlägen ein intensiverer Kommunikationsprozeß stattfinden muß. Auf diese Art und Weise erhält man eine gemeinsame Ausgangsbasis, auf der Kooperation aufbauen kann. Der Nachteil besteht darin, daß dieses Konzept nur für zwei Aushandelnde entworfen ist und daß bei der Erweiterung für meherere Teilnehmer auch mehr Zeit verstreichen kann, bis es zu einer Einigung auf eine gemeinsame Ausgangsbasis kommt. Das ursprüngliche Aushandlungskonzept (Herrmann, 1995) sieht vor, daß solange nicht mit der geänderten Version gearbeitet werden kann, bis der Aushandlungsprozeß abgeschlossen ist. Das mag für Veränderungen der Systemfunktionalität sinnvoll sein, nicht aber aber für Veränderungen von Informationsbasen. Für diese bietet das Konzept der Verschränkung verschiedener, individueller und gemeinsamer Perspektiven den Vorteil, daß man bis zur Erzielung des Aushandlungergebnisses mit der individuellen Perspektive weiterarbeiten kann.

  1. Vergleich mit anderen Ansätzen

Ein wesentlicher Mechanismus zur Unterstützung kooperativer Arbeit mit gemeinsamen Material sind Hypertext- und Hypermediastrukuren, wie sie letztlich auch zumindest partiell mit dem WWW realisiert sind, wobei nachwievor Erweiterungsanforderungen bestehen (Bieber et.al.,1997). Wie oben schon angedeutet, basiert das Konzept verschränkter Perspektiven auf Knoten und Links. Der Ansatz von Stahl (1993) geht jedoch hinsichtlich der Verwaltung und Manipulierbarkeit von Links über das hinaus, was in der Regel mit Hypertextstrukturen angeboten wird. Besonders zu erwähnen ist die Möglichkeit, Knoten zu editieren, die man mittels eines Links innerhalb der eigenen Perspektive darstellt. Da es aus Konsistenzgründen nicht möglich ist, auch geerbte Knoten zu ändern, muß eine Kopie des Knotens erstellt werden, der Link wird abgehängt und die Kopie kann dann bearbeitet werde. Solche Konzepte sind zum Beispiel bei Betriebssystemen bereits realisert (s. Fitzgerald&Rastrich, 1986) ohne jedoch in eine umfassendere Umgebung zur Unterstützung kooperativer Arbeit eingebettet zu sein.

Ein anderes Konzept, das unmittelbar Assoziationen zu der beschriebenen Differenzierung verschiedener Perspektiven anregt, ist die Ermöglichung verschiedener Views auf Datenbanken. In Abhängigkeit von der Struktur einer Datenbank kann bekanntlich festgelegt werden, daß verschiedene Benutzer nur bestimmte Ausschnitte zur Kenntnis nehmen können oder müssen. Auf diese Weise können verschiedene Perspektiven definiert werden. Der Unterschied zu dem hier verfolgten Ansatz besteht darin, daß Benutzer ihre eigene Perspektive selbst definieren können und zwar unter Bezugnahme auf andere individuelle oder gemeinsame Perspektiven. Es ist nicht auszuschließen, daß man mit dem View-Konzept bei Datenbanken ähnliche Mechanismen konfigurieren kann, allerdings ist dies nicht das hauptsächliche Anliegen dieses Konzeptes. Vielmehr wird es dabei immer notwendig sein, auf andere Funktionen von Datenbanken, wie etwa Anfragemechanismen zuzugreifen. Insofern kann man sagen, daß Datenbanken den beschriebenen Perspektivenansatz nicht per se beinhalten, sehr wohl aber unter Ausnutzung ihrer gesamten Funktionalität genutzt werden können, um ihn in Verbindung mit dem WWW zu realisieren.

Unter Organizational Memories verstehen wir grob gesehen einen Ansatz, bei dem eine strukturierte elektronische Ablage für alle Arten von Dokumenten geschaffen wird, die im Rahmen computergestützter Kooperation und Kommunikation unter den Teilnehmern ausgetauscht werden (s. zum Beispiel Ackermann, 1994; Lindstaedt & Schneider, 1997). Es stellt dabei eine wesentliche Anforderung dar, diese elektronische Ablage parallel zu der Kooperation aufzubauen, ohne daß die Kooperierenden hierdurch gestört werden oder zusätzliche Arbeit notwendig wird und daß dennoch eine Struktur entsteht, die es ermöglicht, später möglichst direkt die relevanten Inhalte zu finden. In diesem Sinne ist das Konzept verschränkter Perspektiven nicht zum Aufbau von Organizational Memories gedacht, da es ja zusätzlicher Arbeits- und Entscheidungsschritte bedarf, diese Perspektiven aufzubauen, wodurch wiederum die eigentliche Kooperation gestört werden könnte. Vielmehr ist der Aufbau solcher Perspektiven sinnvoll, um ein vorhandenes Organizational Memory mit Hinblick auf eine neue kooperative Aufgabe auszuwerten, indem man Teile des Memories in die Perspektiven aufnimmt, die zur Bearbeitung der neuen Aufgabe aufgebaut und ausgehandelt werden. Perspektivität erlaubt es, Organizational Memories in verschiedener Weise zu organisieren und zu kategorisieren. Auf diese Weise können schnell neue Strukturen von Informationen geschaffen werden, die an die Erfordernisse der jeweiligen kooperativen Aktivitäten angepaßt sein können.

Ein weiteres Konzept, das einen Raum vorhandener Informationen in Abhängigkeit von den Präferenzen der Individuen oder Teams ordnet, ist Group Lens (Resnick et. al., 1994). Hier wird mittels statistischer Auswertungen automatisch festgestellt, welche Mitglieder einer Gruppe sich für ähnliche Themen interessieren. Solche Korrelationen werden genutzt, um Informationen, die von einem Gruppenmitglied als interessant angesehen werden, an diejenigen anderen Gruppenmitglieder weiterzuleiten, mit denen eine Korrelation hinsichtlich der Themen festgestellt wurde. Auf diese Weise wird also automatisch eine gemeinsame Perspektive auf ausgewählte Informationsausschnitte hergestellt. Dieser Ansatz ist insbesondere für neu auftretende Informationen hilfreich. Der Automatismus ist in dem Perspektivenkonzept nach Stahl (1993) insofern enthalten, als man das Sub-Netz erben kann, das sich an einen Knoten anschließen. Auf diese Weise kann man auf alle Informationen Zugriff erhalten, die der Inhaber eines Knotens an selbigen mittels Links anhängt. Ansonsten unterstützt Group Lens nicht die aktive Selektion bestimmter Information, die auf einer bewußten Entscheidung der Akteure beruht.

Die bisher beschriebenen Ansätze enthalten keine systembasierten Aushandlungsmechanismen. Wulf (1997) hat den Ansatz von Herrmann zum Zwecke des Konfliktmanagements bei Groupware fortentwickelt. Dabei bietet er eine Differenzierung an, die im wesentlichen folgendes unterscheidet: Der Benutzer kann unterbinden, daß ihn andere durch ihre Art der Systemnutzung in unerwünschter Weise beeinflussen; der Benutzer kann den Einfluß anderer nicht unterbinden, aber nachvollziehen; der Einfluß anderer ist aushandelbar. Wir meinen dagegen, daß es den Nutzern immer möglich sein sollte, bei Bedarf wechselseitig aufeinander zu reagieren, und sei es nur mittels Kommentaren. Die wechselseitigen Reaktionen sollte idealer Weise immer mit Hilfe desselben Systems erfolgen können, auf das sich die Reaktionen inhaltlich beziehen.

Die deutlichsten Parallelen mit der systembasierten Aushandlung finden sich bei Decision Support und Meeting Support Systemen (eine Übersicht gibt Geibel, 1993). Zum einen kann man dort auf Vorschläge, die von anderen unterbreitet wurden, modifizierend reagieren, indem man sie direkt durch eigene Vorschläge ergänzt. Zudem ist es möglich, Kommentare an die Vorschläge anzuhängen. Etwas elaboriertere Systeme, die man als Nachfolger des ARGNOTER-Konzepts (Stefik et. al., 1988, S. 345ff.) ansehen kann, erlauben es, Kommentare zu klassifizieren, je nach dem, ob sie als Pro- oder Gegenargument zu einem Vorschlag zu verstehen sind. Diese Argumente stellen eine Parallele zu Ablehnungs- oder Zustimmungsvoten dar, werden aber nicht immer als solche automatisch ausgewertet. Zur Berechnung von Zustimmung oder Ablehnung ermöglichen es einige Systeme, daß die Teilnehmer Bewertungen für die Vorschläge abgeben, indem sie z.B. eine vorgegebene Anzahl von Punkten über die Vorschläge verteilen. Die Vorschläge, die die meisten Punkte erhalten, gelten dann als diejenigen, auf die sich eine Gruppe geeinigt hat. Um solche Abstimmungen gerecht zu organisieren, sind verschiedene Randbedingungen zu beachten; einen guten Überblick und Lösungsdiskussionen hierzu gibt Ephrati et. al. (1992). Eine Anwendung bei Terminkalendern beschreiben Sen et. al. (1997). Mit solchen Abstimmungsverfahren wird häufig eine große Anzahl von Perspektiven abgearbeitet, die dann meistens nicht in angemessener Weise inhaltlich gewürdigt werden, insbesondere wenn keine Kommentierung oder Diskussion zu den einzelnen Punkten erfolgt. Das hier vorzustellende Konzept von Perspektivenverschränkung durch Aushandlung versucht beides miteinander zu verbinden.

Ansätze zur Aushandlung finden sich zum Teil auch in Konzepten, die auf Agenten aufbauen. Martial (1990) schlägt ein solches Konzept zur Lösung von Konflikten bei der Ressourcenzuweisung vor. Neben den oben genannten Reaktionsmöglichkeiten im Rahmen von Aushandlungsprozessen differenziert er zusätzlich zwischen Modifizierung eines Vorschlages und Unterbreitung eines Gegenvorschlages, während wir versuchen, ohne diese Unterscheidung auszukommen. Bayer (1995) entwickelt ein Konzept, bei dem ein Teil der Aushandlungsarbeit von Agenten übernommen wird, um die Benutzer in Standardsituationen zu entlasten.

Es zeigt sich, daß die beschriebenen Konzepte jeweils nur Teilaspekte des hier darzustellenden Lösungskonzeptes beinhalten. Andererseits beinhalten sie auch wertvolle Anregungen, die bei der Ausgestaltung von Möglichkeiten für die Perspektivenverschränkung durch Aushandlung zu berücksichtigen sind.

  1. Beispiele für die Notwendigkeit verschränkter Perspektiven

Um die Entwicklung eines konkreten Lösungskonzeptes für die Verschränkung von Perspektiven vorzubereiten, analysieren wir einige Beispielfälle, aus denen sich entsprechende Anforderungen ableiten lassen. Wir gehen davon aus, daß das Lösungskonzept für jeden Anwendungsbereich unterschiedlich auszugestalten ist. Wir stellen hier dar, wie man ohne Unterstützung durch ein Computersystem verfahren muß, wenn verschiedene Sichtweisen aufeinander abgestimmt werden müssen. Hierdurch wollen wir die Probleme verdeutlichen, die es zu beheben gilt.

  1. Verwaltung von Stichworten zur Klassifizierung von Einträgen in einer Literaturdatenbank

Wissenschaftliche Teams nutzen häufig eine gemeinsame Literaturdatenbank für ihre Arbeit. Ein Teil der Einträge in einer solchen Datenbank ist oft nur für einzelne Individuen interessant, ein anderer Teil hingegen ist für alle oder für Untergruppen relevant. Während die Basisangaben zu einer Literaturstelle meistens einheitlich sein sollten, kann es bei der Bewertung oder Kommentierung einer solchen Stelle zu unterschiedlichen Auffassungen kommen. Dieses Problem kann man lösen, indem für jeden Nutzer eine eigene Sicht definiert wird, die ihm solche Bewertungen und Kommentare zeigt, die er als seinen Vorstellungen entsprechend ausgewählt hat. Diese Individualisierung macht allerdings bei solchen Informationen, die die Zusammenarbeit unterstützen sollen, wenig Sinn. Noch deutlicher als bei den Kommentaren wird dies am Beispiel von Schlagwörtern, mit Hilfe derer man Literatureinträge kategorisiert.

Solche Schlagwörter haben nicht nur den Zweck, das eigene Gedächtnis zu unterstützen, sondern auch anderen das Auffinden von Literatur zu erleichtern. Deshalb sollte der Katalog von Schlagwörtern, die in einem Team zum Einsatz kommen, immer wieder aktualisiert und abgestimmt werden. Geht man von einer einfachen Liste aus, so können Schlagwörter etwa zusammengefaßt oder differenziert werden, sie können gelöscht oder durch neue ersetzt werden oder es können neue, zusätzliche Schlagwörter eingeführt werden. Wer immer eine solche Änderung vornimmt, sollte entscheiden, ob diese nur für ihn persönlich relevant ist, oder ob er der gesamten Gruppe vorschlägt, mit dem geänderten Schlagwort zu arbeiten. In letzeren Fall kann dann zum Beispiel der Chef entscheiden, ob der Vorschlag angenommen wird, oder man kann per Umlaufverfahren abstimmen. Beide Vorgehensweisen haben den Nachteil, daß es nicht zu einer inhaltlichen Diskussion über den Änderungsvorschlag kommt, das Umlaufverfahren nimmt zudem auch viel Zeit in Anspruch. Die inhaltliche Diskussion ist in der Regel wichtig, um das gemeinsame Verständnis eines Schlagwortes zu erhöhen. Ein Ausweg wäre es, die Annahme eines Änderungsvorschlages im Rahmen einer Gruppendiskussion zu entscheiden. Dieses Verfahren hat den Nachteil, daß viel unnötige Diskussionszeit auf banale Entscheidungen verwendet wird.

Es geht darum, ein systemgestützes Verfahren zu entwicklen, mit dem man schnell Kommentare austauschen kann, zu einer Abstimmung kommt oder feststellen kann, welche Änderungen einer intensiveren Diskussion bedürfen. An der Universität Dortmund wird zur Zeit ein WWW-basierter Prototyp für ein solches System entwickelt.

  1. Fortentwicklung eines Glossars

Für die Arbeit in Teams kann es häufig von Nutzen sein, eine Liste der wesentlichen Grundbegriffe samt Definitionen aufzustellen, hierarchisch zu strukturieren und kontinuierlich zu pflegen. Änderungen von Text oder bezüglich der Einordnung in der Hierarchie bedürfen bei einem Glossar, das einer Gruppe als Kommunikationsbasis dient, der Zustimmung aller, ebenso die Eintragung neuer Begriffe. Es sollten Verfahren bereit stehen, mit denen einfache Änderungen, wie etwa das Beheben von Tippfehlern, möglichst unbürokratisch erledigt werden können. Das oben genannte Umlaufverfahren ist hierfür nicht geeignet, sonderen eher der Weg über eine zentrale Entscheidungsinstanz, die feststellt, ob eine Änderung einer intensiveren inhaltlichen Diskussion bedarf. Daneben sollte es Mitgliedern einer Gruppe, wenn es sich etwa um ein interdisziplinäres Wissenschaftlerteam handelt, möglich sein, ein individuelles Glossar aufzustellen, in welchem festgehalten wird, zu welchen Begriffen einzelne Gruppenmitglieder eine abweichende Auffassung im Unterschied zu dem restlichen Team haben. Ein System verschränkter Perspektiven mittels Aushandlung sollte in der Lage sein, die hier skizzierten Vorgänge zu unterstützen und zu ergänzen.

  1. Kooperatives Lernen in Schülergruppen mit asynchronen Aktivitätsphasen

Wir gehen hier von einem Fall aus, der den Hintergrund einer aktuellen Systementwicklung abgibt, die am Center of LifeLongLearning and Design der University of Colorado, Boulder unter dem Titel WebGuide verfolgt wird. Ein Lehrer gibt Schülern die Aufgabe, zum Thema „Historische Indianerkulturen" individuell unter Nutzung des WWW zu recherchieren und die Ergebnisse ihrer Recherche zusammenzufassen. Er läßt vier Untergruppen zu den Themen Inkas, Mayas, Azteken und Anasazi bilden. Die Schüler können dann Bookmarks sammeln und diese kommentieren oder kurze Texte aus den Quellen, die sie finden, zusammenstellen. Um das Ergebnis ihrer Recherche überschaubar zu halten, werden sie dazu angeregt, Kategorien zu bilden, mit denen sie ihre Einträge zusammenfassen und ordnen. Danach sollen sie ihre Ergebnisse in den einzelnen Untergruppen zusammenführen. Dies stellt in der Regel eine Überforderung dar, da einzelne, von den Schülern selbst gewählte Strukuren oftmals kaum kompatibel sind. Schüler sind unter Umständen gezwungen, einen Teil ihrer Arbeit wegzuwerfen, was demotivierend ist. Es wird unnötige Doppelarbeit nötig. Es ist für Schüler schwierig, ihre Ergebnisse zusammenzufassen, wenn sie nicht angeleitet werden, die dazu notwendige Diskussion zu strukturieren.

Es ist ein System anzubieten, das das Zusammenführen der Arbeitsergebnisse schon sehr früh und kontinuierlich unterstützt und die dazu notwendigen Abstimmungprozesse strukturiert und erleichtert, so daß die Schüler Möglichkeiten aufgezeigt bekommen, wie man einen Konsensbildungsprozeß durchführen kann. Wir wählen dieses Beispiel, um unser Konzept der Verschränkung von Perspektiven durch Aushandlung zu erläutern. Zum einen weist das Beispiel auf eine hohe Komplexität hin, anhand derer sich die Lösungsansätze umfassend darstellen lassen. Zum anderen handelt es sich um ein Beispiel für Computer Supported Cooperative Learning, einer aktuellen Forschungsrichtung (s. Koshmann, 1996), die für innovative Nutzungen des WWW von besonderer Bedeutung ist.

  1. Das Lösungskonzept
  2. Voraussetzungen

Schüler sollen einzelne Teile der Arbeit anderer in ihre Perspektive übernehmen können und sie sollen frühzeitig Vorschläge unterbreiten können, welche Teile ihrer eigenen Perspektive oder der Perspektive anderer in die Team-Perspektive eingehen sollen, die letztlich die Zusammenfassung der Arbeit repräsentiert. Diese Anforderung setzt es voraus, das Informationen in kleinen Portionen dargestellt und gesammelt werden können. Letztlich kann man nur mit Bezug auf kleine, überschaubare Informationseinheiten aushandeln, welche übernommen, geändert oder gelöscht werden sollen. Die Abbildung 1 stellt eine geschachtelte Datenstruktur der Informationseinheiten dar, die für WebGuide relevant sind.

Abb.1   Datenstruktur einer Basis Webseite in WebGuide

Eine entscheidende Voraussetzung von WebGuide ist es, daß Schülern Webseiten im Sinne von Notebooks zur Verfügung stehen, mit denen sie das Ergebnis ihrer Recherche festhalten können. Neben den üblichen Browsing-Funktionen enthält eine solche Webseite selbst erzeugte Informationseinheiten. Sie bestehen im wesentlichen aus Bookmarks, Kategorien oder Suchhinweisen. Einem Bookmark kann ein selbst gewählter Titel zugeordnet werden. Bei Bedarf (das Sechseck drückt Optionalität aus) kann ein NOTIZ-Symbol hinzugefügt werden, das einen Link zu einer anderen Webseite repräsentiert, auf der der Schüler zum Beispiel ein Exzerpt oder ein Abstract oder Ergänzungen aus anderen Quellen, wie etwa Büchern oder Gesprächen ablegen kann. Neben oder an Stelle von Bookmarks kann es auch Hinweise geben, wie man mit Hilfe einer Suchmaschine geeignete Inhalte finden kann. Es können Kategorien eingeführt werden, um Bookmarks und/oder Suchhinweise zu klassifizieren. Es kann auch Kategorien geben, die zunächst nur zur Vorbereitung einer Inhaltssammlung eingeführt wurden, zu denen es also keine Bookmarks oder Suchhinweise geben muß. Kategorien können hierarchisch gegliedert sein, was durch die rekursive Einbettung der Informationseinheit (im folgenden kurz Item genannt) ausgedrückt wird.

Jeder der Informationseinheiten kann bei Bedarf ein Kommentar zugeordnet werden. Es muß zugeordnet werden, wer das Item erzeugt hat, es geändert hat und zu welcher Perpsektive es gehört. Zudem ist jedem Item eine Menge von Symbolen für Editierungsfunktionen zugeordnet, von denen aber je nach Eigenart der Informationseinheit nur eine Teilmenge aktiviert werden kann. Eine solche Möglichkeit der Untergliederung in Informationseinheiten ist Voraussetzung für die Möglichkeit für Perspektivenverschränkung durch Aushandlung.

  1. Das Lösungskonzept im Überblick

Abb. 2: Grundmodell des WebGuide Konzeptes

Wir stellen uns vor, daß zunächst die zu bearbeitende Aufgabe vom Lehrer (T, siehe Abbildung 2) vorbereitet wird. Dies kann durch die Festlegung der obersten Kategorien geschehen, also etwa entsprechend der vier Indianerstämme. Analog zu ihnen können sich vier Untergruppen in der Klasse bilden. Zudem können auch Unterkategorien und anleitende Beispiele für Bookmarks oder Suchhinweise gegeben werden. Diese Vorgabe wird in der sogenannten Class-Perspektive abgelegt, die entsprechend der oben beschriebenen Web-Seite strukturiert ist. Wie in Abbildung 2 ersichtlich, können die Schüler (S) danach mit der Ausführung der Aufgabe beginnen. Sie nutzen dabei die Class-Perspektive, bauen in individueller Arbeit individuelle Perspektiven auf, wobei sie auch auf die Perspektiven anderer Schüler zugreifen können sollen, sobald sie selbst einen Beitrag geleistet haben. Die kooperative Arbeit besteht im wesentlichen darin, in gemeinsamer Diskussion Informationen zusammenzutragen, Vorschläge für die Team-Perspektive zu unterbreiten, diese Vorschläge zu verhandeln, und die problematischen Fälle wiederum in gemeinsamer Diskussion zu klären. Während der gesamten Aufgabenbearbeitung können der Lehrer, aber auch die Schüler, das Geschehen beobachten und Hinweise geben; unter Umständen ist es sinnvoll, solche Hinweise auch im WWW abzulegen; diese Möglichkeit wird hier nicht näher vertieft. Auf Basis der in der Team-Perpektive zusammengefaßten Ergebnisse kann dann eine weitere Aufgabe vorbereitet werden, wobei die Schüler u.U. mitwirken können.

.

  1. Möglichkeiten der individuellen Arbeit

Abbildung 3 zeigt die Aufgabenbearbeitung im Detail. Die Schüler recherchieren in den ihnen zugänglichen Informationsquellen; neben dem WWW können dies natürlich auch Bücher sein oder Gespräche oder andere mögliche Quellen, die wir nicht alle antizipieren können, was durch die drei Fragezeichen ausgedrückt ist. Der Schüler kann ebenfalls die Inhalte der Class- und Team-Perspektive sowie der anderen individuellen Perspektiven zur Kenntnis nehmen, die zu diesem Zweck alle in einer Comparison-Perspektive nebeneinander gestellt und überschaubar gemacht werden. Aus der Recherche übernehmen die Schüler diejenigen Daten, die ihnen interessant erscheinen. Zu diesen übernommenen Daten können dann im dritten Schritt eigene Daten, wie etwa Kommentare, eigene Bookmark-Titel etc. hinzugefügt werden. Die drei Schritte können sich beliebig abwechseln und wiederholt werden.

Um die genannten Schritte individueller Arbeit durchführen zu können, ist es sinnvoll, daß man sich zu jedem Item die Menge derjenigen Funktionssymbole anzeigen lassen kann, die in der gegebenen Perspektive auf das Item anwendbar sind. Abb. 4 zeigt die bisher geplante Maximal-Menge von Funktionen.

Der Hide- und Show-Mechanismus ist für jedes Item in jeder Perspektive möglich und bedeutet, daß man sich zum Beispiel nur die Kategorien anzeigen lassen kann, daß man die Kommentare ausblenden kann oder daß man sich alle Details ansieht. Hierdurch soll das Browsen und die Orientierung erleichtert werden. In der Comparison-Perspektive ist kein Editieren möglich; hier hat man nur die Möglichkeit, Items in die eigene Perspektive zu kopieren. Dabei muß es auch möglich sein, Gruppen von Items zu kopieren; man sollte als z.B. nur den Namen einer Kategorie oder auch sämtliche unter einer Kategorie zusammengefaßten Einträge kopieren können.

Abbildung 3: Verfeinerte Darstellung der Aufgabenausführung und der Perspektiven

In der individuellen Perspektive sind verschiedene Editierungsfunktionen möglich, wie Einfügen eines Items hinter die aktuelle Position (1), Verändern von Text (2), Verschieben von Items (3) und Löschen von Items (4). Jede dieser Funktionen bewirkt den Aufruf einer Formularseite, in die weitere Spezifikationen eingetragen werden können:

Abbildung 4: Mögliche Funktionen

  1. Man kann den Typ des neuen Items festlegen und die Zwischenablage einlesen oder neuen Text eingeben,
  2. Man erhält ein Fenster, in dem man den alten Text ändern kann, außerdem wird festgelgt, ob der alte Text durchstrichen angezeigt wird oder gar nicht mehr.
  3. Man gibt die Position an, zu der das Item hingeschoben wird und legt fest, ob es an der alten Position durchstrichen angezeigt wird.
  4. Man legt fest, ob das gelöschte Item durchstrichen angezeigt werden soll oder nicht. Wenn man die Delete-Funktion auf ein durchstrichenes Item anwendet, hat man die Wahl, es gänzlich verschwinden zu lassen oder es wieder in die Perspektive aufzunehmen.

Abbildung 5 zeigt einen Ausschnitt aus Kay's Perspektive. Daran wird deutlich, daß sie immer sieht, was sie aus anderen Perspektiven in ihre Perspektive übernommen hat und was sie selbst hinzugefügt hat.

  1. Vorschlagen und Aushandeln

Abbildung 5: Informationseinheiten in Kay's Perspektive

Jeder Schüler kann aus seiner individuellen Perspektive heraus mittels der Funktion Propose Vorschläge für die Team-Perspektive unterbreiten. Auf diese Weise kann eine Informationseinheit in die Team-Perspektive neu eingefügt werden. Er kann auch Items aus der Perspektive anderer vorschlagen, indem er sie zuerst in seine Perspektive übernimmt. Falls ein bereits bestehender Eintrag der Team-Perspektive geändert werden soll, muß er in eine individuelle Perspektive übernommen werden, dort wird er geändert und dann vorgeschlagen; die Änderung muß nachvollziehbar bleiben, indem mit durchstrichenem Text gearbeitet wird. Dieser etwas umständliche Weg über die individuelle Perspektive ist sehr sinnvoll, weil auf diese Weise die Änderung vom Vorschlagenden selbst und auch von anderen Schülern genutzt werden kann, bevor das Ergebnis der Aushandlung festliegt. Es muß möglich sein, mehrere zusammenhängende Items in nur einem Schritt für die Übernahme vorzuschlagen; z.B.löscht Kay die Kategorie Calendar in der Team-Perspektive und fügt Sun-Calendar neu ein - beide Änderungen sollten zu einem Vorschlag zusammengefaßt und in einem Aushandlungsvorgang behandelt werden. Ferner ist es wichtig, daß man Änderungsvorschläge auch dann zusammenfassen kann, wenn die betroffenen Items nicht direkt nebeneineander stehen. Dies bedarf dann mehrerer Schritte. Wenn ein Schüler z.B. etwas an einer Stelle löscht, um an einer anderen Stelle ein besseres, umfassenderes Bookmark einzufügen, dann sollte auch in diesem Fall beides im Zusammenhang vorgeschlagen und auch ausgehandelt werden. Die Schüler sollten allerdings dazu angehalten werden, nicht zu viele Schritte zusammenzufassen.

Wenn die Proposed-Funktion aktiviert wird, wird eine WWW-Seite mit Formularfenster geöffnet. Hier kann man festlegen, ob der Vorschlag mit dem vorangegangenen oder mit einem nachfolgenden zusammengefaßt werden soll. Zudem sieht man die Liste aller Schüler, die bei dem unterbreiteten Vorschlag an der Aushandlung beteiligt sein werden. Wer das ist, ist im Rahmen der Aushandlungsphilosophie festzulegen, die möglichst mittels Parameter steuerbar sein sollte, um sie von Fall zu Fall variieren zu können. Beispielsweise kann man dann festlegen, daß Neueinträge immer von allen Teammitgliedern zu verhandeln sind, während bei Änderungen nur diejenigen beteiligt werden, die das zu ändernde Item eingebracht haben bzw. es irgendwann modifiziert haben. Man kann so auch festlegen, daß etwa das Einfügen von Kommentaren gar nicht verhandelt wird.

Der Vorschlag erscheint dann sowohl in der Team-Perspektive als auch in der individuellen Perspektive aller Verhandlungsteilnehmer mit dem Label „[Team Perspective, proposed by NAME]". Auf das Proposal können zunächst keine Editierungsfunktionen angewendet werden, sondern nur das Aushandeln mittels der Negotiate-Funktion. Diese öffnet eine Web-Seite mit einem ersten Fenster, auf dem wahlweise nur der Vorschlag mit oder ohne den Kontext der Team-Perspektive gezeigt wird. In einem zweiten Fenster kann man die bereits erfolgten Aushandlungsentscheidungen und Kommentare anderer Teammitglieder sehen.( s. Tabelle 1)

Zu dem Vorschlag sind nun Aushandlungsreaktionen möglich, wie sie in Abbildung 3 gezeigt werden. Der Aushandelnde kann mit ABSTAIN kundtun, daß er an der Aushandlung nicht teilnehmen möchte. Er kann mit LET US TALK mitteilen, daß er über den Vorschlag in der Gruppe sprechen möchte. Die Folge ist, daß das Label zu „[proposed by NAME, let us talk]" geändert wird. Außerdem kann eine automatisch geführte Agenda von Diskussionspunkten der Gruppenbesprechung automatisch erweitert werden.

Zentral ist es, daß man wählen kann, ob man einen Vorschlag ablehnt oder akzeptiert. Hier ist zu beachten, daß ein unterbreiteter Vorschlag von anderen Gruppenmitgliedern modifiziert werden kann, so daß es für denselben Vorschlag mehrere Alternativen geben kann. In dem obigen, auf Abbildung 5 bezogenen Beispiel, könnte Bea etwa den Vorschlag von Kay modifizieren und als Alternative „Sun-Moon Calendar" vorschlagen Falls ein ACCEPT gewählt wird, werden alle anderen eventuell vorhandenen Alternativen mit einem REJECT versehen und das Aushandlungsfenster geschlossen. Falls REJECT gewählt wurde, wird automatisch die nächste Alternative angezeigt (alle Alternativen sind nacheinander aufgelistet). Beim Angebot mehrerer Alternativen, kann man entweder genau eine akzeptieren oder alle zurückweisen.

Nach dem Schließen des Aushandlungsfensters erhält man die Möglichkeit, die eigene Reaktion zu kommentieren. Es wird für alle anderen nachvollziehbar dargestellt hat, wie man reagiert hat und wie man die Reaktion kommentiert hat. Für den hier dargestellten Fall, daß mehrere Teilnehmer miteinander verhandeln, haben wir entschieden, daß es nicht sinnvoll ist, Reaktionen auf Reaktionen zuzulassen, da sonst der Aushandlungsprozess sehr schnell unüberschaubar wird. Allerdings gibt es eine Ausnahme: Alle Reaktionen, auch die von anderen, können kommentiert werden. Auch wenn man sein Votum schon abgegeben hat, kann man immer wieder das Aushandlungsfenster öffnen, um Reaktionen anderer zu kommentieren oder das eigene Votum zu ändern. Diese Funktion wird pro dargestellter Reaktion im Kommentarfenster angeboten - siehe als Beispiel Tabelle 1. Konsequenterweise kann man auch Kommentare kommentieren.

Name Reaktion Statistik
Que: acceptance of Kay's proposal 1 of 3
  Comment: I think this makes sense  
Bea rejection of Kay's proposal and modification of Kay's proposal 1 of 1
Phil rejection of Bea's modification 1 of 1
Jay rejection of Bea's modification 1 of 2
  Comment: I prefer the original  
Bea comment on Jay's comment 1 of 1
  Comment: why do you prefer it?  

Tabelle 1: Beispiel für die Darstellung von Reaktionen und Kommentaren

Die Möglichkeit der Modifikation wird indirekt angeboten. Sobald alle verfügbaren Alternativen eines Aushandlungsvorschlages abgelehnt wurden, kann der Ablehnende in seiner individuellen Perpsektive den Vorschlag editieren und ihn in geänderter Form vorschlagen. Diese Alternative wird dann automatisch dem Aushandlungsvorgang hinzugefügt. Ebenso wird das Label geändert „[proposed by NAME1, altered by NAME2 ]. Die Aushandelnden sehen dann die Alternativvorschläge und können entscheiden, ob sie noch einmal reagieren wollen, um ihr Votum zu ändern. Vor diesem Hintergrund ist es auch sinnvoll, einen Ereignisdienst einzuführen, der auf solche Änderungen hinweist. Die Design-Entscheidung, die Modifikation nur auf diese Weise zu ermöglichen, führt zu einer Vereinfachung, da der Schüler immer nur unter den gleichen Bedingungen editiert, die er im Kontext seiner individuellen Perspektive kennt. Es ist nur möglich, den Ursprungsvorschlag zu ändern, nicht aber proposed Items, die bereits das Label altered haben, da sonst die Übersichtlichkeit verloren ginge. Ein einmal gemachter Vorschlag kann zwar vom Urheber per Votum abgelehnt werden, wenn ihm eine Alternative besser gefällt, der Vorschlag kann aber nicht ganz zurückgenommen werden, da er ggf. der Präferenz anderer Teilenehmer entspricht.

Das Aushandlungsgeschehen kann pro Vorschlag nur über einen im Rahmen der Aushandlungsphilosphie festgelegten Zeitraum erfolgen. Nach Ablauf der Zeit wird festgestellt, ob der Vorschlag bzw. eine der Alternativen akzeptiert oder abgelehnt ist. Für diese automatische Feststellung wird vorab spezifiziert, welcher Mehrheitsmodus (2 Drittel, absolute oder einfache Mehrheit etc.) anzuwenden ist und wie Ablehnung gegen Akzeptanz aufzurechnen ist. Falls kein eindeutiges Votum zu Stande kommt, wird der Vorschlag mit proposed for talk gekennzeichnet und auf die Besprechungsagenda genommen. Die Schüler müssen dann versuchen, sich in direktem Gespräch über den Fall zu einigen. Während solcher Besprechungen sollte es möglich sein, Änderungen direkt in der Team-Perspektive vorzunehmen, indem man sich eines Super-Passwortes bedient, zu dem alle einen Teil-String beitragen.

  1. Zusammenfassung

Es wurde deutlich, daß das hier vorgeschlagene Konzept nur dann umsetzbar ist, wenn es gelingt, den zu bearbeitenden Informationsraum kleingliedrig zu zerlegen. Der Ansatz läßt sich zum Beispiel kaum auf ein Shared Editing längerer Text anwenden. Ferner ergeben sich einige software-ergonomische Probleme, da man mit WWW-Seiten selbst unter Nutzung von JAVA das Prinzip der Direkten Manipulation nicht immer konsequent wird verwirklichen können, da es immer wieder darum geht, daß nach jeder Änderung neue Seiteninhalte erzeugt werden, die auch anderen zugänglich sind.

Es gibt einen Protoypen, der einige Perspektiven des Systems zeigt, ohne daß die dazugehörige Funktionalität verfügbar ist (siehe http://www.cs.colorado.edu/ ~gerry/WebGuide/webguide.htm). Man erkennt aber das Konzept der WWW-Seiten Gestaltung und die zentralen Entscheidungen, die hinsichtlich der Informationsdarstellung getroffen wurden. Das System wird weiter vervollständigt und wird in 1998 in einer konkreten Schulumgebung evaluiert werden. Dabei wird es darum gehen, zum einen das Nutzungsverhalten zu evaluieren. Zum Beispiel: Wie wird das Zusammenfassen von Vorschlägen zu einem Aushandlungsvorgng genutzt; wie stark wird das Kommentieren genutzt, wie gehen Schüler mit der Möglichkeit um, Vorschläge zu modifizieren? Zum anderen sollen Hinweise für die Aushandlungsphilosophie gewonnen werden: Wie verfährt man mit Vorschlägen, die nur von einem oder zweien zur Besprechung vorgeschlagen werden? Welche Zeitlimits, Abstimmungsmodi, Teilnehmer der Aushandlung etc. sind sinnvoll?

Es wurde deutlich, daß das ursprüngliche Aushandlungskonzept stark vereinfacht werden mußte, um für Schüler handhabbar zu sein. Betrachtet man die hier vorliegende textliche Darstellung, so wirkt das Konzept immer noch recht komplex. Die Autoren gehen davon aus, daß sich die Möglihkeiten einfacher darstellen, wenn man sie am System direkt erkunden kann. In der Evaluationsphase können sich sicherlich Hinweise für weitere Vereinfachungsmöglich-keiten ergeben, und es wird sich zeigen, was unter Umständen in einer Systemerklärung bereitgestellt werden muß. Wenn es gelingt, das Konzept für Schüler ab 12 Jahren ausreichend handhabbar und überschaubar zu gestalten, dann lassen sich an diesem Beispiel wichtige Hinweise gewinnen, wie man das Prinzip verschränkter Perspektiven durch Aushandlung auch für andere Anwendungsfälle benutzbar gestalten kann.

  1. Literatur

Ackerman, M. S. (1994): Augmenting the Organizational Memory: A Field Studyof Answer Garden. In: The Conference on Computer Supported Collaborative Work(CSCW'94), New York: ACM. S. 243-252.

Bayer, Elke (1995): Flexibilität in E-Mail Systemen - Ein Modell für Aushandelbarkeit. Diplomarbeit an der Universität Bonn.

Bieber, M., Vitali, F., Ashman, H., Balasubramanian, V., Oinas-Kukkonen, H. (1997): Fourth generation hypermedia: Some missing links for the World Wide Web. International Journal of Human-Computer Studies. Special issue on HCI & the Web.

Boland, R. J., Maheshwari, A. K., Te'eni, D., & Tenkasi, R. V. (1992): Sharing Perspectives in Distributed Decision Making. In: The Conference on Computer Supported Collaborative Work (CSCW'92). New York: ACM. S. 306-313.

Ephrati, Eithan; Zlotkin, Gilad; Rosenschein, Jeffrey (1994): Meet Your Destiny: A Non-manipulable Meeting Scheduler. In: Proceedings of the CSCW '94. New York: ACM. pp. 359-371.

Fitzgerald F., Rashid R. (1986): The Integration of Virtual Memory Managementand Interprocess Communication in Accent. ACM Transactions on ComputerSystems, 4, (2), 147.

Floyd, Christiane (1992): Software Development and Reality Construction. In: Floyd, Christiane; Züllinghoven, Heinz; Budde, Reinhard; Keil-Slawik, Reinhard (1992): Software Development and Reality Construction. Berlin, Heidelberg, New York: Springer-Verlag. S. 86-100.

Geibel, Richard (1993): Computergestützte Gruppenarbeit. Die Förderung von Gruppenentscheidungen durch Group Decision Support System. Stuttgart: M&P Verlag.

Habermas, Jürgen (1981): Theorie des kommunikativen Handelns. Band 1. Handlungsrationalität und gesellschaftliche Rationalisierung. Frankfurt: Suhrkamp.

Herrmann, Thomas (1994): Grundsätze ergonomischer Gestaltung von Groupware. In: Hartmann, Anja; Herrmann, Thomas; Rohde, Markus; Wulf, Volker (Hrsg.) (1994): Menschengerechte Groupware - Software-ergonomische Gestaltung und partizipative Umsetzung. Stuttgart: Teubner Verlag. S. 65-107.

Herrmann, Thomas (1995): Workflow Management Systems: Ensuring organizational Flexibility by Possibilities of Adaption and Negotiation. In: Comstock, Nora et al. (Hrsg.): COOCS´95. Conference on Organizational Computing Systems. August 13-16, 1995. Milpitas, California. New York: acm-press. New York: ACM. S. 83 - 95.

Koschmann, Timothy (ed.) (1996): CSCL: Theory and Practice. New Jersey: Lawrence Erlbaum Associates.

Lindstaedt, Stefanie; Schneider, Kurt (1997): Bridging the Gap between Face-to-Face Communication and Long-Term Collaboration. In: Hayne, S.; Pronz, W. (eds.): Proceedings of the International ACM SigGroup Conference on Supporting Group Work. The Integration Challenge. New York: ACM. S. 331-340.

Martial, Frank von (1996): A Conversation Model for Resolving Conflicts among Distributed Office Activities. In: SIGOIS 2,3. . S. 99 - 108.

Resnick, Paul; Iacovou, Neophytos; Suchak, Mitesh; Bergstrom, Peter (1996): GroupLens: An Open Architecture for Collaborative Filtering of Netnews. In: Proceedings of the CSCW '94: Transcending Boundaries. NY: ACM Press. S. 175 -186.

Sen, Sandip; Haynes, Thomas; Arora, Neeraj (1997): Satisfying user preferences while negotiating meetings. In: Int. J. Human-Computer Studies. S. 407-427.

Stahl, Gerry (1993): Interpretation in Design: The Problem of Tacit and Explicit Understanding in Computer Support of Cooperative Design. University of Colorado at Boulder.

Stefik, M.; Foster, D.; Bobrow, D.G.; Kahn, K.; Lanning, S.; Suchman, L. (1988): Beyond the Chalkboard: Computer Support for Collaboration and Problem Solving in Meetings. In: GREIF, Irene (ed.) (1988): Computer-Supported Cooperative Work. S. 335-366.

Wulf, Volker (1997): Konfliktmanagement bei Groupware. Braunschweig, Wiesbaden: Vieweg

Go to top of this page

Return to Gerry Stahl's Home Page

Send email to Gerry.Stahl@drexel.edu

This page last modified on January 05, 2004