<h2>»Optimiert für …«</h2> <p>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.</p> <h2 lang="en" xml:lang="en">Liquid, fluid, elastic, jello!</h2> <p>Nun gibt es verstärkt <a href="http://www.cssliquid.com/">fließende und elastische Layouts</a> oder auch <a href="http://www.positioniseverything.net/articles/jello.html">Götterspeisen-Layouts</a> als Alternativen zu festen Layouts. Mithilfe von JavaScript sind <a href="http://clagnut.com/blog/1663/">noch</a> <a href="http://www.themaninblue.com/experiment/ResolutionLayout/">mehr</a> anpassbare Alternativen denkbar. <a href="http://www.bs-markup.de/blog/archiv/2006/01/19/herausforderung-elastische-layouts/">Björn Seibert</a> nennt einige prominente Beispiele.</p> <h2>Wir optimieren uns zu Tode</h2> <p>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 <a href="http://aktuell.de.selfhtml.org/weblog/schriftgroesse">Schriftgröße</a> 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.</p> <h2><span lang="en" xml:lang="en">Viewport</span> statt Bildschirmauflösung</h2> <p>Zunächst einmal muss festgestellt werden, dass die <em>Bildschirmauflösung</em> 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 <dfn lang="en" xml:lang="en">Viewport</dfn>. Thomas Lahn hat diese grundsätzlichen Erkenntnisse einmal auf die Formel gebracht:</p> <blockquote> <p>Auflösung != Desktopgrösse != Browserfenstergrösse != Anzeigebereich. [psf 3.7]</p> <p><cite><a href="http://pointedears.de/psf/index.de#general">PointedEars' Standard-Floskeln</a></cite></p> </blockquote> <h2><span lang="en" xml:lang="en">Viewport</span>-Breite untersuchen</h2> <p>Zahlreiche <span lang="en" xml:lang="en">Counter</span> und <span lang="en" xml:lang="en">Tracker</span> fragen <a href="http://de.selfhtml.org/javascript/objekte/screen.htm#width">mittels JavaScript</a> 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.</p> <p>Interessant für Design-Entscheidungen ist hingegen eher die <span lang="en" xml:lang="en">Viewport</span>-Breite sowie ihr Verhältnis zur Auflösung. Die wenigsten Statistik-Scripte vermessen den Viewport. Unter diesen wenigen ist <a href="http://www.haveamint.com/" hreflang="en" lang="en" xml:lang="en">Mint</a>, siehe <a href="http://www.google.com/search?q=%22available+at+haveamint%22+%22window+width%22">Beispielstatistiken</a>.</p> <p>Hier im SELFHTML-Weblog habe ich eine ähnliche Statistik installiert, die mit JavaScript die <span lang="en" xml:lang="en">Viewport</span>-Breite sowie die Bildschirmauflösung untersucht und im Hintergrund zum Server übertragt, wo sie in einer Datenbank gespeichert wird. Dazu benutze ich <a href="http://www.quirksmode.org/viewport/compatibility.html#link2" hreflang="en">diesen einfachen Scriptschnipsel</a> von Peter-Paul Koch. Das <a href="http://aktuell.de.selfhtml.org/weblog/base.js">komplette Script</a> »spioniert« zudem noch einige andere Javascript-Eigenschaften aus, vor allem zu Studienzwecken.</p> <p>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 <a href="http://stats.selfhtml.org/webalizer/aktuell.de.selfhtml.org/">Webalizer-Statistik</a> eine JavaScript-Statistik etabliere wollte, bot sich erst einmal dieses Studienobjekt an. Zuerst begann ich damit, die <span lang="en" xml:lang="en">Viewport</span>-Größe aufzuzeichnen, später auch die Auflösung. Da das Layout dieses Weblogs im Allgemeinen bei verschiedenen <span lang="en" xml:lang="en">Viewport</span>-Breiten passabel aussieht, gehe ich davon aus, dass die Ergebnisse nicht durch an unsere Site angepasste <span lang="en" xml:lang="en">Viewport</span>-Breiten verfälscht wird.</p> <h2>Statistik über die Auflösungsbreite</h2> <p>Vorab, welche Auflösungen sind verbreitet, wenn wir der Eigenschaft <code>screen.width</code> Glauben schenken?</p> [](/images/fb0228a6-9e70-11f0-b2f5-9c6b003e9157.png) Statistik über die Auflösungsbreite<br> 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.</p> <p>Eine Auflösungsbreite von 800 Pixeln scheint hier demnach nahezu überhaupt nicht mehr verbreitet.</p> <h2>Statistik über die <span lang="en" xml:lang="en">Viewport</span>-Breite</h2> <p>Interessant wird nun die <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span>-Breite gemessen wurde.</p> [](/images/316650c0-9e71-11f0-af98-9c6b003e9157.png) Zeitraum: 2006-02-25 bis 2006-10-30. Gezählte »Besucher«: 69375</p> <p>In einem weiteren Diagramm habe ich den interessanten Ausschnitt vergrößert dargestellt:</p> [](/images/3dca38ae-9e71-11f0-a4c8-9c6b003e9157.png) <p>Diese Diagramme sind so zu lesen: 80,6 Prozent aller »Besucher« haben eine <span lang="en" xml:lang="en">Viewport</span>-Breite größer als 1000 Pixel, hingegen nur 50,1 Prozent einen Viewport größer als 1040 Pixel.</p> <p>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 <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span>-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.</p> <h2>Statistik über die <span lang="en" xml:lang="en">Viewport</span>-Breite bei bestimmten Auflösungen</h2> <p>Während die beiden vorigen Diagramme die <span lang="en" xml:lang="en">Viewport</span>-Breite bei allen Auflösungen berücksichtigten, habe ich weitere Diagramme erstellt, die die <span lang="en" xml:lang="en">Viewport</span>-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.</p> <dl> <dt>800 Pixel:</dt> <dd> [](/images/4de8f662-9e71-11f0-91f2-9c6b003e9157.png) </dd> <dt>1024 Pixel:</dt> <dd> [](/images/552066fe-9e71-11f0-9ffd-9c6b003e9157.png) </dd> <dt>1280 Pixel:</dt> <dd> [](/images/5f66f0f6-9e71-11f0-a6e1-9c6b003e9157.png) </dd> </dl> <p>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.</p> <p>In diesen Diagrammen zeigt sich, dass von der Auflösung keinesfalls auf eine Standard-<span lang="en" xml:lang="en">Viewport</span>-Breite geschlossen werden kann. Wenn man für die Auflösungsbreite 1024 Pixel »optimiert« und von einer <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span> zu vergrößern.</p> <h2 lang="en" xml:lang="en">Disclaimer</h2> <p>In meinen Messungen und Auswertungen sind viele Faktoren nicht berücksichtigt. Nicht zuletzt schließe ich methodische Fehler meinerseits nicht aus.</p> <p>Der Schluss, dass eine bestimmte feste Layout-Breite einen gewissen Prozentsatz der Besucher »ausschließt«, ist sicher nicht möglich. Die gemessenen <span lang="en" xml:lang="en">Viewport</span>-Breiten lassen nur Hypothesen darüber zu, was für die Differenz zwischen Auflösung und <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span> 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.</p> <p>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 <a href="mailto:molily@selfhtml.org">E-Mail</a> einzureichen und dazu nicht die Kommentarfunktion zu nutzen.</p> <h2 lang="en" xml:lang="en">Download</h2> <p>Alle obigen Diagramme liegen samt Werte-Tabellen als OpenOffice-Calc-Dateien vor:</p> <ul> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-aufloesung.ods">Auflösungsbreite</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-800.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 800 Pixel</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1024.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 1024 Pixel</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1280.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 1280 Pixel</a></li> </ul> <p>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.</p>

<h2>»Optimiert für …«</h2> <p>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.</p> <h2 lang="en" xml:lang="en">Liquid, fluid, elastic, jello!</h2> <p>Nun gibt es verstärkt <a href="http://www.cssliquid.com/">fließende und elastische Layouts</a> oder auch <a href="http://www.positioniseverything.net/articles/jello.html">Götterspeisen-Layouts</a> als Alternativen zu festen Layouts. Mithilfe von JavaScript sind <a href="http://clagnut.com/blog/1663/">noch</a> <a href="http://www.themaninblue.com/experiment/ResolutionLayout/">mehr</a> anpassbare Alternativen denkbar. <a href="http://www.bs-markup.de/blog/archiv/2006/01/19/herausforderung-elastische-layouts/">Björn Seibert</a> nennt einige prominente Beispiele.</p> <h2>Wir optimieren uns zu Tode</h2> <p>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 <a href="http://aktuell.de.selfhtml.org/weblog/schriftgroesse">Schriftgröße</a> 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.</p> <h2><span lang="en" xml:lang="en">Viewport</span> statt Bildschirmauflösung</h2> <p>Zunächst einmal muss festgestellt werden, dass die <em>Bildschirmauflösung</em> 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 <dfn lang="en" xml:lang="en">Viewport</dfn>. Thomas Lahn hat diese grundsätzlichen Erkenntnisse einmal auf die Formel gebracht:</p> <blockquote> <p>Auflösung != Desktopgrösse != Browserfenstergrösse != Anzeigebereich. [psf 3.7]</p> <p><cite><a href="http://pointedears.de/psf/index.de#general">PointedEars' Standard-Floskeln</a></cite></p> </blockquote> <h2><span lang="en" xml:lang="en">Viewport</span>-Breite untersuchen</h2> <p>Zahlreiche <span lang="en" xml:lang="en">Counter</span> und <span lang="en" xml:lang="en">Tracker</span> fragen <a href="http://de.selfhtml.org/javascript/objekte/screen.htm#width">mittels JavaScript</a> 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.</p> <p>Interessant für Design-Entscheidungen ist hingegen eher die <span lang="en" xml:lang="en">Viewport</span>-Breite sowie ihr Verhältnis zur Auflösung. Die wenigsten Statistik-Scripte vermessen den Viewport. Unter diesen wenigen ist <a href="http://www.haveamint.com/" hreflang="en" lang="en" xml:lang="en">Mint</a>, siehe <a href="http://www.google.com/search?q=%22available+at+haveamint%22+%22window+width%22">Beispielstatistiken</a>.</p> <p>Hier im SELFHTML-Weblog habe ich eine ähnliche Statistik installiert, die mit JavaScript die <span lang="en" xml:lang="en">Viewport</span>-Breite sowie die Bildschirmauflösung untersucht und im Hintergrund zum Server übertragt, wo sie in einer Datenbank gespeichert wird. Dazu benutze ich <a href="http://www.quirksmode.org/viewport/compatibility.html#link2" hreflang="en">diesen einfachen Scriptschnipsel</a> von Peter-Paul Koch. Das <a href="http://aktuell.de.selfhtml.org/weblog/base.js">komplette Script</a> »spioniert« zudem noch einige andere Javascript-Eigenschaften aus, vor allem zu Studienzwecken.</p> <p>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 <a href="http://stats.selfhtml.org/webalizer/aktuell.de.selfhtml.org/">Webalizer-Statistik</a> eine JavaScript-Statistik etabliere wollte, bot sich erst einmal dieses Studienobjekt an. Zuerst begann ich damit, die <span lang="en" xml:lang="en">Viewport</span>-Größe aufzuzeichnen, später auch die Auflösung. Da das Layout dieses Weblogs im Allgemeinen bei verschiedenen <span lang="en" xml:lang="en">Viewport</span>-Breiten passabel aussieht, gehe ich davon aus, dass die Ergebnisse nicht durch an unsere Site angepasste <span lang="en" xml:lang="en">Viewport</span>-Breiten verfälscht wird.</p> <h2>Statistik über die Auflösungsbreite</h2> <p>Vorab, welche Auflösungen sind verbreitet, wenn wir der Eigenschaft <code>screen.width</code> Glauben schenken?</p> [](/images/fb0228a6-9e70-11f0-b2f5-9c6b003e9157.png) Statistik über die Auflösungsbreite<br> 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.</p> <p>Eine Auflösungsbreite von 800 Pixeln scheint hier demnach nahezu überhaupt nicht mehr verbreitet.</p> <h2>Statistik über die <span lang="en" xml:lang="en">Viewport</span>-Breite</h2> <p>Interessant wird nun die <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span>-Breite gemessen wurde.</p> [](/images/316650c0-9e71-11f0-af98-9c6b003e9157.png) Zeitraum: 2006-02-25 bis 2006-10-30. Gezählte »Besucher«: 69375</p> <p>In einem weiteren Diagramm habe ich den interessanten Ausschnitt vergrößert dargestellt:</p> [](/images/3dca38ae-9e71-11f0-a4c8-9c6b003e9157.png) <p>Diese Diagramme sind so zu lesen: 80,6 Prozent aller »Besucher« haben eine <span lang="en" xml:lang="en">Viewport</span>-Breite größer als 1000 Pixel, hingegen nur 50,1 Prozent einen Viewport größer als 1040 Pixel.</p> <p>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 <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span>-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.</p> <h2>Statistik über die <span lang="en" xml:lang="en">Viewport</span>-Breite bei bestimmten Auflösungen</h2> <p>Während die beiden vorigen Diagramme die <span lang="en" xml:lang="en">Viewport</span>-Breite bei allen Auflösungen berücksichtigten, habe ich weitere Diagramme erstellt, die die <span lang="en" xml:lang="en">Viewport</span>-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.</p> <dl> <dt>800 Pixel:</dt> <dd>[](/images/4de8f662-9e71-11f0-91f2-9c6b003e9157.png) </dd> <dt>1024 Pixel:</dt> <dd>[](/images/552066fe-9e71-11f0-9ffd-9c6b003e9157.png)</dd> <dt>1280 Pixel:</dt> <dd>[](/images/5f66f0f6-9e71-11f0-a6e1-9c6b003e9157.png)</dd> </dl> <p>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.</p> <p>In diesen Diagrammen zeigt sich, dass von der Auflösung keinesfalls auf eine Standard-<span lang="en" xml:lang="en">Viewport</span>-Breite geschlossen werden kann. Wenn man für die Auflösungsbreite 1024 Pixel »optimiert« und von einer <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span> zu vergrößern.</p> <h2 lang="en" xml:lang="en">Disclaimer</h2> <p>In meinen Messungen und Auswertungen sind viele Faktoren nicht berücksichtigt. Nicht zuletzt schließe ich methodische Fehler meinerseits nicht aus.</p> <p>Der Schluss, dass eine bestimmte feste Layout-Breite einen gewissen Prozentsatz der Besucher »ausschließt«, ist sicher nicht möglich. Die gemessenen <span lang="en" xml:lang="en">Viewport</span>-Breiten lassen nur Hypothesen darüber zu, was für die Differenz zwischen Auflösung und <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span> 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.</p> <p>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 <a href="mailto:molily@selfhtml.org">E-Mail</a> einzureichen und dazu nicht die Kommentarfunktion zu nutzen.</p> <h2 lang="en" xml:lang="en">Download</h2> <p>Alle obigen Diagramme liegen samt Werte-Tabellen als OpenOffice-Calc-Dateien vor:</p> <ul> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-aufloesung.ods">Auflösungsbreite</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-800.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 800 Pixel</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1024.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 1024 Pixel</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1280.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 1280 Pixel</a></li> </ul> <p>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.</p>

<h2>»Optimiert für …«</h2> <p>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.</p> <h2 lang="en" xml:lang="en">Liquid, fluid, elastic, jello!</h2> <p>Nun gibt es verstärkt <a href="http://www.cssliquid.com/">fließende und elastische Layouts</a> oder auch <a href="http://www.positioniseverything.net/articles/jello.html">Götterspeisen-Layouts</a> als Alternativen zu festen Layouts. Mithilfe von JavaScript sind <a href="http://clagnut.com/blog/1663/">noch</a> <a href="http://www.themaninblue.com/experiment/ResolutionLayout/">mehr</a> anpassbare Alternativen denkbar. <a href="http://www.bs-markup.de/blog/archiv/2006/01/19/herausforderung-elastische-layouts/">Björn Seibert</a> nennt einige prominente Beispiele.</p> <h2>Wir optimieren uns zu Tode</h2> <p>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 <a href="http://aktuell.de.selfhtml.org/weblog/schriftgroesse">Schriftgröße</a> 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.</p> <h2><span lang="en" xml:lang="en">Viewport</span> statt Bildschirmauflösung</h2> <p>Zunächst einmal muss festgestellt werden, dass die <em>Bildschirmauflösung</em> 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 <dfn lang="en" xml:lang="en">Viewport</dfn>. Thomas Lahn hat diese grundsätzlichen Erkenntnisse einmal auf die Formel gebracht:</p> <blockquote> <p>Auflösung != Desktopgrösse != Browserfenstergrösse != Anzeigebereich. [psf 3.7]</p> <p><cite><a href="http://pointedears.de/psf/index.de#general">PointedEars' Standard-Floskeln</a></cite></p> </blockquote> <h2><span lang="en" xml:lang="en">Viewport</span>-Breite untersuchen</h2> <p>Zahlreiche <span lang="en" xml:lang="en">Counter</span> und <span lang="en" xml:lang="en">Tracker</span> fragen <a href="http://de.selfhtml.org/javascript/objekte/screen.htm#width">mittels JavaScript</a> 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.</p> <p>Interessant für Design-Entscheidungen ist hingegen eher die <span lang="en" xml:lang="en">Viewport</span>-Breite sowie ihr Verhältnis zur Auflösung. Die wenigsten Statistik-Scripte vermessen den Viewport. Unter diesen wenigen ist <a href="http://www.haveamint.com/" hreflang="en" lang="en" xml:lang="en">Mint</a>, siehe <a href="http://www.google.com/search?q=%22available+at+haveamint%22+%22window+width%22">Beispielstatistiken</a>.</p> <p>Hier im SELFHTML-Weblog habe ich eine ähnliche Statistik installiert, die mit JavaScript die <span lang="en" xml:lang="en">Viewport</span>-Breite sowie die Bildschirmauflösung untersucht und im Hintergrund zum Server übertragt, wo sie in einer Datenbank gespeichert wird. Dazu benutze ich <a href="http://www.quirksmode.org/viewport/compatibility.html#link2" hreflang="en">diesen einfachen Scriptschnipsel</a> von Peter-Paul Koch. Das <a href="http://aktuell.de.selfhtml.org/weblog/base.js">komplette Script</a> »spioniert« zudem noch einige andere Javascript-Eigenschaften aus, vor allem zu Studienzwecken.</p> <p>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 <a href="http://stats.selfhtml.org/webalizer/aktuell.de.selfhtml.org/">Webalizer-Statistik</a> eine JavaScript-Statistik etabliere wollte, bot sich erst einmal dieses Studienobjekt an. Zuerst begann ich damit, die <span lang="en" xml:lang="en">Viewport</span>-Größe aufzuzeichnen, später auch die Auflösung. Da das Layout dieses Weblogs im Allgemeinen bei verschiedenen <span lang="en" xml:lang="en">Viewport</span>-Breiten passabel aussieht, gehe ich davon aus, dass die Ergebnisse nicht durch an unsere Site angepasste <span lang="en" xml:lang="en">Viewport</span>-Breiten verfälscht wird.</p> <h2>Statistik über die Auflösungsbreite</h2> <p>Vorab, welche Auflösungen sind verbreitet, wenn wir der Eigenschaft <code>screen.width</code> Glauben schenken?</p> <p><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-aufloesung.png"><img src="http://aktuell.de.selfhtml.org/weblog/files/2006-04-aufloesung-k.png" alt="" title="Statistik über die Auflösungsbreite" /></a><br> 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.</p> <p>Eine Auflösungsbreite von 800 Pixeln scheint hier demnach nahezu überhaupt nicht mehr verbreitet.</p> <h2>Statistik über die <span lang="en" xml:lang="en">Viewport</span>-Breite</h2> <p>Interessant wird nun die <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span>-Breite gemessen wurde.</p> <p><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-gesamt.png"><img src="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-gesamt-k.png" alt="" title="Statistik über die Viewport-Breite" /></a><br> Zeitraum: 2006-02-25 bis 2006-10-30. Gezählte »Besucher«: 69375</p> <p>In einem weiteren Diagramm habe ich den interessanten Ausschnitt vergrößert dargestellt:</p> <p><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-gesamt-ausschnitt.png"><img src="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-gesamt-ausschnitt-k.png" alt="" title="Statistik über die Viewport-Breite, Ausschnitt" /></a></p> <p>Diese Diagramme sind so zu lesen: 80,6 Prozent aller »Besucher« haben eine <span lang="en" xml:lang="en">Viewport</span>-Breite größer als 1000 Pixel, hingegen nur 50,1 Prozent einen Viewport größer als 1040 Pixel.</p> <p>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 <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span>-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.</p> <h2>Statistik über die <span lang="en" xml:lang="en">Viewport</span>-Breite bei bestimmten Auflösungen</h2> <p>Während die beiden vorigen Diagramme die <span lang="en" xml:lang="en">Viewport</span>-Breite bei allen Auflösungen berücksichtigten, habe ich weitere Diagramme erstellt, die die <span lang="en" xml:lang="en">Viewport</span>-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.</p> <dl> <dt>800 Pixel:</dt> <dd><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-800.png"><img src="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-800-k.png" alt="" title="Verteilung der Viewport-Breite bei der Auflösungsbreite 800 Pixel" /></a></dd> <dt>1024 Pixel:</dt> <dd><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1024.png"><img src="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1024-k.png" alt="" title="Verteilung der Viewport-Breite bei der Auflösungsbreite 1024 Pixel" /></a></dd> <dt>1280 Pixel:</dt> <dd><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1280.png"><img src="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1280-k.png" alt="" title="Verteilung der Viewport-Breite bei der Auflösungsbreite 1280 Pixel" /></a></dd> </dl> <p>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.</p> <p>In diesen Diagrammen zeigt sich, dass von der Auflösung keinesfalls auf eine Standard-<span lang="en" xml:lang="en">Viewport</span>-Breite geschlossen werden kann. Wenn man für die Auflösungsbreite 1024 Pixel »optimiert« und von einer <span lang="en" xml:lang="en">Viewport</span>-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 <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span> zu vergrößern.</p> <h2 lang="en" xml:lang="en">Disclaimer</h2> <p>In meinen Messungen und Auswertungen sind viele Faktoren nicht berücksichtigt. Nicht zuletzt schließe ich methodische Fehler meinerseits nicht aus.</p> <p>Der Schluss, dass eine bestimmte feste Layout-Breite einen gewissen Prozentsatz der Besucher »ausschließt«, ist sicher nicht möglich. Die gemessenen <span lang="en" xml:lang="en">Viewport</span>-Breiten lassen nur Hypothesen darüber zu, was für die Differenz zwischen Auflösung und <span lang="en" xml:lang="en">Viewport</span> 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 <span lang="en" xml:lang="en">Viewport</span> 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.</p> <p>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 <a href="mailto:molily@selfhtml.org">E-Mail</a> einzureichen und dazu nicht die Kommentarfunktion zu nutzen.</p> <h2 lang="en" xml:lang="en">Download</h2> <p>Alle obigen Diagramme liegen samt Werte-Tabellen als OpenOffice-Calc-Dateien vor:</p> <ul> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-aufloesung.ods">Auflösungsbreite</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-800.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 800 Pixel</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1024.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 1024 Pixel</a></li> <li><a href="http://aktuell.de.selfhtml.org/weblog/files/2006-04-viewport-bei-1280.ods"><span lang="en" xml:lang="en">Viewport</span>-Verteilung bei 1280 Pixel</a></li> </ul> <p>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.</p>