Skip to content

Responsive Webdesign – Eine Herausforderung für Webdesigner

Beitrag von Christoph Zillgens

Seit Ethan Marcotte 2010 seine Grundzutaten des Responsive Web Design in einem A-List-Apart-Artikel vorgestellt hat, schritt die Entwicklung auf technischer Seite mächtig voran. Rund um Ethan drei Grundzutaten flexibles Grid, flexible Bilder und Mediaqueries haben sich mittlerweile einige »Best Practices« entwickelt.

Responsive Web Design, zu deutsch »reaktionsfähiges Webdesign« stellt aber nicht nur Webentwickler, sondern auch Webdesigner vor neue Herausforderungen. Denn die Geräte, mit denen wir Websites konsumieren, werden immer vielfältiger, z.B. in Bezug auf die Bildschirmgröße.

Diverse internetfähige Geräte mit verschiedenen Bildschirmgrößen

Abb. Diverse internetfähige Geräte mit verschiedenen Bildschirmgrößen

Um dieser Gerätevielfalt gerecht zu werden, müssen wir uns auf die Flexibilität des Webs rückbesinnen sowie einen verbesserten Workflow in Zusammenarbeit mit Entwicklern und Auftraggebern etablieren. Außerdem müssen wir unsere Annäherung an die Gestaltung dem Prozess anpassen. Diese Aspekte möchte ich im Folgenden näher erläutern.

Rückbesinnung auf Flexibilität

Responsive Webdesign ist kein aktueller Trend, sondern rückt vielmehr wieder das in den Vordergrund, was HTML-Dokumente seit jeher ausmacht: ihre Flexibilität. Öffnen wir ein »nacktes« HTML-Dokument im Browser, egal welches Dokument, egal welcher Browser, dann passen sich die Inhalte automatisch an die Fenstergröße an. Webdokumente sind also bereits von Natur aus reaktionsfähig.

Erst im Laufe der Jahre haben wir Webdesigner Websites mit unserem Wunsch nach mehr Gestaltung und dem damit verbundenen Bestreben nach Kontrolle jener Anpassungsfähigkeit beraubt. Statt die vorhandene Flexibilität zu nutzen und zu tolerieren, haben wir dem Web die aus der Printwelt vertrauten Gestaltungsprozesse übergestülpt, indem wir feste Breiten definiert und somit ursprünglich reaktionsfähige Webdokumente zu starren Seiten degradiert haben. Das soll an dieser Stelle keine Vorwurf sein, es ist einfach Teil des Lernprozesses im Umgang mit diesem jungen Medium.

Unsere aus dem Print übernommenen Werkzeuge haben uns dabei sicherlich tatkräftig unterstützt. Öffnen wir ein Grafikprogramm wie Photoshop, ist die erste Amtshandlung das Eingeben von Breiten- und Höhenangaben und somit die Festlegung auf fixe Größen. Bevor wir überhaupt richtig anfangen, werden wir gezwungen, erste Annahmen über die Dimensionen zu treffen. Wenn wir dann unsere digitale Leinwand mit Pixeln »befüllen«, erhalten wir schließlich ein starres Gemälde, das zwar eine Webseite suggeriert, aber dennoch weit entfernt ist von einem dynamischen und flexiblen Dokument. Auf diese Weise bewegen wir uns weiter weg von einer reaktionsfähigen Website.

Probleme des klassischen Wasserfallprozesses

Im Laufe Webgeschichte hat sich der sogenannte Wasserfallprozess etabliert, der grob nach einem Schema à la Planung -> Design -> Umsetzung -> Veröffentlichung abläuft.

Abb. Ein herkömmlicher Wasserfallprozess

Nach einer statischen Gestaltungsphase folgt also die Entwicklungsphase, in der es vor allem darauf ankommt, das vom Auftraggeber »abgesegnete« Layout bestmöglich in die Browser zu übertragen. Mittlerweile hat sich zwar schon sehr weit herumgesprochen, dass Websites nicht in jedem Browser gleich aussehen müssen. Dennoch wird mit einem statischen Website-Entwurf eine Erwartungshaltung geweckt, die nicht dem späteren Ergebnis entsprechen wird. Der Webdesigner schaufelt sich eine Grube, in die er dann freimütig hinein springt:

  • Waren bisher schon die statischen Abbildungen eines Webentwurfs im Grafikprogramm nur ein mäßiger Ersatz für eine interaktive Website, so kommt jetzt noch erschwerend hinzu, dass die unterschiedliche Darstellung auf den verschiedenen Geräten anhand eines statischen Entwurfs nicht visualisiert werden kann.
  • Diese Herangehensweise verhindert auch für den Designer eine vernünftige Auseinandersetzung mit dem grundlegenden Problem. Denn im Grafikprogramm werden eventuelle Schwachstellen eines Layouts im Zusammenhang mit kleineren oder größeren Displays nicht offensichtlich.
  • Das Festlegen von Umbruchpunkten in der Gestaltungsphase ohne vorherige Tests im Browser gleicht einem Ratespiel
  • Auch bestimmte Elemente wie Schrift und Schriftgröße können nur vernünftig im Browser und auf den verschiedenen Geräten bewertet werden. Auch das kann ein Grafikprogramm nicht leisten.

Wir müssen also unsere bestehende Arbeitsabläufe anpassen. Wie aber können wir mehr Flexibilität in den Gestaltungsprozess bringen?

Dieser Beitrag hat 177 Kommentare

  1. ich suche gerade ein tool für die leichtere umsetzung von responsive. photoshop erscheint mir dafür ein wenig zu steif.

  2. Danke für den Artikel. Bleibt nur zu hoffen, dass Kunden sich auf diese Art des Workflows einlassen können, was vermutlich gerade bei Konzernen etwas schwierig werden dürfte, da die Art der Abstimmung bisher meistens ja eher das Gegenteil von informell ist.

    In dem Zusammenhang würde ich gerne auf einen Artikel von Luke Wroblewski zum Thema “Mobile First“ hinweisen. Er schlug vor inzwischen drei Jahren vor, sich bei der Entwicklung von Websites und Anwendungen, die auch auf den kleinen Screens mobiler Endgeräte laufen sollen, zuerst auf die Konzeption und das Design für die kleinere Darstellung zu fokussieren und erst anschließend die größeren Auflösungen zu bedienen. Das hat zugleich auch den Vorteil, dass auch die größeren Screens von der Konzentration auf die Kernfunktionalitäten und einen optimierten Ablauf profitieren.

    Mein derzeitiger Favorit ist https://coworkchicago.com/, ich selbst habe vor kurzem mal eine Seite für einen Rechtsanwalt für Versicherungsrecht gemacht (https://ra-fassl.de/, für die ich das responsive Framework Foundation verwendet habe. Alternativ wäre Bootstrap von twitter noch ein interessanter Startpunkt.

    Ehrlich gesagt bin ich aber schon wieder dabei, mich von dem Gedanken von responsive Design im ursprünglichen Sinn (also komplett skalierbare Bilder etc.) zu verabschieden und mehr in die Richtung von https://framelessgrid.com/ zu gehen.

  3. Wie die praktische Arbeit aussehen kann, wenn man dem Kunden keine Grafiken sondern HTML-Entwürfe vorlegt, beschreibt Matt Griffin sehr praxisnah auf A List Apart. Er klärt mit einem Kunden zuerst die Hierarchie der Website und entwickelt dann einen Rohentwurf, der bereits reaktionsfähig ist und auf unterschiedlichen Geräten beurteilt werden kann.

  4. Ich arbeite seit einiger Zeit an einem großen Projekt für eine süddeutsche Bank.
    Das Thema RDW finde super spannend. Die ERfahrungen in diesem Projekt sind sehr nach an dem obigen Artikel.
    Für eigene Projekte setze ich dieses Framework ein: https://www.getskeleton.com/

Kommentare sind geschlossen.

An den Anfang scrollen