Mobile Web Design

Das Thema “Website vs. App” ist die eine Sache, spezielle Webseiten-Ausprägungen nach Geräteklasse (device-detection) eine andere. Fragt mich doch neulich jemand nach einer “iPhone WAP Browser-Weiche“. Also, hier ist eine ganz simple Weiche in PHP. Das Prinzip, wie immer, lautet HTTP-Header auslesen und einen Redirect auslösen:

Hier die index.php :

<?php
if(eregi(”iPhone”,$_SERVER[”HTTP_USER_AGENT”])){
header(”Location: http://m.mwxp.de/iweiche/iphone.php”);
}else {
header(”Location: http://m.mwxp.de/iweiche/default.php”);
}
?>

Um dies gleich zu testen, hier ein Beispiel. Einfach folgende Adresse in beliebigem (vor allem mobilen) Webbrowser eingeben, anschließend mal im iPhone:
m.mwxp.de/iweiche

Als Nachtrag zum letzten Beitrag zum Thema “viewport meta tag”, habe ich mal eine Version mit und ohne diesen eingebaut. Im Apfeltel sowie im Opera Mobile u.a. kann man den Unterschied gut sehen.

Natürlich kann man obiges Beispiel in jeder beliebigen serverseitigen Sprache nachbauen und vor allem verfeinern. Oder gleich eine professionelle Device Detection ala Device Atlas einsetzen.

Eine explizit für mobile Geräte (also “Handys”) optimierte Website sollte unbedingt trotzdem den “viewport meta tag” mitbringen.

Wieso trotzdem? Was macht dieser “viewport meta tag” denn eigentlich?
Dieser meta tag wurde ursprünglich von Apple eingeführt, um die Darstellung von “normalen” Webseiten  auf dem iPhone besser zu kontrollieren. Per default geht es von einer Standard-Webseiten-Breite von 980px aus und skaliert die passend runter. Hat man abweichende Breiten aus seiner Website, kann man über verschiedene Parameter “das Ding passend machen”. (Alle Details dazu im Safari Dev Center.)

Aber warum dann in einer mobil optimierten Seite verwenden?
Das pure Vorhandensein des viewport meta tag zeigt an, dass der Website-Anbieter bereits eine Optimierung vorgenommen hat, und diverse “ich skalier Dich mal runter” Mechanismen bzw. automatische Optimierungen (aka small screen rendering) seitens des mobilen Browsern mögen bitte ausbleiben.

Im Opera-Mobile beispielsweise wäre die ganze Mobil-Optimierung umsonst gewesen, denn der versucht sonst selber, die Seite “mobil-freundlich” darzustellen - und das will man hier nicht. Hier will man, dass der Browser die bereits mobil-optimierte Seite nicht mehr verändert, sondern unangetastet darstellt. Auch andere Browser ziehen hier sukzessive nach.

Zitat: “… the presence of the viewport meta tag in the page’s head section indicates the author has taken care of optimizing for mobile, small screen rendering is not applied.” (Quelle: http://dev.opera.com/articles/view/opera-mobile-9-5-the-developer-angle/)

Langer Rede kurzer Sinn, mit diesen Parametern geht es ganz gut:

<meta name = “viewport” content = “width = device-width,  initial-scale=1″ />Man könnte width oder height auch mit Pixelangaben* fest verdrahten, dies ist aber selten sinnvoll. Nimmt man statt dessen wie oben empfohlen device-width und device-height, dann passt sich die Seite an die Auflösung (VGA, QVGA, WVGA , WQVGA, etc.)  des mobilen web client gut an.

(*Achtung, das wäre dann z.B. “width = 240″ und nicht “width = 240px“!)

- - -

Nachtrag:
Der viewport meta tag funktioniert immerhin “… in many smartphone browsers, including Safari Mobile for the iPhone, Android browser, webOS browser in Palm Pre and Pixi devices, Opera Mini, Opera Mobile and BlackBerry browsers.”
Quelle: http://learnthemobileweb.com/2009/07/mobile-meta-tags/

Kurz zwischendurch zwei drei kleine Linktips:

molipo.mobi
Hier gibt’s jede Menge “Mobile Web”. Das Portal ist ein umfangreiches Linkverzeichnis für mobile Seiten und listet aktuell ca. 1.000 mobile Links aus unterschiedlichen Kategorien.
Der Frage “Wie (mobile) designen eigentlich die anderen?” lässt sich hier gut nachgehen.

App vs. Website
Als Nachtrag zur Diskussion neulich hier noch ein lesenswerter Artikel zum Thema “App vs. Website” im Blog von insertEFFECT

The iPhone obsession
Kleine Denkanregung vom - wie immer recht bissigen - PPK / Quirksmode Blog. (Hinweis: Nicht so ganz der “Standard - Umgangston”. Ich würde vieles anders formulieren.)

Ok, ok - der Titel ist etwas irreführend und dieser Post leicht off-topic, aber: Kürzlich machte mich jemand darauf aufmerksam, dass diese Website hier (mobilewebdesign.de) - laut bizinformation.org - angeblich fast 13.000 EUR wert sei.

Seht selbst: mobilewebdesign.de Bewertung: EUR 12.927,93

Da muss ich doch mal kräftig schmunzeln. Kaufinteressenten können sich ja gerne mal melden

Ansonsten hätte ich noch im Angebot:

• mobilecampaigning.de
• mobilecampaigning.com
• mobilecampaigning.mobi

Na, da könnte man doch was draus machen, oder?

Oft benutzt und immer noch recht aktuell - ausser, dass die kleineren Auflösungen immer unbedeutender werden: Unter www.mobilewebdesign.de/beispiele/viewport-sizes.html habe ich einige verbreitete Display-Auflösungen als iFrames angelegt.

So eine Seite kann während der lokalen Entwicklung einer Mobile-Site hilfreich sein, um die “Wirkung” des eigenen Schaffens auf verschiedenen Displays ein wenig im Auge zu behalten. Einfach die URLs austauschen (und nicht den Internet Explorer verwenden).

Im Feld oben die zu testende Adresse eingeben. Wild hin-ge-hackt - ich weiß. Aber es erleichtert die Arbeit etwas. Wer länger an einem Projekt arbeitet, kann ja in den iFrames seine Adresse bei src=”…” eintragen.

Erleben nach dem großen App-Store-Erfolg mobil-optimierte Webanwendungen vielleicht doch wieder eine Renaissance?

Ich muss erkennen: Ich habe  2007 die weitere Entwicklung des “Mobile Web” ganz anders eingeschätzt. Mit diversen, einigermaßen leistungsfähigen Smartphones ausgestattet dachte ich “jetzt geht’s los”. Jetzt werden Webseiten für Handys benötigt, immer mehr Geräte “können das”, das ist das nächste große Ding. Habe mich mit XHTML-MP und WAP-CSS beschäftigt, Geräte-Betriebssystem-Browser-…-spezifische Besonderheiten untersucht und (teilweise) gelöst, mich zum “Certified DotMobi Web Developer” weitergebildet, einige mobile Sites entwickelt und überhaupt viel gelernt.

Dann kam das iPhone und mit ihm kurz darauf der AppStore. Plötzlich wurde klar, dass sich hier - neben allerlei Apps und dem Businessmodell hinter alledem - eine völlig neue Art des mobilen Internet entwickeln würde. Und so ist’s dann auch gekommen: Native Apps nutzen das Internet, um zu funktionieren. Der (mobile) Browser wird da gar nicht benötigt. Und jede andere Firma, jedes andere System zieht nach. Nokia, Palm, Android, Windows Mobile…

Aber trotzdem frage auch ich mich: Muss denn alles eine “App” sein? Ist nicht auch viel Marketing-Tam-Tam dabei, wenn man etwas, was wirklich gut im Browser liefe dennoch als App baut. Meistens “nur” als iPhone, weil’s so hip ist und jede weitere App für eine andere Plattform dann auch wieder erst entwickelt (also bezahlt) werden müsste? Insbesondere weil die mobilen Browser und die Geräte ja heute wirklich viel mehr können als 2007. HTML5 zum Beispiel… Und auch Desktop-Websites halbwegs benutzbar darstellen.

Tja. Was also wird aus dem (browserbasierten, optimierten) mobile Web? War’s das also?

Peter Paul Koch macht sich Gedanken über Sinn und Unsinn von solchen iPhone Apps, die seiner Meinung nach auch als “stinknormale Web-Applikationen” (also “Websites”) funktionieren würden.

Ich weise hier darauf hin, da ich selber diese Diskussion oft führe. Nicht alles, aber doch sehr vieles könnte als generische, mobile “Website” umgesetzt werden - natürlich gerne mit Device-Detection - oder, wenn gewünscht, auch nur “iPhone-Detection” - und hätte dann gleich eine viel größere Reichweite (nämlich alle anderen halbwegs fähigen Endgeräte) bei i.A. geringeren Entwicklungskosten und weniger “hassle” (Ärger).

Hier also der Artikel von PPK: “Native iPhone apps vs. Web apps”

Der Artikel “Adding a Google Map Image to your Mobile Website” von David Wiles auf coders.mobi beschreibt, wie einfach die Einbindung einer Google Map in eine mobile Website ist. Inklusive ein- und auszoomen mit PHP …

Bachelor-Abschlussarbeit zum Thema “Mobile Hybrid-Apps als mögliche Lösung zur Überwindung der Gerätefragmentierung”

Gestern erreichte mich die freundliche Anfrage von Robert Rockmann aus Berlin, der im Rahmen seiner Bachelor-Arbeit mit o.g. Titel folgende Umfrage durchführt: “Untersuchung zur mobilen Nutzung von SocialNetworks“. Klingt interessant.

Ich zitiere:
“Ich schreibe derzeit an meiner Bachelor-Abschlussarbeit zum Thema “Mobile Hybrid-Apps als mögliche Lösung zur Überwindung der Gerätefragmentierung”. Dazu untersuche ich mit Hilfe einer Online-Umfrage die mobile Nutzung von Facebook und StudiVZ hinsichtlich Nutzererwartungen und Nutzerbefriedigung. Insbesondere geht es darum aufzuzeigen, ob – und welche – Unterschiede es bei den Nutzern von iPhone-, Android-, Blackberry-Geräten gibt.

Facebook hat für jedes Gerät eine eigene App entwickelt, doch ein einheitlichen Funktionsumfang, bzw. eine einheitliche User-Experience wird dabei nicht gewährleistet. StudiVZ dagegen hat – soweit ich das feststellen konnte – für iPhone und Android-Nutzer eine nahezu identische App entwickelt. Ich möchte die Ergebnisse der jeweiligen Plattformen gegenüberstellen und aufzeigen, dass eine einheitliche App auf mehreren Endgeräten zu einer identischen Zufriedenheit der Nutzer der unterschiedlichen Geräte führen kann, und dass die Entwicklung von Hybrid-Apps dazu beitragen könnte.

Ich würde mich freuen, wenn Sie an der Umfrage teilnehmen würden. (…)”

Hier nochmal der Link zur Umfrage:
http://survey.robert-rockmann.de/index.php?sid=96692〈=de

(Link-Tip:)
PPK (Peter-Paul Koch) - u.a. JavaScript Experte und gerade für Vodafone im Bereich Mobile Web am forschen - schreibt ganz nett über seine Meinung zum Testing von Apps/Websites in mobilen Endgeräten, daher hier der Link zu seinem Artikel mit dem sehr aussagekräftigen Titel “Testing mobile phones, or the masochist’s guide to gleeful self-flagellation“: http://www.quirksmode.org/blog/archives/2009/09/testing_mobile_2.html

Das Testen von Websites ist zwar viel(!) umfangreicher als das Testen von Desktop-Applikationen, aber andererseits sind auch durchaus interessanter, weil es natürlich um viel mehr geht als darum, ob eine Site im IE6 der des Safari4 möglichst ähnlich ist (und das wieder massiv zunehmende Scripting auch überall funktioniert).