Seite 2: Usability in Open-Source-Projekten

Inhaltsverzeichnis

2 Usability in Open-Source-Projekten

Bis heute verfügen wenige Open-Source-Projekte über eine ausgeprägte Usability-Community. Zwar haben Nutzer, Entwickler und andere Interessenvertreter die Möglichkeit, Kommentare und Verbesserungswünsche in Usability-Mailinglisten oder -Foren zu diskutieren, doch ist der Anteil der fachlich geschulten Mitwirkenden verschwindend gering. Selbst große Projekte wie die Linux-Desktops KDE und GNOME verfügen nur über einen geringen Anteil an ausgebildeten Usability-Studenten oder -Professionals.

Das geringe Engagement von Usability-Experten in Open-Source-Projekten scheint auf den ersten Blick verwunderlich: Wie Mühlig (2005) beschrieb, kann die Usability Arbeit in OSS-Projekten äußerst erfüllend sein. Da individuelle Entwickler oft über hohen Einfluss verfügen, können substanzielle Änderungen aus Usability-Empfehlungen zeitnah und ohne Diskussionen umgesetzt werden, ein Erfolgsgefühl, das man derart in kommerziellen Projekten selten erfährt. Auch eignen sich Open-Source-Projekte sehr gut zur Aus- und Weiterbildung, da selten Grenzen durch Zeitdruck gesetzt sind und keine Vertraulichkeits-Vereinbarungen getroffen werden müssen.

Eventuell sind die Schwellen bei der Annäherung zu hoch: Welches Open-Source Projekt soll man als Usability-Spezialist unterstützen, wie kann man es ansprechen? Wie kommt man als Open-Source-Projekt an kompetente Usability-Leute? Um diesen Erst-Kontakt zu erleichtern, wurde 2004 die Plattform OpenUsability (10) gegründet, die interessierte Open-Source-Projekte und Usability-Spezialisten zusammenbringt.

Die Plattform erlebte seit ihrer Gründung sowohl auf Seite der Entwickler als auch der Usability-Spezialisten einen starken Zuspruch, der sich unter anderem in der Zahl an Registrierungen oder Pressemeldungen widerspiegelte. Trotzdem wird bis heute nur ein Bruchteil der rund 170 registrierten Projekte (Stand: Oktober 2006) aktiv betreut. Während hierfür zum Teil Schwächen der Plattform verantwortlich sind – Usability-Spezialisten werden nicht in ausreichender Weise über interessante Projekte oder offene Jobs informiert – stellte sich zusätzlich heraus, dass unter bestimmten strukturellen Bedingungen Probleme bei der Kooperation zwischen Usability und Open-Source-Entwicklung auftreten, die dazu führen können, dass die Zusammenarbeit frühzeitig im Sande verläuft.

In den drei Jahren aktiver Usability-Arbeit im Rahmen des Projektes OpenUsability konnten wir Faktoren identifizieren, welche die fortlaufende Zusammenarbeit zwischen Usability und Entwicklung in Open-Source-Projekten beeinflussen. Diese beschreiben zum einen Voraussetzungen der Usability-Arbeit in Open-Source-Projekten, zum anderen strukturelle Eigenschaften in der Community.

2.1 Voraussetzungen der Usability-Arbeit in Open-Source-Projekten

Ein wesentliches Mantra der Usability ist der Leitsatz "Know your User". Denn ohne Kenntnis, wer eine Software später verwenden wird, welche Anforderungen er hat und welche Aufgaben er mit der Software bestreiten wird, ist eine nutzerorientierte Entwicklung, wie in der Einleitung beschrieben, nicht möglich.

Beschreibung der Zielgruppe

In Open-Source-Projekten ist die Frage der Zielgruppe oft nicht eindeutig geklärt. Fragt man Entwickler, für wen sie Software entwickeln, erhält man selten klare Aussagen. So wird häufig der wenig spezifische Durchschnittsnutzer oder Jedermann genannt (z. B. Trillitzsch 2006). Der Gedanke des freien Quellcodes wird hier auf die Nutzerschaft übertragen: Was für alle frei zugänglich sein soll, soll auch für alle gleichermaßen zur Nutzung bereitstehen. Außer Acht wird dabei gelassen, dass die vielzitierte Tante Tillie (z. B. Raymond 2004) und der Geek , also der professionelle Softwareentwickler, sehr unterschiedliche Ansprüche an eine Software haben. Für den Usability-Betreuer ist es schwierig, die Software auf den Endnutzer abzustimmen, da je nach Fragestellung die eigenen Bedürfnisse, die des Powerusers oder meiner Oma angeführt werden. (11)

Auch im GIMP-Projekt (12) , einer Software zur Manipulation von Bildern, zeichnete sich dieser Trend ab: Als lange Zeit einzige ernstzunehmende freie Bildbearbeitungssoftware versuchte der GIMP, die gesamte Bandbreite an potenziellen Nutzern zu bedienen. Diese reichte von Gelegenheitsnutzern, die beispielsweise die Bildgröße oder den Rote-Augen-Effekt eines Fotos manipulieren wollten, bis hin zum professionellen, künstlerischen Einsatz.

Die fehlende Ausrichtung auf eine definierte Zielgruppe resultierte in einem unkontrollierten Zuwachs an Funktionalität, vor allem im Bereich der Filter und Erweiterungen. Selbst für geübte Nutzer wurde es immer schwieriger, einen Überblick über die Funktionalität zu erhalten. Mehrere Usability-Berater, die im Rahmen des Projektes OpenUsability über mögliche Lösungsansätze bezüglich der Usability des GIMP diskutierten, drehten sich immer wieder im Kreis, wenn es zu der Frage kam, welche Funktionalitäten eine Überarbeitung benötigten.

In einer Sitzung zur Definition der Zielgruppe des GIMP bei der Libre Graphics Conference in Lyon 2006 wurde die Zielgruppe schließlich klar auf High-End-Nutzer festgelegt (Joost und Quinet 2006). Diese richtungsweisenden Vorgaben erlauben nun die Priorisierung der Schritte bei der anstehenden Überarbeitung der Informationsarchitektur und des Interaktionsdesigns des GIMP.

Repräsentative Nutzung des User-Feedbacks

Aber Usability-Arbeit bedeutet nicht zwangsläufig wie beim GIMP eine Neudefinition der bestehenden Nutzergruppe. Oft fehlt in Open-Source-Projekten lediglich eine klare und übersichtliche Erfassung von Nutzer-Bedürfnissen.

Bug-Tracking-Systeme oder User-Foren erlauben zwar prinzipiell jedem Nutzer, seine Bedürfnisse zu kommunizieren, doch werden sie oft nur von einem bestimmten Teil der Gesamt-Nutzerschaft verwendet. Auch fühlen sich Entwickler oft überfordert von der Menge an Einträgen, so dass sie zu vorschnellen Urteilen beim Akzeptieren oder Ablehnen von Anfragen neigen: In einer Analyse der Bugtracking-Systeme verschiedener GNOME-Applikationen verglich Yeats (2006) die Reaktionen von Entwicklern auf Feedback von sogenannten Code-Savvy-Nutzern also Bug-Reports, die Wissen über die Quellcode-Struktur erkennen ließen mit Reaktionen auf Bug-Reports ohne Bezug zum Quellcode. Die Kommentare der normalen Nutzer wurden meist zugunsten der Code-Savvy-Kommentare vernachlässigt.

Auch in Nutzer-Foren werden feature requests von normalen Nutzern häufig vorschnell anhand technischer Maßstäbe bewertet (Yeats 2006). Als Resultat greifen user innovation cycles (von Hippel 2005) nicht mehr. Oft werden lange nicht alle innovativen Ideen, die aus kontinuierlichen Rückmeldungen von Nutzern der eigenen Software gewonnen werden könnten, auch tatsächlich aufgegriffen. Der Erfolg des Apache-Servers gegenüber proprietären Alternativen ist laut von Hippel beispielsweise maßgeblich auf derartige Feedback-Zyklen zurückzuführen.

Sinnvoller wäre folglich eine Bewertung anhand der Gewichtung der Einträge: Ausschlaggebend sollte sein, ob ein feature request, also der Wunsch nach zusätzlicher Funktionalität, von einer Einzelperson gestützt wird oder ob eine Vielzahl an Nutzern dahintersteht.

Um Bewertungen, Meinungen und feature requests zusammenzuführen, eignen sich repräsentative Umfragen innerhalb der Nutzer-Basis. Bei zahlreichen Projekten, die auf OpenUsability registriert sind, konnten Umfragen helfen, Features zu priorisieren und so die Entwicklung in die Richtung der Nutzer-Bedürfnisse zu lenken, statt sie durch technische Machbarkeit oder Herausforderung leiten zu lassen.

2.2 Strukturelle Eigenschaften der Community

Strukturelle Eigenschaften der Community kommen vor allem in großen Projekten zum Tragen, in denen die Zusammenarbeit nicht mehr ohne ein gewisses Maß an Management und Organisation funktioniert. Hier handelt es sich nicht nur um OSS-spezifische Merkmale. Auch proprietäre Software-Entwicklung kämpft mit ähnlichen Problemen, wenn Kommunikationspfaden und Wissensmanagement beim Wachstum zu wenig Beachtung geschenkt wurde.

Trotzdem treten gewisse strukturelle Merkmale, die Auswirkungen auf die Usability-Arbeit haben, in OSS-Projekten häufiger auf als in proprietären Projekten. Eines dieser Merkmale ist die hierarchische Struktur, die häufig mit dem Erfolg einer Open Source-Software korreliert (Healy und Schussman 2003).

Auch in der Usability-Arbeit stellte sich dieser Faktor als relevant heraus: Fehlende hierarchische Entscheidungswege stellen in großen Projekten Probleme bei der Zusammenarbeit dar. Möchte ein Usability-Spezialist hier Vorschläge umsetzen, muss er jeden einzelnen Entwickler von den Vorteilen überzeugen, statt eines einzelnen project leaders (13).

Dass Entwickler in Open-Source-Projekten normalerweise das letzte Wort haben, bezeichnete Patricia Jung (2006) als das Primat der Programmierer : Diejenigen, die den Code schreiben, tragen die Entscheidung über Features und Gestaltung des User Interfaces. Dieses Primat ist unproblematisch, so lange die Entwickler gegenüber Usability aufgeschlossen sind und Vorschläge ernsthaft diskutieren und umsetzen. Sind einzelne Entwickler jedoch skeptisch oder gar abgeneigt, so kann eine ganzheitliche Umsetzung von Änderungen am User Interface nicht mehr garantiert werden.

Im Projekt KDE, einer Desktop-Umgebung für Linux, zeigen sich die Auswirkungen hierarchischer Entscheidungswege und des Primats der Programmierer besonders deutlich. Durch seine Größe und Struktur stellt die Summe der KDE-Teilprojekte ein gutes Vergleichsstudienobjekt dar, da es neben dem Core aus einer Vielzahl an kleineren, unabhängigen Software-Projekten besteht. Eine konsistente hierarchische Struktur ist zwischen den einzelnen KDE-Teilprojekten nicht zu beobachten. Während manche Projekte ein strenges Reglement dahingehend aufweisen, welcher Entwickler welchen Code beitragen darf, sind andere offen. Dies hat auch Auswirkungen auf die Möglichkeiten von Usability-Spezialisten und ihre Bereitschaft, sich aktiv an Open-Source-Projekten zu beteiligen.

In den folgenden Abschnitten werden die Begebenheiten bezüglich der Beobachtungen von Jung (2006) und Healy und Schussman (2003) in einzelnen KDE-Teilprojekten näher beschrieben und der Zusammenhang zur Integration von Usability-Methoden veranschaulicht.