Responsive Web: Status Quo

written by devangelist on September 12, 2013 in Allgemein and Browser and CSS3 and HTML and HTML5 and Javascript and Responsive Web Design with 2 comments

Man kann es nicht leugnen oder verdrängen – sogenannte responsive Webseiten sind der momentane Trend schlechthin. Aber wozu eigentlich die ganze Auffuhr? Rein technisch gesehen war das Web schon immer responsiv, es waren also wir, die Webentwickler, welche es in Containern mit fester Breite gesperrt haben. Es ist die Zeit gekommen, die Zügel zu lockern und den wahren Sinn hinter Responsive Web Design (RWD) zu verstehen.

Es entstehen immer mehr Artikel um dieses Thema, die meisten davon befürworte es, andere dementieren es. Grund dafür sind zwei getrennte Welten, nämlich jene der Desktops und jene der mobilen Geräte wie Smartphones. Und diese zwei Welten gilt es als stets getrennt anzusehen – so der jQuery mobile Entwickler.

Grundsätzlich ist es schon richtig – wer es sich leisten kann, für jedes Gerät eine komplett getrennte Version machen zu können (und auch zu warten!), ist klar im Vorteil – nur leider ist dies eher die Ausnahme als die Regel. Somit lassen wir den ewigen Streit beiseite und konzentrieren uns auf das wesentliche: Eine Webseite. Eine Webseite, für alle Geräte, sozusagen. Was vor einigen Jahren nur als Prophezeiung galt, ist mittlerweile Realität geworden: Mehr als 1/5 aller Besucher, von Bereichen wie Tourismus bis hin zu eCommerse, ist mit Smartphone und Tablet unterwegs, Tendenz steigend. Es muss schon ein sehr spezieller Bereich sein, wenn die Google-Analytics Auswertungen etwas anderes anzeigen. Apropos Google, seit kurzem gibt es die Google-AdSense auch für responsive Webseiten – schon gewusst?

Ich kann zwar sagen (oder raten), wie viele verschiedene mobile Geräte es im Moment gibt, aber ich kann nicht sagen, wie viele es in ein paar Jahren geben wird. Allein die Anzahl an verschiedenen Auflösungen, welche im Jahr 2010 noch unter 100 lag, ist mittlerweile auf über 200 geklettert. Der Gedanke daran, dass auf einem Gerät mit einer Diagonale von etwas mehr als 10cm (der bekannte 5-Inch Trend) eine FullHD-Auflösung passt, zeigt, dass die Evolution der Smartphones diese wieder größer werden lässt. Es erfordert immer mehr Flexibilität, immer mehr Unabhängigkeit und in diesen Zeiten kann es sehr gefährlich sein, eine Lösung zugeschnitten für ein Gerät zu erstellen. Also hören Sie auf den Rat, nicht mit dem Feuer zu spielen und lernen Sie alle Vorteile von RWD kennen.

Mobile first

Warum starten wir nicht einen Schritt weiter vorne – wo alles beginnt. Damit sind natürlich nicht nur die Designer gemeint, welche umdenken müssen (nein, bitte nicht jetzt UX auch noch!). Nein, keine Sorge – wir konzentrieren und auf die technische Seite und reden jetzt vom eigentlichen Kern – mobile First.

Good user experience is good for business

Es wird als erstes die Webseite für ein mobiles Gerät entwickelt. Dort gibt es am wenigsten Platz und genau das zwingt die Designer, sich auf das wichtigste zu fokussieren. Dieses nicht ganz unwichtige Detail, nämlich das worst-case-Szenario von vorne herein zu berücksichtigen, bringt einen großen Vorteil mit sich. Es geht darum, dem Besucher die wichtigsten Aufgaben zu ermöglichen, ohne irgendwelchen Schnick-Schnack.

Responsive Web: Mobile First

Vorteile:

  • Es können mehr Besucher erreicht werden
  • Designer werden gezwungen, sich auf das Wichtigste zu konzentrieren (Was machen, wenn man 80% der Fläche verliert?)
  • Progressive enhancement: Mit einer solchen Grundlage wird sichergestellt, dass es ein rudimentäres Level gibt, welches von allen Geräten zugänglich ist. Schichtweise kann dies erweitert werden, um jeden Besucher eine gute und optimierte Experience zu bieten.

Weitere Vorteile RWD:

  • Designer können die Vorteile der neuen Technologien nutzen (z.B. Standortbestimmung, etc.)
  • Eine zentrale Codebase
  • Minimiert Aufwand für Updates und für ein zukünftiges Redesign
  • Minimiert Maintenance-Aufwände
  • Verkürzt Release Zyklen
  • Es gibt eine zentrale URL Struktur (keine mobile-Subdomain oder Ähnliches)
  • Suchmaschinen-freundlich

Nachteile:

  • Eventueller, langsamerer Download, da die Seite mehr Code beinhalten kann
  • Längere Entwicklungszeit und damit verbunden auch höhere Entwicklungskosten
  • Ähnliche Userexperience auf jedem Gerät
  • Der Content ist auf jedem Gerät gleich

Für alle jene, die sich noch unsicher sind, ob RWD für sie etwas ist, gibt es eine kleine Checkliste, die bei der Auswahl vielleicht helfen soll

  • Braucht es denn die Webseite im Moment, oder gilt es, erst andere Teile zu optimieren?
  • Hat das Team die dazu benötigten Fähigkeiten (und auch den damit verbundenen Mehraufwand)?
  • Sind die Einschränkungen im Design bewusst (eine Seite für alle Auflösungen)?
  • Kann der Content so optimieren werden, dass für jeden Besucher (Desktop oder Smartphone) der richtige Content angezeigt wird?

Nicht alle Interpretationen von responsiven Webseiten sind gleich. Vergleichbar mit dem, was wir unter einem Auto verstehen: Wir alle wissen, dass es einen Motor hat, damit auch fahren sollte und dass es von günstig bis teuer sein kann. Das gleiche gilt bei RWD: Eine einfache responsive Webseite soll auf jedem Gerät angezeigt werden können und ist in der Erstellung relativ günstig. Eine gute responsive Webseite hingegen erfordert aber sehr viel mehr: Zum einen ist es der steigende Zeitaufwand, mit welchem natürlich auch höhere Kosten verbunden sind, als auch ein Umdenken in dem, was auf der Webseite wie präsentiert wird (mobile-first).

Neverending Story: Images

Spätestens seit Apples Einführung der Retina Displays und Googles Äquivalent XHDPI wird nicht nur versucht Bilder für kleine Auflösungen, sondern auch für Bildschirme mit einer besonders hohen Pixeldichte zu optimieren. Gelöst wird dies mit der Angabe device-pixel-ratio, welche für hohe Auflösungen auf kleinen Bildschirmen normalerweise einen Wert größer als 2 hat. Dass dies allerdings zum Performancekiller werden kann, liegt auf der Hand. Aber gut, nicht jedes Gerät besitzt eine solche Auflösung und rein technisch gesehen können diese highres-Bilder ohne Probleme nachgeladen werden. Dieser Trick funktioniert allerdings nicht, wenn es um verkleinerte Bilder geht, denn dafür muss schon etwas tiefer in die Trickkiste gegriffen werden.

Das <Picture> Element und das srcset-Attribut

Wie die beiden Namen schon sagen, handelt es sich hierbei um reine Markup-Lösungen, was natürlich optimal wäre – wären sie denn von allen aktuellen Browsern unterstützt.

Behandelt werden diese Lösungen in der Responsive Images Community Group mit dem Gedankenkonzept, verschiedene Bilder für verschiedene Geräte auszuliefern, was heißen soll, dass zum Beispiel kleinere Geräte ein Bild mit einer geringeren Auflösung bekommen. Inspiriert vom HTML 5 Video Element sieht die Syntax wie folgt aus:

<picture width="400"  height="400">
  <source  media="(min-width: 40em)" src="wasserflugzeug-hd.jpg">
  <source  media="(min-width: 15em)" src="wasserflugzeug.jpg">
  <source  src="wasserflugzeug-klein.jpg">
  <img  src="wasserflugzeug-klein.jpg" alt="">
  <p>Ready to take off!</p>
</picture>

Interessant an dieser Stelle ist die Möglichkeit, gecroppte (zugeschnittene) Bilder zu verwenden, um zum Beispiel auf einem kleinen Bildschirm nur einen ganz bestimmten, wichtigen Ausschnitt des Bildes anzuzeigen.

Responsive Images

Die zweite Lösung für ein responsive-Images-Markup, ist das srcset-Attribut, welches von Apple dem W3C vorgeschlagen wurde. Dieses unterscheidet sich vom <Picture>-Element in dem Punkt, dass es auf das gewohnte <img>-Element angewandt wird. Das Attribut stellt ein set, also einen Satz von Bildangaben zur Verfügung, aus welchem der Browser (Useragent) das passende aussuchen soll:

<img  alt="Ready to take off!"
  src="wasserflugzeug.jpg"
  srcset="wasserflugzeug-hd.jpg  2x, wasserflugzeug-phone.jpg 100w, wasserflugzeug-phone-HD.jpeg 100w 2x">

Sofort ins Auge stechen die etwas seltsamen Angaben, welche nicht immer auf Anhieb verstanden werden (was wohl auch dafür verantwortlich ist, dass kein Browser diese bis jetzt implementiert). Diese Komma-separierten Strings sind die Namen der Bilder, die Pixeldichte des Gerätes und die maximale Viewport-Angabe. Etwas vereinfacht ausgedrückt:

  • Wasserflugzeug.jpg: wird als Standard Bilddatei verwendet.
  • Wasserflugzeug-hd.jpg: Für Geräte, welche eine Pixeldichte (pixel ratio) von höher als 2 haben.
  • Wasserflugzeug-phone.jpg: Für Geräte mit einem max. Viewport von 100w.
  • Wasserflugzeug-phone-hd.jpg: Für Geräte mit einem max. Viewport von 100w und einer Pixeldichte von höher als 2.

Als Gegenpart dazu gibt es die image-set() CSS Eigenschaft. Diese ist allerdings noch W3C Editor’s Draft und funktioniert bis jetzt in Safari 6+ und Chrome 21+. Die Syntax ist dem srcset relativ ähnlich und sieht für dieselben Angaben wie folgt aus:

background-image: image-set( "wasserflugzeug.jpg" 1x,
  "wasserflugzeug-hd.jpg" 2x,
  "wasserflugzeug-druck.jpg" 600dpi );

Die einzig bekannte, funktionierende Lösung ist momentan auf JavaScript beschränkt. Ein Beispiel ist PictureFill. Dabei gibt es natürlich keinerlei neue HTML-Markups oder CSS-Properties, sondern nur ein paar SPANs mit einem HTML 5 kompatiblen data-Attribut:

<span data-picture data-alt="Ready to take off!">
    <span data-src="wasserflugzeug-klein.jpg"></span>
    <span data-src="wasserflugzeug-medium.jpg" data-media="(min-width: 400px)"></span>
    <span data-src="wasserflugzeug-large.jpg"  data-media="(min-width: 800px)"></span>

    <!-- Fallback content für non-JS browsers. -->
    <noscript>
        <img src="wasserflugzeug.jpg" alt="Ready to take off!">
    </noscript>
</span>

Zwischenlösung

Es gibt noch eine weitere Möglichkeit, mit Bildern umzugehen. Diese Lösung nennt sich adaptive images und ist aus RWD-Sicht mehr nur ein Hack, als eine elegante Herangehensweise, aber trotzdem kann sie zuverlässig funktionieren. Durch einen Mix aus Client und Server wird, je nach Geräte-Auflösung, ein zurecht geschnittenes (gecropptes) Bild ausgeliefert. Der Vorteil dabei liegt natürlich am HTML-Markup, denn dieses muss vorerst nicht geändert werden. Viel wichtiger ist die Aufgabe des Servers, denn jener muss das Bild on-the-fly croppen.

Step by Step: Damit der Server die Auflösung des Besuchers kennt, benötigt es noch eines Zwischenschritts: Der Client muss, bevor das erste Bild geladen wird, ein Cookie mit der Auflösung speichern. Dieses kann anschließend vom Server ausgelesen und als Richtwert verwendet werden. In JavaScript ist es zwingend nötig, das Cookie im Head zu setzen, denn dieser wird normalerweise als allererstes ausgeführt.

document.cookie = "screen_size=" + screen.width + "x" + screen.height;

Wenn das erste Bild geladen wird, sollte das Cookie bereits gesetzt sein und der Server sollte im Stande sein, es auszulesen. In PHP kann dies über die .htaccess gelöst werden, in ASP.NET beispielsweise über einen HTTP-Handler, welcher alle Aufrufe, endend auf .jpg, .png oder .gif entgegennimmt.

Es müssen natürlich nicht alle Auflösungen auf das Pixel genau vorliegen, sondern es reicht, wenn man sich für einige entscheidet und diese nach dem Crop-Vorgang auf dem Server im Cache ablegt. Kommt ein Besucher mit einer nicht vorhandenen Auflösung, wird die nächst-größere verwendet und dazu das Bild im HTML mit einer maximalen Breite von 100% angegeben.

img {
    max-width: 100%;
}

Beispielsweise bei den Auflösungen von 480, 768, 1024, 1200 und einer Breite des Gerätes von 700, würden die 768 verwendet.

Grid, Flexbox und was es noch so alles gibt

Es ist mit Sicherheit schon einmal vorgekommen, dass Sie komplexe Layouts mit einer großen Portion floats und inline-blocks gelöst haben. Es gibt ja auch nichts Schlimmes dabei, aber eine horizontale und vertikale Positionierung gibt es dabei, ohne JavaScript zumindest, nicht. Einmal davon abgesehen, ist es sehr unflexibel und vor allem für mobile Geräte sehr umständlich.  Also Schluss jetzt mit fluids und floats und her mit einer ordentlichen Lösung: flexible Layouts mit CSS3.

Flexbox

Das CSS3 Flexible Box Module, kurz Flexbox genannt, ist im Prinzip nichts anderes als ein neuer Layout Modus. Ein altbekanntes Beispiel für ein Layout Modus ist block (siehe display:block). Viele HTML-Elemente werden standardmäßig von den Browsern als Block-Elemente behandelt, wie zum Beispiel Paragraphe (p) und Divs. Wenn Elemente nicht block sind, dann können diese manchmal als inline bezeichnet werden (Anchor-, Input- oder Strong-Tag).

Mit dem neuen flex Modus können Elemente aber neu geordnet werden. So wird der Footer am Ende der Seite bleiben, die LIs werden wie kleine Spalten geschmeidig nebeneinander sitzen und Divs werden sich magisch anpassen. Schwachsinn? Nur, wenn Sie den IE9 und kleiner verwenden.

Um die Hexerei um Flexbox zu beherrschen, reicht eine Handvoll neue Eigenschaften. Alles startet mit einem flex-Container. Wenn ein Element erst einmal als flex definiert ist, werden alle Kind-Elemente den Regeln des Layouts und nicht dem des Standard block- oder inline-Regeln, folgen.

.flugzeuge {
    display: flex;
    flex-flow: row;
    justify-content: center;
}
.flugzeug { /* ... */ }

Die Elemente mit der Klasse flugzeug verhalten sich nun, wie vom parent-Element angegeben. Um die Flugzeuge nebeneinander anzuzeigen, wurde flex-flow: row verwendet, um sie zu zentrieren, justify-content: center. Sollen die Produkte hingegen untereinander dargestellt werden, dann kann das flex-flow auf column gestellt werden. Wenn der flow auf letzteres gestellt wird, dann wirkt sich das zentrieren auf den Abstand oben und unten aus (Anstelle von links und rechts).

flex-flow CSS3

Wer sich wundert, warum obiger Code nicht funktioniert: er war eher utopisch zu verstehen, denn es braucht neben dem flex auch die ganzen Präfixe wie -webkit-flex, mox-flex, usw. Für all jene, die SASS verwenden, könnte dieses @mixin helfen:

@mixin flexbox() {
  display: -webkit-box;
  display: -moz-box;
  display: -ms-flexbox;
  display: -webkit-flex;
  display: flex;
}

@mixin flex($values) {
  -webkit-box-flex: $values;
  -moz-box-flex:  $values;
  -webkit-flex:  $values;
  -ms-flex:  $values;
  flex:  $values;
}

...

CSS3 Grid Layout

Eine alternative Möglichkeit ist das sogenannte CSS3 Grid Layout. Dieses bietet, wie der Name schon sagt, ein flexibles Grid, mit welchem Elemente in Spalten und Zeilen, ohne eine fixe Struktur jedoch, angezeigt werden können. Als erster Schritt wird ein Container als grid definiert:

#container {
   display: grid;
}

#element1 {
   grid-column: 1;
   grid-row: 1
}

#element2 {
   grid-column: 3;
   grid-row: 1;
}

Als nächste Möglichkeit kann ein kleineres Grid für mobile Geräte definiert werden, bei welchem die Elemente anders positioniert werden. Dies ermöglicht natürlich einen gewaltigen Schub an Flexibilität. Das Grid-System wird von allen aktuellen Browsern unterstützt – allerdings erst ab dem IE 10.

Wenn es um reinen Content geht, gibt es auch die Möglichkeit mit CSS3 multiple-column-layout eine flexible Anzahl von Spalten zu erstellen. In Sachen responsive hängt die Anzahl der Spalten mit der Größe des Viewports zusammen. Es kann also dem Browser überlassen werden, wie viele Spalten (und vor allem wie Breit) erstellt werden:

.container {
  column-width: 10em; /* Spalten mit 10em Breite, Anzahl hängt vom verfügbaren Platz ab */
}
.container {
  Columns: 5; /* 5 Spalten, Breite wird anhand des Platzes definiert */
}

Perfect is the enemy of done

Es wird immer sehr viel Zeit damit verschwendet, die “beste” Lösung zu finden. Spätestens dann, wenn Sie ewig lange darüber grübeln, wie das HTML-Markup nun am besten sitzt und sich dabei im ungewissen sind, ob mit der Semantik noch alles stimmt, dann sollten Sie aufhören und absolute Positionierung bevorzugen. Wenn Sie über technische Entscheidungen nachdenken, denken Sie nicht über Design. Ihre Aufgabe ist es primär, eine Komponente, und nicht die gesamte Seite zu erzeugen.

SVG: Schöne neue Welt?

Eines steht fest: All diese Lösungen stecken noch in den Kinderschuhen. Ist aber vielleicht bereits der Ansatz falsch, nur am HTML und CSS zu schrauben?  Einen Schritt weiter gedacht könnte es auch neue Formate geben, welche uns eine bessere Kompressionsrate bieten. Die Idee dahinter ist nichts neues, denn zum Beispiel progressive JPEG images versuchen schon länger in diese Richtung zu gehen. Dabei werden, wie der Name schon sagt, die Bilder progressiv gerendert. Normale JPEGs werden nach dem top to bottom Verfahren gerendert, bei den progressiven wird hingegen als erstes ein unscharfes Bild geladen, welches nach und nach (progressiv) schärfer wird. Wenn dies auch die Performance nicht verbessert (das Bild muss ja letztendlich trotzdem geladen werden), gibt es dem Benutzer wenigstens die Möglichkeit, das Bild, wenn auch unscharf, sofort zu sehen und erhöht somit die Benutzerfreundlichkeit.

Auch Google bietet eine Alternative mit seinem WebP Format, welches um etwa ein Viertel kleiner als PNG und JPG ist. Das Format funktioniert in den meisten Browsern, allerdings nur über Umwege im Internet Explorer und erst gar nicht im Firefox, was es für den realen Einsatz letzten Endes leider wertlos macht.

Einen etwas anderen Ansatz ist es mit der Kompressionsrate der Bilder zu spielen. Es gibt ein Experiment (Retina revolution) welches mit verschiedenen Auflösungen und Kompressionsraten spielt und dabei auf interessante Lösungen stößt: Wird das Bild mit der doppelten Auflösung als die benötigte, jedoch mit einer höheren Kompressionsrate abgespeichert, dann wird das Bild im Speicherverbrauch kleiner und kann sowohl auf normalen, als auch auf Bildschirmen mit einer hohen Auflösung noch gut angezeigt werden.

Bilder Pixelunabhängig darzustellen wäre ein Reiz, mit welchem nicht nur Designer konfrontiert sind. Mit dem SVG (Scalable Vector Graphics) Format zum Beispiel, können Vektorgrafiken unabhängig von der Auflösung immer perfekt angezeigt werden. Dazu glänzen sie in ihrer Speichergröße, skalieren ohne Qualitätsverlust und sind somit perfekt Retinatauglich. Im Browser funktionieren sie so gut wie überall, außer im IE 8 und kleiner, sowie Android < 2.3. Allerdings gibt es auch hier Workarounds, wie zum Beispiel mit JavaScript-Fallbacks:

<img src="image.svg" onerror="this.onerror=null; this.src='image.png'">

Alternativ dessen Support mit Modernizr zu testen um auf das Normale Format zu wechseln:

if (!Modernizr.svg) {
  $(".logo img").attr("src", "images/logo.png");
}

Oder Plugins wie SVGeezy zu verwenden.

Auch sogenannte Font-icons gehen in diese Richtung und der Trend auf die Pixelunabhängigen Grafiken ist klar erkennbar.

Das Ende der Pixelbasierten Layouts

Sogenannte Viewport-percentage lengths können das Ende der absoluten Angaben bedeuten, denn sie verhalten sich relativ zu der Größe des zuerst beinhaltenden Blocks. Das bedeutet, dass eine Breite des Viewports von 480 eine Einheit von 1 vw gleich 4,8 Pixel sind. Vw ist die Angabe für die Breite, dazu gibt es noch vh für die Höhe, vmin und vmax für die jeweils kleinere oder größere Angabe von vw und vh. Interessant ist dabei die Möglichkeit, eine Box mit echter 100% Höhe zu machen, ohne sich durch die ganzen Parent-Elemente der Box zu hacken.

So schön diese Angaben auch klingen, sie haben im Moment noch einen großen Hacken: Sie werden nicht von aktuellen Android Browsern unterstützt. Wer also diese Angaben einsetzen möchte, muss sich noch etwas gedulden.

Schrift

Auch bei der Schrift gilt dasselbe: Weg von festen Angaben! Eine Lösung dafür gibt es eigentlich schon seit längerer Zeit, nämlich mit der em-Einheit. Diese verhaltet sich für ein Element relativ zu seinem parent und sind auf jedem Fall eine große Hilfe unabhängig von den Pixeln zu werden. CSS 3 hingegen führt eine neue Einheit ein: rem. Elemente mit dieser Schriftangabe verhalten in sich im Vergleich zu den altgewohnten em nicht relativ zum Elternelement, sondern relativ zum Viewport, was besonders für responsive Webseiten von Vorteil sein kann. Wenn zum Beispiel das html eine feste Schriftgröße hat, können alle anderen bei einer Änderung davon profitieren:

html {
  font-size: 14px;
}

h1 {
  font-size: 1.5rem; /* Das sind 21px */
}

@media screen and (max-width: 480px) {
  html {
    font-size: 12px;
  }

  h1 { /* Hat eine Größe von 18px */ }
}

Andere Elemente: Forms

Vor allem lange Formulare sind ein Killer-Element für responsive Webseiten. Unzählige Textfelder auf einem mobilen Gerät auszufüllen kann zur echten Herausforderung werden. Vom Design her gesehen, werden die Textboxen einfach auf die volle Breite gezogen, eines pro Zeile.

Ein Grundprinzip von Formularen für mobile Webseiten ist jenes, vor allem Checkboxen, Radio Buttons und Select Drop-Down Menüs zu verwenden. Dazu sollten Fehlermeldungen nicht erst beim drücken des Send-Buttons angezeigt werden, sondern on-the-fly, denn die meisten Formulare sind länger als ein mobiler Bildschirm hoch. Wenn sich ein Benutzer also vertippt hat, kann dies problematisch werden, ihn darauf aufmerksam zu machen.

Dank HTML5 gibt es neue Möglichkeiten, Input Elemente mit Attributen zu gestalten. So kann man zum Beispiel mit dem require-Attribut und ohne großen JavaScript-Code sofort festlegen, dass es sich um ein Pflichtfeld handelt.  Dazu gibt es auch neue Form-Controls wie z.b. ein number-, date-, range- oder email-Input. Der Vorteil bei den mobilen Geräten liegt darin, eine spezielle Tastatur anzeigen zu können. Bei Telefonnummern zum Beispiel haben Buchstaben nichts verloren, beim Email-Input hingegen wäre das @-Zeichen sehr wichtig. Auch das date-Input hat seine speziellen Anwendungsfälle. Während bisher so gut wie immer ein Datepicker verwendet wurde, kann dieser auf mobilen Webseiten manchmal irritierend wirken, da er zum Teil über den Bildschirm hinausragen kann und andererseits viel zu klein für ein “touch” ist. Interessanter sind dabei die bereits von mobile Safari und Chrome für Android unterstütze Date-Funktion:

HTML5 Date Input (iOS und Android)

Navigation

Dass sich die Navigation auf den mobilen Geräten anpassen muss, steht fest. Es geht jetzt um die Art und Weise, wie sie dies macht. Immer wieder sieht man Menüs, welche sich ab einer gewissen Auflösung in Dropdown-Listen konvertieren. Dies mag zwar funktionieren und für wenige Menüpunkte auch übersichtlich sein, ist aber letztendlich keine saubere Lösung, denn spätestens wenn es mutli-level Navigationen und dementsprechend viele Menüpunkte gibt,  wird die Navigation der Webseite zur echten Herausforderung.

Viel schöner hingegen ist das ausklappbare Menü, welches mittlerweile die breite Masse erreicht hat. Ab einer bestimmten Auflösung wird das Menü versteckt und kann anschließend mit dem Menü-Link (Liste-Icon) eingeblendet werden.  In fast allen Fällen befindet sich dieses Icon auf der rechten Seite des Bildschirms, da diese leichter zu erreichen ist, wie auch Luke Wroblewski in seinem Artikel zeigt.

Auch hier gibt es keine Schwarz-Weiß Auswahl zwischen den Möglichkeiten, denn bis jetzt ist keine in jedem Fall perfekt. Allerdings haben sich bereits andere Leute den Kopf darüber zerbrochen und an dessen Erfahrungen kann man natürlich angrenzen.

Responsive Navigation

Touch

Für die meisten liegt der Unterschied zwischen mobilen Geräten und Desktops in der Touch-Fähigkeit. Natürlich ist dies nur bis zu einem bestimmten Punkt korrekt, allerdings gibt es ein Problem, welches direkt davon betroffen ist: Die :hover CSS-Pseudo-Klasse kann auf Touch-Geräten nicht verwendet werden. Es gibt zwar eine Fallback-Möglichkeit, dass diese zum Beispiel bei einer Berührung ausgeführt wird, allerdings kann (und sollte) man sich darauf nicht verlassen.

Die W3C working group hat allerdings begonnen, an einer Spezifikation für die Registrierung von Touch-Events begonnen. Somit wird es in Zukunft einen Standard für Events wie touchstart, touchmove und touchend geben. In der Zwischenzeit gibt es thirt-party Frameworks wie Hammer.js.

Auch mit CSS soll es in Zukunft eine Interaktion mit Touch-Events geben. Die CSS Level 4 spezifiziert eine neue Media Query „pointer“, mit welcher die Genauigkeit eines Gerätes, wie zum Beispiel einer Maus erkennt werden kann. Diese Media Query kann durch die folgenden drei Werte gesteuert werden:

  • none (kein Gerät erkannt)
  • coarse (Ungenau, wie zum Beispiel eine Fingerberührung auf einem mobilen Gerät)
  • fine (Genau, wie zum Beispiel eine Maus oder ein Stylus)

Mit dieser Media Query gibt es endlich die Lösung für ein altbekanntes Problem: Buttons größer anzuzeigen, wenn man keine Maus zur Verfügung hat:

@media (pointer:coarse) {
   input[type="submit"],
       a.button {
       min-width: 30px;
       min-height: 40px;
       background: transparent;
   }
 }

Diese Media Query wird im Moment kaum unterstützt, hat aber großes Potenzial, denn sie würde den Aufwand enorm reduzieren.

Die CSS Level 4 Hover Media Query hat nichts mit der gewohnten :hover Pseudo-Klasse zu tun, denn die Media Query gibt einen boolischen Wert zurück, falls das Gerät hover unterstützt. Damit können bestimmte Features ausgeblendet werden, falls kein hover unterstützt wird um somit die Benutzerfreundlichkeit zu erhöhen.

JavaScript & APIs

Es gibt bereits seit längerem die Möglichkeit, mit JavaScript auf bestimmte Gerätefunktionen, wie zum Beispiel das GPS-Signal oder auf die Geräte-Orientierung, zugreifen zu können. Das W3C hat beispielsweise auch eine vibration-API vorgeschlagen. Damit wäre es für die Webseiten möglich, direkt Feedback zu geben, wobei dieses Features wohl viel mehr für Browser-Games interessant sein wird.

Auch die Network Information API wird heiß diskutiert, denn die damit verbundene Möglichkeit, die Bandbreite zu messen um damit bestimmten Inhalt auszuliefern, hat großen Anspruch bei vielen Entwicklern gefunden. Auch bei diesem Thema werden wir noch jede Menge spannende Entwicklungen erleben, denn diese Technologien sind, insbesondere im Web, gerade am Anfang.

Performance

Fast jeder User ist der Meinung, dass mobile Webseiten zu langsam laden. Dies mag zwar zum Teil am Gerät und an der Internetverbindung liegen, kann aber manchmal auch an verschiedenen Faktoren wie dem Aufbau der Seite liegen. Eine Verzögerung (Delay) von einer Sekunde kann für manche eCommerse Seiten einen fatalen Einfluss haben und zu teilweise stark sinkenden Konversionsraten führen. Im Jahr 2013 liegt die durchschnittliche Seitengröße bei 1,4MB, während sich die Ladezeiten der Top 2.000 Seiten bei 6-10 Sekunden bewegt. Getestet werden kann dies beispielsweise mit webpagetest.org und ähnlichen Tools, oder aber mit verschiedenen web inspectors. 86% aller responsiven Webseiten senden denselben HTML-Code an alle Geräte. Während vor einigen Jahren versucht wurde, auf Browser zu optimieren, wird heute versucht auf Gerätebasis zu optimieren.

Prefetching

Also, geht es darum, zu viele http Requests zu machen, ist die Latenzzeit zu hoch oder werden zu viele Bytes übertragen? Oder ist einfach nur ein falsches Caching Schuld? Das Problem mit der Latenz wird zum Teil ja von LTE gelöst, wobei dies nur die Zeit pro Request minimiert, nicht aber die Anzahl der Requests reduziert. Oft ist von pre-fetching die Rede, also vom Vorladen von bestimmten Ressourcen. Wenn es denn von Anfang an klar ist, nach welchem Muster sich ein Besucher auf der Webseite bewegen wird, kann dies auch gemacht werden. Andernfalls wird nur eine Menge unnötiger Bandbreite, CPU und somit auch Akku des mobilen Gerätes verbraucht. Vorgeladen werden sollten vor allem: DNS, HTML, CSS, JavaScript und Bilder.

Auch sogenannte blockierende Ressourcen können ein Problem darstellen. CSS-Dateien zu laden kann ein solches Problem sein, denn die Seite wird erst angezeigt, wenn das CSS da ist. Auch hier kann es helfen, den gesamten Code auf verschiedene Dateien zu splitten und je nach Anforderungen nur den benötigten Teil zu laden, oder wie vorhin erklärt, den am Anfang nicht benötigten Teil vorzuladen. Dasselbe gilt natürlich auf für JavaScript-Dateien, wobei es hier meistens etwas komplexer wird. Eine weitere Alternative ist jene, bestimmte CSS-Dateien (oder auch Schriften und Bilder) mit JavaScript nachzuladen.

Natürlich sollten (nicht nur bei RWD) Ressourcen wie JavaScripts und Stylesheets minified und gzipped sein und Third-Party-Widgets asynchron geladen werden (für die meisten, wie zum Beispiel Facebook, Twitter, Google Analytics, etc. gibt es eine asynchrone Variante).

Fazit: Geräte kommen und gehen, der Content und die Ziele bleiben

Eines steht fest: Responsive Webdesign ist sehr viel mehr als nur ein paar Media Queries und Bildvergrößerung für Retina-Screens. Viel wurde getan, aber es gibt noch umso mehr zu tun, denn viele Probleme wurden noch nicht gelöst und vor allem an genau passenden Lösungen mangelt es. Während es bei manchen Desktop-Browsern noch an der Unterstützung von all den neuen Techniken mangelt, werden diese von den meisten mobilen Browsern durchaus unterstützt. Da es ja vor allem darum geht, Webseiten auf alternativen Geräten anzuzeigen, steht dies definitiv im Vordergrund. Die Technik ist jedenfalls reif genug für den Einsatz, es führt also kein Weg mehr dran vorbei!

Responsive Web: Status Quo: 1 Stern2 Sterne3 Sterne4 Sterne5 Sterne 4,93 von 5 Punkte, 14 abgegebene Stimmen.
Loading ... Loading ...

About the Author

Roberto Bez ist passionierter Webentwickler und TechLead bei der HolidayCheck AG. Für Roberto bedeutet das Entwickeln nicht nur Arbeit, sondern auch Freude, Motivation und täglich neue, aufregende Herausforderungen. Besonders gerne setzt er sich mit neuen Webtechnologien sowie Datenbanken aller Art auseinander und versucht diese in die tägliche Anwendungsentwicklung miteinzubringen. Neben dem Entwickeln trifft man ihn gerne Abends beim Laufen oder im Sommer bei Mountainbike-Touren durch die schönen Berge Südtirols.