Zur Zeit wird irgendwie alles mobil. Die Email auf dem Handy, das Internet auf dem iPhone - dass meine Oma mit 80 noch Auto fährt ist da nix besonderes mehr… Aber wie geht das eigentlich? Was ist so magisch an dem Wörtchen “mobil”? Braucht es etwas besonderes, um eine Webseite mobil zu machen?
Eieiei, Fragen über Fragen. Aber dem werden wir mal auf den Grund gehen. In Anbetracht der Tatsache, das das Kundenvolk immer lauter nach mobilen Webseiten schreit, ist es eigentlich auch höchste Zeit, hier mal einzuhaken.
Also legen wir mal ganz gemütlich los:
Warum mobile Webseiten…
…wenn fast jeder halbwegs moderne Handy-Browser (beim iPhone Safari, bei meinem Nokia Opera) stinknormale Webseiten rendern können? Ganz klar: Sprit sparen. Äh natürlich Datenvolumen. Je mehr Datenvolumen, umso länger dauert die Übertragung und umso länger dauert das Verarbeiten und Rendern des Quelltextes.
Ausserdem macht es natürlich keinen Spaß, eine riesen Hintergrundkachel runterzuladen, nur um es dann wieder klein zu skalieren. Gut, OK, ich weiß, Opera greift auf eine Art Proxydienst zu, der das on-the-fly beim Abrufen macht - bevor der ganze Mist auf dem mobilen Endgerät (will heissen: Handy oder Smartphone) landet.
Natürlich gibt es noch die halbherzige Möglichkeit, über den CSS-Media-Type ein Stylesheet für mobile Geräte zu hinterlegen, das alles mögliche ausblendet. Aber dabei bleibt es ja leider auch. Man sieht es zwar nicht, aber es ist trotzdem da.
Hat sich eigentlich jemand mal diesen kleingerechneten Quatsch angeschaut? Mal wieder haben wir den Beweis - bei Muttern ist es immer noch am besten, oder: Es müssen zielgerichtete Inhalte her.
Wer braucht eigentlich mobile Webseiten?
Gute Frage - wer Geld verdienen möchte, beantwortet sie aber grundsätzlich falsch. Es gibt nicht viele Webseiten, bei denen es sich lohnt sie mobil zu machen. In Wirklichkeit ist es nur eine Hand voll. Ich überlege da einfach mal laut:
Man braucht natürlich mobile Webseiten, wenn man Informationen abrufen möchte, die man benötigt, wenn man unterwegs ist:
- Adressen zum Navi-Füttern
- Telefonnummern zum Telefonieren
- Eben mal eine E***-Auktion überwachen und bieten
- Ein Schnell-Twitterer oder Mini-Blog-Eintrag
- News lesen
- Die Lösung der Aufgabe aus der Mathe-Klausur googeln
Sonst noch was?
Zielgerichteter Content
Ohweh, ein böses Wort. Was da alles dahinter steckt. Viele denken einfach. Joa, ich hab ja mein CMS - da sind ja schon alle Daten und Texte drin. Dann machen wir einfach mal ne mobile Webseite.
Schon klar. Aber man sollte auch bedenken, das die Displays kleiner sind. In der Regel heisst das: Den selben Inhalt mit weniger Worten und Bildern zu vermitteln. Heraus kommt ein komprimierter Text, dessen Inhalt nicht der zusammengestutzte Bruder der “großen” Internet ist, sondern ein vollwertiger Vertreter des selben.
Das macht natürlich Arbeit - auch wenn sich die Redakteure und Website-Betreiber sich darum drücken möchten.
URLs für das mobile Internet
Wie jetzt? .mobi? oder wie oder was? Wer eine mobile Website betreiben möchte, braucht in der Regeln keinen eigens dafür abgestellten Server (es sei denn, es ist natürlich ein spezieller Mobile-Service) - der Standard Apache oder IIS tut’s auch. Aber wie macht man die mobile Website erreichbar?
- www.unternehmen.de: Man verwendet eine Browserweiche (dazu gleich mehr) und die Standard Unternehmens-URL und leitet auf die mobile Präsenz weiter oder zeigt sie direkt an.
- www.unternehmen.de/m: Die Standard Unternehmens-URL und einen Unterordner, Alias, Rewrite oder Reverse-Proxy.
- m.unternehmen.de: Eine Subdomain gefällig?
- www.unternehmen.mobi: Eine Toplevel-Domain ist natürlich auch eine feine Sache - kostet in der Regel aber ordentlich extra.
Aus Usability-Gründen ist natürlich Möglichkeit 1 absolut top: Der Benutzer muss sich nur eine einzige URL merken. Alles andere ist aus meiner Sicht OK, solange es kurz ist.
Wer extra eine neue .mobi URL registriert sollte darauf achten, gleich eine Abkürzung zu wählen: da die TLD schon vergleichsweise lang ist, den eigentlichen Domain-Namen möglichst kurz ausfallen lassen (will heissen: unter 6 Zeichen).
Und noch ein Wort an die Serveradmins: zwingt den Benutzer nicht dazu, ein www vor dem Domain-Namen anzugeben. Wer Duplicate-Content aus SEO Gründen vermeiden möchte, sollte bei einem Aufruf der Domain ohne www einen Redirect verwenden und den Benutzer automatisch auf den richtigen Weg schicken.
Fallbeispiel: Die mobile Unternehmens-Website
Das Telefon klingelt, der Kunde verlangt nach einer mobilen Website. Was bietet man ihm denn nun am besten an. Wohlgemerkt ohne ihm zu viel aufzuschwatzen - das bringt zwar kurzfristig Geld, aber unzufriedene Kunden. Ich fasse mal zusammen, was meine Meinung nach auf eine mobile Unternehmens-Standard-Website gehört:
- Die Öffnungszeiten. Von wann bis wann ist man erreichbar?
- Die Nummer der Hotline oder Zentrale. Wenn man keine Zeit hat, direkt einen Ansprechpartner zu suchen, kann man sich einfach verbinden lassen…
- Die Adresse des Unternehmens. Wenn es mehrere Zweigstellen gibt, diese von der Seite mit der Adresse des Hauptsitzes direkt verlinken. Bei 3 oder weniger Zweigstellen überlegen, ob man nicht einfach alle Adressen auf einer Seite untereinander listet.
- Wichtige Ansprechpartner mit Durchwahl. Wichtige Ansprechpartner (z.B. GF-Assistenz, Vertriebsteam, Support/Helpdesk oder Notruf-Nummern) mit Durchwahl listen.
- Eine Seite über das Unternehmen: Wer sind wir, was machen wir, Kompetenzen, Link zu Ansprechpartnern.
- Technische Daten zu Produkten: Wer Produkte vertreibt und seinen Aussendienstlern technische Daten wie z.B. Abmessungen bereitstellen möchte, sollte das über eine Suchfunktion realisieren, die auf der Produkt-ID oder Produktnummer basiert. So finden fachkundige Besucher schnell die Werte, die sie benötigen.
Wer aufmerksam war, hat gemerkt, dass eine Sache im Vordergrund steht: Kurz und prägnant sein. Keine langen Klick- oder Navi-Wege.
WML, XHTML oder was?
WML hat längst ausgesorgt. Sicherlich wird dieser Standard von allen mobilen Geräten mit Internetzugang unterstützt, die Formatierungen sind aber stark eingeschränkt. So gibt es kein CSS und nur S/W Grafiken.
Der Nachfolger von WML heisst gewissermaßen XHTML MP (”Mobile Profile”). Wie man bei Wikipedia nachlesen kann, basiert es auf XHTML Basic, unterstützt aber noch zusätzliche Elemente. In Verbindung mit WCSS (”Wireless CSS“) und ESMP (”ECMA Script Mobile Profile“, ein abgespecktes Javascript) hat man hier vielfältige Gestaltungs- und Interaktionsmöglichkeiten.
Vor dem geballten Einsatz neuer Technologie sollte man sich aber auf jeden Fall informieren, welche Endgeräte den neuen Schnickschnack überhaupt unterstützen. Aber ich bin mir sicher, in den nächsten Jahren wird sich da einiges tun!
Jetzt noch ein Link zu einem klasse Tutorial zum XHTML Mobile Profile (engl.)
PHP Browserweichen
Bei mobilen Browserweichen muss man zwischen zwei Arten unterscheiden:
- Die einfache Browserweiche: Unterscheidet nur ob mobiles Endgerät oder nicht und veranlasst dann den einen oder anderen Redirect. Oft basieren die einfachen Browserweichen nur auf der übermittelten Browserkennung, dem Betriebssystem und der Displaygröße und lassen sich leicht austricksen.
- Die komplexe Browserweiche: Die Entscheidung basiert nicht nur auf der Browserkennung, sondern auch auf Meta-Informationen wie aus dem UA-Profil und der UA-Kennung (UA = User Agent). Die komplexe Browserweiche stellt die ermittelten Meta-Informationen normalerweise über eine API zur Verfügung.
Wer nur eben mal schnell eine Umleitung für ein mobile Gerät machen möchte, ist mit einer einfachen Browserweiche gut beraten. Der Code ist oft überschaubar und performant. Beispiele für eine Browserweiche wären zum Beispiel die “mobile phone detection” von Andy Moore (engl.) oder das “Mobile Detection Kit” von Eugenia Loli-Queru und Adam Scheinberg.
Komplexer wird die ganze Geschichte schon mit WURFL. WURFL ist die Abkürzung für “Wireless Universal Resource File” und besteht im Kern aus einer XML-Datei mit Endgeräten-Spezifikationen und zum anderen aus einer API zum Auslesen der XML-Datei. Das besondere an WURFL ist, dass es in guter alter Open Source Manier gepflegt und aktualisiert wird. Jeder gibt sein Quentchen hinzu und heraus kommt eine riesen Datenbank. Wer nicht nur in PHP entwickelt, sollte auf jeden Fall mal auf WURFL schauen, denn die API gibt es für nahezu jeder modernen Programmiersprache.
Kommerziell organisiert sind hingegen DetectRight und DeviceAtlas. Beide stellen zwar eine kostenlose Entwickler-Lizenz bereit, sobald man aber ein Projekt aufsetzen möchte, wirds teuer: Während DetectRight eine Liveabfrage auf einer Online-Datenbank durchführt, bietet DeviceAtlas eine ähnliche Lösung wie WURFL und verwendet eine JSON Datei.
Ein paar Tipps…
…zur Verwendung der Meta-Informationen. Ich möchte ja nicht, das jemand mit leeren Händen heimgeht. Deshalb zum Schluss ein paar Hinweise, wie man die Meta-Daten von WURFL und Co geschickt einsetzt.
Generell sollte man schwächere Endgeräte nicht mit schlechteren Informationen versorgen, wie meinetwegen Geräte mit größerem Display. Das Stichwort wäre hier “angepasste Inhalte”.
Beispielsweise kann man das Unternehmens Logo in zwei Auflösungen bereithalten. Endgeräte mit kleinerem Display bekommen das kleinere Logo übermittelt, Endgeräte mit großem Display das entsprechend größere. Da freuen sich alle: Beim größeren Gerät wird der Platz genutzt, bei dem kleineren Gerät wird die Datenübertragung nicht unnötig strapaziert.
In der Regeln kann man auch unterstützte Dateiformate auslesen. Warum keinen PDF Download anbieten für Geräte, die PDF-Dateien darstellen können? Wichtig: Wenn man das macht, auf jeden Fall die Dateigröße vor dem Download anzeigen ;)
