Sie befinden sich hier:
» 
» 
17.04.2013

Erfahrungsbericht:
Umstellung Website auf responsive Webdesign

Regelmäßige Leser dieses Blogs haben sicherlich bemerkt, dass die letzten Blogeinträge dem Thema responsive Webdesign gewidmet waren. Vielleicht hat auch schon jemand die Größe des Browserfensters verändert, um zu sehen, ob hinter der Theorie auch die praktische Erfahrung steckt. Die Frage kann ich mit JA beantworten, denn seit Anfang April 2013 ist diese Website auf responsive Webdesign umgestellt.

Gründe für den Umstieg auf responsive Webdesign

Ich pflegte den Content meiner Webseiten zwar nur einmal und generierte daraus automatisch sowohl die konventionelle, als auch die mobile Version meiner Website, doch fand ich es auf Dauer unvorteilhaft, zwei Versionen zu führen. Zumal ich zwei verschiedene Layouts hatte, die auch optisch keine Verwandtschaften hatten. Des Weiteren war die mobile Version wirklich auf das Minimum reduziert, d.h. nur reiner Text und CSS. Keine soziale Anbindung und keine Kommentar-Box. Die Zugriffe zeigten aber, dass der Anteil mobiler Besucher stetig stieg. Deshalb wollte ich auf der mobilen Seite ebenfalls die volle Funktionalität anbieten. Darüber hinaus sah die minimalistische mobile Version der Website auf größeren Tablets ziemlich armselig aus.

Nachdem Ende November 2012 die konventionelle Version der Website mit neuem Layout und modernisiertem Aufbau (Html5, flachere Struktur, soziale Anbindung über Zwei-Klick-Lösung etc.) online ging, stellte sich die Frage: Mobile Version einfach nachziehen oder beide Versionen vereinen? Ich entschied mich für letztere Variante und setzte auf responsive Webdesign.

Die Zusammenlegung der beiden Website Versionen bedeutet aber auch:

  • Bündelung der Klickraten
  • eine höhere Wahrscheinlichkeit der sozialen Vernetzung

Schwerpunkte und technische Herausforderungen während der Umstellung

Bei der Erstellung der responsive Website hatte höchste Priorität ein minimales Übertragungsvolumen und eine möglichst minimale Anzahl an Requests, um die Webseiten aufzubauen. Mir war klar, dass ich das Übertragungsvolumen der ehemaligen mobilen Version von durchschnittlich 7kB je Webseite nicht halten konnte. Schließlich steht jetzt mehr Funktionalität zur Verfügung (soziale Anbindung, Kommentarbox, Slider auf der Homepage), doch bei 50kB pro Webseite (in der mobilen bzw. minimalsten Version) habe ich mir eine virtuelle Schmerzgrenze gesetzt, die ich auch ziemlich genau getroffen habe. Mitentscheidend hierfür war der „mobile first“-Ansatz, durch den z.B. in der mobilen Version nur die absolut notwendigen Graphiken geladen werden. Die Anzahl der Requests hat sich in der mobilen Version nur um einen Request auf durchschnittlich 6-7 Requests erhöht. Falls der Besucher mehrere Webseiten aufruft, werden weiterhin nur noch ca. 5kB je Webseite übertragen, bei 1-2 Requests. Die restlichen Files (CSS, JS, Graphiken) werden gecached. Insofern sollte auch weiterhin ein zügiges Surfen auf Mobilgeräten möglich sein.

Die ehemals konventionelle Version hat sich logischerweise auch leicht vergrößert. Das ist in der größeren CSS-Datei (durch die unterschiedlichen Media-Query-Blöcke) und dem geteilten CSS-Sprite begründet.

Zusätzliche technische Features für mobile Geräte

Natürlich wurden auch entsprechende technische Features für mobile Geräte eingebaut. So reagieren die Pull-Down-Menüs in der minimalsten Darstellung auch auf Touch-Events. Es wurde ebenso berücksichtigt, dass Tablets z.B. per Finger (Touch) oder Maus bedient werden können. Somit reagieren die Menüs auf beide Events. Die Herausforderung bestand darin, nach dem ausgelösten Touch-Event den kurz darauf folgenden Maus-Event zu unterdrücken, damit ein frisch aufgeklapptes Pull-Down-Menü sich nicht sofort wieder schließt. Die entsprechenden Codesequenzen finden Sie im Blogeintrag „Touch Events richtig anwenden“. Des Weiteren reagiert der Slider auf der Startseite jetzt ebenfalls auf Fingerzeig.

Die gesamten mobilen Features wurden ohne komplexe mobile Frameworks z.B. jQuery-Mobile realisiert, da sonst meine virtuelle Schmerzgrenze von durchschnittlich 50kB je Webseite nicht zu halten gewesen wäre. Darin sehe ich übrigens generell eine Gefahr. Durch Integration von fertigen Scripten und Plug-Ins mag zwar, auch für den Ungeübten, schnell ein ansprechendes Ergebnis realisierbar sein. Allerdings wird durch diese Überfrachtung das Übertragungsvolumen und die Anzahl der Requests unakzeptabel groß werden. Dies hat natürlich Auswirkungen auf Usability, Performance, Ranking etc.

Fazit der Umstellung auf responsive Webdesign

  • Auch wenn beide Versionen leicht an Volumen und Requestanzahl zugelegt haben, war es meiner Meinung nach die richtige Entscheidung, auf responsive Webdesign umzustellen.
  • Wichtig ist es, sich zu Beginn genügend Gedanken über die Aufteilung der Inhalte in den einzelnen Darstellungsgrößen zu machen. Notfalls mit Post-It Zettelchen die einzelnen Versionen durchspielen.
  • Die Website hat nun in allen Größen ein ähnliches Layout, wodurch der Wiedererkennungswert der Website durchgängig gegeben ist.
  • Des Weiteren ist die Website jetzt in allen Versionen funktionell gleichwertig und es gibt keine abgespeckte „Sparversion“ für Mobilgeräte.
  • Der Wartungsaufwand wird sich sicherlich ebenfalls reduzieren.
  • Auf die Gefahren bei Verwendung komplexer Frameworks habe ich bereits hingewiesen.

Autor: Mein Name ist Harry Kämpf und ich bin seit vielen Jahren als Projekt Manager im Webumfeld tätig. Auf diesen Erfahrungen basieren die Tipps zur Webseitengestaltung. Ich schreibe gern über Webthemen, nehme aktuelle Trends auf und gebe bei Bedarf kompetente Beratung. Mehr Infos können Sie auf ueber-mich.html nachlesen.

61

Kommentare:

11.September2013

Mir gefällt das Tablettdesign dieser Seite, vorallem die aufklappbare Footernavigation ist schick umgesetzt.

11.September2013

Danke für das Feedback. smile

14.Oktober2013

Danke für deinen Erfahrungsbericht.

Ich habe meine Webseite auch gerade eben auf ein Responsive Design umgestellt, bin dabei aber den anderen Weg gegangen: Desktop first.

Dadurch hat der mobile Besucher schon ein gehöriges Maß an Traffic zu schultern. Ebenso eine doch recht hohe Anzahl an Requests. Habe mir vorher lange Gedanken gemacht, ob ich nicht eher deinen mobile first Ansatz verfolgen soll. Habe mich dann aber doch für die Desktop Variante entschieden. Das wäre mir dann für die Desktop Ansicht doch zu spartanisch gewesen und die durschnittliche Bandbreite wird zukünftig wohl eher steigen, als sinken (hoffe ich jetzt einfach mal).

Mittlerweile bin ich Fan von responsiven Lösungen (spart doch viel Zeit) und ziehe fast auf jeder Webseite erstmal den Browser kleiner smile

Störend ist aber vor allem, dass man serverseitig nicht die Bandbreite des clients messen kann. Dann könnte man das Ganze doch etwas benutzerfreundlicher machen. Die Auflösung alleine, sagt ja erstmal nicht wirklich was aus. Ist aber erstmal hilfreicher als nichts. So kann man wnigstens die Bilder verkleinert ausliefern. Aber nichtmal die Auflösung kann man ohne Javascript ermitteln.

Von daher ist deine -mobile first- Variante sicher erstmal die bessere Lösung. Schaut auch gut aus.

Wünsch dir jedenfalls noch viel Erfolg...lg

20.Juli2014

Toller Artikel, die zeitliche Anordnung der Gedanken können wir nur allzu gut nachvollziehbar, hatten wir doch mit ähnlichen Gedanken zu tun.

Inzwischen haben wir uns darauf spezialisiert, bestehende, gut platzierte Webseiten nachträglich responsive umzuschreiben, d.h. für Handy, Tablet und alle Breitbildmonitore zu optimieren. Das Redesign von Webseiten nach Kundenwünschen ist dabei selbsverständlich. Referenzen, responsive Testtool für Ihre eigene Webseite, Webkatalog, Blog, Vorlagen u.v.m. finden Sie auf unserer Website.

Wir arbeiten im gesamten deutschsprachigen Raum mit Arbeitsproben auf unserem Server, die vom Kunden jederzeit mitverfolgt und beeinflusst werden können.

17.März2015

Ich bin auf der Suche nach einen Plugin der diese Umstellung komplett übernimmt leider habe ich bisher nur etwas von Wordpress gefunden.

17.März2015

Bei individell erstellten Webseiten wird man kein PlugIn finden, welches die Umstellung komplett übernimmt.