Bild 1: Bitte haben Sie etwas Geduld

Bild 1: Bitte haben Sie etwas Geduld

Bei der Realisierung von Webseiten für mobile Nutzer ­– sei es dass man eine separate mobile Webseite einsetzt oder die Technik des responsive Webdesign wählt – kann einiges schiefgehen. Sehen wir uns eine kleine Auswahl von typischen Fällen an.

„Bitte haben Sie etwas Geduld!“ (Schlechte Performance)

Man könnte annehmen, dass mobile Nutzer um die Besonderheit ihrer Geräte und ihrer Situation wissen und deswegen nicht erwarten, dass alles gleichermaßen schnell funktioniert wie auf einem leistungsstarken Desktop-Rechner. Aber das Gegenteil ist der Fall, wie ein paar Zahlen der „Mobile Web Experience Survey“ von Equation Research eindrucksvoll beweisen:

  • 71% der mobilen Nutzer erwarten, dass Webseiten genauso schnell auf einem mobilen Gerät laden wie auf einem Desktop-Rechner.
  • 74% der mobilen Nutzer warten höchstens 5 Sekunden, bis die Seite geladen ist; 60% der mobilen Nutzer warten sogar nur 3 Sekunden.
  • 57% der Benutzer würden eine langsam ladende Seite nicht empfehlen.
  • 3% der Nutzer werden wahrscheinlich nicht zu einer langsam ladenden Seite zurückkommen.

Das zeigt deutlich: Performance ist ein ganz entscheidender Faktor, wenn nicht sogar einer der Hauptfaktoren.

Das Problem an der Performance ist allerdings, dass sie „unsichtbar“ ist und sich nicht in derselben Weise präsentieren lässt wie schicke grafische Effekte. Erschwerend kommt hinzu, dass mobile Webseiten zu oft unter optimalen Bedingungen getestet werden, d.h. auf neuen Geräten und bei einer flotten WLAN-Verbindung.

„Bitte drehen Sie Ihren Bildschirm!“ (Den Nutzern vorschreiben, wie er die Webseite zu nutzen hat)

Ich erinnere mich noch mit Schaudern an Webseiten, bei denen – per JavaScript – bei Aufruf automatisch das Fenster in den Vollbildmodus sprang.  So etwas würde einem heute niemand mehr zumuten. Aber auch und gerade bei der mobilen Nutzung gibt es immer wieder Fälle, in denen dem Besucher vorgeschrieben wird, wie er die Seite zu verwenden hat.  Bei WTF-Mobile finden Sie Beispiele für Webseiten, die den Nutzer auffordern, sein Smartphone zu drehen, um die Seite besser zu sehen.

Zoomen ist ein Menschenrecht!

Ein anderer Fall ist die Zoommöglichkeit. Häufig wird das Zoomen auf Smartphones prinzipiell unterbunden über die folgende Meta-Angabe:

<meta name=“viewport“ content=“ width=device-width, initial-scale = 1.0, user-scalable=no,  maximum-scale = 1.0″ >

Die Möglichkeit zu skalieren ist wichtig aus Gründen der Zugänglichkeit; im Zweifelsfall vergrößert ein Benutzer Elemente einer Webseite, weil er sie dann besser oder überhaupt erst lesen kann. Vielleicht will er aber auch nur  einen Ausschnitt der Seite – etwa ein Bild – jemand anderem zeigen.

Diese Meinung setzt sich immer mehr durch, so war etwa auch bei Mobile Boilerplate am Anfang das Zoomen deaktiviert, jetzt aber wird nur noch die folgende Viewport-Meta-Angabe benutzt:

<meta name=“viewport“ content=“width=device-width“>

Damit ist der automatische Zoom beim ersten Laden der Seite ausgeschaltet, aber der Nutzer kann weiterhin zoomen, wenn er es braucht.

Tipp: Wenn Sie sich an dem iPhone-Scaling-Bug stören, der bei einem Wechsel von Porträt/Landschaftsmodus auftritt, so gibt es Abhilfe per JavaScript.

Apps funktionieren anders als Webseiten

Aber natürlich gibt es Ausnahmen von der allgemeinen Empfehlung, wonach man dem Benutzer weitgehende Freiheit in der Bedienung lässt. In dem Moment, in dem es um besondere Anwendungen wie etwa Spiele geht, kann das Vorschreiben bestimmter Einstellungen oder das Abschalten des Zooms akzeptabel sein.

„Wollen Sie wirklich ernsthaft auf unsere mobile Seite wechseln?“ (Störende modale Fenster)

Bild 2: Achtung, mobile Seite!

Bild 2: Achtung, mobile Seite!

Letztens wollte ich wissen, wie das Wetter an Pfingsten in Südfrankreich ist. Auf einem mobilen Gerät klicke ich auf einen vielversprechenden Link. Statt der Wettervorhersage erscheint ein modales Fenster mit der Frage, ob ich die mobile oder die Desktop-Seite ansehen möchte. Nach dieser nicht einfachen Entscheidung   erscheint das nächste modale Fenster, ob ich diese Einstellung speichern möchte.Beides sind Fragen, die mich als Benutzer nicht interessieren. Ich möchte eine Information haben, ohne dass ich über die Art der Präsentation nachdenken muss.

Dass diese modalen Fenster gerade eingeblendet werden, wenn man mit einem mobilen Gerät eine Webseite besuchen will, erweckt den Eindruck, der Besucher müsse vor der mobilen Version gewarnt werden. Den Warnhinweis in dem gezeigten Screenshot habe ich so zwar nie „in echt“ gefunden, aber er soll demonstrieren, wie diese modalen Warnungen wirken können.

Wenn es zwei Versionen einer Webseite gibt, dann sollte eine Umleitung automatisch stattfinden – wobei es natürlich zum guten Stil gehört, dass der Benutzer jederzeit die Möglichkeit hat, zur anderen Version zu wechseln. Üblicherweise sollte der Link auf die mobile Version ganz oben sein – damit ein Benutzer nicht lange scrollen muss, falls er auf der Desktop-Version ist und zur anderen wechseln möchte. Der Link auf die Desktop-Seite kann auch unten auf der Seite angebracht werden, damit nicht unnötig Platz verschenkt wird.

„Das, weswegen Sie herkommen, haben wir hier nicht.“ (Links ins Leere )

Bild 3: Typisches Problem - Inhalte nicht vorhanden

Bild 3: Typisches Problem – Inhalte nicht vorhanden

Typisches Problem: Inhalte sind auf der mobilen Version nicht vorhanden.

Besucher kommen auf verschiedenen Wegen auf eine Webseite. Üblich ist beispielsweise, dass sie einem Link folgen, den ihnen jemand anderes geschickt hat. Auch nicht unüblich ist es, dass derjenige, der den Link schickt, einen anderen Gerätetyp verwendet hat als derjenige, der den Link erhält und drauf klickt. Der langen Rede kurzer Sinn: Es ist frustrierend für einen Nutzer, auf einen Link zu klicken, um eine bestimmte Information zu erhalten … und dann zu erfahren, dass diese Information nicht auf der mobilen Seite zur Verfügung steht, oder um dann  auf die Startseite der mobilen Version umgeleitet zu werden.

„Sie haben sicher ein iPhone? Nein? Dann kann es nur ein iPad sein, stimmts?“ (Gerätefixierung)

bildschirmgroessenJedes iPhone ist ein Smartphone, soweit ist die Sache klar. Das Umgekehrte gilt allerdings nicht. Nicht jedes Smartphone ist ein iPhone. Trotzdem wird – sicher auch aufgrund der weiten Verbreitung von iPhones in Webdesigner-Kreisen – oft das iPhone als das „Standard-Smartphone“ angesehen. Beispielsweise gelten die vermeintlich „magischen Werte“ von 320px und 480px als verfügbare Pixelbreite nur bei iPhones. Derartige Standardbildschirmgrößen gibt es nicht bei Android. Wie Brad Frost es einmal schön formuliert hat: 320px und 480px sind nur Tropfen im Ozean der Bildschirmgrößen. („The numbers 320, 480, 768, and 1024 mean nothing to you. You recognize that they are simply drops in a much larger ocean.“  – Die anderen hier erwähnten Größen beziehen sich auf das iPad.)

Die Grafik von Brad Frost This Is Responsive zeigt – im Original noch animiert – schön, dass es keine festen Größen gibt.

Was aber macht man, wenn es keine genormten Größen gibt? Von welchen Geräten soll man denn dann ausgehen? Die Antwort ist klar: Man muss den Blickwinkel ändern und nicht von Geräten ausgehen, sondern von Inhalten. Denn den Kampf gegen die Geräte, d.h. die Berücksichtigung aller möglichen Bildschirmgrößen, hat man verloren, bevor man ihn begonnen hat. Beispielhaft im Folgenden ein Ausschnitt aus einem Stylesheet einer mobilen Webseite, die die Unmöglichkeit des gerätezentrierten Ansatzes demonstriert (wohlgemerkt: Das ist nur ein Ausschnitt!):

@media all and (max-width: 266px) { /* legacy phones */ }
@media all and (min-width: 267px) and (max-width: 279px) {
/* Opera Mini on Android */ }
media all and (min-width: 280px) and (max-width: 319px) {
/* Opera Mini on Android */ }
@media all and (min-width: 320px) and (max-width: 359px) {
/* 320px portrait */ }
@media all and (min-width: 360px) and (max-width: 368px) {
/* 360px portrait (oversize phones) */ }
@media all and (min-width: 369px) and (max-width: 399px) {
/* 369px portrait (oversize phones) */ }
@media all and (min-width: 400px) and (max-width: 479px) {
/* 400px Landscape (Galaxy Wave) */ }
@media all and (min-width: 424px) and (max-width: 479px) {
/* Opera Mini on the Galaxy Nexus */ }
@media all and (min-width: 480px) and (max-width: 532px) {
/* 480px landscape */ }
@media all and (min-width: 533px) and (max-width: 597px) {
/* 533px landscape */ }
@media all and (min-width: 598px) and (max-width: 638px) {
/* 480px landscape */ }
@media all and (min-width: 640px) and (max-width: 959px) {
/* 640px landscape */ }
@media all and (min-width: 704px) and (max-width: 959px) {
/* Opera Mini (Nexus) landscape */ }
@media all and (min-width: 960px) {
/* tablet; desktop */ }

Fazit

Das war nur ein kleiner Streifzug durch die Welt der MMs (d.h. der mobilen Missgeschicke). Nicht erwähnt wurde beispielsweise der Klassiker: die „bitte Flash-Plug-in herunterladen“ –Meldung auf einem iPad oder eine Umleitung des mobilen Nutzers auf einen Bildschirm, der ihn informiert, dass er demnächst etwas zu sehen bekommt, aber bis dahin auf den Desktop-Rechner ausweichen muss. Das und noch mehr finden Sie auf WTF Mobile.

Einige der vorgestellten Punkte haben etwas mit dem Thema Kontrolle zu tun. Der Schritt von Print zu Web geht einher mit einem Kontrollverlust, denn Sie haben bei Webseiten prinzipiell nie dieselbe Kontrolle über die Darstellung wie beim Druck. Schön beschreibt John Allsopp in seinem Artikel auf A List Apart, dass es wichtig, diesen Kontrollverlust zu akzeptieren und nicht dagegen zu arbeiten. Und das gilt umso mehr angesichts der Vielfalt an mobilen Geräten.

Mobile Webseiten

Mobile Webseiten

Wenn Sie mehr lesen wollen – hier geht’s zum Handbuch Mobile Webseiten.