Special: "Mobile Strategie"
Responsive Design oder mobile Website?
Welche die richtige Strategie für mobile Websites ist, darüber wird in der Webgemeinde heftig diskutiert. Unser Artikel informiert Sie über die Vor- und Nachteile beider Ansätze und erleichtert Ihre Entscheidung anhand einer Checkliste.
Jakob Nielsen ist bekannt dafür, dass er mit seinen Statements die Webgemeinde aufmischt - und so war es auch bei seinem Beitrag diesen Frühsommer, als er eine ganz klare Empfehlung abgab:Die richtige Strategie sei es, eine separate mobile Seite zu erstellen mit folgenden Eigenschaften: weniger Features, gekürztem Inhalt und größeren Benutzerelementen. Zu dieser Seite sollten die Mobilnutzer automatisch umgeleitet werden. Gleichzeitig müsse es Links zwischen der mobilen und der vollständigen Seite geben, damit die Benutzer wechseln könnten. Nach Möglichkeit sollte man auch eine dritte Version für Tablets bereitstellen.Zwei Punkte dieser Empfehlung haben einen Sturm der Entrüstung in der Webgemeinde ausgelöst. Zum einen hat Nielsen das Responsive Webdesign, einen der wichtigsten Trends der letzten Zeit, in seinem Artikel mit keinem Wort erwähnt, sondern als einzige Möglichkeit, Nutzern mobiler Seiten ein angemessenes Erleben zu bieten, eine separate mobile Seite ins Spiel gebracht.Zum anderen sind reduzierte Inhalte aus mehreren Gründen problematisch: Damit macht man mobile Nutzer zu Nutzern zweiter Klasse, außerdem ist der "mobile Kontext" nicht klar umrissen und häufig surfen Nutzer mobil zu Hause auf der Couch liegend und wollen keine anderen Inhalte als auf dem Desktop.Betrachten wir abseits einseitiger Betrachtungsweisen die beiden Ansätze, die sich mit der mobilen Nutzung befassen.
Separate mobile Website
Das Prinzip der zwei oder mehr separaten Websites beruht darauf, dass es verschiedene HTML-Dokumente mit zugehörigen Ressourcen (Stylesheets, Bildern, Javascript-Dateien) gibt, die je nach Kontext ausgeliefert werden.Desktop- und Mobilversion können sich in folgenden Punkten unterscheiden:
- Anordnung des Quellcodes: Beispielsweise ist die Navigation auf mobilen Websites besser unten angeordnet.
- Optimierte Bilder: Auf dem Desktop darf es gerne auch mal groß sein, bei mobilen Geräten sollten Bilder aus Performance-Gründen nur genauso groß sein, wie man sie braucht. Eine automatische serverseitige Skalierung funktioniert nicht immer, weil dabei manchmal auf einem kleinen Bildschirm wichtige Details nicht erkennbar sind. Hier greift man besser händisch ein und stellt ein optimiertes Bild zur Verfügung, das dann vielleicht auch nur ein Ausschnitt aus dem großen Bild ist.
- Struktur: Zweitrangige Inhalte könnten auf der Desktop-Seite direkt integriert werden, auf der mobilen Seite werden sie erst über einen Link erreichbar.
- Besondere Inhalte für das Smartphone: Hinweise auf die native App oder ortsbezogene Werbung sind auf der mobilen Website wichtig, nicht aber in der Desktop-Version.
Geräte-Erkennung
Bei einer separaten mobilen Website kommt es natürlich ganz wesentlich darauf an herauszufinden, ob es sich um eine Anfrage von einem mobilen Gerät handelt oder nicht.Hierfür wird der User Agent String ausgelesen. Jeder Browser, der eine Website anfordert, sendet eine kurze Kennung, in der er sich vorstellt - den User Agent String.Dieser lautet beispielsweise bei einem Chrome auf dem Desktop: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5.Bei einem Android-Browser auf einem HTC Sensation sieht er folgendermaßen aus: Mozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30.Und so beim iPhone 4s/5.01: Mozilla/5.0 (iPhone; U; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A406 Safari/7534.48.3.Diese Beispiele sollen nur kurz zeigen, dass ein direktes Interpretieren und Zuordnen, ohne sich tiefer damit zu beschäftigen, nicht klappt: Aus historischen Gründen nennen sich beispielsweise alle Browser Mozilla und alle geben an, "like Gecko" zu sein, obwohl in keinem dieser Browser eine Gecko-Rendering-Engine werkelt.Mit den Feinheiten der User Agent Strings kann man sich lange und intensiv beschäftigen, aber praktischer ist, man lässt sich helfen. Eine schnelle Lösung ist detectmobilebrowsers.com. Es liest den User Agent String aus, sucht nach dem Vorkommen von eindeutigen Indizien für mobile Browser und führt dann die Umleitung auf die gewünschte Seite durch.Ein bisschen anspruchsvoller ist das Skript php-mobile-detect, das noch weitere Header untersucht und auch mehr Differenzierungen erlaubt. So kann man etwa je nach mobilem Betriebssystem einen unterschiedlichen Code ausführen oder differenzieren lassen, ob es sich beim Gerät um ein Tablet oder ein Smartphone handelt.Richtig viele Details über die anfragenden Geräte inklusive Bildschirmauflösung, weiterer Hardware-Features und Techniken bieten Device Description Repositories, also Sammlungen von Gerätebeschreibungen. Ein Beispiel hierfür ist WURFL, für das es Programmierschnittstellen in verschiedenen Sprachen gibt.
Unzuverlässige User Agent Strings
Prinzipiell setzt die Kritik an den separaten mobilen Seiten schon bei den User Agent Strings an, denn diese bringen zwei grundlegende Probleme mit sich: Zum einen können sie gefälscht werden - so hat etwa Opera sich lange Zeit als Explorer ausgegeben - und zum anderen ist die Lösung nicht zukunftssicher: Die benutzte Vergleichsliste kann nur bekannte User Agents berücksichtigen und kennt nicht diejenigen, die in der Zukunft noch kommen werden. Zwei Beispiele für Neuerungen in der letzten Zeit sind Chrome für Android (und iOS) sowie der mobile Firefox.Das Problem an der Verwendung von User Agents ist auch, dass dieses Browser Sniffing einen schlechten Ruf hat; man denkt dabei an die Javascript-Weichen aus den Neunzigern. Bei diesen wurde ermittelt, ob es sich um einen Netscape oder einen Internet Explorer handelte, und dann eine Umleitung durchgeführt, im Zweifelsfall aber oft so ungeschickt, dass Nutzer alternativer Browser gar nichts zu Gesicht bekamen.
An dieser Stelle erweist sich Feature Detection heute als besserer Weg: Meist interessiert uns schließlich nicht, wie ein Browser heißt, sondern was er kann. Aber das hilft nichts, wenn das Senden der für mobile Geräte optimierten Inhalte erfolgen muss, bevor man beispielsweise mit Javascript ermittelt hat, was der Browser kann.Deswegen sind folgende Dinge bei der Zuordnung mittels User Agent String zu beachten:Wichtig ist eine vernünftige Fallbacklösung. Falls der User Agent String nicht erkannt wird, muss man die Besucher ebenfalls zu einer der verfügbaren Versionen umleiten und nicht einfach als nicht erkannt abweisen. Außerdem sollte man den User Agent String nicht nutzen, um Benutzer von Informationen auszuschließen. Besucher auf eine Seite umzuleiten, auf der sie erfahren, dass die Seite noch nicht für mobile Geräte optimiert wurde, ist dabei ein absolutes No-go.Die Listen mit den User Agent Strings sollten aktuell gehalten werden.Da die Zuordnung immer auch falsch sein kann, muss der Benutzer die Version wechseln können. Diese Einstellung sollte gespeichert werden, damit der Benutzer den Versionswechsel nicht immer wieder neu vornehmen muss.
Reduzierte Inhalte
Weitere Probleme ergeben sich dadurch, dass man die Inhalte oder Features für die mobilen Seiten beschränkt: Bei der Inhaltsreduzierung macht man oft falsche Annahmen zu den Nutzern. So gibt es beispielsweise auf der mobilen Seite von bahn.de (mobile.bahn.de ) keinerlei Information über die Ausstattung der Züge (Minibar, Speisewagen). Oft wird der Anspruch der Benutzer unterschätzt. Man unterstellt etwa mobilen Nutzern irrtümlicherweise gerne, sie wollten keine Inhalte eingeben.Wenn es verschiedene Inhalte auf der Desktop- und der Mobil-Vversion gibt, passiert es leicht, dass Aktualisierungen nicht überall gleichermaßen durchgeführt werden und beispielsweise die Sonderangebote nicht oder zu spät aufgenommen oder gelöscht werden. Bei der Weitergabe von Links per E-Mail oder Ähnlichem kann es Probleme geben, wenn ein Desktop-Link auf einem mobilen Gerät angesehen wird, aber bei der entsprechenden reduzierten mobilen Version die betreffenden Inhalte nicht vorhanden sind.Besser wäre es, solche sekundären Inhalte für Nutzer mobiler Geräte erst einmal nicht anzuzeigen, wohl aber durch einen Link verfügbar zu machen.Oft wird als Argument gegen die separaten mobilen Seiten das One-Web-Prinzip herangeführt. Das W3C sagt aber explizit : "Ein Web (One Web) bedeutet nicht, dass exakt dieselben Informationen in exakt demselben Format auf allen Geräten verfügbar sind".
Responsive Webdesign
Responsive Webdesign ist eine neue Herangehensweise, die Problematik der so unterschiedlichen Geräte neu zu lösen. Die wichtigste Komponente des Responsive Webdesign sind CSS3 Media Queries. Über diese kann man je nach Eigenschaften des Ausgabegeräts unterschiedlichen Formatierungen anwenden. So kann eine Website bei viel verfügbarem Platz mehrspaltig und bei wenig verfügbarem Platz einspaltig angezeigt werden.
/* Immer angewandt */
#navi, #inhalt { width: 98% }
/* Bei groesseren Bildschirmen wird die
obige Angabe durch die folgende ueberschrieben */
@media all and (min-width: 500px) {
#navi { width: 30%; float: left; }
#inhalt { width: auto; margin-left:
30%; }
}
Zum Responsive Webdesign gehört mehr: so auch ein flüssiges Layout und flexible Bilder, die sich an die Bildschirmgröße anpassen. Das wird im einfachsten Fall erreicht, indem man die Breitenangaben beim img-Element herausnimmt und über CSS folgende Angabe macht:
img {
max-width: 100%;
}
Damit behalten Bilder ihre inhärente Größe, werden aber nie größer als der sie umgebende Block.Der Vorteil von Responsive Webdesign ist, dass es zumindest auf den ersten Blick so einfach aussieht: Man muss nur das Stylesheet ein bisschen anpassen und die Angaben für die schmalen Bildschirme ergänzen und schon hat man eine Website, die auf den schmalen Bildschirmen wunderbar funktioniert.
Nachteile des Responsive Design
Diese einfache Variante hat aber auch mehrere Nachteile:
- Performance: Bei über CSS kleinskalierten Bildern werden trotzdem noch die großen Bilder auf den mobilen Geräten geladen, was die Ladezeit verlängert. Auch per display: none ausgeblendete Inhalte, müssen trotzdem heruntergeladen werden. Das sorgt für schlechte Performance, doch diese ist gerade für mobile Geräte extrem wichtig.
- Quellcode-Anordnung: Für Mobilnutzer sind die Inhalte oft nicht in der optimalen Reihenfolge, wenn man von einer bestehenden Desktop-Seite ausgeht. Dann kann es sein, dass der Nutzer lange scrollen muss.
- Inhalt: Überhaupt kann es vorkommen, dass der Nutzer vor lauter Scrollen den Überblick verliert. Auf einer Desktop-Seite ist normalerweise eine Menge Inhalt untergebracht, und wenn man diesen auf einem kleinen Bildschirm unterbringt, wird es unübersichtlich. Außerdem können Sie bei einer Responsive-Webdesign-Seite immer nur denselben Inhalt für alle Situationen ausgeben. Aber es gibt Fälle, in denen verschiedene Inhalte für verschiedene Situationen gefragt sind.
- Für mobile Geräte, die kein Javascript ausführen können, gibt es eigene serverseitige Analysetools, beispielsweise Google Analytics for Mobile Websites .
- Auf der mobilen Seite ist eventuell eine andere Werbung angebracht als auf der normalen Website. Zum Beispiel wären auf der mobilen Website Hinweise auf native Apps sinnvoller als in der Desktop-Version.
Was wählen?
Beide Ansätze haben also ihre Vor- und Nachteile, wobei sich letztere durch die richtige Strategie und das bewusste Einsetzen der Technik verringern lassen. Bei der Entscheidung, welche Vorgehensweise bei einem konkreten Projekt die richtige ist, gibt es drei grundlegende Fragen:
- Wie unterschiedlich sind die Inhalte für den wichtigsten mobilen Kontext? Ein Extrembeispiel: Sie machen eine Website für eine Veranstaltung mit allgemeinen Informationen. Während der Veranstaltung haben die Nutzer die Möglichkeit, auf der mobilen Seite über einzelne Punkte der Veranstaltung abzustimmen. Damit haben Desktop- und Mobilversion nicht mehr viel miteinander zu tun. In einem solchen Fall greift Responsive Webdesign zu kurz, Sie müssen auf eine separate Website setzen.
- Können Sie etwas an der Desktop-Seite ändern? Wenn ja, und wenn Sie sogar vor einem vollständigen Relaunch stehen, ist Responsive Webdesign mit Mobile First ein sehr guter Ansatz, der Sie zwingt, sich auf die wichtigsten Dinge zu konzentrieren und die mobile Version von Anfang an im Blick zu haben. Wenn nein, kommt es darauf an, inwieweit die Desktop-Seite durch kleine Anpassungen wie Responsive Webdesign schon akzeptabel wird. Ist dies nicht der Fall, ist eine separate Website die bessere Wahl.
- Wie sieht es mit den technischen Gegebenheiten aus? In anderen Worten: Welche Optionen bietet das benutzte CMS überhaupt derzeit, wie sehen die Kenntnisse der Leute aus, die das Projekt realisieren?
