web & mobile DEVELOPER 04 / 2015

wmd-04-2015

 

Atomic Design

Die Metapher der klassischen Seite hat langsam ausgedient. Immer mehr Geräte mit immer mehr Auflösungen verlangen vor allem im Design-Prozess ein radikales Umdenken. Atomic Design kann dies perfekt unterstützen und noch einiges mehr.
Von Patrick Lobacher

Seit über 2000 Jahren haben Menschen Texte in Büchern organisiert und deren kleineste Einheit war die Buchseite. Als Tim Berners-Lee 1998 das World Wide Web schuf, war es daher nachvollziehbar, dass auch er Informationen in Seiten – sogenannten Dokumenten – organisierte.
Lange Zeit hat dies auch gut funktioniert, da vor allem eine wichtige Eigenschaft der Metapher über Jahre hinweg unverändert blieb bzw. sich nur so langsam änderte, dass es kaum aufgefallen ist: die Breite des Mediums. Während in den Anfangstagen des Webs Design noch überhaupt keine Rolle spielte, dauerte es nicht lange, bis – dank Werbung und Marketing – die ersten Designs erstellt wurden. Damals noch zur Ansicht auf 15 Zoll Monitoren – also mit max. 800×600 Pixeln – geeignet. Die Breite war vom Design her fix, nur die Höhe variabel, was der Designer mit „Above the Fold-Markierungen“ honorierte (der Bergriff kommt im Übrigen ebenfalls aus dem Print-Design). Viele Jahre später ist man dann auf max. 1024×768 Pixeln gegangen. Dieses Format war bis sicherlich weit nach 2010 noch das Maß der Dinge, was sich in Frameworks wie 960gs und vielen anderen manifestierte.

atomicdesign_lobacher_01

In der heutigen Welt, in der wir eine unglaubliche Menge an verschiedenen Geräten abdecken müssen, kommt die Metapher allerdings an ihre Grenzen. Wenn wir uns zwischen Smartwatch und 5k-Bildschirm bewegen und den Anspruch haben, auf allen Geräten eine gleichermaßen gute User Experience herzustellen, sind wir gezwungen von der Idee der Seite aus Sicht des Designs loszulassen. Stephen Hay (Autor des Buches: Responsive Design Workflow) meinte dazu „Wir designen keine Seiten. Wir designen ein System von Komponenten.“.

Das Ende der Photoshop Layouts

Wenn wir also modernes Webdesign gestalten wollen, ist völlig klar, dass Photoshop Layouts (oder die aus anderen, ähnlichen Programmen) der Vergangenheit angehören müssen. Denn einerseits ist es unmöglich, wirklich alle auch nur halbwegs wichtigen Größen zu designen. Man verwendet zwar meistens Breakpoints, an denen größere Änderungen durchgeführt werden, aber auch dazwischen kann es dank Responsivität zu Änderungen kommen, beispielsweise wenn eine Überschrift plötzlich umbricht, damit der Text darunter unter das daneben stehende Bild läuft, was wiederum dazu führen könnte das der abschließende Link nun recht verloren und deplatziert wirkt.
Vor allem für den Kunden wird dies eine große Herausforderung, da doch meist das Layout einer der ersten Schritte in einem Webprojekt ist und manchmal sogar zur Auswahl des Dienstleisters herangezogen wird.
Aber mit genügend Coaching und Consulting kann dieser allhergebrachte Prozess aufgebrochen und dem Kunden der neue, iterative Prozess beigebracht werden.
Zu diesem gehört insbesondere, dass nun nur noch Komponenten gestaltet werden, die am Ende ein Layout bilden.

Atome

Brad Frost (ein Webdesigner aus Pittsburgh, USA) hat beobachtet, dass bereits seit Jahren sogenannte Pattern (bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme) für allerlei Anwendungsfälle, wie Navigationen, Buttons, Formulare und andere UI-Elemente in der Programmierung verwendet werden. So basieren beispielsweise Twitter Bootstrap und Zurb Foundation auf zahlreichen Pattern, die man leicht – je nach Anwendungswunsch – einsetzen kann. Würde man nun diese Pattern in das Design übertragen, wäre hier ebenfalls eine Modularität der einzelnen Elemente gegeben.

atomicdesign_lobacher_02

Denkt man die Modularität konsequent nach unten, so stellt man fest, dass das kleineste mögliche (und sinnvolle) Element das HTML-Tag (oder Kombinationen von elementaren Tags) sein könnte.
Brad Frost hat diese Elemente als Atome bezeichnet, denn wie in der Chemie, sind alle Layouts am Ende aus diesen zusammengesetzt. Hier gibt es beispielsweise die Überschriften H1-H6, Absätze, Links, Buttons, Label, Formular-Elemente und ähnliches.
Diese werden nun von einem Designer gestaltet und von einem Kunden abgenommen. Es gibt Untersuchungen, nachdem ein Mensch Entscheidungen, wie sie ein Layout erfordert (ca. 200-300 Mikro-Entscheidungen für ein mittel komplexes Layout) überhaupt nicht qualifiziert treffen kann. Mikroentscheidungen (wie sie Atome darstellen) können aber gut getroffen werden.
Atome haben also folgende Charakterisierung:

  • Sind die Bausteine für ein Interface
  • Können nicht weiter zerlegt werden, ohne die Bedeutung zu verlieren
  • Sind Abstrakt
  • Oftmals alleine nicht sinnvoll einsetzbar
  • Gut als Übersicht-Referenz einsetzbar
  • Geeignet, um alles Styles in der Übersicht zu sehen

Atome können zudem auch abstraktere Elemente darstellen – wie z.B. Fonts, Farbpaletten oder Aspekte eines Interfaces wie Animationen.

Moleküle

Wie in der Chemie sind nun Moleküle die Zusammenstellung von mehreren Atomen. Ein Suchfeld beispielsweise besteht aus den Atomen Label („Suche“), einem Formularfeld und einem Button.
Moleküle weisen folgende Eigenschaften auf:

  • Gruppieren Atome
  • Kleinste fundamentale Einheit
  • Konkreter wie Atome
  • Folgen der „Mache eines und das richtig“-Philosophie
  • Sind oftmals die Bausteine für komplexere Systeme

Organismen

Die Zusammenstellung von Molekülen werden – laut Brad Frost – als Organismen ausgezeichnet, die sich wie folgt definieren:

  • Organismen sind komplexe Moleküle
  • Mehrere Moleküle formen eine individuelle bzw. eindeutige Sektion
  • Können aus gleichen und/oder verschiedenen Molekül-Typen bestehen
  • Stellen oftmals portable, wieder verwendbare, allein stehende Komponenten dar

Ein Organismus könnte beispielsweise die Navigationsleiste oben auf einer Seite sein, bei der sich rechts eine Suche befindet. Mit Hilfe von Organismen wird nun das spätere Layout deutlich konkreter und eignet sich auch für Kunden um sich in Teilen den Gesamtzusammenhang zu illustrieren.

Templates

Mit den Templates verlassen wir nun die Chemie-Analogie zugunsten einer Sprache, die für Kunden mehr Sinn macht. Grundsätzlich werden im Template Organismen zusammengefügt um damit Seiten zu formen.
Templates sind deutlich konkreter und stellen die Komponenten nun im Kontext dar. Diese sind sinnvollerweise als HTML-Wireframe realisiert.

 

Seiten

Seiten sind spezifische Template-Instanzen. Hier werden Platzhalter-Inhalte mit richtigem Inhalt ersetzt, um ein Gefühl dafür zu entwickeln, was der Benutzer später sehen wird.
Naturgemäß wird hier die meiste Zeit darauf verwendet, da Seiten das greifbarste Element in dem Prozess sind.

Letztlich werden auch Variationen direkt in den Seiten getestet – beispielsweise das Atom H1 einmal in 30pt und einmal in 40pt Schriftgröße. Nur in der Seite kann man entscheiden, in welche Richtung man tendieren würde.

Zusammenfassend kann man postulieren, dass die Konkretisierung des Design-Entwurfes vom Atom zur Seite zunimmt und nach links (also zu den Atomen hin) der Prozess sich eher an den Ersteller des Designs richtet und nach recht (also zur Seite hin) eher an den Kunden.

 

Pattern Lab

Um nun ein Atomic Design System zu erstellen bzw. auch zu pflegen, hat Brad Frost das sogenannte Pattern Lab aus der Taufe gehoben.

atomicdesign_lobacher_03

Das Pattern Lab ist:

  • eine umfangreiche Komponenten-Bibliothek
  • ein Starter-Kit für Patterns
  • ein Design-System-Builder
  • ein praktischer Viewport-Resizer
  • ein Design-Annotation-Tool
  • ein statischer Site-Builder

Das Pattern Lab ist zur Zeit in PHP realisiert und lässt sich entweder lokal oder auf dem Server installieren. Dafür notwendig ist PHP 5.3 oder größer. Daher muss man beispielsweise unter Mac OS X keine weiteren Schritte unternehmen, da PHP dort bereits installiert ist. Unter Windows kann man sich PHP unter der URL http://windows.php.net/download/#php-5.5 installieren.

Ein Webserver (wie Apache) ist zunächst nicht notwendig – es sei denn man will ein Feature nutzen, welches es ermöglicht, mit mehreren Geräten gleichzeitig automatisch zu einem gewählten Pattern zu navigieren.

 

Installation

Das Pattern Lab selbst befindet sich bei GitHub: https://github.com/pattern-lab/patternlab-php. Entweder checkt man nun das Repository lokal aus (hierfür wird Git benötigt) oder aber man lädt sich die zugehörige ZIP-Datei unter https://github.com/pattern-lab/patternlab-php/archive/master.zip herunter.

Nun muss die Pattern Lab Website generiert werden – dies geschieht ebenfalls über die Kommandozeile:

Die Website wird im Unterverzeichnis public erzeugt, welches auch eine index.html enthält, die man direkt im Browser ansehen kann.

atomicdesign_lobacher_04

Editieren der Sourcen

Da Pattern Lab ein Static Sitebuilder ist, sollte man natürlich alles unterhalb von public nicht direkt editieren, da diese sofort wieder überschrieben wird, sobald man die Generierung startet. Daher muss man die Quelldateien editieren – diese befinden sich unterhalb des Verzeichnisses source/. Die Unterverzeichnisse haben dabei folgende Bedeutung:

  • _data
    Hier liegen JSON-Dateien mit Dummy-Daten, die auf der Website ausgegeben werden
  • _patterns
    Hier gibt es fünf Unterverzeichnisse, die nach den Strukturen aus dem Atomic Design benannt sind und vorgefertigte Elemente beinhalten: 00-atoms, 01-molecules, 02-organisms, 03-tempates, 04-pages
  • css
    In diesem Verzeichnis liegt das Stylesheet – einmal als CSS aber auch als SCSS, um damit per Sass zu arbeiten (was dringend empfohlen wird)
  • fonts
    Hier befinden sich die Font-Dateien
  • images
    Alle verwendeten Bilder werden hier platziert
  • js
    Hier wurden JavaScript-Dateien abgelegt, die das Pattern Lab benötigt, wie z.B. jQuery oder Modernizr

Nimmt man nun hier Veränderung vor, müsste man den Site Builder jedesmal manuell neu starten, was gerade während der Entwicklung sehr unpraktisch ist.
Hier kann man sich behelfen, indem man den mitgelieferten Watcher wie folgt startet:

Nun werden die Verzeichnisse source/_patterns, source/_data/ auf Veränderungen kontrolliert und sofort der Browser aktualisiert, sobald eine gefunden wurde. Zudem werden alle Verzeichnisse die mit einem Unterstrich beginnen und im Oberverzeichnis source/ liegen kontrolliert, sowie alle Dateien die in Source liegen. Will man die beiden letzten einschränken, so kann man dies in der Datei config/config.ini einstellen.

 

Mustache

Für die Patterns selbst wird die „Templating-Sprache“ Mustache (http://mustache.github.io/mustache.5.html) verwendet. Die Verwendung dabei ist sehr einfach. Grundsätzlich ist das Mustache-Template ein normales HTML-Template und wird auch direkt also solches angezeigt. Allerdings kann man in den JSON-Dateien einen Schlüssel definieren, auf den man dann im Mustache-Template zugreifen kann:

Richtig spannend wird es aber dann, wenn man getreu der Idee des Atomic Designs nun Elemente wiederverwendet. Exemplarisch wollen wir daher ein Molekül „Text mit Bild“ aufbauen, welches aus den drei Atomen „Quadratisches Bild“, „Titel“ und „Absatz“ besteht.
Dafür legen wir zunächst den Ordner source/_patterns/01-molecules/08-wmd an. Die Nummer zeigt die Reihenfolge der Inklusion an – da unser Molekül am Ende kommen soll und es bereits 7 Moleküle in dem Ordner gibt, geben wir ihm die nächst höhere Nummer 8.
Innerhalb des Ordners legen wir eine Datei 00-text-mit-bild.mustache an. Dorthinein schreiben wir folgendes Markup:

Hier wird das Molekül aufgebaut – zunächst wird dazu die URL mittels {{ url }} verwendet, in der JSON-Datei _data/_data.json definiert wurde (dies ist schlicht #).

atomicdesign_lobacher_05

Nun wird das Atom für ein quadratisches Bild üebr {{> atoms-square }} eingebunden. Dabei wird wie folgt vorgegangen:

  • Die Datei, die tatsächlich eingebunden wird, befindet sich im Verzeichnis: _patterns/00-atoms/04-images/03-square.mustache
  • Die Syntax, um anderen Templates einzubinden lautet generell {{> [patternType]-[patternName] }}
  • Der PatternType befindet sich auf der ersten Ebene des Patterns-Verzeichnis – dabei werden die Zahlen ignoriert. Fündig wird das Pattern Lab also bei _patterns/00-atoms
  • Nun wird bis zur letzten Ebene geschaut (also innerhalb von 04-images) ob es dort eine Datei gibt, welches square im Namen trägt.
  • Will man aber sichergehen, so kann man auch den kompletten Pfad inkludieren – lediglich die Extension wird dann weggelassen: {{> 00-atoms/04-images/03-square }}

Header & Footer

Für den Fall, dass man den Header und/oder den Footer verändern will, um beispielsweise zusätzliche JavaScript-Dateien zu laden, kann man die folgenden Dateien ergänzen:

source/_patterns/00-atoms/00-meta/_00-head.mustache
source/_patterns/00-atoms/00-meta/_01-foot.mustache

Wichtig ist hier nur, niemals die Zeilen {% pattern-lab-head %} und {% pattern-lab-foot %} zu verändern, da ansonsten das Pattern Lab den Betrieb einstellt.

 

Weitere Features

Damit ist aber das Pattern Lab noch nicht am Ende – folgende Features warten noch, um die Erstellung von Atomic Designs zu vereinfachen: Pseudo Patterns, Pattern-Parameter, Pattern-States, styleModifiers, Annotations, Mobile Viewer (z.B. über QR-Codes), Page follow, Compass-Integration, Grunt-Integration, u.v.w.m.

 

Fazit

Mit Hilfe des Pattern Labs ist es nun auch systematisch einfach geworden, ein iteratives Design zu entwickeln, welches auf Prototypen basiert. Erst damit kann das volle Potential von professionellem Responsive Webdesign ausgeschöpft werden. Wer weiter gehende Informationen zu diesem spannenden Thema sucht: Brad Frost schreibt gerade an einem eigenen Buch zu Atomic Design, welches unter der URL http://atomicdesign.bradfrost.com erhältlich ist.

 

Links zum Thema

Atomic Design Website
https://www.gitbook.com

Atomic Design Vortrag
http://vimeo.com/67476280

Pattern Lab
http://patternlab.io

Pattern Lab Dokumentation
http://patternlab.io/docs/index.html

Pattern Lab Demo
http://demo.patternlab.io

GitHub Account Pattern Lab
https://github.com/pattern-lab/patternlab-php

Leave a Comment.