Tip:
Highlight text to annotate it
X
Responsive Webdesign und Mobile First Vor 10 Jahren war die Welt noch einfach: Wenn
man dort eine Webseite machen wollte, hat man die für irgendeine Version von Internet
Explorer ausgelegt, für ein Monitorverhältnis von 4:3 und wahrscheinlich mit einer Auflösung
von 1024×768 Pixeln. Irgendwann kamen dann andere Monitorformate
hinzu, andere Auflösungen, andere Größen, auch andere Browser wurden relevant. Das heißt
man hatte verschiedene Bildschirme, verschiedene Auflösungen und verschiedene Größen. Aber
was alle diese Bildschirme miteinander verband, war dass sie alle für Desktopanwendungen
ausgelegt waren. Und genauso waren es die Webseiten.
Das änderte sich im Jahre 2007, als ein Produkt eingeführt wurde, das wir alle kennen und
teilweise lieben, teilweise hassen, nämlich das iPhone. Das iPhone ist insofern relevant,
als dass es das erste Smartphone war, mit dem man wirklich ernsthaft Surfen konnte — also,
frustrierungsfrei, was man mit den Smartphones davor nicht wirklich konnte.
Dadurch begannen die iPhone-Nutzer sehr schnell die Mehrheit darzustellen bei den mobilen
Surfern und überhaupt wurde dadurch zum ersten Mal das mobile Surfen so richtig genutzt.
Und die Smartphone-Nutzer begannen nun wirklich mal einen relevanten Anteil der Web-Nutzer
darzustellen. Das iPhone konnte die bisherigen Webseiten,
das heißt die, die für Desktop-Monitore ausgelegt waren, bedienbar darstellen, das
war halt das tolle an dem Browser dort. Dennoch haben einige Webseiten-Betreiber ihre Webseite
nochmal speziell für das iPhone neu konzipiert, also eine eigene Version gemacht, die dann
für das iPhone ausgelegt war und man sieht das halt daran: Hier ist das Beispiel von
Yahoo! Eben habt ihr die Desktop-Version gesehen und hier ist die mobile Version. Sie hat ein
anderes Layout, sie ist einspaltig und es orientiert sich auch so ein bisschen an der
User-Experience des iPhone OS. Es gibt noch Webseiten, die stärker nach iPhone aussehen.
Es gab da zum Beispiel das jQTouch-Framework, mit dem man Webseiten machen konnte, die aussahen
wie eine App des iPhones. Das heißt, man hatte nun zwei verschiedene
Versionen: Eine Desktop-, eine normale Version und eine iPhone-Version. Wie wurde unterschieden,
welcher Browser welche Version bekommt? Es ist so, wenn von einem Browser eine Anfrage
an den Server geschickt wird, wird unter anderem auch ein UA-String, ein User-Agent-String,
mitgeschickt. Da stehen dann verschiedene Informationen drin, zum Beispiel, einmal der
Browser — hier in dem Fall Firefox —, die Rendering-Engine, das Betriebssystem, sogar
der Prozessor, der verbaut ist, die Sprache und so weiter. Das wird an den Server geschickt.
Hier auch nochmal ein anderer UA-String, in dem Fall von Windows Microsoft Internet Explorer
10. Und genau dasselbe, oder nicht genau dasselbe, aber ebenfalls ein UA-String, ein User-Agent-String,
schickt auch das iPhone an den Server und dort kommt auch das Wort "iPhone" drin vor.
Und dementsprechend kann der Server halt diesen UA-String auslesen, gucken ob dort das Wort
"iPhone" drin vorkommt, und wenn nicht, dann schickt es einfach die normale Seite zurück,
und wenn es drin vorkommt, dann geht der Server davon aus, dass das iPhone diese Anfrage gestellt
hat und schickt dementsprechend die iPhone-Version. Man kann das ganze auch nachprüfen. Hier
zum Beispiel in Chrome kann man den User-Agent-String des Browsers verändern. Ich setz das hier
mal auf iPhone und schon lädt nur die iPhone-Webseite und nicht die normale Webseite.
Aber wie wir alle wissen, blieb es nicht beim iPhone alleine. Das iPhone hat diesen Smartphone-Trend
ausgelöst, der bis heute anhält und vermutlich auch die Zukunft sein wird. Und ein populäres
weiteres Betriebssystem, neben Windows Phone 7 und verschiedenen anderen, die aber nicht
dermaßen relevant sind, ist Android. Und mit Android kam eine ganze Palette anderer
Geräte, die alle Android verwendet haben, aber nicht einheitlich / standarisiert waren.
Hier habe ich jetzt nur fünf Beispiele, es gibt natürlich viel, viel mehr Geräte, die
Android nutzen. Und für diese Smartphones sollte natürlich
auch eine angepasste Webseite ausgeliefert werden und nicht bloß die Desktop-Variante
und deswegen musste auch Android mit ins Programm aufgenommen werden.
Aber es blieb auch nicht bei diesen Geräten. Es kam noch etwas hinzu und zwar das iPad.
Es gab zwar schon zehn Jahre davor Tablet-Computer, aber mit dem iPad ist die Tablet-Welle ausgelöst
worden, die bis heute anhält. Und so gesehen muss auch das iPad mit aufgenommen werden,
denn auch das iPad sollte nicht die Desktop-Version bekommen, sondern eine dritte, eigenständige
Version. Man hatte nun die Desktop-Version, die mobile Version und die Tablet-Version.
Und diese Version sollte ebenfalls an weitere Tablets ausgeliefert werden, denn auch Android
hatte mit Honeycomb schließlich eine eigene Variante speziell für Tablets.
Das heißt, man musste jetzt bei Android unterscheiden zwischen mobilen Android-Geräten und Tablet-Android-Geräten
und das ist nicht so einfach, denn der Übergang ist teilweise recht fließend. Ein Beispiel
davon ist das Samsung Galaxy Note, das entweder ein überdimensioniertes Smartphone oder ein
relativ kleines Tablet ist. Das steht so ein bisschen zwischen den Dingen.
Neben diesen vielen Geräten und Gerät-Kategorien können aber auch sehr viele andere Geräte
Browser enthalten. Beispiele dafür sind zum Beispiel Spielekonsolen, wie zum Beispiel
die Playstation 3, die Wii und die Xbox 360. Wenn man die auch mit einer eigenen Version
der Webseite beliefern möchte nach diesem System, dann müsste man auch die hier mit
aufnehmen. Und ihr seht schon, wohin das führt: Man hat hier schon total viele Geräte und
diese Auflistung hier ist bei weitem nicht vollkommen. Es gibt auch SmartTVs mit Browsern,
also wo das Web drauf läuft. Das heißt, es gibt — und wird immer mehr geben — Geräte,
auf denen das Web läuft, die aber keine Desktop-Monitore haben, sondern andere, kleinere oder anders-formatige
Monitore. Deswegen ist diese Praxis hier ein wenig sehr
unflexibel und führt nicht zum Ziel. Das Problem ist nämlich: Wir haben eine hohe
Fragmentierung. Das Web ist verfügbar auf einer Vielzahl von Geräten, auf einer Vielzahl
von Plattformen auch und Browsern und das, was ihr eben gesehen habt, dass man anhand
der User-Agent-Strings die Browser voneinander trennt und die Geräte voneinander trennt
und verschiedene Versionen macht, die man dann entsprechend ausliefert, das ist halt
ein Versuch, um dieses Problem zu lösen. Das Problem ist, dass diese Unterscheidung
mit Hilfe von User-Agent-Strings vorgenommen wird. Das ist das sogenannte "UA sniffing"
oder "Browser sniffing" und genau das ist das Problem, denn das ist eine sehr schlechte
Praxis, Bad Practice. UA sniffing ist nämlich unzuverlässig: Ihr
habt es eben gesehen, ich kann in Chrome meinen User-Agent-String verändern und mich einfach
mal als iPhone ausgeben, obwohl ich überhaupt kein iPhone bin.
Das heißt, es ist auch ungenau. Und es ist verlogen: Hier das ist zum Beispiel mein Standard-UA-String
in Chrome. Ihr seht, da steht auch "Chrome". Aber da steht auch "Mozilla" und "Safari",
obwohl ich weder Mozilla noch Safari bin. Die Rendering-Engine, die ich benutze, ist
"Apple WebKit", aber da steht auch "KHTML" und "Gecko", obwohl das nicht die Rendering-Engines
sind, die ich verwende. Das hat alles teilweise historische Gründe, die ihr auf diesen Seiten
hier nachlesen könnt: "History of the Browser user-agent string" ist sehr empfehlenswert,
bei WebAIM. Und da merkt ihr auch: Es schadet dem Fortschritt im Web, wenn ihr UA-sniffing
betreibt. Und wie wir an diesem Beispiel hier sehen,
ist es auch sehr unflexibel. Besser ist, wenn man dieses Problem nicht mit Hilfe von UA-sniffing,
sondern mit Hilfe von Media Queries löst. Und da kommen wir nämlich jetzt zum Responsive
Design. "Responsive Design" oder "Adaptive Design"
bedeutet, das eine Webseite auf ihre 'Umwelt' reagiert, also auf das Gerät, in dem sie
läuft und auf die Eigenschaften, die der Browser hat, in dem sie dargestellt wird.
Das wird über die CSS3 Media Queries realisiert. Mit den Media Queries können Stylesheets
deklariert werden, die nur dann ausgeführt werden oder nur dann Anwendung finden, wenn
das Ausgabegerät oder das Ausgabefenster oder -browser bestimmte Eigenschaften erfüllt.
Hier mal ein Beispiel: Hier ist ein Fenster, das ich verkleinere, und mit den Media Queries
reagiere ich dadrauf. Je nachdem, wie groß das Fenster gerade ist, wird ein Deklarationsblock,
CSS-Deklarationsblock, angewendet. Zum Beispiel, wenn das Fenster zwischen 1024 und 1400 Pixeln
groß ist, wird der zweite Block blau gefärbt und wenn, wie jetzt, das Fenster kleiner als
596 Pixel ist, wird der unterste Block blau gefärbt. Das ganze ist natürlich nur eine
Demo. Wie man das sinnvoll einsetzen kann, kann man hier sehen. Das ist die Webseite
der Information Architects und die haben die Media Queries eingesetzt, um damit Tablet,
Smartphone und Desktop-Version fließend und dynamisch zu realisieren, ohne UA-Sniffing,
einfach über Media Queries. So sieht das ganze aus: Das hier ist CSS-Code.
Man hat eine @media-Regel, die man auf screen anwendet, also dem Media-Typ, in dem Fall
Bildschirm, und verknüpft das mit diesem "and"-Wort und einer Eigenschaft, in dem Fall
hier zum Beispiel "min-width", also minimale Breite, 1044 Pixel. Oder maximale Breite 1024
Pixel. Oder minimale Breite 596 und maximale Breite 1024 Pixel, also wenn das Fenster zwischen
diesen beiden Werten groß ist. Wer mehr darüber wissen will, ich habe bereits
dazu ein Video gemacht und auch einen Artikel geschrieben bei css3-html5.de, den könnt
ihr euch ja durchlesen, falls es euch interessiert. Eine Auswahl an Beispielen für den Einsatz
von Media Queries findet ihr auf mediaquerie.es Da sind ganz viele Seiten, die die Media Queries
bereits in dieser Weise einsetzen. Das ist auch sehr toll, da mal zu gucken.
Das bedeutet, ich mache meine Webseite und mit Hilfe von Media Queries erstelle ich die
Mobile- und die Tablet-Versionen. Nicht ganz. Es ist nämlich so, dass die Mobile- und Tablet-Versionen
nicht nur das Layout der Webseite betroffen haben, sondern sehr viel mehr. Und zwar sind
die mobilen Geräte, also iPhone und Smartphone und Tablets und so weiter, oftmals ja nicht
über WLAN oder über LAN mit dem Internet verbunden, sondern über langsamere Verbindungen,
wie zum Beispiel Edge oder 3G. Und deswegen waren die mobilen Webseiten, die halt speziell
für iPhone und so weiter ausgelegt waren, oftmals sehr viel kleiner in der Download-Größe,
um auch bei schlechter Verbindung schnell zu laden.
Hier mal ein Vergleich von Yahoo! — Die Desktop-Seite ist 452 Kilobyte groß und die
mobile Seite ist 189 Kilobyte groß. Entwickelt man die Desktop-Version also zuerst
und passt sie anschließend mit Media Queries auf Smartphones und Tablets an, hat sie dieselbe
Download-Größe wie die Desktop-Version, das heißt sie ist ausgelegt auf eine LAN-
oder WLAN-Verbindung, ist also sehr groß und nicht auf langsame Verbindungen ausgelegt.
Wie löst man das Problem? Mit Mobile First and Desktop Second.
Man entwickelt die Seite zuerst für mobile Geräte, statt für Desktop-Geräte, und für
Tablets und erstellt anschließend die Desktop-Version. Das ist die Idee hinter Mobile First. Und
das ist inzwischen sogar richtig populär. Google, Facebook und Adobe haben inzwischen
auf Mobile First and Desktop Second umgestellt. Die Vorteile von Mobile First: Der mobile
Sektor gewinnt laufend an Bedeutung. Inzwischen soll die mobile Internet-Nutzung wohl sogar
schon die Desktop-Internetnutzung überholt haben und deswegen ist es eigentlich wichtig,
sehr wichtig, Webseiten für mobile Geräte auszulegen — alles andere ist im Grunde
nicht mehr zeitgemäß. Mobile Geräte zwingen einen, sich auch auf
das Wesentliche zu fokussieren. Einerseits inhaltlich, weil man nicht so viel Platz hat,
aber andererseits auch von den Skripten her, die zum Beispiel im Hintergrund laufen und
vom CSS und überhaupt von dem ganzen Code her. Das heißt, als Entwickler ist man zum
Beispiel gezwungen, auf Performance zu optimieren, und als User-Experience-Designer die Webseite
oder Web-App auf den Kern zu reduzieren. Und obendrein haben mobile Geräte teilweise
sogar mehr Funktionalität als Desktop-Rechner. Präzise Lokalisierung über GPS zum Beispiel,
Geolocation, Zugriff auf Kompass, man hat diese Multitouch-Eingabe, die ja eigentlich
alle heutigen Smartphones und Tablets haben. Man kann auf die Daten des Beschleunigungssensors
zugreifen und, und, und... Das alles ist erst seit HTML5 möglich. Noch nicht alle Geräte
unterstützen alles, aber es gibt mehr und mehr APIs, die auch mehr und mehr implementiert
werden, um halt auf diese Daten des Geräts zuzugreifen.
Das heißt, richtig ist: Ich mache meine Webseite für mobile Geräte und mit Hilfe von Media
Queries erstelle ich eine Desktopversion.