Das Web ist allgegenwärtig

Eine aufregende Zeit, eine gewaltige Revolution ist es, die wir heute als Designer und Entwickler des Webs erleben. Die unglaubliche Vielfalt an Geräten, die heute einen Zugang zum Internet bieten, stellen uns vor ganz neue Herausforderungen und zugleich berauben sie uns jeglicher Kontrolle.

Wisst ihr noch…

Früher, da war alles viel einfacher. Da hatten wir noch das Sagen. Sorglos und selbstsicher bastelten wir Webseiten und Webapplikationen mit fixen Breiten, gemäß der am häufigsten anzutreffenden Bildschirmauflösung jener Zeit. Nach einer groben Skizzierungsphase wechselten wir schon bald zu einem Grafikprogramm und erstellten zuerst ein Dokument mit einer fixen Breite. Dadurch fühlten wir uns sicher, denn wir wussten was uns erwarten würde. Schon konnten wir entspannt die Kopfhörer aufsetzen und uns mehrere Stunden lang im Designprozess verlieren.

Doch dann kam alles anders. Seit dem Jahr 2007 revolutionierten Smartphones und Tablets das Internet und seine Nutzung. Vorbei sind die Zeiten von 1024 x 768px und 960er Grids, denn die Bildschirmauflösung ist heutzutage wohl eine der unzuverlässigsten Variablen überhaupt. Ständig erscheinen neue, glänzende Geräte mit eigenen Bildschirmauflösungen und Pixeldichten und alle bieten sie Zugang zu unseren Webseiten. Dieser Trend zeigt uns, dass das Web nicht “mobile” oder “desktop” ist. Es gibt kein “mobile web”, es gibt kein “desktop web”, es gibt nur ein “ubiquitous web” — ein allgegenwärtiges Web.

Wie sollen wir aber nun für diese Vielfalt an Geräten effizient und sinnvoll designen? Richtig, ihr wisst es ja schon…

Responsive Web Design

Webseiten und Webapplikationen mit fixen Breiten sind vom Aussterben bedroht, und das ist gut so. Endlich besinnen wir uns der flexiblen Natur des Web und beginnen, sie für uns zu nutzen. Mit Responsive Web Design sind wir in der Lage, unsere Webinhalte optimal auf allen Geräten darzustellen.

Durch den Einsatz von CSS Media Queries schmiegen sich unsere Layouts an jegliche Bildschirmbreite und garantieren eine bessere User Experience. Responsive Web Design ist eine sinnvolle Lösung, die gute Ergebnisse hervorbringen kann. Trotzdem sind weder Konzeption, noch Umsetzung einfach zu meistern. Unser alter Workflow scheint einfach nicht mehr effizient genug zu sein und schnell steigen die Aufwände ins Unermessliche. Sehen wir uns an warum.

Der alte Workflow

Immer mehr Designer und Entwickler haben bereits an “responsive-projects” gearbeitet und ich bin fest davon überzeugt, dass einige von euch die selben Erfahrungen gemacht haben, wie wir hier bei intuio. Nach einer ausgiebigen User Research setzt man sich hin und lässt seiner Kreativität freien Lauf. Am Papier entstehen aufregende Konzepte für drei bis fünf verschiedene Bildschirmgrößen, die nach einer groben Skizzierung in Form von Wireframes detailliert und verfeinert werden. Es kommen die üblichen Werkzeuge zum Einsatz: Papier & Bleistift, Omnigraffle oder Balsamiq, Photoshop oder Illustrator etc. Responsive Web Design scheint ja eigentlich doch nicht so schwierig zu sein. Bis zur zweiten Iteration.

Iterieren und Verfeinern

Das erste Konzept ist von Natur aus nie perfekt und Anpassungen und Änderungen sind immer erforderlich. Bisher konnte man damit umgehen. Es bedeutete zwar mehrere Files im Grafikeditor anzupassen, jedoch war es ein überschaubarer und kalkulierbarer Aufwand. Für eine Applikation mit 5 unterschiedlichen UI-Screens musste man also 5 Zeichnungen verändern, kein Weltuntergang. Responsive Web Design verursacht im Vergleich aber viel höhere Aufwände.

4 x 5 = 20

Nehmen wir ein klassisches Szenario als Beispiel. Der Kunde möchte die Applikation mit ihren 5 UI-Screens für Smartphones, Tablets im Hochformat, Tablets im Querformat und Desktop-Geräte optimieren. Das bedeutet, wir haben es mit 3 Breakpoints, sowie 4 UI-Varianten zu tun und schon zeichnen wir nicht mehr 5 sondern 4 x 5 = 20 Screens. Folgende Iterationen und Anpassungen machen dann schon gleich sehr viel weniger Spaß. Häufig durchläuft ein Konzept mindestens zwei bis drei Iterationen und durch die neue Gerätevielfalt steigen die Aufwände ins Unermessliche. Wie sollen wir es nun schaffen, diese zu bewältigen?

Der neue Workflow

Die effizienteste Methode zur Umsetzung von “responsive-projects” ist schlichtweg das Designen im Browser. Sehen wir uns an, wie unser neuer Workflow hier bei intuio aussieht.

Research, Research, Research!

Am Anfang, keine Frage, steht natürlich eine ausgiebige User Research. Ohne diese können wir unsere Zielgruppe nicht einschätzen und laufen Gefahr, Designentscheidungen aus dem Bauch heraus zu treffen. Das geht in den meisten Fällen nach hinten los.

Mobile First

Sobald wir genügend Informationen über die Benutzer gesammelt haben, setzen wir uns hin und konzipieren und skizzieren auf Whiteboards und Papier. Wir gehen immer “mobile first” vor, sprich wir designen zuerst für den kleinsten Bildschirm und arbeiten uns dann nach oben. Dies hat den Vorteil, dass man Inhalte & Funktionalitäten, sowie deren Hierarchie sehr genau analysieren und oft auch in Frage stellen muss. Das Ergebnis ist ein fokussiertes und effizientes User Interface.

“Mobile first” ist unseres Erachtens zwar die beste Designmethode, aber man darf sich nicht Scheuklappen aufsetzen und stur immer nur für eine Bildschirmgröße konzipieren. So geht es leider auch nicht, denn man geht ein hohes Risiko ein, spät im Designprozess drauf zu kommen, dass gewisse Dinge auf größeren Geräten einfach nicht funktionieren. Daher empfehlen wir beim Designen immer alle Bildschirmgrößen im Auge zu behalten.

Einige Papierblöcke später und mit einer groben Idee im Kopf, setzen wir uns hin und fangen an HTML und CSS zu coden. HTML zwingt uns, Inhalte und ihre Hierarchie klar zu definieren. Wir arbeiten stets mit echten Daten, denn “Lorem Ipsum…” ist ein falscher Freund. Sobald die Struktur fest steht, geht es schon munter weiter im CSS. Mit der Hilfe eines guten Frameworks schaffen wir es, in ungefähr der selben Zeit Wireframes im Browser zu erstellen, wie wir es früher in Grafikprogrammen getan haben. Sofort zeigt sich ein klarer Vorteil: “What you see is what you get”, es gibt keine Diskrepanzen mehr zwischen dem Entwurf und dem programmierten Endprodukt. Der Kunde wird von Anfang an in die Entwicklung mit eingebunden, weshalb keine falschen Hoffnungen aufkommen können. Unerwartete Enttäuschungen durch das Endprodukt werden so konsequent ausgeschlossen. Nebenbei können die Konzepte jederzeit in allen Browsern und für jede Bildschirmbreite, von 0 bis 2560 Pixel getestet werden.

Nach der Präsentation ist vor der Präsentation

Voll bepackt mit wertvollem Kundenfeedback stürzen wir uns wieder in den Code und verändern, verfeinern und verbessern unsere Konzepte. Dabei haben wir bemerkt, dass wir HTML/CSS Modifikationen viel einfacher und schneller durchführen können, da oft nur wenige Zeilen Code umgeschrieben, anstatt zwanzig verschiedene Wireframes umgezeichnet werden müssen.

Wir sind also wesentlich flexibler, effizienter und können dem Kunden Wireframes präsentieren, die bereits sehr viel näher am Endprodukt sind, als es gezeichnete Bilder je sein werden. Was sagen unsere Kunden? Sie lieben es.

Alte Freundschaften sollte man pflegen

Doch Photoshop und andere Grafikeditoren sind nicht überflüssig geworden, ganz im Gegenteil. Nachdem das Konzept vom Kunden abgesegnet wurde, dürfen sie, unsere geliebten alten Freunde, wieder glänzen. Mit ihrer Hilfe definieren wir visuellen Stil und Charakter der zukünftigen Webseite, bzw. Webapplikation. Wir erstellen Farbpaletten, kombinieren Texturen, designen UI-Elemente und versehen das Endprodukt mit einer ansprechenden Ästhetik. Der Feinschliff eben.

Prototyping

Neben Wireframes und Visual Designs, können wir im Browser mit Hilfe von JavaScript auch relativ einfach Interaktionen prototypisch abbilden. Und dies ist ein äußerst wichtiger Punkt. Schließlich designen wir in den meisten Fällen keine statischen Webseiten, sondern viel mehr Webapplikationen mit komplexen User Interfaces und hoher Interaktivität. Würden wir die wichtigsten Interaktionsmuster nicht im Prototypen umsetzen, so wäre es deutlich schwieriger, dem Kunden unsere Konzepte zu verdeutlichen.

Design im Browser hat einen weiteren großen Vorteil: wir produzieren keine Wegwerf-Deliverables, sondern können dabei zusehen, wie unsere groben Wireframes erwachsen werden, Interaktivität erlangen und mit einem schönen visuellen Stil geschmückt werden. Sobald sie bereit sind verwandeln wir sie in Templates, um sie dann problemlos in das große Ganze einfließen zu lassen.

Fazit

Responsive Web Design ist ein wertvolles Werkzeug, mit dem wir die Möglichkeit haben, flexible, geräteunabhängige und zukunftssichere Designs zu erstellen. Es bringt uns aber nicht nur neue Möglichkeiten, sondern stellt uns auch vor neue Herausforderungen. Wenn wir den Designprozess im Browser abwickeln, können wir viele dieser Herausforderungen meistern. Anstatt viele Wegwerf-Deliverables zu produzieren, die nur der Veranschaulichung von Konzepten dienen, entwickeln wir schon während der Entwurfsphase interaktive und stilvoll gestaltete Prototypen, die dann dem finalen Produkt einverleibt werden können.

Weiterführende Links

• A Dao of Web Design, John Allsopp
• Responsive Web Design, Ethan Marcotte
• Content Choreography, Trent Walton
• Mobile First, Luke Wroblewski
• Mocking Up Is Hard To Do, Matt Griffin
• Style Tiles, Samantha Warren
• Präsentation über Responsive Design (PDF, 7.2 MB), intuio

2 Responses

1. Claus says:

   18th October 2012 at 4:28 PM

   Guter Artikel! Was ich bei den letzten Projekten noch für mich entdeckt habe, ist Breakpoints aufgrund des Contents zu ermitteln, und nicht der Standard-Device-Größen. Das ist finde ich beim RWD ein bisschen Wasser predigen aber Wein trinken, weil es dann doch wieder sehr bestimmt auf gewisse Größen abzielt.

   Reply
   • Thomas Nägele says:

     18th October 2012 at 5:52 PM

     Da hast du natürlich Recht. Im Idealfall sollte man einfach das Layout so lange in die Breite ziehen, bis es nicht mehr gut aussieht, bzw. nicht mehr funktioniert und dann einen Breakpoint einfügen. Mittlerweile gibt es ja schon so viele unterschiedliche Bildschirmbreiten, dass man sowieso nie alle perfekt abdecken kann.

     Im Projektgeschäft ist es aber leider ein bisschen schwierig, Angebote zu legen, die keine fix definierten Breakpoints beinhalten. Zum einen wollen Kunden festlegen können, für welche Geräte optimiert werden soll und zum anderen muss man aufpassen, dass es nicht zu viele Breakpoints werden. Selbst wenn man im Browser designt, wächst der Aufwand mit jedem Breakpoint und wenn der Content 8 Breakpoints von Smartphone bis Desktop erfordert, dann hat man ein Problem.

     Reply