4.3    Ein neuer Workflow 

Die letzten Abschnitte haben es schon gezeigt: Responsive Webdesign verändert den Ablauf der Webseitenerstellung. Zunächst allerdings ein Blick zurück auf den jahrelang üblichen Workflow, der nach wie vor bei einigen Agenturen und Webdesignern immer noch genau so vonstattengeht.

 

4.3.1    Der traditionelle Workflow 

Im Mittelpunkt des traditionellen Workflows steht ein statisches Screendesign. Zuerst (meistens) als Photoshop-Datei und danach als statische Webseite mit einer festen Pixelbreite.

Nach einer Konzeption samt Inhaltsplanung ging es an die Gestaltung eines bis zum letzten Pixel ausgearbeiteten Screendesigns. Wenn es denn überhaupt eine detaillierte Planung vorher gab. Nicht selten, dass der Webdesigner nicht nur mit Platzhalterinhalten (sogenannten Blindtexten und -bildern) gearbeitet hat, sondern sich auch noch – während des Gestaltens – Gedanken machen musste über mögliche Inhalte. Viele Kunden woll(t)en erst einmal das Design sehen, um zu wissen, wofür sie Inhalte schreiben. (Finde den Fehler: Sie schreiben für das Design, nicht für die Benutzer.) Das Design wurde dann in mehreren Abstimmungsrunden »optimiert« – aber für was eigentlich, wenn nicht einmal die richtigen Inhalte vorhanden waren? Also wurde die Photoshop-Datei, vielleicht sogar mehrere Dateien, weil es ja mehrere Unterseiten gibt, und im Extremfall sogar JEDE Unterseite zuerst in Photoshop gestaltet. Als Ergebnis entstanden viele Screendesigns, die eher Gemälden glichen. Allesamt hübsch anzusehen, aber weit davon entfernt, innerhalb des Browsers in eine Interaktion mit einem Anwender zu treten. Dazu passt, dass Screendesigns sogar ausgedruckt wurden!

Diese Screendesigns wurden also pixelgenau gestaltet und waren die Vorlage für die Frontend-Umsetzung. Und sie wurden auch dankbar von den Entwicklern angenommen – genaue Vorgaben, die keinen großen Spielraum für Interpretationen lassen, was für eine schöne Welt! Genaue Vorgaben gab es übrigens auch zu Recht, haben Sie mal einen reinen Entwickler gestalten sehen? Nein, besser, das Design ist schon genau vorgegeben.

Also wurde das Design pixelgenau mit HTML und CSS umgesetzt, und wehe, es sah nicht in jedem Browser pixelgenau gleich aus. Daher wurde fleißig getestet und eventuell noch ein spannender (JavaScript-)Effekt eingebunden.

Abbildung 4.12    Der »alte« Workflow: Die einzelnen Disziplinen werden nacheinander abgearbeitet.

Diesen Ablauf nennt man auch Wasserfall. Eine Tätigkeit folgt auf die andere, Berührungspunkte zwischen den Disziplinen gab es lediglich bei der Übergabe oder an der Kaffeemaschine.

Dieser Workflow, so viel sollten Sie aus den bisherigen Seiten dieses Kapitels schon mitgenommen haben, ist nicht ohne Grund als veraltet zu bezeichnen. Was aber nicht heißt, dass dieser in freier Wildbahn nicht mehr vorkommt. Teilweise aus alter Gewohnheit, aus Unwissenheit über die neuen Möglichkeiten oder Unkenntnis der genauen Techniken wird immer noch auf diesen Workflow gesetzt – sowohl auf Kunden- als auch auf Agenturseite. Dazu kommt die Verständlichkeit der Prozessabläufe, die gut nachvollziehbar sind. Der lineare Ablauf mag auch vielen entgegenkommen, denn ein Zusammenarbeiten an einem Projekt verursacht auch immer vermehrt zwischenmenschliche Anforderungen.

Der traditionelle Workflow ist aber nicht mehr zeitgemäß. Er beachtet nicht die neuen Anforderungen an Webseiten durch unterschiedliche Geräte. Er kann Interaktionen, Effekte und Funktionalitäten nicht simulieren. Es findet kaum ein Miteinander der einzelnen Tätigkeitsbereiche statt (außer alle Aufgaben liegen in der Hand eines Einzelnen). Aber dies ist auch nicht verwunderlich, stammt er doch aus einer Zeit, als Desktop-Computer samt dazugehörigem externen Monitor die Regel waren.

 

4.3.2    Der responsive Workflow 

Die heutige Internetnutzung sieht anders aus. Unterschiedliche Bildschirmauflösungen gibt es wie Sand am Meer. Endgeräte heißen inzwischen Tablets und Smartphones, Netbooks und Notebooks und manchmal auch Apple Watch und vielleicht bald WebCar oder so ähnlich. Das Internet ist mobil geworden. Die Nutzung hat sich verändert. Auch die Nutzerschichten sind viel breiter geworden: von Jugendlichen mit dem Smartphone auf dem Schulhof bis hin zu Senioren mit dem Tablet auf dem Sofa und alle anderen irgendwo dazwischen.

»The biggest challenge in responsive design is not technical or visual, it's making your client understand what the web is actually about.«
Frontend-Developer Rik Schennink (twitter.com/rikschennink/status/397735883450748928)

Für sie alle soll eine Webseite zugänglich sein (siehe Abschnitt 1.3, »Webseiten für alle – Zugänglichkeit und Barrierefreiheit«), bedienbar, gut nutzbar, alle relevanten Informationen bereithalten. Dabei soll sie noch eine gute Figur abgeben (also optisch ansprechend sein) und ein gelungenes Nutzungserlebnis durch Effekt und Funktionalitäten liefern.

Hier kommt das strategische Vorgehen Content first (siehe Abschnitt 4.2, »Responsive Strategie – Mobile first und Content first«) ins Spiel. Auf den Workflow wirkt sich das so aus, dass es keinen typischen Wasserfall-Ablauf mehr gibt (oder geben sollte). Es entsteht vielmehr eine Art interdisziplinärer Kreislauf:

1. Konzeption
   (Rahmenbedingungen festlegen, Inhalte definieren usw.)

2. Inhalte und Wireframes erstellen

3. HTML-Prototyp erstellen

4. Testen/Korrekturschleifen

5. Look & Feel erarbeiten

6. zweiter HTML-Prototyp mit visuellen Effekten

7. Testen/Korrekturschleifen

8. (Einpflege ins CMS und) Launch

Dieser Ablauf läuft nicht zwangsläufig genauso ab. Aber die Vorgehensweise dürfte sich überall bei responsiven Workflows ähneln:

Abbildung 4.13    Design und Technik (und Konzeption) arbeiten zusammen und entwickeln Prototypen, die regelmäßig getestet werden.

Der große Unterschied ist, dass bei diesem Ablauf die technische Umsetzung wesentlich früher erfolgt. Die konkrete Anwendung, die Interaktion des Anwenders, kann so viel früher überprüft und angepasst werden, genauso eine Optimierung für unterschiedliche Geräte, Bildschirmauflösungen und Browser. Wird zu Beginn des ersten Prototyps sogar komplett auf eine visuelle Gestaltung verzichtet, liegt das Augenmerk vollständig auf den Inhalten und der Zugänglichkeit.

Das Design gestaltet jetzt keine genauen Screendesigns in Form von festen Seiten mehr, sondern eher einzelne Gestaltungselemente. Moodboards sind ein erstes hilfreiches Mittel, um das Look & Feel zu ermitteln. Style Tiles und Design-Styleguides legen die visuelle Richtung fest. Auf Moodboards, Style Tiles und Design-Styleguides gehe ich noch ausführlich in Kapitel 7, »Screendesign«, ein.

Abbildung 4.14    Die verschiedenen Frameworks zeigen den Einsatz von Modulen exemplarisch auf, so wie hier getuikit.com mit verschiedenen Buttongrößen. Ob man diese Vielfalt wirklich braucht, steht auf einem anderen Blatt.

Photoshop bleibt bei diesem Workflow nicht komplett außen vor, wird aber nur noch gezielt eingesetzt. Ein detailliert gestalteter Header mit vielen grafischen Einzelheiten, die sich nicht mehr mit CSS3 umsetzen lassen, wäre so ein Fall, in dem ein Bildbearbeitungsprogramm immer noch seine Bedeutung hat. Design und technische Umsetzung können so parallel erfolgen. Ein erhöhter Abstimmungsbedarf zwischen Screendesigner und Frontend-Entwickler ist die Folge. Sind beide Aufgabenbereiche in einer Person vereint, umso besser.

Die Herausforderungen, die der Wechsel zu einem responsiven Workflow mit sich bringt, sind nicht zu unterschätzen. Vermutlich auch ein Grund, warum sich dieser auch nach Jahren immer noch nicht flächendeckend durchgesetzt hat (wenn er es denn überhaupt jemals tun wird). Die Anforderungen an die Projektbeteiligten steigen. Der Kunde muss flexibler werden, mehr mitarbeiten, sich über Inhalte (und damit über die Ziele und Zielgruppen seiner Webseite) frühzeitig Gedanken machen, was ja grundsätzlich nicht verkehrt ist.

Aber auch die Umsetzenden sind mehr gefordert. Webseitenerstellung wird immer mehr zur Teamarbeit (was es eigentlich schon immer war). Projektmanager, Konzepter, Designer und Entwickler müssen Hand in Hand arbeiten, sich einbringen und ergänzen. Sind sie alles in einer Person, dann besteht sicherlich kein Abstimmungsbedarf (außer nach wie vor mit dem Kunden), aber die Anforderungen sind für einen Einzelnen sicherlich größer.

Die Ergebnisse eines responsiven Workflows sprechen im Idealfall aber für sich – in Form einer Webseite, die ihre Anwender glücklicher macht, weil sie in allen erdenklichen Situationen zugänglich und gut bedienbar ist.