Viele Themen werden uns in Vorträgen und Artikeln wieder und wieder
vorgekaut. So häufig, dass wir dieses Tool oder jenen Workflow als neuen
Standard akzeptieren. Doch in einigen Fällen dürfen wir durchaus
fragen: Ist das überhaupt sinnvoll? Drei Beispiele.

Immer öfter hören Webworker die Frage, auf welches Framework sie denn
setzen? Auf den Platzhirsch Bootstrap? Foundation oder YAML? Skeleton,
Base, Toast, SimpleGrid? Als gehe es heutzutage gar nicht mehr ohne.
Frameworks sind eine nützliche Sache, vor allem fürs Rapid Prototyping.
Aber alle Frameworks setzen uns ein paar Basisgrößen vor die Nase.

Bootstrap etwa nutzt in der nicht-responsiven Version aktuell zwölf
Spalten auf insgesamt 940 Pixeln. Wer ein anderes Raster benötigt, muss
also ein wenig an den Vorgaben schrauben. Das responsive CSS-File setzt
seine Breakpoints bei 768, 980 und 1.200 Pixeln. Diese Werte sind
vielleicht für den Start nützlich, aber ich setze meine Breakpoints
lieber selbst. Und zwar nicht nach üblichen Gerätemaßen, sondern nach
den Inhalten. Bootstraps responsives CSS kommt auf über 1.000 Zeilen
daher oder minifiziert 17 KB, von denen ich aber nur einen Bruchteil
benötige und teilweise auch noch ändern will. Wenn ich aber ohnehin
eigene Themes erstelle, baue ich mir lieber ein eigenes kleines Grid
auf, das für den jeweiligen Zweck ausreicht und viel weniger Zeilen im
CSS benötigt. Im schlimmsten Fall lädt ein Framework zur Faulheit ein:
Wir nutzen einfach die vorgegebenen Maße und Breakpoints und pressen
unsere Inhalte und Design hinein.

Der aktuell nervigste Trend lautet: „Mobile First“. Ein Webworker
beginnt demnach minimalistisch mit dem Design für mobile Geräte und fügt
dann immer mehr Elemente hinzu, wenn die Bildschirme breiter werden.
Was daran ungeheuer sinnvoll ist, lässt sich besser als "Content first"
beschreiben. Bei der Konzeption werden automatisch die wichtigsten
Inhalte hervorgehoben. Komplexe Webseiten lassen sich so sehr schön auf
das Wesentliche reduzieren. Ich sehe nur nicht ein, warum man deshalb
auch dem Design nun unbedingt „von unten“ nähern muss. Mag ja sein, dass
es viele für einfacher halten, einem minimalen Design für breite
Bildschirme immer weitere Elemente hinzuzufügen. Ich dagegen finde es
einfacher, von einem Desktop-Design auszugehen und Elemente wegzunehmen.
Für einen erfahrenen Webprofi ist es eigentlich kein Problem, beim
Desktop-Design schon festzulegen, welche Inhalte besser per Ajax
nachgeladen werden und ob Elemente problemlos mit CSS versteckt werden
können.

Vor allem aber kommt es auf die Komplexität der Site und die eigenen
Kunden an. Wer mit erfahrenen Kunden arbeitet, einigt sich mit ihnen
vielleicht tatsächlich darauf, dass Mobile First der bessere Ansatz ist.
Bei kleinen, mittelständischen Unternehmen hingegen kann ich schlecht
mit einem Handy ankommen und zeigen, wie hübsch minimal die Website
darauf aufsieht oder wie schnell die Informationen geladen werden.
Solche Kunden wollen zuerst die Desktop-Version sehen und nicken später
nur noch die mobilen Varianten ab. Es ist nicht einmal so, dass ich ein
Bedürfnis verspüre, diesen Kunden das mobile Web unbedingt
näherzubringen. Wenn ich an den Statistiken sehe, das über 90 Prozent
der Besucher die Website mit einer Bildschirmbreite von 1024 Pixeln und
mehr betrachten: Warum sollte ich nicht „Desktop first“ arbeiten?
Unabhängig vom Ansatz kommt ein erfahrener Webworker über beide Wege zu
einem guten Ergebnis – zumindest bei klassischen Zwei- oder Dreispaltern
mit übersichtlichen Inhalten.

Wenn wir einen Blick auf die Beispiele unter mediaqueri.es werfen,
finde ich eine Sache bemerkenswert: Die Websites entfalten sich über
verschiedene Breakpoints hin zu einer maximalen Größe; zwischen den
Breakpoints gibt es fluide Übergänge. Warum eigentlich? Nicht, dass das
falsch oder schwierig wäre. Trotzdem, warum?

Fluides (flexibles, elastisches) Design kennen wir schon seit Jahren.
Dennoch haben wir sehr häufig Websites mit fixen Breiten angelegt –
weil es uns mehr Kontrolle gegeben hat. Ist es nicht seltsam, dass wir
nun automatisch fluide Übergänge zwischen Breakpoints schaffen? Wir
könnten doch einfach unsere Websites mit festen Breiten erstellen: etwa
jeweils eine fixed Version für 1.200 Pixel, 900 Pixel, 600 Pixel – und
darunter eben immer auf 100 Prozent Breite (was einige Webworker dann
als Mischung zwischen Adaptive und Responsive Design bezeichnen).
Gewiss, ein fluides Design nutzt den Raum meist besser aus. Aber Ränder
haben uns in den Jahren davor auch nicht gestört. Ob ein Design fluid
ist oder nicht, merken ja in der Regel nur wir Webworker, und zwar dann,
wenn wir am Desktop die Browser breiter und schmaler ziehen. Einem
normalen Benutzer kann es egal sein. Hauptsache er sieht die Inhalte auf
allen Geräten.

Was bieten uns fixe Designs? Genau das, was sie uns auch schon vor
Jahren geboten haben: mehr Kontrolle. Das kann in manchen Fällen auch
äußerst hilfreich sein. Zum Beispiel, wenn wir im Zuge der
Barrierefreiheit darauf achten müssen (oder wollen), dass die Seite auch
mit einem reinen Text-Zoom von 150 Prozent funktioniert. Da kann es
ziemlich vertrackt werden, in den fluiden Übergangsbereichen dafür zu
sorgen, dass in Menüs oder Tabellen auch noch ein Text-Zoom
berücksichtigt wird. Fixe Breiten sind vielleicht uncooler, aber es
kommt einzig und allein darauf an, dass die Inhalte nutzbar sind.

Nur weil „alle“ von bestimmten Tools oder Workflows schwärmen, darf
man sich für die eigene Arbeitsweise durchaus bewusst gegen die Trends
entscheiden. In einigen Fällen ist es für das Ergebnis egal, in anderen
Fällen kann man in bestimmten Bereichen mit alternativen Werkzeugen
sogar bessere Ergebnisse erzielen.