Responsive Webdesign ist heute State of the Art im Webdesign. Alle Kunden wollen eine Webseite, die auch auf mobilen Geräten gut funktioniert. Das stellt uns Designer vor neue Herausforderungen.
Beim Entwerfen des Designs für eine Webseite beginnt man in der Regel mit der Desktopansicht. Ich mache das jedenfalls so, auch wenn der Code später „mobile first“ gebaut wird. Die Desktopansicht ist ein guter Einstieg und man bekommt schnell ein Gefühl für die Gestaltung.
Dann wäre da noch die Frage
„Wie sieht das Design auf einem kleinen Bildschirm aus?“
„Auf dem Tablet wird dann alles irgendwie schmäler.“
Okay. Aber was passiert, wenn die Spalten so schmal werden, dass man den Text nicht mehr lesen kann? Und kann man dieses Bild da noch erkennen, wenn es nur noch 30×50 Pixel groß ist? Und wie soll man diesen winzig kleinen Link mit dem Finger anklicken?
Es hilft nichts. Damit die Seite auch auf kleinen Bildschirmen lesbar und bedienbar muss man verschiedene Szenarien durchspielen.
„Huch, wo ist denn der Text hin?“
Auf einem großen Bildschirm können die Inhalte in mehreren Spalten nebeneinander stehen. Auf kleinen Bildschirmen ist das anders. Weil dort weniger Platz ist, verringert sich die Anzahl der Spalten oder die Inhalte werden untereinander angeordnet.
Das sollte man beim Entwerfen im Hinterkopf behalten. Wenn man nicht aufpasst, verschwinden zum Beispiel wichtige Inhalte aus dem Sichtfeld des Nutzers. Oder es erschließen sich bestimmte Zusammenhänge nicht mehr, weil die Elemente nicht mehr nebeneinander stehen.
„Das Menü wird auf dem Smartphone so ein Hamburger-Dings.“
Wie sieht das Menü auf einem Tablet oder auf einem Laptop aus, wo der Platz knapp ist und es immer enger zugeht?
Man kann dieser Frage ausweichen, indem man relativ zügig auf das Hamburger-Icon wechseln. Alles, was kleiner ist als 1200px bekommt ein Hamburger-Menü verpasst.
Ich finde das nicht überzeugend. Wenn auf dem iPad jede Menge Platz ist und ich die Navigation trotzdem nicht sehen kann, ist das einfach ärgerlich. Wo es machbar ist, sollte die Navigation auch sichtbar und bedienbar sein.
Wichtig ist, die Navigation so zu konzipieren, dass sie sowohl auf großen als auch auf mittelgroßen Bildschirmen gut funktioniert. Die Navigation sollte verkleinerbar und flexibel sein. Je mehr „Luft“ die Navigation hat, um sich anzupassen, desto leichter ist es, das umzusetzen. Andersherum wird es ziemlich schnell ziemlich frickelig, wenn die Navigation beispielsweise auf dem Desktop exakt die volle Breite einnimmt und die Menü-Punkte dicht an dicht stehen.
Auch die klassische Zweit-Navigation in einem vertikalen Kasten, der meist links vom Content steht, ist ein Muster aus der Ära der statischen Seiten. Im Responsive Design funktioniert das nicht so richtig gut. Es ist besser, nach alternativen Lösungen zu suchen.
„Das blenden wir auf dem iPhone einfach aus!“
Das klingt zunächst mal nach einem guten Trick. Was auf den kleinen iPhone-Bildschirm komisch aussieht, wird einfach ausgeblendet. display:none macht’s möglich.
In manchen Situationen und sparsam eingesetzt kann man damit arbeiten. So kann es beispielsweise sinnvoll sein, bei Teaser-Elementen mit Foto, Überschrift und Anreissertext auf kleinen Bildschirmen den Anreissertext wegzulassen. Foto und Überschrift reichen aus und fügen sich besser ins Layout.
Häufig wird diese Methode jedoch eingesetzt, weil es mit dem Smartphone-Layout nicht so recht klappen will. Dann wird schnell mal ein Element als „nicht so wichtig“ erklärt. Wirklich überzeugend ist dieses Argument selten. Denn wenn das wirklich so wäre, hätte man diese Information ja schon von vorn herein weglassen können.
Nein, Wichtigkeit und Priorität sind unabhängig von der Bildschirmgröße. Anders gesagt: Dass der User auf dem Smartphone nur eine Webseite „für Arme“ zu sehen kriegt, kann nicht im Sinne des Betreibers der Webseite sein.
„Lorem ipsum dolor sit amet.“
Blindtexte sind etwas Feines und kein Designer kommt ohne sie aus. Aber Blindtexte lügen uns ganz schön was vor. Ruhige, lange Texte mit hübschen Bildern machen sich im Entwurf immer gut. Aber wie viel haben solche „Texte“ mit den realen Inhalten zu tun? In der Regel reichlich wenig.
Ohne ein Gefühl für die Inhalte kann man kein sinnvolles Layout entwerfen. Schon gar keines, das im Responsive Design funktioniert. Es muss klar sein, was inhaltlich auf der Seite passieren soll. Das müssen noch nicht die fertig ausformulierten Texte sein, aber das inhaltliche Konzept muss vor dem Design stehen.
[white_box]
TIPPS FÜR DESIGNER
- Wenn Ihr ein neues Projekt beginnt, vergesst erst Mal die Ästhetik. Die schönen Bilder kommen später.
- Nehmt Euch Stift und Papier und zeichnet auf, wo was in Eurem Layout stehen soll.
- Macht diese Skizzen für mehrere Bildschirmbreiten und -proportionen: Großer Bildschirm, Laptop, kleines Tablet und Smartphone.
- In welcher Form erscheinen die Inhalte auf der Seite? Als kleine Teaserboxen mit Bild und Anreissertext? Als kurze Texte mit Weiterlesen-Link? Als lange Texte mit Anchors? Als Listen und Aufzählungen? Kann man eine Sache vielleicht besser in einer Slideshows oder Bildergalerie erklären?
- Auch wenn der Kunde alle Inhalte gleich wichtig findet, für ein Layout müssen wir Inhalte priorisieren. Was soll der Besucher auf jeden Fall mitnehmen, wenn er eine Seite aufruft? Befindet sich das, was wichtig ist, immer im Sichtfeld des Besuchers? Auch auf dem Tablet und auf dem Smartphone?
- Diskutiert diese Skizzen mit Eurem Kunden und dem Entwickler Eures Vertrauens.
[/white_box]
Kommentare
•
Hallo,
ich verstehe die Problematik des Hamburger-Icons ehrlich gesagt nicht. Mit WordPress ist es doch vergleichsweise mit geringem Aufwand verbunden, eine Homepage im Responsive Design umzuwandeln. Jeder, der sich ein wenig Mühe gibt, kann so etwas relativ leicht erstellen.
•
Ich verstehe nicht ganz, was Du meinst.
Ich beziehe mich auf Responsive Design als CSS-Methode. Damit ist RWD unabhängig vom CMS. WordPress, Drupal oder HTML, das ist eigentlich egal.
•
Wie Kirsten ja bereits sagte, hat RWD erst mal gar nichst mit dem verwendeten CMS zu tun und darüber hinaus zeugt der Kommentar von relativ überschaubarer Kenntnis der Materie, wie mir scheint.
•
Hallo, Michael! Man kann solche Dinge ja auch per Plugin machen. Da gibt es so einiges. Die zaubern dann irgendwas hin. Schön ist es nicht, was damit raus kommt und hat mit RWD nur am Rande zu tun. Aber der Markt dafür ist da.
•
Eben. Wie Du richtigerweise sagst: Es hat mit RWD bestenfalls am Rande zu tun ;-)
Und um RWD, und dass es eben NICHT so trivial ist, geht es doch in Deinem Artikel. Nicht darum, dass jeder mit ein wenig Halbwissen eine Website irgendwie, so halbwegs mobiltauglich hinbekommen kann.
Nach dem Motto: Das kannste schon so machen, aber dann isses halt…
•
vielen Dank für den gut recherchierten und übersichtlichen Blogbeitrag. Die Tipps werden mir auf jeden Fall gut kommen
•
Ja, responsives Design ist schon eine rechte Herausforderung.
Für alle, die sich viel Prokelei sparen wollen, hier ein paar Tips:
– Responsives Design unbedingt mit dem Flexbox-Model realisieren.
Mehr dazu einfach erklärt gibt’s hier:
https://css-tricks.com/snippets/css/a-guide-to-flexbox/
– Ob’s funktioniert lässt sich am Unproblematischsten im Browser selbst feststellen mit dem Firefox-AddOn „Firebug“. Optionen „Web-Entwickler | Bildschirmgrössen testen“.
– Auch wenn’s unter „Firebug“ gut aussieht: Google kocht wieder sein eigenes Süppchen.
Um beim Ranking nicht wegen (angeblich) fehlender Responsivität abgestraft zu werden
(https://developers.google.com/speed/pagespeed/insights/), fehlen jede Menge Kompatibilitäts Ergänzungen.
Es lebe der Schöpfer von „http://autoprefixer.github.io“.
Das CSS wird um all die alten Kamellen ergänzt die Google sehen möchte.
•
Hallo, Frank,
vielen Dank für Deinen Kommentar.
Eine kurze Bemerkung zum Thema flex-box:
Die flex-box-Methode ist ein wichtiger Fortschritt, der Weg über floats war und ist immer eine Krücke und ist nicht semantisch. Allerdings muss man bedenken, dass flex-box nicht gerade unkompliziert ist. Es braucht einiges an Einarbeitungszeit, um die Prinzipen zu verstehen. Das ist nicht jedermanns Sache.
Auch steckt die Unterstützung durch den Internet-Explorer noch in den Anfängen (10+). Bei Projekten, bei denen der Betreiber der Webseite nicht auf die IE-Besucher verzichten kann, muss man sich noch gedulden.
Meiner Einschätzung nach sind wir noch nicht so weit. Aber es ist nur noch eine Frage der Zeit, dass flex-box die alten float-Methoden ablösen wird.
schöne Grüße
von Kirsten
•
Ich persönlich finde für responsive Versionen das Quadrat mit den 3 Balken (hier auch „Hamburger“ genannt im Beitrag) sehr schön und sehr nützlich für die Navi.
Denn jeder weiß sofort: Da finde ich die Navigation bei der mobilen Webseite.
Daher hat sich dieses Quadrat mit den 3 Balken wohl auch durchgesetzt und ist so weit verbreitet. Ohne lange zu überlegen und zu studieren findet man sofort und eindeutig die Navigation.
•
Hallo, Remo,
vielen Dank für Deinen Kommentar.
Das Hamburger-Button ist inzwischen weit verbreitet. Allerdings ist diese Lösung nicht unumstritten und viele Seiten und Apps bewegen sich wieder davon weg. Der große Nachteil vom Hamburger-Menu ist, dass damit die Navigation unsichtbar gemacht wird und erst auf Klick wieder sichtbar wird. Man sieht also erst Mal nichts und das ist nicht wirklich ideal in Sachen Nutzerführung.
Ich habe ein paar Artikel zum Themenbereich „Nutzerführung und Navigation“ in Planung, da werde ich auf diesen Aspekt zu sprechen kommen.
Schöne Grüße von Kirsten
•
Zitat: „Der große Nachteil vom Hamburger-Menu ist, dass damit die Navigation unsichtbar gemacht wird.“
Antwort: Ich finde gerade das das Tolle. Daß auf dem kleinen Mobiltelefon die Navi weg ist, die soviel Platz verschlingt und man sich – bis man das Quadrat mit den 3 Balken wieder anklickt (ich wußte gar nicht, daß das Hamburger heißt), auf den eigentlichen Inhalt konzentrieren kann, den man sehen möchte.
•
Auch wenn der Artikel schon vor ein paar Monaten verfasst wurde:
es hat sich etwas getan seitdem.
Und ausserdem: responsives Webdesign bleibt immer aktuell.
Es gibt weiss Gott nicht allzu viele Neuerungen bei Google die einem
das Leben erleichtern – diese hier jedoch gehört definitiv dazu.
Mir ist seit einigen Tagen eine wichtige Änderung beim Google Test
auf „mobile-friendly“ aufgefallen und zwar sowohl unter dem
eigentlichen „Test auf Optimierung für Mobilgeräte“ als auch unter
„PageSpeed Insights“.
Seitdem Google in den Prüfergebnissen das Smartphone-Bild anzeigt,
betrug der Viewport dazu stets 320×480 Pixel.
Vor ein paar Tagen fiel mir auf, dass sich dieser Viewport nun
verändert hatte auf 375 Pixeln in der Breite (die ehemals 320 Pixel).
Auf die Höhe hatte ich dabei leider nicht geachtet.
Heute nun zeigt sich, das die Auflösung bei beiden Tests erneut
angepasst wurde – auf 980×1.743 Pixel Bildschirmgrösse.
Ich habe dazu mal eine kleine Test-Datei erstellt, mit deren Hilfe
man sich diese, und alle kommenden Änderungen, bei PageSpeed
anzeigen lassen kann:
https://developers.google.com/speed/pagespeed/insights/?url=www.binary-garden.com%2Fgoogle-screensize-test.php&tab=mobile
Der Seiteninhalt dort wurde fest eingestellt auf eine Breite
von 1.000 Pixeln.
Und tatsächlich: in „PageSpeed“ erhält man nun unter
„Benutzererfahrung“ | „Behebung empfohlen“ | „Fehlerbehebung anzeigen“
den Hinweis:
„Der Seiteninhalt ist 1.020 (Anmerkung: 1.000px Breite + 20px left)
CSS-Pixel breit, aber der Darstellungsbereich hat nur eine Breite
von 980 CSS-Pixel.“
Ich denke, dass diese Info wichtig ist, dass es das „mobile-friendly“
Schulterklopfen jetzt schon mit erheblich weniger Media-Queries
gibt als bisher.
Ab einem Viewport von 800px abwärts ging die Arbeit erst richtig los.
Die ursprünglichen 320×480 waren im wahrsten Sinne des Wortes noch aus dem letzten Jahrhundert – wenn Google es jetzt noch irgendwann mal schafft das Gerätebild auszutauschen…
Ach ja: unverändert geblieben ist der Viewport für die Desktop-Version
1.024×768 Pixel.