Nicht immer Responsive Web Design

Responsive Web Design ist in aller Munde und wird derzeit sehr stark gehyped. Auch Luke W ist Befürworter von Responsive Web Design - dennoch hatte er gute Gründe für die mobile Variante von Bagcheck ein eigenes Interface zu entwickeln. Diese Gründe liefert er in seinem Blog-Post "Why Separate Mobile & Desktop Web Pages?", die ich hier kurz aufgreifen möchte:

Oberstes Gebot bei dem Projekt war Site Performance und Geschwindigkeit. Unter diesen Prämissen - und der generellen Philosopie: "Nur so viel wie nötig" - findet Luke vier Gründe:

Sourcecode Reihenfolge

Der Kern von Responsive Web Design ist die Auslieferung einer einzigen (HTML-) Website-Variante an alle Geräte. Die Anzeige des Contents passt sich dann entsprechend den Möglichkeiten des Gerätes an (in der Regel durch CSS gesteuert).

HTML Markup hat aber eine Reihenfolge, die bestimmt, in welcher Reihenfolge was gerendert wird. Diese kann natürlich mittels JavaScript manipuliert werden - aber dies zuverlässig für alle Geräte umzusetzen ist eine herausfordernde Aufgabe.

Ein einfaches Beispiel ist ein Site-weites Navigationsmenü. Während es auf Desktop-Größen in der Regel oben angeordnet ist, ist es für mobile Geräte, insbesondere in Smartphone Größe üblich, diese Menüs ans Ende der Seite zu rendern.

Medien

Responsive Web Design setzt sich auch mit Medien auseinander. Grafiken und Videos werden auf kleineren Displays kleiner dargestellt. Allerdings ist skalieren hier nicht unbedingt die beste Wahl. Erstens werden dabei unnötig Große Dateien übertragen (gerade an mobile Geräte mit evtl. nicht besonders schneller Anbindung). 

Anm.: Hier kommt zum Beispiel auch die iOS Retina--Display Diskussion ins Gespräch, da es sich für diese Geräte anbietet - genügend Bandbreite vorausgesetzt - hochauflösende Grafiken nachzuladen. (Siehe z.B. What the New iPad’s Retina Display Means for Web Developers. - Danke für den Tipp Moritz)

Zweitens kann es durchaus sinnvoll sein, dass man die Medien für unterschiedliche Display-Größen unterschiedlich aufbereitet: Große Grafiken mit vielen Details vs. kleine Grafiken mit weniger Details, also einem anders gewählten Ausschnitt.

URL-Struktur

Anm. vorab: Wie ich in Mobile und Content oder besser Content vs. Mobile? geschrieben habe, gibt es nur ein Web und ein und der selbe Content sollte auch unter ein und der selben URL zu erreichen sein. Aber:

Es gibt Situationen, in denen eine eigene URL-Struktur für kleinere Screens durchaus Sinn ergibt: Luke nennt als Beispiel eine Seite mit User-Content, Kommentaren dazu, Updates und "Likes". Dies passt alles zusammen gut auf eine Desktop-Seite und ist zum Beispiel unter der URL bagcheck.com/bag/7811 zu erreichen. Für kleinere Bildschirme ist es aber durchaus sinnvoll, einige der Informationen auf Unterseiten auszulagern, die dann unter den URLs bagcheck.com/bag/7811/updates, bagcheck.com/bag/7811/comments und bagcheck.com/bag/7811/likes zu erreichen sind.

Anwendungsdesign

Ein letzter entscheidender Punkt, der zu bedenken ist, ist folgender: Auf kleinen Displays kann es sinnvoll sein, längere Tasks von einer Seite auf mehrere zu verteilen.