Blog von Marc Hinse, Webdesigner und Webentwickler aus Karlsruhe.

made my day.every day.

Sehr geehrter Herr Voelcker, Sie haben keine Ahnung.

Gerade scrollte ein Texterguss an mir vorbei, der nicht unkommentiert bleiben darf. Ein Herr Voelcker schreibt auf einer Website, die sich "mobile-zeitgeist" nennt, einen Artikel, der postuliert, "warum Responsive Webdesign Schrott ist". Schauen wir doch mal, warum dem so sein soll.
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.

Da hat er recht, der Herr Voelcker. Das erste, einzige und damit auch das letzte mal. Auch wenn er natürlich das erste mal generalisiert ("DIE Gestalter", alle, 100%, ausnahmslos), aber das gehört zur gewollten Polemik einfach dazu, also lassen wir es mal gelten.

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.

Ich dachte, das Web war schon immer responsiv? Jetzt ist es dann doch "brandneu"? Aber okay, Bücher braucht man dafür nicht, außer man ist Berater. So kann man es vielleicht noch deuten, wenn man dem Herrn Voelcker Kompetenz unterstellen wollte.

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.

"sein muss"... Immer noch kein wirklicher Widerspruch, das kann noch was werden. Ich bin sowas von gespannt.

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.

Oben noch Buzzwords anprangern, jetzt schon dieselben durcheinander bringen. "Performance" soll hier wohl eher "Conversion Rate" bedeuten, wenn dann buzzen wir richtig. Meine Hobbit-Kollegen und ich aus dem Responsive Auenland verstehen darunter zumindest etwas anderes. Nämlich die Leistung bzgl. Ladezeit, Optimierung von Bildern oder eben Usability. Aber das kann man schon einmal verwechseln.

Usability-Guru Jakob Nielson hat in seinen Studien...

So. Also. Jetzt kommt die Nielsen-Keule (mit "e" übrigens, aber das kann mal passieren).

Ich kenne das Buch nicht, kann also nur versuchen, auf die angegebenen Punkte einzugehen. Trotzdem möchte ich zu bedenken geben, dass Jakob Nielsen keineswegs unumstritten ist. Er prägte zwar den Begriff "Web Usability" mit seinem Standardwerk "Designing Web Usability" von 1998. Die späteren Publikationen schienen oft in eine Art guruartige Polemik zu verfallen, nach dem Motto: "Was ich sage, ist Gesetz, denn ich bin der Guru". Egal, immerhin wird ja hier wissenschaftlich zitiert, also hoffe ich, ebenso fundiert darauf eingehen zu können.

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.

Der Content, z.B. die Teasertexte? Mehrspaltig? Hm, schwer zu verstehen. Nehmen wir mal einfach den Boston Globe. Klassisches mehrspaltiges Layout, viele Teaser. Vergleiche ich die Desktopvariante mit der Smartphone-Variante, sehe ich eher unwichtige Teile rechts. Im Smartphone eben weiter unten. Wieso postuliert man dann, dass der User viel scrollen MUSS, um Teile zu überspringen? Und vor allem... was ist die Alternative auf dem Smartphone? Zoomen? Eigene mobile Version? Wer entscheidet dann, was den User interessiert und was nicht?

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).

Und das ist mit der mobilen Version anders? Oder mit der gezoomten Desktopversion? Natürlich können wir einfach sagen, Webdesign ist auf Smartphones nicht vernünftig möglich, aber ich glaube nicht, dass das die Nutzer interessiert. Also müssen Lösungen geschaffen werden. Brad Frost leistet hier Pionierarbeit, indem er verschiedene Patterns für verschiedene Problemstellungen zeigt. Das sollte man sich anschauen, nicht die Ergüsse eines grantigen Gurus. Dieser meint nämlich, wir sind am Ende wieder bei einer Desktop- und bei einer Mobilversion. Und nimmt jetzt wahllos noch Tablets und TVs hinzu, ergo brauchen wir vier.

Nun erkennt Herr Voelcker, dass ein Tablet eher die Desktopversion ausgeliefert bekommen sollte, da die Auflösung ja vergleichbar ist mit kleinen Notebooks. Dem widerspreche ich nicht. Solange man es im Querformat hält zumindest. Das Hochformat... tja, was ist damit?

Als nächstes geht Herr Voelcker auf die TV-Geräte ein, die ja alle eine HD-Auflösung haben (meiner nicht), aber das ist sowieso alles egal, da die Marktdurchdringung des "Web am TV nutzen" ja sowieso noch kein Thema ist. Soso.

Das bedeutet: Momentan und in naher Zukunft genügen tatsächlich zwei unterschiedliche Webdesigns.

Jawoll. Herr Voelcker hat es verstanden. Eine Frage darf erlaubt sein. Wie sieht denn DIE Desktopvariante aus? 960.gs? Was ist mit 2500er Auflösungen? Weißraum ist ja auch nett. Oder immer 100%? Lange Zeilen sind schwer lesbar, sagte ja schon der gerne zitierte Nielsen. Nein! Denn Responsive Webdesign heißt eben nicht für bestimmte Geräte zu optimieren, sondern für verschiedene Auflösungen die bestmögliche User Experience zu schaffen! Völlig egal, ob hochaufgelöstes Tablet, Beamer oder Fernseher.

Weiter im Text:

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.

Und wieder wird zusammengeschmissen, was nicht zusammen gehört. Es gibt im Responsive Webdesign (RWD) nicht DIE EINE mobile Seite. Zumindest ist es dann eben nicht RWD.

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.

Hm, hat Nielsen nicht gesagt, RWD ist doof? Oder meint der Herr Voelcker jetzt doch die eigenständige mobile Version? Ich glaube fast schon, denn jetzt wird es richtig hanebüchen:

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.

Doppelter Pflegeaufwand? Bei Desktop- und Mobilvariante? Wer macht denn sowas? Er tut wirklich so, als würde man zwei unterschiedliche Webseiten betreuen müssen. Selbst bei der Desktop/Mobilvariante ist das maximal beknackt.

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.

Jetzt muss man genau aufpassen.

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

Also... Erfolg bei Mobilvariante: 64%, bei Apps: 74%. Desktopvariante, aufgerufen auf Mobilgerät: ca. 50%. Verstanden. Klingt plausibel.

Responsive wurde bei diesen Usabilitytests leider nicht ausgewertet...

Was? WAS? "Responsive Webdesign ist Schrott" und dann wird eine Studie zitiert, die RWD nicht einmal untersucht? Meine Güte.

...aber natürlich kann die Erfolgsrate nicht höher sein als die einer mobilen Webseite und liegt irgendwo zwischen 53% und 64%

DAS ist wissenschaftliches Arbeiten: Etwas nicht untersuchen bzw. etwas nicht untersuchtes zitieren und dann etwas völlig aus der Kristallkugel gegriffenes postulieren als "kann nicht". Glückwunsch Herr Dozent, solche Lehrkörper braucht das Land! Da muss ich wirklich mein Mittagessen zurückhalten ob solcher Unverfrorenheit.

Immerhin scheint das "ca. die Hälfte" zu bedeuten, dass 53% es geschafft haben, mit der Desktopvariante auf einem Mobilgerät das Ziel zu erreichen.

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?

Nein, Sie Spezialist. Es stellt sich die Frage, warum:

  • kein RWD untersucht wurde, aber trotzdem Rückschlüsse daraus gezogen werden?
  • wie der Versuchsaufbau überhaupt aussah (welche Seiten wurden getestet)?
  • und wenn es doch eh kaum einen Unterschied macht, warum dann die extra Mobilseite überhaupt entwickelt werden muss, wenn es doch sogar doppelten Pflegeaufwand bedeuten soll?
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.

2009 gab es noch kein RWD, so etwas mit "zumal" einzuleiten ist irreführend. Also drücken wir es aus, wie es ist: Je länger die Seite lädt, desto eher springt der Besucher ab. Das gilt für jedes Device.

Und jetzt liebe Freunde und Kollegen, wird es richtig lustig.

Nun ist es so, dass bei Responsive Webdesign gewöhnlich Frameworks wie less.js oder sass.js dahinter stecken, die die Stylesheets der Bildschirm- bzw. Browserfenstergröße entsprechend anpassen.

Zweimal lesen. Essen/Kaffee/Spucke vom Bildschirm wischen, weiter gehts.

Herr Voelcker disqualifiziert sich nun vollständig. In einen Satz so viele Fehler zu packen, kann nur mutwillig passieren, wenn man unbedingt einen Artikel zu einem vorgegebenen Titel schreiben will. Aber gut, der Vollständigkeit halber:

  • LESS und Sass sind so genannte CSS-Präprozessoren. Sie machen es einfacher, CSS zu schreiben. Mehr nicht. Aber auch nicht weniger.
  • Es sind keine Frameworks, es sind Compiler.
  • Stylesheets werden nicht der Bildschirmgröße angepasst, wenn dann werden Styles innerhalb von Stylesheets angepasst.
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 Framework bei jedem Aufruf einer Seite!

Zu Äpfeln und Birnen gesellen sich nun Knoblauch und Fahrräder.

  • LESS und Sass werden nicht "runtergeladen"
  • Es wird kein Layout angepasst. Es wird gerendert, so wie es das Stylesheet vorgibt. Dadurch wird keine (zusätzliche) Zeit verschwendet.
  • Wo die halbe Sekunde (bei JEDEM AUFRUF!11!!elf!) her kommt, vor allem was das mit den Frameworks - die keine sind - zu tun hat, weiß vermutlich keiner, nicht einmal Herr Voelcker.
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.

Kann sein, muss aber nicht. Vor allem ist das im Vergleich zu nicht optimierten Bildern in der Regel wirklich vernachlässigbar.

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.

Bitte was? Browser, die gar nicht auf mobilen Geräten laufen, verstehen Anweisungen für Browser, die auf mobilen Geräten laufen, nicht? Skandal!

Nein, im Gegenteil. Das ist gut so. Den IE6 überhaupt noch zu erwähnen, ist Panne genug. Aber was die Intention dieses Abschnitts war oder sein sollte, erschließt sich mir nicht.

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.

Jawohl! Back to the roots. Bling-Bling für den Desktop und dazu eine reine Textversion für mobile Endgeräte. Nieder mit dem Fortschritt! Geolocation, Zugriff auf Usermedia, HMTL5-Video, AppCache, alles Teufelszeug!

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.

Das ist hanebüchen. Zeigt mal wieder, dass Herr Voelcker keinerlei Ahnung hat, was RWD überhaupt bedeutet.

Jetzt kommen endlich die Vorteile von RWD \o/

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.

Hm, SEO. Klar. Wenn das das einzige Argument PRO RWD ist, das übrig bleibt, ist die Zielsetzung des Artikels sicher klar. Klicks, PIs. Glückwunsch zu diesem gekonnten Trollstunt.

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.

Wer zum Geier muss denn jemals etwas doppelt einpflegen? Und falls doch, schmeißen wir einfach wieder die verhassten Scripte drauf? Eieieiei.

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!

Von oben:

  • Herr Voelcker, hier mal ein paar Stichworte für Sie: "require.js", "responsive images [serverseitig]".
  • Der schlimmste Usability Fail ist es, seine Besucher zu ignorieren und Ihnen entweder schwarz oder weiß aufzudrücken, anstatt für möglichst viele Grautöne vorbereitet zu sein.

So, genug Trolle gefüttert. Ich mache mal wieder schrottiges Responsive Webdesign.

Update:

Jens Grochtdreis hat das ganze noch einmal weit weniger polemisch zusammengefasst, danke Jens!

Nach oben