Lasst uns idiomatisches Design wiederbeleben

 (essays.johnloeber.com)
1 Punkte von GN⁺ 17 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Designkonventionen, die für Nutzer sofort verständlich sind, verringern den Lernaufwand und ermöglichen konsistente Interaktionen
  • Im Zeitalter der Desktop-Software waren Oberflächen dank Betriebssystemen und Richtlinien vereinheitlicht, etwa bei Menüstrukturen und Tastenkürzeln
  • Im Zeitalter browserbasierter Software ist diese Konsistenz durch die Verbreitung von Frameworks und Custom-Implementierungen zerbrochen
  • Apple und Substack zeigen mit begrenzter Anpassbarkeit und einheitlichen Designsystemen erfolgreiche Beispiele moderner Konventionen
  • Produktdesigner sollten bestehenden Konventionen folgen und Klarheit und Konsistenz priorisieren, um zu einer standardisierten User Experience im Web zu gelangen

Designkonventionen

  • Die Checkbox wird als typisches Beispiel für eine Designkonvention genannt, die Nutzer ohne zusätzliches Lernen sofort verstehen
    • Auf die Frage, ob man eingeloggt bleiben möchte, wären viele Eingabeformen möglich, in der Praxis wird aber stets eine Checkbox verwendet
    • Sie fungiert sowohl für Nutzer als auch für Entwickler als vertrautes standardisiertes Interaktionsmuster

Homogene Oberflächen

  • Eine Oberfläche ist das Mittel, mit dem Nutzer mit einem System interagieren, und je weniger man darüber nachdenken muss, desto besser ist die Oberfläche
    • Zum Beispiel sollte die Kopierfunktion per Command+C überall gleich funktionieren
  • In der heutigen Web-Software-Umgebung ist die Konsistenz von Oberflächen jedoch verschwunden
    • Selbst grundlegende Funktionen wie Datumsauswahl oder Eingabe von Kartennummern sind von Website zu Website unterschiedlich umgesetzt
    • Da Tastenkürzel und Interaktionsweisen je nach App variieren, müssen Nutzer jedes Mal neu lernen, „wo sie was anklicken müssen“

Das Zeitalter der Desktop-Software

  • Desktop-Software in der Windows-95-bis-7-Ära bewahrte eine hohe Konsistenz der Benutzeroberflächen
    • Die Menüstruktur „File, Edit, View“ war in allen Programmen identisch vorhanden
    • Unterstrichene Buchstaben in Menüpunkten signalisierten Tastenkürzel und konnten etwa mit ALT+F, N bedient werden
    • Die Statusleiste (status bar) am unteren Rand zeigte den aktuellen Zustand klar an, etwa Seite, Wortzahl oder Modus
    • Der Schwerpunkt lag auf textbasierten Menüs, Icons wurden nur verwendet, wenn ihre Bedeutung eindeutig war
  • Diese Konventionen waren nicht nur in Microsoft Word, sondern im gesamten Windows-Ökosystem vereinheitlicht
    • Selbst auf dem Abmeldebildschirm von Windows XP wurde visuell klar gemacht, dass alle Elemente Buttons sind, und die Tastenkürzel wurden angezeigt
  • Diese Konsistenz war durch die Beschränkungen des Betriebssystems und der GUI-Bibliotheken möglich, zudem verteilte Microsoft Hunderte Seiten umfassende Designrichtlinien, damit Entwickler ihnen folgten

Das Zeitalter browserbasierter Software

  • Das heutige Zeitalter der Webanwendungen wird als Ära heterogener Oberflächen beschrieben
    • Selbst gute Web-Apps wie Figma und Linear haben keine gemeinsamen Icons oder Tastenkürzel
    • Jede App ist für sich gut gestaltet, hat aber andere Interaktionsmuster
    • Sogar innerhalb desselben Unternehmens unterscheiden sich Gmail, GSuite und Google Docs in ihrem Nutzungserlebnis
    • In der Folge verbringen Nutzer ihre Zeit nicht im produktiven Flow, sondern damit, die Bedienelemente zu suchen

  • Einfluss des mobilen Wandels

    • Mit dem Aufkommen von Touchscreens wurden maus- und tastaturzentrierte Designmuster neu erfunden
    • Weil mobile und Desktop-Systeme gleichzeitig unterstützt werden müssen, verbreiteten sich unvollständige Zwischenformen von UI
    • Beispiel: Hamburger-Menüs für Mobilgeräte werden unverändert auch auf dem Desktop verwendet
    • Eine Kultur der Wiederverwendung modularer Komponenten vervielfältigt fehlerhafte Muster und verschlechtert die Qualität
    • Als Ergebnis von mehr als zehn Jahren hat sich eine generationenübergreifende Erosion der UI/UX-Qualität angesammelt

  • Mangel an Konventionen jenseits von HTML

    • Im frühen Web gab es klare Konventionen wie den blau unterstrichenen Link, heute unterscheidet sich das Styling jedoch von Website zu Website
    • Die HTML/CSS-Standards sind streng, tatsächlich verwenden die meisten aber React- und TypeScript-basierte Build-Systeme
    • Dadurch verbreiten sich Custom-Implementierungen anstelle standardisierter HTML-Elemente, was sogar Barrierefreiheitsprobleme verursacht
    • Beispiel: Wird statt <a> ein <span> mit onclick verwendet, funktionieren Screenreader nicht mehr korrekt
    • Es gibt auch Apps wie Figma, die mit WebAssembly arbeiten und HTML vollständig verlassen
    • Grundfunktionen des Browsers wie Zurück-Button, Tastenkürzel und Ähnliches werden ignoriert, und ein neues Paradigma der Mensch-Computer-Interaktion wird aufgebaut
    • Da sich Frontend-Entwicklung vor allem um Geschwindigkeit und Möglichkeiten weiterentwickelt hat, ist es schwierig, konsistente Konventionen zu etablieren
    • Die Vielzahl an Frameworks und Interaktionsformen schafft strukturell ein Umfeld, in dem ein einheitlicher Standard schwer durchsetzbar ist

Erfolgsbeispiele für idiomatisches Design

  • Apple gilt heute als repräsentatives Beispiel dafür, starke Designkonventionen aufrechtzuerhalten
    • Schriften, Buttons, Farben und das gesamte Designsystem sind vereinheitlicht und bieten eine konsistente Interaktionserfahrung in ganz iOS
    • Diese Konsistenz erzeugt das Vertrauen von „it just works“
  • Substack bietet ebenfalls durch begrenzte Anpassbarkeit und vordefinierte ästhetische Standardwerte ein stabiles Nutzungserlebnis
    • Die Designprinzipien von Apple und Substack verbreiten sich durch ihren Erfolg als Branchenstandard und werden schließlich zu neuen Konventionen

Prinzipien, denen Produktdesigner folgen sollten

  • Für Produktentwickler wird vorgeschlagen, soweit wie möglich bestehenden Designkonventionen zu folgen, um Nutzbarkeit und Kompatibilität zu erhöhen
    • Den Grundkonventionen von HTML/CSS folgen: Links mit Unterstreichung, Farbe, Pointer-Cursor und dem <a>-Tag umsetzen
    • Standard-HTML-Elemente nicht mit JavaScript nachbauen, z. B. statt eines React Button lieber <button> verwenden
    • Browser-Konventionen einhalten: Zurück-Button muss funktionieren, dieselbe Oberfläche muss über kopierte URL erreichbar sein, CTRL+Klick muss einen neuen Tab öffnen
    • Wenn man von allgemeinen Konventionen abweicht, sollte man zumindest innerhalb der Organisation konsistente Regeln beibehalten
    • Text zuerst, Icons sparsam, und Icons nur verwenden, wenn sie allgemein verständlich sind
    • Bei visuellen Elementen sollte Klarheit wichtiger sein als ästhetische Schönheit
    • Wenn die Entscheidung schwerfällt, sollte man sich an guten Websites und an älteren Büchern zum Interface-Design orientieren
  • Letztlich wird eine Zukunft angestrebt, in der Datumswähler oder Formulare zur Karteneingabe im gesamten Web gleich funktionieren, mit dem Ziel einer Web-Umgebung, die nach jahrzehntelanger Wiederholung und Verbesserung zu optimalen Konventionen konvergiert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 17 일 전
Hacker-News-Kommentare

  • In manchen Apps sendet Enter die Eingabe und Ctrl+Enter erzeugt einen Zeilenumbruch, z. B. in Slack; anderswo ist es genau umgekehrt, z. B. auf GitHub.
    Diese mangelnde Konsistenz ist aus Nutzersicht ziemlich verwirrend. Man sagt zwar gern „Lasst uns idiomatisches Design zurückbringen“, aber das eigentliche Problem ist, dass es kaum noch gemeinsame Konventionen gibt.

    • Früher waren Return und Enter verschiedene Tasten. Return war für den Zeilenumbruch, Enter zum Absenden gedacht.
      Heute wurden sie zu einer Taste zusammengelegt, daher gilt üblicherweise: In mehrzeiligen Eingabefeldern erzeugt Enter einen Zeilenumbruch und Ctrl+Enter sendet ab.
      Chat-Apps funktionieren dagegen oft genau andersherum, weil dort meist kurze Nachrichten eingegeben werden. Gute Apps lassen das per Einstellung ändern.
    • Teams hat zwei Modi. Standardmäßig sendet Enter und Shift+Enter macht einen Zeilenumbruch, aber sobald man die Formatierungswerkzeuge öffnet, kehrt sich das um.
      Es wird zwar angezeigt, welche Tastenkombination den Zeilenumbruch erzeugt, trotzdem ist es verwirrend.
    • Slack ist noch komplizierter. Wenn Markdown aktiviert ist, macht Shift+Enter einen Zeilenumbruch, aber innerhalb eines Codeblocks (```) erzeugt Enter den Zeilenumbruch und Shift+Enter sendet ab.
      Die Absicht ist nachvollziehbar, aber die Usability ist miserabel.
    • Eine ideale Lösung wäre wohl: Ctrl+Enter sendet immer, Shift+Enter erzeugt immer einen Zeilenumbruch, und Enter folgt je nach Kontext dem Standardverhalten.
    • Ich selbst dachte auch, dass Shift+Enter für den Zeilenumbruch steht, aber genau das zeigt, wie problematisch diese fragmentierte UX ist.

  • Heutige Software wird nicht mehr wie früher von durchdachten Gestaltern gemacht.
    Stattdessen geben hastig beförderte PMs oder Product-Verantwortliche den Ton an, und sogar Dark Patterns zur Monetarisierung werden gefördert.

    • Als Mobile Engineer ernte ich oft leere Blicke, wenn ich Stakeholdern erkläre, dass man etwas nicht einfach „genau nach der Idee“ bauen kann.
      Man muss die Bedeutung von konsistenter UX und Informationsarchitektur (IA) betonen. Man sollte nicht vergessen, dass Designer ebenfalls Problemlöser sind.
    • Diese Kritik ist zu stark vereinfacht. Schon ein einziges Online-Formular zu bauen, ist in der Praxis die Hölle.
      Bei einem Kreditkartenformular gibt es zum Beispiel unzählige Variablen: Copy-and-paste erlauben oder nicht, Unterstützung alter Browser, das Gleichgewicht zwischen Barrierefreiheit und Sicherheit und vieles mehr.
      Nebenbei erklärt auch Steve Yegges Plattform-Text diese Komplexität sehr gut.
    • In den 2010er-Jahren gingen viele erfahrene UX-Designer verloren, während massenhaft fachfremde Designer aus Print oder Grafik nachrückten; dadurch sank die Qualität.
    • Natürlich gibt es schlechte Anreize und enge Zeitpläne, aber man kann das nicht einfach nur auf Inkompetenz oder Böswilligkeit schieben. Das System selbst hat sich verändert.
    • Wenn man heute sieht, wie PMs sogar die gesamte Architektur und die Release-Roadmap selbst entwerfen wollen, wirkt diese Aussage keineswegs falsch.

  • System-Frameworks waren die Grundlage dafür, idiomatische UIs zu schaffen.
    Win32, AppKit und UIKit kümmerten sich selbst um Details, sodass Entwickler ganz natürlich zu konsistenter UX geführt wurden.
    Im Web fehlt so etwas, deshalb muss alles von Hand implementiert werden, und entsprechend gibt es viele halbfertige UIs.

    • Allerdings trifft der Autor die Inkonsistenz des Webs nicht ganz richtig. Das „Desktop-Zeitalter“ war praktisch das Windows-Zeitalter, und weil Win32 der Standard war, hielten sich alle daran.
      Das Web war von Anfang an dokumentenzentriert und hatte keinen vergleichbaren Standardansatz; erst später entstand mit Dingen wie Bootstrap zeitweise eine Art Standard.
    • HTML und CSS gab es zwar, aber heute wird das mit WebAssembly und Ähnlichem oft umgangen.
      Tatsächlich sollte man für Datumswähler oder Karteneingabe die nativen HTML-Controls verwenden.
      Dann kann der Browser Sicherheit und Komfort auf OS-Ebene bereitstellen, etwa mit Apple Wallet in Safari oder Google Pay auf Android.
    • Entwickler, die an konsistentes Verhalten im Betriebssystem gewöhnt sind, versuchen natürlich, diese Umgebung nachzuahmen.
      Web und Mobile sind jedoch völlig andere kastenförmige Umgebungen, und dadurch ist diese Konsistenz zerbrochen.
      Es gab zum Beispiel die Chance, den Rechtsklick auf dem Desktop mit Long Press auf Mobile zu vereinheitlichen, aber das wurde nie konsequent verfolgt.
    • Das Grundproblem des Webs ist, dass es immer noch im dokumentenzentrierten Paradigma feststeckt.
      Wenn man App-UIs bauen will, muss man sie über eine Dokument-UI stülpen, was zu Konflikten führt.
      Browser haben das etwas abgemildert, aber grundlegend gelöst ist es nicht.
    • Übrigens kann man auch in AppKit die Höhe von Buttons ändern. Es ist nur nicht offensichtlich.

  • Datumswähler sind wirklich ein UX-Albtraum.
    Oft verhindern sie, dass Nutzer ein Datum direkt eingeben, und zwingen sie stattdessen zum Klicken.
    Es würde reichen, Fehleingaben abzufangen, stattdessen wird alles unnötig umständlich gemacht.

    • Wenn man für ein Geburtsdatum durch jahrzehntelange Kalender blättert, spürt man förmlich die Vergänglichkeit des Lebens.
    • Auch die Zeitauswahl auf Mobile ist völlig uneinheitlich. Manchmal springt ein Scrollen von 12:00 auf 11:50, manchmal nicht.
      Analoge Uhren-Selektoren wirken viel intuitiver; schön wäre es, wenn so etwas zum Standard würde.
    • Auch Datumsformate sind ein Problem. Bei 03/04/2026 ist unklar, ob der 3. April oder der 4. März gemeint ist.
      Für internationale Nutzer ist das Format YYYY-MM-DD am sichersten.
    • Websites, die für das Geburtsdatum denselben Datumswähler verwenden wie für zukünftige Termine, sind die schlimmsten.
      Man scrollt 50 Jahre zurück und bekommt dabei nur noch deutlicher sein Alter vor Augen geführt.
    • Jedes Mal beim Eingeben des Geburtsdatums das eigene Alter durchs Scrollen zu spüren, ist fast schon Folter.

  • Der Qualitätsverlust bei UX ist inzwischen massiv, besonders auf Bank-Websites.
    Versteckte Scrollbars, verschwendeter Leerraum, flache Buttons und verwirrende Icons machen vieles deutlich unbequemer als frühere Desktop-UIs.

    • Ich kann wirklich nicht nachvollziehen, warum Scrollbars versteckt werden. Das wirkt wie eine rein ästhetische Entscheidung, nur damit es „schöner“ aussieht.
    • Ich habe das Gefühl, dass Material UI vielen Branchen geschadet hat.
      GCP und Google-Tools sind unnötig komplex geworden und haben mit Dingen wie rahmenlosen Eingabefeldern die UX verschlechtert.
      Immerhin gilt dieser Stil inzwischen zunehmend als veraltet.

  • Eines der Konzepte vom klassischen Mac war, dass Auslassungspunkte (…) am Ende eines Button-Texts bedeuten, dass noch weitere Eingaben nötig sind.
    Ein Button ohne Auslassungspunkte führt die Aktion dagegen sofort aus.

  • Ich stimme der Aussage zu: „Bevorzuge Wörter statt Icons.“
    Die meisten Menschen erkennen Wörter schneller als Icons.

    • Natürlich sind Icons in Ordnung, wenn sie reale Gegenstände darstellen, aber heute gibt es viel zu viele abstrakte, lineare Icons.
      Ohne Textbeschreibung ist es wie Russisches Roulette: Man muss klicken, um herauszufinden, was sie bedeuten.
    • Auch Fälle wie HNs „unvote/undown“ sind verwirrend, weil die Präfixe gleich sind. Man schaut beim Klicken immer wieder noch einmal hin.
    • Wenn Icons klein sind oder ihre Position häufig wechselt, sind Wörter besser; in einer stabilen Umgebung können Icons aber auch schneller sein.

  • Ich habe kürzlich eine neue Technologie namens CSS entdeckt: Damit kann man Layouts deklarativ definieren und hierarchische Styles auf Basis des DOM anwenden.
    Das reduziert Client- und Serverlast, erleichtert das Teilen von Stylesheets und macht benutzerdefinierte Themes einfach.
    Ich würde das gern das „no-framework“-UI-Paradigma nennen.
    Beispielbild

    • Ich habe es ausprobiert und es war ein völliger Albtraum. Man weiß nie, welcher Style wo angewendet wird, und wenn sich die DOM-Struktur ändert, zerfällt das Styling.
      Außerdem ist „minimale Clientlast“ nichts weiter als ein Mythos. In Wirklichkeit ist es langsamer.
    • Vielleicht sollte man diese Idee dem Team des vanilla-js-Frameworks vorschlagen.

  • Gemeinsame Funktionen, die wir verloren haben:
    Undo/Redo, Hilfe (F1), Mouseover-Hinweise, anpassbare Tastenkürzel, Hauptmenü, Dateien/Verzeichnisse, mit ESC schließen, Drag-and-drop usw.
    Funktionen, die einst innovativ waren, sind auf Mobile und im Web inzwischen fast verschwunden.

  • Viele Probleme sind das Ergebnis davon, dass visuelle Designer in die Produktgestaltung gewechselt sind.
    Die Verwirrung über die Rollen in Design-Berufen ist bis heute nicht gelöst, und in der Praxis werden selbst in Projekten, die eigentlich gar keine „Designer“ brauchen, zu viele davon eingesetzt.