praegnanz.de büro für intervernetzte medien

Gerrit, 30.11.2015

Tablet First – der kesse Kniff für Leute von heute!

Wie wohl die meisten Webdesigner haben wir irgendwann 2013 gemerkt, dass der Spaß, den man beim nachträglichen Responsivieren von komplexen Website-Layouts hat, begrenzt ist. Das sogenannte „Responsive Retrofitting“ wird natürlich bis heute häufig praktiziert, wenn das Kundenbudget nicht für einen echten Relaunch ausreicht, oder die Zeit schlichtweg knapp ist. Selbstverständlich kann man sich hier aber auch ganz trefflich im Aufwand verschätzen, denn vierstufige Navigationen und ellenlange Seitenspalten, die unabhängig von der Haupttextspalte agieren, sind im linearisierten Layout echte Störenfriede.

Besser ist es, das Layout gleich als responsives Gesamtkonstrukt zu konzipieren, und die wichtigsten gewünschten Bildschirmbreiten gleichzeitig und gleichberechtigt zu betrachten und zu bauen. Dieser „Everything First“-Ansatz funktioniert auch in der Screendesign-Phase ganz passabel. Egal, ob ihr eure ersten Anmutungen und Wireframes in Photoshop, Sketch oder auf Prototyping-Papier entwerft – es fällt gar nicht sonderlich schwer, parallele Versionen für Desktop (> 900px), Hochkant-Tablet (500–900px) und Smartphones (< 500px) zu bauen, wenn man genügend Routine und ein paar gute Einfälle hat.

(Diese drei klassischen Entwurfsgrößen sind dabei nur grobe Anhaltspunkte und dienen als statische Aufhänger, welche später im browserfähigen Prototypen möglichst stufenlos ineinander übergehen können sollten. Meist braucht man deutlich mehr Breakpoints, und auch die Bildschirmhöhe spielt eine wichtige Rolle, schon klar.)

Sobald wir nun aber die Phase des initialen Entwurf verlassen und in den responsiven Workflow übergehen, wo wir im ständigen kleinteiligen Wechsel Screendesign und Frontend-Entwicklung ineinander greifen lassen, muss es naturgemäß eine Ursprungsgröße geben, sowie eine Richtung, in die man sich vorarbeitet. Klassischerweise ist das in früheren Jahren nach dem Desktop-First-Paradigma verhandelt worden. Die Breiten ab 900px bekommen das reguläre CSS, während die kleineren Bildschirme die CSS-Sonderregeln innerhalb von Media-Query-Klammern zugewiesen bekommen:

/* Normales CSS für alle Geräte: */
nav li { display: inline-block; }

/* Davon abweichende Regeln für Tablets und kleiner: */
@media (max-width: 900px) {
  nav li { font-size: .9em; }
}

/* Weitere Abweichungen für Smartphones: */
@media (max-width: 500px) {
  nav li { display: block; }
}

Diese Taktik ist allerdings größtenteils Schnee von gestern. Seit einiger Zeit wird allenthalben dem Mobile First gepriesen. Abgesehen davon, dass diese Catchphrase auf allen möglichen Ebenen verwendet wird (bis hin zum Business-Mantra disruptiver Enterprise-Unternehmen), bedeutet es für Frontend-Entwickler schlicht die Umkehrung des oben beschriebenen Prinzips. Wir betrachten das Smartphone-CSS als den „Normalfall“, und alles größere ist die Abweichung:

/* Normales CSS für alle Geräte: */
nav li { display: block; }

/* Davon abweichende Regeln für Tablets und größer: */
@media (min-width: 500px) {
   nav li { display: inline-block; }
}

/* Weitere Abweichungen für Desktop-Größen: */
@media (min-width: 900px) {
   nav li { display: block; font-size: 1.1em; }
}

Im Grunde machen beide Codebeispiele das Gleiche, und bei solch einfachen Dingen vermag man kaum einen praktischen Vorteil der einen oder der anderen Methode erkennen. Der reine CSS-Code ist aber nur das eine. Der Workflow ist etwas anderes! Wenn ich davon ausgehe, dass ein nicht unwesentlicher Teil der Gestaltung on-the-fly während des CSS-Aufbaus entsteht, macht es schon einen Unterschied, ob ich mich zuerst mit den „gewohnten“ Bildschirmgrößen beschäftige, und das Browserfenster solange kleiner ziehen, bis man scrollen muss oder nichts mehr erkennen kann, um dann einen Breakpoint zu setzen. Oder ob ich umgekehrt das Browserfenster langsam immer größer ziehen, bis es irgendwann scheiße auszusehen beginnt.

Sowohl Desktop First als auch Mobile First haben dabei gewisse Schwächen, die zunächst nicht auf der Hand liegen, aber deren Auswirkungen man ziemlich gut im derzeitigen Web beobachten kann.

Das Problem von Desktop First ist das Zusammenquetschen von Elementen auf zu engem Raum. Oder – manchmal noch schlimmer – das Weglassen von eventuell nützlichen Elementen. Und natürlich exzessive Ausklapp- und Off-Canvas-Orgien.

Mobile-First-Designs hingegen leiden oft unter akuter Blutleere. Alles wirkt übersimplifiziert und mit zuviel langweiligem Weißraum aufgeblasen, der nur als Füllmaterial dient. Und natürlich schwer lesbare, ellenlange Textzeilen aufgrund der notorischen Einspaltigkeit.

Was liegt also näher als zu versuchen, einen faulen Kompromiss zu machen das Beste aus beiden Welten zusammenzubringen, und von der Mitte auszugehen? Ende letzten Jahres hatten wir genau diesen Gedanken, und Tablet First war geboren! Es funktioniert ganz genauso, wie man es sich vorstellt: Die Originalversion des CSS ist auf Hochkant-Tablets optimiert, und es gibt Anpassungen für breitere sowie, unabhängig davon, schmalere Bildschirme. In der Praxis sieht das dann so aus:

/* Normales CSS für alle Geräte: */
nav li { display: inline-block; }

/* Davon abweichende Regeln für Desktop-Größen: */
@media (min-width: 900px) {
   nav li { font-size: 1.1em; }
}

/* Weitere Abweichungen für Smartphone-Größen: */
@media (max-width: 500px) {
   nav li { display: block; }
}

Hammer, nicht wahr? Mit diesem Paradigma konzentrieren wir uns auf mittelgroße Bildschirme und geraten nicht in Versuchung, allzu komplexe oder allzu reduzierte Layout-Bausteine zu gestalten. Es bleibt irgendwie sane und handlebar. Was denkt ihr?

Bonus: Einbettung in Sass

Dieser Artikel könnte jetzt vorbei sein, doch ich lege noch einen drauf! Da wir, wie wohl die meisten von euch, inzwischen mit dem CSS-Präprozessor Sass arbeiten, haben wir uns angewöhnt, unsere Tablet-First-Media-Queries direkt in die CSS-Eigenschaften hineinzuschreiben, weil man so alle Regeln, die zu einem Element gehören, beisammen hat und nicht ständig zwischen verschiedenen Abschnitten einer CSS-Datei oder gar in verschiedenen CSS-Dateien umherspringen muss. Darüber hinaus verzichten ich gerne auf feste Breakpoints, die für alle Layout-Elemente gleichermaßen als die großen Parameter dieses Webprojekts gelten. Vielmehr setzen wir immer häufiger auf „Mikrobreakpoints“ – noch so ein Wort, was wir uns ausgedacht haben. Soll heißen: Bei der Gestaltung eines ganz bestimmten Elements mag es sinnvoll sein, bei genau 866px auf die Vierspaltigkeit zu wechseln, während bei einem anderen Element 910px der richtige Moment ist, das Floating umzudrehen. One Breakpoint fits all gibt’s ja irgendwie doch nicht wirklich.

Wenn wir alle drei Konzepte (Tablet First, Nested Media Queries, Mikrobreakpoints) zusammenfassen, könnte das in Sass etwa so aussehen:

nav li { 
   display: inline-block; 
   @include greater(900) {
      font-size: em(17);
   }
   @include smaller(500) {
      display: block;
   }
}

Um die Übersichtlichkeit noch ein kleines bisschen zu verbessern, habe ich im obigen Beispiel zwei Sass-Mixins und eine Funktion verwendet, die die Handhabung im Code vereinfacht, und ein paar good practises für die Media-Query-Syntax einsetzt:

@function em($px, $context: 16) {
   @return ($px / $context) * 1em;
}

@mixin smaller($px) {
   @media only screen and (max-width: em($px)) {
      @content;
   }
}

@mixin greater($px) {
   @media only screen and (min-width: em($px)) {
      @content;
   }
}

Jetzt ist aber wirklich Schluss. Über Anregungen und Kritik in den Kommentaren freuen wir uns!

10 Kommentare

  1. André am 1. Dezember 2015 #

    Also ausgehend vom Gerätetyp der wahrscheinlich am wenigsten genutzt wird (siehe Nutzungsverhalten), optimiert ihr für die beiden anderen sehr unterschiedlichen Bildschirmgrößen? Klingt sehr nach faulem Kompromiss! Aber gefällt mir trotzdem irgendwie, weil das Anpassen der Layouts vermutlich besser gelingen kann. Beweist das mal mit guten Beispielen!

  2. Gerrit am 1. Dezember 2015 #

    @André Jo, das ist tatsächlich ein wenig unorthodox – die am wenigsten genutzten Bildschirmgrößen als Referenz anzusehen. In Kürze gehen ein paar Projekte online, die so aufgebaut wurden. Stay tuned.

  3. Arne Kriedemann am 1. Dezember 2015 #

    Moin,

    interessanter Ansatz bzw. interessante Ansätze.
    Ich bin als 1970 Geborener KEIN digital native, sondern im Lese- und Konsumverhalten von gedruckten Inhalten geprägt durch Buch, Zeitung und Zeitschrift und beim Bewegtbild durch die klassische Glotze.
    Mein Tablet habe ich noch nie aka sehr selten im Portrait-Modus gehalten, sondern immer aka sehr häufig im Landscape-Modus.
    Da der Autor dieses Textes bekanntermaßen auch kein Kind der Nuller Jahre ist, würde mich interessieren, warum ihr den Portrait-Modus beim Tablet gewählt habt. Stützen Statistiken zur Nutzung diese Entscheidung? Mein Smartphone nutze ich natürlich hauptsächlich im Portrait-Modus und ich kann mich nicht erinnern, wann ich das letzte Mal versucht habe, meinen Desktop in den Portrait-Modus zu drehen, also stellt sich mir die Frage dort nicht.

  4. Gerrit am 1. Dezember 2015 #

    @Arne: Tablet quer ist ja beinahe Laptop-Breite. Mir geht es darum, eine Mittelwert zu finden, der zwischen 320 und 1280 liegt. Und da ist 768 eben besser als 1024 :-) Außerdem nutze ich mein iPad zum Lesen tatsächlich häufig hochkant, wegen Zeilenlänge.

  5. Chris am 1. Dezember 2015 #

    Ich bin mir nicht sicher, aber war das nicht so, dass bei max-width alle inkludierten Styles interpretiert (und ggf. Assets heruntergeladen werden), während das bei min-width nicht der fall ist?

    Das sollte bei der Smartphone-Filterung durchaus berücksichtigt werden.

  6. Gerrit am 1. Dezember 2015 #

    @Chris – bin nicht sicher, aber nach meiner Einschätzung wird auch auf den Smartphones de facto alles vorgeladen, was der Browser findet, unabhängig von greifenden Regeln.

  7. Daniel am 1. Dezember 2015 #

    Danke für die Ansätze und den Bonus! :)

  8. Christoph Zillgens am 1. Dezember 2015 #

    @Chris Assets werden nicht unbedingt alle geladen, siehe auch https://timkadlec.com/2012/04/media-query-asset-downloading-results/

    Zu Tablet-First:

    Ich habe mich vor längerer Zeit auch mal an diesem Ansatz versucht, nicht nur hinsichtlich CSS, sondern auch konzeptionell/gestalterisch.

    Während Tablet-First konzeptionell durchaus neue Impulse geben kann, kann ich einer solchen Reihenfolge hinsichtlich CSS aber wenig abgewinnen.

    Ich habe schnell festgestellt, dass ich zu viele Dinge im Smartphone CSS resetten muss, gerade solches CSS, das für Layout-Angaben genutzt wird. So bin ich dann häufiger bei Media-Queries gelandet, die für Tablet min- und max-Werte beinhalteten, was für Übersichtlichkeit und Nachvollziehbarkeit von Abhängigkeiten nicht förderlich war.

    Außerdem springt man während der Arbeit am CSS häufiger hin und her, was ich auch nicht als so angenehm empfunden habe, vor allem, wenn es sich um ein größeres Projekt mit umfangreichen CSS handelt.

    Daher bleibe ich bei linearem CSS von klein nach groß.

  9. Götz am 2. Dezember 2015 #

    Ich mache es bei vielen kleinen bis mittelgroßen Projekten auch ähnlich, denn fernab von CSS und Nutzerverhalten ist der Erstentwurf fürs Tablet in einem Punkt wirklich unschlagbar:

    Abstimmung mit dem Kunden!

    Mobile-first versteht nicht jeder Kunde und erfordert unglaublich viel Erklärungen, wenn ich erst mal nur ‘nen lange Grafik fürs Smartphone vorlege. Die Tabletansicht hingegen versteht der Kunde. Außerdem ist es ein ziemlich guter Indikator für Textlängen. Die Texte werden nicht zu kurz (wie in der reinen Smartphoneansicht), verleiten aber auch nicht zu Bleiwüsten, wie ein Entwurf mit 1600px Breite.

  10. Tilman am 3. Dezember 2015 #

    Der Ansatz ist wirklich sehr spannend. Inhaltlich – und ohne das in der Praxis selbst ausprobiert zu haben – würde ich Christoph Zillgens (#8) zustimmen.
    Dass mit Mobile First umgesetzte Websites in den “großen” Ansichten leer aussehe, lässt in meinen Augen diese Schlüsse zu: Ganz durchdrungen und verstanden ist der Begriff “Responsive Webdesign” noch nicht. Hier wird lediglich aus “Desktop First” ein “Mobile First” mit allen damit verbundenen Konsequenzen: Websites, bei denen ein “Responsive Retrofitting” angebracht ist ;)
    Die Auswirkungen der kaum überschaubaren Nutzungszenarien von Websites mit Smartphone bis Desktop sind so komplex, dass das Potential von Responsive Webdesign nur mit hohem Aufwand und einem entsprechenden Spezialisierungsgrad ausgeschöpft werden kann. Weniger aus technischen Gründen, sondern weil sich die Komplexität durch alle Gewerke zieht: Konzept, Redaktion, Gestaltung, technische Umsetzung auf Server- und Clientseite. Der Fokus von Responsive Webdesign löst sich nur langsam von den rein technischen Belangen. Was das z.B. für den Inhalt bedeutet, das bekommt nur langsam die nötige Aufmerksamkeit.

    Genau da finde ich Tablet-First als Ansatz attraktiv. Weil das Fleisch beide Brötchen berührt und Aufmerksamkeit für beide Richtungen herstellt. Die Kompromisse, die man für Anpassungen in beide Richtungen machen muss, dürften weniger gravierend sein, als die bereits angesprochenen: Endlos aneinander gereihte Inhalte auf dem kleinen Bildschirm oder gähnende Leere auf dem großen Bildschirm.
    Abgesehen davon verbessert es die Aufmerksamkeit für wichtige Interaktions- und Navigationselemente. Davon ausgehend, dass Websites auf Tablets für die Bedienung mit Gesten und Touch ausgerichtet sein dürften, entfallen Anpassungen für die Bedienung mit der Maus in der Regel weitestgehend. Da leidet die Tastaturnavigierbarkeit wohl mehr ;)

    Microbreakpoints ist auch ein schöner Begriff, mein Äquivalent dazu sind Tweakpoints. Die ergänzen das pro Projekt fixe Set an Breakpoints für diverse Gerätefamilien (Mobile, Phablet, Tablet, Desktop, Wide, …) und sind an einen definierten Nutzen gebunden, zum Beispiel Slider. Das verbessert die Übersichtlichkeit und bei der Nutzung von Prä- und Postprozessoren für Stylesheets lässt sich das gut zentral organisieren.

Kommentar schreiben

Nutzt Textile zum Strukturieren eures Textes.
SEO-Beiträge werden gelöscht, auch bei thematisch passendem Spam.