Aus eigener Erfahrung wei\u00df ich, dass die Entwicklung von Frontend L\u00f6sungen vielerorts in etwa so abl\u00e4uft: Im besten Fall werden in unterschiedlichen Arbeitsschritten zun\u00e4chst Wireframes definiert. Anschlie\u00dfend werden diese im Zuge des Designprozesses einmal quer durch die g\u00e4ngigen Adobe-Produkte geschleift und in der Regel in eine mehr oder weniger vollst\u00e4ndige Wundert\u00fcte aus .psd, .jpg, .png, .svg, etc. Dateien und diversen Schriftarten transformiert und an den „Themer“ \u00fcbergeben.<\/p>\n

Der folgende Arbeitsschritt beginnt also mit einer Identit\u00e4tskrise des Frontend Developers.<\/p>\n

An diesem Punkt stehen wir an einem Scheideweg. Nicht selten entscheidet man sich dann f\u00fcr den\u00a0scheinbar<\/strong>\u00a0leichteren Weg. Seite f\u00fcr Seite werden die unterschiedlichst gearteteten HTML-Konstrukte entsprechend des Designs platziert und angemalt. Irgendwie f\u00fchlt man sich schmutzig, aber daf\u00fcr gibt es keine Diskussionen mit dem Designer und der Kunde hat ja schlie\u00dflich jeden Pixel einzeln abgesegnet. Im schlimmsten Fall findet ein Hack nach dem anderen findet seinen Weg ins Theme und sp\u00e4testens nach den ersten ein- oder zweitausend Zeilen CSS ist von Wartbarkeit nicht mehr zu sprechen.<\/p>\n

Alternativ l\u00e4sst sich das Design m\u00fchsam Reverse Engineeren. Dabei wird die Vorlage zun\u00e4chst interpretiert und dann in einzelne logische Komponenten aufgeteilt. Die daraus resultierenden Bausteine werden dann St\u00fcck f\u00fcr St\u00fcck in CSS umgesetzt und so gut wie m\u00f6glich auf das Theme angewendet. Weniger schmutzig, aber auch nicht ideal.<\/p>\n

Beide Szenarien sind aus ganz unterschiedlichen Gr\u00fcnden absolut suboptimal. Das Model \u201cAdobe2Theme\u201d ist aus Gr\u00fcnden der Menschenw\u00fcrde weder dem Designer noch dem Entwickler zumutbar.<\/p>\n

Eine Alternative im Frontend-Development<\/h2>\n

Unserer Meinung nach ist die Entwicklung von Frontend-L\u00f6sungen ein integrativer und flie\u00dfender Prozess, der entgegen der obigen Darstellung\u00a0nicht<\/strong>\u00a0beim Wireframing beginnt und beim Theming aufh\u00f6rt. Um dem gerecht zu werden setzen wir seit einiger Zeit Living Styleguides ein.<\/p>\n

Ein Living Styleguide (oftmals auch \u201cPattern Library\u201d) ist eine auf HTML, CSS und JS basierende, grafische Repr\u00e4sentation 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\u00e4ngige 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\u00e4ngige Aufbereitung jeder Komponente entsteht ein besonderer Fokus auf Semantik und optimaler Umsetzung und Strukturierung von HTML und CSS. Das urspr\u00fcngliche Konzept wir dabei laufend validiert. Ein besonderer Vorteil dieser Herangehensweise ist die fast zwingende, vollst\u00e4ndige Aufarbeitung der Typographie als sog. Basis Komponente.<\/p>\n

Der Einsatz eines Living Styleguides ist also nicht ausschlie\u00dflich Dokumentation und Bauanleitung, sondern essentieller Bestandteil von Konzeption, Design und Umsetzung. Denn: Die Effektivit\u00e4t eines Living Styleguides liegt im besonderen Ma\u00df auch an der Ideologie und der Workflows, die er bedingt und vermittelt.<\/p>\n

Mit anderen Worten: ! Wenn die von uns entwickelten Themes leckere T\u00f6rtchen w\u00e4ren, dann w\u00e4re der Styleguide der Tortenboden und nicht das Sahneh\u00e4ubchen.<\/p>\n

Durch die Verwendung eines Living Styleguides sind alle Parteien bereits von Beginn an involviert. Missverst\u00e4ndnissen zwischen Designer und Entwickler werden so vorgebeugt und gegenseitiges Verst\u00e4ndnis aufgebaut, w\u00e4hrend bei allen Beteiligten ein Lerneffekt des gegen\u00fcberstehenden Arbeitsfeldes einsetzt. Konkret bedeutet das, dass unsere Designer inzwischen einen Gro\u00dfteil ihrer Arbeit selber in Sass bzw. CSS und HTML abbilden k\u00f6nnen. Der Styleguide wird also mehr und mehr zu einem Resultat der interdisziplin\u00e4re Teamarbeit und nicht nur abschlie\u00dfende Dokumentation bzw. Aufarbeitung des \u00fcbergebenen Designs.<\/p>\n

Ein weiterer Vorteil liegt in der st\u00e4ndigen Erweiterbarkeit des Styleguides und dessen Flexibilit\u00e4t in Bezug auf \u00c4nderungen (Maintainability). Dar\u00fcber hinaus wird auf diesem Weg eine projekt\u00fcbergreifende Wiederverwendung s\u00e4mtlicher Komponenten sowie eine parallele Erweiterung durch mehrere Entwicklerteams erm\u00f6glicht. Anstatt f\u00fcr verschiedene Projekte mit dem gleichen Corporate Design die jeweilig verwendeten Komponenten neu zu erfinden, k\u00f6nnen diese aus dem Styleguide entnommen und ggf. erweitert werden. Der Styleguide kann somit auch f\u00fcr den Kunden als durchaus n\u00fctzliches, eigenst\u00e4ndiges Produkt anerkannt werden.<\/p>\n

Ein Ausblick<\/h2>\n

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\u00e4utert habe werden wir demn\u00e4chst auf die von uns verwendeten Tools und Practices eingehen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Aus eigener Erfahrung wei\u00df ich, dass die Entwicklung von Frontend L\u00f6sungen vielerorts in etwa so abl\u00e4uft: Im besten Fall werden in unterschiedlichen Arbeitsschritten zun\u00e4chst Wireframes definiert. Anschlie\u00dfend werden diese im Zuge des Designprozesses einmal quer durch die g\u00e4ngigen Adobe-Produkte geschleift und in der Regel in eine mehr oder weniger vollst\u00e4ndige Wundert\u00fcte aus .psd, .jpg, .png, […]<\/p>\n","protected":false},"author":20,"featured_media":1242,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[74,78,84],"tags":[214],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts\/1241"}],"collection":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/comments?post=1241"}],"version-history":[{"count":1,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts\/1241\/revisions"}],"predecessor-version":[{"id":1243,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts\/1241\/revisions\/1243"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/media\/1242"}],"wp:attachment":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/media?parent=1241"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/categories?post=1241"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/tags?post=1241"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}