Konzepter und Benutzer von Axure Libraries wissen: man muss das Rad nicht neu erfinden. Darum gibt es gut-durchdachte UI Pattern Libraries. Aber wie sieht das Ganze in der Entwicklung aus? Wie kann man einzelne Bausteine für die Frontend-Entwicklung erstellen, ohne gleich eine Bibliothek aus Codeschnipseln bauen zu müssen? Ich habe beim vergangenen UX Roundtable im Dezember, 2014 eine mögliche Lösung vorgestellt: Precompiling.

Wenn wir ehrlich sind, dann erfinden wir das Rad bei Webseiten mit jedem Projekt nicht neu, sondern greifen gerne auf altbewährte Oberflächen-Elemente zurück. Das ist auch die Idee von UI Pattern und Axure Libraries. Diese bestehen aus bereits gestalteten oder durchdachten Elementen, die für das jeweilige Projekt nur noch eingefügt und angepasst werden.

Das Problem: starre technische Strukturen und Blockaden

Doch in der Umsetzung sieht das Ganze wieder ein wenig anders aus: die starren Syntax-Strukturen von den Sprachen HTML und CSS lassen keine Aufteilung in Komponenten zu. Das Problem dabei ist, dass für jedes neue Projekt viel aus bestehenden Projekten kopiert oder für das derzeitige Projekt neu geschrieben werden muss. Aber noch viel größer ist der Kommunikationslücke zwischen Konzeptern und Entwicklern: durch die unterschiedliche Struktur ist ebenfalls das Mindset des Projektes unterschiedlich. Das bedeutet, dass im Zweifel mühselige Übersetzungen von der Konzeption zur Entwicklung - meist in Form einer Spezifikation - nötig sind.

Das Problem sind dabei nicht die Entwickler, sondern die Umgebung, in der sie arbeiten: sie müssen ihr Denken an die vorhandene Programmiersprache anpassen - so wie Fließbandarbeiter ihren Arbeitstakt an die Maschine anpassen müssen. Die Lösung ist also, die Programmiersprache zu ändern, um diese Blockade aufzubrechen. Was daraus resultiert, sind Dateien, die mehrere Tausend bis Hunderttausend Zeilen an Code beinhalten. Natürlich bekommen Entwickler durch so viele Zeilen Code auch noch andere Probleme - wie beispielsweise die Übersichtlichkeit vom Code und damit auch die benötigte Zeit für eine Änderung.

Die Lösung: Precompiling

Die Lösung heißt Precompiling und ermöglicht das Benutzen anderer Programmiersprachen oder -syntaxen. So kann beispielsweise die Syntax von CSS so erweitert werden, sodass es möglich ist, die ursprüngliche CSS-Datei in viele kleine Komponenten zu unterteilen. Und das gleiche kann mit HTML auch gemacht werden.

Durch Precompiling werden die einzelnen Komponenten dann wieder in das jeweilige Format zusammen gesetzt, das der Browser für die Darstellung der Webseite benötigt.

Die Sprachen und Tools

Wir haben also nun die Technik, die starre Strukturen von HTML und CSS aufbrechen kann. Was wir nun benötigen, sind die jeweiligen Spracherweiterungen und der Precompiler selbst.

Für CSS gibt es sowohl die Sprache SASS als auch LESS, die sich nach einigen Jahren Weiterentwicklung bei den Entwicklern etabliert haben. Vor allen für SASS existieren bereits viele andere Bibliotheken, die jeder Entwickler zu schätzen wissen wird.

Die Sprachen SASS und LESS sind sehr mächtig und bieten viele Vorteile. So können Mix ins und Funktionen geschrieben werden, die den Code automatisch erweitern. Wieder eine Zeitersparnis also. Außerdem ermöglichen es beide Sprachen, Variablen für Farben, Schriftgröße usw. festzusetzen. So können Änderungen im Contextual Design über das gesamte Design hinweg schnell und effizient eingepflegt werden. Eine Farbänderung von Blau zu Violett kann so innerhalb weniger Sekunden erfolgen.

Für selbstständige Entwickler ist das besonders praktisch: sie müssen nur noch kleine Anpassungen bei einem neuen Webseiten-Projekt vornehmen, um die Webseite komplett neu zu gestalten.

Für HTML sieht die Welt deutlich anders aus. Es gibt bisher ein mir bekanntes Konzept, welches die Aufteilung von HTML-Dateien in Komponenten erlaubt und anwendbar macht. Dieses Konzept wurde in den so genannten Hammer Tags (http://hammerformac.com/docs/tags) in der zugehörigen Hammer Mac App http://hammerformac.com) umgesetzt.

Mit Hammer haben wir auch gleichzeitig eine App, die das Precompiling von unseren HTML-Komponenten erlaubt. Eine weitere App für den Mac ist CodeKit oder Koala. Alle drei Apps sind vom Prinzip her ziemlich ähnlich: man zieht den Projektordner in die jeweilige App rein und die App erledigt den Rest - vom Erkennen der zu kompilierenden Dateien bis hin zur Prekompilierung selbst. Die komponentenweise Aufteilung von HTML und CSS erlaubt allerdings bis heute nur Hammer mit den Hammer Tags (der Precompiler ist mittlerweile aber Open Source und könnte in Zukunft auch in anderen Apps benutzt werden: https://github.com/riothq/hammer-gem).

Die Struktur

Wie strukturiert man aber nun die einzelnen Komponenten? Klar ist, dass diese Komponenten durchaus zusammen gesteckt werden können. So können eine Navigationsleiste und ein Logo gemeinsam den Kopfbereich einer Webseite bilden. Auf der anderen Seite beinhaltet die Navigationsleiste jeweils die einzelnen Navigationselemente. Fakt ist, dass diese Elemente durch ihre Komposition eine gewisse Hierarchie darstellen. Ein Fußbereich einer Webseite besteht aus mehreren kleineren Unterteilungen, die wiederum aus vielen kleineren Unterteilungen bestehen.

Brad Frost hat 2013 bei der Konferenz „Beyond Tellerrand“ in Düsseldorf eine Struktur vorgestellt, die sich auf den atomaren Aufbau von Organismen orientiert. Die Idee ist, dass größere Strukturen (wie Organismen) kleinere Strukturen (wie Moleküle) beinhalten können. Das „Atomic Design“ ist meiner Meinung nach eine sehr gute Grundlage, denn nicht anders strukturieren wir unsere Axure Libraries, die wir für Kunden bauen. Für die Entwicklung müssen wir diese Struktur allerdings noch etwas kleinteiliger strukturieren, damit wir die Wiederverwendbarkeit der einzelnen Elemente und Codezeilen gewährleisten können. Daher fangen wir mit dem ersten Element der Kette an: dem Proton.

Protonen

Die aus dem altgriechischen übersetzte „Ersten“ Teilchen unserer Struktur sind dafür zuständig, sämtliche notwendigen Bestandteile unseres Projektes - wie die SASS-eigenen Mix ins oder Funktionen - zu deklarieren. Hier steckt sozusagen alles drin, was bei nahezu jedem Element und Projekt benutzt werden kann und sollte. Somit sind hier auch die Variablen zu finden, die durch wenige Änderungen die gesamte Seite neu gestalten könnten.

Atomkern

Der Atomkern beinhaltet die Kernelemente, die ebenfalls in jedem Projekt zu finden sind, also grundsätzliche Gestaltungen von Tabellen, Typografien, Buttons und Formularfeldern. Es ist sozusagen eine Ansammlung vieler kleiner Gestaltungsmuster von User Interface Elementen. Wer hier sorgfältig Best Practices auswählt, braucht sich um solche Gestaltungsmuster keine Gedanken mehr zu machen, sondern kopiert diese nur noch von Projekt zu Projekt.

Atom

Die erste projektbezogene Strukturebene ist das Atom. Hier werden sämtliche Elemente aus dem Atomkern nochmals angepasst und auch neue, spezifischere kleine Elemente (meistens definiert durch CSS-Klassen) gestaltet.

Moleküle

Die Moleküle sind die ersten kleinen Kompositionen, speziell zum vorliegenden Projekt. So kann ein grundsätzliches Navigationselement oder eine Kombination aus einem Formularfeld und Button hier gestaltet werden.

Organismen

Organismen sind ganze Teilbereiche einer Seite, wie beispielsweise der Kopf- oder Fußbereich.

Templates

Die Organismen werden am Ende bei der nächstgrößeren Struktur - den Templates - in der richtigen Reihenfolge eingebunden

Pages

Für spezifische Seiten kann nun in der letzten Strukturebene die Gestaltung angepasst werden. So kann die Hauptseite anders als der Blog aussehen, ohne dabei die grundsätzliche Gestaltung einzelner Elemente allzu sehr zu verfälschen.

Diese gesamte Struktur mündet letztendlich in eine Dummy-SASS oder Dummy-LESS Datei, wodurch eine einzige CSS-Datei entsteht.

Mit dieser Struktur haben wir also eine hierarchische Abbildung einzelner Elemente. Durch die zusätzlichen zwei Strukturebenen Protonen und Atomkern haben wir außerdem bereits zwei Strukturebenen für eine eigene Bibliothek. Diese beiden Ebenen können in jedem Projekt genutzt werden.

Einige Elemente aus den weiteren Strukturen Atom und Moleküle können ebenfalls genutzt werden, allerdings ist die Gestaltung hier immer auf das jeweilige Projekt bezogen.

Fazit

Durch das Precompiling der Erweiterungssprachen wie SASS und Hammer Tags können Frontend-Entwickler eine sehr ähnliche Struktur von Bausteinen aufbauen, wie sie Prototypen-Entwickler mit Axure Libraries oder wie Konzepter mit UI Pattern Libraries aufbauen und nutzen. Missverständnisse können so verringert und verhindert werden, weil jeder im Team von der gleichen Sache spricht. Aber vor allem für die Entwickler bietet Precompiling einen entscheidenden Mehrwert: Änderungen können viel schneller durchgeführt werden, da die Aufteilung in Komponenten einen deutlich besseren Überblick verschafft.