Einfach ganz normale Web-Funktionen

 (heather-buchel.com)
3 Punkte von GN⁺ 2023-08-06 | 3 Kommentare | Auf WhatsApp teilen
  • Mit der Zunahme neuer Social-Media-Plattformen und ihrer Clients, Apps sowie Web-Portierungen auf Basis von React Native häufen sich Fälle, in denen Websites grundlegendes Web-Verhalten verlieren, das Nutzer erwarten
  • Als Hauptursachen gelten der Druck, schnell zu launchen, das Fehlen von UI-Ingenieuren, auf Mobile ausgelegte Touch-first-Konzepte und Implementierungen, die Standardverhalten des Browsers mit JavaScript ersetzen
  • Integrierte Browser-Funktionen wie Text kopieren, Rechtsklick auf Links und ctrl + click, Browser-Zoom, responsive Layouts, :hover und :focus, URL- und Verlaufsaktualisierung, Scrollbars und ctrl + f sollten unverändert funktionieren
  • Bei klickbaren Karten zerstören Implementierungen, die pointer-events entfernen oder Ebenen übereinanderlegen, ebenso wie Navigation per div und on-click statt per Anker, die normale Link-Erfahrung
  • Es gibt viele Überschneidungen mit Verstößen gegen die Barrierefreiheit, aber Web-Apps sollten statt wie Mobile-Apps auszusehen die von Nutzern erwarteten ganz normalen Web-Funktionen bewahren

Das grundlegende Verhalten, das Websites verloren haben

  • In Webprojekten wird immer häufiger verhindert, dass Nutzer ganz normale Web-Funktionen nutzen können, die sie erwarten
  • Mit der Zunahme neuer Social-Media-Plattformen entstehen viele verschiedene Clients und Apps, und oft wird versucht, plattformübergreifend Code zu teilen, etwa mit React Native
  • Solche Versuche sind an sich positiv, aber dabei fehlen nicht nur grundlegende Anforderungen an die Barrierefreiheit wie alt-Texte für Bilder, sondern auch die üblichen Bedienmuster des Webs
  • Als Ursachen lassen sich unter anderem nennen
    • der Druck, schnell etwas auf den Markt zu bringen, das wenigstens testbar ist
    • das Fehlen von UI-Ingenieuren im Projekt
    • Designs, die mobile Touch-Eingaben priorisieren und andere Eingabeformen oder Geräte ignorieren
    • Implementierungen, die Standardverhalten des Browsers mit JavaScript umgehen oder ersetzen

Ganz normale Web-Funktionen, die erhalten bleiben sollten

  • Text muss kopierbar sein
    • In klickbaren Karten-Komponenten kann das Entfernen von pointer-events oder das Überlagern klickbarer Ebenen die Textauswahl und das Kopieren verhindern
  • Elemente, die wie Links navigieren, müssen auch die Link-Funktionalität vollständig bieten
    • Per Rechtsklick sollte sich das Kontextmenü öffnen lassen, um Linktext oder Linkadresse zu kopieren
    • Übliche Link-Shortcuts wie ctrl + click unter Windows zum Öffnen in einem neuen Tab müssen funktionieren
    • Statt Navigation über ein div mit on-click sollte ein Anker-Element verwendet werden
  • Beim Browser-Zoom darf das Layout nicht kaputtgehen, und Nutzer müssen zur besseren Lesbarkeit hineinzoomen können
  • Responsives Webdesign sollte beim Unterschreiten von 1200px nicht einfach in ein simples Mobile-Layout kippen, sondern auch in schmalen Viewports den Platz sinnvoll nutzen
    • Mastodon und Twitter sind Beispiele dafür, dass die UI bei schmalerer Browserbreite vertraut bleibt und der verfügbare Raum meist gut genutzt wird
  • Web-Apps müssen Interaktionszustände wie :hover, :focus und :active korrekt bereitstellen
    • Bei auf das Web portierten React-Native-Apps fehlen mitunter :hover- oder :focus-Stile, oder es erscheint ein seltsamer :active-Stil, der wie deaktiviert wirkt
  • Wenn sich die UI nach einem Klick vollständig wie eine neue Seite verändert, müssen sich auch Browserverlauf und URL entsprechend ändern
    • Wenn auf UI-Zustände, die wie eigenständige Seiten wirken, nicht verlinkt werden kann und der Zustand nach der Navigation verschwindet, leidet die Nutzbarkeit
  • Scrollbars sollten nicht versteckt werden
    • Nutzer möchten möglicherweise die Scrollbar anklicken und ziehen
  • Normale Browser-Shortcuts sollten nicht von App-internen Funktionen abgefangen werden
    • Wenn ctrl + f eine benutzerdefinierte In-App-Suche öffnet, funktioniert die Seitensuche womöglich nicht mehr wie gewohnt
  • Vieles davon überschneidet sich mit Punkten, die auch als Verstöße gegen die Barrierefreiheit gelten können, aber der Fokus liegt darauf, dass Web-Apps die grundlegenden Browser-Erwartungen der Nutzer nicht brechen
  • Weitere fehlende Beispiele können auf Mastodon weiterdiskutiert werden

Verwandte Beiträge

3 Kommentare

 
plastic041 2023-08-06

Der Inhalt des Textkörpers scheint falsch zu sein.
 
xguru 2023-08-07

Oh, wie interessant. Das Crawling dieses Blogbeitrags selbst scheint etwas merkwürdig zu funktionieren.
Ich sollte mir den Crawler-Teil einmal ansehen.
 
GN⁺ 2023-08-06
Meinungen auf Hacker News

  • Wenn man das Web zuerst mit React lernt und HTML erst später, kann es passieren, dass einem das Standardverhalten von Links egal wird.
    Als ich zum Team stieß, waren alle Links entweder Buttons, beliebige Elemente oder wurden per onClick behandelt. Niemand beschwerte sich, aber Strg+Klick war nutzlos, und das Rechtsklick-Menü bot nicht die erwarteten Optionen.
    Bei Links gibt es meiner Meinung nach keinen Verhandlungsspielraum.

    • Ich hasse solchen JS-Missbrauch wirklich; er macht immer mehr Dinge kaputt, die eigentlich auf die richtige Weise erledigt werden sollten.
      Selbst die von YC finanzierte Dokumentationsplattform archbee kann Suchergebnisse nicht in einem neuen Tab öffnen: Man muss eines im aktuellen Tab öffnen oder zurückgehen, erneut suchen und das nächste Ergebnis öffnen.
      Ein Beispiel sieht man hier: https://docs.sparklayer.io/
    • In der neuen Web-Version von Reddit sind alle Links Buttons, daher kann man sie nicht in einem neuen Tab öffnen.
      Es ist wirklich seltsam und zum Verrücktwerden, dass ein so großer Internetdienst ein derart offensichtliches Barrierefreiheitsproblem hat.
    • Etwa die Hälfte des Grundes, warum ich nitter statt Twitter nutze, ist genau das.
      Es ist auch schön, dass man kein Konto braucht, aber man kann Tweet-Threads per Rechtsklick in einem neuen Tab öffnen.
      Angesichts der Art von Twitter-Unterhaltungen möchte man oft mehrere Threads neu öffnen und ansehen, während die Position auf der ursprünglichen Seite erhalten bleibt; die tatsächliche Twitter-UI macht das sehr schwierig.
    • Das Link-Problem ist ein Hügel, auf dem man jederzeit bis zum Ende standhalten kann.
      Es gibt kaum etwas, das mehr stört; wenn überhaupt, dann vielleicht Dinge, die den Browserverlauf kaputtmachen.
    • Es ist eine Katastrophe der Webnutzung, wenn man auf Websites mit Listen- und Detailansicht einen Eintrag nicht per Rechtsklick oder Erweiterung in einer Detailansicht in einem neuen Tab öffnen kann.
      Wenn Zurück sofort und reibungslos funktionieren würde, könnte man das noch verzeihen, aber in der Praxis wartet man darauf, dass Inhalte neu geladen werden, und verliert auch noch die Scrollposition.
      Noch schlimmer sind Sites wie Facebook, die in mehreren Tabs denselben Zustand eines Chat-Pop-ups erzwingen. Schließt man es in einem Tab, wird es auch in den anderen Tabs geschlossen, obwohl es einen Grund gibt, warum man mehrere Tabs offen hat.

  • Sobald man am eingebauten Verhalten herumdreht, übernimmt man meiner Ansicht nach auch die Verantwortung dafür.
    Das geschaffene „Feature“ bleibt nicht auf den engen Bereich beschränkt, den der Designer im Sinn hatte, sondern wird zur gesamten Erfahrung, die Besucher tatsächlich machen.
    Wenn man die Logik des Zurück-Buttons ändert, ändert man auf dieser Website die Bedeutung dessen, was „Zurück“ liefert; und man muss dann auch dafür Verantwortung übernehmen, dass verwirrte und verärgerte Nutzer die Site als „kaputt“ beschimpfen.
    Man sollte sich fragen, ob man wirklich bereit ist, selbst für Verhaltensweisen wie Scrollbars Verantwortung zu übernehmen, die sich je nach Browser und Betriebssystem unterscheiden.
    Letztlich bringt man die Website dazu, eine Art Kreolsprache zu sprechen; es ist also nicht überraschend, wenn Besucher diese Sprache nicht verstehen oder sie „falsch interpretieren“.
    Solche Funktionen sollte man nicht nur aus Freundlichkeit gegenüber Besuchern vermeiden; der Gewinn wirkt begrenzt, der mögliche Schaden dagegen nahezu unbegrenzt.

    • Stimmt. Websites profitieren von lange verfeinerten Design-Idiomen.
      Sites, die solche Idiome ignorieren, werden schwerer nutzbar, weil sie nicht die Sprache sprechen, mit der Nutzer vertraut sind.
      Es gibt auch einen längeren Artikel über den Verlust von Design-Idiomen: https://loeber.substack.com/p/4-bring-back-idiomatic-design

  • Ich halte das für die Verappung von Websites, und das muss aufhören.
    Websites sollten zurück zu Server-Side Rendering und nur so viel JavaScript daraufsetzen, wie nötig ist.
    Web-Apps hingegen dürfen etwas stärker in die UX eingreifen, wenn das den Nutzern einen Mehrwert bietet; solange sie aber im Browser laufen, gelten die Grundprinzipien weiterhin.
    Ich unterstütze Web-Apps, weil sie eine für alle zugängliche Entwicklungsplattform außerhalb der Mauern der App-Stores sind, aber wir müssen aufhören, jede Website wie eine App zu behandeln.
    Wenn eine Seite in Suchmaschinenergebnissen erscheinen soll, ist sie keine Web-App, sondern eine Website.

    • Es wäre schön, wenn Browser für Rohdokumente Accept: text/markdown senden könnten, aber ich denke, sobald CSS auftauchte, war dieser Zug abgefahren.
    • Dieser Artikel könnte dir gefallen: https://notan.app/
    • Ich stimme der Aussage zu: „Websites sollten zu Server-Side Rendering und ein wenig JS zurückkehren.“
      Zum Glück scheint es dank Dingen wie React Server Components wieder in die Richtung zu gehen, JavaScript schrittweise auf Websites aufzusetzen, was ich gut finde.
    • Auch eine gute Web-App kann eine Website sein.
      Mit genug Zeit ist das ein lösbares Problem.

  • Ich verstehe nicht, warum Banking-Websites Einfügen blockieren
    Wenn man merkt, dass man nichts einfügen kann, hat man den Text bereits kopiert
    Tippt man ihn von Hand ein, passieren eher Fehler, und wenn die Zwischenablage kompromittiert ist, ist das Kopieren schon erledigt, sobald man das Einfügeverbot bemerkt

    • Es fühlt sich an, als stünde irgendwo in einer „Einführung in Formularprogrammierung“ Code zum Blockieren von Kopieren und Einfügen, und dieses Konzept hätte im ganzen Web Tausende Nachkommen hinterlassen
      Offenbar stellen sich Leute das als Sicherheitsmaßnahme vor und kopieren es freiwillig
      Ich verstehe grundsätzlich nicht, warum man Nutzer am Einfügen hindern sollte
    • Die Website meiner Bank blockiert nicht nur das Einfügen des „Passworts“, sondern auch Tastatureingaben
      Dieses „Passwort“ ist gerade einmal eine 6-stellige Zahl und ich kann es nicht einmal selbst festlegen. Als wären 6 Ziffern viel sicherer als eine zufällige 16-Zeichen-Zeichenkette aus einem Passwortmanager
      Man wird gezwungen, es über Buttons an zufälligen Positionen auf der Seite einzugeben; wenn das Gerät aber schon so infiziert ist, dass Tastendrücke und Klicks aufgezeichnet werden, kann der Angreifer vermutlich auch einfach das Passwort aus dem Browser-Speicher lesen
    • Vor ein paar Tagen habe ich mich bei einem neuen ISP angemeldet, und das Passwortfeld blockierte Einfügen, wodurch der Passwortmanager kaputtging
      Aus Sicherheitssicht ist das eine wirklich unglaublich schlechte Entscheidung
    • Meist beginnt es damit, dass ein Unternehmen ein Problem mit Bot-Traffic hat
      Man probiert allerlei Dinge aus, um Bots zu stören, und eines Tages werden Entwickler von einem mittleren Manager dazu gedrängt, Kopieren und Einfügen auf der Login-Seite zu blockieren, woraufhin die Bots kurz innehalten
      Ein paar Tage später umgehen die Bots das, aber der frühere „Fix“ bleibt mit dem Gedanken erhalten, er könne „vielleicht manche Bots blockieren“
      So überlebt ein gutes Dutzend Zeilen JavaScript bis Rewrite v6, und ein paar Monate oder Jahre nach einem Neustart wird dasselbe Verbot wieder eingebaut
      Ich spreche hier natürlich keinesfalls aus Erfahrung
    • Ich will nicht behaupten, dass es hier so ist, aber es gab durchaus Clipboard-Malware, die kopierte Inhalte, wenn sie wie eine Bitcoin-Adresse aussehen, durch die eigene Adresse ersetzt
      https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
      Vielleicht hatte man so etwas im Hinterkopf

  • Es nervt, wenn schicke JS-Entwickler Komplexität und Funktionen, nach denen niemand gefragt hat, hinter select-Menüs verstecken, die wie natives HTML aussehen
    Ich sehe das oft bei Eingaben für Stadt und Bundesstaat: Die Stadt ist ein Texteingabefeld, der Bundesstaat ein Dropdown/select-Menü
    Als Texaner gebe ich die Stadt ein, springe mit Tab zur Auswahl des Bundesstaats, drücke t, t und gehe dann zum nächsten Formularelement weiter
    Heutzutage ist es aber oft ein als Dropdown gestyltes Textsuchfeld, sodass t, t nicht erst Tennessee und dann Texas auswählt, sondern buchstäblich nach tt sucht
    Es funktioniert nur für Leute erwartungsgemäß, die mit der Maus auf das Dreieck klicken und durch die Liste der Bundesstaaten scrollen
    Wenn es nicht kaputt ist, sollte man es nicht reparieren

    • Das war größtenteils ein Problem, das durch eine Lücke in der Web-Plattform entstanden ist
      Historisch war ein echtes <select> sehr schwer oder unmöglich zu stylen oder im Verhalten zu erweitern, daher haben viele Apps es selbst neu implementiert, meist ziemlich schlecht
      Es scheint neue, stylebare eingebaute Alternativen zu geben
      Außerdem war Code-Sharing zwischen Apps, Frameworks und Unternehmen schwierig, sodass eingebaute Komponenten-Ersatzlösungen mit vollem Funktionsumfang, Accessibility und Anpassbarkeit nur von großen Unternehmen gebaut werden konnten
      Web Components können dieses Problem lösen, indem sie weltweite Zusammenarbeit an gemeinsamen Leaf-Komponenten wie <select> ermöglichen
      Zugehöriger Artikel: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...

  • Ich denke, ein großer Teil kaputten Link-Verhaltens entsteht dadurch, dass es an höherwertigen Methoden fehlt, um das Standardverhalten von Links zu überschreiben
    Wenn ich zum Beispiel einen Link in einem Modal öffnen will, möchte ich keinen Click-Event-Listener anhängen. Click-Events sind zu niedrigstufig, weil man Modifier-Tasten selbst prüfen muss
    Was ich wirklich will, ist dem Browser zu sagen: „Wenn sich wegen dieses Anchor-Elements die URL des aktuellen Fensters ändern würde, rufe stattdessen diese Funktion auf“
    Dann kann der Nutzer den Link frei in einem neuen Fenster oder Tab öffnen, und in diesem Fall wird mein Code nicht ausgeführt
    Bei CSS ist es ähnlich: Ich möchte nicht für jedes Element und jede Pseudoklasse ein Cursor-Bild angeben. Ich möchte sagen: „Überall dort, wo der Standard-Hand-/Warte-/Resize-Cursor verwendet würde, nimm stattdessen dieses Custom-Bild“
    Dann bleibt der Code auch bei neuen Elementen oder UI zukunftssicher
    Manche Browser-APIs scheinen gelegentlich am XY-Problem zu leiden

    • Das ist mit JavaScript durchaus möglich
      Man registriert onclick am Tag und bricht im Event-Handler die Standard-Navigation ab
      Wenn Nutzer JavaScript deaktivieren, funktioniert die Site weiterhin gut, und eingebaute Browser-Verhalten wie das Rechtsklick-Link-Menü oder Ctrl+Klick funktionieren ebenfalls unverändert
      Allerdings ist das ein ziemlich obskurer „Trick“, daher wäre es schön, wenn die DOM API es einfacher machen würde
    • https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
      Ich denke, das ist ein Use Case für die Navigation API
    • Endlich habe ich online gesehen, was ich meine
      Wir brauchen kein Click- oder Pointer-Event, sondern ein höherwertiges visit-Event

  • Als ich Flutter Gallery zum ersten Mal sah, war ich überrascht, weil sich im Webbrowser alles kaputt anfühlte: https://gallery.flutter.dev
    Besonders das Reply-Beispiel war, glaube ich, so
    Ctrl+Klick oder die mittlere Maustaste auf Links funktionierten nicht, Rechtsklick ging nicht, Textauswahl und Kopieren gingen nicht, wegen der technischen Struktur war auch das Inspizieren von Elementen nicht möglich, und beim Versuch, die Seite zu vergrößern, passierte nichts
    Wenn ich an diese Erfahrung und an einige SPA-Implementierungen mit traditionelleren Technologien denke, klingt dieser Artikel für mich richtig

    • Flutter ist eine weitere Sackgasse auf dem Weg zu einem integrierten Entwicklungs-Framework
      Ob Web oder Mobile: Keine Flutter-Demo hat mich je davon überzeugt, dass sie eine brauchbare UX bietet
    • Auch in mobilen Browsern scheint die Textauswahl seltsam behandelt zu werden
      Wenn Flutter verspricht, überall gleich zu sein, dürfte diese Demo auf dem Desktop genauso schlecht sein

  • Ich fände es auch gut, wenn das Scroll-Verhalten nicht überschrieben würde
    Man sollte nicht versuchen, Scrollen „flüssiger“ zu machen
    Unter Windows mag das okay aussehen, aber auf dem Mac mit Apple-Eingabegeräten entspricht die Bewegung des Scroll-Ziels 1:1 der Bewegung des Fingers auf Trackpad oder Maus
    Solche „Verbesserungen“ fühlen sich meist an, als würde man durch Melasse scrollen
    Generell sollte man nicht versuchen, das Standardverhalten des Browsers zu verbessern

  • Eines der Dinge, die ich am chaotischen modernen Web nicht mag, ist das Herumpfuschen an der History API
    Wenn man auf einer Seite wie HN einen interessant wirkenden Link anklickt, die Seite öffnet und scrollt, fügt sie für jeden Header oder jedes ziemlich unwichtige Element einen Eintrag in den Verlauf ein
    Um zur ursprünglichen Seite zurückzukehren, muss man gefühlt eine Million Mal auf Zurück klicken
    Ich kann alle nicht ausstehen, die so etwas machen

    • Dazu möchte ich auch Infinite Scroll hinzufügen
      Nehmt einfach Pagination
      Sie ist verlinkbar, durchsuchbar, navigierbar und funktioniert korrekt mit dem Verlauf
      Infinite Scroll macht all das ohne großen Grund kaputt

  • Hier gibt es eigentlich zwei Probleme, die so alt sind wie das Web selbst: niedrige Erwartungen und das Fehlen von Standards und Kriterien, die Menschen oder die Praxis definieren
    Wenn man sich heutige Stellenausschreibungen ansieht, steht überall „Senior Fullstack Engineer“, aber schaut man genauer hin, wird oft tatsächlich eine Kombination aus Java oder Python, R, Spring und SQL gesucht
    Wenn das nicht Fullstack ist und man es trotzdem so nennt, verschwendet man die Zeit der Leute und sendet der Öffentlichkeit das Signal, dass man Technologie nicht versteht oder sich nicht darum kümmert
    In der Programmierung nennt man das das „X/Y-Problem“. Ein Anti-Pattern, bei dem man den gewünschten Endzustand X lösen müsste, stattdessen aber nur über den Ansatz Y spricht, den man verfolgen möchte
    So bekommen Arbeitgeber auf eine Ausschreibung 500 Lebensläufe und haben trotzdem das Gefühl, dass niemand passt
    Der Ausgangspunkt sollte das Ziel sein: etwa „Wir stellen ein, um diese Client/Server-App zu bauen; Kandidaten müssen die Funktionen X, Y und Z schreiben und unterstützen, und die Einschränkungen sind A, B und C“
    Der Grund, warum Unternehmen das nicht hinbekommen, ist meist, dass sie selbst nicht wissen, was sie eigentlich tun, und bereits über mehrere falsche Wege hinweg kaputte Technologie mit sich herumschleppen. Deshalb nennt man es technische Schulden
    Wenn das Ziel so klar ist, wissen im Interview sowohl das Unternehmen als auch die Kandidaten, was sie prüfen müssen, und können einander sinnvoll aussortieren. Andernfalls wird es zu einem schrecklichen Prozess, der an eine Mischung aus Blind Date und Gameshow erinnert
    Zum Beispiel könnte man klar angeben, dass man für den Bau einer hochgradig verteilten Medienkonferenz-Anwendung einstellt und dass Entwickler TypeScript schreiben, Stream-Daten aus Sockets per Pipeline verbinden, sowohl im Browser als auch auf dem Server arbeiten und Testautomatisierung schreiben müssen
    Zu den betrieblichen Einschränkungen gehören WCAG-AA-Konformität, eine vom Legal-Team erstellte Checkliste zur Einhaltung von Datenschutzvorgaben sowie Performance-Überlegungen mit Blick auf Ausführungsgeschwindigkeit und Netzwerklatenz; ideale Kandidaten sollten im Interview Lösungen für Netzwerklatenz, Browser-Anwendungslogik und Zustandsverwaltung von Streaming-Daten zeigen