Aus eigener Erfahrung weiß ich, dass die Entwicklung von Frontend Lösungen vielerorts in etwa so abläuft: Im besten Fall werden in unterschiedlichen Arbeitsschritten zunächst Wireframes definiert. Anschließend werden diese im Zuge des Designprozesses einmal quer durch die gängigen Adobe-Produkte geschleift und in der Regel in eine mehr oder weniger vollständige Wundertüte aus .psd, .jpg, .png, .svg, etc. Dateien und diversen Schriftarten transformiert und an den „Themer“ übergeben.
Der folgende Arbeitsschritt beginnt also mit einer Identitätskrise des Frontend Developers.
An diesem Punkt stehen wir an einem Scheideweg. Nicht selten entscheidet man sich dann für den scheinbar leichteren Weg. Seite für Seite werden die unterschiedlichst gearteteten HTML-Konstrukte entsprechend des Designs platziert und angemalt. Irgendwie fühlt man sich schmutzig, aber dafür gibt es keine Diskussionen mit dem Designer und der Kunde hat ja schließlich jeden Pixel einzeln abgesegnet. Im schlimmsten Fall findet ein Hack nach dem anderen findet seinen Weg ins Theme und spätestens nach den ersten ein- oder zweitausend Zeilen CSS ist von Wartbarkeit nicht mehr zu sprechen.
Alternativ lässt sich das Design mühsam Reverse Engineeren. Dabei wird die Vorlage zunächst interpretiert und dann in einzelne logische Komponenten aufgeteilt. Die daraus resultierenden Bausteine werden dann Stück für Stück in CSS umgesetzt und so gut wie möglich auf das Theme angewendet. Weniger schmutzig, aber auch nicht ideal.
Beide Szenarien sind aus ganz unterschiedlichen Gründen absolut suboptimal. Das Model “Adobe2Theme” ist aus Gründen der Menschenwürde weder dem Designer noch dem Entwickler zumutbar.
Eine Alternative im Frontend-Development
Unserer Meinung nach ist die Entwicklung von Frontend-Lösungen ein integrativer und fließender Prozess, der entgegen der obigen Darstellung nicht beim Wireframing beginnt und beim Theming aufhört. Um dem gerecht zu werden setzen wir seit einiger Zeit Living Styleguides ein.
Ein Living Styleguide (oftmals auch “Pattern Library”) ist eine auf HTML, CSS und JS basierende, grafische Repräsentation der User Interface-Bestandteile einer Applikation. Entgegen einer einfachen Photoshop-Datei bzw. eines Static Styleguides, z.B. in Form eines starren Textdokuments, werden beim Living Styleguide also vollwertigen Prototypen der einzelnen zu erwartenden Bestandteile der entstehenden Applikation als unabhängige Komponenten unter realistischen Bedingungen im Browser dargestellt. Im Gegensatz zu einem statischen Dokument lassen sich die einzelnen Komponenten einfach erweitern und Derivate ableiten. Durch die unabhängige Aufbereitung jeder Komponente entsteht ein besonderer Fokus auf Semantik und optimaler Umsetzung und Strukturierung von HTML und CSS. Das ursprüngliche Konzept wir dabei laufend validiert. Ein besonderer Vorteil dieser Herangehensweise ist die fast zwingende, vollständige Aufarbeitung der Typographie als sog. Basis Komponente.
Der Einsatz eines Living Styleguides ist also nicht ausschließlich Dokumentation und Bauanleitung, sondern essentieller Bestandteil von Konzeption, Design und Umsetzung. Denn: Die Effektivität eines Living Styleguides liegt im besonderen Maß auch an der Ideologie und der Workflows, die er bedingt und vermittelt.
Mit anderen Worten: ! Wenn die von uns entwickelten Themes leckere Törtchen wären, dann wäre der Styleguide der Tortenboden und nicht das Sahnehäubchen.
Durch die Verwendung eines Living Styleguides sind alle Parteien bereits von Beginn an involviert. Missverständnissen zwischen Designer und Entwickler werden so vorgebeugt und gegenseitiges Verständnis aufgebaut, während bei allen Beteiligten ein Lerneffekt des gegenüberstehenden Arbeitsfeldes einsetzt. Konkret bedeutet das, dass unsere Designer inzwischen einen Großteil ihrer Arbeit selber in Sass bzw. CSS und HTML abbilden können. Der Styleguide wird also mehr und mehr zu einem Resultat der interdisziplinäre Teamarbeit und nicht nur abschließende Dokumentation bzw. Aufarbeitung des übergebenen Designs.
Ein weiterer Vorteil liegt in der ständigen Erweiterbarkeit des Styleguides und dessen Flexibilität in Bezug auf Änderungen (Maintainability). Darüber hinaus wird auf diesem Weg eine projektübergreifende Wiederverwendung sämtlicher Komponenten sowie eine parallele Erweiterung durch mehrere Entwicklerteams ermöglicht. Anstatt für verschiedene Projekte mit dem gleichen Corporate Design die jeweilig verwendeten Komponenten neu zu erfinden, können diese aus dem Styleguide entnommen und ggf. erweitert werden. Der Styleguide kann somit auch für den Kunden als durchaus nützliches, eigenständiges Produkt anerkannt werden.
Ein Ausblick
Dies ist der erste Blogpost einer Serie rund um das Thema Living Styleguide. Nachdem ich nun unsere Philosophie in Bezug auf Frontend Entwicklung und Styleguides erläutert habe werden wir demnächst auf die von uns verwendeten Tools und Practices eingehen.
Noch kein Kommentar, Füge deine Stimme unten hinzu!