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

[Gunther]

Hallo LX!

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

Dann versuche ich mich doch mal an einer Antwort:

• Welche Auszeichnungssprache (in welcher Variante) sollte ich idealerweise verwenden (z.B. HTML 4 oder HTML 5)?

Eindeutig (X)HTML5, teilweise so reduziert, dass jene älteren Browser, die nichts mit den neuen Elementen anzufangen wissen, darunter nicht leiden. Außerdem kann man mit ausgeblendeten hr-Tags eine Strukturierung für reine WAP-Geräte erreichen.

Ja, HTML5 scheint nach allem was ich bisher so gelesen und gesehen (Sourcecode) habe wohl die beste und vorallem zukunftsweisende/ -sichere Variante zu sein. Gleichzeitig eine gute Gelegenheit sich mit HTML5 vertraut zu machen, da ich davon ausgehe, dass es in Zukunft auch im Desktop-Bereich eine zunehmend wichtigere Rolle spielen wird.
OK - erste Grundfrage geklärt - checked.

• Eine Version für "alle" oder doch besser eine eigene "Mobile Version"? Und wenn ja, wie (UA- / Browser Sniffing)?

Je nachdem, wie komplex die Seite aufgebaut ist. Wenn es wirklich nur um einfache Inhalte mit einer ebenso einfachen Navigation geht, kann man durchaus die gleiche Seite verwenden - aber schon bei etwas mehr Komplexität oder Daten, die im mobilen Umfeld viele Umbrüche verursachen, muss man sich überlegen, bei entsprechenden UA-Strings eine mobile Version zur Verfügung zu stellen. Die Unterscheidung per RegExp->Rewrite bietet sich an.

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.

• Welche Besonderheiten gibt es/ gilt es zu beachten (bspw. meta viewport tag)?

Es gibt 3 maßgebliche Meta-Tags, viewport, handheldfriendly und mobileoptimized. Zudem verstehen viele modernere Browser media queries, so dass man diese zur Optimierung auf die jeweilige Auflösung nutzen kann.

Ja, und gleich der erste (viewport) hat es ja schon in sich ... *grins*
Folgende Übersicht hilft ggf. weiter: Safari HTML Reference - Supported META Tags

Da ich nicht unbedingt beabsichtige eine "native App" zu erstellen, möchte ich auf keinen Fall das Zoomen verunmöglichen. Und es scheint eine allgemeine Empfehlung zu sein
'width=device-width'
zu verwenden.

Übrigens sind nicht nur Browser schuld an Bugs: besonders Vodafone neigt zur Filterung der Seiten, wobei der CSS-Code überschrieben und Werbung eingeblendet wird, was man jedoch mit entsprechenden Cache-Policy-Headern verhindern kann.

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?
Oder welche Cache-Policy ist zielführend?
Wie sieht es überhaupt mit dem Caching aus (bei den mobilen Browsern)? Verhalten sie sich gleich wie ihre Desktop-Varianten?

Bei der Gelegenheit bin ich auch über das 'cache' Attribut für den html Tag gestolpert. In der im value angegebenen Datei kann man alle files auflisten, die dann lokal im Gerät gespeichert werden. Wenn man dort tatsächlich alle Dateien (HTML, CSS, JS, Images) angibt, könnte man die Seite auch offline aufrufen. In wie weit das bei einer Blog-Seite sinnvoll ist, weiss ich nicht. Aber man könnte natürlich zumindest alle mehr oder weniger statischen Dateien cachen, sodass jeweils nur der Teil mit neuen Beiträgen tatsächlich übers Netz geladen werden müsste.
Hast du damit Erfahrungen?

• Wie handhabe ich die verschiedenen Displaygrößen_und_Auflösungen am besten (Stichwort "Media Queries")?

Relative Maße wo möglich, media-queries wo nötig. Solange es keine Schmerzen bereitet, dem Browser die Formatierung überlassen.

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. 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.
Die einzig mir bekannte Methode das zu verhindern ist die Zoomfunktion zu unterdrücken/ verbieten, was für mich aber absolut nicht in Frage kommt - schon gar nicht auf den mobilen Geräten.
Wie gehst du mit der Problematik um?
Eine weitere "Falle" lauert ja auch noch in dem unterschiedlich ausgeprägten Verständnis der jeweiligen Browser im Bezug auf die Angaben in den MQs - siehe Safe Media Queries

• Welcher Browser versteht was und wieviel (HTML5, CSS3)?

Die Frage macht nur dann Sinn, wenn man wirklich jeden dieser Browser einzeln unterstützen möchte.

Gehe davon aus, dass es 3 Klassen gibt:

Moderne Browser
Webkit-basierte Browser, Opera Mini/Mobile, Blackberry Torch, Netfront Access 5, Obigo W10 und IE9 (ab Sommer), Fennec: HTML5 ja CSS3 teilweise

Ältere Browser
mobileIE6/7, Obigo, Netfront Access 4, Opera Mini 4: HTML5 nein HTML4 ja CSS3 nein CSS2 teilweise

Rudimentäre Browser
OVI Browser/Novarra, PocketIE, (auch Blackberry vor 2008:) UP, Teleca, WAPfront: HTML teilweise WAP ja CSS nein

Ja, prima. Und dann kommt als erstes wieder das Problem der entsprechenden Testmöglichkeiten. Auf reeller Hardware kann ich nur die aktuellen Android Versionen testen, für die es nebenbei bemerkt auch noch die besten (und freien) Emulatoren für Windows gibt. Für das iPhone 3 gibt es noch ein paar Online Simulatoren und das war's dann aber auch schon.
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"!". Hinzukommt, dass ich der potenziellen Usergruppe eine weit höhere Affinität zur Materie und somit auch eine größere Update-Bereitschaft unterstelle, als das im sonstigen Umfeld der Fall ist.
Also werde ich erstmal versuchen für "meine" Konfiguration zu entwickeln, mit einer Nummer kleiner (Displaygröße) im Hinterkopf, und mich dabei wohl erstmal auch auf die 'Class A' Browser konzentrieren.

media queries nach dpi (iphone4 retina display) iVm CSS3 background-scale.

Hmmm ..., das ist noch einer der Punkte, die mir nicht ganz klar sind.
Grundsätzlich gibt, oder besser gab es bisher ja 3 Gruppen von Auflösungen:

• ldpi (120dpi)
• mdpi (160dpi), ist quasi der Default
• hdpi (240dpi)
  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.

Soweit ich das verstanden habe, spielt das in erster Linie für Grafiken eine Rolle. Aber auch hier 'verwirrt' mich aktuell noch das automatische Scaling der Browser ...!?

Und für Androids Webkit Browser gibt es ein neues Attribut für den Viewport Meta Tag, nämlich 'target-densitydpi' mit dem imho einzig sinnvollen Wert 'target-densitydpi=device-dpi', wodurch nach meinem Verständnis genau dieser Automatismus der Anpassung an die jeweilige Auflösung quasi ausgeschaltet wird.

Aber so richtig und ganz verstanden habe ich das noch nicht.

Ich würde mich freuen, wenn du mir noch mehr Tipps geben und deine Erfahrungen mitteilen würdest. Einstweilen schon mal meinen besten Dank!

Gruß Gunther