CMI-Entwurfsmuster: Group Support

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Kurs
Kursname Web-Engineering
Kurstyp Projektkurs
Dozent KQC
Semester WS 10/11
Studiengang Master


CMI steht für "Computer-Mediated Interaction" und bezieht sich auf das Musterbuch von Till Schümmer und Stephan Lukosch: "Patterns for Computer-Mediated Interaction", Wiley, 2007 (Einsicht bei Google-Books).

Im Masterkurs "Web-Engineering" werden die CMI-Patterns in diesem Beitrag dargestellt und aufgezeigt, ob das einzelne CMI-Pattern bereits auf der eStudy-Plattform zu finden ist und wie es implementiert wurde. Falls das CMI-Pattern nicht zu finden ist, wird eine mögliche Implementierung skizziert.

Die CMI-Patterns sind in drei Cluster eingeteilt: "Community Support", "Group Support" und "Base Technology". Entsprechend haben sich im Masterkurs drei Gruppen organisiert, deren Mitglieder jeweils ein oder mehrere CMI-Patterns eines Clusters beschreiben.

Im Folgenden werden die CMI-Patterns des Clusters "Group Support" beschrieben.

Inhaltsverzeichnis

How to Modify Shared Material Together

Deutsch: Wie man Material gemeinsam modifizieren kann.

GROUP

Aahr66 01:19, 23. Nov. 2010 (CET)

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
GROUP

Alternative Bezeichnung: TEAM

Absicht

Das GROUP-Pattern (oder auch TEAM) eignet sich dazu, Gruppen zu verwalten und in der Gruppe wie mit einer einzelnen Person zu interagieren.

Kontext

Anwender kommunizieren in einer Gemeinschaft.

Problem

Die Kommunikation in einer Gruppe verläuft über mehrere Personen, jedoch agieren die Nutzer als einzelne Personen. Somit kann es schwierig sein ein Gruppenbewusstsein zu entwickeln.

Szenario

James und Rodrigo sind im Interpretieren von Texten sehr gut geworden. Die meisten der schwierigeren Sprachanalysen haben sie in Zusammenarbeit umgesetzt, jedoch hat nur James die Ergebnisse ins Versionsverwaltungssystem eingepflegt. Susan möchte nun die Sprachanalyseexperten zu einem Treffen einladen, weiß jedoch nur von James und lädt dementsprechend nur ihn dazu ein. Rodrigo ist infolgedessen enttäuscht.

Symptome

Dieses Muster sollte verwendet werden wenn, …

  • Jedes Mal wenn eine sog. COLLABORATIVE SESSION geplant ist, müssen dessen Teilnehmer dazu manuell ausgewählt werden.
  • Anwender möchten häufig mit der gleichen Gruppe an Personen kommunizieren.
  • Den Nutzern ist nicht wirklich klar, wer ihr Ansprechpartner ist.

Lösung

Teilen sie die Teilnehmer in Gruppen ein und benennen sie diese. Visualisieren sie die Gruppenzusammensetzungen. Ermöglichen Sie den Anwendern die Gruppen zu verwalten und mit ihnen in einer Weise zu kommunizieren als seien sie eine einzelne Person.

Dynamik

Ermöglichen sie den Teilnehmern die Nutzergruppen zu verwalten. Hierzu sollten folgende Funktionen zur Verfügung stehen:

  • Teilnehmer hinzufügen
  • Teilnehmer entfernen
  • Erstellen einer Gruppen
  • Benennen einer Gruppen
  • Entfernen einer Gruppen

Ist eine Gruppe erstellt, kann diese in sog. BUDDY LISTS oder USER LISTS erscheinen. In den meisten Fällen werden die GROUPS in den BUDDY LISTS dargestellt, wobei sich in den USER LISTS generell die einzelnen Nutzer wiederfinden. Diese Funktionen sollten für alle GROUPS, die für die einzelnen Teilnehmer erreichbar sind, zur Verfügung stehen.

Begründung

Da GROUPS in der gleichen Art und Weise wie einzelne Nutzer behandelt werden, ist es möglich diese in eine COLLABORATIVE SESSION einzuladen (INVITE). Des Weiteren wissen die Teilnehmer zu jedem Zeitpunkt mit wem sie kommunizieren, da die GROUPS über eine Benutzerschnittstelle visualisiert werden.

Überprüfung

Bei der Verwendung dieses Musters, sollten folgende Fragen beantwortet werden können: Wo sollen die GROUPS und wo sollen die einzelnen Nutzer visualisiert werden?

Ist eine GROUP auch für den Rest der Gemeinschaft sichtbar oder nur für Gruppenmitglieder?

Welche Funktionen sollen einer GROUP zur Verfügung gestellt werden?

Wer soll innerhalb einer GROUP die Entscheidungen treffen? Soll es einen Moderator wie in QUALITY INSPECTION geben oder sollen die Gruppenmitglieder abstimmen (VOTE) dürfen?

Gefahrenpunkte

Die Verwaltung der GROUPS kann zu einer zusätzlich Arbeitsüberlastung für die Teilnehmer führen. GROUPS können dazu führen, dass sich die Gruppenmitglieder vom Rest der Gemeinschaft isolieren und sie somit ausgrenzen. In einem breiteren Kontext der Gemeinschaft sollte darüber nachgedacht werden, wie die Gruppenmitglieder vertrieben werden. (siehe QUALITY INSPECTION)

Bekannte Anwender

  • Skype, wie auch die meisten anderen Kommunikationsinstrumente wie beispielsweise Microsoft Messenger ermöglichen Gruppen in BUDDY LISTS zu organisieren. Genauso wie bei einzelnen Benutzern können auch Gruppen als Empfänger von Aktionen ausgewählt werden.
  • Yahoo Groups ermöglichen es Nutzern über FORUMS in der Gruppe zu kommunizieren. Hier können die Nutzer sich in diese FORUMS an- sowie abmelden.

Verwandte Muster

Implementierung in eStudy

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Erstellen von Gruppen
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Benachrichtigen der Gruppen als seien sie eine einzelne Person

SHARED FILE REPOSITORY

Aahr66 01:36, 23. Nov. 2010 (CET)

Alternative Bezeichnung: SHARED FILE SYSTEM, SHARED WORKSPACE

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
SHARED FILE REPOSITORY

Absicht

Nutzern ermöglichen bei der Nutzung von Dateien zusammenzuarbeiten.

Kontext

Nutzer erstellen Dateien gemeinsam.

Problem

Nutzer tauschen zwischenzeitliche Resultate aus, indem sie Dateien an einen oder meherere Nutzer versenden. Die Sicherstellung, dass jeder Nutzer im Verteiler bleibt, ist fehlerbehaftet.

Szenario

Der erste Schritt, die Zusammenarbeit zwischen Paul und Charley zu organisieren, war es sich auf eine gängige Projektstruktur zu einigen. Jeder von ihnen erstellte Ordner auf seinem Computer, in dem sie ihre Dateien speichern/ablegen. In regelmäßigen Abständen packte (komprimierte) Charley die Ordner zu einem einzelnen Archiv und schickte dieses per E-Mail an Paul. Paul verglich dieses Archiv anschließend mit seinen lokalen Dateien und aktualisierte diese entsprechend. Wie zu erwarten ist es Paul zu umständlich seine Dateien per E-Mail Austausch (der Daten) zu aktualisieren.

Symptome

Sie sollten in Erwägung ziehen dieses Muster zu verwenden, wenn …

  • Nutzer große E-Mails mit Anhang mit einer Größe von mehreren Megabytes austauschen.
  • Nicht alle zusammenarbeitenden Nutzer die aktuellsten Dokumente besitzen oder diese Zusammenarbeit auf inkonsistenten Dokumenten basiert.
  • Dateien der Zusammenarbeit verloren gehen.

Lösung

Stellen sie ein SHARED FILE REPOSITORY zur Verfügung, in dem Nutzer Dateien ablegen und abrufen können. Gestatte es Nutzern, Dateien und Ordner zu organisieren.

Dynamik

Der Ort für ein SHARED FILE REPOSITORY kann beispielsweise ein zentraler Server sein, oder auf der peer-to-peer Architektur/Technologie basieren. Gestatte es Nutzern zumindest die folgenden Basisfunktionen in dem „Repository“ zu verwenden:

  • Dateien und Ordner erstellen
  • Dateien und Ordner entfernen
  • Dateien und Ordner umbenennen
  • Dateien und Ordner verschieben
  • Dateien und Ordner auflisten

Bevor die Datei geändert wird, erstellen die Nutzer eine lokale Kopie der Datei, in dem sie sie auf ihr eigenes System (ihren eigenen Rechner) herunterladen/laden. Anschließend verwenden sie lokale Tools, um die Datei zu verändern. Nachdem sie fertig sind (dieser Prozess abgeschlossen ist), speichern sie die Datei lokal. Bevor die modifizierte (geänderte) Datei in das Repository hochgeladen/geladen wird, prüfen die Nutzer oder das System, ob ein weiterer (anderer) Nutzer die Datei in der Zwischenzeit geändert hat. Im Falle einer geänderten Datei vergleicht der Nutzer die lokale Version mit der Version im Repository, um eine zusammengefügte Datei, welche alle Änderungen beinhaltet, zu erstellen. Abschließend lädt der Nutzer die modifizierte (geänderte) Dateien hoch.

Gestatte es Nutzern, individuellen Nutzern oder GROUPS Rechte zu ge- oder verwähren, oben beschriebene Operationen mit Dateien oder Ordnern im Repository durchzuführen. Speichere diese Informationen für jede Datei und jeden Ordner.

Gründe

Da Nutzer Dateien, die für die Zusammenarbeit nötig sind, über das SHARED FILE REPOSITORY austauschen/teilen können, ist es nicht länger nötig, große E-Mail Anhänge auszutauschen und Dateien können nicht verloren werden. Wenn alle Nutzer dem Vorgang folgen, die Datei herunterzuladen bevor sie verändert wird, kann ein SHARED FILE REPOSITORY weiterhin sicherstellen, dass Nutzer immer die aktuellste Dateiversion vorliegen haben.

Prüfung

Bei Anwendung des Musters sollten sie folgende Fragen

  • Welche Verteilungs-Architektur wird für das SHARED FILE REPOSITORY verwendet. Ist es beispielsweise ein zentraler Server oder ein Peer-to-Peer System?
  • Wie sehen sie vor, den Zugriff auf das Repository zu kontrollieren (organisieren)?
  • Haben Sie mehrere Dateiversionen zu verwalten?
  • Werden sie Tools bereitstellen, welche Nutzern bei der Synchronisation der lokalen Kopie mit den Dateien des Repositorys unterstützen?


Gefahrenpunkte

Die lokalen Kopien auf dem neusten Stand zu halten ist schwierig und zeitaufwendig. Das System kann die Benutzer durch Mittel der Synchronisation, zwischen den lokalen Kopien und den Kopien des Repository, bei dieser Aufgabe unterstützen. Zu diesem Zweck kann das System Meta-Informationen über die Datenversion in das Repository sowie lokal beim Benutzer lagern, und diese Meta-Informationen für die Synchronisation vergleichen. Wenn nur die lokalen Datei verändert wurden, werden die Daten im Repository aktualisiert. Wenn die Datei im Repository geändert wurde, wird die lokale Kopie ersetzt mit der letzten Version. Wenn beide Dateien geändert wurden, muss der Benutzer den Konflikt manuell lösen. Sollten verschiedene Benutzer die gleiche Datei modifizieren, kann das zu Konflikten beim hochladen der Datei führen, sobald ein anderer Benutzer eine neuere Version der Datei hochgeladen hat. Solche Konflikte können erkannt werden indem man CONFLICT DETECTION benutzt. Aber das manuelle Lösen solcher Konflikte kann schwierig und zeitaufwendig sein. Um diesen Fall zu bewältigen, können die Dateien für einen exklusiven Zugang gesperrt werden. (cf. PESSIMISTIC LOCKING). Der Benutzer müsste den Verlauf bzw. die Entwicklung der Datei kennen. Benutzen Sie IMMUTABLE VERSIONS, um den Benutzern zu erlauben, den historischen Verlauf der Dateien einzusehen. Benutzer könnten es als schwierig ansehen, neue und aktualisierte Dateien zu finden. Um dies zu lösen, integrieren Sie CHANGE INDICATORS.


Bekannte Anwender

  • CVS (Concurrent Versioning System) ([1] and SubVersion [2]) sind SHARED FILE REPOSITORIES die einen zentralen Server anbieten, auf dem Benutzer Dateien verwalten und organisieren können. Zusätzlich zum Repository, lagern beide Systeme alle Versionen der Dateien und bieten Mittel zum verwalten und zum Zugriff auf die verschiedenen Versionen.
  • FTP (FILE TRANSFER PROTOCOL) (Postel and Reynolds, 1985) beschreibt wie man Dateien über das Netzwerk transferiert und wie man diese dann auf einem zentralen Server verwaltet. FTP verwaltet keine verschiedenen Versionen der Datei, erlaubt aber Zugriffrechte auf die verwalteten Dateien um zu bestimmen ob diese gewährt oder verweigert werden.
  • WebDAV ([3]) steht für Web-based Distributed Authoring and Authoring. Technisch gesehen erweitert WebDAV HTTP/1.1. (Fielding et al. 1999) mit den Zielen das Internet zu einem les- und beschriftbaren Medium zu machen. Zu diesem Zweck fügt WebDAV eine Vielzahl an Methoden zu HTTP hinzu, um die Dateiverwaltung zu erlauben (Goland et al., 1999). Um Konflikte zu vermeiden, unterstützt WebDAV geteilte wie auch exklusive Locks.
  • Google Docs ([4]/) ist, wie in der Abbildung zu sehen, ein web-basiertes Repository um Dateien zu verteilen.
    Fehler beim Erstellen des Vorschaubildes: Datei fehlt
    Dateien mit Hilfe von Google Docs Verteilen
    Die Benutzer können ihr Dateien hochladen und andere Benutzer dazu einladen, mit Ihnen an einzelnen oder mehreren Dateien zusammen zu arbeiten. Google Docs unterstützt keine Ordner. Anstatt dessen können Dateien mit verschiedenen Schlüsselwörtern versehen werden, welche dann benutzt werden können um zu filtern, welche Dateien angezeigt werden.

Verwandte Muster

  • CENTRALIZED OBJECTS
  • CONFLICT DETECTION
  • INTERACTION DIRECTORY
  • LOGIN
  • USER LIST
  • PESSIMISTIC LOCKING
  • FILE AUTHORIZATION
  • LIMITED ACCESS

Implementierung in eStudy

eStudy verfügt über eine Funktion externe Tools miteinzubinden. Innerhalb einer Community ist es mit ein paar wenigen Einstellungen möglich sich eine fertiges SVN Repository einzurichten, womit dieses Muster innerhalb eStudy als verwirklicht anzusehen ist.

SHARED BROWSING

Aahr66 02:55, 23. Nov. 2010 (CET)

Alternative Bezeichung: Collaborative Browsing oder Travel Together.

Absicht

Informationsaustausch der Teammitglieder über einen gemeinsamen Kommunikationskanal.

Kontext

Die Nutzer einer Anwendung haben je nachdem einen unterschiedlichen Wissensstand über den Zustand einer Anwendungsumgebung. Welche Möglichkeiten gibt es um es den Anwendern zu erleichtern sich in der Anwendungsumgebung zu orientieren.

Problem

Benutzer haben Probleme für sie relevante Informationen in einem gemeinsamen Bereich zu finden, sodass sie sich verloren fühlen.

Szenario

Michelle ist eine angehende Doktorantin mit Interesse an Datenaustauschformaten. Ihr Interesse für das Projekt einer Spiele Engine wurde geweckt, nachdem sie mitbekam, dass Ana und Maurice an einem Export Feature für eine „Virtual Reality Modeling Language“ (VRML) arbeiteten. Daraufhin fragt sie Ana ob sie ihr und Maurice in der Entwicklung behilflich sein kann. Ana und Maurice freuen sich auf der einen Seite darüber mit Michele einen weiteren Entwickler willkommen heißen zu können, auf der anderen Seite bedauern sie jedoch das Michele nicht wirklich helfen kann, da sie sich in den vielen Projektdokumenten und im Quellcode schlecht zurecht findet.

Symptome

Sie sollten sich überlegen dieses Muster zu verwenden, wenn …

  • Die Nutzer brauchen generell lange Zeit um Informationen zu finden, die sie suchen.
  • Verschiedene Nutzer haben einen unterschiedlichen Wissensstand von der Projektspezifischen Umgebung. Dies führt zu unterschiedlich orientierten Fähigkeiten in speziellen Bereichen wobei Nutzer mit weniger Fertigkeit unter gehen.
  • Das Ziel ist es Informationen als Gruppe zu finden, jedoch kommt es vor, dass die Bemühungen von einigen Gruppenmitgliedern doppelt durchgeführt werden um dieses Ziel zu erreichen.
  • Navigation verlangt kreative Entscheidungen bei der Auswahl des richtigen Weges, wobei jedoch einzelne Benutzer diese benötigte Kreativität nicht besitzen. Es muss ihnen gesagt werden wo die gewünschten Informationen zu suchen sind.
  • Wenn Nutzer über verteilte Daten sprechen möchten, sie jedoch nicht wissen wie sie sicherstellen sollen, dass ihr Kollegen die gleichen Daten sehen.

Lösung

Durchstöbern sie einen gemeinsamen Informationsraum, welcher die gemeinsame Kommunikation und Zusammenarbeit ermöglicht, indem jeder Nutzer an jedem Ort die gleichen Informationen angezeigt bekommt.

Dynamik

Nutzer arbeiten in einem verteilten Informationsraum zusammen. Dies kann ein Dokument (mit räumlicher Gliederung) oder eine Reihe von Dokumenten sein, die in einem kollaborativen, verteilten Informationsraum liegen. Beim arbeiten mit einem bestimmten Teil dieser Daten positionieren sich die Nutzer an der benötigten Stelle. Im Falle eines Dokuments, sehen sie die bestimmte Stelle. Im Falle eines größeren Informationsraums, konzentrieren sie sich auf ein bestimmtes Dokument oder Artefakt in diesem Raum. Die Position eines jeden Nutzers kann als Ort beschrieben werden. Dies kann eine URL im Falle des WEB sein, es kann ein Dateiname im Falle eines verteilten Arbeitsbereiches sein, es kann ein Punkt im Falle eines zweidimensionalen Dokuments, beispielsweise eine Abbildung, oder es kann ein Index in einem linearen Dokument, z.B. der 1769ste Buchstabe eines Textdokuments sein. Über den Cobrowser hat also jeder Nutzer in einer Gruppe die gleiche Ansicht und kann somit in der Gruppe die gewünschten Informationen erhalten. Wie die Informationverteilung abgewickelt wird, hängt von der jeweiligen Navigationsstrategie des einzelnen Cobrowser ab. Beispiele:

  • Maser-slave browsing beschreibt die Strategie, dass ein Nutzer navigiert und die anderen folgen. Sobald also der „Master“ seine Position aktualisiert, werden auch die „Slave“-Nutzer auf die entsprechende Ansicht aktualisiert. Diese Art des cobrowsens ist für Situationen geeignet, in denen Anfänger von einem Experten eingearbeitet werden sollen.
  • Anarchistic browsing - Hierbei navigiert ein Nutzer zu einem neuen Ort und alle anderen Nutzer folgen ihm. Diese Methode eignet sich für Gruppenmitglieder die nach Informationen suchen und sich auf dem gleichen Wissensstand befinden. Diese Strategie wird hauptsächlich in gemeinschaftlichen Diagrammeditoren verwendet in denen Nutzer ihre Scrollposition teilen.
  • Democratic browsing in welchem die Gruppe zuerst eine kollaborative Meinung formen muss, bevor deren Mitglieder zum nächsten Artefakt übergehen können (VOTE). Diese Strategie ist nur geeignet für Kontexte in denen Navigation eine ausschlaggebende Aktivität ist. Ein Beispiel könnte ein kollaborativer Internet Browser sein: wann immer ein Benutzer einem Link folgt, muss der Rest der Gruppe zustimmen ob sie folgen wollen. Wenn Sie in einem Fall ein gemeinsames Diagramm vergleichen, wäre es nicht sinnvoll sich für eine neue Scroll Position per Abstimmung zu einigen, nachdem ein Benutzer die Scroll Leiste verschiebt.

Gründe

Bei einer Studie der traditionellen Bibliotheken, zeigte Twidale et al.(1997) das browsen ein kollaborativer Vorgang sein sollte. Ebenso sind viele Suchen nach Informationen in entsprechenden Orten alleine durchgeführt worden. Twidale et al. (1997) zeigt das Interaktion zwischen Benutzern ebenfalls statt finden. Seitdem kollaboratives browsen die gleichen Artefakte zeigt, sind die Benutzer in der Lage über die gezeigten Inhalte zu kommunizieren. Das hilft Ihnen die Artefakte besser zu verstehen. Wenn ein Benutzer zu einem anderen Artefakt navigiert, folgen alle anderen Benutzer, was sichert das die Gruppe beim gleichen Artefakt zusammen bleibt. Dadurch, das die Route diskutiert wird, kann die Gruppe sich für einen angemessenen Weg entscheiden. Seitdem mehrere Benutzer zusammen reisen, kann man den Verlauf der Schritte besser nachvollziehen. Im Fall der SHARED EDITORS, sowie im Fall von mehr grob-körnigen Informationsräumen, macht das vereinigte Navigieren es einfacher, über die auf dem Bildschirm dargestellten Informationen zu reden.

Überprüfung

Wenn sie dieses Muster anwenden, sollten sie diese Fragen beantworten:

  • Wie sollten Sie die Ansicht präsentieren? Können Sie eine URL oder Koordinaten benutzen?
  • Welche browsing Strategie werden Sie den Benutzern anbieten?
  • Wenn Sie ein Master-Slave browsen anwenden, wie werden Sie entscheiden wer der Anführer sein soll?

Gefahrenpunkte

Seitdem alle Browser verbunden sind, wird sich die Gruppe immer im gleichen Tempo fortbewegen.Dies kann ein Problem darstellen, wenn die verschiedenen Benutzerverständnisse sich in der Geschwindigkeit der besuchten Artefakte deutlich unterscheiden. In diesem Fall können schnelle Benutzer sich von langsameren Benutzern behindert fühlen. Die Benutzer könnten ebenso verärgert sein, da sie nicht in der Lage sind, die Gruppe zu verlassen für einen persönlichen Umweg. Dafür sollten Sie es vereinfachen, die COLLABORATIVE SESSION zu verlassen und wieder einzusteigen nach solch einem Umweg.

Bekannte Anwendungen

  • TUKAN (Schümmer 2001) ist eine kollaborative Software Entwicklungsumgebung. Sie informiert Programmierer über die Anwesenheit anderer Programmierer um eine dynamische Gruppenzusammentstellung (Gruppenerstellung) zu unterstützen. Nachdem sich Nutzer getroffen haben, können sie mithilfe eines eng gekoppelten Browsers durch den Quellcode navigieren. Immer wenn ein ein Nutzer eine Klasse oder Methode verwendet, wird der Browser aller verbundenen Nutzer ebenfalls zur gewählten Klasse oder Methode geleitet. Innerhalb der Methode, kann der Nutzer unabhängig von den anderen navigieren. Das bedeutet, dass die Scroll Position der Textfelder nicht miteinander verbunden, also unabhängig, ist.

    Während der gemeinsamen Untersuchung des Quellcodes können die Programmierer mithilfe eines integrierten Chat Tools über Code Fragmente diskutieren.
  • CobWeb (Stotts et al., 1998) gestattet es Nutzergruppen gemeinsam Websites zu betrachten. Es verwendet hierbei zwei Frames (Fenster) innerhalb des Browsers. In einem Frame wird der Inhalt dargestellt, während das andere Frame zum Browsen (Surfen) verwendet wird. Zweites Frame enthält zudem eine Möglichkeit den/das Floor anzufordern. (siehe FLOOR CONTROL).
    Fehler beim Erstellen des Vorschaubildes: Datei fehlt
    Gemeinsames Browsen (Surfen) in CobWeb (Stotts et al., 1998)
    Ein besonderes Feature von CobWeb ist die Möglichkeit für den Systementwickler, Interaktionsmodelle (Interaction Models) für das gemeinsame Browsen (Surfen) zu entwerfen. Dieser Ansatz beinhaltet vielfältige Möglichkeiten, den oben beschriebenen Interaktionsprozess zu gestalten.

GroupScape (Graham, 1997) und CoWeb (Jacobs et al., 1996) sind vergleichbar mit dem CobWeb System. Beide Systeme unterstützen ebenfalls das gemeinsame Browsen (Surfen) im Internet.

  • efa (Lukosch and Schümmer, 2006) ist ein web-basiertes Präsentations System, mit dem Studenten Seminargespräche über Entfernung proben können. Gespräche werden durch die integrierten Wiki Authorisations Mechanismen des Systems asynchron vorbereitet.
    Fehler beim Erstellen des Vorschaubildes: Datei fehlt
    Gemeinsames Browsen (Surfen) mit dem Präsentationssystem efa
    In einer synchronen Sitzung übernimmt ein Nutzer die Rolle des Präsentierenden. Der Präsentierende kann Folien aus der Übersicht der Präsentation, oder mithilfe der Navigationsschaltflächen, auswählen. (Zu sehen links in der Abbildung). Nachdem die Seite (Folie) ausgewählt wurde, wird die Ansicht der Teilnehmer entsprechend aktualisiert, so dass alle Nutzer die gleiche Folie sehen. In der rechten Hälfte der Abbildung ist die Ansicht der Teilnehmer dargestellt. Beachten sie, dass Teilnehmer keine Navigationsschaltflächen angezeigt bekommen.

Verwandte Muster

  • APPLICATION SHARING
  • SHARED EDITING
  • REMOTE FIELD OF VISION
  • COLLABORATIVE SESSION
  • FLOOR CONTROL
  • VOTE
  • EMBEDDED CHAT
  • REPLAY
  • JIGSAW

VOTE

Jant89 16:29, 22. Nov. 2010 (CET)

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
VOTE

Deutsch: Abstimmen Auch bekannt als: Poll (Umfrage), Election (Wahl)

Absicht

Die Meinungen einer Gruppe ermitteln bezüglich ein bestimmtes Thema.


Kontext

Es existiert eine Gruppe der die Austausche von Meinungen ein wichtiger Bestandteil ist.

Problem

Manchmal ist es schwer zu ermitteln, welche Meinungen zu bestimmten Themen bereits existieren und wie sie verteilt sind, doch das Verstehen dieser Ansichten verschiedener Gruppenmitglieder dient als wesentliche Entscheidungsgrundlage.


Szenario

Liam, Paul und Ana sind sich nicht sicher ob sie das Spielenginekern aktualisieren sollen. Die Aktualisierung würde die Betriebsgeschwindigkeit des Spiels erheblich verbessern, doch es wäre danach mit älteren Versionen des Spiels nicht mehr kompatible. Was sollen sie bloß tun?

Symptome

Dieses Muster sollte dann angewandt werden wann . . .

  • Unklarheit gegenüber die Erfahrungen der Benutzer könnte dazu führen dass Arbeitsschritte wiederholt werden mussen.
  • Benutzer sind in sich unstimmig welche Strategie eine gemeinsame Problemstellung am besten passt.
  • Entscheidungen, die nach Diskussion bezüglich umstrittenen Themen getroffen wurden, haben sich als falsch erwiesen.

Lösung

Daraus folgt: Es ist nötig eine leicht bedienbare Abstimmung zu führen. Diese soll Auffällig dargestellt werden. Nach der Strich gezogen wird, soll die Ergebnisse jede Beteiligte zugänglich sein.

Dynamics

Ein Benutzer initiiert die Abstimmung in dem er sowohl eine Frage als auch eine Menge an möglichen Antworten. Der Initiator legt ein Zeitfenster fest in dem Benutzer abstimmen durfen fest. Dieses Fenster kann dann durch bestimmte Zeiten / Daten eingeschränkt werden, oder nachdem eine Entscheidungsmehrheit unter den möglichen Teilnehmer sich gebildet hat, spricht genug haben für eine Lösung gewählt haben sodass weitere Stimmen diese Lösung nicht mehr überstimmen könnten. Der Initiator stimmt auch ob Zwischenergebnisse öffentlich bekannt gemacht werden sollen.

Die Frage ist den Teilnehmer entsandt, oder präsentiert beim betretten der gemeinsamen Arbeitsbereich. Teilnehmer stimmen ab in dem sie die Alternative auswählen die sie am besten. Diese Selektion wird dann vom System aufgezählt und der Teilnehmer wird gemerkt als abgestimmt zu haben. Sollte Teilnehmer die Zwischenergebnisse öffentlich gestellt sein, so werden sie nach Selektion zu diesen umgeleitet. Sollte es von Wichtigkeit sein welcher Mitglied welche Selektion getroffen hat muss die Identität der Teilnehmer an seiner Stimme gebunden sein. Dies hat aber zufolge, dass Strukture, die Stimmen abbilden kompliziert werden können. Anstatt das bloße Speichern von Anzahl der Stimmen nach Selektion, muss nun eine Menge von Teilnehmer dieser Selektion gebunden sein.

Nachdem die Abstimmung geschlossen wird sollen dann die Ergebnisse auf gleicher Weise wie die Abstimmung die Teilnehmer bekannt gemacht werden.


Philosophie

Wann Teilnehmer aufgefördert abzustimmen sind, sie werden ihre eigene Meinungen überlegen bezüglich die Frage. Wenn der Prozess einfach gestrickt ist, bspw. ein einziges Maus-Klick, werden sie keine Hemmungen haben an der Abstimmung teilzunehmen. In dem sie ihre eigene Entscheidungen mit dem der Gruppe werden sie sich besser zurecht finden in der Gruppe und Einsicht gewinnen wie andere Teilnehmer die Frage beurteilen.

Wichtige gestaltungs Kriterien

Wenn Sie vorhaben dieses Muster anzuwenden sollten sie sich diese Fragen stellen:

  • Werden Entscheidungsmehrheiten von Abstimmung zu Abstimmung variieren, oder würde die selbe Entscheidungsmehrheit sich bei jeder Abstimmung bilden?
  • Können / sollen alle registered Benutzer an der Abstimmung teilnehmen? Wenn nicht wie wird die Benutzermenge eingeschränkt?
  • Wie werden Abstimmungen angekündigt? Kennen Sie alle ihre Benutzer und können Sie sie alle eine Nachricht schicken?
  • Macht es vielleicht Sinn Benutzer an das Abstimmen zu errinern kurz davor die Abstimmung zu Ende geht?
  • Wie sollten Zwischenergebnisse dargestellt werden? Können Sie bspw. ein Bar Chart erzeugen?
  • Gibt es Aufgaben die am Ende einer Abstimmung erledigt werden sollten? Wenn ja, können diese Aufgaben automatisiert werden?
  • Wie sollten Benutzer gehandhabt werden die nicht an der Abstimmung teilnehmen? Werden Sie die Abstimmung zu einem bestimmten Zeitpunkt beenden? Wenn ja, stelle sicher dass Sie Teilnehmer, die sich noch nicht beteiligt haben, benachrichtigt werden wieviel Zeit den noch übrig bleibt um Abzustimmen.

Knackpunkte

Die Veröffentlichung von Zwischenergebnisse kann einen Einfluß haben auf das Verhalten der noch nicht beteiligte Teilnehmer.

Die automatisierte Beendung einer Abstimmung nach eine Entscheidungsmehrheit erreicht worden ist kann auch problematisch sein. Kleine Details können sehr wichtig sein für künftige Entscheidungen, iB wenn die Abstimmung soll eine Aussage machen können über die gefühle der Gruppe.

Es kann auch vorkommen, dass Benutzer nur flüchtig verstehen wofür sie tatsächlich stimmen oder desen Wichtigkeit. Jedoch die Stimmen solche Teilnehmger wird genauso gewichtet wie informierte Teilnehmer.

Bekannte Anwender

Die Starcraft Community Site (http://starcraft.org/) hält wöchentlich eine Umfrage auf deren Startesite. Nach Auswahl kann der Teilnehmer die Zwischenergebnisse betrachten. Die Umfrage Ergebnisse werden manchmal zu Headline News verarbeitet.

PoliTeam (Stiemerling and Wulf, 2000) benutzt Teilnehmer Stimmen um Zugriffsrechte auf Artifakte in Groupware Systeme zu verhandeln. Angenommen ein Benutzer hat keine Rechte auf einem Artifakt aber würde diese gerne haben. Er erstellt eine Umfrage an die Benutzer mit Zugriffsrechte ob sie ihm gestatten Zugriffsrecht auf diese Artifakt zu gewährleisten. Sollte eine Entscheidungsmehrheit erreicht werden, werden den die Rechte der Umfrage Initiator gestattet.

efa (Lukosch and Schümer, 2006) ist eine Web-basierte Präsentationssystem, wo Benutzer können gemeinsam Seminar Präsentationen durchgehen. efa benutzt VOTE an zwei verschiedenen Stellen im Präsentationsprozess:

  • Vor der Präsentation können Teilnehmer für ein bestimmtes Mitgleid als Redner wählen der sich für diese Rolle gemeldet hat.
  • Während einer Präsentation können Benutzer ihre Verständnis der vorgetragenen Stoff einstuffen. Diese Stimmen werden danach analyziert und das Ergebnis wird dann als die "Qualität" der Präsentation ausgewertet.

Lotus Sametime (http://www.lotus.com/sametime) verfügt über einen Conferencing-Tool welches erlaubt die Benutzer Diskussionen führen können, mittels einen gemeinsamenb Editor Diagramme basteln, oder geteilte propriotäre Anwendungen mittels Application Sharing Mechanismen. Zu jeder Zeit kann ein Moderator eine Umfrage initiieren in dem er bloß eine Frage stellt. Diese Frage wird entsand an alle Teilnehmer des gegenwärtige Collaborative Session, welches wird als Pop-Up dargestellt.

Digital Moderation (http://digital-moderation.com) ist ein System die Gruppenverwaltung unterstutzt. Ein Matrix kann verwendet werden um Abzustimmen bei zwei von einander abhängige Attribute. Abstimmen kann auch auf eine Liste von Ideen benutzt werden, generiert während eines Brain-Storming Session, um die Ideen eine Ranghöhe zuzuordnen gemäß bestimmte Eigenschaften.

Verwandte Muster

Letter of Recommendation ist eine Abstimmung bezüglich die Eigenschaften eines bestimmten Benutzers, weil die Werte werden aufsummiert und zu einer Empfehlungsniveau gebildet.


Collaborative Session Eine Abstimmung kann als gemeinsame Session modeliert werden.


Bell Wenn Benutzer bei einer gemeinsamen Session mitmachen möchten, können vorhandene Teilnehmer den akzeptieren oder ablehnen.


Shared Browsing benutzt Teilnehmer Stimmen falls Browsing implementiert ist um demokratisches Browsing zu realizieren.


Lovely Bags Jede Stimme kann in einem "Lovely Bag" gelagert werden, welche beinhaltet benutzer-spezivische Objekte um die Synchronität zu verhelfen — spricht Teilnehmer sollen gleichzeitig abstimmen können.

Verwendung in eStudy

Dieses Muster ist zur Zeit als eCom/Kurs Werkzeug zur Meinungsbildung/Entscheidungsfindung angeboten und wird oft benutzt innerhalb den aktiven.

Kritik

Vote sollte eigentlich "Remember Me..." denn es unterstutzt eher die asynchrone Gruppenbewusstsein und keine Artifakte werden zusammen bearbeitet.

APPLICATION SHARING

Jant89 19:56, 22. Nov. 2010 (CET)

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
APPLICATION SHARING

Absicht

Synchrones Agieren ermöglichten in einzelbenutzer Anwendungen durch reproduzieren der Benutzerschnittstelle.


Kontext

Benutzer sind auf dem Globus verteilt und wollen gemeinsam Data verarbeiten, die sich nur von domän-spezifische einzelbenutzer Anwendungen verarbeiten lies.

Problem

Benutzer arbeiten mit domän-spezifische einzelbenutzer Anwendungen. Die Notwendigkeit der Synchron-Zusammenarbeit macht sich bemerkbar, doch ist nicht von die Anwendungen unterstutzt.


Szenario

Maurice wohnt in Brazilien und glaubt einen Bug gefunden zu haben in dem VRML export Routine. Er hat bereits den defekten Teil des Export-Treibers getestet, doch ist nicht hundertprozentig sicher das Verhalten des Treibers richtig verstanden zu haben. Es wäre geschickt wenn George, einer der Text-Experten in London, die Anwendung untersuchen könnte.

Symptome

Dieses Muster sollte dann angewandt werden wenn . . .

  • Benutzer wollen zusammen mittels einzelbenutzer propriotärer Anwendungen arbeiten.
  • Benutzer wollen das was auf ihrem eigenen Bildschirm erscheint besprechen.
  • Benutzer brauchen hilfe mit einer einzelbenutzer propriotärer Anwendung, aber ein Berater ist geographisch entfernt.

Lösung

Daraus folgt: I/O Streams beobachten und geschickt duplizieren um Anwendungen fernzusteuern.

Prozess

Ein Benutzer entscheidet eine Anwendung oder gar seine gesamte Desktop mit einem anderen. Bei dem Benutzer, der seine Anwendung(en) teilen möchte, ein Application-Sharing Server sammelt die I/O Ströme der Benutzerschnittstelle. Der Output Strom ist typischerweise die graphische Darstellung der Ansichten und der Input Strom beinhaltet eine Sequenz von Maus und Tastitur Ereignisse. Andere Benutzer können sich dann mit dieser Application-Sharing Server verbinden mittels eines geeigneten Clients. Ab dieser Punkt verteilt die A-S Server den Output Strom an alle verbundene Clients. Der Client benutzt dieser Strom um eine Darstellung um eine Abbildung der Ziel Anwendung / der Ziel Rechner zu gestalten.

Wenn die entfernte Benutzer Objekte innerhalb der Anwendung manipulieren möchten mussen sie erstmals den Zugriff verlangen. Dies ist realizierbar mittels Floor Control. Sobald der entfernte Benutzer hat die nötigen Rechte, sammelt sein Client seine Eingaben auf und schickt sie zum A-S Server, der verursacht dass die Eingaben local ausgeführt werden.

Philosophie

Jede Anwendung kann auf diese Weise geteilt werden, somit können Benutzer synchron agieren in beliebige einzelbenutzer Anwendung.

Wichtige gestaltungs Kriterien

Wenn Sie vorhaben dieses Muster anzuwenden sollten sie sich diese Fragen stellen:

  • Werden sie einzelne Anwendungen teilen oder die gesamte Desktop?
  • Wie soll die Output-Strom aufgesammelt werden für die Replikation?
  • Wird die gesamte Benutzer-Schnittstelle aktualisiert werden sollte eine Änderung vorkommen, oder werden bloß die Änderungen verteilt? Beim letzeren, wie werden denn die Änderungen aussondiert?
  • Wie werden die Eingabeströme der Clients eingeschlüesst?

Knackpunkte

Das duplizieren der Outputströme benötigt sehr viel Bandbreite. Sollte der Bandbreite gering sein, mussen die Bildschirmauflösung und Farbentiefe dementsprechend angepasst werden um sparsam damit umzugehen. Einige Benutzer, wegen der Privatspäre oder Datenschütz, möchten nicht ihre gesamte Desktop teilen, aus diesem Grund muss die Anwendung entscheiden können zwischen Einzelfenster- und Desktopübertragungs Modus.

Das Model der geteilte Anwendung is nur der Benutzer der seine Schnittstelle teilt zugänglich. Wenn die Zusammenarbeit abgeschlossen ist hat nur der Teiler die Resultat, aus diesem Gründ wäre es nicht ungeschickt an andere Mechanismen zu denken die das Teilen der Endprodukt an alle Teilnehmer ermöglichen würden.

Als der Benutzerschnittstelle vervielvälltigt wird, kann die Anwendung keine besondere Gruppendienste leisten, welche Zusammenarbeit oder das Gruppenbewusstsein leisten. Solche Anwendungen sind "collabaration-transparent" (Lauwers and Lantz, 1990). Um bessere Zusammenarbeit zu gewährleisten wäre es angebracht eine Zusammenarbeitsanwendung und / oder Gruppenbewusstseinsanwendung mit einzubinden. Zum Beispiel durch Shared Editing dieses beschreibt wie man diese Markel überwinden kann und gleichzeitig mehrere Aktionen auszuführen.

Bekannte Anwender

HP SharedX (Garfinkel et al., 1994) erlaubt das Teilen von Anwendungen zwischen entfernte Benutzer und Anzeigen in dem sie die X Window System erweitert (Gettys et al., 1990). HP SharedX ist ein tief-schicht Mechanismus, die Fensterinhalte teilt und aktualisiert. Zudem schleusst sie eintreffende Daten von den interagierenden Benutzer zusammen.

Microsoft NetMeeting (Summers, 1999) erlaubt das Teilen von Anwendungen die auf Microsoft Windows Betrieb systeme laufen.

RealVNC (Richardson et al., 1998) (http://www.realvnc.com/) wurde entwickelt als Fernsteuerungsanwendung welche das Zuschauen und Interagieren mit einem Server von einem anderen mit installiertem Client. Zu dem erlaubt RealVNC eine Gruppe von Benutzern mit dem VNC Server um zusammenzuarbeiten.

Verwandte Muster

Shared Editing und Shared Browsing beschreiben geschicktere Metheoden um synchron zu interagieren und das Gruppenbewusstsein zu gewährleisten.


Floor Control bechreibt wie Modifikationsrecht können von einem interagierenden Benutzer zum Benutzer gegeben werden kann.


Replicated Objects und Mediated Updates beschreiben wie der Outputstrom vervielfacht werden kann.

Verwendung in eStudy

Application Sharing wird nicht in eStudy zur Zeit verwendet, wäre auch nicht unbedingt angebracht.

Kritik

Es wird durch den ganzen Text die Synchronität dieses Muster beteuert, dies ist aber nur in die Darstellung vorhanden. Im Wesentlichen unterscheidet sich Application Sharing von Shared Editing in dem gemeinsame Artifakte werden in Application Sharing asynchron bearbeitet und in Shared Editing synchron. Dies ist zwar eine wesentliche Unterscheidung dennoch klein genug um zu sagen dass die Funktionalität Application Sharing eine echte Untermenge die von Shared Editing, oder dass Shared Editing setzt die Funktionalität angeboten von Application Sharing voraus.

SHARED EDITING

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
SHARED EDITING

Absicht

Ermöglicht die Benutzer die Gleichzeitige bearbeitung von Daten.


Kontext

Benutzer sind graphisch verteilt und wollen gleichzeitig Data gemeinsam verarbeiten.


Problem

Benutzer teilen Data untereinander aus um zusammenzuarbeiten. Der Zwang gleichzeitig Data zusammen zu bearbetien wird festgestellt, doch die Anwendungen (see Application Sharing ) können nicht damit umgehen.

Szenario

Maurice hat seine Arbeit am VRML Export Driver des VR Engine fortgesetzt. Der Grossteil seiner Aufgaben sind durchaus nachvollziehbar sodass er die Implimentierung über eine Tasse Kaffee ausgeheckt werden kann. Plötzlich stößt er auf ein zeimlich kompliziertes Triangulationsproblem. Er würde diese Problem am liebsten mit Paul durchkauen, doch Pual ist auf eine Geschäftsreise und ist nur im Internet erreichbar. Maurice hat keine andere Wahl als per E-Mail um mit Paul seine Ideen zu kommunizieren. Paul hat teilweise andere Ideen wie Maurice und schlägt ihm die vor. Nach einige Austausche einigen sie sich auf eine Lösung. Es wäre viel einfacher gewesen wenn sie hätten im Style von Pair-Programming, spricht beide vor der selben Tastitur, zusammen arbeiten können.

Symptome

Dieses Muster sollte dann angewandt werden wenn . . .


  • Benutzer wollen gleichzeitig die selben Materialien bearbeiten.
  • Benutzer wollen gleichzeitig zusammen arbeiten können.
  • Benutzer beschweren sich weil ihnen das Gruppenbewusstsein fehlt.
  • Die Leistung einer geteilte Anwendung schränt die Gruppe schwer ein.

Lösung

Daraus folgt: Es muss einen Editor her, der das gleichzeitige Bearbeiten von geteilte Materialien erlaubt. Er muss auch sicher stellen, dass alle Änderungen sofort bei allen Beteiligten angezeigt werden und dass alle Teilnehmer einender bewusst sind.

Prozess

Text.

Philosophie

In dem mann einen Editor-Modell teilt und so strukturiert, dass bei der Eingabe die Überreinstimmung der Daten beachtet wird, können Benutzer gleichzeitig gemeinsam arbeiten. Im Vergleich zu Application Sharing ist es aber möglich die Benutzerschnittstelle so zu gestalten sodass sie das Gruppenbewusstsein fordert. Zudem ist die Leistung eines Shared Editors um einiges höher als eine geteilte Anwendung, weil bloß die Änderungen werden kommuniziert, anstatt die komplette Aktualisierungen zu den Views. Dies hat auch zu folge dass weniger Bandbreite verbraucht wird. Wenn die Implementierung auf das Modell von Replicated Objects erhöht dass noch noch weiter die Antwortezeit vom geteilten Editor, weil Lese-Operationen können lokal ausgeführt werden. Dies erlaubt die Aktualisierung der lokaler Ansicht ohne das eine Request ausgeführt werden muss.

Wichtige gestaltungs Kriterien

Wenn Sie vorhaben dieses Muster anzuwenden sollten sie sich diese Fragen stellen:

  • Wie werden die Eingabestrukturen aussehen und wie werden Unstimmigkeiten in geteilte Daten vermieden?
  • Wie wird das Gruppenbewusstsein unterstützt?
  • Ist ein streng oder ein fehler toleranter WYSIWIS?

Knackpunkte

Text

Bekannte Anwender

Company (source) Text.

Verwandte Muster

Application Sharing beschreibt wie die Darstellung und die Geschäftslogik von einzelanwender Anwendungen können vervielfälltigt werden um gemeinsame Bearbeitung zu ermöglichen, die einzige Unterschied liegt daran dass in Shared Editing alle Benutzer gleichzeitig bearbeiten können und nicht nur beobachten.

Centralized Objects oder Replicated Objects ermöglichen das Teilen das Modell, die Darstellung und der Controller des gemeinsamen Editors.

Collaborative Session Die gemeinsame Bearbeitung findet statt in einem gemeinsamen Session, der definiert wer an der Bearbeitung teilnimmt.

Floor Control, Pessimistic Locking und Optimistic Concurrency Control bieten verschiedene möglichkeiten an der gemeinsame Editor Ordnung und Structure zu bieten und dadurch das Verhalten des Editors zu gewährleisten.

Shared Browsing beschreibt wie Benutzer die gleiche Wissenstand erreichen können durch gemeinsames Förschen. Spricht Shared Browsing unterstutzt synchrone Beobachtung, aber keine Bearbeitung gemeinsame Dokumente.

Shared File Repository and Room beschreibt wie man notwendige Dokumente mit andere Benutzer teilen kann, doch nicht wie man sie gemeinsam bearbeiten kann. Shared File Repositories oder Rooms können als Treffpunkte benutzt werden um Shared Editing anzufangen.

Remote Cursor, Remote Selection und Remote Field of Vision können angewandt werden um Benutzer an den derweiligen Ziele ihre Kollegen bewusst zu machen.

Telepointer kann verwendet werden von Benutzer die gemeinsam arbeiten um auf einem spezifischen Artifakt anzudeuten.

Verwendung in eStudy

Zur Zeit wird dieses Muster nicht innerhalb von eStudy verwendet, dennoch wäre es sehr sinnvoll für die Erstellung gemeinsame Dokumente wie Projektarbeiten oder Präsentationen.

Kritik

Application Sharing: Kritik

FLOOR CONTROL

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
FLOOR CONTROL

Absicht

Es soll immer nur ein Benutzer zur gleichen Zeit in dem zusammen genutzten Kollaborationsraum agieren.

Kontext

Benutzer interagieren zur gleichen Zeit in einem Kollaborationsraum.

Problem

Gleichzeitige Interaktion kann zu parallelen und damit zu kollidierenden Aktionen führen, welche die Benutzer verwirren, ungewollte Resultate mit sich bringen und die Interaktion allgemein erschweren können.

Szenario

Paul würde gerne Projektflyer für potentielle Sponsoren für die Spiel-Engine erstellen. Dafür nutzt er einen von mehreren Benutzern gleichzeitig verwendbaren Editor und lädt noch zehn weitere Teammitglieder dazu ein an der gemeinsamen Bearbeitungssitzung teilzunehmen. Allerdings wird ihre Arbeit schnell unstrukturiert, da jeder Teilnehmer an einer anderen Stelle im Editor arbeitet.
Konsistenz geht verloren.

Symptome

Dieses Muster sollte angewendet werden, wenn...

  • Kollidierende und parallele Aktionen interagierende Benutzer verwirren können.
  • Parallele Nutzung von gemeinsam genutzten Ressourcen (wie z.B. einem Kommunikationskanal) nicht möglich ist.

Lösung

Daraus folgt: Es muss ein Rechtesystem in dem gemeinsam genutzten Kollaborationsraum modelliert werden. Mit Hilfe eines Tokens wird festgelegt, dass nur der Benutzer, der das Token gerade besitzt, auf die gemeinsam genutzten Ressourcen zugreifen und sie auch modifizieren darf. Es muss ein fairer Prozess designt werden, der das Token innerhalb der Benutzergruppe weiterreicht.

Dynamik

Der Benutzer, der gerade im Besitz des Tokens ist, gilt als Benutzer, der im Besitz des Bodens (Floor) ist. Der Benutzer, der im Besitz des Bodens ist, ist der/die Einzige, der/die auf einen Satz gemeinsam genutze Ressourcen im Kollaborationsraum, die dem Boden zugeordnet sind, zugreifen und auch manipulieren kann. Es können mehrere Böden in einem Kollaborationsraum existieren, denen jeweils verschiedene Sätze von gemeinsam genutzen Ressourcen zugeordnet sind. Da dies nur von dem zu unterstützten Kollaborationsprozess abhängt, gehen wir an dieser Stelle von nur einem einzigen vorhandenen Boden aus.

Es existieren viele möglichen Gruppenprozesse, die dem Weiterreichen des Bodens zwischen kollaborierenden Benutzern dienen. Diese Gruppenprozesse mussen gewährleisten, dass der Boden in einer fairen - oder zumindest akzeptierten - Art und Weise zwischen den Benutzern weitergereicht wird.

Ein üblicher Gruppenprozess basiert auf Benutzern, die den Boden über eine Benutzerschnittstelle explizit anfordern und freigeben. Um den Boden zu implementieren und einen fairen Auswahlprozess, der aus den den Boden anfordernden Benutzern den nächsten auswählt, zugewährleisten, kann das Token als eine Warteschlange realisiert werden, die zentralisierte Objekte (Centralized Objects, 2.1) verwendet. Jede Anfrage des Bodens wird der Warteschlange hinzugefügt: Sobald der aktuelle Besitzer des Bodens diesen wieder freigibt, erhält der nächste Benutzer in der Warteschlange den Boden. Um ein Gruppenbewußtsein zu unterstützen, können der aktuelle Bodenbesitzer und die Positionen der anderen Benutzer in der Warteschlange in der Benutzerliste (User List, 4.1) dargestellt werden.

Sollte es nicht möglich sein eine zentrale Seite zur Verwaltung einer solchen Warteschlange anzubieten, kann der Boden auch als verteiltes Token implementiert werden, welches auf Token-basierte Algorithmen zum gegenseitigem Ausschluss basiert. Chang (Chang, 1996) liefert eine Klassifizierung von bestehenden Algorithmen für verteilten, gegenseitigen Ausschluss.

Neben dem grundlegenden Anfrage-Regelwerk behandeln Dommel und Garcia-Luna-Aceves (Dommel and Garcia-Luna-Aceves, 1997) beispielsweise einige weitere Möglichkeiten, den Boden zwischen kollaborierenden Benutzern weiter zu reichen.


  • Leitung des Vorsitzenden. Der Vorsitzende einer Sitzung ist der Vermittler des Bodens.
  • Ordnungs-Ausrichtung. Der Boden wird anhand eines speziellen Plans oder einer speziellen Aufgabe weitergereicht.
  • Zeitliche Ausrichtung. Das Recht, den Boden zu besitzen, basiert auf einer Zeitbeschränkung ('Timeout').
  • Vordefinierte Ordnung. Der Boden wird anhand einer spezifischen Ordnung zwischen den Benutzern weitergereicht.
  • Wahl. Die Teilnehmer wählen den nächsten Besitzer des Bodens.
  • Lotterieplan. Das Weiterreichen des Bodens an den nächsten Benutzer wird anhand einer stochastisch unabhängigen, fairen Schemas durchgeführt.


Erkenntnis

Wenn immer nur ein Benutzer zu gleichen Zeit Zugriff auf gemeinsam genutzte Ressourcen hat und diese manipulieren kann, gibt es keine kollidierenden Änderungen/Aktionen und/oder parallele Nutzung der Ressourcen.

Kontrolle

Wenn dieses Muster angewandt werden soll, sollten zuvor die folgenden Fragen geklärt werden:

  • Durch welche Art und Weise soll der Boden zwischen den Benutzern weitergereicht werden?
  • Soll der Boden durch die Verwendung einer zentralen Seite verwaltet werden?
  • Soll der aktuelle Besitzer des Bodens und die Benutzer die ihn anfordern in einer Benutzerliste visualisiert werden?

Gefahrenpunkte

Es muss geährleistet werden, dass der Boden wieder freigegeben wird, wenn sein aktueller Besitzer seine Verbindung trennt. Einige Prozesse, die Kollaboration ermöglichen, erzeugen eventuell einen höheren Grad an konkurrierender Interaktion. In diesem Fall müssen gemeinsam genutzte Ressourcen entweder in verschiedene Sätze aufgeteilt werden, für die wiederum mehrere Böden notwendig sind, oder es muss Optimistic Concurrency Control (3.2) angewendet werden.

Bekannte Nutzer

NetMeeting (Summers, 1999) nutzt Floor Control für das Application Sharing (1.5).
Es ist immer nur dem aktuellen Besitzer des Bodens gestattet, mit der gemeinsam genutzen Anwendung zu interagieren. Die anderen Benutzer dürfen lediglich die Aktionen des Bodenbesitzers verfolgen. Benutzer müssen den Boden explizit vom Besitzer des Bodens anfordern, der den Boden dann entweder dem nächsten Benutzer übergeben kann oder ihn weiterhin behält.

VITERO ist ein Konferenzsystem, welches die Verantwortung für die Einhaltung von Floor Control in die Hände von bis zu zwei Moderatoren legt. Um reden zu können, müssen Benutzer ihre Absicht bekünden, indem sie "ihre Hand heben" und den Status ihres virtuellen Ichs (Virtual Me, 1.5) ändern, so dass dieses mit einem Symbol visualisiert wird, welches einer gehobenen Hand entspricht. Die Moderatoren können dann ein Mikofon-Symbol an den anfordernden Benutzer reichen. Dieses Mikrofon-Symbol wird auch allen anderen Benutzern angezeigt, damit sie stets darüber informiert bleiben, welcher Benutzer gerade sprechen kann. Wenn ein Benutzer das Mikrofon besitzt, eröffnet das System einen Kanal von diesem Benutzer zum Rest der Gruppe.

FlashMeeting (http://www.flashmeting.com) ist ein webbasiertes Audio/Video Konferezwerkzeug. In FlashMeeting müssen Benutzer deb Boden explizit anfragen, wenn sie reden möchten. Ihre Anfrage sowie ihre Position in der Warteschlange wird in einer Benutzerliste (User List, 4.1) visualisiert. Zusätzlich wird der nächste Besitzer des Bodens in einer Statusleiste angezeigt, der den Boden erhält, sobald der aktuelle Besitzer seine Sendung einstellt.

Verwandte Muster

  • Optimistic Concurrency Control (3.2)
  • Pessimistic Locking (3.1)
  • Turn Taking (Björk and Holopainen, 2005) regt eine ähliche Lösung im Kontext des Spieledesigns an. Die Autoren schlagen vor, dass jeweils nur ein Spieler zu einem Zeitpunkt agieren darf, während die anderen Spieler nur Zuschauer sind. Wie das Token, welches einen Spieler dazu befähigt zu agieren, weitergereicht wird, hängt von der Strategie des Spiels ab - zum Beispiel zufällige Auswahl des nächsten Spielers.

Rgdk47 18:15, 22. Nov. 2010 (CET)

How to Create Places for Collaboration

Deutsch: Wie man virtuelle Orte erzeugt die gemeinsames Arbeit erleichtern.

ROOM

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
ROOM

Absicht

Einer Gruppe soll ein Raum geboten werden, in dem sie sich zur Kollaboration treffen kann.

Kontext

Verteilte Benutzer möchten über Kommunikationskanäle und Dokumente zusammen arbeiten.

Problem

Die Benutzer nutzen verschiedene Werkzeuge für die Kommunikation, den Dateitransfer, die Nutzung der zusammen genutzten Anwendungen und weiterer Aufgaben, die für die Interaktion in einer Gruppe notwendig sind. In den meisten kollaborativen Sitzungen (Collaborative Session, 1.1) werden diese Werkzeuge gemeinsam verwendet. Das Aufsetzen dieser Werkzeuge ist jedoch schwierig und zeitaufwändig.

Szenario

Da Paul immer noch auf seiner Geschäftsreise ist, beschließt Maurice Noah zu einer paarweisen Programmiersitzung einzuladen. Noah hat bislang noch nicht an der Entwicklung der Virtual Reality Engine teilgenommen, daher gwährt ihm Maurice Zugriff auf ihr gemeinsam genutztes Dateiarchiv (Shared File Repository, 1.2). Allerdings kann Noah dadurch weiterhin nur einen Teil des Projektes einsehen. So hatte Maurice zum Beispiel einen langen E-Mail verkehr mit Paul, der viele wichtige Informationen bereithält. Auf diese E-Mails kann Maurice jedoch nicht zugreifen. Paul und Maurice tauschten auch ihre Telefonnummern aus, damit sie auf diesem Wege miteinander kommunizieren können. Dies muss nun von Noah ebenfalls durchgeführt werden, und es ist so gut wie sicher, dass Maurice ein paar wichtige Informationen Noah unwissentlich vorenthalten wird.

Symptome

Dieses Muster sollte angewendet werden, wenn...

  • Benutzer es schwierig finden, an einer bestehenden, kollaborativen Sitzung teilzunehmen.
  • Dokumente parallel bearbeitet werden und Benutzer deren neue Versionen häufig an die Gruppe weiterreichen müssen.
  • Benutzer mehrere Werkzeuge nutzen, die separat gestartet und gesteuert werden müssen, diese jedoch von der gesamten Gruppe gemeinsam genutzt werden sollen.
  • Benutzer sich darüber beschweren, dass die Verwaltung der Werkzeuge und Kommunikationskanäle zu schwierig ist.

Lösung

Daraus folgt: Es gilt einen virtuellen Platz zu schaffen, der als Raum für Kollaboration dient und Dokumente sowie Teilnehmer unter ein Dach bringt. Es muss gewährleistet sein, dass zwischen allen sich in einem Raum befindlichen Benutzern automatisch Kommunikationskanäle bestehen. Jeder Benutzer muss Zugriff auf alle Dokumente innerhalb des Raums haben, und alle Dokumente müssen zu jeder Zeit beständig sein. Änderungen an den Dokumenten müssen von allen Benutzern im Raum gesehen werden können.

Dynamik

Der Raum beinhaltet Benutzer und Dokumente und stellt Kommunikationskanäle sowie gemeinsam genutzte Editoren zur Verfügung. Jeder Raum verfügt über klar definierte Grenzen, die festlegen, was sich innerhalb und was sich außerhalb des Raums befindet. Ein Raum hat eine Identifikation, anhand derer die Benutzer den Raum finden können. Diese kann entweder ein Name oder etwa eine Position innerhalb eines Satzes von verbundenen Räumen sein. Benutzer können einem Raum beitreten, wodurch sie die Erlaubnis erteilt bekommen den Kommunikationskanal des Raumes mit zu benutzen und an kollaborativen Aktivitäten teilzunehmen. Der Kommunikationskanal kann dabei synchron, wie etwa bei einem eingebetteten Chat (Embedded Chat, 3.1), oder asynchron sein, wie zum Beispiel in Form eines Forums (3.2).

Benutzer können dem Raum Dokumente oder Werkzeuge hinzufügen. Dies bedeutet, dass das Dokument für alle anderen Teilnehmer des Raums sichtbar wird. Wenn Benutzer mit Dokumenten arbeiten, können sie dies oft mit den anderen Teilnehmern im Raum durch die Nutzung von gemeinsam verwendbaren Arbeitsbereichen tun oder das Ergebnis teilen, indem innerhalb des Raums auf das selbe Dokument zugegriffen wird.

Wenn Benutzer den Raum verlassen bleibt der Inhalt bestehen, so dass zurückkehrende Benutzer ihre Arbeit an den im Raum zur Verfügung stehenden Dokumenten fortführen können.

Erkenntnis

Alle in einem Raum anwesenden Benutzer teilen automatisch die Kommunikationskanäle und Dokumente, die sie mit in den Raum hineinbringen. Dies gewährleistet, dass Benutzer nicht mit der Einrichtung von notwendigen, aber schwierig einzurichtenden Kommunikationskanälen belastet werden. Das Einzige, was ein Benutzer tun muss, ist dem Raum beizutreten. Alle wichtigen Verbindungsverwaltungen werden automatisch vom System bzw. dem Raum übernommen.

Das Gleiche gilt für das Nutzen von gemeinsamen Dokumenten. Das System verteilt Änderungen an den Dokumenten an alle Im Raum befindlichen Benutzer. Benutzer müssen sich daher nicht mehr mit dem Aufbau von Verbindugnen zur gemeinsamen Nutzung von Anwendungen herumschlagen.

Dokumente müssen nun nicht mehr über eine externe Kommunikationsmöglichkeit der Gruppe zugesendet werden, sondern lediglich im Raum platziert werden, wo dann auch gleich die gemeinsame Arbeit an den Dokumenten durchgeführt werden kann.

Hinweis: Räume werden auch oft als Metaphern für Anwendungen genutzt, die nur von einem Benutzer benutzt werden. Henderson, Jr. und Card (1986) haben diese Metapher des Raums dem Begriff des Desktops gleichgestellt.

Kontrolle

Wenn dieses Muster angewandt werden soll, sollten zuvor die folgenden Fragen geklärt werden:

  • Wie können die Grenzen des Raums wahrnehmbar gemacht werden?
  • Wie soll die Konfiguration der Werkzeuge, Anwendungen und Dokumente im Raum bewerkstelligt werden?
  • Welche Kommunikationskanäle werden im Raum benötigt?
  • Wie sollen die Räume selbst platziert werden? Soll ein Benutzer dem Raum eine Position zuweisen können? Ist diese Position wichtig?

Gefahrenpunkte

Der Vorteil dieses Muster, namentlich die automatische Erstellung von Kommunikationskanälen, kann auch problematisch sein, da sie Rechenleistung und Bandbreite benötigt. Wenn Benutzer zu sehr abgelenkt werden, sollte ihnen die Möglichkeit offen stehen, die Kommunikationskanäle von ihrer Seite aus zu deaktivieren. Dies kann jedoch zu ungewollten Annahmen der anderen Benutzer führen, da diese weiterhin davon ausgehen, dass alle Teilnehmer des Raums an der Kommunikation teilnehmen.

Bekannte Nutzer

Collaborative virtual learningenvironments wie zum Beispiel VITAL oder Lecture2000. In VITAL (Virtual Teaching and Learning, Pfister et al., 1998) wurden Räume dazu genutzt, das virtuelle Lernen zu strukturieren. In beiden Systemen hielten die Räume Hypertext-Dokumente bereit, an denen gemeinsam gearbeitet werden konnte. Die Lernenen hatten auch einen persönlichen Raum, der ihr Heim (Home) wiederspiegelte. Sie betraten diesen Raum wenn sie begannen das System zu nutzen, und normalerweise waren sie in diesem Raum allein. Sie konnten andere Lernende in ihr Heim einladen oder konnten spezielle Gruppenräume besuchen, die für das Lernen in der Gruppe genutzt werden konnten.

Die Heim- als auch Gruppenräume stellten einen Audiokanal zur Verfügung, der automatisch für alle Teilnehmer des Raums aufgebaut werden konnte. Weitere Räume setzten spezielle soziale Interaktionen voraus, wie zum Beispiel dem Auditorium, in dem der Trainer die Interaktionen kontrollierte, indem er Benutzern erlaubte zu sprechen oder an gemeinsam genutzen Dokumenten zu arbeiten.

Eine vergleichbare Struktur wird im Lecture2000 Prototypen (Schlichter et al., 1998a) verwendet. Benutzer betreten das System durch eine Eingangshalle und können von dieser aus die Gruppenräume oder die Tuturienräume betreten.

Verwandte Muster

Rgdk47 17:40, 22. Nov. 2010 (CET)

ACTIVE MAP

Absicht

Es soll eine graphische und skalierte Repräsentation eines Bereich dargestellt werden, die mit Wahrnehmungsinformationen angereichert wird.

Kontext

Benutzer interagieren in einem großen und komplexen Bereich, der viele Werkzeuge und Orte für Kollaboration beherbergt. In diesem Bereich gilt es die Orientierung und Koordinierung zu erleichtern.

Problem

Um sich in einem Bereich orientieren und in diesem interagieren zu können, müssen sich die Benutzer geistig ein Modell vorstellen können, das den gesamten Bereich mit all seinen Werkzeugen und Benutzern repräsentiert. Dies ist eine schwierige Aufgabe.

Szenario

Die Idee Räume zu benutzen wurde von Community gut aufgenommen. Einige Arbeitsgruppen haben ihre eigenen Arbeitsräume erstellt, sowie angrenzende Räume, die von Untergruppen benutzt werden. Michele erinnert sich daran dass sie eine Verabredung mit Noah hat, um am VRML export weiter zu arbeiten. Allerdings hat sie vergessen in welchem Raum sie sich treffen wollten, denn sie haben mehrere Räume erstellt, um an verschiedenen Aspekten des VRML export zu arbeiten. Also beginnt Michele damit, jeden einzelnen Raum aufzusuchen, bis sie schließlich Noah gefunden hat.

Symptome

Dieses Muster sollte angewendet werden, wenn...

  • Benutzer nur einen kleinen Teil des sehr großen Interaktionsbereichs sehen, was es ihnen erschwert, sich einen Überblick zu verschaffen.
  • Benutzer in verschiednen, sich nicht überlappenden Regionen im Bereich arbeiten, so dass es schwierig wird über die Aktivitäten der anderen Benutzer auf dem Laufenden zu bleiben, zum Beispiel mit Hilfe von Remote Cursors (4.7) oder Remote Fields of Vision (4.5).

Lösung

Daraus folgt: Es muss eine reduzierte visuelle Repräsentation des räumlichen Bereichs mit Hilfe einer sogenannten Karte ("Map") erstellt werden. Auf der Karte sollen die Positionen der anderen Benutzer angezeigt werden. Es muss gewährleistet sein, dass die Karte in Bezug auf Werkzeuge und Benutzer dynamisch ist, jedoch statisch im Hinblick auf Grenzsteine.

Dynamik

Die Erstellung einer aktiven Karte benötigt sechs Schritte:

  1. Filter. Im ersten Schritt wird festgelegt, welche Bestandteile und Werkzeuge als wichtig genug erscheinen, um sie auf der aktiven Karte darzustellen und um somit einen Überblick zu erhalten. Welche Bestandteile das sind, hängt von der Zielgruppe ab. In einer kollaborativen Lernumgebung sind Studenten beispielsweise wahrscheinlich nur an solchen Räumen interessiert, die mit den von ihnen besuchten Veranstaltungen zusammenhängen. Andere Räume von Veranstaltungen anderer Fakultäten können zum Beispiel herausgefiltert werden.
  2. In Ansammlungen gruppieren. Verschiedene Bestandteile oder räumliche Strukturen müssen zu einer zusammengefassten Struktur kombiniert werden, um eine Karte zu erstellen, die eine angemessene Detailfülle besitzt. Dies bedeutet, dass individuelle Räume zu einem "Gebäude" kombiniert werden könnten, so dass auf der Karte lediglich das Gebäude abgebildet werden muss. Solche Zusammenfassungen vereinfachen die Karte, da in ihr nicht mehr so viele Details dargestellt werden müssen.
  3. Entwurf/Organisieren. Falls die Ansammlungen noch keine räumliche Anordnung besitzen, können sie mit Hilfe von automatisierten Layout Algorithmen, wie zum Beispiel dem Graph Embedder Algorithm (Frick et al., 1995), arrangiert werden. Jedes automatisierte Layout sollte zwei Aspekte in Betracht ziehen: Zunächst sollte es dem Benutzer erlauben, das automatisierte Layout der Karte manuell zu korrigieren. Dies bedeutet, dass die generierte Karte von den Benutzern des Bereichs editierbar sein muss, so dass diese die Anordnungen ggf. korrigieren können. Des weiteren sollte es alte Positionen respektieren, die es bereits den Benutzern mitgeteilt hat. So sollte zum Beispiel ein spezifischer Raum, der in der ersten Version der Karte in der oberen linken Ecke platziert war, auch in der zweiten Version der Karte an eben jener Stelle dargestellt werden.
  4. Mit Bewusstseins-Informationen verbessern. Nach der räumlichen Anordnung der Bestandteile und Räume sollten Aktivitäten, die in einem Zusammenhang mit den Bestandteilen oder Räumen stehen, auch von ihrer Position auf der Karte her mit den Bestandteilen und Räumen zusammenhängen. Potentielle Visualisierungen sind Benutzerlisten (User Lists, 4.1), virtuelle Ichs (Virtual Mes, 1.5), Remote Cursors (4.7) oder Remote Fields of Vision (4.5).
  5. Maßstab. Alle Koordinaten müssen herunter skaliert werden, um eine Miniaturversion der virtuellen Umgebung zu erstellen. Falls die Karte durchscrollt werden kann, sollte der Maßstab vom Benutzer selbst festgelegt werden können. Anderenfalls sollte der Maßstab von der Größe der Karte in Relation zur Größe des gesamten Bereichs stehen.
  6. Zeichnen. Die Karte muss als Ansicht aufgefasst werden. Diese Ansicht sollte für alle Benutzer gültig gehalten werden. Änderungen, zum Beispiel der Wechsel der Position eines Benutzers von einem Platz zu einem anderen, müssen ein automatisiertes Update der Karten aller anderen Benutzer auslösen. Das Shared Subscription Muster kann verwendet werden, um solch ein Update zu erzwingen.

Die Schritte 1-3 müssen immer dann ausgelöst werden, sobald sich ein für die Darstellung der Karte relevanter Bestandteil ändert. Schritt 4 wird häufig durchgeführt, da er die Aktivitäten der Benutzer in der virtuellen Umgebung repräsentiert. Die Schritte 5 und 6 sind schließlich die Erzeugungsphase. Wann immer sich Informationen auf der Karte ändern, müssen diese Schritte ausgeführt werden.

Erkenntnis

Die aktive Karte löst das Problem durch die Kombination von zwei Vorteilen: Es reduziert Details, die im Kollaborationsbereich vorkommen und ist daher eine Abstraktion des konkreten Bereichs, inklusive Informationen zum Finden von Plätzen, Räumen und anderen Bestandteilen. Sie kombiniert diese reduzierte Ansicht mit Informationen über die Aktivitäten der anderen Benutzer und fördert somit das Gruppenbewusstsein.

Das Wahrnehmen der Standorte der anderen Benutzer erleichtert das Treffen mit ihnen an einem konkreten Ort durch das Navigieren zu der Position des anderen Benutzers. Dies kann auch dabei behilflich sein, kollidierende Aktivitäten zu vermeiden, indem zu einer Position navigiert wird, die aktuell nicht besetzt ist.

Die umfassendste Reihe von Studien, die sich mit der Nützlichkeit von aktiven Karten beschäftigt hatte, wurde von Gutwin und Greenberg (Gutwin and Greenberg, 1999) durchgeführt. Sie führten Experimente durch, in denen die Teilnehmer eine Konstruktionsaufgabe in einem zweidimensionalen, gemeinsam genutzten Arbeitsbereich erfüllen mussten. Teams mit aktiven Karten verrichteten ihre Aufgabe erheblich besser, in denen es darum ging, die Koordination zwischen den Teammitgliedern zu testen, wie zum Beispiel andere Teammitglieder durch den Arbeitsbereich zu führen. In ihrer Studie verglichen Gutwin und Greenberg auch die Unterschiede zwischen einer aktiven Karte mit einer Remote Field of Vision (4.5) und einer aktiven Karte, die lediglich die Topologie des Arbeitsbereichs und eine Local Field of View (auch als Übersicht bezeichnet) besitzt. Laut ihren Ergebnissen waren aktive Karten nützlicher, wenn eine Remote Field of View inbegriffen war.

Kontrolle

Wenn dieses Muster angewandt werden soll, sollten zuvor die folgenden Fragen geklärt werden:

  • Welche Bestandteile sind noch relevant, wenn der Kollaborationsbereich auf einem hohen Abstraktionsgrad betrachtet wird? Was wäre noch wichtig, wenn der Bereich mit großem Abstand betrachtet werden würde?
  • Wie sollen die Teile der Karte angeordnet werden? Macht es Sinn, einen automatisierten Layout Algorithmus zu verwenden? Falls ja, gibt es Eigenschaften des Bereichs, wie zum Beispiel hierarchische Raumstrukturen, die einen spezifischen Layout Algorithmus empfehlen?
  • Wie kann räumliche Konsistenz und Beständigkeit gewährleistet werden? Kann ein schrittweiser Layout Algorithmus angewendet werden, der nur neu hinzugefügte Bestandteile der Karte automatisch arrangiert?
  • Welche Bewusstseins-Informationen sollten der Karte hinzugefügt werden? Wieviele Benutzer sollten auf der Karte dargestellt werden?
  • Wie soll der Maßstab der Karte berechnet werden? Ist er fest oder dynamisch? Kann der Benutzer den Maßstab frei wählen?
  • Kann der Benutzer mit der Karte interagieren? Soll zum Beispiel ein Klick auf die Karte den Benutzer an die gewählte Position verschieben?

Gefahrenpunkte

Die Reduzierung der Details für die Karte könnte zu streng werden, zum Beispiel wenn Türen zwischen den Räumen entfernt werden. Dies resultiert in einer Situation, in der der wahrgenommene Bereich nicht mehr mit dem gezeigten Modell auf der Karte übereinstimmt.

Automatisierte Mechanismen für die Filterung und Anordnung der Besatndteile der Karte kann zu suboptimalen Darstellungen führen. Solche Mechanismen sollten nur als Werkzeug für die erste Skizze der Karte verwendet werden. Die finale Version der Karte benötigt eventuell manuelle Änderung durch die Benutzer.

Bekannte Nutzer

GIA (Group InterAction)(Manhart, 1999) war ein prototypisches System von DaimlerChrysler um die Interaktion kooperierenden Webseiten zu ermöglichen. Die kürzlich besuchten Seiten wurden in einer Kartenansicht geordnet, zusammen mit den aktuellen Benutzern an jedem der Bereiche. Es war möglich zwischen den Bereichen zu wechseln, indem man auf einen anderen Benutzer klickte, um diesem zu folgen.

College Town (Guernsey, 1996) verwendet Karten, um die Relationen zwischen Räumen zu erläutern und die räumliche Wahrnehmung zu verbessern.

COAST UML-Editor Der COAST UML-Editor http://www.opencoast.org/ zeigt Diagrammknoten in einer Radaransicht. Text und Details der Knoten wurden in dieser Ansicht weggelassen. Anstatt eines Knotens für eine Klasse oder eine Schnittstelle zeigt die Ansicht lediglich ein farbiges Rechteck.

Das Sichtfeld eines jeden Benutzers wird als farbiges Rechteck in der Farbe des Benutzers dargestellt.

Aus technischer Sicht wurde die aktive Karte als eine Instanz einer zusätzlichen Ansichtsklasse modelliert, die das gleiche gmeinsam genutzte Datenmodell nutze wie die Diagramm-Ansicht. Die Ansicht berechnete die Positionen einer Komponente neu und reduzierte deren Größe, um den gesamten Arbeitsbereich auf einem kleinen Schirm darstellen zu können. Die Instanz der aktiven Karte besitzt auch einen anderen Controller (UMLActiveMapController), der das Sichtfeld des lokalen Benutzers verschob, wenn dieser auf einen Punkt in der Radar-Ansicht klickte. Dies erleichterte die Navigation zum Sichtfeld eines anderen Benutzers.

Verwandte Muster

Annotated Scrollbar (Tidwell, 2006) beschäftigt sich damit, wie die lineare Struktur eines Dokuments zusammen mit einer Navigationsschnittstelle visualisiert werden kann. Die Scrolleiste dient in diesem Fall zwei Absichten: Sie zeigt eine lineare "Karte" des Inhalts sowie die aktuelle Position des Benutzers im Dokument. Angewendet auf den Kontext von Gruppensoftware sollte sie auch die Positionen von anderen Benutzern darstellen (wie es im Remote Field of Vision (4.5) Muster beschrieben wird).

Rgdk47 17:41, 22. Nov. 2010 (CET)

INTERACTION DIRECTORY

Alternativer Name: Service Directory

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
INTERACTION DIRECTORY

Absicht

Auflisten von potentiell zusammenhängenden Interaktionen.

Kontext

Benutzer interagieren in mehr als nur einem Kontext. Es gibt Interaktionen zwischen verschiedenen Benutzern über verschiedene Themen, an verschiedenen Orten, wobei verschiedene Tools benutzt werden.

Problem

Es ist schwierig bestehende Zusammenhänge zu finden um eine Interaktion zu starten und dabei ältere Zusammenhänge fortzusetzen.

Szenario

Nach dem ersten Erscheinen einer Spiele-Engine hat die Paul die Idee, eine virtuelle Konferenz zu starten, um über neue Richtungen für die Spiele-Engine zu diskutieren. Es sucht sich Moderatoren für spezielle Themen, wie Sound-Synthese oder künstliche Intelligenz und bittet sie, Sitzungen zu eröffnen. Aber es kommt niemand zu diesen Sitzungen. Paul und die anderen Moderatoren sind etwas enttäuscht, bis sie herausfinden, dass die anderen Entwickler nicht wussten, wann und wo diese Sitzungen stattfanden.

Symptome

Sie sollten in Erwägung ziehen, dieses Muster anzuwenden, wenn: - Benutzer zusammenarbeiten wollen, aber nicht wissen, wo und wie sie den benötigten Kontext finden. - Benutzer ihre Interaktionen unterbrechen und fortsetzen wollen, nachdem sie in anderen Kontexten gearbeitet haben.

Lösung

Stellen sie einen gemeinschaftlichen Bereich zur Verfügung, welcher für alle Nutzer zugänglich ist und wo die Nutzer ihre Interaktionskontexte speichern und wieder aufnehmen können.

Dynamik

Benuzter betreten einen gemeinschaftlichen Bereich, wo sie ihre Interaktionskontexte beschreiben können, oder die von anderen durchsuchen können. Um das durchsuchen zu unterstützen, sollten die Kontexte mit Metadaten versehen werden und eine kurze Beschreibung abrufbar sein. Beides sollte von dem Nutzer angelegt werden, der den Kontext erstellt hat.

Erkenntnis

In dem gemeinschaftlichen Bereich erhalten die Benutzer Informationen über bestehende Kontexte oder können ihre eigenen Kontexte anlegen und beschreiben. Sie haben nun die Möglichkeit Interaktionen aufzubauen.

Kontrolle

Beim Benutzen dieses Musters sollten sie sich folgende Fragen stellen:

  • Was ist ihr Kontext?
  • Welche Art von Metadaten müssen die Nutzer zur Verfügung stellen?
  • Wie sollte die Beschreibung für den Kontext erstellt werden? Automatisch generiert durch das beschriebene Objekt, oder vom Nutzer selbst?
  • Wie sollte man den gemeinschaftlichen Bereich aufbauen?
  • Sollen Kontexte nach einer gewissen Zeit entfernt werden?
  • Wollen sie Zugangsberechtigungen für den gemeinschaftlichen Bereich benutzen?

Gefahrenpunkte

In zu großen Verzeichnissen kann es schwer werden, den gewünschten Kontext zu finden, auch mit einer Suchfunktion. Um dieses Problem zu umgehen, sollten die Kontexte kategorisiert werden, was dem Benutzer hilft, die Suche einzugrenzen.

Bekannte Nutzer

CURE (Haake et al., 2003b) ist ein Web-basiertes System für gemeinschaftliche Arbeitsbereiche. Es basiert auf Rooms, um die Zusammenarbeit zu organisieren.

DreamTeam (Roth, 2000a) ist eine Entwicklungsplattform für synchrone Groupware. DreamTeam bietet eine Laufzeitumgebung für Collabroative Sessions. Es bietet zudem ein Sitzungsverzeichnis mit allen verfügbaren Sitzungen und deren aktuellem Status.

Yahoo groups erlaubt es dem Benutzer nach allen verfügbaren Gruppen zu suchen. Yahoo kategorisiert die Gruppen zudem und bietet eine Beschreibung der Gruppen, sowie die Suche nach Schlüsselwörtern, um die gewünschte Gruppe schneller zu finden.

Verwandte Muster

Collaborative Session
Forum
Room
Active Map
Shared File Repository


Dlgn63 13:08, 22. Nov. 2010 (CET)

BELL

Alternativer Name: Door Knocker

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
BELL

Absicht

Informiere Sitzungsteilnehmer, wenn ein Benutzer teilnehmen möchte.

Kontext

Sie haben eine Zusammenarbeit zwischen mehreren Benutzern eingerichtet, zum Beispiel mit dem Collaborative Sessions Muster, oder dem Rooms Muster. Nun sind sie besorgt, wie Zuspätkommende in diese Sitzung einsteigen können.

Problem

Wenn zuspätkommende Benutzer einer zusammenarbeitende Gruppe beitreten wollen, kann die Gruppe von nicht erwünschten Teilnehmern gestört werden, oder sie merken nicht, dass jemand teilnehmen möchte.

Szenario

Paul und Charley arbeiten zusammen mit einem Shared Editor, um eine neue Version des Message Digest Algorithmus zu implementieren, der zur Authentifizierung genutzt wird. John, ein weiterer Sicherheitsexperte würde gerne mitarbeiten, weiß aber nicht, wie er an der Gruppe teilnehmen kann.

Symptome

Sie sollten in Erwägung ziehen, dieses Muster anzuwenden, wenn:

  • Sie haben Gruppeninteraktionen als Ereignis mit Zugangskontrolle aufgebaut.
  • Sie nicht davon ausgehen können, dass alle Teilnehmer von Beginn an an der Gruppeninteraktion teilnehmen können.

Lösung

Bieten sie einen Treffpunkt mit einer Klingel an, wo Benutzer auf sich aufmerksam machen können, wenn sie an einer Gruppe teilnehmen möchten.

Dynamik

Eine Gruppe von Benutzern trifft sich in einer Sitzung, um über freigegebene Gegenstände zu diskutieren, oder an ihnen zu arbeiten. Die Sitzung garantiert die Ungestörtheit vom Rest der Welt. Ein Benutzer, weiß wo die Gruppe zu finden ist und möchte teilnehmen. Er kann somit die Klingel betätigen, was den anderen Teilnehmern signalisiert, dass jemand teilnehmen möchte und sie können entscheiden, ob er das darf. Der Benutzer wird über die Entscheidung informiert und darf gegebenenfalls teilnehmen.

Erkenntnis

Das Bell-Muster ist modelliert einen Interaktions-Grundsatz, der aus dem reellen Leben bekannt ist.

Kontrolle

Beim Benutzen dieses Musters sollten sie sich folgende Fragen stellen:

  • Wie soll die Klingel aussehen? Soll sie sehr auffällig sein, wie bei einem Ton der abgespielt wird, oder weniger auffällig, zum Beispiel in Form einer E-Mail?
  • Wie lang sollte der zuspätkommende Benutzer auf eine Reaktion der Gruppe warten?
  • Wie sollen die Reaktionen der Gruppe auf das Klingel angezeigt werden?

Gefahrenpunkte

In vielen Fällen ist es nicht einfach, den Einstiegspunkt zu einer Sitzung zu finden. Eine Liste mit allen zur Zeit laufenenden Sitzungen kann da Abhilfe schaffen.

Bekannte Nutzer

ISDN
Die Deutsche Telekom erlaubt den Kunden Telefonkonferenzen. Der Zuspätkommende macht sich beim Eröffner der Konferenz mit einem Signalton bemerkbar. Der Eröffner kann sich nun mit dem Zuspätkommenden unterhalten und entscheiden, ob er der Konferenz beitreten darf, oder nicht.

NetMeeting
Die NetMeeting Anwendung von Microsoft verwendet das Bell-Muster um zu signalisieren, dass ein Benutzer an einer laufenden Sitzung teilnehmen möchte.

FUB (Haake und Schümmer, 2003) (Haake et al., 2003a) listet alle Collaborative Sessions in einer Sitzungsliste auf. Benuzter können Teilnehmer fragen, ob sie teilnehmen dürfen, oder nicht.

Verwandte Muster

Collaborative Session und Rooms benutzen Bells um Zutritt anzufordern.

Availability Status

Invitation

Interaction Directory

Dlgn63 13:08, 22. Nov. 2010 (CET)

INVITATION

Absicht

Erlaube Benutzern eine Interaktion mit anderen zu planen.

Kontext

Sie wollen zusammenarbeiten.

Problem

Ein Benutzer möchte mit einem anderen zusammenarbeiten. Die anderen Benutzer könnten nicht verfügbar sein, oder sie sind in anderen Bereichen beschäftigt, so dass sie eine sofortige Zusammenarbeit stören würde.

Szenario

Maurice will mit Charley an einem Sicherheitsfeature für den VRML Exporter arbeiten. Er denkt, dass eine enge Zusammenarbeit angebracht wäre. Es besteht immernoch ein Link zu einer geteilten Anwendung mit Charley. Er öffnet seine Entwicklungsumgebung und sieht sofort Charleys Bildschirm. Er weiß jedoch nicht, dass Charley gerade eine Präsentation vor einem wichtigen Kunden hält. Das sich öffnende Fenster stört die Präsentation mit dem Ergebnis, dass der Kunde nicht von Charley Ideen beigeistert ist. Charley beschließt, keine geteilten Anwendungen mehr offen zu lassen und will nicht mehr mit Maurice zusammenarbeiten.

Symptome

Sie sollten in Erwägung ziehen, dieses Muster anzuwenden, wenn:

  • Benutzer wollen synchron zusammenarbeiten, wissen aber nicht, wie sie solch eine Sitzung planen können.
  • Ein Benutzer möchte mit einem anderen zusammenarbeiten, aber weiß nicht, wie er ihm das mitteilen kann.
  • Benutzer können einer Sitzung nicht zugezogen werden, wenn sie bereits andere Dinge zu tun haben.
  • Eine geplante Interaktion setzt es vorraus, dass sich die Benutzer über eine längere Zeitspanne mit ihr beschäftigen.

Lösung

Senden und verfolgen sie Einladungen zu den beabsichtigten Teilnehmern. Fügen sie der beabsichtigten Collaborative Session Metadaten hinzu. Fügen sie automatisch alle Benutzer, welche die Einladung akzeptieren zur Collaborative Session hinzu.

Dynamik

Der Benutzer, der eine Sitzung plant, legt ein Invitation Objekt an, welches alle wichtigen Meta-Informationen über die Collaborative Session enthält. Diese wird an alle beabsichtigten Teilnehmer gesendet. Für langfristige Einladung kann eine E-Mail versendet werden, für kurzfristige eine Kurznachricht. Jeder Benutzer erhält diese und kann die Einladung annehmen, oder ablehnen. Vor dem Start der Sitzung werden alle Benutzer die angenommen haben nochmals erinnert.

Erkenntnis

Das Muster modelliert eine bekannte kulturelle Interaktion: Ein Benutzer oder eine Gruppe lädt andere Benutzer ein, teilzunehmen. Der Eingeladene kann die Einladung annehmen oder ablehnen.

Kontrolle

Beim Benutzen dieses Musters sollten sie sich folgende Fragen stellen:

  • Ist das Datum der Sitzung wichtig, oder werden nur Einladungen für Sitzungen versendet, die dabei sind zu starten?
  • Können sie eine Verbindung zum Kalender-Werkzeug des Benutzers herstellen, damit er es einfacher hat, die Einladungen zu verfolgen?
  • Können sie verschiedene Kommunikationsmöglichkeiten auswählen, basierend auf der Verfügbarkeit des Benutzers, zum Beispiel Sofortnachrichten, wenn der Benutzer verfügbar ist.
  • Dürfen sie die anderen Teilnehmer in der Einladung nennen? Wie sollten sie diese Anzeigen? (USER LIST)
  • Können sie der Einladung eine Verknüpfung zum Ort des Meetings hinzufügen?
  • Was passiert, wenn zu viele Benutzer die Einladung ablehnen? Werden die anderen Benutzer informiert?
  • Wie sollte die Erinnerung an die Sitzung aussehen? Ist eine E-Mail ausreichend, oder sollten Kurznachrichten verwendet werden?
  • Wollen sie Einladungen für Benutzer unterstützen, die noch nicht Teil der Community sind? Wenn ja, wie sollten diese Benutzer informiert werden? Denken sie auch über eine QUICK REGISTRATION nach, wenn die Benutzer die Einladung akzeptieren.

Gefahrenpunkte

Es kann schwer sein, vorauszusagen, wann ein Benutzer die Einladung zur Kenntnis nimmt. Der einladende Benutzer könnte annehmen, dass der Eingeladene sofort auf die Einladung reagiert. Eine USER LIST kann dem einladenden Benutzer helfen vorauszusehen, wann seine Einladung zur Kenntnis genommen wird.
Benutzer könnten befürchten, dass es als unhöflich angesehen wird, eine Einladung abzulehnen. Sie sollten die Möglichkeit haben, sich zu äußern, warum sie die Einladung ablehnen.

Bekannte Nutzer

FUB (Haake und Schümmer, 2003)
Google Docs (http://docs.google.com/)
DreamTeam

Verwandte Muster

Bell

Blind Date

Collaborative Session und Rooms benutzen Invitations um andere Nutzer zur Teilnahme einzuladen.

User List

Interactive User Info

Quick Registration

Dlgn63 13:09, 22. Nov. 2010 (CET)

BLIND DATE

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
BLIND DATE

Absicht

Es soll hiermit die Gruppenbildung für aufgaben-orientierte Gruppen vereinfacht werden.

Kontext

Das System besteht aus Aufgaben, die von einer Gruppe von Benutzern gelöst werden muss.

Problem

Wenn Aufgaben in Zusammenarbeit mit mehreren Benutzern gelöst werden müssen, dann müssen mindestens zwei Benutzer miteinander interagieren. Schwierig wird es geeignete Benutzer zu finden, wenn die Benutzer selbst nicht wissen, wer alles beteiligt ist.

Szenario

Marc will eine neue Aufgabe auf einer Visualisierungs-Engine starten. Er ist ein Fan von Paar- Programmierung und sucht daher nach einem geeigneten Peer. Allerdings ist dies komplizierter, als er zunächst dachte: Juan ist derzeit mit einer anderen Aufgabe beschäftigt und Carla ist im Urlaub, während Rodrigo nicht erreicht werden kann. Nach dem dritten Versuch versucht Marc nicht noch weitere Partner zu erreichen und entscheidet sich etwas anderes zu tun. Er wusste aber nicht, dass Janet gerne mit ihm gearbeitet hätte.

Symptome

Dieses Muster sollte also verwendet werden wenn,

  • die Gruppe homogen ist, so dass verschiedene Benutzer gemeinsam eine Aufgabe lösen können.
  • die Notwendigkeit für eine Zusammenarbeit von Benutzern mit spezifischen Erfahrungen besteht

Lösung

Die Erstellung eines Meeting-Bereichs für die Aufgabe, die kooperativ gelöst werden muss und wo die Anwender ihr Interesse an der Aufgabe mitteilen können. Alle interessierten Anwender werden informiert, wenn genug Nutzer im Meeting-Bereich existieren. Anschließend kann eine COLLABORATIVE SESSION gestartet werden.

Dynamik

Ein Benutzer navigiert zu dem Meeting-Bereich, welcher eine Beschreibung der Aufgabe ist. In den meistenFällen bezieht sich dies auf einen bestimmten Kontexts einer Anwendung. Im Kontext einer Unterstützung von verteilten eXtreme-Programming, könnte eine vereinfachte Aufgabe sein, die Entwicklung des Systems mit einem Peer fortzusetzen. Wenn ein Benutzer sich entscheidet eine Aufgabe zu bearbeiten, dann erstelle er im Meeting-Bereich ein VIRTUAL ME. Technisch gesehen wird der Benutzer in eine Liste von bereiten Benutzern eingereiht. Wenn genügend Benutzer in der Liste vorhanden sind, startet das System eine COLLABORATIVE SESSION und fügt alle Benutzer der Session hinzu.

Begründung

Verglichen mit anderen Formen der Gruppenbildung, in der die Gruppen ihre Benutzer hinsichtlich ihrer Persönlichkeit oder ihrer Einsatzmöglichkeiten wählen, bringt BLIND DATE Benutzer zusammen mit der Fähigkeit, eine bestimmte Aufgabe zu einem bestimmten Zeitpunkt zu lösen. Dadurch wird sichergestellt, dass die Gruppe so schnell wie möglich gebildet wird. Voraussetzung hierfür ist, dass alle Benutzer, die bereit sind sich an der Aufgabe zu beteiligen, eine klare Darstellung ihre speziellen Fähigkeiten im Meeting-Bereich gemacht haben. Die Benutzer müssen sich nicht im Voraus kenn. Die Benutzer werden somit ermutigt, neue Kontakte knüpfen. Da alle ein gemeinsames Ziel habe, erleichtert sich die Gruppenbildung.

Check

Sollte dieses Muster angewandt werde, so sollten diese Fragen beantwortet werden:

  • Wie sollte der Meeting-Bereich aussehen bzw. aufgebaut sein?
  • Wie sollte die interessierten Benutzer einer Aufgabe dargestellt werden? Sollen sie für jeden sichtbar sein, oder nur für die Benutzer, die ein gemeinsames Arbeitsinteresse haben.
  • Soll eine COLLABORATIVE SESSION sofort gestartet werden, sobald mehrere Benutzer verfügbar sind oder soll die Benutzer nur darüber informiert werden und selbst entscheiden, ob die Gruppe vollständig gebildet wurde.

Gefahrenpunkte

Wenn es sehr lange dauert, dass Benutzer dem Meeting-Bereich beitreten, dann kann es sein, dass sie ihre Interessenbeschreibung vergessen haben. Man könnte sich also überlegen, die Interessen auf der Benutzeroberfläche darzustellen. Desweiteren könnten die Benutzer ihr Interesse an der Aufgabe verlieren, wenn die Gruppenbildung zu lange dauert. Es gibt keine Garantie, dass die Gruppe gut funktioniert. Es muss auch eine Möglichkeit geben, die Gruppe wieder zu verlassen. Der Benutzer müsste dann für eine Ersatzperson sorgen.

Bekannte Nutzer

  • World of Warcraft
  • L3

Verwandte Muster

  • Birds of a Feather
  • Invitation
  • Bell
  • Collaborative Session
  • Interaction Directory

Cptr07 12:46, 22. Nov. 2010 (CET)

How to Support Textual Communication

Deutsch: Wie man Text-Nachrichten unterstutzt.

EMBEDDED CHAT

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
EMBEDDED CHAT

Absicht

Den Benutzern wird erlaubt, synchron zu kommunizieren mit geringer technischer Unterstützung.

Kontext

Die Benutzer verwenden ein Groupware-System wie beispielsweise eine kollaborative Anwendung oder ein Community-System.

Problem

Die Nutzer müssen kommunizieren. Sie neigen dazu, E-Mails zu versenden. Aber da E-Mails von Natur aus asynchron sind, dauert es oft zu lange bis Probleme gelöst werden.

Szenario

Juan und Carla entwickeln gemeinsam eine Grafik-Engine. Sie sich für eine Paar-Programmierung getroffen und teilen die gleichen Quellcode, so dass beide den Code ändern und auch sofort sehen können, was der andere Entwickler geändert hat. Sie müssen über die Änderungen diskutieren, ihnen fehlt aber eine Sprachkommunikation. Juan verwendet ein Instant-Messaging-Tool von einem bekannten Messaging-Service-Provider. Leider hat Carla ein Instant-Messaging-Tool bei einem anderen Anbieter. Also funktioniert das auch nicht. Schließlich schreiben beide ihre Nachrichten in den Quellcode, aber keiner von ihnen wirklich zufrieden mit dieser Lösung.

Symptome

Dieses Muster sollte also verwendet werden wenn,

  • die asynchrone Kommunikation zu lange dauert
  • das verbale Erklären von Sachen wie Webadressen oder Kontaktdaten zu schwierig und fehleranfällig ist
  • die Benutzer verschiedene Tool für die Kommunikation benutzen

Lösung

Integrieren Sie ein Werkzeug zur schnellen synchronen Interaktion in ihre Anwendung. Lassen Sie den Nutzer kurze Textnachrichten versenden, verteilen diese Nachrichten sofort an alle anderen Mitglieder der Gruppe und zeigen diese Meldungen jedem Mitglied der Gruppe an.

Dynamik

Für die Integration eines Chats in einem Groupware-System, sind mindestens drei Textfelder auf der Benutzeroberfläche notwendig. In einem dieser Textfelder können die lokalen Benutzer eine Nachricht eingeben, ein anderes zeigt das Gespräch, und das letzte enthält eine Benutzerliste.

Begründung

Durch die Einbettung eines Chats in ein Groupware-System, können die Benutzer durch Nachrichten kommunizieren, um somit den Austausch von Informationen zu vereinfachen.

Check

Sollte dieses Muster angewandt werden, so sollten diese Fragen beantwortet werden:

  • Soll ein eigener oder eine bereits vorhandener Chat in das System integriert werden
  • Wo soll der Chat auf der Benutzeroberfläche integriert werden

Gefahrenpunkte

Die Benutzer verwenden meist unterschiedliche Chat-Tools zur Kommunikation. Das macht es schwierig ein neuen Chat-Tool zu verwenden, weil sich die Anwender von der vertrauten Umgebung und den bestehenden Kontakten ungern trennen wollen.

Bekannte Nutzer

  • Eclipse (IRC-plugin)
  • CURE
  • XING
  • Star Wars Galaxies

Verwandte Muster

  • Digital Emotions
  • Quality Inspection
  • Floor Control
  • Activity Indicator
  • User List
  • Persistent Session
  • Virtual Me

Cptr07 12:47, 22. Nov. 2010 (CET)

FORUM

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
FORUM

Absicht

Bereitstellung für eine persistente asynchrone Kommunikation in der Gruppe.

Kontext

Die Benutzer möchten im Rahmen einer Community kommunizieren.

Problem

Die Benutzer möchten zu einem bestimmten Thema kommunizieren. Aber ohne zu wissen, welche Benutzer das gleiche Thema interessiert, ist dies schwierig.

Szenario

Martin, ein Experte in der Computer-Unterstützten Lerngruppe, wollte neue Anwendungsbereiche für eine Spiel-Engine diskutieren. Er ist überzeugt, dass dies verwendet werden könnte, um verschiedene Spiele für die öffentliche Bildung zu erschaffen.Er weiß auch, dass es andere Community-Mitglieder wie Weigang und Molo gibt, die vielleicht an einer solchen Diskussion interessiert sein könnten. Sie per E-Mail anzuschreiben oder sich mit ihnen zusammen in einen Raum zu setzen, würde die Teilnehmer auch nur beschränken auf die Leute die Martin schon kennt.

Symptome

Dieses Muster sollte also verwendet werden wenn,

  • Benutzer Nachrichten von vielen Communities über die gleiche E-Mail Adresse erhalten
  • Benutzer vergessen, Gruppenmitglieder in die Liste der Empfänger hinzu zufügen
  • Benutzer Probleme haben, Nachrichten einem Kontext zu zuordnen
  • Benutzer Probleme haben, in der Gruppeninteraktion auf Nachrichten zu beziehen
  • man erlauben möchte „Zu-Spät-Kommern“ an der Kommunikation teilzunehmen
  • man Gruppen anhand der Themen und nicht den Personen bilden möchte

Lösung

Erstellen Sie ein Forum als zentralen Ort für Kommunikation, in der alle Gruppenmitglieder durch das Lesen und Schreiben von Mitteilungen asynchron diskutieren können. Mann muss die Forum-Nachrichten persistent halten.

Dynamik

Um ein Forum zu erstellen muss ein zentraler Server eingerichtet werden, die leicht von allen benutzt werden kann. Die Benutzer müssen in der Lage sein, ihre eigenen Foren auf dem Server zu erstellen. Der Server verfügt über ein Verzeichnis aller verfügbaren Foren und Nutzer müssen diese Liste durchsuchen können.

Begründung

Als Benutzer kann die Liste der verfügbaren Foren durchsucht und auch neue Foren erstellt werden. Der zentrale Server hält alle Nachrichten persistent. Neue Mitglieder können also auch eine Diskussion verstehen, die bereits von einem Benutzer angelegt wurde. Benutzer können ihre eigenen Nachrichten in einem Forum postenoder Antworten auf bereits vorhandene Einträgen geben.

Check

Sollte dieses Muster angewandt werden, so sollten diese Fragen beantwortet werden:

  • Wie können die Benutzer auf das Forum zugreifen
  • Wie lassen sich die Foren kategorisieren
  • Wie lässt sich die Kommunikation zwischen den Benutzern und dem zentralen Server realisieren
  • Werden Fremden das Lesen der Forumsnachrichten erlaubt

Gefahrenpunkte

Die Benutzer können nicht ständig das Forum ihrer Community kontrollieren und überprüfen. Wenn möglich, sollte es dem Benutzer des Forums erlaubt werden, seine bevorzugte Anwendung für die asynchrone Kommunikation zu benutzen. Man will meistens keine zusätzliche Software verwenden, um auf das Forum zugreifen zu können.

Bekannte Nutzer

  • USENET
  • Yahoo Groups

Verwandte Muster

  • Feedback Loop
  • Interaction Directory
  • FAQ
  • Quality Inspection
  • Threaded Discussions
  • Periodic Report
  • Change Indicator
  • Embedded Chat
  • Message Board
  • e-Forum


Cptr07 12:47, 22. Nov. 2010 (CET)

THREADED DISCUSSIONS

Alternativer Name: Conversations Threading

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
THREADED DISCUSSIONS

Absicht

Beiträge zu einer Diskussion in Threads strukturieren

Context

Benutzerbeiträge in einem textbasierten Nachrichtenkanal wie etwa ein Forum

Problem

Schriftliche Kommunikation über den Computer ist meist nicht linear. Leute beziehen sich auf Beiträge von anderen Leuten so dass, zwischen dem ursprünglichen Beitrag und den Antworten der anderen Leute Beiträge dazwischen sind die die Diskussion in eine andere Richtung lenken. Das führt zu schwer verständlichen und verschachtelten Diskussionen.

Szenario

Martins Initiative zur Besprechung von unterschiedlichen Anwendungsgebieten von Spieleengines zeigt großes Interesse. Mehr als zwanzig Testbenutzer haben über achtzig neue Ideen für Spiele eingestellt. Leider hat Martin nur ein einfaches Forum. Durch so viele Beiträge wird es immer schwerer die einzelnen Diskussionen auseinander zu halten. Deshalb werden einige Ideen nicht beachtet.

Symptome

Überlegungen zur Anwendung dieses Musters sollten erfolgen wenn:

  • Ein Konversationsraum wird benutzt um mehrere unterschiedliche Themen gleichzeitig zu erörtern.
  • Benutzer entscheiden selbst welche Themen besprochen werden.
  • Missverständnisse zwischen Benutzern wegen falscher Hinweise im Gespräch

Lösung

Aufspüren und Anzeigen der Zusammenhänge zwischen den einzelnen Beiträgen

Dynamik

Wenn ein Benutzer eine Antwort verfasst spürt das System den Beitrag auf zu welchem die Antwort gehört. Ein Weg dies zu realisieren ist es dem Benutzer einen „Antwort“ Button zur Verfügung zu stellen welcher angibt dass die neue Antwort zu dem gerade angezeigten Thema gehört. In der synchronen Interaktion kann Bezug auf den letzten Beitrag vor der Antwort des Benutzers genommen werden. Wenn der Benutzer den Beitrag für die anderen Benutzer freigibt hat der Beitrag einen Verweis auf seinen vorherigen Beitrag (parent). Andere Benutzer sehen die neue Antwort (child) in einer Baumstruktur. Beiträge die keinen Verweis auf andere Beiträge haben sind Ursprünge für neue Threads. Auf der Benutzeroberfläche wird der Baum durch einen Tree Table dargestellt durch den der Benutzer navigieren kann.

Begründung

Threads helfen Benutzern einzelne Themen und Beiträge gefiltert anzuzeigen so dass der Benutzer sich auf ein Thema konzentrieren kann.

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Wie können Verweise aufgedeckt werden? Gibt es einen eingebauten Verweismechanismus um Kommunikationsprotokoll?
  • Wie soll es dem Benutzer ermöglicht werden Verweise auf Beiträge zu bilden? Werden die Verweise explizit oder durch die Benutzeraktionen gebildet?

Gefahrenpunkte

Das Aufspüren von neuen Beiträgen kann kompliziert werden. Deshalb sollte sichergestellt werden das neue Beiträge hervorgehoben werden. Zum Beispiel durch die Benutzung von Change Indicator. Alternativ kann es dem Benutzer erlaubt sein zwischen der Chronologischen und der Thread Ansicht hin und her zu wechseln.

Bekannte Nutzer

  • USENET

Wenn der Klient eine Antwort für eine Nachrichtengruppe verfasst, hängt der „news reader“ einen Verweis auf den Elternbeitrag in den Header an.

  • E-mail

Ursprünglich enthalten E-Mails keine Verweise oder Informationen auf vorherige E-Mails. Das ist ein Grund warum Klients die E-Mails nicht in Threads darstellen können. Um es dennoch zu ermöglichen bekommt jede E-Mail eine eindeutige ID die es dem Klient ermöglicht einen Baum von Eltern und Kind E-Mails aufzubauen.

  • KOLUMBUS 2

KOLUMBUS 2 ist eine gemeinschaftliche Lernumgebung, die Inhaltsbezogene Kommunikation mit Anmerkungen unterstützt. Kommuniziert wird über Anmerkungen zu Materialien oder zu anderen Anmerkungen. Indem man Anmerkungen kommentiert, werden Diskussion Gewinde entwickelt.

  • Chat Systems

In dem Kontext der Chat Konversationen haben einige System die Darstellung der Beiträge erforscht. Eins der frühesten Systeme war Threaded Chat (Smith et al., 2000). Das Problem hierbei ist es einzelne Nachrichten anderen Nachrichten zuzuordnen. Um eine neue Nachricht zu erstellen müssen die Benutzer eine vorherige Nachricht auswählen. Diese wird dann zum Elternteil der neuen Nachricht. Direkt nach dem selektieren des Elternteils wird für alle anderen Benutzer sichtbar das gerade einen neue Nachricht verfasst wird. Die Erfinder von Threaded Chat haben erkannt das es schwer ist neue Nachrichten zu erkennen. Deshalb werden neuen Nachrichten hervorgehoben.

Verwandte Muster

Implementierung in eStudy

In eStudy gibt es ein Forum welches es ermöglicht strukturierte Beiträge anzulegen.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Wngr74 12:50, 22. Nov. 2010 (CET)

FLAG

Alternativer Name: Flagged Messages

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
FLAG

Absicht

Benutze Kennzeichner um wichtige Inhalte zu markieren.

Context

Benutzer interagieren zusammen in einem Bereich wie etwa einem Forum oder Raum. Teile in diesem Bereich werden mit Text beschriftet.

Problem

Es ist schwer unwichtige und wichtige Inhalte zu unterscheiden da beide nur mit Text beschriftet werden.

Szenario

Charley schaut schon wieder nach Fehlern in der Spieleengine. Immer wenn er einen Fehler findet schickt er eine Nachricht an das Entwicklerteam. Da Charley schon eine menge Fehler gefunden hat, hat Paul keine Übersicht mehr darüber welche Fehler schon behandelt wurden und welche neu sind.

Symptome

Überlegungen zur Anwendung dieses Musters sollten erfolgen wenn:

  • Benutzer müssen Teile aufspüren können
  • Der gemeinsame Arbeitsraum enthält viele Teilbereiche und die Benutzer haben Probleme wichtige Teile zu finden.
  • Benutzer brauchen viel Zeit um die wichtigen von den unwichtigen Teilen zu trennen.

Lösung

Ermögliche es Benutzern wichtige Teile zu markieren. Zeige die Markierungen so an das markierte Teile später schnell gefunden werden.

Dynamik

Benutzer markieren einen Teil und kennzeichnen ihn. Der markierte Teil soll sich sichtlich von den nicht markierten Teilen abheben. Etwa durch Icons oder verschiedenen Farben. Einige Kennzeichen werden benutzt um Interaktion mit dem System auszudrücken. Ein Beispiel dafür ist das „Neue Nachricht“ Icon. Es wird gelöscht sobald der Benutzer die Nachricht gelesen hat. Andere Zeichen drücken generelle Werte aus. Um eine erhöhte Klassifizierung zu ermöglichen sollten die Benutzer ihre eigenen Icons ins System einbringen können. Wenn nach Teilen gesucht wird kann das System nach speziellen Icons durchsucht werden.

Begründung

Die Markierungen dienen als Anzeige und Filtermöglichkeit. Es hilft den Benutzer sich auf wichtige Teile zu konzentrieren. Es ist auch sehr nützlich um Benutzer auf bestimmte wichtige Teile hinzuweisen.

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Wie werden die Markierungen gespeichert? Können sie zu dem Artefakt als ein Attribut hinzugefügt werden oder muss ein Proxy Object erzeugt werden welches die Markierung für das spezielle Artefakt speichert?
  • Ist es sinnvoll eine gemeinsame Markierung zu benutzen oder macht es mehr Sinn persönliche Markierungen einzufügen?

Gefahrenpunkte

Stell sicher das markierte Teile hervorgehoben und sortiert werden können so wie sie beschriftet sind. Begrenze die Anzahl an Markierungsmöglichkeiten um dem Benutzer die Auswahl zu erleichtern. Das Kennzeichen von einzelnen Teilen kann Zeitraubend sein, deshalb sollte versucht werden die Kennzeichnung automatisch durchzuführen etwa durch Filtern des Textes wie in Attention Screen beschrieben.

Bekannte Nutzer

  • IMAP Message Flags

Das The Internet Message Access Protocol definiert wie E-Mails auf dem zentralen Server gespeichert werden. Jede E-Mail kann mit einem oder mehreren Markierungen gekennzeichnet werden. Der Klient kann die Markierungen zu jeder E-Mail setzen und der Server speichert die neue Markierung.

  • ToDo Messages in Eclipse

Die Eclipse Programmierumgebung ermöglicht es den Benutzern verschiedene Aufgaben unterschiedlich zu Markieren. In Eclipse werden Text Markierungen benutzt. Ein Beispiel hierfür ist die FIXME Kennzeichnung. //FIXME: Generate Error Message In Eclispe wird die Markierung auch rechts am Scrollbalken angezeigt. Da Eclipse Team basiertes Programmieren ermöglicht werden die einzelnen Markierungen für das ganze Team sichtbar.

Verwandte Muster

Implementierung in eStudy

In eStudy werden in den Foren wichtige oder neue Threads durch Icons dargestellt. Dabei hat jedes Icon eine eindeutige Bedeutung. Auch beim Nachrichtenversand und -empfang werden Icons benutzt.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Wngr74 12:58, 22. Nov. 2010 (CET)

SHARED ANNOTATION

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
SHARED ANNOTATION

Absicht

Stell Mittel zum teilen von Kommentare zu spezifische Inhalte zur Verfügung.

Context

Benutzer teilen sich Bereiche. Jeder Bereich wurden von einem Autor oder einer Gruppe von Autoren erstellt die für die Leser eindeutig sind.

Problem

Mitglieder einer Gruppe wollen Einfluss darauf haben wie sich ein Produkt entwickelt oder von der Gruppe wahrgenommen wird.

Szenario

Während Ana Charley’s Quellcode liest hat sie jede Menge Ideen und Vorschläge. Sie notiert sie auf einem Blatt Papier ist sich aber nicht sicher wie sie es umsetzen soll. Sie bedauert auch das die anderen Gruppenmitglieder ihre Notizen nicht sehen können.

Symptome

Überlegungen zur Anwendung dieses Musters sollten erfolgen wenn:

  • Benutzer diskutieren über einen bestimmten Bereich im Quellcode haben aber Probleme sich auf spezielle Teile im Quellcode zu beziehen.
  • Benutzer stellen dem Autor immer wieder die gleiche Frage.
  • Die Gruppen Mitglieder haben unterschiedliche Meinungen zu einen speziellen Thema, aber die unterschiedlichen Meinungen sind nicht im gemeinsamen Arbeitsraum verknüpft, dass macht es schwer alternative Möglichkeiten zu finden.

Lösung

Stell Mittel zum Eintragen von Kommentaren zu spezifischen Inhalten zur Verfügung und stelle alle Kommentare mit dem spezifischen Inhalten da.

Dynamik

Das Muster ist in zwei Phasen unterteilt. Dem erstellen der Anmerkung zu den spezifischen Inhalten und das Darstellen dieser Anmerkung mit dem spezifischen Inhalt. Um eine Anmerkung zu erstellen musst der Benutzer den Teil markieren zu dem er die Anmerkung schreiben will. Dann selektiert der Benutzer die „Kommentar hinzufügen“ Funktion und gibt sein Kommentar ein. Der Kommentar wird dann in einem gemeinsamen Repository gespeichert (s. Centralized Objects). Der Kommentar besteht aus einem Verweis auf den spezifischen Inhalt und einer Positionsangabe innerhalb des Inhaltes sowie dem eigentlichen Kommentar, einer Identifikation des Benutzers und manchmal auch einen Zeitstempel. Beim Anschauen wird dann zuerst das ursprüngliche Dokument geladen und im Anschluss alle Anmerkungen zu diesem Dokument. Die Anmerkungen werden im Dokument dann farblich hervorgehoben.

Begründung

Der Vorteil bei dieser Methode ist dass das ursprüngliche Dokument nicht verändert wird und dennoch können Benutzer unterschiedliche Ansichten zu dem Inhalt des Dokuments ausdrücken. Kommentare können verschiedene Rollen spielen:

  • Ein Kommentar kann weitere Schritte in einem Projekt koordinieren und die Haltung der Gruppe verändern
  • Ein Eindruck aus Sicht eines Experten
  • Eine Erklärung zu Änderungen im Dokument

Es wird dem Benutzer erlaubt spezielle Bereiche im Dokument zu Kommentieren. Was einige Risiken birgt.

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Wie kann der Verweis auf das Dokument modelliert werden? Kann direkt ein Objektverweis benutzt werden oder doch eher ein Proxy Objekt?
  • Wo werden die Kommentare gespeichert?

Gibt es Anwendungen die das ursprüngliche Dokument und die Kommentare zusammenfügen?

Gefahrenpunkte

Einige Benutzer wollen nicht alle Kommentare der ganzen Gruppe zugänglich machen. Deshalb sollte das System zwischen privaten, gemeinsamen und öffentlichen Kommentaren unterscheiden. Die privaten Kommentare sind für den Benutzer. Die gemeinsamen Kommentare für die ganze Gruppe und die öffentlichen Kommentare für Außenstehende. Um die einzelnen Kommentarebenen zu trennen werden Kennungen eingesetzt die die Sichtbarkeit des Kommentars festlegen. Die Kommentare können sehr lang werden deshalb sollten sie aus- und einklappbar sein. Es können Probleme auftreten wenn sich der Text in einem Dokument ändert und die Kommentarpositionen nicht mehr zum Text passen. Deshalb sollten versionsunabhängige Bezugspunkte für jeden Absatz im Dokument gesetzt werden. Falls der Benutzer nicht über ein Programm verfügt dass das Dokument und die Anmerkungen zusammenfügt muss es einen Proxy geben der dies für den Benutzer übernimmt.

Bekannte Nutzer

  • Annotea

Annotea ist ein WC3 Projekt mit dem Ziel Kommentarfunktionen zu standardisieren. Es werden genau die Mechanismen angewendet wie oben besprochen.

  • Pink

Die wesentlichen unterschiede zu Annotea sind das sich Kommentare auf Paragraphen beziehen und nicht auf vom Benutzer selektierten Text und es benutzt kein standardisiertes RDF Format zum speichern der Kommentare.

  • KOLUMBUS 2

In diesem Projekt können Benutzer Kommentare zu Paragraphen oder ganzen Kapiteln speichern. Kommentare können auf jeder Ebene gesetzt werden und je weiter oben sie gesetzt sind desto allgemeiner sind die Kommentare. Für jeden Kommentar kann die Sichtbarkeit privat oder öffentlich eingestellt werden.

  • Points of Interest

Hier können interessante Punkte auf einer Karte markiert und der ganzen Community mitgeteilt werden. Ein konkretes Beispiel hierfür ist Google Earth.

Verwandte Muster

Implementierung in eStudy

Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Wngr74 13:05, 22. Nov. 2010 (CET)

FEEDBACK LOOP

Dsck50

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
FEEDBACK LOOP

Alternative Bezeichnungen: Antwort, Frage den Autor, bidirektionale Kommunikation

Absicht

Der Leser soll dabei unterstützt werden, die Aussage des Autors eines Textes besser zu verstehen. Zudem soll die Möglichkeit gegeben sein, dass der Leser dem Autor Feedback geben kann.

Kontext

Autoren möchten Texte für Leser bereitstellen. Sie erstellen Texte für eine Leserschaft, beispielsweise auf einer Website oder einem Forum. Die Leser lesen diese Texte und wollen die Aussagen dieser verstehen.

Problem

Der Leser kann sich nur auf die Nachricht beziehen, um diese zu verstehen, es gibt keine Hintergrundinformationen zu dieser. Zudem sind die meisten Aussagen nicht eindeutig.

Szenario

Paul hat ein SHARED FILE RESPOSITORY eingerichtet, in dem Mitglieder die Dokumentation für eine Spiele-Engine ablegen können. Marc dokumentiert die Grafik-Engine. Charley benutzt eine schwer verständliche Sprache um das Sicherheitsmodell der Spiele-Engine zu beschreiben. Nur Susan hat eine gewisse Ahnung davon, was Charley auszudrücken versucht.

Symptome

Es sollte überlegt werden, dieses Muster einzusetzen, wenn...

  • Autoren feststellen, dass ihre Aussage missverstanden wird
  • Leser Probleme damit haben, die Aussage des Autors zu verstehen

Lösung

Ein einfaches Mittel zur Verfügung stellen, mit dem die Leser den Autoren kontaktieren können. Es muss also ein Interface-Element in der Nähe des Textes des Autors zur Verfügung gestellt werden, dass ein Eingabefeld öffnet, in dem der Leser seinen Fragen und Feedback abgeben kann.

Dynamik

Der Leser sieht die Aussage des Autoren. Wenn der Leser eine Frage hat, kann er eine Antwort-Maske öffnen. Beispielsweise indem er einen ANTWORTEN-Button anklickt. Die Antwort bezieht sich automatisch auf die Aussage des Autors, die gerade angezeigt wird. Dies kann entweder dadurch bewerkstelligt werden, dass die komplette Aussage zitiert wird, oder dadurch, dass ein Link zu der Aussage angegeben wird. Die Antwort wird beim abschicken dann an den Autor übertragen, der wiederum darauf eine Antwort an den Leser verfassen kann.

Gründe

Dadurch, dass der Leser beim Autor persönlich nachfragen kann, können schwierige Punkte schnell und direkt geklärt werden. Zudem kann der Leser genau erklären, wo das Verständnisproblem liegt. Dies hilft dem Autor, sodass dieser seine Aussage so umgestalten kann, dass diese besser zu verstehen ist.

Gefahrenpunkte

Es ist sinnvoll eine Unterscheidung zwischen allgemeinen und speziellen Problemen zu machen. Zuerst sollte die Frage an die ganze Benutzergruppe weitergegeben werden, danach nur an den Autor der Aussage. Diese Unterscheidung ist, speziell in Foren, oft unklar. Die Anwender gehen dort davon aus, den Autor zu erreichen, wenn sie eine Frage stellen. Allerdings ist es meist so, dass dort alle anderen Mitglieder die Frage auch zu sehen bekommen.

Bekannte Nutzung

eMail-Antwort: Alle eMail-Clients stellen die Möglichkeit bereit, dem Absender zu antworten. Normalerweise wird hierbei der Original-Text zitiert, der mit bestimmten Zeichen vor den Zeilen gekennzeichnet ist. Zudem wird in die Betreffzeile meint noch ein Re: vorgestellt. In vielen Programmen kann der Anwender entscheiden, ob nur der Sender der Nachricht die Antwort bekommt, oder aber alle, die auch die Originalnachricht erhalten haben.


Kontakt-Button auf Websites: Die meisten Websites bieten eine Möglichkeit an, mit dem Autor der Site in Verbindung zu treten. Die einfachste Möglichkeit ist es, einen mailto-Link im Fußbereich der Website zu implementieren. Bei einem Klick auf diesen Link öffnet sich ein Fenster für eine neue eMail, bei dem die Adresse des Empfängers schon automatisch eingetragen ist. Um das Muster vollständig zu implementieren, sollte einen Referenz auf den zu besprechenden Bereich eingefügt werden. Dies kann auch mit dem mailto-Link realisiert werden. Hierzu müssen an diesen noch zusätzliche Parameter angehängt werden. Als Beispiel öffnet der Link <ahref=‘‘mailto:stephan.lukosch@fernuni-hagen.de?Subject=Question%20regarding%20the%20Ask%20the%20Author%20pattern’’>Asktheauthor</a> eine eMail-Vorlage, in der die Empfänger-Adresse sowie ein Betreff, der dem aktuellen Kontext entspricht, schon eingefügt sind. Der Link ist etwas unschön, da er URL-enkodiert ist. Das bedeutet, dass Leerzeichen durch %20 ersetzt sind. Zudem ist es möglich, durch hinzufügen eines body-Parameters, vorgefertigten Inhalt für die eMail vorzugeben. Dies wird allerdings selten genutzt.


Schreibwerkstätte: Sie enthalten eine nichttechnische Umsetzung des Musters. Leser diskutieren über ein Muster, während die Autoren des Musters die Antworten lesen und begutachten. Dies hilft den Autoren die Auffassung der Leser besser verstehen zu können. Um zu verhindern, dass sich die Autoren einmischen und ihre Vorschläge verteidigen, sind diese dazu aufgefordert, nicht in das Geschehen einzugreifen. Nachdem die Leser fertig diskutiert haben, können die Autoren zu den Kommentaren Fragen stellen, um diese zu konkretisieren und besser zu verstehen.

Verwandte Muster

  • Forum
  • Threaded Discussions
  • FAQ
  • Quality Inspection
  • Letter of Recommendation


eStudy

Feedback Loop gibt es in eStudy. Man hat in einem Thread bei jedem Beitrag die Möglichkeit eine PN an den Verfasser zu schicken. In dieser wird der Beitrag, auf den man sich beziehen möchte zitiert und die Betreffzeile entsprechend angepasst.

DIGITAL EMOTIONS

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
DIGITAL EMOTIONS

Dsck50

Absicht

Dem Benutzer die Möglichkeit geben, persönliche Gefühle ausdrücken zu können.

Kontext

Benutzung von textueller Kommunikation ohne Audio und/oder Video Unterstützung.

Problem

Bei persönlicher Kommunikation (Auge in Auge) werden Gefühle durch nonverbale Hinweise und Verhaltensweise übermittelt. Bei textueller Kommunikation ist es aufwändig, Gefühle mit Worten zu beschreiben. Gefühle werden oft nicht übermittelt, wenn der Fokus der Unterhaltung auf dem Inhalt der Gespräche liegt.

Szenario

John hat Quellcode bearbeitet, der von Charley verfasst wurde und schwer zu verstehen ist. Er will Charley dies mitteilen und ihm sagen, dass der Quellcode überarbeitet werden sollte. Allerdings versteht Charley gute Ratschläge, speziell bei textueller Kommunikation, oft falsch und ist danach beleidigt.

Symptome

Es sollte überlegt werden, dieses Muster einzusetzen, wenn...

  • Anwender ironische Bemerkungen nicht erkennen oder witzige Anmerkungen nicht verstehen
  • Anwender über eine sarkastische Anmerkung eines anderen Benutzers in lange Diskussionen verfallen
  • Anwender sich eingeschränkt fühlen, wenn sie Gefühle übermitteln wollen

Lösung

Textuelle Möglichkeiten zur Verfügung stellen, mit denen die Benutzer ihre Gefühle ausdrücken können.

Dynamik

Es gibt verschiedene Mittel, mit denen die Benutzer ihre Gefühle textuell mitteilen können:

  1. Die Darstellung von emoticons (Smilies) die nur aus ASCII-Zeichen bestehen, mit denen Benutzer ihre Gefühle ausdrücken können.
  2. Die Bereitstellung einer Toolbar, die verschiedene (Gefühls-)Grafiken zur Verfügung stellt, die die Nutzer in die Texte einfügen können.
  3. Die Bereitstellung eines Interface-Elementes, auf dem die Benutzer ihren aktuellen Gefühlszustand auf einer Skala definieren können.

Gründe

':-)'

Gefahrenpunkte

Neue Benutzer müssen sich mit der Bedeutung der emoticons vertraut machen. Dies kann durch Feedback Loop oder einem FAQ unterstützt werden. Die automatische Interpretation von ASCII-Zeichen kann, beispielsweise bei Austausch von Quellcode, zu Fehlern führen. Es muss also die Möglichkeit gegeben sein, diese Automatismen abschalten zu können.

Bekannte Nutzung

eMail-Clients wie beispielsweise Thunderbird interpretieren gewisse Kombinationen von ASCII-Zeichen als emoticons. Diese Funktion kann allerdings vom Benutzer abgeschaltet werden.

Bekannte Beispiele sind:


':-)' Lächeln oder glücklich sein


':-(' Stirnrunzeln oder unglücklich sein


';-)' Zwinkern


':P' Zunge rausstrecken, Witz unterstreichen oder unbeschwerten Sarkasmus


Instant Messenger wie ICQ, MSN Messenger etc. stellen dem Benutzer eine Liste von emoticons zur Verfügung. Zudem ist auch hier die automatische Umwandlung von ASCII-Zeichen in Smilies integriert.


Auch in MMORPG wie Dungeons & Dragons Online oder World of Warcraft sind Digitale Emotionen ein wichtiger Bestandteil. Hierbei führt zum einen der Avatar des Spielers gewisse Bewegungen aus, zum anderen wird ein entsprechender Hinweis im Embedded Chat angezeigt.

Verwandte Muster

  • Embedded Chat
  • Feedback Loop
  • FAQ


eStudy

Emoticons (Smilies) gibt es in eStudy, da hier ASCII-Zeichen durch bestimmte Symbole ersetzt werden. Allerdings gibt es weder eine Toolbar noch eine andere grafische Hilfe, mit der diese ausgewählt werden könnten.

FAQ

Dsck50

Auch: Wissensarchiv, RTFM

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
FAQ

Absicht

Fragen die immer wieder wiederholt werden, vermeiden.

Kontext

Man unterstützt langfristige Kommunikation von einer großen Gruppe/Community, die sowohl aus erfahrenen Anwendern, als auch aus Anfängern besteht. Man möchte die neuen Mitglieder möglichst schnell und gut in die Gruppe/Community eingliedern.

Problem

Autoren verbringen viel Zeit damit immer wieder auftauchende Fragen zu beantworten. Dies wirkt demotivierend und stört die meisten anderen Anwender.

Szenario

Paul hat eine Idee, wie die Anwender einer Spiele-Engine besser unterstützt werden können. Er stellt eine Support-Hotline zur Verfügung. Die meisten der Core-Entwickler melden sich freiwillig um Fragen an der Support-Hotline zu beantworten. An einem Montagmorgen ruft Adrian an und fragt, wie die Sound-Bibliotheken kompiliert werden. Eine halbe Stunde später ruft Weigang an und stellt die selbe Frage, genauso wie Molo, der sie nachmittags stellt. So hatten sich das die Entwickler an der Support-Hotline nicht vorgestellt.

Symptome

Dieses Muster sollte also verwendet werden wenn,

  • die Community-Mitglieder beim Beantworten von Fragen öfter ein deja-vù-Erlebnis haben
  • die Benutzer ihre Probleme schlecht als Fragen formulieren können
  • die Bereitschaft Fragen zu beantworten mit der Zeit nachlässt
  • man Fragen und Antworten weiß, bevor der Kontext genauer definiert wurde

Lösung

Eine Liste mit häufig gestellten Fragen, die schon beantwortet wurden, verfassen. Diese Liste als Wissenssammlung der Gruppe ansehen. Die Liste, besonders für neue Benutzer, einfach zugänglich machen.

Dynamik

Ein FAQ kann ohne großes technisches Hintergrundwissen implementiert werden. Der Autor des FAQ muss sich einen Überblick über die Interaktion der Gruppe verschaffen und feststellen, welche Fragen oft auftauchen. Diese fasst er, mit den dazugehörigen Antworten, in einem Dokument zusammen. Diese Liste wird frei zur Verfügung gestellt, damit von allen Benutzern darauf verwiesen werden kann und neue Benutzer diese sofort einsehen können und sollten, bevor sie eine Frage in der Gruppe stellen. Zudem kann die Liste noch mit einem Zähler versehen werden, um die Prioritäten der einzelnen Fragen zu managen. Außerdem sollte die FAQ-Liste gepflegt werden und neue Fragen ergänzt werden, wenn dies notwendig ist. Zu diesem Zweck kann sie in einem Shared File Respository abgelegt werden.

Gründe

Ein FAQ macht gestellte Fragen und die Antworten dazu eindeutig. (Eine bestimmte Frage, eine richtige Antwort dazu). Die Benutzer können von anderen Benutzern lernen, ohne diese explizit fragen zu müssen. Es reduziert die Anzahl von wiederholt gestellten Fragen und erlaubt es, sich auf neue Fragen zu konzentrieren.

Check

Folgende Fragen sollte man sich stellen, bevor man dieses Muster anwendet:

  • Wo soll die FAQ-Liste gespeichert werden?
  • Wer erstellt und pflegt die FAQ-Liste? Ist dies Aufgabe der ganzen Community oder nur die einer bestimmten Benutzergruppe?
  • Wie soll die FAQ-Liste bereitgestellt werden?

Gefahrenpunkte

Fragen, die im FAQ beantwortet werden, werden nichtmehr so häufig normal gestellt. Dies bedeutet, dass sie als weniger wichtig eingestuft werden. Diesem Problem kann entgegengewirkt werden, indem ein Zähler in da FAQ eingebaut wird, wodurch die Wichtigkeit der Fragen im FAQ bewertet werden kann. Eine andere Möglichkeit ist es, eine Feedback-Funktion ins FAQ einzubauen, dass es dem Benutzer erlaubt, mitzuteilen ob die Antwort im FAQ hilfreich für ihn war. Es muss sichergestellt werden, dass die Benutzer wissen, dass es ein FAQ gibt und dieses leicht erreichbar ist. Um eine gute Struktur im FAQ zu erhalten, müssen es Nutzer pflegen, die viel Ahnung von Thema haben; dies sollte bei der Auswahl der Autoren berücksichtigt werden.

Bekannte Nutzung

Newsgroups. Bestimmte newsgroups senden regelmäßig aktualisierte FAQ an ihre Benutzer.

Verwandte Muster

  • Hall of Fame
  • Feedback Loop
  • Mentor
  • Quality Inspection
  • Forum
  • Frequently Asked Questions


eStudy

In eStudy gibt es ein rudimentäres FAQ. Allerdings nicht speziell für den Bereich Textual Communication.

How to Provide Synchronous Group Awareness

Deutsch: Wie man Synchron-Gruppenbewusstsein vermittelt.

USER LIST

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
USER LIST

Intent

Zeigen, welche Benutzer momentan an einer Sitzung beteiligt sind.

Context

Mehrere Benutzer operieren auf einer Menge gemeinsam genutzter Artefakte.

Problem

Benutzer wissen nicht, mit wem sie interagieren oder interagieren könnten. Dadurch wird der Eindruck erweckt, dass der Benutzer kein Teilnehmer einer Gruppe ist.

Scenario

Charley arbeitet an einem sicherheitsrelevanten Code und überlegt Passwörter in den Benutzeraccounts unterzubringen. Dafür sind Änderungen an einigen Dateien und der Definition der entsprechenden Datenbanktabelle in der Datenbank notwendig. Zur gleichen Zeit überlegt Cindy die Darstellung der Benutzeraccounts zu erweitern, um sie noch mehr zu personalisieren, wofür ebenfalls Änderungen an der Tabellendefinition notwendig sind. Wenn beide nicht mitbekommen, dass ein anderer Benutzer an der Tabelle arbeitet, wird die Tabelle parallel von beiden Benutzern verändert, was in einem Konfikt enden wird.

Symptoms

Überlegungen zur Anwendung dieses Musters sollten erfolgen wenn :

  • Benutzer ein gemeinsam genutztes Artefakt als privates Artefakt behandeln
  • Benutzer den Eindruck haben alleine an einem Artefakt zu arbeiten.
  • Eine effektive Interaktion die Identifikation anderer Benutzer erfordert
  • Verteilte Benutzer andere Benutzer nicht sehen können.
  • Benutzer regelmäßig Nachrichten senden, wie "Hi, ist noch jemand hier?"
  • Bei einer Verwendung des Musters "COLLABORATIVE SESSION" wenn:
  1. Benutzer bei der Arbeit an gemeinsam genutzten Artefakten gehindert werden, da sie nicht wissen wer ihre Änderungen ausser ihnen selbst sonst noch mitbekommt.
  2. Benutzer wissen, dass sie mit anderen Benutzern interagieren, aber sie nicht identifizieren können.

Solution

Sorgen Sie für ein Bewußtsein des aktuellen Kontexts. Zeigen Sie, welche Benutzer derzeit auf ein Artefakt zugreifen oder an einer "COLLABORATIVE SESSION" teilnehmen. Stellen Sie sicher, dass solche Informationen immer gültig sind.

Dynamics

Wenn Benutzer einem Interkationskontext beitreten werden ihre Namen der Benutzerliste des entsprechenden Interaktionskontextes hinzugefügt. Diese Benutzerliste ist eine visuelle Repräsentation aller Benutzer, die in demselben Interaktionskontext agieren. Wenn ein Benutzer den Interaktionskontext verlässt, so wird der Benutzer umgehend aus der Benutzerliste wieder entfernt. Der Benutzer spielt in diesem Zusammenhang die Rolle eines "Subscribers" der immer dann informiert wird, wenn sich das zu Grunde liegende Model ändert.

Rationale

Dadurch dass dem Benutzer explizit mitgeteilt wird, dass ebenfalls andere Benutzer an demselben Artefakt (bzw. Interaktionskontext) arbeiten, werden die Benutzer aufeinander aufmerksam gemacht, was die Grundlage für eine Zusammenarbeit darstellt.

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Was ist der Interaktionskontext?
  1. Macht es sinn eine ganzheitlich Applikations-umfassende Benutzerliste zu verwenden oder soll eine Aufteilung in Kontext-zentrierte Benutzerlisten erfolgen?
  2. Sind solche Artefakte auf unterschiedlichen Eskalationsstufen der Anwendung erkennbar? Wenn ja, welche ist die richtige Eskalationsstufe für die Bekanntgabe, dass auch andere Anwesend sind?
  • Wieviele Benutzer sollen auf der Benutzerliste schätzungsweise angezeigt werden?
  • Kann man graphische Repräsentationsmöglichkeiten verwenden (siehe "VIRTUAL ME")?
  • Gibt es Situationen, in denen es Sinn macht die Benutzerliste abzuschalten?

Danger Spots

Known uses

Chatsysteme mit Benutzerlisten oder Instant Messenger mit Konferenzfunktion (z.B.: MSN Messenger).
Bei solchen Applikationen werden üblicherweise alle Benutzer in einem Kontext (z.B.: "Chatraum" oder einer Konferenz) jedem einzelnen Teilnehmer in einer Benutzerliste in der Client-Anwendung bzw. dem Browser angezeigt.

UNIX "who"
Mit dem UNIX Kommando "who" kann man per Konsole alle Benutzer anzeigen lassen, die momentan auf der Maschine (Kontext) arbeiten.

Verwandte Muster (Ralated Patterns)

  • Login (3.1.2)
  • Virtual Me (3.1.5)

Implementierung in eStudy

eStudy stellt dem Benutzer eine Applikations-umfassende Version einer Benutzerliste zur Verfügung. Hierbei stellt beispielsweise die Gesamtapplikation den Interaktionskontext dar.

EStudyUserList.png


Asms47

SPONTANEOUS COLLABORATION

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
SPONTANEOUS COLLABORATION

Absicht

Unterstütze die Benutzer bei der Vereinbarung einer Zusammenarbeit mit anderen Benutzern. Dies soll darauf basieren, dass Benutzern bewusst gemacht wird, dass auch andere Benutzer präsent sind.

Kontext

Benutzer arbeiten mit Applikationen, die Zugang zu gemeinsam genutzten Daten gewähren. Die Benutzer arbeiten dabei an verschiedenen Orten und konsumieren oder manipulieren gemeinsam genutzte Daten, indem Sie ihre persönlichen Clients benutzen.

Problem

Obwohl Benutzer an gemeinsam genutzten Daten arbeiten, merken sie nicht, dass auch andere Benutzer parallel an denselben Daten arbeiten.

Szenario

James arbeitet an der Darstellung der Benutzerdaten im Browser. Will ändert währenddessen die Tabellendefinition für Benutzerdaten um zusätzliche Daten speichern zu können. Für beide sieht die Aufgabe sehr klar aus und es besteht nach ihrem Ermessen kein Bedarf für eine Kollaboration mit anderen Personen. James ist aber nicht klar, dass Will die Tabellendefinition ändern wird und zusätzliche Benutzerinformationen hinzugefügt werden, die ja für die Darstellung der Benutzerdaten ebenfalls notwendig sein könnten. Hätte James es vorher gewusst, dass die Tabellendefinition geändert wird, so hätte er von Anfang an mit Will zusammengearbeitet und wüsste über die Änderungen bescheid.

Symptome

Eine Verwendung des Musters sollte in Erwägung gezogen werden, wenn :

  • es für Führungskräfte schwierig ist zu bestimmen, welche Personen mit einander zusammenarbeiten sollen
  • Team-Mitglieder erst dann feststellen, dass sie an denselben Daten gearbeitet haben, wenn ihre Arbeit bereits abgeschlossen ist
  • Konflikte, die aus parallenen Tätigkeiten resultierten hätten vermieden werden können, wenn die betroffenen Team-Mitglieder von Anfang an zusammengearbeitet hätten.
  • den Benutzern die Möglichkeiten für eine Zusammenarbeit mit anderen Personen nicht bewusst sind

Lösung

Ermutige Benutzer dazu, dass sie spontan Kollaborationsgruppen erstellen. Dies soll darauf basieren, dass den Benutzern die Präsenz anderer Benutzer bewusst gemacht wird.

Dynamik

Eine Applikation kann beispielsweise einen "ACTIVITY LOG" verwenden, um dem Benutzer auf eine angemessene Weise bewußt zu machen, dass auch andere Benutzer präsent sind. Hierbei sei jedoch angemerkt, dass das Bewußtsein sich auf die Aktivitäten der Benutzer stützt und nicht auf deren Existenz oder Verfügbarkeitsstatus ("Virtual Me"). Wenn sich die Benutzer dessen bewußt sind, dass auch andere präsent sind und an einer verwandten Sache arbeiten, können Sie sich zu einer Zusammenarbeit verabreden, indem sie eine Gruppe eröffnen, in die auch weitere Benutzer hinzugefügt werden können. Für die Zusammenarbeit verwendet die Gruppe gemeinsam genutzte Werkzeuge. Alle Aktivitäten der Gruppe werden dabei festgehalten, um wiederum (auf höherer Ebene) ein Bewusstsein einer Gruppenpräsenz zu vermitteln, aber ebenso auch um nach Außen hin (also den Benutzern, die nicht Mitglied der Gruppe sind) die Aktivitäten der Gruppe bewusst zu machen.

Rationale

Die "SPONTANEOUS COLLABORATION" beginnt damit, dass Benutzer ihre Arbeit (Aktivikäten) eigenständig erledigen, wobei Sie gemeinsam genutzte Daten bearbeiten. Das System zeichnet diese Aktivitäten auf eine geeignete Weise auf und kann auf dieser Basis die Benutzer auf die Aktivitäten anderer aufmerksam machen. Dies kann sich beispielsweise derart ausprägen, dass den entsprechenden Benutzern bekannt gegeben wird, dass auch andere Benutzer an denselben Daten arbeiten. Dadurch können die Benutzer in Kontakt treten, sich zusammenschließen und eine Gruppe für eine Zusammenarbeit an den gemeinsam genutzten Daten eröffnen.

Check

Bevor dieses Muster angewendet wird, sollten folgende Punkte vorher berücksichtigt weden:

  • Welche Artefakte werden von mehr als nur einem Benutzer verwendet?
  • Welche parallelen Aktivitäten gibt s und wie wirken sie sich auf die Artefakte aus?
  • Gibt es eine vordefinierte Menge an Gruppen, die die Aufzeichnung der Aktivitäten des Systems einschränken soll? Wenn ja, wie sollen Konflikte, die durch parallel arbeitende Gruppen entstehen, gelöst werden?

Gefahrenpunkte

Die Bereitstellung einer dynamischen und Artefakt-basierten Gruppenerzeugung kann das formale Team-Management aushebeln. Das Ziel dieses Musters ist jedoch, dass dies lediglich durch eine dynamsiche Kollaboration unterstützt wird. Beim System-Design sollte deshalb berücksichtigt werden, dass Benutzer dazu neigen nur Widerwillens ihre Arbeitsumgebung zu ändern. Aus diesem Grund ist es unwahrscheinlich, dass allein zum Zweck einer verbesserten Gruppenzusammenarbeit völlig neue Werkzeuge verwendet werden. Folglich sollten Gruppenbewusstsein und Mechanismen für eine Zusammenarbeit der Team-Mitglieder so eng wie nur irgend möglich integriert werden.

Verwandte Muster

Verwendung in eStudy

In eStudy wird dieses Muster in einer etwas abgeänderten Weise für eCommunities angewendet. eCommunities bilden in diesem Sinne die Gruppe die in einem Kontext zusammenarbeitet, die spontan eröffnet und wiederum geschlossen werden kann. Abweichend von diesem Muster stützt sich der Mechanismus der "eComs" allerdings auf keine "Tracking"-Funktion (bzw. Aufzeichnung der Benutzeraktivitäten) als Basis für die Erweckung des Bewusstseins des Benutzers, dass auch andere Benutzer in demselben Kontext arbeiten. Der eCom-Mechanismus in eStudy ist also nicht Artefakt-basiert und weicht somit an dieser Stelle von diesem Muster ab.


Asms47

ACTIVE NEIGHBORS

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
ACTIVE NEIGHBORS

Absicht

Zeige Aktivitäten nicht nur an Artefakten an, an denen der Benutzer derzeit arbeitet, sondern auch Aktivitäten an den verwandten Artefakten.

Kontext

Es werden User Lists benutzt, um Benutzern anzuzeigen, welche Aktivitäten die jeweiligen Benutzer derzeit ausüben. Zwei oder mehr Benutzer arbeiten an verwandten Artefakten. Die Wahrscheinlichkeit, dass ein anderer Benutzer gerade an demselben Artefakt arbeitet ist gering, sofern es mehr Artefakte als Benutzer gibt.

Problem

Mit dem User List Muster werden nur Benutzer angezeigt, die die gleiche Absicht bzw. das Interesse an demselben Artefakt haben. Wenn Benutzer an verwandten Artefakten arbeiten, dann werden sie nicht auf einander aufmerksam, was darin resultiert, dass sie nicht zusammenarbeiten werden.

Szenario

James ist auf Will aufmerksam geworden, weil beide an derselben Klasse in ihrem Modul bearbeitet haben. Sie waren sich einig einen Schnittstellen-Code zu ändern. Unglücklicherweise betrifft die Änderung der Schnittstelle auch Charley, der für die Wartung dieser Schnittstelle zuständig ist und derzeit an einer neuen Klasse arbeitet, die viel Gebrauch von dieser Schnittstelle macht.

Symptome

Dieses Muster sollte verwendet werden, wenn:

  • Benutzer denken, dass es Sinn machen würde mit anderen Benutzern zusammenzuarbeiten, die dieselbe gemeinsame "semantische" Aktivität (verwandte Aktivität) durchführen, aber nicht sehen können wer exakt dieselbe Aktivität durchführt.
  • Benutzer nur selten an demselben Artefakt arbeiten.
  • Die Anzahl der Artefakte wesentlich größer ist, als die der Benutzer.
  • semantische Abhängigkeiten zwischen den Artefakten existieren.
  • Nach Mitteln gesucht wird, die kreative Prozesse und gegenseitiges Unterrichten unterstützen.

Lösung

Mache Benutzer auf andere Benutzer aufmerksam, die dieselbe oder eine semantisch verwandte Aktivität auf demselben oder einem verwandten Artefakt durchführen.

Dynamik

Modelliere eine Menge von Artefakten für jeden Benutzer, die alle Artefakte beinhaltet, die die derzeitig vom Benutzer durchgeführten Aktivitäten betreffen. Erweitere diese Menge mit allen verwandten Artefakten. Bestimme die verwandten Artefakte entweder über Vergleichsmetriken, wie "overlap of terms" oder den Mitteln eines semantischen Netzes. Anschließend, ermittle welche Benutzer auf diesen Artefakten Aktivitäten durchführen und zeige diese dem Benutzer an. Stelle sicher, dass diese Information interaktiv ist, sodass man leicht mit diesen Personen kommunizieren kann oder in deren (u.U. entfernte) Arbeitsumgebung wechseln kann.

Begründung

Durch die Inkenntnismahme des Benutzers über die Aktivitäten anderer Benutzer auf denselben oder semantisch vernwandten Artefakten, können Konflikte paralleler semantisch verwandter Aktivitäten aufgedeckt werden. Dieses Muster schließt solche Konflikte jedoch nicht aus, sondern minimiert ihre Auftrittswahrscheinlichkeit. Zugleich werden jedoch auch die Benutzer zusammengeführt und zu einer Zusammenarbeit animiert.

Check

Bevor dieses Muster eingesetzt wird, sollten folgende Fragen beantwortet werden :

  • Wie können die semantisch verwandten Artefakte bestimmt werden?
  • Bis zu welcher "semantischen Distanz" (~"Verwandtschaftsgrad") sollen Benutzer angezeigt werden, die semantisch Verwandte Aktivitäten durchführen?
  • Wie soll die Arbeitsumgebung von Benutzern ausgedrückt werden? Hat jede Arbeitsumgebung eine eindeutige Bezeichnung?
  • Können Links zur Verfügung gestellt werden, die einen Benutzer an die Arbeitsumgebung eines anderen Benutzers führen?

Gefahrenpunkte

Wichtig ist, dass der Algorithmus zur Berechnung der Maximalschwelle semantisch verwandter Benutzer, gut ist. Ist die Schwelle zu groß, so werden dem Benutzer u.U. zu viele Benutzer angezeigt, die u.U. wiederum nicht wirklich viel mit der derzeitigen Aktivität des Benutzers zu tun haben. Andersherum, wenn die Schwelle zu klein ist, werden nicht alle relevanten Benutzer angezeigt.

Verwandte Muster


Asms47

INTERACTIVE USER INFO

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
INTERACTIVE USER INFO

Absicht

Informationen über andere Benutzer klickbar machen und diese zum Kommunizieren und Kollaborieren verwenden.

Kontext

Sie wollen die Aktionen von anderen Benutzern der Gruppe mithilfe ihrer Benutzernamen visualisieren. Sie überlegen Sie sich jetzt wie dies zu realen Interaktionen zwischen Benutzern führen kann.

Problem

Jeder Benutzer der Plattform weiß, dass es andere Users auf der Plattform gibt und wer sie Sind. Sie wissen aber nicht wie sie mit einem bestimmten Benutzer enger Interagieren können.

Szenario

James sieht ,dass Wil und er beide an dem gleichen Produkt arbeiten und entscheidet sich dafür, wil eine private Nachricht zu hinterlassen. Der merkt leider ,dass dies nicht so einfach ist. James muss die adresse von Wil in seinem Adressbuch finden, eine neue e-mail nachricht erfassen und Wil zu der Empfängerliste in seinem e-mail client hinzufügen.

Symptome

Dieses Muster sollte dann angewandt werden wann . . .

  • Eine Kontaktaufnahme zu lange dauert.
  • Die Benutzer müssen sich überlegen wie sie mithilfe der verfügbaren Informationen über Benutzer AKontakt mit ihm Aufnehmen können.
  • Die Kontaktaufnahme benötigt zusätzliche Informationen, die normalerweise nicht im VIRTUAL ME angezeigt werden.

Lösung

Daraus folt: Das Benutzerprofil mit einem Kontextmenü aufstatten, das Funktionen anbietet, um mehr Informationen über den Benutzer zu kriegen und eine engere Kollaboration mit dem Benutzer zu starten.

Dynamik

Für jeden Benutzer definiert das System mögliche Interaktionsadapters. Ein Interaktionsadapter definiert die Kanäle und die Adressen, die verwendet werden können, um einen Benutzer zu erreichen. Wenn ein Benutzer angezeigt wird sind alle Kommunikationskanäle über ein Kontextmenü erreichbar.

Begründung

In mehreren Groupware Systeme, kann man nur eine Benutzerliste sehen. Es gibt leider nicht viel was man mit einem anderen Benutzer "machen" kann. Ohne Interaktive User Informationen, muss man die Interaktionsmöglichkeiten mit anderen Benutzern selbst rausfinden. z.B. suchen nach der email Adresse eines Benutzers in einem Adressbuch. Mit interaktiven Informationen erfolgt diese Suche automatisch.

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Welche Aktionen können Sie zum Kontextmenü hinzufügen?
  • Wie werden Sie den Benutzerzustand im Kontextmenü anzeigen?
  • Können Sie ein Kontextmenü verwenden oder müssen Sie zusätzlich graphische Links angeben?

Gefahrenpunkte

In manchen Systeme haben nicht alle Benutzer die gleichen Interaktionsmöglichkeiten. Ein Benutzer kann z.B. ein Instant-Messaging System haben während andere Benutzer nur per mail erreichbar sind.


Bekannte Nutzer

  • Buddylists (IM Systeme): Freundesliste in Instant-Messaging Systeme wie die BuddyList in MSN Messenger (http://messenger.msn.com). Sie bietet ein Kontextmenü an für jeden Benutzer, der in der Freundesliste steht.

Das Beispiel zeigt die Menüaktionen, die verfügbar sind, um den Benutzer "Paulin" zu kontaktieren. Das Menü wird automatisch an den "Features" des Benutzers angepasst. Wenn der Benutzer Offline ist, sind die Optionen "chat" und "Video Chat" deaktiviert. Das System erlaubt immer noch das Versenden von emails an Offline Benutzern.

  • vBulletin
  • Videospiele
  • CURE

Verwante Muster

  • VIRTUAL ME
  • BUDDY LIST
  • INVITATION
  • LOCALIZED OBJECT ACTIONS
  • DISABLE IRRELEVANT THINGS

REMOTE FIELD OF VISION

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
REMOTE FIELD OF VISION

Absicht

Liefert Benutzern eines gemeinsamen Programms Informationen über den Teil des Systems, der von anderen Benutzern grad betrachtet wird.

Kontext

Verschiedene Benutzer arbeiten gleichzeitig mit einem gemeinsamen Editor an verteilten Dokumenten, die auf dem Editor angezeigt werden. Jeder Benuzter darf individuell scrollen.

Problem

Individuelle Scroll Positionen in einem gemeinsamen Editor ermöglicht eine lose gekoppelte Arbeit. Es macht aber den Abgleich schwerer.

Szenario

James und Wil editieren beide ein Diagramm. James bearbeitet die Ecke oben rechts während Wil nach unten gescrollt hat. Irgendwann hat James eine Frage über den Titel des Diagrammes, der oben rechts angezeigt wird. Der fragt Wil ob er oben rechts gucken kann. Der hat aber vergessen, dass Wil was anderes dort sieht. Dies führt zu Missverständnissen

Symptome

Dieses Muster sollte dann angewandt werden wann . . .

  • Benutzer müssen ihre Aufmerksamkeit auf den gleichen Inhalt richten.
  • Benutzer unterbrechen sich ständig, um zu fragen welche Bereiche sie grad bearbeiten oder um die andere zu benachrichtigen jedes mal wenn sie ihre Position im Editor wechseln.
  • Benutzer fragen andere Benutzer einen bestimmten Bereich des Bildschirmes zu betrachten, obwohl die was anderes im Editor sehen.

Lösung

Explicit die Position und den Bereich jedes Benutzers an alle andere anzeigen.

Dynamik

Begründung

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Wie können Sie das Blickfeld des lokalen Benutzers ermitteln? Können Sie die Scroll Position direkt von der Applikation lesen?
  • Wie wird das Blickfeld in dem gemeinsamen Raum/Editor dargestellt? Werden Sie ein Rechteck, ein Polygon oder einen Zwischenraum verwenden?
  • Wie können andere Benutzer wissen wessen Blickfeld grad angezeigt wird? Können Sie Benutzername hinzufügen? Lohnt es sich ein Bild anzuzeigen?

Gefahrenpunkte

Bekannte Nutzer

  • COAST UML Editor.
  • MAUI
  • GroupWEB

Verwandte Muster

  • TELEPOINTER
  • REMOTE SELECTION
  • ACTIVE MAP
  • VIRTUAL ME
  • SHARED BROWSING

REMOTE SELECTION

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
REMOTE SELECTION

Absicht

Benachrichtigt andere Benutzer über die Auswahl des lokalen Benutzers.

Kontext

Benutzer kollaborieren in einem gemeinsamen Editor, der ihnen erlaubt gleichzeitig Objekte auszuwählen und zu bearbeiten.

Problem

Ein Benutzer wählt ein Dokument aus und will es bearbeiten. Wenn zwei Benutzer gleichzeitig das gleiche Objekt auswählen kann dies zu Koordinationsprobleme führen.

Szenario

James und Wil kollaborieren immer noch mit einem gemeinsamen Diagrammeditor. James wählt die abstrakte Klasse A während Wil die gleiche Klasse und alle ihre Unterklassen auswählt. James verschiebt jetzt die abstrakte Klasse A in einem anderen Bereich des Diagrammes. Wil ärgert sich weil er dachte er könnte seine gewählte Klassen separat bearbeiten und sagt zu James "Was hast du mit meinen Klassen getan?"

Symptome

Dieses Muster sollte dann angewandt werden wann . . .

  • Benutzer betrachten ausgewählte Objekte als "Ihre" Objekte. Diese können aber auch von anderen Benutzern geändert werden.
  • Benutzer sind schon daran gewöhnt, Elemente auszuwählen, bevor sie es erstmal mit anderen Benutzern klären.

Lösung

Auswahl andere Users vom lokalen Benutzer sichtbar. Sicherstellen, dass alle Benutzer, die ein bestimmtes Dokument bearbeiten wollen, wissen welche andere Benutzer grad das gleiche Dokument ausgewählt haben.

Dynamik

Begründung

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Was können andere Benutzer auswählen?
  • Kann man nur einen bestimmten Teil eines Objektes auswählen?
  • Wie sollen entfernte Auswahlen dargestellt werden?

Gefahrenpunkte

Bekannte Nutzer

  • MAUI
  • Dolphin
  • TUKAN
  • COAST UML-Editor

Verwandte Muster

  • TELEPOINTER
  • REMOTE CURSOR
  • REMOTE FIELD OF VISION

REMOTE CURSOR

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
REMOTE CURSOR

Absicht

Ermöglicht "Remote gestures". Andere Benutzer wissen was der lokale Benutzer grad macht/bearbeitet.

Kontext

Benutzer manipulieren gleichzeitig Dokumente mit Hilfe von verschiedenen Eingabegeräten wie Maus, Tastatur. Um mit einen bestimmten Objekt interagieren zu können, muss der Benutzer erstmal sein Eingabegerät richtig positionieren.

Problem

Der Benutzer will ständig über die Aktivitäten andere Benutzer informiert sein. Das bedeutet ein Verständnis der Interaktionen von anderen Benutzern mit dem System, wie z.B. Maus oder Kursor Bewegung.

Szenario

Juan und Carla müssen zusammenarbeiten, um das neue Logo einer Spiel-Engine zu entwerfen. Sie hatten die Idee eine gemeinsame Online Whiteboard zu verwenden, worauf sie beide ihre Skizzen zeichnen können. Leider haben sie sich ständig gegenseitig gestört und über die Skizzen des anderen gezeichnet.

Symptome

Dieses Muster sollte dann angewandt werden wann . . .

  • Andere Synchrone bewusstsein widgets, wie TELEPOINTER, REMOTE SELECTION oder REMOTE FIELD OF VISION bieten nicht genug bewusstsein, das führt dazu, dass Benutzer die Präsenz und implizite Koordination vermissen, die man in realen Sitzungen erlebt hätte.
  • Benutzer haben nicht das Gefühl das andere Benutzer aktiv sind im gemeinsamen Arbeitsraum.
  • Es gibt ständig Konflikte zwischen Benutzern, weil sie gleichzeitig das selbe Objekt bearbeiten. REMOTE SELECTION bietet hier auch keine Lösung zum Problem.
  • Die Benutzer wollen die Aktionen von anderen Benutzern verfolgen und nicht nur die Ergebnisse sehen.

Lösung

Daraus folt: Maus Cursor oder Text Cursor von anderen Benutzern im lokalen View des gemeinsamen Editors zeigen. Andere Farben und Formen verwenden, um die anderen Kursor vom lokalen Kursor zu unterscheiden. Die Position der Cursoren aktualisieren jedesmal wenn ein anderer Benutzer seinen Cursor bewegt.

Dynamik

Begründung

Check

Bevor dieses Muster angewendet werden soll, sollten folgende Fragen beantwortet werden:

  • Welche Formen werden Sie verwenden, um die anderen Cursoren darzustellen?
  • Werden sie Text-Cursoren, Maus-Cursoren oder beide abfangen?
  • Wie kann ein Benutzer den entferten Cursor aktievieren?
  • Wie werden sie die Positionen der Cursoren speichern?

Gefahrenpunkte

Bekannte Nutzer

  • SEPIA
  • MAUI
  • GroupWeb
  • Lotus Sametime

Verwandte Muster

  • TELEPOINTER
  • REMOTE SELECTION
  • ACTIVITY INDICATOR

TELEPOINTER

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
TELEPOINTER

Absicht

Die Aufmerksamkeit der entfernten Nutzer auf einen bestimmten Punkt in den bereitgestellten Informationen lenekn.

Kontext

Nutzer interagieren gleichzeitig im visuellen Informationsraum.

Problem

Es ist schwer die gemeinsame Aufmerksamkeit aller nutzer auf ein bestimmtes Visuelles Hilfsmittel zu lenken oder auch nur auf einen Teil davon.

Szenario

Charly und Paul befinden sich in einem Meeting um das neue Klassendiagramm der Sicherheits-Schicht zu besprechen. Sie öffnen das Klassendiagramm und besprechen es. Charly zeigt mit seinem Finger auf einen bestimmten Teil des Diagramms und schlägt vor diese spezielle Klasse zu entfernen. Da Paul jedoch nicht kollokiert ist versteht er nicht was Charlie mit "diese Klasse" meint.

Symptome

Dieses Muster sollte angewendet werden wenn...

  • Wenn Nutzer mit ihren Fingern auf bestimmte Punkte der Werkzeuge zeigen müssen in einer kollektiven Situation.
  • Entfernte Nutzer Probleme haben mit den Werkzeugen zu verbinden auf die sie sich gerade beziehen.
  • Nutzer ein Zeigeinstrument benötigen um die Aufmerksamkeit der zuhörer auf bestimmte Punkte zu lenken.

Lösung

Jeder Nutzer benötigt ein geeignetes Zeigeinstrument das er im Informationsraum platzieren kann.

Dynamik

Der Besitzer eines Telepointers aktiviert diesen, mit dem Effekt das alle anderen Nutzer diesen ebenfalls sehen. Die Sicht hat nun einen bestimmten Fokus im Visuellen Werkzeug oder im Informationsraum. Es wird gleichzeitig auch der Name des derzeitig zeigenden Nutzers eingeblendet. Der Besitzer des Telepointers kann diesen bewegen und damit quasi im Informationsraum gestikulieren. Der Fokus des Telepointers wird zwischen allen Nutzern synchronisiert, so das jeder den gleichen Fokus hat. Wenn der Besitzer des Telepoiters diesen nicht weiter benötigt, kann er ihn entfernen.

Begründung

Es gibt verschiedene Gründe wieso ein Telepointer hilft die Aufmerksamkeit einer Gruppe besser zu steuern. Der Hauptgrund ist, das es ein deutliches Zeigeinstrument ist. Die Nutzer wissen, das der Telepointer nur zum Markieren wichtiger Informaitonen genutzt wird. Deshalb können sie ihn besser Interpretieren als ein REMOTE CURSOR. Ein REMOTE CURSOR würde sich auch bewegen wenn der Besitzer die Maus bewegt. Da der Telpointer eher ein Statisches Instrument ist, kann er auch eher in diesem Sinn genutzt werden. Nutzer können z.B. einen Telepointer an der Position platzieren an der sie gerade arbeiten. Dies hatt den Effekt das insgesammt weniger Bewegung auf dem Bildschirm herrscht im vergleich zu situationen wo ein REMOTE CURSOR genutzt wird.

Check

Wenn dieses Muster genutzt wird sollten folgende Fragen beantwortet werden...

  • Wie sollte der Raum auf den sich der Telepointer bezieht dargestellt werden?
  • Welches Icon sollte genutzt werden um den Telepointer darzustellen?
  • Soll der Name des Telepointer Nutzers dargestellt werden oder sogar sein Foto?
  • Soll der Telepointer entfernt werden wenn der Nutzer die Session verlässt?

Gefahrenpunkte

Nutzer könnten vergessen ihren Telepointer wieder zu entfernen, dies kann konfussion in der Gruppe verursachen. Eine Lösung wäre das Moderatoren nicht mehr genutzte Telepointer abschalten können. Das Bewegen des Fokussierten Teils der Informationen könnte den Sinn des Telepointers verändern. Lösung wäre den Pointer an die Fokusierten Informationen zu koppeln und mitzubewegen.

Bekannte Nutzer

  • Netmeeting shared whitheboard
Das Shared Whiteboard erlaubt Nutzern eine Zeigenden Hand in der Zeichnung zu platzieren.
  • Vital
Erlaubt mehreren Nutzern das gleichzeitige Einsehen und Bearbeiten eines Textes.

Verwante Muster

  • Remote Cursor
  • Remote Selection
  • Flag
  • Embedded Chat
  • Digital Emotions
  • Virutal Me

ACTIVITY INDICATOR

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
ACTIVITY INDICATOR

Absicht

Einen Indikator für die Aktivität eines Nutzers zur Verfügung stellen ohne Zwischenergebnisse der Aktivität zu zeigen.

Kontext

Die Nutzer befinden sich an verschiedenen geografisch entfernten Punkten und interagieren in einer hoch Synchronen Session die regelmäßige Frage-Antwort Interaktion beinhaltet.

Problem

Nutzer benötigen Zeit um eine Aufgabe auszuführen, leider wird aber nur das Ergebnis gezeigt. Bei gemeinsamen Arbeiten erhalten Nutzer immer auch non-Verbale Signale über die Aktivität verschiedener Nutzer. Befinden sich die Nutzer an weit entfernten Punkten fehlt dieses Element. Nutzer wissen deshalb nicht über die Aktivität anderer Nutzer bescheid, was zu Konflikten oder unnötigen Verzögerungen führen kann.

Szenario

Rick und Dimitri haben sich beide entschlossen an den Graphischen Aspekten einer Spiele Engine zu arbeiten. Rick arbeitet an der Darstellung von Orten, während Dimitri sich um die Darstellung von Personen kümmert. An einem bestimmten Punkt ändert Dimitri ein Stück Code den ebenfalls Rick betrifft. Wenn Rick nun an der gleichen Stelle Modifikationen durchführt müssen beide Ergebnisse Zusammengeführt werden.

Symptome

Dieses Muster kann angewendet werden wenn...

  • Nutzer mögen nicht das Entfernte arbeiten im gleichen Arbeitsfeld weil sie nicht wissen was die anderen gerade tun.
  • Nutzer überlagernde Aufgaben ausführen.
  • Nutzer warten lange auf die Aktionen anderer Nutzer, selbst wenn diese überhaupt nichts durchführen.
  • Nutzer arbeiten zur gleichen Zeit. Nicht zwingend am gleichen Material.
  • Nutzer möchten nicht von ihren derzeitigen Aufgaben abgelenkt werden, möchten aber über die Aktivität anderer Nutzer informiert werden.

Lösung

Stelle die Aktivität der Nutzer grafisch dar. Um Ablenkung zu vermeiden sollte jedoch ein unauffälliger Indikator gewählt werden.

Dynamik

Stelle einen Indikator in einer Ecke des Interfaces bereit, das Informationen über die Aktivität der Nutzer wiedergibt. Die genaue derzeitige Aktivität eines Nutzer kann z.B. auch mit einem ACTIVITY LOG ermittelt werden. Stelle sicher das die Aktivität anderer Nutzer im Arbeitsraum des aktuellen Nutzers dargestellt wird. Verstecke die Indikatoren wenn keine Aktivität stattfindet.

Begründung

Der Indikator erscheint, sobald entfernte Nutzer agiert. Dies zeigt dem lokalen Nutzer, das Konflikte entstehen könnten.

Check

Folgende Fragen sollten bei der Anwendung dieses Musters beantwortet werden...

  • Wo werden die Aktivitäten anderen Nutzer dargestellt? Häufige Orte sind.
* Die Status Bar der Anwendung
* Die Status Bar auf dem Desktop
* Ein Popup auf dem Desktop das nach kurzer Zeit wieder verschwindet.
* Eine Informatinsleiste in der Applikation.
* Eine Farbveränderung in der Titelleiste der Anwendung.

Gefahrenpunkte

Wenn viele Nutzer aktiv sind ist es schwer deren individuelle Aktivität darzustellen.

Bekannte Nutzer

  • MSN Messanger
Zeigt wenn andere Nutzer gerade eine Nachricht verfassen.
  • Palantir
Jede Aktivität die den Lokalen nutzer Betrifft läuft durch durch einen Ticker.
  • Mail Clients wie z.B. Thunderbird
Stellen ein Status-Icon zur Verfügung wenn neue Nachrichten eingetroffen sind. Auch Hintergrundaktivitäten wie das Abrufen oder abschicken von E-Mails werden mit einem Status-Icon dargestellt.

Verwante Muster

  • Attention Screen
  • Activity Log

Mow to Maintain Asynchronous Group Awareness

Deutsch: Wie man Asynchron-Gruppenbewusstsein beibehält.

ACTIVITY LOG

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
ACTIVITY LOG

Absicht

Informationen über die Aktivitäten verschiedener Nutzer in einem Log zu speichern und so eine Historie der Aktivitäten und der Entwicklung des Inhalts zu erhalten.

Context

Nutzer führen parallele Aktivitäten im gleichen Arbeitsraum durch ohne sich wirklich sicher über die Effekte auf andere Nutzer zu sein.

Problem

Die Aktivitäten zweier Nutzer zusammenzuführen ist nicht immer ganz leicht. Die Aktivitäten müssen in den gleichen Kontext transferieret werden und auf die gleichen Ziele ausgerichtet werden. Allerdings ist dieser Prozess fehleranfällig und findet oft überhaupt nicht statt, da der aufwand meist den Nutzen übersteigt.

Szenario

Paul behält einen guten überblick über die Spiele Engine, während James sich gleichzeitig nur mit der Spracherkennung auskennt. James möchte nun etwas zeit in die Sicherheit investieren, hier ist Paul involviert. Die einzige Möglichkeit wie er mer über den Fortschritt in diesem Bereich erfahren kann ist Paul zu fragen. Paul möchte aber nicht die gleichen Geschichten immer und immer wieder erzählen.

Symptome

Dieses Muster kann angewendet werden wenn...

  • Nutzer merken oft das sich ein Projekt geändert hat, haben jedoch nicht mehr den Stand vor der Änderung in Erinnerung.
  • Nutzer können nicht ermitteln wer inkorrekte Änderungen vorgenommen hat und was diese Änderungen waren.
  • Nutzern erschließt sich nicht was Nutzer X gestern an Projekt Y geändert hat.
  • Nutzer verstehen die Änderungen anderer Nutzer nicht.

Lösung

Zeichne alle Änderungen auf, nicht nur Modifikationen, sondern auch Zugriffe. Stellen sie dieses Logbuch allen zur Verfügung.

Dynamik

Das Logbuch ist ein Container der Aktivitäten aufzeichnet. Anwendungen interagieren mit dem Log indem sie Aufzeichnungen über Aktivitäten hinzufügen, abrufen oder in Schleifen einreihen. Aktivitäten werden auf verteilten Daten angewendet und durch Requests eines User-Interfaces repräsentiert. Ein Beispiel wäre eine Anfrage aus einem Texteditor heraus eine Datei zu speichern. Um Aktivitäten zu erkennen benötigt eine Applikation eine weitere Schicht zwischen der Applkation und den zu bearbeiteten Daten. Aufzeichnungen beinhalten Daten über:

  • Typ der Aktivität (Lesen, Schreiben, Bearbeiten, Erstellt, Entfernt usw.)
  • Das Projekt das bearbeitet wurde. Oft in mehreren Revisionen, vor und nach der bearbeitung.
  • Den Zeitpunkt der Aktivität
  • Den Nutzer von dem diese Aktivität ausging.

In manchen Systemen beinhalten diese Aufzeichnungen auch noch einen Kommentar des Nutzers. Aufzeichnungen sollten sich weiterhin auf einzelne Transaktionen mit dem System beziehen, zum Beispiel das auswählen eines Menüpunktes oder das einfügen eines neuen Absatzes oder das Betrachten einer Website im Browser. Die Aufzeichnungen sollten zeitnah zu der Aktivität des Nutzers abgespeichert werden.

Begründung

Das Aufzeichnung aller Aktivitäten vereinfacht es diese Später genauer zu betrachten. Dies hilft den Überblick über die Entwicklung eines Projektes zu behalten. Da das Logbuch persistent ist behält es auch dann die Informationen wenn sie der Nutzer längst vergessen hat. Ein ACTIVITY LOG geht in zwei wesentlichen Punkten über eine einfache Versionskontrolle hinaus.

  • Es werden auch Zugriffe aufgezeichnet die das Projekt nicht direkt verändert haben. Dies ist zwar nicht direkt für den Fortschritt relevant, hilft jedoch den Hintergrund einer Aktivität zu verstehen.
  • Ein ACTIVITY LOG stellt mehr Hintergrundinformationen bereit zu Aktivitäten die mit einem bestimmten Projekt im Zusammenhang stehen.

Check

Folgende Fragen sollten beantwortet werden wenn dieses Muster angewendet wird:

  • Gibt es einen Zentralen Server wo das Logbuch abgespeichert werden kann? Wenn nicht wie wird das Logbuch zwischen den Nutzern verteilt?
  • Wer Erstellt das Aktivitätsobjekt? Der Client oder der Server? Welche Informationen sind zur Initialisierung nötig?
  • Welche Informationen über Aktivitäten werden an den Server gesendet?
  • Wie sollen effiziente Warteschlangen unterstützt werden? Wie soll eine übermäßige Anzahl an Aktivitäten behandelt werden? Kann eine Datenbank verwendet werden um Aktivitäten zu Speichern?
  • Sind die Nutzer damit einverstanden dass ihre Aktivitäten überwacht werden? Was passiert wenn ein Nutzer nicht überwacht werden will?

Gefahrenpunkte

Stelle sicher das viele Nutzer gleichzeitig Informationen zu dem Log hinzufügen können. Eine Möglichkeit dies sicherzustellen ist das Log als LOVLEY LOG zu modellieren. Wenn sich im Log auf Projekte bezogen wird muss sichergestellt werden das sich auf die korrekte Version bezogen wird. Beachte das ein ACTIVITY LOG nur Neuerungen speichern kann über die es auch informiert wird. Bei Manchen Programmen kann das eventuell nur die Erstellung einer neuen Dateiversion sein. Hier sollte die Applikation überwacht und Beobachtet werden um so viele Informationen wie möglich zu Speichern. Stelle sicher das der Nutzer weiß dass er überwacht wird. Nutzer sollten für sich selbst entscheiden können ob sie diese Überwachung zulassen oder nicht. Sie sollten auch verstehen das die Überwachng ihrer Aktivitäten einen Mehrwert darstellt, zum Beispiel nach dem Prinzip von RECIPROCITY.

Bekannte Nutzer

  • CVS
  • VisualWorks Smalltalk
  • NESSIE
  • TUKAN

Verwante Muster

  • Centralized Objects
  • Distributed Command
  • Login
  • User List
  • Model-View-Controller
  • Change Log
  • Edition

TIMELINE

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
TIMELINE

Absicht

Die Aktivität eines Nutzers zu einem bestimmten Zeitpunkt darstellen.

Context

Ihr System unterstützt langfristige synchrone oder asynchrone Interaktion.

Problem

Nicht alle Nutzer nehmen ununterbrochen an einer gemeinsamen Sitzung teil. Dies erschwert das Verständnis wer mit wem und mit was interagiert. Ohne dieses Verständnis fehlt den Nutzern die nötige Übersicht zur Gruppenarbeit.

Szenario

Maurice versucht zu verstehen was Paul und seine Kollegen implementiert haben während Maurice im Urlaub war. Er weiß das andere Entwickler ihre Arbeitsstrategien bereits besprochen haben und die Arbeit untereinander aufgeteilt haben. Er entscheidet sich die Änderungshinweise zu studieren die per E-Mail verteilt wurden, anschließend fehlt ihm jedoch immer noch eine Allgemeine Übersicht über die Entwicklungsaktivitäten.

Symptome

Dieses Muster kann angewendet werden wenn...

  • Nutzer sich beschweren das andere nichts zur Arbeit beitragen, selbst wenn diese doch etwas tun.
  • Nutzer nehmen nicht mehr am Projekt teil, dies kommt jedoch nicht bei der restlichen Gruppe an.

Lösung

Stelle die Aktivitäten im Arbeitsbereich als Timeline dar.

Dynamik

Eine Timeline ist ein zweidimensionales Diagramm dass die Zeitlinie mit dem Projekt oder den Aktivitäten einzelner Nutzer verknüpft. Jede Aktivität wird dabei von einem Punkt oder einem Icon repräsentiert. Verschiedene Icons repräsentieren dabei verschiedene User. Wenn auf einer Achse verschiedene Nutzer dargestellt werden sollte über verschiedene Icons für unterschiedliche Projekte nachgedacht werden. Nutze dynamische Datenvisualisierung wie z.B. DATATIPS oder LOCAL ZOOMING und die Darstellung von langen Aktivitäten mit verschiedenen Ressourcen zu visualisieren. Verbinde die Aktivitäten gleichzeitig mit den Dokumenten die bearbeitet wurden, so kann die Timeline zur Navigation durch die Entwicklungsschritte genutzt werden.

Begründung

Die Darstellung der Gruppenaktivitäten unterstützt Nutzer dabei diese besser zu verstehen. Es vereinfacht gleichzeitig das Verständnis wer wann und mit welcher Ressource aktiv war.

Check

Wenn dieses Muster angewendet wird sollten folgende Fragen beantwortet werden...

  • Sind die Nutzer oder die Ressourcen interessanter? Sollen die Nutzer oder die Ressourcen in einer Achse angezeigt werden?
  • Wie sollen Elemente Codiert werden? Ist es sinnvoll verschiedene Farben oder Icons zu verwenden?
  • Können Tooltips mit weiterführenden Informationen zu den Aktivitäten angezeigt werden?
  • Können die Punkte im Diagramm direkt mit den Ressourcen verknüpft werden.
  • Soll Zoomen unterstützt werden oder soll die Timeline statisch sein?

Gefahrenpunkte

Die Daten mit der höheren Kardinalität sollten für die Y Achse verwendet werden. Ein Problem kann auch die Skalierbarkeit sein. Eine Timeline kann weniger effektiv werden wenn wenn sehr häufig Änderungen an verschiedenen Ressourcen durchgeführt werden.

Bekannte Nutzer

  • Virtual School
  • Babble Timeline
  • CVS History Explorer

Verwante Muster

  • Replay
  • Periodic Report
  • Activity Log
  • Aliveness Indicator
  • Immutabel Versions
  • Dynamic Queries

PERIODIC REPORT

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
PERIODIC REPORT

Absicht

Informiert die Benutzer über Veränderungen von Relevanten Artefakten in einer vordefinierten Frequenz.

Context

Benutzer können asynchron voneinander an gemeinsam Benutzten Objekten arbeiten (kollaborieren)

Problem

Veränderungen bei dieser Art von Kolaboration sind nur sichtbar wenn man das veränderte Objekt betrachtet. Als Benutzer will man auf solche Aktionen reagieren können, jedoch ist es nicht möglich vorherzusagen, wann diese Aktionen stattfinden.

Szenario

Beim Schreiben eines Tweets auf Twitter kann man direkt Leute ansprechen (@user). Nun hofft man in absehbarer Zeit eine Antwort auf seinen Tweet zu bekommen. Zu Beginn überprüft man alle 5 Minuten ob ein neuer an sich gerichteter Tweet geschrieben wurde.


Symptome

Dieses Muster kann angewendet werden wenn...

  • Benutzer oft nach Aktualisierungen suchen aber selten welche finden.
  • Kollaboration länger dauert als gewünscht, da Benutzer zu selten nach Aktualisierungen schauen.
  • Eine direkte Benachrichtigung über alle Änderungen zuviel Aufmerksamkeit erregt.

Lösung

Informiere die Benutzer in periodischen Abständen über Änderungen die zwischen dem aktuellen Zeitpunkt und dem letzten Bericht geschehen sind.

Dynamik

Benutzer legen basierend auf ihren Zugriffsrechten ein Interessenprofil an und definieren das Interval mit dem sie über Neuerungen informiert werden möchten. Wenn das Interval vorbei ist, generiert das System einen Bericht der alle Aktivitäten seit dem letzten Bericht umfasst. Dabei kann das System die neuen Aktivitäten auf zwei Wege feststellen: 1. Das System nutzt Timestamps 2. Das System führt ein ACTIVITY LOG und erstellt eine Anfrage an dieses für Aktivitäten die im entsprechenden Zeitraum stattgefunden haben.


Begründung

Benutzer werden informiert über Neuigkeiten, das erlaubt es Ihnen sich auf Änderungen anderer Benutzer zu reagieren. Andere Benutzer können in etwa Abschätzen wie lange es dauert bis der Bericht den Benutzer erreicht und dadurch abschätzen, wann sie selbst eine Reaktion bekommen.


Check

Wenn dieses Muster angewendet wird sollten folgende Fragen beantwortet werden...

  • Wie oft finden Veränderungen statt und wie lange sind Benutzer bereit zu warten bis ihre Änderungen bemerkt werden?
  • Wie lassen sich Aktivitäten im Report-Format darstellen (E-Mail?). Ist es möglich URLs anzugeben die direkt auf die Änderungen verlinken?
  • Was ist die beste Zeit Berichte zu senden?
  • Wie stellen Benutzer den Bericht ab?
  • Wie können Benutzer Kriterien für ihren Bericht spezifizieren?

Gefahrenpunkte

Der Bericht könnte als Spam angesehen werden. Leere Berichte sollten vermieden werden, jedoch könnten Benutzer denken, dass ihr Bericht verloren gegangen ist.


Bekannte Nutzer

  • Foren wie Yahoo!Groups
  • Amazon sendet regelmäßig Berichte über neue Artikel in zuvor Besuchten Artikelgruppen

Verwante Muster

  • Attention Screen
  • Change Indicator
  • Activity Log

CHANGE INDICATOR

Absicht

Anzeigen, dass ein gemeinsam genutztes Objekt geändert wurde.

Context

Benutzer arbeiten an unabhängigen Kopien des gleichen Objekts

Problem

Benutzer prüfen relativ selten, ob Änderungen an der eigenen Kopie des Objektes vorliegen. Es besteht die Gefahr, dass dadurch konfligierende Änderungen mit einem anderen Objekt entstehen.

Szenario

Ein Entwickler macht Änderungen an einer API-Funktion. Ein anderer Entwickler der die API gut kennt überprüft beim Benutzen der API nicht auf möglicherweise neue Updates dieser und läuft somit gefahr, beim Update einen Konflikt zu produzieren.

Symptome

Dieses Muster kann angewendet werden wenn...

  • Benutzer Änderungen an Objekten machen wollen die auf einem alten Status des Objekts basieren
  • Benutzer Objekte oft verändern
  • Benutzer melden, dass sie anders entschieden hätten, wären sie über den aktuellen Status des Objekts informiert gewesen.

Lösung

Sobald eine Änderung eines Objektes gemacht wird wird dies allen anderen Benutzern angezeigt sobald sie das Objekt ansehen. Dabei könnten Informationen über den Typ der Änderungen angezeigt werden.

Dynamik

  • Graphic


Begründung

Es gibt zwei Gründe warum dieses Pattern funktioniert:

  • Technischer Aspekt: Durch den Indikator verkürzt sich die Zeit bis der Änderungen integriert werden. Benutzer werden dadurch möglichst frühzeitig, wenn sie weitere Arbeit auf einem Objekt basieren, möglichst frühzeitig die Änderungen zu integrieren.
  • Kognitiver Aspekt: Text

Check

Wenn dieses Muster angewendet wird sollten folgende Fragen beantwortet werden...

  • Wie zeigt man die Änderung an? Kann man eine Info zu dem Icon anzeigen der die Änderung signalisiert?
  • Wie früh zeigt man Benutzern die Änderungen an?

Gefahrenpunkte

Leute könnten die Anzeige ignorieren und Objekte und Änderungen überschreiben. Es muss ein Protokoll geben wie mit CHANGE INDICATIONS umgegangen wird.

Bekannte Nutzer

  • Microsoft Team Foundation Server zeigt direkt hinter der Datei im Quellcodebrowser an, ob Änderungen vorliegen.

Verwante Muster

  • Active Neighbours
  • Activity Log
  • User List

ALIVENESS INDICATOR

Absicht

Einen Indikator in der virtuellen Umgebung erstellen, der die Aktivität von einzelnen Benutzern wiederspiegelt.

Context

Benutzer arbeiten asynchron an Kopien des gleichen Objekts oder in geteilten virtuellen oder nicht virtuellen Kollaborationsumgebungen.

Problem

Benutzer die hauptsächlich ansynchron arbeiten erleben nur einen Bruchteil der Aktivitäten die in der Kollaborationsplattform stattfinden. Insbesondere ist es nicht möglich zu Erfahren ob andere Benutzer während der eigenen Abwesenheit aktiv waren.

Szenario

Ein Entwickler führt ein Projekt mit mehreren Entwicklern. Nach einer Woche möchte er an einem Problem weiterarbeiten, dass er zuvor angefangen hat. Er möchte wissen, ob ein anderer Entwickler in der Zwischenzeit an seinem Problem weitergearbeitet hat.

Symptome

Dieses Muster kann angewendet werden wenn...

  • Benutzer sich beschweren, dass andere Benutzer gestoppt haben Aktivitäten wahrzunehmen, obwohl es Benutzer gibt die nach wie vor der Interaktion folgen.
  • Benutzer fragen die ganze Gruppe, ob sie noch immer aktiv sind.
  • Benutzer sich gegenseitig auffordern die Kollaborationsumgebung aufzusuchen, sich aber nicht sicher sind ob die anderen der Bitte gefolgt sind.

Lösung

Zeige einen Aliveness Indikator zusammen mit dem Profil des Benutzers. Für Benutzer die vor kurzem erst aktiv waren, nutze ein Bild welches sehr "aktiv" aussieht. Je weniger der Benutzer aktiv war, desto weniger "aktiv" sollte das Bild aussehen.

Dynamik

Das System muss die letzten Aktionen der Benutzer in einer Timeline sichern. Wenn ein Benutzer dargestellt werden soll, berechnet die Plattform wann die letzte Aktivität des Benutzers zu vermelden war und zeigt dementspechend ein Symbol im Profil des Benutzers an. In eStudy wird hier ein Aktivitätsbalken im Profil eingeblendet der die Farbe von Scharz bis Grün annehmen kann.

Eine Entscheidung die zu treffen ist, ist ob der Indikator nur für einzelne Benutzer gilt oder für ganze Bereiche einer Kollaborationsplattform.


Begründung

Das Wissen über die Aktivität anderer Benutzer hilft beim Verständnis, wie eng eine Gruppe zusammen arbeitet. Es zeigt insbesondere, welche Benutzer in letzter Zeit aktiv waren und welche nicht. Indikatoren mit unterschiedlichen Scopes können helfen ganze Bereiche eine Plattform auf Aktivität hin zu überprüfen.

Check

Wenn dieses Muster angewendet wird sollten folgende Fragen beantwortet werden...

  • Wie wird der Indikator grafisch Dargestellt?
  • Werden unterschiedliche Scopes unterstützt? Welche Scopes sind das?
  • Welcher Zeitrahmen wird genutzt um die Aktivität zu Berechnen?


Gefahrenpunkte

Leute könnten die Anzeige ignorieren und Objekte und Änderungen überschreiben. Es muss ein Protokoll geben wie mit CHANGE INDICATIONS umgegangen wird.

Bekannte Nutzer

  • XING zeigt am Rand des Profils die Aktivität einzelner Benutzer an.

Anwendung in eStudy

Jede Profilseite beinhaltet einen Aliveness Indicator.

Verwandte Muster

  • Change Indicator

AWAY MESSAGE

Intent

Informiere den Benutzer, dass die Antwort zu einer Anfrage sich verzögern wird.

Context

Benutzer interagieren in einem Request-Response-Schema auf verschiedenen Synchronitätsstufen miteinander.

Problem

Benutzer erwarten oft, dass ihre Interaktionspartner auf ihre Aktionen schnell antworten. Manchmal ist jedoch nicht möglich, dass der Interaktionspartner schnell antworten kann. Je länger ein Benutzer auf die Antwort seines Interaktionspartnerswarten muss, desto größer wird auch seine Frustration.

Scenario

Mario stößt bei der Benutzung einer Grafikkomponente der Game-Engine auf ein Problem, weshalb er Carla eine Frage stellt. Normalerweise antwortet Carla schnell, aber gegen Abend und Ende des Arbeitstages hat er immer noch keine Antwort erhalten.

Symptoms

Die Verwendung dieses Musters kann in Erwägung gezogen werden, wenn:

  • Absender die Empfänger befragen, ob sie ihre Nachricht erhalten haben, da sie immer noch keine Antwort erhalten haben.
  • Absender auf eine Aktion des Empfängers warten, aber die Aktion nicht eintrifft.
  • Absender einer Nachricht üblicherweise schnelle Antworten ihrer Interaktionspartner erwarten basierend auf deren bisheriger Erfahrung bzw. dass sie ein gewisses Entgegenkommen von ihrem Interaktionspartner erwarten.
  • Benutzer ab und an ihren Interaktionsraum verlassen.

Solution

Lasse das GroupWare-System auf eine Kommunikation anhand automatischer "Away messages" antworten, wenn eine normale Antwortzeit nicht garantiert werden kann. Stelle Informationen zur Verfügung, wann mit einer Antwort gerechnet werden kann.

Dynamics

Das "Away Message" - Muster stellt einen dreistufigen Prozess dar:

Einrichten: Der Benutzer erstellt bevor er seinen Arbeitsplatz verlässt eine "Away Message" und hinterlässt dabei eine Nachricht hinterlässt, warum er nicht antworten kann und wann er wieder zurück sein wird.

Ausführung: Wenn ein Absender zu seinem abwesenden Empfänger sendet, antwortet das System des Empfängers automatisch mit der "Away Message".

Abschalten: Wenn der abwesende Benutzer wieder an seinem Arbeitsplatz angekommen ist, wird das Versenden der "Away Message" deaktiviert.

Rationale

Die Kernidee dieses Musters ist, dass der Benutzer eine ungefähre Einschätzung davon erhält, wie lange er auf die Antwort seines Interaktionspartners warten muss. Wird eine Nachricht nicht innerhalb der zugesicherten Zeit beantwortet, kann dies als ein Zusammenbruch der Kollaboration verstanden werden,wodurch eine Reorganisation der Kollaboration eintreten kann um das Ziel der Kollaborationspartner zu erreichen.

Check

Wenn dieses Muster angewendet werden soll, dann sollten diese Fragen gestellt werden:

  • Wie soll die "Away Message" konfiguriert werden?
  • Wie kann zugesichert werden, dass die "Away Message" alle notwendigen Informationen enthält?
  • Sollen Abwesende nach ihrer Rückkehr an ihren Arbeitsplatz darüber informiert werden, welche Absender eine "Away Message" erhalten hat?

Danger Spots

Ein Problemgebiet von "Away Messages" ist, dass sie oft die zweiseitige Kommunikation nicht von der Gruppenkommunikation unterscheiden.Beispielsweise wenn in einem Forum kommuniziert wird und das Forum-System eine Nachricht an einen abwesenden Benutzer sendet, könnte das das System des Abwesenden mit einer "Away Message" antworten.Diese wird jedoch an alle Empfänger der Mailingliste gesendet anstatt an einen einzelnen. Eine weitere Angelegenheit ist, dass der Abwesende nicht vorhersagen kann, welche Interaktionspartner eine "Away Message" erhalten werden, in der wertvolle Information enthalten sein kann und die Fremde Personen nicht lesen dürfen.

Known Uses

Instant Messengers (á la) Miranda: Ein moderner Instant Messenger erlaubt i.d.R. solche Arten von "Away Messages" zu erstellen. Benutzer, die eine Nachricht an einen Abwesenden senden, erhalten i.d.R. die vom Abwesenden vorher definierte "Away Message".

Related Patterns