Responsive Webdesign

Wireframe der Storefront

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.