Das Phänomen des Rückgangs der „Usability“ (2020)
(datagubbe.se)- Bei Desktop-GUIs etwa von 1994 bis 2012 gab es selbst über unterschiedliche Betriebssysteme hinweg viele gemeinsame Regeln, sodass erfahrene Nutzer sich schnell an neue Umgebungen anpassen konnten; inzwischen sei diese Grundlage schwächer geworden
- Das auf kleine Smartphone-Bildschirme und Touch-Eingabe zugeschnittene Single-App-Paradigma wurde auf den Desktop übertragen und kollidiert dort mit der Nutzung mehrerer Fenster, die von Tastatur und präziser Mausbedienung ausgeht
- In Beispielen wie Windows-10-Apps, Slack, Chrome, Firefox 75, QT5 und Gnome-Apps wiederholen sich Veränderungen, die bestehende UI-Konzepte verwässern, etwa Titlebar-Widgets, die Megabar, automatisch ausblendende Scrollbars oder verschwundene Menüleisten
- Dropdown-Menüs, klar erkennbare Titlebars, Anzeigen des Fensterfokus sowie identifizierbare Buttons und Eingabefelder waren eine plattformübergreifend erlernbare gemeinsame Sprache, doch app-spezifisches Verhalten erfordert zusätzliches Lernen
- Mit Platzersparnis, der Unvermeidlichkeit von Veränderungen, den Multiplattform-Grenzen von Electron oder dem bloßen Hinweis auf freie Software lässt sich das Aufbrechen bewährter UI-Konzepte kaum rechtfertigen; einflussreiche Projekte und Unternehmen brauchen Konsistenzstandards
Geschwächte gemeinsame Regeln in Desktop-GUIs
- Etwa zwischen 1994 und 2012 konnten sich Nutzer mit vernünftiger Computererfahrung schnell zurechtfinden, egal vor welcher GUI eines Betriebssystems sie saßen
- Nicht nur Windows, MacOS, CDE, OpenStep und OS/2, sondern auch Umgebungen wie Amiga, Atari und BeOS hatten mehr Gemeinsamkeiten als Unterschiede
- Fenster boten damals in der Regel über die Titlebar die Möglichkeit zum Ziehen, zur Identifikation und zur Anzeige des aktuellen Eingabefokus
- Standardisierte Dropdown-Menüs wie File, Edit, View und Help erleichterten es, Funktionen einer neuen App zu erkunden und Shortcuts zu lernen
- Buttons, Eingabefelder und andere Widgets waren dank visueller Hinweise wie 3D-Bevels leicht als interaktive Elemente erkennbar
- Es gab zwar einige Ausnahmen, die sich nicht an die Regeln hielten, aber in wichtigen Grundbereichen teilte die meiste Software dieselben Konventionen
Das Problem des auf den Desktop übertragenen Smartphone-Paradigmas
- Auf relativ neuen Plattformen wie Smartphones kann wegen der anderen Eingabemethoden und Bildschirminteraktionen im Vergleich zum Desktop ein neues Paradigma nötig sein
- Das Problem ist, dass sich dieses Paradigma auch auf den Desktop ausbreitet, wo Tastatur und pixelgenaue Maussteuerung möglich sind
- In Kombination mit Flat Design werden UI-Elemente tendenziell größer, sind aber gleichzeitig schwerer von Dekoration oder Inhalt zu unterscheiden
- Das Design von Desktop-Anwendungen schwächt zunehmend die Annahme, dass mehrere Apps und Fenster gleichzeitig sichtbar sein können, und bewegt sich hin zu einer smartphoneartigen Single-App-Nutzung
- Besonders störend ist, dass dabei Desktop-UI-Konventionen umgangen werden, die sich bei vielen Nutzern bereits als Muskelgedächtnis eingeprägt haben
Fensterverwaltung: Die Titlebar ist nicht mehr nur ein Bereich für Fenster
- Bei vielen beliebten Windows-10-Apps fällt in der Titlebar mangelnde Konsistenz auf, obwohl die Screenshots im Abstand von nur wenigen Minuten auf demselben Computer aufgenommen wurden
- Alle sechs Fenster zeigen ein aktives Fenster an, doch Outlook und Slack wirken fast wie inaktiv, und auch bei den anderen Fenstern ist der Unterschied zwischen aktiv und inaktiv mit Ausnahme von
cmd.exesehr subtil - Die meisten Titlebars enthalten Tool-Icons, Tabs, Dropdown-Menüs oder eine Kombination daraus
- Dadurch variiert die Breite des anklickbaren Bereichs für traditionelle Aktionen wie Fenster verschieben, fokussieren oder in den Vordergrund holen je nach App
- Nutzer, die die Titlebar als Bereich zur Fenstersteuerung gelernt haben, führen dadurch leicht unbeabsichtigt App-Funktionen aus
- Es gibt auch Elemente wie das kleine Logo von Visual Studio Code, die wie ein Icon aussehen, tatsächlich aber nur Dekoration sind
- Dass vier der sechs Apps Microsoft-Apps sind, deutet darauf hin, dass sich dieses unregelmäßige Design wie ein Standard verbreiten könnte
- In der neuesten Slack-Version ist der Bereich zum Ziehen an oberem Rand und Ecken zum Größenändern, der seit Windows 2 existierte, stark reduziert
- Der rote Bereich markiert die verbliebenen Hotspots zum Ändern der Fenstergröße, der blaue Bereich die Hotspots zum Verschieben des Fensters
- Der restliche Raum wird von einer nicht standardmäßigen Kombination aus Widgets eingenommen
- Mit dem Update vom 22. April 2020 zeigt die Desktop-Version von Slack bei inaktiven Fenstern die Titlebar nun etwas dunkler an
Browser-UI: Tooltips und Adressleiste erschüttern bestehende Konzepte
- Chrome bietet große Tab-Tooltips, die sofort erscheinen, wenn der Mauszeiger auf einem Tab liegt
- Übliche Browser-Tab-Tooltips erscheinen erst nach kurzer Verzögerung als kleines schwebendes Tooltip
- Das neue Tooltip in Chrome erscheint ohne Verzögerung und verdeckt einen großen Bereich der darunterliegenden UI
- Schon der Nutzen von Tab-Tooltips ist diskussionswürdig, doch diese Form gilt als ablenkendes und unnötiges Element
- Die Änderungen an der URL-Leiste in Firefox 75 werden als Megabar bezeichnet
- Sie springt in schwer vorhersehbaren Momenten auf
- Sie lässt sich schwer abschalten und verdeckt die darunterliegende Lesezeichenleiste
- Text-Eingabefelder sind ein altes UI-Element, dessen Grundkonzept sich mindestens seit den frühen 1980er Jahren gehalten hat, doch die Megabar verändert dieses Verhalten stark
Scrollbars: Ausblenden und geringer Kontrast erschweren die Positionswahrnehmung
- Automatisch ausblendende Scrollbars können auf Smartphones nützlich sein, weil sie auf kleinem Bildschirm Platz sparen und direkt mit dem Daumen gescrollt werden kann
- Auf dem Desktop erfüllen Scrollbars die Funktion einer Statusanzeige, die die aktuelle Position im Inhalt zeigt
- Nutzer können ihre aktuelle Position erkennen, ohne ihre Arbeit zu unterbrechen und zur Maus zu greifen
- Auch in Fenstern ohne Fokus lässt sich die Position erkennen
- In Logfile-Readern mit
tailoder in Eingabeaufforderungen mit Debug-Streams helfen Scrollbars dabei zu prüfen, ob gerade die neuesten Ausgaben sichtbar sind - Bei automatisch ausblendenden Scrollbars wird diese Prüfung schwieriger, und man muss auf andere, weniger klare oder umständlichere Methoden ausweichen
- Das Standard-Rendering von Scrollbars in QT5 macht es schwer, Balken und Spur zu unterscheiden, und der Kontrast ist sehr gering
- Selbst wenn man weiß, dass der etwas hellere Bereich der Balken ist, kommt es häufig zu Fehlklicks
- Auf alten und günstigen Laptop-Displays kann es schwer sein, den Unterschied zwischen Balken und Spur zu erkennen
- QT5 lässt sich mit Tools auf ein traditionelleres Erscheinungsbild umstellen, aber neue Nutzer wissen das meist nicht, weshalb das Standardaussehen wichtig ist
Menüleiste und Inkonsistenz bei Gnome-Apps
- Die Menüleiste war unter Windows, Mac und Unix-artigen Systemen weitgehend ein kleinster gemeinsamer Nenner, der ähnlich funktionierte
- Das klassische File/Edit/View-Schema war der Standardweg, um App-Funktionen zu erkunden, doch das Gnome-Design ersetzt dies durch andere Ansätze
- Hamburger-Menüs können auf Smartphones nützlich sein, aber auf Desktop-Systemen mit breiten Bildschirmen ist der Bedarf, horizontale Platzknappheit zu lösen, gering
- In Gnome scheinen Hamburger-Menüs dazu zu dienen, UI-Aktionen aufzunehmen, die sonst nirgends platziert wurden
- Im Hamburger-Menü von Evince finden sich Open, Save, Print und Close
- Im Hamburger-Menü von Gnome-MPV gibt es weder Open noch Close; zum Öffnen einer Datei muss man links auf den Plus-Icon-Button klicken
- Der App-Icon-Button in Gnome-MPV enthält Optionen wie preferences und quit, während der App-Icon-Button in Evince ein anderes Menü bietet
- Wegen der geringen Konsistenz zwischen Apps müssen Nutzer unterschiedliche Positionen lernen, um dieselbe Funktion zu finden
- Anders als bei normalen Dropdown-Menüs oder einigen Hamburger-Menüs ist es bei diesen Menüs nach dem Öffnen schwer herauszufinden, wie man sie per Tastatur navigiert
Integration der Titlebar in Gnome und zusätzliche Toolbars
- Gnome-Apps übernehmen ein neues Paradigma, bei dem die Toolbar in die Fenster-Titlebar integriert wird, und institutionalisieren damit genau die Belegung der Titlebar, die zuvor bei Windows-Apps kritisiert wurde
- Bei Verwendung anderer Window-Manager können die Schließen-Buttons des Window-Managers und der App doppelt erscheinen
- Weil ein gewisser Bereich zum Verschieben des Fensters freigehalten werden muss, werden Widgets, die früher in einer Toolbar unterhalb der Titlebar Platz hatten, nun in separat aufklappende Strukturen ausgelagert
- Das Suchfeld von Evince wird separat aufgeklappt angezeigt
- Die Annotations-Toolbar enthält nur zwei Icons, benötigt zu ihrem Öffnen aber ein eigenes zusätzliches Icon
Antworten auf häufige Gegenargumente
- Die Aussage „Technologie entwickelt sich weiter und Veränderung ist unvermeidlich“ ist eher eine Floskel, die ohne echtes Argument verwendet wird
- Änderungen am UI-Design sind keine Naturgewalt, sondern menschliche Entscheidungen
- Veränderung bedeutet nicht automatisch Verbesserung; das Ziel sollte Verbesserung sein, nicht Veränderung an sich
- Das Gegenargument, man „hänge in der Vergangenheit fest“, mag insofern zutreffen, als traditionelle UI-Elemente bevorzugt werden, bedeutet aber nicht, dass jeder moderne Desktop wie Windows 95 oder CDE aussehen müsse
- Es gibt andere Wege, Look and Feel eines UI zu verbessern, ohne Grundkonzepte aufzubrechen
- Auf das Gegenargument „Electron-Apps können keinem einzelnen Plattformstandard folgen“ lautet die Antwort, dass gerade Multiplattform-Apps Paradigmen einhalten sollten, die sich auf gemeinsame Plattformen übertragen lassen
- Dropdown-Menüs, saubere Titlebars und klare Anzeigen des Fensterfokus sind keine Konzepte, die schwer umzusetzen wären
- Multiplattform-Frameworks sollten solche Konzepte leicht implementierbar machen und es schwerer machen, sie zu umgehen
- Auch auf das Argument „Über freie Software sollte man sich nicht beschweren“ gilt: Große FOSS-Projekte wie Gnome und KDE haben ähnlich wie Microsoft oder Google großen Einfluss auf Nutzer, Designer und Programmierer
- Wenn Projekte als Vorbilder gelten, sollten für sie entsprechende Standards gelten
Platzersparnis auf dem Bildschirm und UI-Komplexität
- Das Platzieren von Elementen in der Titlebar kann bis zu einem gewissen Grad Bildschirmfläche sparen
- Allgemein sei Bildschirmfläche heute jedoch kein großes Problem mehr
- Wer viel am Computer arbeitet, kann für rund 200 US-Dollar einen großen Monitor mit 2560x1440 Auflösung kaufen
- Selbst die günstigsten Laptops bieten meist mindestens 1366x768 Pixel Auflösung
- Das Problem mit dem verfügbaren Platz wird eher durch die großzügigen Abstände in heutigen UI-Designs verschärft
- Es gibt Beispiele, in denen einfache Dialogfenster wie Vollbild-Anwendungen wirken
- Wer den ganzen Tag auf einem 13-Zoll-Laptop programmiert, sollte sich nach Ansicht des Autors eher um Rücken, Nacken, Hände und Schultern sorgen als um ein paar Pixel
- Zwar ist UI-Design schwierig und kann nicht immer alle Nutzer zufriedenstellen, doch das rechtfertigt nicht, grundlegende und über Jahrzehnte bewährte UI-Konzepte absichtlich aufzubrechen
- Wenn Nutzer für jede App die Details von Fensterdekoration und Bedienweise gesondert lernen müssen, investieren sie wiederholt Zeit und Energie in das Interpretieren dieser Unterschiede
1 Kommentare
Hacker-News-Kommentare
In den letzten ungefähr zehn Jahren hatte ich das Gefühl, ständig mit UI/UX-Teams zu kämpfen; im Kern scheint es darum zu gehen, dass sich die Designmaßstäbe bei professionellen Tools hin zu Paradigmen des Content-Konsums für Verbraucher verschoben haben.
Vor 20 Jahren war Software meist ein Werkzeug für Profis, heute steht nach Nutzung gemessen Consumer-Software wie Video und Social Media im Mittelpunkt. Designer versuchen, die Regeln des Content-Konsums auch auf Produkte anzuwenden, mit denen man „Dinge erledigen“ soll.
Typischerweise werden sichtbare Werkzeuge im Namen von „aufgeräumter und intuitiver“ hinter einem Drei-Punkte-Menü versteckt, wodurch aus einem Klick zwei werden, und Tool-Nutzer müssen das hunderte Male am Tag wiederholen. Tabellen zeigen in einem Bereich, der früher 20 Einträge und 6 bis 8 Detailangaben zeigte, nur noch 10 Einträge und 4 Detailangaben; Dashboards zeigen statt 10 Diagrammen nur noch 4; Menüs nehmen oben in der App 10 bis 20 % ein; H1-Überschriften werden riesig.
Ich habe eine Tante, die ständig die Möbel umstellt, nicht weil es eine bessere Anordnung gäbe, sondern weil ihr die aktuelle langweilig wird; bei PMs und UX-Leuten scheint diese Neigung verbreitet zu sein. Wenn einem Produkt eine vierte Tabellenansicht hinzugefügt wird und es heißt, man müsse „einen völlig anderen Stil verwenden“, dann nicht, weil er besser wäre. Seit COVID treffe ich mich jede Woche mit Freunden in Google Meet, und fast jedes Mal hat sich irgendetwas geändert; zuletzt wurde der Ablauf für Beitrittsanfragen wieder geändert, aber besser ist er nicht geworden.
Irgendwann akzeptiert man es einfach und wartet, bis der bessere Ansatz zum neuen Best Practice wird.
Aber die Bewegung, die ursprünglich das Problem beheben wollte, hat sich immer weiter verstärkt, und niemand scheint bemerkt zu haben, dass sie längst zu weit gegangen ist. Oder vielleicht wenden neue Designer, die den Kontext früherer UIs nicht kennen, dieselbe Kur erneut auf bereits reparierte UIs an.
Es fühlt sich weniger an, als würde das Pendel zurückschwingen, sondern eher, als hätte es Fluchtgeschwindigkeit erreicht.
Jeder Button und jede Scrollbar auf dem Bildschirm sagt ständig: „Das könntest du tun, hast es aber noch nicht getan“; für Designer persönlich ist das offenbar so lästig und aufdringlich, dass sie am Ende alles entfernen wollen.
Ich frage mich, wann die UI-Strömung zu so viel Skeuomorphismus zurückkehrt, wie durchschnittliche Nutzer brauchen. Selbst das Web-Link-Paradigma scheint für ältere oder unerfahrene Nutzer zu schwierig zu sein, und irgendwann wird das wohl durch unvermeidliche Daten sichtbar werden.
Auch PMs und UX-Verantwortliche werden dafür bezahlt, Arbeit zu leisten, und ihre Arbeit besteht darin, UI/UX zu verändern. Wenn man dafür bezahlt wird, eine fast fertige Software zu warten, verbringt man seine Zeit mit Refactoring oder kleinen Korrekturen; der Unterschied ist, dass nicht alles, was wir tun, für Nutzer sichtbar ist.
Mir ist egal, was UX-Leute sonst tun; gebt mir nur die Möglichkeit, Ctrl-K zu drücken und die Anfangsbuchstaben des gewünschten Befehls einzugeben.
Als UX-Designer, der seit etwa 2000 nur Web-, Mobile- und verwandte UIs gestaltet hat, stimme ich zu, dass Veränderung um der Veränderung willen viele Usability-Probleme verursacht.
Das größere Problem ist jedoch, dass professionelle Diskussionen oder saubere Designanalysen unter den tatsächlich gestaltenden Leuten fast verschwunden sind.
Viele Designer, mit denen ich arbeite, haben weder das Vokabular noch das Wissen, um im weiteren Sinn zu erklären, was etwas „benutzbar“ macht, und ihnen fehlt auch die Fähigkeit, subtile Probleme des Interaktionsdesigns oder der Informationsdarstellung zu lösen. Da es kein Wissen und kein Interesse an grundlegenden Heuristiken gibt, wissen sie nicht einmal, wo sie anfangen sollen.
Also leben sie in Figma, schieben Farben, Formen und Effekte herum und zeigen dann ein paar Varianten derselben UI im „User Testing“. Daraus ist ein absichtlich ahnungsloser „nichttechnischer“ Innovationskult geworden, der seinen ursprünglichen Zweck völlig verloren hat.
Es ist keine Übertreibung zu sagen, dass ich mich für meinen Beruf schäme. Wir haben auf ganzer Linie versagt.
Damals dachte ich, wir bekämen nur einen kleinen Einblick in eine Welt, mit der UI/UX-Designer viel vertrauter seien; vielleicht stimmt das gar nicht.
Viele stellen auf Basis dürftiger Recherche nur enge Fragen und kehren dann wieder dazu zurück, Dinge „hübsch“ zu machen, statt über Kontext, Ökosysteme und die systemischen Effekte von Designentscheidungen nachzudenken.
Ich habe sehr grundlegendes Wissen aus einer HCI-Einführung und von guten Designern, aber noch nichts auf technischem oder formalem Niveau.
Im Grunde investieren sie nur das Mindestmaß an geistiger Arbeit, das nötig ist, um bezahlt zu werden.
Ich will ihnen keine Schuld geben. Sie arbeiten in einem gesättigten Feld und sind den Launen und Vorlieben von Führungskräften ausgeliefert, die visuelle Attraktivität oder Gefühl höher bewerten als Usability.
Am Ende ist es Marketing. Wenn Menschen ein Produkt nicht benutzen wollen, spielt es keine große Rolle, wie einfach es zu bedienen ist. Es gibt viele Branchen, die hochgradig benutzbare Dinge herstellen, etwa das Militär; meist sehen sie nur hässlich aus.
Der Autor sagte zwar, dass ihm bei macOS die Erfahrung fehle und er sich deshalb kein Urteil erlaube, aber auch dort findet derselbe Niedergang statt. Insbesondere scheint Apple darauf verfallen zu sein, Funktionen hinter langsamen Hover-Effekten und allzu subtilen Grauschattierungen zu verstecken.
Wahrscheinlich soll das elegant wirken, aber es schadet der Auffindbarkeit der Oberfläche. Selbst wenn man gelernt hat, dass sich etwas hinter einer Hover-Animation verbirgt, lässt es sich nicht leicht ansteuern, weil der tatsächliche Zielbereich erst sichtbar und aktiv wird, nachdem man die Maus genau dorthin bewegt hat. Die Music-App und das Verhalten von Benachrichtigungen sind besonders schlimm.
Auch in der Titelleiste eines Fensters ist nicht klar erkennbar, welcher Bereich ziehbar ist. Ich habe nie verstanden, warum man an einem Pixel das Fenster ziehen kann, der direkt darunter liegende, gleich aussehende Pixel aber nicht funktioniert.
Meiner Meinung nach war die UI-Usability von Apple schon lange keine Stärke mehr. Wenn man sowohl Mac als auch PC nutzen muss, ist macOS in vielerlei Hinsicht genauso furchtbar wie ein PC, oder sogar schlimmer.
Was Apple gut kann, ist die geräteübergreifende Integration der Nutzung im eigenen Ökosystem.
macOS spielt beim Wechseln zwischen Bildschirmen aber eine träge Animation ab. Man kann sie nicht abschalten und nur zwischen zwei ähnlich langsamen Varianten wählen.
Mir fällt kein guter Grund ein, der das rechtfertigen würde. Ich weiß nicht, welches Nutzermodell zu dem Schluss kommt: „Beim Fensterwechsel ist eine langsame Animation gut.“
Beidseitiges Drucken wird nicht unterstützt, also muss man es von Hand machen, und manche Apps drucken die Seiten in umgekehrter Reihenfolge, sodass man sie danach wieder sortieren muss.
Damit der
.auf dem Ziffernblock als.und nicht als,verwendet wird, muss man eine App herunterladen, nur um eine vernünftige Voreinstellung zu bekommen.Wenn man keine englische Tastatur verwendet, funktioniert im Terminal auch Alt+. nicht.
Um eine heruntergeladene App auszuführen, muss man sie starten, das Scheitern hinnehmen, zu Einstellungen und Sicherheit gehen, die blockierte App finden und sie erlauben. Schlimmer als Windows Vista.
Wenn man einer App eine Berechtigung geben will, muss man die Art der Berechtigung kennen, und man kann nicht nach App suchen. So geht es immer weiter.
Selbst heute verbringe ich viel zu viel Zeit damit, die bläulich-grauen Icon-Formen in der Finder-Seitenleiste zu entschlüsseln.
Man ist noch weiter darin gegangen, die Dateistruktur und sogar das Konzept einer Datei zu verstecken. Fragt man nichttechnische Windows- oder Mac-Nutzer, wo eine Datei gespeichert ist, wissen sie es nicht. Fragt man, ob sie in der Cloud liegt, wissen sie es ebenfalls nicht.
Noch schlimmer ist, dass Apps, genau wie bei der UI, Daten nicht konsistent am selben Ort speichern. Und die idiotische Praxis, Dateiendungen zu verstecken, darf man auch nicht vergessen.
Windows lügt nicht englischsprachige Nutzer sogar an. Auf Deutsch behauptet es zum Beispiel, das Home-Verzeichnis liege unter „Benutzer“, tatsächlich gibt es dieses Verzeichnis aber nicht, nur „Users“. Der Versuch, Komplexität zu verstecken, erzeugt am Ende Verwirrung und noch mehr Komplexität.
Das erinnert mich an ein anderes Problem aus meinem ersten Vollzeit-iOS-Job. In der App-Beschreibung stand „button“, die deutsche Übersetzung war „Knopf“, und das blieb am Schimpfwortfilter von Apple hängen. Vermutlich, weil „Knopf“ auch eine Übersetzung von „knob“ sein kann, aber im Deutschen hat „Knopf“ keine sexuelle Anspielung wie das englische „knob“.
Apple wirkt auf mich wie der Anbieter, der am stärksten darauf drängt, sich vom Konzept „Datei“ zu lösen und „Inhalte“ zwischen verschiedenen Apps zu bewegen. Allerdings unterscheiden sich die Paradigmen für Teilen, Importieren und Exportieren je nach App wieder ein wenig.
Inzwischen gibt es sogar die App „Dateien“ für iCloud Drive. Was bedeutet das? Woher soll ich wissen, ob etwas auf meinem Telefon liegt oder ob ich nur eine Darstellung davon sehe, was in iCloud Drive ist? Ich weiß nicht, ob das Wolken-Icon bedeutet, dass es heruntergeladen wurde oder nicht, und was ein etwas dunkleres oder etwas helleres Grau wiederum bedeuten soll.
Und das, obwohl selbst die am wenigsten technischen Nutzer wissen, was Dateiendungen sind und wie sie funktionieren.
Keine Ahnung, was Microsoft da treibt.
Ein weiterer Rückschritt im Explorer ist, dass es früher neben Verzeichnissen mit Inhalt ein kleines „+“ gab, das Microsoft entfernt hat.
Es erscheint erst, wenn man mit dem Cursor über den linken Bereich fährt, ohne erkennbaren Grund. Oder vielleicht ist man vom allgemein verstandenen „+“-Symbol noch weiter zu einem dummen Dreieck zurückgefallen.
Ich komme mit den Rückschritten schon gar nicht mehr hinterher.
Die Desktop-Usability wurde zugunsten von Mobilkompatibilität beschnitten, trotzdem sind viele Umgebungen auf Mobilgeräten weiterhin praktisch nicht präsent. Bitte gebt uns jetzt endlich die Scrollbars zurück.
Einmal haben ein Entwickler und ich viel Zeit damit verbracht, eine bestimmte Einstellung zu suchen, ohne dass es irgendeinen Hinweis darauf gab, dass sich unterhalb des Fensters noch weitere Inhalte und Checkboxen befanden. Vor der Zeit der versteckten Scrollbars wäre das selbstverständlich sichtbar gewesen.
Das Problem ist: Befindet sich der Pointer über dem Navigationspanel, also dort, wo er fast immer ist, werden die Scrollbars anderer Panels ausgeblendet. Ohne den visuellen Hinweis einer Scrollbar gab es keinen Grund, den Pointer zu bewegen, um herauszufinden, dass es in einem anderen Panel noch mehr Inhalte gibt. Inzwischen wurden auch noch alle Trennlinien entfernt, sodass man nicht einmal mehr erkennen kann, ob es sich überhaupt um ein separates Panel handelt.
Nachdem ich dem Entwickler einen Screenshot geschickt und bestätigt hatte, dass ich die aktuelle Version benutze, kam die Antwort: „Scrollen Sie nach unten.“ Klar, ich war natürlich der Idiot. /s
Wie auf Mobilgeräten muss man alle UI-Elemente wahllos antippen, um herauszufinden, wie sie funktionieren, und die dabei gelernte Fähigkeit gilt dann nur für genau diese eine App. Tippen, lange tippen, unterschiedlich lange lange tippen, schneller tippen, wild herumdrücken, „googeln“, und diesmal muss man an eine Stelle ziehen, die nicht einmal wie ein UI-Element aussieht.
„Ist die Checkbox angehakt?“ war nie so mehrdeutig wie „Ist der Slider-Schalter eingeschaltet?“ Checkboxen brauchen außerdem weniger Platz auf dem Bildschirm. Das optimiert weder Platz noch Benutzerfreundlichkeit, sondern nur das Aussehen.
Es kann sogar noch schlimmer werden, wenn man sie noch flacher macht, sodass sie wie zwei Rechtecke aussehen. Ist der dunkle Bereich der Schalterteil? Wen kümmert’s. Hauptsache, es sieht sauber und störungsfrei aus. Offenbar war ich zu abgelenkt davon, den Zustand des Schalters erkennen zu können.
Das Buch verwendet Seiten darauf, zu sagen, dass man Modi vermeiden sollte, und erklärt auch warum. Die Dos and Don’ts für UI auf Seite 70 sind es wert, wiederholt zu werden.
Zu den Dos gehört, den Nutzern möglichst viel Kontrolle über das Aussehen von Objekten zu geben, für ausführbare Menübefehle Verben zu verwenden, Warnungen selbsterklärend zu machen und nicht nur Menübefehle, sondern auch Controls und Grafiken zu nutzen.
Zu den Don’ts gehören der Missbrauch von Modi, Nutzer für Aufgaben, die mit der Maus einfacher sind, zur Tastatur zu zwingen oder umgekehrt, insbesondere bei Dingen wie Scrollen, die das Aussehen des Bildschirms unerwartet verändern, Objekte unnötig neu zu zeichnen und eigene Menüs mit denselben Namen wie Standardmenüs anzulegen. About, File, Edit und sogar was dort hineingehört, hat dieses Buch definiert.
Wir sind in einem seltsamen lokalen Minimum gelandet, in dem es pro App eine andere einzig richtige UI gibt, die allen Nutzern in derselben Form aufgezwungen wird. In Bereichen wie der industriellen Steuerung dagegen, wo eine App zu einer 50.000-Dollar-Maschine von ein bis drei Personen genutzt wird, lassen sich responsive Mobile-Interfaces so einfach anordnen wie Slide Decks, und ein maßgeschneidertes Dashboard ist nur ein Widget entfernt.
Wenn die Cloud Schuhe herstellen würde, gäbe es getrennte Schuhe für Rasen und Beton, aber alle wären in derselben Größe; wer große Füße hat, müsste sich die Zehen abschneiden, und wer kleine hat, müsste sie mit Implantaten ausfüllen.
Im Zusammenhang mit der Beschwerde über Scrollen gibt es ein desktopspezifisches Prinzip, das deutlich wird, wenn man sich ältere Desktop-UIs anschaut: Controls scrollen niemals, nur Inhalte scrollen.
Wenn Controls nicht in ein Fenster passen, macht man dieses Fenster nicht scrollbar, sondern teilt es in Tabs auf oder legt zusätzliche Controls in ein separates Fenster, das über einen Button geöffnet wird. Zumindest unter Windows und macOS scheint das ein allgemeines Prinzip zu sein.
Checkboxen sind viel besser, solange das Label keine doppelte Verneinung enthält. Entwickler, die es zum Beispiel so bauen, dass durch Anhaken etwas deaktiviert wird, gehören im Morgengrauen erschossen.
Ich kann schon nicht erkennen, ob der gleitende Kreis tatsächlich ein- oder ausgeschaltet ist, und in der Hälfte der Fälle weiß ich nicht einmal, welcher der Zustände Ein und Aus der ist, den ich will. Doppelte Verneinungen überall, merkwürdige Formulierungen und keinerlei Hinweis auf die tatsächliche Wirkung.
Das wirkt alles völlig verrückt.
Es hieß, Orte wie Google würden sich in letzter Zeit immer stärker in A/B-Tests verbeißen, aber in der Geschichte der Nutzerforschung hat noch kein A/B-Test die heftige Wut von Power-Usern richtig gemessen, die ausbricht, wenn ein Button aus irgendeinem Grund verschoben wird.
Tragbare Musikplayer, früher Walkman oder MP3-Player genannt, heute im Bereich DAP, sind mein Dauerärgernis. Die aktuell verkauften Player sind in der Bedienbarkeit so furchtbar, dass ich nicht verstehe, wer sie kaufen wollen sollte.
Die guten Produkte sind durch die Kombination aus Streamingdiensten und Android-Geräten verdrängt worden. Es gibt keine leichten, einfachen Player mehr, mit großer Kapazität, physischen Tasten und guter Akkulaufzeit. So ein Ding, das keine blauen Flecken verursacht, wenn man es beim Laufen in der Tasche hat.
Ein gut lesbares Display, eine vernünftige Menüstruktur, ein Gerät, das Datei-Tags liest und auf das man Playlists einfach per Drag-and-drop ziehen kann. Es gibt sicher Leute, die so etwas wollen, aber die Hersteller bringen riesige Ziegelsteine heraus, mit herausstehenden Drehknöpfen, seltsamen Kanten, riesigen Touchscreens, die den Akku leer saugen, und schrecklichen Android-Derivat-OS.
„Der hat zwei DACs!“ Wirklich? Ich sitze nicht in einem schallisolierten Hörraum mit 10.000-Euro-Monitoren, sondern mit Ohrhörern im Bus.
Reviews behandeln die wichtigsten Aspekte tragbarer Musikgeräte kaum und schwärmen stattdessen wie Weinkritiker vom Geruch oder Geschmack der Musik. Das ist halb im Scherz gemeint. Je angesehener der Reviewer, desto mehr Unsinn schreibt er, und oft findet man nicht einmal Angaben zu Gewicht oder Größe.
Wenn sie es erwähnen, liegen sie trotzdem falsch. Zum Beispiel heißt es: „Der Shanling Q1 ist ein leichtes tragbares Gerät“ – ist er überhaupt nicht. Er ist ein schrecklicher Ziegelstein mit miserablen OS, schlechter Akkulaufzeit und überempfindlichen Tasten. Egal wie gut er klingt: Wenn ich keine Playlists darauf bekommen kann, er schwer ist und das Interface miserabel ist, sodass ich ihn nicht benutzen will, interessiert er mich nicht.
Rockbox auf dem Sansa Clip+ war vor 13 Jahren großartig. Wenn man das mit heutiger Technik einfach genauso bauen könnte, würde ich es diesen absurd teuren, riesigen Ziegelsteinen vorziehen.
Es tut wirklich weh zu sehen, wie schlechte Designentscheidungen bei UI, Formfaktor und Touchscreen ansonsten ordentliche Hardware ruinieren.
Nach mehreren Stunden habe ich eine brauchbare Lösung gefunden. Ich habe bei Amazon einen Hifi Walker H2 gekauft; er hat schlechtes UI-Design, einschließlich Tippfehlern, aber die Hardware ist gut.
Darauf habe ich RockBox installiert, und mit etwas Anpassung waren die miesen UI-Probleme gelöst. Schade ist, dass RockBox weder Bluetooth noch USB-DAC unterstützt; wenn man diese Funktionen braucht, ist das ein Problem.
„Wir müssen Platz auf dem Bildschirm sparen, also … Notizen prüfen … bauen wir einen Button ein, der den ganzen Bildschirm einnimmt.“
Genau daran hänge ich mich bei der Behauptung auf, „wenn man es in die Titelleiste verschiebt, spart man Bildschirmfläche“.
Was mich heutzutage ebenfalls wütend macht: Viele Anwendungen stehlen beim Start mehrfach den Fokus. Wegen dieses absurden Fokus-Diebstahls haben schon viel zu viele Leute versehentlich ihr Passwort in den Team-Chat gepostet.
Als iOS langes Drücken eingeführt hat, hatte ich das Gefühl, dass es fast vorbei ist. Man konnte nicht wissen, was ein UI-Element tut, wenn man darauf tippt, also musste man alles antippen; und jetzt muss man für andere Aktionen lange drücken.
Ich kann nicht meine Zeit damit verbringen, jedes Element erst anzutippen und dann lange zu drücken, nur um herauszufinden, was eine App vielleicht kann oder was ich von ihr erwarte.
Es sah so aus, als müsste es selbstverständlich so funktionieren, aber heute wird langes Drücken für völlig beliebige Zwecke verwendet.
Beweisen lässt es sich nicht, aber ich glaube, dass solche UI/UX-Katastrophen manchmal aus dem Druck entstehen, sich ständig ändern zu müssen, um zu zeigen, dass die Software noch lebt.
Stellen wir uns vor, irgendeine App hätte 2023 den Gipfel der Usability erreicht. Sie ist nicht perfekt, aber es gibt keine vorstellbare Möglichkeit mehr, ihre Bedienbarkeit weiter zu verbessern. Die Nutzer sind ziemlich geübt, und sobald man die inhärenten Hürden beim Erlernen der App überwunden hat, passt im Großen und Ganzen alles zusammen.
Kann dieser Zustand erhalten bleiben? Nein. Wenn die UI unverändert bleibt, nimmt die Softwarewelt die App oft als „veraltet“ oder sogar tot wahr. Also muss sie geändert werden. Wenn man aber nach dem Usability-Gipfel noch etwas ändert, verschlechtert man zwangsläufig die UX, manchmal sogar katastrophal.
Ich denke, das ist einer der Gründe, warum die ordentliche UI mancher Apps und Desktop-Umgebungen gründlich ruiniert wird.
Die weite Verbreitung schneller Always-on-Internetverbindungen hat dieses Problem massiv verschärft. Früher mussten Softwareentwickler ihr Produkt auf CDs, Disketten oder Ähnlichem in die Läden bringen, und weil es keine einfache Möglichkeit für Updates gab, brauchte man zumindest ein klares Ziel und einen Termin.
Auch wenn man ein Update veröffentlichte, musste es sinnvoll und substantial genug sein, damit Nutzer den Aufwand auf sich nahmen, die neue Version zu besorgen und zu installieren. Moderne Software dagegen passt am besten zu einer groben Übersetzung unseres Sprichworts: „Der Samurai hat kein Ziel, nur einen Weg.“
Mein Ideal wäre, ein geliebtes und weit verbreitetes Produkt zu bauen, möglichst alle Support- und Betriebsprobleme zu automatisieren und dann zu einem anderen Produkt weiterzuziehen oder am Strand zu entspannen.
Niemand will Veränderung. Ich habe nur Horden gesehen, die sich bei jeder UI-Änderung beschweren, aber nie, dass auf der Gegenseite echte Gläubige in ähnlicher Zahl herausströmen.
In der Anfangsphase will man, dass die Leute unser Produkt mögen; man kümmert sich, hört zu und weist Usability Ressourcen zu. Glückliche Kunden machen uns glücklich.
In der mittleren Phase erkennt man, dass Usability schwierig ist, dass Ergonomie und Affordanzen zu schaffen weniger einfach ist als gedacht, und dann kommt auch noch Internationalisierung dazu. Niemand bringt einem diesen Bereich richtig bei, also mussten die meisten es selbst lernen, und Auftragnehmer sind teuer.
In der Verfallsphase will man mehr Features bauen und stellt mehr Programmierer ein, während das Usability-Team entlassen wird, weil „alles Nötige erledigt“ sei. Das Dokumentationsteam wird ebenfalls entlassen. Softwareentwickler sind ja Ingenieure, also können sie wohl auch eine FAQ schreiben.
In der Tiefpunktphase hat man den Kunden in tollen Sprints jede Menge Features hingeworfen, und trotzdem sind sie unglücklich. Man fragt sich: „Was ist nur mit den Kunden los?“
Nach Office 2007 habe ich eine Zeit lang den Atem angehalten und gehofft, dass die OpenOffice-/LibreOffice-Entwickler nicht eilig das Ribbon implementieren. Dass sie bis heute durchgehalten haben, ist ein kleiner Lichtblick.
Man bezahlt weiterhin ein ganzes UX-Team, das für eine nahezu perfekte v1 nützlich war, also muss man ihm Arbeit geben.