Webdesign für mobile Endgeräte

[Gunther]

Hallo werte Selfgemeinde!

Zwei Vorschläge möchte ich gerne unterbreiten:

1. Ich fände es gut, wenn es hier im Forum eine extra Kategorie (einen eigenen Themenbereich) für "mobiles Webdesign" gäbe.

2. Ferner würde ich es sehr begrüßen, wenn es auch im Wiki dazu eine eigene (Unter-)Rubrik geben würde.

Da nach Meinung vieler Experten das Thema "Mobile Web" in den kommenden (2-3) Jahren stark an Bedeutung zunehmen soll, kommt wohl kaum ein Webdesigner um das Thema drumrum.
Und leider haben scheinbar weder die Macher der Browser, noch die Hersteller der Endgeräte etwas aus der Problematik der "Browser Wars" im vorletzten Jahrzehnt gelernt. Von daher dürften wir uns auf nicht absehbare Zeit hinaus auch mit ähnlichen Problemen konfrontiert sehen.

Da es sich hierbei aber aktuell auch um einen der sich am schnellsten fort-/ weiterentwickelnden Bereiche handelt, sowohl was die Endgeräte, alsauch die Browser anbelangt, bedarf es hier einer recht häufigen Aktualisierung, bzw. Ergänzung der jeweiligen Informationen. Wofür IMHO das Wiki natürlich prädestiniert wäre.

Viele der aktuell im Netz zu findenden Informationen beziehen sich bspw. rein auf das iPhone 3 und sind teilweise bereits überholt, bzw. decken eben nur noch einen kleinen Bereich ab.

Von besonderem Interesse wäre z.B. eine Übersicht der am häufigsten verwendeten Browser auf mobilen Endgeräten in ihrer jeweiligen Version mit deren jeweiligen Fähigkeiten (und Bugs).
Denn selbst wenn viele Browser aktuell auf der Webkit Engine basieren, so sind die Unterschiede je nach Plattform, Hersteller und Version doch teilweise recht enorm.

Vielen Dank!

Gruß Gunther

[bleicher]

Grüße,
du hast de-facto mit 2 Browsern im mobilen Bereich zu tun - webkit-ableger und Opera(Mobile/mini).Beide sind in der Lage normale, "nichtmobile" Webseiten prima darzustellen, und ich sehe kein Grund da etwas zusätzlich anzupassen - Standartmaßnahmen für guten Styl, wir das verpacken von text in p reichen dicke aus.

mich als mobilen Nutzer, nerven die abgespeckten mobilen Seiten ziemlich (die sind unübersichtlich und um das gesuchte zu finden muss ich 3 mal länger rumsuchen - das spart KEIN traffic) . also lass die "Optimierung", "best voodoo in internet explorer 6" hat uns nur eins beigebracht -
man codet nach standarten NICHT nach dem aktuellen forced-hype
MFG
bleicher

[suit]

du hast de-facto mit 2 Browsern im mobilen Bereich zu tun - webkit-ableger und Opera(Mobile/mini).Beide sind in der Lage normale, "nichtmobile" Webseiten prima darzustellen, und ich sehe kein Grund da etwas zusätzlich anzupassen - Standartmaßnahmen für guten Styl, wir das verpacken von text in p reichen dicke aus.

mich als mobilen Nutzer, nerven die abgespeckten mobilen Seiten ziemlich (die sind unübersichtlich und um das gesuchte zu finden muss ich 3 mal länger rumsuchen - das spart KEIN traffic) . also lass die "Optimierung", "best voodoo in internet explorer 6" hat uns nur eins beigebracht -
man codet nach standarten NICHT nach dem aktuellen forced-hype

Full ACK.

Was man an mobilen Webseiten optimieren sollte ist die Ladezeit - runde Ecken mittels CSS anstatt Grafiken, Schatten mittels CSS anstatt Grafiken - CSS, CSS, CSS - ältere Browser bleiben dann zwar auf der Strecke, aber das ist imho. Vernachlässigbar.

Wer eine ordentliche Mobile Version will hat zwei Möglichkeiten:

1. Eine unzuverlässige Weiche mit einer speziell angepassten Site nur für Mobilbenutzer die Unmengen an Aufwand (Erstellung und Wartung) bedeutet und zudem idR. den Besucher eher weniger bringt als die eigentliche Site.

2. Die bestehende Site geschwindigkeitsoptimieren und dabei auf alte Browser keine rücksicht zu nehmen - dabei bleiben notwendigerweise einige Browser visuell auf der Stecke, aber das verschlechtert den Inhalt nicht.

Wenn ein Benutzer mit IE8 keine runden Ecken hat ist mir das eher Wurst als wenn alle Mobilbenutzer irre Ladezeiten auf sich lasten müssen.

[Gunther]

Hi suit!

Was man an mobilen Webseiten optimieren sollte ist die Ladezeit - runde Ecken mittels CSS anstatt Grafiken, Schatten mittels CSS anstatt Grafiken - CSS, CSS, CSS

Oder bspw. auf solche "optischen Gimmicks" ganz verzichten!?
Schatten können bspw. auch zum Performance-Hit werden auf mobilen Endgeräten.

Wer eine ordentliche Mobile Version will hat zwei Möglichkeiten:

1. Eine unzuverlässige Weiche mit einer speziell angepassten Site nur für Mobilbenutzer die Unmengen an Aufwand (Erstellung und Wartung) bedeutet und zudem idR. den Besucher eher weniger bringt als die eigentliche Site.

Zum Thema "unzuverlässige Weiche": Eine z.B. auf dem User-Agent basierende Weiche wird erst durch einen "manipulativen User-Eingriff" unzuverlässig. Auf solche Ding muss und kann man imho keine Rücksicht nehmen, zumal diese in Ausnahmefällen ja sogar auch angebracht/ notwendig sein können.

Zum Thema "speziell angepasste Site nur für Mobilbenutzer":
Erstens_zwingt_dich ja keiner eine solche "Variante" deiner Website anzubieten - aber wenn, dann bitte auch "ordentlich". Und wodurch oder besser warum entstehen denn "Unmengen an Aufwand (Erstellung und Wartung)"? Zumeist doch wohl nur dadurch, dass bei der Konzeption dieser (bestehenden) Seiten nicht daran gedacht/ berücksichtigt wurde, auch eine "mobile" Version davon ausliefern zu können. Wer nimmt denn heutzutage schon (besondere) Rücksicht auf die Anzahl an HTTP Requests, an verwendeten Grafiken, eingebundene Scripte etc.? Alles Dinge, die auf einmal wieder eine wesentliche Rolle spielen.
Hinzukommt der Trend dem User möglichst viele Informationen, neben den eigentlich/ vermeintlich gesuchten, auf einmal zu liefern.

2. Die bestehende Site geschwindigkeitsoptimieren und dabei auf alte Browser keine rücksicht zu nehmen - dabei bleiben notwendigerweise einige Browser visuell auf der Stecke, aber das verschlechtert den Inhalt nicht.

OK, das klingt für mich beim ersten Lesen wieder so, dass ich mich frage, warum man dann nicht jede Seite als "reine (unformatierte) Textseite" ausliefert. Nach dem Motto:"Der Inhalt ist ja vorhanden!".
Und ja, Seiten für mobile Endgeräte stellen einige grundsätzlich andere Anforderungen als die für die Betrachtung am heimischen PC. Und ja, diese Anforderungen können es imho auch erforderlich machen, nicht nur ein eigenes Layout zu erstellen, sondern auch einen eigenen Sourcecode dafür zu "generieren". Ein Beispiel dafür ist u.a. eine "durchschnittliche" Wordpress Seite. Fast jedes installierte Plugin fügt eine eigene Script- und CSS Datei hinzu. Diese jedem Mobile-Nutzer mit auszuliefern, auch wenn die jeweiligen Plugins auf der entsprechenden Seite gar nicht "zum Einsatz" kommen, ist imho "grob fahrlässig".

Es ist dabei eine ganz andere Frage (und eine, die mich in diesem Zusammenhang nicht interessiert), ob und in wie weit man diese Änderungen manuell/ händisch oder automatisiert per Script erledigt.

Wenn ein Benutzer mit IE8 keine runden Ecken hat ist mir das eher Wurst als wenn alle Mobilbenutzer irre Ladezeiten auf sich lasten müssen.

Ob runde Ecken oder nicht ist aktuell leider eines der geringsten Probleme, jedenfalls meiner Meinung nach. Das Fehlen "zuverlässiger" Layoutmittel unabhängig vom verwendeten Endgerät und Browser hingegen stört mich weit mehr.

Gruß Gunther

[suit]

Oder bspw. auf solche "optischen Gimmicks" ganz verzichten!?
Schatten können bspw. auch zum Performance-Hit werden auf mobilen Endgeräten.

Selbst auf wirklich langsamen Smartphones werden Schatten und runde Ecken ausreichend schnell gerendert - da sind andere Dinge wesentlich performancelastiger, eben zusätzliche HTTP-Requests oder unnötig riesige Bilder.

Zum Thema "unzuverlässige Weiche": Eine z.B. auf dem User-Agent basierende Weiche wird erst durch einen "manipulativen User-Eingriff" unzuverlässig. Auf solche Ding muss und kann man imho keine Rücksicht nehmen, zumal diese in Ausnahmefällen ja sogar auch angebracht/ notwendig sein können.

Besonders am Mobilsegment nimmt diesen Eingriff der Internetanbieter direkt vor um z.B. Bandbreite zu sparen - aber auch auf Clientseite ist das nicht selten, dass das der benutzer Aktiv macht - Opera Turbo ist nur eines der Beispiele wo der traffic Manipuliert wird.

Wer nimmt denn heutzutage schon (besondere) Rücksicht auf die Anzahl an HTTP Requests, an verwendeten Grafiken, eingebundene Scripte etc.?

Ich.

Alles Dinge, die auf einmal wieder eine wesentliche Rolle spielen.

Das war in der Geschichte der Menschheit immer so: zuerst gibts keine Ressourcen und alle müssen Sparen, dann gibt es plötzlich viele Ressourcen und es wird herumgesaut und verbraucht was geht - dann reicht die Leistung plötzlich doch wieder nicht mehr aus, es gibt eine Kriese, eine Knappheit oder sonstwas und man muss wieder sparsamer arbeiten.

Ob das nun die Rechneleistung von Computern und Mobilgeräten ist oder man auf die Ausbeutung der natürlichen Ressourcen unseres Planeten umlegt ist dabei egal. Der Mensch neigt dazu Raubbau zu betreiben und erst zu reagieren, wenn es wirklich nicht mehr anders geht.

Momentan geht der Trend wieder zum sparsamen und sauberen arbeiten - dh. man bedenkt das bei neuen Projekten, kann es aber bei alten nicht machen weil da noch gesaut wurde.

Hinzukommt der Trend dem User möglichst viele Informationen, neben den eigentlich/ vermeintlich gesuchten, auf einmal zu liefern.

Ja, das ist oft ein Wunsch dejenigen die die Website betreiben, nicht die die sie machen - 3 Seiten nach unten scrollen können weil in den Sidebars 25 Werbeangebote und Affiliate-Links sind aber der Nutztext in der inhaltsspalte ist grade mal 10 Zeilen lang - und ja, ich hab' solche Kunden.

Aber die Frage war, wie man es macht und nicht was leider gängige Praxis ist.

OK, das klingt für mich beim ersten Lesen wieder so, dass ich mich frage, warum man dann nicht jede Seite als "reine (unformatierte) Textseite" ausliefert.

Ja - das ist die Frage. Was spricht gegen einen RSS-Feed der nur die Nutzinhalte bereitstellt? Genau das ist EXAKT das was ich auf einem Mobiltelefon möchte, wenn ich Nachrichten lesen.

Beim einfachen herumsurfen ist das natürlich nicht praktikabel, aber für Stammbesucher ist das ein _echter_ Mehrwert.

Und ja, Seiten für mobile Endgeräte stellen einige grundsätzlich andere Anforderungen als die für die Betrachtung am heimischen PC.

Du hast noch nichtmal definiert, was du als mobiles Gerät betrachtest.

Und ja, diese Anforderungen können es imho auch erforderlich machen, nicht nur ein eigenes Layout zu erstellen, sondern auch einen eigenen Sourcecode dafür zu "generieren". Ein Beispiel dafür ist u.a. eine "durchschnittliche" Wordpress Seite. Fast jedes installierte Plugin fügt eine eigene Script- und CSS Datei hinzu. Diese jedem Mobile-Nutzer mit auszuliefern, auch wenn die jeweiligen Plugins auf der entsprechenden Seite gar nicht "zum Einsatz" kommen, ist imho "grob fahrlässig".

Ja - das liegt aber mitunter daran, dass Wordpress diesbezüglich einfach schlecht geschrieben ist und die Plugins ihre CSS- und JavaScript-Schnipsel nicht in ein Globales (bei bedarf erzeugtes) File schreiben können wie das z.B. bei ordentlichen CMS möglich ist.

Es ist dabei eine ganz andere Frage (und eine, die mich in diesem Zusammenhang nicht interessiert), ob und in wie weit man diese Änderungen manuell/ händisch oder automatisiert per Script erledigt.

Fakt ist, dass sie gemacht gehören, weil genau das einen wirklichen unterschied in der Ladezeit bedeutet.

[Gunther]

Hallo suit!

Also wenn ich mir deinen Beitrag so durchlese, dann habe ich den Eindruck, dass unsere Meinungen/ Ansichten doch gar nicht so verschieden sind, bzw. weit auseinander liegen. ;-)

Um das Fazit vorwegzunehmen: Ich finde halt, dass die ganze Thematik zumindest in Teilen neu ist, und in anderen Teilen neue Aktualität gewonnen hat, sodass man ihr durchaus eine eigene Rubrik, bzw. Kategorie spendieren sollte/ könnte.

Oder bspw. auf solche "optischen Gimmicks" ganz verzichten!?
Schatten können bspw. auch zum Performance-Hit werden auf mobilen Endgeräten.

Selbst auf wirklich langsamen Smartphones werden Schatten und runde Ecken ausreichend schnell gerendert - da sind andere Dinge wesentlich performancelastiger, eben zusätzliche HTTP-Requests oder unnötig riesige Bilder.

ACK. Aber Kleinvieh macht eben auch Mist und läppert sich. Wichtig ist auf jeden Fall eben auf alle Aspekte hinzuweisen.

Zum Thema "unzuverlässige Weiche": Eine z.B. auf dem User-Agent basierende Weiche wird erst durch einen "manipulativen User-Eingriff" unzuverlässig. Auf solche Ding muss und kann man imho keine Rücksicht nehmen, zumal diese in Ausnahmefällen ja sogar auch angebracht/ notwendig sein können.

Besonders am Mobilsegment nimmt diesen Eingriff der Internetanbieter direkt vor um z.B. Bandbreite zu sparen - aber auch auf Clientseite ist das nicht selten, dass das der benutzer Aktiv macht - Opera Turbo ist nur eines der Beispiele wo der traffic Manipuliert wird.

Das Wort "Manipulation" ist für mich von Hause aus schon eher immer mit einem schalen Beigeschmack versehen. Denn letztlich_möchte_ich als Autor doch darüber bestimmen, welche Informationen wie beim Nutzer/ Leser ankommen. Das bedeutet, dass ich vom Grundsatz her jedwede fremde Manipulation vermieden sehen möchte. Zumal wenn ich die Möglichkeit habe, diese Informationen auch so auszuliefern, dass eine solche Manipulation sowieso überflüssig ist.

Wer nimmt denn heutzutage schon (besondere) Rücksicht auf die Anzahl an HTTP Requests, an verwendeten Grafiken, eingebundene Scripte etc.?

Ich.

Sehr löblich. Aber man sollte halt nie von sich auf andere schließen - will sagen: Wenn ich mir aktuell das "Web" so angucke, dann sehe ich da noch einen enormen Informations- & Handlungsbedarf.

Alles Dinge, die auf einmal wieder eine wesentliche Rolle spielen.

Das war in der Geschichte der Menschheit immer so: zuerst gibts keine Ressourcen und alle müssen Sparen, dann gibt es plötzlich viele Ressourcen und es wird herumgesaut und verbraucht was geht - dann reicht die Leistung plötzlich doch wieder nicht mehr aus, es gibt eine Kriese, eine Knappheit oder sonstwas und man muss wieder sparsamer arbeiten.

Ob das nun die Rechneleistung von Computern und Mobilgeräten ist oder man auf die Ausbeutung der natürlichen Ressourcen unseres Planeten umlegt ist dabei egal. Der Mensch neigt dazu Raubbau zu betreiben und erst zu reagieren, wenn es wirklich nicht mehr anders geht.

Momentan geht der Trend wieder zum sparsamen und sauberen arbeiten - dh. man bedenkt das bei neuen Projekten, kann es aber bei alten nicht machen weil da noch gesaut wurde.

Und mein Vorschlag war und ist, dass man diesem "Trend" (zeitnah) bei SELFHTML Rechnung trägt.

Hinzukommt der Trend dem User möglichst viele Informationen, neben den eigentlich/ vermeintlich gesuchten, auf einmal zu liefern.

Ja, das ist oft ein Wunsch dejenigen die die Website betreiben, nicht die die sie machen - 3 Seiten nach unten scrollen können weil in den Sidebars 25 Werbeangebote und Affiliate-Links sind aber der Nutztext in der inhaltsspalte ist grade mal 10 Zeilen lang - und ja, ich hab' solche Kunden.

Aber die Frage war, wie man es macht und nicht was leider gängige Praxis ist.

Ja, und "gängige" Praxis ist letztlich immer das Ergebnis der vorhergehenden Frage. Also wie macht man es denn? Und wieder bezog sich mein Vorschlag darauf, Antworten auf diese Frage bei SELFHTML bereitzustellen.

OK, das klingt für mich beim ersten Lesen wieder so, dass ich mich frage, warum man dann nicht jede Seite als "reine (unformatierte) Textseite" ausliefert.

Ja - das ist die Frage. Was spricht gegen einen RSS-Feed der nur die Nutzinhalte bereitstellt? Genau das ist EXAKT das was ich auf einem Mobiltelefon möchte, wenn ich Nachrichten lesen.

Da stimme ich dir zu. Ein RSS-Feed ist_eine_der brauchbaren Varianten, aber ihn als völligen "mobilen Ersatz" für Websites anzusehen, geht mir dann doch zu weit.

Beim einfachen herumsurfen ist das natürlich nicht praktikabel, aber für Stammbesucher ist das ein _echter_ Mehrwert.

Genau! Darauf bezog sich auch meine Einschränkung im vorherigen Absatz.

Und ja, Seiten für mobile Endgeräte stellen einige grundsätzlich andere Anforderungen als die für die Betrachtung am heimischen PC.

Du hast noch nichtmal definiert, was du als mobiles Gerät betrachtest.

Ja, geschickt nicht? Warum versuchen etwas zu definieren, wenn auch (fast) jeder ohne Definition weiss, was gemeint ist?

Und ja, diese Anforderungen können es imho auch erforderlich machen, nicht nur ein eigenes Layout zu erstellen, sondern auch einen eigenen Sourcecode dafür zu "generieren". Ein Beispiel dafür ist u.a. eine "durchschnittliche" Wordpress Seite. Fast jedes installierte Plugin fügt eine eigene Script- und CSS Datei hinzu. Diese jedem Mobile-Nutzer mit auszuliefern, auch wenn die jeweiligen Plugins auf der entsprechenden Seite gar nicht "zum Einsatz" kommen, ist imho "grob fahrlässig".

Ja - das liegt aber mitunter daran, dass Wordpress diesbezüglich einfach schlecht geschrieben ist und die Plugins ihre CSS- und JavaScript-Schnipsel nicht in ein Globales (bei bedarf erzeugtes) File schreiben können wie das z.B. bei ordentlichen CMS möglich ist.

ACK. Aber solange du nicht die hunderttausenden Verwender von WP dazu gebracht hast auf ein "Ordentliches CMS" umzusteigen, muss man sich wohl oder übel in der Praxis damit herumschlagen.

Es ist dabei eine ganz andere Frage (und eine, die mich in diesem Zusammenhang nicht interessiert), ob und in wie weit man diese Änderungen manuell/ händisch oder automatisiert per Script erledigt.

Fakt ist, dass sie gemacht gehören, weil genau das einen wirklichen unterschied in der Ladezeit bedeutet.

Ja, und ich möchte halt gerne dass dazu auf SELFHTML auch entsprechende Informationen angeboten werden.

Gruß Gunther

[bleicher]

Grüße,

Du hast noch nichtmal definiert, was du als mobiles Gerät betrachtest.

Ja, geschickt nicht? Warum versuchen etwas zu definieren, wenn auch (fast) jeder ohne Definition weiss, was gemeint ist?

Jedes Gerät mit mehr als einer logischen Schaltung und Ausgabevorrichtung, das über eine interne Stromquelle oder Netzanschluss über 3 Meter Länge verfügt.
MFG
bleicher

[suit]

Ja, geschickt nicht? Warum versuchen etwas zu definieren, wenn auch (fast) jeder ohne Definition weiss, was gemeint ist?

Was ist denn nun gemeint? Und vor allem: von welcher Signifikanz bzw. welchen Marktanteilen reden wird?

Meine kunden kommen daher und wollen eine iPhone- und iPad-Version - ohne auch nur 1x in die Besucherstatistik geschaut zu haben mit welchen geräten die Leute wirklich daherkommen.

ACK. Aber solange du nicht die hunderttausenden Verwender von WP dazu gebracht hast auf ein "Ordentliches CMS" umzusteigen, muss man sich wohl oder übel in der Praxis damit herumschlagen.

Damit sollen sich aber "die" herumschlagen, nicht ich (mal ungeachtet der Tatsache, dass ich auch Wordpress für einige Projekte verwende).

Ja, und ich möchte halt gerne dass dazu auf SELFHTML auch entsprechende Informationen angeboten werden.

Jetzt kommen wir der Sache näher.

[Gunther]

Hi,

Ja, geschickt nicht? Warum versuchen etwas zu definieren, wenn auch (fast) jeder ohne Definition weiss, was gemeint ist?

Was ist denn nun gemeint? Und vor allem: von welcher Signifikanz bzw. welchen Marktanteilen reden wird?

Lass' es mich mal so formulieren: Gemeint (thematisch) ist alles, was von der derzeit "üblichen" Norm (Display mit mind. 960px, Maus, Internetanbindung über "Kabel") abweicht. Dein "Einwand" in dem verlinkten Beitrag ist insofern richtig, dass es eben nicht nur um kleinere Displays geht, sondern eben u.a. auch um andere Arten der Steuerung (Maus - Touchscreen).
Die verbreitesten Vertreter dieser "Gattung" dürften wohl aktuell Smartphones und Tablets sein. Die Frage nach der Signifikanz und den Marktanteilen möchte ich mal außen vor lassen. Für mich spielt die nämlich keine Rolle, denn für mich ist das Thema signifikant genug, um mich damit auseinanderzusetzen. Wenn man sich jedoch alleine den Trend im letzten Jahr anguckt und die vielfach vertretene Meinung (von Leuten, die in dieser Hinsicht mir gegenüber von ihrer Kompetenz her um Längen voraus sind), dann darf man wohl davon ausgehen, dass sich dieser Trend in Zukunft noch verstärkt, bzw. anhält. Wodurch sich dann auch die Marktanteile entsprechend erhöhen dürften.

Meine kunden kommen daher und wollen eine iPhone- und iPad-Version - ohne auch nur 1x in die Besucherstatistik geschaut zu haben mit welchen geräten die Leute wirklich daherkommen.

Hmmm, ja und? Gerade von Leuten, die ansonsten doch eher den Grundsatz vertreten, nicht einen einzigen User "außen vorzulassen", kann ich das Argument jetzt nicht ganz nachvollziehen. Also wenn auch nur einziger User mit iPhone oder iPad angesurft kommt, was spricht dagegen ihm eine "optimierte" Darstellung zu liefern? Zumal ich persönlich der Meinung bin (s.o.), dass sich die Anzahl in naher Zukunft eher erhöht.

ACK. Aber solange du nicht die hunderttausenden Verwender von WP dazu gebracht hast auf ein "Ordentliches CMS" umzusteigen, muss man sich wohl oder übel in der Praxis damit herumschlagen.

Damit sollen sich aber "die" herumschlagen, nicht ich (mal ungeachtet der Tatsache, dass ich auch Wordpress für einige Projekte verwende).

Ja, durchaus. Wobei es eben aber auch interessant wäre zu wissen, wie ich bspw. eine "ordentliche" Version meiner Wordpress Seite erstellen kann, die den entsprechenden Anforderungen, bspw. von Smartphone-Usern, gerecht wird.

Ja, und ich möchte halt gerne dass dazu auf SELFHTML auch entsprechende Informationen angeboten werden.

Jetzt kommen wir der Sache näher.

Wieso jetzt erst?
Was war oder ist denn an meinem Ausgangsposting anders zu verstehen?

Gruß Gunther

[bleicher]

Grüße,

Also wenn auch nur einziger User mit iPhone oder iPad angesurft kommt, was spricht dagegen ihm eine "optimierte" Darstellung zu liefern?

weil wenn A!=B && A=true, B=false.
die Darstellung ist entweder gut durchdacht und optimal, dann ist jegliche Veränderung/Anpassung an iPoop eine Verschlechterung (dann bin ich ganz auf deiner Seite das ist eine eine gute idee) oder aber die "optimierte" ist gut, dann muss aber die normale scheiße sein. warum willst du allen anderen dann, die schlechte Version präsentieren?

die mobil-borwser programmierer, tun ihr bestes, die normalen webseiten optimal darzusteleln, kommst du dem mit mobiler Version entgegen, hast du eine balkontür im keller geschnitten.
MFG
bleicher

[Gunther]

Grüße,

Also wenn auch nur einziger User mit iPhone oder iPad angesurft kommt, was spricht dagegen ihm eine "optimierte" Darstellung zu liefern?

weil wenn A!=B && A=true, B=false.
die Darstellung ist entweder gut durchdacht und optimal, dann ist jegliche Veränderung/Anpassung an iPoop eine Verschlechterung (dann bin ich ganz auf deiner Seite das ist eine eine gute idee) oder aber die "optimierte" ist gut, dann muss aber die normale scheiße sein. warum willst du allen anderen dann, die schlechte Version präsentieren?

Das ist imho zu "einseitig" betrachtet. Wie hier im Thread schon erwähnt wurde, gibt es u.a. auch Unterschiede in der "Bedienung" (Stichworte: Maus, Touchscreen). Und ich bin schon der Auffassung, dass bspw. Links zur Bedienung auf einem Touchscreen anders gestaltet sein sollten, als wenn man sie mit einem Cursor und Maussteuerung anklicken kann (oder per Tastatur auswählen).

Ebenfalls erwähnt wurde auch der Unterschied bei Hover-Effekten. Bei Touchscreens schlicht nicht möglich, können sie ansonsten eine echte Bereicherung sein.

Hinzukommt dann immer auch noch der Aspekt, dass das Datenvolumen so gering wie möglich gehalten werden sollte, also einfach eine CSS Datei "für alle" vermutlich nicht die optimalste Lösung ist.

die mobil-borwser programmierer, tun ihr bestes, die normalen webseiten optimal darzusteleln, kommst du dem mit mobiler Version entgegen, hast du eine balkontür im keller geschnitten.

Wie ich in der Antwort an Martin bereits geschrieben habe (letzter Absatz), bin ich ja nicht dagegen, nur sollte es auch in diesem Bereich möglich sein/ bleiben, dass ich als Autor "das letzte Wort" habe - zumindest wenn ich es explizit so will. Und das größte Problem bei "die mobil-borwser programmierer, tun ihr bestes, die normalen webseiten optimal darzusteleln" ist doch (schon wieder), dass es jeder auf seine Art & Weise tut, die sich natürlich von der der Mitstreiter unterscheiden muss ...!

Gruß Gunther

[Der Martin]

Hallo,

Was man an mobilen Webseiten optimieren sollte ist die Ladezeit - runde Ecken mittels CSS anstatt Grafiken, Schatten mittels CSS anstatt Grafiken - CSS, CSS, CSS
Oder bspw. auf solche "optischen Gimmicks" ganz verzichten!?

auch das kann eine gute Idee sein. Es kommt immer drauf an, was die Besucher wollen. Wollen sie Information, oder wollen sie ästhetisches Design? Solange man beides zugleich haben kann, okay.

Schatten können bspw. auch zum Performance-Hit werden auf mobilen Endgeräten.

Aber höchstens bei Halbtransparenz-Effekten. Harte Schlagschatten dürften, wenn sie nicht durch *zusätzliche* Grafiken dargestellt werden, nicht ins Gewicht fallen. Es sind technisch gesehen bloß ein paar zusätzliche Linien zu zeichnen.

Zum Thema "unzuverlässige Weiche": Eine z.B. auf dem User-Agent basierende Weiche wird erst durch einen "manipulativen User-Eingriff" unzuverlässig. Auf solche Ding muss und kann man imho keine Rücksicht nehmen, zumal diese in Ausnahmefällen ja sogar auch angebracht/ notwendig sein können.

Da will ich einerseits zustimmen, andererseits widersprechen. Zustimmen insofern, als man sicher nicht auf jede "exotische" Konfiguration eingehen kann und in Kauf nimmt, dass *sehr* untypische Fälle mal unter die Räder kommen.
Widersprechen möchte ich aber, weil ich es *prinzipiell* für ein technisches Foul halte, wenn man den User Agent für etwas anderes als eine ungefähre Statistik verwendet. Wenn man auf Spezialitäten bestimmter Browser (im positiven wie im negativen Sinn) eingehen möchte, sollte man besser die *Fähigkeiten* des Browsers abfragen oder ausnutzen, anstatt ihn nach seinem Namen zu fragen.

Wer nimmt denn heutzutage schon (besondere) Rücksicht auf die Anzahl an HTTP Requests, an verwendeten Grafiken, eingebundene Scripte etc.?

Außer suit zum Beispiel auch ich. Und ich erwarte das auch von anderen Webautoren, Programmierern und Softwareentwicklern, die ihre Sache ordentlich machen wollen.

Alles Dinge, die auf einmal wieder eine wesentliche Rolle spielen.

Nein, nicht "auf einmal wieder". Sie haben immer eine große Rolle gespielt, wurden aber lange Zeit mit Füßen getreten.

2. Die bestehende Site geschwindigkeitsoptimieren und dabei auf alte Browser keine rücksicht zu nehmen - dabei bleiben notwendigerweise einige Browser visuell auf der Stecke, aber das verschlechtert den Inhalt nicht.
   OK, das klingt für mich beim ersten Lesen wieder so, dass ich mich frage, warum man dann nicht jede Seite als "reine (unformatierte) Textseite" ausliefert. Nach dem Motto:"Der Inhalt ist ja vorhanden!".

Eben! Da sind wir wieder bei der eingangs gestellten Frage: Wollen sie Information, oder wollen sie ästhetisches Design?
Ich möchte im Internet vor allem Information. Und die möchte ich möglichst übersichtlich, direkt, schnörkellos und leicht erfassbar haben. Plaintext, ggf. hier und da mit Skizzen oder Fotos zum besseren Verständnis ergänzt ist dafür optimal. Deswegen surfe ich meistens ohne Javascript, und gelegentlich sogar mit deaktivierter CSS-Unterstützung.

Nebenbei bemerkt ist ein Design für mich meistens umso ästhetischer, je schlichter es ist. Ausnahmen bestätigen die Regel.

Ob runde Ecken oder nicht ist aktuell leider eines der geringsten Probleme, jedenfalls meiner Meinung nach. Das Fehlen "zuverlässiger" Layoutmittel unabhängig vom verwendeten Endgerät und Browser hingegen stört mich weit mehr.

Inwiefern? Ich sehe es gerade als eine der Stärken von HTML/CSS an, z.B. Boxen untereinander zu setzen, wenn sie nicht mehr nebeneinander passen, den Textfluss einschließlich der Zeilenumbrüche der zur Verfügung stehenden Breite anzupassen, oder nicht angegebene Maße und Abstände als Freiheitsgrade zu betrachten.

So long,
 Martin

[Gunther]

Hallo Martin,

Was man an mobilen Webseiten optimieren sollte ist die Ladezeit - runde Ecken mittels CSS anstatt Grafiken, Schatten mittels CSS anstatt Grafiken - CSS, CSS, CSS
Oder bspw. auf solche "optischen Gimmicks" ganz verzichten!?

auch das kann eine gute Idee sein. Es kommt immer drauf an, was die Besucher wollen. Wollen sie Information, oder wollen sie ästhetisches Design? Solange man beides zugleich haben kann, okay.

ACK. Aber die Entscheidung darüber sollte doch beim User liegen, oder?
Denn je nach "Situation" (Internetanbindung, verwendete Hardware, etc.) habe ich völlig unterschiedliche Wünsche.

Schatten können bspw. auch zum Performance-Hit werden auf mobilen Endgeräten.

Aber höchstens bei Halbtransparenz-Effekten. Harte Schlagschatten dürften, wenn sie nicht durch *zusätzliche* Grafiken dargestellt werden, nicht ins Gewicht fallen. Es sind technisch gesehen bloß ein paar zusätzliche Linien zu zeichnen.

Keine Ahnung - ist auch aktuell nicht (mein) Hauptthema/ -anliegen. Soviel ich gelesen habe, ist gerade die Veränderung von Alpha-Transparenz ziemlich CPU belastend für Smartphones. Generell sollte man auch im Kopf haben, dass jedes Neu-Rendern der Seite in einem "Mobile Browser" wesentlich resourcenbelastender ist, als das bei der breiten Masse der heimischen Desktoprechner und Notebooks der Fall sein dürfte.

Zum Thema "unzuverlässige Weiche": Eine z.B. auf dem User-Agent basierende Weiche wird erst durch einen "manipulativen User-Eingriff" unzuverlässig. Auf solche Ding muss und kann man imho keine Rücksicht nehmen, zumal diese in Ausnahmefällen ja sogar auch angebracht/ notwendig sein können.

Da will ich einerseits zustimmen, andererseits widersprechen. Zustimmen insofern, als man sicher nicht auf jede "exotische" Konfiguration eingehen kann und in Kauf nimmt, dass *sehr* untypische Fälle mal unter die Räder kommen.

So, jetzt sind wir bei einem (meiner) "Knackpunkte" ..., wo bei mir seit geraumer Zeit eher Unverständnis vorherrscht.
Erste Frage, die sich mir in dem Zusammenhang stellt: Warum ist es überhaupt erforderlich, dass es (mal abgesehen von individuell manipulierten) überhaupt eine derartige Vielzahl von UAs geben muss? Und warum gibt es nicht neben einer "manipulierbaren" Variante auch eine nicht manipulierbare? Mal davon abgesehen, dass ich ja eh der Aufassung bin, dass man auf manipulierte UAs keine Rücksicht nehmen muss/ kann.

Widersprechen möchte ich aber, weil ich es *prinzipiell* für ein technisches Foul halte, wenn man den User Agent für etwas anderes als eine ungefähre Statistik verwendet. Wenn man auf Spezialitäten bestimmter Browser (im positiven wie im negativen Sinn) eingehen möchte, sollte man besser die *Fähigkeiten* des Browsers abfragen oder ausnutzen, anstatt ihn nach seinem Namen zu fragen.

So muss man es in der Praxis machen. Aber imho nur deswegen, weil der Browser u.a. einige der wichtigsten Informationen eben nicht mitsendet.

Es macht nämlich durchaus einen Unterschied, ob ich serverseitig anhand des Requests schon bestimmte Dinge weiss und dementsprechend nur die wirklich benötigten Teile ausliefern könnte, oder ob ich in Ermangelung dieser Informationen im Prinzip erstmal Alles rüberschicke nach dem Motto "dann such dir halt das Passende raus!".

Denn welchen Sinn hat es, wenn ich einem Smartphone-Surfer erstmal die komplette Desktop-Variante zukommen lasse, nur damit er dann auf einen Link "Mobile Version" klicken kann?

Aber wenn du eine andere (bessere/ zuverlässigere) Methode kennst, wie man bereits serverseitig entscheiden kann, welche Variante für den User (erstmal) die geeignetste ist, bin ich ganz Ohr.

Wer nimmt denn heutzutage schon (besondere) Rücksicht auf die Anzahl an HTTP Requests, an verwendeten Grafiken, eingebundene Scripte etc.?

Außer suit zum Beispiel auch ich. Und ich erwarte das auch von anderen Webautoren, Programmierern und Softwareentwicklern, die ihre Sache ordentlich machen wollen.

Es freut mich, das zu lesen. Es ändert aber nichts an meiner Meinung, dass es seeehr viele Webautoren (viele davon vermutlich mangels "Problembewußtsein") nicht tun. Also können "Aufklärung" und Anleitungen wie man es (besser) machen kann doch nicht schaden, oder?

Alles Dinge, die auf einmal wieder eine wesentliche Rolle spielen.

Nein, nicht "auf einmal wieder". Sie haben immer eine große Rolle gespielt, wurden aber lange Zeit mit Füßen getreten.

"wurden aber lange Zeit mit Füßen getreten" ist für mich im Endeffekt gleichbedeutend mit "keine Rolle gespielt", da das Ergebnis dasselbe ist.

2. Die bestehende Site geschwindigkeitsoptimieren und dabei auf alte Browser keine rücksicht zu nehmen - dabei bleiben notwendigerweise einige Browser visuell auf der Stecke, aber das verschlechtert den Inhalt nicht.
   OK, das klingt für mich beim ersten Lesen wieder so, dass ich mich frage, warum man dann nicht jede Seite als "reine (unformatierte) Textseite" ausliefert. Nach dem Motto:"Der Inhalt ist ja vorhanden!".

Eben! Da sind wir wieder bei der eingangs gestellten Frage: Wollen sie Information, oder wollen sie ästhetisches Design?
Ich möchte im Internet vor allem Information. Und die möchte ich möglichst übersichtlich, direkt, schnörkellos und leicht erfassbar haben.

Eben! Da sind wir wieder beim Design. Übersichtlichkeit und leichte Erfassbarkeit von Informationen hängen maßgeblich von deren Layout ab (bei optischer Darstellung, sprich im Screendesign, womit ich nicht sagen will, dass es bei anderen Präsentationsformen keine Rolle spielen würde).

Kleines Beispiel: Wenn ich mir das SELFHTML Weblog auf meinem Smartphone-Browser angucke, dann "rutscht" das ansonsten rechts neben der Hauptinhaltsspalte befindliche Menü unter diese Spalte (einspaltiges Seitenlayout). Das bedeutet für mich aber, dass einer der wesentlichsten Teile der Seite eben nicht mehr "auf Anhieb" erkennbar ist und ich eine wahre "Scroll-Orgie" veranstalten muss, um ihn überhaupt zu erreichen. Ein Skip-Link am Seitenanfang wäre also bspw. eine enorme Hilfe/ Steigerung der Usability.

Plaintext, ggf. hier und da mit Skizzen oder Fotos zum besseren Verständnis ergänzt ist dafür optimal. Deswegen surfe ich meistens ohne Javascript, und gelegentlich sogar mit deaktivierter CSS-Unterstützung.

Persönliche "Vorlieben" und "Eigenheiten" können imho nicht Bestandteil allgemeiner Vorgehensweisen und Grundlagen sein. Ich kenne persönlich etliche Leute, die weder wissen was sich hinter den von dir genannten Begriffen verbirgt, noch dass sie sowohl das eine, als auch das andere überhaupt deaktivieren können. Hinzukommt, dass es sie auch gar nicht interessiert. Und für mich ist das die erste "Zielgruppe". Wer sich "auskennt" und (hoffentlich) weiss was er tut, der wird dadurch ja nicht in seinem Vorhaben oder Tun eingeschränkt.

Nebenbei bemerkt ist ein Design für mich meistens umso ästhetischer, je schlichter es ist. Ausnahmen bestätigen die Regel.

Und über Geschmack lässt sich bekanntlich nicht streiten.
Abgesehen davon gibt es einige Grundsätze, die imho zumindest auf die Mehrheit der Menschen zutrifft und somit potenziell erstmal auch auf die Untergruppe der Internetuser.

Ob runde Ecken oder nicht ist aktuell leider eines der geringsten Probleme, jedenfalls meiner Meinung nach. Das Fehlen "zuverlässiger" Layoutmittel unabhängig vom verwendeten Endgerät und Browser hingegen stört mich weit mehr.

Inwiefern? Ich sehe es gerade als eine der Stärken von HTML/CSS an, z.B. Boxen untereinander zu setzen, wenn sie nicht mehr nebeneinander passen, den Textfluss einschließlich der Zeilenumbrüche der zur Verfügung stehenden Breite anzupassen, oder nicht angegebene Maße und Abstände als Freiheitsgrade zu betrachten.

Das bestreitet doch auch niemand. Ich betrachte es aber als ziemlich nachteilig/ unvorteilhaft, wenn Browser irgendwelche "Phantasiewerte" bereitstellen im Bezug auf die Viewportgröße, oder meine sorgfältig ausgewählten Schriftgrößen einfach vom Browser abgeändert werden.
Um nicht falsch verstanden zu werden: Ich bin nicht generell gegen diese "Automatismen" oder "Eigenmächtigkeiten" der Browser. Diese sind aktuell sicherlich sogar notwendig, bzw. sinnvoll, damit (möglichst) jede Website auch irgendwie dargestellt werden kann.
Aber ..., dann bitte auch so, dass ich diese auch "abschalten/ vermeiden/ umgehen" kann, wenn ich das explizit angebe (weil ich meine Seite selber bereits "optimiert" habe)!
Und natürlich wäre es schön, wenn nicht jeder Hersteller dafür seine ganz eigenen Methoden verwenden würde, und dann auch noch mit Unterschieden zwischen den jeweiligen Versionen (das war u.a. damit gemeint, als ich eingangs schrieb:"... nichts aus den Browser-Wars gelernt!").

Gruß Gunther

[Der Martin]

Hi Gunther,

Es kommt immer drauf an, was die Besucher wollen. Wollen sie Information, oder wollen sie ästhetisches Design? Solange man beides zugleich haben kann, okay.
ACK. Aber die Entscheidung darüber sollte doch beim User liegen, oder?

ja, sehe ich auch so. Ein Autor, der sich drei Ohren abbricht, um doch irgendwie die Layout-Vorstellung zur Anwendung zu bringen, die er für gut hält, passt dann aber nicht dazu. Und den Eindruck habe ich bei dir zumindest teilweise: Du hältst eine bestimmte Darstellung für richtig, also versuchst du intensiv, diese Darstellung zu "erzwingen".

Denn je nach "Situation" (Internetanbindung, verwendete Hardware, etc.) habe ich völlig unterschiedliche Wünsche.

Ja, keine Frage. Nur klaffen die Wünsche des Autors und die des Nutzers oft deutlich auseinander.

Da will ich einerseits zustimmen, andererseits widersprechen. Zustimmen insofern, als man sicher nicht auf jede "exotische" Konfiguration eingehen kann und in Kauf nimmt, dass *sehr* untypische Fälle mal unter die Räder kommen.
So, jetzt sind wir bei einem (meiner) "Knackpunkte" ..., wo bei mir seit geraumer Zeit eher Unverständnis vorherrscht.

Ich bin gespannt ...

Erste Frage, die sich mir in dem Zusammenhang stellt: Warum ist es überhaupt erforderlich, dass es (mal abgesehen von individuell manipulierten) überhaupt eine derartige Vielzahl von UAs geben muss?

Ist es nicht. Der User-Agent-String ist streng nach der HTTP-Spezifikation überhaupt nicht nötig, sondern nichts weiter als schmückendes Beiwerk im Protokoll. Aber selbstverständlich nutzen die Browserhersteller gern die Möglichkeit, hier nochmal den Produktnamen und Detailinformationen unterzubringen und in die Welt hinauszubrüllen.
Eine zuverlässige Information war das aber noch nie.

Und warum gibt es nicht neben einer "manipulierbaren" Variante auch eine nicht manipulierbare?

Wozu? Unterschiedlich ausgeprägte Fähigkeiten z.B. in der Darstellung werden dadurch berücksichtigt, dass der eine Browser bestimmte CSS-Eigenschaften interpretiert, ein anderer eben nicht. Für ganz grobe Unterschiede gibt es Media Queries (für die Browser, die sie unterstützen). Und wenn man Ressourcen in generell unterschiedlichen Datenformaten vorhalten und individuell ausliefern will, könnte man den Accept-Header auswerten. So erkennt man ja beispielsweise einen alten IE, bei dem es keinen Sinn ergibt, XHTML als application/xhtml+xml auszuliefern.
Also was vermisst du noch?

Mal davon abgesehen, dass ich ja eh der Aufassung bin, dass man auf manipulierte UAs keine Rücksicht nehmen muss/ kann.

Doch, man sollte sie insofern berücksichtigen, dass man sie generell nicht beachtet. Desktop-Firewalls, Proxies, Browser-Addons und anderes Zeugs, das den UA verändert, ist einfach zu verbreitet, als dass man die Augen davor veschließen könnte. Oft wird der UA sogar manipuliert, ohne dass der Nutzer davon weiß, geschweige denn Einfluss darauf hat (z.B. Proxy im Firmennetzwerk).

Es macht nämlich durchaus einen Unterschied, ob ich serverseitig anhand des Requests schon bestimmte Dinge weiss und dementsprechend nur die wirklich benötigten Teile ausliefern könnte, oder ob ich in Ermangelung dieser Informationen im Prinzip erstmal Alles rüberschicke nach dem Motto "dann such dir halt das Passende raus!".

Aber nur, *weil* du die Browser unterschiedlich bedienen willst, anstatt einfach von guten Implementierungen auszugehen und nur ein paar wenige bekannte Problemkandidaten gesondert zu behandeln. Ich habe keine Erfahrung mit den Browsern auf Mobilgeräten (und verspüre auch keinen Anreiz, mich mit ihnen zu befassen oder sie zu nutzen). Aber ich habe mindestens zweimal in diesem Thread schon gelesen, dass man gut fährt, wenn man sie genauso bedient wie die "gewöhnlichen" Browser der Desktop-Systeme.

Denn welchen Sinn hat es, wenn ich einem Smartphone-Surfer erstmal die komplette Desktop-Variante zukommen lasse, nur damit er dann auf einen Link "Mobile Version" klicken kann?

Und nochmal: Willst du ein grundsätzlich anders aufgebautes Dokument ausliefern? Oder nur ein angepasstes Design?
Wenn ersteres: Verwende eine Subdomain, z.B. mobile.example.org, dann haben auch die Desktop-User etwas davon, die gern eine einfachere Darstellung hätten.
Wenn letzteres: Biete ein alternatives, weniger anspruchsvolles Stylesheet an.

Aber wenn du eine andere (bessere/ zuverlässigere) Methode kennst, wie man bereits serverseitig entscheiden kann, welche Variante für den User (erstmal) die geeignetste ist, bin ich ganz Ohr.

Ein paar habe ich oben genannt; für weitere Unterscheidungen sehe ich persönlich keine Veranlassung.

Plaintext, ggf. hier und da mit Skizzen oder Fotos zum besseren Verständnis ergänzt ist dafür optimal. Deswegen surfe ich meistens ohne Javascript, und gelegentlich sogar mit deaktivierter CSS-Unterstützung.
Persönliche "Vorlieben" und "Eigenheiten" können imho nicht Bestandteil allgemeiner Vorgehensweisen und Grundlagen sein.

Können schon; ist auch schön, *wenn* sie berücksichtigt werden. Darf man aber nicht erwarten.

Abgesehen davon gibt es einige Grundsätze, die imho zumindest auf die Mehrheit der Menschen zutrifft und somit potenziell erstmal auch auf die Untergruppe der Internetuser.

Das "Problem" ist, dass sehr sehr viele Leute das Internet hauptsächlich als Entertainment-Medium sehen, nicht als reine Informations- und Wissensquelle.

Das bestreitet doch auch niemand. Ich betrachte es aber als ziemlich nachteilig/ unvorteilhaft, wenn Browser irgendwelche "Phantasiewerte" bereitstellen im Bezug auf die Viewportgröße, oder meine sorgfältig ausgewählten Schriftgrößen einfach vom Browser abgeändert werden.

Da sind wir wieder beim Autor/Nutzer-Konflikt. Ich halte es für unbedingt richtig, dass mein Browser die Darstellungsempfehlungen des Autors umsetzen *kann*, wenn ich ihn lasse - sie aber ebensogut ignorieren und meine eigenen Wünsche mit höherer Priorität umsetzen kann. Zum Beispiel eine Mindest-Schriftgröße, weil manche Autoren zu glauben scheinen, 8px wäre noch gut lesbar. Zum Beispiel eine kontrastreiche Abstimmung von Schrift- und Hintergrundfarbe, weil der Anwender eine Sehschwäche hat. Zum Beispiel das Verbot, Scrollbalken und Formularelemente bis zur Unkenntlichkeit umzustylen.

Um nicht falsch verstanden zu werden: Ich bin nicht generell gegen diese "Automatismen" oder "Eigenmächtigkeiten" der Browser. Diese sind aktuell sicherlich sogar notwendig, bzw. sinnvoll, damit (möglichst) jede Website auch irgendwie dargestellt werden kann.
Aber ..., dann bitte auch so, dass ich diese auch "abschalten/ vermeiden/ umgehen" kann, wenn ich das explizit angebe (weil ich meine Seite selber bereits "optimiert" habe)!

Die oberste Priorität darüber darf aber eben nicht beim Autor liegen, sondern beim Nutzer. Das ist einer der wichtigesten Unterschiede zwischen Print- und Screendesign.

So long,
 Martin

[Gunther]

Hi Martin,

ich antworte mal in zwei Teilen (weil mich das Foren-Script für "geschwätzig" hält - tss, keine Ahnung wie es darauf kommt ...)!

Es kommt immer drauf an, was die Besucher wollen. Wollen sie Information, oder wollen sie ästhetisches Design? Solange man beides zugleich haben kann, okay.
ACK. Aber die Entscheidung darüber sollte doch beim User liegen, oder?

ja, sehe ich auch so. Ein Autor, der sich drei Ohren abbricht, um doch irgendwie die Layout-Vorstellung zur Anwendung zu bringen, die er für gut hält, passt dann aber nicht dazu. Und den Eindruck habe ich bei dir zumindest teilweise: Du hältst eine bestimmte Darstellung für richtig, also versuchst du intensiv, diese Darstellung zu "erzwingen".

Denn je nach "Situation" (Internetanbindung, verwendete Hardware, etc.) habe ich völlig unterschiedliche Wünsche.

Ja, keine Frage. Nur klaffen die Wünsche des Autors und die des Nutzers oft deutlich auseinander.

Ja, unbestritten. Ich bezog das aber auf mich als Nutzer und_nicht_als Autor in diesem Zusammenhang.
Beispiel: Wenn ich eine Seite von meinem Smartphone mit Datenverbindung übers Mobilfunknetz aus aufrufe, dann habe ich ganz andere Priritäten, als wenn ich dieselbe Seite von zu Hause auf ansurfe. Nur habe ich derzeit ja de facto keine "offizielle" Möglichkeit dies dem Server vorab mitzuteilen ...!

Da will ich einerseits zustimmen, andererseits widersprechen. Zustimmen insofern, als man sicher nicht auf jede "exotische" Konfiguration eingehen kann und in Kauf nimmt, dass *sehr* untypische Fälle mal unter die Räder kommen.
So, jetzt sind wir bei einem (meiner) "Knackpunkte" ..., wo bei mir seit geraumer Zeit eher Unverständnis vorherrscht.

Ich bin gespannt ...

Erste Frage, die sich mir in dem Zusammenhang stellt: Warum ist es überhaupt erforderlich, dass es (mal abgesehen von individuell manipulierten) überhaupt eine derartige Vielzahl von UAs geben muss?

Ist es nicht. Der User-Agent-String ist streng nach der HTTP-Spezifikation überhaupt nicht nötig,

Wobei jeder mir bekannte auch nur halbwegs verbreitete Browser diesen mitsendet. Stellt sich mir also folglich die Frage, warum ihn dann nicht (in nicht manipulierbarer Version) mit in die Spezifikation aufnimmt?

sondern nichts weiter als schmückendes Beiwerk im Protokoll. Aber selbstverständlich nutzen die Browserhersteller gern die Möglichkeit, hier nochmal den Produktnamen und Detailinformationen unterzubringen und in die Welt hinauszubrüllen.
Eine zuverlässige Information war das aber noch nie.

Und warum macht man keine daraus? Das (zuverlässige) Wissen über das zugrundeliegende Betriebssystem und die Browser-Engine würde zumindest einiges vereinfachen. Natürlich nicht restlos alle Prüfungen "verstehst du das?" überflüssig machen.

Und warum gibt es nicht neben einer "manipulierbaren" Variante auch eine nicht manipulierbare?

Wozu? Unterschiedlich ausgeprägte Fähigkeiten z.B. in der Darstellung werden dadurch berücksichtigt, dass der eine Browser bestimmte CSS-Eigenschaften interpretiert, ein anderer eben nicht. Für ganz grobe Unterschiede gibt es Media Queries (für die Browser, die sie unterstützen). Und wenn man Ressourcen in generell unterschiedlichen Datenformaten vorhalten und individuell ausliefern will, könnte man den Accept-Header auswerten. So erkennt man ja beispielsweise einen alten IE, bei dem es keinen Sinn ergibt, XHTML als application/xhtml+xml auszuliefern.
Also was vermisst du noch?

Überlege nur mal wieviel Traffic/ Datenvolumen man einsparen könnte, wenn der Browser u.a. Informationen über die aktuelle Viewportgröße und Javascript (on/off) mitliefern würde. Oder speziell bei den "mobilen Endgeräten" zusätzlich Informationen über die aktuelle Datenanbindung, Touchscreen (ja/nein) und einige andere Dinge, die mir jetzt spontan natürlich nicht einfallen. ;-)
Das Mehr an Daten, welches durch diese Informationen im Header anfällt würde man imho doppelt und dreifach (oder noch mehr) wieder einsparen, dadurch dass man wesentlich kleinere, weil besser angepasste Inhalte ausliefern könnte.

Rest siehe Teil 2

[Gunther]

Mal davon abgesehen, dass ich ja eh der Aufassung bin, dass man auf manipulierte UAs keine Rücksicht nehmen muss/ kann.

Doch, man sollte sie insofern berücksichtigen, dass man sie generell nicht beachtet. Desktop-Firewalls, Proxies, Browser-Addons und anderes Zeugs, das den UA verändert, ist einfach zu verbreitet, als dass man die Augen davor veschließen könnte. Oft wird der UA sogar manipuliert, ohne dass der Nutzer davon weiß, geschweige denn Einfluss darauf hat (z.B. Proxy im Firmennetzwerk).

Für mich nur ein Beweis dafür, dass nicht alles "was gemacht wird/ machbar ist" auch wirklich hilfreich, geschweige denn sinnvoll ist.
Manches davon sollte man eben auch unterbinden.

Es macht nämlich durchaus einen Unterschied, ob ich serverseitig anhand des Requests schon bestimmte Dinge weiss und dementsprechend nur die wirklich benötigten Teile ausliefern könnte, oder ob ich in Ermangelung dieser Informationen im Prinzip erstmal Alles rüberschicke nach dem Motto "dann such dir halt das Passende raus!".

Aber nur, *weil* du die Browser unterschiedlich bedienen willst, anstatt einfach von guten Implementierungen auszugehen und nur ein paar wenige bekannte Problemkandidaten gesondert zu behandeln.

Nein, es ist eben nicht_nur_eine Frage des verwendeten Browsers (s.o.), aber auch. Und das liegt schlicht und ergreifend daran, dass es nunmal verschiedene Browser mit unterschiedlichen Fähigkeiten gibt und ich aktuell eben nur so vorgehen kann, dass ich durch clientseitiges "Sniffing" dem User die "möglichst optimale Darstellung offeriere.

Ich habe keine Erfahrung mit den Browsern auf Mobilgeräten (und verspüre auch keinen Anreiz, mich mit ihnen zu befassen oder sie zu nutzen). Aber ich habe mindestens zweimal in diesem Thread schon gelesen, dass man gut fährt, wenn man sie genauso bedient wie die "gewöhnlichen" Browser der Desktop-Systeme.

Das halte ich schlichtweg für einen Trugschluss. ;-)
Zumal das durch browserseitige Manipulation (*ohne* Zutun und Einfluss des Users!!!) geschieht. Grundsätzlich halte ich eine solche Vorgehensweise nur dann für angebracht, wenn ich als Autor (oder User) dem Browser dieses auch verbieten kann und er meine Website auch so anzeigt, wie vom jeweiligen Autor gewünscht.

Denn welchen Sinn hat es, wenn ich einem Smartphone-Surfer erstmal die komplette Desktop-Variante zukommen lasse, nur damit er dann auf einen Link "Mobile Version" klicken kann?

Und nochmal: Willst du ein grundsätzlich anders aufgebautes Dokument ausliefern? Oder nur ein angepasstes Design?

Diese Frage lässt sich imho nicht pauschal beantworten, da es von der jeweiligen Seite (und deren Inhalt) abhängig ist. Es können also beide Fälle in der Praxis auftreten.

Wenn ersteres: Verwende eine Subdomain, z.B. mobile.example.org, dann haben auch die Desktop-User etwas davon, die gern eine einfachere Darstellung hätten.

Aaaah ..., jetzt sind wir auch noch bei der "One Web" Frage angekommen (musste ja früher oder später auch passieren).
Nur soviel: Grundsätzlich halte ich persönlich nicht viel davon, für gleiche Inhalte unterschiedliche (Sub-)Domains zu verwenden. Das ist aber ein sehr umfangreiches und eigenes Thema wie ich finde, weshalb ich darauf jetzt mal nicht weiter eingehen möchte.

Wenn letzteres: Biete ein alternatives, weniger anspruchsvolles Stylesheet an.

Alternative Stylesheets sind ja auch, oder gerade für Desktop-User nicht verkehrt. Allerdings kommen bspw. bei Smartphones auch noch einige andere Besonderheiten dazu (z.B. die unterschiedliche Ausrichtung des Displays, Portrait + Landscape). Oder bspw. auch die Zoom Methoden der Browser. Natürlich kann man sein Stylesheet soweit reduzieren, dass es letztendlich so gut wie von jedem CSS fähigen Browser umgesetzt werden kann. Die Frage dabei ist aber, ob dadurch nicht auch die Usability leidet?

Aber wenn du eine andere (bessere/ zuverlässigere) Methode kennst, wie man bereits serverseitig entscheiden kann, welche Variante für den User (erstmal) die geeignetste ist, bin ich ganz Ohr.

Ein paar habe ich oben genannt; für weitere Unterscheidungen sehe ich persönlich keine Veranlassung.

OK, ich verstehe deine Ansichten und daraus resultierende Argumentation. Verkürzt ausgedrückt stellt das aber für mich eine Beschneidung der Möglichkeiten dar, sprich die Reduktion auf den kleinsten gemeinsamen Nenner. Und das halte ich in Anbetracht der verschiedenen Geräte und sonstigen Gegebenheiten für eine Einschränkung der Nutzungsmöglichkeiten für viele User. Das halte ich nicht für erstrebenswert.

Plaintext, ggf. hier und da mit Skizzen oder Fotos zum besseren Verständnis ergänzt ist dafür optimal. Deswegen surfe ich meistens ohne Javascript, und gelegentlich sogar mit deaktivierter CSS-Unterstützung.
Persönliche "Vorlieben" und "Eigenheiten" können imho nicht Bestandteil allgemeiner Vorgehensweisen und Grundlagen sein.

Können schon; ist auch schön, *wenn* sie berücksichtigt werden. Darf man aber nicht erwarten.

Abgesehen davon gibt es einige Grundsätze, die imho zumindest auf die Mehrheit der Menschen zutrifft und somit potenziell erstmal auch auf die Untergruppe der Internetuser.

Das "Problem" ist, dass sehr sehr viele Leute das Internet hauptsächlich als Entertainment-Medium sehen, nicht als reine Informations- und Wissensquelle.

Über die Ansichten und die Motivation jedes einzelnen Users weiss man als Autor nie Bescheid. Von daher wird jede Website vor allem immer durch die persönlichen Ansichten des jeweiligen Autors geprägt sein und vermutlich bei den Usern Anklang finden, bei denen ein entsprechend hoher Übereinstimmungsgrad besteht.

Das bestreitet doch auch niemand. Ich betrachte es aber als ziemlich nachteilig/ unvorteilhaft, wenn Browser irgendwelche "Phantasiewerte" bereitstellen im Bezug auf die Viewportgröße, oder meine sorgfältig ausgewählten Schriftgrößen einfach vom Browser abgeändert werden.

Da sind wir wieder beim Autor/Nutzer-Konflikt. Ich halte es für unbedingt richtig, dass mein Browser die Darstellungsempfehlungen des Autors umsetzen *kann*, wenn ich ihn lasse - sie aber ebensogut ignorieren und meine eigenen Wünsche mit höherer Priorität umsetzen kann.

Full ACK. Gerade das scheint mir aber bei den mobilen Browsern aktuell in Gefahr. Denn neben den Vorgaben durch den Autor und die höher einzustufenden Wünsche des Nutzers kommen hier noch die "Eigenmächtigkeiten" der Browser ins Spiel. Und frei nach dem Motto "Drei sind einer zuviel ...", halte ich das eben für "ungünstig", wenn man diese teilweise ungewollten Eigenmächtigkeiten nicht umgehen/ verhindern kann (und zwar sowohl als Autor, wie auch als User).

Zum Beispiel eine Mindest-Schriftgröße, weil manche Autoren zu glauben scheinen, 8px wäre noch gut lesbar. Zum Beispiel eine kontrastreiche Abstimmung von Schrift- und Hintergrundfarbe, weil der Anwender eine Sehschwäche hat. Zum Beispiel das Verbot, Scrollbalken und Formularelemente bis zur Unkenntlichkeit umzustylen.

Um nicht falsch verstanden zu werden: Ich bin nicht generell gegen diese "Automatismen" oder "Eigenmächtigkeiten" der Browser. Diese sind aktuell sicherlich sogar notwendig, bzw. sinnvoll, damit (möglichst) jede Website auch irgendwie dargestellt werden kann.
Aber ..., dann bitte auch so, dass ich diese auch "abschalten/ vermeiden/ umgehen" kann, wenn ich das explizit angebe (weil ich meine Seite selber bereits "optimiert" habe)!

Die oberste Priorität darüber darf aber eben nicht beim Autor liegen, sondern beim Nutzer. Das ist einer der wichtigesten Unterschiede zwischen Print- und Screendesign.

Full ACK. Das habe ich auch nie bestritten oder würde das in Frage stellen. Aber aufgrund meiner bereits geschilderten Erfahrungen mit "Internetnutzern" sollte eine Seite grundsätzlich erstmal so angezeigt werden, wie sich der Autor das (im Sinne seiner Besucher) vorgestellt hat. Und nicht wie der verwendete Browser (ohne weitere Userkonfiguration) sich das vorstellt. Wäre es andersherum, dann könnten wir uns ja wirklich jegliches Design sparen und das den Browsern überlassen (überspitzt formuliert).
Also worum es mir geht ist, dass eine Seite grundsätzlich auch erstmal ohne weitere Eingriffe und Veränderungen durch den User "benutzbar" ist und den Gegebenheiten entsprechend möglichst optimal (natürlich immer aus Autorensicht) dargestellt wird.
Dessen ungeachtet muss es natürlich immer dem jeweiligen User überlassen sein, die Darstellung seinen Wünschen und Vorstellungen entsprechend anzupassen.
Ich bin aber durchaus überzeugt davon, dass die Gruppe derer, die das entweder nicht wollen oder auch nicht wissen, wie sie das machen sollten, wesentlich größer ist als die andere Gruppe.

Also nochmal zusammengefasst:
Ich möchte schlichtweg die Option als Autor haben, dass meine Seite erstmal ohne jegliche Veränderungen so beim User ankommt, wie ich mir das vorstelle. Was der User dann damit anstellt sei völlig ihm überlassen.

Gruß Gunther

[Der Martin]

Hallo,

ich antworte mal weitgehend, ohne konkret zu zitieren.

Anscheinend sind wir uns zum Großteil einig - was mir mangels intimer Kenntnisse bisher nicht so klar war, ist die Eigensinnigkeit einiger Browser auf Mobile Devices.

Und ganz ehrlich: Ich würde mich hier auf die Hinterbeine stellen und sagen, "Wenn dein Browser Scheiße baut, kann ich nichts dafür."

Zumal das durch browserseitige Manipulation (*ohne* Zutun und Einfluss des Users!!!) geschieht.

Dann ist der in diesem Gerät verbaute Browser Murks. Da kannst du doch nichts dafür!

OK, ich verstehe deine Ansichten und daraus resultierende Argumentation. Verkürzt ausgedrückt stellt das aber für mich eine Beschneidung der Möglichkeiten dar, sprich die Reduktion auf den kleinsten gemeinsamen Nenner.

Ja, und genau das halte ich für den einzigen wirklich gangbaren Weg. Natürlich ist es schade, wenn man die Fähigkeiten bestimmter Geräte oder Browser nicht wirklich ausnutzen kann. Andererseits bin ich der Meinung, man muss nicht alles machen, nur weil es möglich ist.

Also worum es mir geht ist, dass eine Seite grundsätzlich auch erstmal ohne weitere Eingriffe und Veränderungen durch den User "benutzbar" ist und den Gegebenheiten entsprechend möglichst optimal (natürlich immer aus Autorensicht) dargestellt wird.

Ja, gut. Und dazu gehört, dass man entweder die automatischen Anpassungen bestimmter Browser[1] einfach akzeptiert, oder dem Benutzer klarmacht: Es ist dein Browser, der Mist macht.

Ciao,
 Martin

[1] Ich war auch schon entsetzt über die Defaulteinstellung von IE6, große Bilder auf Fensterbreite zu skalieren.

[Gunther]

Grüße,

du hast de-facto mit 2 Browsern im mobilen Bereich zu tun - webkit-ableger und Opera(Mobile/mini).Beide sind in der Lage normale, "nichtmobile" Webseiten prima darzustellen,

Sorry, aber das sehe ich de facto etwas anders (wie bereits erwähnt) ... ;-)
Denn auch wenn die "Basis(-Engine)" zwar die selbe sein mag, gibt es riesen Unterschiede. Und zwar werden diese am deutlichsten bei den jeweiligen "Automatismen", die die Browser von Hause aus mitbringen. Und da ist eben ein Webkit-Browser nicht gleich Webkit-Browser - vgl. u.a. Webkit iOS vs. Android (plus die bereits jetzt unzähligen Versionen der jeweiligen OS).

und ich sehe kein Grund da etwas zusätzlich anzupassen - Standartmaßnahmen für guten Styl, wir das verpacken von text in p reichen dicke aus.

Diese Maßnahmen sollten ja selbstverständlich sein - für jede Website. Aber für mich liegt es schon in der "Natur der Sache", dass eine möglichst benutzerfreundliche Webseite auf einem >= 960px breiten Viewport nicht identisch aufgebaut (layoutet) sein kann, wie auf einem Viewport mit 320px - 480px.

mich als mobilen Nutzer, nerven die abgespeckten mobilen Seiten ziemlich (die sind unübersichtlich und um das gesuchte zu finden muss ich 3 mal länger rumsuchen - das spart KEIN traffic) .

Da hast du mich missverstanden. Ich sprach nicht von "Abspecken". Dem mobilen User Informationen vorzuenthalten, halte ich in den allermeisten Fällen auch für falsch. Aber die Präsentation_muss_eine andere sein. Eine Seite, die für eine Viewportgröße von >= 960px layoutet ist auf meinem Smartphone zu betrachten und dann immer auf die ggf. gesuchten Stellen zoomen zu müssen erachte ich nämlich nicht als besonders "benutzerfreundlich".

also lass die "Optimierung", "best voodoo in internet explorer 6" hat uns nur eins beigebracht -
man codet nach standarten NICHT nach dem aktuellen forced-hype

Hmmm ..., wie immer man das auch verstehen mag/ soll - ich bin überzeugt davon, dass man für die Besucher seiner Seite coden sollte und möglichst jedem die für ihn bestmögliche "Präsentation" liefern sollte, unabhängig davon, welche Geräte und Software er verwendet (auch wenn man ggf. genau das dafür "wissen" muss)!

Gruß Gunther

[GrandmasterA]

Aber die Präsentation_muss_eine andere sein. Eine Seite, die für eine Viewportgröße von >= 960px layoutet ist auf meinem Smartphone zu betrachten und dann immer auf die ggf. gesuchten Stellen zoomen zu müssen erachte ich nämlich nicht als besonders "benutzerfreundlich".

Also mein HTC Desire HD skaliert Webseiten automatisch, so dass sie in den Viewport passen. Im Querformat kann ich Seiten, die "für 1024px optimiert" (gibt's ja genug) sind, ohne zoomen problemlos lesen. Und wenn nicht, zoom ich halt ran. Der Text verteilt sich zumindest in meinem Android-Browser dann automatisch auf den Viewport (neue Zeilenumbrüche), da brauch ich nicht mal hin und herscrollen.

Mit anderen Worten: Die MODERNEN mobilen Browser haben da keine gesonderten Ansprüche. Von daher würde ich auch zustimmen, dass hier nichts extra angepasst werden muss...

Ich surfe recht viel über mein Handy im Netz. Hatte da noch nie Probleme. Auch nicht bei veralteten Webseiten.

[bleicher]

Grüße,
ich hätte merken sollen, dass du nicht gefragt, sondern proklamiert hast ;)
ich bin "mobiles-internet-nutzer" und als deine potentielle targetgroup, habe ich meine Erfahrung und Meinung dazu mit dir geteilt.
wenn du die Seite für dich und nach deinen Wunschvorstellung aufbaust, ist es natürlich dein weg. aber was wolltest du dann hier von uns wissen?
MFG
bleicher

[molily]

du hast de-facto mit 2 Browsern im mobilen Bereich zu tun - webkit-ableger und Opera(Mobile/mini).

Ja, aber There is no WebKit on Mobile.

man codet nach standarten NICHT nach dem aktuellen forced-hype

Sicherlich nicht.

Mathias

[bleicher]

Grüße,

man codet nach standarten NICHT nach dem aktuellen forced-hype

Sicherlich nicht.

ich sollte mir abgewöhnen solch sensible wortspiele zu nutzen, kommt nie an :/
MFG
bleicher

[ChrisB]

Hi,

Und leider haben scheinbar weder die Macher der Browser, noch die Hersteller der Endgeräte etwas aus der Problematik der "Browser Wars" im vorletzten Jahrzehnt gelernt.

Fragt sich, wie viel jemand gelernt hat, der etwas vorschlägt -

1. Ich fände es gut, wenn es hier im Forum eine extra Kategorie (einen eigenen Themenbereich) für "mobiles Webdesign" gäbe.

• was stark danach klingt, wieder mit der „Optimierung“ auf bestimmte Endgeräte anfangen zu wollen.

MfG ChrisB

[Gunther]

Hi,

Fragt sich, wie viel jemand gelernt hat, der etwas vorschlägt -

• was stark danach klingt, wieder mit der „Optimierung“ auf bestimmte Endgeräte anfangen zu wollen.

Nicht bestimmte Endgeräte in dem Sinne, den ich dir jetzt mal in deiner Aussage unterstelle. Aber in dem Sinne, dass die Präsentation u.a. von der Größe des Viewports und der Auflösung des Anzeigegeräts abhängig sein sollte.

Und machen wir nicht im "Desktop-Design" genau das? Verwenden wir nicht u.a. deshalb bspw. Media Queries, um dem Besucher je nach Viewportgröße eine möglichst "optimale" Präsentation der Inhalte zu liefern?

Nichts anderes gilt IMHO für die Präsentation auf mobilen Endgeräten mit ihren meist deutlich kleineren Displays. Wobei die größte "Problematik" m.M.n. eben in den stark unterschiedlichen Automatismen der jeweiligen Hersteller begründet ist, die es eben genau verhindern/ verunmöglichen, "einfach" ein Layout für Alle zu erstellen.

Und genau durch solchen proprietären "Mist" fallen wir wieder zurück in die "Steinzeit". Oder sind eben "gezwungen" herauszufinden um welches Gerät/ welchen Browser es sich handelt, um diese (ungewollten) Automatismen zu "neutralisieren/ umgehen".

Und Media Queries alleine sind auch nicht das "Allheilmittel" dagegen!
Ich hatte hier im Forum bereits mal einen Post dazu geschrieben, der jedoch ohne jegliche Antwort geblieben ist.
Eines der "Hauptprobleme" von und mit Media Queries aktuell ist, dass fast alle Browser/ Geräte eine Zoom-Funktion bieten/ besitzen, es aber bislang _keine_Möglichkeit gibt, dies bei den Media Queries in irgendeiner Form zu berücksichtigen!
Hinzukommt (wie fast immer), dass die diversen Browser (-versionen) die ganze Geschichte unterschiedlich handhaben.
Diese Problematik verstärkt sich bei der Optimierung für mobile Endgeräte noch dadurch, dass ich bspw. anstatt Traffic für den User zu verringern genau das Gegenteil erreiche, weil plötzlich dann doch noch Stylesheets geladen werden, obwohl sie eigentlich gar nicht angewendet werden sollen.

Gruß Gunther

[molily]

1. Ich fände es gut, wenn es hier im Forum eine extra Kategorie (einen eigenen Themenbereich) für "mobiles Webdesign" gäbe.

• was stark danach klingt, wieder mit der „Optimierung“ auf bestimmte Endgeräte anfangen zu wollen.

Dieser Vergleich ist Quatsch. Früher hieß Optimierung, sich auf eine technische Konfiguration zu versteifen und alle anderen zu diskriminieren (Kritiker sprachen daher von »pessimieren«). Heute spricht man von Responsive Design, was ein komplett anderer Ansatz ist. Dabei geht es darum, Layouts und Inhalte anpassungsfähig zu machen, um den Zugang zu erleichtern. Auch das ist nichts neues.

Mobilgeräte stellen Websites anders dar, sie werden anders bedient und die Nutzeransprüche können andere sein. Es ergibt daher Sinn, Seiten im Sinne des Responsive Designs für Mobilgeräte zu »optimieren«.

Mathias

[ChrisB]

Hi,

Mobilgeräte stellen Websites anders dar, sie werden anders bedient und die Nutzeransprüche können andere sein. Es ergibt daher Sinn, Seiten im Sinne des Responsive Designs für Mobilgeräte zu »optimieren«.

Ich bin nur nicht der Ansicht, dass es dafür eine extra Kategorie braucht.

MfG ChrisB

[suit]

Ich bin nur nicht der Ansicht, dass es dafür eine extra Kategorie braucht.

Besonders unter dem Gesichtspunkt, dass das eher eine Frage der Bedienung und nicht der Displaygröße ist.

Ein Touchscreen-Gerät mit einem 15"-Monitor muss anders bedient werden als ein Gerät mit Tastatur- und Maus.

Ein Mobilgerät mit winzigem Display und Stift muss anders bedient werden als eines mit Fingerbedienung.

Zumal: was ist ein Mobilgerät? Ein Telefon mit Opera Mini ohne Touchscreen? Ein Telefon mit Safari und Touchscreen? Ein Tablet in der Kategorie iPad? Ein Subnotebook? Ein Tablet mit großem Touchscreen? Ein Notebook ohne Touchscreen?

[Wouzhuo]

Ich bin nur nicht der Ansicht, dass es dafür eine extra Kategorie braucht.

Besonders unter dem Gesichtspunkt, dass das eher eine Frage der Bedienung und nicht der Displaygröße ist.

Ein Touchscreen-Gerät mit einem 15"-Monitor muss anders bedient werden als ein Gerät mit Tastatur- und Maus.

Inwiefern z.B.?

[JürgenB]

Hallo Wouzhuo,

Ein Touchscreen-Gerät mit einem 15"-Monitor muss anders bedient werden als ein Gerät mit Tastatur- und Maus.

Inwiefern z.B.?

onmouseover / hover / ...

Gruß, Jürgen

[Wouzhuo]

Hallo Wouzhuo,

Ein Touchscreen-Gerät mit einem 15"-Monitor muss anders bedient werden als ein Gerät mit Tastatur- und Maus.

Inwiefern z.B.?

onmouseover / hover / ...

Okay, mir fällt als Beispiel ein Menü ein, was sich beim hover ausklappt. Was passiert denn momentan, wenn man mit Android / iPhone auf so einer Seite surft? Ist die dann nicht benutzbar oder lösen die Mobilbrowser das Problem irgendwie?

[suit]

Okay, mir fällt als Beispiel ein Menü ein, was sich beim hover ausklappt. Was passiert denn momentan, wenn man mit Android / iPhone auf so einer Seite surft? Ist die dann nicht benutzbar oder lösen die Mobilbrowser das Problem irgendwie?

Ein Klick ist mouseover, 2. Klick ist das tatsächliche click-Event, ein Klick irgendwo andershin ist das mouseout-Event.

[JürgenB]

Hallo suit,

ich habe das vor ca. zwei Jahren mal mit den Ipod-Touch ausprobiert, und damals hat der Mouseover auch beim Klick nicht funktioniert. Vielleicht gab es die Gesten damals noch nicht, vielleicht war ich aber auch nur zu ungeschickt. Ich bin schon froh, wenn mich die Kinder mal an ihre Spielzeuge ranlassen (Mensch Papa, irgendwie kriegst du's mal wieder nicht hin ...).

Seit diesem Misserfolg spendiere ich den Elementen zusätzlich zum onmouseover noch einen onclick:

ele.onmouseover = ele.onclick = mach_was;

Gruß, Jürgen

[suit]

Seit diesem Misserfolg spendiere ich den Elementen zusätzlich zum onmouseover noch einen onclick:

ele.onmouseover = ele.onclick = mach_was;

Du solltest das dringend auf einem neueren Gerät ausprobieren, damit zerstörst du nämlich das für den Benutzer gewohnte Bedienkonzept ;)

[JürgenB]

Hallo suit,

Seit diesem Misserfolg spendiere ich den Elementen zusätzlich zum onmouseover noch einen onclick:

ele.onmouseover = ele.onclick = mach_was;

Du solltest das dringend auf einem neueren Gerät ausprobieren, damit zerstörst du nämlich das für den Benutzer gewohnte Bedienkonzept ;)

warum? Wird onmouseover unterstützt, ist's gut, sonst kann geklickt werden.
Ich habe das bei meiner Navigation so gemacht: onmouseover öffnet Menü, onclick ebenfalls und ohne Javascript führt Klick zur Sitemap.

Gruß, Jürgen

[Gunther]

Okay, mir fällt als Beispiel ein Menü ein, was sich beim hover ausklappt. Was passiert denn momentan, wenn man mit Android / iPhone auf so einer Seite surft? Ist die dann nicht benutzbar oder lösen die Mobilbrowser das Problem irgendwie?

Ein Klick ist mouseover, 2. Klick ist das tatsächliche click-Event, ein Klick irgendwo andershin ist das mouseout-Event.

Das kann ich so für Android Browser nicht ganz bestätigen.
Denn ist das Element mit dem Hover-Effekt selbst bereits ein Link, dann wird zwar beim ersten Klick darauf auch der Hover-Effekt ausgeführt, gleichzeitig wird aber auch schon der Link geladen.

Gruß Gunther

[suit]

Das kann ich so für Android Browser nicht ganz bestätigen.

Denn ist das Element mit dem Hover-Effekt selbst bereits ein Link, dann wird zwar beim ersten Klick darauf auch der Hover-Effekt ausgeführt, gleichzeitig wird aber auch schon der Link geladen.

In Opera Mobile 11 unter Android nicht - im Default Browser unter Android 2.1 schon, unter 2.2 aber wieder nicht.

Grade ausprobiert :)

[suit]

Ein Touchscreen-Gerät mit einem 15"-Monitor muss anders bedient werden als ein Gerät mit Tastatur- und Maus.

Inwiefern z.B.?

Troll? :)

[Gunther]

Hallo werte Selfgemeinde!

Nach den bisherigen Antworten (danke dafür schon mal), möchte ich hier mal einige (exemplarische) Fragen auflisten, deren Beantwortung oder Abhandlung ich persönlich sehr begrüßen würde.

Diese Frage beziehen sich im wesentlichen auf die Besonderheiten für die Gestaltung von Webseiten für die Betrachtung auf "mobilen Endgeräten". Ich möchte diesen Begriff absichtlich nicht versuchen genau zu definieren, aber grundsätzlich zählen für mich darunter die Endgeräte, für die einer oder mehrere der nachfolgenden Punkte zutreffen:

• Displaygröße kleiner als 960px (wenn man diese mal als "Untergrenze" für den klassischen Desktop-PC annehmen möchte)
• keine Maus (und somit auch kein Cursor) zur Steuerung vorhanden - stattdessen Touchscreen
• Internetanbindung über Mobilfunknetz

Ich bin der Meinung, dass sich aus den oben genannten Punkten durchaus etliche Fragen aufwerfen, die vielleicht nicht unbedingt alle ganz neu sind, deren Relevanz sich aber zumindest deutlich erhöht hat.

Folgende Fragen fallen mir dazu u.a. ein:

• Welche Auszeichnungssprache (in welcher Variante) sollte ich idealerweise verwenden (z.B. HTML 4 oder HTML 5)?
• Eine Version für "alle" oder doch besser eine eigene "Mobile Version"? Und wenn ja, wie (UA- / Browser Sniffing)?
• Welche Besonderheiten gibt es/ gilt es zu beachten (bspw. meta viewport tag)?
• Welche Aspekte spielen eine besondere Rolle (Anzahl Requests, Datenvolumen, Bildgrößen) und wie setzt man sie am besten um?
• Mit welchen Besonderheiten und Bugs muss man bei den (gängigen) mobilen Versionen der jeweiligen Browser umgehen?
• Wie kann ich die Anzahl der HTTP Requests reduzieren/ möglichst gering halten?
• Worauf sollte ich bei der Bedienung auf einem Touchscreen besonders achten?
• Wie handhabe ich die verschiedenen Displaygrößen_und_Auflösungen am besten (Stichwort "Media Queries")?
• Welcher Browser versteht was und wieviel (HTML5, CSS3)?
• Welche (zusätzlichen) Möglichkeiten/ Optionen bieten die Endgeräte? Und wie kann ich ggf. darauf zugreifen?
• Worauf kann und sollte ich bei einer Webseite achten, wenn ich_keine_eigene "Mobile Version" davon erstellen möchte?
• Wie wirken sich evt. "Manipulationen" durch zwischengeschaltete Server (z.B. Opera Turbo) aus? Und wie kann ich diese ggf. unterstützen oder vermeiden?
• Wie kann ich trotz unterschiedlichster Displaygrößen und Auflösungen die Anzahl an Grafiken durch die Verwendung von CSS Sprites minimieren?

und und und ...
Diese Liste erhebt keinen Anspruch auf Vollständigkeit - im Gegenteil. Dies soll nur mal ein kleiner Auszug an möglichen Fragestellungen sein, mit denen man sich bei Beschäftigung mit dem Thema konfrontiert sehen kann.

Sicherlich mag es auf viele Fragen keine eindeutige Antwort geben. Aber dann war und ist es nach guter alter SELFHTML Manier doch so, dass alle Alternativen vorgestellt und gegeneinander abgewogen werden und ggf. eine Empfehlung gegeben wird.

Auch eine sachliche Diskussion über die Für & Wider hat noch nie geschadet. ;-)

Gruß Gunther

[LX]

Hallo, Gunther

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.

• 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.

• 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.

• Welche Aspekte spielen eine besondere Rolle (Anzahl Requests, Datenvolumen, Bildgrößen) und wie setzt man sie am besten um?

Jeder Request kostet Zeit - mit deutlich mehr Latenz als auf dem Desktop. Das Datenvolumen spielt jedoch im mobilen Kontext auch eine größere Rolle. Grundsätzlich gilt also: weniger ist mehr. Ein zusätzlicher HTTP-Request kann schon mal 1-2 Aufrufe (einschließlich DNS-Auflösung) mit insgesamt 3k Datenvolumen ausmachen, die zu einer spürbaren Verlangsamung führen.

Dementsprechend gilt: weniger ist mehr: weniger und kleinere Bilder, Reduzieren der optischen Elemente auf das Wesentliche, Darstellung vorwiegend untereinander statt nebeneinander.

• Mit welchen Besonderheiten und Bugs muss man bei den (gängigen) mobilen Versionen der jeweiligen Browser umgehen?

Am Schlimmsten ist die Formular-Formatierung - da haben selbst moderne Browser teilweise Probleme. Danach kommen diverse Probleme mit Floating im Mobilen IE und im Blackberry (in letzterem teilweise mit dem Effekt, dass Elemente nicht mehr klickbar sind). Opera hat zudem noch einen Fehler im Schriftrenderer, der Breiten teilweise nicht korrekt erkennt und umgebende Nodes abschneidet.

Ü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.

• Wie kann ich die Anzahl der HTTP Requests reduzieren/ möglichst gering halten?

CSS und HTML in eine Datei. Images sofern es Vorteile bringt in Sprites. JS sparsam einsetzen, ggf. auch mit ins HTML.

• Worauf sollte ich bei der Bedienung auf einem Touchscreen besonders achten?

Der minimale Platz, um ein Node zu treffen, ist bei normal großen Displays 16x16px². Elemente, die klickbar sind, sollten mindestens so groß bzw. so weit vom nächsten Element entfernt sein.

• 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.

• 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

• Welche (zusätzlichen) Möglichkeiten/ Optionen bieten die Endgeräte? Und wie kann ich ggf. darauf zugreifen?

Insbesondere iOS Safari bietet die Möglichkeit, Seiten als WebApps zu betreiben. Google hilft. Safari und der Android Browser kennen touch-Events.

• Worauf kann und sollte ich bei einer Webseite achten, wenn ich_keine_eigene "Mobile Version" davon erstellen möchte?

Semantik.

• Wie wirken sich evt. "Manipulationen" durch zwischengeschaltete Server (z.B. Opera Turbo) aus? Und wie kann ich diese ggf. unterstützen oder vermeiden?

Nicht wahrnehmbar, außer dass es im Opera Mini keine Events in dem Sinne gibt.

• Wie kann ich trotz unterschiedlichster Displaygrößen und Auflösungen die Anzahl an Grafiken durch die Verwendung von CSS Sprites minimieren?

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

Gruß, LX

[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

[LX]

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

[LX]

Hallo, Gunther!

Schon die wenigen Desktopbrowser stellen uns immer wieder vor große Herausforderungen. Wenn wir nun noch Energien binden, um obskure Browserprobleme wie den GIF-Darstellungsfehler von Obigo oder die Formular-Darstellung im Netfront Access zu katalogisieren, kommen wir zu nichts mehr.

Zu meinem Job gehört auch der Bau von mobilen Webseiten - und dabei habe ich gelernt, dass das mobile Web grundlegend anders funktioniert als das Internet auf dem Desktop. Begrenzter Bildschirmplatz führt zu minimalistischen Lösungen; Einschränkungen der Bedienbarkeit zu neuen Herausforderungen an die Usability. JavaScript ist fast auf allen Geräten verfügbar - aber zu welchem Anteil? Und mit wie viel Speicher kann man wie lange arbeiten? Die Verbindungen sind manchmal langsam oder können auch völlig abbrechen, dennoch möchte man eine nutzbare Seite. Mit einem einzelnen Template kommt man angesichts der unterschiedlichen Geräte nicht immer aus; wie filtert man - und was liefert man aus?

Gruß, LX