A weblog by pogrzeba*net

Responsive Design schrittweise modularisieren – so geht’s

getatomic

Den Unterschied, ob eine Designagentur und ein IT-Dienstleister wirklich profunde Erfahrungen mit Responsive Web Design (RWD) haben, zeigt sich – viel mehr als noch in der reinen Design- und Umsetzungsqualität und dem Beherrschen von allen gängigen HTML5/CSS3-Spielereien – vor allem im analytischen, objektorientierten Ansatz, mit dem die Elemente der Responsive Website konsequent in seine kleinsten Bestandteile aufgesplittet werden.

Dieser Ansatz ist vergleichbar mit einem Legobaukasten, bei dem große Objekte aus verschiedensten kleinen, selbstähnlichen Bausteinen zusammengesetzt sind.

Responsive Design besteht aus:

  • Seiten (Pages), aus denen die Online-Applikation, Website o.a. besteht
  • Module auf diesen Seiten – beispielsweise Content-Container, Teaser-Module, Navigations- und Interaktionsmodule
  • Elemente, aus denen wiederum diese Module bestehen – beispielsweise Buttons, Formularelemente oder Content-Elemente
  • Atome, die den Elementen zugrunde liegen – beispielsweise Bilder, Typodefinitionen wie Headlines, Sublines, Fließtext, Farbdefinitionen oder Standardabstände

Die Multi-Device-Anforderungen von Responsive-Lösungen und die verschiedenen Dimensionen in Konzept und Design, die damit einhergehen, erfordern ein iteratives Vorgehen und die permanente Notwendigkeit, das Konzept von einzelnen Website-Elementen im Bedarfsfall rückwirkend anpassen zu können. Für die Entwicklungsaufwände einer Responsive Web-Lösung ist es daher essentiell, dass die Programmierung konsequent auf Basis eines solchen modularen Baukastens erfolgt. Um dies zu erreichen, ist ein schrittweises Vorgehen sinnvoll – das im folgenden beschrieben ist:

Schritt 1: Module und Atome identifizieren

Der erste Schritt, der bereits im Grobdesign erfolgen sollte, ist die Gliederung der Website in Seitentypen: welche Gemeinsamkeiten gibt es, welche Seitentypen bauen aufeinander auf?

Konzepter und Design müssen von Beginn an versuchen, gedanklich alle Module zu erfassen: Gliederung in Modulgruppen und – auch hier – Identifikation von Modulvarianten, die einen gemeinsamen Nenner haben oder die vererbbar sind.

Wichtig beim atomaren Aufteilen des Designs:

  • Objektorientiertheit: Gliederung der Module in deren kleinste Bausteine
  • Vererbung: Abhängigkeiten und Gemeinsamkeiten zwischen Atomen identifizieren
  • Katalogisierung: Gruppierung und Vereinheitlichung in einem Elementekatalog

Hier sollte bereits eine enge Abstimmung zwischen Konzept, Design und Entwicklung stattfinden – ein falsches atomares Design kann zu eklantanten Mehraufwänden bei der Entwicklung führen:

Keine Atome:
Die ganz klassische Herangehensweise, bei der die Frontend-Entwicklung gar nicht objektorientiert angegangen wird und im schlimmsten Fall jede Seite ihre eigenen CSS-Definitionen zugrunde liegen hat, führt dazu, dass im Falle von kleinen Konzept- und Designanpassungen während der Entwicklung (was bei Responsive sehr häufig passiert) jede Änderung einzeln nachgezogen werden muss. In der Praxis führt das häufig dazu, dass Webanwendungen wild und chaotisch wachsen und Anpassungen in Form von bypassartigen Wucherungen umgesetzt werden.

Zu viele Atome:
Die Web-Anwendung wird in seine Module aufgeteilt, die jedoch in sich so speziell konzipiert sind, dass eine Reduktion auf ein überschaubares Set von Elementen nicht möglich scheint. Vielmehr ist es am Ende so, dass so gut wie jedes Bestandteil der Website ein eigenes Atom sein muss. Der Grund: Das Element hat ganz bestimmte individuelle Eigenschaften, die nur es selbst und kein anderes Element hat – zum Beispiel Dropdown-Module, die kontextuell so spezifiziert sind, dass eine Wiederverwendbarkeit schwierig ist. Das Resultat: Eine unüberschaubare Anzahl von Elementen und schwer in den Griff zu bekommenden Sonderfällen. Auch wenn dies konzeptionell vom Design offensichtlich gut begründet werden kann, ist es für eine effiziente Entwicklung doch nicht der richtige Weg.

Zu wenig Atome:
Die konzeptionelle Aufteilung geht nicht konsequent bis zur letzten Ebene, sondern betrachtet Elemente als kleinste Bestandteile, ohne sie weiter runter zu brechen. Das Ergebnis sind zu wenig Atome, was dazu führt, dass wirklich atomar zu definierende Bestandteile wie Standardabstände und Schriftdefinitionen nicht losgelöst definiiert werden, sondern zu oft in Elemente eingekapselt sind. Ein schönes Beispiel hierfür sind Schriftgrößen von Navigations-Texten, die sich oftmals responsive anders verhalten wie andere Schrifttypen auf der Website. Das Ergebnis beim Skalieren: Ein unschöner Schriftenfriedhof.

Schritt 2: Living Styleguide

Das Ziel von Responsive Webdesign ist es, so früh wie möglich in HTML-Format zu produzieren – wie hier ausführlich dargelegt.

Warum ist das so? Zu Zeiten von Websites mit statischem Design in einer festen Auflösung („wir optimieren unsere Website für Internet Explorer Version null-punkt-acht und tausendvierundzwanzig Pixel“) konnte man die Designdetails und die Feinausrichtung der Seitenelemente einer Website sehr gut in Form eines statischen Photoshop-Designs beurteilen und kundenseitig abnehmen. In Zeiten von plattform- und deviceübergreifender Nutzung jedoch gibt es keine feste Auflösung mehr, nur noch die dynamische Anpassung an beliebige Auflösungsgrößen (Viewports), auf Basis derer die Website gerade dargestellt wird.

Die vielfältigen Seiteneffekte von in sich verschachtelten Objekten mit jeweils eigenem fluiden Verhalten, eingebettet in ein Seitenraster, das ebenfalls bei den definierten Breakpoints dynamisch umbricht, können hier immens sein. Erfahrungsgemäß stellt man während einer responsiven Designentwicklung fest, dass man, egal, wie tief man die Abhängigkeiten von Objektskalierungen, -Grenzen, -Ausrichtungen etc. versucht zu durchdenken, man am Ende nie genügend Fantasie hat, um an wirklich alle Sonderfälle und möglichen Auswirkungen zu denken.

Dies ist insbesondere dann der Fall, wenn die Konzept- und Designagentur stoisch darauf beharrt, das Design in Form von statischen Screendesigns in Photoshop zu liefern und abnehmen zu lassen – wie früher immer erfolgt.

Probleme tauchen bei Responsive Designs meist nah an den Grenzbereichen der Breakpoints auf, das heißt an den Stellen, wo Elemente umbrochen werden, mehrzeilig werden, weitere Spalten hinzukommen (oder wegfallen), um so die Platz zu schaffen für die optimierte Darstellung der größer oder kleiner gewordenen Oberfläche. Statische Photoshop-Seitenlayouts mit einer idealen Screengröße und Blindtexten können eben nicht das unschöne Umbrechen von Content- und Navigationselementen knapp unter oder über den Breakpoints antizipieren.

Erfahrungsgemäß passieren bei statischen Designs oftmals die gleichen Layout-Faux-Pas rund um die Breakpoints – beispielsweise in Form von:

  • Buttons mit zwei- oder dreizeiligen Texten
  • Navigationsleisten (zum Beispiel eine linke Subnavigation) mit unschön umbrochenen Zeilen
  • Drei- bis vierzeilige Headlines auf Mobilgeräten, die den Seiteninhalt bis unter den Fold wegdrücken
  • Formulare, in denen zusammengehörige Elemente wie Radiobutton-Blöcke untereinander unschön umbrochen werden

All diese gestalterischen Ausprägungsformen eines dynamischen Responsive Designs können valide nur in einer Form geprüft werden – in HTML: Nur in der Form, in der die Elemente sich später auf der Website darstellen. Alles andere ist nur eine Trockenübung.

Solche HTML-Darstellungen von Seitenmodulen und -Elementen inklusive deren Responsive-Verhalten werden als Living Styleguides bezeichnet. Es gibt mittlerweile einige sehr gute Beispiele im Web für offen zur Verfügung stehende Living Styleguides von Marken, die Gestaltungselemente im Browser in finalem HTML5/CSS3 zeigen:

Diese und noch mehr zum Teil sehr anschauliche Beispiele kann man auf der Website Styleguides.io finden.

Schritt 3: Frontend-Unit-Testing, Feedback & Abnahme Living Styleguide

Der Vorteil eines Living Styleguides mit responsiver HTML5-Umsetzung von Atomen, Elementen und Seitenmodulen liegt vor allem auch darin, dass man frühzeitig frontendseitige Browser-Unittests durchführen kann, die von späteren Funktionstests losgekoppelt sind.

Zu prüfen, welche Design-Features in welchem Browser funkionieren und welche nicht, welche eingesetzten CSS3-Features in älteren Browsern noch laufen oder ob die Pixelgenauigkeit auch in kritischen Browsern wie IE 9 noch gewährleistet ist, kann – und sollte – so früh wie möglich durchgeführt werden. Responsive Testing ist sehr viel komplexer als herkömmliches Browsertesting, so dass man hier durch die zeitliche Entkopplung von frühen Unittests von finalen Funktionstests nur gewinnen kann.

Auch das Thema der Browsermatrix kann sehr viel flexibler und dynamischer gehandhabt werden: War sie früher eine feste initiale Kundenvorgabe, ist eine Browsermatrix heute eher ein dialogisches Abstimmungswerkzeug in der Kollaboration zwischen Kunde und Entwicklungspartner.

Schritt 4: Schrittweise Erweiterung des Living Styleguide

Nach Durchführung der Unit-Tests des User Interface und der Abnahme der Atome, Elemente und Module wird der Living Styleguide erfahrungsgemäß schrittweise weiterentwickelt.

Mit jeder der zum Teil zahlreichen Rücksprünge ins Feinkonzept während der Umsetzung wird die HTML-Basis der Website entsprechend angepasst. Daher heißt es auch Living Styleguide.

Schritt 5: Objektorientierte Entwicklung unter Anwendung der HTML-Atome, Elemente, Module

Im letzten Schritt – und auch das passiert in einem agilen Projekt im Idealfall iterativ und parallel – wird die Online-Applikation mit allen backend- und middleware-seitigen Anbindungen und Funktionalitäten entwickelt. Die Oberflächenelemente des User Interface liegen hierfür bereit – im Living Styleguide.

Similar posts