Responsive by Design, Successful by Chance – Wo steht RWD 2015?

Responsive Now

Die gute Nachricht zuerst. Wer 2015 responsive werden will, hat dafür mehr vorgefertigte Bausteine als je zuvor: es gibt kaum eine Template-Sammlung, in der sich nicht auch 1-2 responsive Varianten finden. Mit etwas Glück sogar mit Parallax-Effekt. Allerdings stoßen Templates schnell an ihre Grenzen, weil sie dann doch nicht viel Raum für eigene Business-Logik bieten und es schmerzt, wenn man im gleichen Gewand wie die Konkurrenz im Netz steht.

Also greift man dann doch zu kleineren Bausteinen und baut mit Hilfe von responsiven Frameworks wie Bootstrap oder Foundation. Keine schlechte Idee, denn diese Frameworks sind erprobt, und das auch auf Geräten, die sich in den meisten Device-Sammlungen nicht finden. Aber auch hier ist der Preis für die Bequemlichkeit mangelnde Flexibilität, denn jedes Framework trifft gewisse Design-Entscheidungen, die sich nachträglich nur schwer ändern lassen. Zum Beispiel welche Browser unterstützt werden oder wie viele Spalten ein Grid haben sollte.

Wer nicht mit den Vorgaben der Frameworks leben will, überschreibt am Ende große Teile des Ausgangsmaterials. Wer zu wenig ändert, steht letztendlich mit einer Website da, die dann irgendwie doch aussieht wie alle anderen responsiven Projekte der letzten Jahre.

Auch wenn Templates und Frameworks also ihren Platz haben, ist die schlechte Nachricht deshalb: Innovative responsive Websites sind auch 2015 noch Maßarbeit.

Ein Muster, dem bis heute zu viele responsive Webseiten gefolgt sind

Gleichzeitig First

Wir stehen also wieder ganz am Anfang. Wenn man nicht in der unschönen Situation ist, eine Desktop-Seite nachträglich zu responsivieren, ist dieser Anfang 2015 natürlich mobil. Denn es hat sich mittlerweile herum gesprochen, dass es leichter ist, zu mobilen Designs Features hinzufügen als sie von Desktop-Designs abzukratzen. Das gilt besonders im Code, denn so lässt sich die Kernfunktionalität blitzschnell laden und dann schrittweise mit aufwändiger Funktionalität ergänzen.

Progressive Enhancement heißt das entsprechende Mantra. Die Annahme hinter Progressive Enhancement und Mobile First ist allerdings, dass sich Designs für große Displays immer aus denen für kleine ableiten lassen. In der Praxis klappt das nicht immer, weil sich mit dem Formfaktor auch Usecases ändern. Auch wenn Mobile First also technisch die Strategie der Wahl ist, muss man als Designerin immer wieder prüfen, wie verschiedene Größenvarianten einer Interaktion zusammenpassen.

Das ist nicht leicht und bekommt deshalb hier den paradoxen Titel „Gleichzeitig first“.

Browser, Schere, Papier

Wer nun seine Wireframes gleichzeitig über alle Breakpoints hinweg gestaltet, muss sich auf zwei Enttäuschungen einstellen: Erstens ist es unglaublich viel Arbeit, für jedes Template nicht nur ein, sondern gleich mehrere Designs anzulegen bzw. zu pflegen. Zweitens funktioniert vieles, das sich etwa in gängigen Prototyping-Tools wie Axure zusammenklicken lässt, nicht ohne weiteres im Browser. „Ohne Weiteres“ meint ohne JavaScript, das bei Breakpoint-Wechseln DOM-Bäume umsortiert und ähnliche Workarounds, die Entwicklern den Schlaf und Benutzern die Bandbreite rauben. Umgekehrt schränken Prototyping-Tools die Kreativität beim Interaktionsdesign erheblich ein, da die technischen Möglichkeiten im Browser durch CSS3 und JavaScript doch wesentlich ausgereifter sind als die wenigen vorgefertigten Slides, Swipes und Drag’n’Drops von Axure.

Nicht alle Wireframes lassen sich problemlos in responsiven Code übersetzen. Gerade wechselnde Reihenfolgen von Elementen sind problematisch, weil der zugrundeliegende HTML-Code möglichst immer gleich bleiben soll.

Responsive Konzeption sollte deshalb so früh wie möglich in den Browser wandern und dort unter realen Bedingungen geprototyped werden. Das hat den immensen Vorteil, dass nicht nur drei oder vier Zustände einer Website sichtbar sind. Der Browser lässt sich fließend groß- und kleinziehen und zeigt so die Stärken und Schwächen des eigenen Designs auch jenseits der von Apple diktierten Auflösungen. So entstehen Designs, die auch auf der nächsten iPhone-Generation noch funktionieren.

Das beständige Auf- und Zuziehen des Browsers, das dieser Design-Stil erfordert, nennt man auf der Straße übrigens „Browser-Wanking“.

Responsive Prototyping mittels Browser-Wanking

Responsive Prototyping mittels Browser-Wanking

Design im Browser heißt nicht, dass ab jetzt alle Designer CSS, JavaScript oder besser noch React lernen müssen. Es bedeutet, dass sie sich neben ihre Entwickler-Kolleginnen setzen und Konzepte gemeinsam erarbeiten. Designer sollten sich deshalb mit technischem Jargon anfreunden. Und Entwicklerinnen sollten in dieser Zusammenarbeit lernen, dass Entwürfe genau das sind und gar nicht selten weggeworfen werden. Trotz Jargon und verworfener Versuche ist das Ergebnis am Ende besser und mit weniger Missverständnissen erreicht.

Design im Browser heißt auch nicht, dass alle anderen Gestaltungswerkzeuge plötzlich wertlos geworden sind. Papier ist und bleibt weiterhin das schnellste Medium, um Interaktionen zu skizzieren. Photoshop, Illustrator und Sketch sind immer noch sehr nützlich, um ein grafisches Gefühl für eine Website zu bekommen. Etwa in Form von Style Tiles, in denen Typografie und Farbwelt einer Seite definiert werden, ohne bis ins Detail eines Mockups zu gehen.

Noch besser als Style Tiles ist allerdings dann doch wieder eine code-basierte Pattern Library, aus der sich Entwicklung und Design gleichermaßen bedienen können. So ist sicher gestellt, dass eine gemeinsame Sprache über UI-Elemente existiert und es muss nicht für jeden Design-Prototyp der Button neu erfunden werden.

 

Beispiel für ein Style-Tile des Transparency-Camp 2013 (Quelle: Sunlight-Foundation)

Design heißt jetzt Performance

Das Designer und Entwicklerin nun nebeneinander sitzen und schon früh gemeinsam an Konzepten schrauben, hat noch einen weiteren Vorteil – sie können sich der größten Herausforderung des responsiven Webs annehmen: Performance. Denn mobile Devices unterscheiden sich nicht nur in der Displaygröße, sondern auch in der Übertragungsgeschwindigkeit und der Leistungsfähigkeit der Hardware.

Der Versuch, einfach eine Desktop-Website mit all ihren Inhalten und Interaktionen auf unter 400 Pixel zusammenzuquetschen führt deshalb zwangsläufig zu sehr langen und – gemessen in Megabyte – großen Websites, die nur langsam laden. Solche Ladezeiten schlagen sich direkt in der Bounce-Rate und der Zufriedenheit mit der Experience nieder.

Gute User Experience setzt also gute Performance voraus und geht somit Designer wie Entwicklerinnen gleichermaßen an.

2015-mobile-page-growth-detail

Webseiten werden immer Größer (Quelle: Webperformance Today)

Trotz dieser Erkenntnis werden Webseiten immer größer, wobei der Haupttreiber für dieses Wachstum die Bilder sind. Deshalb muss jede moderne responsive Seite eine Antwort auf die Frage haben, wie für verschiedene Devices jeweils passende Bildergrößen ausgeliefert werden. In den meisten Fällen wird diese Antwort 2015 „picture-tag“ lauten. Dieses neue HTML-Tag erlaubt es für verschiedene Breakpoints jeweils eigene Bilder zu verknüpfen und so etwa auf 320px breiten Displays keine 2048px Bilder zu laden. Firefox und Chrome unterstützen das Tag bereits, dem Internet Explorer kann mit einem Polyfill auf die Sprünge geholfen werden, das die Funktionalität (mit Abstrichen) in Javascript emuliert.

Soweit wirken responsive Bilder sehr technisch, aber sie haben auch für das Design interessante Konsequenzen. Denn sie machen es möglich, für jeden Breakpoint einen anderen Bildausschnitt oder sogar eine ganz andere Illustration zu wählen – „art direction“ nennt sich dieses Feature und macht direkt klar, welche Berufsgruppe sich dafür interessieren könnte.

Doch nicht nur bei Bildern macht es Sinn, dass sich Art Direktoren und User Experience Designerinnen frühzeitig einbringen. Ganz allgemein lässt sich Performance nicht allein auf Messgrößen wie die Zeit zum ersten Byte reduzieren, sondern hat auch viel mit menschlicher Wahrnehmung zu tun. Ein gutes Beispiel dafür ist der Facebook-Feed, der schon erscheint, wenn er noch praktisch keine Inhalte geladen hat. Statt dem Ladebalken des Browsers oder hunderten Lade-Spinnern zeigt der Feed schon ein Skelett des kommenden Inhalts. Auch wenn dieser Inhalt technisch dadurch nicht schneller wird, verlagert sich psychologisch der Fokus vom Warten auf den Inhalt, der hoffentlich bald kommt.

Genau das ist die Strategie hinter Webseiten die sich schnell anfühlen: Die wichtigsten Informationen erscheinen sofort, alles andere folgt so schnell es geht. Also wieder Progressive Enhancement.

Auf Facebook wird das Skelett [sic!] der Seite vor dem eigentlichen Inhalt angezeigt

Offline ist das neue Schwarz

Gemeinsame Arbeit an Performance von UX und Entwicklung bringt momentan die spannendsten responsiven Website hervor. Hier werden auch ganz neue Fragen gestellt, wie beispielsweise sich eigentlich Webseiten verhalten können, wenn mal kein Empfang ist. Bislang war die Antwort, darauf: Gar nicht. Entwicklungen rund um das Offline First Manifest hinterfragen das und arbeiten an Techniken die intelligent genug puffern, um auch mit solchen Ausnahmesituationen umgehen zu können.

So gesehen bleiben 2015 responsive Frontends auch weiterhin spannend.

 

Dieser Artikel basiert auf einem Vortrag, den Thomas Piribauer und Björn Ganslandt 2015 beim IxDA-Roundtable in Hamburg gehalten haben. Die vollständigen Slides dazu findet ihr bei Slideshare.

Über Thomas Piribauer

Thomas ist Mitgründer und Managing Director von intuio. Am liebsten und schon seit mehr als 20 Jahren denkt, konzipiert und entwickelt er interaktive Lösungen, die gut funktionieren und noch besser bedienbar sind.

Über Björn Ganslandt

Björn ist freier Frontend-Entwickler in Wien. Neben CSS interessiert er sich aber auch für Typografie, User Experience und alles was digitale Produkte sonst noch besser macht. Früher war er bei Peek & Cloppenburg für Usability und Conversion verantwortlich und hat das Kleinzeigensystem der Expat-Community »Just Landed« mit konzipiert.

Ein Kommentar


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →