Vergesst Bildschirmauflösungen!
Oft wird in Artikeln und Diskussionen zum Thema Responsive Webdesign die Frage gestellt, welche Auflösungen, Breiten oder Geräte ein Layout bedienen solle. Man kann nicht oft genug betonen, dass diese Herangehensweise von einem falschen Verständnis der Technik zeugt. Daher: Vergesst Bildschirmauflösungen! (Vergesst auch Gerätetypen.)
Jeder kennt das Spiel Schere, Stein, Papier. Übertragen auf Responsive Webdesign müsste es eine Regel namens „Layout übertrumpft Auflösung“ geben. Denn es geht weder darum, eine Seite „für das iPad“ noch „für 768 Pixel Breite“ zu optimieren – das sind Relikte aus den Anfangstagen unserer jungen Zunft, in denen wir (viel zu) viel aus der artverwandten Print-Ecke übernommen haben.
Frage nicht, was das Display hergibt …
Ich glaube, dass jedes responsive Layout individuell umgesetzt werden sollte. Der entscheidende Aspekt dieser Technik sind die „breaking points“, also die Breiten, ab denen ein von Natur aus flexibles Basis-Layout nicht mehr vernünftig lesbar ist und mit Media queries korrigiert bzw. umgestellt werden muss.
Diese Punkte sollten aber nicht durch bestimmte Geräte und ihre Auflösungen definiert werden, sondern durch Layout und Design sowie die Frage, in welcher Auflösung sie funktionieren. Nebenbei macht dieser Ansatz ein bestimmtes Design auch zukunftssicherer in Bezug auf neu erscheinende Geräte.
… frage, wonach das Layout verlangt
Konkret prüft man also (unabhängig vom Gerät), innerhalb welcher Bereiche der Breite ein bestimmtes Layout „funktioniert“ und passt es außerhalb dieser Bereiche an. Das ist der entscheidende Unterschied dieser Technik zur vertrauten Vorgehensweise. Das wird noch klarer, wenn man sich des Ansatzes „mobile first“ bedient. Dann lautet die Frage auch nicht mehr, ab welcher Viewport-Breite ein Layout nicht mehr funktioniert – dann geht es darum, ab welcher Breite bestimmte Aspekte des Layouts und Designs erst möglich oder sinnvoll sind.
Eine Einschränkung in puncto Geräte gibt es, aber auch die sollte unabhängig von der Auflösung gesehen werden. Die meisten kleinen Displays sind heutzutage Touchscreens, für die man das Design durchaus anpassen sollte – in Form größerer Buttons und anders gestalteter Navigationselemente etwa.
Responsive Web Design ist also idealerweise quasi Progressive Enhancement für Layouts, ähnlich dem Ansatz, den Modernizr nutzt: Entscheidend ist nicht, welcher Browser eine Seite anfordert; entscheidend ist, was in diesem Browser möglich ist. Der gemeinsame Vorteil dieser Ansätze ist, dass sie uns unabhängig von Dingen machen, die wir ohnehin nicht hinreichend zuverlässig vorhersagen können – beispielsweise die Bildschirmauflösungen, mit denen unsere Webseiten betrachtet werden.
0 Trackbacks
Trackback-URL für diesen Eintrag
- Keine Trackbacks
13 Kommentare
Kommentar-Feed für diesen Eintrag
Patrick Bisenius am :
Das große Problem, das ich mit Responsive Webdesign momentan noch habe, ist der zwangläufig entstehende Overhead für alle Geräte. Sobald die Seiten komplexer werden und mehr Inhalt bereitgestellt wird, wird es problematisch, diesen auf Mobilgeräten mitzuschleppen.
Da das mobile Web leider immer noch ziemlich langsam ist, kann es durchaus einen Unterschied machen, ein paar KiloBytes zu sparen und eine separate Mobilversion anzubieten.
Responsive Webdesign ist natürlich trotzdem eine Sache und sollte auch betrieben werden, allerdings nur solange sich der Overhead noch in Grenzen hält bzw. noch alle ausgelieferten Informationen auch sinnvoll untergebracht werden können.
Und jetzt zerreißt mich in der Luft :)
Matthias Mees am :
Dass es nicht für alle Bandbreiten und Anwedungsfälle ideal ist, ist richtig. Allerdings stellt sich da schon das nächste Problem: Wie unterscheidest Du z.B. zwischen „Smartphone, unterwegs, dünne Verbindung“ und „Smartphone, zu Hause, WLAN“?
Ich glaube, dass dieser Teil nicht mit Responsive Web Design zu lösen ist – das ist aber auch nicht die Aufgabe des Designs.
Patrick Bisenius am :
Man sollte das Bedienkonzept ja nicht abhängig von der verfügbaren Bandbreite machen, sondern für möglichst viele Endgeräte eine vertretbare Lösung anbieten.
Oftmals ist es auch sinnvoll, dem mobil surfenden Nutzer ganz andere Funktionen zu präsentieren als dem Desktop-User. Beispiel Reiseführer: Der Desktop-User ist gerade bei der Urlaubsplanung, der Mobiluser bereits im Urlaub. Also biete ich dem Mobiluser mittels Geolocation Sehenswürdigkeiten in der Nähe an.
Responsive Webdesign macht da Sinn, wo der Hauptinhalt der Seite im Fokus steht (wie z.B. bei Blogs) und der optionale Content sich in Grenzen hält.
Matthias Mees am :
Da gebe ich Dir durchaus Recht – das ist aber eine ganz andere Argumentation als Overhead und Bandbreite. :)
Responsive Webdesign kann sicher nicht allein die User Experience optimieren, ich wüsste aber auch nicht, was dagegen spricht, es mit entsprechenden Maßnahmen wie etwa Geolocation zu kombinieren.
Patrick Bisenius am :
Das Problem “Overhead” hat man immer dann, wenn Sachen geladen werden, die man eigentlich nicht bräuchte. Und ich gehe jetzt einfach mal davon aus, dass der Smartphone-Surfer an meiner mit weiteren Navigationspunkten vollgestopften Sidebar kein Interesse hat, also sollte er es auch nicht herunterladen müssen (egal ob er per WLAN oder per GRPS unterwegs ist). Der Desktop-User wiederum hat kein Interesse an meiner “Diese Sehenswürdigkeiten in der Nähe könnten Sie interessieren”-Box.
So meinte ich das eigentlich bezüglich Overhead und unterschiedlichen Anforderungen unterschiedlicher Nutzer.
Matthias Mees am :
Mmh, in gewisser Weise kann man das ja schon jetzt mit Modernizr machen – Modernizr.load() hat ja z.B. einen Test für Touchscreens. Optimal ist das aber sicherlich nicht.
Vielleicht führt der beste Weg hier tatsächlich über Browser im weitesten Sinne, in etwa so, wie Readability eine Seite auf das Wesentliche reduziert, um die Lesbarkeit zu erhöhen. Ähnlich macht das anscheinend ja auch Opera Mini – komplexe (und auch nicht ganz so komplexe) Seiten für den Mobilnutzer linearisieren.
Patrick Bisenius am :
Man muss auch bedenken, dass irgendwann dieser Gesamtapparat mit den ganzen Abhängigkeiten und Bedingungen einfach unüberschaubar wird und somit dem KISS-Prinzip widersprechen würde.
Sven Dietrich am :
Aha. ja, vielleicht, vielleicht auch nicht. Das muss ich erst mal sackenlassen.
pascal am :
Was sind das denn für Bandbreitenargumentationen hier? Die meisten Websites sind mit unnötigem Code vollgestopft und meist nichteinmal komprimiert übertragen. Statt euch an euren Spezial-Mobilversionen festzuklammern (am besten mit eigener Domain und komplett anderem URL-Schema) lasst doch einfach die Kommentare und Whitespace weg, schrumpft CSS und Scripte und aktiviert Kompression (das kostet heutzutage nichts mehr, genauso wie SSL, und man kann es sogar cachen)
Frank am :
@Patrick Responsiv Design hat zunächst einmal nichts mit dem Content zu tun, der ausgeliefert wird, daher halte ich die Aussage, das sei nur etwas für Blogs schlicht falsch.
Weiterhin stelle ich mir in Bezug auf den Artikel die Frage: Wenn man als Designer nicht von den Möglichkeiten des Endgerätes (Stichwort Auflösung) ausgehen soll, wie weiss z.B. das Stylesheet, wann welche Buttongrösse auszuliefern ist?
Der Artikel dreht sich meiner Meinung nach ein bißchen im Kreis. Aber ich habe von dem Thema ja nicht soviel Ahnung… ;-)
Siehe: https://twitter.com/#!/flhh/status/94770892927799296
Matthias Mees am :
Tja, und dann minifizierst Du HTML und CSS, lieferst das gzipped aus – und stellst fest, dass z.B. das iPhone es ggf. eben doch nicht cachen kann, weil es (je nach Version) Dateien nur bis zu einer bestimmten Größe (15 oder 25 KB, wenn ich mich richtig erinnere) cachen kann – und zwar vor gzip gemessen.
(Nein, dass soll kein Argument dagegen sein, Code zu minifizieren und gzip zu aktivieren, da bin ich ich ganz Deiner Meinung.)
Matthias Mees am :
@Frank: Mit Modernizrs Test auf Touchscreens, der eine CSS-Klasse bereit stellt, mittels derer man den Button für solche Geräte umformatiert.
(Und ja, mit 5 Wochen Abstand habe ich auch den Eindruck, hier nicht immer die logischste Argumentation und Struktur verwendet zu haben. ;-))
Blockhaus am :
@ Patrick Bisenius: Ich vermute viele haben ein Problem damit. Ich bin zwar nicht wirklich ein guter Entwickler aber sobald ich was komplexes erstellen muss ist der Overhead bei mir auch total deformiert und klappt irgendwie nicht – nicht sofort zumindest :) erst durch viel Anstrengungen und Zeit klappt das dann schon besser.