18. Juni 2009
Fast auf den Tag genau vor einem Jahr habe ich bei Dr. Web und im Smashing Magazine einen längeren Essay über “Flexible Layouts als die Herausforderung der Zukunft” veröffentlicht.
Schon damals – lange bevor mit dem IE8 und dem Safari 4 die letzten beiden Browsergrößen auf den Seitenzoom-Zug aufsprungen – war ich der Meinung, dass die von Opera 9 und Firefox 3 eingeführte Technik nicht das Allheilmittel für die zahlreichen Limitierungen pixelbasierter Layouts, bzw. der Sargnagel für flexible Layouts sein wird und hatte dies in den beiden Artikeln mit der immer weiter aufklaffenden Schere von Bildschirmauflösungen und der verstärkten Nutzung von Smartphones und Netbooks begründet. Seinerzeit entbrannte eine heiße Diskussion, danach war aber eigentlich die Luft raus und kaum jemand widmete sich mehr diesem Thema.
Umso erstaunter war ich heute über drei aktuelle, englischsprachige Beiträge (Danke Angar, für den Hinweis), die sich erneut dem Thema widmen und weitere gute Argumente für elastische und fluide (oder allg. flexible) Layouts liefern.
- Page zoom does not mean the end of flexibility [456bereastreet.com]
- Why browser zoom shouldn’t kill flexible layouts [zomigi.com]
- Zoomfusion [Adactio]
Der Beitrag auf 456bereastreet.com bringt ein sehr interessantes Argument: die Mehrsprachigkeit. Allein aufgrund der Sprache, in der Inhalte ausgegeben werden, verändert sich die Textmenge, bzw. deren Platzbedarf. Flexible Layouts können sich hier deutlich besser anpassen als fixe Konstrukte. Der Beitrag von Zoe Mickley Gillenwater geht noch deutlich tiefer ins Detail und bringt sechs weitere, gut durchdachte Argumente pro elastischem bzw. flexiblen Layout. Besonders interessant dabei ist der Punkt “Preserve design proportions”. Genau dies wird aktuell sehr gern als Grund angeführt, warum elastische Layouts in Zeiten eines funktionierenden Seitenzooms praktisch keine Relevanz mehr hätten (noch dazu, da sie sehr aufwändig in der Erstellung seien). Das überzeugende Argument pro elastischem Layout ist wieder einmal der User mit seiner Möglichkeit, die Standardschriftgröße seines Browsers/Betriebssystems beliebig nach oben oder unten anzupassen. Ein fixes Layout - Seitenzoom hin oder her - kann sich derartigen Gegebenheiten nicht anpassen, die Laufweiten der Texte ändern sich zwangsläufig und die schönste Typografie kann den Bach runter gehen.
Ich möchte hier nicht alle Punkte wiederholen. Die Beiträge sind hervorragend geschrieben, also lest selbst. Der sehr schön formulierten Zusammenfassung von Zoe Mickley Gillenwater schließe ich mich hiermit aus ganzem Herzen an.
Again, I have to stress that zooming is a great function for browsers to include. Also, fixed-width layouts are not evil—they are ideal in certain situations. But liquid and elastic layouts have a lot of benefits that fixed-width layouts in combination with browser zoom can’t necessarily match. ... Don’t use browser zooming as a reason to stop—or never start—making flexible layouts.
“Why browser zoom shouldn’t kill flexible layouts”, Zoe Mickley Gillenwater
Donnerstag, 18.06.09 (23:32 Uhr)
Danke für den Artikel, Dirk.
Muß gestehen, ich versteh die ganze Diskussion nicht. Und auch nicht, dass der Browserzoom nun als Argument pro schlechtes Webdesign herhält. Wer einmal die absoluten Vorteile elastischer Layout begriffen und umgesetzt hat, wird es nicht mehr missen wollen. Ich sehe den Trend eindeutig in Richtung flexibler und elastischer Layouts gehend, auch wenn einige Leute immer noch fast zwanghaft für fixe; pixelbasierte Layouts plädieren.
Ist es Unfähigkeit, neue Wege zu beschreiten oder dazu zu lernen? Keine Ahnung. Übrigens zieht das Argument, das elastische Layouts sehr aufwändig in der Erstellung sind definitiv nicht. Sind sie nämlich nicht. Wenn man einmal umgedacht hat, ist es ebenso leicht ein flexibles wie ein fixes Layout zu erstellen.
Freitag, 19.06.09 (08:04 Uhr)
Im Übrigen ist das Buch von Zoe Gillenwater eine gute Einführung für Designer und Entwickler zu diesem Thema. Zoe war jahrelang aktive Moderatorin und Mentorin von css-discuss und kann mit umfassendem Background die Sache gut erklären.
Freitag, 19.06.09 (10:10 Uhr)
Die beiden meistgenutzten Browser IE und FF bieten in ihren aktuellen Versionen die Auswahl, ob man nur den Text oder die gesamte Seite zoomen möchte. Mit einem elastischen Layout nehme ich dem Besucher diese freie Wahl, denn ein elastisches Layout verhält sich bei Textzoom genauso wie bei Seitenzoom.
Deshalb sehe ich zu 100% elastische Layouts als eine Technik von gestern. Wer heute noch elastische Layouts erstellt ist von gestern und nicht bereit dazuzulernen ;-)
Das betrifft natürlich nicht die wirklich flexiblen liquiden oder fluiden Layouts.
Elastische Layouts waren nach meiner Auffassung nie “flexibel”, sondern “auf die Spitze getriebene fixe Layouts”. Heute sind sie “Seitenzoom für alte Browser”. Ich verstehe überhaupt nicht, wie Leute, die gegen den Seitenzoom wettern, elastische Layouts basteln können.
Vielleicht wettern sie gegen den Seitenzoom, weil sie mühsam etwas gelernt haben, was nun nicht mehr gebraucht wird.
Ein Hinweis zur Möglichkeit, dass der Besucher die Standard-Schriftgrösse seines Browsers oder gar seines Betriebssystems verstellt haben könnte:
Wenn ich alle Möglichkeiten meines Browsers und meines Betriebssystems ausreize, bekomme ich JEDES Layout zerschossen.
Freitag, 19.06.09 (10:36 Uhr)
Mal ein Kommentar aus Anwendersicht.
Ich bin kurzsichtig und benötige auf vielen Seiten einen Zoom. Den Browser-Zoom, der die ganze Seite zoomt, habe ich standardmäßig aber deaktiviert und Browser, die nur diesen bieten, verwende ich prinzipiell nicht. Warum? Weil ich es absolut nicht haben kann, wenn ich beim Lesen waagrecht zoomen muss. Das ist definitiv schlechte Usability. Die Breite der Seite muss maximal auf die Fensterbreite beschränkt bleiben und der Text beim Zoomen neu umbrechen und nach unten rutschen, sonst wird das Lesen zur Zumutung.
Durch die Verwendung von passenden Browsern (Firefox mit deaktiviertem Browserzoom oder Safari) ist das bei normalen Seiten mit fixen Breiten problemlos möglich. (Opera und IE scheiden natürlich aus.) Seiten mit statischen Breiten sind deshalb aus meiner Sicht unproblematisch, auch dann, wenn sie generell Pixelmaße verwenden; moderne, vernünftige Browser setzen sich nämlich einfach drüber weg.
Das Problem tritt besonders bei flexiblen Layouts auf, die sich ausschließlich an der Grundgröße der Schrift ausrichten und die Breite nicht begrenzen. Das ist leider aus meiner Sicht die schlechteste aller Lösungen. Das bedeutet nämlich nach dem Zoomen praktisch grundsätzlich waagrechtes Scrollen, und zwar auch in den besseren Browsern.
Seit dem Redesign finde ich zum Beispiel heise.de ziemlich nervig; das alte Design war erheblich besser lesbar. Da jetzt beim Zoomen die rechte Spalte verschwindet muss ich jedesmal zum Umschalten auf eine neue News quer scrollen ... Ich bin deshalb zu einer seltsamen Kombination übergegangen: ich öffne meinen Feedreader und navigiere von da aus durch die Heise-Artikel, das geht erheblich schneller.
Bei den meisten Seiten, die sich so verhalten, mache ich mir die Mühe nicht.
Es ist eigentlich ganz einfach: nehmt Firefox, schaltet den Browserzoom ein, lehnt euch im Stuhl zurück und schaut euch eure Seiten mit 200% Zoomstufe an. Und bitte den gesamten Inhalt einer längeren Seite mal entspannt vorlesen ... Dann wiederholt das gleiche mit deaktiviertem Browserzoom.
Wie ist das Leseerlebnis? Kann man die Seite lesen, ohne endlos quer zu scrollen? Und vor allem ohne dabei die Übersicht zu verlieren und permanent nach der Anschlussstelle im Text zu suchen?
Aus meiner Sicht gibt es folgende Hierarchie:
- gut: flexible Layouts mit maximalen Breiten (z. B. Fenster)
- befriedigend: normale Layouts mit fixen Breiten
- mangelhaft: flexible Layouts ohne Breitenbegrenzung.
Freitag, 19.06.09 (11:10 Uhr)
@Peter
Danke für deinen Blickwinkel. Ich stimme Dir zu bei der Hierarchie. Ein Ergänzung muss ich aber vornehmen. Wie ich bereits in meinem damaligen Essay erläutert habe, gehören zu einem flexiblen (fluid, elastisch oder Mischformen) immer auch minimale und maximale Breiten. Wer dies nicht berücksichtigt, arbeitet – sagen wir: unsauber.
Die von Dir angesprochenen Probleme sind ja nicht prinzipbedingt. CSS kennt sehr wohl mit
min-widthundmax-widthdie notwendigen Eigenschaften und für unfähige Browser existieren Workarounds auf JavaScript-Basis. Die Probleme entstehen also infolge einer schlechten Umsetzung durch den Webdesigner. In der Wahrnehmung durch den Nutzer färben die Probleme aber gelegentlich auf das Prinzip ab, und das möchte ich an dieser Stelle vermeiden.Wenn ich - oder Zoe Gillenwater - flexible Layouts in all ihren Formen empfehlen, dann reden wir nicht von schlechtem Webdesign, sondern von einer korrekten und vollständigen Umsetzung. Und in einem solchen Fall verhält sich ein elastisches Layout beim Zoom nicht anders als ein fluides. Es skaliert bis zum Erreichen der Viewportbreite mit der Schriftgröße und stoppt dann. Die Umsetzung dieser Regeln ist alles andere als kompliziert (siehe zahlreiche Beispiele).
Dein Hinweis, dass schlechte Implementationen vom Anwender sogar als problematisch und störend empfunden werden verdeutlicht, wie wichtig gute Fachkenntnisse und Qualitätsbewusstsein (Webstandards) in diesem Bereich sind und wie sensibel Nutzer darauf reagieren.
Freitag, 19.06.09 (11:38 Uhr)
@ Peter: Du hast den Nagel auf den Kopf getroffen, auch wenn du, wie viele andere, die em-basierten elastischen Layouts bei den flexiblen Layouts einzuordnen scheinst, was ich eben anders sehe.
Ein in der Breite fixes Layout von 760 px Breite kann ich bei einem Seitenzoom von 200% auf einem widescreen mit 1680 px Breite noch sehr gut und vollständig lesen und bedienen.
Habe ich einen schmaleren Bildschirm, kann ich die “Nur Text Vergrösserung” nutzen. Wenn der Webdesigner nicht mit allzu schmalen Spalten arbeitet, hat der Text auch noch genügend Raum zum fliessen.
DAS ist flexibel, nicht die 100% em-basierten elastischen Layouts, die eine “Nur Text Vergrösserung” verhindern.
Oder eben konsquent flexibel mit einem gut gemachten liquid (fluid) Layout.
Samstag, 20.06.09 (04:27 Uhr)
Die Internationalisierung – sprich ob ein Text nun 10 Zeilen mehr oder weniger Platz in einem Layout braucht – finde ich als Argument ziemlich gesucht. Flexible Layouts passen sich schliesslich nicht der Textmenge, sondern dem Viewport oder dem Zoomfaktor an. Ergo sind grössere Texte (und dabei dürfte es sich auch bei ausgefallenen Sprachen um höchstens 20% +/- handeln) in einem flexiblem wie fixen Layout ein und dasselbe: schlicht und einfach etwas länger oder etwas kürzer. Nicht mehr und nicht weniger. Ich möchte hier nicht die fixen Layouts verteidigen, aber die Argumentation muss für mich dann doch etwas stichhaltiger sein. Die stetig zunehmende Grösse der Bildschirmauflösung ist in der Tat ein Problem. Aus meiner Sicht jedoch nicht das von fixen Layouts. Ich finde die Aufgabe des Webdesigners ist es nicht von 800x600 bis Full-HD grundsätzlich möglichst den ganzen Bildschirm zu füllen, sondern einen optimalen Lesekomfort – sprich Worte pro Zeile – zu liefern. Alles andere können moderne Browser entweder über Text-Zoom (Grösse des Textes bei verändertem Umbruch) oder Seiten-Zoom (Grösse der Darstellung mit gleichbleibendem Textumbruch) meiner Meinung nach genügend abdecken.
Sonntag, 28.06.09 (00:56 Uhr)
Hi!
Wie geht es denn euch so, nutzt ihr die Browser-Zoom Fähigkeit eigentlich?
Ich für meinen Teil erhöhe im Normalfall höchstens den Schriftgrad ein wenig, aber ich hab noch nie eine Website größer “gezoomt”.
Gibt es irgendwelche Umfragen, Studien, Erkenntnisse ob und wenn ja wie oft dieser Zoom so allgemein verwendet wird? Kann ja gut sein, dass dieses Feature vom Markt nicht angenommen wird.
Gruß
Sonntag, 28.06.09 (09:51 Uhr)
Hallo Christian, ich denke der normale Besucher nimmt das, was voreingestellt ist oder auf der Browseroberfläche verfügbar. Die gehen nicht in die Menüs.
Beim FF ist Seitenzoom für strg + voreingestellt, beim IE ist der Seitenzoom auf der Browseroberfläche (unten rechts) und der Textzoom in den Tiefen der Menüs versteckt. Ein geschickter Schachzug der Browserhersteller, um das neue Feature unters Volk zu bringen.
Die normalen Surfer denken über sowas viel weniger nach als wir oder als wir denken, dass sie darüber nachdenken.
Sonntag, 28.06.09 (11:27 Uhr)
Hallo, GE!
Das ist sowieso unser Problem, dass wir zwar versuchen können uns in die Nutzer reinzudenken, es allerdings nie wirklich schaffen und um Tests nicht drumherum kommen.
Mir ist dazu kein Statistik-Programm für Websites bekannt, dass Browser-Zoom merkt, aufzeichnet und auswertet. Gibt es sowas?
Gruß
Christian
Sonntag, 28.06.09 (14:00 Uhr)
Hi CSS-Bastler ;) Ich finde Frameworks generell nicht schlecht, wenn es um Programmierung geht - jedoch nicht bei CSS-Layouts. CSS-Frameworks finde ich leicht überzogen. Ein vernünftiges, von Hand ‘gezimmertertes’ CSS, welche die meissten Bugs der Browser berücksichtigt finde ich wesentlich flexibler. Frameworks lösen das eigentliche CSS unnötig in unüberschaubare Module auf und kosten Zeit und Nerven, wenn Änderungen anstehen.. Klar, wer sucht, der findet… ;) Ich hab Yaml versucht und mir ist einfach die Zeit zu schade, in zig Dateien Anpassungen vornehmen zu müssen. Ein selbstgeschriebenes CSS ist übersichtlich und WIRLICH flexibel - denn man weiss, wo man was findet. Ich habe ein Projekt aufgebaut und probehalber für drei Monate online gestellt (2007). 150.000 Seitenaufrufe in den drei Monaten und nur Lob geerntet… Das Layout bestand aus einer einzigen CSS-Datei (mit Berücksichtigung der meissten Browser-Bugs) und die User waren begeistert. Es geht also auch ohne Frameworks.
Zu Christian: Ich gebe Dir Recht. User kommen auf eine Seite und ‘nehmen sie erstmal so auf’ wie sie sie vorfinden. 99 % werden keine oder kaum Änderungen an der Darstellung vornehmen, wenn es nicht notwendig ist.
Zu GE:
Dies meissten User (ich meine hier Standard-Besucher, keine Freaks) haben auch keine Lust irgendwas umzustellen im Browser, um die Seite ‘richtig’ darstellen zu lassen. Wenn die Seite gefällt, bleiben sie, ansonsten… und tschüß...
Statische Layouts - wenn sie gut lesebar, übersichtlich und leicht zu navigieren sind, haben meiner Meinung nach ihre volle Berechtigung. Ein Grund für statische Layouts sind die wachsenden Bildschirmgrößen, die die Arbeit eines jeden Webmasters (Webdesigners) zerstören können, wenn sie die Inhalte auseinanderreissen.
Solange die Browser-Entwickler nicht in der Lage sind CSS vollends umzusetzen, hat jedes statische Layout seine Daseinsberechtigung.
Krasses Winkerchern ;)
Sonntag, 28.06.09 (15:36 Uhr)
@ TOM (Nr. 11)
Wer die “meissten” konsequent mit -ss- schreibt und bei YAML “in zig Dateien” Anpassungen vornehmen muss, der hat das Prinzip von YAML nicht richtig verstanden und dem bleibt dann u. U. nichts anderes übrig, als ein “von Hand ‘gezimmertertes’ CSS” einzusetzen.
SCNR, aber nichts für ungut.
Klaus
Sonntag, 28.06.09 (20:57 Uhr)
@ Klaus (12)
Ich bitte um Entschuldigung dafür, dass ich nur… ein Mensch bin und somit nicht unfehlbar. Allerdings ändert Kritik in dieser Form nicht unbedingt meine Meinung ;)
Sonntag, 28.06.09 (22:00 Uhr)
@ TOM (11/13)
> Ich bitte um Entschuldigung dafür, dass ich nur… ein Mensch bin und somit nicht
> unfehlbar.
Das ist jetzt ein wenig zu viel der Bescheidenheit ;-)
> Allerdings ändert Kritik in dieser Form nicht unbedingt meine Meinung ;)
Meine Kritik war nicht böse gemeint, aber angesichts des Eigenlobs in Nr. 11
(“150.000 Seitenaufrufe in den drei Monaten und nur Lob geerntet… Das Layout bestand aus einer einzigen CSS-Datei (mit Berücksichtigung der meissten Browser-Bugs) und die User waren begeistert. Es geht also auch ohne Frameworks.”)
sah ich mich zu dieser kleinen Spitze veranlasst.
Ich will Deine Meinung auch nicht ändern, da ich keinerlei missionarische Ambitionen verspüre, aber es musste halt mal raus, weil man doch häufig bei Leuten, die über bzw. gegen YAML schreiben, merkt, dass sie sich nicht genügend damit beschäftigt haben und daher einige ihrer Negativ-Argumente einfach nicht stichhaltig sind.
Dass man auch ohne YAML oder vergleichbare Frameworks tolle Seiten bauen kann,
steht m. E. außer Frage.
Noch einmal: nichts für ungut und einen schönen Sonntagabend!
Klaus
Sonntag, 28.06.09 (23:40 Uhr)
Ich achte schon lange darauf, dass Seiten nicht nur in verschiedenen Browsern, sondern auch mit verschiedenen Schriftgrößen optimal dargestellt sind.
Aus meiner Sicht haben daher die Hacks, mit welchem man per CSS und JavaScript die Funktionalität auf den Webseiten anbietet, ausgedient. Solche Funktionen sollten aus meiner Sicht dem Browser vorbehalten bleiben.
Evtl. könnte man noch so eine Art “Gütesiegel” einführen, da eine optimale Darstellung bei Vergrößerung der Seiteninhalte doch in einer gewissen Weise eine richtige Einstellung zur Barrierefreiheit darstellt, oder?
Sonntag, 28.06.09 (23:45 Uhr)
@Hahnefeld
Hi!
Wohin soll denn das Gütesiegel? Auf den Browser? In die Website?
Ich finde es schon lächerlich, wenn Leute nach dem Motto: “schaut mal wie toll ich bin, ich schaffe validen Code” mit dem W3C-Buttons umsichwerfen. Das ist für mich einfach eine Selbstverständlichkeit. Autohersteller pappen auch keine Sticker drauf “unsere Bremsen bringen sie zum stehen”... ;)
Ein Website muss einfach unter Stress bestehen. Sie muss Browser, Betriebssysteme, Schriftgrößen, Sichtfenstergrößen, kein CSS, keine Grafiken usw. standhalten, dafür brauche ich doch kein Siegel?
Gegen einen Preis/Award für verschiedene Kategorien habe ich nichts, aber ein Gütesiegel im Web. Ne, muss nicht sein.
Gruß
Montag, 29.06.09 (21:52 Uhr)
Die Darstellung funktioniert doch grundsätzlich. Wenn auch im Quirks-Modus… Doch ich würde es - um bei deinem Beispiel mit den Bremsen zu bleiben - eher wie Hersteller- und Dritthersteller-Qualität sehen. Und genau dafür gibt es die Siegel. Denn auch bei Bremsen ist nicht der Bremsbelag immer gleich haltbar oder von gleicher Qualtität. Dass der Zweck des Bremsens erfüllt ist, wird erwartet. Doch das tut auch eine Frame-Basierte Seite, die in FrontPage erstellt wurde. Ist diese aber barrierearm oder investitionssicher?
Mittwoch, 08.07.09 (19:35 Uhr)
Sag ich schon lange :)
Ich bin 52 nd habe irgendeinen Augenschaden: Ich sehe nicht mehr besonders gut. Also bin ich angewiesen auf relativ große Schriften (22px). Damit trotzdem noch was auf die Seite passt, habe ich mir extra einen schön großen Monitor angeschafft.
Ich erwarte von einer guten Webseite, dass ich sie aufmache, und sofort nutzen kann. Und zwar, ohne dass es auffällt, dass ich einen zu großen Monitor habe. Schließlich ist er für mich nicht zu groß. Nur für die Vorstellungskraft des Designers. Für mich ist der Bildschirm genau passend.
Ebenso erwarte ich, dass eine Webseite auch dann noch gut nutzbar ist und gut aussieht, wenn ich eine Sidebar offen habe (z.Zt. z.B. oft Sage, ein rss Feedreader als Extension für Firefox). Eine Seite, bei der ich dann anfange muss, wie wild herumzuscrollen, ist nicht so besonders doll. Und wenn ich die Seite wegen zu kleiner Schriften auf 150% zoomen muss, dann muss ich selbst auf dieser Seite hier anfangen, horizontal zu scrollen, wenn ich die Sidebar offen habe. Hier hilft mir der Seitenzoom also nur bedingt weiter.
Momentan bin ich am experimentieren (bei meiner eigenen Seite), die Schriftgröße per media queries an die viewport Größe anzupassen. Funktioniert im FF 3.5 recht gut. Aber ich bin mir nicht sicher, ob das eine gute Idee ist. Schließlich sollten die Einstellungen, die der User vorgenommen hat, das Maß der Dinge sein. Nicht immer ist Etwas gut und wünschenswert, nur, weil es technisch machbar ist. Naja, andererseits kann man auch mal experimentieren und eine Zeit lang beobachten. Man muss solche Entscheidungen ja nicht über’s Knie brechen.