TFT Monitor bei Mercateo kaufen.

Neues Netbook? Ein Preisvergleich lohnt sich.

Bei uns finden sie Notebooks, PDAs und Drucker mit Testberichten und Tipps.

Diamant Buchhaltungssoftware – transparent und detailliert auch für die Konzernbuchhaltung.

Günstige Shareware Programme als direkte Downloads im Software Portal.

Bis zu 70% sparen durch Preisvergleich.

Erschienen in LinuxUser 03/2004 » Ausgabe bestellen

Warum Open Source Usability braucht

Der Nutzer, das unbekannte Wesen

von Jutta Horstmann und Jan Mühlig

Muss Linux benutzerfreundlich sein? Was ist das, Benutzerfreundlichkeit, und wer sind überhaupt die Nutzer? Fragen über Fragen, die beantwortet sein wollen, wenn Linux den Desktop erobern will.

Usability im LinuxUser

Am Thema "Usability", also: Benutzerfreundlichkeit, dürfte sich das Schicksal von Linux auf dem Desktop auf lange Sicht entscheiden. Grund genug, ihm von nun an eine monatliche Kolumne zu widmen, in der wir Open-Source-Projekte mit Blick auf ihre Benutzbarkeit diskutieren.

Ein altes Sprichwort sagt: "Unix is very user friendly, it's just picky about who its friends are." -- "Unix ist sehr benutzerfreundlich, nur etwas wählerisch, was seine Freunde betrifft." Bis vor kurzem galt dieser Satz auch für Linux und sonstige Open-Source-Software (OSS): Spezialisten schrieben Programme für Spezialisten, man wusste, für wen man programmierte, und dem Nutzer musste die Bedienung der Tools nicht erklärt werden. Hohe Anpassbarkeit (per Konfigurationsdatei oder Patch), Funktionsvielfalt sowie Zweckdienlichkeit waren die Qualitätsmerkmale einer Anwendung.

Patch: Ein Software-"Flicken", bei Open-Source-Software meist in Form einer Quellcode-Änderung, der, in ein Programm eingespielt, Fehler behebt oder neue Funktionen einbaut. Bei Quellcode-Patches muss das Programm anschließend neu kompiliert werden.

Und nun ist plötzlich alles ganz anders? Tatsächlich hat sich im letzten Jahr enorm viel geändert. In Deutschland mögen die Städtenamen München und Schwäbisch Hall für eine Entwicklung stehen, die gerade erst begonnen hat: die Migration zu Linux auf zehntausenden Arbeitsplatzrechnern, Open-Source-Programme auf den Desktops von Menschen, deren Interesse an ihrem Computer sich auf ein Minimum beschränkt. Auch auf internationaler Ebene halten Linux-Desktops Einzug -- gerade wenig industrialisierte Länder sehen darin eine Möglichkeit, breiten Bevölkerungsschichten Zugang zur Computer-Nutzung zu bieten.

Abb. 1: Erklärungen, die auf etwas verweisen, das es nicht gibt, fallen Entwicklern kaum auf. Für normale Nutzer sind sie schlicht irreführend (hier bei Gnome 2.2).

Nicht nur werden nun Programme nachgefragt, die vorher nicht im Zentrum des Entwicklerinteresses standen (Wer braucht ein Office-Paket, wenn er einen LaTeX-Editor hat?), auch zählen Menschen mit vollkommen anderen Erfahrungen, Erwartungen und Wissen als bisher zu ihren Benutzern.

LaTeX-Editor: Ein Programm, das das Erstellen von Dokumenten im LaTeX-Format unterstützt. TeX/LaTeX ist ein speziell im wissenschaftlichen Bereich verbreitetes, professionelles Textsatzsystem. Ähnlich wie bei HTML formatiert man seinen Text mit speziellen Auszeichnungen. Diesen wandelt das Programm latex in ein fertig layoutetes Dokument.

Die schiere Masse dieser neuen Linux-Nutzer auf der einen Seite und ihre extreme Unähnlichkeit zu den bisherigen Nutzern (und natürlich Entwicklern!) freier Software auf der anderen Seite bringt die Frage auf die Tagesordnung: "Muss Linux benutzerfreundlich sein?" Das heißt: Soll die Qualität einer Anwendung nicht mehr (nur) an der Qualität ihres Codes gemessen werden, sondern daran, wie einfach gerade unerfahrene Benutzer mit ihr zurecht kommen?

"Nein!", könnte eine Antwort auf diese Frage sein -- schließlich besorgen Freiwillige einen großen Teil der OSS-Entwicklung, und diese -- "They just don't like to do the boring stuff for the stupid people!" [5] -- haben keine Lust, sich langweilige Arbeit aufzuhalsen, nur weil Otto Normaluser zu faul oder "zu blöd" ist, sich in eine Software ordentlich einzuarbeiten.

Chancen und Herausforderungen

Eine ganze Reihe Open-Source-Projekte hat die Frage jedoch schon mit "Ja!" beantwortet. Sie wollen die Chancen nutzen, die die breitere Nutzerbasis der Community bietet: höherer Marktanteil der Open-Source-Software, Verbesserung der vorhandenen Applikationen durch mehr Feedback, Vergrößerung der Entwicklergemeinde, Gewinnen von Unterstützern in Wirtschaft und Politik.

Wie soll aber innerhalb von Projekten (gerade größeren wie KDE, Gnome, OpenOffice.org etc.) damit umgegangen werden, wenn sich nur ein Teil der Entwickler und Entwicklerinnen für diese Richtung begeistern? Inwieweit lassen sich mit den bisherigen Projektstrukturen Vorgaben z. B. hinsichtlich benutzerfreundlicher Oberflächen durchsetzen? Braucht die Community plötzlich Hierarchien? Müssen sich freiwillige Entwickler vorschreiben lassen, wie ihre Software auszusehen und zu funktionieren hat? Oder wird es Spaltungen geben

von Anwendungen: in Bedienelemente für Anfänger und Fortgeschrittene?
von Projekten: in die Entwicklung von Code mit direktem Nutzerkontakt und ohne?
innerhalb der Community: in Projekte für die Massen und solche für Spezialisten?

Unser Artikel kann diese Fragen nur aufwerfen, aber nicht beantworten. Im folgenden konzentrieren wir uns auf die Herausforderungen für jene Projekte, die die breite Masse erreichen wollen, indem sie die Anwendungen benutzerfreundlicher machen. Damit stellt sich die nächste Frage: "Benutzerfreundlichkeit -- was ist das?"

In Regeln gefasst

Benutzerfreundliche Software zeichnet sich dadurch aus, dass sie die Nutzerin zu ihrem Ziel führt, ohne dass diese sich über den Weg dorthin viele Gedanken machen muss. Um das zu erreichen, muss die Software sich an den folgenden "Usability-Regeln" orientieren:

Konsistenz: Es besteht ein für den Nutzer eindeutiger Zusammenhang zwischen Handlung und Wirkung, d. h., im gleichen Kontext passiert auch immer das gleiche. Beispiel: Die [Enter]-Taste erzeugt immer einen Zeilenumbruch, sie wird nicht (zusätzlich) zum Abschicken von Formulareingaben eingesetzt.
Feedback: Die Software reagiert auf die Aktionen des Nutzers in für diesen verständlicher, nachvollziehbarer und unterstützender Weise. Negativ-Beispiel: Erklärungen zu Aktionen, die an dieser Stelle gar nicht in Frage kommen wie in Abbildung 1 oder unverständliche Fehlermeldungen wie in Abbildung 3.
Trennschärfe: Begriffe stehen für klar abgegrenzte Funktionen. So führt es zu Verwirrung, wenn z. B. die Begriffe "Systemsteuerung" und "Einstellungen" nebeneinander verwendet werden. (Der Fachbegriff für diese klare Abgrenzung lautet Naming/Labeling.) Verwendete Metaphern stammen aus der Begriffswelt der Nutzer-Zielgruppe und sind aussagekräftig, zum Beispiel "Ordner" statt "Verzeichnis" (Fachbegriff: Wording). Problematisch hingegen sind Metaphern wie "Dateisystem oder Gerät einhängen". Was die Software dem Nutzer mitteilt, muss dessen Sprache und Denkstrukturen entsprechen. Zusätzliche Probleme entstehen bei der Übersetzung in andere Sprachen, wie Abbildung 2 zeigt.
Transparenz der Benutzerführung: Die Nutzerin versteht, welche Möglichkeiten die Software ihr bietet, und kann dadurch den Weg zu ihrem Ziel planen. Der kognitive Aufwand ist gering, d. h., die Benutzerin muss nicht bei jedem Schritt nachdenken. Welche Aktionen sie in welcher Reihenfolge ausführen muss, ergibt sich intuitiv oder wird von der Software gut angedeutet. Beispiel: Buttons, die zum Ziel führen, werden hervorgehoben im Vergleich zu denjenigen, die Abbruchmöglichkeiten bieten.
Schnell zum Ziel: Der Benutzer muss möglichst wenig Einzelaktionen durchführen, um zu seinem Ziel zu gelangen. So empfiehlt es sich zum Beispiel, häufig verwendete Optionen in der Menühierarchie möglichst weit oben anzuordnen. Das heißt aber auch, dass die Gliederung dem folgt, was der Nutzer (und nicht der Entwickler!) wichtig findet.
Fehlertoleranz und Reversibilität (Umkehrbarkeit): Die Software informiert den Benutzer bei Fehlern darüber, was er falsch gemacht hat und wie er stattdessen sein Ziel erreichen kann. Das Programm bricht nicht ab, sondern bietet die Möglichkeit, fehlerhafte Schritte rückgängig zu machen, und unterstützt dabei, den richtigen Weg zu finden. Beispiel: Jemand will einen Drucker benutzen, der noch nicht konfiguriert ist. Anstatt eine Fehlermeldung anzuzeigen, bietet das Programm an, den Drucker jetzt einzurichten.
Positive Nutzungserfahrung: Die Nutzung der Software bleibt für den Anwender frustrationsfrei, sie macht Spaß, und der Nutzer fühlt sich kompetent. Die Software wird so zu einem Werkzeug, um ein Ziel zu erreichen; das Ziel besteht nicht schon darin, die Software zu verstehen und zu bedienen. Das lässt sich mit der Lektüre eines Buchs vergleichen: Man muss nicht Buchstaben für Buchstaben entziffern und bei jedem Wort über dessen Bedeutung nachdenken, sondern "liest einfach" und erlebt die Geschichte.

Abb. 2: Nebenwirkungen einer Übersetzung: In der deutschen Version von Mozilla Firebird fehlt der Bezug zwischen "Chronik" und dem Kurzbefehl (H wie "History"). Hinzu kommt, dass nur ein Teil der Menüeinträge überhaupt übersetzt wurde.

Wer sind "die Nutzer"?

So international die Open-Source-Community auch ist -- von einigen wirklich großen Projekten wie dem Webserver Apache abgesehen, kannten die Entwickler bisher ihre Nutzer. Wenn nicht persönlich, dann aus Mailinglisten, aus dem IRC, von Bug-Reports etc. Es gab eine Kommunikation zwischen Gleichgesinnten.

IRC: "Internet Relay Chat". Ein Internet-Dienst, der es seinen Nutzern erlaubt, quasi in Echtzeit schriftlich miteinander zu kommunizieren (zu "chatten"). Für viele Projekte gibt es dedizierte "Chat-Räume", Kanäle genannt, in denen u. a. Probleme mit der jeweiligen Software diskutiert werden.
Bug-Report: An die Entwickler einer Software gerichtete Fehlerbeschreibung.

Wenn nun große Verwaltungsapparate nicht nur in Deutschland, sondern weltweit ihre Mitarbeiter an Open-Source-Software setzen -- und immer mehr Nutzer Linux auf dem heimischen PC ausprobieren -- steht der Entwickler plötzlich einer Masse von Nutzern gegenüber, die er weder kennt noch versteht, und die keine der genannten Kommunikationswege nutzt.

Abb. 3: Fehlermeldungen sollten verständlich darüber informieren, was schief gelaufen ist (Hier eine Gnome-2.2-Fehlermeldung auf SuSE Linux Desktop 1.0 beim Versuch, YaST2 zu starten).

Benutzerfreundliche Software kann aber nur produzieren, wer sich klar macht: Der Nutzer einer Software ist grundverschieden von ihrem Entwickler.

Die meisten Entwickler realisieren Funktionen, Interaktionsabläufe und Oberflächen so, dass die Software die eigene Begriffs- und Denkwelt widerspiegelt. Sie kennen ihre Software in- und auswendig, wissen Bescheid über ihre Funktionen und Grenzen, müssen nicht erst nachdenken, welche Schritte sie tun müssen.

Woher weiß aber die Entwicklerin, was unterschiedliche Nutzer mit welchen Begriffen assoziieren? Wie kommt sie an die notwendigen Informationen über "die Nutzer"?

Die Feedback-Schwelle niedrig halten

Setzt man auf der Seite des Anwenders an, so liegt es nahe, zunächst auf die bestehenden Kommunikationswege zurückzugreifen. Das heißt z. B., Mailinglisten einzurichten, die Usability-Probleme diskutieren -- und zwar in einem moderierten Rahmen, so dass die Anliegen der Nutzer verstanden und in technische Aufgabenstellungen für die Entwickler umformuliert werden können. Oder: In Form eines Web-Angebots oder als Teil der Applikation eine Möglichkeit für die Benutzerinnen und Benutzer zu schaffen, den Softwareentwicklern in standardisierter Form von Problemen zu berichten, die sie mit der Anwendung hatten (Usability Bug Reporting).

Das Ziel wäre also, die große Masse der neuen Nutzer zu einem Teil der Community zu machen, sie durch niedrigschwellige Angebote einzubinden und die Möglichkeit der Kommunikation mit den Softwareentwicklern zu einem Teil einer positiven Nutzungserfahrung werden zu lassen. Wesentlich ist hier, dass die Angebote möglichst einfach verständlich und bedienbar sind -- und andererseits der Nutzer-Input in für die Entwickler und Entwicklerinnen verwertbare Informationen umgewandelt werden kann.

Denn in der Praxis sind die Feedback-Kanäle immer noch stark auf Entwickler und technisch versierte Nutzer und Nutzerinnen beschränkt (Abbildung 4). Wer schon einmal einen Bugzilla-Report ausgefüllt hat, in der Datenbank versuchte, "seinen" Bug zu finden und schließlich das daraus resultierende Mail-Feedback zu verstehen, wird zustimmen, dass die Hürden doch eher hoch sind und viele ausschließen.

Wenn allerdings jeder Nutzer seine persönlichen Probleme mit der Software an den oder die Entwickler schickte, dann wäre zum einen keine Zeit mehr zum Programmieren, zum anderen müssten die Entwickler ihrerseits verstehen, was der Nutzer genau meint. Je größer und heterogener die Nutzergruppen werden, desto schwieriger und zeitaufwändiger wird es für Entwickler, die Übersicht über die oft widersprüchlichen Anforderungen zu behalten und das Softwareprojekt für möglichst viele Betroffene akzeptabel zu konzipieren.

Hier kommen Usability-Experten ins Spiel, deren Aufgabe darin besteht, als Mittler zu fungieren zwischen Anwendern und Entwicklern. Sie sind nicht in die Programmierung eingebunden und damit nicht "betriebsblind" gegenüber Usability-Problemen der Anwendung. Sie können aufgrund ihrer Erfahrung nicht nur Nutzergruppen dazu bringen, verwertbare Informationen über die Benutzbarkeit der Software zu formulieren, sondern diese Informationen auch soweit abstrahieren, zusammenfassen und bewerten, dass konkrete Handlungsempfehlungen für die Projektentwickler entstehen. Dies kann durch Moderation von Mailinglisten, durch die Teilnahme am Usability-Bug-Reporting-Prozess, durch Usability-Tests oder direkte Beratung und durch Unterstützung einzelner Projekte geschehen.

Bei der kommerziellen Softwareentwicklung spielt Usability-Expertise bereits eine große Rolle, da sich diese schon viel früher mit dem Problem einer großen, heterogenen Nutzerschicht auseinandersetzen musste. Usability-Experten (oder ganze Usability-Abteilungen) übernehmen dort die Aufgabe, Probleme in der Benutzbarkeit systematisch zu erkennen (in der Regel durch sogenannte Usability-Tests), zu filtern und für die Entwickler als klare, umsetzbare Empfehlungen aufzubereiten.

Abb. 4: Hohe Eingangshürden: Die Eingabemaske für Issuezilla (hier bei OpenOffice.org) ist für "normale Nutzer" kaum verständlich.

Im kommerziellen Bereich lässt sich auch die Frage, wie man an diese Experten kommt, ganz einfach beantworten: Man bezahlt sie. Aber wie sollen Open-Source-Projekte dies regeln? Einerseits geht es natürlich auch auf kommerzielle Weise: Namhafte Firmen, die sich im Open-Source-Umfeld engagieren, stellen ihre Usability Labs zur Verfügung; der "Gnome Usability Report" der SUN Human Computer Interaction Group ist hier nur ein Beispiel.

Aber ließen sich die Experten nicht direkt in die Community einbinden, im Sinne einer echten "Open Usability"? Sobald sich Firmen, universitäre Gruppen und Einzelpersonen durch Förderung der Benutzerfreundlichkeit von OSS einen guten Namen und Reputation erwerben können, werden zumindest einige ihre Expertise der Community zur Verfügung stellen -- wie die Softwareentwickler freiwillig und umsonst: "Just for fun". Da dieses Prinzip schon dabei geholfen hat, besseren Code zu produzieren, könnte dieselbe Logik auch im Bereich der Usability gelten -- erste Ansätze [2,3] gibt es bereits.

Kann offene Software benutzerfreundlicher sein als geschlossene?

Noch hinkt OSS -- vor allem in der Öffentlichkeitswahrnehmung -- proprietärer Software hinterher, was die Benutzerfreundlichkeit anbelangt. Sollen Tools leicht zu erlernen und zu verwenden sein, wird oft einfach die Oberfläche des Closed-Source-Äquivalents nachgebildet.

Dabei verfügt offene Software über eine Reihe von Vorteilen, die ihr auf längere Sicht auch die Gunst breiter Nutzerschichten sichern könnte:

vorhandene Kommunikationskanäle zwischen Entwicklern und Nutzern,
schnelles Entwickler-Feedback und kurze Entwicklungszyklen,
hohe Motivation der Beteiligten (ob Entwickler oder Usability-Experten), denn ihr Beitrag ist freiwillig,
Anwendungen lassen sich dank hoher Konfigurierbarkeit sowie aufgrund von hochwertigem (modularem, flexiblem) Code an ganz unterschiedliche Nutzergruppen, Kulturen, Schriften usw. anpassen.

Inwieweit Open-Source-Projekte diese Chancen nutzen, um ihre Anwendung benutzerfreundlich zu gestalten, werden wir hier in den nächsten Monaten anhand von Beispielen diskutieren. (pju)

Infos

[1] Linux-Usability-Studie: http://www.relevantive.de/Linux.html
[2] KDE-Usability-Projekt: http://usability.kde.org/
[3] Gnome-Usability-Projekt: http://developer.gnome.org/projects/gup/
[4] "The Usability of Open Source Software": http://www.firstmonday.dk/issues/issue8_1/nichols/
[5] Bruce Sterling: "A Contrarian View of Open Source", http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html?page=1

Die Autoren

Jutta Horstmann ist Informatikerin und arbeitet als selbständige IT-Beraterin im Bereich Entwicklung und Projektmanagement. Jan Mühlig ist Vorstand der relevantive AG, die sich auf Usability im Software- und Web-Bereich spezialisiert hat. Gemeinsam haben sie u. a. die "Linux-Usability-Studie" [1] entwickelt und durchgeführt.

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.