UProtokoll 06 03 15

Aus Chaos Computer Club Berlin
Wechseln zu:Navigation, Suche

Open Software Usability Stammtisch

Protokoll vom 15. März 2006

(Protokoll von Carsten Grandke)


1.

Status der alten OU-Seite: Ellen zeigt die Seite und erläutert ein paar Probleme:

  • Gforge(?)
  • Plattform kann nicht genug Content-arten und ist zu projektfixiert
  • Peer review der Experten funktioniert nicht.
  • allgemein zu geringe Aktivität

2.

Ellen stellt das neue Site-Konzept anhand der Map und dem Content-Konzept von Björn vor. Get the party started:

Content/Struktur

  • Kritik an der offenen Content-Matrix (alles ist mit allem verwoben): Es braucht klare Einstiege und "Führung der Ahnungslosen" in der Site. Stichworte: "Get Help", "Learn more" "Try & Practice", "Share it", etc.
  • Die Bereiche Knowledgebase und Collaboration/Discussion müssen klar getrennt werden.
  • Allgemein die Frage: was motiviert Experten, sich an die Site/an Projekte zu binden?
  • Welche Erfolgserlebnisse können in frühen Stufen der Teilnahme angeboten werden (siehe Bereich "Splash Screen" in der Sitemap?)
  • Wie wird die redaktionelle Betreuung der Site (Struktur und Thesaurus) dauerhaft organisiert?
  • Thema Zusammenfassungen/Knowledgebase (KB): Wie funktioniert der Workflow für Zusammenfassungen? Welche Motivation kann es für diese Arbeit geben? KB-Artikel können nur von UExperten geschrieben/zusammengefasst werden, alles andere sind Erfahrungsberichte.
  • Ist es das Ziel von OU.org, auch generelle Guidelines für verschiedene OS-Projekttypen/Softwaretypen zu entwickeln? Als Bsp. kann das CMS-Guidlines-Projekt auf OU.org gesehen werden. Konsens: Ja, das geschieht innerhalb der "Workgroups".
  • Wie integriert sich OU.org in die bestehenden Infrastrukturen der OS-Projekte? Muss OU.org als Plattform benutzt werden, wenn ein Projekt registriert ist?
  • Wie öffentlich wird gearbeitet? Können Projektmaintainer und UExperten "closed door" arbeiten, ohne das Rauschen von außen?

Contentbewertung/Expertenbewertung/Qualitätssicherung:

  • Das Bewertungsmodell ist sehr komplex, wahrscheinlich zu komplex. Daher ist es nicht transparent für die Einsteiger.
  • Bewertungen der Suchergebnisse sollten hauptsächlich über Klicks erfolgen. Eine explizite Bewertung kann zusätzlich gemacht werden, sollte aber nachrangig sein.
  • Expertenbewertung: Das peer-review von Gforce funktioniert nicht. Als praktikabel wird angesehen, dass UEs sich nach einer Vorlage selbst darstellen.
  • Die Bewertung der UEs birgt die Gefahr, das Anfänger nicht zum Zuge kommen, weil keiner Anfänger will. Das kann zum Teil über standardisierte Aufgaben (Evaluation, Erfahrungsbericht, etc.) abgefangen werden, die jeder immer für alle Projekte machen kann.
  • Die Beiträge eines UE sollten mit seinem Profil sichtbar sein.
  • Weitere, aber komplizierte bzw ungenaue Möglichkeiten zur Bewertung sind: Aktivitätsindex, Referenzen, Karmapunkte...

Projektregistrierung

  • Die Schwelle für Projektregistrierungen sollte angehoben werden. Gleichzeitig muss vor der Registrierung der Aufwand / die Anforderungen an ein OU.org-Projekt sehr deutlich werden.
  • Nur noch OS-Projektmaintainer sollten ein Projekt anmelden können. Sonst wird das nix.
  • Eine Projektvision muss vorhanden sein oder als erster Schritt im Projekt entwickelt werden.
  • Eventuell ein "Letter of Intent" entwickeln, das von Projekten akzeptiert/unterschrieben werden muss. Soll es Strafen geben, und wenn ja welche?
  • "Hit&Run"-Kollaboration soll unterstützt werden. Das heißt, UEs oder andere, die gerade etwas Zeit haben, können sich für ein Projekt eine offene Aufgabe greifen, diese machen und das wars.
  • Erfolgsgeschichten müssen gut aufbereitet vorhanden sein, um den Wert von OU.org zu vermitteln (Eigenmarketing)
  • Es soll templates und Anleitungen für Erfolgsgeschichten geben, damit UEs und Projekte Unterstützung bei der Selbstdarstellug ihrer Erfolge haben.
  • Projektmaintainern muss das Wissen an die Hand gegeben werden, was ihr Projekt brauchen kann, damit sie einen UE auswählen können. Die Prozesse zur Usability-Einbindung und die Tasks müssen transparent gemacht werden * "Usability 101 for Coders".
  • Wie präsent soll die "Dating-Funktion" von OU.org sein?

Ein Ende der Skala ist das simple Zusammenbringen von UEs und Projekten, alles weitere sollen die dann unter sich ausmachen, aus jenseites von OU.org Am anderen Ende stehen detallierte Profile für UEs und Projekte und automatisierte Vorschläge zur Zusammenarbeit.

UseCases:

  • Ellen hat UseCases, die noch veröffentlicht werden
  • Wichtige: Projektanmeldung

Förderung von UE-Anfängern

  • Eigene Evaluationen sollten mit anderen Verglichen werden können.
  • Ein Konzept für ein Mentor/Student-Modell muss her
  • Ein "Summer of Usability" (wird dann wohl eher ein "Winter of Usability") ist Erfolg versprechend. Janet Haven wäre da eine Kooperationspartnerin.

Organisatorisches

  • Geplanter Release-Termin ist im Herbst/Winter.
  • Der CCC OSUS-Stammtisch wird sich im 2-Wochen-Rhythmus mit openusability.org beschäftigen dazwischen sind Termine mit konkreten Methoden oder Beispielen, damit es nicht zu langweilig wird.
  • Da viele UEs im Stamtisch in der Konzeption von Ou.org beteiligt sind, fehlt uns ein "externer UE". Die Rollenverteilung der UEs muss geklärt werden.

Next Steps

  • Dieses Protokoll ergänzen und ordentlich strukturieren.
  • Infrastruktur für das Redesign festlegen und zusammenführen (relevantive)
   Bisher:
   Projektspace auf http://plone.openusability.org:8080/ou/all-about-ou (registered user only) - Testsystem, nicht benutzen!
   Projekt im alten OU.org: http://www.openusability.org/projects/openusability/
   CCC Wiki https://berlin.ccc.de/index.php/Usability_Stammtisch
   Mailingliste http://www.openusability.org/mailman/listinfo/berlin
   irc #openusability auf irc.freenode.net
  • 5 Szenarios für OU.org incl. "Erfolgserlebnissen" erarbeiten (UEs)
  • UseCases veröffentlichen
  • Produktvision für Openusability.org ausformulieren (dazu evtl. nächsten Termin zur KDE vision abwarten)
  • Rollenverteilungen festlegen
  • ToDo: Konzept für die Qualitätsprüfung/den Redaktionsworkflow in der knowledgebase (KB).

Hinweise

Vorschlag: Das aus der OU-Perspektive evaluieren. Pluralistic walkthrough? Wann?