LX: Antworten zum Thema "Webdesign für mobile Endgeräte"

Beitrag lesen

Hallo Gunther!

Vorweg meinen besten Dank - bist du doch der Erste und bislang (leider) auch Einzige, der mal "echte" Antworten zum Thema liefert!

Gern geschehen.

Ich dachte an die Verwendung von: Detect Mobile Browser
Wobei ich als erste "Übung" eine Mobile-Version für eine Wordpress Seite erstellen will. VOn daher verwende ich die RegExp in PHP um in WP dann auf das Mobile-Theme zu switchen.

Unter tera-wurfl findet sich eine Sammlung nahezu aller mobilen UserAgents. Daraus sollte sich leicht eine RegExp erstellen lassen. Da ich meine meinem Arbeitgeber "vermacht" habe, darf ich sie hier leider nicht einstellen.

Ah, interessant. Aber verhindere ich dadurch dann nicht auch das Caching, sodass u.U. bei jedem neuen Seitenaufruf wieder alle Daten (= mehr Traffic/ Datenvolumen) übertragen werden? (...)

Ja und nein. Vodafone ignoriert die Angabe im HTML, sondern richtet sich nur nach dem HTTP-Header, die meisten Browser hingegen ziehen die Angabe im HTML vor. Bilder werden generell im Client gecached, wenn das HTML aber den Header hat, werden sie von Vodafone nicht gefiltert.

Das Problem, welches ich mit Media Queries habe ist, dass zwar jeder Browser, egal ob Mobile oder Desktop, über eine Zoomfunktion verfügt, die Auswirkungen auf die Viewport-Größen aber von Browser zu Browser variieren.

Deswegen sollte man innerhalb von media-queries auch nur minimale Anpassungen vornehmen, die notwendig sind, den reduzierten Platz sinnvoll zu nutzen.

Leider führt das Zoomen bei den gängigsten Browsern (WebKit basierte Browser) oftmals dazu, dass aufgrund geänderter Größenwerte dann Rules angewendet werden, die nicht angewendet werden sollen. Zumal diese dann quasi auch das Zoomen des Users wieder konterkarieren, was absolut unerwünscht ist.

zoom, -webkit-transform: scale und Konsorten sollte man überhaupt nur dann verwenden, wenn man ganz, ganz genau weiß, was man da macht - und auch nur dann mit viel Widerwillen - denn man verbrät hier wertvolle Akkulaufzeit seiner Kunden; dafür sollte man schon was Brauchbares liefern können. Besser ist es, Breiten, Textgrößen, etc. direkt anzupassen.

Ja, prima. Und dann kommt als erstes wieder das Problem der entsprechenden Testmöglichkeiten.

Es gibt verschiedene zusätzliche Testmöglichkeiten. Viele Hersteller liefern kostenlose SDKs für ihre Geräte, auf denen teilweise auch der Browser installiert ist (Android, Blackberry, Bada, WebOS); zudem findet man bspw. die Testversion des aktuellen OVI Browsers von Nokia als JAR-Applet zum Download (mit MicroJar-Simulator lauffähig). Wenn Du Ausgaben nicht komplett scheust: DeviceAnywhere hat zahlreiche ältere und aktuelle Geräte aufgeschraubt und Tastaturen sowie Bildschirme umverkabelt, so dass man sie am heimischen PC bedienen und testen kann.

Jetzt kann ich natürlich auch von mir ausgehen und behaupten:"Auf Displays kleiner als 320px ist das Surfen eigentlich nicht mehr wirklich "schön"!". (...)

An dieser Stelle ist es unser Job, dafür zu sorgen, dass diese Behauptung falsch ist. Ich schränke ein, dass die ganz kleinen, 176px breiten Displays älterer Geräte nicht wirklich zeitgemäß sind - aber das ist kein Grund dafür, dass eine Seite nicht funktionieren sollte.

Bezogen auf die 'device-pixel-ratio' bedeutet das, dass mdpi = 1.0 ist und die anderen Werte im entsprechenden Verhältnis dazu angegeben werden (als Dezimalzahlen außer bei Opera wo sie als Brüche angegeben werden müssen also bspw. hdpi als 3/2). Neuere Browser verstehen aber auch 'resolution' wo man direkt die jeweiligen DPI Werte verwenden kann.

In den meisten Fällen lohnt es sich nicht, sich Sorgen darum zu machen, es sei denn, man möchte Nutzer des iPhone4 bevorzugen. Ich neige hier dazu, zuerst auf die Funktionalität und Geschwindigkeit der Seite zu achten und erst dann auf einzelne Browser zu optimieren.

Gruß, LX

--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.