Sturkopf adé

Wieso der “fixed header” in der Regel ein eher schlechtes Design-Pattern ist.

Viele Pattern im Webdesign machen erst einmal Sinn und sind schnell verteidigt im Sinne der Praktikabilität. So auch beim feststehendem Header, auf mobilen Devices sowie auf dem Desktop. Zentrale Dinge wie Menü und Suche immer schnell zu erreichen — und dazu noch das Logo an prominenter Position inklusive auffälliger Markenfarbe als Hintergrund, klingt erst einmal gut. Diesen angeblichen Nutzen möchte ich aber in Frage stellen. Eigentlich mehr als das, denn als User nervt mich dieser Designklotz jetzt seit einer Weile. Weg mit dem fixed Header — Freiheit für die Inhalte!

Browserhersteller machen es seit Jahren vor: Interface verkleinern und in den Hintergrund stellen — denn das was zählt, ist der Content, ist die Webseite. Das zeigt sich im Zurücknehmen von Steuerelementen wie History-Back und weiterer Funktionen im Kopf des Browsers oder auch in der Betriebssystemseitigen Rücknahme von Elementen wie der Scrollbar auf dem MacOS.

Mozilla Firefox 2007
Mozilla Firefox 2017

Medium hat es erkannt: Ein Text und seine Lesbarkeit sind zwei untrennbare Dinge, und dies zum USP ihres Services gemacht. Der Erfolg kommt nicht nur durch die Inhalte, sondern auch durch die Art und Weise, in der sie präsentiert werden. Jetzt ist unsere Wahrnehmung ein empfindliches Gut, schneller als wir denken kön… — Katze!

Schlimm, wenn die wichtigsten Artikel, die schönsten Texte, und die interessantesten Meinungen durch visuell schreiende und deplatzierte Werbung gestört werden. Noch schlimmer, wenn dies ohne Absicht und durch Designs geschieht, die eigentlich in ihrer Intention als Unterstützung, als Interface gedacht sind. Fixierte Elemente wie der Fixed Header können so eine Ablenkung sein, denn — Lesefluss, Schreibrichtung und Blickrichtung sind im europäisch/westlichen Kulturkreis von oben links nach unten rechts. Wenn wir nun als Dokument alles innerhalb des Viewports nehmen, ist oben links der logische Punkt an dem unsere Wahrnehmung relevante Inhalte vermutet und anfängt zu erkennen. Nicht ohne Grund finden wir in der Regel das Logo genau dort. Wir haben hier eine elementare Gestaltungsregel aus unserem Kulturkreis. Wenn wir jetzt das “Oben” standardisieren oder für das Web interpretieren wollen, dann ist dies immer die erste Pixelreihe des Dokuments, direkt unter der Adresszeile des Browsers. Wir nutzen diese täglich — kennen sie also intuitiv.

1/3 fixed Header

Jetzt ist es zwar gut, wenn ich auf einer Seite lande auch erkennen kann, wo ich bin, wo relevante Steuerinhalte sind — aber, wenn ich Anfange Texte zu lesen, dann gehört an den oberen Rand nichts anderes mehr als das, für das ich das Medium gerade nutze — der Inhalt. Wenn meine Augen eine Zeile wiederfinden möchten, vielleicht scrolle ich sogar die ganze Zeit beim Lesen und nicht in Schüben, dann sucht das Auge den oberen Rand des Dokuments. Wenn dort ein fixed Header ist, dann muss das Auge weitersuchen. Das sind zwar nur Millisekunden, aber es gibt noch mehr Gründe als “schnelles Erfassen”.

Limitierte Viewports sind doom

Nicht alle haben ein 4k oder Cinema-Display, und — Überraschung: Gerade mobile Screens sind limitiert. Fixierte Elemente klauen hier relevanten Platz. Nichts ist gerade wichtiger, wenn ich einen Text lese — ich möchte nicht suchen, keine Toolbar und auch nicht über die Seite surfen. Wenn ich aber trotz Phablet nur durch ein kleines Fenster scrollen kann, ist das nervig und unpraktisch.

Wo kommen eigentlich eure User her und was machen sie? Ich wage mal eine Prognose: Sie kommen zu einem überwiegendem Anteil von Google, Facebook, Twitter, Email und Marketing. Überwiegende Direkteinstiege sind bei Webseiten nicht die Regel. Zweite Prognose: Sehr viele User besuchen oft nur eine Seite in einer Session.
Worauf ich hinaus will: Ja, ihr müsst euren Usern Orientierung und Nutzbarkeit im Sinne von Header, Menü etc. geben — aber das ist oft nur Nebensache. Es muss klar sein, wann diese Elemente schnell erreicht und wie diese genutzt werden können.

Primär habt ihr aber erst mal eure BesucherInnen dort wo ihr sie haben wollt. Bei euren Inhalten. Denen gehört der Fokus.

Was alleine vielleicht noch Sinn machen kann, und nicht sofort negativ auf die Nutzungserfahrung einwirkt, kann in Kombination ungewollte Auswirkungen haben. Wir kennen es: Fixed Header, Cookie Warnung, Social Bookmarks, App-Download-Banner und Newsletterlightbox. Seite geschlossen. Peinlich sind auch Toolbars am unteren Rand über nativen Toolbars.

Last but not least: Diese Patterns sind nicht die “Günstigsten”, wenn es um den “return of invest” geht. Damit meine ich, dass die Komplexität solcher Patterns in der Entwicklung sehr schnell unverhältnismäßig werden können. 
Vor allen Dingen dann, wenn es Transitionen gibt von einem ursprünglichen Zustand zu einem in fixierter Variante, inklusive Animation etc. Hier kommen gerade in der Feinabstimmung oft Herausforderungen auf das Entwicklungsteam zu, die vielleicht unerwartet sind. Gerade wenn man es “spot on” möchte. Diese komplette Komplexität geht verloren, wenn es einfach statisch bleibt.

Hast du einen Hammer…

…sieht alles aus wie ein Nagel. Schlechte Design-Pattern haben manchmal die unangenehme Angewohnheit sich zu vermehren und zum zentralen Thema in der Gestaltung einer Seite zu werden. Zum Beispiel bei Modal-Fenstern/Lightboxen und Slider/Caroussels — so aber auch beim Fixieren von Elementen. Fixed Header, Fixed Footer, Fixed Social Media Bar, Fixed Toolbar, Fixed Dialouges, Fixed Key Facts, Fixed Add To Basket usw.
Das heißt in unserem Fall — die Probleme multiplizieren sich. Im unangenehmsten Fall führt dies zum kompletten Totalschaden einer Seite. Von oben und unten werden Inhalte überdeckt, fixed inception, fixed Kaskaden, bloß nichts mehr von der Seite zu sehen. Dieses Phänomen ist bekannt und wird nicht wenig hämisch auf twitter und co. von der Szene kommentiert.

Wie es besser geht

Ja, der fixed Header ist dann gut, wenn ich ihn erwarte. Also wenn ich vom Lesen hin zum Navigieren switchen möchte. Wieso nicht einfach genau dann erst einblenden statt permanent? 
Medium (siehe Beispiel) ist hier wieder ein Vorbild. Kurzer Scroll nach oben = Wahrscheinlichkeit hoch nach Menü etc. zu wollen = Header eingeblendet. Scroll nach unten, Header wieder weg.

Interface wird unsichtbar, so soll es sein.

Weiterhin: Bei bestimmten Pattern und Features auf native Features des OS zurückgreifen, wenn möglich. Zum Beispiel sind die integrierten Social-Sharing-Optionen auf mobilen Betriebssystemen schon vorhanden und vom User gelernt — wieso Neue initiieren?

TL;DR

Fixed Header = Doof. Wenn doch Fixed Header, dann erst wenn wahrscheinlich benötigt.