Responsive Baustellen
Es ist kein Geheimnis, dass Responsive Web Design nicht länger nur „sowas Neues, was jetzt viele Designer ausprobieren“ ist. Ich glaube allerdings nicht, dass es bereit für den Einsatz auf ganz großen Portalen mit komplexen Layouts ist. Noch nicht. Zu jung ist die Technik als solche, speziell die benötigten Komponenten wie etwa fluide Grafiken. Aber es entwickelt sich.
Media-Query-Krücken
Bekanntlich unterstützen verschiedene ältere Generationen gängiger Browser die Kernkomponente @media in Kombination mit Dimensionsangaben nicht. Das gilt nicht nur für den allseits beliebten Wunderbrowser aus Redmond, aber dort fällt es ins Gewicht – der gemeine Nutzer von Firefox, Chrome & Co. ist ja eher updatefreudig (und in der Lage dazu).
css3mediaqueries.js schien mir bislang die ausgereifteste Lösung, doch nun holt respond.js merklich auf. Es ist schmaler und nicht ohne Tücken, wird aber aktiv entwickelt. In neuester Version kommt es ohne den Kommentar hinter der schließenden Klammer eines @media aus, womit es kein Problem mehr ist, das zugehörige Stylesheet zu minifizieren. Vor allem aber: respond.js ist neuerdings Teil von Modernizr, womit man sich einen HTTP-Request sparen kann, wenn man Modernizr ohnehin nutzt.
Kleiner Bildschirm vs Navigation
Ein echter Stolperstein ist es nicht, eher eine „kreative Einschränkung“ – Aufbau und Gestaltung von Navigationen in Layouts für ganz kleine Bildschirme wie etwa die 320×480 Pixel eines Smartphones. Klassische Navigationsdesigns, wie man sie von altbekannten Auflösungen her kennt, funktionieren da nur selten, ganz haarig wird es natürlich, wenn eine zweite Ebene oder gar eine Dropdown-Navigation verwendet wird.
Die Alternative für kleine Bildschirme soll kompakt sein, gleichzeitig aber möglichst große Flächen und/oder Schriften haben, damit man sie selbst mit den übelsten Wurstfingern auf einem Touchscreen noch bedienen kann. Da hat man rasend schnell den (ersten) Bildschirm nur mit 5 bis 6 Menüpunkten gefüllt, aber es sollte ja zumindest auch noch eine Andeutung von Inhalt erscheinen …
Der bisher pfiffigste Lösungsansatz, den ich bislang dazu gesehen habe, ist es, die Navigation am Ende des Quelltextes auszugeben und am Seitenanfang lediglich einen Skiplink zur Navigation zu verbauen – quasi das etwas andere „content first“. Auf größeren Auflösungen holt man die Navigation dann mit position: absolute; nach oben und verbirgt den Skiplink mit geeigneten CSS-Mitteln.
Das Buch
Last, but not least liegt mit Responsive Web Design aus der allgemein ganz hervorragend gemachten und sehr lohnenswerten A Book Apart-Schmiede nun das gedruckte Standardwerk zum Thema vor. Dazu mehr, sobald ich mein (gedrucktes) Exemplar in den Händen halte.
2 Kommentare
Jens Grochtdreis
Responsive Webdesign ist wie jeder andere Ansatz EIN Beitrag zur Lösung der Frage: "Wie realisiere ich mein Layout?" Es gibt dafür nicht DIE Antwort. Es wird sie sicherlich auch nie geben.
Eines der größten Probleme ist sicherlich die aktuelle teilweise Abhängigkeit von Javascript, wenn man denn den IE bis einschließlich Version 8 ebenfalls mit anpassbaren Layouts beglücken möchte.
Viel größere technische und grundsätzliche Probleme sehe ich aber darin, dass die Browser immer erstmal alles runterladen und dann mal schauen, ob sie es brauchen. Das steigert die Reaktionszeit, hemmt aber die Performance.
Selbst wenn wir mit Javascript dafür sorgen, dass Resourcen nur in bestimmten Breiten geladen werden, haben wir nicht die Lösung aller Probleme. Denn dann müssen wir wieder auf die Bilder, evtl. Headerbilder, warten.
Ein Teufelskreis. Ich finde die Idee schön und mediengerecht, finde aber zuviele Macken in der Realität. Oder ist das nur wieder typisch deutsch? :-)
Matthias Mees
Ich empfinde das nicht als Abhängigkeit -- ganz abgesehen davon, dass denen, die heute noch im IE ohne JS unterwegs sind, ohnehin nicht zu helfen ist. ;-)
Zumindest in puncto @media geht es ja auch ohne. Man liefert dann halt für die Browser, die es nicht können, ein fluides Desktop-Layout aus. Da man offenbar bestrebt ist, den mobilen Windows-Versionen zügig einen neuen IE zu verpassen, dürfte das sogar recht passabel funktionieren.
Die Ressourcen-Problematik sehe ich ähnlich, zumal man kaum Seiten finden wird, in denen alle Grafiken Hintergründe sind (die könnte man ja z.B. mit yepnope/Modernizr auch konditionell nachladen).
Da kommt aber ergänzend hinzu, dass man das Nachladen solcher Ressourcen meines Erachtens nicht unbedingt (rein) von der Auflösung abhängig machen sollte. Wenn ich mit dem Smartphone im heimischen WLAN hänge, juckt es mich ja nicht wirklich, wenn Bilder nachgeladen werden, mobil schon eher.