Ein tolles UI-Design ist ein Anfang. Aber ist es auch nachhaltig strukturiert bzw. umgesetzt?

Nur durch nachhaltige Lösungen können wir langfristigen Erfolg sicherstellen.

Erweiterbarkeit, Wartbarkeit und Wiederverwendbarkeit sind auch im Frontend unabdingbar. In diesem Blogartikel werfen wir einen Blick auf den Aufbau von Frontend-Projekten. Je weiter wir im Blogartikel kommen, umso exklusiver werden die Prinzipien, die wir kennenlernen. Wir enthüllen Techniken, die Sie so auch bei großen Designagenturen nicht bekommen.

Die Basis: der Styleguide

Am Anfang unseres Blogartikels steht ein schönes UI-Design. Zum Beispiel in Form eines Styleguides. Der Styleguide dient als Spezifikation für die Umsetzung. Er enthält Farbdefinitionen oder beschreibt die Typographie. Also Schriftarten, Schriftgrößen oder Schriftschnitte. Ein Styleguide beschreibt auch das Design von Oberflächenelementen. Bei modernen Softwareprojekten ist ein Styleguide unerlässlich. Bei Codelution setzen wir diese Art der UI-Spezifikation deswegen als Minimum ein. Besser wäre es noch, den Styleguide zum Designsystem weiterzuentwickeln, aber das sprengt den Rahmen dieses Artikels.

Ein einfacher Styleguide muss nicht aufwändig sein. Hier sehen wir ein Beispiel mit 21 Seiten:

Daran können wir schon das erste Best-Practice für ein erfolgreiches Frontend Projekt erkennen:

Best-Practice #1:

Der Styleguide muss konsistent umgesetzt werden.

Hierzu sollte ein UI-Designer in die Entwicklung eingebunden werden. Der UI-Designer sollte die Arbeit der Entwickler reviewen. Wie ein Code Review sollte das Design Review regelmäßig durchgeführt werden - z.B. regelmäßig während der Sprints und auch wenn die Entwickler keine Rückfragen haben. Das geschulte Auge eines Profis lässt sich nicht einfach ersetzen.

Als nächstes stehen die Ziele Wiederverwendbarkeit, Erweiterbarkeit und Wartbarkeit an.

Der Schlüssel zur Wiederverwendbarkeit liegt in einer sinnvollen Modularisierung.

Softwareentwickler sind Modularisierung eigentlich gewöhnt. Interessant wird es im Bereich UI. Hier findet die Modularisierung nicht nur anhand der Domäne (Fachlichkeit) statt - wichtig ist auch noch die "Integrationstiefe". Konkret heißt das, dass wir zwischen Smart Components und Dumb Components unterscheiden.

Smart Components sind unsichtbare UI-Bausteine mit Domäne - also Geschäftslogik. Dumb Components sind primitive Oberflächenelemente, z.B. Steuerelemente (UI-"Controls") wie Textfelder und Buttons. Diese haben keine Logik.

Best-Practice #2:

Bei der Modularisierung zwischen Smart- und Dumb-Components trennen.

Smart Components verwenden Dumb Components (oder andere Smart Components). Dumb Components verwenden niemals Smart Components. Dumb Components empfangen Eingabedaten des Benutzers und übergeben diese an ihre Smart Components. Umgekehrt können Smart Components Daten an ihre Dumb Components übergeben, damit diese dem Benutzer angezeigt werden (Beispiel eine Label-Komponente).

Die Schachtelung von Smart und Dumb Components könnte dann ungefähr so aussehen (die Smart Components sind hier in türkis hervorgehoben, die Dumb Components in rot.:

An dieser Stelle werfen wir einen Blick auf die typische Modularisierung einer Anwendung. Die sog. Shell definiert den Rahmen, das Grundgerüst unserer Anwendung.

Die Anwendung ist weiter in Feature Module unterteilt. Bei modernen Webanwendungen werden diese "lazy" - also erst bei Bedarf vom Webserver geladen.

Die Featuremodule greifen auf geteilte Komponenten und Services zurück - z.B. in einem oder mehreren Domäne Modul/en.

Die Featuremodule und das/die Domänemodul/e sind die Stellen, in denen die Smart Components kodiert sind. Die Dumb Components sind auf einer tieferen Schicht kodiert, z.B. in einer Widget Bibliothek.

Die Referenzen verlaufen von oben nach unten:

Vor wenigen Jahren haben wir die Dumb Components noch technologiespezifisch umgesetzt. Bei Angular beispielsweise mit Widget Libraries. Der aktuelle Stand der Technik sind aber HTML5 Webcomponents. Diese sind "webtechnologieagnostisch" und können Framework übergreifend eingesetzt werden (Angular, React, Vue, ...). HTML5 Webcomponents können z.B. mit Lit.dev entwickelt werden.

Best-Practice #3:

Frameworkunabhängige Dumb Component Libraries auf Basis von HTML5 Webcomponents entwickeln.

Grundvoraussetzung für eine einfache Erweiterbarkeit ist die Modularisierung unserer Anwendung.

Eine Dumb Component Library, nennen wir sie "Widget-Library" lässt sich zentral erweitern und alle Konsumenten der Library können von den neuen Erweiterungen profitieren. Es versteht sich von selbst, dass bei größeren Softwaresystemen die Widget-Library wie ein eigenes Produkt versioniert, packetiert usw. werden sollte.

Jetzt gehen wir auf einen noch unbekannteren Aspekt der Widgets ein: ihrem übergeordneten Verwendungszweck - ihrem "superordinate type" sozusagen. Das bedeutet, dass wir unsere UI-Widgets kategorisieren und zwar nach: Struktur (also Layouting Components) und Verhalten (Behavior Components).

Best-Practice #4:

UI Widgets nach strukturellen Komponenten und Verhaltenskomponenten trennen.

Das heißt nicht, dass getrennte Widget Libraries für Structural oder Behavioral Components benötigt werden, sondern, dass bei der Kodierung der Komponenten die Aspekte Layout und Interaktion getrennt werden sollten.

Bleibt noch die Wartbarkeit als hegeres Ziel unseres "Softwaredesigns". Ein häufiges Problem bei der Entwicklung von UI Libraries ist, dass das Styling nicht von der strukturellen Definition der eigentlichen UI-Controls getrennt wird.

Für unser neues Projekt wollen wir aber nicht von vorneherein die Fehler für das nächste historisch gewachsene Softwareprodukt machen. Der nicht-funktionale Aspekt der Wartbarkeit soll wirklich im Vordergrund stehen.

Wir müssen das Styling, also das Aussehen von der "Struktur und dem Verhalten" der Widgets trennen - nur so können wir später ein guten Theming usw. realisieren. Außerdem erleichtert diese Vorgehensweise ungemein spätere Änderungen im Design.

Best-Practice #5:

Styling aus UI-Controls extrahieren und von top to bottom definieren.

Bei Webtechnologien setzen Sie als eine der Möglichkeiten CSS Variablen ein. Diese lassen sich im Gegensatz zu SASS / SCSS zur Laufzeit des Programms ändern und sind damit wirklich variabel.

FAZIT

In diesem Beitrag haben Sie die Basis zum Aufbau von nachhaltigen Designsystemen gelernt. Damit Sie nicht heute das Legacy System von morgen bauen sollten die folgenden Punkte berücksichtigt werden:

Im Detail gibt es natürlich noch mehr Best-Practices, aber das ist eine solide Basis. Go for it!