2 Punkte von GN⁺ 2023-10-14 | 1 Kommentare | Auf WhatsApp teilen
  • Scrollbars werden zunehmend kleiner oder ausgeblendet; das führt zu echten Usability-Problemen, nicht nur für Nutzer, die Scrollrad oder Touch-Gesten schwer verwenden können, sondern auch für Menschen, die in einem Dokument schnell die Position wechseln möchten
  • Nutzer mit eingeschränkter Feinmotorik oder mit Zeigegeräten wie Eye-Trackern, deren Genauigkeit begrenzt ist, treffen eine 8 Pixel breite Scrollbar nur schwer; auch Nutzer mit Sprachsteuerung möchten statt wiederholtem Scrollen oft direkt auf die gewünschte Position klicken
  • In GTK, Qt, Firefox, Chrome und Electron lassen sich Breite und Anzeigeverhalten von Scrollbars zwar teilweise anpassen, doch meist nur über für normale Nutzer schwer zugängliche Wege wie CSS-Anpassungen, gsettings, about:config, Neu-Kompilieren von Themes oder app-spezifische Einstellungen
  • Früher gab es Scroll-Buttons, die bei gedrückter Taste schrittweise weiterbewegten, doch sie sind still verschwunden; Pfeiltasten ersetzen manches, verhalten sich aber je nach Fokuszustand unterschiedlich
  • UIs wie eine Dokument-Minimap, bei der man Inhalte sieht und über eine große Klickfläche navigieren kann, können auch für Eye-Tracker- und Tablet-Stift-Nutzer ein nützlicher alternativer Navigationsansatz sein

Scrollbars werden kleiner und verschwinden

  • Die Scrollbar ist ein grundlegendes UI-Element, mit dem man per Klicken und Ziehen die aktuelle Position innerhalb eines scrollbaren Bereichs verändert
  • In letzter Zeit sind Scrollbars so klein geworden, dass sie sich kaum noch per Screenshot zeigen lassen, und der Trend zu noch kleineren oder ausgeblendeten Scrollbars schadet der Usability
  • Der Ansatz „Man kann doch einfach das Scrollrad benutzen“ setzt voraus, dass alle Nutzer ein Scrollrad oder Wischgesten auf dem Touchscreen verwenden können
  • Selbst Nutzer, die das Scrollrad gut nutzen, möchten manchmal schnell zu einer bestimmten Stelle springen

Auswirkungen auf die Barrierefreiheit

  • Nutzer mit Schwierigkeiten bei der Feinmotorik können schmale Scrollbars nur schwer präzise greifen
  • Zeigegeräte wie Eye-Tracker sind beeindruckend, reichen aber nicht aus, um eine 8 Pixel breite Scrollbar zuverlässig zu treffen
  • Nutzer, die Computer per Stimme oder Geräusch steuern, verwenden vielleicht Werkzeuge wie Talon Voice, bevorzugen aber unter Umständen statt wiederholtem scroll down oder Auto-Scroll lieber das direkte Anvisieren und Anklicken der gewünschten Position in der Scrollbar
  • Schon 2015 wurde das Problem der GTK3-Scrollbar-Breite diskutiert; schmale Scrollbars belasten nichttechnische Nutzer ebenso wie Menschen mit Problemen bei Handbedienung oder Sehvermögen

Wie Scrollbars schwerer benutzbar wurden

  • In manchen Fällen bleibt die Scrollbar-Breite in Pixeln gleich, doch mit höherer Monitorauflösung wird das tatsächliche Zielobjekt kleiner
  • In anderen Fällen wird die Scrollbar selbst tatsächlich kleiner
  • Erwähnt wird auch das Beispiel der extrem schmalen Scrollbars, die Ubuntu früher einmal ausprobierte
  • Während Scrollbars schrumpften, verschwanden auch Scroll-Buttons, mit denen man bei gedrückter Taste schrittweise weiterkam
    • Pfeiltasten ersetzen einen Teil dieser Funktion, hängen aber davon ab, welches Element gerade den Fokus hat
    • Buttons ließen sich unabhängig vom Fokuszustand verwenden
  • Insgesamt sind Scrollbars weniger brauchbar geworden, und passende Nutzereinstellungen fehlen entweder ganz oder sind tief in Technik-Stacks versteckt, die normale Nutzer kaum finden

Hürden bei GTK-Einstellungen

  • In GTK2 konnte man die Scrollbar-Breite direkt in gtkrc ändern, und es gab sogar GUI-Programme dafür
  • In GTK3 muss man dies über CSS anpassen; ohne Verständnis des Themes fehlt es an nutzerfreundlichen Einstellmöglichkeiten
  • In einem Reddit-Thread wird ein Skript vorgestellt, das in gtk.css für GTK3 und GTK4 slider { min-width: ...; min-height: ...; } ergänzt und zusätzlich Flatpak-Overrides sowie Overlay-Scrolling-Einstellungen behandelt
  • Flatpak-Apps benötigen separate Overrides, sodass das System-Theme möglicherweise nicht unverändert übernommen wird
  • GTK verwendet standardmäßig auch ein Verhalten, bei dem die Scrollbar zunächst verborgen ist und erst sichtbar wird, wenn die Maus an die betreffende Stelle bewegt wird
    • In GTK3 lässt sich das mit folgendem Befehl dauerhaft sichtbar machen gsettings set org.gnome.desktop.interface overlay-scrolling false
    • Auch im Dconf Editor ist die Option zu finden, allerdings nur, wenn man die genaue Stelle kennt
  • Für GTK4 wird ein GNOME-Bugzilla-Thread zitiert, laut dem sich diese Einstellung nicht global festlegen lässt
    • In der Diskussion wird kritisiert, dass man für jede App einzeln eine non-overlay-scrollbar-Option anfordern muss

Hürden bei Qt-Einstellungen

  • Die Breite von Qt-Scrollbars wird durch das verwendete Qt-Widget-Style-Plugin bestimmt
  • /u/cfeck_kde erklärt in einer Antwort auf r/kde, nach seinem Wissen erlaube nur der Stil Skulpture eine Größeneinstellung, während andere Stile wie Breeze Änderungen am C++-Quellcode und anschließendes Neukompilieren erfordern
  • Qt-Style-Plugins sind echter Code und erlauben daher eine mächtige Kontrolle, aber man muss erst ein Plugin finden, das die gewünschten Einstellungen anbietet
  • Bei Kvantum ist eine Einstellung für die Scrollbar-Breite schwer zu finden, doch die Funktion zum Verschwindenlassen der Scrollbar namens „Transient scrollbars“ lässt sich deaktivieren
  • Skulpture könnte einen Versuch wert sein, allerdings wurde kein Weg bestätigt, es ohne KDE Plasma per GUI zu konfigurieren
  • Wenn man sich auf eine einzige Theme-Engine verlassen muss, bleibt die Sorge, ob sie während der fortlaufenden Qt-Entwicklung gepflegt wird

Firefox, Chrome und Electron

  • Auch Firefox verwendet sehr kleine Scrollbars, doch sie lassen sich derzeit in about:config anpassen
    • about:config in die Adressleiste eingeben
    • widget.non-native-theme.scrollbar.size.override auf die gewünschte Zahl setzen
    • widget.non-native-theme.scrollbar.style ändern, um das Aussehen anzupassen
    • Der Wert 4 stellt eine dicke rechteckige Form ein
    • Im normalen Einstellungsfenster about:preferences lässt sich „Always show scrollbars“ aktivieren
  • Als Beispiel kann man die Firefox-Scrollbar-Größe auf 50 setzen; auch wenn man sie nicht wirklich so groß verwenden möchte, ist es ein Vorteil, dass es überhaupt möglich ist
  • Athena Lilith Martins Beitrag zu zusätzlichen Firefox-Scrollbar-Einstellungen behandelt weitere Verbesserungen wie das Deaktivieren von CSS-Overrides durch Webseiten
  • Von Chrome werden kaum nützliche Einstellungen erwartet
  • Auch bei Electron-Apps sind Einstellungen schwierig; ob sich das Problem per injiziertem Custom-CSS beheben lässt, bleibt offen, und eine sichere Lösung wird nicht genannt

Ein besserer Navigationsansatz: die Minimap

  • Eine Minimap zeigt Inhalte an, erlaubt das Anklicken von Inhalten und springt zur angeklickten Position im Inhalt
  • Das Klickziel ist sehr groß und dadurch auch für Eye-Tracker-Nutzer und Tablet-Stift-Nutzer nützlich
  • Allgemeine „moderne Designprinzipien“ wirken sich nachteilig auf Scrollbars und auf Menschen mit unterschiedlichen Arten der Computernutzung aus

1 Kommentare

 
GN⁺ 2023-10-14
Meinungen auf Hacker News
  • Es ist nicht nur ein Problem der Scrollbars. Durch das Entfernen von Fensterrahmen lassen sich Fenster mit ähnlich farbigem Hintergrund kaum noch unterscheiden, und es ist fast unmöglich geworden, den Rand zu greifen, um die Fenstergröße zu ändern.
    Die Titelleiste ist vollgestopft mit Suchfeldern und unnötigen Buttons, sodass es kaum noch eine Stelle gibt, an der man sie greifen kann, um ein Fenster zu verschieben; auch das Wechseln per Tab zwischen Textfeldern funktioniert nicht wie erwartet oder gar nicht.
    Tooltips stören und überladen das Interface, verdecken oft den Inhalt, den man eigentlich sehen will, und sind zu 95 % redundant oder nutzlos.
    In den letzten zehn Jahren hat Cargo-Cult-UI/UX jahrzehntelang gewachsene Usability-Prinzipien über Bord geworfen und Ergebnisse hervorgebracht, die zwar gut aussehen, für viele Menschen aber nicht richtig funktionieren.
    Apps wie Postman, Teams, die meisten aktuellen Microsoft-Apps, Chrome und Insomnia sollten als Beispiele dafür dienen, wie man UI für Desktop-Software nicht baut.
    Die größere Sünde ist: All das wäre kein Problem, wenn solche Elemente auf Ebene des Fenstersystems konfigurierbar wären und App-Entwickler sie nicht überschreiben könnten. Stattdessen bewegen sich Windows und Gnome/GTK aber eher in die Richtung, bestehende Optionen zu entfernen.

    • Ich halte die Bezeichnung „Idioten“ für passend. Ich will Leute, die arbeiten, nicht grundlos beschimpfen, aber mittlerweile muss man wie ein Trottel überall herumklicken, um herauszufinden, ob etwas die Titelleiste oder ein Button ist, wenn man ein Fenster verschieben will.
      Jedes Mal, wenn ich „New Teams“ starte, werde ich gefragt, ob ich zu Old Teams zurückkehren will; und wenn ich im Datei-Explorer ein PDF mit New Teams öffne, ist auch nicht klar, wie ich das PDF schließen kann, ohne den Speicherort im Dateisystem zu verlieren.
      Außerdem ist alles furchtbar langsam. Ziemlich viele Leute, die bei Microsoft/Apple/Google arbeiten, machen ihren Job schlecht, und sie sollten sich dafür schämen.
    • Ich habe das Gefühl, Windows XP war der Höhepunkt einer benutzbaren Oberfläche, und man hätte dort aufhören sollen. Natürlich kann es auch einfach sein, dass ich alt werde und den Kindern sage, sie sollen von meinem Rasen runter.
      Für Windows gilt das aus meiner Sicht jedenfalls definitiv; alle späteren Windows-Versionen haben die User Experience verschlechtert.
    • Ich finde, Beleidigungen sind nicht nötig. Einer der Gründe, warum ich HN mag, ist, dass es einer der wenigen Orte ist, an denen höfliche Diskussion Vorrang vor dem hasserfüllten Ton anderer Plattformen hat.
      Ich stimme grundsätzlich zu, dass Usability wichtiger ist als Ästhetik, aber ich weiß nicht, wer genau mit „Cargo-Cult-UI/UX-Idioten“ gemeint sein soll.
      Aus meiner Sicht nach über 20 Jahren als UX/UI-Leiter waren die Hauptverursacher schlechter Usability oft eher Business-Leader und Marketer als Designer.
      Natürlich gibt es Designer, die Form wichtiger finden als Funktion und kleine Scrollbars durchdrücken, aber wenn man ihnen das Problem erklärt, geben sie oft nach und entwickeln ein nutzbares Design.
      C-Level, Marketingleiter und Manager sind gefährlicher, weil sie wenig Ahnung von UI haben, aber starke Meinungen vertreten und Forderungen stellen wie „die Scrollbar auf dieser Website ist gut“ oder „das Design sieht nicht modern aus“.
      Es ist extrem schmerzhaft, für Usability und Barrierefreiheit zu kämpfen, und manche Hierarchieebenen sollten professioneller handeln und Experten vertrauen. Dass Designer Usability zuerst denken sollten, stimmt allerdings auch.
    • Das größere Problem ist, dass es inzwischen kaum noch Versuche gibt, Informationen zu strukturieren.
      Einstellungsmenüs sind ein Albtraum aus Listen über Listen, jede App hat eine völlig zufällige Menüstruktur, und oft wird man selbst für lokal konfigurierbare Dinge auf externe Websites verlinkt.
      Es ist wirklich schwer, die Absicht der Designer zu verstehen, und man kann nicht erkennen, ob man eine Einstellung nur nicht gefunden hat oder ob sie von Anfang an so gebaut wurde, dass sie in diesem Menü nicht vorhanden ist.
      Ich musste viel zu oft googeln, um Standardeinstellungen zu ändern, und selbst bei Spielen, bei denen die Experience die Hälfte des Produktwerts ausmacht, ist es genauso.
      Im Einstellungsmenü von CS2 sehen die Text-Buttons oben wie Tabs aus, scrollen aber in Wirklichkeit nur zu beliebigen Punkten in einer langen Einstellungsliste; dadurch ist es schwer, die Bedeutung der einzelnen Buttons im Kopf voneinander zu trennen.
      Die Bedeutungen von Konzepten sind nicht miteinander verknüpft und auch nicht strukturiert, wodurch das Erkunden von Computing unnötig schwer geworden ist.
      Ich vermisse die UI von Macromedia Flash; ich habe sie nicht viel benutzt, aber sie war wirklich einfach und leicht zu bedienen.
      Einer der großen Gründe, warum ich nach Privatsphäre und selbstgebauten Lösungen suche, ist auch, dass ich dieser heutigen Verschmutzung von Erfahrung und Wissen entkommen will.
    • Genau dafür gab es die Größenänderungsbox. Tatsächlich handelt es sich um einen ziehbaren Rand ohne sichtbare Fläche; damit wurde einem 1-Pixel-Element übermäßig viel Verantwortung aufgebürdet und ein Konflikt erzeugt.
      Die frühere Größenänderungsbox war ein separater Griff speziell zum Ändern der Fenstergröße, ganz unten an der vertikalen Scrollbar, direkt unter dem Pfeil-nach-unten-Button.
      Weil sie sich direkt neben den Scroll-Buttons befand, mit denen man anfangs nicht sichtbare Inhalte aufrufen konnte, war sie ein natürlicher Start- und Bezugspunkt für die Interaktion mit dem Viewport.
      Ironischerweise ist sie in App-UIs größtenteils verschwunden, aber Webbrowser rendern sie bei Elementen wie textarea, bei denen Scrollbar und Resize aktiviert sind, teilweise immer noch. Nur gibt es in den meisten UIs die zugehörigen Scroll-Buttons nicht mehr.
  • Ich hatte kürzlich eine lustige Erkenntnis: Nicht meine Sehkraft ist schlechter geworden, sondern die UI ist schlechter geworden.
    Lächerlich kontrastarme, winzige Scrollbars sind für niemanden barrierefrei.
    Ich nutze KDE seit Kurzem mit dem Oxygen-Theme und freue mich, dass es sich ohne Augenbelastung gut verwenden lässt.
    Solche Scrollbars sind ein erbärmliches Ding ohne jede Möglichkeit zur Anpassung, und wenn man auf gesperrte Apps ein Theme anwenden will, braucht man Glück.
    Es ist allzu offensichtlich, dass UI-Designer sich nicht um die Bedürfnisse der Nutzer kümmern, und die FOSS-Welt ist da keine Ausnahme.
    Es ist traurig, dass wir von einer Zeit mit gut aussehender, funktionaler, barrierefreier und schneller Software zu gesperrtem, nicht thematisierbarem Electron-Müll zurückgefallen sind.
    Wenn UIs genug Kontrast und Lesbarkeit hätten, bräuchte es auch keinen „Dark Mode“.

    • Ich nutze Dark Mode nicht wegen des Kontrasts, sondern weil der Light Mode vieler Software einfach reinweiß ist. Bildschirme sind immer heller und leistungsfähiger geworden.
      Wenn man Software ohne dunklen Modus verwendet, ist sie oft so hell, dass die Wand in der Nähe wirkt, als hätte man eine Taschenlampe eingeschaltet.
      Dreht man deshalb die Bildschirmhelligkeit herunter, geraten Farben und Kontrast durcheinander, und man sieht trotzdem nichts.
      Ich vermisse die grauen Oberflächen aus der Win-9x-Ära; hübsch waren sie nicht, aber man konnte sie tatsächlich sehen.
    • Kontrast ist auch ein Faktor, aber der Flat-UI-Trend hat mittlere und helle Grautöne verdrängt und stattdessen reines Weiß und Fast-Weiß durchgesetzt, wodurch der Light Mode viel blendender wirkt als früher.
      Es ist überhaupt nicht überraschend, dass die Leute Dark Mode verlangten, nachdem blendende Flat-UIs dominiert hatten.
    • Ich wünschte, es gäbe in der digitalen Welt mehr analoge Steuerung. Statt 10-stufiger Hoch-/Runter-Tasten hätte ich lieber Drehregler.
      Digitale manuelle Steuerungen, bei denen man leicht ein Menü verlässt und beim Zurückgehen plötzlich etwas ganz anderes verstellt, sind zu digital und umständlich geworden.
      Früher konnte man Kontrast und Helligkeit eines Displays, die Lautstärke eines Verstärkers, analoge Fernseher, Thermostate, Autoradios usw. leicht einstellen.
      Noch gibt es keinen Trend, viele analoge Bedienelemente wieder einzuführen, aber letztlich ist unsere Welt analog. Eingaben sind analog, etwa Sprache oder Muskelbewegungen, und Ausgaben sind ebenfalls analog, etwa Licht und Vibrationen, die unsere Sinne erreichen.
      Ich weiß nicht, warum Steuerung nicht analoger ist; vermutlich ist es eine Kostenfrage.
      Ein Display oder Notebook mit analogen Reglern würde ich wohl sofort kaufen. Selbst wenn es praktisch ein Drehregler mit 16 Millionen Stufen wäre, reicht es, solange die Reaktion unmittelbar ist und er sich wie ein echter variabler Widerstand anfühlt.
      Es wäre schön, einen Drehknopf zu haben, mit dem man je nach Situation Intensität schnell ändern oder Optionen durchlaufen kann, um sie leichter lesbar und hörbar zu machen.
      90 % dessen, was man heute tut, passiert im Browser; daher wäre es schön, wenn der Browser eine Accessibility API bereitstellte, sodass man ihn per Drehknopf steuern kann, ob über Bluetooth oder was auch immer. Im Grunde eine verbesserte Version des Scrollrads.
    • Besonders bedauerlich ist die neue „don’t theme my app“-Strömung. Das Problem mit CSS-Stylesheets in GTK sollte man lösen, indem man CSS durch eine bessere Styling-Technik ersetzt, nicht indem man alles wegwirft und Nutzern verbietet, ihr eigenes Theme zu verwenden.
    • Ich denke, die Nutzbarkeit erreichte vor etwa 20 Jahren in der Windows-2000-Ära ihren Höhepunkt. Die Screenshots im Artikel sehen tatsächlich nach frühem OS X 10.x aus dieser Zeit aus, vermutlich etwa 10.3.
  • Ich stoße häufig auf Websites mit scrollbaren Popovers oder seltsamen internen Frames; weil die Scrollbar des kleinen internen Frames verborgen ist, kann man nicht erkennen, ob es noch mehr Inhalte gibt, und denkt, die Website sei komplett kaputt.
    Das macht mich wirklich wütend, und ich mache iOS und macOS dafür verantwortlich, diesen Wahnsinn gefördert und populär gemacht zu haben. Indirekt verantwortlich ist auch der „Flat“-UI-Trend, der es schwer gemacht hat zu erraten, was was ist.
    UI ist Kommunikation, und UI-Designer haben offenbar beschlossen, dass Nuscheln cool ist.

    • Im ursprünglichen iPhone-Kontext ergibt es in gewissem Maß Sinn, die Scrollbar auszublenden, wenn gerade nicht gescrollt wird. Der Bildschirm ist 3,5 Zoll groß, und wenn man Inhalte auf Desktop-Niveau anzeigen will, gibt es nicht viel Platz für eine Scrollbar; außerdem werden die meisten nicht mit der Scrollbar selbst interagieren.
      Bei Desktop-Betriebssystemen dagegen sind selbst die kleinsten verwendeten Bildschirme deutlich größer, daher gibt es wenig gute Gründe, Scrollbars zu verstecken.
    • Auf die Gefahr hin, diesen Beschwerde-Thread in eine noch hitzigere Richtung zu entführen: Vielleicht ahmt man heutzutage Film und Fernsehen nach.
      Selbst wenn die Kinder ruhig sind, schlafen oder in der Schule sind, sind viele heutige Filme und Serien ohne Untertitel schwer anzusehen.
    • Ich verstehe nicht einmal, wie diese Flat UI überhaupt in Mode kommen konnte.
  • Noch einmal muss man Firefox dafür loben, dass es in about:config Werkzeuge bietet, um so etwas abzuschalten. Im besten Fall ist es niedlicher Zierrat, im schlimmsten nervig und missbräuchlich.
    Die Browser-UI sollte fast vollständig außerhalb des Bereichs liegen, den Websites verändern können, und Scrollbars gehören dazu.

    • Umgekehrt musste ich bei Chrome an der Stelle laut lachen: „Stell dir vor, man könnte in Chrome etwas Nützliches einstellen.“
      Der ganze Artikel ist sehr gut geschrieben, Lob an den Autor.
      Ich bin auch wieder zu Firefox gewechselt, weil Edge mir ständig Bing-Suche und andere Funktionen aufdrängte und selbst die Aufforderung zur Tab-Wiederherstellung viel zu nervig war. Es soll einfach den Mund halten und damit aufhören.
    • Ich erinnere mich noch sehr gut daran, wie ich Anfang der 2000er in Foren die Funktion zum Styling der Scrollbars im IE6 hartnäckig verteidigt habe. Die Mozilla-Seite nannte sie damals etwas Abscheuliches.
      Jetzt, älter, mit der Kraft zum Zurückblicken und der Schwäche schlechter gewordener Sehkraft, kann ich zugeben, dass ich falschlag. Sie lässt sich viel zu leicht missbrauchen.
    • Smooth Scrolling sollte ebenfalls auf diese Liste. Egal ob man mit dem Mausrad scrollt oder mit Ctrl-F zwischen gefundenen Wörtern springt.
      Zum Glück lässt es sich mit uBlock Origin überschreiben.
    • Auch das breite Ökosystem der Erweiterungsautoren ist lobenswert. Der Autor lobt am Ende eine Minimap-Seitenleiste als Upgrade der bisherigen Scrollbar, und so etwas gibt es tatsächlich.
      https://addons.mozilla.org/en-US/firefox/addon/minimap-scrol...
    • Es funktioniert auch mobil, aber den genauen Zauberspruch zum Überschreiben muss man nachschlagen.
      Vermutlich ist es dieser hier:
      <https://www.makeuseof.com/change-firefox-scrollbar-style/>
  • Der Autor sieht zwar die Hälfte des Problems, schlägt aber die schlechte Hälfte der Lösung vor.
    Scrollbars sind nicht nur Bedienelemente, sondern auch Positionsanzeigen. Sie zeigen, wo sich der aktuelle Viewport innerhalb einer größeren Ansicht befindet, etwa in einer langen Liste.
    Scrollbars zu verstecken, wie es manche GUIs wie macOS tun, ist extrem unhöflich – so, als würde man Buttons nicht mehr von Text unterscheidbar machen oder hellgraue Schrift auf hellgrauen Hintergrund setzen.
    Die Lösung gibt es bereits und sie ist nahezu überall implementiert: das Scrollrad der Maus und Scrollgesten auf dem Trackpad.
    Ansichten, die sich per Scrollbar scrollen lassen, aber nicht mit Standard-Trackpad-Gesten oder dem Mausrad, sind sehr selten. Meine Maus kann mit dem Rad auch horizontal scrollen, und TrackPoint-Bedienelemente ebenso.
    Für diese Art des Scrollens muss der Zeiger nicht einmal über der Scrollbar stehen; es reicht, wenn er über der gewünschten Ansicht/dem gewünschten Control/Widget liegt.
    Das ist auch mit unpräzisen Eingabegeräten, zitternden Händen oder schlechter Sehkraft sehr einfach.
    Aber gerade wenn es eine so natürliche und einfache Art zu scrollen gibt, vermisst man Scrollbars umso mehr, wenn sie als Anzeige dienen.
    Minimap-Ansichten sind manchmal nützlich, oft aber auch nicht; persönlich empfinde ich sie beim Bearbeiten von Text als sperrig und wenig hilfreich. Natürlich bin ich dafür, sie als Option für Leute anzubieten, die sie mögen.

    • Scrollräder und Gesten sind Geräte zum seitenweisen Bewegen, und Scrollbars erfüllen diese Funktion ebenfalls; zugleich sind sie aber auch ein Bedienelement im Sinne von „bring mich in die Mitte des Dokuments“.
      Unter der Voraussetzung, dass das Dokument ordentlich reagiert, kann man mit der Scrollbar gerade in großen Dokumenten leicht über große Bereiche springen. Im heutigen Web kann man dieser Voraussetzung allerdings kaum noch trauen.
      Bei alten, großen PDFs ohne Links, die Abschnittsseitenzahlen wie „B-29“ verwenden, habe ich unzählige Male mit der Scrollbar praktisch eine binäre Suche durchgeführt, um eine vergrabene Seite zu finden.
      Natürlich hat das moderne Web mit dem übermäßigen Einsatz von Lazy Loading und Infinite Scroll die Möglichkeit, Scrollbars als Anzeige zu verwenden, fast zerstört.
      Auf dem Mac habe ich oft mit Cmd-Pfeil nach unten ans Ende eines Dokuments gesprungen, in der Hoffnung, dass es ein Ende gibt, und erwartet, dass alle formatzerstörenden Embeds geladen werden.
      Am Ende fühlt es sich aber an, als säße man auf einem Zug ohne sichtbares Ende: Man weiß weder, wie weit man gekommen ist, noch wie viel noch vor einem liegt.
      Weil Scrollbars damit praktisch nutzlos geworden sind, verwende ich ein schweres Mausrad mit Lager, das für schnelles Doomscrolling ausgelegt ist.
    • Es wirkt, als hättest du den Artikel nicht gelesen. Gleich im ersten Absatz heißt es: „Man könnte sagen, dass genau dafür das Scrollrad da ist, aber nicht jeder kann ein Scrollrad oder Wischen auf einem Touchscreen benutzen.“
      Direkt im nächsten Absatz geht es außerdem um die Schwierigkeiten, die kleine/versteckte Scrollbars für andere Eingabemethoden wie Eye Tracker verursachen.
    • Genau. Endlich jemand, der versteht, wofür Scrollbars da sind.
      Die primäre Aufgabe einer Scrollbar ist es, dem Nutzer zu zeigen, dass das Dokument größer ist als das Fenster; die sekundäre Aufgabe ist zu zeigen, welcher Teil des Dokuments sichtbar ist. Den Nutzer scrollen zu lassen, ist nicht ihre Hauptfunktion.
      Ich war wirklich erstaunt, als Apple begann, Scrollbars in macOS standardmäßig auszublenden. Die UI-Designer von Apple scheinen nicht zu wissen, was grundlegende UI-Controls tatsächlich leisten.
    • Scroll-Eingabegeräte sind nicht überall selbstverständlich vorhanden.
      Wacom-/Stift-Nutzer haben kein Scrollrad.
      Viele Trackballs haben ebenfalls kein Scrollrad; manche haben immerhin einen Scrollring um die Kugel.
      Ich habe das Scrollrad aus meiner Maus entfernt, weil ich durch die wiederholte Nutzung eine RSI-Verletzung am Scrollfinger bekommen habe. Es gab auch eine Zeit, in der ich meinen Mausschulterarm überlastet hatte und mehrere Wochen lang mit der anderen Hand einen Trackball benutzen musste.
    • Wenn man über sehr große Distanzen scrollen muss, bricht das Mausrad zusammen.
  • Man muss auch über Fensterränder sprechen. Ich habe mehrere VS-Code-Fenster mit schwarzem Hintergrund und schwarzem Rand überlappend geöffnet, und es gibt keinen Schatten.
    Man sieht überhaupt nicht, wo der Rahmen/Rand eines Fensters über einem anderen Fenster liegt. Das sollte eigentlich ein Problem auf Betriebssystemebene sein, ist aber apparently ein Problem der App.
    Außerdem hat VS Code die Unterstützung für Randeinstellungen „zurückgezogen“: https://github.com/microsoft/vscode/issues/160159

    • Mehr zu Rändern und Titelleisten gibt es hier:
      https://news.ycombinator.com/item?id=37865824
      Meine Theorie ist, dass Designer offenbar Nutzer im Blick haben, die jeweils nur ein einziges Vollbildfenster sehen.
      Ihr Modellnutzer sitzt in einem Raum mit idealer Beleuchtung und ohne Reflexionen vor einem 13-Zoll-Laptop, verschiebt oder skaliert keine Fenster und öffnet pro Tag auch nicht mehr als drei Tabs/Dokumente.
  • Jedes Mal, wenn ich solche Artikel oder UX-Blogs lese, wird überdeutlich, wie wenig wir uns um Barrierefreiheit kümmern.
    Ein zugängliches, „gutes“ Design ist deutlich langweiliger und reduzierter als das, was von modernen Web-Apps erwartet wird.
    Nachdem ich Adam Silvers Buch über Formulare gelesen hatte, wurde mir klar, dass wir aus Sicht der Barrierefreiheit völlig falsch liegen, aber Barrierefreiheit hat keine Priorität.

    • Es ist ironisch, dass ein Kommentar, um barrierefrei zu sein, vom Leser verlangt, nachzuschlagen, dass a11y „accessibility“ bedeutet.
    • Aus geschäftlicher Sicht ist das nicht unbedingt falsch. Wenn Unternehmen Dinge tun, die man beim Bau einer barrierefreien Website nicht tun kann, geht die Rechnung oft besser auf.
      Besonders Dark Patterns stehen der Barrierefreiheit stark entgegen.
      Deshalb braucht es Gesetze, die Barrierefreiheit verpflichtend machen.
  • Wissen Sie, was für viele Menschen über 40 ein Barrierefreiheitsproblem ist? Weiße Schrift auf dunklem Hintergrund.
    Ich glaube, ich werde nie müde, dafür zu argumentieren, Webseiten so zu gestalten, dass Menschen in meinem Alter sie lesen können.
    Wenn ich die Entwicklerwerkzeuge öffnete und das CSS des Autors änderte, konnte ich es zwar lesen, aber die Shell-Skripte wurden unlesbar.

    • Ich bin unter 40, aber diese Kombination belastet die Augen trotzdem enorm. Wenn ich ein paar Absätze lese und dann auf eine Wand schaue, bleiben Nachbild-Buchstaben länger als 30 Sekunden in meinem Sichtfeld.
      Das ist so unangenehm, dass ich eine Seite gar nicht erst lese, wenn selbst das Markieren des gesamten Textes den Kontrast von dunklem Hintergrund/weißer Schrift nicht abmildert.
    • Leider widersprechen sich Anforderungen an Barrierefreiheit oft gegenseitig, und die Leute, die Webseiten erstellen, haben auch nicht unendlich viel Zeit, um Optionen für alle zu garantieren.
      Man kann auch erwägen, CSS komplett auszuschalten.
    • Ich bin noch nicht 40, aber bei mir ist es umgekehrt. Ich habe starke Glaskörpertrübungen, und auf weißem Hintergrund fallen sie besonders auf.
      Was in den letzten fünf Jahren wirklich gut war: Die meisten großen Benutzeroberflächen bieten inzwischen sowohl Dark Mode als auch Light Mode an.
    • Im Browser lohnt es sich, mit der Erweiterung Dark Reader herumzuspielen. Normalerweise nutzt man sie für einen globalen Dark Mode, aber man kann auch pro Website oder global einen White Mode einstellen.
    • Nicht exakt dasselbe Problem, aber ich sehe oft dunkle oder mittelgraue Schrift auf hellem oder mittelgrauem Hintergrund.
      Meine Lösung dafür ist diese:
      https://addons.mozilla.org/en-US/firefox/addon/font-contrast...
      Sie erzwingt zumindest schwarzen Text. Sie ist ziemlich zuverlässig, und die gelegentlich nötigen Ausnahmen lassen sich leicht konfigurieren.
  • Ich stimme zu, dass Scrollleisten aussterben und unbenutzbar werden. Scrollleisten sollten breit, klar sichtbar und leicht zu treffen sein.
    Sie sollten proportional groß sein, um den aktuell sichtbaren Anteil des Dokuments anzuzeigen, und der bewegliche Teil sollte Merkmale haben, die Reibung statt Glätte suggerieren.
    Die Pfeil-Buttons sollten zusammen angeordnet sein und nicht an gegenüberliegenden Enden; Hover- und gedrückter Mauszustand sollten farblich angezeigt werden.
    Unter den hier gezeigten klassischen Scrollleisten kommt https://scrollbars.matoseb.com/ Nextstep diesen Anforderungen am nächsten, und Mac OS 8 ist meiner Ansicht nach insgesamt am schönsten.

    • Zusätzlich sollte es, sofern das Dokument es unterstützt, auch die Option geben, mit einem einzelnen Toolbar-Widget in beide Richtungen zu pannen. Ich habe solche Implementierungen gesehen, aber keine, bei der die Pfeil-Buttons zusammen statt an den Enden angeordnet sind.
      Früher gab es ein Forschungsfeld namens Mensch-Computer-Interaktion, in dem man Dinge wie Fitts’ Gesetz lernte und die Tatsache, dass Bildschirmränder praktisch unendliche Größe haben und deshalb besonders wertvoll sind.
      Unter OS X habe ich zur Strafe MS Teams geöffnet; das Fenster klebt am rechten Bildschirmrand, und am rechten Rand befindet sich die Scrollleiste.
      Wenn ich die Maus nach rechts schiebe und klicke, um die Scrollleiste zu greifen, die sich beim Mouseover erweitert hat und bis zum Randpixel reicht, wird das ganze Fenster gezogen.
      Ich weiß nicht, wie wir hier gelandet sind. Es gab eine Zeit, in der aktiv erforscht wurde, was eine gute Benutzeroberfläche ausmacht; diese Forschung floss in die tatsächliche User Experience ein, und die Ergebnisse waren sichtbar.
    • Ich hatte nie darüber nachgedacht, dass Pfeil-Buttons nebeneinander statt an gegenüberliegenden Enden angeordnet sein sollten, aber es ergibt Sinn.
      Ich frage mich, warum das so selten ist, abgesehen von „war schon immer so“.
  • Es heißt, „Designer führen keine Usability-Tests mit nichttechnischen Nutzern durch“, aber selbst wenn sie es täten, würde es wohl kaum einen Unterschied machen.
    Ich arbeite seit fast 25 Jahren als Webentwickler und habe mit vielen Designern zusammengearbeitet; was sie interessiert, ist ein pixelperfektes Layout, das ihrer „Vision“ entspricht. UX ist nicht einmal ein flüchtiger Gedanke.

    • Nicht alle Designer sind so, aber viele schon. Ich habe Designer erlebt, die aus UX-Studien mit echten Nutzern kamen und sagten: „Das ist nur ein einzelner Datenpunkt, und wir sind der Ansicht, dass diese Nutzer falsch liegen.“
      In solchen Fällen kommt man mit Überzeugungsarbeit nicht weiter.