Wie geht man mit dem stetig zunehmenden mobilen Zugriff auf Webseiten um? Prinzipiell gibt es drei grundlegende Möglichkeiten: Sie können eine/mehrere separater Version(en) für die Nutzer von Smartphones und Tablets bereitstellen – ein sehr klassisches Verfahren. Die zweite Möglichkeit – eher neuer – ist es, die Webseite nach dem Prinzip des Responsive Webdesigns zu gestalten, so dass sie sich an die unterschiedlichen Ausgabemedien anpasst. Die dritte Möglichkeit ist ebenfalls weit verbreitet und besteht darin, einfach nichts zu tun. Sehen wir uns diese drei Möglichkeiten im Detail an und beginnen mit der Letzteren.

Strategie 1: Nichts tun
Smartphones und Tablets sind im Prinzip so konzipiert, dass sie „normale“, nicht speziell für sie konzipierte Webseiten darstellen können. Smartphones greifen dafür zu einem Trick: Sie verkleinern die Inhalte so, dass diese gesamt auf dem Bildschirm Platz haben. Die Benutzer können dann einzelne Bereiche vergrößern, um die Inhalte zu lesen.

Ob das „Nichts tun“ und sich darauf verlassen, dass Smartphones diese Anpassungen durchführen, akzeptabel ist, hängt von mehreren Faktoren ab. Keine gute Wahl ist diese Strategie schon einmal, wenn die Webseite Inhalte hat, die sich nur schlecht oder überhaupt nicht auf Smartphones nutzen lassen. Dazu zählen zum Beispiel folgende Fälle:

  • Wichtige Informationen sind nur beim Hover sichtbar und nicht auf Touchscreens erreichbar.
  • Wesentliche Komponenten funktionieren nur mit Flash.
  • Die Dateimenge, die heruntergeladen werden muss, ist umfassend, was zu einer sehr schlechten Performance führt.

Aber Nichts tun kann besser sein, als eine der anderen gleich vorgestellten Techniken schlecht einzusetzen. Auf WTF Mobile Web etwa finden Sie Beispiele für mobile Webseiten, bei denen der mobile Nutzer nur den Hinweis bekommt, dass es in Zukunft eine mobile Version geben wird, ohne dass er an die Inhalte herankommt. Hier ist es auf alle Fälle besser, den mobilen Nutzer nicht von der normalen Webseite auszuschließen.

Etwas provokativ, aber in der Sache völlig richtig, schreibt Jason Grigsby auf dem Cloud Four Blog: Wenn man nur eine Sache für den mobilen Nutzer tun kann, so wäre es besser, die Performance der Desktop-Seite zu verbessern als eine schicke Optik über das Responsive Webdesign umzusetzen: „If you could only do one thing to prepare your desktop site for mobile and had to choose between employing media queries to make it look good on a mobile device or optimizing the site for performance, you would be better served by making the desktop site blazingly fast.“ In diesem Sinne kann eine Performance-Optimierung ohne sonstige Anpassungen ein guter Zwischenschritt sein.

Strategie 2: Separate mobile Seite
Eine eigene mobile Seite bereitzustellen ist eine klassische Methode, die schon seit Längerem praktiziert wird. Das funktioniert so: Browser senden bei der Anforderung einer Webseite eine Kennung mit, den so genannten User-Agent-String. Dieser User-Agent-String enthält Informationen wie Browserversion, Betriebssystem, etc. Aufgrund dieser Kennung wird durch ein Skript auf dem Server entschieden, welche Version der Webseite ausgeliefert werden soll. Die Version für mobile Geräte kann in vielerlei Ansichten angepasst werden – sie kann Informationen enthalten, die nur für mobile Nutzer sinnvoll sind, aber es können auch Inhalte für mobile Nutzer ausgeblendet werden. So sind manche Präsentationsarten wie etwa die Lightbox für mobile Geräte weniger sinnvoll. Häufig – aber nicht obligatorisch – werden die Seiten unter unterschiedlichen Domains ausgeliefert, d.h. es gibt neben der „normalen“ Domain auch eine Subdomain wie m.example.

Ein klassisches Beispiel für die zwei separaten Versionen ist die Webseite der Lufthansa:

Bild 1: Lufthansa Website

 Bild 1: Separate Webseiten von Lufthansa

Diese Variante hat mehrere Vorteile:

  • Die mobile Version kann ganz an die Erfordernisse der kleinen Bildschirme angepasst werden und bei Bedarf können „mobile Kontexte“ angemessen berücksichtigt werden.
  • Es können separat Maßnahmen zur Performance-Optimierungen durchgeführt und für den mobilen Zugriff optimierte Medien bereitgestellt werden.
  • Diese Variante ist auch möglich, wenn Sie an der eigentlichen Webseite keinerlei Änderungen durchführen können.

Aber es gibt auch Nachteile:

  • Die Zuordnung mobiles Gerät vs. Desktopbrowser ist schwierig und kann schief gehen.
  • Bei unterschiedlichen Inhalten kann das Problem auftreten, dass Surfer gewünschte Inhalte nicht finden, wenn sie von Suchmaschinen oder über verschickte Links kommen.
  • Inhalte/Features reduzieren setzt voraus, dass man sicher weiß, was welcher Nutzer wann braucht. Dabei werden mobile Nutzer jedoch oft unterschätzt. Symptomatisch hierfür sind die Bezeichnungen für die Links zum Wechseln zwischen den Versionen: Im englischsprachigen Raum wird oft die Desktop-Version als „Full“-Site bezeichnet. Daraus ergibt sich logischerweise, dass die mobile Version nur eine halbe Sache ist … und das ist eindeutig nicht das, was mobile Nutzer wollen.

Wichtig bei der Realisierung einer separaten mobilen Seite ist: Das Skript, das die Kennung interpretiert, sollte immer auf dem aktuellen Stand sein. Außerdem sollte der Nutzer stets die Option haben, sich zwischen den Versionen zu entscheiden. Wenn er in die andere Version wechselt, sollte er natürlich auf der Seite mit den Informationen bleiben, auf der er war – es wäre kontraproduktiv, ihn immer nur auf die Startseite der anderen Version umzuleiten.

Strategie 3: Responsive Webdesign (RWD)
Hauptbestand des klassischen RWD sind CSS3-Media Queries. Über diese können Sie je nach Eigenschaften des Ausgabegeräts – am häufigsten herangezogen wird die Breite des Ausgabegeräts – unterschiedliche CSS-Formatierungen festlegen. Im Sinne von Ethan Marcotte, der den Begriff Responsive Webdesign geprägt hat, gehören zum RWD ebenfalls flüssige Angaben (d.h. Breitenangaben in Prozent) und flüssige Bilder (max-width: 100%). Inzwischen gibt es einige sinnvolle Erweiterung des RWD, wie etwa das serverseitige Ausliefern unterschiedlich direkt angepasster Bilder oder das konditionale Laden einzelner Inhalte mit Ajax.

Beim Responsive Webdesign sind zwei Ansätze zu unterscheiden, je nachdem, was als Ausgangsbasis genommen wird. Beim Desktop-First-Ansatz dient ein Desktop-Layout als Basis, davon ausgehend gibt es dann angepasste CSS-Regeln für kleinere Bildschirme. Umgekehrt ist der Ansatz Mobile First: Hier wird zuerst das Layout für die kleinen Bildschirme entwickelt und dann weitere Anpassungen für Desktops und größere Viewports vorgenommen.

Ein schönes Beispiel für ein RWD nach dem Mobile-First-Ansatz stammt von Brad Frost.

Bild 2: Brad Frost

 Bild 2: Beispiel für einen Mobile-First-Ansatz

Vorteile des RWD:

  • In der Desktop First-Variante ist ein Responsive Webdesign auch auf eine bereits existierende Seite anwendbar.
  • RWD löst das Problem der unterschiedlichen Anzeigebereiche auf dem Desktop und ist deswegen ein Konzept, das über die Optimierung für mobile Nutzer hinausgeht.
  • In der einfachsten Variante sind nicht mehr als CSS-Kenntnisse notwendig, um die Anpassungen durchzuführen.
  • Da immer dieselben Inhalte ausgeliefert werden, besteht keine Gefahr, dass Nutzer von bestimmten Inhalten ausgeschlossen werden.

Aber es gibt eine Reihe möglicher Nachteile:

  • Die Performance bei der mobilen Version ist schlecht, sofern Bilder nur über CSS skaliert oder Inhalte einfach mit display: none ausgeblendet werden.
  • Bei umfangreichen Inhalten muss der Nutzer auf einem Smartphone endlos scrollen.
  • Beim Desktop-First-Ansatz ist häufig die Quellcode-Anordnung für mobile Geräte nicht passend.
  • Der vielversprechendere Mobile First-Ansatz bedeutet ein grundlegendes Umdenken und eine Fokussierung – erstrebenswert, aber recht aufwändig.

Allgemein gilt für das RWD: Die Performance sollte von Anfang an, d.h. schon in der Designphase  berücksichtigt werden. Kontraproduktiv ist es, größere Inhalte per display: none auszublenden, die dann trotzdem geladen werden müssen. Wenn mehr Bilder eingesetzt werden, benötigen Sie eine eigene Lösung für Bilder mit einer serverseitigen Komponente, die für die Auslieferung der passenden Bilder sorgt.

Je mehr die Version für kleinere Viewports von Anfang an mitberücksichtigt wird und je mehr gleichzeitig eine Konzentration auf das Wesentliche stattfindet, desto besser gelingt die Umsetzung. Von der Konzentration auf das Wesentliche profitieren dann natürlich alle Nutzer.

Es kommt darauf an, wie es gemacht ist.
Welcher Ansatz für jeden der richtige ist, hängt natürlich vom Projekt ab. Keiner der beiden Ansätze ist aber per se gut oder schlecht, entscheidend ist die Art der Implementierung. Häufig hingegen werden einzelne Techniken verteufelt mit dem Hinweis auf schlechte Realisierungen. Dass das an sich falsch ist, hat Tim Kadlec schön formuliert: Blame the Implementation, Not the Technique.

Mobile Webseiten

Mobile Webseiten

Mehr Informationen zum Thema Mobile Webseiten finden Sie im gleichnamigen Handbuch.