Responsive-Webdesign-Tutorial (Vorwort, Einleitung, Kapitel 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

Vergleich: statisches, mobiles und reaktionsfähiges Layout (Vorteile und Nachteile)

Kapitel 9 umfasst den Kriterienvergleich und erläutert die Vor- und Nachteile der jeweiligen Lösungen. Abschnitt 10.1 fasst die gewonnenen Erkenntnisse tabellarisch zusammen und gibt Handlungsempfehlungen, welche Lösung bei welchem Schwerpunkt vorzuziehen ist.

Dieser Abschnitt behandelt vor allem Argumente, d.h. die Vor- und Nachteile (Pro und Kontra), die für/gegen Responsive Webdesign (Prototyp C), eigene mobile Website (Prototyp B) und (klassisches) statisches Layout (Prototyp A) sprechen. Ausgewertet wurden dabei die Prototypen aus Kapitel 4 bis 8, Literatur und auch zahlreiche – meist kritische – Onlinequellen.

9.1. Flexibilität des Designs (Nachhaltigkeit)

Erstes Unterscheidungsmerkmal ist die Gerätevielfalt, die mit einem Layout angesprochen werden kann – und damit auch die unterschiedlichen Auflösungen, auf denen das Layout (gut) funktioniert.

Prototyp C funktioniert sowohl für mobile Besuche(r), wie auch am Desktop (siehe letzten zwei Abbildungen, Kap. 8). Um diese beiden Besuchergruppen anzusprechen, benötigt man alternativ Prototyp A und B zusammen, die je nach Gerät gewählt bzw. angezeigt werden.

Zillgens betont im Zusammenhang mit Responsive Webdesign die Rückbesinnung auf flexible Layouts (die „immer“ schon möglich waren).

Gleichzeitig werden mobile Geräte immer wichtiger, bei immer höheren Zugriffszahlen. Ein reaktionsfähiges Layout funktioniert dabei – im Idealfall – bereits auf allen (aktuellen) Geräten.

Zillgens bringt den Begriff „Nachhaltigkeit“ ins Spiel und betont auch die steigende Gerätevielfalt (zukünftige Geräte):

Für Nachhaltigkeit sorgt das Responsive Webdesign durch die flexible Ausrichtung der Website, die auf die Vielzahl aktueller und noch kommender Geräte, Bildschirme und Nutzerszenarien ausgerichtet ist. Wichtig ist in diesem Zusammenhang auch hervorzuheben, dass Smartphone, Tablet & Co. nicht mehr nur Zweitgerät sind, sondern schon heute für eine stetig wachsende Zahl von Nutzern die erste Wahl für die Internetnutzung sind.

Im Vergleich dazu gibt es bei statischen Layouts gar keine Anpassungen, d.h. es reagiert nicht auf die Bildschirmgröße. Ein mobiles Layout ist meist auch statisch und hinsichtlich der Breite auf einen „gemeinsamen Nenner“ ausgerichtet (siehe Bsp. aus Kapitel 7).

Eine wenig optimale Umsetzung im Responsive Webdesign kann zu Verwirrung beim Benutzer führen (etwa wenn das Navigationsmenü ausgeblendet wird; Bsp: http://www.catswhocode.com/blog/ - gültig im Dez. 2013). Hier stellt sich die Frage, ob der Benutzer dann nicht lieber die „Desktop-Sicht“ sehen würde, d.h. ohne die Anpassungen durch Media Queries bzw. ohne die Skalierung über das Meta-Tag zu viewport.

Wird ein eigenes mobiles Layout gestaltet, kann dieses mit der Desktop-Ansicht („Klassisches Layout“) verlinkt werden (und umgekehrt, = Crosslinking). Dem Benutzer wird damit die Möglichkeit gegeben, alternativ zur „normalen“ Ansicht zu wechseln (wenn ihm dieses lieber ist). Diese Verlinkungen müssen allerdings auch gewartet (oder durch Programmierung automatisiert) werden.

9.2. Kontrolle über das Design

In Abschnitt 1.1 wurde der Begriff „Papierdenken“ vorgestellt. Dabei wird eine Webseite ähnlich einem Blatt Papier gestaltet und Elemente exakt positioniert.

Wie breit etwa der Navigationsbereich ist, wird in den statischen Layouts (Prototyp A und B) fix definiert (z.B. 200px), im reaktionsfähigen Layout ist dieser – innerhalb gewisser Grenzen – dynamisch größer oder kleiner (im Bsp. 22,9167%, mind. 17rem).

Maximale Kontrolle kann das reaktionsfähige Layout nicht bieten – wie groß Elemente erscheinen (und wo sie positioniert werden), wird dem Browser überlassen. Unter dem Aspekt der maximalen Kontrolle „gewinnt“ das statische Layout (Desktop-Ansicht oder statisches mobiles Layout).

9.3. User Experience

Mobile Geräte haben Vorteile und bieten Funktionen, die es am Desktop häufig nicht gibt (z.B. Positionsbestimmung mit GPS, Kamera, Mikrofon, Bewegungssensor). Um diese Funktionen nutzen zu können, muss i.d.R. sogar auf eine native mobile App zurückgegriffen werden (was allerdings nicht Thema dieser Arbeit ist). Dabei ist Responsive Webdesign (RWD) nicht die Lösung für alle Probleme:

This is the danger in having tunnel vision and claiming responsive web design is the future: innovation in solutions outside of RWD might be overlooked.

Der Autor des Artikels „Responsive Webdesign is Not the Future“ nennt als Beispiel die mobile App einer Bank, die die Handykamera zum Scannen von Bankschecks nutzt. Mit einer Website (gleichgültig, ob reaktionsfähig oder nicht) ist das nicht möglich. Hierbei handelt es sich aber vor allem um die Grenzen von Websites im Allgemeinen. Der Autor räumt jedoch ein:

Certainly, for types of websites with limited user interaction — such as informational sites, blogs and news sites — responsive web design is a good, and often very practical, solution.

Solche „informational sites“ haben häufig lange Texte – genau hier liegt auch ein großer Vorteil von reaktionsfähigen Layouts. Diese verhindern horizontales Scrollen, Zoomen bzw. Vergrößern/Verkleinern der Ansicht. Große Buttons (durch Media Queries geändert) erleichtern die Navigation. Ein statisches Layout erfüllt diese Anforderungen nur, wenn es nicht zu breit für die Bildschirmauflösung ist.

Die Prototypen sind mit Ausnahme der Bildergalerie als Content-Sites („informational sites“) zu werten, in diesem Fall ist ein reaktionsfähiges Layout also gut geeignet.

9.4. Möglichkeiten im Inhaltsbereich

Die Gestaltung einer mobilen Website zwingt Betreiber oft dazu, sich auf das Wesentliche zu konzentrieren, wie in Abschnitt 1.5 gezeigt wurde (übersichtlicher, klare Strukturen). In diesem Zusammenhang kann man auch von Kontrolle im Inhaltsbereich (im Vergleich zum Design in Abschnitt 9.2) sprechen, wo eine separate mobile Website die größten Möglichkeiten bietet.

Bei einer eigenen mobilen Website lässt sich der komplette Inhalt auf den mobilen Kontext zuschneiden. Texte können über Schreibstil und Länge angepasst werden, Bilder werden bereits in passender – kleiner – Größe geladen. Es werden nur die JavaScript- und CSS-Codes vom Server geladen, die tatsächlich notwendig sind. Das führt im Idealfall zu schnelleren Ladezeiten und benötigt weniger Rechenzeit am Gerät

Verwendet man stattdessen ein reaktionsfähiges Layout, stehen alle Mittel zur Verfügung, die CSS (und JavaScript) zur Anpassung bietet. In Prototyp C werden zunächst kleine Bilder geladen, größere bei Bedarf (also wenn der Bildschirm groß genug ist) mit einem kleinen JavaScript nachgeladen (= Progressive Enhancement).

Eine ähnliche Lösung verfolgt die Library Adaptive Images. Über JavaScript wird die Auflösung ermittelt und ein Cookie gesetzt. Anfragen zu den Bildern (.jpg) werden vom Webserver an ein PHP-Skript weitergeleitet (über eine .htaccess-Datei konfiguriert). Dieses erkennt anhand des Cookies die Auflösung und liefert ein passend skaliertes Bild aus. Bei fehlenden Cookie-Headern wird der User Agent ausgewertet. Somit handelt es beim Laden der Bilder um eine Mischlösung aus Browserweiche (nur User Agent erkennen) und JavaScript-Unterstützung.

9.5. Wirtschaftlichkeit (Erstellung und Wartung)

Das Thema Wirtschaftlichkeit bezieht sich auf die Erstellung und laufende Wartung einer Website, d.h. auf Kosten und Dauer.)

Ein reaktionsfähiges Design benötigt eine andere Vorgehensweise bei der Entwicklung, wie in Abschnitt 4.2 gezeigt wurde. Grafiker und Designer müssen in mehreren Zyklen zusammenarbeiten, was meist mehrere Entwürfe und Anpassungen zur Folge hat. Eine längere Umsetzungsdauer führt auch zu höheren Kosten (Arbeitszeit). Noch teurer als ein Responsive Design ist allerdings die Erstellung und Wartung einer separaten mobilen Website. Texte, Bilder und Medien müssen dabei oft doppelt erstellt und eingepflegt werden. Am günstigsten ist das statische Desktop-Layout. Vor dem Projektstart sollte jedenfalls der „return on investment“ berücksichtigt werden.

Der Vorteil beim reaktionsfähigen Layout liegt in der gemeinsamen Code-Basis (HTML / CSS / JavaScript), bei Änderungen (Updates) muss nur ein Code angepasst werden. Dieser muss allerdings auf wesentlich mehr Endgeräten, Auflösungen bzw. Browser-Versionen getestet werden (als dies bei statischen Layouts notwendig ist). Zur längeren Planungs- und Implementierungsphase kommt somit auch noch eine längere Testphase, was sich in höheren Kosten niederschlägt

Beim Thema Wirtschaftlichkeit ist ein statisches Desktop-Layout die günstigste, eine separate mobile Website i.d.R. die teuerste Lösung (lässt man den „return on investment“ unberücksichtigt).

9.6. Performance: Geschwindigkeit und (indirekte) Kosten

Ein weiteres Unterscheidungsmerkmal ist die Ladezeit, wobei hier nur die Zeit der Datenübertragung beachtet wird (d.h. unterschiedliche Rechenleistung der Geräte außer Acht gelassen).

Viele reaktionsfähige Websites werden leider so gestaltet (bad practice), dass Elemente auf kleinen Displays ausgeblendet werden. Sinnvollerweise sollten Elemente aber eingeblendet werden (= Progressive Enhancement). So werden in Prototyp C größere Bilder in der Galerie nur bei Bedarf geladen.

Responsive Layouts laden unabhängig vom Endgerät dieselben HTML-, CSS- und JavaScript-Codes. Die Lösung des Ausblendens führt dann zur gleichen Ladezeit wie am Desktop – bei weniger angezeigtem Content. Dabei kann kann eine Website durch zu lange Ladezeiten sogar Besucher verlieren (höhere Absprungrate), was bei einem Onlineshop zu einem entgangenen Gewinn führen kann

Dagegen lädt eine separate mobile Website nur das absolut Notwendigste an Code und Inhalt (Texte, Bilder, Medien), optimiert somit Ladezeit und minimiert den dazu notwendigen Datentransfer.

Bei kleinen Websites wie den vorgestellten Prototypen ist das Thema Ladezeit wenig relevant, auch ist bei einem kleinen Unternehmen (fiktive Firma aus dem Bereich der Fotografie) wahrscheinlich nicht mit sehr vielen Besuchern zu rechnen.

9.7. Kompatibilität (Browser-Support)

Wichtiges Kernelement im Responsive Webdesign sind die in Abschnitt 3.3 vorgestellten Media Queries. Diese funktionieren im Mozilla Firefox ab Version 3.5 (Juni 2009), im Internet Explorer allerdings erst ab Version 9 (März 2011). Mittlerweile werden Media Queries in allen gängigen Browsern unterstützt.

Im Internet Explorer 8 und darunter lässt sich ein eingeschränkter Support für Media Queries über die JavaScript-Bibliothek „Respond.js“ nachrüsten.

Ist Kompatibilität ein wichtiger Punkt, kann eine Auftrennung in Desktop- und Mobile-Layout sinnvoll sein. Während in der Desktop-Version mehr auf Kompatibilität geachtet wird, kann das Mobile-Layout neuere Technologien einsetzen (z.B. semantische Auszeichnung mit HTML5).

Das Design von Prototyp C funktioniert im Internet Explorer 8 praktisch gar nicht, was vor allem an der fehlenden Unterstützung für rem¹Anm.: Für rem können Sie mit einem Fallback in CSS Abhilfe schaffen, indem Sie jeweils nacheinander px und rem verwenden. Z.B.:
font-size: 10px; /* Fallback */
font-size: 1rem;
Die erste Zeile funktioniert in allen Browsern und setzt die Schriftgröße auf 10px. Ein älterer Webbrowser ignoriert die unbekannte zweite Zeile (1rem) und behält die Schriftgröße bei 10px. liegt. Prototyp A und B funktionieren ohne Probleme, lediglich die runden Ecken werden nicht dargestellt (Progressive Enhancement).

9.8. Suchmaschinenoptimierung

Weitere Kriterien können die Möglichkeiten in der Suchmaschinenoptimierung (SEO / search engine optimization) und Werbetauglichkeit eines Layouts sein.

Ausgangspunkt vieler SEO-Überlegungen ist eine Empfehlung von Google für Responsive Webdesign bei der Optimierung für mobile Geräte:

Google recommends webmasters follow the industry best practice of using responsive web design, namely serving the same HTML for all devices and using only CSS media queries to decide the rendering on each device.

Ein weiterer Vorteil ist, dass es keine separaten URLs für Desktop- und Mobile-Ansicht gibt. Eine Webseite erhält somit die gesamte eingehende „Link-Power“ (sich vererbender PageRank bei Google).