Freie Software ist nichts für den wenig erfahrenen Endanwender? Der Beitrag untersucht die Ursachen schlechter Ergonomie und zeigt die Chancen für Open-Source-Software.

Im Schlepptau von Open Office, Firefox & Co. gerät Open-Source-Software (OSS) immer mehr auf die Computer ganz normaler Anwender. Einfache Benutzbarkeit gilt jedoch nicht gerade als Stärke freier Software. Den Ausbruch aus der Nische wird der OSS-Desktop nur schaffen, wenn es ihm gelingt, die Sympathie der in mehrfacher Hinsicht verständnislosen Anwender zu gewinnen.

Entwickeln im Elfenbeinturm

Benutzfreundlichkeit von Software lässt sich wissenschaftlich schwer beschreiben. Dennoch bestreitet kaum jemand, dass freie Software in diesem Bereich Defizite aufweist. Eine verbreitete Argumentation schiebt die Schuld dafür auf ihren Entwicklungsprozess. Der Usability-Experte Jakob Nielsen[1] etwa sieht den Grund in der Einstellung der Open-Source-Entwickler: Sie schrieben Software entweder, weil sie sie selbst benötigen, oder um die Anerkennung anderer Programmierer zu gewinnen[2].

Dieses Argument lässt sich schwer entkräften, auch wenn es alle OSS-Projekte über einen Kamm schert. Tatsächlich entstehen viele Projekte, weil Programmierer eine bestimmte Anwendung vermissen und deshalb selbst Hand anlegen. Dabei dominiert häufig die Einstellung, dass unzufriedene Anwender gewünschte Features selbst programmieren sollten. Doch normale Computernutzer verfügen selten über die dazu nötigen Fachkenntnisse.

Entscheidungen

Hier zeigt sich eine wichtige Konfliktlinie: Programmiert man für sich selbst oder für die Endanwender? Diese Entscheidung wirkt sich auf die Funktionen aus. Open-Source-Software bietet diesbezüglich sehr viel, im Idealfall deckt sie alle Bedürfnisse von Entwicklern ab. Was ihnen fehlt, steuern sie selbst bei. Den Nur-Anwender überfordert aber oft gerade die Vielfalt. Beispielsweise gibt es im Mailprogramm KMail die Möglichkeit, einen Ordner einer Mailingliste zuzuordnen. Eine praktische Funktion, jedoch nur für Power User interessant. Trotzdem steht sie im Einstellungsdialog auf einer Ebene mit der Namensvergabe und der restlichen Basiskonfiguration des Ordners.

Laien verwirrt die Feature-Flut, weil sie nicht erkennen, welche Funktionen sie wirklich benötigen und welche nur sehr speziellen Vorgängen gelten. Andererseits möchten versierte Nutzer, darunter meist die Entwickler selbst, auf die Spezialfunktionen nicht verzichten. Erstrebenswert ist wie so oft ein Kompromiss. Wie der aussehen soll, ist die Frage.

Triviale Aufgabe?

Den nötigen Willen vorausgesetzt: Wie erreicht ein Projekt das Ziel einfach bedienbarer und zugleich funktionstüchtiger Software? Unter[3] beschreibt Eric S. Raymond das Problem am Beispiel des Drucksystems Cups: Er bemängelt, selbst er als Programmierer könne mit Cups nicht ohne weiteres seinen Netzwerkdrucker einrichten. Die Entwickler sollten aber die technisch ahnungslose Tante Tillie als Nutzerin vor Augen haben und die Software nach deren Ansprüchen entwerfen, um so den Desktop zu erobern.

Als Problem anerkennen

Raymonds Argument zeigt, dass die Problematik häufig unterschätzt wird, denn die Realität ist nicht so einfach. Woher weiß ein Entwickler, was Tante Tillie wirklich braucht? Gewöhnlich hat er weder die Gelegenheit, sie danach zu fragen, noch sie beim Benutzen seiner Software zu beobachten. Hinzu kommt, dass nicht alle Laien die gleichen Ansprüche haben und fehlende Features nicht immer benennen können. Es bringt niemanden der Lösung des Usability-Problems näher, die Endbenutzer als einheitliche Masse von “dümmsten anzunehmenden Usern” zu pauschalieren, wie der Mac-Experte und Webdesigner John Gruber in einer Antwort auf Raymonds Essay ausführt[4].

Um ein Interface zu entwickeln, das unter Usability-Gesichtspunkten die Anforderungen der Benutzer erfüllt, planen Entwickler idealerweise diesen Aspekt von Anfang an ein. Dann lassen sie während des Entwicklungsprozesses Prototypen der Software immer wieder von realen Nutzern testen und passen das Programm deren Bedürfnissen an. Dieses aufwändige Verfahren ist teuer und auch kommerzielle Softwarehersteller investieren in diesen Bereich selten genug Zeit und Geld.

Abbildung 1: Das Messenger-Programm Gaim bietet keine intuitive Möglichkeit, sich nach einem Verbindungsabbruch bei einem Konto wieder anzumelden. Stattdessen muss der Nutzer unter »Konten« das Kästchen »Online« erst abwählen und anschließend wieder aktivieren.

Künstlerische Freiheit

Gewöhnlich unterliegt Open-Source-Software jedoch keinem wirtschaftlichem Druck. Freiwilligen Entwicklern steht es frei, ob sie Programme nach Usability-Maßstäben gestalten oder nicht. Sie haben keine ernsthaften Nachteile, wenn ihnen die Anwender abspringen. Entscheiden sie sich dafür, fehlen allerdings die finanzielle Ressourcen für Usability-Tests, abgesehen von einigen von Firmen finanzierten Projekten.

Abbildung 2: Die Schnittstellen zwischen Anwendern und Entwicklern sollten leicht zu verstehen sein. Wie hier im Webinterface von Bugzilla schrecken sie jedoch häufig durch umständliche Anweisungen ab.

Basar der Usability

Ein möglicher Ausweg wäre die Übertragung des von Raymond[5] als Basar beschriebenen Open-Source-Entwicklungskonzepts auf den Usability-Bereich. Doch Usability lässt sich nicht so objektiv bewerten wie Programmcode. Einen von einem User bemängelten Softwarefehler kann der Maintainer üblicherweise nachvollziehen und beheben. Auch Verbesserungsvorschläge, die sich auf die Qualität des Code beziehen, lassen sich meist eindeutig als gut oder schlecht einstufen.

Das sieht bei Usability-Beiträgen anders aus. Schlägt ein Benutzer eine Umgestaltung des User Interface vor, spiegelt dies zunächst nur dessen individuellen Geschmack wieder. Ob sich die vorgeschlagene Änderung bei der Mehrheit der Anwender tatsächlich positiv auswirkt, lässt sich aufgrund der einzelnen Meinung nicht beurteilen.

Subjektive Wahrnehmung

Auch in der Programmierung gibt es unterschiedliche Auffassungen, was die Qualität von Code betrifft. Trotzdem gibt es hier messbare Daten, etwa die Auswirkung auf die Performance oder die Fehleranfälligkeit, die Diskussionen oft überflüssig machen. Im Fall von Usability bieten nur möglichst umfangreiche Tests mit Anwendern ernst zu nehmende Grundlagen für die Bewertung. Zwar gibt es Richtlinien (siehe Kasten “Grundsätze der Dialoggestaltung”), sie fallen jedoch entweder recht abstrakt aus oder basieren auf Erfahrungen aus früheren Tests.

Die Beobachtungen anhand einer bestimmten Software lassen sich auch nur bedingt auf andere Programme übertragen. Diskussionen über die Usability-Qualitäten von Programmen in Foren und Mailinglisten geben gegenwärtig leider meist persönliche Meinungen und daraus resultierende Projektionen wieder.

Auch die Verständigung zwischen Programmierern und Anwendern gestaltet sich im Bereich Usability schwierig. Die bestehenden Kommunikationsformen richten sich an technisch versierte Anwender, die das Einsenden eines Bugreports nicht vor Schwierigkeiten stellt (siehe Abbildung 2). Doch gerade ein Benutzer, der schon beim Einreichen seines Verbesserungsvorschlags vor einer Hürde steht, personalisiert möglicherweise einen idealen Testanwender. Aber damit er sich beim Programmierer meldet, braucht er ein User Interface, das ihm dies ermöglicht und möglichst einfach macht.

Chancen nutzen

Dennoch bietet das bei Open-Source-Software gebräuchliche Prinzip “Früh und häufig veröffentlichen!” Chancen beim Usability-Engineering. Es schafft die Möglichkeit, im laufenden Entwicklungsprozess oft zu testen und bei Bedarf das User Interface frühzeitig in eine andere Richtung zu lenken. Einer Testgruppe dafür Prototypen bereitzustellen kostet kommerzielle Softwarehersteller Zeit und damit Geld, OSS veröffentlicht gewöhnlich ohnehin regelmäßig Zwischenversionen. Hier wirkt sich der fehlende ökonomische Druck positiv aus, es fehlt nur die Testgruppe.

Es gibt also Möglichkeiten, die Usability freier Software zu verbessern. Es kommt darauf an, sie auch zu nutzen. Nach der KDE-Entwicklerkonferenz im tschechischen Novre Hrady 2003 entstand auf Initiative der Firma des Autors das Projekt Open Usability[6] mit dem Ziel, Programmierer und Usability-Experten zu vernetzen. Es bleibt abzuwarten, ob sich ausreichend viele Fachleute finden, die die inzwischen bestehenden Schnittstellen zu Programmierern nutzen und die Open-Source-Entwicklung freiwillig unterstützen. Das Feedback auf der Open-Usability-Seite immerhin stimmt optimistisch.

Grund zur Hoffnung

Eine weitere Hoffnung für die Zukunft liegt in der zunehmenden Anerkennung der Bedeutung von Usability bei Firmen und Bildungseinrichtungen. Das führt dazu, dass die Zahl entsprechender Lehrveranstaltungen steigt – und aus dem akademischen Umfeld stammt seit langem der größte Teil der Open-Source-Entwickler. (csc)n