Für Interaktionen lassen sich viele kleine HTML-Seiten per Navigation aneinanderreihen

 (blog.jim-nielsen.com)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der Ansatz (L)ots of (L)ittle ht(M)l page(s) ersetzt seiteninterne Interaktionen auf JavaScript-Basis durch Navigation zwischen vielen kleinen HTML-Seiten
  • Interaktionen werden als Navigation zwischen HTML-Seiten aufgebaut, in modernen Umgebungen mit CSS-View-Transitions verbessert und nur bei Bedarf um etwas JavaScript ergänzt
  • Das Menü des Blogs ist keine per JavaScript aufklappende UI, sondern funktioniert durch das Folgen des Links <a href="/menu/"> zu einer eigenen Menü-Seite
  • Auch das Schließen des Menüs ist standardmäßig ein Link zu /, aber wenn document.referrer vorhanden ist, wird per JavaScript history.back() ausgeführt, damit sich im Browserverlauf keine Einträge für das Öffnen und Schließen des Menüs ansammeln
  • Wenn man sich auf die Standardfunktion des Browsers, also Link-Navigation, verlässt, funktioniert es auch auf älteren Geräten, in älteren Browsern und bei deaktiviertem JavaScript; je kleiner die Seiten bleiben, desto schneller und robuster werden Interaktionen

Umsetzungsweise des Menüs und die Folgen für das Design

  • Öffnen und Schließen jeweils als Link behandeln

    • Auf normalen Seiten gibt es einen Link zur Menü-Seite, und auf der Menü-Seite wird dieser Link zu einem „X“, das das Menü schließt
    • Auch das Schließen ist standardmäßig ein Link zu /, aber wenn document.referrer vorhanden ist, wird per JavaScript history.back() ausgeführt, damit im Browserverlauf keine Einträge für das Öffnen und Schließen des Menüs hinzugefügt werden
    • Eine vereinfachte Implementierung sieht so aus 
      <!-- Normal page -->
<nav>
  <a href="/menu/">
    <svg>...</svg>
  </a>
</nav>

<!-- Menu page -->
<nav>
  <a href="/" onclick="document.referrer ? history.back() : window.location.href = '/'; return false;">
    <svg>...</svg>
  </a>
</nav>

  • Direkten Aufruf und interne Navigation unterscheiden

    • Mit document.referrer wird unterschieden, ob die Menü-Seite über interne Navigation im Blog erreicht wurde oder durch einen direkten Aufruf wie die Eingabe der URL
    • Bei interner Navigation kann sinnvoll history.back() ausgeführt werden, bei einem direkten Aufruf geht es zu /

  • Der Ansatz prägt das Design

    • Die Lösung wirkt einfach, aber man muss zugleich das Wesen von Navigation, seitenübergreifende Interaktionen und Wege zum Erhalt kleiner Seitengrößen mitdenken
    • Die Seitengröße muss klein bleiben, damit Interaktionen schnell, robust und intuitiv bleiben können
    • Wenn man den Browser nicht als Runtime zum Ausführen, Laden, Kompilieren und Anzeigen beliebigen Codes betrachtet, sondern als Werkzeug zum Navigieren durch Dokumente, kann man deutlich einfachere Websites bauen, als die Werkzeuge es nahelegen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Lobste.rs-Kommentare

  • Normalerweise mag ich den Ansatz, immer mit HTML zu antworten, aber bei Menüs bin ich mir nicht sicher.
    Mich würde die Meinung von Accessibility-Expert:innen interessieren, was besser ist: umschaltbare Elemente oder ein kompletter Seitenwechsel, um ein Menü zu öffnen.
    Hier wirkt die Popover API wie die bessere Lösung, weil man damit ein Menü ohne JavaScript und ohne vollständigen Roundtrip anbieten kann.
    Ansonsten stimme ich größtenteils zu, dass man keine Angst vor Seitenwechseln haben muss. Sogar eine SPA-artige Navigation ist auf SSR- und statischen Sites heute fast immer nicht schwer barrierefrei umzusetzen.

    • Ich bin kein Accessibility-Experte, aber als jemand, der NVDA für die Webentwicklung installiert hat, nehme ich in der User Experience keinen großen Unterschied wahr.
      Ein Seitenwechsel setzt zwar die aktuelle Position zurück, aber wenn man ohnehin ein Menü öffnen wollte und tatsächlich beim Menü landet, ist das ziemlich ähnlich.
      Trotzdem fühlt es sich, auch unabhängig von Screenreadern, ziemlich seltsam an, zum Öffnen eines Menüs auf eine neue Seite zu wechseln.
    • Das entscheidende Wort ist can, nicht should. Wenn HTML-Seiten für eine Interaktion passend sind, nutzt man sie; wenn etwas anderes besser passt, dann eben das.
      Wenn man etwa fragt, ob man den aufgeklappten/zugeklappten Zustand einer Komponente als zwei verschiedene HTML-Seiten modellieren oder einfach das Tag <details> verwenden sollte, ist natürlich Letzteres richtig.
      Genauso ist es völlig in Ordnung, die Popover API zu verwenden. Der Punkt ist, JavaScript für Interaktionen innerhalb einer Seite möglichst nicht zu benötigen, nicht stur auf mehrseitiger HTML-Navigation zu bestehen.

  • Der gezeigte Ansatz lädt das Menü dynamisch mit JavaScript und onclick, dadurch entsteht Latenz und ein zusätzlicher Datenpunkt in der User Journey.
    Stattdessen könnte man das Menü auf jeder Seite einbetten und mit dem Element <details> oder dem CSS-Selektor :focus-within ein- und ausblenden.
    https://nlnet.nl funktioniert so.

  • Der beschriebene Ansatz funktioniert in der Praxis eigentlich nicht richtig. Wenn man JavaScript deaktiviert, einen Blogpost öffnet und dann das Menü öffnet und wieder schließt, landet man nicht beim ursprünglichen Beitrag, sondern auf der Startseite (/).
    Damit der Schließen-Button den korrekten Link hat, müsste das Backend das Menü dynamisch rendern; erst dann ergibt dieser Ansatz Sinn.
    Ich persönlich bevorzuge, wenn möglich, die Popover API. Dann kann man alles auch ohne Backend statisch rendern.

    • Der Link auf dem X-Icon des Menüs zeigt auf https://blog.jim-nielsen.com/, aber mit aktiviertem JavaScript scheint der onclick-Handler die Navigation abzufangen. 
      document.referrer
  ? history.back()
  : window.location.href = '/';
return false;
      Es ist eine schlechte User Experience, wenn man auf eine andere Seite geschickt wird als die, die im href steht. Ich prüfe oft das Ziel, indem ich über Links hovere, und so in die Irre geführt zu werden fühlt sich nicht gut an.

  • Einerseits gefällt mir das wirklich sehr. Mit reinem HTML kann man oft viel mehr machen, und zwar flüssiger und einfacher als mit JavaScript.
    Andererseits scheint dieser Ansatz vor allem auf Mobilgeräten gut zu passen. Auf Desktop-Seiten würde ich erwarten, dass ein Menü immer sichtbar ist oder herausklappt, nicht dass dafür ein Seitenwechsel nötig ist.
    Dann fragt man sich, ob man jetzt zwei Versionen von Seiten je nach Browser braucht.

    • Umgekehrt muss man auf dem Smartphone bei instabiler Verbindung erst zum Menü wechseln und dann noch einmal zum eigentlichen Ziel.
      Das verdoppelt die Reibung.
    • Du scheinst vergleichsweise jung zu sein. Vor 20 bis 30 Jahren funktionierten alle Websites so, und HTML war bis zu einem gewissen Grad auch genau dafür gedacht.
      JavaScript war eher ein Unfall.
      Ich finde es seltsam, das als schwieriger oder komplizierter zu empfinden als irgendeine JavaScript-Lösung. Es ist eindeutig die schlichteste und einfachste Art, eine Website zu bauen.

  • Die Navigationsart gefällt mir nicht besonders, aber den Übergangseffekt mochte ich, und ich wusste nicht, dass so etwas möglich ist.
    Ich habe das direkt auch auf meiner Site eingebaut, die einen selbstgeschriebenen statischen Generator in C++ und eine Template-Bibliothek nutzt: https://vittorioromeo.com/
    Besonders gut passt es meiner Meinung nach zum Umschalter für Dark-/Light-Theme.

  • Auf dem Desktop auf „menu“ zu klicken und dann auf eine andere Seite zu wechseln fühlt sich nicht gut an. Es gibt einen vollständigen Page Reload, und das ist entgegen der Erwartung ziemlich störend.
    Für mich unterbricht das den Lesefluss und den Gedankengang. Wenn ich auf einen Link zu einer anderen Website klicke, fühlt es sich an, als würde ich den Raum verlassen und den vorherigen hinter mir lassen; wenn mir das aber in einem Menü passiert, fühlt es sich an, als stünde ich vor einer Tür und wäre plötzlich in einem ganz anderen Raum gelandet.
    Die Idee selbst ist ehrlich gesagt gut, aber in der tatsächlichen Nutzung fühlt sie sich nicht gut an.
    Und ich weiß auch nicht, welcher Übergangseffekt gemeint ist. In meiner Umgebung lädt beim Drücken des Menu-Buttons einfach ganz normal die Menu-Seite.

    • View Transitions zwischen Dokumenten funktionieren in Firefox noch nicht.
      Möglicherweise auch in anderen Browsern nicht, aber mein Hauptbrowser ist Librewolf, ein Firefox-Fork.
      In Chromium sieht man den Übergangseffekt.

  • Interessante Idee, aber ich frage mich, wie das auf dem Desktop funktionieren soll.
    Ein Menü als ganze Seite wirkt etwas übertrieben, deshalb erscheint mir ein Ansatz, der die ganze Seite austauscht, weniger passend.

  • Es wird kein preload erwähnt, um die Ladeverzögerung der Menüseite zu verringern.
    Ich frage mich, wie gut das damit funktionieren würde.

    • Man müsste auch die richtigen Cache-Header setzen. Hier könnte schon ein einfacher Expires-Header ausreichen.
      Dann müsste vor dem Anzeigen nicht einmal mehr zur Validierung beim Server nachgefragt werden, was sich sehr schnell anfühlen würde.

  • Vor ein paar Jahren habe ich ein Textspiel von @misty gesehen, das einfache Links als Interaktion nutzte und so die Illusion von Auswahl erzeugte.
    Das schlichte HTML und die starke Erzählung haben einen bleibenden Eindruck hinterlassen.