Warum Open Source Usability braucht

Der Nutzer, das unbekannte Wesen

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

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.

LinuxCommunity kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

Kommentare

Infos zur Publikation

LU 04/2017: SPEZIAL-DISTRIBUTIONEN

Digitale Ausgabe: Preis € 5,95
(inkl. 19% MwSt.)

LinuxUser erscheint monatlich und kostet 5,95 Euro (mit DVD 8,50 Euro). Weitere Infos zum Heft finden Sie auf der Homepage.

Das Jahresabo kostet ab 86,70 Euro. Details dazu finden Sie im Computec-Shop. Im Probeabo erhalten Sie zudem drei Ausgaben zum reduzierten Preis.

Bei Google Play finden Sie digitale Ausgaben für Tablet & Smartphone.

HINWEIS ZU PAYPAL: Die Zahlung ist ohne eigenes Paypal-Konto ganz einfach per Kreditkarte oder Lastschrift möglich!

Aktuelle Fragen

WLAN lässt sich nicht einrichten
Werner Hahn, 21.03.2017 14:16, 0 Antworten
Dell Latitude E6510, Ubuntu 16.4, Kabelbox von Telecolumbus. Nach Anklicken des Doppelpfeiles (o...
"Mit Gwenview importieren" funktioniert seit openSuse 42.2 nicht mehr
Wimpy *, 20.03.2017 13:34, 2 Antworten
Bisher konnte ich von Digitalkamera oder SD-Karte oder USB-Stick Fotos mit Gwenview importieren....
Ich habe eine awk Aufgabe und bekomme es nicht so Recht hin
Dennis Hamacher, 10.03.2017 18:27, 1 Antworten
Ich hoffe Ihr könnt mir dabei helfen oder mir zeigen wie der Befehl richtig geschrieben wird. Ich...
Unter Linux Open Suse Leap 42.1 einen Windows Boot/ ISO USB Stick erstellen...
Tim Koetsier, 07.03.2017 15:26, 1 Antworten
Hallo, weiß jemand wie ich oben genanntes Vorhaben in die Tat umsetzen kann ? Wäre echt dankba...
Druckertreiber installieren OpenSuse42.1
Tim Koetsier, 07.03.2017 15:22, 1 Antworten
hallo, kann mir BITTE jemand helfen ich verzweifel so langsam. Habe einen Super Toner von Canon...