Responsive Web Design & Mobile First

Responsive Web Design & Mobile First


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.

Comments

  1. Post
    Author
    Thytos

    😀
    Wow, wie hast du so schnell von dem Video mitbekommen? Du bist einer der drei ersten Zuschauer.
    Wenn du willst: Gebe morgen in der Uni von 10-14 Uhr einen Überblick über HTML5 und allem drum und dran. Dafür ist auch dieser Vortrag hier. Kannst kommen, wenn du willst 😉

  2. Post
    Author
    Thytos

    Dann wünsch ich viel Erfolg beim Umzug 🙂
    …Zu viele »i's«?! Zu viele »ähm's« würde ich verstehen, aber »i's«?! 😀

  3. Post
    Author
  4. Post
    Author
  5. Post
    Author
    TheJUMovies

    Aber eine Frage hab ich noch, was bringt den Mobile First, denn die Bildgröße muss ja trotzdem gleich bleiben und das macht ja die Größe einer Website aus.

  6. Post
    Author
    Thytos

    @TheJUMovies Ganz genau. Deswegen ist ein Ansatz, kleine komprimierte Bilder auszuliefern und per JavaScript für die Desktop-Version und für schnelle Verbindungen große Bilder dann nachzuladen.

  7. Post
    Author
  8. Post
    Author
  9. Post
    Author
  10. Post
    Author
    Janek Donhauser

    Mal ne frage weil ich gerade so ne neue Idee hab. Weist du wie genau ich den Prozessor bestimmen kann also nur intel oder auch i7?

  11. Post
    Author
    Janek Donhauser

    @Thytos da du ja gerade dein js tut machst glaubst du dass man so was eher in javascript oder PHP umsetzten könnte?

  12. Post
    Author
    Janek Donhauser

    @Thytos also meinst du dass ich mit beiden etw über den Prozessor herausfinden könnte also auch i7 mit 2.4 GHz? Oder nicht so genau und würde das auch mit anderer Hardware gehen Festplatte Info oder Grafikkarte USW.

Leave a Reply

Your email address will not be published. Required fields are marked *