Der Nutzer, das unbekannte Wesen

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.

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.

Abbildung 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.

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.

Abbildung 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.