Der Martin: Webdesign für mobile Endgeräte

Beitrag lesen

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

--
Drei Sachen vergesse ich immer wieder: Telefonnummern, Geburtstage und ... äääh ...
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(