Ein Jahr responsive: fünf Fehler, die ich nicht noch einmal mache

Archivbeitrag aus dem Jahr 2013

Dieser Beitrag stammt aus dem Blog meiner früheren Website. Gegenüber dem damaligen Original wurden eventuell Rechtschreibfehler korrigiert und Bilder ersetzt; Inhalt und Aussagen entsprechen dem Stand von damals.

Im März 2012 habe ich das erste Kundenprojekt responsive gebaut, inzwischen sind es sieben, vom TYPO3-Relaunch im Dezember bis zur Bäckerei vor Ostern. Zeit für eine ehrliche Liste. Nicht, was gut lief — das steht in den Angeboten —, sondern was ich beim ersten, zweiten und teilweise dritten Mal falsch gemacht habe.

1. Ich habe am Desktop angefangen und dann geschrumpft

Die ersten beiden Projekte habe ich wie immer in Photoshop auf 960 Pixel entworfen und das Layout anschließend mit Media Queries nach unten „gerettet“. Das Ergebnis funktioniert, aber man sieht es ihm an: Auf dem Handy stehen Elemente untereinander, die dort niemand braucht, und das Wichtigste — Telefonnummer, Öffnungszeiten, Anfahrt — steht nach dreimal Scrollen. Seit dem Herbst entwerfe ich zuerst die schmale Ansicht. Das zwingt mich und den Kunden, die Reihenfolge der Inhalte zu klären, bevor wir über Farben reden. Luke Wroblewski hat recht: Der kleine Bildschirm ist kein Problem, er ist ein Filter.

2. Ich habe geglaubt, max-width löst das Bilderproblem

Tut es nicht. Es löst das Layoutproblem. Die Datei bleibt so groß, wie sie ist, und auf einer schlechten UMTS-Verbindung lädt ein Projekt mit zwölf Produktfotos über eine halbe Minute. Ich habe das bei einem Kunden im Laden auf seinem eigenen Handy vorgeführt bekommen, das war unangenehm. Seitdem gilt: Bilder serverseitig auf die größte wirklich benötigte Breite rechnen, Hintergrundbilder per Media Query in zwei Größen, und für die Fotos im Inhalt nutze ich seit ein paar Wochen Scott Jehls Picturefill, das je nach Bildschirmbreite eine andere Datei lädt. Das ist ein Behelf mit JavaScript, keine Lösung. Die echte Lösung — ein picture-Element oder Apples srcset-Vorschlag vom letzten August — wird gerade noch in den Standardisierungsgruppen diskutiert, und ich habe keine Ahnung, welche Seite gewinnt.

3. Ich habe acht Menüpunkte in ein Dropdown gequetscht

Die Desktop-Navigation hatte acht Punkte nebeneinander. Mein erster Reflex fürs Handy: alles in ein select-Feld packen. Das ist technisch simpel, sieht aber wie ein Formular aus, und niemand erwartet dort eine Navigation. Brad Frost hat im letzten Jahr die gängigen Muster gesammelt, und ich bin nach einigem Probieren bei der einfachsten Variante gelandet: ein Knopf „Menü“, der die Liste darunter auf- und zuklappt, Punkte untereinander, jeder mindestens 44 Pixel hoch, damit der Daumen ihn trifft. Apple nennt dieses Maß in den eigenen Richtlinien für iOS, und es stimmt auch auf Android.

navigation.js

var knopf = document.getElementById('menue-knopf'),
    liste = document.getElementById('navigation');
knopf.onclick = function () {
  liste.className = liste.className === 'offen' ? '' : 'offen';
  return false;
};

Kein jQuery dafür, kein Plugin. Zwanzig Zeilen CSS, acht Zeilen JavaScript, und ohne JavaScript bleibt die Liste einfach sichtbar.

4. Ich habe Breakpoints nach Geräten gesetzt

Darüber habe ich im Juli schon geschrieben, und das Jahr hat es bestätigt: Im September kam das iPhone 5 mit einem längeren Bildschirm, das Galaxy S III hat 720 Pixel Breite, das Nexus 7 liegt mit 600 dazwischen. Jede Geräteliste ist am Tag ihrer Fertigstellung veraltet. Ich setze Breakpoints da, wo der Inhalt bricht — in em, meist drei Stück —, und teste anschließend auf den Geräten, die ich habe. Das reicht.

5. Ich habe Hover-Zustände gebaut, die es auf dem Handy nicht gibt

Ein Aufklappmenü, das sich bei Mausberührung öffnet. Tooltips auf Produktbildern. Ein Bildwechsel beim Darüberfahren. Alles hübsch, alles auf einem Touchscreen entweder unerreichbar oder nervig, weil der erste Tipp den Hover auslöst und erst der zweite den Link. Ich baue inzwischen nichts mehr, das nur per Hover erreichbar ist. Wenn eine Information wichtig ist, steht sie sichtbar auf der Seite.

Was bleibt

Die Technik ist inzwischen der kleinere Teil. Fluid Grid, flexible Bilder, Media Queries — das lässt sich in einem Nachmittag erklären. Die eigentliche Arbeit liegt davor, in der Frage, was ein Besucher mit dem Handy auf dieser Seite will, und sie ist bei jedem Kunden anders. Vor einem Jahr habe ich Responsive Design verkauft, damit nichts kaputt aussieht. Heute verkaufe ich es, damit die Seite auf dem Gerät funktioniert, auf dem die Leute sie tatsächlich öffnen. Das ist ein anderer Satz, und er führt zu anderen Websites.