Seite 3: Die Rolle der Usability-Befürworter im Projekt

Inhaltsverzeichnis

Die Rolle der Usability-Befürworter im Projekt

Zunächst betreuten verschiedene OpenUsability-Berater einzelne KDE-Projekte wie Kontact, Kivio, DigiKam oder Kuroo. Jedes dieser Projekte umfasste eine überschaubare Anzahl an Entwicklern, zudem hatten jeweils die einflussreichen Kern-Entwickler – leader im Sinne von Healy und Schussman (2003) (13) – um Usability-Beratung gebeten, waren der Thematik gegenüber also aufgeschlossen. Die Zusammenarbeit wurde von beiden Seiten als fruchtbar bewertet.

Anders der Beginn der OpenUsability-Aktivität im Projekt Amarok, einem Audio-Player für KDE: Hier bat ein einzelner Entwickler um Usability-Beratung, ohne die Kern-Entwickler des Projektes darüber zu informieren. Ein Usability-Spezialist führte bald darauf eine Analyse durch und leitete die Ergebnisse an das Projekt weiter. Die Core-Developer, die ja nicht selbständig um Usability gebeten hatten, fühlten sich durch den Report angegriffen und beachteten ihn nicht weiter.

Ein Grund, der zu dieser enttäuschenden Reaktion führte, war die fehlende Absprache mit den Projektleitern. Wie in der proprietären Software-Entwicklung auch kann Usability nur effektiv umgesetzt werden, wenn die einflussreichen Stellen von der Idee überzeugt sind und Usability aktiv fördern.

Zur Verteidigung der Amarok-Entwickler muss eingeräumt werden, dass der Usability-Spezialist im Vorfeld nicht mit dem Projekt über dessen Ziele und Zielgruppe gesprochen hat: Während der Report generelle Richtlinien berücksichtigte, hatten die Amarok-Entwickler damals eine besondere Vorstellung, wie sich ihre Software verhalten sollte. Eine klare Absprache über diese Ziele vor Beginn der Usability-Aktivität hätte Missverständnisse verhindert. Erfahrungen aus anderen Projekten stützen diese Annahme.

Kontinuierliches Engagement der Usability-Spezialisten

Punktuelle und generelle Reports sind die einfachste Methode, Usability-Feedback an ein Projekt zurückzumelden. Usability-Spezialisten können den Zeitaufwand für das Erstellen des Reports leicht einschätzen, mit etwas Extra-Zeit für die Diskussion ist der Beitrag für sie zügig erledigt. In der Praxis hat sich jedoch gezeigt, dass Entwickler unterschiedliche Prioritäten bei der Implementierung der Vorschläge setzen. Statt sie im Nutzungs-Kontext zu beurteilen, werden quick fixes in der Regel zuerst implementiert, selbst wenn im Report andere Prioritäten gesetzt sind. Bei Kontact, dem KDE Personal Information Manager, führte dies zu Inkonsistenzen in der Menüstruktur der Sub-Komponenten Mail, Adressbuch und Kalender, da Empfehlungen für einige Teile umgesetzt wurden, für andere nicht.

Insgesamt hat sich gezeigt, dass punktuelle Reports anhand genereller Usability-Heuristiken lediglich in einer Vielzahl an quick fixes resultieren. Die häufig notwendigen, umfangreicheren Änderungen am Interaktions-Design oder der Informationsarchitektur werden jedoch selten umgesetzt. Auch dies gilt in gleicher Weise für die proprietäre Software-Entwicklung. Punktuelle Reports ohne weitere Anstrengungen widersprechen der Idee eines nutzerorientierten Entwicklungsprozesses (vgl. Abschnitt 1).

Dennoch: Punktuelle Reports sind besser als kein Feedback und können als Einstiegspunkt für langfristige Usability-Arbeit dienen. Dass dies häufig nicht der Fall ist, lässt sich wiederum auf das Primat der Programmierer (Jung 2006) und die von Yeats (2006) beschriebenen Reaktionen auf nicht-technisches Feedback zurückführen: Beiträge von Usability-Mitwirkenden, die sich innerhalb der Community noch keinen Namen gemacht haben, werden häufig vorschnell mit einem won't fix abgetan. Nur hochmotivierte Usability-Spezialisten werden sich dann auf weitere Diskussionen einlassen.

Im KDE-Projekt wurde deshalb versucht, die Usability-Mitwirkenden durch Blogs und Interviews stärker in die Community einzubinden. Auf der einen Seite erhöhte dies die Bindung und damit das kontinuierliche Engagement der Usability-Berater, auf der anderen Seite wurde unter den Entwicklern das Vertrauen in Usability gestärkt. Die Usability-Experten waren keine Außenstehenden mehr, die ungefragt die eigene Software kritisieren, sondern wurden zu gleichwertigen Mitgliedern des Projektes.

Verantwortlichkeiten und Entscheidungswege

Mit steigendem Engagement im Projekt mussten die Usability-Berater in KDE bald feststellen, dass sie immer wieder die gleichen Probleme an unterschiedlichen Stellen des Projektes angingen. So wurden ähnliche Interaktions-Elemente benötigt, die jeweils in einem Unterprojekt neu implementiert wurden. (14) Auch erläuterten sie gegenüber einzelnen Programmierern stets die gleichen Usability-Grundsätze, was viel Zeit und Energie kostete.

Es zeigte sich, dass dem KDE-Desktop eine einheitliche Richtung fehlte. Die Usability-Spezialisten sahen sich einer neuen Herausforderung gegenübergestellt: Um Änderungen konsistent in KDE umsetzen zu können, wurden allgemeine guidelines sowie Änderungen an den Bibliotheken der Desktop-Umgebung notwendig.

Um dies zu erreichen, ist eine enge Zusammenarbeit mit den Entwicklern ausschlaggebend. An den Bibliotheken ist jedoch eine Vielzahl Entwickler beteiligt, klare Verantwortlichkeiten fehlen. Die Implementierung von Usability-Verbesserungen scheiterte somit oft daran, dass die Usability-Berater zunächst selbständig einen Entwickler finden mussten, der Zeit und Fähigkeiten besitzt, die Änderung umzusetzen. Mailinglisten stellten sich als ein wenig geeignetes Medium heraus, um Entwickler zu werben, da Requests oft ungehört im Archiv untergingen.

Um diesen Problemen zu begegnen, wurden Ende 2005 verschiedene Umstrukturierungen in der KDE-Community durchgesetzt.(15) Mit der Schaffung einer technischen Arbeitsgruppe (16) wurde das Problem der fehlenden Verantwortlichkeiten angegangen, so sollten klare Ansprechpartner für bestimmte technische Bereiche geschaffen werden. Für Anfang 2007 sind Job-Listen geplant, auf denen unter anderem Requests des Usability-Teams permanent ausgeschrieben sind. Human-interface guidelines (17) als allgemein verbindliche Richtlinien bei der Gestaltung von Anwendungen sind in der Entstehung.