Responsive Design
Die Seitenbeschreibungssprache HTML (Hypertext Markup Language) von Tim Berners-Lee war ursprünglich allein dazu gedacht, Dokumente für das Lesen am Computermonitor einigermaßen leserlich aufzubereiten – und zwar unabhängig von den technischen Eigenheiten des genutzten Rechners. Webseiten sahen in den Anfangsjahren des WWW entsprechend eher wie Fachzeitschriften-Artikel aus: viel Text, klitzekleine Bilder (wenn überhaupt), hier und da eine Überschrift, ein paar Leerzeilen zur Auflockerung und natürlich jede Menge blau gefärbte Hyperlinks. Das war’s. An Bandbreitenfresser wie Großformatfotos, Audios oder gar Videos war Mitte der 90er-Jahre zu Zeiten der 28-KB-Einwahlmodems nicht zu denken. Für Webdesigner in den damals jungen Online-Redaktionen war das alles schlicht nervig.
Zum Glück ist das lange her. HTML stellt längst ein breites Spektrum gestalterischer Optionen bereit. Vor allem die Trennung von Form und Inhalt per Cascading Style Sheets hat die Situation deutlich verbessert. Zwei Grundherausforderungen an das Webdesign allerdings sind geblieben und werden auf absehbare Zeit auch weiterhin Bestand haben:
1 Anders als im Printdesign gibt es im Webdesign kein fixes, für alle Rezipienten verlässlich gleich aussehendes Layout einzelner Seiten.
2 Die Vielfalt der Bildschirmgrößen und der Display-Auflösungen wächst beständig.
Die technische Antwort auf die wachsende Endgerätevielfalt ist das Responsive Webdesign, entworfen von Ethan Marcotte in einem Aufsatz für A List Apart in 2010. Er diagnostizierte schon damals mit einiger Weitsicht: »Mobile browsing is expected to outpace desktop-based access within three to five years. Two of the three dominant video game consoles have web browsers (…). We’re designing for mice and keyboards, for T9 keypads, for handheld game controllers, for touch interfaces. In short, we’re faced with a greater number of devices, input modes, and browsers than ever before.« Und entwickelte dazu auch gleich die passende Therapie: Seitenlayouts, die sich automatisiert an die jeweiligen Monitorabmessungen beziehungsweise an die jeweilige Display-Auflösung anpassen. Vereinfacht gesagt werden dazu in der Website-Programmierung typische Schwellenwerte (Breakpoints) für gängige Monitorbreiten beziehungsweise -höhen festgelegt, an denen ein Seitenlayout – abhängig vom Display des Endgeräts – dann jeweils neu umbricht: Hat ein Seitenlayout in der Desktop-Version beispielsweise ein vierspaltiges Seitenraster (für Monitore mit mindestens 1.024 Pixeln in der Breite), dann wird es für ein Tabletdisplay an einem definierten Breakpoint (beispielsweise ab einer Monitorbreite von 768 Pixeln) zweispaltig umbrochen. Bei noch kleinerem Bildschirm, etwa auf einem Smartphone (mit 320 Pixeln in der Breite), wird die Seite als Einspalter angezeigt.
Abb. 16:Die Content-Komponenten einer Desktopseite werden auf mobilen Endgeräten in strikt vertikaler Folge angeordnet. Quelle: Google, deutschlandfunk.de, eigene Screenshots.
Rechtsbündige Spalten rutschen dabei in der schmaleren Version in der Regel unter die linksbündigen Spalten; je kleiner der Bildschirm, desto länger also die umbrochene Seite. Wie das praktisch aussieht, kann sich jeder am Desktop-Rechner anschauen: Man ruft eine Website auf, etwa www.hannover.de, verschmälert dann das Browserfenster und der Umbruch passt sich an die veränderte Fensterbreite an. Vorausgesetzt, die betrachtete Website ist »responsive« programmiert, was für die hannoversche Stadt-Website der Fall ist.
Was folgt daraus fürs Website-Layout?
Website-Navigation ist dann optimal, wenn sie den Nutzerinnen als Aufgabe gar nicht mehr bewusst ist. Wer intuitiv von A nach B und von B nach C navigieren kann, ohne dabei über den besten Weg nachdenken zu müssen, wird das immer als angenehm empfinden. Manchem mag das vielleicht als haarspaltende Sekundenzählerei erscheinen, aber im Web sind Sekundenvorteile sehr schnell Wettbewerbsvorteile. Der Online-Shopping-Gigant Amazon beispielsweise hat einmal ausgerechnet, dass eine um eine Sekunde längere Ladezeit jährlich etwa 1,6 Milliarden US-Dollar geringeren Jahresumsatz bedeutet. Ob diese Zahlen so stimmen, lässt sich kaum überprüfen. Unter dem Strich allerdings ist unstrittig: Alles, was die Geduld der Nutzer strapaziert, reduziert Kontaktzeit und kostet letztlich bares Geld.
Positionserwartungen für Desktop-Sites
Wenn die nutzerseitig investierte Zeit für das Scannen der Inhalte knapp ist, dann lautet die erste Empfehlung: Standardkomponenten sollten genau dort stehen, wo sie von den Nutzern erwartet werden. Erwartungskonformität ist folglich das A und O, sie unterstützt die schnelle Orientierung – und gehört deshalb zu den wichtigsten Usability-Faktoren im Webdesign. Nachzulesen ist das in der DIN-Norm EN 9241-110 über die Grundsätze der Dialoggestaltung für Software-Oberflächen.
Der Usability-Forscher Michael Bernard befasste sich bereits in den Nullerjahren intensiv mit den Konturen des Website-Schemas und befragte damals in mehreren Studien weit über 1.000 Testpersonen, an welchen Positionen sie typische Site-Komponenten auf einer Desktopsite üblicherweise erwarten. Um die Platzierungserwartungen herauszufinden, wurden die Bildschirmflächen dazu in 56 Zellen eingeteilt, und die Probanden sollten benennen, in welcher dieser Zellen sie die einzelnen Seiten-Elemente üblicherweise suchen würden. In seiner ersten Studie aus dem Jahr 2001 befragte Bernard 346 Testpersonen und unterteilte seine Probandengruppe in Neulinge und erfahrene Web-User. Nebeneinander gestellt zeigen die Befunde, inwieweit generelle Platzierungserwartungen für Standardkomponenten in Abhängigkeit von der Nutzungserfahrung voneinander abweichen. Im Einzelnen ergab sich in der Untersuchung folgendes Bild (ausgewählte Befunde):
Abb. 17: Erwartete Position für den »Zurück zur Startseite«-Link im Jahr 2001 bei Nutzern mit weniger als einem Jahr Internet-Erfahrung (links) und bei Nutzern mit drei und mehr Jahren Internet-Erfahrung (rechts); das Blau in den Zellen ist auf den Ergebnisbildern umso dunkler, je öfter die betreffende Zelle von den Probanden als »erwartete Position« angegeben wurde. Quelle: surl.org (nicht mehr im Netz)
Abb. 18: Erwartete Position für die Hauptnavigationslinks. Quelle: surl.org (nicht mehr im Netz)
Abb. 19: Erwartete Position für die site-interne Suche. Quelle: surl.org (nicht mehr im Netz)
Abb. 20: Erwartete Position für Werbebanner. Quelle: surl.org (nicht mehr im Netz)
In unregelmäßigen Zeitabständen (2002 und 2004) wiederholte Bernard seine Tests und stellte dabei fest, dass sich im westlichen Kulturkreis, also dort, wo von links nach rechts gelesen wird, in vielen Fällen bereits ein deutlicher Konsens über das Website-Schema eingestellt hatte. Allerdings
