Mobile Web

Kürzlich habe ich mich mit dem Thema „Mobile Web“ befasst und für meine Website eine „mobile“ Version angelegt, auf die automatisch weitergeleitet wird, wenn ein „mobiler“ Browser erkannt wird.

Bitte auch die Ergänzung am Ende des Artikels beachten.

Der Begriff „Mobile Web“ wurde ursprünglich durch WAP geprägt, einem Standard, der speziell für mobile Geräte mit niedriger Übertragungsgeschwindigkeit und kleinen, monochromen Displays entwickelt wurde. WAP konnte sich allerdings aus verschiedenen Gründen nur bedingt verbreiten und wurde mit der Einführung von UMTS, Handys mit großen Farbdisplays und Browsern, wie Netfront oder Opera Mini weitgehend bedeutungslos. Daraus entstand der Eindruck, dass man nun auf Smartphones einfach die regulären Websites nutzen wird.

Trotz aller Entwicklungen sollte man aber bedenken, dass auch aktuelle Smartphones häufig nur eine Displayauflösung von 480*800 Pixeln oder weniger bieten. Bei höher aufgelösten Displays werden entsprechend größere Schriften genutzt, da Details sonst nur schwer zu erkennen wären. Zudem bedingt eine höhere Displayauflösung in der Regel auch ein größeres Gerät, was aber nicht jeder Nutzer möchte. Tablets lasse ich hier außen vor, da sie bezüglich der Displays eher mit Netbooks vergleichbar sind.

Arbeitsweise aktueller Webbrowser auf Smartphones

Als Kompromiss arbeiten Webbrowser auf Smartphones intern mit einer höheren horizontalen Auflösung (z.B. 850 Pixel Breite bei Opera Mobile) und verkleinern die so erzeugte Ansicht dann so weit, dass der Benutzer eine stark verkleinerte Übersicht zu sehen bekommt, wie hier mit Android 2.3.3:

Mobile Web

Das genügt, um wesentliche Seitenelemente optisch zu finden. Text zu lesen oder Links anzutippen ist aber schwierig bis unmöglich, selbst bei höher aufgelösten Displays.

Um eine Detailansicht mit lesbarem Text zu sehen, tippt man zweimal mit dem Finger auf das Display und erhält eine vergrößerte und lesbare Ansicht, die aber in alle Richtungen verschoben werden muss, um den gesamten Inhalt zu erfassen. Zum Auffinden von Navigationsmenüs oder Startseiten-Links ist das mitunter sehr umständlich. Zudem wird jede weitere aufgerufene Seite wieder zuerst in der Übersicht dargestellt.

Mobile Web

Alternatives Layout für mobile Geräte

Für die Behandlung der Darstellungsbreite auf mobilen Geräten, die eine „normale“ Ansicht erzeugen und nachträglich verkleinern, gibt es eine zusätzliche CSS-Regel, die auch als META-Angabe „viewport“ eingefügt werden kann und sowohl von Opera Mini und Opera Mobile, aber auch von den Browsern bei Android oder iOS beachtet wird. Details dazu siehe auch http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/.

Die Idee dabei ist, dass man dem Browser mitteilt, wie breit das „virtuelle“ Display sein soll, auf dem die Inhalte dargestellt werden. Möchte man das Display des Gerätes 1:1 nutzen, ohne dass der Browser den Inhalt intern breiter zeichnet und dann auf dem Display passend verkleinert, kann man dazu folgendes META-Element in den Kopf eines HTML-Dokuments einfügen:

<meta name="viewport" content="width=device-width, initial-scale=1" />

Damit wird festgelegt, dass die benutzte Darstellungsbreite (viewport) exakt dem Display des Gerätes entspricht (width=device-width) und dass keine Vergrößerung oder Verkleinerung des Inhaltes (initial-scale=1) erfolgen soll. Dadurch entfällt der Wechsel zwischen verschiedenen Ansichten. Das genügt aber oft nicht – denn mit deutlich weniger als 600-700 Pixeln verfügbarer Darstellungsbreite funktionieren mehrspaltige Layouts meist nicht mehr sehr gut, selbst wenn sie sich an die verfügbare Breite anpassen. Es ist daher empfehlenswert, das Layout dafür anzupassen. In der Regel läuft das auf ein einspaltiges Layout hinaus und die vorher genannte Anpassung des Viewports. Auch die Reihenfolge von Seitenelementen sollte für die mobile Nutzung geändert werden. Navigationsmenüs sind am Ende besser aufgehoben, damit der Benutzer nicht erst bei jeder Seite zum eigentlich interessanten Inhalt scrollen muss.

Nachfolgend die selbe Ansicht, wie weiter oben gezeigt, aber mit der „viewport“-Angabe, etwas größerer Schrift und veränderter Anordnung der Elemente:

Mobile Web

Das Navigationsmenü und die Suchfunktion, die vorher in der linken Spalte zu finden waren, sind jetzt am Ende der Seite über den Link „Themen“ erreichbar – deutlich schneller, als zuerst die Seite zu vergrößern und dann ggf. noch an die richtige Stelle zu scrollen. Auch wurde der Kopfbereich vereinfacht, um Platz zu sparen. So wurde der Titel der Website und die „Backlink“-Funktion komplett entfernt, dafür aber ein Link zur Desktop-Version ergänzt (mehr dazu weiter unten). Die in DokuWiki vorhandenen „lokalen“ Inhaltsverzeichnisse, die bei Artikeln mit mehreren Überschriften als Kasten am rechten Rand eingeblendet werden, erscheinen in der mobilen Ansicht ebenfalls nicht, da hierfür in der Regel kein Platz ist.

Nachfolgend noch ein weiterer Vergleich der beiden Varianten in Opera Mini auf einem Gerät mit einer noch geringeren Displaygröße:

Mobile Web Mobile Web

Und mit NetFront, einem Browser der auf vielen „Feature Phones“ zu finden ist:

Mobile Web Mobile Web

Automatische Weiterleitung zur mobilen Version

In HTML gibt es die Möglichkeit, Stylesheets abhängig vom Ausgabegerät einzubinden. So kann man mit dem Attribut „media“ festlegen, ob ein Stylesheet für die Bildschirmdarstellung (screen) oder für den Druck (print) angewendet werden soll.

Für mobile Geräte existiert die Option „handheld“ – und es ist zunächst naheliegend, dass man für mobile Endgeräte zusätzlich ein entsprechend angepasstes Stylesheet einbindet, so dass der Inhalt identisch ist und lediglich durch das Stylesheet für die mobile Darstellung angepasst wird.

Diese Vorgehensweise hat aber mehrere Probleme:

  • Nicht alle mobilen Browser beachten die „handheld“-Regeln
  • Nicht immer ist ausschließlich eine mobile Version gewünscht, Besucher sollten immer die Möglichkeit haben, auch die Desktop-Version einsehen zu können
  • Manche Änderungen, wie eine andere Reihenfolge von Elementen (nicht nur optisch), lassen sich nicht immer allein mit CSS lösen
  • Nicht jeder Inhalt ist für eine mobile Version sinnvoll – man will vielleicht nur eine Auswahl anbieten, die auch für die Nutzung unterwegs interessant ist (z.B. bei einem Kino nur das aktuelle Programm)

Ein besserer Ansatz ist daher oft die Verwendung einer angepassten Version für mobile Geräte unter einer eigenen URL. Damit Besucher nicht erst in der Desktop-Version nach einem Link zur mobilen Ansicht suchen müssen (sofern sie überhaupt davon ausgehen, dass es so eine Ansicht gibt), kann man auch eine automatische Erkennung implementieren, die anhand des User-Agent ermittelt, ob es sich um einen mobilen Browser handelt und bei Bedarf auf die mobile Version weiterleitet.

Man sollte sich aber darüber klar sein, dass die Erkennung über die User-Agent-Angabe des Browsers nicht immer funktioniert. Manche Browser schicken u.U. eine Angabe, die noch nicht bekannt ist oder ein Browser wird als „mobil“ erkannt, obwohl er auf einem Gerät läuft, mit dem das reguläre Layout problemlos darstellbar ist, wie etwa Tablets. Daher ist es eine gute Idee, auch in der Desktop-Version einen Link zur mobilen Ansicht einzubauen und umgekehrt. Beim Wechsel von „mobil“ zu „Desktop“ muss man auch darauf achten, die automatische Erkennung z.B. mit einem temporären Cookie außer Kraft zu setzen, das vor der automatischen Weiterleitung abgefragt wird und diese verhindert.

Eine solche Lösung habe ich für arnowelzel.de auf Basis des Scripts von http://detectmobilebrowsers.com/ implementiert. Die mobile Version kann über http://m.arnowelzel.de erreicht werden. Wird die Desktop-Version mit einem als „mobil“ erkannten Browser aufgerufen, erfolgt eine automatische Weiterleitung dorthin. Ruft man dagegen die „mobile“ Version mit einem Desktop-Browser auf, wird automatisch auf die Desktop-Version umgeleitet. In jeder Version gibt es einen Link zum Wechsel von „mobil“ zu „Desktop“ oder umgekehrt im Seitenkopf, wobei zusätzlich der Parameter „ignoreua“ übergeben wird. Dieser Parameter sorgt dafür, dass ein Cookie gesetzt wird, damit für die Dauer der Sitzung generell keine automatische Weiterleitung mehr erfolgt.

Testmöglichkeiten

Für Tests sollte man echte Geräte nutzen oder Emulatoren, in denen die dort verwendeten Browser nativ ausgeführt werden. „Browser-Emulatoren“, die lediglich einen Rahmen innerhalb einer Website verwenden, um darin eine „mobile“ Ansicht zu simulieren, sind dafür kaum geeignet, da die Darstellung weiterhin vom regulären Desktop-Browser erfolgt und nur sehr eingeschränkt mit dem tatsächlichen Ergebnis auf einem Smartphone vergleichbar ist.

Sofern man ein Smartphone mit WLAN-Anbindung hat, entstehen durch Tests keine zusätzlichen Kosten für die Datenübertragung. Man sollte trotzdem auch unter realen Bedingungen die eigenen Sites zumindest stichprobenweise begutachten, um einen Eindruck für die Ladezeiten zu bekommen.

Eine Übersicht zu verschiedenen Emulatoren findet man auch auf http://www.mobilexweb.com/emulators.

Opera Mini

Opera stellt auf http://www.opera.com/de/developer/opera-mini-simulator ein Java-Applet bereit, in dem die J2ME-Version von Opera Mini ausgeführt wird.

Android

Für Android findet man auf http://developer.android.com/sdk/index.html ein SDK, in dem auch ein Emulator enthalten ist, der Tests auf Geräten mit verschiedenen Displaygrößen und Softwareversionen ermöglicht. Da die Software im Emulator nativ ausgeführt wird, entsprechen die Ergebnisse weitgehend der realen Umgebung und man kann auch mit verschiedenen Browsern, wie Opera Mobile oder Firefox für Android testen.

Responsive Design

Die hier beschriebene Technik ist nur eine Möglichkeit. Die Verwendung von „Responsive Design“, also einem Layout, das sich unter Verwendung von CSS3-media-queries automatisch an das Ausgabegerät anpasst und ggf. Elemente anders anordnet oder gänzlich ausblendet, ist eine andere Variante, die ich ich seit Anfang 2014 mit dem Umstieg von DokuWiki zu WordPress selber nutze.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.