Rheinwerk Computing < openbook >

 
Inhaltsverzeichnis
Vorwort
1 Prinzipien des modernen Webdesigns
2 Projektmanagement
3 Konzeption und Strategie
4 Responsive Webdesign
5 Informationsarchitektur
6 Gestaltungsgrundlagen
7 Screendesign
8 Layout und Raster
9 Farbe im Webdesign
10 Typografie
11 Bilder und Grafiken
12 Navigations- und Interaktionsdesign
13 Webdesign-Stile und -Trends
14 Animationen
15 Website-Typen
16 Tipps, Tricks und Tools
Stichwortverzeichnis

Download:
- Beispieldateien, ca. 3.64 MB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Webdesign von Martin Hahn
Das Handbuch zur Webgestaltung
Buch: Webdesign

Webdesign
Pfeil 4 Responsive Webdesign
Pfeil 4.1 Einleitung – und sie bewegen sich doch
Pfeil 4.1.1 Neue Geräte und Bildschirmgrößen
Pfeil 4.1.2 Zurück in die Zukunft – von flexibel zu statisch zu flexibel
Pfeil 4.1.3 Ganzheitliche Flexibilität – es betrifft alle
Pfeil 4.2 Responsive Strategie – Mobile first und Content first
Pfeil 4.2.1 Adaptive Layout vs. Responsive Layout
Pfeil 4.2.2 Mobile oder Content – wer ist der Erste?
Pfeil 4.2.3 Graceful Degradation vs. Progressive Enhancement
Pfeil 4.3 Ein neuer Workflow
Pfeil 4.3.1 Der traditionelle Workflow
Pfeil 4.3.2 Der responsive Workflow
Pfeil 4.4 Bestandteile einer responsiven Webseite
Pfeil 4.4.1 Flexible Raster
Pfeil 4.4.2 Media Queries
Pfeil 4.4.3 Flexible Bilder, Typografie und Weiteres
Pfeil 4.5 Tipps zur Umsetzung
Pfeil 4.5.1 HTML-Prototyping
Pfeil 4.5.2 Testen
 
Zum Seitenanfang

4.3    Ein neuer Workflow Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 
Zum Seitenanfang

4.3.1    Der traditionelle Workflow Zur vorigen ÜberschriftZur nächsten Überschrift

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.

Aus der Praxis

Regelmäßig habe ich die »Diskussion« über den Projektablauf: Erst das Design, dann die Umsetzung oder das Design bei der Umsetzung.
Und es hat sich gezeigt, wenn zuerst das Design gestaltet wird (manchmal tatsächlich noch ausführlich in Photoshop, weil Kunde und Agentur es so möchten), wird viel Zeit und Arbeit in »Pixel«-Details gesteckt. Bei der technischen Umsetzung und der Betrachtung im Browser sind dann aber meistens all diese Details unwichtig. Der Kunde kann klicken und achtet auf andere Sachen, aber kaum noch auf die ihm vorher ach so wichtigen Design-Aspekte. Was ich dagegen mache? Versuche aufzuklären! Erklären, warum wir uns nicht ewig in Photoshop über einzelne kleine Details unterhalten sollten, sondern recht früh in die Umsetzung gehen sollten. Denn sieht der Kunde die Webseite erst einmal im Browser, sind ganz schnell Feinheiten am Design vergessen oder unwichtig geworden. Kaum kann er scrollen und klicken, fallen visuelle Aspekte viel weniger auf. Daher: so früh wie möglich in den Browser wechseln!

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.

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

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.

 
Zum Seitenanfang

4.3.2    Der responsive Workflow Zur vorigen ÜberschriftZur nächsten Überschrift

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

Vorteile eines responsiven Workflows

Neben dem Ergebnis, einer responsiven Webseite, liegt der Vorteil vor allem in der Erstellung:

  • (Konzeptionelle) Fehler bzw. mögliche Fehlerquellen können bei einem Prototyp frühzeitig erkannt und rechtzeitig angepasst werden, nicht erst in der fertigen Webseite wie beim klassischen Workflow.

  • Das Design folgt der Funktion (den Inhalten und deren Bedeutung), nicht andersherum.

  • Kompatibilitäten, Funktionalitäten, Animationen und Effekte lassen sich frühzeitig testen.

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

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

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.

Prototypen

Dem Einsatz von Prototypen kommt eine besondere Bedeutung in der Entwicklung responsiver Webseiten zu. Mehr zu interaktiven Prototypen lesen Sie in Abschnitt 8.4.5, »Interaktive Prototypen«.

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.

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.

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.

Design-Module

Beim responsiven Workflow werden Design-Module gestaltet und keine vollständigen Screendesigns mehr. Module können z. B. Elemente wie die Navigationsleisten, Suchfelder, Buttons und Inhaltsblöcke sein. Diese Module lassen sich dann flexibel in der Seite einsetzen.

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.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Webdesign Webdesign
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: HTML5 und CSS3
HTML5 und CSS3


Zum Rheinwerk-Shop: Praxisbuch Usability und UX
Praxisbuch Usability und UX


Zum Rheinwerk-Shop: Responsive Webdesign
Responsive Webdesign


Zum Rheinwerk-Shop: Website-Konzeption und Relaunch
Website-Konzeption und Relaunch


Zum Rheinwerk-Shop: UX Writing und Microcopy
UX Writing und Microcopy


Zum Rheinwerk-Shop: WordPress 5
WordPress 5


Zum Rheinwerk-Shop: Stile & Looks
Stile & Looks


Zum Rheinwerk-Shop: Digitale Illustration
Digitale Illustration


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2020
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 
[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern