Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Vom Tabellenlayout über RWD (Responsive Web Design) zu AWD (Adaptive Web Design)

Geschichtliches gefällig?

Mein erster Kontakt mit dem Internet erfolgte per 56-kbit/s-Telefonmodem (oder war es gar noch ein Akustikkoppler?). Das muss so um das Jahr 1995 gewesen sein. Die heutigen Digital Natives können sich vermutlich nicht vorstellen, was 56 kbit/s bedeutet (oder etwa doch? Wozu gibt es schließlich Mobilfunk und Edge?). Eine Webseite, die nur Text beinhaltete, baute sich zeilenweise im Verlauf von Minuten auf. Grafik auf Webseiten war zwar damals technisch schon möglich, aber Grafiken, die keinen Inhalt transportierten, also Schmuckgrafiken, zu verwenden, verbot sich unter solchen Umständen.

Gut, ganz so aussichtslos war die Situation auch damals nicht. Wenig später konnte ich an einem Pilotprojekt "Internet via TV-Kabel" teilnehmen. Wow! Der Speed war vergleichbar mit DSL, das Internet machte Spaß!

Das Medium Internet hat mich schnell gefesselt. Und bald wollte ich wissen, wie man so eine Webseite selbst erstellt. Nach kurzer Recherche — nein, nicht via Google; Google gab es 1995 noch gar nicht! AltaVista war angesagt — fand ich ein Programm namens FrontPage auf meiner Festplatte. Damit konnte man tatsächlich eine Webseite erstellen. Mir fiel allerdings auf, dass Änderungen an fertigen Seiten das Layout immer mehr zerschossen. Ich wollte der Ursache auf den Grund gehen. Bald entdeckte ich, dass Webseiten auch nur Textdateien sind. Halt mit einigen speziellen "Befehlen" angereichert. (Ja, ich weiß, HTML kennt keine Befehle; sei's drum.) Diese "Befehle" haben meine Neugier geweckt. Und tatsächlich, FrontPage war gar nicht nötig, um Webseiten zu erstellen. Ein beliebiger Texteditor, und das Wissen um einige wenige "Befehle" genügen.

Ich lernte HTML.

Natürlich sollten auch meine mit dem Texteditor erstellten Seiten ein ansprechendes Layout aufweisen. Das Mittel der Wahl war damals — bei FrontPage konnte ich das ja abgucken — Layouten mittels Tabellen. Dieses sogenannte Tabellenlayout war vom Printlayout inspiriert. Jedes Element wurde pixelgenau platziert. Ein wichtiges Hilfsmittel dazu war auch das sogenannte Null-Gif. Eine transparente Grafik von 1 x 1 Pixel Größe.

Diskussionen um Webdesign drehten sich damals vorwiegend um die Frage, ob man (noch) für 800 x 600 oder bereits für 1024 x 768 Monitore produziert.

Dass Layout für feste Seitenabmessungen aus der Print-Welt stammt, und dem Web nicht angemessen ist, und Tabellenlayout einen Mißbrauch darstellt (Tabellen dienen der übersichtlichen Darstellung von Daten!), ahnte ich, als ich erstmals von CSS hörte.

CSS

trennt das Layout vom Inhalt. Meine Probleme mit ständig zerschossenem (Tabellen-)Layout hatten ein Ende. Erst Jahre später entdeckte ich, dass es so etwas wie Barrierefreiheit auch für Webseiten gibt. Und wie elegant die Trennung von Layout und Inhalt mittels CSS Barrierefreiheit unterstützt. (Dass zu barrierefreien Webseiten mehr als das gehört, ist nicht Thema dieses Artikels.)

CSS ermöglicht beispielsweise Angaben, um die Lesbarkeit von Texten zu optimieren: Vorder- und Hintergrundfarben, Schriftarten und -größe, aber auch Zeilenabstände und sogar minimale und maximale Zeilenlänge konnten vorgegeben werden. Mit CSS hielt Flexibilität Einzug. Prozentuale Größenangaben, oder CSS-Angaben wie min-width und max-width, machten Schluss mit der fruchtlosen Diskussion um Monitorgrößen. Das Design konnte sich der jeweiligen Monitorgröße (genauer: Viewportgröße) anpassen.

Damit, und mit weiteren, fortgeschrittenen CSS-Techniken, z. b. float und position kann man schon recht flexibel layouten, und eine große Bandbreite von Monitorgrößen abdecken.

Tortendiagramm mobile Nutzung
Mobile Nutzung auf dem Vormarsch.
Hier: webdesign.weisshart.de.
Desktop: 67,6 %
Mobile: 25,7 %
Tablet: 6,7 %

Erst mit der Verbreitung von Smartphones stieß man mit reinen CSS-Techniken wieder an eine Grenze. Die kleinen Monitore von Smartphones erzwingen ein neues Denken über die "richtige" Anordnung von Seitenelementen. Aus mehrspaltigem Layout muss unterhalb einer minimalen Monitorgröße ein einspaltiges Layout werden. Seitenelemente wie Header, Navigation, oder Footer, die auf größeren Monitoren gerne auch feste (fixed) Positionen einnehmen, dürfen das auf Smartphones natürlich keinesfalls, weil fixierte Elemente keinen Platz für die eigentlichen Inhalte mehr freilassen würden. Bilder müssen eventuell durch Ausschnitte der Originalbilder ersetzt werden, weil der Inhalt des Originalbildes auf dem kleinen Monitor anders nicht mehr erkennbar wäre. Der Einsatz von Schmuckgrafiken muss eventuell reduziert, Schriften vielleicht größer dargestellt werden.

RWD

Diese oben genannten grundsätzlichen Anforderungen an das RWD (Responsive Web Design) können mittels Media Queries umgesetzt werden, die es seit CSS3 gibt. CSS3, und damit Media Queries, werden von allen modernen Browsern unterstützt. Media Queries erfordern kein Browser Sniffing und keine Browserweichen, sondern werden als Bereiche innerhalb ein und derselben CSS-Datei definiert. Entscheidend ist dabei das Konzept der Breakpoints. Breakpoints entscheiden, unter- bzw. oberhalb welcher Monitorabmessungen bestimmte CSS Regeln gelten. Häufig wird auch JavaScript zur Unterstützung von RWD eingesetzt. Beispielsweise, um Navigationsmenüs je nach Monitorgröße unterschiedlich darzustellen, oder gar erst nach einem Mausklick zu öffnen.

RWD sorgt also dafür, dass Webseiten auf allen Monitoren ansprechend angezeigt und vernünftig benutzt werden können, von winzigen Smartphones, bis zu riesigen Desktop-Monitoren.

RWD ist heute weitestgehend Stand der Technik, und wird auf zahlreichen Websites eingesetzt. Leider jedoch "vergessen" die meisten Webworker einen wichtigen Aspekt: Die Beschränkung der verfügbaren Bandbreite und des Transfervolumens im mobilen Bereich. Seiten mit 1 bis 2 MB "Gewicht" sind heute leider üblich, 3 und sogar 6 MB nicht selten. Wenn ich mit meinem Smartphone kein LTE oder wenigstens 3G habe, sind solche Seiten eine Zumutung, egal wie "schön" das (responsive) Design ist. Und selbst wenn LTE bzw. 3G verfügbar ist, bezeichne ich solche Seiten als rücksichtslos. Mein mobiles Datenvolumen wird mit mehreren MB belastet, obwohl RWD viele Inhalte "unsichtbar" oder unbenutzbar, und damit unnütz und überflüssig gemacht hat.

Man muss sich also Gedanken machen, was auf den kleinen Smartphone-Monitoren angezeigt, was weggelassen werden kann oder muss. Auch der lange Zeit verpönte Begriff "above the fold" gewinnt eine ganz neue Bedeutung. Was muss, was muss nicht auf den kleinen Monitoren ohne Scrollen sofort sichtbar sein? Siehe dazu auch LazyLoad weiter unten.

Vielleicht macht es Sinn, das Konzept an einem Beispiel zu erläutern:

Screenshot Desktop
Der Header mit dem Namen der Webpräsenz ist mit einer Slideshow aus 4 zufällig ausgewählten Bildern hinterlegt.
Das Navigationsmenü wird komplett angezeigt.
Das Bild mit der Ansicht des Objekts ist ebenfalls als Slideshow (3 wechselnde Bilder) ausgeführt.
Screenshot iPhone
Die beiden Slideshows wurden durch entsprechend kleine, statische Bilder ersetzt.
Das Menü wurde als Klappmenü ("Hamburger Menü") ausgeführt.
Auf der Desktop-Ansicht ausgeblendet, für Smartphones jedoch an prominenter Stelle: Die Anschrift, sowie 4 Buttons, die eine ggf. auf dem Smartphone installierte Navigationsapp aufrufen.

Jenseits von RWD

Was für Monitorgrößen gilt — es gibt nichts, was es nicht gibt — gilt auch für Bandbreite und Datenvolumen. Von GSM / Edge (maximal 384 kbit/s, häufig jedoch deutlich darunter, je nach aktueller Auslastung des Netzes) bis VDSL mit 50 MB/s und mehr kann die verfügbare Bandbreite betragen. Dazu kommt, je nach Mobilfunk-Datentarif eine Begrenzung des monatlichen Datenvolumens. 200 oder 500 MB pro Monat sind übliche Werte. Sparsamer Umgang mit der Dateigröße von Webseiten ist also unumgänglich, wenn RWD Sinn machen und nicht nur eine "Schönwetterveranstaltung" für Smartphones im (heimischen?) WLAN sein soll.

AWD = RWD + Conditional Loading

Um den mobilen Geräten wirklich nur das auszuliefern, was sie auch benötigen / anzeigen, sind weitere Techniken erforderlich, die ich unter dem Begriff AWD (Adaptive Web Design) zusammenfassen möchte. (Der Begriff AWD ist leider nicht etabliert, und wird sehr kontrovers definiert. Am ehesten noch würde ich folgende Definition teilen: www.sitepoint.com)

Zuerst und vor allem gilt dies für Bilder. Keinesfalls dürfen Bilder einfach vom Browser oder mittels CSS auf das passende (kleine) Anzeigeformat heruntergerechnet werden. Vielmehr muss Sorge getragen werden, dass die Bilder bereits in der passenden Größe (und damit Dateigröße) vom Server geliefert werden.

Eine vielleicht sogar seitenfüllende Slideshow etwa, die auf dem Smartphone (zurecht) nicht angezeigt wird (per Media Queries), darf gar nicht erst übertragen werden. Das gilt für die einzelnen Bilder, aber eventuell auch für das einige hundert kB schwere Script, das die Slideshow erzeugt. Glücklicherweise ist so etwas durch Abfrage des User Agents recht zuverlässig realisierbar: detectmobilebrowsers.com liefert fertige Scripts zur Abfrage des User Agents.

Anmerkung:

Ja, ich weiß, die Abfrage des User Agents ist unzuverlässig, weil der User Agent eventuell nicht übertragen wird, oder manupuliert werden kann. Beides ist im Falle von Smartphones allerdings recht unwahrscheinlich.
Zum anderen: Die Logik des Conditional Loading auf Basis des User Angents muss immer so angelegt werden, dass alle Inhalte angezeigt werden, falls der User Agent nicht erkannt wird.

Elemente von Webseiten, und was ist für AWD im Einzelnen zu beachten:

Das Ergebnis von AWD in der Praxis:

webpagetest.org ist ein geniales Online-Tool, um das "Gewicht" von Webseiten zu analysieren und zu optimieren.
Beispiel: Diese Seite "wiegt" auf dem Desktop 260kB, auf dem Smartphone nur noch 73 kB

Ja, ich weiß, von 260 kB auf 73 kB klingt nicht berauschend. Ich bin aber überzeugt, dass bei konsequenter Anwendung der beschriebenen Techniken sich eine Seite von 1 oder 2 MB Gewicht auf wenige hundert kB "eindampfen" lässt. Und das hat dann schon einen spürbaren Effekt, wenn man mobil surft.

Weiterführender Lesestoff

5 Kommentare

  1. Fabian schrieb am Dienstag, 25.11.14 18:49 Uhr:

    habe auch schon mal den Ausdruck RESS (Responsive Webdesign with Server Side components) gelesen für die hier beschriebene Vorgehensweise.

  2. Peter schrieb am Freitag, 06.03.15 15:38 Uhr:

    Zum Thema gibt es ein interessantes Interview mit Patrick Lobacher: http://goo.gl/36pDrB

    Beste Grüße aus Stuttgart

  3. Fritz schrieb am Freitag, 06.03.15 15:46 Uhr:

    @Peter

    Interessant ist insbesondere die Tatsache, dass Patrick Lobacher zwar über Responsive Web Design schwafelt, aber die eigene Unternehmenswebsite http://www.pluswerk.ag/ wird mit 2,8 GB an Smartphones ausgeliefert.
    Einer mehr in der Sammlung, der mit Schlagworten seine Produkte verkauft, aber nicht wirklich verstanden hat, wofür RWD.
    Hier der Beleg für meine Aussage

  4. Peter schrieb am Freitag, 06.03.15 16:26 Uhr:

    @Fritz
    Vielen Dank für die Analyse. Ich denke die Seite wird zum nächsten Relaunch entsprechend ausgestattet werden.
    Was sagen Sie denn zu unserer Seite http://www.andersundsehr.com mit RWD? Diese gehört zur Pluswerk AG.

  5. Miklos schrieb am Mittwoch, 11.03.15 15:14 Uhr:

    @Fritz
    2,8 GB ist wohl etwas zu viel. Ich denke es sind 2,8 MB also ca. nur ein tausendstel.

Ihr Kommentar zu diesem Artikel:

Über Ihren Kommentar oder Ihre Frage zu diesem Artikel freue ich mich. Ich behalte mir jedoch vor, Einträge wider die guten Sitten, unsinnige Einträge, oder Spam kommentarlos zu entfernen.