Versteckt meine Bedienelemente nicht: Wie verborgene Interface-Controls die Usability beeinträchtigen

• Verborgene Bedienelemente verschlechtern die Usability von Benutzeroberflächen
• Früher waren sichtbare Menüs auf dem Bildschirm ein entscheidender Wendepunkt für deutlich bessere Usability
• In letzter Zeit ist auf Mobilgeräten und diversen anderen Geräten wieder eine Rückkehr zu gedächtnisbasierten Bedienkonzepten zu beobachten
• Die Komplexität des Interface-Designs und ästhetische Aspekte sind die Hauptursachen für die Zunahme verborgener Controls
• Designer müssen nun die Struktur überdenken, damit alle zentralen Funktionen sichtbar sind und von Nutzern erkundet werden können

---

Einleitung: Wo Wissen liegt und wie Interfaces funktionieren

• In den 1960er-Jahren formulierte Douglas Engelbart das Konzept, ob „Wissen in der Welt oder im Kopf“ liegt
• „Knowledge in the world“ bedeutet, dass Bedien-Controls im Interface sichtbar sind und Nutzer sie ohne Auswendiglernen direkt finden und verwenden können
  • Beispiel: eine grafische Oberfläche mit Dropdown-Menüs
• „Knowledge in the head“ bezeichnet eine Umgebung, in der Nutzer sich alle Controls und Befehle merken müssen
  • Beispiel: In der DOS-Eingabeaufforderung kann man ohne Kenntnis von Befehlen (DIR usw.) praktisch nichts tun

Warum versteckte Controls zunehmen und welche Nebenwirkungen sie haben

• Mit steigender Komplexität von Interfaces werden immer mehr Controls visuell verborgen
• Auf den ersten Blick wirkt das zwar aufgeräumter, für Einsteiger wird die Bedienung jedoch deutlich schwieriger
• Mit dem Aufkommen sichtbarer Controls wie früher Dropdown-Menüs stiegen die Verbreitung von Computern und die Produktivität massiv an
• Auf Mobilgeräten und neueren elektronischen Geräten breitet sich jedoch erneut eine Bedienlogik aus, die auf Wissen und Erinnerung basiert
  • Beispiel: Für die Taschenlampe des iPhones, die Anzeige von Benachrichtigungen oder das Starten von Apple Pay muss man ohne passende Hinweise oft verborgene Aktionen oder bestimmte Gesten kennen

Beispiele für versteckte Controls im Alltag

• Auch bei Auto-Funkschlüsseln oder Türgriffen gibt es versteckte Controls, sodass ohne Kenntnis der Bedienung sogar der grundlegende Zugang erschwert sein kann
  • Beispiel: ein innen liegender Schlüssel, ein verstecktes Schlüsselloch oder bestimmte Tastensequenzen
• Auch Fahrzeug-Navigationssysteme (wie Apple Maps auf CarPlay) neigen dazu, essenzielle Controls zu verbergen, um mehr Karte anzuzeigen; bestimmte Funktionen sind dann nur über das Wissen um eine bestimmte Berührungsfläche nutzbar
• Zeitbasierte Controls funktionieren ebenfalls als versteckte Form von Bedienung
  • Beispiel: Der Power-Button eines Computers führt nur bei langem Drücken ein reguläres Ausschalten aus; bei elektronischen Türschlössern erfordern das Verriegeln oder andere Funktionen oft eine separate Taste oder langes Drücken

Allgemeine Probleme durch versteckte Controls und ihre Auswirkungen auf Profis

• Selbst wenn die Lautstärke auf 0 steht, geben Apps mitunter trotzdem Töne aus; solche „versteckten Einstellungen“ überschreiben direkte Nutzerbefehle
• Auch fortgeschrittene Nutzer erleben bei befehlsorientierten Interfaces (z. B. R oder DOS-Fenster) eine starke Abhängigkeit von „Knowledge in the head“
• Insgesamt zeigt sich eine Tendenz zur Rückkehr zu primitiveren Interfaces

Warum versteckte Controls zunehmen

• Es gibt zu viele Funktionen, um alles auf dem Bildschirm anzuzeigen, was die Sichtbarkeit senkt
• Wechselwirkungen zwischen Systemmodi, zunehmende Komplexität sowie ästhetische Vorlieben oder Implementierungsbequemlichkeit auf Seiten der Designer führen häufig zur Verbergung von Controls
• Tatsächlich stehen oft Designziele (etwa ästhetische Wirkung) über der Rücksicht auf Nutzer

Erfolgreiche Beispiele und der Unterschied zu mission-kritischen Systemen

• Einige Systeme wie die General-Motors-Navigation zeigen alle nötigen Controls dauerhaft gut sichtbar an, sodass auch Einsteiger sich leicht zurechtfinden
  • Beispiel: Zoom per physischem Drehregler im Buick LaCrosse
• In mission-kritischen Systemen (Flugzeuge, Fabriken usw.) wird fast immer mit dauerhaft sichtbaren Controls gearbeitet
  • Niemand würde das Risiko eingehen, dass schnelle Bedienung durch versteckte Controls behindert wird

Die Verteidigung versteckter Interfaces und ihre Grenzen

• Versteckte Controls sind kein bloßes Generationenthema, sondern ein reales Usability-Problem
• Manche preisen das Entdecken versteckter Funktionen als Vorteil an, tatsächlich sinkt die Zugänglichkeit jedoch klar
• Aus Nutzersicht gilt: Ein Control, das man nicht finden kann, existiert praktisch nicht

Ubiquitous Computing und die Automatisierung/Transparenz von Controls

• Mark Weiser und Donald Norman sagten eine Zukunft voraus, in der Technik transparent in den Hintergrund tritt
  • Beispiel: Die Motorsteuerung im Auto wird vollständig automatisch im Hintergrund angepasst, ohne dass Nutzer eingreifen müssen
• Wenn Controls durch Automatisierung vollständig verborgen werden, ist deren Notwendigkeit und Kontext klar
  • Wo jedoch Nutzerinteraktion erforderlich ist, braucht es zwingend explizite Controls

Fazit und Orientierung für Interface-Designer

• Interface-Designer sollten den Einsatz versteckter Controls vermeiden und Funktionen möglichst in „Knowledge in the world“ überführen
• Discoverability von Controls bleibt ein zentrales Designprinzip
• Sinkende Auffindbarkeit in modernen Interfaces ist letztlich ein Rückschritt in die Frühzeit der Computer

Literaturhinweise

• Zentrale Literatur wie Engelbart, D.C. (1962) u. a.
• Verweise auf Apple Macintosh, The Psychology of Everyday Things, The Invisible Computer und weitere einschlägige Bücher und Arbeiten

Informationen zum Autor

• Philip Kortum: Professor am Department of Psychological Sciences der Rice University; forscht zur Entwicklung nutzerzentrierter Systeme in Bereichen wie Usability und Vertrauensbewertung, globale Gesundheit und mobile Systeme

[GN⁺]

Hacker-News-Kommentare

• Geteilte Nutzererfahrungen über Unannehmlichkeiten durch Designs, die in letzter Zeit Scrollbars verbergen; zudem der Hinweis, dass einige im Artikel erwähnte intuitive physische Knöpfe in der Praxis durch Kosten- und Nutzbarkeitsgrenzen eingeschränkt sind; Verwirrung darüber, dass die Beschriftung von Toggle-Switches teils nicht den aktuellen Zustand, sondern den Zustand nach dem Umschalten bezeichnet
  • Auch echte Toggle-Switches werden als mehrdeutig und daher unerquicklich empfunden; Checkboxen oder gedrückte Buttons seien deutlich klarer, schade sei nur, dass sie dem Modernisierungstrend geopfert wurden
  • Erinnerung an einen verwirrenden Sofortvalidierungs-Toggle an einem österreichischen Fahrkartenautomaten; auch Scrollbars seien so dünn geworden, dass man fast schon FPS-Spiel-Skills brauche; manchmal seien horizontale Scrollbars sogar praktischer; Seitenhieb auf Firefox und den CSS-Standard
  • Hinweis, dass sich unter macOS Scrollbars über die Systemeinstellungen oder per Terminal-Befehl dauerhaft anzeigen lassen
  • Wenn ein Toggle eine Aktion bezeichnet, sollte zwingend ein Verb wie "TURN ON" verwendet werden; wenn er einen Zustand zeigt, dann klar in einer Form wie "IS ON"; bis auf wenige kontextabhängige Ausnahmefälle würden Verben die Mehrdeutigkeit fast immer beseitigen
  • Bitte auch Unterstützung für PgUp und PgDn
• Jemand fährt einen älteren Toyota, bei dem alle Bedienelemente stets sichtbar, klar beschriftet und per Fingerspitzen unterscheidbar sind; das sei leicht zu replizieren und erfordere nur minimales Engineering, doch die meisten heutigen Autohersteller bekämen nicht einmal das hin und hätten schlicht nicht die nötige Kompetenz
  • Teilweise Zustimmung, aber die Behauptung, alle Controls müssten sichtbar sein, unterschätze Designer; in der Praxis seien nur während der Fahrt zwingend nötige Bedienelemente exponiert, andere seien klein, komplex oder verborgen; Hebel zur Sitzhöhenverstellung oder zum Öffnen der Motorhaube seien versteckt, aber dennoch zugänglich; ein Designprozess, der solche Details berücksichtigt, sei weder simpel noch trivial, und gerade die Bagatellisierung solcher Fragen trage zum heutigen schlechten UX bei
  • Aus dieser Sicht gehe es nicht um Können, sondern um Kosten: Heutzutage sei ein Touchscreen billiger und einfacher zu produzieren als viele einzelne Buttons und Knöpfe samt Montage
  • Geteilte Erfahrung, dass US-Autohersteller massenhaft Einstellungsangebote für Systementwickler verschickten, während es in der Hacker-News-Community oft hieß: Wer seine psychische Gesundheit bewahren wolle, solle diese Jobs meiden
  • Auch aus persönlicher Sicht die Erklärung, dass unterschiedlich gestaltete mechanische Teile wie Knöpfe spezielle Formen und damit höhere Fertigungskosten erfordern; auf einem Bildschirm unterzubringen sei aus Kostensicht deutlich effizienter
• Es ist nachvollziehbar, UI-Elemente aus Gründen der Flächeneffizienz zu verbergen, aber unverständlich, wenn dafür genutzter Raum leer bleibt; in IntelliJ sind über dem Projektbaum Icons versteckt und erscheinen erst beim Mouseover, und es wird bezweifelt, dass das wirklich nötig war
  • In einer Zeit, in der Smartphone-, Desktop- und Laptop-Bildschirme größer sind als je zuvor, wird die Rechtfertigung hinterfragt, UI-Elemente auszublenden; Rückblick auf den kleinen Schwarz-Weiß-Bildschirm des Macintosh von 1984, bei dem selbst auf Kosten des verfügbaren Inhaltsraums Buttons zugunsten von Klarheit und Sichtbarkeit platziert wurden
  • Manche beklagen, visuelles "Rauschen" schade der Konzentration, andere möchten wie bei einem Armaturenbrett alle Bedienelemente und Anzeigen jederzeit sichtbar haben; Standardkonfigurationen von IDEs seien daher ein Ausbalancieren extremer Vorlieben und faktisch ein Kompromiss; manche Tools böten dafür Detailoptionen wie einen "no distractions mode"
  • Auch im Windows-Build von IntelliJ ist das Menü hinter einem Hamburger-Icon versteckt, obwohl viel Leerraum bleibt; zum Glück lässt sich das in den Einstellungen rückgängig machen, aber der Standardwert ist schwer nachvollziehbar
  • Selbst wenn man weiß, dass ein Button existiert und wie er erscheint, schaut man manchmal trotzdem nur leer auf den Bildschirm, weil man vergessen hat, wo er war
  • Manche Apps verbergen zusätzliche Buttons im Gegenteil nicht; eher wünscht man sich dort eine Möglichkeit, sie auszublenden, erwähnt wird Google Maps
• Kritisiert wird, dass bei Smart Keys fürs Auto der eigentliche Schlüssel versteckt ist und man teils sogar den Türgriff zerlegen muss, um an das Schlüsselloch zu kommen; wichtige Controls zu verstecken sei extrem nutzerunfreundliches Engineering
  • Ähnliche Erfahrung mit einem Mietwagen: Der Funkschlüssel war defekt und das gesamte Gepäck im Auto eingeschlossen; dass es einen physischen Schlüssel gab, war bekannt, und das Schlüsselloch ließ sich schließlich an den Kratzspuren rund um den Türgriff erkennen, die frühere Nutzer beim Suchen hinterlassen hatten
  • Dagegen die Position, dass Nutzer solche Dinge grundsätzlich wissen sollten und sich Informationen etwa über Google beschaffen könnten; als Beispiel wird genannt, dass man bei einem neuen Auto sofort die Backup-Optionen und deren Funktionsweise überprüft habe; betont wird, wie wichtig ein Grundverständnis der eigenen Produkte ist
• Einer der Gründe für den Wechsel vom iPhone zu Android sei gewesen, dass mit dem Wegfall des Home-Buttons die Erklärung und Nutzung für ältere Familienmitglieder schwieriger geworden sei; bei neuen Pixel-Smartphones werde zuerst die 3-Button-Navigation aktiviert, allerdings gingen moderne Apps oft nur noch von einer Bottom-Navigation-Bar aus, sodass Inhalte unter der 3-Button-Leiste verdeckt würden
  • Zentrale UI-Elemente sollten zwingend sichtbar sein; auch Apple verletze dieses Prinzip mitunter, widersetze sich dem aber meist; das Entfernen des Home-Buttons wird eher als Veränderung der Interaktion denn als Verbergen eines UI-Elements interpretiert; über Intuitivität und Qualität lasse sich streiten, doch nach der Gewöhnung gebe es kaum Reibung; zudem Hinweis auf eine iOS-Accessibility-Funktion mit einem kleinen frei verschiebbaren runden Shortcut auf dem Bildschirm, inklusive Textlabel
  • Ein ähnliches Phänomen seien Menüeinträge in normaler Software, die kommentarlos verschwinden; als Beispiel wird genannt, dass in MS Word das Icon zum Speichern schreibgeschützter Dateien ganz verschwunden sei; besser wäre es, den Eintrag deaktiviert stehen zu lassen und beim Speichern den Grund samt Lösungsvorschlag anzuzeigen
  • Aus Sicht eines langjährigen Android-Nutzers ist es jedes Mal frustrierend, wenn man sich ein iPhone leiht und auf unklare oder fehlende Interaktionen stößt; da auch die Kameraqualität von Pixel und Samsung stark geworden sei, gebe es keinen Grund, ins Apple-Ökosystem zu wechseln
• Die Meinung, dass der Artikel nicht ausreichend darauf eingeht, dass verschwindende UI nicht Unfall oder Versehen, sondern ein Mittel zur Nutzerbindung ist; bei Software, die einen gesättigten Punkt erreicht habe, werde die UI absichtlich weniger intuitiv verändert, um Bestandsnutzer am Weggang zu hindern; Geräte würden nicht mehr nur "benutzt", sondern verinnerlicht, wodurch Wechselbarrieren entstünden; der Lernaufwand für eine UI erzeuge Angst vor dem Umstieg auf neue Produkte, weshalb die meisten großen Softwareunternehmen diesen Weg gingen
  • Als Hypothese mag das punktuell stimmen, tatsächlich gebe es aber auch viel Gegenreaktion gegen "komplexe und überfüllte Interfaces"; mit dem Minimalismus-Trend und Communities wie /r/unixporn hätten viele Nutzer selbst eine starke Tendenz, Controls zu verstecken; auch bei GNOME sei die minimalistische Oberfläche inzwischen Mainstream; viele Nutzer könnten Funktionen gezielt bei Bedarf finden, deshalb sei das eher eine bewusste Wahl
  • Diese Methode sei ein zweischneidiges Schwert, weil sie den Einstieg neuer Nutzer erschwere; geteilt wird die Erfahrung, Android als vertrauter zu empfinden, weil man Apples auf einen einzigen Button konzentrierte Interfaces nicht möge; weitere Vorbehalte gegenüber Apple bestünden ohnehin aus anderen Gründen
  • Auch gemeinnützige OSS-Projekte folgten solchen Trends scheinbar unkritisch, etwa die wiederkehrenden Designänderungen in Firefox oder die Entwicklung bei GNOME
• Wenn Designer vom "Künstlertyp" die UI-Entscheidungen dominieren, fixieren sie sich auf Sauberkeit und ignorieren Affordance und Lernmöglichkeiten; als Gegenbeispiel wird ein Flugzeugcockpit genannt, das für Laien überwältigend wirkt, für Fachleute aber vollständig beschriftet ist
  • Dem wird entgegnet, dass selbst ein gewöhnlicher Wasserhahn im Haushalt keine Richtungslabels braucht; ein Flugzeugcockpit sei für Anfänger geradezu überwältigend; Interface-Designer wüssten sehr wohl, was intuitiv ist, und könnten komplexe Funktionen gut in einfache Formfaktoren verdichten; zu glauben, Menschen ohne Designausbildung erzielten automatisch bessere Resultate, sei bloß arrogant und respektlos; dass viele Nutzer moderne Smartphones ohne Schulung kompetent bedienen, sei tatsächlich eine enorme Leistung
• Hacker-News-bezogener Desktop-Software-Rant und Frage zum aktuellen Zustand
• Eines der eigenen UI-Designprinzipien ist, dass Tastaturkürzel und Kontextmenüs immer über klar sichtbare Buttons oder Menüs erreichbar sein müssen; das mag etwas altmodisch sein, wird aber als wichtig angesehen; die vier Ecken des Bildschirms seien im UI besonders wertvoll, weil sich die Maus schnell dorthin bewegen lasse; das zentrierte Startmenü in Windows 11 wird als Beispiel für nutzerunfreundliches Design genannt, möglicherweise aus einer Touch-first-Logik heraus statt aus Desktop-Perspektive
• Es wird betont, dass sinkende Zugänglichkeit und geringere Intuitivität von UIs Menschen mit Behinderungen und ältere Personen besonders stark treffen; Touch und Gesten seien zwar dominant geworden, doch frühe mobile UIs seien paradoxerweise oft zugänglicher gewesen; die eigentliche Ursache sei der übertriebene Trend zu Minimalismus und Flat Design; palm, compaq pilot, iPod und frühe iPhone-UIs werden positiv erinnert, während die Entwicklung danach als Rückschritt gesehen wird
  • Demgegenüber steht die Sicht, dass es schöner und angenehmer sei, wenn wie etwa beim Lesen von HN-Kommentaren auf dem Smartphone viele UI-Controls verborgen bleiben und man sich stärker auf den eigentlichen Inhalt konzentrieren kann; zu Palm-Pilot-Zeiten hätten Buttons und Controls oft die Hälfte des Bildschirms eingenommen und damit den Inhaltsbereich verkleinert; versteckte Controls seien nicht per se schlecht und nach dem Erlernen für Power-User sogar sehr mächtig; dass Nutzer eine UI bis zu einem gewissen Grad erlernen müssen, sei unvermeidlich, und bei leistungsfähigen Tools wie dem eigenen Code-Editor oder git gebe es stets einen Trade-off zwischen Einfachheit und Stärke; problematisch sei heute eher, dass zu viele Apps ihre Controls individuell anpassen und dadurch die Übertragbarkeit von UI-Wissen leidet; ideal sei eher eine Struktur wie bei der Palm-Pilot-Plattform, bei der man ein Bedienmuster einmal lernt und dann in allen Apps gleich anwenden kann