nicht angemeldet Mathias Schäfer (molily)
Mathias Schäfer (molily)
Mathias Schäfer (molily)
Struppi
Mathias Schäfer (molily)
Empirische Untersuchungen widerlegen die Standard-Layout-Breiten (aktualisiert)
800 × 600 Pixel gilt seit etlichen Jahren als Auflösung, für die eine Website »optimiert« wird. Das heißt in der Regel: Das Layout wird ungefähr auf eine Breite von 780 Pixeln festgezurrt, darunter werden horizontale Bildlaufleisten angezeigt. Das Ganze wird dann zentriert oder links angeordnet. Der möglicherweise entstehende freie Platz bleibt entweder frei oder wird vereinzelt durch auftauchende Werbebanner aufgefüllt. Zunehmend wird auch für 1024 × 768 Pixel »optimiert«, die magische Grenze liegt dann etwa bei 990 Pixeln.
Nun gibt es verstärkt fließende und elastische Layouts oder auch Götterspeisen-Layouts als Alternativen zu festen Layouts. Mithilfe von JavaScript sind noch mehr anpassbare Alternativen denkbar. Björn Seibert nennt einige prominente Beispiele.
Trotz dieser Möglichkeiten, ein Layout in verschiedener Hinsicht anpassungsfähig zu gestalten, ist die Mehrheit aller Websites nach wie vor für eine Auflösung »optimiert«. Das liegt in den seltensten Fällen daran, dass das Design stark mit Pixelgrafiken arbeitet, die eine Flexibilität einschränken. Anwender mit höheren Bildschirmauflösungen bekommen daher oft winzige Sites zu Gesicht, die nur einen Teil des Bildschirms ausfüllen. Die Schriftgröße passt sich selbstverständlich auch nicht der größeren Auflösung an. Im Endeffekt haben wir also ein auf 800 × 600 Pixel »optimiertes« Web. Dieser (vermeintliche) kleinste gemeinsame Nenner hemmt die Vielfalt der Layouts. Der Wechsel auf 1024 × 768 ändert dabei nichts grundlegendes, sondern läutet nur die nächste Phase des Optimierungswahns ein.
Zunächst einmal muss festgestellt werden, dass die Bildschirmauflösung nicht entscheidend ist. Auch die Browserfenstergröße ist für die Website nachrangig. Vielmehr ist die Breite des Bereiches wichtig, die der Website tatsächlich zur Verfügung steht. Der Fachbegriff für diesen Bereich ist Viewport. Thomas Lahn hat diese grundsätzlichen Erkenntnisse einmal auf die Formel gebracht:
Auflösung != Desktopgrösse != Browserfenstergrösse != Anzeigebereich. [psf 3.7]
Zahlreiche Counter und Tracker fragen mittels JavaScript die Bildschirmauflösung ab, sodass der Webautor eine schöne, bunte Statistik über die verwendeten Auflösungen bekommt. Diese Statistiken dienen dann als Killerargumente dafür, dass man eine bestimmte Auflösung nicht mehr berücksichtigen muss und dass man getrost für eine bestimmte Auflösung »optimieren« kann.
Interessant für Design-Entscheidungen ist hingegen eher die Viewport-Breite sowie ihr Verhältnis zur Auflösung. Die wenigsten Statistik-Scripte vermessen den Viewport. Unter diesen wenigen ist Mint, siehe Beispielstatistiken.
Hier im SELFHTML-Weblog habe ich eine ähnliche Statistik installiert, die mit JavaScript die Viewport-Breite sowie die Bildschirmauflösung untersucht und im Hintergrund zum Server übertragt, wo sie in einer Datenbank gespeichert wird. Dazu benutze ich diesen einfachen Scriptschnipsel von Peter-Paul Koch. Das komplette Script »spioniert« zudem noch einige andere Javascript-Eigenschaften aus, vor allem zu Studienzwecken.
Sicher ist dieses Weblog in keinster Weise repräsentativ, wird es doch vornehmlich von Technik-affinen Webbastlern frequentiert. Da ich hier sowieso als Alternative zur wenig aussagekräftigen Webalizer-Statistik eine JavaScript-Statistik etabliere wollte, bot sich erst einmal dieses Studienobjekt an. Zuerst begann ich damit, die Viewport-Größe aufzuzeichnen, später auch die Auflösung. Da das Layout dieses Weblogs im Allgemeinen bei verschiedenen Viewport-Breiten passabel aussieht, gehe ich davon aus, dass die Ergebnisse nicht durch an unsere Site angepasste Viewport-Breiten verfälscht wird.
Vorab, welche Auflösungen sind verbreitet, wenn wir der Eigenschaft screen.width Glauben schenken?
Zeitraum: 2006-04-01 bis 2006-10-30. Gezählte »Besucher«: 87155. Ein »Besucher« ist definiert als eine eindeutige Kombination aus IP-Adresse und HTTP-User-Agent.
Eine Auflösungsbreite von 800 Pixeln scheint hier demnach nahezu überhaupt nicht mehr verbreitet.
Interessant wird nun die Viewport-Statistik. Anstatt ein Verteilungsdiagramm zu zeichnen, bin ich folgendermaßen vorgegangen: Ich habe eine kumulative Statistik erstellt, in der zu einer bestimmten Breite zu sehen ist, wieviel Prozent aller »Besucher« einen Viewport haben, in den diese Breite hineinpasst. Auf diese Weise sieht man, wieviel Prozent der »Besucher« bei einer bestimmten Breite noch mithalten können beziehungsweise bei wieviel Prozent eine geringere Viewport-Breite gemessen wurde.
Zeitraum: 2006-02-25 bis 2006-10-30. Gezählte »Besucher«: 69375
In einem weiteren Diagramm habe ich den interessanten Ausschnitt vergrößert dargestellt:
Diese Diagramme sind so zu lesen: 80,6 Prozent aller »Besucher« haben eine Viewport-Breite größer als 1000 Pixel, hingegen nur 50,1 Prozent einen Viewport größer als 1040 Pixel.
Diese Statistik ist für mich erstaunlich, denn sie bestätigt viele Vermutungen. Obwohl eine Auflösungsbreite von 1024 und höher klar dominiert, gehen auf dem Weg von 780 Pixel bis 1000 Pixel Viewport-Breite 16 Prozent der »Besucher« verloren. Dann kommt der starke Abfall, der durch die Auflösungsbreite bedingt ist (ca. 30 Prozent). Diese Kurve legt die Vermutung nahe, dass viele Browserfenster nicht maximiert sind bzw. innerhalb des Browserfensters noch andere Elemente in der Horizontalen Raum einnehmen. Vermutlich sind ICQ, Skype und ähnliche Programme, die ständig als Leiste links oder rechts sichtbar sind, für eingeengte Browserfenster verantwortlich. Und einige Anwender ziehen das Browserfenster absichtlich nicht größer. Was die angenommene Differenz von Browserfensterbreite und Viewport-Breite angeht, so sind vermutlich geöffnete Sidebars verantwortlich, über die fast alle Browser verfügen. Insbesondere Opera stellt darin alle möglichen Browserfunktionen dar.
Während die beiden vorigen Diagramme die Viewport-Breite bei allen Auflösungen berücksichtigten, habe ich weitere Diagramme erstellt, die die Viewport-Breite bei den verbreitesten Auflösungen zeigen, jeweils gleichsam kumulativ. Dieser Vergleich ist etwas heikel, da ich wie gesagt nur von einer recht kleinen Messbasis hinsichtlich der Auflösungsbreite ausgehen kann.
Zeitraum jeweils 2006-02-25 bis 2006-10-30. Messbasis: 1169 »Besucher« bei 800 Pixel, 29042 »Besucher« bei 1024 Pixel und 39894 »Besucher« bei 1280 Pixel.
In diesen Diagrammen zeigt sich, dass von der Auflösung keinesfalls auf eine Standard-Viewport-Breite geschlossen werden kann. Wenn man für die Auflösungsbreite 1024 Pixel »optimiert« und von einer Viewport-Breite von 980 Pixeln ausgeht, so »erreicht« man tatsächlich weniger als 80 Prozent aller Besucher mit dieser Auflösung. Noch eklatanter ist es bei der Auflösungsbreite von 1280 Pixeln. Hier gelten die oben geäußerten Vermutungen ganz besonders: Das Browserfenster füllt den Bildschirm nicht aus, zudem füllt der Viewport nicht das Browserfenster aus. Mit größerer Auflösung steht Websites also keinesfalls mehr Raum zur Verfügung. Für 1280 Pixel »optimieren« wäre widersinnig, denn würde man die hinzu gewonnene Breite nutzen, so würde man die Besucher dazu zwingen, den Viewport zu vergrößern.
In meinen Messungen und Auswertungen sind viele Faktoren nicht berücksichtigt. Nicht zuletzt schließe ich methodische Fehler meinerseits nicht aus.
Der Schluss, dass eine bestimmte feste Layout-Breite einen gewissen Prozentsatz der Besucher »ausschließt«, ist sicher nicht möglich. Die gemessenen Viewport-Breiten lassen nur Hypothesen darüber zu, was für die Differenz zwischen Auflösung und Viewport verantwortlich ist. Browser-Sidebars können problemlos eingeklappt werden und Browserfenster meist auch maximiert werden, wenn die Website dies erfordert und der Besuche die Site in ihrer Gänze betrachten will. Er wird lediglich dazu gezwungen, den Viewport anzupassen. Mein SELFHTML-Kollege Roland Skop schlägt daher vor, zu messen, ob viele Leute die Fenstergröße nach dem Laden der Website ändern. Interessant wären dann die Ausgangs- und die Endbreite. Dies wäre mit einigem Aufwand messbar, wenngleich auch nicht sehr zuverlässig.
Dieser Bericht ist bewusst voreilig, denn ich habe nur Daten in diesem wenig relevanten fachlichen Weblog gesammelt. Ich werde meine Untersuchungen fortführen und ausweiten. Dieser Artikel wird entsprechend aktualisiert. Daher bitte ich darum, Fehlerkorrekturen per E-Mail einzureichen und dazu nicht die Kommentarfunktion zu nutzen.
Alle obigen Diagramme liegen samt Werte-Tabellen als OpenOffice-Calc-Dateien vor:
Die PHP-Scripte, mit denen ich die Auswertung vorgenommen habe, stelle ich gerne auf Wunsch zur Verfügung. Leider bin ich bisher noch nicht dazu gekommen, ein einfaches Download-Zip mit Scripten für PHP/MySQL zusammenzustellen.
Hallo Mathias,
es wäre schon interessant zu wissen mit welchen Auflösungen die Leute unterwegs sind und noch viel interessanter wäre zu wissen, wie du es schon erwähnt hast, ob, wie oft und wann ein Nutzer den Viewport ändert.
Aber eines darf man nicht vergessen, wie übrigens bei Diskussionen um die Verbreitung der Geckos. Das hier ist eine Stelle wo der eher technik-affine Mensch vorbeischaut. Und die haben eher den neueren Rechner, größeren Monitor und Programme die in der Seitenleiste untergebracht sind. Soweit ich aus meinen Beobachtungen gesehen habe tut der "Otto-Normal-Surfer" dies nicht.
Aber was ich sehr wichtig finde und das geht manchmal unter, ist der Hinweis deinerseits dass eine Auflösung von 800x600 nicht heisst, dass man auch 800px zur Verfügung hat. Je nach System und Browser kann das variieren. Auf meinem System gehen der SeaMonkey und IE 6 bis 772px, ab 773px kommt der horizontale Scrollbalken zum Vorschein. Bei den anderen Auflösungen ist es ähnlich.
Zum Thema "ein auf 800 × 600 Pixel »optimiertes« Web", fluide Layouts und Zeilenlänge:
was mir sehr oft als unangenehm auffällt ist die Tatsache, dass sehr viele Websites einfach unleserlich werden, weil sich der Text zu stark ausbreitet. Beispiel dafür sind dieses Weblog hier und dein Götterspeisen-Beispiel.
Um z.B. in diesem Weblog angenehm lesen zu können muss ich die Schriftgröße verkleinern und vor allen Dingen den Viewport auf ca. 700px Breite stellen.
Ich habe für mich persönlich festgestellt, das ich am besten einen Text lesen kann bei ca. folgenden Werten: Verdana/Arial bei 12-13px und einen Zeilenlänge bzw. Text-Breite von 480-550px. Alles was breiter ist empfinde ich als nicht sonderlich leserlich.
Wenn man in den Kommentaren auf einen Fehler hinweist, wird dieser Kommentar gelöscht und der Fehler stillschweigend korrigiert. Respekt!
Entschuldigung, habe den letzten Absatz nicht gelesen!
Ich danke Dir 1. für diese Arbeit, die mir sehr nützlich ist.
Werde mich dafür in meinem Rahmen revanchieren.
Der Viewpoint ist für mich dabei das derzeit relevanteste, weil die anderen Dinge sehe ich bei all meinen Websites -das sind viele- meist in den Auswertungen.
Als Betroffene (Gleitsichtbrillenträgerin) mag ich anmerken, dass es tatsächlich absolut unmöglich ist das 'Götterspeisen Beispiel' zu lesen.
Bedauerlicherweise haben diese sogenannten superüberdrüber Layouts derzeit Hochkonjunktur und meine Favoritenliste wird immer kleiner, weil ich die einfach rausschmeiß.
Ich arbeite derzeit mit einer sehr interessanten Gruppe von Internetusern, den Silver Surfern, lehre die 'schnelle Post' und anderes und die haben eine sehr hohe Auflösung, Schriftgröße ab 150% aufwärts.
Die andere Gruppe von mir beobachtbar waren an die 600 Menschen um die 50Jahre, die haben ebenfalls mindestens 130% der Schriftgröße eingestellt.
Wien hat bereits mehr als 50% über 60jährige.... ich glaube manchmal wir klammen uns zu sehr an Auflösungen als an unsere Zielgruppe.
In Zeiten von Hartz IV oder VII werden die PDAs nicht gleich die Mehrheit werden, nehme ich mit ziemlicher Sicherheit an. ;)
Nochmals recht herzlichen Dank Monika
Perun, Monika:
Kleine Anmerkung, weil hier ein Missverständnis vorzuliegen scheint: Die verlinkte Site zum Götterspeisen-Layout ist nicht das Jello-Layout-Beispiel, sondern ein Artikel dazu, der selbst ohne Zeilenlängenbegrenzung arbeitet. Dort findet man den Verweis auf die Minimale Jello-Demo.
molily oh ! ich habe da 'ehrlich bin' nicht draufgeklickt, weil ich mir das einfach nicht immer antun wollte ;) war für mich missverständlich
'lesen geh' lg
Nur so als Hinweis:
Opera hat eine "Fit to Width" Funktion. Die rufe ich immer als erstes auf, wenn ich eine horizontale Scrollbar habe. Damit bekomme ich den meistens weg, ohne dass ich irgendwie merken wuerde, dass das Layout nicht mehr passt. Leider nicht immer, aber solche Webseiten nerven mich dann wieder so sehr, dass ich sie schnell wieder verlasse.
Meine aktuelle Viewport-Breite: 787
Aber Bildschirmaufloesung: 1280x1024
Warum? Weil mein Browser nicht die wichtigeste Applikation ist, die gerade laeuft.
twm
Hallo,
das Argument von Perun mit der zu großen Textausbreitung würde ich sofort unterschreiben. Der Gedanke der fluid Layouts ist ja generell sehr löblich, doch leider gibt es nur wenige Beispiele, die trotz variablem Layout die Leserlichkeit und Benutzerfreundlichkeit optimal beibehalten. Im Grunde spricht für mich eigentlich gar nichts gegen fixed width, optimiert für ~ 800x600. Denn auch bei sehr großen Auflösungen bleibt das Layout somit gut für das Auge erfassbar. Abgesehen davon beschweren wir uns ja auch nicht, dass ein DIN A4 Blatt nicht unseren ganzen (realen) Schreibtisch ausfüllt. Wenn das so wäre, hätten wir gewaltige Schwierigkeiten den Inhalt des Blattes auf einen Blick zu erfassen. Und das gleiche Problem sehe ich halt bei den meisten breiten Web-Layouts.
Viele Grüße, Ralf
Der angesprochene Optimierungswahn muss eigentlich nicht sein, oder? Was ändert sich zwischen einer Optimierung von 800x600 auf 1024x768? Nicht, außer zwei Zahlen. Denn letztlich wird doch wieder auf irgendeine feste Breite gezielt.
Eine artgerechte Nutzung flexibler Layouts verstehe ich als die einzig erforderliche und sinnvolle Optimierung weil gerade die Unabhängigkeit von irgendeiner Vorgabe (Mindestauflösung, Viewport, usw.) den gewünschten Fortschritt hin zu mehr Nutzungsqualität bringt.
Flexibel muss dabei nicht zwingend bedeuten, dass der Webdesigner jeden Einfluss über die Seitenbreite verliert. Der Einsatz von em muss ja nicht auf die Skalierung der Schriftgröße beschränkt bleiben. Das Focus-Remake von Eric Eggert hat es vorgemacht, in kleineren Stil habe ich Ähnliches in meinem Weblog-Layout selbst probiert. Beide Layouts haben eine quasi "fixe" Breite, skalieren jedoch auch Grafiken zusammen mit der Schriftgröße mit. Bei meinem Versuch in meinem Weblog beachtet das flexible Layout im Firefox sogar die Breite des Viewports und skaliert das Layout nicht über die Fensterbreite hinaus.
Ich finde diesen Ansatz deutlich interessanter, als über die nächst größere fixe Breite zur Optimierung unser Websites zu sprechen. Bedenkenswert ist in diesem Zusammenhang auch, dass bei der Vergrößerung auf eine 1024er Breite ein vernünftig durchdachtes Druckstylsheet immer wichtiger wird (es leider aber die wenigsten anbieten). Denn während eine auf 800x600 optimierte Seite in der Regel noch hochkant ausgedruckt werden kann, ist dies bei 1024 Pixeln vorbei.
Beste Grüße Dirk
Dirk, ich finde den Ansatz mit den mitwachsenden Bildern bei den meisten Seiten nicht praktikabel, da Bilder ja dennoch immer eine Breite in pixel haben. Dadurch weden die Bilder öfter verpixelt dargestellt, als normal. Da ist der Ansatz den Opera schon lange verfolgt und jetzt wohl auch der nächste Internet Explorer nicht nur den Text zu vergrößern, sondern einfach die komplette Seite zu »zoomen« viel vielversprechender. Immerhin kann das der Firefox mit so einem Plugin auch, somit hätten wir die drei großen Browser abgedäckt, ok der Safari bräuchte auch so etwas.
Wenn es dann so weit ist dann können wir endlich auch unsere Texte in der Größe in Pixel angeben, und sie werden nicht unsinnigerweise mitskaliert wenn man die em größe verändert. Das hätte für alle große Vorteile. Der Designer kann sein Design genauer vorherbestimmen und auch pixelgenau mit texten arbeiten und der Leser kann sich die Seite so vergrößern, dass er sie gut lesen kann, ohne dabei das Design zu zerstören. Dass das sehr gut funktionieren kann beweist Opera schon seit jahren und ich liebe diese Funktion.
Die max-width funktionalität wie du sie in YAML einsetzt, also mit JS für den IE finde ich für die heutige Zeit optimal gelöst. Das Script funktioniert auch prima.
Jeena, die Diagramme oben zeigen mir, dass es nicht unbedingt sinnvoll ist, Webseiten auf eine spezielle Auflösung zu optimieren - zumindest keine größere als 800x600. Diese hat für mich als anerkannte untere Grenze für Desktop-Auflösungen nach wie vor eine gewisse Berechtigung. Für jede größere Auflösung erreicht eine pixelbasierte "Optimierung" nach den Diagrammen des Beitrags nur noch ca. 85% der Nutzer oder sogar weniger, falls man über 1024 Pixel hinausgeht.
Der Drang hin zu größeren Auflösungen / Viewport-Breiten wird sich vermutlich weiter fortsetzen. Damit wird die Zielgruppe, für die man sein Angebot auf eine feste Pixelgröße optimiert, in Zukunft aber immer kleiner. Daher halte einen flexiblen Ansatz für sinnvoller. Die Skalierung der Bilder ist dabei als Bonus zu sehen. Die Lösung mit den skalierten Grafiken ist nicht mehr als ein Vorschlag. Letztlich zoomen Opera und IE7 die Grafiken ebenfalls (allerdings mit besserer Interpolation). Was mich diesen Zoom-Funktion jedoch stört ist, dass beide Browser die Fensterbreite ignorieren. Besonders störend wirkt sich dieser Umstand aus, wenn das Layout bereits in der Standardgröße auf 100% Viewportgröße ausgelegt ist. Hier entstehen beim Zoom von Opera und IE7 sofort horizontale Scrollbalken.
Bei neueren Web-Anwendungen oder Webseiten setze ich die Seitenbreite oft auf ca. 60em (entspricht ca. 900px), beschränke sie aber auf sowas wie 95% als Obergrenze (max-width). So passt die Seite auch mal in ein schmaleres Fenster, wird bei größeren Breiten aber nicht unlesbar. Dazu befindet sich links oft auch ein Navigationsbereich, der nochmal etwas Breite belegt. Die Webseiten auch mal kurz bei anderen Text-Zoom-Einstellungen (Firefox) zu testen, ist für mich dabei selbstverständlich.
Leider sind andere Benutzer gerade mit der Breitenbeschränkung oft nicht zufrieden. Ich frage sie dann direkt danach, wie es denn so sei, meterbreite Textzeilen zu lesen, darauf kommt aber keine Antwort mehr. Auch wenn man denkt, dem Leser mit einer begrenzten Breite was Gutes zu tun, ist er damit machmal nicht einverstanden. Allen kann man es sowieso nicht recht machen. Eine Lösung dafür sind eigentlich nur alternative Styles, die man im Browser (Firefox, andere?) auswählen kann, und die sich um solche Größenangaben unterscheiden.
Also ich bin mit 1024b x 1280h unterwegs und betreibe meinen Firefox immer im maximierten Modus. Im Kommentar hier drüber habe ich mal nachgemessen und sehe, dass eine lange Zeile 870 Pixel breit ist. Das ist mir dann für eine gute Lesbarkeit auch zu viel, obwohl Schriftgröße und Zeilendurchschuss auf dieser Seite echt OK sind.
Ich betreibe seit Anfang des Jahres eine Webseite mit der Blog/CMS-Software Textpattern (sehr empfehlenswert!) und verwende ein einspaltiges Fertiglayout wo die meisten Zeilen bei ca. 720 bis 750 Pixeln umgebrochen werden. Die fixierte Spaltenbreite beträgt 760 Pixel und ist optisch soweit ganz robust und halbwegs gut lesbar (Ich hadere da noch etwas mit der serifenlosen Schrift).
Was mir allerdings im Laufe der CMS Auswahl aufgefallen ist, dass die meisten Pakete von Haus aus keine richtig tollen und barrierefreien gut kommentierten Grundlayouts mitbringen und man deswegen als Nicht-CSS-Profi (Ich) einige Probleme hat das Ganze richtig hin zu biegen. Vom Zeitaufwand mal ganz zu schweigen.
Ich würde also von der Pixel x Pixel Optimierung oder der hier aufgeworfenen Viewport Betrachtung mal abgesehen dafür plädieren einer Blog- oder CMS-Software ein paar gute robuste und barrierefreie Layout-Lösungen mitzugeben. Einen Grund für die häufig anzutreffenden 'schlechten' Standard-Layouts sehe ich nämlich darin begründet, dass ein CSS-Laie (Ich) sein Blog installiert und halt nimmt was er kriegen kann.
Zur barrierefreien Webseite gehört für mich auch unbedingt ein Layout-Switcher, der einfach und nachvollziehbar verschiedene Schriftgrößen, Seitenbreiten und Farbkombinationen anbietet.
PS: Bei einem meiner Blogs, das für 1024 Pixel Breite optimiert ist, habe ich seit Anbeginn einen stabilen Anteil von 25% von anscheinend leidenswiligen 800 x 600 Lesern. Andererseits habe ich darauf geachtet, dass die Hauptspalte nur 720 Pixel breit ist. Die Leser scheinen also nach eimaligem Querscrollen gut auf die Sidebar verzichten zu können :-)
Ich kann nur für mich sprechen, aber ich "optimiere" auch für 800x600 und werde es auch weiterhin tun. Dynamische Layouts mögen zwar technisch möglich sein, aber zu breite Seiten und zu lange Zeilen empfinde ich als schwierig zu lesen.
Man könnte zwar damit argumentieren, dass der User selber entscheiden können sollte, wie breit die Seite wird (sprich dass er bei dynamischer Größe eben das Browserfenster auf eine angenehme Leseweite justiert), allerdings denke ich dass das für den 0815-Surfer keine realistische Option ist. Zumindest nicht solange nicht *alle* Seiten im Netz entsprechend gestaltet sind. Solange sollte man sich, finde ich, auf die "Hauptzielgruppe" oder eben die "breite Masse" der Leute einstellen.
Volle Zustimmung gebe ich allerdings dem Hinweis, dass man nicht auf 1024x768 optimieren sollte nur weil keine 800x600er-User mehr in den Stats auftauchen. Ich denke bis die Zeit kommt, dass man von 1024 Pixeln als angezeigte Breite ausgehen kann, wird noch viel passieren...
Interessant. Aber nur weil horizontale Scrollbars eingeblendet werden, schliesst man doch niemanden aus! Eben dafür sind die Scrollbars ja erfunden worden. Wir können doch nicht ewig auf einer 780er Auflösung bleiben, weil noch jemand mit seinem Apple IIe auf eine Seite surft. Die Technik entwickelt sich weiter, das Web muss es auch.
Ich empfinde den Ansatz schon recht interessant. Das auf 800x600 oder 1024x768 optimieren erinnert doch ein wenig an den Anfängen des Web wo als Startseite ein mehr oder weniger schickes Logo steht und "Diese Seite ist auf Interent Explorer, MacOS oder Netscape Explorer optimiert."
Ich meine, mensch kann mit solch schönen als auch vielseitigen Möglichkeiten arbeiten... Für eine Firma, für die ich arbeite, haben wir uns nach langem Hin und Her eher stillschweigend auf ein Tabellenbreite von etwas unter 100% mit 2 Spalten, von der eine dynamisch bleibt und die andere mit dem Text auf etwas über 50%. Die Schriftgröße wird nicht mehr mit Pixel definiert. Natürlich könnte das viel geschickter mit css und div erledigt werden... Wir haben bezüglich der Übersichtlichkeit ein Optimum für verschieden Einstellungen erreicht. Auch Andere Betriebssysteme als das von Bill Gates können angesprochen werden, die vom User selbststätige Einstellung wird auch immer aktueller.
Oft genug beobachte ich als unstudierter, dass gerade die "alten Herren vom Fach" und die unkundigen mit bestem Bildungsabschluß auf die Optimierung mit bestimmten Maßstäben beharren.
Das Ziel einer Webseite sollte ja sein: a)gefunden werden, b)unterhalten, c)informieren oder d)eine Ware und Dienstleistung anbieten. Natürlich verstehe ich diese zwanghafte optimieren an x-beliebige Seitengrößen: oft genug sind das die einzigen Fixpunkte für das erstellen einer Webseite.
Schönen Tach von Martin
Ein sehr interessanter Bericht muss ich sagen. Es wird sicherlich für viele nützlich sein.
Ich war auch schon zur Auflösung 1024x768 übergegangen. Allerdings setzen wir inzwischen großen Wert auf die WAI Zugänglichkeitskriterien und versuchen unsere Seiten auch für benachteiligte Menschen zugänglich zu machen. Dies erfordert natürlich, dass man nicht mit festen breiten arbeiten kann. "Mit viel Geduld und Spucke..." ...bekommt man auch Seiten hin, die sowohl mit Grafiken arbeiten, als auch flexible Schriftgrößen haben. Das muss allerdings der Auftraggeber entscheiden bzw. über die Zielgruppe des Auftraggebers entschieden werden und nicht vom Webdesigner.
Ich bin weiterhin gespannt auf die kommenden Ergebnisse dieser Studie.
Vielen Dank!
Ünal Aydin
Die Diskussion geht teilweise in die falsche Richtung. Eine bestimmte Viewportgröße vorauszusetzen benachteiligt Besucher, mehr will der Artikel gar nicht ausdrücken – die Diagramme sind nicht als Empfehlung zu verstehen. Welchen Anteil man bei welcher Größe abdeckt ist völlig unerheblich, da das eigentliche Ziel lautet, alle zufriedenzustellen. Ob nun 320 oder 1.024 Pixel horizontal zur Verfügung stehen darf für die Bedienbarkeit keine Rolle spielen. Relevant ist lediglich die Zeilenlänge und diese lässt sich bei browserseitig skalierbaren Schriftgraden nicht in ein starres Pixelraster umrechnen. Was also spricht für die »Optimierer« unter euch für width in px und gegen max-width in em?
Also ich finde die ganze Diskussion etwas einseitig, denn die Entscheidung für ein Webdesign grenzt doch immer eine Gruppe von Benutzern aus oder benachteiligt sie - Zumindest habe ich die Erfahrung gemacht, dass es eher um die Wahl des kleineren Übels geht.
Wenn man sich auf eine definierte Seitenbreite festlegt, benachteiligt man doch immer eine Gruppe von Benutzern - entweder die mit den hohen Auflösungen oder die mit de niedrigen Auflösungen. Je mehr man sich dann auf die Ebene flexibler Lösungen begibt, desto größer wird das Risiko, dass die einzusetzenden Technologien (css, client seitige Scriptsprachen) vom Browser des benutzers nicht oder nur teilweise unterstützt werden. Ich bin erst gestern wieder auf eine Seite gestoßen, die nicht angezeigt werden konnten, weil ich nicht die aktuelle Flash Version habe ... - wer klickt da nicht weiter?
hallo,
die diskussion ist sehr interessant, aber doch auch sehr theoretisch. ich möchte mal aus der praxis berichten. wir bieten kostenlose homepagevorlagen an. gerade die auflösung liegt uns sehr am herzen. es erscheint uns verstärkt das eher solche seiten gewählt, die den platz vollständig ausnutzen.
Eine Webseite sollte immer für verschiedene Monitorauflösungen (800x600 und 1024x768) konzipiert sein, da man nicht wissen kann, mit welchem Monitor ein Anwender die Seite ansurft bzw. welche Auflösung der Anwender auf seinem Bildschirm eingerichtet hat.
das ist nicht veraltet sondern ist neben der browserkompatibilität (crossbrowser - in möglichst vielen browser funktionabel) der wichtigste punkt der webdesign ausmacht.
es sollte für den anwender nur eine einzige scroll-leiste zu sehen sein, nämlich die vertikale (von oben nach unten) leiste neben dem inhalt.
auf keinen fall weitere scroll-leisten wie - eine untere horizontale leiste - und auch keine weiteren vertikalen scroll-leisten, wie man es manchesmal bei frame-seiten und auch inline-frame-seiten sieht.
wie geht das jetzt ¿
neben der technik ist auch wichtig, dass es auf den ersten blick nicht so aussieht, dass die seite für mehrere auflösungen geschrieben ist.
dazu sollte man in der regel dem menü eine feste pixelgrösse geben und dem platz für inhalt und logo prozentmässig anpassen. die grafiken ganz oben rechts und ganz unten links (ausgehend von 800x600 ohne browserleisten) sollte man dann kacheln.
1. frameset-konstruktion:
bei einer frameset-konstruktion sieht das dann so aus:
a)beispiel: http://www.on-mouseover.de/templates/hp39/index.html
b) hier mit pixel-menü links und prozent-menü oben. beispiel: http://www.on-mouseover.de/templates/hp13/index.html
***
2. als nicht-frame-konstruktion (tabellen-konstruktion):
zu beachten ist, das einige browser auf der inhaltszelle keine höhenangabe in prozent akzepieren, hier ist die höhe in pixeln vorzugeben.
a)hier ist das menü oben auf 760 pixel begrenzt - durch die kachelung rechts oben sowie auch beim linken menü (nach unten unbegrenzt) die kachelung links unten fällt das aber garnicht so auf: beispiel: http://www.on-mouseover.de/templates/hp25/index.html
b) reine tabellenseite ohne grafiken: beispiel: http://www.on-mouseover.de/templates/hp06/index.html
***
3.) inline-frame-seiten:
zu beachten ist, das der netscape browser bei inline-frames auf dem inhaltsframe leider keine höhenangabe in prozent aktzeptiert - man sieht dann nur eine leere seite.
a)somit bleibt einem hier nur ein pixel-layout zur auswahl. beispiel: http://www.on-mouseover.de/templates/hp04/index.html
liebe grüsse, Jürgen
Hallo Jürgen,
ich will hier kein Streit vom Zaun reißen, aber wir haben das Jahr 2006 und du redest von Templates mit Frames, Tabellen und inline Frames ... das ist ein verspäteter Aprilscherz .... oder?
'Tschuldigt, bin absolut kein Webseitendesigner etc., aber warum versteifen sich eigentlich alle auf Pixel? Warum nicht umstellen/optimieren auf 30x20 cm (oder besser: Viewport in cm rausfinden)? Dann hätte man auch als Besitzer hochauflösender Bildschirme ohne Lupe etwas davon. Nach der Pixelansicht hier dürfte doch ein Ausdruck einer 800x600 Pixel Website mit 1200 dpi nur ca. 1,6x1,2 cm groß sein.
Hallo,
welche Gründe sprechen gegen Frames?
Warum sind Frames böse?
Ich bitte um Antwort.
PS: Es gibt so viele andere Dinge, die bei Webseiten äußerst ärgerlich sind (und auch schon angesprochen wurden); z.B. Webseiten auf 800x600 "optimiert" - wenn ich dann den 6pt Text um 200% vergrößere, verhauts das ganze Layout...
1. Zoi wegen dem drucken: prinzipiell, aber alle modernen browser skalieren die website so das sie ordentlich aufs blatt passt wegen den cm, genau die idee hatte ich mal auch, nachdem ich aber bemerkt hab das diese angabe sehr unterschiedlich interpretiert wird hatte ich es doch gelassen
zum thema, was haben eigendlich alle gegen variable seiten, ich habe auf meiner ein css layout dass komplett mit Prozent angaben auskommt und imho siet des auf allen Auflösungen ok aus (naja, es sei denn man benutzt 640x480 oder so pervers hohe alla 2040x irgendwas)
Hallo,
sehr interessanter Beitrag. Aber was meiner Meinung nach gegen Liquid-Design usw. spricht: Wenn ich Projekte für Firmen umsetz, arbeit ich nach Stunden, d.h. wenn ich allein um nur die Anpassung an die verschiedenen Browsergrößen durchführe, dann bin ich schon bei mehreren Stunden. Es ist ja nicht so, dass es mal eben gemacht ist, jedem Bereich und nen prozentualen Wert zu geben, nein das Ganze soll ja auch stimmig aussehen. Und da kommen wir schon zum größten Problem, das auch schon viele angesprochen haben. Wenns zu breit wird, werden Texte teilweise nur eine Zeile lang. Klar könnte/kann man das mit der max-width begrenzen, wo wir aber schon wieder mit Größenangaben arbeiten... (Mal ganz davon abgesehen, hab ich nicht die größeren Auflösungen, dementsprechend arbeitet man dann immer "blind", ich kontrolliere gern, was wie wo aussieht... hab aber nur einen Monitor.)
Aus meiner Erfahrung ist es einfach im Moment praktikabler, die Größe an die Auflösung anzupassen, mit der die jeweilige Klientel arbeitet. Und das ist dann meistens die 1024er Auflösung oder 1280, wobei eben es sehr ok ist, wenn die Seite auf 1024 optimiert ist. Sie schaut bei 1280 auch noch gut aus.
Noch ein Problem sind grafische Logos usw. (schon im Beitrag besprochen), die halt nunmal Pixelgrößen haben. Und ein 120px großes Logo schaut je nach Auflösung ziemlich klein im Kontext oder sehr sehr groß aus. Bevor da keine wirkliche Lösung mittels Vektorgrafiken o.Ä. gefunden ist, ist auch das ein Punkt für die Unpraktikabilität.
Achja, @Zoi: Wir geben Pixel an, weil der Monitor nunmal mit Pixeln arbeitet. Sozusagen ist alle Grafik im PC auf Pixeln aufgebaut, metrische Angaben sind ja "reale" Angaben, sprich 1cm sind auf dem Papier immer 1cm egal mit welchen dpi man arbeitet. (Printdesign) Wenn ich aber Seiten optimiere oder Grafiken nur für den Computer, komm ich um Pixel nicht drumrum, 1px bei 72dpi ist der Standard. Und da alle Monitore mit 72dpi arbeiten ist da kein Problem. (Warum das so ist: http://de.wikipedia.org/wiki/Pixel) Das mit dem Ausdrucken stimmt schon, nur skaliert der Browser schon die Seite dann auf DinA4 oder was auch immer hoch. Was passieren würde, wenn du das nicht machst, kannst du in nem Grafikprogramm sehen, wenn du ne Pixelgrafik erstellst mit 72dpi und die ausdruckst. Die ist auf dem Monitor schön groß aufm Papier dann aber miniklein. Stellt man die dpi dann auf 300 ist alles gut für den Druck...
so long Davie
@Davie: Eben, da es für das Drucken skaliert wird, warum nicht auch für den Bildschirm? Im Büro arbeite ich an einem 15" Laptop mit einer Auflösung von 1650x1080, das sind sicher keine 72 dpi. Die dpi müssten sich ja schon unterscheiden, ob jemand 1024er oder 1280er Auflösung an einem 17" Monitor einstellt. Wäre es nicht schöner, die Webseiten wären in beiden Fällen gleich groß, nur daß sie im 2.Fall mehr Pixel zu Verfügung hat, um dies darzustellen? Ein 1000dpi Monitor wäre doch super, eine Qualität wie gedrucktes Papier und man muss sich um AntiAliasing z.B. bei Schriften und/oder Spielen nicht mehr kümmern. Dass ein 1000dpi 17" Monitor im Augenblick unbezahlbar wäre, von der zugehörigen Grafikkarte mal ganz abgesehen, ist mir schon klar. Grüsse, Zoi
@Zoi: da hab ich was für dich: http://praegnanz.de/essays/137 (die Seite braucht lang zum laden)
Da wird das ganze schön erklärt, bzw. ist in den Kommentaren noch eine gute Seite mit noch mehr Infos genau dazu...
Warum die Hersteller das nicht machen...tja, wahrscheinlich weils ihnen einfach zu blöd ist und sie ja kein Problem mit 72dpi haben, nur Printdesigner haben das :) Eine DinA4 Seite ist halt nur in der realen Welt eine DinA4 Seite...
Davie
Hallo Dirk, ich finde deine Auswertungen genial und werde sie mir ensprechend in meinen Blueprintlayern mit eintragen.
Dies möchte hier für die Öffentlichkeit beisteuern.
Hier könnt ihr einen Blueprintlayer als Photoshop-Datei für die Entwicklung von solchen spezifischen Layouts herunterlanden. Dort könnt ihr ohnen Probleme den Viewport ergänzen und für das Layout entsprechend berücksichtigen. Mit der Scalierung des Layers könnt Ihre es ja noch für andere Auflösungen erweitern.
Ich verwende dies in Photoshop und Dreamweaver als Tracingbild für die Entwicklung von Layouts.
Gruß Dirk Wohlrabe
Download:
Dirk, da es nicht nur dich stört, dass horizontale Balken auftauchen sobald man vergrößert, hat Opera die "Fit to width" Funktion eingebaut, die genau das verhindert.
Ein englischsprachiger Artikel, der in die gleiche Kerbe schlägt, aber nicht mit dem Viewport-Begriff operiert:
Nachdem keiner Beitrag 18 beachtung geschenkt hat, wiederhole ich die Frage nochmal, bevor hier dieses Pixelgeschubse weitergeht:
Was also spricht für die »Optimierer« unter euch für width in px und gegen max-width in em?
Wobei ich prinzipiell, für Fließtexte em als Einheit benutze.
Ich höre schon das Argument das Banner hat eine feste Breite. Wenn die Designer nicht in der Lage sind ein Banner zu entwerfen, das mit Hilfe einer gekachelten Hintergrundgrafik sich verbreitern kann, dann ist die ganze Geschichte eben nur bedingt ein Webdesign. (Wobei zur Not fast immer rechts oder links gekachelt werden kann) Aber die meisten Banner die ich gesehen habe liessen sich so auf 60 oder 70 em "fixieren".
HTML/CSS sind eben Werkzeuge um auf völlig unterschiedlichen Ausgabemedien eine gleichmäßige (nicht identische) Ausgabe zu erzielen. Wer das nicht berücksichtigt macht kein Weblayout, sondern versucht sein Papielayout auf den Bildschirm zu pressen.
Danke! Ein gelungener Artikel! Ich achte bei meiner Homepage darauf, dass sie bei verschiedenen Viewportgrößen aussieht. Ich glaube ich werde in meinen Counter auch mal Viewport auswerten.
Konstantin
Hi Namensvetter,
zunächst mal Danke für Deine interessanten Ausführungen.
Ein paar Anmerkungen zur Relevanz von Bildschirmauflösung und Viewportgröße
Bildschirmauflösung
- Beeinflusst vor allem die Wirkung von grafischen Elementen und Bildern und ihr Verhältnis zur Schriftgröße, wenn diese flexibel ausgezeichnet wird. - Beeinflusst die Lesbarkeit von Fließtext
Viewportgröße
- In vielen Szenarios gibt es eine Bandbreite, innerhalb derer das geplante Design "hält", bei Mehrspaltern etwa könnte man den Punkt definieren, wo aus drei Spalten zwei werden oder ein Scrollbalken auftaucht. Bei Fließtext wird es unangenehm, wenn die Zeilen zu lang werden, auch dazu wurde ja schon einiges gesagt. Leider sind die Steuerungsmöglichkeiten für das letzte Problem, überhaupt für die Schriftgestaltung unzureichend. Ich nutze gerade so ca. 1000 von meinen 2480 Pixeln Bildschirmbreite für dieses Fenster und finde die Zeilenlänge des Blogs als nervig.
- Oft empfinde ich Seiten, die für die Kernelemente so um die 770 Pixel Breite nutzen als angenehmer als "flüssige" Designs, die den ganzen Viewport nutzen. Leere Ränder kann man nutzen, sie stören mich aber auch nicht.
- Es ist tatsächlich einiger Testaufwand nötig, eine Seite so aufzubauen, dass sie bei verschiedenen Auflösungen/Viewportgrößen angenehm zu nutzen ist, ich denke, das ist der Hauptgrund für die 770-optimierten Sites.
Viele Grüße Mathias Bigge
Hallo,
Bin grad erst auf diesen Artikel gestosen, weil ich eine ganz andere Problematik hatte. Ich entwerfe auch eigentlich immer statisch in Berein um 900px breite. Aber im Moment mache ich eine Site für einen Designer und diese benötigt mindestens eine Viewbreite von 1050 und ne Höhe von idealerweise 750. Er wollte es so. Jetzt heisst es: Mensch, das sieht auf 1024x768 aber nicht so doll aus usw.
Also hab ich mich im Web mal umgesehen was es für Statistiken gibt bezüglich der verwendeten Auflösung. und damit bin ich beim Kern der Sache. Auch ich denke das das hier ein hervorragender und aufschlussreicher Artikel ist. Das Problem ist aber das er sich auf Besucher dieses Forums bezieht. Auch ich denke das Leute die sich mit Webdesign beschäftigen sicherlich einen Monitor mit großer Auflösung haben oder aber mit zwei Monitoren arbeiten. Viel wichter also als eine generelle Entscheidung für welche Auflösung man optimiert ist die Frage was hat mein Kunde für Kunden. Denn wie heisst es: Der Wurm muss dem Fisch schmecken, nicht dem Angler. Es macht also Sinn sich genau anzuschauen was ich für eine Kundschaft habe. Schaut man sich mal nach anderen Statistiken im Web um, so stellt man fest das viele Zocker mit 1024x768 arbeiten. Im B2B Bereich ist diese Auflösung ebenfalls weit verbreitet (häufig sogar noch 800x600) und grade Notebookuser die nicht innerhalb der letzten 12Monate ein neues Gerät erworben haben sind mit solchen Auflösungen unterwegs. Und der durschnittliche user ist nunmal immernoch zu einen großen Prozentsatz mit IE unterwegs daher optimiere ich für exotische browser auch nur nach anfrage. Ein dynamisches Layout oder eine Lösung über Browserweichen o.ä. ist sicher bei Tabellen orientierten Sites eine gute Lösung und halte ich auch für den sinnigsten Ansatz. Allerdings hab ich festgestellt das grade im Design und Bereich der Web-Portfolios fixe Flash und statische HTML-Layouts vertreten sind.
Die maximale Viewportbreitennutzung empfinde auch ich als störend. Aber das hat einen relativ einfachen Grund. Der Mensch ist es gewohnt Hochformate zu lesen die eine gewisse Zeichenmenge pro Zeile nicht überschreiten. Klar, denn das gedruckte Wort orientiert sich üblicherweise an Din Formaten und ist hochformatig angelegt. Es ist also eine reine gewohnheit das uns so etwas gefällt oder missfällt. Ich gebe aber zu, das auch ich entnervt binn wenn ich an meinem 23" eine Seite habe die dynamisch arbeitet und mir dann bei einer Viewbreite von 1200 den Text über die gesamte Site haut aber der Text dann nur 3 Zeilen lang ist. klar bin ich eine aussnahme, aber es ist ja auch nur ein Beispiel. Ich für meinen Teil habe halt hauptsächlich mit statischen"kleinen" Sites zu tun, bei denen die Frage nach einen dynamischen Layout eher unnötig ist. Wichtiger ist dort einen kundenspezifische Anpassung mit der man möglichst den Großteil des Klientels abdeckt.
Daher: Es wäre schön, wenn die ganzen Leute die hier kommentiert haben einfach mal ihre statistike posten würden und den link zur entsprechenden Site. und vielleicht ein kurzer Abriss über das Kundenprofil. Das wäre sicherlich sehr interessant für alle weil man dann recht schnell sehen könnte welche Sites mit welchen Kunden welche Auflösungen haben.
in diesem Sinne: Danke für diesen aufschlussreichen Artikel. Sehr gut!
Ich war ja nun schon länger nicht mehr ... interessante Kommentare.
Ein pragmatischer Ansatz wenn es um die Lesbarkeit geht, ist in Deutschland immer noch die gute alte DIN A4 Seite mit 12 Punkt Schrift und mehr oder weniger breiten Rändern links und rechts.
Wenn ich einem Kunden so ein bedrucktes Ding vor die Nase halte und darauf hinweise, dass das der Standard ist, dann ist ein Nicht-Grafiker-Kunde schon mal von diesem Usability Beispiel beeindruckt :-)
Wenn man sich jetzt mal gut funktionierende lesbare Spalten-Webdesigns anschaut, dann findet man überraschend viele Parallelen in Bezug auf 'angenehme' Lesbarkeit.
Nicht ganz ernst gemeint, aber durchaus ein Ansatz.
Liebe Leute !
Mein Anwender-Fazit ist :
Und jetzt seht zu, wie ihr das hinkriegt. Denn, im Ernste, als ich hier das meiste durchgelesen habe, fand ich auch fast alles einleuchtend - aber wie denn , ihr widersprecht euch doch ? Ich werde also zunächst mal weiterwursteln.
Trotzdem schönen Dank !
Wow ganz herzlichen Dank, genau diesen Artikel habe ich lange gesucht. Hab mich immer gewundert, warum so viele behaupten, screen.width wäre ja breit genug für 1000px-Layouts schon vor 2 Jahren. Lustig wird es sicher das Ganze in Zukunft weiterhin zu betrachten: erstens die neuen Gadgets bei Windows Vista, dann die neuen Sidebars und letzlich auch noch in Zukunft die Viewport-Höhe...wird sich sicherlich nur die 16:10 Monitore deutlich verringern im Schnitt...
Sehr interessante Studie und Kommentare. Haben mir sehr weitergeholfen.
nette statistik, also das kreisdiagramm. nur sollte man bedenken, dass die selfhtml seite vermehrt computerinteressierte betreten und nicht jeder hans-und-franz, der durchs internet surft! was ich damit dagen möchte, die tatsache, dass nur 1,13% die 800x600 haben bedeutet keineswegs, dass die 15" röhre ausgestorben ist.
Ich habe das hier zweimal von oben nach unten gelesen und frage mich was gegen eine Auflösungsredirect spricht. Es geht primär darum das alle dasselbe vors Gesicht bekommen, egal mit welchen Auflösung sie ankommen. Ich mein um nicht enorm viel abdecken zu müssen, nur die beiden zurzeit gängigsten Auflösungen: 800x600 und 1024x768 wäre eine Auflösungs- Weiche ideal.
moin nuno, ich denke die gängigsten auflösungen sind 1024*168 und 1280*xxxx (also 17" und 19" TFT) habe auf meiner hp von google analytics ein script geschaltet, welches mir das verrät! und es sind viele verschiedene besucher...
moin, Die gängigsten Auflösungen sind... hmmm... man kann es gar nicht so generell sagen, aber ich stimme dir zu und füge noch 19" dazu - also drei Weichen.
Aber wo wir jetzt bei den Suchmaschinen sind (du hast G** Analytics erwähnt) - ist mir gerade eingefallen dass die Weichen bei G** gar nicht so gut ankommen (ganz andere Thema, dennoch zum nachdenken) Gruß nuno
Mal eine andere Frage, ... erstellt ihr vorwiegend fixe oder liquide Layouts?
Außerdem würde mich interessieren ob ihr freischwebende Layouts oder klebende Layouts nutzt - das ist schließlich oft eine Designfrage.
freischwebend = einen mittig zentrierten DIV-Layer in dem die gesamte Website steht
klebend = Website-Layout am Rand ausgerichtet
Bislang habe ich meistens am Rand ausgerichtete liquide Layouts erstellt (dynamische CSS-Body-Fixierung*), aber ich möchte demnächst ein freischwebendes aber dennoch liquides Layout entwerfen. Dieses Design soll in drei verschiedenen Layout-Auflösungen vorliegen, hauptsächlich wegen der Grafiken. (W:1024-1280px / W:1280-1600px / W:1600-3200px) wobei ich noch ein viertes Layout entworfen habe, das aber auch designtechnisch eingeschränkt wurde, da es auf PDA und Handy optimiert ist. Eventuell krumme Zwischenauflösungen will ich via liquidem, bzw. prozentualen Maßen abfangen.
Ich persönlich sehe mich als Fan von Weißbereichen und freien Rändern. Das gibt mir zusätzlichen Spielraum.
Einen exakten Viewport kann man via JavaScript auch auslesen, in dem man die Elementbreite und -höhe des BODYs ausliest. Noch sinnvoller, man legt einen prozentualen DIV-Layer an, den man dann via JS in Pixeln ausliest, so kann man auch gleich noch diverse Abhängigkeiten einflechten, gerade für Web-2.x-Projekte (AJAX/JSON) recht interessant.
Die einzige, perfekte Lösung wäre ein komplett prozentuales Layout, dann aber auch mit Vektorgrafiken. - Tja, somit bleibt uns dieses Delämmer wohl erhalten.
*dynamische CSS-Body-Fixierung:
@media screen
{
body>div.topbar, body>div.logobar, body>div.leftbar
{
POSITION:fixed;
}
}
Wirklich ein Interessanter Artikel von dem man noch mehr lernen kann.Ob das dann bei bei Windows Vista auch so funktioniert, mal sehen.
Hallo alle zusammen, am besten gefällt mir der Beitrag, in dem gesagt wird: „Alle Beiträge leuchten mir ein ... aber hoppla, Ihr widersprecht Euch doch ...“.
Gott sei Dank, dass nicht alle ihre Seiten gleich gestalten.
Ich halte es so wie im normalen Leben (ausserhalb des Internet ;-). Ein Blatt Papier liegt auf dem Schreibtisch, und wenn ich es lesen will, hebe ich es auf (zoome es heran). Die modernen Browser können das. Deshalb gestalte ich für 800x600, fest in eine Tabelle gezwängt, denn der beste CSS-Hack ist eine Tabelle. Das versteht auch der IE6, der ja bekanntlich mit dem padding so seine Probleme hat.
Ich gehe dabei ganz einfach von folgenden Vermutungen aus:
- Wer einen modernen Computer mit einem hochauflösenden Bildschirm hat, hat auch einen moderen Browser mit Seitenzoom.
- Wer ein altes System hat, ist mit 750px Breite in der Regel auch gut bedient.
- Auf dem Handy zieht sich meine Seiten sowieso keiner rein.
In naher Zukunft werden alle modernen Browser eine Seitenzoom-Funktion haben, ich denke, dass das eine Folge der Entwicklung hin zu immer grösseren Auflösungen ist. Liquid Design ist meiner Meinung nach dadurch in eine Sackgasse geraten.
Ich halte es für schlicht unsinnig, ein liquides Design für Auflösungen von 800-2000px herstellen zu wollen, das idealerweise auch noch bei 220px auf dem Handy gut aussieht.
Für Handys sollten schon deshalb gesonderte Seiten gestaltet werden, weil das Datenvolumen unserer schönen PC-optimierten Seiten (meist auf Grund von Bildern und Hintergrundbildern) viel zu hoch ist. Un denkt doch mal nach, wie ich mit dem Handy scrollen muss, um den Inhalt nur einer einzigen Seite zu sehen, die einen 19-Zoller ausfüllt. Da hilft auch das abschalten der Bilder nicht. Da müssen die Inhalte reduziert werden. Seiten fürs Handy sind einfach ein ganz anderes Ding.
Fazit: Seiten mit einer festen Breite von 750px sind für jede heute übliche Auflösung von PC-Bildschirmen gut, dank Seitenzoom nun auch wieder für die grossen. Das Layout bleibt wenigstens ein wenig unter Kontrolle. 800x600px ist das DIN A4 des Internet. Mehr nicht, es gibt ja auch im wirklichen Leben DIN A3 und grösser. Dafür braucht man aber eben einen grossen Schreibtisch, und den hat nicht jeder.
Und als Notizzettel stecke ich mir kein DIN A4-Blatt ein, das heisst, Seiten fürs Handy sollten kleiner gestaltet sein. Das wäre dann DIN A6, ein übliches Notizblock-Format.
So, nun reichts aber!
Hi,
vom Print zum Web: Wenn die Bildzeitung optimiert werden würde, dann wäre die untere Hälfte doch weiss, oder? Schliesslich liegt diese Hälfte im Kiosk nicht im sichtbaren Bereich. Das wäre aber schlecht für die Bildzeitung und so stehen dort die 2.-"wichtigsten" Informationen. ;-) So handhabe ich das mit Websites auch. Ich optimiere weder auf eine feste Breite, noch erstelle ich fluid designs. Aber ich achte darauf, dass die wichtigsten Infos wie z.B. Navi und Marke auch auf dem kleinstanzunehmenden Display zu lesen sind. Anpassbare Spaltenbreiten sehe ich ähnlich wie in den vorhergehenden Kommentaren. Gut, Schriftgrösse ändern und Bilder vergrössern sind ok, aber Texte mit bis zu 1600 Pixeln Breite gehen nicht... Ich würde das Wort "Optimierung" gerne durch "Kompromiss" ersetzen wollen.
Zwar sind die Statistik-Scripte hier nur beiläufig erwähnt, das beschriebene Mint ist aber auf jeden Fall empfehlenswert, nicht nur weil damit Statistiken über den Viewport erstellt werden. Das Preis-Leistungs-Verhältnis ist wirklich gut.
Schon sehr interessant der Artikel und die ganzen Komments. Stimme dem Roland Skop zu. Hauptsache richtig coden, dann kannste das Ganze auch mit PDA lesen.
Auch ich habe Zweifel, dass das bei Vista optimal funktioniert. Hat da schon jemand Erfahrungen gemacht?
Ich werde meine Seiten mit einer Breite von 790px weiter behalten. Es gibt sehr viele Laptop-User und Leute die schlechter sehen. Mit einem schönen Hintergrund finde ich das lange nicht so schlimm wir horizontal Scrollbalken!
Danke an alle für die Kommentare, die wichtige Aspekte in die Diskussion eingebracht haben!
Nach der riesigen Textmenge von 50 Kommentaren, die zum Teil separate Diskussionen starteten und zum Teil weit vom Thema des Artikels abschweiften, möchte ich die Kommentare nun schließen.
Die Kommentarfunktion ist für solchen allgemeinen Austausch sowie für Grundsatzdiskussionen eher ungeeignet, dafür steht weiterhin unser Forum offen. Siehe auch unser erster Blogeintrag mit Anmerkungen zum Zweck der hiesigen Kommentarfunktion.
Ich muss auch gestehen, dass ich den Eindruck habe, dass manche Kommentatoren den Artikel anscheinend missverstanden haben oder sich nicht mit den kritischen Kernaussagen des Artikels auseinandergesetzt haben. Roland hatte das in seinem Kommentar ganz gut auf den Punkt gebracht.
Meine Absicht war gerade nicht, die »Optimierung« für irgendwelche Auflösungen oder vermeintlich ideale Layout-Breiten zu empfehlen oder die Entwicklung von »Auflösungsweichen« voranzutreiben. Gerade diese Praxis galt es mir mit stichhaltigen Argumenten grundsätzlich zu hinterfragen, ohne dabei eine Lösung vorzustellen, die von sich behauptet, das Nonplusultra zu sein.