Design Systems: Building for the Future

Der moderne Webdesign- und Entwicklungsprozess entwickelt sich rasant weiter, und responsive Websites werden schnell zur Norm. Frameworks wie Bootstrap und Foundation zeigen uns den Wert der Schaffung robuster Komponentensysteme, um den Aufbau von Dingen im Web schneller, besser und einfacher zu gestalten.

Vor etwa einem Jahr begann ich als UX Engineer bei (mt) Media Temple, einem Webhosting- und Cloud-Services-Unternehmen mit Sitz in Los Angeles. Mit der Aufgabe, die Frontend-Entwicklung des Redesigns der (mt)-Website zu leiten, nutzte ich die Gelegenheit, innezuhalten und meinen Ansatz für die Frontend-Entwicklung zu überdenken. So erkannte ich, dass die Art und Weise, wie ich zuvor große Websites erstellt hatte, etwas fehlerhaft war. Ich wollte einige meiner Lernerfahrungen teilen und den High-Level-Ansatz beleuchten, den ich beim Erlernen und Erstellen eines Designsystems gewählt habe.

Aber was genau ist ein Designsystem?

Auf der FOWA 2013 in London beschrieb Mark Otto ein Designsystem als „alles, was Ihr Produkt ausmacht“ (seine vollständige Präsentation finden Sie hier: Build your own Bootstrap).

Alles? Alles. Von Typografie, Layouts und Grids, Farben, Icons, Komponenten und Kodierkonventionen bis hin zu Stimme und Tonfall, Styleguide und Dokumentation – ein Designsystem vereint all dies auf eine Weise, die es Ihrem gesamten Team ermöglicht zu lernen, zu bauen und zu wachsen.

Zuerst war ich mir nicht sicher, ob ich etwas Eigenes bauen oder mit einem bestehenden Framework wie Bootstrap beginnen sollte. Letztendlich entschied ich mich gegen Letzteres aus mehreren Gründen:

• Wir hatten bereits ein individuelles Design. Als ich bei Media Temple anfing, waren die visuellen Entwürfe für die neue Website fast fertig. Wenn ich ein Framework verwendet hätte, müsste ich es *erheblich* anpassen, um es an unsere Designs anzupassen.
• Ich wollte Codierkonventionen und eine Struktur basierend auf den Vorlieben meines Teams etablieren. Auch hier hätte ich viel Zeit damit verbracht, Klassennamen umzubenennen oder Dinge neu zu organisieren, um sie an unsere Bedürfnisse anzupassen.

Der Zeitaufwand, den ich damit verbringen würde, das Framework im Grunde auszuräumen, schien es nicht wert zu sein. Ich hatte das Gefühl, dass der Aufbau unseres eigenen Frameworks langfristig von Vorteil, wartungsfreundlicher und als Bonus eine unglaubliche Lernerfahrung wäre. Es half auch, dass ich die Zeit dafür hatte und ein ganzes Team begeistert mitmachte.

Obere Ziele festlegen

Beim Wiederaufbau einer Legacy-Website hat man die Möglichkeit, vieles zu verbessern. Bevor ich mit der eigentlichen Entwicklung begann, legte ich einige übergeordnete Ziele fest:

• Organisation: Eine unordentliche Codebasis kann zum Albtraum werden. Eine gut durchdachte Struktur und Vorgehensweise war sehr wichtig.
• Wartbarkeit: Im Laufe der Zeit werden neue Entwickler hinzukommen, um Fehler zu beheben und Funktionen hinzuzufügen. Wir mussten richtige Richtlinien und Konventionen haben, um es den Leuten leicht zu machen, Dinge korrekt zu tun.
• Responsivität: Angesichts des stetigen Anstiegs des mobilen/Tablet-Traffics war es sehr wichtig, die Erfahrung plattformunabhängig zu gestalten.
• Skalierbarkeit: Das Unternehmen wird in Zukunft wachsen, und das sollte auch seine Website tun. Die Erstellung von Aktionsseiten und/oder neuen Produktseiten sollte keine unangenehme (und fast unmögliche) Aufgabe mehr sein.

Mein „Aha“-Moment

Mit den übergeordneten Zielen im Hinterkopf begann ich mit intensiver Recherche. Ich begann mit dem Lesen über HTML-Semantik und Frontend-Architektur und entdeckte die Vorteile des Aufbaus flexibler Module, nicht Seiten. Das war mein „Aha“-Moment.

Zuvor war ich beim Erstellen großer Websites daran gewöhnt, die Arbeit nach Seitenvorlagen aufzuteilen. Ich habe einen Satz zusammenhängender Vorlagen bearbeitet und bin dann zum nächsten übergegangen. Das Problem bei diesem Ansatz ist, dass, wenn die Kommunikation im Team nicht außergewöhnlich ist, viele ähnliche – manchmal identische – Module und Komponenten auf unterschiedliche Weise markiert und gestylt werden. Wenn Sie nicht die zusätzliche Zeit aufwenden, sie zu refaktorisieren, wird Ihre Codebasis zu einem absoluten Chaos.

Ich beschloss, zwei ausgezeichnete – aber unterschiedliche – Projekte sehr genau zu studieren: InuitCSS von Harry Roberts und Bootstrap von Mark Otto und Jacob Thornton, und mir wurde schnell klar, dass der nächste Schritt darin bestand, Richtlinien dafür festzulegen, wie unser HTML, CSS und JavaScript kodiert werden sollten und was unser gesamter Frontend-Ansatz sein sollte.

Kodierkonventionen und Richtlinien

Inspiriert von Idiomatic HTML, CSS Guidelines und Idiomatic JavaScript, begann ich, diese in unsere eigenen Kodierrichtlinien zu übernehmen. Dabei entdeckte und übernahm ich eine interessante Namensmethodik namens BEM (Block, Element, Modifier). Es ist im Wesentlichen eine clevere Art, Ihre CSS-Klassen zu benennen, um sie aussagekräftiger und einfacher zu verstehen zu machen.

Unsere leicht modifizierte Konvention ist:

• .block {} – Repräsentiert die Hauptkomponente.
• .block-elementName {} – Ein Kindelement, das dazu beiträgt, die Komponente als Ganzes zu bilden.
• .block--modifier {} – Eine Modifikatorklasse, die verwendet wird, um den Zustand oder das Erscheinungsbild der Komponente zu verändern.

Hier ist ein Beispiel für eine Alert-Box, die diesen Ansatz verwendet:

/* Main 'alert' component */
.alert {}

  /* Sub-components that make up the 'alert' */
  .alert-text {}
  .alert-close {}

/* Modifiers for various styles of the 'alert' */
.alert--warning {}
.alert--error {}
.alert--success {}
.alert--info {}

Außerdem habe ich eine Reihe von Tools finalisiert, die uns dabei helfen, darunter LESS für unsere CSS-Präprozessing-Bedürfnisse und Grunt, um unsere LESS-Dateien zu kompilieren und unseren Code zu komprimieren, zu minifizieren und zu verketten.

Entwicklung von Basisstilen

Ähnlich wie bei InuitCSS und Bootstrap erstellte ich eine primäre Stylesheet namens mt-global.less, die alle Seitenstile zusammen importiert und die endgültige mt-global.css-Datei erstellt. Um die Dinge organisiert zu halten, erstellte ich einige Ordner:

• core – Hier werden unsere benutzerdefinierten Variablen und Mixins gespeichert.
• vendor – Für verwendete Dienstprogramme von Drittanbietern, wie z. B. LESSHat und REMixins.
• base – Für alle zugrundeliegenden Basisstile wie Typografie, Farben und Struktur.

Ich begann mit normalize.css, passte es bei Bedarf an und fuhr fort, allgemeine Elemente wie Überschriften, Links, Listen, Formularelemente und Tabellen zu stylen.

Komponenten identifizieren und erstellen

Mit den Basisstilen an Ort und Stelle war es an der Zeit, sich die Website als Ganzes anzusehen und mit der Identifizierung einzelner Komponenten zu beginnen. Ich begann mit dem Aufbau eines benutzerdefinierten Grid-Systems, das auf dem für die Designs verwendeten Grid basierte. Von dort aus fuhr ich mit gängigen Elementen wie Buttons, Call-to-Action-Links, Hero-Einheiten und Navigation fort.

Während ich Komponenten erstellte, begann ich, Wege zu finden, gemeinsame Stile in wiederverwendbare Objekte zu abstrahieren, ähnlich dem Media Object. InuitCSS war hier eine große Hilfe, da es unzählige nützliche Objekte enthält. All diese Stile wurden in einen Ordner namens components gelegt.

Module identifizieren und erstellen

Da die meisten Komponenten einsatzbereit waren, war es an der Zeit, diese Bausteine zu verwenden, um die verschiedenen Module jeder Seite zu erstellen. Ich erstellte einen weiteren Ordner namens modules und begann, sie zusammenzusetzen, beginnend mit globalen Modulen wie dem Website-Header, Footer und der Hero-Einheit.

Muster etablieren

Während ich Komponenten und Module erstellte, begann ich, sie in einem Styleguide mit dem Style-Guide Boilerplate zu integrieren. Das Ergebnis war ein zentraler Bezugspunkt für jedes Teammitglied, das lernen wollte, wie man zum Projekt beiträgt. Sobald das gesamte Team Zugriff auf den Styleguide hatte, war der Aufbau von Seitenvorlagen ein Kinderspiel. Es war nur eine Frage des Kombinierens und Anpassens von Modulen sowie des Erweiterns oder Anpassens bei Bedarf.

Fazit

Der Aufbau eines Designsystems ist ein langer Prozess voller Versuche und Irrtümer. Etablierte Frameworks können Ihnen Wochen Entwicklungszeit sparen, aber wenn Sie Ihr Webprojekt mit einem Framework erstellt haben, das seitdem viele Versionen durchlaufen hat, kann die Wartung schwierig sein. Aktualisieren Sie Ihre Codebasis mit jeder Veröffentlichung? Was ist, wenn Sie es so stark angepasst haben, dass eine Aktualisierung nicht einmal mehr möglich ist?

Wenn Sie die Möglichkeit haben, eine Website von Grund auf neu aufzubauen, löst eine benutzerdefinierte Lösung viele Probleme: Sie hilft, ein maßgeschneidertes System zu etablieren, das es Ihrem gesamten Team ermöglicht, schnell und einfach zu lernen, wie es zu Ihrem Projekt beitragen kann; es wird von Ihnen und speziell für die Bedürfnisse Ihres Unternehmens erstellt; und vor allem wird es für die Zukunft gebaut. Ohne an die Entwicklung und Richtung eines anderen Projekts gebunden zu sein, kann es frei in Ihrem Unternehmenstempo skalieren.

Recherchieren. Bauen. Lernen. Wiederholen.
– John Polacek

Vor allem war es eine unglaubliche Lernerfahrung und eine große Quelle des Stolzes für unser Team. Ich ermutige jeden, die zahlreichen Ressourcen zu Designsystemen und dem sich ständig verändernden Webdesignprozess zu studieren.