Zeitgemäße Design Systems mit Figma, Storybook und Angular (Teil 1)
Christian Liebel, Andreas Wissel
(Bild: Blackboard/Shutterstock.com)
Zeitgemäße Anwendungen erfordern eine enge Zusammenarbeit von Entwicklern und Designern. Die Tools Figma, Storybook und Angular helfen bei der Kollaboration.
App-Entwickler kennen das Problem: Softwareentwickler und Designer sprechen oftmals eine andere Sprache. Steigende Anforderungen an zeitgemäße Software erfordern jedoch, dass beide zusammenarbeiten. Die Artikelserie erklärt, wie Softwareanbieter mit dem JavaScript-Framework Angular und den Tools Figma und Storybook robuste Design Systems aufziehen können, die Entwickler und Designer näher zusammenbringen. Ergänzend zu den Werkzeugen hilft ein Prozess, der zur interdisziplinären Zusammenarbeit anregt.
Storybook hilft, Entwurf und Code näher zusammenzubringen. In einer Bibliothek erhalten Entwickler und Designer einen einfachen Zugang zu Komponenten, ohne die komplette Anwendung starten zu müssen. Eigenschaften lassen sich über eine Formularmaske anpassen, die die Änderungen direkt umsetzt. (Abb. 1)
Heutige Clientanwendungen laufen nicht mehr nur auf Windows, sondern müssen sich auf einer ganzen Reihe an Plattformen behaupten: Das schließt die Desktopbetriebssysteme Windows, macOS und Linux, aber auch mobile Betriebssysteme wie iOS und Android und das Web ein, wo mit Progressive Web Apps ebenfalls ein Anwendungsmodell zur Verfügung steht. Entwickler plattformübergreifender Software stehen oftmals vor dem Problem, eine konsistente Benutzererfahrung über die Plattformen hinweg anzubieten. Google implementiert in Chrome beispielsweise Material Design, das sich nur an den Stil der nativen Plattform anlehnt.
Spotify ignoriert die Plattformkonventionen sogar komplett und etabliert stattdessen eigene Konventionen, die unabhängig von der Zielplattform funktionieren und den Nutzer durch iterative Änderungen langsam aufgleisen. Oberflächen müssen nicht mehr nur schick aussehen – vielmehr müssen sie Anwender an die Software binden.
Zeitgemäße Design Systems mit Figma, Storybook und Angular
Mit den wachsenden Anforderungen an Applikationen steigt der Bedarf für robustere Prozesse. Im Kontext agiler Softwareentwicklung gilt vor allem eine Maxime: Scheitere früh, scheitere oft. Releasezyklen sind immer kürzer, um möglichst wenig Reibungsverluste gegenüber den Mitbewerbern zu erzeugen und Hypothesen früh zu validieren. Dafür braucht es einen verlässlichen Prozess, der iterativer Entwicklung Stand hält.
Eine solche Komponentenbibliothek ist Teil eines Design Systems (Abb. 2)
Design Systems bieten hierfür einen Weg: Sie sind zugleich Dokumentation, Komponentenbibliothek (s. Abb. 2) und Werkbank für das komplette Team. Aus Techniken wie Living Styleguides, Kompontenbibliotheken und Pattern Libraries gewachsen bieten sie eine einfache Möglichkeit, einen Konsens im Team zu erzeugen. Darüber hinaus bieten Design Systems die Chance, die Entwicklung von komplexen Applikationen durch Dokumentation und klare Schnittpunkte zu entwirren. Vor allem steht bei Design Systems ein Kerngedanke im Vordergrund, der in der Softwareentwicklung seit Jahrzehnten großen Anklang findet: Alles basiert auf Komponenten.
Design Systems im Kontext moderner Softwareentwicklung
Design Systems passen hervorragend zum Konzept des Component-based Software Engineering (CBSE), einem wesentlichen Fundament für skalierbare Anwendungen. Die Idee ist alt: Größere Aufmerksamkeit erhielt das Thema der komponentenorientierten Entwicklung bei einer NATO-Konferenz in Garmisch-Partenkirchen im Jahre 1968 – als Reaktion auf die sogenannte Softwarekrise. Damals waren Softwareprojekte zu komplex, und wurden oft nicht rechtzeitig oder gar nicht fertig.
Um das zu adressieren, schauten sich die frühen Softwareingenieure in der Industrie um: Denn in der Massenproduktion gab es Standardteile, die Hersteller je nach Anforderung austauschen und von Zulieferern beziehen konnten. Douglas McIlroy übertrug die Idee auf die Softwareentwicklung.
Softwarekomponenten zeichnen sich dadurch aus, dass sie abgeschlossen sind ("black box"), isoliert, wohldefinierte Ein- und Ausgänge besitzen, dadurch einfach testbar und wiederverwendbar sind. Darüber hinaus können Entwickler sie von Drittanbietern und über Marktplätze bekommen. Mit npm, NuGet und Maven existieren riesige solcher Softwaremarktplätze, bei denen Kunden oftmals sogar aus verschiedenen Implementierungen auswählen können.
Darauf aufbauend wollen Design Systems nun den Durchstich in die grafische Welt schaffen: Projektbeteiligte sollen auf allen Ebenen, also auch in visuellen Entwürfen am Whiteboard oder einem Grafikdesign-Tool, nur noch in Komponenten denken. Durch den konsequenten Einsatz der Komponentenorientierung rücken Konzeption und Entwicklung – Design und Code – näher zusammen und bilden eine durchgängige Einheit. Anstatt über abstrakte Entwürfe zu sprechen, sollen konkrete, lebendige Komponenten ein gemeinsames Verständnis schaffen. Richtig angelegt ergeben sich sogar Synergieeffekte für das Testing der Komponenten, da Beteiligte etwa Mock-Implementierungen zwischen Design System und Unit-Tests teilen können.
Design Systems im Kontext der User Experience
Aus der Softwareentwicklung nicht wegzudenken ist das Thema User Experience. ISO 9241-210 versteht darunter alle Aspekte der Erfahrung des Nutzers bei der Interaktion mit einem Produkt oder Dienst, einer Umgebung oder Einrichtung. Zunehmend komplexe Anwendungen ringen ihren Benutzern immer mehr kognitive Leistung ab. Es ist mittlerweile das Credo aller Branchengiganten (Google, Facebook, Twitter und Co.) geworden, die teilweise komplexen Workflows durch intelligente und lernende Benutzeroberflächen und grafischen Elementen wie Illustrationen und Animationen zu vereinfachen.
Um die sogenannte kognitive Belastung zu schmälern [4], setzen Entwickler vor allem auf Konsistenz und bekannte Bedienmuster. Selbst hochkomplexe (Business-)Awnendungen führen Nutzer spielerisch an Funktionen heran, um die Belastung durch langwierige Schulungen hin zu einfach verständlichen Benutzeroberflächen zu verlagern. Denn: Noch nie war der Softwaremarkt so hart umkämpft wie heute.
Dabei können Design Systems ebenfalls helfen. Durch die klare Strukturierung und scharf definierte Use-Cases ist es deutlich einfacher, Features zugänglich zu gestalten. Auch hier kommt das Prinzip "Fail Early Fail Often" zum Einsatz. Die Annahmen, die Entwickler zu neuen Features treffen, können sie innerhalb kurzer Zeit in Form eines Benutzertests innerhalb des Design System validieren. Eine Neuentwicklung im laufenden Produktzyklus stellt dank der isolierten Komponenten ebenfalls keine große Herausforderung mehr dar: Enterprise-Entwicklung im Silicon-Valley-Stil.
Tooling: Angular, Figma und Storybook
Zur Umsetzung zeitgemäßer Design Systems stehen ausgereifte Werkzeuge zur Verfügung, sodass Entwickler keine eigenen Entwicklungen implementieren müssen. Die Artikelserie konzentriert sich auf einen Stack bestehend aus dem Framework Angular sowie den Tools Figma und Storybook.
Das JavaScript-Framework Angular
Angular ist ein quelloffenes Framework [5] zur Implementierung von Single-Page Applications (SPA), das von Google entwickelt wird. Angular setzt ebenfalls auf CBSE. Wiederverwendbare UI-Bausteine heißen bei Angular sogar "Komponenten". Eine solche besteht aus einem HTML-Template, einem Stylesheet in CSS oder einem darauf aufsetzenden Dialekt sowie einer Logikklasse, meistens in TypeScript verfasst:
Das obige Listing zeigt eine solche Komponentenklasse am Beispiel einer einfachen Button-Komponente. Wie dort zu sehen, kommt sie über den benutzerdefinierten Selektor app-button (Zeile 2) zum Einsatz. Mit sogenannten Input- und Output-Bindings können Entwickler kontextabhängige Daten in die Komponente einreichen beziehungsweise von ihr entgegennehmen. In Zeile 7 ist ein solches Input-Binding zu sehen, das die Beschriftung der Schaltfläche definiert. Verwenden können Anwender die Komponente wie folgt:
<app-button caption="Test"></app-button>
Das benutzerdefinierte HTML-Element können Anwender beliebig duplizieren und mit unterschiedlichen Beschriftungen versehen. Zeile 3 zeigt das HTML-Template der Komponente. Da es sehr kurz ist, ist es zu Demonstrationszwecken direkt in der Komponentenklasse angegeben. In echten Anwendungen befindet sich das Template in einer eigenen HTML-Datei, die neben der TypeScript-Komponentenklasse liegt.
Die doppelten geschwungenen Klammern repräsentieren ein sogenanntes Data Binding. Angular interpoliert zur Laufzeit an dieser Stelle den echten Wert, der sich im caption-Feld befindet, also von außen über das Input-Binding eingereicht wurde. Die Button-Komponente kapselt ein HTML-Button-Element und wendet die von außen angegebene Beschriftung darauf an. Zeile 4 referenziert eine SCSS-Datei.
Das Stylesheet im Detail
Das folgende Listing gibt den Inhalt des Stylesheets wieder.
Das Stylesheet verwendet gleich in Zeile 1 den button-Selektor, der im nachfolgenden Regeln erhält, etwa die Rahmengestaltung oder Farben. Der Einfachheit halber hinterlegt das Listing die Farbwerte direkt im Stylesheet, in echten Anwendungsfällen wäre eine Deklarierung an zentraler Stelle als Variablen sinnvoller. Normalerweise beziehen sich die gezeigten Regeln auf sämtliche button-Elemente auf der gesamten Website.
Angular wendet das Komponenten-CSS jedoch lediglich auf die aktuelle Komponente an; insbesondere hat das Stylesheet nicht in äußeren Kontexten Gültigkeit. Das nennt Angular View Encapsulation und es soll unübersichtliche, globale CSS-Stile à la Bootstrap vermeiden. Entwickler können im Gegensatz zu Namensschemata wie BEM (Block, Element, Modifier) einfache, generische Selektoren verwenden, ohne Seiteneffekte fürchten zu müssen.
Dazu fügt Angular standardmäßig dem angegebenen Selektor automatisch zur Laufzeit einen weiteren, spezifischen Selektor hinzu, wie in den Entwicklertools in Abb. 3 zu sehen. Das soll sicherstellen, dass sich die CSS-Stile nicht auf andere Komponenten ausbreiten. Die Methode nennt Angular ViewEncapsulation.Emulated.
Angular modifiziert die CSS-Selektoren, um die View-Encapsulation umzusetzen. (Abb. 3)
Teil der Web-Components-Schnittstellen bildet das Shadow DOM (Document Object Model), über das Entwickler eine Isolation der Komponenten auf technischer Ebene sicherstellen können. Die Web-Components-Schnittstellen verstehen noch nicht allen im Umlauf befindlichen Browser [8]. Möchten Entwickler das Shadow DOM heute in Angular verwenden, können sie auf die Strategie ViewEncapsulation.Native umsteigen. Dann kommt für die damit ausgezeichnete Komponente das Shadow DOM zum Einsatz.
Das Designwerkzeug Figma
Am Anfang eines jeden guten Design Systems steht der grafische Entwurf. Durch gezieltes Prototyping bleiben die Iterationszyklen kurz und eine schnelle Visualisierung von Ideen ist garantiert. Neben Whiteboard, Flipchart und Haftnotizen besticht vor allem ein digitales Gegenstück durch die saubere Integration von Komponenten, Prototyping und Kollaboration: Figma. Das kommerzielle, browserbasierte Tool [9] ermöglicht es Anwendern, Entwürfe in Echtzeit mit Kollegen zu teilen und von vornherein komponentenorientiert zu arbeiten.
Figma ist ein grafisches Tool, um Benutzeroberflächen kollaborativ und komponentenorientiert zu entwerfen. Links sind die einzelnen Bestandteile des Screens zu sehen, rechts die Eigenschaften des ausgewählten Objekts. (Abb. 4)
Im Mittelpunkt stehen auch hier Komponenten. In Figma versteht man darunter die Möglichkeit, grafische Entwürfe modular und zusammensetzbar zu gestalten (s. Abb. 4). Einmal erstellt, schlagen sich Änderungen an der sogenannten Master Component durch alle Instanzen der Component durch. Mit dem bekannten Konzept aus der Softwareentwicklung lässt sich die Produktivität im fortlaufenden Designprozess steigern. Es empfiehlt sich, Übersichtsseiten wie in Abbildung 5 anzulegen, um alle Komponenten auf einen Blick einsehen zu können.
Auch Komponentenbibliotheken können Anwender mit Figma erstellen. Links sind die einzelnen Komponenten zu sehen, aus denen sich die Übersicht zusammensetzt. (Abb. 5)
Die Generierung von CSS-, iOS- oder Android-Stilen beherrscht Figma weitestgehend sauber. Sortieren Anwender den generierten Code etwas aus, können sie mit wenigen Handgriffen die entsprechenden Stile für die Komponente bereitstellen (s. Abb. 6). Dadurch positioniert sich Figma als Platzhirsch im Bereich des Design-Toolings. Denn kaum ein anderes Werkzeug versteht es so gut, auf die Bedürfnisse verschiedener Zielgruppen einzugehen. Nennenswerte Konkurrenten sind Sketch und Adobe Experience Design.
Figma generiert aus dem Prototyp CSS-Stile (rechts), die man oftmals mit geringfügigen Anpassungen direkt übernehmen kann. Interessant ist der untere Block mit den Stilinformationen. (Abb. 6)
Für Entwickler: Storybook
Das Gegenstück zu Figma im Code bildet das quelloffene Tool Storybook [10]. Es setzt die visuellen Abbildungen der Komponenten in echte, lebendige Komponenten im Framework der Wahl um. Storybook stammt ursprünglich aus der React-Welt, funktioniert aber mit vielen Frameworks, darunter Vue.js oder Angular. Storybook ist durch eine Vielzahl von Add-ons erweiterbar und bildet die Schnittstelle zwischen Designer und Entwickler. Insbesondere ermöglicht es eine Dokumentation direkt an den Komponenten.
Ein besonderes Augenmerk sollten Anwender darauf legen, die Komponenten von Anfang an mit klaren Schnittstellen zu konzipieren und dass sie ohne Abhängigkeiten funktionieren.
Die Komponenten können Entwickler, nach einem erfolgreichen Test, direkt in der Anwendung weiterverwenden. Dem Einsatz in der Produktivumgebung steht demnach nichts im Wege. Die übersichtliche Oberfläche von Storybook (s. Abb. 1) ermöglicht es nichttechnischen Mitarbeitern, direkt mit den Komponenten zu interagieren. Reviews und Demos können Teams direkt in Storybook durchführen und tragen dadurch den Komponentengedanken in die Planungsebene.
Der Weg zum eigenen Design System
Zunächst gilt es, die Entwicklungsumgebung mit Angular und Storybook aufzusetzen. Für die folgenden Schritte benötigen Interessierte eine aktuelle Version von Microsoft Windows, macOS oder Linux, eine aktuelle Version von Node.js, einen Texteditor, bevorzugt Microsoft Visual Studio Code sowie einen aktuellen Webbrowser (Google Chrome, Apple Safari, Mozilla Firefox oder Microsoft Edge). Eventuell benötigt der Computer nach der Installation von Node.js einen Neustart. Manche der folgenden Kommandozeilenaufrufe geben bestimmte Versionsnummern ("@1.2.3") mit an, um sicherzustellen, dass die folgende Beschreibung auch zu einem späteren Zeitpunkt noch funktioniert.
Ein neues Angular-Projekt anlegen
Zunächst legt man ein neues Angular-Projekt an. Das geschieht mit dem Kommandozeilentool Angular CLI. Das von Google bereitgestellte Standardtool zum Starten neuer Angular-Projekte ist quelloffen und von Google bereitgestellt. Dazu müssen Entwickler folgende Befehle ausführen:
npm i -g @angular/cli@8.3.4
ng new design-systems --routing=false --style=scss
cd design-systems
ng serve --open
Hat alles geklappt, öffnet sich daraufhin der Standardbrowser des Betriebssystems und zeigt die Angular-Standardseite an (s. Abb. 7).
Hat die Installation des Angular-Projekts geklappt, ist dieser Bildschirm zu sehen. (Abb. 7)
Storybook-Unterstützung installieren
Als nächstes muss man in der Codebasis der Angular-Anwendung die Storybook-Unterstützung installieren. Dazu müssen Anwender zunächst das zuvor ausgeführte Kommando durch Drücken von Ctrl + C anhalten (unter Windows muss man das gegebenenfalls nochmal quittieren). Dann ruft man folgenden Befehl auf:
npx -p @storybook/cli@5.2.3 sb init
Das führt das Storybook CLI aus. Das Kommandozeilentool erkennt das verwendete Framework und führt die erforderlichen Schritte aus, um Storybook dort verfügbar zu machen. Nach erfolgreicher Installation können Anwender Storybook über das folgende Kommando starten (s. Abb. 8):
npm run storybook
Erste Schritte mit Storybook
Bei erfolgreicher Durchführung öffnet sich die Storybook-Benutzeroberfläche mit einer Willkommensnachricht sowie den ersten Beispiel-Storys. Storys sind das Äquivalent zu einem Unit-Test. Sie bilden Testfälle, beziehungsweise Zustände einer Komponente ab.
Hat die Installation von Storybook funktioniert, öffnet sich dieser Bildschirm. (Abb. 8)
Fazit und Ausblick
Nach einer kurzen Setup-Phase können Entwickler nun erste Komponenten mit Storybook testen und eine Komponentenbibliothek bereitstellen. Durch das vorhandene Tooling lässt sich der Prozess auch in weiteren Projekten einfach einbinden.
Der nächste Artikel der Serie stellt den Entwicklungs-Workflow vor. Er erstellt eine UI-Komponente in Figma, implementiert sie in Angular und macht sie in Storybook zugänglich – mit dem Storybook-Add-ons Knobs auch für Nichtentwickler.
Christian Liebel [11] ist Consultant bei der Thinktecture AG in Karlsruhe. Dort entwickelt er moderne Cross-Plattform-Apps auf Basis von Angular und .NET Core. Christian ist mit dem Web groß geworden und hat sein Handwerk mit Microsoft-Technologien gelernt. Er ist begeistert von den neuen Möglichkeiten der Anwendungsentwicklung, die sich mit HTML5 und JavaScript erschließen.
Andeas Wissel [12] ist als User Experience Architect für INNOQ Deutschland in Frankfurt am Main tätig. In Zusammenarbeit mit seinen Kunden konzipiert er greifbare Cross-Plattform-Anwendungskonzepte und hilft dabei, ein besseres Verständnis für die Rolle von User Experience im Enterprise-Umfeld zu entwickeln. Sein Fokus liegt dabei aktuell auf Design Systems, UX-Workflows und isolierten Komponenten. Er bloggt auf www.andreaswissel.com [13].(bbo [14])
URL dieses Artikels: https://www.heise.de/-4634522
