++++ Folgen Sie uns auf Twitter oder Facebook ++++
[Update April 2015: Leider waren die Kommentatoren dieses Beitrags trotz mehrfacher Ermahnungen nicht zu einer von gegenseitigem Respekt geprägten und sachlichen Diskussion bereit. Daher haben wir die Kommentarfunktion deaktiviert.]
Wer das Buzzwort „Responsive“ beim Bullshit-Bingo in letzter Zeit nicht zentral in die Mitte setzt, reduziert seine Gewinnchancen immens: „Responsive Web“, „Responsive Advertising“, „Responsive Design“, „Responsive Wasauchimmer“:
Fast könnte man meinen, es wäre ein moderner Trend, Webseiten responsive zu gestalten, dabei war das Web schon immer per Definition responsive… nur die Gestalter hielten sich bislang halt nicht daran und kommen nun, nachdem sie mit 5 Jahren Verspätung feststellen, dass es auch noch andere Geräte als den heimischen Monitor gibt, langsam in die Bredouille.
Also kauft man sich ein Buch über „Responsive Design“ und hält diese brandneue Gestaltungstechnologie für den Heiligen Gral und empfiehlt als Berater den Publishern, ihre Webseiten zu relaunchen, damit sie auf allen Geräten optimal laufen.
Dabei ist es nun an der Zeit, sich den Titel dieses Blogposts in Erinnerung zu holen und an Hand der folgenden Punkte festzustellen, dass dieser Weg eben doch nicht das Gelbe vom Ei sein muss.
Betrachtet man eine mobile Webseite aus der Perspektive der Performance, also z. B. des Verkaufs, dann kommt man unabdinglich zum Thema Usability, denn letztendlich basiert ja die ganze Idee von Responsive auf bessere Zugänglich- und Bedienbarkeit.
Usability-Guru Jakob Nielson hat in seinen Studien, die er zusammen mit Raluca Budiu Ende Oktober 2012 (deutsche Ausgabe: im Mai 2013) herausgebracht hat, vernünftige Bedenken gegenüber Responsive Design geäußert und vor allem die Nachteile gegenüber extra entwickelten mobilen Webseiten aufgezählt:
- Da der Content (z. B. die Teasertexte) gewöhnlich dem der Desktopseite entspricht, müssen Nutzer auf Seiten, die mehrere Spalten einfach untereinander setzen, viel scrollen um einen Teil, der sie nicht so interessiert zu überspringen.
- Die Navigation ist meist nur im Rahmen der CSS-Möglichkeiten angepasst, die Semantik ist die selbe und somit bestehen potenzielle Usabilitykonflikte. Soll heißen: Die Navigation selbst kann für kleine Bildschirme überfrachtet wirken und nimmt oft einen Großteil des kleinen Displays ein. Dabei steht das Design im Konflikt zwischen Zugänglichkeit (jeder Navigationspunkt sollte mindestens eine Fläche von 1cm x 1cm aufweisen, damit er sauber mit dem Finger zu bedienen ist), Übersicht, Platz (so klein wie möglich, damit wenigstens der erste Absatz des eigentlichen Inhalts sichtbar ist) und Vollständigkeit (damit die Nutzer alle Funktionen wie vom Desktop gewohnt nutzen können). Er schließt das Kapitel mit den Worten:
„Die meisten uns bekannten Beispiele für Responsive Design waren recht primitiv und gingen nicht weit genug, um hinreichend verschiedene Benutzeroberflächen zu schaffen, wie sie für die mobile bzw. PC-Nutzung erforderlich sind. Es reicht nicht, das Layout einfach dadurch zu ändern, dass man einige Inhalte an anderen Stellen platziert und einzelne Designelemente vergrößert oder verkleinert. […] Um allerdings wirklich alle Unterschiede berücksichtigen zu können, muss man wieder zum Ausgangspunkt zurück: zu zwei separaten Webdesigns.“
Jetzt werden sich viele fragen, ob es mit zwei separaten Webdesigns überhaupt getan ist, schließlich gibt es noch Tablets und irgendwann könnte ja sein, dass mit Apple oder Google TV auch noch riesige Bildschirme hinzukommen, d. h. dann bedürfe es ja mindestens 4 separaten Webdesigns.
Gehen wir die angesprochenen Devices einfach mal durch:
Eine mobile Webseite auf einem iPad anzusehen macht keinen Spaß! Die Buttons sind meist zu groß, die Schrift meistens auch. Es hat sich erwiesen, dass die Desktopdarstellung auf Tablets oft die optimale ist. Nicht umsonst haben heutige Tablets mittlerweile die Auflösung eines kleinen Notebooks. Auch dass man mit Tablets öfters an Orten online ist, bei denen die Verbindung zum Internet über schnelleres Wireless Lan möglich ist, spricht eher für die Möglichkeit weitere Ressourcen über die schnellere Verbindung nachzuladen (wie z. B. hochauflösende Bilder).
Wenn es ein Medium gibt, dass es sich in Sachen Bildschirmgröße in den letzten Jahren seit Einführung von HD kaum verändert hat, dann ist es der Fernseher. Egal ob über Playstation, XBox, Wii, DVD- oder Blu-ray-Player, der Bildschirm verfügt über maximal 1920 x 1080 Pixel, was ungefähr einem 19″-Computermonitor entspricht. Dieser wird gewöhnlich auch nicht per Touchscreen, sondern über die Fernbedienung bedient. Die Buttons werden durch die geringe Auflösung der Displays automatisch größer und das ist auch nötig, denn bei Fernsehmonitoren ist gewöhnlich ein Abstand von über 2 Metern der Fall. Sollten sich die von der nach mehr Profit sehnenden Endgerätehersteller eingeführten 4k-Fernseher (Ultra-HD) längerfristig durchsetzen, wäre allerdings die Überlegung, wie man mit diesen Bildschirmgrößen umgeht. Aber da die Fernsehinhalte mit diesen Displays noch nicht konkurrieren können, wird sich deren Marktdurchdringung – wenn überhaupt – noch ein Weilchen hinziehen.
Das bedeutet: Momentan und in naher Zukunft genügen tatsächlich zwei unterschiedliche Webdesigns.
Die Entwicklung eines Responsive Designs setzt für einen Webseitenbetreiber allerdings einen kompletten Relaunch voraus, d. h. Publisher können die mobile Seite nicht einfach parallel entwickeln, sondern müssen einen Großteil ihrer bisher mühsam entwickelten Templates komplett auf Responsive umstellen. Das mag auf dem ersten Blick zwar billiger sein, als zwei Webseiten initial zu launchen, aber wenn responsive tatsächlich sinnvoll – wie von Nielsen vorgeschlagen – umgesetzt sein soll, dann entspricht der Entwicklungsaufwand fast dem für zwei separate Webseiten.
Natürlich kann man jetzt denken, dass vor allem der später doppelte Pflegeaufwand bei zwei separaten Webseiten finanziell stark zu Buche schlägt, aber man sollte dabei nicht vergessen, dass sich dieser bei absolut auf mobil optimierten Webseiten auch wieder ausgleichen kann, wenn die Nutzer die gewünschten Informationen oder Produkte einfacher und schneller finden.
Dazu hat Nielsen Usabilitytests durchgeführt, bei der die Testprobanden auf verschiedenen mobilen Endgeräten und verschiedenen Versionen von mobilen Webseiten Aufgaben zu erfüllen hatten (z. B. ein bestimmtes Produkt zu suchen und zu kaufen). Das wenig überraschende Ergebnis war, dass die Erfolgsrate parallel zur Displaygröße stieg. Erdrückend hingegen die Zahlen bei den unterschiedlichen Webstrategien:
Bei mobilen Webseiten lag die Erfolgsrate bei immerhin 64% und wurde nur durch die Erfolgsrate von Apps geschlagen, die bei 74% lag. Lediglich jeder Zweite hingegen konnte auf nicht angepassten Webseiten einen Erfolg verbuchen. Responsive wurde bei diesen Usabilitytests leider nicht ausgewertet, aber natürlich kann die Erfolgsrate nicht höher sein als die einer mobilen Webseite und liegt irgendwo zwischen 53% und 64%. Je nach Publisher oder Sortiment des Onlineshops kann innerhalb dieser Bandbreite also ein kaum merklicher Umsatzverlust oder gar das fehlende Prozent zum Erfolg liegen.
Wenn also der Aufwand für eine sich flexibel anpassende Webseite fast genauso hoch ist, wie für eine extra angefertigte mobile Webseite, dann stellt sich die Frage, warum man auf diese fehlenden Prozente verzichten sollte und nicht gleich zwei extra Webseiten entwickelt?
Zumal man mit Responsive Design auch seine Kundschaft vergraulen kann. Wie Google 2009 auf der O’Reilly Velocity Conference zeigte, könne bereits wenige Millisekunden zusätzlicher Ladezeit einen signifikanten Verlust an wiederkehrenden Besuchern verursachen. Lädt eine Seite nur 200ms länger, dann verliert man nach 6 Wochen durchschnittlich 0.4% aller potenziellen Kunden. Bei einer Verzögerung von 400ms nähert sich der Verlust der 1%-Marke.
Nun ist es so, dass bei Responsive Webdesign oft Frameworks oder Bibliotheken wie response.js oder Gumpy 2 dahinter stecken, die die Styles der Bildschirm- bzw. Browserfenstergröße entsprechend anpassen [Passage von Autor nach Hinweisen durch Leser geändert]. Dabei wird mindestens ein zusätzlicher Http-Request gestartet, welcher sich unter GPRS-Bedingungen – zusammen mit der abschließenden Anpassung des Layouts – bis zu einer halben Sekunde ziehen kann. Und das je nach Methode bei jedem Aufruf einer Seite!
Zusätzliche Ladezeit kommt hinzu, weil z. B. der komplette HTML-Code geladen wird, obwohl manches davon nicht angezeigt wird. Ein weiterer klarer Nachteil gegenüber der extra erzeugten mobilen Webseite.
Aber die Nachteile von Responsive Webdesign betreffen nicht nur die kleinen Displays, auch auf dem Desktop kann einiges schief laufen. So verstehen IE6 bis IE8, deren Verbreitung nach wie vor nicht unterschätzt werden sollte, die für Responsive Webdesign notwendigen CSS-Anweisungen nicht, was für zusätzlichen Javascriptcode sorgt oder weitere Stylesheets bedeutet. Ein ebenfalls nicht zu unterschätzender Mehraufwand gegenüber einer Webseite, die sich um diese browserübergreifende Rückwärtskompatibilität für moderne Technologien nicht scheren muss.
Und das letztes Stichwort, welches den finanziellen Aufwand von Responsive Webdesign ebenfalls in Frage stellen sollte, lautet „Advertising„.
Die gängigen mobilen Banner weichen von den klassischen Werbebannerformaten insofern ab, dass mögliche Mehreinnahmen unterlaufen werden könnten. Aus einem klassischen Inpage auf einer normalen Webseite wird unter Umständen ein FloorAd, also ein ständig sichtbares Banner, welches am unteren Bildschirmrand sichtbar und nicht wegscrollbar oder -klickbar ist.
Auch wenn das Werbemittel mittlerweile – ebenfalls Dank Responsive Design – so flexibel gebaut sein kann, dass es sich problemlos dem jeweiligen Format anpasst, so wird hier doch ein anderes Abrechnungsmodell gefahren. Aus dem Inpage wird ein Floating oder Interstitial, welches dem Betreiber mehr Geld pro Impression einbringt, welches er aber nicht abrechnen kann, da das Banner – je nach Ausgangsbrowserfenstergröße – ursprünglich eventuell als Inpage reingeladen und auch als dieses abgerechnet wurde.
Auch wenn dieses Problem publisherseitig gelöst werden kann, bedarf es hier wieder zusätzlicher Skripte, die weitere Ladelatenzen hervorrufen. Statt gleich zu Beginn eine schlankere mobile Webseite aufzurufen, bei der das Werbeformat fest steht.
Doch welche Vorteile hat Responsive Webdesign denn denn überhaupt?
Zum Einen gibt es natürlich viele Befürworter, alles voran Google, das allein schon aus Suchmaschinenoptimierungssicht eine(!) URL für darstellungsunabhängige Inhalte empfiehlt. Zum Anderen ist natürlich der Aufwand, einen Artikel zweimal in ein Content Management System einzupflegen nicht zu unterschätzen, aber selbst dieses Problem sehe ich auf lange Sicht als lösbar an, denn selbst WordPress bietet mittlerweile genügend Plugins, die einen Blogpost für verschiedene Anwendungen (Blogpost, SEO, etc) aufbereiten. Zwar nicht automatisch, aber zumindest innerhalb eines für den Redakteur nicht unzumutbaren Umfangs.
Ansonsten ist Responsive Design Schrott.
Responsive bedeutet, den ganzen Inhalt einer Seite samt allem Unnötigen (und etwas mehr wegen der technischen Verarbeitung) clientseitig (sprich: Auf Kosten des Besuchers) in eine kleine Form zu bringen, statt die beste Version bereits serverseitig auszuliefern, wie es bei einer mobilen Webseite der Fall ist. Dort kann der Nutzer dann zwischen beiden Darstellungsversionen immer noch wechseln…
Auch das kann er bei Responsive Design nicht, sondern es zwingt sein Design dem User auf.
Für mich der schlimmste Usability Fail überhaupt!
Nichts verpassen mit dem kostenfreien Newsletter von mobile zeitgeist.