Let it flow, mate

Im Zuge einer als Hilfestellung gedachten E-Mail, die ich nach Ablauf meiner Mitarbeit an einem sog. Responsive Projekt an den verantwortlichen Mitarbeiter der Agentur schrieb, wurde mir wiederholt deutlich, wie grundlegend sich der Workflow in derartigen Projekten von dem – immer noch sehr verbreiteten – Wasserfallprinzip unterscheidet. Und zwingend muss.

Responsive Web/Design im Abriss

Das Web an sich ist responsive. Eine ursprüngliche Intension der Hypertext Markup Language war/ist die Anzeige von Inhalten unabhängig von bestimmten Viewports/Geräten.

Die Einführung von fixen Layouts hat genau das pervertiert. Just war Web == Computer-Desktop, bzw. Computer-Monitor mit dezidierten Viewports. Und lange Zeit deckte sich die Annahme auch mit der Realität, respektive den technischen Möglichkeiten. Diese Realität haben Entwickler sowie Kunden über all die Jahre erlernt und vollständig verinnerlicht.

Im Grunde geht es beim Responsive Design um nichts anderes, als genau diese Denkweise zu durchbrechen und der ursprünglichen Intension von HTML wieder mehr Raum zu geben: Der Viewport- und geräteunabhängige Darstellung von Inhalten.

Denkweisen (Device-Driven, Content-Driven)

Erstaunlicherweise scheint es, dass auch in progressiven Entwicklerhirnen das Denken in fixen Viewports noch nicht ganz ausgestorben ist. Responsive Design wird oft verstanden als die Optimierung einer Webseite auf bestimmte Viewports von Geräten, die gerade aktuell sind. So findet man überall die üblichen Verdächtigen an media queries (320px, 768px, 1024px etc.pp), die sich an den aktuellen Platzhirschen auf dem Gerätemarkt orientieren. Der Fokus liegt in erster Linie auf einen bestimmten Zustand der Darstellung (Viewport) eines jeweiligen Gerätes.

Wodurch wir uns dann im Grunde mit den gleichen Problemen rumschlagen müssen wie zuvor bei den fixen Pixel-Layouts…

Nicht nur, das die unter dieser Prämisse erstellten Seiten heutzutage schneller veralten, als die Agentur/der Kunde “iphone/Galaxy” sagen kann (Stichwort: Marktzyklen),- wir erheben es faktisch zum Prinzip, den Großteil der Besucher/Geräte da draußen mit einem Achselzucken einfach als “unbekannt/nicht verifizierbar” sich selbst und ihren Möglichkeiten der Darstellung zu überlassen.

Im Web geht es um eine adäquate Darstellung von Inhalten. Unabhängig vom Ausgabegerät. Salopp gesagt: Wir sollten die Viewports dezidierter, bekannter Geräte vergessen, an Design vorerst gar nicht auch nur denken, die Inhalte/Komponenten der geplanten Seite genau studieren, inhaltliche HTML-Protoypen bauen, uns anschauen, wie sich die Inhalte in verschiedenen Viewports verhalten und auf dieser Grundlage konzeptionelle Entscheidungen treffen, welche Breakpoints an welcher Stelle sinnvoll sind.

Soweit das Ideal. All das oben gesagte wirft natürlich – gerade im Agenturalltag – viele Fragen auf: In welcher Form ist das mit den derzeitigen Projekt- und Entwicklungsabläufen umsetzbar? Muss der Designer jetzt HTML/CSS können? Wie erkläre ich dem Kunden, warum er nicht eine gemalte, grafisch bis ins Detail ausformulierte Ansicht seiner fertigen Webseite vor Begin der Produktion bekommt? Wie binde ich ihn ein in den Entwicklungsprozess?

Responsive Web ist nicht einfach. Im Gegenteil,- es ist komplex und kann zu Anfang ziemlich anstrengend sein. Man muss neue Wege gehen und immer wieder Entscheidungen in der laufenden Entwicklung treffen. Und – das muss man klar so sehen – es ist zumindest so lange zeit- und budgetaufwändiger, bis sich die veränderten Arbeitsweisen im Team etabliert haben. Zudem ist es schwer mit den gewohnten Konventionen zu brechen, die sich in der Vergangenheit vermeintlich bewährt haben (das gilt für Kunden ebenso).

Aufgabenverteilung im Team

Ein großer Unterschied zu konventionellen Projekten ist die Notwendigkeit die Rollen/Aufgabenteilung im Team neu zu definieren. Diese sind bislang in der Regel klar verteilt sind: Man hat einen Designer, der sich ausschließlich auf die Erstellung grafischer Mockups/Assets konzentriert und im Detail wenig/nichts über technische Beschränkungen oder Bedingungen der (responsive) HTML-Welt weiß. Und den Webentwickler, der die Designs in valides, voll zugängliches und effizientes HTML/CSS Markup verwandeln soll. Beide arbeiten im Kern mehr oder weniger unabhängig von einander (und i.d.R. auch nacheinander).

Dieses Wasserfallprinzip (Konzept -> Design -> Frontend -> Backend -> Release), funktioniert bei Responsive Projekten nicht, bzw. führt fast zwangsläufig in für alle schmerzhafte Sackgassen. In solchen Projekten ist es schon in der Konzeptionsphase zwingend erforderlich, technische Details zu berücksichtigen und inhaltliche Entscheidungen zu treffen. Mit einer konventionellen Arbeitsteilung, die einzelne Aufgaben der Reihe nach abarbeitet, ist dies nicht erreichbar.

Zugespitzt gesagt: der Designer in einem solchen Projekt muss technische Kenntnisse haben, wie sich Markup im HTML-Flow verhält und wo es technische Fallstricke gibt etc.pp. Aber er kann nicht Experte für alles mögliche gleichzeitig sein: Typografie, UX – und Interfacedesign, HTML, CSS etc.pp.

Der Workflow in Responsive Projekten ist dem Prinzip der agilen Webentwicklung sehr ähnlich. In beiden ist das interdiziplinäre Teamwork von größter Bedeutung. Projektleitung, Kunde, Texter, Designer und Entwickler müssen eng zusammenarbeiten. Die Arbeitsabläufe laufen nicht linear nacheinander ab, sondern bewegen sich in kurzen Zyklen, an deren Ende immer wieder getestet, Lösungen evaluiert und eruiert und gemeinsam Entscheidungen getroffen werden.

Grafische oder HTML Mockups?

Das führt unweigerlich zur Frage: Wie soll ein Designer einen technisch umsetzbaren Layoutentwurf erstellen, der alle Eventualitäten und Besonderheiten von Responsive Design Techniken vorausschauend berücksichtigt? Die Antwort ist so schlicht wie wichtig: Gar nicht!

Es ist unmöglich am Anfang eines Projektes (das ist i.d.R. ja der Zeitpunkt, an dem der Designer sein Grafikprogramm startet) die technischen sowie inhaltlichen Anforderungen zu berücksichtigen,- sie sind zu dem Zeitpunkt noch gar nicht bekannt. Auch macht es keinen Sinn, Stunden, Tage an Arbeitszeit damit zu verschwenden, um etwas zu erstellen, dass trotz größter Sorgfalt und fantastischen Einfällen trotzdem immer nur eines bleibt: ein Bild. Etwas, das nichts mit dem Medium zu tun hat, in dem das Ergebnis unserer Arbeit stattfinden wird.

Das ist auch des Pudel’s Kern: Wir entwickeln Webseiten/Webanwendungen. Demzufolge ist es naheliegend und sinnvoll sobald als möglich direkt in dem Medium zu arbeiten, in dem unsere Arbeit konsumiert wird/funktionieren soll. Das, was häufig als Design im Browser bezeichnet wird, bedeutet im Grunde nichts anderes, als dass wir zu dem frühstmöglichen Zeitpunkt der Entwicklung damit beginnen sollten, HTML-Prototypen zu bauen. Wir sollten keine Zeit (und somit Geld) dafür verschwenden, komplexe, statische Designs mühevoll in HTML nachzubauen. Um dann mitten in der Arbeit festzustellen, dass einzelne Designideen schlicht nicht funktionieren im HTML-Flow. Oder/und sich einfach als nicht benutzerfreundlich herstellen. Wie will man anhand einer statischen Grafik die Usability/UX einer Webseite testen, bzw. bewerten?

All das heißt übrigens nicht, dass Photoshop (oder besser: Fireworks) im Schrank und der Designer zu Hause bleiben kann ;-). Ich selber bspw. brauche grafische Scribbles um mir einen visuellen Eindruck machen zu können, ob ein Design in sich stimmig ist. Das möchte ich nicht erst im Prozess später entscheiden. Und es kann ebenfalls hilfreich sein, mit Hilfe von grafischen Wireframes an bestimmten Punkten der Entwicklung visuelle Ideen auszuprobieren. Auch initiale Sketches werden ggf. benötigt. Ob diese in einem Grafikprogramm oder mit Zettel und Stift erstellt werden, ist allein abhängig, womit man sich wohl fühlt.
Aber der Designer malt nicht mehr die Mastervorlage, an dem sich dann alle weiteren Entwicklungsschritte orientieren (müssen).

Alles schön und gut, aber der Kunde will sehen, wie seine Seite aussehen wird

Ein Knackpunkt, dem man bei richtiger Kommunikation (gerade bei größeren Auftraggebern) und Techniken oft beikommen kann.

Anstatt dem Kunden am Beginn des Projektes grafisch vollständig ausformulierte Layouts zu präsentieren, ist es sinnvoller mit sog. Style tiles zu arbeiten. Style tiles konzentrieren sich auf die grundsätzliche visuelle Sprache, die im Gespräch mit dem Kunden in einem ersten Schritt entwickelt wird. Abgebildet werden bspw. Farben, Schriften, einzelne Interface-Elemente die Relevanz für die CI haben, Link-Auszeichnung etc.pp. Diese Datei bildet die gestalterische Blaupause im späteren Designprozess.

Das wichtigste hieran: Das Design wird von der Entwicklung entkoppelt. Der Kunde erwartet in diesem Ansatz nicht eine 1:1 Umsetzung eines ausformulierten, grafischen Designs, wenn er einen HTML Entwicklungsstand gezeigt bekommt. Präsentiere ich dem Kunden zu Anfangs ein detailiertes, gemaltes Design, wird der Kunde immer enttäuscht sein bei Ansicht eines beliebigen Entwicklungsstandes. Einfach aus dem Grund, dass er – bewusst oder unbewusst – kontinuierlich vergleicht zwischen dem Bild, das ihm vorliegt und der aktuellen Ansicht des Prototypen. Er wird immer die Defizite sehen…

Ein beispielhafter Workflow und die daraus entstehenden Vorteile für das Team und den Kunden folgt in einem folgenden Beitrag.