- Die komplexen Benutzeroberflächen (UI) freier Software stellen für normale Nutzer eine Einstiegshürde dar
- Selbst einfache Aufgaben wie Videokonvertierung führen dazu, dass normale Nutzer wegen der auf Experten ausgerichteten UI von Tools wie Handbrake aufgeben
- Um dieses Problem zu lösen, entwickelte der Autor mit Magicbrake ein einfaches Frontend mit einer einzigen Schaltfläche, das nur die Funktion „seltsame Videodateien in normale MP4s umwandeln“ bietet
- Wenn komplexe Funktionen verborgen und nur die 20 % der Funktionen sichtbar gemacht werden, die die meisten Nutzer tatsächlich brauchen, steigen Produktivität und Zufriedenheit
- Das Ökosystem freier Software muss ein nutzerfreundliches Design für normale Anwender übernehmen, damit sich der Einsatzbereich der Werkzeuge erweitern kann
Die Kluft zwischen freier Software und normalen Nutzern
- Normale Nutzer haben selbst bei grundlegenden Aufgaben wie Videokonvertierung, Upload und Wiedergabe Schwierigkeiten wegen Formatproblemen
- Formate, die in QuickTime oder auf Facebook nicht abgespielt werden, gelten schlicht als „seltsam“
- Handbrake ist leistungsfähig, verursacht bei normalen Nutzern wegen seiner auf Fachnutzer ausgerichteten UI aber Unbehagen und Verwirrung
- Dieses Problem ist im gesamten FOSS-Ökosystem (Free and Open Source Software) verbreitet; infolgedessen geben normale Nutzer auf oder bitten Experten um Hilfe
Das Beispiel Magicbrake
- Magicbrake verbirgt die komplexen Funktionen von Handbrake und erfüllt nur eine einzige Aufgabe: „seltsame Videos in normale MP4s umwandeln“
- Das Ergebnis der Umwandlung ist eine kleine MP4-Datei, die in den meisten Umgebungen funktioniert
- Die Oberfläche besitzt nur eine einzige Schaltfläche
- Dieser Ansatz ist eine schnelle und einfache Lösung und eignet sich für Nutzer, die keine komplexen Funktionen benötigen
Einwände gegen Vereinfachung und Antworten darauf
- Manche fragen: „Warum wurde Handbrake weniger leistungsfähig gemacht?“, „Was, wenn ich ein anderes Format brauche?“, „Was ist mit Spezialfunktionen?“
- Die Antwort darauf ist klar: Wer erweiterte Funktionen braucht, kann Handbrake weiterhin direkt verwenden, alle anderen nutzen einfach das vereinfachte Tool
- Das ähnelt dem Abkleben unnötiger Tasten auf einer TV-Fernbedienung: Bei Bedarf sind die Funktionen weiterhin vorhanden, stören aber nicht bei der normalen Nutzung
Der Wert einer einfachen UI
- Es gibt viele Medienserver, die für normale Menschen schwer einzurichten sind, Audio-Editoren, bei denen selbst Grundaufgaben Lernaufwand erfordern, und Netzwerk-Monitoring-Tools, die Einsteiger ausschließen
- Diese Werkzeuge sind funktional hervorragend, bleiben für normale Nutzer aber unzugänglich, weil ihr Design alle Funktionen in einer einzigen UI unterbringen will
- 80 % der Nutzer brauchen nur 20 % der Funktionen; wenn der Rest verborgen wird, entsteht eine produktivere und zufriedenstellendere Erfahrung
Ein Vorschlag an Entwickler
- Eine einfache Oberfläche für normale Nutzer zu entwerfen ist etwas, das sich an einem Abend umsetzen lässt und echten praktischen Wert hat
- Statt alle komplexen Funktionen offenzulegen, erhöht eine Designphilosophie, die nur die nötigen Funktionen sichtbar macht, die Zugänglichkeit freier Software
- Der Autor empfiehlt Entwicklern, mehr solcher vereinfachten Werkzeuge zu bauen
9 Kommentare
Man kann das als Komplexität von UI/UX bezeichnen,
aber ich denke, das Problem ist, dass die heute entwickelte Software – ob frei oder proprietär – meist nur für genau den einen vorgesehenen Fall gut funktioniert und sich kaum darum kümmert, was bei allen anderen Nutzungserfahrungen passiert.
Wenn man zum Beispiel
toml- oderyaml-Konfigurationen bearbeitet, gibt es Fälle, in denen etwas eigentlich funktionieren müsste, es aber nicht tut. Oft ist nicht sauber dokumentiert, ob das an der Kodierung liegt, an der Einrückung oder daran, dass eine Funktion bei gesetztem bestimmten Flag nicht verwendet werden kann. Nutzer probieren dann unzählige Fälle einzeln durch und finden die richtige Lösung oft erst mit Mühe.Bei der UI ist es noch gravierender. Wie die Erfahrung beim Zurücksetzen von Passwörtern zeigt, die sich schon als Meme verbreitet hat: Wenn auf dem Bildschirm 100 Felder stehen, kann man die Zusammenhänge zwischen ihnen und die optimale Art der Änderung oft „nur durch Ausprobieren“ herausfinden.
Das ist einerseits ein UI/UX-Problem, andererseits aber auch ein Problem versteckter „Expertise“. Ohne eine vorbereitete, stufenweise Lernkurve wird ein Problem, das jemand mit Fachwissen sofort richtig ausfüllen kann, für Anfänger zu einer Prüfung oder Hürde, bei der sie immer wieder Ablehnung erfahren.
In einem ähnlichen Zusammenhang scheint eine GUI bequemer zu sein als eine CLI; ich nutze auch bei
yt-dlpmityt-dlgdie GUI.ffmpegverwende ich ebenfalls, indem ich mir häufig genutzte Befehle notiere; dafür könnte man wohl auch eine GUI erstellen.Wie zu erwarten: die UI/UX!!
Ich persönlich habe mir schon oft ähnliche Gedanken gemacht, deshalb kann ich dem ziemlich gut nachempfinden. Als ich unter Linux versucht habe, Anwendungen zu finden, die so sind wie Paint, Editor oder Media Player aus der WinXP~7-Ära — also Programme, die man „einfach mal schnell öffnet und irgendwie benutzt“ —, war ich schon froh, wenn ich erst nach der Installation von fünf oder sechs Stück etwas gefunden habe, das mir gefiel.
Für einen Screenshot muss man ihn eigentlich nur aufnehmen und zuschneiden, dafür kann man schlecht Gimp verwenden. Ich erinnere mich nicht mehr, was ich alles ausprobiert habe, aber unter den GTK-Apps habe ich nichts Passendes gefunden und bin am Ende bei Kolourpaint gelandet. Beim Editor gibt es Gedit, Kate, Mousepad, Leafpad, Xed und so weiter, und wenn man noch etwas Leichteres sucht, landet man gleich bei Sachen wie xedit, nano oder vim, die praktisch aufgegeben haben, benutzerfreundlich zu sein. Und bei Media-Playern wird mir schon ganz eng, wenn ich nur an mpv, VLC oder mplayer denke.
Solche Beiträge wirken etwas fragwürdig, wenn sie ohne irgendwelche Statistiken einfach behaupten, richtig zu sein.
Nutzer interessieren sich nur für 20 % einer Anwendung
Irgendwie scheint das auch mit dem obigen Artikel zusammenzuhängen.
„Die meisten Nutzer verwenden von den Funktionen einer Anwendung nur etwa 20 %, die sie tatsächlich brauchen, und diese 20 % sind bei jedem Nutzer anders.“
Ist das nicht der Kern der Sache?
Sobald man irgendetwas fragt, kommt als Antwort nur: „Lies zuerst
man/README/Docs.“Tatsächlich ist bei UX wichtig, dass man etwas einfach benutzen kann und sofort versteht, wie es funktioniert.
Da niemand dafür bezahlt wird, sieht man darüber hinweg, aber aus der Sicht von Nicht-Entwickler:innen stimmt es schon, dass die User Experience nicht besonders gut ist.
Hacker-News-Kommentare
Guter Artikel, aber ich denke, die Argumentation ist fehlerhaft.
Eine einzelne schlanke Schnittstelle zu schaffen, ist keineswegs einfach.
Eine UI für einen bestimmten Anwendungsfall umzusetzen, ist nicht so schwer, aber den „genauen Anwendungsfall“ zu definieren und dann Anforderungen wie „Könnt ihr nicht nur noch das hier hinzufügen?“ abzuwehren, ist der wirklich schwierige Teil.
Diese Einfachheit ist wünschenswert, aber ein instabiler Zustand.
Die Komplexität von Code ist sichtbar, die Komplexität einer UI dagegen nicht.
Buttons und Eingabefelder wirken simpel, aber Probleme in dieser Sprache zu lösen, ist sehr komplex.
Scheitern ist eindeutig, aber Erfolg ist vage und für jeden Nutzer anders.
Gute Interfaces vermitteln vieles implizit, und genau das ist der schwierigste Teil.
Auch wenn der Button mit seiner eigentlichen Funktion Y fast nichts zu tun hat, bestehen sie darauf, dass er genau das tun soll.
Solche „Bitte nur ein bisschen ändern“-Wünsche stapeln sich, die UI wird immer komplexer und bricht am Ende zusammen.
Sie wollen ihre eigene Bequemlichkeit nicht zugunsten der Nutzbarkeit für die 80 % der normalen Anwender opfern.
Der Funktionsumfang wird im Voraus festgelegt, danach konzentriert man sich auf Bugfixes und Effizienzverbesserungen.
Neue Funktionen dürfen nur nach strenger Prüfung hinzugefügt werden.
Für schnelllebige Software ist das schwierig, aber in den meisten stabilen Bereichen dürfte es wirksam sein.
Langfristig könnten Apps selbst AI integrieren und sich in Richtung automatisch erzeugter UI weiterentwickeln, die dem Wunsch des Nutzers entspricht.
Ich denke, dieses Problem läuft letztlich auf Vertrautheit hinaus.
Meine Frau ist nicht technikaffin, aber Linux-Nutzerin.
Als sie ein neues Geschäft begann und Windows verwenden musste, fand sie es so unpraktisch, dass sie wieder zu Linux zurückwollte.
Ich hatte mit Mac vs. PC eine ähnliche Erfahrung.
Als ich gezwungen war, einen Mac zu benutzen, fiel meine Produktivität auf etwa 10 %, und es war furchtbar.
Letztlich arbeitet jeder Mensch am besten in einer Umgebung, die ihm vertraut ist.
Am Ende war es einfach „ein Computer“.
Zum Glück funktionieren VPN und die nötigen Apps alle mit Linux + Web-Interface.
Es braucht eine stabile Distribution, die fast dieselbe UI wie kommerzielle Betriebssysteme bietet und bei der man kein Terminal öffnen muss.
Nicht „ungefähr ähnlich“, sondern Detailgenauigkeit ist entscheidend.
Open-Source-UIs wirken anfangs fremd und komplex.
Sie werden entwicklerzentriert gebaut, sodass das Prinzip „Überrasche den normalen Nutzer nicht“ nicht eingehalten wird.
Aber wenn man sie konsequent nutzt, gewöhnt man sich an eine neue Philosophie und kann sie erfolgreich verwenden.
Ich selbst nutze Firefox, LibreOffice, Avidemux und Virt-manager problemlos.
Das Problem ist der Mangel an Designpersonal.
An FOSS beteiligen sich meist Entwickler mit etwas freier Zeit, aber relativ wenige Künstler oder Designer.
Deshalb wird oft nur ein grundlegendes UI-Niveau erreicht.
Die UX-Probleme des kostenlosen Audioeditors Audacity sind den Designern bereits bewusst.
Sie haben ein UX-Redesign-Video veröffentlicht, das die Probleme mit „Modes“ und „Audacity says no“ angehen soll.
Es soll künftig besser werden; gute UX ist in Open Source weiterhin knapp, aber es bewegt sich etwas.
Anfangs ist eine App für den Eigenbedarf gebaut, später sagen Leute: „Die Funktionen sind gut, aber die UX ist schlecht.“
Verbessert man dann die UX, heißt es umgekehrt: „Es fehlen Funktionen.“
Am Ende versucht man, alle zufriedenzustellen, und landet in einer endlosen Redesign-Hölle.
Viele Projekte brechen sogar zusammen, während sie Dinge wie eine Theme-Engine bauen.
Wenn sie unter einem anderen Namen neu veröffentlicht worden wäre, hätte sich wohl niemand beschwert.
Ich denke, die Lösung dieses Problems liegt in Standardisierung auf OS-Ebene.
Das OS sollte UI und Workflow konsistent bereitstellen.
Statt „Handbrake“ gäbe es zum Beispiel eine Standard-App namens „Video Converter“,
die Anweisungen wie „Konvertiere es so, dass es auf Facebook abgespielt werden kann“ versteht und automatisch die passenden Einstellungen anwendet.
App-Marken sollten minimiert werden, und der Nutzer sollte Themes und Schriftarten vollständig kontrollieren können.
Außerdem braucht es eine standardisierte Shell-Sprache, die mit GUI-Funktionen verknüpft ist.
Menschen wollen letztlich Funktionalität.
Selbst eine komplexe UI wird akzeptiert, wenn man nach dem Lernen damit das Gewünschte erreichen kann.
Software mit nur einfachen Optionen hat einen kleinen Markt.
Nutzer, die Videoformate nicht verstehen, suchen am Ende auf Websites nach „convert x to y“ und lösen es so.
Sobald man ein spezialisiertes Tool nutzt, bewegt man sich ohnehin schon im Bereich der fortgeschrittenen Nutzer.
Eine einfache UI nach dem Muster „Datei hier ablegen und auf Fix It klicken“ ist ebenfalls möglich.
Ich denke, genau das war der Kern des ursprünglichen Artikels.
Es gibt mehrere Gründe, warum Open Source komplex ist.
Aber die meisten FOSS-Projekte setzen eine gewisse technische Grundbildung voraus.
Komplexe Software zu lernen, ist langfristig oft sogar effizienter.
Open-Source-Entwickler können das innerhalb ihrer begrenzten Zeit nur schwer priorisieren.
Es gibt den Witz: Wenn dir Handbrake schon schwerfällt, dann zeig dir lieber gar nicht erst ffmpeg.
Auch ich fand Handbrake bei der ersten Nutzung deutlich einfacher als ffmpeg.
GUI-Tools dagegen muss man eher über Videos lernen.
Mit
ffmpeg -i input.avi output.mp4ist alles in einer Zeile erledigt.Handbrake zeigt alle Optionen an, während man bei ffmpeg nur eingibt, was man braucht.
Wenn man sich daran gewöhnt hat, ist eine sehr präzise Steuerung möglich.
Die Einfachheit von „nur Eingabe und Ausgabe angeben, fertig“ ist gerade der Reiz.
Sie ist nicht perfekt, aber gefühlt besser als ich selbst.
Deshalb wirkt es als Beispiel im ursprünglichen Artikel etwas seltsam.
Leute wie ich bevorzugen komplexe Interfaces.
Ich möchte, dass man davon ausgeht, dass ich intelligent bin.
Je öfter ich ein Tool benutze, desto lieber ist mir, dass ich damit auch bei höherer Komplexität schnell arbeiten kann.
Das Problem ist, dass jeder andere 20-%-Funktionen will.
Gute UI/UX braucht enge Feedback-Schleifen zwischen Testern, Designern, Entwicklern und Nutzern.
Dafür fehlen FOSS die Ressourcen.
Aber der durchschnittliche FOSS-Nutzer ist ein Top-1-%-Power-User und versteht das nicht.
Deshalb stößt eine Umstellung auf normale Nutzer schnell auf Widerstand in der Community.
Entwickler bauen es für ihre eigenen Bedürfnisse, daher ist Nutzerzufriedenheit möglicherweise gar nicht das Ziel.
Das ist kein Scheitern, sondern einfach ein anderer Zweck.
Erweiterte Funktionen nutzen nur wenige.
Deshalb ist eine Aufteilung in Standard-UI + erweiterten Modus realistisch.
Es testen nur Nutzer, die an diese UI bereits gewöhnt sind, deshalb gibt es viele Stimmen nach dem Motto „Lasst es unverändert“.
Große Unternehmen können dagegen bezahlte Nutzertests mit neuen Anwendern durchführen.
Deshalb verbessern sie UX oft schneller.
Wenn man UI/UX-Experten um Beiträge bittet, fühlen diese sich meist nicht verstanden.