Responsive Webdesign

Seit einigen Jahren mischen Smartphones und Tablets den klassischen PC-Markt auf. Immer mehr Menschen gehen mit ihren mobilen Geräten ins Internet. Diesem Trend versucht OTTO mit diversen geräteoptimierten Shops sowie hybriden Apps gerecht zu werden. Daraus resultiert eine nicht zu unterschätzende Design-, Code- und damit auch Feature-Fragmentierung.

Seit 2010 gibt es aber auch einen anderen Ansatz, um auf die Multi-Device Problematik einzugehen, und zwar Responsive Webdesign. Zum ersten Mal wurde der Begriff von Ethan Marcotte in einem Artikel für das Magazin A List Apart verwendet. Er beschreibt ihn dort wie folgt:

„Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.“

Aus technischer Sicht bedeutet das ganz konkret: Eine einzige HTML Struktur mit dazugehörigem CSS für alle Endgeräte, also keine Fragmentierung mehr. Besonders interessant wird Responsive Webdesign unter dem Gesichtspunkt, dass die Grenzen zwischen den Geräten zunehmend verschwimmen.

Aus diesem Grund haben wir uns im Rahmen einer Product Discovery mit diesem Thema beschäftigt. Ziel war es, Responsive Webdesign kennen zu lernen, herauszufinden ob es möglich ist, einen großen Shop wie otto.de responsive umzusetzen, und wie das überhaupt geht. Die Discovery wurde von einem kleinen Team bestehend aus Designern (User Experience, Visual und Interaction), Entwicklern und einem Produktmanager durchgeführt. Während der Discovery entstand ein mehrere Seiten umfassender Prototyp ohne Backend Anbindung.

Der Werkzeugkasten, um eine Website grundsätzlich responsive umzusetzen, lässt sich auf wenige Punkte herunterbrechen:

  • Den Viewport richtig setzen – Mobile Browser rendern eine HTML Seite auf eine imaginäre, desktopähnliche Bildschirmbreite und passen sie durch Herauszoomen auf die tatsächliche Breite an, wenn der Viewport nicht wie folgt gesetzt ist<meta name="viewport" content="width=device-width, initial-scale=1.0">width=device-width setzt die Breite des zu renderden Viewports auf die tatsächliche Breites des Geräts und Initial-scale=1.0 stellt den Zoom auf 100%
  • Media Queries – Mit Media Queries lassen sich Breakpoints, also die Punkte an denen sich das Layout einer Seite verändert, im CSS umsetzen. Eine Media Query hierfür sieht zum Beispiel so aus:@media (min-width:  768px) {
    /*Reguläre CSS Anweisungen*/ }
    Alle im @media Block definierten CSS Anweisungen interpretiert der Browser nur, wenn sein Viewport mindestens 768 Pixel breit ist.
  • Relative Größen – Neben dem pixelgenauen Design sind auch die pixelgenauen Größenangaben im CSS überholt. Um die Anpassungsfähigkeit insbesondere innerhalb der Breakpoints zu gewährleisten, werden Pixel als Maßeinheit durch Prozent, em bzw. rem ersetzt.

Die genannten Techniken lassen sich je nach Anspruch (Performance, Bildoptimierung usw.) beliebig erweitern, aber diese drei finden auf jeder responsive Seite Verwendung.

Während der Prototypenentwicklung war eine der größten Herausforderungen keine technische, sondern die veränderte Arbeitsweise. Die ersten Wireframes wurden wie bisher gewohnt im Voraus von den Designern entworfen und den Entwicklern zur Umsetzung übergeben. Schnell traten bei der Entwicklung aus dem Design resultierende Probleme auf. Einige Elemente des Layouts ließen sich über die Breakpoints hinweg nicht mit ein und derselben HTML Struktur realisieren. Grund hierfür war, dass den Designern logischerweise der technische Blick auf ihr Layout fehlte.

Um daraus resultierende Codedoppelungen – aus Performancesicht nicht zu empfehlen – zu vermeiden, arbeiteten Designer und Entwickler fortan schon zu einem frühen Zeitpunkt enger zusammen. Eine gemeinsame Scribble Session, in der weitere Wireframes erstellt wurden, erwies sich als sehr guter Ansatz. So konnten die Entwickler schon frühzeitig auf technische Limitationen hinweisen und es entstanden gut umsetzbare Layouts. Die engere Zusammenarbeit hörte mit den erstellten Wireframes aber nicht auf. Auch während der Programmierung fand ein ständiger Austausch statt, da einige technische Probleme bei der Umsetzung des Layouts erst während der Entwicklung auffielen.

Als größte technische Herausforderung stellte sich das Thema Client-Performance heraus. Besonders mobile Geräte hatten mit der Rendering Performance Probleme. Als Grund dafür konnten wir den DOM Tree identifizieren. Für eine normale Desktop Seite ist er meist sehr groß, so auch bei unserem Prototypen. Zwar stellen wir in unserem Prototypen für kleine Breakpoints Inhalte verkürzt dar, blenden sie aber nur mittels display:none aus. Der DOM Tree wird dadurch also nicht kürzer. Das Problem bei einem großen DOM Tree ist, dass seine Berechnung logischerweise länger dauert als bei einem kleinen DOM Tree. Hinzu kommt noch, dass ein Gerät mit wenig Rechenleistung, wie zum Beispiel ein Smartphone, natürlich auch unabhängig von der Größe des DOM Trees länger für dessen Berechnung braucht als eines mit viel Rechenleistung. Zusammengefasst bedeutet dies, dass ein schwaches Gerät einen langen DOM Tree bekommt, der eventuell für seine Bildschirmgröße nicht anzuzeigende Elemente enthält und für dessen Berechnung es viel Zeit braucht.

Das ist nicht optimal, da sich die initiale Seitenladezeit durch lange Renderingzeit verlängert. Außerdem kann es  auch nach dem ersten Laden der Seite durch Repaints bzw. Reflows zu teilweisen bzw. kompletten Neuberechnungen des DOM Trees kommen. Gerade Reflows – die zum Beispiel durch einen Orientation Change ausgelöst werden – in Kombination mit einem langen DOM Tree erzeugen auf schwachen Geräten meist ein unschönes Ruckeln beim Neuzeichnen. Dieses Problem lässt sich am einfachsten dadurch lösen, dass im HTML wirklich nur die, für das jeweilige Gerät, benötigten Elemente vorhanden sind. Übertragen auf die HTML Struktur bedeutet dies, dass initial nur die Elemente vorhanden sind, die auf dem kleinsten Breakpoint dargestellt und bei Bedarf die restlichen Elemente nachgeladen werden. Dieser Ansatz ist nur beim Verkürzen von Inhalten anzuwenden, da sich die grundlegende Struktur bei Responsive Design nicht verändern sollte. Außerdem darf SEO relevanter Content natürlich nicht nachgeladen werden, sondern muss immer vorhanden sein.

Wir haben aus der Discovery jede Menge neue Erfahrungen und Erkenntnisse zum Thema Responsive Webdesign mitgenommen. Es gibt zwar noch Themen wie zum Beispiel Performance, Bilderoptimierung oder SEO, in denen wir den heiligen Gral noch nicht gefunden haben; aber grundsätzlich glauben wir, dass eine Umsetzung auch für einen großen Shop wie otto.de möglich ist. Die Vorteile von Responsive Design liegen klar auf der Hand: Eine einheitliche User Experience über alle Geräte hinweg mit nur einem zu pflegenden bzw. zu erweiternden Code, der auch für zukünftige Geräte nutzbar ist, klingt traumhaft. Ein Traum der durchaus Realität werden könnte.

Jan Klecka schloss 2013 seine Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei OTTO erfolgreich ab und arbeitet seitdem im hauseigenen E-Commerce als Entwickler.

Tagged with: , ,
Veröffentlicht in Development
5 comments on “Responsive Webdesign
  1. Responsive Webdesign ist ein relativ einfacher und unkomplizierter Weg, die verschiedenen Geräte anzusprechen. Allerdings geht man beim Webdesign mit Responsive Design davon aus, dass die Kunden auf mobiler und der Desktop Version die gleichen Informationen und Möglichkeiten haben wollen. Meistens könnten und sollten die Desktop Versionen aber viel umfangreicher gestaltet werden.

    • Jan Klecka sagt:

      Grundsätzlich hast du mit deiner Annahme recht. Allerdings sollte ich darüber nachdenken ob die Informationen bzw. Möglichkeiten wirklich so wichtig sind, wenn ich sie für mobile Kunden einfach nicht zugänglich machen möchte.
      Es gibt aber durchaus Anwendungsfälle wo es Sinn machen kann mobilen Nutzern bestimmte Informationen und Möglichkeiten vor zu enthalten. Zum Beispiel um Datenvolumen bei der Benutzung der Seite zu sparen oder die Performance für schwache Geräte zu optimieren. Um diese Anwendungsfälle abzudecken, wäre ein Lösungsansatz eine Basisversion der Seite zu definieren, die immer ausgeliefert wird. Diese Basisversion enthielte eine Feature Detection (Bildschrimbreite, DPI, Latenz usw.) an Hand der dann entschieden werden kann ob weitere Informationen bzw. Möglichkeiten nachgeladen werden.

  2. Ich glaube, dass die Annahme schon ganz richtig ist! Denn letztendlich ist es, wie du schon richtig erkannt hast, eine Frage des Nutzungskontextes. Aber woher weiß man, was der User wann möchte? Nur weil er Mobil unterwegs ist, heißt es schließlich nicht das er auch Grundsätzlich einen anderen Nutzungskontext hat.

    Ich frage mich vielmehr was denn die Erwartungshaltung des Users ist? Bisher kennt der User, das so: Er geht auf eine Webseite und findet dort entsprechend auch die Inhalte der Webseite. Und genau das sollte der User dann auch bekommen! Nun ist es leider so, dass die Webseite auf mobilen Geräten nicht besonders gut funktionieren. Sei es, weil die Performance schlecht ist oder die Webseite insgesamt einfach schlecht zu benutzen ist. Und da kommt RWD eigentlich ins Spiel, es ermöglicht es uns die Webseite so anzupassen, dass sie auch auf mobilen Geräten gut zu benutzen ist. Die Performance muss man dann natürlich noch Optimierung ganz unabhängig vom RWD. (Ich erwähne das nur, damit nicht der Eindruck entsteht, dass man mit dem RWD auch automatisch performant ist.)

    Es gibt sicher Fälle, in den es, wie Jan es schon sagte Sinn macht von unterschiedlichen Nutzungskontexten auszugehen. Allerdings glaube ich, dass das Ausnahmen sind. Sollte das nicht der Fall sein, dann sollten diese Funktionen bzw. die Anwendungen dediziert erreichbar sein bzw. als eigenständige App realisiert werden.

    Wer lässt sich schon gerne bevormunden? Ich stelle mir das grauenvoll vor, wenn ich eine Webseite grundsätzlich anders verwenden muss nur weil ich gerade mobil unterwegs bin. Dann müsste ich eine Webseite zukünftig wohl 3-4 mal neu kennen lernen, nur weil ich mal mit Smartphone, mal mit dem Tablet, PC oder doch mit dem Fernseher auf der Webseite bin.

  3. Bernd sagt:

    Herzlichen Glückwunsch noch mal zum erfolgreichen Launch von Lhotse. Ich bin sehr froh, dass alles so gut verlaufen zu sein scheint.

    Bin auch schon mächtig gespannt, auf das Responsive Design des Shops.

  4. […] nach responsive Prinzipien investiert hat, ist es nun soweit. In einem eigenen Beitrag im Otto-Developer-Blog werden ausführlich Herangehensweise und Herausforderungen bei diesem massiven Projekt geschildert. […]

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: