Responsive Design (technisches HowTo)

Was ist eigentlich Responsive Design und warum kommt man derzeit kaum noch darum herum? Welche Probleme kann man damit lösen und wie funktioniert das Alles technisch?

Auch wenn die heute eingesetzten Webtechnologien alle noch nicht besonders alt sind, ändern sich die Anforderungen und Möglichkeiten doch beinahe täglich. Transparente Bilder, Hovereffekte, Schatten und Farbverläufe sind Standard. Mittlerweile unterstützt (fast) jeder Browser JavaScript, CSS ist bei Versionspunkt 3, HTML gar bei Version 5 angelangt. Sogar der Internet-Explorer verursacht immer weniger Schmerzen und ist spätestens seit Version 9 wieder mit von der Partie.

Einige Probleme bleiben aber trotz aller Änderungen bestehen… Ich erinnere mich noch sehr gut an die Diskussionen, ob eine Website nur für 640×480 optimiert sein muss, oder ob man gar 800×600 voraussetzen kann. Darüber oder darunter gab es im Prinzip nicht viel. Mittlerweile ist es – was die Auflösungen angeht – deutlich vielfältiger und damit schwieriger geworden. Von Retina-Displays mit einer Auflösung von 2880×1800 Pixeln und mehr bis zum Smartphone mit teilweise nur 240×340 Pixeln soll die Homepage-/Webapp nicht nur „gerade so lesbar“ sein, sondern auch etwas hermachen. Eine Obergrenze ist noch nicht erreicht. Das Stichwort heißt Responsive Design. In diesem Artikel möchte ich mich mit diesem aktuellen Problem der Webentwicklung beschäftigen und aufzeigen, wie man mit diesem umgehen kann.

Responsive Design

… so lautet die Lösung für dieses Problem. Oft wird es auch mit Responsive Layout, Responsive Web, oder ganz einfach mit Responsiveness umschrieben. Leo Dict bietet für das Wort Responsiveness unter anderem die Übersetzung „Reaktionsfreudigkeit“, welche meiner Meinung nach am besten passt. Je mehr „Responsiveness“ eine Website besitzt, desto eher reagiert sie auf die Auflösungen und Anforderungen der unterschiedlichen Browser und Endgeräte.

Theoretisch muss man versuchen das Verhalten des eingesetzten Browsers und Betriebssystems möglichst nahe zu kopieren/imitieren und Buttons, Drop-Downmenüs, und Formulare möglichst ähnlich umzusetzen. So weiß der User sofort, wie er die Website/Anwendung zu bedienen hat und fühlt sich wohl. Niemand möchte auf seinem Gerät für jede Website oder Anwendung ein neues Bedienkonzept und Layout „erlernen“. Bei einfachen Buttons übernimmt der Browser dies meist noch selbst, aber sobald es tiefer ins Detail geht und komplexe Benutzeroberflächen oder gar komplette Mobile Apps umgesetzt werden sollen, stößt man hier an seine Grenzen.

Primär werde ich in diesem Artikel auf den Teilaspekt der verschiedenen Auflösungen eingehen. Das unterschiedliche Look- and Feel der Browser, die unterschiedlichen Bedienmöglichkeiten (Touch, Maus, Tastatur, …) und andere Responsive-Elemente seien vorerst außer Acht gelassen. Auf Wunsch werde ich diese später in weiteren Artikeln behandeln.

Das Wirrwarr der Auflösungen

Zunächst sind die reinen Pixelzahlen der Auflösung interessant. Über spezifische CSS-Anweisungen kann beispielsweise je nach Auflösung angegeben werden, wie sich der Inhalt auf der Seite verteilen soll. So können z.B. Inhalte auf Geräten mit einer höheren Auflösung (zum Beispiel Desktopgeräte) in mehreren Spalten, auf Geräten mit geringerer Auflösung (zum Beispiel Smartphones) jedoch nur einspaltig angezeigt werden. Neben diesen Pixelzahlen sind aber auch die sogenannten DPI („dots per inch“ – grob: „Bildpunkte pro Zoll“) interessant. Über diese kann die Zahl der Pixel in Relation zur tatsächlichen Größe des verwendeten Displays gesetzt werden. Bei selber Displaygröße aber unterschiedlichen DPI kann eine in Pixeln angegebene Schriftgröße auf dem einen Display bestens lesbar sein, während sie auf dem anderen Display zu unlesbarer Pixelsuppe wird.
Auch die Unterscheidung zwischen Landscape- (quer) und Portraitansicht (hochkant) ist durchaus interessant. Während in der Landscape-Ansicht zweispaltige Inhalte auf dem Handy vielleicht noch akzeptiert werden, sind diese im Portraitmodus oft besser in einspaltige Inhalte umzuwandeln.

Folgende Grafik vermittelt einen ungefähren Eindruck von den tatsächlichen Ausmaßen des Auflösungswirrwarrs:

Framework vs. Homemade

Da nahezu jede Seite mit den Auflösungsproblemen zu kämpfen hat, bieten mittlerweile zahlreiche CSS-Frameworks Hilfsmittel zur Lösung des Problems. Um das grundsätzliche Problem und die Lösungsansätze jedoch zu verstehen, und da die Frameworks zwar in vielen – aber doch nicht in allen – Problemen hilfreich sind, werde ich in diesem Artikel auf den Einsatz von Frameworks weitestgehend verzichten und einen Ansatz via „plain“ css diskutieren.

Dennoch rate ich dringend dazu, die vorhandenen Frameworks unter die Lupe zu nehmen und einen Einsatz zu erwägen. In den meisten Fällen spart man sich hier viel Arbeit. Bei Interesse wird hierzu auch noch ein Artikel folgen.

Der Einsatz von Mediaqueries

Die CSS-Mediaqueries sind der wichtigste (technische) Bestandteil von Responsive Design. Mit ihnen kann, neben den erwähnten Auflösungen, auch zwischen den Ausgabemedien (Bildschirm, Drucker, Audio, …), den DPI-Zahlen und weiteren Kriterien  unterschieden werden. Eingeführt wurden diese Selektoren mit dem CSS 2 Standard und HTML 4. Die Selektoren hierfür starten alle mit @media oder lassen sich wahlweise direkt im entsprechenden link-tag oder im CSS selbst mit angeben:

Link-Tag:

<!-- Media selector im Link-Tag: -->
<link rel="stylesheet" type="text/css" href="styles.css" media="screen and (min-width: 800px)" />

CSS:

/* media selector im css */
@media only screen and (min-width: 800px) {
  /* hier dann die Anweisungen */ 
}

In beiden Beispielen tritt der CSS Code aus der Datei style.css bzw. dem CSS innerhalb der geschweiften Klammern nur ein, wenn die Ausgabe auf dem Bildschirm (screen) erfolgt und die aktuelle Browserfenster-Breite mindestens 800 Pixel beträgt. Eine Liste zu den möglichen Ausgabemedien findet man auf Selfthml, die genaue Syntax und mögliche Optionen auf der entsprechenden Seite des W3C.

Es können beliebig viele Link-Tags oder Mediaqueries verwendet werden, um das Verhalten für verschiedene Auflösungen zu definieren. Zusätzlich zu der Angabe der min-width (minimale Breite) lässt sich auch eine max-width (maximale Breite), eine min-height (minimale Höhe) und max-height (maximale Höhe) definieren. Ferner gibt es die Schlüsselworte orientation: landscape bzw. orientation: portrait, mit welchen sich ermitteln lässt, ob der Browser im Landschafts- oder Protraitmodus ausgeführt wird.

Darüber hinaus gibt es noch weitere Media-Selektoren, die mit den anderen kombiniert werden können (siehe Selfhtml oder W3C). Erwähnenswert ist hier insbesondere das Schlüsselwort „resolution“, mit dem man sich auf die DPI beziehen kann:

@media (resolution: 96dpi) { 
  //hier css für mindestens 96dpi
}

Hochauflösende Bilder und die Retina-Auflösung

Zwar können viele Größenangaben in CSS auch ohne Pixelangaben gemacht werden (zum Beispiel in Relation zur normalen Schriftgröße (em) oder in Relation zur Größe des Elternelementes oder Viewports (%) – weitere: siehe hier), viele Webseiten bedienen sich aber auch sehr häufig direkt der Maßeinheit Pixel (px). Gerade wenn die Seite zunächst nur für eine Auflösung optimiert wird, ist der Gebrauch von px intuitiver und passt auch besser zu den pixelgenauen Vorgaben der Grafiker. Somit ist es nicht verwunderlich, dass ein Großteil der Webseiten stark auf die Verwendung von px als Größeneinheit setzt, auch wenn dies eigentlich nicht mehr zeitgemäß ist.

Spätestens seit der Einführung der Retina-Displays kommt es hier jedoch zum Problem. Eine Schriftgröße von „12px“ ist auf normalen Bildschirmen super lesbar, auf einem Retina-Display mit doppelt so hoher Auflösung bei gleichen Bildschirm-Maßen würde die Schrift jedoch dann so klein angezeigt, wie eine 6px-Schrift auf einem normalen Bildschirm (nur etwas schärfer).

Um dieses Problem zu umgehen werden normalerweise auf Systemen mit Displays mit einer sehr hohen DPI die Pixelangaben automatisch angepasst. Im Falle der Apple-Retina-Auflösung schlichtweg verdoppelt. Da Texte und Schriften grundsätzlich als Vektoren gerendert werden, sehen diese auch auf dem Retina-Display gestochen scharf aus, und auch die ganzen Abstands- und Größenangaben sollten sauber funktionieren. Schwieriger wird es hingegen bei verwendeten (nicht-Vektor-) Bildern.

Auf normalen Webseiten empfiehlt es sich, Bilder in exakt der Größe anzubieten, in der sie auf der Webseite eingebunden werden sollen. Soll ein Logo beispielsweise einen 400×200 Pixel großen Platz einnehmen, wird auch das entsprechende Bild in der angegebenen Auflösung gespeichert. Auf dem Retina-Gerät wird (wie auch bei den anderen Pixelangaben) die tatsächliche Bildgröße auf 800×400 gesetzt. Da das tatsächliche Bild jedoch nur in 400×200 vorliegt, wird es auf die 800×400 Pixel gestreckt und schaut entsprechend unscharf aus.

Ein naiver Lösungsansatz wäre, einfach alle Bilder in einer doppelt so hohen Auflösung zu speichern, wie normal benötigt. Leidtragende wären hier nur alle Nicht-Retina-Besitzer. Die geladenen Bilder würden durch die höhere Auflösung zum einen deutlich mehr Bandbreite benötigen und zum anderen wäre der Browser gezwungen das Bild auf die tatsächliche Größe zu schrumpfen. Das benötigt zum einen Rechenzeit (was aber eher vernachlässigbar ist), zum anderen sieht es meist nicht so gut aus. Je nach Browser kommen hier andere Verfahren zum Skalieren zum Einsatz, die mehr oder weniger gute Ergebnisse liefern. Vorzuziehen wäre hier definitiv ein schön im Voraus via Gimp (oder PhotoShop, …) skaliertes Bild.

Dank Mediaqueries bietet sich die Möglichkeit, beide Eventualitäten entsprechend zu behandeln. Via min-device-pixel-ratio lässt sich auf dieses automatische Hochskalieren reagieren. Die min-device-pixel-ratio gibt das Verhältnis der im CSS angegebenen Pixelgrößen zur tatsächlich verwendeten Displaypixelanzahl an. Im Falle eines normalen Retina-Displays ist das Verhältnis exakt 2 (da alle CSS-Pixelangaben exakt verdoppelt werden). Wobei auch niedrigere Werte verwendet werden können. Gerade bei Android-Devices kommen viele Geräte mit Pixel-Ratios zwischen 1 und 2 vor, für die man auch hochauflösendere Bilder zur Verfügung stellen kann. Hierbei sollte man es jedoch nicht übertreiben und nicht für jede etwaige Zwischen-Auflösung vorskalierte Bilder einbinden. In der Praxis hat sich ein Bild in normaler und ein Bild in doppelter Auflösung bewährt, welches für alle Geräte mit einer device-pixel-ratio ab zum Beispiel 1.3 eingebunden wird.

@media (min-device-pixel-ratio: 1.3) {
  /* hier retina optimierter code */
}

Für das Beispiel mit dem Logo wäre folgender Code denkbar:

//html:

<div class="logo">Mayflower.de</div>

//scss:

.logo {
  background-image: url('logo.png');
}

@media (min-device-pixel-ratio: 1.3) {
  background-image: url('logo2x.png');
  -webkit-background-size: 400px 200px;
}

Das Bild wird hier nicht per img-tag eingebunden sondern als Hintergrundbild eines anderen Elementes (zum Beispiel div ) gesetzt. So kann über die CSS Anweisung background-image die URL des Bildes entsprechend ausgetauscht werden.

Die zusätzliche Angabe der -webkit-background-size  wird benötigt, um dem Browser mitzuteilen, dass das angegebene Bild auf eine Fläche von 400×200 Pixeln (bzw. bei Retina auf 800×400 Pixeln) dargestellt werden soll. Ohne diese Angabe würde das Bild entsprechend in doppelter Größe angezeigt.

Bild-Beispiel:

Links: Das Logo normal in 47×47 Pixeln, Rechts: Das Logo in doppelter Auflösung, aber skaliert auf 47×47 Pixel. Auf einem Retina-Display sollte das rechte Bild schärfer aussehen (da das linke auf 94×94 hochskaliert werden muss), auf einem nicht-retina Display eventuell schlechter (da das rechte vom Browser auf 47×47 runterskaliert werden muss).

Icon-Fonts

Eine weitere Möglichkeit um die Auflösungsprobleme bei den Bildern zu umgehen können  sind (in begrenztem Maße) auch Icon-Fonts. Hier werden eine Vielzahl von Grafiken/Icons als Vektor-Grafiken in einer Schriftart gespeichert. Die Schriftart wird auf der Webseite eingebunden und durch das Setzen von font-family und Zeichen können die Icons verwendet werden.

Bei vielen dieser Schriftarten liegen auch noch CSS-Dateien bei, die bereits Klassen für die Icons vordefinieren und so die Benutzung vereinfachen. Als Beispiel für so eine Schriftart sei hier Font-Awesome genannt.

Für komplexere, buntere und größere Bilder eignet sich diese Variante jedoch nicht. Sie sollte nur für kleinere Dinge wie Menü-Icons, o.ä. verwendet werden. Für Logos bietet sich überdies noch die Variante als .svg-Datei an. Hier können einzelne mehrfarbige und komplexere Bilder im Vektor-Format eingebunden werden. Gerade für Logos macht dies oft Sinn. Jedoch sollten die Daten bereits als Vektorformat vorliegen.
Eine Vektorisierung ist meist nicht ganz trivial, funktioniert nicht bei allen Bildern (insbesondere nicht bei Fotografien) und lohnt den Aufwand (zumindest für diesen Zweck) meist eher nicht.

Wer eigene Icon-Fonts erstellen möchte sollte einmal einen Blick auf Birdfont oder IcoMoon werfen.

Mehrspalten-Layouts, aber bitte responsive!

Mehrspaltiger Text oder andere mehrspaltige Elemente sind beliebte Elemente des modernen Webdesigns. Allerdings macht eine solche Mehrspaltigkeit je nach Auflösung nicht unbedingt Sinn. Während auf einem 22″ Full-HD Bildschirm 4-5 Spalten bestens lesbar sind, möchte man auf seinem Smartphone nur maximal 1-2 Spalten angezeigt bekommen. Perfekt wäre es, je nach Auflösung (und DPI) des Zielgerätes eine unterschiedliche Spaltenanzahl anzuzeigen. Die Lösung? Klar: Responsive Design. Wie erreicht man das technisch mit reinem CSS?

Ausgehend von folgender HTML-Struktur soll ein CSS erstellt werden, welches entsprechend die Inhalte in drei, zwei oder einer Spalte anzeigt – je nach Auflösung.

<ul class="responsive-container col-3-2-1">
    <li class="column-element">Elem1</li>
    <li class="column-element">Elem2</li>
    <li class="column-element">Elem3</li>
    <li class="column-element">Elem4</li>
    <li class="column-element">Elem5</li>
    <li class="column-element">Elem6</li>
</ul>

Fangen wir direkt mit dem Ausrichten der Spalten-Elemente für Auflösungen von mindestens 600 Pixeln Breite an:

.responsive-container .column-element {
  display: block;
}
@media (min-width: 600px) {
  .responsive-container.col-3-2-1 .column-element {
    width: 33.333%;
  }
  .responsive-container.col-3-2-1 .column-element:nth-child(3n+1), 
  .responsive-container.col-3-2-1 .column-element:nth-child(3n+2) {
    float: left;
  }
  .responsive-container.col-3-2-1 .column-element:nth-child(3n+3) {
    float: right;
  }
}

Die Spalten-Elemente bekommen eine Breite von 33.333%, jeweils das erste und zweite Element einer Zeile bekommt float: left, das dritte float: right.

Zusätzlich werden alle Spalten-Elemente als Block dargestellt (unabhängig von der Auflösung).

Für das Beispiel wurden die Auflösungsgrenzen von 600px und 400px willkürlich gewählt und müssen entsprechend je nach bezwecktem Layout angepasst werden. Es sind hier keine Grenzen gesetzt, und man kann theoretisch zwischen beliebig vielen Auflösungen unterscheiden. Hier der Rest unseres Beispiels:

@media (max-width: 600px) {
  .responsive-container.col-3-2-1 .column-element {
    width: 50%;
  }
  .responsive-container.col-3-2-1 .column-element:nth-child(2n+1) {
    float: left;
  }
  .responsive-container.col-3-2-1 .column-element:nth-child(2n+2) {
    float: right;
  }
}
@media (max-width: 400px) {
  .responsive-container.col-3-2-1 .column-element {
    width: 100%;
  }
  .responsive-container.col-3-2-1 .column-element:nth-child(1n) {
    float: none;
  }
}

Für Auflösungen bis 600 Pixel möchten wir zwei Spalten (Breite von 50% und das erste Element der Zeile jeweils links, das zweite rechts ausgerichtet). Darauf folgt die Anweisung mit 100% Breite und kein Floating für die einspaltige Ansicht bis 400 Pixel.
Hier ist auch die Reihenfolge im CSS wichtig, da die zweite Anweisung (400 Pixel) die vorherige  überschreiben kann. Zwar gelten die Regeln aus der Mediaquery bis 600 Pixel nach wie vor, bei Auflösungen unter 400 Pixeln gelten die für die Mediaquery bis 400 Pixel aber auch. Da sie jedoch erst nach der Regel mit den 600 Pixeln steht, kann die Mediaquery die Effekte (Breite der Elemente und Floating) der ersten Query überschreiben.

Alternativ könnte man auch die Einschränkung der Auflösungen in den Mediaqueries noch weiter differenzieren:

@media (min-width: 600px) {
 /* 3 spalten */
}
@media (min-width: 400px) and (max-width: 599px) {
 /* 2 spalten */
}
@media (max-width: 399px) {
 /* 1 spalte */
}

So überschneiden sich die einzelnen Queries nicht.

Jetzt bleibt nur noch ein Problem: Wir haben das böse (manche mögen es, manche nicht. Ich mag es :)!) Floating verwendet. Der Container übernimmt deshalb die Höhe der in ihm beinhalteten Elemente nicht. Hierfür gibt es eine einfache Lösung:

.responsive-container {
  overflow: hidden;
}
.responsive-container .column-element:last-child:after {
  visibility: hidden;
  content: ".";
  display: block;
  height: 0;
  clear: both;
}

Der Container selbst bekommt overflow:hidden und nach dem letzten Spalten-Element wird ein unsichtbares Block-Element mit clear:both eingefügt. Jetzt hat der Container trotz Floating und ohne zusätzliche Markup-Anpassungen in allen modernen Browsern die richtige Höhe.

In einem entsprechend Mediaquery und nth-child-fähigem Browser sieht das Ergebnis dann wie folgt aus (leider unterstützt nicht jeder Browser die Mediaqueries, und auch mit nth-child haben einige Browser Probleme, doch dazu mehr im nächsten Abschnitt):

Einfach mal das Browserfenster ein wenig verkleinern und die Spalten verändern sich entsprechend.

Anmerkung: Das Beispiel funktioniert nur auf der nicht-https-Variante dieses Artikels. Den Code selbst und das volle Beispiel findet ihr entweder auf JSFiddle oder hier zum Download als reine CSS- oder als Compass-Datei (Wer Compass noch nicht kennt: Es ist ein wundervolles CSS Framework, das auf jeden Fall einen Blick wert ist. Bei Interesse werde ich hierzu auch noch einen Artikel veröffentlichen). Bei der Compass-Datei muss noch das .txt am Ende des Dateinamens entfernt werden, anders erlaubt WordPress den Upload leider nicht.

Anmerkung:
Der Einfachheit halber wurde in diesem Beispiel nur die tatsächliche Pixel-Auflösung in der Mediaquery benutzt. Da es mittlerweile aber auch Smartphones mit Full-HD Auflösung gibt, auf denen man aber trotzdem keine 4-5 Spalten anzeigen möchte, sollte man definitiv die DPI nicht außer Acht lassen!

Der InternetExplorer: Das gallische Dorf

Alle Browser stellen die Seite nun responsive dar. Alle Browser? Nein, ein „kleiner“ Browser weigerte sich hartnäckig – zumindest bis Version 9. Der InternetExplorer beherrscht Mediaqueries erst ab dieser Version (Siehe hier) und auch der CSS-Selektor nth-child  wird erst ab Version 9 unterstützt (Siehe hier). Der Pseudo-Selektor :after  ist erst ab Version 8 teilweise unterstützt (Siehe hier).

In InternetExplorer Version 6, 7 und 8 wird es folglich nicht funktionieren, zumindest nicht ohne Zutun. Die Diskussion darüber, welche Browser nun unterstützt werden sollten möchte ich hier nicht anschneiden. In manchen Fällen muss man dies einfach tun, sei es nun der Kundenwunsch oder der eigene.

Lösung für das nth-child

Um das Problem mit dem nth-child zu umgehen, bietet sich (allein schon aus Mangel an Alternativen) die Verwendung von JavaScript an. Selectivizr.js rüstet via JavaScript einige fehlende CSS Selektoren im InternetExplorer nach (unter anderem den nth-child-Selektor). Das Skript funktioniert soweit zuverlässig, aber nur dann, wenn das CSS statisch bleibt. Die CSS Dateien werden selbstständig von dem Skript analysiert und nicht-unterstützte Browserregeln werden nachgerüstet. Hierzu bedient sich das Skript anderer Bibliotheken wie zum Beispiel jQuery, die selbstständig erkannt werden. Bei nachträglichen Änderungen im CSS via JS funktioniert Selectivizr nicht mehr.

Nachrüsten von MediaQueries

Die dann immer noch fehlenden Mediaqueries können über den Einsatz eines weiteren JavaScript-Tools nachgerüstet werden. Respond.js heißt das Scriptlet, welches die min-width und max-width Selektoren im CSS via JavaScript nachbildet. Die Funktionsweise ist ähnlich wie bei Selectivizr: Die CSS Dateien werden geparsed und entsprechend ausgewertet. Die aktuell gültigen Regeln werden dem Head-Element hinzugefügt und entsprechend bei einer Größenänderung des Browserfensters angepasst.

Kombiniert man beide Scripte, erhält man tatsächlich auch im InternetExplorer 6 die Möglichkeit full responsive Webseiten mit Mediaqueries, nth-child und anderen CSS 2 bzw. 3 Features zu bauen, die normalerweise nicht unterstützt werden.

Vorsicht mit der Performance

Meine Tests waren durchaus zufriedenstellend, wurden jedoch auf einer VM auf einem aktuellen Rechner ausgeführt. Man sollte im Hinterkopf behalten, dass Rechner, die zum Beispiel mit einem InternetExplorer 6 ausgestattet sind vermutlich nicht mehr die aktuellste Hardware beinhalten und dementsprechend deutlich langsamer sind. Unter Umständen sollte man – wenn man denn wirklich diese alten Browser noch unterstützen muss – auf einige Effekte und Möglichkeiten verzichten und gezielt nur die wichtigeren Features  umsetzen.

Die Container-Höhe

Da der Pseudo-Selektor :after leider nicht durch Selectivizr unterstützt wird, muss hier eine andere Lösung für eine korrekt berechnete Container-Höhe gefunden werden. Zum Glück kann man den InternetExplorer in Version 6 und 7 bereits durch das Hinzufügen einer einfachen CSS-Anweisung dazu bringen, die Container-Höhe neu zu berechnen:

.responsive-container {
  *zoom: 1;
}

Fazit und Ausblick

In diesem Artikel wurde beschrieben, wie man mittels Mediaqueries alle gängigen Browser und unter zur Hilfenahme von JavaScript sogar den Internet-Explorer ab Version 6 dazu bringen kann, auf die unterschiedlichen Auflösungen und DPI der Browser zu reagieren. Gerne wird „Responsive Design“ auf dieses Feature begrenzt, in meinen Augen geht es aber noch einen ganzen Schritt weiter. Die Anwendung oder Webseite sollte sich möglichst nahtlos in den verwendeten Browser und dessen Betriebssystem einbetten. Der User sollte sofort wissen, wie die Seite zu bedienen ist. Hinter welchen Knöpfen verbergen sich Dropdowns, welche Formularfelder sind Pflichtfelder, welche Inhalte sind scrollbar und wo finde ich das Menü bzw. die Navigation? Das alles möchte der Besucher bzw. Anwender nicht erst mühsam herausfinden müssen. Apple hat hierfür einen mehrseitigen Katalog mit Designvorgaben für (Web-)Apps, die im Appstore landen sollen, doch ob man mit einer perfekt nach diesen Regeln umgesetzten Anwendung auch im Google Play-store Erfolg hat?

Man sollte auch beachten, dass eine Website oder Anwendung in den seltensten Fällen für alle Eventualitäten optimiert sein muss. Es macht durchaus Sinn, sich vorher genau zu überlegen, welche Ziel- und Usergruppen man erreichen möchte. Ein Portal für Rentner wird sicher auf andere Bedienelemente setzen müssen als eine Gaming App für Jugendliche. Auch wird hier unterschiedliche Hardware bei den Besuchern zum Einsatz kommen.

In einem Satz gesagt: Responsive Design ist also all das, was getan wird (bzw. werden muss) um dem Endbenutzer ein möglichst angenehmes Umfeld zu schaffen, in dem er sich auskennt und wohl fühlt. Es geht hierbei nicht darum eine Liste mit unterstützten Geräten abzuhaken, sondern der Zielgruppe ein angenehmes Umfeld zu bieten. Leider wird das Thema Responsive Design oft missverstanden und auf Dinge wie Auflösungen reduziert. Ich denke es ist ein sehr wichtiger Bestandteil und trägt maßgeblich mit zum Erfolg der Websites bzw. Anwendungen bei. Lieber ein paar Features weniger und dafür sauber und komfortabel bedienbar.

Wie sind eure Meinungen zum Thema Responsive Design? Welche Frameworks setzt ihr ein, für wie viele unterschiedlichen Gerätetypen optimiert ihr eure Seiten und Anwendungen und wie habt ihr eure Probleme mit dem Internet-Explorer gelöst?

Ich freue mich auf euer Feedback!