Design im Umbruch

piratos · 03. September 2011 11:23

Webdesigner sehen sich heute mit einer Situation konfrontiert die völlig anders ist als noch vor 2 Jahren.

Mobile Einheiten

Da tummelt sich noch so ziemlich alles - Geräte die fast nichts können bis zu den hoch aktuellen Geräten die reichlich leisten, was Webbrowser und Display betrifft.

Und - die sind dabei die Vorherrschaft im Netz zu gewinnen, knabbern bei der Nutzung bereits an der 50% Marke.

Aber - Mobile sind 3 bis 10 mal langsamer als ein Desktop PC und haben Einschränkungen, da eine Tastatur normal nur virtuell vorhanden ist und eine Maus überhaupt nicht, dafür hat man Tastensteuerung und Displaysteuerung.

Home Netzwerk
Da gibt es inzwischen ja so ziemlich alles, der aktuelle Knüller ist die Einbeziehung des Fernsehers in die Internetwelt.

Da kann man fixe Layouts bewundern, die wie ein Klecks auf dem Großbildschirm aussehen. Murrt jemand aus der Familie bei einem solchen Anblick ist die Seite bereits gestorben bevor jemand sich überhaupt etwas angesehen hat.

Und das kann schon passieren, wenn eine Seite sich nur ätzend langsam aufbaut, wobei ätzend langsam da ein Bezug ist zu den Filmen die man sich normal über den Fernseher anschaut.

Home Netzwerke schlucken zudem Zeit.

Desktop PC's

Auch hier gelten ähnliche Bedingungen wie beim Homenetzwerk, nur das man hier eine geballte Rechnerleistung vorliegen hat und Bildschirme die es unter 21 Zoll kaum noch zu kaufen gibt.

Was zählt ist nicht nur ein Design das gut aussieht und praktikabel ist sondern was auch schnell ist.

Speed wird durch mehrere Faktoren bestimmt.

1. Speed der Anwendung selbst - darauf haben nur die Programmierer einen Einfluss

2. Reaktionszeiten - da kann man nur wenig an der Providerschraube drehen

3. Pagespeed - das ist eigentlich völlig unabhängig von einem System und Sache des Webdesigner und des Webmasters (Inhalte) und das bringt am meisten.

Neben allerhand Dingen die man schlagartig via htaccess erledigen kann sind es insbesondere die Anzahl der Request's die entscheidend für den Speed sind.

Das aber ist bereits eine Frage des Designs und dessen Ausführung.

Jeder Request kann zu enormen Zeiten führen, insbesondere dann wenn die Leitungen länger werden, d.h. sie wird von einem anderen Standort aus betrachtet, als wo sich der Server aufhält.
Je mehr Knotenpunkte zu überwinden sind, desto mehr Zeit pro Request - da können dann locker mehrere Sekunden aus einem Seitenaufruf werden.

Wenn man überlegt, das Mobile 3...10 x langsamer sind und diese Gruppe langsam aber sicher den Markt beherrscht, dann kann man sich sicher vorstellen, das eine solche Website was Mobile betrifft nichts werden wird bzw. enorme Einbußen haben wird.

Beispiel: http://www.webpagetest.org/result/110903_MY_1G469/

Es kommt also darauf an die Anzahl der Request's stark zu verringern.

Neben den bekannten Pagespeed-Maßnahmen gibt es auch so einige, die weniger bekannt aber sehr wirkungsvoll sind.

1. CSS zusammenfassen und als inline darstellen
2. CSS von der Seite abhängig ausführen, nur das durchlassen was man benötigt
3. Images in der CSS als base64 ausführen oder wenn das nicht geht als Sprite.
4. Javascripte async oder defer laden, wenn machbar
5. Images in HTML als base64 laden
6. application cache nutzen
7. möglichst keine Fremdscripte von extern laden da man darauf keinerlei Einfluss hat

Man sollte versuchen die Anzahl der Request's so weit zu drücken, das diese < 20 werden.

Die Navigation ist bei mobilen Einheiten ein ganz heikles Thema und es sieht bei Pads noch ganz anders aus als bei Smartphones.
Ein Pad ist durchaus in der Lage ein normales Web verarbeiten zu können, bei Smartphones kann das aber schon ganz anders aussehen - da rührt man u.U. wie verrückt mit dem Finger herum und erntet Frust - eine solche Website wird man nicht noch einmal besuchen.

Da muss sich ein Designer etwas einfallen lassen.

Das gilt auch für die Bildschirmgrößen, denn da hat man ja nun alles von 320 Pixel Displays bis hin zum 50 Zoll (und mehr) Fernseher.

Das ist nicht einfach, es gibt auch keine Universalrezepte, eine Aufteilung in verschiedene Webs für Desktop, Homenetzwerk, Smartphones und Tabs scheint mir aber nicht praktikable zu sein.

Diese Situation ist eine echte Herausforderung und erfordert Webdesigner die ihr Handwerk verstehen - oder was meint ihr ?

mike-r · 03. September 2011 17:16

piratos schrieb:

Mobile Einheiten
[...]
Und - die sind dabei die Vorherrschaft im Netz zu gewinnen, knabbern bei der Nutzung bereits an der 50% Marke.

Quelle?

1. CSS [...] als inline darstellen
3. Images in der CSS als base64 ausführen [...]
4. Javascripte async oder defer laden, wenn machbar
5. Images in HTML als base64 laden

Dufte Ideen für dünne mobile "Leitungen". Nee, ernshaft: Mittags schon Eierlikör? glasses

Beitrag geändert von mike-r (03. September 2011 17:16)

piratos · 03. September 2011 17:43

Du trinkst schon mittags Eierlikör ?
Naja - jedem das seine.

mike-r schrieb:

Dufte Ideen für dünne mobile "Leitungen".

Also in Deutschland sind es 28% (http://www.accenture.com/SiteCollection … h-2011.pdf) , weltweit in den Industrieländern knapp 50% (man sollte da schon dran denken, das Internet keine Grenzen hat. ) smile

Die Ideen sind nicht nur für dünne mobile Leitungen gut sondern die wirken auch bei normalen Web's und außerdem bereits längst aus dem Ideenbereich raus , realisiert und praktisch ausprobiert mit Super Ergebnissen, um nicht zu sagen, bei manchen ist das Standard.

Man muss sich einmal Gedanken machen wie man diese verschiedenen Leistungsklassen bei dem Empfangsgeräten / Browsern unter einem Hut bringen kann.
Ich glaube niemand hat wirklich Lust (und wer bezahlt das) für jeden Bereich ein eigenes Web machen zu wollen.

Beitrag geändert von piratos (03. September 2011 17:45)

NaN · 03. September 2011 19:43

piratos schrieb:

Man muss sich einmal Gedanken machen wie man diese verschiedenen Leistungsklassen bei dem Empfangsgeräten / Browsern unter einem Hut bringen kann.
Ich glaube niemand hat wirklich Lust (und wer bezahlt das) für jeden Bereich ein eigenes Web machen zu wollen.

Naja, aber ein Web für alle Geräte funktioniert auch nicht, ohne dass man irgendwo Kompromisse machen muss.
Denn niemand hat Lust für eine Seite zu bezahlen, die dann aussieht wie vor 10 Jahren, nur weil gerade Surfen in Zigarettenschachtelgröße In ist.

man sollte da schon dran denken, das Internet keine Grenzen hat.

Man sollte aber auch schon daran denken, dass man nicht immer gleich die ganze Welt erreichen will und schon garnicht muss. Es gibt nämlich sowas, das nennt sich Zielgruppe. Man muss sich immer überlegen, wen man eigentlich erreichen will. Der lokale Rentnerverein z.B. braucht keine für mobile Endgeräte optimierte Webseite. Es gibt auch noch andere Dinge im Internet als Firmenpräsenzen und Geldscheffelei.

mike-r · 03. September 2011 19:57

piratos schrieb:

Die Ideen sind nicht nur für dünne mobile Leitungen gut

Die Ideen sind für mobile Leitungen Quatsch mit Sosze, das kann Dir ein Viertklässler vorrechnen.

bei manchen ist das Standard.

ein schöner Standard, wo ich für 50ms (request-)Ersparnis je Grafik eine Sekunde brauche, weil der Autor so schlau war 10×30kb-Grafiken mittels base64 ins HTML reinzuklamüsern.

Ich glaube niemand hat wirklich Lust (und wer bezahlt das) für jeden Bereich ein eigenes Web machen zu wollen.

es gibt ausreichend gute Mobil-templates, die fluid sind und auf jedem Mobilgerät gleich aussehen, egal wieviel Pixel das Gerät mitbringt.
Somit sind wir bei 2 "Webs".
€:

piratos schrieb:

Also in Deutschland sind es 28% (http://www.accenture.com/SiteCollection … h-2011.pdf)

Ach, die Ecke. 28% nutzen also "mal" das Netz aufm Handy. Dachte, Du wärst wieder bei deiner Trafficschiene.

Beitrag geändert von mike-r (03. September 2011 20:02)

piratos · 03. September 2011 20:05

mike-r schrieb:

Die Ideen sind für mobile Leitungen Quatsch mit Sosze, das kann Dir ein Viertklässler vorrechnen.

Also wenn ich das so lese darf ich mal genauso antworten - du hast von solchen Dingen offenbar keinen blassen Schimmer Ahnung, wie man das macht und was sie bewirken, was sie bringen und was sie kosten , wirklich NULL Ahnung.

Thema Zielgruppe

Die gibt es praktisch nicht, die Leute schauen mobil rein wenn sie mobil sind und via Desktop wenn sie am Schreibtisch sitzen.

Das Thema ist das Webbetreiber und Co. nämlich diejenigen die als Lieschen Müller über ein CMS die Inhalte pflegen das nicht 2 x oder 3 x machen wollen.

NaN · 03. September 2011 20:12

piratos schrieb:

Thema Zielgruppe
Die gibt es praktisch nicht, die Leute schauen mobil rein wenn sie mobil sind und via Desktop wenn sie am Schreibtisch sitzen.

Na wenn Du meinst.

piratos schrieb:

Das Thema ist das Webbetreiber und Co. nämlich diejenigen die als Lieschen Müller über ein CMS die Inhalte pflegen das nicht 2 x oder 3 x machen wollen.

Wieso sollte jemand Inhalte doppelt pflegen sollen, nur weil er auch Mobile Endgeräte berücksichtigen ... ? Das ist doch nicht Aufgabe des Content-Erstellers, sondern des Webseiten-Erstellers. Die Webseite muss so aufgebaut sein, dass sie je nach Client die Inhalte in entsprechender Form wiedergeben kann. Aber das verstehe ich wiederum unter "zwei oder mehr Webs aufbauen". Also mehr als nur ein Template. Für jedes Ausgabemedium eines, was dann per Schalter auf dem Server ausgeliefert wird.

mike-r · 03. September 2011 20:17

piratos schrieb:

du hast von solchen Dingen offenbar keinen blassen Schimmer Ahnung, wie man das macht und was sie bewirken, was sie bringen und was sie kosten , wirklich NULL Ahnung.

Ich brauch keine Ahnung um mir auszurechnen dass ein durch Base64 ersparter Request aufm Mobile genau das Gegenteil von dem macht, was du hier propagierst.
Wenn ich da einen Denkfehler haben sollte, kannste mir das auch gern mal nachvollziehbar vorrechnen, was - ausser nervtötende Warterei - das bringen soll.

piratos · 03. September 2011 20:41

mike-r schrieb:

piratos schrieb:
du hast von solchen Dingen offenbar keinen blassen Schimmer Ahnung, wie man das macht und was sie bewirken, was sie bringen und was sie kosten , wirklich NULL Ahnung.
Ich brauch keine Ahnung um mir auszurechnen dass ein durch Base64 ersparter Request aufm Mobile genau das Gegenteil von dem macht, was du hier propagierst.

Es steht dir ja frei deine Behauptung mit einem einfachen Beispiel zu berechnen.

Aber schau mal hier:

http://www.blaze.io/mobile/result/?test … SZ&src=wpt

oder ganz einfach pcms.

Tut mir leid - da musst du nochmal etwas dazu lernen.

Von Caching scheinst du auch noch nie etwas gehört zu haben. smile

NaN · 03. September 2011 20:49

Ich wusste doch, dass es darauf hinausläuft, Grafiken ganz wegzulassen roll
Aber exakt die gleiche Seite auf einem PC sieht einfach nur Scheiße aus.
Sorry, aber Speed allein ist nicht alles.

mike-r · 03. September 2011 21:14

piratos schrieb:

Tut mir leid - da musst du nochmal etwas dazu lernen.

Wie ich eine Seite ohne Grafiken auf kleiner 25KB bekomme, weiss ich, aber danke für die Info. Du hast da 15% Information/Text auf deiner Seite, und willst ernstgenommen werden? Es ist Samstag Abend und ich fange an mich ernsthaft zu amüsieren. Hast Du noch mehr zu bieten?

NaN schrieb:

Ich wusste doch, dass es darauf hinausläuft, Grafiken ganz wegzulassen

Das muss nicht zwingend wie 1993 aussehen. wink

NaN · 03. September 2011 21:21

Naja, mit CSS3 könnte man bestimmt so einige hübsche grafische Effekte rein mit Hilfe von Stylesheets realisieren. Schattierungen, runde Ecken, Farbverläufe - vielleicht sogar Canvas-Elemente und Javascript ... nur weiß ich grad nicht genau, wie das mit der begrenzten Rechenpower von Smartphones zusammenpasst. Möglicherweise ist das auch zu vernachlässigen. Möglicherweise aber auch nicht. Kann da leider grad keine Erfahrungswerte beisteuern.

piratos · 03. September 2011 21:23

Das ist doch Kokolores.
Das geht hier überhaupt nicht um Optik einer Baustelle, die ist völlig egal, sondern um Wirkung und darum das irgend jemand erkennbar ohne einen blassen Schimmer auf den Putz haut und von Dingen reden will von denen er absolut wissensfrei ist, der offenbar meint man generiere base64 jedesmal frisch, oder etwa eine angepasste Seitencss usw. der Caching lediglich aus dem Wörterbuch kennt oder von hörensagen.
Solche Einfaltspinsel, die mir dazu Alkoholgenuss unterstellen, bringen mich auf die Palme.

Ein paar Images mehr =
http://www.blaze.io/mobile/result/?test … T9&src=wpt

Jede Menge Images ?
Kein Thema nimmt man halt eine andere Seite http://www.webpagetest.org/result/110903_2Z_1G72Q/ , da sind massig base64 enthalten aber keine sonstigen Tricks.

Connie · 03. September 2011 21:34

ach piratos,

sei doch ein bißchen entspannter ;=)

mike-r · 03. September 2011 21:49

piratos schrieb:

irgend jemand erkennbar ohne einen blassen Schimmer auf den Putz haut und von Dingen reden will von denen er absolut wissensfrei ist,

Quelle?

der offenbar meint man generiere base64 jedesmal frisch,

Quelle? Davon ab: kannst Du da ein paar Infos zum Thema nachschieben, statt zu hyperventilieren?

oder etwa eine angepasste Seitencss usw. der Caching lediglich aus dem Wörterbuch kennt oder von hörensagen.

Quelle?

Solche Einfaltspinsel

Oh, es geht wieder mit persönlichen Beleidigungen los. Weiss grad nicht, warum ich ich bisher Deinen rechnerischen Unsinn oben und Dein Statistikbildchen-fetisch nicht als Mumpitz bezeichnet habe. Werde mir in Zukunft mehr Mühe geben, mit Dir auf Deinem Niveau zu diskutieren.

piratos · 04. September 2011 22:10

mike-r schrieb:

Nee, ernshaft: Mittags schon Eierlikör?

Schon vergessen wer damit angefangen hat ?
Das ist dein Niveau und das liegt in Wirklichkeit offenbar noch niedriger als ich vermutet habe.

Einem dem man erst einmal nachweisen muss wie es um mobile Aktivitäten steht, der davon also vorher nicht so richtig etwas gewusst hat, und dann völlig unqualifiziertes Zeug von sich gibt.

Mach doch mal eine Rechnung wie auf wie deine Bilanz bei http://www.webpagetest.org/result/110903_2Z_1G72Q/ ohne base64 ausehen würde.

NaN · 04. September 2011 22:13

Leute... nun kommt mal bitte wieder runter.

@piratos: Kompliment. Deine Seiten sind schnell. Aber sie sind - mit verlaub - keine Eye-Catcher. Auf Smartphones & Co ist das völlig okay. Aber auf einem riesen Display (wo hinten noch ein Quad-Core Superduper Rechner dranhängt) ist das wirklich nur bissel Fließtext mit paar Bildchen und daher nicht sonderlich aufregend.

Versteht mich nicht falsch, ich stehe auf Seiten die übersichtlich und auf das wesentliche reduziert sind. Noch mehr stehe ich dabei allerdings auf Seiten die noch dazu interessant gestaltet sind. Und da bin ich nicht alleine.

In den letzten 20 Jahren haben sich Webseiten von reinen langweiligen Dokumenten mit Querverweisen hin zu interessanten Applikationen oder Kunstwerken entwickelt. Eine einzige Seite für alle Geräte zu machen, würde bedeuten, auf allen Geräten einen ganzen Schritt zurück zu gehen. Ich glaube nicht, dass das wirklich einen Vorteil bietet. Da erstelle ich doch lieber eine Seite, die je nach Gerät entsprechend reduziert oder aufgebläht ist.

Es kommt natürlich immer auf den Geldbeutel an. Aber hier kommt der Punkt an dem ich bereits sagte: Manchmal muss man einfach Kompromisse machen. Entweder der Kunde bezahlt für ein hochoptimiertes aber dafür einfaches Design für alle Geräte oder er zahlt für mehrere ja nach Gerät optimierte aber dafür (für einige Geräte) etwas anspruchsvollere Designs.

Das muss man meiner Meinung nach von Fall zu Fall entscheiden. Eine allgemeingültige Musterlösung gibt es da nicht und wird es vermutlich auch nie geben.

mike-r · 04. September 2011 22:46

piratos schrieb:

Mach doch mal eine Rechnung wie auf wie deine Bilanz bei http://www.webpagetest.org/result/110903_2Z_1G72Q/ ohne base64 ausehen würde.

Inhaltlich mag das ne interessante Geschichte sein, haste da vlt. paar Testcases dazu? Mag mir grad die Grafiken da nich rauspulen.
Das Webpagetest-ding, nunja, Firebug sagt mir was anderes. Wenn ich da bspw. trash-wissen.de vergleiche, wo nix inline und nix grossartig optimiert ist, wo jede Menge Müll mitgeladen wird und zig Requests am Werkeln sind, macht Deine Referenz den 2. Platz:
Erster Aufruf:
trash-wissen.de:
24 requests: 1,91 Sek
tagungshotels.com/..suche
6 requests: 2,78s

2. Aufruf:
trash-wissen.de:
24(2×200ok) requests: 2,17 Sek (warum auch immer für 12,5kb Text)
tagungshotels.com/..suche
6(1×200ok) requests: 2,74s

Wie bringen wir diese Zahlen jetzt in Übereinstimmung mit Deiner Liste?

Beitrag geändert von mike-r (04. September 2011 22:49)

piratos · 04. September 2011 10:31

mike-r schrieb:

Wie bringen wir diese Zahlen jetzt in Übereinstimmung mit Deiner Liste?

Man muss mit gleicher Technologie und Rahmenbedingungen und gleicher Empfangsstelle und gleichen Browser vergleichen.

Einfach base64 erzeugen für alle das funktioniert nicht, da nicht alle Browser das überhaupt oder nur teilweise verarbeiten können.

Das soll nun kein Grundkurs für Pagespeed - Anfänger werden, aber man kann es sich vielleicht vorstellen, das man diesen Imageteil vom Browser abhängig ausführt.

Nehmen wir mal den ersten Test - Frankfurt IE9

http://www.webpagetest.org/result/110903_2Z_1G72Q/

und nehmen wir mal einen weiteren Test Frankfurt IE 7, der IE 7 hat absolut keinen Schimmer von Base64, deswegen bekommt er alles als normalen Imagelink vorgesetzt.

http://www.webpagetest.org/result/110904_B2_1GA4Q/

Und wenn man sich die Werte ansieht hat man eine ziemlich klare Vorstellung von dem was base64 bringt - nämlich nur Vorteile.

Was bei dem http://www.blaze.io/mobile/result/?test … SZ&src=wpt niemand aufgefallen ist 0 Request, 0 Bytes übertragen - erstaunlich.

Und dennoch 0,84 Sekunden beim ersten Durchlauf für die Darstellung, dann aber 0 Sekunden beim zweiten.

Nun liegt die Teststelle in Kanada, das muss man so hinnehmen, ansonsten käme da eine sehr viel kleinere Zeit heraus.

Was man in dem Test sieht ist das 0 Request - Web.

Das Speed unabdingbar ist - völlig klar, denn Smartphones und Tabs sind 3..10 langsamer als ein Desktop.

Das ist eine Herausforderung und wegen der Verbreitung der Mobilen eine schwerwiegende.

Das Web muss gefallen, aber es muss ausreichend schnell sein und es muss funktionabel sein für Desktop wie auch für Mobile.

Das ist die Herausforderung und nicht die Aufklärung einzelner wie Pagespeed und Speed - Methoden funktionieren.

Nachtrag:

Wenn man sich den mobilen Check ansieht, der allerdings weit weg in Kanada läuft kann man die Problematik erkennen, auch wenn die Zeiten bei dem geballten Inhalt und für Kanada nicht schlecht sind, sie reichen aber in der Praxis nicht aus.

Nicht vergessen - hier werden nur die Request's über base64 reduziert, ansonsten keine Tricks verwendet:

http://www.blaze.io/mobile/result/?test … pt#testube

Beitrag geändert von piratos (04. September 2011 11:09)

piratos · 04. September 2011 12:02

NaN schrieb:

Wieso sollte jemand Inhalte doppelt pflegen sollen, nur weil er auch Mobile Endgeräte berücksichtigen ... ? Das ist doch nicht Aufgabe des Content-Erstellers, sondern des Webseiten-Erstellers. Die Webseite muss so aufgebaut sein, dass sie je nach Client die Inhalte in entsprechender Form wiedergeben kann. Aber das verstehe ich wiederum unter "zwei oder mehr Webs aufbauen".

Natürlich ist es die Aufgabe zunächst vom Webseiten-Ersteller, aber Lieschen Müller muss sich u.U. an bestimmte Dinge halten und wenn es nur die Größen von verwendeten Images sind.

Und natürlich ist Lieschen auch dafür mit verantwortlich ob eine bestimmte Leistung erreicht wird oder nicht.

Und der Aufbau einer Darstellung kann sich verändern, was z.B. vorher in drei Spalten nebeneinander lag, kommt jetzt untereinander - das muss bei den Inhalten berücksichtigt werden.
-------------
Manche kommen auf die Idee das ihr Web auch so von den Mobilen verarbeitet werden.

Das ist tatsächlich bei den meisten aktuellen Geräten der Fall, aber dann wird eine Seite auf dem kleineren Display entweder soweit verkleinert das es da rein passt oder es wird so genommen das man Fingerspiele machen muss.

Das Thema Leistung wird dabei absolut nicht berücksichtigt.
Verkleinerte Seiten sind meist nicht lesbar.
Die Navigation ist für Fingerbetrieb unbrauchbar.

Ein solches Vorhaben bewirkt nur eines - die Besucher kommen nicht wieder.

---------------

Nun haben wir ja noch die andere Seite - die des Surfens über Fernseher.
Gute Fernseher haben da mindestens 1920 x 1080 Pixel.

Verwendet man ein fixes Layout hat man u.U.den Klex auf dem Bildschirm.

Nimmt man Fluid hat man u.U. einen Streifen auf dem Bildschirm, der Rest ist Hintergrund.

Auch da gibt es Haue vom Besucher - die kommen nicht wieder und insbesondere dann, wenn die Familie vor der Glotze sitzt und einer fängt an zu meckern.

Zum anderen haben wir da ja auch noch einen ganz anderen Sichtabstand.

Man müsste also ein Konzept finden bei dem das alles vernünftig gesteuert werden kann.

NaN · 04. September 2011 14:16

Also prinzipiell sind Deine Überlegungen die gleichen die mir auch manchmal durch den Kopf gehen. Nur bin ich a) kein Profi und b) habe ich nicht die Zeit, mir ewig Gedanken um Techniken zu machen, mit denen man alles abdecken kann. Daher gehe ich meist den Weg mit dem Kompromiss.

piratos schrieb:

Zum anderen haben wir da ja auch noch einen ganz anderen Sichtabstand.

Stimmt. Und das nicht nur vor dem Fernseher. Ich habe ja schon öfter darüber geklagt, dass ich bei meinem 15" Macbook mit einer Auflösung von 1680x1050 kaum eine Webseite lesen kann, ohne die Kiste 30cm vor mir auf dem Schoß zu haben oder jede Webseite erst 3-5 mal vergrößern zu müssen. Außer mit Javascript kenne ich da leider keine Möglichkeit, auch die Schriftgröße in Abhängigkeit von Fenstergröße oder Auflösung anzupassen.

piratos schrieb:

Und natürlich ist Lieschen auch dafür mit verantwortlich ob eine bestimmte Leistung erreicht wird oder nicht.
Und der Aufbau einer Darstellung kann sich verändern, was z.B. vorher in drei Spalten nebeneinander lag, kommt jetzt untereinander - das muss bei den Inhalten berücksichtigt werden.

Naja ... lassen wir Lieschen mal Lieschen sein und konzentrieren wir uns lieber darauf, wie wir das bei der Ausgabe hinkriegen. Lass Lieschen doch riesige Bilder einfügen o.ä. Das kann uns doch sowas von egal sein, wenn wir beim Speichern oder besser erst bei der Ausgabe diese Bilder auf die Größe, die gerade tatsächlich gebraucht wird, runterrechen und evtl. auch noch base64 kodiert einbinden (und cachen). Das Thema Bilder dürfte hier weniger das Problem sein, denn da sehe ich viele Möglichkeiten wie man als Webdesigner dafür sorgen könnte, dass sie für das jeweilige Gerät optimiert sind.

Komplizierter wird es meiner Meinung nach tatsächlich erst beim Layout. Auch hier dürften Bilder oder Formatierungen weniger das Problem sein. Grafische Spielereien könnte man bei mobilen Endgeräten weglassen und stattdessen einfach nur mit Hintergrundfarben oder den Möglichkeiten von CSS3 arbeiten. Formatierungen (Schriftgrößen, Abstände, Breite etc.) passt man dem Gerät an bzw. verwendet Prozent-Angaben. Und natürlich muss man auf den korrekten Media-Type achten.

Was die Aufteilung der Webseite angeht (Spalten, Positionen etc.) das ist der Punkt an dem es meiner Meinung nach komplizierter wird, weil man das nicht unbedingt nur mit einem angepassten Stylesheet hinbekommt. Da muss dann mitunter auch mal ein dynamisches Template her, oder man hat eben mehrere Templates.

Ich glaube jedenfalls nicht, dass das alles nur eine Frage eines einzigen omnipotenten Layouts ist - ohne irgendwo einen Kompromiss eingehen zu müssen. Ich glaube eher, da muss man schon ein wenig mehr programmieren oder zumindest (in Hinsicht auf CMSms) mit Smarty-Logik arbeiten.

Das Problem ist allerdings, dass man serverseitig nur sehr bedingt alles für die Ausgabe vorbereiten kann. Man kann sich dabei natürlich auf den User-Agent stützen, aber ob man dadurch 100%ig weiß welches Gerät mit welchen Fähigkeiten tatsächlich dahinter steckt, ist fraglich. Ich glaube, ohne irgendeinen Kompromiss geht das garnicht zu machen. Sei es in optischer Hinsicht oder in Sachen Speed. Man kann meiner Meinung höchstens einen Mittelweg finden, mit dem dann vielleicht 70-80% zufrieden sein werden.

Was man alles auf Client-Seite tun könnte ... da kann man mit Sicherheit noch einige Techniken mehr einsetzen, die in einem einzigen Layout für alle Geräte verwendet werden können. (Javascript, App-Cache, Ajax - allerdings braucht man dazu auf dem Server auch wieder die entsprechenden Schnittstellen) Aber dafür ist gerade zu schönes Wetter als dass ich mir an einem sonnigen Sonntag noch mehr Gedanken darüber machen will wink

Interessant ist diese Frage nach einer Technik mit der man so einfach wie möglich so viel wie möglich abdecken kann allemal.

faglork · 05. September 2011 10:18

Moin!

piratos schrieb:

Man müsste also ein Konzept finden bei dem das alles vernünftig gesteuert werden kann.

Das trifft sich ja gut. Ich hatte doch tatsächlich vor, heute hier im Forum anzufragen ob jemand Lust hat auf so ne Art "task force" ... :-)

Ich bekomme immer mehr Anfragen von Kunden die nach einer "App" fragen. Meine Antwort: Meist nicht sinnvoll, wenn man eh nur die gleichen Inhalte wie auf der Website reinpacken will. Da ist ne Web-App die bessere Lösung.

In dieser Richtung muss tatsächlich etwas passieren, allerdings werde ich das alleine wohl nicht hinbekommen.

Die grundsätzlichen Überlegungen wurden ja schon genannt.

Was mir vorschwebt ist die Entwicklung eines Moduls o.ä. welches an mobile Endgeräte angepasste Seiten ausliefert bzw. eine sogenannte Web-App bereitstellt.

Für Wordpress zb. gibt es sowas ähnliches:
http://wordpress.org/extend/plugins/wptouch/

Die Basis sollte HTML5 sein:
http://diveintohtml5.org/
http://net.tutsplus.com/tutorials/html- … -be-using/

Für Videos brauchts ne HTML5-Lösung mit Flash-Fallback. Gibts aber AFAIK.

Was die Auflösungen angeht: da bietet CSS3 mit @media einen Ansatz, etwa

Hier klicken, um den Code zum Kopieren zu markieren

/* --- iPad Portrait --- */ @media screen and (max-width: 880px) {zoink: blafasel;}

Mit anderen Worten - man kann an unterschiedliche Auflösungen unterschiedliches CSS ausliefern.
Hab ich schon im Test, sieht IMO vielversprechend aus.

Zum Thema Web-App:
http://sixrevisions.com/web-development … phone-app/
http://www.whatwg.org/specs/web-apps/cu … fline.html

So, DAS ALLES jetzt in ein möglichst flexibles Standard-Layout sowie ein schönes, einfach zu konfigurierendes Modul (mit sinnvollen Default-Einstellungen) gepackt und wir hätten ein echtes "Killer-Modul".

Macht jemand mit?

Servus,
Alex

Beitrag geändert von faglork (05. September 2011 10:20)

nockenfell · 05. September 2011 10:55

Es gibt hier bereits was:
http://dev.cmsmadesimple.org/projects/cmstouch

Für ein Ultimate Modul fehlts noch ein wenig, wäre aber mal ne gute Grundlage.

piratos · 05. September 2011 11:50

faglork schrieb:

So, DAS ALLES jetzt in ein möglichst flexibles Standard-Layout sowie ein schönes, einfach zu konfigurierendes Modul (mit sinnvollen Default-Einstellungen) gepackt und wir hätten ein echtes "Killer-Modul".

Ich freu mich das dieses Thema als ein wirklich wichtiges erkannt wird .
In der Tat kann es auch für das Überleben eines ganzen Titels entscheidend sein.

Aber - darauf möchte ich nochmals hinweisen - die angepasste Auslieferung von Inhalten ist eine Sache, der Erfolg im Einzelfall ist bei den Mobilen ganz besonders auch eine Sache wie man den Powerverlust Desktop vs. mobile Einheiten ausgleicht. Die sind nun mal 3..10 mal langsamer als Desktops, was an der minderen Prozessorleistung aber auch an den wesentlich aufwendigeren Wegen der Request - Übertragung liegt.

Volleinsatz der bekannten Pagespeedmethoden ist angesagt wie auch Volleinsatz der weniger bekannten und das erfordert in einigen Core - Bereichen Eingriffe z.B. verfeinerte Cachingmethoden, Xajax - Schnittstelle.

Diesen Bereich darf man nicht aus den Augen verlieren.

NaN · 06. September 2011 10:01

Volleinsatz der bekannten Pagespeedmethoden ist angesagt wie auch Volleinsatz der weniger bekannten und das erfordert in einigen Core - Bereichen Eingriffe z.B. verfeinerte Cachingmethoden, Xajax - Schnittstelle.

Da hätte ich mal noch eine Idee, die mancheiner vielleicht schon gesehen oder gar angewendet hat: "Lazy Loading". Aber diesmal nicht für irgendwelche Scripte, sondern für den Content.

Ich kann zwar alles (Stylesheets, Javascript und Bilder) direkt ins HTML Gerüst packen um die Requests zu minimieren, aber dann kommt mitunter ein riesen Batzen Info durch die dünne Leitung mobiler Geräte. Das Einsparen der einzelnen Requests alleine wird da nichts bzw. nicht das beste Ergebnis bringen. Bei DSL Verbindungen macht das warscheinlich nicht so viel aus, ob da 500kB in 4 Requests oder mit einem einzigen ausgeliefert werden, aber bei mobilen Geräten schon eher. D.h. sowohl die 4 Requests (die alles extrem langsam machen würden) als auch der ganze Batzen auf einmal (der aufgrund der dünnen Leitung eben nicht in einer Sekunde da sein kann), würden hier zu keinem optimalen Ergebnis führen.

Wenn man den Inhalt allerdings in einzelne Blöcke aufteilen könnte, von denen jeweils nur die geladen werden, die gerade sichtbar sind (z.B. mit Xajax & Co. z.B. in Abhängigkeit von der Position des Scrollbars), könnte man die Datenmenge und somit die Zeit bis zur ersten Reaktion auf dem Display noch mehr verkürzen. Gerade bei Mobilen Geräten stelle ich mir das recht praktisch vor. D.h. es wird erstmal nur ein Grundgerüst geladen (ein "Framework") und die Inhalte kommen dann erst nach und nach. Und zwar NUR die Inhalte. Nichts anderes. Die Blöcke könnte man dann evtl. auch wieder im AppCache ablegen, sodass man nicht die gesamte Seite cached, sondern selektiv einzelne Teile. (Man weiß ja selber, welche Teile sich häufig ändern und welche nicht)

Man könnte darüber hinaus, was einige Browser bereits nativ anbieten, im Vorraus laden und ebenfalls cachen. Rufe ich eine Seite auf, wird der Rest der Seite noch während ich lese heruntergeladen und im AppCache gespeichert.

Diese Ideen und Techniken sind alle nicht neu. Daher wundert es mich regelrecht, dass man sowas nicht häufiger im Web antrifft.

Forum für CMS/made simple

#1 03. September 2011 11:23

Design im Umbruch

#2 03. September 2011 17:16

Re: Design im Umbruch

#3 03. September 2011 17:43

Re: Design im Umbruch

#4 03. September 2011 19:43

Re: Design im Umbruch

#5 03. September 2011 19:57

Re: Design im Umbruch

#6 03. September 2011 20:05

Re: Design im Umbruch

#7 03. September 2011 20:12

Re: Design im Umbruch

#8 03. September 2011 20:17

Re: Design im Umbruch

#9 03. September 2011 20:41

Re: Design im Umbruch

#10 03. September 2011 20:49

Re: Design im Umbruch

#11 03. September 2011 21:14

Re: Design im Umbruch

#12 03. September 2011 21:21

Re: Design im Umbruch

#13 03. September 2011 21:23

Re: Design im Umbruch

#14 03. September 2011 21:34

Re: Design im Umbruch

#15 03. September 2011 21:49

Re: Design im Umbruch

#16 04. September 2011 22:10

Re: Design im Umbruch

#17 04. September 2011 22:13

Re: Design im Umbruch

#18 04. September 2011 22:46

Re: Design im Umbruch

#19 04. September 2011 10:31

Re: Design im Umbruch

#20 04. September 2011 12:02

Re: Design im Umbruch

#21 04. September 2011 14:16

Re: Design im Umbruch

#22 05. September 2011 10:18

Re: Design im Umbruch

#23 05. September 2011 10:55

Re: Design im Umbruch

#24 05. September 2011 11:50

Re: Design im Umbruch

#25 06. September 2011 10:01

Re: Design im Umbruch

Fußzeile des Forums