Keine Frage des Werkzeugs

Im Moment befasse ich mich viel mit Pattern Libraries und wie man sie baut, organisiert und verwaltet. Wie so ziemlich jede(r) in der Webentwicklung derzeit stürzte ich mich dabei natürlich zuerst auf Tools, nur um relativ schnell festzustellen, was scheinbar für viele oder alle Aspekte moderner, modularer Webentwicklung und -gestaltung zu gelten scheint: Das Werkzeug ist eigentlich nebensächlich.

Ob man nun Astrum, Fractal, PatternLab oder doch eine andere Lösung wählt, ist eher eine Frage der persönlichen Vorliebe, der Rahmenbedingungen des Projektes oder der bevorzugten Arbeitsabläufe des Teams. Das ist in meinen Augen durchaus ein sich wiederholendes Muster in modernen WebDev-Werkzeugen und -Techniken. SASS, LESS, Stylus und/oder PostCSS? Eigentlich egal. Atomic Design, OOCSS, SmaCSS und/oder BEM? Wie man möchte.

Die wahre Herausforderung

Die eigentliche Herausforderung an Pattern Libraries ist gar nicht die Wahl des passenden Tools, sondern die Organisation der Patterns.

— Matthias Mees (@yellowled) March 24, 2017

Hat man sich erstmal für ein Tool entschieden, das die Pattern Library erzeugt, kommt die wahre Schwierigkeit: Wie strukturiert und organisiert man nun die (normalerweise) zu erstellenden Patterns? Wie detailliert bzw. wie granular geht man die Sache überhaupt an?

Atomic Design z.B. beginnt mit (der Name deutet es an) Atomen – grundlegende HTML-Elemente, die nicht in kleinere Teile zerlegt werden können. Das meint z.B. auch eine Checkbox ohne Label oder eine einsame <hr>, wenn man so fein granuliert arbeiten möchte. Ich finde diesen Ansatz in vielen Fällen richtig, weil er es erschwert, „ungestaltete“ Elemente zu haben; das mag man u.A. aus Performancegründen anders sehen.

Teilt man diese Atome z.B. nochmal in thematisch zusammenhängende Gruppen (Typografie, Medien, Formularelemente, Listen etc.) auf, um die Pattern Library übersichtlich zu halten oder zerstören zu viele Kategorien gar die Übersichtlichkeit? Falls ja, übernimmt man diese Kategorien in die „nächsthörere Ebene“, gruppiert also z.B. in Atomic Design Moleküle und Organismen in entsprechenden Kategorien?

Hat man diese „Grundlagen-Elemente“ hinter sich, geben die Anforderungen des Projektes üblicherweise vor, welche Moleküle und Organismen benötigt werden; vieles davon (Header, Footer etc.) ist inzwischen nahezu standardisiert, der Rest ergibt sich aus „Wir brauchen …“-Anforderungen. Da liegt in meinen Augen eine Gefahr für „Wildwuchs“ – eine sauber strukturierte, gut organisierte Pattern Library braucht eben das, was in Projekten oft knapp bemessen ist: Zeit. Mehr Zeit bekommt man nur, wenn die Wertschätzung für den Nutzen der Pattern Library da ist.