Vom Design zum Code

Designen in Figma

Unsere Designer arbeiten mit Figma, einem webbasierten Design-Tool, das für die einfache Zusammenarbeit mit Entwicklern entwickelt wurde. Wir werden später zeigen, wie wir das konkret nutzen, aber zuerst ein Blick darauf, wie wir die Projekte strukturieren.

Normalerweise legen wir zuerst fünf sogenannte Pages in Figma an:

• Design Tokens
• Elements
• Patterns
• Template Components
• Templates

Design Tokens

Design Tokens sind eine Gruppe an Designmerkmalen – Farben, Typografie, Größe und Effekte, die produktübergreifend verwendet werden, um eine einheitliche und einfache Designsprache zu schaffen.

Bei den Design Tokens erstellen wir vier verschiedene Artboards: Colors, Typography, Spacings, Other.

Colors können Farben für die Typografie, aber auch dekorative Farben enthalten. Uns ist es wichtig, diese beiden Arten von Farben zu trennen, um sicherzustellen, dass bestimmte Farben nur für bestimmte Zwecke verwendet werden. Beispielsweise eignet sich ein helles Grau gut für Hintergründe oder Umrisse, aber nicht für die Typografie, da das Kontrastverhältnis insbesondere für sehbehinderte Nutzer zu gering sein könnte.

Spacings enthalten eine Liste von pixelbasierten Abstandswerten (die später in CSS in rem umgewandelt werden), die in der Regel bei 4 beginnen und nicht mehr als 8 bis 10 Werte enthalten.

Typography umfasst alle Arten von Textstilen: Überschriften, Fließtext, hervorgehobener Text, Links und so weiter.

Unter Other definieren wir Werte für Höhe, Rahmen, Radien oder bestimmte Stile, die beispielsweise für Hover-Effekte oder Überlagerungen benötigt werden.

Elements, Patterns, Template Components und Templates

Die Seiten Elements, Patterns, Template Components und Templates enthalten die eigentlichen Designs.

Unter Elements gibt es kleine Komponenten, die überall wiederverwendet werden können. Dabei handelt es sich in der Regel um Komponenten wie Buttons, Icons, Formularelemente, Bilder, usw.

Patterns sind Kombinationen von Elements, aber nicht nur. Es handelt sich eher um komplexe Komponenten wie eine Bildergalerie, Rich Text, eine Galerie und so weiter. Diese Komponenten können später von den Redakteuren eines CMS ausgewählt werden, um den Inhalt einer Website zusammenzustellen, z.B. mit dem Layout Builder von Drupal.

Template Components sind die einzelnen Teile eines Templates: Header, Footer, Navigation, Suchergebnisse, Seitenleiste usw. Diese Elemente können nicht von Redakteuren ausgewählt werden, sondern sind fester Bestandteil der Templates.

Templates bringen alles zusammen: Sie verbinden Template Components und Patterns und stellen komplette Seiten wie eine Startseite, Produktseite, Suchergebnisse usw. dar.

Import der Design Tokens per Figma API

Bei der Benennung von Pages, Artboards und Tokens in Figma ist es sehr wichtig, dass wir einer bestimmten Struktur und Namenskonvention folgen. Das erleichtert nicht nur die Kommunikation und Wiederverwendbarkeit, sondern ermöglicht es uns auch, die Figma-API zu nutzen, um unsere Design-Tokens und Komponenten direkt in unsere Projekte zu importieren.

Unser Frontend-Stack, der Teil jedes neuen Projekts ist, enthält ein kleines Skript, mit dem wir genau das tun können. Bei der Ausführung verbindet es sich über die Figma-API mit unserer Figma-Datei, empfängt eine JSON-Response mit allen notwendigen Informationen zu den Designs und erstellt dann

• eine tokens.css-Datei, die CSS Custom Properties basierend auf den Design Tokens in unserer Figma-Datei enthält,
• sowie leere Komponenten basierend auf den anderen vier Pages in Figma.

Die Custom Properties werden entsprechend den Design-Tokens in der Figma-Datei benannt. Dadurch wird sichergestellt, dass Designer und Entwickler über dieselben Dinge sprechen, und es ist einfacher, sich die Namen zu merken. Da diese Datei automatisch generiert werden, sollte sie niemals vom Entwickler geändert werden. Sobald wir den Import erneut ausführen, würde diese Datei überschrieben werden.

Für Elements, Patterns, Template Components und Templates erstellt das Skript leere Komponenten in derselben Hierarchie. Wenn die Figma-Datei beispielsweise eine Button-Komponente auf dem Artboard „Elements“ enthält, würde es erstellen:

Dies würde nur dann geschehen, wenn diese Komponente noch nicht existiert, um ein Überschreiben bereits implementierter Komponenten zu vermeiden.

Während button.css und button.twig (Twig ist die von uns gewählte Template-Sprache) Teil der eigentlichen Komponente sind, sind mocks.yaml und schema.yaml wichtig für die Zusammenarbeit mit Backend-Entwicklern und für unsere Komponentenbibliothek.

Entwicklung in miyagi

Nachdem wir Pattern Lab viele Jahre lang verwendet hatten, erfüllte es unsere Anforderungen als Komponentenbibliothek immer weniger. Es ist ein bewährtes, gut funktionierendes Tool, aber mit der Zeit fühlte es sich für uns zu schwerfällig und langsam an. Außerdem hatten wir immer mehr Anforderungen, die unsere Komponentenbibliothek erfüllen sollte, und Pattern Lab war dazu einfach nicht in der Lage. Nachdem ich viele verschiedene Tools evaluiert hatte und kein einziges Tool finden konnte, das alle unsere Anforderungen erfüllte, habe ich schließlich selbst ein Tool für diesen Zweck entwickelt. Es heißt miyagi.

miyagi ist ein node module, das einen Express-Server verwendet und sich grundsätzlich an jede Projektstruktur anpassen lässt. Wir können die Ordner und Komponenten beliebig benennen, sie beliebig tief verschachteln, (fast) jede Art von JavaScript-Templating-Sprache verwenden, und alles, was wir in einem Projekt benötigen, ist eine Konfigurationsdatei (es funktioniert sogar ohne Konfigurationsdatei, indem es versucht, Ihre Template-Sprache zu ermitteln, aber dafür müssen wir eine bestimmte Namenskonvention für Ihre Ordner und Komponenten befolgen). Dadurch können wir es in verschiedenen Arten von Projekten verwenden und gleichzeitig die Projektstruktur vollständig unabhängig von unserer Komponentenbibliothek halten. Wenn wir jemals eine andere verwenden möchten, müssen wir lediglich die Konfigurationsdatei entfernen.

Design Tokens

Wenn wir die Startseite einer miyagi-Anwendung öffnen, erhalten wir eine Darstellung unserer Design Tokens: miyagi ist in der Lage, unsere CSS-Dateien zu analysieren, nach Custom Properties mit einer bestimmten Benennung zu suchen (die wir dank unseres Token-Importers automatisch erhalten) und eine Übersicht über alle Design-Token zu erstellen, die wir in einem Projekt haben.

Anpassung ans CI des Kunden

miyagi kann auch an das CI unserer Kunden angepasst werden: Schriftarten, Farben, ein Logo und grundsätzlich jedes CSS können hinzugefügt werden, um dem Kunden das Gefühl zu geben, dass es sich um seine eigene Komponentenbibliothek handelt.

Die Schema-Dateien

Die Schema-Dateien sind JSON-Schema-Dateien. Wir verwenden sie, um eine bestimmte Datenstruktur für eine Komponente zu vereinbaren und sicherzustellen, dass die von einer API bereitgestellten Daten tatsächlich zu dieser Komponente passen. Sie ermöglichen es unseren Designern aber auch, bestimmte Einschränkungen festzulegen, z. B. dass ein bestimmter Text nur 200 Zeichen lang sein darf usw.

Obwohl diese Schema-Dateien unabhängig von einer Komponentenbibliothek sind, werden sie dennoch von miyagi zur Validierung der Mock-Daten verwendet: Wenn die für eine Komponente angegebenen Mock-Daten nicht zum angegebenen JSON-Schema passen, wird ein Fehler ausgegeben.

Die Mock-Dateien

Ein Aspekt von Komponentenbibliotheken ist in der Regel, dass sie eine gekapselte und unabhängige Entwicklung von Komponenten ermöglichen. Das bedeutet, dass Frontend-Entwickler eine Komponente erstellen können, ohne auf eine Backend-Implementierung warten zu müssen, die ihnen Daten oder eine Umgebung zum Rendern dieser Komponente bereitstellt.

Um dies in miyagi zu erreichen, können wir Mock-Dateien erstellen, um Dummy-Daten für unsere Komponenten bereitzustellen. Diese können statisch im YAML- oder JSON-Format sein, wir können aber auch JavaScript-Dateien verwenden, die beispielsweise Daten aus einer API asynchron exportieren. Auf diese Weise können wir viele verschiedene Varianten einer Komponente erstellen, um sicherzustellen, dass die Komponenten immer funktionieren, unabhängig davon, wie die an die Komponente übergebenen Daten aussehen.

Basierend auf diesen Mock-Dateien erstellt miyagi für jede Variante eine separate Ansicht. Wir verwenden diese Ansichten auch für unsere Visual Regression Tests.

Visual regression tests mit unserer Komponentenbibliothek

Um sicherzustellen, dass wir nicht versehentlich visuelle Veränderungen verursachen, verwenden wir BackstopJS, um unsere Komponenten (einschließlich aller Elements, Patterns, Template Components und Templates) genau darauf zu testen.

Das funktioniert so, dass wir beim Erstellen eines Pull-Requests in unserem Git-Repository zunächst einen statischen Build unserer Komponentenbibliothek erstellen (der später auf einer dedizierten Instanz bereitgestellt wird, sodass alle darauf zugreifen können: Designer, Entwickler, Projektmanager, der Kunde usw.) und dann diese statischen Build-Dateien mit den vorherigen (die im Git-Repository eingecheckt sind) vergleichen.

Das bedeutet, dass wir eine direkte Verbindung zwischen unserer Komponentenbibliothek und unseren visuellen Regressionstests haben und nicht von Drittanbieterdiensten abhängig sind: Es gibt keine Ausfallzeiten und nichts verlässt unsere Server.

Neue Projekte basierend auf dem Frontend Starter Kit

Zu guter Letzt haben wir versucht, die Dinge noch einfacher, noch konsistenter und damit noch besser und stabiler zu gestalten.

Da Websites häufig aus denselben (oder zumindest sehr ähnlichen) Komponenten bestehen, haben wir das Frontend Starter Kit entwickelt, das im Wesentlichen aus all dem oben Genannten besteht:

• eine Figma-Datei, die barrierefreie Farben, Typografie, Komponenten wie Formularelemente usw. enthält,
• Web Components für Formularelemente und andere wiederkehrende Komponenten, die als node modules veröffentlicht werden,
• ein Drupal-Theme, das Formularelemente und andere Arten von Komponenten bereitstellt,
• alles entwickelt und getestet mit Visual Regression Tests basierend auf miyagi.

Dieses Frontend Starter Kit eignet sich für viele verschiedene Arten von Projekten, und da wir die Komponenten als node modules veröffentlichen, können wir sie sogar in Vue-Projekten verwenden.

Insgesamt ermöglicht uns dies eine standardisierte, bewährte und konsistente Basis für alle unsere Projekte, wodurch wir die “langweilige” Arbeit, die jedes Projekt mit sich bringt, vermeiden und uns stattdessen auf den Rest konzentrieren können.