CMI-Entwurfsmuster: Community Support

Aus THM-Wiki
Version vom 30. November 2010, 08:24 Uhr von U13135 (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
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 "Community Support" beschrieben.

Inhaltsverzeichnis

Welcome me... or how to arrive in the community

Quick Registration

Intent

Der Beitritt eines Nutzers in eine Gemeinschaft muss für diesen so einfach wie möglich gestaltet werden, bei gleichzeitigem Sicherstellen, die Mitglieder der Gemeinschaft mit dieser Registrierung gegenüber Gemeinschaftsfremden abzugrenzen.

Context

Eine Gemeinschaft, die offen für den Beitritt neuer Nutzer ist, intendiert eine Vielzahl aktiver Nutzer und den dadurch hervorgehobenen Verstärkungsprozess der Gemeinschaft. Aus der Sichtweise von Nichtmitgliedern besteht allerdings zunächst die Zielsetzung, mehr über die Gemeinschaft zu erfahren.

Problem

Dem Gemeinschaftsziel, neue Nutzer so schnell wie möglich an die Ziele und Normen der Gemeinschaft zu binden, steht aus den o.g. Gründen der initiale Vorbehalt neuer Nutzer gegenüber, sich umgehend an die Gemeinschaft zu binden, da einerseits das Vertrauen in die neuen Verbindungen und die Erkenntnis über den eigenen Nutzen fehlt und andererseits noch keine Klarheit darüber besteht, wie stark man als neuer Nutzer in die Gemeinschaft eingebunden sein möchte.

Scenario

Folgendes Szenario kann zur Beschreibung dieser Sachverhalte herangezogen werden: Gudrun hat sich die gemeinschaftliche Spielumgebung heruntergeladen und in diesem Zusammenhang festgestellt, dass es eine Online-Gemeinschaft für Nutzer und Entwickler gibt. Sie überlegt, dieser Gemeinschaft beizutreten und ruft die Registrierungsseite auf. Dort wird sie mit einem langen Fragebogen empfangen, welchen Sie ausgedruckt und unterschrieben in die Vereinigten Staaten faxen muss, um Mitglied der Gemeinschaft zu werden. Angesichts dieser umständlichen Prozedur und dem Vorbehalt, so viele private Daten lediglich für die Mitgliedschaft in dieser Gemeinschaft preiszugegeben, entscheidet Gudrun sich gegen einen Beitritt.

Symptoms

Das hier beschriebene Pattern kann daher verwendet werden, wenn folgende Umstände vorliegen:

  • Nutzer sind zurückhaltend bei der Preisgabe privater Daten
  • die Gemeinschaft versteht sich als offen für neue Nutzer und hat das Ziel schnell zu wachsen
  • Nutzer beginnen vielfach die Registrierung, schließen sie aber (auch aus o.g. Gründen) nicht ab

Solution

Aus oben genannten Gründen soll die Registrierung mit so wenig wie dazu notwendiger Nutzerinformation möglich sein. Das Konto eines frisch registrierten, noch nicht bestätigten Nutzers unterscheidet sich im Funktionsumfang von den Möglichkeiten Fremder, sodass für den neuen Nutzer eine Art Test der Gemeinschaft möglich ist. Erst nach der Bestätigung durch den neuen Nutzer selbst und ggf. eine gemeinschaftsseitige Überprüfung wird das Konto in eine vollständige Mitgliedschaft umgewandelt.

Dynamics

Folgender Ablauf hat sich als bewährt erwiesen: Beim Start des Systems besteht die Wahl eines Logins oder der Anforderung eines neuen Logins. Soll die Aktivität nur für eine Sitzung gültig sein, kann ein zufälliger Name vom System vorgegeben werden.
Soll es möglich sein, sich über mehrere Sitzungen an- und abmelden zu können, muss ein Name und ein Passwort angefordert werden. Hierbei sollte bedacht werden, dass der Anmeldename durchaus einzigartig sein muss. Des Weiteren ist es notwendig, dass das Konto in der Gemeinschaft mit einer realen Identität belegt ist. Zu diesem Zweck kann eine Emailadresse angefordert werden.
Damit wird es nun für den neuen Nutzer möglich, die Gemeinschaft zu betreten und in beschränktem Umfang diese nutzen.
Um eine Mitgliedschaft in eine vollwertige umzuwandeln, muss der Nutzer sich authentifizieren. Dazu kann ein Verifikationslink an die hinterlegte Emailadresse versendet werden, welcher vom Nutzer bestätigt werden muss. Im Falle höherer Sicherheitsstufen kann der Postweg oder eine Treuhandform verwendet werden.
Nach erfolgter Bestätigung des Nutzerkontos kann die Plattform dann vom Nutzer im vollen Umfang verwendet werden.

Rationale

Das beschrieben Vorgehen hat somit einige Vorteile: Je weniger private Daten erhoben werden, desto bereitwilliger sind neue Nutzer die restlichen Daten anzugeben. Damit können diese entscheiden, wie viele Daten sie preisgeben müssen. Generell sollten nur Daten erhoben werden, die einer Verwendung entsprechen, optionale Angaben sollte daher als solche gekennzeichnet werden. Das erlaubt einem neuen Nutzer, die Plattform kennenzulernen, bei gleichzeitiger Absicherung der Plattform gegenüber neuen, als solchen gekennzeichneten Nutzern.

Check

Bei der Verwendung des beschrieben Musters sollte folgende Umstände berücksichtig werden:

  • Der Ablauf der Verifikation wurde überlegt und sichergestellt, dass eine Emailverifikation machbar ist.
  • Die Möglichkeiten eines unbestätigten Nutzers wurde überdacht und eingeschränkt.
  • Es wurde eine Möglichkeit vorgesehen, unbestätigte Nutzer zu kennzeichnen.
  • Wird es eine Einschränkung des Nutzerkreises geben?
  • Es wurde zusammengestellt, welche Informationen bei der Registrierung erhoben werden sollen und müssen.

Danger Spots

Folgende Aspekte sollte bedacht werden: Bei der Registrierung muss sichergestellt sein, dass der Prozess nur von Menschen ausgeführt werden kann und nicht ebenfalls von Computerprogrammen. Dies ist möglich über sog. Captchas, welche nur von Menschen identifiziert und rückgemeldet werden können.
Des Weiteren sollte die Möglichkeit bedacht sein, das es Kontonamen bereits vergeben sein können. Daher sollte neuen Nutzer im Fall, dass der Name bereits verwendet wird, ein naheliegender Alternativvorschlag unterbreitet werden.

Known Uses

Das beschrieben Pattern und seine Charakteristika werden von beispielsweise von folgenden Plattformen verwendet:

  • Google: hier wird die Registrierung mit einer Emailverifikation durchgeführt.
  • SpinChat: Zur Registrierung ist lediglich eine Nutzername sowie die Angabe des Geschlechts notwendig. Einen vollen Funktionsumfang erhält man mit der Angabe weiterer Daten.
  • PayPal: Besonderheit hier ist, dass zur Authentifikation auf die Bankdaten des neuen Nutzers gesetzt wird. In der Annahme, dass diese Daten nur dem anmeldenden Nutzer bekannt sind, transferiert PayPal ein kleine Menge an Geld auf das angegebene Konto, welche vom Empfänger bestätigt werden muss.

Related Patterns

Einige Muster sind verwandt mit dem hier beschrieben Anwendungsfall. Ist eine Zustimmung der Nutzer der Gemeinschaft notwendig, können diese mit Hilfe des BELL-Patterns notifiziert werden, neue Nutzer müssen erst „klingeln“. Das Verlassen einer Gruppe sollte ebenso einfach möglich sein, wie das hier beschriebene Betreten (QUICK GOODBYE).
Neue Nutzer sollte in einer Galerie erscheinen, damit sie nicht im Unbekannten verharren (USER GALLERY).
QUALITY INSPECTION stellt sicher, dass neue Nutzer zunächst von Gemeinschaftsmitgliedern überwacht werden und bei Missachtung der Gemeinschaftsregeln ausgeschlossen werden. Das LOGIN-Pattern wird im Anschluss besprochen und ist eine Fortführung des QUICK REGISTRATION-Pattern.
Ähnlich eines unbestätigten Nutzerkontos kann alternativ oder ergänzend ein GUEST ACCOUNT umgesetzt werden, damit neue potentielle Nutzer zunächst eine Möglichkeit haben, die Plattform kennenzulernen.

Realisierung auf der eStudy-Plattform

Für alle Interessenten ohne die U-Kennung besteht die Möglichkeit, sich mit einem kurzen Formular für eStudy anzumelden. Dieses Formular umfasst lediglich Angaben, welche notwendig sind.

QuickRegistration.png

Die Angaben werden geprüft (siehe auch QUALITY INSPECTOR) und nach erfolgreicher Prüfung wird dem Interessenten ein Bestätigungslink an die angegebene Emailadresse zugesandt, welcher spätestens nach drei Tagen genutzt werden sollte, da er ansonsten verfällt.

Bearbeitet von -- U13344 08:23, 30. Nov. 2010 (CET)

Login

Intent

Bevor Nutzer eine Applikation verwenden können, müssen Sie sich dieser gegenüber identifizieren.

Context

Die Kollaboration und Interaktion einer Plattform geschieht in Anonymität, soll aber nun persönlich erfolgen.

Problem

Generell wollten Nutzer einer Plattform als Personen miteinander arbeiten, vielfach wird dies aber nicht gewährt und die Nutzer auf Individuenbasis wahrgenommen.

Scenario

Folgendes Fallbeispiel beschreibt das Muster: Paulchen hat ein gemeinschaftliches Portal eingerichtet, in welchem jeder zur Planung der nächsten Version der Spieleumgebung beitragen kann. Unvorteilhafterweise können aber außer den Mitgliedern der Gemeinschaft auch Nutzer mit kontextfremden Zielen Einträge verfassen, und so finden sich nach eine Weile Werbung für Mittel zur Bildung versprochener Riesenextremitäten, Vorschläge für Banktransaktionen mit versprochenen Riesendividenden und andere riesig irrelevante Beiträge.

Symptoms

Unter folgenden Voraussetzungen sollte eine Verwendung bedacht werden:

  • Nutzer möchte private von öffentlicher Interaktion unterscheiden
  • Die Verteilung bestimmter Informationen soll überwacht und kontrolliert werden können
  • Nutzer würden gerne wissen, mit wem sie interagieren
  • Diese Interaktion soll sich über eine längere Zeit fortsetzen und so nicht in der Anonymität bleiben
  • Der Zugriff auf die Gemeinschaft soll von unterschiedlichen Orten möglich sein

Solution

Zur Lösung dieser Problematik ist es von Nutzer erforderlich, einen Namen und ein Passwort anzugeben, bevor Sie einen gemeinschaftlichen Bereich betreten und verwenden können.

Dynamics

Der folgende Ablauf beschreibt das Vorgehen des Musters: Zunächst wird er Nutzer mit einem Bildschirm empfangen, in welchem er seinen Benutzernamen und das zugehörige Passwort in zwei Eingabefelder eintragen kann. Das Eingabefeld für das Passwort sollte maskiert gestaltet sein. Des Weiteren kann der Nutzer nach Eintrag der Daten einen verfügbaren Button verwenden, um die Bestätigung auszuführen. Die Plattform kann nun anhand dieser angegebenen Daten und der hinterlegten Daten einen Abgleich durchführen.
Nach erfolgreichem Login stellt die Plattform ein Verfahren bereit, welches den Nutzer für alle nachfolgenden Aktionen als korrekten Nutzer verifziert, sodass dieser nicht noch mal einen Login für andere Bereiche ausführen muss. Damit ist der Nutzer eindeutig identifiziert und alle abfolgenden Aktionen können ihm zugeordnet werden.
Falls die angegebenen Daten nicht korrekt sind, wird der Nutzer darüber unterrichtet und ihm eine Möglichkeit geboten, das Passwort wiederherzustellen.
Des Weiteren stellt das System eine Möglichkeit bereit, sich abmelden zu können. In diesem Fall agiert das System, wie wenn der Nutzer nicht angemeldet ist.
Außerdem beinhaltet der Login-Bildschirm eine Möglichkeit für neue Nutzer, sich registrieren zu können, sowie die Möglichkeit, Anmeldename und Passwort wiederherstellen zu können.

Rationale

Zwecks des Umstandes, dass Nutzer eine gültige Kombination aus Anmeldenamen und Passwort angeben müssen, ist der zu betretende Gemeinschaftsbereich ein zutrittsbeschränkter Bereich, der Information darüber hält, wer von einem bestimmten Computer in einer bestimmten Sitzung agiert.
Damit wird die Interaktion auf ein nicht-anonymisiertes Level gehoben, welches erlaubt, soziale Verbindungen herzustellen und angepasst auf den jeweiligen Nutzer ein künstliches Ich anzuzeigen. Das hat zur Folge, dass klar eingesehen werden kann, wer Mitglied einer Gemeinschaft ist und wer nicht.

Check

Bei der Anwendung des beschriebenen Patterns sollte folgende Frage bedacht worden sein:

  • Ist es für Nutzer möglich oder notwendig, das Passwort (periodisch) zu ändern?
  • Gibt es Regeln, nach denen ein Passwort konstruiert sein muss, um die Sicherheit zu erhöhen?
  • Wie werden Passwort und Nutzername übertragen, geschieht dies über eine verschlüsselte Verbindung?
  • Wo findet sich der Nutzer nach dem Login wieder, gibt es einen personalisierten Startbildschirm oder einen gemeinsamen Bereich für alle Mitglieder
  • Wo können Nutzerinformationen abgerufen werden und wo besteht die Möglichkeit, sich von System abzumelden?
  • Wie wird die Passwortwiederherstellung umgesetzt?

Danger Spots

Die Eingabe von Passwörtern für jeden Login ist möglicherweise etwas umkomfortabel für den Leser, daher sollte die Möglichkeit geboten werden, die Kombination lokal zu speichern und automatisch eintragen zu lassen. Das kann aber zur Folge haben, dass Passwörter von Nutzer vergessen werden. Daher bestehen folgende Möglichkeiten der Wiederherstellung:

  • Verwendung einer Sicherheitsabfrage, die vom Nutzer korrekt beantwortet werden muss
  • Die Zustellung eines neuen und vom Nutzer zu ändernden Passwortes bei Email. Hierbei ist darauf zu achten, dass nicht Nutzername und Passwort gemeinsam gesendet werden.
  • Die Zustellung eines einmaligen Loginpasswortes, welches vom Nutzer geändert werden muss.

Known Uses

Folgende Plattformen verwenden das hier beschrieben Prinzip:

  • Ebay: Nach dem Login kann mit anderen Nutzern der Plattform ein Auktionshandel durchgeführt werden
  • Planeshift
  • ICQ, Yahoo Messenger, MSN Messenger, Skype: Die Logindaten können gespeichert werden und ein Einloggen funktioniert in diesem Fall automatisch
  • HTTP Authentication: Diese Technik ist allerdings recht unsicher, jeder, der den Übertragungskanal überwacht, kann die Daten mitlesen. Des Weiteren ist es schwierig den Browser die Daten wieder „vergessen“ zu lassen. Das kann mit dem Einloggen eine anonymen Nutzers umgangen werden.

Related Patterns

Das vorangehend beschriebene QUICK REGISTRATION bildet die Grundlage des hier beschriebenen Musters. SECURITY SESSION beschreibt wie die Phase zwischen Login und Logout unter sicherheitsrelevanten Aspekten durchgeführt werden kann. HANDLES beschäftigt sich mit der Notwendigkeit eines einzigartigen Logins für Mehrspielerspiele. SIGN-IN/NEW ACCOUNT befasst sich mit der Handhabung von Nutzerkonten und wie mit verlorenen Konten umgegangen werden kann. LOGIN existiert ein zweites Mal, hier mit Fokus auf einen Webkontext. PASSWORD DESIGN AND USE befasst sich mit der Gestaltung von Passwörtern und deren Erneuerungszyklen. SINGLE ACCESS POINT stellt Überlegungen bereit, dass der Zutritt lediglich über einen Knotenpunkt läuft. AUTHENTICATOR prüft die Identität eines sich einloggenden Nutzers.

Realisierung auf der eStudy-Plattform

Es bestehen zwei Möglichkeiten, sich auf eStudy einzuloggen: Ein zentraler Login, welcher den Nutzer gleich für alle weiteren FH-Communities anmeldet und eine lokaler Login, der nur das Anmelden auf der eStudy-Plattform vollzieht. Beide Logins sind nach den hier beschriebenen Richtlinien gestaltet und enthalten zwei Eingabefelder zur Eingabe der Kennung und des Passwortes, sowie einen Button zum Abschicken der eingebenen Kombination. Des Weiteren besteht durch 3 weitere Schaltflächen die Möglichkeit, sich entweder neu für die Plattform zu registrieren, ein neues Kennwort anzufordern, sowie den Helpdesk zu kontaktieren.

LoginEStudy.png

Bearbeitet von -- U13344 08:24, 30. Nov. 2010 (CET)

Welcome Area

Intent

An einer bedeutenden Stelle werden alle neuen Mitglieder einer Community oder einer Gruppe aufgelistet und vorgestellt.

Context

Durch die Gründung einer Gruppe und deren ersten Nutzer wurden soziale Bindungen geschaffen, wodurch die Gruppe ihre Identität findet. Mitglieder dieser Gruppe grenzen sich von nicht-Mitgliedern dieser Gruppe ab.

Problem

Will eine Gruppe Fortschritte machen, so muss diese neue Mitglieder für sich gewinnen. Gruppenmitglieder die nur auf Internes fokussiert sind, könnten das Potential und den Beitrag, den neue Mitglieder leisten könnten, nicht wahrnehmen.

Scenario

Mario ist ein neues Mitglied in der Community. Er bekommt mit, dass zwischen Paul und Ana eine anhaltende Diskussion vorliegt, versteht jedoch nicht, worum es geht. Die beiden anderen Mitglieder scheinen schon lange dabei zu sein und nutzen Konventionen und Begriffe, die außerhalb dieser Gruppe nicht verwendet werden. Auf der einen Seite weiss Mario nicht, wie er sich Paul und Ana annähern soll, auf der anderen Seite haben Paul und Ana nicht mal mitbekommen, dass Mario der Community beigetreten ist.

Symptoms

Die Anwendung dieses Patterns sollte geprüft werden, wenn

  • sich Langzeitmitglieder eine große gemeinsame Geschichte teilen, in welchen neue Mitglieder keine Rolle spielen.
  • die Community so groß ist, dass Langzeitmitglieder bereits eine Subgruppe bilden.
  • neue Mitglieder es schwierig finden, der Gruppe beizutreten.
  • neue Ideen, welche die Community vorwärts bringen würden von neuen Mitgliedern geboten werden, diese jedoch von den alten Mitgliedern ignoriert werden.

Solution

Die Lösung für dieses Problem ist sehr simpel. Eine markante Stelle in der Community sollte dafür verwendet werden, neue Mitglieder und ebenfalls deren neue Ideen vorzustellen. Hierdurch wird erreicht, dass jede neue Mitgliedschaft auch von der ganzen Community wahrgenommen wird.

Dynamics

Die Neuankömmlinge in der Gruppe stellen sich selbst in der "Welcome Area" vor und legen dar, warum sie Teil der Gruppe sein wollen. Die "Welcome Area" zeichnet sich dadurch aus, dass sie ein markanter Bereich innerhalb der Community ist. Die Veteranen der Gruppe teilen eine lange Interaktionsgeschichte innerhalb der Community, sind akzeptierte Mitglieder und halten viele soziale Verknüpfungen zu anderen Mitgliedern. Sie verpflichten sich dafür, die "Welcome Area" regelmäßig zu besuchen. In den Fällen, wenn die "Welcome Area" ein spezieller Zeitpunkt ist, verpflichten sich die Veteranen in der Community an diesem Zeitpunkt teilzunehmen.

Rationale

Seitdem Neuankömmlinge gebeten werden, sich selbst vorzustellen, besitzen diese ein Forum, in welchem sie ihre Ideen und Gedanken, die sie zum Gruppenbeitritt bewegt haben, niederschreiben können. Aufgrund dessen, dass alle neuen Mitglieder so handeln, fürchtet keiner mehr, dass sich bestehende Mitglieder gestört fühlen und des Weiteren nehmen alle Veteranen die neuen Mitglieder aufgrund ihrer Verpflichtung regelmäßig in der "Welcome Area" vorbeizuschauen, wahr. Der getrennte Bereich für diesen Inhalt bietet den Vorteil, dass dieser Abschnitt nicht in andere Abschnitte eingreift.

Check

Bei der Anwendung dieses Patterns sollten folgende Fragen beantwortet werden:

  • Wie können technisch gesehen neue Mitglieder erkannt werden? Gibt es einen Registrierungsprozess?
  • Wie lange sollten neue Mitglieder ein Teil der Gruppe sein, bevor sie gefragt werden, sich in der "Welcome Area" vorzustellen.
  • Macht es Sinn, dass Mitglieder selbst entscheiden, wann sie sich selbst vorstellen sollen? Wenn ja, wie entscheiden sie dies?
  • Macht es Sinn Mitglieder vorzustellen, die bis jetzt noch keine privaten Informationen bereitgestellt haben?
  • Kann die "Welcome Area" mit anderen Interaktionsbereichen verbunden werden, welche für die Veteranen von hoher Bedeutung sind? Zum Beispiel durch das Verbinden der "Welcome Area" mit einem Alumni-Event.

Danger Spots

Es ist möglich, dass neue Mitglieder nicht viel Aufmerksamkeit auf sich ziehen wollen, wenn sie der Gruppe beitreten. Möglicherweise wollen sie zuerst der Gruppe passiv zusehen und schauen, wie diese interagiert. In diesem Fall sollte die Willkommenszeremonie auf einen Zeitpunkt verschoben werden, an welchem das Mitglied aktiv an der Community teilnimmt. Bis zu diesem Zeitpunkt kann das Mitglied als unbestätigtes Mitglied agieren. (siehe QUICK REGISTRATION) Ein weiteres Problem ist es, die Veteranen dazu zu bekommen, der "Welcome Area" Aufmerksamkeit zu schenken. Dies kann durch ein Ranking (siehe HALL OF FAME) möglicherweise behoben werden.

Known Uses

www.visualbuilder.com ist eine Community von Software-Entwicklern, in welcher neue Mitglieder in der "Welcome Area" auf der Startseite aufgelistet werden.

www.communities.com erlaubt es Mitgliedern durch das Klicken auf "neues Mitglied" abgefragt zu werden. Durch das Klicken auf den neuen User werden weitere Informationen angezeigt.

www.xing.com ist eine kollaborative Umgebung für die Pflege von Beziehungen zu anderen Nutzern. Diese können der Buddy-List hinzugefügt werden. (siehe auch die Diskussion von XING im BUDDY LIST Pattern) Zusätzlich präsentiert das System jedem User eine Anzahl von neu angemeldeten Usern auf der Startseite.

Spiele auf EuroPLop sind spezielles Slots in einem Konferenzprogramm, in welchem sich die Teilnehmer für kooperative Spiele treffen. Diese sind dafür da, in Kontakt mit anderen zu geraten und bei Namensspielen deren Namen zu lernen.

Related Patterns

Nachfolgend werden zum eben beschriebenen Pattern verbundene Patterns vorgestellt: Das MENTOR Pattern behandelt die Verbindung zwischen Neuankömmlingen und Mentoren, welche diese "begleiten". Das MASQUERADE Pattern geht um die Möglichkeit, dass Nutzer sich zu Beginn anonym in der Community "bewegen" können. Im eben beschriebenen Pattern geht es um die Vorstellung der neuen Mitglieder wohingegen es im HALL OF FAME Pattern darum geht, einflussreiche Veteranen der Community vorzustellen. Die WELCOME AREA ist oft ein spezieller Bereich der USER GALLERY und somit direkt mit dieser verbunden. Das BIRDS OF A FEATHER Pattern beschreibt das gegensätzliche Problem wie man den Kontakt mit verbundenen halten soll, ohne von Neuankömmlingen und anderen Mitglieder gestört zu werden. Das BIG JOLT Pattern schlägt vor, Experten einzuladen und über seine Erfahrungen zu sprechen. Das Einladen in die "Welcome Area" kann zwei Zwecken dienen. Zum einen er erhält die "Welcome Area" einen besseren Ruf, und zum anderen lernen Neuankömmlinge mehr über die Ideen, welche die Community verbreitet. Das INTRODUCTION SESSION Pattern handelt von der Phase zu Beginn eines Seminars, in welchem sich genug Zeit genommen werden sollte, dass jeder sich selbst vorstellen kann. Das FACE TO FACE BEFORE WORKING REMOTELY behandelt das Thema des Kennenlernens vor einem entfernten gemeinsamem Arbeiten.

Realisierung auf der eStudy-Plattform

Die Realsierung dieses Patterns ist in eStudy zu sehen. Auf der Foyer-Seite, welche sicherlich regelmäßig von jedem Mitglied der Community besucht wird, sind immer die neuen Portalmitglieder zu sehen. (siehe nachfolgende Abbildung; roter Bereich)

Foyer-neue-Portalmitglieder.JPG

Durch einen Klick auf einen der neuen Mitglieder gelangt man zu seinem Profil, auf welchem seine Benutzerdaten angezeigt werden. Hier besteht die Möglichkeit dem Nutzer eine Nachricht zu schicken oder diesen auf die eigene Freundesliste zu setzen. Durch die Umsetzung des Patterns ist gesichert, dass jeder der neuen Nutzer auf der Foyer-Seite wahrgenommen wird.

Bearbeitet von -- U13135 08:24, 30. Nov. 2010 (CET)

Mentor

Intent

Dieses Pattern konzentriert sich auf die Verbindung eines Neuankömmlings mit einem erfahrenen Mitglied um den Einstieg zu erleichtern.

Context

Nach dem Entwerfen eines Umfelds für eine große Gruppe oder Community verändert sich die Mitgliederschaft ständig, deshalb muss über Wege nachgedacht werden, wie neue Mitglieder besser in die Gruppe integriert werden können.

Problem

Neue Mitglieder wissen nicht, wie die Community Mitglieder in bestimmten Situationen reagieren und welche Praktiken in der Gemeinschaft angewendet werden.

Scenario

Jeden Freitagabend treffen sich alle Mitglieder um über die Ergebnisse der Woche zu diskutieren. Mario, welcher neu in der Gruppe ist, wusste nichts davon und war deshalb nicht anwesend. Dies irritiert die Gruppe.

Symptoms

Die Anwendung dieses Patterns sollte geprüft werden, wenn

  • Neuankömmlinge Aufmerksamkeit erregen, weil ihr Verhalten erkannt wird.
  • Neuankömmlinge Probleme mit dem Verständnis der angewendeten best practices haben.
  • wenn Veteranen eine gängige Praxis für die Interaktion in der Gruppe etabliert haben.
  • es schwierig ist die Praktiken der Interaktionen in einem Text zu erklären, wie beispielsweise in den FAQ's. (siehe FAQ)
  • es große Unterschiede vom Expertenwissen zwischen den Gruppenmitgliedern gibt.

Solution

Durch die Verbindung von Neuankömmlingen und erfahrenen Mitgliedern, welche als Meontren dienen, können die Neuankömmlinge diese zuerst beobachten bevor sie selbst die "Kontrolle" übergeben bekommen.

Dynamics

Ein Veteran stimmt zu als Mentor zu agieren. Neuankömmlinge werden informtiert, dass es Mentoren gibt. Für die Zuweisung eines Mentors gibt es zwei Möglichkeiten. Die erste Möglichkeit ist, dass der Neuankömmling nach eine Mentor fragt. Dieser Antrag wird an alle potentiellen Mitglieder geschickt, woraufhin diese mit dem Neuankömmling in Verbindung treten können. Die zweite Möglichkeit ist, dass das neue Mitglied eine Liste von Mentoren sieht. Dies erfordert, dass es zu den Mentoren Beschreibungen gibt, welche selbst manuell oder automatisch erstellt werden. Nach der Verbindung eines Mentors mit dem neuen Mitglied, kann dieses den Mentor im Umgang in der Gruppe beobachten und bei Fragen diesen anschreiben. Nachdem der Mentor sieht, dass das neue Mitglied gut zurecht kommt, wird dieses "freigegeben" und kann zusätzlich niederschreiben, wie die Interaktion mit dem Mentor abgelaufen ist. (siehe LETTER OF RECOMMENDATIONS)

Rationale

Benjamin Franklin prägte den Spruch "Tell me and I forget. Teach me and i Remember. Involve me and I learn." Das Mentor Pattern folgt dem dritten Weg der Weitergabe von Wissen. Ein Experte paart sich mit einem Neuling und löst zusammen ein Problem. Das Ziel des Mentors ist es, den Neuling zu stärken, so dass er allmählich mehr Teile der Aufgaben ausführen kann.

Check

Bei der Anwendung dieses Patterns sollten folgende Fragen beantwortet werden:

  • Wie können Mentoren ihre Bereitschaft zur Hilfe eines Neulings ausdrücken?
  • Werden Mentoren in einer Mentoren-Liste angezeigt?
  • Können Neuankömmlinge ihren Mentor selbst auswählen oder wird ihnen dieser zugewiesen?
  • Wie langte sollte eine Mentorenunterstützung dauern?
  • Wie werden Mentor und Neuling interagieren? Können sie synchrone Editoren bieten, welche ihnen die gemeinsame Bedienung von Gruppenartefakten ermöglichen?

Danger Spots

Das richtige Gruppenmitglied als Mentor zu finden ist sehr schwer. oft passiert es, dass sich Mitglieder selbst überschätzen. Sinnvoll wäre deshalb ein Empfehlungsmechanismus (siehe LETTER OF RECOMMENDATION) oder eine automatische Erkennung von sachkundigen Mitgliedern (siehe EXPERT FINDER). Wie Manns und Rising (2005) bereits vorgestellt haben, kann es schwierig sein, einen Mentor zu finden. Außenstehende Experten sind selten und schwer zu motivieren, dass sie Neulingen helfen. Während der Interaktion ist es wichtig, dass Mentor und Neuling ihre Aktionen sehen können. Das APPLICATION SHARING Pattern sollte betrachtet werden, wenn die Verwendung einer Applikation Teil der Praxis ist, welchen der Neuling lernen soll.

Known Uses

MSN Messenger - Die deutsche Version bietet einen Pool von Buddyscouts. Nutzer können selbst Scouts werden, wenn sie Informationen über sich veröffentlichen und schreiben, wieso sie ein Scout werden wollen. Neulinge können diese dann bei Fragen anschreiben und bekommen Hilfe.

Pair Programming in XP - Ein Nutzer fungiert als "Treiber" und der andere als "Navigator". Der "Treiber" schreibt Code während der "Navigator" kommentiert. Im Kontext des Mentor Patterns agiert der "Treiber" am Anfang als Mentor. Sobald der "Navigator" eine vielversprechende Idee hat, übernimmt dieser.

GestureMan ist ein Beispiel, wie das Mentor Pattern an einem realen Arbeitsplatz verwendet werden kann. Der Mentor kontrolliert einen Roboter - den "GestureMan", welcher auf wichtige Bereiche in der entfernten Umgebung zeigen kann. Der Neuling ist auf der "anderen Seite" und agiert wirklich mit seinen Händen. Mit der Zeit verringert der Mentor die Anzahl an Hinweisen und folgt schließlich nur noch dem Neuling in seinen Aktionen.

Related Patterns

Nachfolgend werden zum eben beschriebenen Pattern verbundene Patterns vorgestellt: SHARED BROWSING ist ein Weg eine Gruppe mit einem Mentor gemeinsam zu erkunden. Um die Arbeit des Mentors zu bewerten, kommt das LETTER OF RECOMMENDATION Pattern ins Spiel, in welchem die Bewertungen der ehemaligen Neulinge über die Mentoren zu finden sind. Mittels des EXPERT FINDERs werden ebenfalls Neuling und Mentor zusammengeführt, jedoch muss vor einer Überflutung von zu vielen Anfragen an einen Mentor geschützt werden. Das MASTER AND APPRENTICE Pattern beinhaltet ebenfalls die Zusammenführung eines Experten mit einem Neuling. Diese bleiben solange zusammen, bis sich der Neuling bereit fühlt, die Arbeit ohne den Mentor zu erledigen. Das MENTOR Pattern von Manns und Rising (2005) beschreibt wie ein externer Experte bei dem Launch eines Projekts helfen kann. Der Hauptunterschied besteht darin, dass nach deren Auffassung ein Mentor lediglich während des Projektes benötigt wird und danach kein externer Mentor benötigt wird. Sowohl das Mentor als auch das ACTIVITIES THAT SHAPE Pattern teilen die Idee, dass die Community mittels der Verbindung von Neulingen und Mentoren verstärkt werden soll. Allerdings schlägt das Mentor Pattern eine konkrete Instanz einer Interaktion vor und diskutiert die Bedeutung für den Erlass dieser Instanz in einem Computer-vermittelten Umfeld.

Realisierung auf der eStudy-Plattform

Eine Realisierung des Mentor Patterns ist mir auf eStudy nicht bekannt. Jedoch kann ich mir vorstellen, dass der Dozent eines Kurses als Mentor für die gesamte Gruppe gelten kann. Eine direkte Zuordnung als Mentor ist mir jedoch in eStudy nicht bekannt.

Bearbeitet von -- U13135 08:24, 30. Nov. 2010 (CET)

Virtual Me

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Virtual Me

Intent

Das Pattern beschreibt den Aufbau einer virtuellen Repräsentanz eines Community-Mitglieds, das dieses für die anderen Community-Mitglieder identifizierbar macht.

Context

Nutzer agieren miteinander in einem Kollaborationssystem.

Problem

In großen Community besteht oftmals das Problem, das die Bezeichnungen der Mitgliederaccounts sehr ähnlich aussehen. Dies erschwert die Identifirzierung der Mitglieder untereinander, welche jedoch für eine Zusammenarbeit unumgänglich ist.

Scenario

Rodrigo ist ein neues Mitglied in einer Community, die sich mit Game-Engines beschäftigt. Er hat seinen Namen als Login gewählt und sieht nun, dass sich drei weitere Mitglieder an der Diskussion über die Grafik-Engine beteiligen. Dies sind Marc, Juan und Carla. Er erkennt jedoch nicht die Ziele und Absichten dieser Mitglieder und hat auch keinen Anhaltspunkt, wie diese an der Entwicklung der Game-Engine beteiligt sind. Aus diesem Grund zögert er, Kontakt mit ihnen aufzunehmen.

Symptons

Das Pattern sollte angewendet werden, wenn

  • sich Mitglieder in einer Community über kurze Anmeldenamen identifizieren müssen.
  • die Community so groß ist, dass sich die Mitglieder nicht persönlich können.
  • sich die Mitgliedergemeinde über die Zeit stark verändert.
  • bestehende Mitglieder mit neuen Mitgliedern interagieren sollen.
  • die persönliche Beteiligung von Mitgliedern wichtig ist.

Solution

Den Mitgliedern muss es ermöglicht werden, eine virtuelle Identität in der Community aufzubauen. Diese Identität wird angezeigt, wenn das Mitglied in der Community aktiv ist.

Dynamics

Nachdem sich die Mitglieder in ein System eingeloggt haben, zeigt das System ihnen eine Referenz zu ihrer virtuellen Identität. Hier sind die relevanten Informationen wie der komplette Name, ein Bild des Nutzers und eine kurze Selbstbeschreibung hinterlegt. Beschäftigt sich die Community fest mit einem bestimmten Thema, ist es empfehlenswert spezifische zum Thema passende Angaben abzufragen.

Wird das Mitglied in der Community nun aktiv, wird an den jeweiligen stellen statt seinem Login-Namen sein richtiger Name angezeigt und wenn möglich auch sein Nutzerbild. Beides ist wiederum verknüpft mit der Selbstbeschreibung des Mitglieds.

Rational

Es wurden verschiedene Theorien entwickelt, die den Aufbau eines Selbstbildes beschreiben. Im Wesentlichen geht es darum, dass ein Mitglied mit dem Ausfüllen seiner Profilangaben neben seiner virtuellen Identität auch indirekt seine Erwartungen an die Community bekannt gibt. Dies hilft anderen Mitgliedern ihr Bild über dieses Mitglied anzupassen.

Check

Bei der Anwendung dieses Patterns sollten folgende Frage beantwortet werden:

  • Welche Fragen sollten Mitgliedern gestellt werden, damit die Selbstbreschreibungen entsprechend strukturiert sind.
  • Ist es möglich ein Bild des Mitglieds anzuzeigen?
  • Kann der Benutzername mit Hilfe eines Hyperlinks mit der Repräsentation des Mitglieds verlinkt werden.

Danger Spots

Benutzer schrecken oftmals dafür zurück, ein Bild von sich in der Community zu veröffentlichen. Um dieses Problem zu lösen, empfiehlt es sich, ein so hässliches Standardbild zu hinterlegen, dass die Mitglieder eine Motivation haben, dieses durch ihr eigenes zu ersetzen. Mitglieder können außerdem falsche Angaben hinterlegen. Dies ist vor allem dann problematisch, wenn die Echtheit der Angaben von Bedeutung für die Zusammenarbeit in der Community ist. Hier empfiehlt es sich ein authentisches Foto als Pflichtangabe einzuführen. Bei allen Angaben muss der Datenschutz beachtet werden. Ist die Community öffentlich, sollten Gäste deutlich weniger Informationen sehen, als registrierte Nutzer. Benutzerbezogene Daten sind oftmals veraltet. Hier ist eine regelmäßige Erinnerung zur Aktualisierung empfehlenswert.

Known Uses

  • E-Mail-Signaturen: Für jeden E-Mail-Account kann ein Benutzer eine individuelle Signatur hinterlegen, die zusätzliche Informationen über ihn beinhaltet.
  • CHIplace: Wurde als Tool zur Vorbereitung einer Konferenz genutzt. Auf einer Seite wurden zufällige Teilnehmer der Konferenz dargestellt. Diese Bilder waren mit der jeweiligen Profilseite des Teilnehmers verknüpft. Auf ihr erhielt man weitere Informationen, wie zum Beispiel über den Beruf und Informationen die in direktem Bezug zur Konferenz standen.
  • XING: Die Onlineplattform hat sich den Aufbau von Netzwerken zwischen Experten zum Ziel gesetzt. Jedes Mitglied (Experte) verfügt dabei über eine Seite, auf der seine Informationen in strukturierter Form angezeigt werden. Eine solche Seite kan prinzipiell mit einer privaten Website verglichen werden. Die Seiten innerhalb einer solchen Plattform sind jedoch deutlich strukturierter.

Related Patterns

  • USER GALERY: Alle Nutzerprofile sollten in einer Galerie gelistet werden.
  • USER LIST / REMOTE CURSOR: Verfügbarkeit von Informationen über die aktuelle Aktivität von Mitgliedern im System
  • INTERACTIVE USER INFO: Erklärt, wie die visuelle Repräsentation eines Mitglieds eine engere Zusammenarbeit der Mitglieder fördern kann.
  • MASQUERADE: Beschreibt, wie benutzerbezogene Daten vor ungewollten Zugriff geschützt werden können.
  • NAMEPLATE: Evaluiert die Notwendigkeit von identifizierbaren Mitgliedern in einem Kollaborationssystem.

Realisierung in eStudy

In eStudy wird dieses Pattern umgesetzt in dem alle Nutzer mit Ihrem vollen Namen angezeigt werden. Der Anmeldenamen taucht dabei nicht auf. Außerdem sind alle diese Namen mit einer Profilseite des Users verknüpft, auf der zahlreiche Informationen zur Person (Fachbereich, etc...), sowie zur Aktivität innerhalb von eStudy (Belegte Kurse) aufgelistet werden.

eStudy regt jedoch nicht unbedingt zum Einstellen eines Fotos an, da neben den Mitgliedernamen immer das gleiche Icon, statt einem kleinen Bild des Users (wie es bei moodle der Fall ist) angezeigt wird.

Kritik

Es ist auf jeden Fall sinnvoll, dieses Pattern umzusetzen. Allerdings kann es auch einige Mitglieder abschrecken, wenn sie ihrem kompletten Namen, sowie ein Bild von sich einstellen sollen. Dies hängt jedoch sehr von der jeweiligen Art der Community ab.

Bearbeitet von -- U13448 18:04, 29. Nov. 2010 (CET)

User Gallery

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
User Gallery

Intent

Eine Anzeige der Personen, die die Kollaborationsplattform nutzen.

Context

Man ist mit dem Aufbau eines Systems beschäftigt, in dem die Mitglieder aktiv zusammen arbeiten sollen. Die Mitglieder werden dabei mit ihrem richtigen Namen oder mit Hilfe eines Nicknames identifiziert.

Problem

Wenn mehr als ein Mitglied mit geteilten Daten interagiert, ist es schwierig die Interaktion zu koordinieren. Ohne zu wissen, wer ein System nutzt, ist es fast unmöglich eine Zusammenarbeit aufzubauen oder von den Aktivitäten anderer zu erfahren.

Scenario

Nach ein paar Monaten ist die Game-Engine-Community auf 200 Mitglieder angewachsen. Dies hat unvermeidbar zu Folge, dass sich nicht mehr alle Mitglieder persönlich kennen. So sucht zum Beispiel eine Person nach einem anderen Mitglied, dass in seiner Nähe wohnt, um sich mit ihm zu treffen, damit sie genauer über ein bestimmtes Thema sprechen können.

Symptons

Dieses Pattern sollte angewendet werden, wenn...

  • sich neue Mitglieder schwertuen mit anderen in Kontakt zu treten
  • Mitglieder Schwierigkeiten haben sich zu erinnern, wer Mitglied in der Community ist
  • Mitglieder mehr übereinander erfahren wollen, als nur den Namen.

Solution

Es sollte eine Liste mit allen Mitgliedern der Community angeboten werden. Sie sollte in einer Form aufbereitet werden, die dazu anregt, die Liste zu durchstöbern.

Dynamics

Mitglieder haben sich für das System registriert und ihre virtuelle Repräsentation angelegt. Die Informationen über ALLE registrierten Mitglieder wird auf einer Seite mit Hilfe einer Mitglieder-Galerie angezeigt. Diese Liste beinhaltet den echten Namen der Mitglieder oder einen Nickname und oftmals auch Photos der Mitglieder.

Rational

Wenn Mitglieder durch eine Liste der Mitglieder stöbern können, können Sie die Selbstbeschreibung anderer Mitglieder mit ihrer eigenen vergleichen und so welche finden, die die gleichen Interessen oder Absichten haben, wie sie selbst. Der "Spaßfaktor" wird erhöht, wenn die Liste Bilder nutzt.

Check

Sollte das Pattern umgesetzt werden, müssen folgende Fragen beantwortet werden:

  • Macht es abhängig von der Gesamtzahl der Mitglieder Sinn, eine Suchmaske für die Liste anzubieten?
  • Sollte in der Mitgliedergalerie zwischen öffentlichen und privaten Angaben unterschieden werden?
  • Sollen Bilder der Mitglieder angezeigt werden?

Danger Spots

In großen Communities sollte die Mitgliederliste unbedingt durchsuchbar sein. Es muss außerdem eine Balance bei der Anzahl der angebotenen Informationen gefunden werden.

Known Uses

  • CHIplace: Die Plattform zur Konferenz listet alle Mitglieder in einem "people browser". Die Mitglieder sind dabei anhand ihrer Daten aus den Profilen auf der Seite arrangiert.
  • Community-Webseiten: Fast alle Community-Seiten listen Ihre Mitglieder anhand der Daten, die während der Registrierung abgefragt werden.

Relatet Patterns

  • WELCOME AREA: Bezeichnet einen bestimmten Bereich, in dem neue Mitglieder eingeführt werden. Hier kann auch eine Liste der neuen Mitglieder enthalten sein.
  • HALL OF FAME: Zeigt die "wichtigsten" Mitglieder in einer Community an. Dies können zum Beispiel die aktivsten sein.
  • BUDDY LIST: Zeigt nur die Mitglieder in einer Liste an, die das Mitglied direkt kennt.

Umsetzung in eStudy

Neben einer gesamten Mitgliederliste, gibt es in eStudy zusätzlich noch Mitgliederlisten für jeden weiteren Unterbereich (Kurse / eComs), in denen nur die Mitglieder aufgeführt werden, die dort eingetragen sind. Außerdem gibt es eine Liste aller Mitglieder, die geradem online sind. Bis auf die Online-Liste sind alle Listen mit eine Suchfunktion ausgestattet.

Kritik

Da die Möglichkeit andere Mitglieder mit änhlichen Interessen zu finden, einer der wesentlichen Bestandteile einer Community ist, ist auch dieses Pattern von entsprechender Bedeutung. Wie aber bereits angesprochen wird, hängt der Erfolg der Umsetzung sehr stark von der angebotenen Suchfunktion ab. Dies gilt insbesondere für Communities mit vielen Mitgliedern. Hier reicht es nicht aus, nur nach einem Namen suchen zu können

Bearbeitet von -- U13448 18:08, 29. Nov. 2010 (CET)

Buddy List

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Meine Freunde.

Intent

Zeige nur bekannte Personen.

Context

In einer Community, wo viele Personen miteinander agieren.

Problem

Wenn viele Personen zur Verfügung stehen, verliert man schnell die Übersicht, welche Personen für einen selbst relevant sind. Benutzerlisten wachsen sehr schnell und es ist schwer, die lokalen Personen zu finden. Auf der anderen Seite sind Nutzer oft nur an den Personen aus ihrem lokalen Umfeld interessiert.

Scenario

Jochen hat einen Sicherheitsexperten gefunden, nachdem er die User Gallery durchsucht hat. Es handelt sich um Vincent, der sich gut mit Angriffen auskennt. Zusammen haben die beiden viel an einem Programm gearbeitet. Die beiden haben sich super verstanden. Nach einer Woche hat Jochen erneut ein paar Fragen - aber weil er so viel Arbeit hatte, hat er mittlerweile den Namen wieder vergessen - er sucht erneut in der User Gallery.

Symptoms

Man sollte diese Pattern anwenden, wenn

  • Nutzer nur an einem kleinen Kreis aller Nutzer interessiert sind
  • Nutzer lange nach anderen Nutzer suchen müssen
  • Es Nutzer mit dem gleichen Namen gibt, die sich z.B. nur durch Ihren Login-Namen unterscheiden.

Solution

Eine Freundesliste anbieten, auf dem der Nutzer relevante Nutzer speichern kann. Wenn der Nutzer alle Personen durchsucht, immer zuerst die Freunde anzeigen.

Dynamics

Immer wenn ein Nutzer mit einem anderem Nutzer interagiert, sollte die Möglichkeit (zum Beispiel durch einen Menueintrag) gegeben sein, diesen Nutzer als "Freund" hinzuzufügen.

Rationale

Diese Pattern funktioniert, weil es den Prozess des Suchens nach anderen Personen drastisch erleichtert. Im Unterschied zu globalen Nutzerlisten, interessieren einen Freundeslisten viel mehr. Wenn man z.B. das Profil als Nutzer-Objekt sieht, macht es Sinn, diesen als Verbindung hinzufügen zu können.

Check

Wenn dieses Pattern angewendet wird, sollte auf folgendes geachtet werden:

  • Wie fügen Nutzer andere hinzu?
    • Kann man einen Button zum User Interface hinzufügen, der den aktuellen Partner zum Freund macht?
    • Kann man das Kontext-Menu vom Virtual Me nehmen?
  • Muss ein Nutzer zustimmen, um ihn auf eine Freundesliste zu setzen?

Danger Spots

Wenn Nutzer nur die Kontakte aus ihrer Freundesliste als wichtig ansehen, finden sie keine neuen Kontakte mehr. Dies sollte verhindert werden und dem Nutzer sollten andere Nutzer leicht zugänglich gemacht werden.

Known Uses

Related Patterns

User Gallery Reciprocity User List Virtual Me Centralized Objects

Realisierung auf der eStudy-Plattform

Auf eStudy hat man die Möglichkeit Freunde zu einer Liste hinzuzufügen. Dies kann, wie im Pattern beschrieben, über einen Link im Profil gemacht werden. Man kann sich dann alle Freunde in einer Liste anzeigen lassen, vgl. Bild.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
eStudy Freundesliste.

Guide me . . . or how to deal with quality

Quality Inspection

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Qualitätskontrolle.

Intent

Steigere die Qualität der Zusammenarbeit durch das Löschen vom schlechtem Inhalt und bösen Nutzern.

Context

Man hat einen Platz für den Austausch geschaffen. Jetzt macht man sich Sorgen um die Qualität.

Problem

Mitglieder einer Community erhoffen sich den Spaß an qualitativ hochwertigen Beiträgen der andere Nutzer. Aber nicht jeder Beitrag hat die gleiche Qualität. Beiträge mit schlechter Qualität stören die Mitglieder und ziehen die Aufmerksamkeit von Guten ab.

Scenario

Björn hat sich als eher schädlicher Nutzer herausgestellt. Er bearbeitet den Quellende einer Gameengine nach seinen Bedürfnissen und lädt diese anschließend wieder hoch, ohne sich Gedanken um das Testen oder der Kompatibilität zu machen. Aus diesem Grund müssen jeden Abend Dennis und Beni wieder alles in Ordnung bringen, weil Björn's Beitrag hinderlich für das ganze Projekt sind.

Symptoms

Man sollte diese Pattern nutzen, wenn:

  • Mitglieder Beiträge mit niedriger Qualität oder anstößigen Inhalt liefern
  • Nutzer sich darüber beklagen, zu viele unnütze Nachrichten zu erhalten
  • Auch nach Ermahnung, Nutzer weiter Unnützlich sind

Solution

Bestimmte Nutzer sollten als Moderatoren berufen werden, die Beiträge nach Überprüfung auf die Community loslassen. Moderatoren sollten das Recht haben jeglichen Inhalt zu löschen und Nutzer von der Plattform auszuschließen.

Dynamics

Erfahrende Nutzer können sich als Moderatoren bewerten. Die Beiträge von normalen Nutzern sind erst nicht sichtbar und werden in einen Pool für Moderatoren gelegt. Diese erhalten darüber eine Nachricht und können nach Kontrolle den Beitrag freigeben oder löschen. Wenn der Beitrag abgelehnt wird, sollte der Nutzer informiert werden, aus welchen Gründen dies geschehen ist. Wenn der Nutzer weiterhin schlechte Beiträge liefert, sollte er aus der Community ausgestoßen werden.

Rationale

Weil die Moderatoren schlechten Inhalt rausfiltern, wird der gesamte Inhalt besser. Wenn es mehrere Moderatoren gibt, wird dieser Prozess einfacher und schneller.

Check

Wenn dieses Pattern eingesetzt wird, sollten folgende Fragen beantwortet werden:

  • Wer wird der erste Moderator? Wer entscheidet, ob ein Nutzer ein Moderator wird oder nicht? Sollte es darüber eine Abstimmung geben?
  • Wie wird der Nutzer über die Kontrolle informiert? Sollte er eine Nachricht erhalten, dass das Moderatorenteam benachrichtigt wurde, den Beitrag kontroller und dann den Beitrag freigibt oder ablehnt?
  • Was passiert mit Beiträgen, die nicht moderiert werden? Werden diese automatisch abgelehnt oder wird der Fall einem anderen Moderator zugewiesen?
  • Macht es Sinn, das Moderatoren Beiträge sortieren, bevor sie für alle öffentlich sind?
  • Werden unterschiedliche Nutzer von den Moderatoren unterschiedlich behandelt? Sollte es zum Beispiel eine Whitelist geben, auf der Nutzer stehen, die bekannt für guten Inhalt sind? Soll es eine Blacklist geben, auf der Nutzer stehen, dessen Beiträge bereits einmal abgelehnt wurden?

Danger Spots

Die Aufgabe des Moderators kann sehr zeitintensiv sein. Deswegen sollte die Größe des Moderatorenteams an die Anzahl der Beiträge angepasst werden. Moderatoren spielen eine entscheidene Rolle. Wenn sie zu streng sind, wächst die Community langsamer. In diesem Fall sollte man den Nutzer die Funktion ermöglichen, seinen eigenen Beitrag an einen anderen Moderator zu übergeben. Da Moderation Zeit in Anspruch nimmt, könnten es Nutzer als unangenehm empfinden, dass ihre Beiträge erst nach längere Zeit aktiv sind. Aus dem Grund sollte es Bereich in der Community geben, die ohne Kontrolle auskommen, um ein gleichzeitiges arbeiten zu ermöglichen.

Known Uses

Wikipedia (http://wikipedia.de) hat Moderatoren, die die Beiträge von allen Nutzern kontrollieren. In den Anfangszeiten waren alle Änderungen sofort sichtbar, da die Menge an Beiträgen so unglaublich groß war, dass sie nicht kontrolliert werden konnte. Es gibt ein Moderatorensystem, in dem je nach Erfahrung und Zeit, die man in der Community verbraucht hat, die Rechte (und Pflichten) steigen.

Newspoint.CC (http://newspoint.cc) ist eine Nachrichtencommunity, in der jeder Nutzer Nachrichten des Tagesgeschehen aus unterschiedlichen Rubriken einstellen kann. Um die Qualität der Nachrichten zu gewährleisten, gibt es Moderatoren, die als Editoren die Nachrichten prüfen, gegebenenfalls anpassen und dann online stellen. Da die Menge an Nachrichten sich in Grenzen hält, ist es möglich, jeden einzelnen Beitrag zu überprüfen. Die Kommentare zu den Nachrichten sind hingegen ungeprüft und erscheinen sofort.

Related Patterns

Letter of Recommendation Mentor Attention Screen Hall of Fame Vote Engage Quality Assurance

Realisierung auf der eStudy-Plattform

Letter of Recommendation

(User Experience Feedback)

Intent

Lassen Sie die Nutzer sich gegenseitig über ihre Zuverlässigkeit und Know-how bewerten.

Context

Ihr System erlaubt den Nutzern, ihre Interaktionspartner zu wählen. Es unterstützt sie, indem jeder Nutzer detaillierte eigene Informationen, beispielsweise in einer User-Gallery , über sich selbst preisgeben darf. User Gallery

Problem

Wenn Nutzer keine potentiellen Interaktionspartner kennen, so können sie eine Angst gegenüber der Interaktion entwickeln, da sie keinem Partner vertrauen. Dies kann zu einer hohen Hemmschwelle führen, diese beeinträchtigen oder die Interaktion verhindern.

Scenario

James fand mehrere Experten mit Erfahrung in der Spracherkennung. Eine von ihnen ist Susan, der andere ist Wil. James kennt beide nicht und wählt zufällig Wil als Kooperationspartner für die Klärung der Internationalisierungsaspekte aus. Leider ist Will weit weniger unterstützend als es Susan gewesen wäre. Er weist James lediglich auf die Handbücher hin und ignoriert konkrete Fragen. Das hilft James nicht wirklich weiter.

Symptoms

Sie sollten sich überlegen, wann diese Patterns zutreffen:

  • Es gab keine Wechselwirkungen zwischen den Interaktionspartnern, was bedeutet, dass die Partner keine Erfahrungen mit der Qualität der Interaktion sammeln konnten.
  • Die Interaktion verbraucht Ressourcen und es dauert seine Zeit, bis der Nutzer die Qualität der Interaktion beurteilen kann.
  • Ressourcen in Interaktionen zu investieren ist nicht wünschenswert, denn ein zufriedenstellendes Ergebnis kann nicht gewährleistet werden.
  • Eine Interaktion erfordert Vertrauen in den Interaktionspartner oder den Inhalt.

Solution

Deshalb: Entwickeln Sie ein Verfahren zur Bewertung von Wechselwirkungen und zeigen Sie eine Analyse aller Nutzer Bewertungen oder Artefakten, mit denen die Nutzer interagiert haben.

Dynamics

Der Nutzer interagiert mit einem Interaktionspartner. Der Interaktionspartner kann ein anderer Nutzer oder ein Artefakt sein. Die Interaktion mit einem Artefakt stellt eine indirekte Interaktion dar. Dies bedeutet, dass ein Nutzer ein Artefakt entwirft, welches später vom lokalen Nutzer bemerkt wird. Interaktion zwischen Nutzern kann beispielsweise der Austausch von Informationen oder Ware sein. Nach der interaktiven Episode bewerten die Nutzer die Qualität der Interaktion. Sie äußern wie gut die Anforderungen an die Interaktion erfüllt wurden. Die Bewertung basiert auf einer Skala, z.B. von schlecht bis ausgezeichnet. Es kann auch eine Textbeschreibung beinhalten, warum die Interaktion so bewertet wurde, wie sie bewertet wurde. Die Bewertungen werden in einem zentralen Repository gesammelt oder als Attribut eines bewerteten Artefakts oder als Nutzer. Immer wenn ein Artefakt oder Nutzer den anderen Nutzern gezeigt wird, so zeigt das System auch den Durchschnitt der anderen Nutzer Bewertungen.

Rationale

Die Grundannahme dieses Patterns ist, dass Nutzer in der gleichen Weise handeln werden, wenn sie sich in einer vergleichbaren Situation befinden. Macht ein Nutzer schlechte Erfahrungen mit einem Interaktionspartner, so macht ein dritter Nutzer eventuell auch schlechte Erfahrungen mit dem gleichen Interaktionspartner, wenn die Situationen vergleichbar sind. Auf der anderen Seite, wenn ein Nutzer erfolgreich mit einem Interaktionspartner interagieren konnte, so wird ein dritter Nutzer wahrscheinlich auch eine erfolgreiche Interaktion haben. Wenn die Bewertung auf der Ebene der Artefakte durchgeführt wird, so ist ein Artefakt, welches für andere Nutzer hilfreich war, auch für einen Neuen hilfreich. Die Kenntnis der Interaktionsqualität der ehemaligen Episoden verstärkt oder schwächt das Vertrauen in einen potentiellen Interaktionspartner. Mehr Vertrauen senkt die Hemmschwelle und erleichtert damit den Beginn einer Interaktion. Dieses Pattern verringert nicht die Zeit, die benötigt wird, bevor der Nutzer sein persönliches Urteil über die Interaktionsqualität gefällt hat, aber es reduziert das Risiko zu viel Aufwand in gescheiterte Interaktionen zu investieren.

Check

Wenn diese Patterns angewendet werden, sollten folgende Fragen beantwortet werden:

  • Was sind Ihre Interaktionsszenarien? Gibt es eine Aktion, die ein Ende einer Interaktionsepisode darstellt (z.B. wenn ein Nutzer einen Chatraum verlässt oder wenn eine gemeinsame Aufgabe als fertig gekennzeichnet wird)?
  • Welche Bewertungsskala werden Sie verwenden?
  • Werden Sie Nutzer oder Artefakte bewerten?
  • Wie werden Sie die Bewertung darstellen?
  • Können Sie die Visualisierung des Artefakts oder des Theusers erweitern? Sind Sie in der Lage die Art Artefakte und Nutzer in Bezug auf ihre durchschnittliche Bewertung anzuzeigen?
  • Wie werden Sie textliche Teile der Empfehlung darstellen? Macht es Sinn nur die schlechtesten und besten Empfehlungen zu zeigen?

Danger Spots

Ob die Bewertungen Nutzer oder Artefakte bewerten, ist von der Anwendungsdomäne abhängig. In den Fällen, in denen die Artefakte nicht relevant für eine große Nutzergruppe sind, kann es hilfreicher sein, die Nutzer mit den Artefakten zu bewerten. Obwohl der Transfer von einer Artefakt Erfahrung für den Nutzer, der das Artefakt erstellt oder angeboten hat in vielen Fällen zu falschen Annahmen führen kann, sowie andere, die nicht einen Nutzer sondern ein Artefakt bewertet haben. Systeme sollten daher sorgfältig jede Veränderung an den Bewertungen erklären. Nutzer Bewertungen können offensive für den bewerteten Nutzer sein. Eine Bewertung ist immer eine persönliche Meinung, die den Nutzer ungerechterweise verletzen kann. Daher sollten die Nutzer die Möglichkeit haben ihre Bewertungen kommentieren zu können. Darüber hinaus sollte sollten die Bewertungen durch einen Moderator überprüft werden, falls es Probleme mit destruktiven Bewertungen gibt. Ein verwandtes Thema ist, dass die Nutzer von ihren vorherigen Fehlern lernen können. Wenn ein Nutzer ein schlechtes Empfehlungsschreiben erhält, ist es möglich, dass er seinen Interaktionsstyle ändert und so die berichteten Probleme behoben sind. Die Nutzer sollten daher in der Lage sein, sich selbst zu rehabilitieren. Es kann schwierig sein das Ende einer interaktiven Episode zu erkennen. In Systemen, in denen die Interaktionen strikten Workflows folgen, können die Episoden von der ersten bis zur letzten für den Nutzer gleich aussehen. In Systemen ohne strikten Workflow können interaktive Episoden zu jeder Zeit beginnen und enden. Die Bewertung kann den Nutzer von seiner Aufgabe ablenken. Die Möglichkeit zur Bewertung sollte daher unauffällig sein.

Known Uses

eBay nutzt Empfehlungen, um die Zuverlässigkeit eines Nutzers zu zeigen. Seitdem Handelsinteraktionen bei eBay die Übertragung von Geld beinhalten, ist das Vertrauen in die Interaktionspartner eine entscheidende Frage. Nach jeder Transaktion werden die Käufer per E-Mail erinnert ihren Interaktionspartner zu bewerten. Die Bewertung besteht aus einer Zahl (-1 für eine negative Bewertung, 0 für eine neutrale Bewertung und 1 für eine positive Bewertung) und einem textuellen Kommentar. Die Zahlen werden verwendet, um eine Gesamtnote für den Nutzer zu errechnen, welche zusammen mit dem Nutzernamen neben jedem verkauften Produkt steht.

Die Berechnung der Gesamtbewertung zählt alle Nutzer, die positiv bewertet haben und subtrahiert alle Nutzer, die negativ bewertet haben. Die Bewertung eines Nutzers wird nur einmal gezählt, auch wenn es mehr als eine Empfehlung gibt. Dies gewährleistet, dass die Gesamtwertung nicht durch einen einzelnen Benutzer verzerrt werden kann. Wenn ein Nutzer mehr positive als negative Erfahrungen gemacht hat, dann wird die Empfehlung als eine positive Empfehlung gewertet. Wenn die negativen Bewertungen überwiegen, so wird eine negative Bewertung gezählt.

SETI@home ist eine verteilte Anwendung, die auf Zeichen von außerirdischer Intelligenz achtet. Es gibt Clients zum Download der Rohdaten für die spätere Offline – Analyse. Während diese Webseite als Zweckgemeinschaft begann (für die Suche nach außerirdischer Intelligenz), so ist die Verschiebung zu einer Interessensgemeinschaft zu beobachten. Die Webseiten-Designer wurden dazu veranlasst eine persönliche Homepage zu erstellen, wo sie ihre Gedanken über SETI@home teilen können.

Andere können diese Homepage durchsuchen und die Informationen bewerten. Über einen „empfehlen“ Button können sie diese der Community empfehlen. Nutzer mit positiven Bewertungen können zum „Nutzer des Tages“ ernannt werden, welche dann auf der Einstiegsseite von SETI@home zu sehen sind.

Rate my Professor (http://www.ratemyprofessors.com) ist ein System, welches Studenten erlaubt, ihre Erfahrungen über bestimmte Professoren zu teilen. Nach der Teilnahme am Unterricht, kann der Student einen Kommentar posten und seinem Professor eine Note geben. Die Noten können nach verschiedenen Kriterien wie, Hilfsbereitschaft, Klarheit oder Leichtigkeit im Unterricht gegeben werden. Das System berechnet dadurch eine Durchschnittsnote für jeden Studenten und eine, in der alle Bewertungen der Studenten kombiniert werden.

Amazon.com bietet verschiedene Möglichkeiten Informationen zu bewerten. Bei der ersten Möglichkeit können die Nutzer eine Rezension für verschiedene Begriffe erstellen, z.B. für ein Buch. Jeder Artikel beinhaltet einen Link Zu „Schreibe einen Beitrag“. Benutzer werden dazu aufgefordert ihre Gedanken zu teilen, wenn sie ein Element suchen. Beträge enthalten einen textlichen Kommentar über das Element und eine Bewertung (1-5). Zu jedem Element wird der Durchschnitt der Bewertungen angezeigt. Die Elemente können nach Anzahl ihrer Sterne sortiert werden, was den Prozess des Findens erleichtert. Die zweite Möglichkeit ist ein Feedback über eine Bewertung eines anderen Nutzers zu geben. Jeder Beitrag beinhaltet einen Button, der fragt, ob dieser Beitrag hilfreich war. Dazu zeigt das System an, wie viele Beiträge als hilfreich empfunden wurden. Die nicht-hilfreichen Beiträge können die andern Nutzer überspringen. Die Benutzer, die viele hilfreiche Bewertungen abgegeben haben, werden als beliebte Nutzer betrachtet und bekommen einen Platz in der Hall of Fame. Das kann aber auch zu Problemen führen, siehe Danger Spots. Es ist wichtig zu wissen, das der Nutzer bekannt geworden ist, weil er gute Rezensionen geschrieben hat, nicht aus irgendeinem anderen Grund. Eine dritte Möglichkeit erhält der Nutzer indem er externe Händler bewerten kann. Genauso wie der Handel auf eBay ist es wichtig, dass die Nutzer vertrauen in externe Händler haben. Auch hier kann der Händler mit Sternen bewertet werden. Aus allen Bewertungen ergibt sich eine Gesamtbewertung für den Händler.

Related Patterns Hall of Fame Quality Inspection Vote Birds of a Feather Participant’s Feedback Form Recommendation Community Just Say Thanks

Related Patterns

Realisierung auf der eStudy-Plattform

Dieses Pattern wurde nicht auf der eStudy-Plattform eingebunden.

Birds of a Feather

(Expertise selection)

Intent

Finden Sie andere, die das meiste mit den Nutzern gemeinsam haben.

Context

Viele Nutzer interagieren mit Artefakten in einem gemeinsamen Informationsraum. Die Artefakte beziehen sich auf spezifische Themen. Die Nutzer-Community ist recht groß und die Community Mitglieder kennen sich gegenseitig nicht gut.

Problem

Desto größer eine Nutzer-Community, desto höher ist die Wahrscheinlichkeit, dass ein perfekter Teamkollege ein Teil der Community ist.

Scenario

James hat festgestellt, dass viele Entwickler an der Dialog Interpretation interessiert sind. Er hat die Idee ein Spracherkennungssystem an die Spiel-Engine anzuhängen. James weiß, dass Rodrigo kürzlich an der Dialog Interpretation gearbeitet hat, er hat aber den vagen Eindruck, dass viele Community-Mitglieder interessiert wären über die Spracherkennung zu diskutieren. Da er die Leute nicht kennt, ist es schwer für ihn, sie zu erreichen und zu ermutigen ihre Gedanken zu teilen.

Symptoms

Sie sollten überlegen diese Patterns einzubinden, wenn...

  • Nutzer beschweren sich, dass es schwierig ist, geeignete Kooperationspartner zu finden.
  • Erfolgreiche Zusammenarbeit hängt von der Überlappung der gemeinsamen Interessen ab, da es nur wenig Zeit gibt, um die Gruppe zu normieren.

Solution

Deshalb: Vergleichen Sie Benutzerprofile und Interaktionsverläufe, um 2 Nutzer zu identifizieren, die große Teile ihrer Vergangenheit teilen. Schlagen Sie diese Nutzer als Kooperationspartner vor.

Dynamics

Nutzer führen Aktivitäten auf Artefakten in der Community aus. Diese Aktivitäten werden protokolliert und verwendet, um ein Profil der wichtigsten Artefakte für einen Nutzer zu erstellen. Artefakte, denen häufig oder vor kurzem Aufmerksamkeit geschenkt wurde, gelten als die Interessen des Nutzers. Wenn ein lokaler Nutzer einen Kooperationspartner sucht, so vergleicht das System alle Profile der Remote-Nutzer, um die Profile zu finden, die am besten korrelieren. Das sind diese, die die meisten Interessen teilen. ‘‘Birds of a feather“ sind Nutzer, die am besten zusammen passende Profile besitzen. Diese werden dem lokalen Nutzer als Kooperationspartner vorgeschlagen.

Rationale

Die Psychologie legt nahe, dass eine Strategie zur erfolgreichen Teambildung, das Zusammenbringen von Nutzern mit gleichem Hintergrund ist. Byrne (1971) zeigte, dass Menschen, die viele Eigenschaften teilen, mehr als andere, betrachten sich gegenseitig als intelligenter und kenntisreicher. Als Ergebnis zeigt sich, dass sich solche Paare gegenseitig respektieren und die Kommunikation und Interaktion miteinander genießen. Die Folge daraus ist bessere Gruppeninteraktion. Aufgaben, die sich auf die Nutzung und Umsetzung bestehendes Wissen beziehen, können vor allem aus homogenen Gruppen (Mannix und Neale, 205) profitieren. Wenn die Nutzer einen großen Teil ihrer Interaktionsgeschichte teilen, werden die eine gemeinsame Sprache und manchmal ein gemeinsames Verständnis des Artefakts besitzen. Dies erleichtert die erste Phase der Zielausrichtung und lässt das Gruppenziel schneller durch effektives Arbeiten errreichen.

Check

Wenn diese Patterns angewendet werden, sollten folgende Fragen beantwortet werden:

  • Macht es Sinn zu zeigen, wie gut Profile von versteckten Nutzern korrelieren? Wenn ja, wie würden Sie diese visualisieren? Man könnte beispielsweise eine Zahl oder Stern-Bewertung verwenden.
  • Wird mehr als ein Ergebnis in dieser Zeit präsentiert, oder sind die Nutzer nur am besten Zusammenspiel interessiert?
  • Ist es sinnvoll, die Interaktion zwischen den Nutzern automatisch zu initiieren?

Danger Spots

Nicht alle Ziele profitieren von Nutzern mit der gleichen Interaktionsgeschichte. Aufgaben die Kreativität verlangen, profitieren von diversen Teams. Mannis und Neale (2005) bieten einen guten Überblick über die Vielfalt der Forschung und der positiven und negativen Auswirkungen der Vielfalt an Arbeitsgruppen. Der aktuelle Kontext eines Nutzers, der einen Kooperationspartner sucht, wird unabhängig von großen Teilen derer Interesse erkannt. Ein Experte der Kunstgeschichte kann zum Beispiel eine Person für klassische Musik zu begeistern. Obwohl die Geschichte der klassischen Kunst eine recht große Aktivität besitzt, so dominiert doch die viel größere Geschichte der klassischen Kunst. Das System wird daher keinem Nutzer mit musikalischen Hintergrund empfohlen, obwohl diese der Nutzer sucht. Eine Lösung wäre dem anfragenden Nutzer die Möglichkeit zu geben interessante Profile zu filtern, sodass ihre aktuellen Interessen passen. Wie solch eine Filter- Oberfläche aussehen könnte ist jedoch sehr anwendungsabhängig.

Known Uses

MEMOIR (Pikrakis et al., 1998) ist ein System, welches Web-Browsing-Aktivitäten überwacht, um andere Nutzer mit ähnlichen Browsing-Geschichten zu empfehlen. Für jeden Nutzer werden die Adressen aller besuchten Webseiten in einer Web-Spur gespeichert. Diese Web-Adressen formen die Interessen des Nutzers. Immer wenn sich ein Nutzer für andere mit vergleichbaren Interessen interessiert, berechnet das System die „Birds of a Feather“, die eine große Überschneidung in ihrem Browserverlauf haben. Diese Nutzer werden dann für Zusammenarbeit empfohlen.

Autonomy CEN (Autonomy, 2002) ist ein Wissensmanagement-Portal, welches Zusammenarbeit und Expertenwissens-Netzwerke verwaltet. Nutzer werden über die Dokumente überwacht, die sie lesen oder sie sind Autor in der Dokumenten-Repository. Diese Dokumente formen das Interesse des Nutzerprofils. Wenn die Nutzer das Bedürfnis verspüren mit anderen zusammen arbeiten zu wollen, so können sie das System nach Nutzern mit ähnlichen Interessen abfragen. Ähnlich bedeutet in diesem Fall eine ähnlich enge semantische Beziehung zu dem betreffenden Dokument.

Yenta (Foner, 1996) ist ein Agent-basiertes System zur Unterstützung von Matchmaking. Ein Agent beobachtet die lokale Nutzer-E-Mail, Nachrichten und Datenkonsum und erstellt ein Benutzerprofil basierend dieser Artefakte. Wie im Fall von Autonomy CEN, wird die Ähnlichkeit der semantischen Distanz zwischen den Artefakten berechnet. Da alle Artefakte textuell sind, kann dieser Abstand anhand linguistischer Ansätze berechnet werden. Die einzigartige Yenta Architektur ist die Art, wie Profile verglichen werden, seitdem diese vom lokalen Nutzer gesteuert werden. Yenta verwendet das Konzept der autonomen Agenten. Jeder Benutzer sieht „seinen“ Agenten mit dem gesuchten Benutzerprofil. Der Agent kontaktiert dann andere Agenten von anderen Kunden. Beide Agenten vergleichen ihre Profile und schauen, ob diese übereinstimmen. Am Ende präsentiert der Agent seinem Nutzer de Auswahl der passenden anderen Agenten.

BoF-Sessions at Conferences sind Veranstaltungen an denen Menschen mit gleichen Interessen zusammen kommen und über ein bestimmtes Thema diskutieren können. Diese sind in den meisten Fällen, unter Angabe des Themas oder des Attributs, bekannt. So können andere Konferenzteilnehmer, die sich mit dem Thema identifizieren können, an der Veranstaltung teilnehmen. Obwohl Matchmaking von keiner Technologie unterstütz wird, teilt es den gleichen Fluss der Interaktion, wie die beschriebene Lösung dieses Patterns.

Related Patterns

Active Neighbors erweitern die Interessen eines Nutzers in Bezug auf dessen Artefakte. Das Active Neighbors pattern soll die Zusammenarbeit der Nutzer erkennen, aber auch Nutzer mit gleichen Interessensverläufen finden.

Activity Log protokolliert die Tätigkeit der Nutzer und bietet somit notwendige Informationen, um die Ähnlichkeit im Interaktionsverlauf der Nutzer zu finden.

Expert Finder betrachtet die aktuellen Artefakte des lokalen Nutzers, um Nutzer mit gleicher langer Vergangenheit des selben Artefakts zu finden. Während While Birds of a Feather Menschen findet, die einen gemeinsamen Interaktionsverlauf besitzen, so findet Expert Finder in den meisten Fällen Menschen mit unterschiedlichen Interaktionsverläufen in einem bestimmten Bereich. Birds of a Feather konzentriert sich somit auf die Interessen und Hintergründe des Nutzers, um diese zusammen zu bringen. Expert Finder konzentriert sich dagegen auf die Interaktionsverlaufe eines bestimmten Artefakts des lokalen Nutzers.

Diverse Groups (Coplien und Harrison, 2004) beschreiben das Gegenteil dieses Patterns in Anbetracht heterogener Teams im Rahmen der Design.Aufgaben. Das Rationale dahinter ist, dass Änderungen notwendige Meinungen und Hintergründe erfordern. Dies ist in Teams mit großem gemeinsamen Hintergrund sehr schwierig.

Subsystem by Skill (Coplien and Harrison, 2004)plädiert dafür, Teams aus Menschen vergleichbarer Fähigkeiten zusammen zu setzen. Im Vergleich zu Birds of a Feather, welches sich auf das Wissen über Artefakte konzentriert, fokussiert sich das Subsystem auf die Erfahrung in der Praxis.

Realisierung auf der eStudy-Plattform

Auf eStudy ist diese Pattern nicht realisiert. Da es sich um eine Lernplattform handelt, ist die Hemmschwelle für Studenten Unsinn einzustellen relativ gering. Deswegen ist das Pattern auch nicht relevant.

Expert Finder

Intent

Kontaktiert den User, der am ehesten mit der Problemlösung aufgrund seines Könnens vertraut werden sollte

Context

Stellt eine Umgebung zur Verfügung, in der Benutzer mit Aufgabenbereichen interagieren können. Allerdings benötigen die Benutzer detailliertere Informationen, die den Aufgabenbereich Verfügung stellen kann. Deshalb sollte darüber nachgedacht werden für spezielle Aufgabenbereiche eine persönliche Hilfe für Benutzer zur Verfügung zu stellen.

Problem

Du weißt, dass andere Benutzer mehr Erfahrung mit einem speziellen Aufgabenbereich haben, aber du weißt nicht wie du sie erreichen sollst.

Scenario

Rodrigo schreitet immer weiter in der Implementierung seines ersten Package für eine Game Engine voran. Er hat sich dazu entschlossen an einem Dialogmodul zu arbeiten, dass dazu verwendet werden kann einen Dialog zwischen Mensch und künstlichen Spielern herstellen kann… er versteht allerdings das Rollenkonzept nicht in allen Punkten. Da er neu in dem Code Projekt ist, weiß er nicht, dass Susan diesen Part implementiert hat und sie um Hilfe fragen muss.

Symptoms

Sie sollten die Anwendung des Patterns prüfen, wenn…

  • Das Fachwissen nicht explizit bei einem Benutzer liegt, speziell wenn kein Expertenverzeichnis angelegt wurde
  • Keine globalen Experten im Projekt existieren, keine „Hall of Fame“ angelegt wurde.
  • Unterschiedliche Nutzer machen dieselben Fehler, da keine Möglichkeit des Erfahrungsaustauschs besteht.

Solution

Hierfür: Finde einen Benutzer, der eine lange Erfahrungsgeschichte mit dem Aufgabenbereich hat. Benutze den Activity Log 4.5.1) wer welche Aktivitäten im welchem Aufgabenbereich ausführt. Soertiere die Liste der Leute nach Nummer und Typ der Aktivitäten und oder der Zeit

Dynamics

Benutzer führen die Aktivitäten aus, die im Activity Log festgehalten sind. An welchem Aufgabenbereich Benutzer auch immer arbeiten, bei dem sie Unterstützung benötigen, brauchen sie nur eine Suchanfrage zu starten, um den Benutzer mit den meisten Informationen über den Aufgabenbereich zu finden. Hierzu können unterschiedliche Strategien verwendet werden:

  1. Es kann der Benutzer sein, der zuletzt den Aufgabenbereich begutachtet hat. In diesem Fall ist es wahrscheinlich, dass der gefundene Benutzer einen gemeinsamen Kontext mit dem auffordern Benutzer teilt.
  2. Es kann der Benutzer sein, der den Aufgabenbereich zuletzt modifiziert hat. Dieser Fakt sagt auch aus, dass der Benutzer aktiv mit dem Inhalt interagiert hat und somit auch einen Grund gefunden hat, um das Objekt zu ändern, das zumindest ein wenig Erfahrung benötigt.
  3. Es kann auch der Benutzer sein, welcher die meisten Aktivitäten mit dem Objekt durchgeführt hat. Das wiederum kann unterschieden werden zwischen nur lesen/ modifizieren.
  4. Falls der Effekt dieser Aktivität im Sinne einer Aktivitätsgröße gemessen werden kann, gibt auch den Benutzer, welcher die gravierendsten Modifizierungen ausgeführt hat. Diese kann kombiniert werden mit den vorherigen beiden Strategien.

Im Grund genommen sollte die Strategie reflektieren, wie sehr das Objekt mit der letzten Aktion des Benutzers verändert hat und wie viel von dieser Veränderung in der neuesten Version des Objekts überlebt hat.

Rationale

McDonald und Ackermann führten eine ethnologische Studie durch zur Lokalisierung der Fachkompetenzen der einzelnen Teammitglieder durch die Art wie sie mit den Objekten umgehen. Die Autoren interviewten Teammitglieder eines Softwareentwicklungsteams wie sie reagieren wenn sie eine Frage haben: „Wenn ein Programmierer eine Veränderung in seinem Programm durchführt, sollte er sein Kürzel zu der Zeile hinzufügen und das Datum aktualisieren. So sieht man, wer das Programm zuletzt verändert hat. Wer auch immer die Veränderung in dem Programm durchgeführt hat ist der Standardexperte für dieses Programm…das liegt nahe. Die Logik dahinter ist, dass die Person die Zeit damit verbracht hat sich am besten daran erinnert und somit die beste Person ist um eine Frage zu stellen.“ An diesem Zitat kann man sehen, dass es traditionelle Methoden gibt, um die Kompetenz eines Benutzers zu beurteilen. Die Autoren entdeckten ein Problem, welches diesen Ansatz fehlschlagen lassen könnte. Wenn die Benutzer nur kleine Veränderungen durchführen, sind sie oft keine Experten an diesem Objekt. Das erfordert eine Methode zur Auffindung der Experten, die auf der Zahl oder auf der Auswirkung einer Veränderung basiert. Unabhängig von der ausgewählten Strategie wird das System den Antragsteller einen Benutzer finden, der Erfahrungen mit dem Objekt hat. Dieser Benutzer kann als Experte angesehen werde, der seine Erfahrungen mit dem Antragsteller teilt.

Check

Bei Anwendung dieser Methoden sollten diese Fragen beantwortet werden

  • Wie berechnet sich der Grad der Kompetenz eines Benutzers?
  • Welche Objekte und Aktivitäten sollten zur Berechnung dieser Kompetenz berücksichtigt werden?

Danger Spots

Es kann sehr kompliziert gültige Methoden zur Messung des Beitrags zur Modifikation zu finden. Es kann erfordern den Effekt einer Veränderung von der ersten bis zur letzten Version eines Objektes zurückzuverfolgen. Veränderung die immer noch in der aktuellen Version des Objekts sichtbar sind können als sehr wichtig eingestuft werden.

Known Uses

Experise Browser – Tool zur Unterstützung von Software-Entwickler-Teams. Die Fachkompetenz wird bestimmt durch die „Change History“ eines Software-Objekts. Wenn ein Entwickler eine Veränderung durchführt, wird diese in einem Versionsmanagement geloggt. Das Bild 3.37 zeigt das User-Interface zur Findung eines Experten. Ein Projekt-Objekt kann auf der rechten Seite der Abb. ausgewählt werden. Das System durchsucht dann alle Veränderungen dieses Objekts und berechnet Kompetenzlevels für alle Teilnehmer unter Beachtung aller gewichteter Veränderungen (Strategie 3 berücksichtigt nur Schreibaktivitäten und gewichtet diese wie in Strategie 4 beschrieben). Das Ergebnis wird auf der linken Seite dargestellt. Die mittlere Spalte zeigt die beitragenden Benutzer sortiert nach ihrer Expertise und die Schriftgröße stellt den Level der Expertise dar. Ein Benutzer kann den Experten kontaktieren, in dem er den Namen in der mittleren Spalte auswählt und auf die entsprechende E-Mail-Adresse am unteren Bildschirmrand klickt.

Memoir Sammelt alle Spuren des Web-Browsing Verhaltens der Benutzer. Wenn Benutzer Experten zu einem bestimmten Thema suchen, sammelt das System alle Spuren, welche Webseiten zu diesem Thema beinhalten. Die Experten werden nach der Anzahl der Keyword-Treffern in den Spuren der Benutzer gelistet.

Realted Paterns

Realisierung auf der eStudy-Plattform

Hall of Fame

Intent

Die Absicht ist: Honoriere die hilfsbereitesten Teilnehmer im System, in dem sie in der “Hall of Fame” gelistet werden.

Context

Euer Community-System erlaubt Nutzern ihrer Fähigkeiten zur Community beizutragen. Man will so die aktiven Benutzer zu noch größeren Anstrengungen motivieren.

Problem

Die Motivation zur Teilnahme in einer Community steht oft auch in dem Zusammenhang mit dem Feedback, welches die Teilnehmer von der Community erhalten. Trotzdem passiert es oft, dass der Beitrag von sehr aktiven Mitgliedern ungenügend von den anderen Mitgliedern erkannt wird.

Scenario

Susan war von Anfang an ein aktives Mitglied der Community. Sie war es, die die Rollenspiel-Engine implementiert hat, was das Gemeinschaftsspiel so erfolgreich gemacht hat. Trotzdem wissen das die neuen Mitglieder nicht. Susan unterstützte auch neue Mitglieder sehr. Trotzdem hat in den letzten Monaten das Interesse nachgelassen und die Community begann sie zu ignorieren, obwohl ihr Verlust ein großes Problem für die Community wäre.

Symptoms

Man sollte über die Anwendung diese Methode nachdenken, wenn:

  • Die Anzahl der passiven Mitglieder viel höher ist als die Anzahl der aktiven und das Verhältnis zwischen Vorteil und Anstrengung besser für die passiven Mitglieder ist als für die Aktiven. Das würde das RECIPROCITY verletzen.
  • Teilnahme ist ungleich verteilt, das resultiert in Frustration für jedes aktive Mitglied.
  • eilnahme nimmt mit der Zeit ab, obwohl das Thema für die Teilnehmer immer noch interessant ist.

Solution

Deswegen sollte eine Liste von den Teilnehmern bereitgestellt werden, die am meisten tun. Sollte der Grad der Teilnahme eines Teilnehmers in Zusammenhang mit dem Grad mit der Hilfsbereitschaft gegenüber anderen berechnet werden. Es soll die Möglichkeit geben sein, dass die Teilnehmer sich mit denjenigen in der „Hall of Fame“ vergleichen können.

Dynamics

Ein Teilnehmer trägt zu einer Community bei. Ein Teilnehmer kann entweder ein Mitglied der Community sein, oder der Gruppe der Benutzer. Die Beiträge der Teilnehmer werden von anderen Benutzern bemessen mit der Methode der Beitrags-Metrik. Eine Beitrags-Metrik kann z.B. die Eintrag von Posts in einem Forum sein. Die Teilnehmer mit der höchsten Bewertung werden in der Hall of Fame gelistet. Alle Mitglieder können die Hall of Fame durchsehen und alle Informationen über die Teilnehmer mit hohen Bewertungen ansehen. So ist ein Vergleich mit dem eigenen Beitrag möglich. Es ist wichtig die Hall of Fame an einem prominenten Platz innerhalb der Community zu platzieren.

Rationale

Die Hall of Fame fügt ein Element des Wettbewerbs hinzu. Nur die Teilnehmer die viel zu einer Community beitragen erhalten einen Platz in der Hall of Fame. Wenn Teilnehmer aufhören einen Beitrag zu leisten werden sie von anderen überholt. Vorausgesetzt, dass noch einige Member aktiv sind. Wie gut eine Hall of Fame funktioniert hängt sehr stark von der Community ab. Falls die Mitglieder der Community darauf aus sind zu wissen, wer der beste Teilnehmer ist wird der Wettbewerb verstärkt. Das hilft relativ passive Mitglieder zu aktiven Mitgliedern zu konvertieren.

Check

Wenn diese Maßnahme angewendet wird sollten diese Fragen beantwortet werden:

  • Wie kann der Grad der aktiven Teilnahme gemessen werden.
  • Wie kann wertvolle Teilnahme erkannt werden. Können die Benutzer die Teilnahme kommentieren? Z.B. durch die LETTER OF RECOMMENDATION
  • Wo sollte die Hall of Fame platziert werden?

Danger Spots

Der Unterschied in der Platzierung zwischen einem Newcomer und einem langfristigen Teilnehmer kann demotivierend sein, wenn man als neuer Benutzer der Hall of Fame auch hinzugefügt wird. Eine Lösung dafür ist es abzusichern, dass die Punktezahl mit der Zeit reduziert wird. Andererseits könnte es sein, dass viele Teilnehmer in der Vergangenheit aktiv waren, deren Aktivität aber nachgelassen oder ganz aufgehört hat. Aus demselben Grund müssen Newcomer sehr viel investieren, bevor sie in der Hall of Fame gelistet werden, falls sich die Punkte nicht reduzieren. Diese Reduzierung der Punktezahl kann z.B. erfolgen durch dividieren des erreichten Wertes durch die Zeit die seit diesem Beitrag vergangen ist. Teilnehmer können versuchen die Metrik auszutricksen, um eine bessere Position in der Hall of Fame zu erreichen. Man betrachtet z.B. das Beispiel eines Softwareentwicklungsprojekts. Da die Vitalität eines Projekts der Anzahl der Beiträge gemessen wird können die Projektteilnehmer hohe Vitalität simulieren, in dem sie durch posten von sinnlosen Nachrichten neues generieren.

Known Uses

Realted Paterns

Realisierung auf der eStudy-Plattform

Reward

Intent

Positive Teilnahme von Einzelpersonen oder Gruppen belohnen.

Context

Die Umgebung unterstützt Benutzer oder Benutzergruppen, welche aktiv an der Community teilnehmen. Es muss überlegt werden, wie die Mitwirkenden besser motiviert werden können etwas zur Community beizutragen, um die Zusammenarbeit in Gruppen zu fördern.

Problem

Die Community Akteure (Einzelperson oder Gruppe) beteiligen sich auf unterschiedlichen Ebenen. Sehr aktive Akteure sehen durch ihre Beiträge zur Community eventuell keinen direkten Vorteil. Hierdurch sinkt die Motivation und Teilnahme.

Scenario

Janet ist ein Experte auf dem Gebiet der Visualisierungs-Algorithmen. Viele Nutzer fragen Janet um Rat bei Fragen und Problemen auf diesem Gebiet. Janet verliert jedoch die Lust daran ständig Fragen zu beantworten. In dem seltenem Fall, dass Janet ein Problem hat, wird Ihr meist nicht geholfen. Beispielsweise hatte Janet erst kürzlich ein Sicherheitsproblem, aber Charley hatte keine Zeit ihr zu helfen, wobei sie ihm schon oft bei Visualisierungs-Problemen geholfen hat.

Symptoms

Über die Anwendung des Patterns sollte nachgedacht werden, wenn:

  • Akteure unterschiedliche Fähigkeiten haben.
  • Akteure auf ihrem Fachgebiet keine Hilfe benötigen, aber Fragen in anderen Bereichen haben.
  • Der Umstand, dass Benutzer A Benutzer B helfen kann nicht beinhaltet, dass Benutzer B von Benutzer A profitieren kann.
  • Die Community Akteure ungewöhnliche Dinge erledigen müssen.
  • Akteure unmotiviert sind, da andere die Früchte ihrer Arbeit ernten.
  • Manche Nutzer einer Gruppe öffentlich bekannt gegeben werden, aber andere unbemerkt bleiben.

Solution

Erstelle Tokens in deiner Community, welche die Benutzer, die sich positiv beteiligen, erhalten können. Ermögliche es den Benutzern mit ihren Tokens zu Handeln, um von anderen Mitgliedern Hilfe zu bekommen.

Dynamics

Jeder Benutzer hat einen Account, in dem alle erhaltenen Community Tokens gespeichert sind. Die Benutzer können als Service Provider oder Service Consumer handeln. Wenn ein Service Consumer Hilfe von einem Service Provider möchte, kann der Service Provider nach einer bestimmten Anzahl Tokens fragen. Bei Beiträgen zum allgemeinen Interesse der Community können neue Tokens generiert und an den Nutzer gegeben werden. Falls eine Gruppe sich Tokens verdient, werden diese fair unter den Gruppenmitgliedern aufgeteilt.

Rationale

Der Austausch der Nutzer untereinander basiert nun nicht mehr nur auf direktem Informationsaustausch, sondern auf dem Tokenaustausch, der nicht an ein bestimmtes Thema gebunden ist. Die Tokens fördern außerdem die Aktivität und Hilfsbereitschaft, da die verdienten Tokens benötigt werden, um Hilfe von anderen zu bekommen. Gruppen Tokens zu zahlen fördert außerdem die Zusammenarbeit in der Gruppe, um das gemeinsame Ziel zu erreichen.

Check

Bei der Anwendung dieses Patterns sollten folgende Fragen beantwortet werden:

  • Wie teuer soll ein bestimmter Service sein? Gibt es überhaupt genug Services, um unterschiedliche Preise festzulegen?
  • Wie kann Inflation verhindert werden? Macht es Sinn ein Limit für Tokens, die die Community erhalten kann, zu setzen?
  • Was können Benutzer mit ihren Tokens tun? Gibt es spezielle Events für Benutzer mit vielen Tokens? Kommen Benutzer mit vielen Tokens in die Hall of Fame?

Danger Spots

Es muss sichergestellt werden, dass jeder Benutzer durch positive Teilnahme Tokens verdienen kann, da sonst vor allem neue Benutzer abgeschreckt werden. Die Benutzer können süchtig danach werden das virtuelles Geld zu sammeln. Dies hat zur Folge, dass Interaktionen nur noch für möglichst großen Gewinn ausgeführt werden. Die Belohnung wird quasi zum einzigen Grund für Interaktionen und der eigentliche Hintergrund der Community geht verloren. Das Belohnungssystem kann auch dazu führen, dass Ideen nicht mehr geteilt werden aus Angst dass einem die Belohnung weggeschnappt wird. Deshalb muss aufgepasst werden, dass Gruppenarbeit nicht weniger belohnt wird. Durch die gleiche Aufteilung der Belohnung in Gruppen kann es passieren, dass Benutzer sich nicht mehr verwantwortlich für das Gruppenergebnis fühlen und den restlichen Gruppenmitgliedern die Arbeit überlassen. Um dies zu verhindern, kann es besondere Auszeichnung für sehr aktive Benutzer innerhalb einer Gruppe geben.

Known Uses

  • Experts-Echange: Ein Online-Hilfe-Forum, in dem Antworten mit Expert Points bezahlt werden.
  • eMule: Eine Peer-To-Peer File Sharing Börse, die ein Credit System für Transaktionen eingeführt hat.
  • SourceForge.net: Das Projekt des Monats erhält besondere Aufmerksamkeit. Auch die Namen der Entwickler werden hier gezeigt.

Related Patterns

Realisierung auf der eStudy-Plattform

Eine Realisierung des Reward Patterns ist mir auf eStudy nicht bekannt.

Save me . . . or how to protect users

Reciprocity

Intent

Es muss sichergestellt werden, dass Benutzer, die etwas zum System beitragen, belohnt werden. Je mehr ein Benutzer beiträgt, umso mehr soll er belohnt werden.

Context

Die Beiträge aller Benutzer eines Systems produzieren das Gruppenergebnis. Für eine optimale Zusammenarbeit sollte jedes Mitglied etwas beitragen, um das Gruppenziel zu erreichen.

Problem

Jeder arbeitet mit, wenn das Ziel für ihn lukrativ ist. Aber in vielen Fällen ist das Gruppenziel für machen Benutzer lukrativer als für andere. Dies kann zur Frustration führen.

Scenario

Charley macht sich Sorgen um die Stabilität der Spiele-Engine. Früher hatten sich die Entwickler damit einverstanden erklärt Test Cases für jeden hinzugefügten Code auszuführen. Aber neue Entwickler testen ihren Code nicht mehr. Beispielsweise testet Mario seinen Code für die neue Polygon Kalkulation nicht, da er davon ausgeht, dass er funktioniert.

Symptoms

Über die Anwendung des Patterns sollte nachgedacht werden, wenn:

  • Benutzer sich nicht gleichmäßig beteiligen, aber für das Gruppenergebnis gleich viel beisteuern sollen.
  • Manche Gruppenmitglieder das Gefühl haben, dass sie die ganze Arbeit machen.

Solution

Schaffen Sie ein Austauschverhältnis. Es muss sichergestellt werden, dass sich ein gutes Gruppenergebniss für alle Mitglieder auszahlt. Es muss unterbunden werden, dass Benutzer vom Gruppenergebnis provitieren, ohne als Gegenleistung etwas für das Ergebnis getan zu haben.

Dynamics

Die Benutzer interagieren über ein Groupware System, welches bestimmte Funktionen bietet. In der Aufbauphase entscheiden die Mitglieder für jede Funktion wer von dieser profitieren soll und wer mehr Arbeitsaufwand erbringen muss. Dies bedeutet, dass sie beschließen wer die Rechte erhält die Funktionen zu nutzen und wessen Rechte eingeschränkt sind. Möchte ein Benutzer eine weitere für ihn praktische Funktion nutzen, muss er eine zusätzliche Aufgabe übernehmen.

Rationale

Das Problem bei gemeinschaftlichen Systemen ist, die Benutzer zu motivieren aktiv mit zu arbeiten. Ohne die Teilnahme von Benutzern wird eine Community schnell inaktiv und die Fairness zwischen denen, die mitarbeiten und denen, die nur vom Ergebnis profitieren, geht verloren. Durch das Verbinden von praktischen Services mit weiterem Aufwand für die Community kann das Aufwand- und Nutzenverhältnis wieder hergestellt werden.

Check

Das Pattern wird hauptsächlich benötigt, wenn die Zahl der Benutzer so klein ist, dass die Mitarbeit aller Benutzer erforderlich ist. Bei einer sehr großen Community ist die Aktivität nur einiger Mitglieder nicht weiter nachteilig.

Known Uses

  • TUKAN: Eine collaborative Programmierumgebung, bei der durch Mitarbeit weitere Rechte erworben werden können.
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Modes of collaboration in the distributed software development environment TUKAN.
  • Bulletin Board System: Je mehr Informationen ein Benutzer frei gibt, umso mehr Informationen kann er bei anderen Nutzern einsehen.

Related Patterns

Realisierung auf der eStudy-Plattform

Eine Realisierung des Reciprocity Patterns ist mir auf eStudy nicht bekannt.

Masquerade

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Privatsphäre

Intent

Kontrolliere, wie viele private Informationen zwischen den Nutzern ausgetauscht werden.

Context

In einer geschlossenen Community gibt es von jedem Nutzer private Daten, wie zum Beispiel die E-Mail-Adresse, Jobinformationen, aktuelle Beschäftigungen oder Auszüge aus Forenbeiträgen.

Problem

Die Anwendung überwacht seine Nutzer - grundsätzlich um weiter Funktionen anbieten zu können und das Angebot zu verbessern. Nutzer mögen es aber nicht, wenn sie wissen, dass sie überwacht werden und geben aus dem Grund manche privaten Daten nicht oder falsch an.

Scenario

Beni und Kristina haben beide ihr Virtual Me in der Community eingerichtet. Die anderen Nutzer wissen, was sie an den beiden haben. In den letzten Wochen allerdings gefällt den beiden das Verhalten einiger Nutzer der Community nicht mehr. Normalerweise würden sie es einfach den Anderen sagen - sie haben beide nicht den Mut es zu sagen, weil sie dadurch vielleicht andere Mitglieder verletzten. Das Ergebnis ist, dass beide nichts sagen und hoffen, dass jemand anderes für sie übernimmt.

Symptoms

Man sollte sich über diese Pattern Gedanken machen, wenn einer der Folgenden Fälle zutrifft:

  • persönliche Informationen werden von Anderen missbraucht
  • Nachdem einmal Informationen missbraucht wurden, sind Nutzer extrem vorsichtig was dazu führt, dass die Mitarbeit sinken kann
  • Nutzer teilen zwar gerne Informationen mit ihren Mitstreitern, aber nicht mit Fremden oder ihren Chefs
  • Nutzer haben Angst an der Community teilzuhaben, weil sie möglicherweise von Anderen kritisiert wird

Solution

Aus diesen Gründen: Lass den Nutzer entscheiden, welche Informationen in welchen Anwendungsgebieten freigegeben werden. Die Nutzer müssen die Möglichkeit haben, sich anzeigen zu lassen, welche Infos sie teilen. Denke auch an Reciprocity.

Dynamics

Während der Interaktion mit einer Plattform kann der Nutzer entscheiden, welches Level an Datenschutz er benutzten möchte und welche Informationen er auf seinem persönlichen Profil einträgt. Der Unterschied zwischen dem Level und dem Profil ist, dass das Level global als Skala verwendet werden kann. Wenn man also ein hohes Level auswählt, gestattet man alle anderen Informationen, die unter diesem Level liegen auch. Bei einem Profil werden einzelne Aspekte einzeln betrachtet.

Rationale

Wenn die Nutzer entscheiden können, welche Informationen mit Anderen geteilt werden, haben Sie keine Angst mehr, in bestimmten Situation mehr Informationen preiszugeben. Allerdings haben Studien gezeigt, dass manchmal eine bessere Diskussion mit mehr Kritik zu Stande kommt, wenn die Nutzer gänzlich anonym sind.

Check

Wenn diese Pattern angewendet wird, sollte auf folgende Punkte geachtet werden:

  • Welche Informationen kann der Nutzer kontrollieren und welche Informationen sind nötig, um die Basisfunktionalität der Community zu erlauben?
  • Welche Level von Privatsphäre-Einstellungen werden angeboten?
  • Soll es anonyme Aktivitäten geben?

Danger Spots

Das Problem bei anonymen Aktivitäten ist, dass es schnell dazu kommen kann, das Nutzer Dinge machen, die dem gemeinsamen Arbeiten schaden, das sie nicht befürchten, entdeckt zu werden. Die Hemmschwelle sinkt dadurch. Man sollte anonymen Nutzern also nur beschränkte Funktionen anbieten - bei einem Forum beispielsweise nur Lesezugriff.

Known Uses

Related Patterns

Realisierung auf der eStudy-Plattform

Es gibt keine Privatsphäre-Level auf der Seite, sondern ein Profil, dass man so weit ausfüllen kann, wie man möchte. Ein guter Punkt ist der Datenauszug. Es werden einem alle Daten gezeigt, die mit dem eigenen Profil in der Community verknüpft sind.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Datenauszug auf eStudy

Availability Status

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Bitte nicht stören!

Intent

Wie und wo kann ein Nutzer bei seiner Arbeit unterbrochen werden?

Context

Die Community möchte, dass die Nutzer spontan miteinander interagieren.

Problem

Um gemeinsames, gleichzeitiges Interagieren zu erlauben, müssen Nutzer für Kontaktanfragen offen stehen. Jede Anfrage unterbricht einen in seiner Arbeit, egal an welcher Arbeit man sitzt. Zusätzlich kann es aus einem unwichtigen Grund passieren, dass man bei etwas Wichtigem unterbrochen wird.

Scenario

Kristina ist sehr hilfsbereit. Nachdem Kai das rausgefunden hat, hörte er auf Beni mit seinen Fragen zu belästigen und kontaktierte bei jeder Frage Kristina. Aber auch Kristina braucht Zeiten, in denen sie sich auf ihre Arbeiten konzentrieren kann. Wenn sie die Möglichkeit hätte, sich in diese Phasen vor Fragen von Kai zu schützen, könnte sie ihre Produktivität stark steigern.

Symptoms

Man sollte diese Pattern anwenden, wenn der folgende Fall zutrifft:

  • Nutzer mögen es, sich gegenseitig kontaktieren zu können, beschweren sich aber auch darüber, dass sie bei wichtigen Arbeiten unterbrochen werden.

Solution

Einbinden einer Statusanzeige, ob ein Nutzer gerade Erreichbar ist oder nicht.

Dynamics

Jeder Nutzer, der in dem System arbeitet, kann sich einen Status zuschreiben. Dieser kann nur "Verfügbar" oder "Nicht stören" sein, oder aber durch mehrere Stufen gehen, z.B. "Beschäftigt", "am Telefon" o.ä. Es ist nicht nötig, dass diese Status in einer Reihenfolge bestehen. "Beschäftigt" und "am Telefon" zeigen beide an, dass der Nutzer nicht gestört werden kann, aber es gibt keine Reihenfolge von den Beiden. In Fällen, in denen Gruppen kontaktiert werden können, sollen auch Gruppen eine Status erhalten. Der Beschäftigungsstatus wird zusammen mit dem Nutzer angezeigt, hat aber keine Einfluss darauf, ob und wie der Nutzer kontaktiert werden kann. Nutzer entscheiden selbst, ob sie einen anderen bei einem bestimmten Status kontaktieren oder nicht. In Fällen, in denen mehr Informationen zu einem Status gebraucht werden, sollte der Nutzer die Möglichkeit haben, einen eigenen Statustext hinzuzufügen, damit Jemand, der mit dem Nutzer Kontakt aufnehmen will, besser einschätzen kann, wie sehr gestört der Nutzer jetzt wäre.

Rationale

Das größte Problem, das mit diesem Pattern angesprochen wird, ist der Unterschied zwischen störendem Unterbrechen und Anfragen, die die aktuelle Situation benötigt. Wenn ein Nutzer einfach jegliche Kontaktanfragen blockt, stellt er seine Interessen über die der Anderen. Es kann sein, dass ein Nutzer kontaktiert werden muss. Wenn man aber alle Anfragen erlaubt, wird man schnell nur noch unterbrochen. Der Status eines Nutzers bringt den Vorteil, dass Nutzer entscheiden können, ob ihre Anfrage wichtig genug ist, denjenigen bei seiner aktuellen Arbeit zu unterbrechen. Dieses Pattern beruht auf sozialen Standards. Es ist unhöflich jemanden zu stören, der zeigt, dass er im Moment nicht gestört werden möchte.

Check

Wenn diese Pattern angewendet wird, sollten folgende Fragen geklärt werden:

  • Wie wird der Status angezeigt? Kann er bei jedem Nutzernamen angezeigt werden?
  • Welche Status sollten in der eigenen Applikation verfügbar sein?
  • Sollte der Status auch den Kontext beschreiben, in dem sich der Nutzer befindet, z.B. "am Telefon" oder "unterwegs"?
  • Brauchen Nutzer genauere Statusmeldung mit eigenem Text?

Danger Spots

Sicherstellen, dass jeder Nutzer seinen Status setzt, wenn er online geht. Weil das oft vergessen wird, kann es sinnvoll sein, einen "nicht-verfügbar" Status nur für einen begrenzten Zeitraum zu aktivieren.

Known Uses

schueler.cc ist eine Schüler-Community. Man kann seinen Online-Status anpassen, je nach dem, mit wem man zur Zeit kommunizieren möchte.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Messenger auf schueler.cc

MSN Messenger hat immer den Status aller Nutzer, die online sind. Neben vorausgewählten Status, wie "online", "offline", "nicht sichtbar", kann man auch eigene Status setzten und mit Texten versehen. So weiß jeder, ob man gerade angesprochen werden möchte oder nicht.

Datei:Msn.png
MSN Messenger

Related Patterns

Realisierung auf der eStudy-Plattform

Auch auf der eStudy-Plattform wurde das Pattern umgesetzt. Es gibt für den Chat verschiedene Status, vgl. Bild. Allerdings wurde hier die einfache Variante ausgewählt und man hat keine weiteren Informationen, warum jemand gerade beschäftigt ist und ob es in Ordnung wäre, ihn trotzdem zu unterbrechen, weil sein eigenes Anliegen wichtiger ist.

eStudy Mitglieder-Liste


Attention Screen *

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Filterung von Nachrichten die die Aufmerksamheit ablenken könnten

-- Jclm08

Alternative Namen: Message Filter, Go Away (Goldman et al., 2002)

Intent

Festlegen wer und was die Aufmerksamkeit eines Benutzers in Anspruch nehmen kann.

Context

In einem System in dem Informationen gemeinsam genutzt werden, gibt es Benutzer welche die Informationen bereitstellen und andere, die diese Informationen konsumieren. Einige Nutzer haben das Bedürfnis mit den Urhebern der Informationen in Kontakt zu treten. Dazu senden sie Nachrichten an den Urheber, durch welche die Aufmerksamkeit des Urhebers auf den Anfragenden gelenkt wird.

Problem

Jede Anfrage an einen Benutzer muss von diesem verarbeitet werden, was eine gewisse Aufmerksamkeit verlangt. Wenn ein Benutzer jedoch seine Aufmerksamkeit auf andere Dinge konzentrieren muss, dann sind solche Anfragen sehr störend.

Scenario

Rodrigo ist dankbar über das Feature, dass er schnell mit anderen angemeldeten Benutzern in Kontakt treten kann. Daher kontaktiert er oft den Spracherkennungsexperten Wil und fragt ihn über die Auffassungsgabe in Gesprächen aus. Das stört allerdings Wil, vor allem wenn er an komplexen Signalverarbeitungsalgorithmen arbeitet. Wil ärgert sich über dieses neue Feature und fragt Paul ob er das Feature wieder von System entfernen kann.

Symptoms

Dieses Muster sollte angewendet werden wenn:

  • Informationen, die nichts mit der aktuellen Aufgabe des Benutzers zu tun haben, im Vordergrund angezeigt werden.
  • Besprechungen durch Dinge unterbrochen werden, die nichts mit dem Thema zu tun haben, wie Telefonklingeln oder ein Kollege der mal kurz plaudern will.
  • Benutzer durch kurze Anfragen gestört werden und Probleme haben sich wieder auf ihr eigentliches Thema zu konzentrieren.
  • Benutzer durch Leute angesprochen werden, mit denen sie in der aktuellen Situation nicht kommunizieren wollen.

Solution

Daher sollten Benutzer die Möglichkeit bekommen Informationen zu filtern, die für sie bestimmt sind. Um dies zu ermöglichen, sollten Metainformationen, wie der Absender oder wichtige Schlagwörter aus dem Inhalt herangezogen werden, um wichtige von unwichtigen Informationen zu unterscheiden. Weniger wichtige Informationen sollten an einem Ort gesammelt werden. Wenn der Benutzer es wünscht, kann er diese Informationen später durchsehen und dann den Absender kontaktieren.

Dynamics

Ein Benutzer definiert Regeln für die eingehenden Anfragen (Nachrichten oder Ereignisse). Die Regeln definieren welche Eigenschaften der eingehenden Anfragen berücksichtigt werden sollen, sowie welche Wichtigkeit die verschiedenen Werte dieser Eigenschaften haben. Eine Regel kann zum Beispiel die Absenderadresse einer Email berücksichtigen und daraufhin einen Wert für die Wichtigkeit dieser Adresse berechnen. Dies kann zum Beispiel dadurch geschehen, indem die Adresse mit den Adressen in der BUDDY LIST verglichen wird. Im einfachsten Fall ist der Wert für die Wichtigkeit binär und gibt damit an, ob eine Aktion stattfinden darf oder nicht.

Wenn eine Anfrage empfangen wird, prüft das System die Regeln und kategorisiert die Anfrage je nach Wichtigkeit. Darauf basierend entscheidet das System wie mit der Anfrage umgegangen werden soll. Die einfachste Möglichkeit besteht wieder darin eine Aktion auszuführen oder nicht. Beispiele für Aktionen die je nach Wichtigkeit einer Anfrage ausgeführt werden können sind:

  • Spezielle Audiosignale oder andere Informationen, die die Aufmerksamkeit erregen (Wisneski et al., 1998)
  • Eine mehr oder weniger aufdringliche Art und Weise die Nachricht an den Benutzer heranzutragen
  • Speichern der Nachricht an einem Ort, den der Nutzer aufrufen kann, wenn er sonst keine wichtigen Aufgaben zu erledigen hat
  • Das Löschen der Anfrage

Rationale

DeMarco und Lister (1999) machten darauf aufmerksam, dass sich Unterbrechungen drastisch auf die Produktivität auswirken. Sie behaupteten, dass es ungefähr fünfzehn Minuten dauert um einen idealen Grad der Produktivität zu erreichen. Eine Unterbrechung von nur fünf Minuten würde somit eine Verringerung der Produktivität für eine Dauer von zwanzig Minuten bedeuten. Jackson et al. (2003) studierten die Auswirkungen von Unterbrechungen durch Emails. Sie beobachteten das Verhalten bei Email Eingängen von sechzehn Angestellten und fanden heraus, dass die Zeit zum Wiedereinfinden in den Arbeitsablauf nach Email Unterbrechungen viel geringer war (im Durchschnitt 64 Sekunden). Selbst eine so kurze Wiedereinfindungszeit ist immer noch signifikant.

Regeln reduzieren die Anzahl der Nachrichten, die direkt zum Nutzer durchdringen. Dies führt zu weniger Unterbrechungen und ermöglicht dem Benutzer sich auf seine Arbeit zu konzentrieren. Wichtige Ereignisse, die die sofortige Aufmerksamkeit erfordern, können jedoch diese Konzentration unterbrechen. Der Effekt der Wiedereinfindungszeit wird zusätzlich dadurch reduziert, dass Benutzer aktiv entscheiden können die unwichtigeren Nachrichten zu bearbeiten, wenn sie gerade nicht beschäftigt sind.

Andererseits werden wichtige Nachrichten nicht zurückgestellt. Dadurch werden wichtige Anfragen nicht mehr übersehen.

Check

Wenn dieses Muster angewendet wird, sollten sie folgende Fragen beantworten:

  • Welche Regeln machen in ihrem Kontext Sinn? Sollten die Regeln Gegenstände, Benutzer oder beides berücksichtigen?
  • Wie sollen ihre Benutzer die Regeln aufstellen? Soll ein einfacher Dialog nach den Eigenschaften von Ereignissen fragen oder soll es eine komplexe Variante sein, in der Benutzer Regeln mit Hilfe einer domänen spezifischen Sprache programmieren?
  • Können sie vordefinierte Regeln für alle Benutzer bereitstellen?
  • Wo sollen die Regeln abgelegt werden? Können sie auf einem zentralen Server gespeichert werden, um dieselben Regeln unabhängig von der aktuellen Client Konfiguration zu benutzen?
  • Kann der Benutzer eine Liste der aktuell definierten Regeln einsehen?

Danger Spots

Für unbefangene Nutzer kann die Definition von Regeln zu kompliziert werden.

Regeln könnten wichtige Informationen falsch klassifizieren, wodurch sie vom Benutzer ignoriert werden. Daher sollte nicht zu streng beim Filtern von Informationen vorgegangen werden. Wenn zum Beispiel nur Anfragen von Leuten aus der BUDDY LIST angenommen werden, hat der Benutzer Schwierigkeiten neue Kontakte zu knüpfen. Das wäre fatal in einem Community System, den dort ist es erforderlich, dass Mitglieder offen gegenüber anderen Mitgliedern sein können.

Known Uses

Mozilla Junk Mail Filter:

Der Junk Mail Filter in Mozilla blockiert eingehende Emails. Beim Eintreffen wird jede Email gemäß einem Benutzer trainiertem Junk Mail Filter analysiert. Das Ergebnis der Analyse gibt Aufschluss darüber ob die Email unerwünscht ist oder nicht. Der Benutzer kann den Filter kontrollieren, indem er bestimmte Eigenschaften festlegt, die während der Analyse berücksichtigt werden sollen (siehe Bild Mozilla’s Junk Mail Filter). Emails von Benutzern, die im Adressbuch des Benutzers eingetragen sind, werden zum Beispiel niemals als unerwünscht deklariert. Daher wird das Adressbuch auch von Mozilla als White List bezeichnet und ist gleichzeitig eine Implementierung des BUDDY LIST Musters.

Mozilla’s Junk Mail Filter

Im Konfigurationsdialog kann der Benutzer zudem festlegen, was passieren soll wenn eine Email als unerwünscht eingestuft wurde. Es gibt unter anderem die Möglichkeit die Nachricht zu löschen, in einen speziellen Ordner zu verschieben oder die Nachricht als unerwünscht zu markieren.

Instant Messaging Systeme wie MSN Messenger, ICQ, AIM oder Jabber stellen Modi bereit in denen nur Nachrichten von Benutzern in der BUDDY LIST akzeptiert werden. Wenn andere Benutzer, die nicht in der Buddy Liste sind, Kontakt aufnehmen wollen, wird der Benutzer darüber informiert. Darauf kann dann auf verschiedene Arten reagiert werden:

  • Die Anfrage kann für die laufende Sitzung angenommen werden und eine Kommunikation ist möglich.
  • Der anfragende Benutzer kann zur Buddy Liste hinzugefügt werden. Damit ist auch eine zukünftige Kommunikation möglich.
  • Der anfragende Benutzer kann zu einer blockierenden Liste hinzugefügt werden. Nutzer in dieser Liste können keinen Kontakt mehr mit dem Benutzer aufnehmen, Chat Anfragen werden somit unterbunden.

WebWasher (https://www.webwasher.com) ist ein Beispiel für ein System, welches spezielle Informationen aus dem Web blockiert, wie Links zu anstößigem Inhalt, Banner Werbung oder spezielle Medientypen wie MP3 Dateien. Der Benutzer oder Administrator muss zunächst einige Filterkriterien auswählen. Dann filtert WebWasher die Anfragen, die diesen Kriterien entsprechen und verhindert, dass störende Inhalte zum Benutzer übertragen werden.

Online Spiele stellen oft Möglichkeiten bereit Anfragen von anderen Spielern zu filtern. Beispiele sind Guild Wars (ArenaNet, 2005), Star Wars Galaxies (Sony Online Entertainment, 2003) oder World of Warcraft (Blizzard Entertainment). In jedem dieser Spiele kann der Benutzer eine 'Ignorieren Liste' anlegen und dem Spiel mitteilen welche anderen Benutzer ihn nicht kontaktieren können. In Star Wars Galaxies kann der Spieler zusätzlich global spezielle Arten von Anfragen blockieren, wie eine Einladung zum Handeln. Das Konzept hilft Spielern dabei sich auf die aktuelle Mission zu konzentrieren.

Related Patterns

AVAILABILITY STATUS erlaubt es Benutzern ebenfalls auszudrücken, dass sie nicht gestört werden wollen. Anstatt jedoch Anfragen zu filtern, basiert das AVAILABILITY STATUS Muster auf einem sozialen Protokoll und das Bewustsein des Benutzers über seinen Status. Wenn ein Benutzer nicht gestört werden will, kann das einem anderen Benutzer signalisiert werden. Die anderen Benutzer können dann selbst entscheiden ob sie gegen den Willen des Benutzers handeln wollen.

BUDDY LIST definiert diejenigen Benutzer, die vom Benutzer als erwünschte Kommunikationspartner angesehen werden.

BIRDS OF A FEATHER kann dazu genutzt werden die Liste der erwünschten Kommunikationspartner zu erweitern. Wenn zwei Nutzer viele Gemeinsamkeiten haben, ist es sehr wahrscheinlich, dass sie miteinander in Kontakt treten wollen.

MASQUERADE stellt eine Möglichkeit bereit unsichtbar in einem System zu agieren. Wenn Anfragen jedoch auf gegenseitiger Anwesenheit basieren (wie in Instant Messaging Systemen), werden andere Benutzer nicht die Möglichkeit haben ihre Anfragen an einen unsichtbaren Benutzer zu senden, da sie annehmen müssen, dass der Benutzer nicht anwesend ist.

FIREWALLS (Coplien und Harrison, 2004) nehmen eine spezifische Rolle ein um Teammitglieder eines Projektes vor externen Kommunikationspartnern abszuschirmen. Die Logik dahinter ist, dass ein Team zu speziellen Zeiten einen Bereich haben sollte, in dem es hochkonzentriert und effizient an seinen Aufgaben arbeiten kann.

Realisierung auf der eStudy-Plattform

Im Nachrichtenmodul können Mitglieder auf die Ignorierenliste gesetzt werden.

Quick Goodbye *

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Quick Goodbye

-- Jclm08

Alternativer Name: Easy to Unsubscribe (Goldman et al., 2002)

Intent

Es Benutzern einfach machen eine Gruppe zu verlassen.

Context

Benutzer stehen lange Zeit mit einer Gruppe in Verbindung.

Problem

Die Zeitspanne zwischen dem Eintritt eines Benutzers in eine Gruppe und dem Wunsch die Verbindung wieder zu trennen kann sehr lange werden. Daher können Benutzer vergessen wie sie die Gruppe verlassen können.

Scenario

Gianna war nun für einige Monate ein Mitglied der Game Engine Community. Anfänglich plante sie mehr über Game Design herauszufinden, doch nun stellt sie fest, dass sich die technischen Diskussionen der Spieleentwickler mehr um allgemeine Softwareentwicklung drehen. Leider hat sie vergessen wie sie die Community verlassen kann, daher erhält sie immer noch Nachrichten aus der Gruppe sowie Einladungen von anderen Mitgliedern um an gemeinsammen Treffen teilzunehmen.

Symptoms

Sie sollten dieses Muster anwenden wenn:

  • Benutzer andere Benutzer um Rat fragen, wie eine Gruppe verlassen werden kann.
  • Nach kurzer anfänglicher Aktivität die Nutzer inaktiv werden und nicht mehr auf Anfragen reagieren. (Denken Sie daran, dass dies sowohl stille Mitleser als auch Leute sein können, die nicht wissen wie man die Gruppe verlassen kann)

Solution

Seinen Sie sich daher darüber im klaren, dass Nutzer zu jeder Zeit den Wunsch haben eine Gruppe zu verlassen. Gestalten Sie es für diese Leute möglichst einfach eine Gruppe zu verlassen und stellen Sie einen einfachen Zugang zu dieser Funktionalität bereit. Verlangen Sie von Benutzern nicht im Detail zu wissen wie das System Registrierungen handhabt.

Dynamics

Die wichtigste Nachricht dieses Musters ist, dass das Austragen aus einer Gruppe einfach gehalten und leicht auffindbar sein soll. Wenn Benutzer in einer Gruppe aktiv sind, sollten die Informationen, die während der Interaktion ausgetauscht werden, eine Möglichkeit zum abmelden enthalten. Wenn die Nutzer zum Beispiel per Email kommunizieren, können Sie im Fuß der Email einen Link zum Abmelden unterbringen. Wenn sie über ein Online System oder einen Computer interagieren, sollten Sie einen Menüknopf breitstellen, der ermöglicht die Gruppe zu verlassen. Dieser sollte nicht in Untermenüs versteckt werden, sondern direkt im Hauptmenü erreichbar sein.

Eine Gruppe zu verlassen sollte nicht mehr Aufwand erzeugen, als auf einen Link oder Knopf zu drücken. Fragen Sie nicht nach spezifischen Informationen, die der Nutzer vor langer Zeit bereitgestellt hat, wie ein spezielles Passwort, da die Benutzer es in den meisten Fällen vergessen haben werden. Nachdem der Benutzer die Funktion zum Abmelden angestoßen hat, sollte das System nocheinmal eine Bestätigung vom Benutzer einholen. Wenn zugestimmt wurde, wird der Benutzer vom System entfernt oder als ehemaliger Nutzer markiert, falls die Beiträge und die Identität für den Rest der Gruppe sichtbar bleiben soll.

Rationale

Wenn ein einfacher Weg bereitgestellt wird, wie Nutzer eine Gruppe verlassen können, hilft das die Anzahl der nicht interessierten Mitglieder zu verringern. Dies sind haupsächlich inaktive Leute, die auf keinerlei Anfragen reagieren und im Gegensatz zu stillen Mitlesern nicht länger daran interessiert sind, was die Gruppe macht. Zudem ist es dann für aktive Mitglieder einfacher potentielle Gesprächspartner zu finden.

Aus technischer Sicht wird es zudem einfacher nicht interessierte Mitglieder auf dem Laufenden zu halten.

Die Gruppe wird auch nicht länger uninteressierte Mitglieder mit unwichtigen Informationen belästigen. Mit dem Wissen, dass man eine Gruppe einfach verlassen kann, erhöht die Motivation zunächst doch beizutreten.

Eine alternativer weg um Benutzer aus einer Gruppe zu entfernen, ist Benutzerkonten nach einer festgelegten Zeit der Inaktivität automatisch zu löschen. Das ist jedoch eine schlechte Idee, weil inaktive Benutzer einen guten Grund für ihre Inaktivität haben könnten.

Check

Wenn Sie dieses Muster anwenden, sollten Sie folgende Fragen beantworten:

  • Welche Schritte sind in der Anwendung nötig um eine Gruppe zu verlassen?
  • Wo sollten Informationen untergebracht werden, die beschreiben wie man eine Gruppe verlässt?
  • Sollen Benutzerkonten gelöscht werden oder als inaktiv markiert werden, wenn eine Gruppe verlassen wird? Wenn das erste zutrifft, was soll dann mit den Informationen geschehen die der Benutzer über das VIRTUAL ME Muster bereitgestellt hat?

Danger Spots

Auch wenn Informationen zum Abmelden bei jeder Interaktion in der Gruppe bereitgestellt werden, kann es immer noch zu kompliziert für Benutzer sein eine Gruppe zu verlassen. Bei einer Mailing Liste zum Beispiel in der in jeder Email im Fuß die Anweisungen zum Abmelden enthalten sind, wird es immer noch Nutzer geben die die Anweisungen an eine falsche Adresse senden zum beispiel direkt an die Mailing Liste. Ron Goldman konnte selbst miterleben, wie eine große Anzahl von Abmeldungs Emails fälschlicherweise an ein Forum gesendet wurden: "Es ist irgendwie lustig zu sehen wie jemand versucht sich in seiner Nachricht klar und deutlich abzumelden und darunter steht genau wie es richtig funktioniert." (Goldman et al., 2002) Versuchen sie daher den Abmeldeprozess wirklich einfach zu gestalten.

Es kann kompliziert sein Benutzerkonten zu löschen, weil es immer noch aktive Referenzen auf dieses Konto geben kann. Ein Benutzer kann zum Beispiel als Autor eines Beitrags auftauchen. Diesen Vorgang für Benuter abzuwickeln, die das System verlassen wollen kann kompliziert sein. Das System kann dann entweder immer noch den Benutzernamen anzeigen und dazusagen, dass der Nutzer kein Mitglied mehr ist oder einen neutralen Benutzernamen anzeigen.

Es ist kompliziert es Benutzern zu ermöglichen sich einer Gruppe wieder anzuschließen, wenn das Konto gelöscht wurde. Wenn das jedoch wichtig ist, sollten sie ein Benutzerkonto lediglich als gelöscht markieren und mit vollen Rechten wieder reaktivieren wenn der Benutzer sich der Gruppe wieder anschließen will.

Known Uses

Yahoo Groups fügt zu jeder Nachricht einen Link hinzu, der genutzt werden kann die Gruppe zu verlassen. Wenn auf diesen Link geklickt wird öffnet sich einen neue Email mit vordefiniertem Betreff. Wenn der Benutzer diese Email absendet erhält er eine Bestätigungsnachricht. Antwortet er auf diese Email wird er endgültig aus der Gruppe entfernt. Die Antwort ist an eine Anfrage-spezifische Antwort Adresse gerichtet die der Yahoo Groups Server der Originalanfrage des Benutzers zuordnen kann.

Obwohl es einfach aussieht hat dieses Vorgehen einen Hacken: Wenn das Email Programm des Benutzers so konfiguriert ist, dass Emails von einem anderen Konto abgesendet werden, kann der Yahoo Groups Server die Anfrage dem anfragenden Benutzer nicht zuordnen. In diesem Fall schlägt die Abmeldung fehl.

Eine Yahoo Gruppe verlassen

Related Patterns

QUICK REGISTRATION erklärt wie ein Benutzer einfach einer Gemeinschaft beitreten kann.

QUALITY INSPECTION beschreibt wie Benutzer gezwungen werden können eine Gruppe zu verlassen.

ATTENTION SCREEN ist eine Alternative, wenn ein Benutzer wünscht nicht gestört zu werden. In diesem Fall können sie sich selbst so abschirmen, dass keine weiteren Nachrichten zu ihnen durchdringen, aber sie bleiben immer noch Mitglieder der Gemeinschaft. Das mach das "Wiederanschließen" an die Gruppe einfacher.

ALIVENESS INDICATOR zeigt wie aktive von inaktiven Benutzern unterschieden werden können. Aus der Sicht der Gemeinschaft kann dies nützlich sein um uninteressierte Nutzer zu verwalten.

Realisierung auf der eStudy-Plattform

  • Abmeldung von der Plattform ist im Profil möglich.
  • Abmeldung von einem Kurs oder einer eCom ist im Modul Kurse und eCommunities möglich.
  • Im täglichen Newsletter wird im Fuß daruf hingewiesen wie man das Portal verlassen kann.